FFI on 1.3: compile fields

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

FFI on 1.3: compile fields

Schwab,Wilhelm K
Does 1.3 by default not create field accessors?  Why is that?  I thought nothing was happening.

Bill






Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

Igor Stasenko
On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

Schwab,Wilhelm K
Another glitch: is there any problem passing things as void*?  I'm getting failure to coerce errors that did not arise before.



________________________________________
From: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
Sent: Wednesday, February 29, 2012 5:51 PM
To: [hidden email]
Subject: Re: [Pharo-project] FFI on 1.3: compile fields

On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

Igor Stasenko
On 1 March 2012 00:58, Schwab,Wilhelm K <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
> Sent: Wednesday, February 29, 2012 5:51 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>
> On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

EstebanLM
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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
>> Sent: Wednesday, February 29, 2012 5:51 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>>
>> On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

Schwab,Wilhelm K
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: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
Sent: Wednesday, February 29, 2012 6:23 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
>> Sent: Wednesday, February 29, 2012 5:51 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>>
>> On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.
>



Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

EstebanLM
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: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
> Sent: Wednesday, February 29, 2012 6:23 PM
> To: [hidden email]
> 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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
>>> Sent: Wednesday, February 29, 2012 5:51 PM
>>> To: [hidden email]
>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>>>
>>> On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

Schwab,Wilhelm K
What does "cannot find callback signature" mean from #signature:block:?  I'm stuck.




________________________________________
From: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
Sent: Wednesday, February 29, 2012 6:54 PM
To: [hidden email]
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: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
> Sent: Wednesday, February 29, 2012 6:23 PM
> To: [hidden email]
> 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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
>>> Sent: Wednesday, February 29, 2012 5:51 PM
>>> To: [hidden email]
>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>>>
>>> On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

EstebanLM
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: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
> Sent: Wednesday, February 29, 2012 6:54 PM
> To: [hidden email]
> 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: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
>> Sent: Wednesday, February 29, 2012 6:23 PM
>> To: [hidden email]
>> 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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
>>>> Sent: Wednesday, February 29, 2012 5:51 PM
>>>> To: [hidden email]
>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>>>>
>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.
>>>
>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: FFI on 1.3: compile fields

Schwab,Wilhelm K
thanks!!!!!




________________________________________
From: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
Sent: Wednesday, February 29, 2012 10:18 PM
To: [hidden email]
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: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
> Sent: Wednesday, February 29, 2012 6:54 PM
> To: [hidden email]
> 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: [hidden email] [[hidden email]] on behalf of Esteban Lorenzano [[hidden email]]
>> Sent: Wednesday, February 29, 2012 6:23 PM
>> To: [hidden email]
>> 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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Igor Stasenko [[hidden email]]
>>>> Sent: Wednesday, February 29, 2012 5:51 PM
>>>> To: [hidden email]
>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields
>>>>
>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <[hidden email]> 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.
>>>
>>
>>
>>
>
>
>