[Pharo-project] Alien signature: first attempt

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 1 15:30:36 EST 2012


On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm at 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-bounces at lists.gforge.inria.fr [
> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Schwab,Wilhelm
> K [bschwab at anest.ufl.edu]
> > Sent: Thursday, March 01, 2012 12:15 AM
> > To: Pharo-project at lists.gforge.inria.fr
> > Subject: Re: [Pharo-project] FFI on 1.3: compile fields
> >
> > thanks!!!!!
> >
> >
> >
> >
> > ________________________________________
> > From: pharo-project-bounces at lists.gforge.inria.fr [
> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Esteban
> Lorenzano [estebanlm at gmail.com]
> > Sent: Wednesday, February 29, 2012 10:18 PM
> > To: Pharo-project at 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-bounces at lists.gforge.inria.fr [
> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Esteban
> Lorenzano [estebanlm at gmail.com]
> >> Sent: Wednesday, February 29, 2012 6:54 PM
> >> To: Pharo-project at 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-bounces at lists.gforge.inria.fr [
> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Esteban
> Lorenzano [estebanlm at gmail.com]
> >>> Sent: Wednesday, February 29, 2012 6:23 PM
> >>> To: Pharo-project at 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 <bschwab at 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-bounces at lists.gforge.inria.fr [
> pharo-project-bounces at lists.gforge.inria.fr] on behalf of Igor Stasenko [
> siguctua at gmail.com]
> >>>>> Sent: Wednesday, February 29, 2012 5:51 PM
> >>>>> To: Pharo-project at lists.gforge.inria.fr
> >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
> >>>>>
> >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120301/8151df0f/attachment-0001.html>


More information about the Pharo-dev mailing list