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

Re: [Pharo-project] Monticello Version Info

by Dale Henrichs

For the majority of use cases I think that the immediate ancestor is the only one needed ... so you might be onto something here... Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> | Sent: Thursday, March 1, 2012 1:53:48 PM | Subject: [Pharo-project] Monticello Version Info | | I am still having a look at the Monticello implementation. | Now coming from the git world, this seems very weird: | | Why does each Monticello version store the complete ancestor history? | | ------------------------------------------------------------------------ | | Wouldn't it simply be enough to keep pointers to the immediate | ancestors, and then lazily load and cache them? | | Where is the complete ancestry needed, besides diffing/merging? | | ------------------------------------------------------------------------ | | The current setup implies that something like | | MCCacheRepository default loadVersionFromFileNamed: | 'SLICE-Issue-5416--Improve-MC-version-loading-CamilloBruni.1.mcz' | | takes around 1.5 seconds to complete, whereas this could be done in a | fragment of a second for most cases... |

March 1, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by Benjamin

I do not think so, since I fixed a lot the system itself :S Sorry. (Maybe it's a good excuse to try Pharo 1.4 ^^ ) Ben On Mar 1, 2012, at 10:44 PM, patmaddox wrote: > Does this load on Pharo 1.3? I tried loading it but it barfed on something > like "Browser does not understand addGroup.." (don't entirely remember the > error message). > > -- > View this message in context: http://forum.world.st/Nautilus-version-4-0-4-tp4422530p4436518.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 1, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by Marcus Denker

On Mar 1, 2012, at 10:45 PM, patmaddox wrote: > Does this load on Pharo 1.3? I tried loading it but it barfed on something > like "Browser does not understand addGroup.." (don't entirely remember the > error message). No, we are at the same time improving the base system. e.g. - MC now emits announcements that Nautilus can react on. - Widgets are improved. Example: Multi-selection, lots more - Specs, declaratively define UIs. - RPackage: Merge SystemCategories with PackageInfo, for real. - Ring. This replaces MethodReferences and provides a meta-model for code. I think in the end it's a question of philsophy. Some people say that a project like Nautilus should run on 1.3 and 1.4 (and possibly Squeak and even VW and VA), and never ever improve anything in the systems We disagree ;-) Marcus -- Marcus Denker -- http://marcusdenker.de

March 1, 2012

[Pharo-project] Monticello Version Info

by Camillo Bruni

I am still having a look at the Monticello implementation. Now coming from the git world, this seems very weird: Why does each Monticello version store the complete ancestor history? ------------------------------------------------------------------------ Wouldn't it simply be enough to keep pointers to the immediate ancestors, and then lazily load and cache them? Where is the complete ancestry needed, besides diffing/merging? ------------------------------------------------------------------------ The current setup implies that something like MCCacheRepository default loadVersionFromFileNamed: 'SLICE-Issue-5416--Improve-MC-version-loading-CamilloBruni.1.mcz' takes around 1.5 seconds to complete, whereas this could be done in a fragment of a second for most cases...

March 1, 2012

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

by Schwab,Wilhelm K

Eliot, That helps a bit; it's still unfamiliar territory. I am a little bothered by #wordResult: and #floatResult. There are times when one is expected to return 16 bit values (rare) and either a float or a double (common). Does that flexibility exist? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Thursday, March 01, 2012 3:26 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Alien signature: first attempt On Thu, Mar 1, 2012 at 10:57 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Esteban, Will this work? Even if so, is there a better way to define it? No it won't work, because you don't understand what it does. 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) ) The above takes only one parameter's value from the spAlien (the void * value) and passes garbage for the other parameters. The spAlien is a pointer to the incoming C callback stack frame, i.e. a pointer to the callback's parameters. So spAlien unsignedLongAt: 5 gets the four-byte pointer for the void * parameter, wraps it up in a convenient pointer Alien (so the callback block can e.g. indirect through it to get at the data the pointer is pointing to), and passes it as the second argument of the callback block. But the two Alien newC: 4's are entirely bogus, passing effectively uninitialized data for the first and third parameters of the callback block. They're just empty Aliens, when in fact you want to pass two longs to the block for the first and third parameters. So to pass values in you need something like: longVoidStarLongRetInt: callbackContext sp: spAlien <signature: 'int (*) (long, void *, long)' abi: 'IA32'> ^callbackContext wordResult: (block value: (spAlien signedLongAt: 1) value: (Alien forPointer: (spAlien unsignedLongAt: 5)) value: (spAlien signedLongAt: 9) ) You might also need to consider passing the result of the block back out. If you only want to use it to answer integers then the above is fine. But take a look at the intcharstarRetint:sp: signature: intcharstarRetint: callbackContext sp: spAlien <signature: 'int (*)(int, char *)' abi: 'IA32'> ^callbackContext wordResult: ((block value: (spAlien signedLongAt: 1) ~= 0 value: (Alien forPointer: (spAlien unsignedLongAt: 5)) strcpyUTF8) ifNil: [0] ifNotNil: [:result| result isInteger ifTrue: [result] ifFalse: [result == true ifTrue: [1] ifFalse: [0]]]) Analogously it passes a signed integer as the first argument and a UTF8 string derived from the second char * parameter. (The method should probably be called intcharstarasUTF8Retint:sp: or some such; forgive me, we're getting there). But on return it takes the result of the callback block and passes it to the ifNil:ifNotNil: which - maps a nil result form the block to 0 (ifNil: [0]) - maps integers to integers (which will only deal correctly with integers in the 32-bit range), and - maps true to 1, mapping all other results to 0. Does what's going on now make more sense? HTH, Eliot Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>] Sent: Thursday, March 01, 2012 12:15 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] FFI on 1.3: compile fields thanks!!!!! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] Sent: Wednesday, February 29, 2012 10:18 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] > Sent: Wednesday, February 29, 2012 6:54 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] >> Sent: Wednesday, February 29, 2012 6:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:bschwab@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<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>> Sent: Wednesday, February 29, 2012 5:51 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:bschwab@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. >>> >> >> >> > > > -- best, Eliot

March 1, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by patmaddox

Does this load on Pharo 1.3? I tried loading it but it barfed on something like "Browser does not understand addGroup.." (don't entirely remember the error message). -- View this message in context: http://forum.world.st/Nautilus-version-4-0-4-tp4422530p4436518.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 1, 2012

[Pharo-project] issue 5425 Re: Small usability glitch

by Sebastian Sastre

done: http://code.google.com/p/pharo/issues/detail?id=5425 thanks for the patch Camillo, it hurts every time :) On Mar 1, 2012, at 6:20 PM, Camillo Bruni wrote: > true :) > > found the bug, patch on the way. > > can you open a bug report? > > best > cami > > On 2012-03-01, at 21:50, Sebastian Sastre wrote: > >> just for reference, it doesn't in today's one >> >> Pharo1.4a >> Latest update: #14369 >> >> sebastian >> >> o/ >> >> >> On Mar 1, 2012, at 4:32 PM, Benjamin wrote: >> >>> 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/ >>>> >>>> >>>> >>>> >>> >> >> >> > > sebastian o/

March 1, 2012

Re: [Pharo-project] Small usability glitch

by StÃ©phane Ducasse

thanks! On Mar 1, 2012, at 10:20 PM, Camillo Bruni wrote: > true :) > > found the bug, patch on the way. > > can you open a bug report? > > best > cami > > On 2012-03-01, at 21:50, Sebastian Sastre wrote: > >> just for reference, it doesn't in today's one >> >> Pharo1.4a >> Latest update: #14369 >> >> sebastian >> >> o/ >> >> >> On Mar 1, 2012, at 4:32 PM, Benjamin wrote: >> >>> 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

true :) found the bug, patch on the way. can you open a bug report? best cami On 2012-03-01, at 21:50, Sebastian Sastre wrote: > just for reference, it doesn't in today's one > > Pharo1.4a > Latest update: #14369 > > sebastian > > o/ > > > On Mar 1, 2012, at 4:32 PM, Benjamin wrote: > >> 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] Alien signature: first attempt

by Nicolas Cellier

Le 1 mars 2012 21:30, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> 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. > > > No it won't work. Â See my message. > >> >> 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) > > > Yes, the idea is to have a library of signature methods that marshal > specific C callback signatures to/from Smalltalk blocks. Â The pragma > specifies what ABI (application binary interface, or stack layout) the > signature is for so that the scheme is cross-platform. Â But I expect that > these signature methods could be the output of an ABI compiler, so that one > wouldn't have to write them by hand. Â The pragma doesn't need to include a > word-size since IA64 is a different ABI to IA32, and so the ABI subsumes > word size. > > HTH > Let me understand... If I have a signature (char x,double y, short z) IA-32, where is the spalien pointing to? - the original call stack (with proper ABI alignment, that is offsets 0,4,12, or 1-based indices 1,5,13) - a serialized copy without alignment padding (offsets 0,1,9, or 1-based indices 1,2,10) In the former case, that means that the indices must be computed according to ABI (might be different in PPC for example). And even if such code is generated with an ABI-aware interface compiler, is it really platform independent? I'm quite sure the ABI have subtle variations, which are not even platform but compiler specific... For example of such niceties in win32, did you ever try returning a structure by value from a cdecl mingw-gcc compiled function to a cdecl visual studio compiled caller, not even speaking of different internal structure alignment padding (controlled with #pragma packed(4) or other compiler options...) This apple page helps a lot, for example it tells how gcc returns a structure by value... https://developer.apple.com/library/mac/#documentation/developertools/Conce… Nicolas >> >> >> 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. >> >>>> >> >>> >> >>> >> >>> >> >> >> >> >> >> >> > >> > >> > >> > >> >> > > > > -- > best, > Eliot >

March 1, 2012