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

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

by Javier PimÃ¡s

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?. 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

March 3, 2010

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

by Adrian Lienhard

On Mar 3, 2010, at 16:53 , Yanni Chiu wrote: > Isn't readability a matter of taste, or were experiments done? Indeed. As long as we don't carry out usability studies, we don't know what is better and we have to resort to personal taste. When I said "I don't like x" I also meant "I find it is less readable". Yanni gives a good argument below. In any case, I don't want to start an endless discussion about formatting, but I think it is interesting to get the different opinions to be able to come up with a formatter that works for as many people as possible. What we probably all agree on is that a common convention (or automatic formatter) for code in PharoCore would improve readability in comparison to the current situation in which we have all sorts of formatting. Cheers, Adrian > > 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. > > -- > Yanni > > > Chris Muller wrote: >> Well, Kent makes a well-reasoned argument for Rectangular Block, >> readability and productivity. "I don't like it" is just a statement >> of someone's personal taste, a non-starter in terms of a useful >> discussion about formatting. >> >> My goal is to make the system more productive and, by my experience, >> that's what these formatting patterns accomplish. >> >> - Chris >> >> >> On Wed, Mar 3, 2010 at 3:51 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> what do you mean by now used? >>>> Did they change that recently? >>> According to http://planetmisc.squeak.org/ >>> a new package Compiler-cmm.131.mcz is now in Squeak inbox >>> and may find its way into trunk ... >>> >>> >>>> I don't like Beck's rule "3. Rectangular Block" >>> vs. >>>> So for me personally, Beck's rule 3 is the one that looks better. >>> And there we have them: discussions on what looks better :) >>> >>> Bye >>> T. >>> -- >>> Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - >>> jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser >>> >>> _______________________________________________ >>> 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] about code formatting in pharo

by Chris Muller

On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > Isn't readability a matter of taste...? Not according to the pattern description; did you read it? It says, the "tendency of the eye to distinguish and interpolate vertical and horizontal lines. The square brackets used to signify blocks lead the eye to create the illusion of a whole rectangle even though one isn't there." For me, it's absolutely true. > 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). No, universal conformity is not one of the arguments made, nor have I ever felt "consistency for consistency's sake" was ever very useful. Again, I invite you to read the patterns and their basis. > 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. I'm not sure what "hanging left bracket" is. In Rectangular Block, subsequent lines have the "same tabbing" so it may be the same thing. I don't know how anything related to formatting could be faster than having the machine doing it. But if you are not using automatic-formatting, then you won't really be affected by these proposed pretty-print changes..

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by Levente Uzonyi

On Tue, 2 Mar 2010, Alexandre Bergel wrote: >> Well it seems rather special purpose. What are you using it for? >> Why is the cost impacting your work? > > There is an excellent paper at oopsla'09 that shows the method call > graph can be effectively inferred using the method call stack depth: http://www-plan.cs.colorado.edu/klipto/mytkowicz-oopsla09.pdf > > Executing "[ running sender notNil ] whileTrue: [ running := running > sender. depth := depth + 1]" before each method execution of my > application terribly slows it down. This is more than twice as fast, though it may be still too slow for your needs: | depth running | running := thisContext. depth := 1. [ (running := running instVarAt: 1) == nil ] whileFalse: [ depth := depth + 1 ]. depth Levente > > Cheers, > Alexandre > >> >> On 2010-03-02, at 4:06 PM, Alexandre Bergel wrote: >> >>> Will it be of any use for you? If yes, then I will do it. >>> >>> Alexandre >>> >>> >>> On 2 Mar 2010, at 21:00, John M McIntosh wrote: >>> >>>> Maybe you could write a plugin/primitive to do the work? >>>> >>>> On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote: >>>> >>>>> Dear List, >>>>> >>>>> I was wondering whether there is a fast way to know the method call >>>>> stack depth. Something like what follows does the job: >>>>> >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> | depth running | >>>>> depth := 0. >>>>> running := thisContext. >>>>> [ running sender notNil ] whileTrue: [ running := running sender. >>>>> depth := depth + 1]. >>>>> depth >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> But it is rather slow. Anyone has a suggestion? >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> -- >> = >> = >> = >> = >> = >> ====================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> ====================================================================== >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 Yanni Chiu

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

March 3, 2010

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

by Yanni Chiu

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. -- Yanni Chris Muller wrote: > Well, Kent makes a well-reasoned argument for Rectangular Block, > readability and productivity. "I don't like it" is just a statement > of someone's personal taste, a non-starter in terms of a useful > discussion about formatting. > > My goal is to make the system more productive and, by my experience, > that's what these formatting patterns accomplish. > > - Chris > > > On Wed, Mar 3, 2010 at 3:51 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> what do you mean by now used? >>> Did they change that recently? >> According to http://planetmisc.squeak.org/ >> a new package Compiler-cmm.131.mcz is now in Squeak inbox >> and may find its way into trunk ... >> >> >>> I don't like Beck's rule "3. Rectangular Block" >> vs. >>> So for me personally, Beck's rule 3 is the one that looks better. >> And there we have them: discussions on what looks better :) >> >> Bye >> T. >> -- >> Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - >> jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser >> >> _______________________________________________ >> 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] Problems using java code importer with inFusion under windows

by Levente Uzonyi

On Wed, 3 Mar 2010, Simon Denier wrote: > > On 3 mars 2010, at 03:34, David T. Lewis wrote: > >> On Tue, Mar 02, 2010 at 02:18:20PM +0100, Fabrizio Perin wrote: >>> Because the discussion about this topic happened on the moose mailing list i >>> just update also the pharo mailing list. To summarize: >>> >>> I had problems using the importer of java code with inFusion on Windows, at >>> the end i discovered that the primitives into WindowsOSProcessAccessor just >>> fails during the initialization and that the process is not able to access >>> the OS. There is also a bug report here: >>> >>> http://code.google.com/p/moose-technology/issues/detail?id=321&q=OSProcess&… >> >> Hi Fabrizio, >> >> The failure that you are seeing is because the OSProcessPlugin is not >> present in your VM, and therefore the primitives are not there (so really >> there is nothing to debug). >> >> OSProcess is not fully implemented on Windows. You can find some information >> about OSProcess at http://wiki.squeak.org/squeak/708 >> >> If you have the option to use Unix/Linux or Mac, you should get better results. > > > Hi David > > Is there other means to launch a command line (and external tools) form a Windows VM then? You can give this a try: http://www.squeaksource.com/ProcessWrapper.html . Don't know if it works in Pharo or not. Levente > > > -- > Simon > > > > > _______________________________________________ > 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] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available)

by Levente Uzonyi

On Tue, 2 Mar 2010, Igor Stasenko wrote: > 2010/3/2 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: > >> >>>> PS. For the not-so-faint-of-heart, open a Transcript and try evaluating: >>>> |proc| >>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>> 'Finish!' Processor yield.]] newProcess. >>>> proc resume. >>>> Processor yield. >>>> proc suspend. >>>> proc terminate. >>> >>> Why don't we get it printing? >> >> Forgot a . there, supposed to be >> >> |proc| >> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >> 'Finish!'. Processor yield.]] newProcess. >> proc resume. >> Processor yield. >> proc suspend. >> proc terminate. >> >> on my machine it prints: >> *Start!Start!Finish! > > The problem occurs because Transcript >> #endEntry (sent from #show:) > takes a while to execute, so the process (proc) prints 'Start!', but > it gets terminated before execution reaches #resetContents (#reset in > Squeak). So 'Start!' is still in the stream. Then our process executes the > #ensure: block and it prints 'Start!' and 'Finish!' too. > > There's worse problem with #ensure: and #terminate is that, a process > executing an #ensure: block can be terminated. If you evaluate this code: > > | process stage1 stage2 stage3 counter | > stage1 := stage2 := stage3 := false. > counter := 0. > process := [ > Â Â Â Â [ stage1 := true ] ensure: [ > Â Â Â Â Â Â Â Â stage2 := true. > Â Â Â Â Â Â Â Â 1000000 timesRepeat: [ counter := counter + 1 ]. > Â Â Â Â Â Â Â Â stage3 := true ] ] newProcess. > process resume. > Processor yield. > process suspend. > process terminate. > 1000 milliSeconds asDelay wait. > { stage1. stage2. stage3. counter } explore > > you will find that stage1 and stage2 is reached as expected, but stage3 is > not and counter is less than 1000000. That's because the forked process > started evaluating the #ensure: block, but it was terminated by our process. > > Is this the expected behavior when sending #terminate to a process which is > evaluating an #ensure: block? > > What you think is expected behavior here: a) process termination should start (be triggered) only when process is outside of any #ensure: closure? b) #ensure: block should always run to the end, despite anything? Since you can't predict, what code will run inside ensure block, the only guarantee that you having is actually that your process will always enters such blocks during the normal flow, or exception handling. But there is no guarantees that it will be able to run the code inside it, when you terminating it. I'd expect it to be evaluated no matter what happens. Levente > Cheers, > BalÃ¡zs & Levente > > >> >> *yay >> Henry* >> * > > > > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ 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 Chris Muller

Well, Kent makes a well-reasoned argument for Rectangular Block, readability and productivity. "I don't like it" is just a statement of someone's personal taste, a non-starter in terms of a useful discussion about formatting. My goal is to make the system more productive and, by my experience, that's what these formatting patterns accomplish. - Chris On Wed, Mar 3, 2010 at 3:51 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>what do you mean by now used? >>Did they change that recently? > > According to http://planetmisc.squeak.org/ > a new package Compiler-cmm.131.mcz is now in Squeak inbox > and may find its way into trunk ... > > >>I don't like Beck's rule "3. Rectangular Block" > vs. >>So for me personally, Beck's rule 3 is the one that looks better. > > And there we have them: discussions on what looks better :) > > Bye > T. > -- > Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - > jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > 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 Henrik Johansen

I'd vote for b) too, should make it easier than a) in the future to move towards a separation of concerns like what was discussed. Personally, I think some of the voters might be a bit mislead by the points "compatible with Cuis" for a), and "different from Cuis" for b, listed in the initial post. Option b) is still _compatible_ with Cuis, only the _implementation_ is different. (ie code like Smalltalk vmParameterAt: xyz will work with both proposed solutions). Unless, of course, I'm the one misunderstanding :) Cheers, Henry Den 03.03.2010 15:02, skrev Nicolas Cellier: > 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