On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <esteba...@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 > > 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-boun...@lists.gforge.inria.fr [ > pharo-project-boun...@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm > K [bsch...@anest.ufl.edu] > > Sent: Thursday, March 01, 2012 12:15 AM > > To: Pharo-project@lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > > > thanks!!!!! > > > > > > > > > > ________________________________________ > > 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 10:18 PM > > To: 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-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:54 PM > >> To: 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-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. > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > > > -- best, Eliot
