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. 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)
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: [email protected] > [[email protected]] on behalf of Schwab,Wilhelm K > [[email protected]] > Sent: Thursday, March 01, 2012 12:15 AM > To: [email protected] > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > thanks!!!!! > > > > > ________________________________________ > From: [email protected] > [[email protected]] on behalf of Esteban Lorenzano > [[email protected]] > Sent: Wednesday, February 29, 2012 10:18 PM > To: [email protected] > 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: [email protected] >> [[email protected]] on behalf of Esteban Lorenzano >> [[email protected]] >> Sent: Wednesday, February 29, 2012 6:54 PM >> To: [email protected] >> 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: [email protected] >>> [[email protected]] on behalf of Esteban >>> Lorenzano [[email protected]] >>> Sent: Wednesday, February 29, 2012 6:23 PM >>> To: [email protected] >>> 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 <[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. >>>> >>> >>> >>> >> >> >> > > > >
