March 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] CRC in System-Hashing?

by Max Leske

I need to calculate CRC for Git and couldn't find it in the system packages (I guess I'd find it in Cryptography). Since Pharo has a system package called "System-Hashing" I was wondering if anyone sees a reason why CRC should not be part of that package. That would also allow the Zip implementation to use the system CRC function (at the moment Zip implements its own CRC check). Another thing: going through Sytem-Hashing I noticed that there are two implementations for SHA1: "SHA1" and "SecureHashAlgorithm". They both have the exact same class comment but vary slightly in the messages they implement (although most of them are present in both classes). Can we remove one? Cheers, Max

March 2, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by Tudor Girba

Hi, On 2 Mar 2012, at 01:42, Benjamin wrote: > I made some improvements in it, and I will use it :) > > But here, the Growl morph is really text oriented when in my version, you can add whatever you want :) > > Maybe I will do a refactor in Growl to have this abstraction I don't know :) Please :). It would be nice to have one strong mechanism for providing notifications. Cheers, Doru > But for sure, you did a cool job with Doru, and I will use it n Nautilus :) > > > Ben > > On Mar 1, 2012, at 10:07 PM, StÃ©phane Ducasse wrote: > >> MCHttpRepository >> location: 'http://www.squeaksource.com/Growl' >> user: '' >> password: '' >> >> Feel free to improve it :) >> We should include it by default in the system. >> >> Stef >> >>>>>> I am working on self destructive balloon morphs for such events. >>>>>> Because you want a popup to get the info, but you do not want this popup to interrupt you :) >>>>>> Something like Growl seems to work well ;) >>>>>> (the same when no senders are found etc) >>>>> >>>>> I did that yesterday: >>>>> >>>>> http://dl.dropbox.com/u/24369478/VanishingMorph.mov >>>>> >>>>> (you can specify the position, the width the height, the margin, and it automatically split the text if it's too long ^^ ) >>>> >>>> Cool! >>>> Just a question the growlMorph was not good enough? >>> >>> What is this ? Where can I find it ? >>> >>> >>> Ben >>> >>>> >>>> Stef >>>> >>>> >>> >>> >> >> > > -- www.tudorgirba.com "To utilize feedback, you first have to acquire it."

March 2, 2012

[Pharo-project] odd bug in Squeak 4.3, also in Pharo 1.3?...

by Lawson English

I was creating a new video tutorial to show how to find all comments in all classes but I'm getting errors in both Squeak 4.3 and Pharo 1.3. In Squeak 4.3, the error is: Key not found: Comment In Pharo 1.3, the error is: Improper store into indexable object. the code is: myNav := SystemNavigation default. (myNav allMethodsWithSourceString: '"' matchCase: false) do: [:each| Transcript show: each asString, ' => ', ( each actualClass commentsIn: each sourceString);cr ] In Pharo, the error shows up after the Transcript output: UndefinedObject>>DoIt (myNav is Undeclared) In Squeak the error shows up each time after the Transcript output: [...] AbstractSound class updateScorePlayers => an OrderedCollection('Force all ScorePlayers to update their instrument list from the sound library. This may done after loading, unloading, or replacing a sound to make all ScorePlayers feel the change.') UndefinedObject>>DoIt (myNav is Undeclared) UndefinedObject>>DoIt (myNav is Undeclared) Help? Error shows up in Squeak 4.3 image running both in the all-in-one distribution, and running on Cog VM. In Pharo 1.3 using Cog VM. Mac OS X 10.6.8. Thanks, Lawson

March 2, 2012

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

by Schwab,Wilhelm K

Eliot, Thanks for the help. I'm not as convinced as you that I have it<g>, but I'm getting there. Alien subclasses per struct - interesting! Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Thursday, March 01, 2012 9:56 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Alien signature: first attempt On Thu, Mar 1, 2012 at 6:45 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, I've unearthed some code from Dolphin, and might want to use something like this: vectorStarVoidStarMatrixStarRetInt: callbackContext sp: spAlien <signature: 'int (*) (Gsl_vector *, void *, Gsl_matrix *)' abi: 'IA32'> ^callbackContext wordResult:( block value: (Alien forPointer:( spAlien unsignedLongAt: 1)) value: (Alien forPointer: (spAlien unsignedLongAt: 5)) value: (Alien forPointer:( spAlien unsignedLongAt: 9)) ). Am I at all on the right track? The vector and matrix are structs. Yes, exactly. The next level is to create Alien subclasses for Gsl_vector and Gsl_matrix and use these in place of the simple Aliens. These e.g. GslMatrixIA32Alien and GslVectorIA32Alien classes would define higher-level accessors so that your callback can access their members by name, not by offset. Of course these classes should be auto-generated by parsing e.g. a C header file using the rules of the platform's ABI. You've got it. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] Sent: Thursday, March 01, 2012 5:38 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Alien signature: first attempt On Thu, Mar 1, 2012 at 1:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, That helps a bit; it's still unfamiliar territory. I am a little bothered by #wordResult: and #floatResult. There are times when one is expected to return 16 bit values (rare) and either a float or a double (common). Does that flexibility exist? Yes, the flexibility exists. But the mechanism needed to provide the flexibility is less than one might expect. For example, on x86 there are three fundamental return conventions, one for integral values, one for floating-point values, and one for structure values. See e.g. chapter 3 of the Sys V ABI for 386 (in my reply to Nicolas). Read it; it's good for the soul; makes one value Smalltalk's simplicity. Integral values are returned in %eax, %edx. edx is not used if the value fits in 32-bits. So the same sequence can be used to answer all integral values from 1 byte to 8 bytes, irrespective of sign. That said, I use two sequences, one for 32-bits or less and one for 33 to 64 bits. In your example of answering 16 bits one simply answers either the sign-extension of 16-bits (if signed) to 32-bits or the zero-extension of 16-bits to 32-bits (if unsigned). In any case, the result is answered in %eax, and it is up to the caller to access the result correctly. Float values are returned on the top of the floating point register stack (%st(0)). The same machine-code sequence can be used to answer single, double and extended precision floats, since on the fp stack, they are all represented in the same extended format. So on x86 the callback implementation supports 4 return mechanisms, retword, retword64, retdouble and retstruct. So far only two of these are fleshed out in Smalltalk code. But look at http://www.squeakvm.org/svn/squeak/branches/Cog/src/vm/vmCallback.h & http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/IA32ABI/ia32ab… and you'll see the other two. cheers, Eliot Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] Sent: Thursday, March 01, 2012 3:26 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Alien signature: first attempt On Thu, Mar 1, 2012 at 10:57 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@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<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>] Sent: Thursday, March 01, 2012 12:15 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] FFI on 1.3: compile fields thanks!!!!! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] Sent: Wednesday, February 29, 2012 10:18 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto: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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] > Sent: Wednesday, February 29, 2012 6:54 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto: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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] >> Sent: Wednesday, February 29, 2012 6:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr<mailto: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(a)anest.ufl.edu<mailto: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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>> Sent: Wednesday, February 29, 2012 5:51 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto: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(a)anest.ufl.edu<mailto: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. >>> >> >> >> > > > -- best, Eliot -- best, Eliot -- best, Eliot

March 2, 2012

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

by Eliot Miranda

On Thu, Mar 1, 2012 at 6:45 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Eliot, > > I've unearthed some code from Dolphin, and might want to use something > like this: > > vectorStarVoidStarMatrixStarRetInt: callbackContext sp: spAlien > <signature: 'int (*) (Gsl_vector *, void *, Gsl_matrix *)' abi: > 'IA32'> > ^callbackContext wordResult:( > block > value: (Alien forPointer:( spAlien unsignedLongAt: 1)) > value: (Alien forPointer: (spAlien unsignedLongAt: 5)) > value: (Alien forPointer:( spAlien unsignedLongAt: 9)) > ). > > Am I at all on the right track? The vector and matrix are structs. > Yes, exactly. The next level is to create Alien subclasses for Gsl_vector and Gsl_matrix and use these in place of the simple Aliens. These e.g. GslMatrixIA32Alien and GslVectorIA32Alien classes would define higher-level accessors so that your callback can access their members by name, not by offset. Of course these classes should be auto-generated by parsing e.g. a C header file using the rules of the platform's ABI. You've got it. > Bill > > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [ > eliot.miranda(a)gmail.com] > *Sent:* Thursday, March 01, 2012 5:38 PM > > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Alien signature: first attempt > > > > On Thu, Mar 1, 2012 at 1:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> Eliot, >> >> That helps a bit; it's still unfamiliar territory. I am a little >> bothered by #wordResult: and #floatResult. There are times when one is >> expected to return 16 bit values (rare) and either a float or a double >> (common). Does that flexibility exist? >> > > Yes, the flexibility exists. But the mechanism needed to provide the > flexibility is less than one might expect. For example, on x86 there are > three fundamental return conventions, one for integral values, one for > floating-point values, and one for structure values. See e.g. chapter 3 of > the Sys V ABI for 386 (in my reply to Nicolas). Read it; it's good for the > soul; makes one value Smalltalk's simplicity. > > Integral values are returned in %eax, %edx. edx is not used if the > value fits in 32-bits. So the same sequence can be used to answer all > integral values from 1 byte to 8 bytes, irrespective of sign. That said, I > use two sequences, one for 32-bits or less and one for 33 to 64 bits. In > your example of answering 16 bits one simply answers either the > sign-extension of 16-bits (if signed) to 32-bits or the zero-extension of > 16-bits to 32-bits (if unsigned). In any case, the result is answered in > %eax, and it is up to the caller to access the result correctly. > > Float values are returned on the top of the floating point register > stack (%st(0)). The same machine-code sequence can be used to answer > single, double and extended precision floats, since on the fp stack, they > are all represented in the same extended format. > > So on x86 the callback implementation supports 4 return mechanisms, > retword, retword64, retdouble and retstruct. So far only two of these are > fleshed out in Smalltalk code. But look at > http://www.squeakvm.org/svn/squeak/branches/Cog/src/vm/vmCallback.h & > http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/IA32ABI/ia32ab… you'll see the other two. > > cheers, > Eliot > > >> >> Bill >> >> >> >> >> ------------------------------ >> *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [ >> eliot.miranda(a)gmail.com] >> *Sent:* Thursday, March 01, 2012 3:26 PM >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Subject:* Re: [Pharo-project] Alien signature: first attempt >> >> >> >> 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 >> >> > > > -- > best, > Eliot > > -- best, Eliot

March 2, 2012

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

by Schwab,Wilhelm K

Eliot, I've unearthed some code from Dolphin, and might want to use something like this: vectorStarVoidStarMatrixStarRetInt: callbackContext sp: spAlien <signature: 'int (*) (Gsl_vector *, void *, Gsl_matrix *)' abi: 'IA32'> ^callbackContext wordResult:( block value: (Alien forPointer:( spAlien unsignedLongAt: 1)) value: (Alien forPointer: (spAlien unsignedLongAt: 5)) value: (Alien forPointer:( spAlien unsignedLongAt: 9)) ). Am I at all on the right track? The vector and matrix are structs. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Thursday, March 01, 2012 5:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Alien signature: first attempt On Thu, Mar 1, 2012 at 1:52 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, That helps a bit; it's still unfamiliar territory. I am a little bothered by #wordResult: and #floatResult. There are times when one is expected to return 16 bit values (rare) and either a float or a double (common). Does that flexibility exist? Yes, the flexibility exists. But the mechanism needed to provide the flexibility is less than one might expect. For example, on x86 there are three fundamental return conventions, one for integral values, one for floating-point values, and one for structure values. See e.g. chapter 3 of the Sys V ABI for 386 (in my reply to Nicolas). Read it; it's good for the soul; makes one value Smalltalk's simplicity. Integral values are returned in %eax, %edx. edx is not used if the value fits in 32-bits. So the same sequence can be used to answer all integral values from 1 byte to 8 bytes, irrespective of sign. That said, I use two sequences, one for 32-bits or less and one for 33 to 64 bits. In your example of answering 16 bits one simply answers either the sign-extension of 16-bits (if signed) to 32-bits or the zero-extension of 16-bits to 32-bits (if unsigned). In any case, the result is answered in %eax, and it is up to the caller to access the result correctly. Float values are returned on the top of the floating point register stack (%st(0)). The same machine-code sequence can be used to answer single, double and extended precision floats, since on the fp stack, they are all represented in the same extended format. So on x86 the callback implementation supports 4 return mechanisms, retword, retword64, retdouble and retstruct. So far only two of these are fleshed out in Smalltalk code. But look at http://www.squeakvm.org/svn/squeak/branches/Cog/src/vm/vmCallback.h & http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins/IA32ABI/ia32ab… and you'll see the other two. cheers, Eliot Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] Sent: Thursday, March 01, 2012 3:26 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Alien signature: first attempt On Thu, Mar 1, 2012 at 10:57 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@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<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>] Sent: Thursday, March 01, 2012 12:15 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] FFI on 1.3: compile fields thanks!!!!! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] Sent: Wednesday, February 29, 2012 10:18 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto: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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] > Sent: Wednesday, February 29, 2012 6:54 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto: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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Esteban Lorenzano [estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>] >> Sent: Wednesday, February 29, 2012 6:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr<mailto: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(a)anest.ufl.edu<mailto: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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>> Sent: Wednesday, February 29, 2012 5:51 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto: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(a)anest.ufl.edu<mailto: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. >>> >> >> >> > > > -- best, Eliot -- best, Eliot

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Chris Cunningham

The issue is that Monticello is setup for distributed processing, and allowing for multiple repositories, some of which may not be available to all of the users for a project. For instance, a project might be developed internally (or on the developers hard-drive) until they feel comfortable distributing the code later. So, publicly, you get version 12, 17, 34, and 37. There is no access to the intermediate ones (unless you happen to be the one that created them and didn't release them). The 'whole ancestry' let's you do diffs off of a version derived from 37 against one derived from 34 - the ancestry can determine that version 34 if 'common', and work from there. [Note that just numbers aren't enough - the original developer, say, cbc could have version cbc.34, while you could have, say, CamilloBruni.34, but yours is based off of 17 (since you picked up that verison and started working there). So, merging cbc.37 with CamilloBruni.34 would need to pull down cbc.17 for a good merge to work.] At least, that's my understanding from long ago discussions. -Chris On Thu, Mar 1, 2012 at 2:15 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > well, you usually cache the mcz in your local directory cache (at least that's the default). > and extracting the meta-data out of a local mcz is rather cheap since zip allows you to directly extract certain files. > > maybe we could add another entry to the mcz with just the stripped down version info in it. this way older monticello versions would still be able to load it the slow way, whereas an updated version could benefit from incremental loading? > > > On 2012-03-01, at 23:11, Nicolas Cellier wrote: > >> I think the main reason is that you cannot load just the metadata, but >> the whole mcz when you need to dig into the history... >> That ain't cheap, and that happens when you merge more or less distant branches. >> >> Also, it's not unusual to upload directly version N+5 without the >> whole N+1 to: N+4 ancestry... >> In this case MC can still find a common ancestor.

March 2, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by Benjamin

I made some improvements in it, and I will use it :) But here, the Growl morph is really text oriented when in my version, you can add whatever you want :) Maybe I will do a refactor in Growl to have this abstraction I don't know :) But for sure, you did a cool job with Doru, and I will use it n Nautilus :) Ben On Mar 1, 2012, at 10:07 PM, StÃ©phane Ducasse wrote: > MCHttpRepository > location: 'http://www.squeaksource.com/Growl' > user: '' > password: '' > > Feel free to improve it :) > We should include it by default in the system. > > Stef > >>>>> I am working on self destructive balloon morphs for such events. >>>>> Because you want a popup to get the info, but you do not want this popup to interrupt you :) >>>>> Something like Growl seems to work well ;) >>>>> (the same when no senders are found etc) >>>> >>>> I did that yesterday: >>>> >>>> http://dl.dropbox.com/u/24369478/VanishingMorph.mov >>>> >>>> (you can specify the position, the width the height, the margin, and it automatically split the text if it's too long ^^ ) >>> >>> Cool! >>> Just a question the growlMorph was not good enough? >> >> What is this ? Where can I find it ? >> >> >> Ben >> >>> >>> Stef >>> >>> >> >> > >

March 2, 2012

Re: [Pharo-project] [Bug Tracker] Issues tagged 1.3

by Christoph Wysseier

Dear Marcus, Am 01.03.12 23:35, schrieb Marcus Denker: >> I think this attitude is what will continue to hold Pharo back from wider >> adoption. I've found 1.4 to be unusable for daily development. And yet >> there's no interest in fixing problems in 1.3. > > There is. But we need to be reasonable... we can not back-port everything. > Even fixing bugs changes the system so that it leads to incompatibility and new problems. Personally, I am convinced that the Pharo core team is willing to support users with a stable environment which is in our case also 1.3. But I need to say that Pats statement sound familar to feedback I heard from my dev team too. Reading the comments of some issues and being one month on this list now I suppose the root of the problem to be completely on the layer of communication, nothing else. Actually we all "love smalltalk and pharo and really want to see it win and receive wider adoption" but IMHO this does not work as long as there are mutual recriminations and no appreciation. Let's get back to work together with united forces, with understanding for the counterpart, helpfulness and constructiveness! And fun will return for sure... > We can not backport everything... especially as the amount of people looking > at stuff is very small. yes, we should release more often... > > E.g. since I asked for help on 1.3 issues: > > http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 > > There was *no reaction at all*. Nothing. Zero. > > Sometimes I think we should just stop and do something else. This is clearly not working. I understand your personal feelings very well but don't take it too seriously. You (and all other contributors too) are doing a great job and all of the users appreciate your work very much otherwise nobody would actually use Pharo at all. Keep it going! We (to be more precise: Andrea) tried to deliver input for at #4617 and #5045 and will continue to support you too as much as we can. Just let us now how we can help you with additional input for this issue. We will definitely send you virtual flowers and offer some original Swiss chocolate if you find a way out of this problem... :) Good night! Chris P.S: I don't intend to be instructive and I am aware it to be off-topic... just would like to help in the area where I am clearly better than as a Smalltalk developer.

March 1, 2012

[Pharo-project] Give it five minutes - (37signals)

by Sven Van Caekenberghe

Coming from someone who is often accused of having a big ego: http://37signals.com/svn/posts/3124-give-it-five-minutes Well written. I am equally guilty sometimes. Sven

March 1, 2012