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

[Pharo-project] about code formatting in pharo
by Torsten Bergmann March 4, 2010

March 4, 2010

>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

10 15

[Pharo-project] SmalltalkImage current vs Smalltalk : plan B
by Nicolas Cellier March 4, 2010

March 4, 2010

For now, plan A has more votes than plan B. plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. Let SmalltalkImage current ^Smalltalk for crossfork compatibility plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = SystemDictionary. Use messages indirections like: Smalltalk vm imagePath Smalltalk commandLine optionAt: 2. etc... (see previous thread) At 1st step, they are not much different: both unify Smalltalk and SmalltalkImage current API. Also Plan A is much simpler, thus attractive. But: - Plan A is essentially coming back to 3.8 statu quo. - Plan B is essentially introducing message indirections Advantages of plan B I see for the future: - cleaner separation of concerns - less vulnerable to refactoring (thanks to messages indirection) - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) easier thru messages Last, I do not desesperate to sell plan B to other forks. See the outline pf plan B below. So do you still buy plan A ? Nicolas ------------------------------------------ OUTLINE OF PLAN B : ------------------------------------------ PART I - Fusion of the 2 APIs in 1 1) add a globals instance variable to SmalltalkImage 2) initialize this instance variable SmalltalkImage current globals: Smalltalk 3) implement SystemDictionary methods in use to SmalltalkImage, and redirect them through globals MessageSentToGlobalFinder testMessagesSentToSmalltalk may help 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. PART II - Refactoring 1) add a few messages in SmalltalkImage (vm ^self) 2) refactor users of SmalltalkImage current -> Smalltalk vm (or Smalltalk commandLine or...) This is the compatibility layer which will enable cross fork compatibility PART III - Provide cross fork compatibility layers: simple, Cuis and Pharo and Squeak3.8 and... just have to respond to Smalltalk vm (and a few others) either ^self or ^SmalltalkImage current or whatever they prefer PART IV - deeper refactorings 1) split SmalltalkImage at will (no precipitation good Rationale SHALL be provided). 2) introduce other Smalltalk hooks for not so well known classes (SystemNavigation / SourceFiles etc...)

3 4

[Pharo-project] Pharo by Example vol 2: new chapter available
by StÃ©phane Ducasse March 4, 2010

March 4, 2010

Hi guys We just released a new chapter for Pharo by Example Vol.2 on Exceptions http://pharobyexample.org/ Let us know what you think. Stef

8 20

[Pharo-project] Problems using java code importer with inFusion under windows
by Fabrizio Perin March 4, 2010

March 4, 2010

Hi, i was using moose in windows and i had an error trying to use the function "import from Java source with inFusion". Seems that OSProcess doesn't work properly. To reproduce the error just try to import java code using this function in the Moose panel in windows. In Mac i never had problem using that cool function. Anybody can help me to figure out where the problem is? Thanks in advance for the support, Fabrizio PS: Here the stack trace: --- The full stack --- UndefinedObject(Object)>>doesNotUnderstand: #nextPutAll: ExternalWindowsOSProcess>>value ExternalWindowsOSProcess class>>command: WindowsProcess>>command: WindowsProcess>>waitForCommand: OSProcess class>>waitForCommand: MooseImportFromJavaSourceFilesWizard>>validateImportation [] in MooseImportFromJavaSourceFilesWizard>>performTerminateButtonAction [] in ProgressInitiationException>>defaultAction BlockClosure>>ensure: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: PSUIManager(MorphicUIManager)>>displayProgress:at:from:to:during: MooseImportFromJavaSourceFilesWizard>>performTerminateButtonAction WizardLastPane>>terminateButtonAction PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction PluggableButtonMorphPlus>>performAction [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: Array(SequenceableCollection)>>do: PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: PluggableButtonMorphPlus>>mouseUp: PluggableButtonMorphPlus(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorphPlus(Morph)>>handleEvent: PluggableButtonMorphPlus(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: [] in PasteUpMorph>>becomeActiveDuring: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess [] in BlockClosure>>newProcess

7 8

[Pharo-project] Quickly getting the method call stack depth
by Alexandre Bergel March 3, 2010

March 3, 2010

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

6 12

[Pharo-project] Undo compiler temporary variable handling
by Lukas Renggli March 3, 2010

March 3, 2010

Before going to Pharo 1.0 final, could we please undo the compiler changes that handle the temporary variables? 1) In various code bases I see an increasing number of temp variables that shadow instance variables. This can lead to subtle bugs in various situations that are very hard to debug. Furthermore consider that the code that shadows instance variables in unlikely to load into any other Smalltalk. 2) In various code bases I see an increasing number of unused temporary variables. Instead of just leaving them in there it would be nice if the compiler removed them right away. Point 1 is a *major* annoyance, I already lost hours for that reason. Point 2 is not that important, as it has no intermediate consequences and can be deferred to code critics. I would need to write a new lint rule though. If I knew where these compiler changes were done, I would propose a fix for Pharo 1.0 and 1.1. Any pointers? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

8 19

[Pharo-project] SketchMorph removal
by StÃ©phane Ducasse March 3, 2010

March 3, 2010

Hi I removed SketchMorph and adapted ImageMorph to be invoked instead. Now sketchMorph has ColorPickerMorph as a subclass so since I did not get the time to understand how we can substitute ColorChooserMorph here is what I did: I fileout sketchmoroh from another image, renamed it with emacs with a funky name and fileout ColorPickerMorph and made sure to use this new superclass. In the process I added some example in comment to ColorChooserMorph. Now it would be good if one of you could have a look at the slice I published in the inbox. alain yes we got rid of it :) http://code.google.com/p/pharo/issues/detail?id=2109 Stef

1 0

March 3, 2010

Browser vs SystemNavigation and much more such as abstraction (traits kind of mistakes) for the sake of it. I was thinking that I would love to have a message-oriented solution. One of these days 1.2 we will have to clean Smalltalk, SmalltalkImage current. The mail is long but worth to get some ideas that you may like or not. Stef Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: March 2, 2010 5:08:56 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Folks - > > I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk": > > 1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk. > > Pro: Compatible with Cuis. > Con: Lack of separation of concerns. > > 2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this: > > SmalltalkImage current globals: Smalltalk. > Smalltalk := SmalltalkImage current. > > Pro: Better separation of concerns. > Con: Different from Cuis. > > I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current". > > If you have an opinion, voice it, otherwise I'll just pick one. > > Cheers, > - Andreas > Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: March 2, 2010 10:56:03 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 2010/3/2 keith <keith_hodges(a)yahoo.co.uk>: >> >> Smalltalk host windowSystem >> >> Smalltalk host platformName >> >> Smalltalk host osVersion >> >> Smalltalk commandLine vmPath. >> >> Smalltalk commandLine imagePath. >> >> Smalltalk commandLine documentPath. >> >> Smalltalk commandLine optionNumber: 2. >> >> Smalltalk commandLine optionAt: 2. >> >> Not every protocol has to be implemented by a different class. >> I asked earlier about a name for the StartupManager. StartupManager would >> happily handle #commandLine and probably #host as well. >> Keith >> >> > > Sure, implementation detail. > Quite sure Squeak/Cuis/Pharo/... wouldhave different implementations. > > Nicolas > >> >> > Begin forwarded message: > From: Igor Stasenko <siguctua(a)gmail.com> > Date: March 2, 2010 11:00:26 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > So, looks like we having a good consensus? > /me always happy when it happens :) > > On 2 March 2010 23:56, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2010/3/2 keith <keith_hodges(a)yahoo.co.uk>: >>> >>> Smalltalk host windowSystem >>> >>> Smalltalk host platformName >>> >>> Smalltalk host osVersion >>> >>> Smalltalk commandLine vmPath. >>> >>> Smalltalk commandLine imagePath. >>> >>> Smalltalk commandLine documentPath. >>> >>> Smalltalk commandLine optionNumber: 2. >>> >>> Smalltalk commandLine optionAt: 2. >>> >>> Not every protocol has to be implemented by a different class. >>> I asked earlier about a name for the StartupManager. StartupManager would >>> happily handle #commandLine and probably #host as well. >>> Keith >>> >>> >> >> Sure, implementation detail. >> Quite sure Squeak/Cuis/Pharo/... wouldhave different implementations. >> >> Nicolas >> >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > Begin forwarded message: > From: Igor Stasenko <siguctua(a)gmail.com> > Date: March 2, 2010 11:10:29 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Haha.. > i just recalled that i proposed something like this before. > Here it is: > http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg02869.ht… > > > -- > Best regards, > Igor Stasenko AKA sig. > Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: March 3, 2010 3:41:22 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Folks - > > That response was most definitely not what I had expected :-) I thought this was going to be a quick round of -1 or +1 instead lots of discussions about interesting forward-looking issues. > > However, what I'm after in this round is not "how to make things better" but rather how to most effectively undo what got broken before. The current separation into SystemDictionary and SmalltalkImage is unmotivated and pointless. However, regardless of what we may end up in the future there is no doubt that there's a *lot* of code out there that will be using either Smalltalk or SmalltalkImage current. This is the problem that I'm trying to address here, no more, no less. > > 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). This isn't the final tally but if you care about the compatibility issues raised here please be specific and state your preference for the options listed below rather than making another forward-looking proposal that I have no intention to implement for this round. > > Cheers, > - Andreas > > > On 3/1/2010 8:08 PM, Andreas Raab wrote: >> Folks - >> >> I was just trying to load some other code and once too many I got bitten >> by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it >> now. The only question is which way. There are two alternatives which >> achieve the goal of "SmalltalkImage current == Smalltalk": >> >> 1) The Cuis variant: Move all the code back to SystemDictionary; >> implement SmalltalkImage current as ^Smalltalk. >> >> Pro: Compatible with Cuis. >> Con: Lack of separation of concerns. >> >> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >> SmalltalkImage; add a 'globals' variable (populated by an instance of >> SystemDictionary) and convert everything roughly like this: >> >> SmalltalkImage current globals: Smalltalk. >> Smalltalk := SmalltalkImage current. >> >> Pro: Better separation of concerns. >> Con: Different from Cuis. >> >> I really don't care which way we do it; all I want is to get out of the >> mess we've created by introducing "SmalltalkImage current". >> >> If you have an opinion, voice it, otherwise I'll just pick one. >> >> Cheers, >> - Andreas >> >> > > Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: March 3, 2010 3:45:10 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On 3/2/2010 9:04 AM, Eliot Miranda wrote: >> The worst thing going on with things like SmalltalkImage current, >> SystemNavigation default and traits is the introduction of abstraction >> for its own sake. Abstraction is properly used to manage complexity. >> But for example, as others have pointed out, there is no other image >> than the current image and so SmalltalkImage current is merely verbiage. >> And yet SourceFiles is an obvious area which could use a lot more >> features (being able to load package sources without appending them to >> the sources file, or having two changes files, one for loaded packages, >> one for user modifications, etc). > > Thanks Eliot. That's an *excellent* description of the problem. > > Cheers, > - Andreas > Begin forwarded message: > From: keith <keith_hodges(a)yahoo.co.uk> > Date: March 3, 2010 4:15:51 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > > On 3 Mar 2010, at 02:45, Andreas Raab wrote: > >> On 3/2/2010 9:04 AM, Eliot Miranda wrote: >>> The worst thing going on with things like SmalltalkImage current, >>> SystemNavigation default and traits is the introduction of abstraction >>> for its own sake. Abstraction is properly used to manage complexity. >>> But for example, as others have pointed out, there is no other image >>> than the current image and so SmalltalkImage current is merely verbiage. >>> And yet SourceFiles is an obvious area which could use a lot more >>> features (being able to load package sources without appending them to >>> the sources file, or having two changes files, one for loaded packages, >>> one for user modifications, etc). >> >> Thanks Eliot. That's an *excellent* description of the problem. >> >> Cheers, >> - Andreas > > And option 3 dnu handler on smalltalk. > > I think that my vote would be for option 1, and cuis compatibility. Regrouping, before breaking things out again, > but lets start using the new accessors as well. > > I implemented some in cuis > > #host #organization #query #sourceCode #vm #commandLine #startupManager > > However isn't the dnu solution is the only one that will be able to cope in the longer term if you do break things out again. > So one could argue that you may as well use it now. > > Keith > Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: March 3, 2010 5:01:05 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On 3/2/2010 7:21 PM, Ronald Spengler wrote: >> Well heck:) I don't think my opinion is of a lot of value here, but >> aesthetically I'd like to see SmalltalkImage killed. Partly I'm just >> not clear on what concerns it really separates. > > The dictionary and the name aspect. Option #2 has the effect that Smalltalk is-no-longer-a Dictionary. I do find that an improvement; subclassing the collection classes by something that's not really a collection (in this case SystemDictionary is a representative of the Smalltalk environment with very few dictionary aspects) isn't particularly good design. Plus I find it a bit problematic that in option #1 Smalltalk is an instance of SystemDictionary and SmalltalkImage is a class that has no relationship to the Smalltalk image. > > Cheers, > - Andreas > >> On Tuesday, March 2, 2010, Andreas Raab<andreas.raab(a)gmx.de> wrote: >>> On 3/2/2010 9:04 AM, Eliot Miranda wrote: >>> >>> The worst thing going on with things like SmalltalkImage current, >>> SystemNavigation default and traits is the introduction of abstraction >>> for its own sake. Abstraction is properly used to manage complexity. >>> But for example, as others have pointed out, there is no other image >>> than the current image and so SmalltalkImage current is merely verbiage. >>> And yet SourceFiles is an obvious area which could use a lot more >>> features (being able to load package sources without appending them to >>> the sources file, or having two changes files, one for loaded packages, >>> one for user modifications, etc). >>> >>> >>> Thanks Eliot. That's an *excellent* description of the problem. >>> >>> Cheers, >>> - Andreas >>> >>> >> > > Begin forwarded message: > From: Michael Haupt <mhaupt(a)gmail.com> > Date: March 3, 2010 7:14:27 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 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. > > Best, > > Michael > Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: March 3, 2010 7:38:12 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 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 > Begin forwarded message: > From: Michael Haupt <mhaupt(a)gmail.com> > Date: March 3, 2010 8:57:02 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Hi again, > > On Wed, Mar 3, 2010 at 7:38 AM, Andreas Raab <andreas.raab(a)gmx.de> wrote: >>> here's another for "Smalltalk", then. >> >> That choice doesn't exist :-) You can vote for: >> a) Smalltalk class == SystemDictionary, or >> b) Smalltalk class == SmalltalkImage > > ach yuck. Sorry, I meant #1. :-) > Early morning syndrome. > > Best, > > Michael > Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: March 2, 2010 10:05:13 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 2010/3/2 Bert Freudenberg <bert(a)freudenbergs.de>: >> On 02.03.2010, at 05:08, Andreas Raab wrote: >>> >>> Folks - >>> >>> I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk": >>> >>> 1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk. >>> >>> Pro: Compatible with Cuis. >>> Con: Lack of separation of concerns. >>> >>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this: >>> >>> SmalltalkImage current globals: Smalltalk. >>> Smalltalk := SmalltalkImage current. >>> >>> Pro: Better separation of concerns. >>> Con: Different from Cuis. >>> >>> I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current". >>> >>> If you have an opinion, voice it, otherwise I'll just pick one. >>> >>> Cheers, >>> - Andreas >> >> 1) +1 >> 2) -0 >> >> - Bert - >> > > I won't propose anything here. > Just invite to think of it. > > As noticed by Ronald, the main problem with SmalltalkImage is that it > does not represent any Object indeed... > It's just a place holder for some system utilities... > > When I see idioms like (SmalltalkImage current vmParameterAt: > parameterIndex), I just wonder why not (SmalltalkVM current > parameterAt: parameterIndex).... > If the VM where reified anyway, I would as well understand (Smalltalk > vm parameterAt: parameterIndex). > > Sure, Marcus & Steph were right: why the hell a SystemDictionary > should know about the image file name or some vm parameter ? > Except that Smalltalk was not only a SystemDictionary but the > interface to "System" parameters fora very long time (st80)... > And as we can see under vmParameter idiom light, SmalltalkImage is > arbitrary. At least as arbitrary as Smalltalk. > Just less readable, adding an unnecessary current complexification... > Yes, current is just meaningless indeed until you start playing with > some sort of hydra VM and gain access to an external image (a frozen > ObjectMemory, or its Image file dump). > In the interim, a global named #System would have been far better > understood (or #Squeak if we don't want to be portable across forks) > > That's where Stephane and Marcus failed... > ... replacing a well known hack (Smalltalk == System) with something > not solid enough. > When you break such habits (and code) you have to sell it with well > thought replacement. > > Though, when I see code like (Smalltalk cleanUpUndoCommands), I can't > help thinking Steph and Marcus intention was right... > > Nicolas > Begin forwarded message: > From: StÃ©phane Rollandin <lecteur(a)zogotounga.net> > Date: March 2, 2010 1:18:55 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > >> As noticed by Ronald, the main problem with SmalltalkImage is that it >> does not represent any Object indeed... > > It represent some meta-information about the Smalltalk system, aspects of the system seen from outside so to say. It can not really be an object semantically on par with the others, but that information must be provided somehow. > > AFAIC I see no actual problem here, better a question of taste concerning where the meta-info should be stored and how it should be retrieved. > >> Though, when I see code like (Smalltalk cleanUpUndoCommands), ... > > That's the user (that is, the outside) ordering the system to do something. It fits in my view of what SmalltalkImage represents. > > Concerning Andreas question, I would keep globals in Smalltalk (since it is the SystemDictionary) and put everything else in SmalltalkImage that I would rename Squeak because it's nicer (and also because the image is only a part of the system, along with the VM for example). > > Or we could just reify everything, and have classes Image, Changes, Sources, VM, Platform, User... why not ? we already have DisplayScreen ("There is only one instance of me, Display. It is a global and is used to handle general user requests to deal with the whole display screen."). It could be fun. > > > my 2 cents... > > Stef > > > Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: March 2, 2010 4:41:52 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 2010/3/2 StÃ©phane Rollandin <lecteur(a)zogotounga.net>: >>> As noticed by Ronald, the main problem with SmalltalkImage is that it >>> does not represent any Object indeed... >> >> It represent some meta-information about the Smalltalk system, aspects of >> the system seen from outside so to say. It can not really be an object >> semantically on par with the others, but that information must be provided >> somehow. >> > > Hehe, I notice you used this idiom (Smalltalk system), rather than > this one (SmalltalkImage current). > This is not neutral :) > I would prefer the former too ;) > > See for example, Dolphin has: > Smalltalk developmentSystem -> a SmalltalkSystem > > Could they have a Smalltalk deploymentSystem ? > In the same time, they have a rather clean SystemDictionary. > > VW, with namespace changes completely cleaned Smalltalk too (it's just > a NameSpace). > Utilities are spreaded around a bunch of classes (apart Smalltalk > version for portability). > > Personnally, I was bred with st80 (Browser browse...), not those > (SystemNavigation default browse...) and it sometimes still bugs me ;) > ... > >> AFAIC I see no actual problem here, better a question of taste concerning >> where the meta-info should be stored and how it should be retrieved. >> >>> Though, when I see code like (Smalltalk cleanUpUndoCommands), ... >> >> That's the user (that is, the outside) ordering the system to do something. >> It fits in my view of what SmalltalkImage represents. >> >> Concerning Andreas question, I would keep globals in Smalltalk (since it is >> the SystemDictionary) and put everything else in SmalltalkImage that I would >> rename Squeak because it's nicer (and also because the image is only a part >> of the system, along with the VM for example). >> >> Or we could just reify everything, and have classes Image, Changes, Sources, >> VM, Platform, User... why not ? we already have DisplayScreen ("There is >> only one instance of me, Display. It is a global and is used to handle >> general user requests to deal with the whole display screen."). It could be >> fun. >> > > As I said, (Smalltalk vm parameterAt: ) would not shock me. > Of course, replace first all these (vmParameterAt: > obscureCodeForGurus) by more explicit message ;) > > What idiom do we have in use by now ? > > - The globals: > Smalltalk keys sort reject: [:e | (Smalltalk at: e) isBehavior] > #(#ActiveEvent #ActiveHand #ActiveWorld #CustomEventsRegistry > #Display #ImageImports #Processor #References #ScheduledControllers > #ScriptingSystem #Sensor #Smalltalk #SourceFiles #SystemOrganization > #TextConstants #Transcript #Undeclared #World) > > - (SomeClass current) > (Smalltalk classNames asArray sort select: [:e | (Smalltalk at: e) > class includesSelector: #current]) > #(#BitBlt #CPUWatcher #ChangeSet #ColorTheme #Locale #LocaleID > #NaturalLanguageTranslator #Project #ReleaseBuilderFor3dot10 > #ResourceCollector #ServiceRegistry #SmalltalkImage #SystemVersion > #TestResource #WarpBlt) > > I omit #( #DateAndTime #Time #TimeStamp #Timespan #Year ) > > - (SomeClass default) > (Smalltalk classNames asArray sort select: [:e | (Smalltalk at: e) > class includesSelector: #default]) > #(#AbstractSound #AppRegistry #Beeper #BorderStyle #Categorizer > #Clipboard #FMSound #FileDirectory #FontChooserTool #HTTPLoader > #Imports #InputSensor #InstallerUniverse #MCCacheRepository > #MCRepositoryGroup #NaturalLanguageTranslator #PackageInfo > #PackageOrganizer #PluckedSound #Requestor #SMSqueakMap > #SecurityManager #SystemNavigation #TTCFontDescription > #TTFontDescription #TextConverter #TextStyle #TimeZone #ToolBuilder > #UIManager #UUIDGenerator #UnloadedSound #WeakRegistry) > > Nobody would bring back all corresponding methods in SystemDictionary > I presume... > > Nicolas > >> >> my 2 cents... >> >> Stef >> >> >> >> > Begin forwarded message: > From: "David T. Lewis" <lewis(a)mail.msen.com> > Date: March 2, 2010 5:24:18 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On Mon, Mar 01, 2010 at 08:08:56PM -0800, Andreas Raab wrote: >> Folks - >> >> I was just trying to load some other code and once too many I got bitten >> by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it >> now. The only question is which way. There are two alternatives which >> achieve the goal of "SmalltalkImage current == Smalltalk": >> >> 1) The Cuis variant: Move all the code back to SystemDictionary; >> implement SmalltalkImage current as ^Smalltalk. >> >> Pro: Compatible with Cuis. >> Con: Lack of separation of concerns. >> >> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >> SmalltalkImage; add a 'globals' variable (populated by an instance of >> SystemDictionary) and convert everything roughly like this: >> >> SmalltalkImage current globals: Smalltalk. >> Smalltalk := SmalltalkImage current. >> >> Pro: Better separation of concerns. >> Con: Different from Cuis. > > I favor #1. > > Rationale: > > The name "SmalltalkImage" sounds like it means something, but I can't > figure out what. Based on the things that it actually implements, I > can't think of any definition that would make sense. The class comment > is meaningless and adds to the confusion. > > I honestly can't think of any way to fix "SmalltalkImage" that does > not introduce more incompatibilities, so that leaves the Cuis approach > as my preference. > > I do think it may be worth waiting a week or so to see if anyone can > come up with any better approach that meets these criteria: > > - Moves the extraneous behavior out of SystemDictionary, as per the > original intent of the SmalltalkImage refactoring. > - Consists only of classes with meaningful class comments and > clear responsibilities > - Preserves "SmalltalkImage current == Smalltalk" for compatibility > - Preserves the "SmalltalkImage current" idiom for compatibility > > I cannot personally think of any good way to do this, but maybe someone > else can. > > Dave > > Begin forwarded message: > From: "David T. Lewis" <lewis(a)mail.msen.com> > Date: March 2, 2010 5:27:24 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On Tue, Mar 02, 2010 at 10:05:13AM +0100, Nicolas Cellier wrote: >> >> Though, when I see code like (Smalltalk cleanUpUndoCommands), I can't >> help thinking Steph and Marcus intention was right... > > Well, it's a utility procedure, so "Utilities cleanUpUndoCommands" comes > to mind. > > Dave > > Begin forwarded message: > From: Chris Muller <asqueaker(a)gmail.com> > Date: March 2, 2010 5:32:34 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: ma.chris.m(a)gmail.com, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Smalltalk is a SystemDictionary, which is-a Dictionary. This suggests > Smalltalk's main responsibility is mapping the list of global names to > their global objects, and providing access to them by direct > reference. > > I don't understand why would want to commingle a bunch of utility > methods in with this primary (global name mapping) responsibility..? > > What is the problem exactly? > > Also, I'm curious about Cuis compatibility; is this really realistic > or important? Why is it important? This would seem to be a > relatively superficial difference with Cuis and other Smalltalk's, so > I hope we will base decisions on what we think is the "right thing" to > do rather than compatibility with something else that might not > matter.. > > > On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: >> Folks - >> >> I was just trying to load some other code and once too many I got bitten by >> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. >> The only question is which way. There are two alternatives which achieve the >> goal of "SmalltalkImage current == Smalltalk": >> >> 1) The Cuis variant: Move all the code back to SystemDictionary; implement >> SmalltalkImage current as ^Smalltalk. >> >> Pro: Compatible with Cuis. >> Con: Lack of separation of concerns. >> >> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >> SmalltalkImage; add a 'globals' variable (populated by an instance of >> SystemDictionary) and convert everything roughly like this: >> >> SmalltalkImage current globals: Smalltalk. >> Smalltalk := SmalltalkImage current. >> >> Pro: Better separation of concerns. >> Con: Different from Cuis. >> >> I really don't care which way we do it; all I want is to get out of the mess >> we've created by introducing "SmalltalkImage current". >> >> If you have an opinion, voice it, otherwise I'll just pick one. >> >> Cheers, >> - Andreas >> >> > Begin forwarded message: > From: Igor Stasenko <siguctua(a)gmail.com> > Date: March 2, 2010 5:55:10 PM GMT+01:00 > To: ma.chris.m(a)gmail.com, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > If you remember previous discussion about this, i proposed to use > Smalltalk, which having a 'globals' ivar , which is a SystemDictionary > so, that Smalltalk>>at: x > implemented as > globals at: x > > then Smalltalk global is an instance of SmalltalkImage , equal to > SmalltalkImage current. > And SystemDictionary is just a dictionary without any extra utility methods. > > > On 2 March 2010 18:32, Chris Muller <asqueaker(a)gmail.com> wrote: >> Smalltalk is a SystemDictionary, which is-a Dictionary. This suggests >> Smalltalk's main responsibility is mapping the list of global names to >> their global objects, and providing access to them by direct >> reference. >> >> I don't understand why would want to commingle a bunch of utility >> methods in with this primary (global name mapping) responsibility..? >> >> What is the problem exactly? >> >> Also, I'm curious about Cuis compatibility; is this really realistic >> or important? Why is it important? This would seem to be a >> relatively superficial difference with Cuis and other Smalltalk's, so >> I hope we will base decisions on what we think is the "right thing" to >> do rather than compatibility with something else that might not >> matter.. >> >> >> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: >>> Folks - >>> >>> I was just trying to load some other code and once too many I got bitten by >>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. >>> The only question is which way. There are two alternatives which achieve the >>> goal of "SmalltalkImage current == Smalltalk": >>> >>> 1) The Cuis variant: Move all the code back to SystemDictionary; implement >>> SmalltalkImage current as ^Smalltalk. >>> >>> Pro: Compatible with Cuis. >>> Con: Lack of separation of concerns. >>> >>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >>> SmalltalkImage; add a 'globals' variable (populated by an instance of >>> SystemDictionary) and convert everything roughly like this: >>> >>> SmalltalkImage current globals: Smalltalk. >>> Smalltalk := SmalltalkImage current. >>> >>> Pro: Better separation of concerns. >>> Con: Different from Cuis. >>> >>> I really don't care which way we do it; all I want is to get out of the mess >>> we've created by introducing "SmalltalkImage current". >>> >>> If you have an opinion, voice it, otherwise I'll just pick one. >>> >>> Cheers, >>> - Andreas >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > Begin forwarded message: > From: Ronald Spengler <ron.spengler(a)gmail.com> > Date: March 3, 2010 4:21:26 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Well heck:) I don't think my opinion is of a lot of value here, but > aesthetically I'd like to see SmalltalkImage killed. Partly I'm just > not clear on what concerns it really separates. > > On Tuesday, March 2, 2010, Andreas Raab <andreas.raab(a)gmx.de> wrote: >> On 3/2/2010 9:04 AM, Eliot Miranda wrote: >> >> The worst thing going on with things like SmalltalkImage current, >> SystemNavigation default and traits is the introduction of abstraction >> for its own sake. Abstraction is properly used to manage complexity. >> But for example, as others have pointed out, there is no other image >> than the current image and so SmalltalkImage current is merely verbiage. >> And yet SourceFiles is an obvious area which could use a lot more >> features (being able to load package sources without appending them to >> the sources file, or having two changes files, one for loaded packages, >> one for user modifications, etc). >> >> >> Thanks Eliot. That's an *excellent* description of the problem. >> >> Cheers, >> - Andreas >> >> > > -- > Ron > Begin forwarded message: > From: Alexander LazareviÄ <laza(a)blobworks.com> > Date: March 3, 2010 4:26:22 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 1) +1 > > On Tue, Mar 2, 2010 at 05:08, Andreas Raab <andreas.raab(a)gmx.de> wrote: >> Folks - >> >> I was just trying to load some other code and once too many I got bitten by >> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. >> The only question is which way. There are two alternatives which achieve the >> goal of "SmalltalkImage current == Smalltalk": >> >> 1) The Cuis variant: Move all the code back to SystemDictionary; implement >> SmalltalkImage current as ^Smalltalk. >> >> Pro: Compatible with Cuis. >> Con: Lack of separation of concerns. >> >> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >> SmalltalkImage; add a 'globals' variable (populated by an instance of >> SystemDictionary) and convert everything roughly like this: >> >> SmalltalkImage current globals: Smalltalk. >> Smalltalk := SmalltalkImage current. >> >> Pro: Better separation of concerns. >> Con: Different from Cuis. >> >> I really don't care which way we do it; all I want is to get out of the mess >> we've created by introducing "SmalltalkImage current". >> >> If you have an opinion, voice it, otherwise I'll just pick one. >> >> Cheers, >> - Andreas >> >> > Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: March 2, 2010 9:41:35 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > > > On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/3/2 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges(a)yahoo.co.uk> wrote: > >> > >> 1) The Cuis variant: Move all the code back to SystemDictionary; implement > >> SmalltalkImage current as ^Smalltalk. > >> > >> Cuis didn't exactly move the code back to SystemDictionary, of course it > >> never left in the first place. It is easier for Cuis to implement > >> compatibility with "trunk" than it is for "trunk" to go back to the old way. > >> How much code uses Smalltalk at: ? As soon as you put SmalltalkImage > >> current into Smalltalk you have to make what was an "image utilities" class > >> behave like a dictionary. > >> You seem to be saying, we must have a single place to access this stuff > >> called "Smalltalk". I think what really needs to happen is to factor things > >> up nicely and logically so we know where to find things and can write > >> compatible code. > >> I propose as a starting point, that we design a scheme or convention that > >> implements the "long hand" variant, and then when happy with this, implement > >> the short hand versions. The most obvious long hand variant. > >> self class environment "system globals" > >> self class environment image > >> self class environment navigation > >> self class environment sourceFiles > >> self class environment startupManager. > >> self class environment organization. > > > > This doesn't make sense in a workspace where the notion of the current class > > is a weak one (current class is UndefinedObject for want of having no class > > at all). > > Why are global names worse than any of these? > > I think Smalltalk == System is a good approach. Making things verbose is a > > very poor direction. When a cluster of associated behaviours gets complex > > enough then by all means move it out to a class. So in VisualWorks the > > pairing of ObjectMemory and MemoryPolicy which allows inspection and > > tailoring of memory management makes sense. > > A Tools object for systemNavigation might make sense, but SystemNavigation > > is a poor name; long (SystemNavigation default being worse) and not very > > informative. BrowserQuery would be better. Browse would be better. > > Maybe a SystemNavigation was introduced to handle the fact that there > were many different browsers... Or Morphic + MVC.... > Maybe some were thinking embedding a default + some alternatives in a > single image... > > Maybe, but if that effort wasn't implemented it wass pointless. Introducing the abstraction without adding it is pointless. For example, using traits only in the traits implementation, instead of where it belongs, the collection hierarchy, is pointless. > > But I'm not criticising the idea of SystemNavigation, only its naming. There's clear benefit to having something with SystemNavigation functionality, but SystemNavigation is a poor name. Browse is a better name. > > (Browser browseAllCallsOn: #yourself) was just perfectly short :) > Or (Browser allCallsOn: #yourself) open/view/edit/browse/..., if we > really want to avoid pairing each message. > A pity that Browser itself failed to become the abstract factory which > SystemNavigation default is... > > Yes, but Browser is a specific tool and it makes sense when there are many different browsers to separate the request to open a browser from the browser itself. Also, queries which answer sets of MethodReferences et al are very useful and don't necessarily belong in Browser. So why not Browse and Browser for the request and one of its results? Is SystemNavigation default a good name? Does the default in SystemNavigation default provide anything useful (e.g. that preferences don't)? > > > > The worst thing going on with things like SmalltalkImage current, > > SystemNavigation default and traits is the introduction of abstraction for > > its own sake. Abstraction is properly used to manage complexity. But for > > example, as others have pointed out, there is no other image than the > > current image and so SmalltalkImage current is merely verbiage. And yet > > SourceFiles is an obvious area which could use a lot more features (being > > able to load package sources without appending them to the sources file, or > > having two changes files, one for loaded packages, one for user > > modifications, etc). > > I meant to emphasise here that traits is a perfect example of not going far enough to justify its existence. Traits are a great idea but unless they're carried through and used in implementing class libraries other than the traits system itself (i.e. especially the collection hierarchy) they're overhead that is carried in lots of places (cognitive complexity for new users, complexity in the tools, e.g. Monticello, etc). I'm not saying get rid of traits. I'm saying that something shouldn't become a component of the core until it carries its weight (much as in PARC the contents of the base image were discussed every 6 months in a sort of balloon game with components that couldn't be defended being ejected) and we shouldn't repeat the mistake of integrating half-completed abstractions. When introducing new abstractions during decomposition be sure that the effort is worth it and that the implementation is carried through. > > > Another bad thing is not thinking about names. Names are extremely > > important for making sense of a system, most especially for new users. > > Finding a vivid short name is well worth extra effort. > > I'd love to see someone start a side project which comprised > > - a minimal kernel image, capable of bootstrapping (so includes base class > > library, compiler, gui-less debugger/back-tracer, file system interface) > > - a set of packages comprising loadable programming tools > > - a refactoring engine and rules base for converting from the current Squeak > > dialects where the rules were renamings of things like "SystemNavigation > > default" into "Browse" > > and which focussed on a new set of global names for the environment. The > > base class library would stay the same, but Smalltalk, SystemNavigation, > > SmalltalkImage etc would be up for grabs. > > I'd then love to see a university department divide a class into two and see > > how each set of students faired with each variant, each provided with > > otherwise identical introductory material that differed only in the names & > > organization of these system services classes. > > > >> > >> For the shorter hand variants, personally I wouldn't mind these being > >> implemented on Object, aka #systemNavigation. > >> self systemEnvironment, self systemImage, self systemNavigation, self > >> systemSourceFiles, self systemStartupManager, self systemOrganization > >> but I think I would prefer an instance side implementation of > >> #environment/#system/#smalltalk > >> SmalltalkImage current would then become: > >> self environment image / self smalltalk image. > >> ok, it's not compatible, but its not a mess either. > >> The compatibility I would fix temporarily with better code loading tools, > >> or a dnu: on SystemDictionary. > >> K. > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: March 2, 2010 10:07:33 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 2010/3/2 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> 2010/3/2 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> >>>> >>>> On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges(a)yahoo.co.uk> wrote: >>>>> >>>>> 1) The Cuis variant: Move all the code back to SystemDictionary; >>>>> implement >>>>> SmalltalkImage current as ^Smalltalk. >>>>> >>>>> Cuis didn't exactly move the code back to SystemDictionary, of course >>>>> it >>>>> never left in the first place. It is easier for Cuis to implement >>>>> compatibility with "trunk" than it is for "trunk" to go back to the old >>>>> way. >>>>> How much code uses Smalltalk at: ? As soon as you put SmalltalkImage >>>>> current into Smalltalk you have to make what was an "image utilities" >>>>> class >>>>> behave like a dictionary. >>>>> You seem to be saying, we must have a single place to access this stuff >>>>> called "Smalltalk". I think what really needs to happen is to factor >>>>> things >>>>> up nicely and logically so we know where to find things and can write >>>>> compatible code. >>>>> I propose as a starting point, that we design a scheme or convention >>>>> that >>>>> implements the "long hand" variant, and then when happy with this, >>>>> implement >>>>> the short hand versions. The most obvious long hand variant. >>>>> self class environment "system globals" >>>>> self class environment image >>>>> self class environment navigation >>>>> self class environment sourceFiles >>>>> self class environment startupManager. >>>>> self class environment organization. >>>> >>>> This doesn't make sense in a workspace where the notion of the current >>>> class >>>> is a weak one (current class is UndefinedObject for want of having no >>>> class >>>> at all). >>>> Why are global names worse than any of these? >>>> I think Smalltalk == System is a good approach. Making things verbose >>>> is a >>>> very poor direction. When a cluster of associated behaviours gets >>>> complex >>>> enough then by all means move it out to a class. So in VisualWorks the >>>> pairing of ObjectMemory and MemoryPolicy which allows inspection and >>>> tailoring of memory management makes sense. >>>> A Tools object for systemNavigation might make sense, but >>>> SystemNavigation >>>> is a poor name; long (SystemNavigation default being worse) and not very >>>> informative. BrowserQuery would be better. Browse would be better. >>> >>> Maybe a SystemNavigation was introduced to handle the fact that there >>> were many different browsers... Or Morphic + MVC.... >>> Maybe some were thinking embedding a default + some alternatives in a >>> single image... >> >> Maybe, but if that effort wasn't implemented it wass pointless. Introducing >> the abstraction without adding it is pointless. For example, using traits >> only in the traits implementation, instead of where it belongs, the >> collection hierarchy, is pointless. >> But I'm not criticising the idea of SystemNavigation, only its naming. >> There's clear benefit to having something with SystemNavigation >> functionality, but SystemNavigation is a poor name. Browse is a better >> name. >>> >>> (Browser browseAllCallsOn: #yourself) was just perfectly short :) >>> Or (Browser allCallsOn: #yourself) open/view/edit/browse/..., if we >>> really want to avoid pairing each message. >>> A pity that Browser itself failed to become the abstract factory which >>> SystemNavigation default is... >> >> Yes, but Browser is a specific tool and it makes sense when there are many >> different browsers to separate the request to open a browser from the >> browser itself. Also, queries which answer sets of MethodReferences et al >> are very useful and don't necessarily belong in Browser. So why not Browse >> and Browser for the request and one of its results? Is SystemNavigation >> default a good name? Does the default in SystemNavigation default provide >> anything useful (e.g. that preferences don't)? > > Agree, 99% > For the remaining 1%, my thought was that Browser could become an > abstract factory instead of a Specific tool. > The specific tools would be renamed SystemBrowser (or HierarchyBrowser > OBBrowser WhiskerBrowser etc...). > > Nicolas > >>> >>> > The worst thing going on with things like SmalltalkImage current, >>>> SystemNavigation default and traits is the introduction of abstraction >>>> for >>>> its own sake. Abstraction is properly used to manage complexity. But >>>> for >>>> example, as others have pointed out, there is no other image than the >>>> current image and so SmalltalkImage current is merely verbiage. And yet >>>> SourceFiles is an obvious area which could use a lot more features >>>> (being >>>> able to load package sources without appending them to the sources file, >>>> or >>>> having two changes files, one for loaded packages, one for user >>>> modifications, etc). >> >> I meant to emphasise here that traits is a perfect example of not going far >> enough to justify its existence. Traits are a great idea but unless they're >> carried through and used in implementing class libraries other than the >> traits system itself (i.e. especially the collection hierarchy) they're >> overhead that is carried in lots of places (cognitive complexity for new >> users, complexity in the tools, e.g. Monticello, etc). I'm not saying get >> rid of traits. I'm saying that something shouldn't become a component of >> the core until it carries its weight (much as in PARC the contents of the >> base image were discussed every 6 months in a sort of balloon game with >> components that couldn't be defended being ejected) and we shouldn't repeat >> the mistake of integrating half-completed abstractions. When introducing >> new abstractions during decomposition be sure that the effort is worth it >> and that the implementation is carried through. > > Don't apply that on Squeak now, we gonna feel naked ;) > >>> >>>> Another bad thing is not thinking about names. Names are extremely >>>> important for making sense of a system, most especially for new users. >>>> Finding a vivid short name is well worth extra effort. >>>> I'd love to see someone start a side project which comprised >>>> - a minimal kernel image, capable of bootstrapping (so includes base >>>> class >>>> library, compiler, gui-less debugger/back-tracer, file system interface) >>>> - a set of packages comprising loadable programming tools >>>> - a refactoring engine and rules base for converting from the current >>>> Squeak >>>> dialects where the rules were renamings of things like "SystemNavigation >>>> default" into "Browse" >>>> and which focussed on a new set of global names for the environment. >>>> The >>>> base class library would stay the same, but Smalltalk, SystemNavigation, >>>> SmalltalkImage etc would be up for grabs. >>>> I'd then love to see a university department divide a class into two and >>>> see >>>> how each set of students faired with each variant, each provided with >>>> otherwise identical introductory material that differed only in the >>>> names & >>>> organization of these system services classes. >>>> >>>>> >>>>> For the shorter hand variants, personally I wouldn't mind these being >>>>> implemented on Object, aka #systemNavigation. >>>>> self systemEnvironment, self systemImage, self systemNavigation, self >>>>> systemSourceFiles, self systemStartupManager, self systemOrganization >>>>> but I think I would prefer an instance side implementation of >>>>> #environment/#system/#smalltalk >>>>> SmalltalkImage current would then become: >>>>> self environment image / self smalltalk image. >>>>> ok, it's not compatible, but its not a mess either. >>>>> The compatibility I would fix temporarily with better code loading >>>>> tools, >>>>> or a dnu: on SystemDictionary. >>>>> K. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> >> >> > Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: March 2, 2010 10:20:34 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 2010/3/2 Igor Stasenko <siguctua(a)gmail.com>: >> On 2 March 2010 22:00, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 2010/3/2 Andreas Raab <andreas.raab(a)gmx.de>: >>>> On 3/2/2010 8:55 AM, Igor Stasenko wrote: >>>>> >>>>> If you remember previous discussion about this, i proposed to use >>>>> Smalltalk, which having a 'globals' ivar , which is a SystemDictionary >>>>> so, that Smalltalk>>at: x >>>>> implemented as >>>>> globals at: x >>>>> >>>>> then Smalltalk global is an instance of SmalltalkImage , equal to >>>>> SmalltalkImage current. >>>>> And SystemDictionary is just a dictionary without any extra utility >>>>> methods. >>>> >>>> This is option #2 below. (Sorry I didn't recall your post; otherwise I >>>> would've named it the Igor variant :-) >>>> >>>> Cheers, >>>> - Andreas >>>> >>>>> On 2 March 2010 18:32, Chris Muller<asqueaker(a)gmail.com> wrote: >>>>>> >>>>>> Smalltalk is a SystemDictionary, which is-a Dictionary. This suggests >>>>>> Smalltalk's main responsibility is mapping the list of global names to >>>>>> their global objects, and providing access to them by direct >>>>>> reference. >>>>>> >>>>>> I don't understand why would want to commingle a bunch of utility >>>>>> methods in with this primary (global name mapping) responsibility..? >>>>>> >>>>>> What is the problem exactly? >>>>>> >>>>>> Also, I'm curious about Cuis compatibility; is this really realistic >>>>>> or important? Why is it important? This would seem to be a >>>>>> relatively superficial difference with Cuis and other Smalltalk's, so >>>>>> I hope we will base decisions on what we think is the "right thing" to >>>>>> do rather than compatibility with something else that might not >>>>>> matter.. >>>>>> >>>>>> >>>>>> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab(a)gmx.de> >>>>>> wrote: >>>>>>> >>>>>>> Folks - >>>>>>> >>>>>>> I was just trying to load some other code and once too many I got bitten >>>>>>> by >>>>>>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it >>>>>>> now. >>>>>>> The only question is which way. There are two alternatives which achieve >>>>>>> the >>>>>>> goal of "SmalltalkImage current == Smalltalk": >>>>>>> >>>>>>> 1) The Cuis variant: Move all the code back to SystemDictionary; >>>>>>> implement >>>>>>> SmalltalkImage current as ^Smalltalk. >>>>>>> >>>>>>> Pro: Compatible with Cuis. >>>>>>> Con: Lack of separation of concerns. >>>>>>> >>>>>>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >>>>>>> SmalltalkImage; add a 'globals' variable (populated by an instance of >>>>>>> SystemDictionary) and convert everything roughly like this: >>>>>>> >>>>>>> SmalltalkImage current globals: Smalltalk. >>>>>>> Smalltalk := SmalltalkImage current. >>>>>>> >>>>>>> Pro: Better separation of concerns. >>>>>>> Con: Different from Cuis. >>>>>>> >>>>>>> I really don't care which way we do it; all I want is to get out of the >>>>>>> mess >>>>>>> we've created by introducing "SmalltalkImage current". >>>>>>> >>>>>>> If you have an opinion, voice it, otherwise I'll just pick one. >>>>>>> >>>>>>> Cheers, >>>>>>> - Andreas >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> What if instead of writing (SmalltalkImage current) you would just say >>> (Smalltalk vm). >>> Would this be tolerably short ? >>> Would the compatibility layer be short enough ? >>> >>> Squeak 3.8: SystemDictionary>>vm ^ self >>> Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current >>> >>> I took a look, and except source code management, a majority of >>> SmalltalkImage methods are related to VM and command line. >>> We could as well move messages to SmalltalkVM and just let a >>> SmalltalkImage class current hook >>> But I don't think it is necessary. >>> >>> What do you think ? >>> >>> >> I think we should define a distinctive roles for these parts and make >> sure none of them overlap. >> 'vm' is for tuning/poking GC options/attributes and various >> interpreter specific stuff. >> 'system' is for poking with host system options/attributes >> 'image' is for poking with language-wide (global) stuff & utils >> >> then , for any behavior it would be clear, what entity is responsible >> for it, not like currently >> when you don't know what is better 'Smalltalk' or 'SmalltalkImage current' >> > > like this ? > > Smalltalk vm version > Smalltalk vm extraMemory > Smalltalk vm listLoadedModules > > But then: > Smalltalk vm allocationCount > or Smalltalk memory allocationCount ? > or Smalltalk gc allocationCount ? > > Smalltalk host windowSystem > Smalltalk host platformName > Smalltalk host osVersion > > Smalltalk commandLine vmPath. > Smalltalk commandLine imagePath. > Smalltalk commandLine documentPath. > Smalltalk commandLine optionNumber: 2. > Smalltalk commandLine options. > Smalltalk commandLine argumentNumber: 1. > Smalltalk commandLine arguments. > > Smalltalk sourceCode condenseChanges. > ... > > >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > Begin forwarded message: > From: Igor Stasenko <siguctua(a)gmail.com> > Date: March 2, 2010 10:35:22 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On 2 March 2010 23:20, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2010/3/2 Igor Stasenko <siguctua(a)gmail.com>: >>> On 2 March 2010 22:00, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> 2010/3/2 Andreas Raab <andreas.raab(a)gmx.de>: >>>>> On 3/2/2010 8:55 AM, Igor Stasenko wrote: >>>>>> >>>>>> If you remember previous discussion about this, i proposed to use >>>>>> Smalltalk, which having a 'globals' ivar , which is a SystemDictionary >>>>>> so, that Smalltalk>>at: x >>>>>> implemented as >>>>>> globals at: x >>>>>> >>>>>> then Smalltalk global is an instance of SmalltalkImage , equal to >>>>>> SmalltalkImage current. >>>>>> And SystemDictionary is just a dictionary without any extra utility >>>>>> methods. >>>>> >>>>> This is option #2 below. (Sorry I didn't recall your post; otherwise I >>>>> would've named it the Igor variant :-) >>>>> >>>>> Cheers, >>>>> - Andreas >>>>> >>>>>> On 2 March 2010 18:32, Chris Muller<asqueaker(a)gmail.com> wrote: >>>>>>> >>>>>>> Smalltalk is a SystemDictionary, which is-a Dictionary. This suggests >>>>>>> Smalltalk's main responsibility is mapping the list of global names to >>>>>>> their global objects, and providing access to them by direct >>>>>>> reference. >>>>>>> >>>>>>> I don't understand why would want to commingle a bunch of utility >>>>>>> methods in with this primary (global name mapping) responsibility..? >>>>>>> >>>>>>> What is the problem exactly? >>>>>>> >>>>>>> Also, I'm curious about Cuis compatibility; is this really realistic >>>>>>> or important? Why is it important? This would seem to be a >>>>>>> relatively superficial difference with Cuis and other Smalltalk's, so >>>>>>> I hope we will base decisions on what we think is the "right thing" to >>>>>>> do rather than compatibility with something else that might not >>>>>>> matter.. >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab(a)gmx.de> >>>>>>> wrote: >>>>>>>> >>>>>>>> Folks - >>>>>>>> >>>>>>>> I was just trying to load some other code and once too many I got bitten >>>>>>>> by >>>>>>>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it >>>>>>>> now. >>>>>>>> The only question is which way. There are two alternatives which achieve >>>>>>>> the >>>>>>>> goal of "SmalltalkImage current == Smalltalk": >>>>>>>> >>>>>>>> 1) The Cuis variant: Move all the code back to SystemDictionary; >>>>>>>> implement >>>>>>>> SmalltalkImage current as ^Smalltalk. >>>>>>>> >>>>>>>> Pro: Compatible with Cuis. >>>>>>>> Con: Lack of separation of concerns. >>>>>>>> >>>>>>>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >>>>>>>> SmalltalkImage; add a 'globals' variable (populated by an instance of >>>>>>>> SystemDictionary) and convert everything roughly like this: >>>>>>>> >>>>>>>> SmalltalkImage current globals: Smalltalk. >>>>>>>> Smalltalk := SmalltalkImage current. >>>>>>>> >>>>>>>> Pro: Better separation of concerns. >>>>>>>> Con: Different from Cuis. >>>>>>>> >>>>>>>> I really don't care which way we do it; all I want is to get out of the >>>>>>>> mess >>>>>>>> we've created by introducing "SmalltalkImage current". >>>>>>>> >>>>>>>> If you have an opinion, voice it, otherwise I'll just pick one. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> - Andreas >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> What if instead of writing (SmalltalkImage current) you would just say >>>> (Smalltalk vm). >>>> Would this be tolerably short ? >>>> Would the compatibility layer be short enough ? >>>> >>>> Squeak 3.8: SystemDictionary>>vm ^ self >>>> Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current >>>> >>>> I took a look, and except source code management, a majority of >>>> SmalltalkImage methods are related to VM and command line. >>>> We could as well move messages to SmalltalkVM and just let a >>>> SmalltalkImage class current hook >>>> But I don't think it is necessary. >>>> >>>> What do you think ? >>>> >>>> >>> I think we should define a distinctive roles for these parts and make >>> sure none of them overlap. >>> 'vm' is for tuning/poking GC options/attributes and various >>> interpreter specific stuff. >>> 'system' is for poking with host system options/attributes >>> 'image' is for poking with language-wide (global) stuff & utils >>> >>> then , for any behavior it would be clear, what entity is responsible >>> for it, not like currently >>> when you don't know what is better 'Smalltalk' or 'SmalltalkImage current' >>> >> >> like this ? >> > yes > >> Smalltalk vm version >> Smalltalk vm extraMemory >> Smalltalk vm listLoadedModules >> > i like it much. From this code its clear what it does! > >> But then: >> Smalltalk vm allocationCount >> or Smalltalk memory allocationCount ? >> or Smalltalk gc allocationCount ? >> > Depends to what level you need to decompose things: > vm includes interpreter, and gc. > >> Smalltalk host windowSystem >> Smalltalk host platformName >> Smalltalk host osVersion >> >> Smalltalk commandLine vmPath. >> Smalltalk commandLine imagePath. >> Smalltalk commandLine documentPath. >> Smalltalk commandLine optionNumber: 2. > > Smalltalk commandLine optionAt: 2. > >> Smalltalk commandLine options. >> Smalltalk commandLine argumentNumber: 1. >> Smalltalk commandLine arguments. >> >> Smalltalk sourceCode condenseChanges. >> ... >> >> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: March 2, 2010 10:44:16 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > > > On Tue, Mar 2, 2010 at 1:20 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/3/2 Igor Stasenko <siguctua(a)gmail.com>: > > On 2 March 2010 22:00, Nicolas Cellier > > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> 2010/3/2 Andreas Raab <andreas.raab(a)gmx.de>: > >>> On 3/2/2010 8:55 AM, Igor Stasenko wrote: > >>>> > >>>> If you remember previous discussion about this, i proposed to use > >>>> Smalltalk, which having a 'globals' ivar , which is a SystemDictionary > >>>> so, that Smalltalk>>at: x > >>>> implemented as > >>>> globals at: x > >>>> > >>>> then Smalltalk global is an instance of SmalltalkImage , equal to > >>>> SmalltalkImage current. > >>>> And SystemDictionary is just a dictionary without any extra utility > >>>> methods. > >>> > >>> This is option #2 below. (Sorry I didn't recall your post; otherwise I > >>> would've named it the Igor variant :-) > >>> > >>> Cheers, > >>> - Andreas > >>> > >>>> On 2 March 2010 18:32, Chris Muller<asqueaker(a)gmail.com> wrote: > >>>>> > >>>>> Smalltalk is a SystemDictionary, which is-a Dictionary. This suggests > >>>>> Smalltalk's main responsibility is mapping the list of global names to > >>>>> their global objects, and providing access to them by direct > >>>>> reference. > >>>>> > >>>>> I don't understand why would want to commingle a bunch of utility > >>>>> methods in with this primary (global name mapping) responsibility..? > >>>>> > >>>>> What is the problem exactly? > >>>>> > >>>>> Also, I'm curious about Cuis compatibility; is this really realistic > >>>>> or important? Why is it important? This would seem to be a > >>>>> relatively superficial difference with Cuis and other Smalltalk's, so > >>>>> I hope we will base decisions on what we think is the "right thing" to > >>>>> do rather than compatibility with something else that might not > >>>>> matter.. > >>>>> > >>>>> > >>>>> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab(a)gmx.de> > >>>>> wrote: > >>>>>> > >>>>>> Folks - > >>>>>> > >>>>>> I was just trying to load some other code and once too many I got bitten > >>>>>> by > >>>>>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it > >>>>>> now. > >>>>>> The only question is which way. There are two alternatives which achieve > >>>>>> the > >>>>>> goal of "SmalltalkImage current == Smalltalk": > >>>>>> > >>>>>> 1) The Cuis variant: Move all the code back to SystemDictionary; > >>>>>> implement > >>>>>> SmalltalkImage current as ^Smalltalk. > >>>>>> > >>>>>> Pro: Compatible with Cuis. > >>>>>> Con: Lack of separation of concerns. > >>>>>> > >>>>>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to > >>>>>> SmalltalkImage; add a 'globals' variable (populated by an instance of > >>>>>> SystemDictionary) and convert everything roughly like this: > >>>>>> > >>>>>> SmalltalkImage current globals: Smalltalk. > >>>>>> Smalltalk := SmalltalkImage current. > >>>>>> > >>>>>> Pro: Better separation of concerns. > >>>>>> Con: Different from Cuis. > >>>>>> > >>>>>> I really don't care which way we do it; all I want is to get out of the > >>>>>> mess > >>>>>> we've created by introducing "SmalltalkImage current". > >>>>>> > >>>>>> If you have an opinion, voice it, otherwise I'll just pick one. > >>>>>> > >>>>>> Cheers, > >>>>>> - Andreas > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> What if instead of writing (SmalltalkImage current) you would just say > >> (Smalltalk vm). > >> Would this be tolerably short ? > >> Would the compatibility layer be short enough ? > >> > >> Squeak 3.8: SystemDictionary>>vm ^ self > >> Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current > >> > >> I took a look, and except source code management, a majority of > >> SmalltalkImage methods are related to VM and command line. > >> We could as well move messages to SmalltalkVM and just let a > >> SmalltalkImage class current hook > >> But I don't think it is necessary. > >> > >> What do you think ? > >> > >> > > I think we should define a distinctive roles for these parts and make > > sure none of them overlap. > > 'vm' is for tuning/poking GC options/attributes and various > > interpreter specific stuff. > > 'system' is for poking with host system options/attributes > > 'image' is for poking with language-wide (global) stuff & utils > > > > then , for any behavior it would be clear, what entity is responsible > > for it, not like currently > > when you don't know what is better 'Smalltalk' or 'SmalltalkImage current' > > > > like this ? > > Smalltalk vm version > Smalltalk vm extraMemory > Smalltalk vm listLoadedModules > > But then: > Smalltalk vm allocationCount > or Smalltalk memory allocationCount ? > or Smalltalk gc allocationCount ? > > Smalltalk host windowSystem > Smalltalk host platformName > Smalltalk host osVersion > > Smalltalk commandLine vmPath. > Smalltalk commandLine imagePath. > Smalltalk commandLine documentPath. > Smalltalk commandLine optionNumber: 2. > Smalltalk commandLine options. > Smalltalk commandLine argumentNumber: 1. > Smalltalk commandLine arguments. > > Smalltalk sourceCode condenseChanges. > > This is very nice. So... > > Smalltalk query allImplementorsOf: #printOn: > Smalltalk query browseSendersOf: #ensure: > > ? > > ... > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > > > > Begin forwarded message: > From: keith <keith_hodges(a)yahoo.co.uk> > Date: March 2, 2010 10:48:34 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > >> >>> Smalltalk host windowSystem >>> Smalltalk host platformName >>> Smalltalk host osVersion >>> >>> Smalltalk commandLine vmPath. >>> Smalltalk commandLine imagePath. >>> Smalltalk commandLine documentPath. >>> Smalltalk commandLine optionNumber: 2. >> >> Smalltalk commandLine optionAt: 2. > > Not every protocol has to be implemented by a different class. > > I asked earlier about a name for the StartupManager. StartupManager would happily handle #commandLine and probably #host as well. > > Keith > > Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: March 2, 2010 7:04:45 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > You're precisely repeating all the reasons why I want it fixed :-) > > Cheers, > - Andreas > > On 3/1/2010 10:01 PM, Ronald Spengler wrote: >> Are there things we mean idiomatically by saying Smalltalk which we >> don't mean by saying SmalltalkImage? >> >> And why SmalltalkImage current? What does current really mean? Would >> you ever say SmalltalkImage lastWeek? Or SmalltalkImage aDate? Or >> SmalltalkImage obsolete? >> >> I don't have an opinion, I'm just confused. Isn't the image itself >> just Smalltalk? >> >> On Monday, March 1, 2010, Phil (list)<pbpublist(a)gmail.com> wrote: >>> On Mar 1, 2010, at 11:08 PM, Andreas Raab wrote: >>> >>> >>> Folks - >>> >>> I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk": >>> >>> 1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk. >>> >>> Pro: Compatible with Cuis. >>> Con: Lack of separation of concerns. >>> >>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this: >>> >>> SmalltalkImage current globals: Smalltalk. >>> Smalltalk := SmalltalkImage current. >>> >>> Pro: Better separation of concerns. >>> Con: Different from Cuis. >>> >>> I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current". >>> >>> If you have an opinion, voice it, otherwise I'll just pick one. >>> >>> >>> >>> Having dealt with this a few times getting some code running on Cuis, I'd prefer that Squeak/Cuis try to remain compatible in areas like this where there doesn't seem to be any compelling reason for them not to be. I have no preference whether it's Cuis moving to the Squeak approach or Squeak moving (back) to the Cuis approach though. >>> >>> >>> Cheers, >>> - Andreas >>> >>> >>> >>> Thanks, >>> Phil >>> >>> >> > > Begin forwarded message: > From: keith <keith_hodges(a)yahoo.co.uk> > Date: March 2, 2010 12:08:45 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > >>>> 1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk. > > Cuis didn't exactly move the code back to SystemDictionary, of course it never left in the first place. It is easier for Cuis to implement compatibility with "trunk" than it is for "trunk" to go back to the old way. > > How much code uses Smalltalk at: ? As soon as you put SmalltalkImage current into Smalltalk you have to make what was an "image utilities" class behave like a dictionary. > > You seem to be saying, we must have a single place to access this stuff called "Smalltalk". I think what really needs to happen is to factor things up nicely and logically so we know where to find things and can write compatible code. > > I propose as a starting point, that we design a scheme or convention that implements the "long hand" variant, and then when happy with this, implement the short hand versions. The most obvious long hand variant. > > self class environment "system globals" > self class environment image > self class environment navigation > self class environment sourceFiles > self class environment startupManager. > self class environment organization. > > For the shorter hand variants, personally I wouldn't mind these being implemented on Object, aka #systemNavigation. > > self systemEnvironment, self systemImage, self systemNavigation, self systemSourceFiles, self systemStartupManager, self systemOrganization > > but I think I would prefer an instance side implementation of #environment/#system/#smalltalk > > SmalltalkImage current would then become: > > self environment image / self smalltalk image. > > ok, it's not compatible, but its not a mess either. > > The compatibility I would fix temporarily with better code loading tools, or a dnu: on SystemDictionary. > > K. > > > > > > > Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: March 2, 2010 12:27:23 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > I like Keith proposition, and I think it's also urgent to read the > Newspeak ones before making any modification > > Nicolas > > 2010/3/2 keith <keith_hodges(a)yahoo.co.uk>: >> 1) The Cuis variant: Move all the code back to SystemDictionary; implement >> SmalltalkImage current as ^Smalltalk. >> >> Cuis didn't exactly move the code back to SystemDictionary, of course it >> never left in the first place. It is easier for Cuis to implement >> compatibility with "trunk" than it is for "trunk" to go back to the old way. >> How much code uses Smalltalk at: ? As soon as you put SmalltalkImage current >> into Smalltalk you have to make what was an "image utilities" class behave >> like a dictionary. >> You seem to be saying, we must have a single place to access this stuff >> called "Smalltalk". I think what really needs to happen is to factor things >> up nicely and logically so we know where to find things and can write >> compatible code. >> I propose as a starting point, that we design a scheme or convention that >> implements the "long hand" variant, and then when happy with this, implement >> the short hand versions. The most obvious long hand variant. >> self class environment "system globals" >> self class environment image >> self class environment navigation >> self class environment sourceFiles >> self class environment startupManager. >> self class environment organization. >> For the shorter hand variants, personally I wouldn't mind these being >> implemented on Object, aka #systemNavigation. >> self systemEnvironment, self systemImage, self systemNavigation, self >> systemSourceFiles, self systemStartupManager, self systemOrganization >> but I think I would prefer an instance side implementation of >> #environment/#system/#smalltalk >> SmalltalkImage current would then become: >> self environment image / self smalltalk image. >> ok, it's not compatible, but its not a mess either. >> The compatibility I would fix temporarily with better code loading tools, or >> a dnu: on SystemDictionary. >> K. >> >> >> >> >> >> >> >> >> > Begin forwarded message: > From: Michael Haupt <mhaupt(a)gmail.com> > Date: March 2, 2010 12:35:42 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Hi, > > On Tue, Mar 2, 2010 at 12:27 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> I like Keith proposition, and I think it's also urgent to read the >> Newspeak ones before making any modification > > I also generally like the idea of binding things via messages instead > of via global state, and the Newspeak pointer is just right in this > regard. > > But I believe we must not forget that Newspeak is extremely consequent > in that everything is late-bound; Smalltalk just isn't. (Newspeak even > late-binds super classes at object instantiation time.) > > Apart from that, Object is already rather cluttered. > > Some questions: > How appropriate would such a model be in Smalltalk? > Is there a scenario where "the image" would not be global state? (Hydra?) > > Note that I'm not totally opposed to these ideas, just skeptical. :-) > > Best, > > Michael > Begin forwarded message: > From: Igor Stasenko <siguctua(a)gmail.com> > Date: March 2, 2010 1:18:28 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On 2 March 2010 13:35, Michael Haupt <mhaupt(a)gmail.com> wrote: >> Hi, >> >> On Tue, Mar 2, 2010 at 12:27 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> I like Keith proposition, and I think it's also urgent to read the >>> Newspeak ones before making any modification >> >> I also generally like the idea of binding things via messages instead >> of via global state, and the Newspeak pointer is just right in this >> regard. >> >> But I believe we must not forget that Newspeak is extremely consequent >> in that everything is late-bound; Smalltalk just isn't. (Newspeak even >> late-binds super classes at object instantiation time.) >> >> Apart from that, Object is already rather cluttered. >> > then how about: > > thisContext environment "system globals" > thisContext image > thisContext navigation > thisContext sourceFiles > ... > ? > > >> Some questions: >> How appropriate would such a model be in Smalltalk? >> Is there a scenario where "the image" would not be global state? (Hydra?) >> > > It is. When you building things from scratch, using different object model, > experimenting etc it is important to keep your code and objects > isolated from usual object graph. > >> Note that I'm not totally opposed to these ideas, just skeptical. :-) >> >> Best, >> >> Michael >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > Begin forwarded message: > From: Michael Haupt <mhaupt(a)gmail.com> > Date: March 2, 2010 2:37:19 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Hi Igor, > > On Tue, Mar 2, 2010 at 1:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> Apart from that, Object is already rather cluttered. >>> >> then how about: >> >> thisContext environment "system globals" ... > > eh, in my opinion, that's even more awkward. Why should these things > be associated with a Context? Of all *classes*, Object would be the > appropriate place for such things, but see above. :-) > >>> Some questions: >>> How appropriate would such a model be in Smalltalk? >>> Is there a scenario where "the image" would not be global state? (Hydra?) >> >> It is. When you building things from scratch, using different object model, >> experimenting etc it is important to keep your code and objects >> isolated from usual object graph. > > Yes, I figured this would make sense. > > Best, > > Michael > Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: March 2, 2010 6:04:00 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > > > On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges(a)yahoo.co.uk> wrote: >>>> 1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk. > > Cuis didn't exactly move the code back to SystemDictionary, of course it never left in the first place. It is easier for Cuis to implement compatibility with "trunk" than it is for "trunk" to go back to the old way. > > How much code uses Smalltalk at: ? As soon as you put SmalltalkImage current into Smalltalk you have to make what was an "image utilities" class behave like a dictionary. > > You seem to be saying, we must have a single place to access this stuff called "Smalltalk". I think what really needs to happen is to factor things up nicely and logically so we know where to find things and can write compatible code. > > I propose as a starting point, that we design a scheme or convention that implements the "long hand" variant, and then when happy with this, implement the short hand versions. The most obvious long hand variant. > > self class environment "system globals" > self class environment image > self class environment navigation > self class environment sourceFiles > self class environment startupManager. > self class environment organization. > > > This doesn't make sense in a workspace where the notion of the current class is a weak one (current class is UndefinedObject for want of having no class at all). > > Why are global names worse than any of these? > > I think Smalltalk == System is a good approach. Making things verbose is a very poor direction. When a cluster of associated behaviours gets complex enough then by all means move it out to a class. So in VisualWorks the pairing of ObjectMemory and MemoryPolicy which allows inspection and tailoring of memory management makes sense. > > A Tools object for systemNavigation might make sense, but SystemNavigation is a poor name; long (SystemNavigation default being worse) and not very informative. BrowserQuery would be better. Browse would be better. > > The worst thing going on with things like SmalltalkImage current, SystemNavigation default and traits is the introduction of abstraction for its own sake. Abstraction is properly used to manage complexity. But for example, as others have pointed out, there is no other image than the current image and so SmalltalkImage current is merely verbiage. And yet SourceFiles is an obvious area which could use a lot more features (being able to load package sources without appending them to the sources file, or having two changes files, one for loaded packages, one for user modifications, etc). > > Another bad thing is not thinking about names. Names are extremely important for making sense of a system, most especially for new users. Finding a vivid short name is well worth extra effort. > > I'd love to see someone start a side project which comprised > - a minimal kernel image, capable of bootstrapping (so includes base class library, compiler, gui-less debugger/back-tracer, file system interface) > - a set of packages comprising loadable programming tools > - a refactoring engine and rules base for converting from the current Squeak dialects where the rules were renamings of things like "SystemNavigation default" into "Browse" > and which focussed on a new set of global names for the environment. The base class library would stay the same, but Smalltalk, SystemNavigation, SmalltalkImage etc would be up for grabs. > > I'd then love to see a university department divide a class into two and see how each set of students faired with each variant, each provided with otherwise identical introductory material that differed only in the names & organization of these system services classes. > > > For the shorter hand variants, personally I wouldn't mind these being implemented on Object, aka #systemNavigation. > > self systemEnvironment, self systemImage, self systemNavigation, self systemSourceFiles, self systemStartupManager, self systemOrganization > > but I think I would prefer an instance side implementation of #environment/#system/#smalltalk > > SmalltalkImage current would then become: > > self environment image / self smalltalk image. > > ok, it's not compatible, but its not a mess either. > > The compatibility I would fix temporarily with better code loading tools, or a dnu: on SystemDictionary. > > K. > > > > > > > > > > > Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: March 2, 2010 8:53:32 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On 3/2/2010 8:55 AM, Igor Stasenko wrote: >> If you remember previous discussion about this, i proposed to use >> Smalltalk, which having a 'globals' ivar , which is a SystemDictionary >> so, that Smalltalk>>at: x >> implemented as >> globals at: x >> >> then Smalltalk global is an instance of SmalltalkImage , equal to >> SmalltalkImage current. >> And SystemDictionary is just a dictionary without any extra utility methods. > > This is option #2 below. (Sorry I didn't recall your post; otherwise I would've named it the Igor variant :-) > > Cheers, > - Andreas > >> On 2 March 2010 18:32, Chris Muller<asqueaker(a)gmail.com> wrote: >>> Smalltalk is a SystemDictionary, which is-a Dictionary. This suggests >>> Smalltalk's main responsibility is mapping the list of global names to >>> their global objects, and providing access to them by direct >>> reference. >>> >>> I don't understand why would want to commingle a bunch of utility >>> methods in with this primary (global name mapping) responsibility..? >>> >>> What is the problem exactly? >>> >>> Also, I'm curious about Cuis compatibility; is this really realistic >>> or important? Why is it important? This would seem to be a >>> relatively superficial difference with Cuis and other Smalltalk's, so >>> I hope we will base decisions on what we think is the "right thing" to >>> do rather than compatibility with something else that might not >>> matter.. >>> >>> >>> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab(a)gmx.de> wrote: >>>> Folks - >>>> >>>> I was just trying to load some other code and once too many I got bitten by >>>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. >>>> The only question is which way. There are two alternatives which achieve the >>>> goal of "SmalltalkImage current == Smalltalk": >>>> >>>> 1) The Cuis variant: Move all the code back to SystemDictionary; implement >>>> SmalltalkImage current as ^Smalltalk. >>>> >>>> Pro: Compatible with Cuis. >>>> Con: Lack of separation of concerns. >>>> >>>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >>>> SmalltalkImage; add a 'globals' variable (populated by an instance of >>>> SystemDictionary) and convert everything roughly like this: >>>> >>>> SmalltalkImage current globals: Smalltalk. >>>> Smalltalk := SmalltalkImage current. >>>> >>>> Pro: Better separation of concerns. >>>> Con: Different from Cuis. >>>> >>>> I really don't care which way we do it; all I want is to get out of the mess >>>> we've created by introducing "SmalltalkImage current". >>>> >>>> If you have an opinion, voice it, otherwise I'll just pick one. >>>> >>>> Cheers, >>>> - Andreas >>>> >>>> >>> >>> >> >> >> > > Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: March 2, 2010 9:00:43 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 2010/3/2 Andreas Raab <andreas.raab(a)gmx.de>: >> On 3/2/2010 8:55 AM, Igor Stasenko wrote: >>> >>> If you remember previous discussion about this, i proposed to use >>> Smalltalk, which having a 'globals' ivar , which is a SystemDictionary >>> so, that Smalltalk>>at: x >>> implemented as >>> globals at: x >>> >>> then Smalltalk global is an instance of SmalltalkImage , equal to >>> SmalltalkImage current. >>> And SystemDictionary is just a dictionary without any extra utility >>> methods. >> >> This is option #2 below. (Sorry I didn't recall your post; otherwise I >> would've named it the Igor variant :-) >> >> Cheers, >> - Andreas >> >>> On 2 March 2010 18:32, Chris Muller<asqueaker(a)gmail.com> wrote: >>>> >>>> Smalltalk is a SystemDictionary, which is-a Dictionary. This suggests >>>> Smalltalk's main responsibility is mapping the list of global names to >>>> their global objects, and providing access to them by direct >>>> reference. >>>> >>>> I don't understand why would want to commingle a bunch of utility >>>> methods in with this primary (global name mapping) responsibility..? >>>> >>>> What is the problem exactly? >>>> >>>> Also, I'm curious about Cuis compatibility; is this really realistic >>>> or important? Why is it important? This would seem to be a >>>> relatively superficial difference with Cuis and other Smalltalk's, so >>>> I hope we will base decisions on what we think is the "right thing" to >>>> do rather than compatibility with something else that might not >>>> matter.. >>>> >>>> >>>> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab(a)gmx.de> >>>> wrote: >>>>> >>>>> Folks - >>>>> >>>>> I was just trying to load some other code and once too many I got bitten >>>>> by >>>>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it >>>>> now. >>>>> The only question is which way. There are two alternatives which achieve >>>>> the >>>>> goal of "SmalltalkImage current == Smalltalk": >>>>> >>>>> 1) The Cuis variant: Move all the code back to SystemDictionary; >>>>> implement >>>>> SmalltalkImage current as ^Smalltalk. >>>>> >>>>> Pro: Compatible with Cuis. >>>>> Con: Lack of separation of concerns. >>>>> >>>>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >>>>> SmalltalkImage; add a 'globals' variable (populated by an instance of >>>>> SystemDictionary) and convert everything roughly like this: >>>>> >>>>> SmalltalkImage current globals: Smalltalk. >>>>> Smalltalk := SmalltalkImage current. >>>>> >>>>> Pro: Better separation of concerns. >>>>> Con: Different from Cuis. >>>>> >>>>> I really don't care which way we do it; all I want is to get out of the >>>>> mess >>>>> we've created by introducing "SmalltalkImage current". >>>>> >>>>> If you have an opinion, voice it, otherwise I'll just pick one. >>>>> >>>>> Cheers, >>>>> - Andreas >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> > > What if instead of writing (SmalltalkImage current) you would just say > (Smalltalk vm). > Would this be tolerably short ? > Would the compatibility layer be short enough ? > > Squeak 3.8: SystemDictionary>>vm ^ self > Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current > > I took a look, and except source code management, a majority of > SmalltalkImage methods are related to VM and command line. > We could as well move messages to SmalltalkVM and just let a > SmalltalkImage class current hook > But I don't think it is necessary. > > What do you think ? > Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: March 2, 2010 9:03:51 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > 2010/3/2 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges(a)yahoo.co.uk> wrote: >>> >>> 1) The Cuis variant: Move all the code back to SystemDictionary; implement >>> SmalltalkImage current as ^Smalltalk. >>> >>> Cuis didn't exactly move the code back to SystemDictionary, of course it >>> never left in the first place. It is easier for Cuis to implement >>> compatibility with "trunk" than it is for "trunk" to go back to the old way. >>> How much code uses Smalltalk at: ? As soon as you put SmalltalkImage >>> current into Smalltalk you have to make what was an "image utilities" class >>> behave like a dictionary. >>> You seem to be saying, we must have a single place to access this stuff >>> called "Smalltalk". I think what really needs to happen is to factor things >>> up nicely and logically so we know where to find things and can write >>> compatible code. >>> I propose as a starting point, that we design a scheme or convention that >>> implements the "long hand" variant, and then when happy with this, implement >>> the short hand versions. The most obvious long hand variant. >>> self class environment "system globals" >>> self class environment image >>> self class environment navigation >>> self class environment sourceFiles >>> self class environment startupManager. >>> self class environment organization. >> >> This doesn't make sense in a workspace where the notion of the current class >> is a weak one (current class is UndefinedObject for want of having no class >> at all). >> Why are global names worse than any of these? >> I think Smalltalk == System is a good approach. Making things verbose is a >> very poor direction. When a cluster of associated behaviours gets complex >> enough then by all means move it out to a class. So in VisualWorks the >> pairing of ObjectMemory and MemoryPolicy which allows inspection and >> tailoring of memory management makes sense. >> A Tools object for systemNavigation might make sense, but SystemNavigation >> is a poor name; long (SystemNavigation default being worse) and not very >> informative. BrowserQuery would be better. Browse would be better. > > Maybe a SystemNavigation was introduced to handle the fact that there > were many different browsers... Or Morphic + MVC.... > Maybe some were thinking embedding a default + some alternatives in a > single image... > > (Browser browseAllCallsOn: #yourself) was just perfectly short :) > Or (Browser allCallsOn: #yourself) open/view/edit/browse/..., if we > really want to avoid pairing each message. > A pity that Browser itself failed to become the abstract factory which > SystemNavigation default is... > > >> The worst thing going on with things like SmalltalkImage current, >> SystemNavigation default and traits is the introduction of abstraction for >> its own sake. Abstraction is properly used to manage complexity. But for >> example, as others have pointed out, there is no other image than the >> current image and so SmalltalkImage current is merely verbiage. And yet >> SourceFiles is an obvious area which could use a lot more features (being >> able to load package sources without appending them to the sources file, or >> having two changes files, one for loaded packages, one for user >> modifications, etc). >> Another bad thing is not thinking about names. Names are extremely >> important for making sense of a system, most especially for new users. >> Finding a vivid short name is well worth extra effort. >> I'd love to see someone start a side project which comprised >> - a minimal kernel image, capable of bootstrapping (so includes base class >> library, compiler, gui-less debugger/back-tracer, file system interface) >> - a set of packages comprising loadable programming tools >> - a refactoring engine and rules base for converting from the current Squeak >> dialects where the rules were renamings of things like "SystemNavigation >> default" into "Browse" >> and which focussed on a new set of global names for the environment. The >> base class library would stay the same, but Smalltalk, SystemNavigation, >> SmalltalkImage etc would be up for grabs. >> I'd then love to see a university department divide a class into two and see >> how each set of students faired with each variant, each provided with >> otherwise identical introductory material that differed only in the names & >> organization of these system services classes. >> >>> >>> For the shorter hand variants, personally I wouldn't mind these being >>> implemented on Object, aka #systemNavigation. >>> self systemEnvironment, self systemImage, self systemNavigation, self >>> systemSourceFiles, self systemStartupManager, self systemOrganization >>> but I think I would prefer an instance side implementation of >>> #environment/#system/#smalltalk >>> SmalltalkImage current would then become: >>> self environment image / self smalltalk image. >>> ok, it's not compatible, but its not a mess either. >>> The compatibility I would fix temporarily with better code loading tools, >>> or a dnu: on SystemDictionary. >>> K. >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > Begin forwarded message: > From: Igor Stasenko <siguctua(a)gmail.com> > Date: March 2, 2010 9:07:10 PM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] Re: SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On 2 March 2010 22:00, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2010/3/2 Andreas Raab <andreas.raab(a)gmx.de>: >>> On 3/2/2010 8:55 AM, Igor Stasenko wrote: >>>> >>>> If you remember previous discussion about this, i proposed to use >>>> Smalltalk, which having a 'globals' ivar , which is a SystemDictionary >>>> so, that Smalltalk>>at: x >>>> implemented as >>>> globals at: x >>>> >>>> then Smalltalk global is an instance of SmalltalkImage , equal to >>>> SmalltalkImage current. >>>> And SystemDictionary is just a dictionary without any extra utility >>>> methods. >>> >>> This is option #2 below. (Sorry I didn't recall your post; otherwise I >>> would've named it the Igor variant :-) >>> >>> Cheers, >>> - Andreas >>> >>>> On 2 March 2010 18:32, Chris Muller<asqueaker(a)gmail.com> wrote: >>>>> >>>>> Smalltalk is a SystemDictionary, which is-a Dictionary. This suggests >>>>> Smalltalk's main responsibility is mapping the list of global names to >>>>> their global objects, and providing access to them by direct >>>>> reference. >>>>> >>>>> I don't understand why would want to commingle a bunch of utility >>>>> methods in with this primary (global name mapping) responsibility..? >>>>> >>>>> What is the problem exactly? >>>>> >>>>> Also, I'm curious about Cuis compatibility; is this really realistic >>>>> or important? Why is it important? This would seem to be a >>>>> relatively superficial difference with Cuis and other Smalltalk's, so >>>>> I hope we will base decisions on what we think is the "right thing" to >>>>> do rather than compatibility with something else that might not >>>>> matter.. >>>>> >>>>> >>>>> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab(a)gmx.de> >>>>> wrote: >>>>>> >>>>>> Folks - >>>>>> >>>>>> I was just trying to load some other code and once too many I got bitten >>>>>> by >>>>>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it >>>>>> now. >>>>>> The only question is which way. There are two alternatives which achieve >>>>>> the >>>>>> goal of "SmalltalkImage current == Smalltalk": >>>>>> >>>>>> 1) The Cuis variant: Move all the code back to SystemDictionary; >>>>>> implement >>>>>> SmalltalkImage current as ^Smalltalk. >>>>>> >>>>>> Pro: Compatible with Cuis. >>>>>> Con: Lack of separation of concerns. >>>>>> >>>>>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to >>>>>> SmalltalkImage; add a 'globals' variable (populated by an instance of >>>>>> SystemDictionary) and convert everything roughly like this: >>>>>> >>>>>> SmalltalkImage current globals: Smalltalk. >>>>>> Smalltalk := SmalltalkImage current. >>>>>> >>>>>> Pro: Better separation of concerns. >>>>>> Con: Different from Cuis. >>>>>> >>>>>> I really don't care which way we do it; all I want is to get out of the >>>>>> mess >>>>>> we've created by introducing "SmalltalkImage current". >>>>>> >>>>>> If you have an opinion, voice it, otherwise I'll just pick one. >>>>>> >>>>>> Cheers, >>>>>> - Andreas >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> What if instead of writing (SmalltalkImage current) you would just say >> (Smalltalk vm). >> Would this be tolerably short ? >> Would the compatibility layer be short enough ? >> >> Squeak 3.8: SystemDictionary>>vm ^ self >> Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current >> >> I took a look, and except source code management, a majority of >> SmalltalkImage methods are related to VM and command line. >> We could as well move messages to SmalltalkVM and just let a >> SmalltalkImage class current hook >> But I don't think it is necessary. >> >> What do you think ? >> >> > I think we should define a distinctive roles for these parts and make > sure none of them overlap. > 'vm' is for tuning/poking GC options/attributes and various > interpreter specific stuff. > 'system' is for poking with host system options/attributes > 'image' is for poking with language-wide (global) stuff & utils > > then , for any behavior it would be clear, what entity is responsible > for it, not like currently > when you don't know what is better 'Smalltalk' or 'SmalltalkImage current' > > -- > Best regards, > Igor Stasenko AKA sig. > Begin forwarded message: > From: Ronald Spengler <ron.spengler(a)gmail.com> > Date: March 2, 2010 7:01:47 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Are there things we mean idiomatically by saying Smalltalk which we > don't mean by saying SmalltalkImage? > > And why SmalltalkImage current? What does current really mean? Would > you ever say SmalltalkImage lastWeek? Or SmalltalkImage aDate? Or > SmalltalkImage obsolete? > > I don't have an opinion, I'm just confused. Isn't the image itself > just Smalltalk? > > On Monday, March 1, 2010, Phil (list) <pbpublist(a)gmail.com> wrote: >> On Mar 1, 2010, at 11:08 PM, Andreas Raab wrote: >> >> >> Folks - >> >> I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk": >> >> 1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk. >> >> Pro: Compatible with Cuis. >> Con: Lack of separation of concerns. >> >> 2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this: >> >> SmalltalkImage current globals: Smalltalk. >> Smalltalk := SmalltalkImage current. >> >> Pro: Better separation of concerns. >> Con: Different from Cuis. >> >> I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current". >> >> If you have an opinion, voice it, otherwise I'll just pick one. >> >> >> >> Having dealt with this a few times getting some code running on Cuis, I'd prefer that Squeak/Cuis try to remain compatible in areas like this where there doesn't seem to be any compelling reason for them not to be. I have no preference whether it's Cuis moving to the Squeak approach or Squeak moving (back) to the Cuis approach though. >> >> >> Cheers, >> - Andreas >> >> >> >> Thanks, >> Phil >> >> > > -- > Ron > Begin forwarded message: > From: Bert Freudenberg <bert(a)freudenbergs.de> > Date: March 2, 2010 8:21:53 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On 02.03.2010, at 05:08, Andreas Raab wrote: >> >> Folks - >> >> I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk": >> >> 1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk. >> >> Pro: Compatible with Cuis. >> Con: Lack of separation of concerns. >> >> 2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this: >> >> SmalltalkImage current globals: Smalltalk. >> Smalltalk := SmalltalkImage current. >> >> Pro: Better separation of concerns. >> Con: Different from Cuis. >> >> I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current". >> >> If you have an opinion, voice it, otherwise I'll just pick one. >> >> Cheers, >> - Andreas > > 1) +1 > 2) -0 > > - Bert - > > > Begin forwarded message: > From: "Phil (list)" <pbpublist(a)gmail.com> > Date: March 2, 2010 6:38:58 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [squeak-dev] SmalltalkImage current vs. Smalltalk > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > On Mar 1, 2010, at 11:08 PM, Andreas Raab wrote: > >> Folks - >> >> I was just trying to load some other code and once too many I got bitten by this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it now. The only question is which way. There are two alternatives which achieve the goal of "SmalltalkImage current == Smalltalk": >> >> 1) The Cuis variant: Move all the code back to SystemDictionary; implement SmalltalkImage current as ^Smalltalk. >> >> Pro: Compatible with Cuis. >> Con: Lack of separation of concerns. >> >> 2) The inverse Cuis variant: Move all the code from SystemDictionary to SmalltalkImage; add a 'globals' variable (populated by an instance of SystemDictionary) and convert everything roughly like this: >> >> SmalltalkImage current globals: Smalltalk. >> Smalltalk := SmalltalkImage current. >> >> Pro: Better separation of concerns. >> Con: Different from Cuis. >> >> I really don't care which way we do it; all I want is to get out of the mess we've created by introducing "SmalltalkImage current". >> >> If you have an opinion, voice it, otherwise I'll just pick one. >> > > Having dealt with this a few times getting some code running on Cuis, I'd prefer that Squeak/Cuis try to remain compatible in areas like this where there doesn't seem to be any compelling reason for them not to be. I have no preference whether it's Cuis moving to the Squeak approach or Squeak moving (back) to the Cuis approach though. > >> Cheers, >> - Andreas >> > > Thanks, > Phil >

3 7

March 3, 2010

11242 ----- - Issue 2102: Fix the fact that local temp can shadow silently instance var --- reverted for now jorge I would appreciate a bit of your knowledge on this one :) Stef

1 0

March 3, 2010

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

3 5