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

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

On Mar 3, 2010, at 4:53 PM, Yanni Chiu wrote: > Isn't readability a matter of taste, or were experiments done? > > IIRC, the arguments for productivity had to do with everyone just > accepting one standard - not that one standard was "better" than > another, just that there be *one* team standard (in the interest of > productivity). > > I prefer the "hanging left bracket" because it allows the subsequent > lines to have the same tabbing. That makes me faster, without requiring > an automatic formatter. Yes this is the tradeoff and since I know that adrian is really productive (manage a company and did his phd and won prices) I took his sentence to the right level. :) And I do not like not self aligned :) but I do not like ifTrue: [ either. So anything people /majoirty prefer is ok for me as soon as I get a nice formatter formatting the core :) Stef

March 3, 2010

Re: [Pharo-project] [update 1.1] #11241

by Adrian Lienhard

ok, I'll wait. Adrian On Mar 3, 2010, at 18:39 , StÃ©phane Ducasse wrote: > there is a problem do not integrate it. > > We cannot have twice the same block arg in a method > > [:each | each ...] > [:each | each ...] > > I will revert the change in 11242 > > Stef > > On Mar 3, 2010, at 3:01 PM, Adrian Lienhard wrote: > >> Yes, I agree. I'll do it this evening. >> >> Adrian >> >> On Mar 3, 2010, at 14:32 , Lukas Renggli wrote: >> >>> Great! >>> >>> Adrian, is it possible to merge Issue 2102 into Pharo 1.0 too? I think >>> it is important to have that fixed there too. >>> >>> Lukas >>> >>> >>> On 3 March 2010 14:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> 11241 >>>> ----- >>>> >>>> - Issue 2102: Fix the fact that local temp can shadow silently instance var >>>> - cleaning findChgSet >>>> - fixing packageInfo typos overriden -> overridden >>>> - Fix file = and added one test >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] Worth reading discussion on Smalltalk vs SmalltalkImage

by StÃ©phane Ducasse

> 1) Rename Browser -> SystemBrowser > 2) Rename SystemNavigation -> Browser > 3) move SystemNavigation methods -> class side Why not Navigator Finder and we do not change all the existing books that always called Browser the tool Finder allCallOn: #new Stef > > Rationale: > 1) that's what is written in window title, isn't it ? > 2) Browser allCallsOn: and Browser browseAllCallsOn: are so neat ! > 3) Is there any value in instance side, or is SystemNavigation just a factory ? > > Browser would not designate the tool, but the friendly compagnon used > to browse and query. > You can easily create a few compatibility hooks to SystemBrowser if required. > > Nicolas > >>> The important thing if this becomes the solution, is deciding what goes >>> where, (in a consistent fashion across forks), >> >> I'm sure that we will be able to have something that is cross fork. I do not have the energy >> to argue. >> >>> as well as the level of >>> backwards-compatibility packages should be offered/deprecation methods >>> kept in the image. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] Fwd: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk

by StÃ©phane Ducasse

Yes I like it even if this looks like more work. After we can write Smalltalk system vmPath Smalltalk namespace allClasses + at: -> forward to namespace before been deprecated > Sorry to open a new thread, but here is my own position. > > Cheers > > Nicolas > > ---------- Forwarded message ---------- > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: 2010/3/3 > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > To: The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > > > 2010/3/3 Andreas Raab <andreas.raab(a)gmx.de>: >> On 3/2/2010 10:14 PM, Michael Haupt wrote: >>> >>> Hi, >>> >>> Am 03.03.2010 um 03:41 schrieb Andreas Raab <andreas.raab(a)gmx.de>: >>>> >>>> Consequently I'm going to completely ignore any forward-looking >>>> proposals and simply state that the current count is 3 votes for the >>>> first variant (Phil, David, Bert) and 1 vote for the second variant >>>> (Igor). >>> >>> here's another for "Smalltalk", then. >> >> That choice doesn't exist :-) You can vote for: >> >> a) Smalltalk class == SystemDictionary, or >> >> b) Smalltalk class == SmalltalkImage >> >> Cheers, >> - Andreas >> >> > > I vote for b). > > After discussing this with Stephane Ducasse, I quite agree on this scheme: > > SmalltalkImage should better be renamed System. > System soleInstance = Smalltalk. > Of course an optional bakward compatibility module would define > SmalltalkImage current > > Smalltalk globals or Smalltalk namespace class = SystemDictionary > Maybe SystemDictionary shouldbetter be renamed Namespace to separate > the notion of System. > > Then, if we are in need of separating methods, create new classes > SmalltalkVM etc... > But don't impose that in Kernel code, use methods indirections > (Smalltalk vm blah...) > > This is a bit harder path than a), but lot cleaner IMO > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] [update 1.1] #11241

by StÃ©phane Ducasse

there is a problem do not integrate it. We cannot have twice the same block arg in a method [:each | each ...] [:each | each ...] I will revert the change in 11242 Stef On Mar 3, 2010, at 3:01 PM, Adrian Lienhard wrote: > Yes, I agree. I'll do it this evening. > > Adrian > > On Mar 3, 2010, at 14:32 , Lukas Renggli wrote: > >> Great! >> >> Adrian, is it possible to merge Issue 2102 into Pharo 1.0 too? I think >> it is important to have that fixed there too. >> >> Lukas >> >> >> On 3 March 2010 14:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> 11241 >>> ----- >>> >>> - Issue 2102: Fix the fact that local temp can shadow silently instance var >>> - cleaning findChgSet >>> - fixing packageInfo typos overriden -> overridden >>> - Fix file = and added one test >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] Trying to build alien plugin in linux

by Javier PimÃ¡s

Exactly, that's what confuses me most! The function doesn't even have locals: EXPORT(LONGLONG) ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2) { return c1+c2+c3+c4+c5+c6+c7+c8+c9+c10+i1 + i2; } I'm quite sure it's substracting because I see the memory contents, and the disassembly is this (notice how it accumulates the result in edx): 0x75d32725 <ffiTestLongLong10a2+308>: movsbl -0x1c(%ebp),%edx 0x75d32729 <ffiTestLongLong10a2+312>: movsbl -0x20(%ebp),%eax 0x75d3272d <ffiTestLongLong10a2+316>: add %eax,%edx 0x75d3272f <ffiTestLongLong10a2+318>: movsbl -0x24(%ebp),%eax 0x75d32733 <ffiTestLongLong10a2+322>: add %eax,%edx 0x75d32735 <ffiTestLongLong10a2+324>: movsbl -0x28(%ebp),%eax 0x75d32739 <ffiTestLongLong10a2+328>: add %eax,%edx 0x75d3273b <ffiTestLongLong10a2+330>: movsbl -0x2c(%ebp),%eax 0x75d3273f <ffiTestLongLong10a2+334>: add %eax,%edx 0x75d32741 <ffiTestLongLong10a2+336>: movsbl -0x30(%ebp),%eax 0x75d32745 <ffiTestLongLong10a2+340>: add %eax,%edx 0x75d32747 <ffiTestLongLong10a2+342>: movsbl -0x34(%ebp),%eax 0x75d3274b <ffiTestLongLong10a2+346>: add %eax,%edx 0x75d3274d <ffiTestLongLong10a2+348>: movsbl -0x38(%ebp),%eax 0x75d32751 <ffiTestLongLong10a2+352>: add %eax,%edx 0x75d32753 <ffiTestLongLong10a2+354>: movsbl -0x3c(%ebp),%eax 0x75d32757 <ffiTestLongLong10a2+358>: add %eax,%edx 0x75d32759 <ffiTestLongLong10a2+360>: movsbl -0x40(%ebp),%eax 0x75d3275d <ffiTestLongLong10a2+364>: lea (%edx,%eax,1),%eax 0x75d32760 <ffiTestLongLong10a2+367>: mov %eax,%edx 0x75d32762 <ffiTestLongLong10a2+369>: sar $0x1f,%edx 0x75d32765 <ffiTestLongLong10a2+372>: add -0x48(%ebp),%eax 0x75d32768 <ffiTestLongLong10a2+375>: adc -0x44(%ebp),%edx 0x75d3276b <ffiTestLongLong10a2+378>: add -0x50(%ebp),%eax 0x75d3276e <ffiTestLongLong10a2+381>: adc -0x4c(%ebp),%edx 0x75d32771 <ffiTestLongLong10a2+384>: add $0xbc,%esp 0x75d32777 <ffiTestLongLong10a2+390>: pop %ebx 0x75d32778 <ffiTestLongLong10a2+391>: pop %esi 0x75d32779 <ffiTestLongLong10a2+392>: pop %edi 0x75d3277a <ffiTestLongLong10a2+393>: pop %ebp 0x75d3277b <ffiTestLongLong10a2+394>: ret This is really weird! Why could gcc compiled it flipped? I'll continue looking. Regards, Javier. 2010/3/3 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/3/3 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > > Ok, this is way nicer. The line that was missing and that seems to solve >> all this is >> >> self initializeSpecialObjectIndices. >> >> which I think should be placed in Alien>>#initialize just before >> >> self ensureInSpecialObjectsArray. >> >> but then I don't know why it should ensure anything that is done just >> before. >> >> With that I it's really close to work. After a few hours I understood the >> way tests are done. In Alien plugin you integrated a couple of exported >> functions (ffiTest*), which you then call in the tests. These funcs do >> simple stuff like adding and returning the result, so you can compare, am I >> right? >> >> Then I realized that (at least in linux) the tests won't work if you >> compile as internal (there won't be a .so, so you won't be able to load the >> C test functions!). >> >> Now with the small fix I added, and compiling as external, I can see that >> it's actually almost almost working, buuuut I get these test results: 36 >> run, 17 passed, 19 failures, 0 errors (had to remove >> testCallingSquenceString because it crashed the VM). Notice that before I >> got 20 errors and 0 failures. This is because the results are wrong. >> >> >> I debugged the code with ddd to see what's happening, and I can see that >> everything is going nice before the actual function call, that is done in >> dabusiness.h. >> >> funcAlien = interpreterProxy->stackValue(funcOffset); >> f = *(void **)startOfParameterData(funcAlien); >> >> #if STACK_ALIGN_BYTES (in my compiled code it is'nt defined, should it?) >> /* cut stack back to start of aligned args */ >> setsp(argstart); >> #endif >> r = f(); >> >> I took as example test #ffiTestLongLong10a2:, which calls >> ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, >> char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2). >> >> dabusiness.h allocated 56 bytes in argvec (10*4 for chars + 2*8 for >> longlong), which then fills correctly (ddd says 1 2 3 4 5 6 7 8 9 10 11 0 12 >> 0). I have to admit that I don't fully understand whats happening with the >> stack then, but ffiTestLongLong10a2 gets its arguments wrong. I'm thinking >> of a calling convention problem. Here it's why: >> >> In some run I have: &argvec[0] is pos 0aa0 (this is actually direction >> inside the stack, near it's top). Just before assembly CALL >> ffiTestLongLong10a2 I have ebp=0b68, and after the call it is pushed and >> replaced with esp, which is 0a88. Then, we have, args at 0aa0, 0aa4, ..., >> and current stack frame starting at 0a88 and going lower, 0a84, etc. That >> may be ok, but when I look into the ffiTestLongLong10a2 assembly it is >> trying to find the arguments by *substracting* to ebp (arg1 in ebp-1c, 2nd >> in ebp-20, ...) when it should adding, looking in greater positions >> (previous stack frame, arg1 is in ebp+18). This has to be some simple >> calling convention stuff, but I don't know how to solve it, any ideas?. >> > > Subtracting from ebp is for accessing locals, adding to ebp for accessing > arguments. Are you sure you're not misinterpreting a local access as an > argument access? > > > >> Thanks for reading, >> Javier. >> >> >> On Mon, Mar 1, 2010 at 9:05 PM, John M McIntosh < >> johnmci(a)smalltalkconsulting.com> wrote: >> >>> It would be missing, propose a change set. >>> >>> I would think people usually don't use VMMaker images as their daily work >>> image. >>> >>> So take image, load vmaker, load vmaker stuff for alien, make alien >>> plugin. >>> >>> got to my work image that doesn't have vmmaker in it, >>> load alien support stuf, you don't need the alien-vmmaker-support btw. >>> run tests. >>> >>> >>> >>> On 2010-03-01, at 3:36 PM, Javier PimÃ¡s wrote: >>> >>> Hi, I'm still trying to advance with this. Don't know what caused the >>> ObjectMemory classPools but it seems to be away now, maybe I did some >>> mistake last time. >>> >>> The thing is that now I have in ObjectMemory classPools all the original >>> ones plus 4 new elements, which I think were added with this >>> Alien-VMMaker-Support override: >>> >>> ObjectMemory>>#initialize >>> initialize >>> #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector >>> #SelectorAttemptToAssign) >>> do: [:c | >>> [ObjectMemory addClassVarName: c] ifError: []]. >>> >>> the thing is that it never assigns them any value, so my theory is that >>> there's some code missing? Then in Interpreter it happens something quite >>> similar. Interpreter>>#initialize does this: >>> >>> ... >>> >>> #(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs >>> #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate >>> #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification >>> #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) >>> do: [:c | >>> [Interpreter addClassVarName: c] ifError: []]. >>> >>> #(#primFailCode) >>> do: [:i | [Interpreter addInstVarName: i] ifError: []]. >>> >>> ... >>> >>> but then never calls initializePrimitiveErrorCodes, which would set the >>> vars to a meaningfull value. >>> >>> >>> In conclusion, the question would be, where is this missing >>> initialization code? >>> >>> Hope you can help, thanks! >>> >>> Javier. >>> >>> On Tue, Feb 23, 2010 at 4:39 PM, Javier PimÃ¡s < >>> elpochodelagente(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < >>>> johnmci(a)smalltalkconsulting.com> wrote: >>>> >>>>> >>>>> On 2010-02-22, at 6:48 PM, Javier PimÃ¡s wrote: >>>>> >>>>> Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the >>>>> results: >>>>> >>>>> 37 run, 17 passed, 0 failures, 20 errors. >>>>> >>>>> TestCallingSequenceChar10Long2 >>>>> TestCallingSequenceChar2LongLong2 >>>>> TestCallingSequenceChar8Long2 >>>>> TestCallingSequenceChar9Long2 >>>>> TestCallingSequenceCharLongLong2 >>>>> TestCallingSequenceChars >>>>> TestCallingSequenceDoubles14 >>>>> TestCallingSequenceDoubles2 >>>>> TestCallingSequenceFloats13 >>>>> TestCallingSequenceFloats14 >>>>> TestCallingSequenceFloats2 >>>>> TestCallingSequenceFloats2WithInteger >>>>> TestCallingSequenceFloats2WithInteger2 >>>>> TestCallingSequenceFloats7 >>>>> TestCallingSequenceInt >>>>> TestCallingSequenceInt8 >>>>> TestCallingSequenceIntWithFloatArgs >>>>> TestCallingSequenceLongLong2 >>>>> TestCallingSequenceShort >>>>> TestCallingSequenceString >>>>> >>>>> >>>>> Oh look SUnits, great stuff (*cough* well I wrote most of them). >>>>> >>>>> >>>> Cool, this is really really useful (although I sometimes find wrting >>>> tests boring ;) ). >>>> >>>>> >>>>> >>>>> It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why >>>>> should it try to load itself, if it's compiled as an internal plugin? I >>>>> compiled it as external too but didn't work either. >>>>> >>>>> >>>>> Well it compiled, but that doesn't mean it works. In fact the error >>>>> means the plugin code is never loaded, or is callable. >>>>> Now one thing to consider is that the plugin load fails, because it >>>>> can't find it. (external usage). >>>>> Or because (internal and external plugin) the VM Version and the >>>>> plugin version don't match. >>>>> >>>>> Look for your definition of >>>>> #define VM_PROXY_MINOR 8 >>>>> >>>>> It should be 8 or higher for compiling BOTH the VM and the Plugin. >>>>> Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is >>>>> mass confusion about which header is being used? >>>>> >>>>> If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't >>>>> work with a plugin compiled with VM_PROXY_MINOR = 8. >>>>> It silently fails... Well actually it gives the primLoadLibrary >>>>> failure, but good luck in guessing why... >>>>> >>>> >>>> Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have >>>> I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in >>>> any other place? >>>> >>>> >>>>> >>>>> >>>>> Other question, can classic FFI and Alien live nicely together (I mean >>>>> have x plugin use classic FFI while y uses Alien)? >>>>> >>>>> >>>>> yes. >>>>> >>>>> One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't >>>>> have both in, right? >>>>> >>>>> >>>>> One is a subclass of the other. I use the IA32ABIPluginAttic one. >>>>> >>>> >>>> Ok, what is the difference between them? a performance issue? everything >>>> works the same I choose one or the other? >>>> >>>> >>>>> >>>>> >>>>> Syntax highligthing is broken for Alien primitive methods like these: >>>>> >>>>> <primitive: 'primUnsignedShortAtPut' error: errorCode module: >>>>> 'IA32ABI'> >>>>> >>>>> Lastly, as I said when I loaded Alien Core the first time, I got this >>>>> error while loading it: >>>>> >>>>> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". >>>>> >>>>> What should I do about that? ignore it? >>>>> >>>>> >>>>> Well it seems to be related to >>>>> >>>>> ((Smalltalk includesKey: #ObjectMemory) >>>>> and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien >>>>> ifAbsent: []) ~~ (index - 1)]) ifTrue: >>>>> [self error: 'index probably wrong']. >>>>> >>>>> Usually people don't have ObjectMemory loaded in their image, and I"m >>>>> not sure what it is check for. >>>>> Why don't you try it in a regular Pharo image versus your VMMaker >>>>> image. >>>>> >>>>> >>>> In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I >>>> load VMMaker it's downloaded from monticello, but obviously, #ClassAlien >>>> isn't defined inside >>>> >>>> (Smalltalk at: #ObjectMemory) classPool >>>> >>>> Interestingly, after load alien, #ClassAlien gets added as a key, but >>>> all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like >>>> this: >>>> >>>> (Smalltalk at: #ObjectMemory) classPool inspect: >>>> >>>> - size : 119 >>>> [#AllButHashBits] : nil >>>> [#AllButMarkBit] : nil >>>> [#AllButMarkBitAndTypeMask] : nil >>>> [#AllButRootBit] : nil >>>> [#AllButTypeMask] : nil >>>> ... >>>> [#ClassAlien] : nil >>>> ... >>>> >>>> >>>> Any ideas? >>>> >>>> >>>> >>>> -- >>>> Javier PimÃ¡s >>>> Ciudad de Buenos Aires >>>> >>> >>> >>> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >>> >>> >>> -- >>> >>> =========================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> >>> =========================================================================== >>> >>> >>> >>> >>> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by StÃ©phane Ducasse

Yanni I imagine that you are right. Jorge I got problem with colorPaletteForDepth: depth extent: chartExtent I think that we should recompile the image. I should have thought about that. I could remove the last change for the moment. Stef On Mar 3, 2010, at 4:58 PM, Yanni Chiu wrote: > Jorge Ressia wrote: >> We tested it with Lukas and is working fine. However, we should see >> that there are no further side effects. > > I can't check right now, but I suspect it is the cause of this > side-effect - you cannot use the same block variable name in the same > method. E.g. > > foobar > collectionA do: [:each | each foo]. > collectionB do: [:each | each bar]. > > I get a syntax error on the second "each". Is this considered shadowing? > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] about code formatting in pharo

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 03-03-2010 a las 10:19 +0100, Adrian Lienhard escribiÃ³: > I don't like Beck's rule "3. Rectangular Block": > > b ifTrue: > [self clearCaches. > self recomputeAngle] > > I prefer (and this is how most other people format blocks in my experience): > > b ifTrue: [ > self clearCaches. > self recomputeAngle ] +1 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 3, 2010

Re: [Pharo-project] Trying to build alien plugin in linux

by Eliot Miranda

2010/3/3 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > Ok, this is way nicer. The line that was missing and that seems to solve > all this is > > self initializeSpecialObjectIndices. > > which I think should be placed in Alien>>#initialize just before > > self ensureInSpecialObjectsArray. > > but then I don't know why it should ensure anything that is done just > before. > > With that I it's really close to work. After a few hours I understood the > way tests are done. In Alien plugin you integrated a couple of exported > functions (ffiTest*), which you then call in the tests. These funcs do > simple stuff like adding and returning the result, so you can compare, am I > right? > > Then I realized that (at least in linux) the tests won't work if you > compile as internal (there won't be a .so, so you won't be able to load the > C test functions!). > > Now with the small fix I added, and compiling as external, I can see that > it's actually almost almost working, buuuut I get these test results: 36 > run, 17 passed, 19 failures, 0 errors (had to remove > testCallingSquenceString because it crashed the VM). Notice that before I > got 20 errors and 0 failures. This is because the results are wrong. > > > I debugged the code with ddd to see what's happening, and I can see that > everything is going nice before the actual function call, that is done in > dabusiness.h. > > funcAlien = interpreterProxy->stackValue(funcOffset); > f = *(void **)startOfParameterData(funcAlien); > > #if STACK_ALIGN_BYTES (in my compiled code it is'nt defined, should it?) > /* cut stack back to start of aligned args */ > setsp(argstart); > #endif > r = f(); > > I took as example test #ffiTestLongLong10a2:, which calls > ffiTestLongLong10a2(char c1, char c2, char c3, char c4, char c5, char c6, > char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG i2). > > dabusiness.h allocated 56 bytes in argvec (10*4 for chars + 2*8 for > longlong), which then fills correctly (ddd says 1 2 3 4 5 6 7 8 9 10 11 0 12 > 0). I have to admit that I don't fully understand whats happening with the > stack then, but ffiTestLongLong10a2 gets its arguments wrong. I'm thinking > of a calling convention problem. Here it's why: > > In some run I have: &argvec[0] is pos 0aa0 (this is actually direction > inside the stack, near it's top). Just before assembly CALL > ffiTestLongLong10a2 I have ebp=0b68, and after the call it is pushed and > replaced with esp, which is 0a88. Then, we have, args at 0aa0, 0aa4, ..., > and current stack frame starting at 0a88 and going lower, 0a84, etc. That > may be ok, but when I look into the ffiTestLongLong10a2 assembly it is > trying to find the arguments by *substracting* to ebp (arg1 in ebp-1c, 2nd > in ebp-20, ...) when it should adding, looking in greater positions > (previous stack frame, arg1 is in ebp+18). This has to be some simple > calling convention stuff, but I don't know how to solve it, any ideas?. > Subtracting from ebp is for accessing locals, adding to ebp for accessing arguments. Are you sure you're not misinterpreting a local access as an argument access? > Thanks for reading, > Javier. > > > On Mon, Mar 1, 2010 at 9:05 PM, John M McIntosh < > johnmci(a)smalltalkconsulting.com> wrote: > >> It would be missing, propose a change set. >> >> I would think people usually don't use VMMaker images as their daily work >> image. >> >> So take image, load vmaker, load vmaker stuff for alien, make alien >> plugin. >> >> got to my work image that doesn't have vmmaker in it, >> load alien support stuf, you don't need the alien-vmmaker-support btw. >> run tests. >> >> >> >> On 2010-03-01, at 3:36 PM, Javier PimÃ¡s wrote: >> >> Hi, I'm still trying to advance with this. Don't know what caused the >> ObjectMemory classPools but it seems to be away now, maybe I did some >> mistake last time. >> >> The thing is that now I have in ObjectMemory classPools all the original >> ones plus 4 new elements, which I think were added with this >> Alien-VMMaker-Support override: >> >> ObjectMemory>>#initialize >> initialize >> #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector >> #SelectorAttemptToAssign) >> do: [:c | >> [ObjectMemory addClassVarName: c] ifError: []]. >> >> the thing is that it never assigns them any value, so my theory is that >> there's some code missing? Then in Interpreter it happens something quite >> similar. Interpreter>>#initialize does this: >> >> ... >> >> #(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs >> #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate >> #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification >> #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) >> do: [:c | >> [Interpreter addClassVarName: c] ifError: []]. >> >> #(#primFailCode) >> do: [:i | [Interpreter addInstVarName: i] ifError: []]. >> >> ... >> >> but then never calls initializePrimitiveErrorCodes, which would set the >> vars to a meaningfull value. >> >> >> In conclusion, the question would be, where is this missing initialization >> code? >> >> Hope you can help, thanks! >> >> Javier. >> >> On Tue, Feb 23, 2010 at 4:39 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com >> > wrote: >> >>> >>> >>> On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < >>> johnmci(a)smalltalkconsulting.com> wrote: >>> >>>> >>>> On 2010-02-22, at 6:48 PM, Javier PimÃ¡s wrote: >>>> >>>> Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the >>>> results: >>>> >>>> 37 run, 17 passed, 0 failures, 20 errors. >>>> >>>> TestCallingSequenceChar10Long2 >>>> TestCallingSequenceChar2LongLong2 >>>> TestCallingSequenceChar8Long2 >>>> TestCallingSequenceChar9Long2 >>>> TestCallingSequenceCharLongLong2 >>>> TestCallingSequenceChars >>>> TestCallingSequenceDoubles14 >>>> TestCallingSequenceDoubles2 >>>> TestCallingSequenceFloats13 >>>> TestCallingSequenceFloats14 >>>> TestCallingSequenceFloats2 >>>> TestCallingSequenceFloats2WithInteger >>>> TestCallingSequenceFloats2WithInteger2 >>>> TestCallingSequenceFloats7 >>>> TestCallingSequenceInt >>>> TestCallingSequenceInt8 >>>> TestCallingSequenceIntWithFloatArgs >>>> TestCallingSequenceLongLong2 >>>> TestCallingSequenceShort >>>> TestCallingSequenceString >>>> >>>> >>>> Oh look SUnits, great stuff (*cough* well I wrote most of them). >>>> >>>> >>> Cool, this is really really useful (although I sometimes find wrting >>> tests boring ;) ). >>> >>>> >>>> >>>> It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why >>>> should it try to load itself, if it's compiled as an internal plugin? I >>>> compiled it as external too but didn't work either. >>>> >>>> >>>> Well it compiled, but that doesn't mean it works. In fact the error >>>> means the plugin code is never loaded, or is callable. >>>> Now one thing to consider is that the plugin load fails, because it >>>> can't find it. (external usage). >>>> Or because (internal and external plugin) the VM Version and the plugin >>>> version don't match. >>>> >>>> Look for your definition of >>>> #define VM_PROXY_MINOR 8 >>>> >>>> It should be 8 or higher for compiling BOTH the VM and the Plugin. >>>> Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is >>>> mass confusion about which header is being used? >>>> >>>> If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't >>>> work with a plugin compiled with VM_PROXY_MINOR = 8. >>>> It silently fails... Well actually it gives the primLoadLibrary failure, >>>> but good luck in guessing why... >>>> >>> >>> Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have >>> I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in >>> any other place? >>> >>> >>>> >>>> >>>> Other question, can classic FFI and Alien live nicely together (I mean >>>> have x plugin use classic FFI while y uses Alien)? >>>> >>>> >>>> yes. >>>> >>>> One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't >>>> have both in, right? >>>> >>>> >>>> One is a subclass of the other. I use the IA32ABIPluginAttic one. >>>> >>> >>> Ok, what is the difference between them? a performance issue? everything >>> works the same I choose one or the other? >>> >>> >>>> >>>> >>>> Syntax highligthing is broken for Alien primitive methods like these: >>>> >>>> <primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'> >>>> >>>> Lastly, as I said when I loaded Alien Core the first time, I got this >>>> error while loading it: >>>> >>>> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". >>>> >>>> What should I do about that? ignore it? >>>> >>>> >>>> Well it seems to be related to >>>> >>>> ((Smalltalk includesKey: #ObjectMemory) >>>> and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien >>>> ifAbsent: []) ~~ (index - 1)]) ifTrue: >>>> [self error: 'index probably wrong']. >>>> >>>> Usually people don't have ObjectMemory loaded in their image, and I"m >>>> not sure what it is check for. >>>> Why don't you try it in a regular Pharo image versus your VMMaker >>>> image. >>>> >>>> >>> In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I >>> load VMMaker it's downloaded from monticello, but obviously, #ClassAlien >>> isn't defined inside >>> >>> (Smalltalk at: #ObjectMemory) classPool >>> >>> Interestingly, after load alien, #ClassAlien gets added as a key, but all >>> values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this: >>> >>> (Smalltalk at: #ObjectMemory) classPool inspect: >>> >>> - size : 119 >>> [#AllButHashBits] : nil >>> [#AllButMarkBit] : nil >>> [#AllButMarkBitAndTypeMask] : nil >>> [#AllButRootBit] : nil >>> [#AllButTypeMask] : nil >>> ... >>> [#ClassAlien] : nil >>> ... >>> >>> >>> Any ideas? >>> >>> >>> >>> -- >>> Javier PimÃ¡s >>> Ciudad de Buenos Aires >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> >> -- >> >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> >> =========================================================================== >> >> >> >> >> > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by Eliot Miranda

On Wed, Mar 3, 2010 at 7:58 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > Jorge Ressia wrote: > > We tested it with Lukas and is working fine. However, we should see > > that there are no further side effects. > > I can't check right now, but I suspect it is the cause of this > side-effect - you cannot use the same block variable name in the same > method. E.g. > > foobar > collectionA do: [:each | each foo]. > collectionB do: [:each | each bar]. > > I get a syntax error on the second "each". Is this considered shadowing? > No, it's not shadowing in the closure compiler. Are you in an old image? If not and you're using the closure compiler then there's a bug somewhere. My image does not warn. Again, I need to spend some time bringing the various closure compilers up-to-date, which I should have time to do real soon now. best Eliot > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 3, 2010