> 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@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [
bschwab@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-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [
estebanlm@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-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [
estebanlm@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-bounces@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [
estebanlm@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 <
bschwab@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@lists.gforge.inria.fr [
pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [
siguctua@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 <
bschwab@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.
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>