- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.4] #14370

by Marcus Denker

On Mar 1, 2012, at 9:47 PM, StÃ©phane Ducasse wrote: > Thanks! > Finally we got this code inâ¦ > Thanks camillo > Thanks marcus! Sadly not... it turned out the be not loadable with Monticello, so after wasting far too much time we rolled back and we now have a changeset to try... Marcus -- Marcus Denker -- http://marcusdenker.de

March 1, 2012

Re: [Pharo-project] [update 1.4] #14370

by StÃ©phane Ducasse

Thanks! Finally we got this code inâ¦ Thanks camillo Thanks marcus! > 14370 > ----- > > Issue 5290: Cleanup Startup Error Handling > http://code.google.com/p/pharo/issues/detail?id=5290 > > Camillo Bruni. > > - provide a more readable log output on stdout > - properly handle the -interactive -headless switch > - reuse existing code when using scripts (CodeLoader) > - cleanup the logging in SmalltalkImage > - added exit code

March 1, 2012

Re: [Pharo-project] fun with NBOpenGL

by StÃ©phane Ducasse

> What i really like Igor is, i don't need to close the morph for apply my change to the render method, i mean in addition to not recompile the whole project. Yeeesssssssssss! Stef

March 1, 2012

Re: [Pharo-project] fun with NBOpenGL

by StÃ©phane Ducasse

Excellent! Erwan should really look how we could use that to build a back end for Lumiere or Klotz. Alex :) Fernando :) It will be really fun. On Mar 1, 2012, at 1:47 AM, Jean Baptiste Arnaud wrote: > I really like do useless thing ;-p. > > The control > for the cube > x : increase by one the number of cube on the x axis > y : increase by one the number of cube on the y axis > z : increase by one the number of cube on the z axis > X : decrease by one the number of cube on the x axis > Y : decrease by one the number of cube on the y axis > Z : decrease by one the number of cube on the z axis > > left arrow : turn left > right arrow : turn right > up arrow : turn up > down arrow : turn down > > Shift left arrow : translate left > Shift right arrow : translate right > Shift up arrow : translate up > Shift down arrow : translate down > > space move forward. > ctrl space (because dont take shift space as specific keystroke and array dont take ctrl so i choose that): move backward. > > i search during half a hour but dont find a relevant quote from pinky and the brain. sad. > What i really like Igor is, i don't need to close the morph for apply my change to the render method, i mean in addition to not recompile the whole project. > > > <NBOpenGL-JB end i am tired.st> > > > <Screen shot 2012-03-01 at 1.26.09 AM.png> > > On Feb 29, 2012, at 11:38 PM, Igor Stasenko wrote: > >> woow... >> >> it is always fun to see that something which looks like trash (who can >> be impressed by a stupid rotating cube today?) >> can be turned into piece of art with a few keystrokes, just by taking >> right pictures :) >> >> And that's why it is soo fun to work with graphics. >> >> -- >> Best regards, >> Igor Stasenko. >> > > Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > >

March 1, 2012

Re: [Pharo-project] [squeak-dev] can this be done via modification to the Squeak/Pharo IDE?

by StÃ©phane Ducasse

> now after i found time to watch this video, i can comment on it :) > > Strangely enough, but i was driven by the very same idea when i first > found squeak and joined community. > I imagined the scene with animation, like a bullet leaving the gun and > flying towards its victim, and i wanted to give an > artist/designer/engineer to > be able to stop the scene at any moment, interact with objects, like > inspect their properties, allow them to change the code and then > continue again. > > What i seen in those days, that smalltalk is much more enabling > environment for doing that, than anything else! > And i still keep that idea in mind, every time i doing something, be > it VM, FFI or Morphic or OpenGL or bug fixes.. > every single step gets me a bit closer to this.. even if i won't be > able to work on this thing directly, i trying to push things in > direction which would allow > others to get to that point. You are great enabler. COntinue. Of course we want to do too much because this is exciting. So let us check and focus on the fundamentals. April will be a crazy month :) Stef

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Esteban Lorenzano

yeah, I see... I was thinking on method structure (pragma signature, etc.), not the contents evaluated inside... but of course, you are right :) best, Esteban El 01/03/2012, a las 5:30p.m., Eliot Miranda escribiÃ³: > > > On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > > Sent: Thursday, March 01, 2012 12:15 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > > > thanks!!!!! > > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] > > Sent: Wednesday, February 29, 2012 10:18 PM > > To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] > >> Sent: Wednesday, February 29, 2012 6:54 PM > >> To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com] > >>> Sent: Wednesday, February 29, 2012 6:23 PM > >>> To: Pharo-project(a)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(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] > >>>>> Sent: Wednesday, February 29, 2012 5:51 PM > >>>>> To: Pharo-project(a)lists.gforge.inria.fr > >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields > >>>>> > >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)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 >

March 1, 2012

Re: [Pharo-project] does anybody use for business the Native Mac menus?

by StÃ©phane Ducasse

Ok I will add that to my todo Now dead :) Stef On Mar 1, 2012, at 12:13 AM, Igor Stasenko wrote: > yes, we found that many things in implementation is hardwiring between > different things. So even if it will stay, we need cleanup/refactoring. > Absolutely it cannot stay in its current form. > > On 1 March 2012 01:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> I think we need to support it for all platforms or for none... so... >> >> +1 to drop them :) >> >> (mars work will solve this, imho in a less "hacky" way... but of course, mars is taking some time :P) >> >> best, >> Esteban >> >> El 29/02/2012, a las 6:21p.m., StÃ©phane Ducasse escribiÃ³: >> >>> Hi guys >>> >>> we are thinking that we want to (rewrite) remove the support for native mac menus because >>> it goes against the flow of things and the cleanup of the events we are doing. >>> So before removing them we would like to assess if we should really support that or not now. >>> >>> Stef >> >> > > > > -- > Best regards, > Igor Stasenko. >

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Eliot Miranda

On Thu, Mar 1, 2012 at 11:08 AM, Esteban Lorenzano <estebanlm(a)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(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm > K [bschwab(a)anest.ufl.edu] > > Sent: Thursday, March 01, 2012 12:15 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > > > thanks!!!!! > > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano [estebanlm(a)gmail.com] > > Sent: Wednesday, February 29, 2012 10:18 PM > > To: Pharo-project(a)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(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano [estebanlm(a)gmail.com] > >> Sent: Wednesday, February 29, 2012 6:54 PM > >> To: Pharo-project(a)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(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano [estebanlm(a)gmail.com] > >>> Sent: Wednesday, February 29, 2012 6:23 PM > >>> To: Pharo-project(a)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(a)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(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [ > siguctua(a)gmail.com] > >>>>> Sent: Wednesday, February 29, 2012 5:51 PM > >>>>> To: Pharo-project(a)lists.gforge.inria.fr > >>>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields > >>>>> > >>>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)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

March 1, 2012

Re: [Pharo-project] FilePlugin rant

by Marcus Denker

On Mar 1, 2012, at 9:03 PM, Mariano Martinez Peck wrote: > I have also experimented the problem of Monticello being unusable The sentence should stop here... We really need to think hard about Monticello... just look at 1.4 from https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifac… Image size: 17.7MB Hmm... that's large. Pharo is growing out of leaps and bounds! We add crap all the time! No, actually not. 1. Monticello ancestry. MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. doit, save. --> 12.7 MB. So MC wastes 5MB for history. Now history is important. But can we actually use the history? The Changes and Source are together now 53MB... because we need the history. But, isn't that what MC should do? Why can't it do it? Even though it wastes 5MB constantly? Continuing... 2) Scriptloader. Big piece of crap. Delete the class. Save ---> 10.3 MB What it does is to define which exact package versions made up a pharo version. So we know what 14345 was *exactly*. And it records the comment of what changed. Again: Shoudn't a "software versioning and a revision control system" do *exactly* that? No? 3) "ScriptLoader new cleanUpForProduction" does 1 and 2 and removed the tests, does some cleanup --> 8.3 MB And that is with all the fonts! Fully usable. All tools. (but not SUnit). 8.3 MB.... So I really wonder if we don't need to do something different.... Marcus -- Marcus Denker -- http://marcusdenker.de

March 1, 2012

Re: [Pharo-project] Alien signature: first attempt

by Eliot Miranda

On Thu, Mar 1, 2012 at 10:57 AM, Schwab,Wilhelm K <bschwab(a)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(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm > K [bschwab(a)anest.ufl.edu] > Sent: Thursday, March 01, 2012 12:15 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI on 1.3: compile fields > > thanks!!!!! > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano [estebanlm(a)gmail.com] > Sent: Wednesday, February 29, 2012 10:18 PM > To: Pharo-project(a)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(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano [estebanlm(a)gmail.com] > > Sent: Wednesday, February 29, 2012 6:54 PM > > To: Pharo-project(a)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(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Esteban > Lorenzano [estebanlm(a)gmail.com] > >> Sent: Wednesday, February 29, 2012 6:23 PM > >> To: Pharo-project(a)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(a)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(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [ > siguctua(a)gmail.com] > >>>> Sent: Wednesday, February 29, 2012 5:51 PM > >>>> To: Pharo-project(a)lists.gforge.inria.fr > >>>> Subject: Re: [Pharo-project] FFI on 1.3: compile fields > >>>> > >>>> On 1 March 2012 00:37, Schwab,Wilhelm K <bschwab(a)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

March 1, 2012