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

Re: [Pharo-project] FFI on 1.3: compile fields

by Esteban Lorenzano

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. >> > > >

Feb. 29, 2012

Re: [Pharo-project] [squeak-dev] can this be done via modification to the Squeak/Pharo IDE?

by Benjamin

Thanks guys :) Nautilus is an example of "just do something". With Stef and co, we got some ideas, some stuff that we want to experiment and then we tried. If you look, nothing is complicated or complex in Nautilus, but we got few good ideas from the beginning, goals to reach and good feedback to help keeping the motivation :) And even if I swore a few times, I learned a lot and I am really glad (and a bit proud) to see so many peoples enjoying Nautilus right now :) I hope I will have the time to keep this inertia and keep Nautilus always moving forward :) Thank you, Ben On Mar 1, 2012, at 12:27 AM, Igor Stasenko wrote: > On 1 March 2012 01:10, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 01 Mar 2012, at 00:02, Igor Stasenko wrote: >> >>> Nautilus is a good example of what can be done in pharo, starting with >>> a little knowledge, a little love and seeing clear goal ahead. >> >> Indeed, but I would give Ben en co more credit than that, they did a great job ! >> > > No doubt this is an achivement. > I was a witness of the creation process, hearing beeps and swearing, > but not seeing what happens, > because we sitting faced to each other :) > >>> Instead of endless discussions on mailing list "can this be done" :) >> >> +10 >> >> Sven > > > > -- > Best regards, > Igor Stasenko. >

Feb. 29, 2012

Re: [Pharo-project] FFI on 1.3: compile fields

by Schwab,Wilhelm K

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. >

Feb. 29, 2012

Re: [Pharo-project] [squeak-dev] can this be done via modification to the Squeak/Pharo IDE?

by Igor Stasenko

On 1 March 2012 01:10, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 01 Mar 2012, at 00:02, Igor Stasenko wrote: > >> Nautilus is a good example of what can be done in pharo, starting with >> a little knowledge, a little love and seeing clear goal ahead. > > Indeed, but I would give Ben en co more credit than that, they did a great job ! > No doubt this is an achivement. I was a witness of the creation process, hearing beeps and swearing, but not seeing what happens, because we sitting faced to each other :) >> Instead of endless discussions on mailing list "can this be done" :) > > +10 > > Sven -- Best regards, Igor Stasenko.

Feb. 29, 2012

Re: [Pharo-project] FFI on 1.3: compile fields

by Esteban Lorenzano

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. >

Feb. 29, 2012

Re: [Pharo-project] does anybody use for business the Native Mac menus?

by Igor Stasenko

yes, we found that many things in implementation is hardwiring between different things. So even if it will stay, we need cleanup/refactoring. Absolutely it cannot stay in its current form. On 1 March 2012 01:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I think we need to support it for all platforms or for none... so... > > Â +1 to drop them :) > > (mars work will solve this, imho in a less "hacky" way... but of course, mars is taking some time :P) > > best, > Esteban > > El 29/02/2012, a las 6:21p.m., StÃ©phane Ducasse escribiÃ³: > >> Hi guys >> >> we are thinking that we want to (rewrite) remove the support for native mac menus because >> it goes against the flow of things and the cleanup of the events we are doing. >> So before removing them we would like to assess if we should really support that or not now. >> >> Stef > > -- Best regards, Igor Stasenko.

Feb. 29, 2012

Re: [Pharo-project] FFI on 1.3: compile fields

by Igor Stasenko

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.

Feb. 29, 2012

Re: [Pharo-project] [squeak-dev] can this be done via modification to the Squeak/Pharo IDE?

by Sven Van Caekenberghe

On 01 Mar 2012, at 00:02, Igor Stasenko wrote: > Nautilus is a good example of what can be done in pharo, starting with > a little knowledge, a little love and seeing clear goal ahead. Indeed, but I would give Ben en co more credit than that, they did a great job ! > Instead of endless discussions on mailing list "can this be done" :) +10 Sven

Feb. 29, 2012

Re: [Pharo-project] does anybody use for business the Native Mac menus?

by Esteban Lorenzano

I think we need to support it for all platforms or for none... so... +1 to drop them :) (mars work will solve this, imho in a less "hacky" way... but of course, mars is taking some time :P) best, Esteban El 29/02/2012, a las 6:21p.m., StÃ©phane Ducasse escribiÃ³: > Hi guys > > we are thinking that we want to (rewrite) remove the support for native mac menus because > it goes against the flow of things and the cleanup of the events we are doing. > So before removing them we would like to assess if we should really support that or not now. > > Stef

Feb. 29, 2012

Re: [Pharo-project] [squeak-dev] can this be done via modification to the Squeak/Pharo IDE?

by Igor Stasenko

Nautilus is a good example of what can be done in pharo, starting with a little knowledge, a little love and seeing clear goal ahead. Instead of endless discussions on mailing list "can this be done" :) On 29 February 2012 23:42, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Here is the video of Nautilus I made for ESUG [1] > > You can see groups in the video. > > But this video is a bit old, and Nautilus changed a lot in the mid time :) > So soon I will do another video (but tonight I am too tired ^^) > > > Ben > > [1] http://dl.dropbox.com/u/24369478/ESUG-Nautilus-Award.m4v > > On Feb 29, 2012, at 7:53 PM, StÃ©phane Ducasse wrote: > >> >> On Feb 29, 2012, at 7:02 PM, Nick Ager wrote: >> >>> Hi Chris, >>> >>> >>> His comment on modality really emphasizes this point, and something I >>> think folks even in this community could stand to listen: Â when I >>> observe folks in their demo videos using Squeak or Pharo, almost every >>> time I see folks browsing in a modal way. Â They have a big >>> Package-Pane browser open and they're looking at one package, one >>> class and one method at a time... Â They have to do about 4-5 clicks to >>> "navigate" to a sent method, and 4-5 clicks to get back. Â This is way >>> too slow for ideas to emerge. >>> >>> I'd love to learn how to be more effective in the Pharo image. >> >> use nautilus and groups! >> They are cool. >> >>> Be great if you could share with us Â more effective ways to navigate around the code >>> .... even in a video :-) >>> >>> Nick >> >> > > -- Best regards, Igor Stasenko.

Feb. 29, 2012