Does 1.3 by default not create field accessors? Why is that? I thought nothing was happening.
Bill |
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. |
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. |
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. |
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. > |
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. > |
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. >> > > > |
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. >> > > > |
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. >>> >> >> >> > > > |
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. >>> >> >> >> > > > |
Free forum by Nabble | Edit this page |