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-boun...@lists.gforge.inria.fr > [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Esteban Lorenzano > [esteba...@gmail.com] > Sent: Wednesday, February 29, 2012 6:23 PM > To: 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 <bsch...@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-boun...@lists.gforge.inria.fr >>> [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko >>> [siguc...@gmail.com] >>> Sent: Wednesday, February 29, 2012 5:51 PM >>> To: 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 <bsch...@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. >> > > >
