[Pharo-project] Alien signature: first attempt

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 1 15:26:07 EST 2012


On Thu, Mar 1, 2012 at 10:57 AM, Schwab,Wilhelm K <bschwab at anest.ufl.edu>wrote:

> Esteban,
>
> Will this work?  Even if so, is there a better way to define it?
>

No it won't work, because you don't understand what it does.


>
> 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)
>                )
>

The above takes only one parameter's value from the spAlien (the void *
value) and passes garbage for the other parameters. The spAlien is a
pointer to the incoming C callback stack frame, i.e. a pointer to the
callback's parameters.  So spAlien unsignedLongAt: 5 gets the four-byte
pointer for the void * parameter, wraps it up in a convenient pointer Alien
(so the callback block can e.g. indirect through it to get at the data the
pointer is pointing to), and passes it as the second argument of the
callback block.  But the two Alien newC: 4's are entirely bogus, passing
effectively uninitialized data for the first and third parameters of the
callback block.  They're just empty Aliens, when in fact you want to pass
two longs to the block for the first and third parameters.

So to pass values in you need something like:

longVoidStarLongRetInt: callbackContext sp: spAlien
       <signature: 'int (*) (long, void *, long)' abi: 'IA32'>
       ^callbackContext wordResult:
               (block
                       value: (spAlien signedLongAt: 1)
                       value: (Alien forPointer: (spAlien unsignedLongAt:
5))
                       value: (spAlien signedLongAt: 9)
               )

You might also need to consider passing the result of the block back out.
 If you only want to use it to answer integers then the above is fine.  But
take a look at the intcharstarRetint:sp: signature:

intcharstarRetint: callbackContext sp: spAlien
<signature: 'int (*)(int, char *)' abi: 'IA32'>
^callbackContext wordResult:
((block
value: (spAlien signedLongAt: 1) ~= 0
value: (Alien forPointer: (spAlien unsignedLongAt: 5)) strcpyUTF8)
ifNil: [0]
ifNotNil:
[:result|
result isInteger
ifTrue: [result]
ifFalse: [result == true ifTrue: [1] ifFalse: [0]]])

Analogously it passes a signed integer as the first argument and a UTF8
string derived from the second char * parameter. (The method should
probably be called intcharstarasUTF8Retint:sp: or some such; forgive me,
we're getting there).

But on return it takes the result of the callback block and passes it to
the ifNil:ifNotNil: which
- maps a nil result form the block to 0 (ifNil: [0])
- maps integers to integers (which will only deal correctly with integers
in the 32-bit range), and
- maps true to 1, mapping all other results to 0.

Does what's going on now make more sense?

HTH,
Eliot


> 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/d5737a95/attachment-0001.html>


More information about the Pharo-dev mailing list