Hi, It is published on http://ss3.gemstone.com/ss/Mars, package Mars-Cocoa. You can also see the Alien ObjectiveC-Bridge as an example, on http://squeaksource.com/Alien, packages Alien-MaxOSX-* (those are hard to follow, but they work :)
but... my names are more or less equal to yours (I just followed Eliot "de facto" convention) best, Esteban El 01/03/2012, a las 4:23p.m., Schwab,Wilhelm K escribió: > Esteban, > > Would you be willing to post your subclass? It might be useful both in > defining signatures and in naming them. > > Bill > > > > ________________________________________ > From: [email protected] > [[email protected]] on behalf of Esteban Lorenzano > [[email protected]] > Sent: Thursday, March 01, 2012 2:08 PM > To: [email protected] > Subject: Re: [Pharo-project] Alien signature: first attempt > > 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. >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > >
