March 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Small usability glitch

by Benjamin

It works in Nautilus with almost the latest Pharo Ben On Mar 1, 2012, at 8:30 PM, Camillo Bruni wrote: > Hi sebastian > > This actually used to work that way. > Will check > > Best > Cami > > > -----Original message----- > From: Sebastian Sastre <sebastian(a)flowingconcept.com> > To: Pharo-project(a)lists.gforge.inria.fr > Sent: 2012 Mar, Thu, 1 19:25:01 GMT+00:00 > Subject: [Pharo-project] Small usability glitch > > Hey guys, > > when opening a SystemBrowser and executing a "Find class..." command (with context menu or cmd-f with focus in the packages pane) there is a dialog listing the classes that matches whatever you type. > > So far so great. > > The problem is that time and again I use the arrows keys to select the one that I was looking for and press enter only to get a dialog closed in a no-op. > > Note that: > 1. to make that dialog work, the only way is to use the mouse to click on OK or double click the target class and > 2. the input even says: "Hit return to accept" > > so.. > > sebastian > > o/ > > > >

March 1, 2012

Re: [Pharo-project] Small usability glitch

by Camillo Bruni

Hi sebastian This actually used to work that way. Will check Best Cami -----Original message----- From: Sebastian Sastre <sebastian(a)flowingconcept.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: 2012 Mar, Thu, 1 19:25:01 GMT+00:00 Subject: [Pharo-project] Small usability glitch Hey guys, when opening a SystemBrowser and executing a "Find class..." command (with context menu or cmd-f with focus in the packages pane) there is a dialog listing the classes that matches whatever you type. So far so great. The problem is that time and again I use the arrows keys to select the one that I was looking for and press enter only to get a dialog closed in a no-op. Note that: 1. to make that dialog work, the only way is to use the mouse to click on OK or double click the target class and 2. the input even says: "Hit return to accept" so.. sebastian o/

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Esteban Lorenzano

Hi, It is published on http://ss3.gemstone.com/ss/Mars, package Mars-Cocoa. You can also see the Alien ObjectiveC-Bridge as an example, on http://squeaksource.com/Alien, packages Alien-MaxOSX-* (those are hard to follow, but they work :) but... my names are more or less equal to yours (I just followed Eliot "de facto" convention) best, Esteban El 01/03/2012, a las 4:23p.m., Schwab,Wilhelm K escribiÃ³: > Esteban, > > Would you be willing to post your subclass? It might be useful both in defining signatures and in naming them. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] > Sent: Thursday, March 01, 2012 2:08 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Alien signature: first attempt > > Hi, > > sorry for not sending before: work is hard :P > yes, that should work, and no, I don't know a better way to define it. I think Eliot's idea is to form "libraries" of generic callbacks (for mars, for instance, I have CocoaCallback, child of Callback, who defines all my needed signatures, looks a lot at first instance, but if you see in detail, finally there are not so much variants) > > best, > Esteban > > El 01/03/2012, a las 3:57p.m., Schwab,Wilhelm K escribiÃ³: > >> Esteban, >> >> Will this work? Even if so, is there a better way to define it? >> >> longVoidStarLongRetInt: callbackContext sp: spAlien >> <signature: 'int (*) (long, void *, long)' abi: 'IA32'> >> ^callbackContext wordResult: >> (block >> value: (Alien newC:4) >> value: (Alien forPointer: (spAlien unsignedLongAt: 5)) >> value: (Alien newC:4) >> ) >> >> Bill >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] >> Sent: Thursday, March 01, 2012 12:15 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> thanks!!!!! >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] >> Sent: Wednesday, February 29, 2012 10:18 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> you need to define a signature... not at home now, but wait 'til tomorrow and I'll send an example >> >> best, >> Esteban >> >> El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: >> >>> What does "cannot find callback signature" mean from #signature:block:? I'm stuck. >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] >>> Sent: Wednesday, February 29, 2012 6:54 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>> >>> yeah... sorry about that >>> is a bug on FFI... I managed to worked around it for HPDF, for a customer's project... but of course is not a good and definitive solution. >>> >>> best, >>> Esteban >>> >>> El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: >>> >>>> This is gonna take a while... I had structs flying around as void* and was moderately happy. Nonetheless, your suggestion worked, provided I add a lot getHandle asInteger and change the void* to long :( >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] >>>> Sent: Wednesday, February 29, 2012 6:23 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>> >>>> I also found some problems using void* in linux... maybe you want to use long (which has same size)... I "fixed" my problems that way. >>>> >>>> yes... maybe we need to look at FFI to see why void* has problems some times, but well, that can help you atm (sorry for not having a better answer) >>>> >>>> Esteban >>>> >>>> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: >>>> >>>>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>>> Another glitch: is there any problem passing things as void*? I'm getting failure to coerce errors that did not arise before. >>>>>> >>>>> No idea. As you may suspect, i stopped using FFI/Alien once i got >>>>> NativeBoost toy to play with. >>>>> >>>>> Please file the issue, describing the problem. so we can look over it >>>>> and fix it. >>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >>>>>> Sent: Wednesday, February 29, 2012 5:51 PM >>>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>>>> >>>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>>>> Does 1.3 by default not create field accessors? Why is that? I thought >>>>>>> nothing was happening. >>>>>>> >>>>>> >>>>>> Good question, i'd like to know the answer too. >>>>>> It is related to MC final 'installation' phase, >>>>>> where it initializing all classes. >>>>>> >>>>>> In NativeBoost i was also using >>>>>> >>>>>> noteCompilationOf: aSelector meta: isMeta >>>>>> "A hook allowing some classes to react to recompilation of certain selectors" >>>>>> >>>>>> but there was a big question, at which point this hook is triggered, >>>>>> and looks like some changes in MC stop triggering it/triggering at >>>>>> wrong time (not all methods get into a class/ class not initialized >>>>>> etc), >>>>>> which makes it not very useful. >>>>>> >>>>>> So i ended up creating a DNU handler on instance side, then on DNU i >>>>>> check if i have field accessors and if not, >>>>>> compile them on the fly. >>>>>> >>>>>> >>>>>>> Bill >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > >

March 1, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by Benjamin

On Feb 29, 2012, at 7:51 PM, Mariano Martinez Peck wrote: > Ben/Laurent: it would be really nice to open issues so that not to forget things :) > sorry, but no time now :( > > On Wed, Feb 29, 2012 at 5:56 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Feb 29, 2012, at 8:44 AM, laurent laffont wrote: > >> Hi Benjamin, >> >> I've worked with Nautilus and I like it. Several nice ideas to work faster. Good work ! >> >> Bugs: >> - Go in groups, select a class. Click Hierarchy, then Groups. The Hierarchy/Flat button state is wrong. >> - jump to test class not working (MNU) > > Fixed, thanks :) > >> >> Suggestions: >> - we don't know if a test is running or finished. I would like some visual feedback. > > I am working on self destructive balloon morphs for such events. > Because you want a popup to get the info, but you do not want this popup to interrupt you :) > Something like Growl seems to work well ;) > (the same when no senders are found etc) I did that yesterday: http://dl.dropbox.com/u/24369478/VanishingMorph.mov (you can specify the position, the width the height, the margin, and it automatically split the text if it's too long ^^ ) Ben > >> - history: I would like to go backward faster without tens of click. Something like a drop down history like in web browsers > > Yes, I will work on that ;) > >> - I hardly see if I browse instance or class side. Maybe change class color/font would help. > > I fixed that :) Now on class side, protocol and methods font is bold. > >> - In Amber commented classes have not the same font color. Easy to see which class to look at for documentation. > > Here, uncommented class get this icon <UncommentedClass.png> > >> - Right click on a class, Analyzing menu. Create inst var / Create initializer / Generate / Force generation... entries should better be in refactoring ? > > In fact, this menu is the poor version of refactoring which is here even in the core version (like in Browser). > Normally, all this entries should be also present in a RB version, but I do not have time to learn how RB works right now :s > > > Thanks for your feedback and your suggestions :) > > > Ben > >> >> Cheers >> >> Laurent >> >> On Sun, Feb 26, 2012 at 6:28 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> Hi guys, >> >> I really want to thank you all for your feedbacks which give me the will to always add cool features to Nautilus. >> >> Thanks to that, let me introduce the new stable version with some new features: >> >> - better groups (now the granularity is method and no longer class) >> - better algorithm for coloring protocols and methods >> - more menu entries and shortcuts >> - Monticello integration >> - OCompletion integration >> - a lot of new icons :) >> >> (and some cleans in the code but ^^) >> >> >> Thanks every one for your good energy :) >> >> >> Ben >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

March 1, 2012

Re: [Pharo-project] Small usability glitch

by Marcus Denker

On Mar 1, 2012, at 8:24 PM, Sebastian Sastre wrote: > Hey guys, > > when opening a SystemBrowser and executing a "Find class..." command (with context menu or cmd-f with focus in the packages pane) there is a dialog listing the classes that matches whatever you type. > > So far so great. > > The problem is that time and again I use the arrows keys to select the one that I was looking for and press enter only to get a dialog closed in a no-op. > > Note that: > 1. to make that dialog work, the only way is to use the mouse to click on OK or double click the target class and > 2. the input even says: "Hit return to accept" > I think this is fixed in 1.4. The class find dialog is now usable just by keyboard... (Camillo fixed that). Marcus -- Marcus Denker -- http://marcusdenker.de

March 1, 2012

[Pharo-project] Small usability glitch

by Sebastian Sastre

Hey guys, when opening a SystemBrowser and executing a "Find class..." command (with context menu or cmd-f with focus in the packages pane) there is a dialog listing the classes that matches whatever you type. So far so great. The problem is that time and again I use the arrows keys to select the one that I was looking for and press enter only to get a dialog closed in a no-op. Note that: 1. to make that dialog work, the only way is to use the mouse to click on OK or double click the target class and 2. the input even says: "Hit return to accept" so.. sebastian o/

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Schwab,Wilhelm K

Esteban, Would you be willing to post your subclass? It might be useful both in defining signatures and in naming them. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] Sent: Thursday, March 01, 2012 2:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Alien signature: first attempt Hi, sorry for not sending before: work is hard :P yes, that should work, and no, I don't know a better way to define it. I think Eliot's idea is to form "libraries" of generic callbacks (for mars, for instance, I have CocoaCallback, child of Callback, who defines all my needed signatures, looks a lot at first instance, but if you see in detail, finally there are not so much variants) best, Esteban El 01/03/2012, a las 3:57p.m., Schwab,Wilhelm K escribiÃ³: > Esteban, > > Will this work? Even if so, is there a better way to define it? > > longVoidStarLongRetInt: callbackContext sp: spAlien > <signature: 'int (*) (long, void *, long)' abi: 'IA32'> > ^callbackContext wordResult: > (block > value: (Alien newC:4) > value: (Alien forPointer: (spAlien unsignedLongAt: 5)) > value: (Alien newC:4) > ) > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Thursday, March 01, 2012 12:15 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > thanks!!!!! > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] > Sent: Wednesday, February 29, 2012 10:18 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > you need to define a signature... not at home now, but wait 'til tomorrow and I'll send an example > > best, > Esteban > > El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: > >> What does "cannot find callback signature" mean from #signature:block:? I'm stuck. >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] >> Sent: Wednesday, February 29, 2012 6:54 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> yeah... sorry about that >> is a bug on FFI... I managed to worked around it for HPDF, for a customer's project... but of course is not a good and definitive solution. >> >> best, >> Esteban >> >> El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: >> >>> This is gonna take a while... I had structs flying around as void* and was moderately happy. Nonetheless, your suggestion worked, provided I add a lot getHandle asInteger and change the void* to long :( >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] >>> Sent: Wednesday, February 29, 2012 6:23 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>> >>> I also found some problems using void* in linux... maybe you want to use long (which has same size)... I "fixed" my problems that way. >>> >>> yes... maybe we need to look at FFI to see why void* has problems some times, but well, that can help you atm (sorry for not having a better answer) >>> >>> Esteban >>> >>> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: >>> >>>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>> Another glitch: is there any problem passing things as void*? I'm getting failure to coerce errors that did not arise before. >>>>> >>>> No idea. As you may suspect, i stopped using FFI/Alien once i got >>>> NativeBoost toy to play with. >>>> >>>> Please file the issue, describing the problem. so we can look over it >>>> and fix it. >>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >>>>> Sent: Wednesday, February 29, 2012 5:51 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>>> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>>> Does 1.3 by default not create field accessors? Why is that? I thought >>>>>> nothing was happening. >>>>>> >>>>> >>>>> Good question, i'd like to know the answer too. >>>>> It is related to MC final 'installation' phase, >>>>> where it initializing all classes. >>>>> >>>>> In NativeBoost i was also using >>>>> >>>>> noteCompilationOf: aSelector meta: isMeta >>>>> "A hook allowing some classes to react to recompilation of certain selectors" >>>>> >>>>> but there was a big question, at which point this hook is triggered, >>>>> and looks like some changes in MC stop triggering it/triggering at >>>>> wrong time (not all methods get into a class/ class not initialized >>>>> etc), >>>>> which makes it not very useful. >>>>> >>>>> So i ended up creating a DNU handler on instance side, then on DNU i >>>>> check if i have field accessors and if not, >>>>> compile them on the fly. >>>>> >>>>> >>>>>> Bill >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >> >> >> > > > >

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Esteban Lorenzano

Hi, sorry for not sending before: work is hard :P yes, that should work, and no, I don't know a better way to define it. I think Eliot's idea is to form "libraries" of generic callbacks (for mars, for instance, I have CocoaCallback, child of Callback, who defines all my needed signatures, looks a lot at first instance, but if you see in detail, finally there are not so much variants) best, Esteban El 01/03/2012, a las 3:57p.m., Schwab,Wilhelm K escribiÃ³: > Esteban, > > Will this work? Even if so, is there a better way to define it? > > longVoidStarLongRetInt: callbackContext sp: spAlien > <signature: 'int (*) (long, void *, long)' abi: 'IA32'> > ^callbackContext wordResult: > (block > value: (Alien newC:4) > value: (Alien forPointer: (spAlien unsignedLongAt: 5)) > value: (Alien newC:4) > ) > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Thursday, March 01, 2012 12:15 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > thanks!!!!! > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] > Sent: Wednesday, February 29, 2012 10:18 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > you need to define a signature... not at home now, but wait 'til tomorrow and I'll send an example > > best, > Esteban > > El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: > >> What does "cannot find callback signature" mean from #signature:block:? I'm stuck. >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] >> Sent: Wednesday, February 29, 2012 6:54 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> yeah... sorry about that >> is a bug on FFI... I managed to worked around it for HPDF, for a customer's project... but of course is not a good and definitive solution. >> >> best, >> Esteban >> >> El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: >> >>> This is gonna take a while... I had structs flying around as void* and was moderately happy. Nonetheless, your suggestion worked, provided I add a lot getHandle asInteger and change the void* to long :( >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] >>> Sent: Wednesday, February 29, 2012 6:23 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>> >>> I also found some problems using void* in linux... maybe you want to use long (which has same size)... I "fixed" my problems that way. >>> >>> yes... maybe we need to look at FFI to see why void* has problems some times, but well, that can help you atm (sorry for not having a better answer) >>> >>> Esteban >>> >>> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: >>> >>>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>> Another glitch: is there any problem passing things as void*? I'm getting failure to coerce errors that did not arise before. >>>>> >>>> No idea. As you may suspect, i stopped using FFI/Alien once i got >>>> NativeBoost toy to play with. >>>> >>>> Please file the issue, describing the problem. so we can look over it >>>> and fix it. >>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >>>>> Sent: Wednesday, February 29, 2012 5:51 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>>> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>>> Does 1.3 by default not create field accessors? Why is that? I thought >>>>>> nothing was happening. >>>>>> >>>>> >>>>> Good question, i'd like to know the answer too. >>>>> It is related to MC final 'installation' phase, >>>>> where it initializing all classes. >>>>> >>>>> In NativeBoost i was also using >>>>> >>>>> noteCompilationOf: aSelector meta: isMeta >>>>> "A hook allowing some classes to react to recompilation of certain selectors" >>>>> >>>>> but there was a big question, at which point this hook is triggered, >>>>> and looks like some changes in MC stop triggering it/triggering at >>>>> wrong time (not all methods get into a class/ class not initialized >>>>> etc), >>>>> which makes it not very useful. >>>>> >>>>> So i ended up creating a DNU handler on instance side, then on DNU i >>>>> check if i have field accessors and if not, >>>>> compile them on the fly. >>>>> >>>>> >>>>>> Bill >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >> >> >> > > > >

March 1, 2012

[Pharo-project] Alien signature: first attempt

by Schwab,Wilhelm K

Esteban, Will this work? Even if so, is there a better way to define it? longVoidStarLongRetInt: callbackContext sp: spAlien <signature: 'int (*) (long, void *, long)' abi: 'IA32'> ^callbackContext wordResult: (block value: (Alien newC:4) value: (Alien forPointer: (spAlien unsignedLongAt: 5)) value: (Alien newC:4) ) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Thursday, March 01, 2012 12:15 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI on 1.3: compile fields thanks!!!!! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] Sent: Wednesday, February 29, 2012 10:18 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI on 1.3: compile fields you need to define a signature... not at home now, but wait 'til tomorrow and I'll send an example best, Esteban El 29/02/2012, a las 11:21p.m., Schwab,Wilhelm K escribiÃ³: > What does "cannot find callback signature" mean from #signature:block:? I'm stuck. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] > Sent: Wednesday, February 29, 2012 6:54 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > yeah... sorry about that > is a bug on FFI... I managed to worked around it for HPDF, for a customer's project... but of course is not a good and definitive solution. > > best, > Esteban > > El 29/02/2012, a las 8:37p.m., Schwab,Wilhelm K escribiÃ³: > >> This is gonna take a while... I had structs flying around as void* and was moderately happy. Nonetheless, your suggestion worked, provided I add a lot getHandle asInteger and change the void* to long :( >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] >> Sent: Wednesday, February 29, 2012 6:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> I also found some problems using void* in linux... maybe you want to use long (which has same size)... I "fixed" my problems that way. >> >> yes... maybe we need to look at FFI to see why void* has problems some times, but well, that can help you atm (sorry for not having a better answer) >> >> Esteban >> >> El 29/02/2012, a las 8:11p.m., Igor Stasenko escribiÃ³: >> >>> On 1 March 2012 00:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> Another glitch: is there any problem passing things as void*? I'm getting failure to coerce errors that did not arise before. >>>> >>> No idea. As you may suspect, i stopped using FFI/Alien once i got >>> NativeBoost toy to play with. >>> >>> Please file the issue, describing the problem. so we can look over it >>> and fix it. >>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] >>>> Sent: Wednesday, February 29, 2012 5:51 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >>>> >>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>> Does 1.3 by default not create field accessors? Why is that? I thought >>>>> nothing was happening. >>>>> >>>> >>>> Good question, i'd like to know the answer too. >>>> It is related to MC final 'installation' phase, >>>> where it initializing all classes. >>>> >>>> In NativeBoost i was also using >>>> >>>> noteCompilationOf: aSelector meta: isMeta >>>> "A hook allowing some classes to react to recompilation of certain selectors" >>>> >>>> but there was a big question, at which point this hook is triggered, >>>> and looks like some changes in MC stop triggering it/triggering at >>>> wrong time (not all methods get into a class/ class not initialized >>>> etc), >>>> which makes it not very useful. >>>> >>>> So i ended up creating a DNU handler on instance side, then on DNU i >>>> check if i have field accessors and if not, >>>> compile them on the fly. >>>> >>>> >>>>> Bill >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> > > >

March 1, 2012

Re: [Pharo-project] leaking semaphores

by Igor Stasenko

On 1 March 2012 18:20, Milan Mimica <milan.mimica(a)gmail.com> wrote: > On 1 March 2012 02:11, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> >> Modify RFBSocket class >> #acceptFrom: to read: >> ^RFBSocketInstances add: (super acceptFrom: aSocket) > > > Congratulations! You have just turned Pharo from so-so to awesome. > With one line of code? No, you must be joking! :) -- Best regards, Igor Stasenko.

March 1, 2012