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 <[email protected]> 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: [email protected] >> [[email protected]] on behalf of Igor Stasenko >> [[email protected]] >> Sent: Wednesday, February 29, 2012 5:51 PM >> To: [email protected] >> Subject: Re: [Pharo-project] FFI on 1.3: compile fields >> >> On 1 March 2012 00:37, Schwab,Wilhelm K <[email protected]> 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. >
