December 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Old smalltalker is slightly lost

by Sean P. DeNigris

>From KasperOsterbye: > > This post has NOT been accepted by the mailing list yet. > 15 years ago I did a lot in Smalltalk, and have done some recreational > meta programming along the way. However, I now wanted to do something > where I was in need of drawing a diagram with x and y axes on what I > presume might be called a Canvas. > > I lack a simple tutorial to get me started. I have looked at many, but > they seem to presume I want to draw on the world "openInWorld". I should > like not to scatter my world with line fragments and points, but keep it > inside a "normal" window with borders, a background color (i.e. not a see > through window). > I have gone dead in two approaches. > > First attempt is to use a SystemWindow, and then draw on the canvas I > presume is there somewhere. I have just not been able to figure out how to > find the canvas of that SystemWindow, nor what method presumeable does the > painting. > > Second attempt is to use a SystemWindow, and then add (addMorph:) line and > circle morphs for my diagram. But it seems something is missing in my > understanding there as well. > > While it is fun that I can open circles and other stuff in "world", it is > not what I need. > > Small hits or direct solutions more than welcome. > > -- Kasper > -- View this message in context: http://forum.world.st/Old-smalltalker-is-slightly-lost-tp4191432p4191432.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2011

[Pharo-project] Old smalltalker is slightly lost

by KasperOsterbye

15 years ago I did a lot in Smalltalk, and have done some recreational meta programming along the way. However, I now wanted to do something where I was in need of drawing a diagram with x and y axes on what I presume might be called a Canvas. I lack a simple tutorial to get me started. I have looked at many, but they seem to presume I want to draw on the world "openInWorld". I should like not to scatter my world with line fragments and points, but keep it inside a "normal" window with borders, a background color (i.e. not a see through window). I have gone dead in two approaches. First attempt is to use a SystemWindow, and then draw on the canvas I presume is there somewhere. I have just not been able to figure out how to find the canvas of that SystemWindow, nor what method presumeable does the painting. Second attempt is to use a SystemWindow, and then add (addMorph:) line and circle morphs for my diagram. But it seems something is missing in my understanding there as well. While it is fun that I can open circles and other stuff in "world", it is not what I need. Small hits or direct solutions more than welcome. -- Kasper -- View this message in context: http://forum.world.st/Old-smalltalker-is-slightly-lost-tp4191137p4191137.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2011

Re: [Pharo-project] Startup Preferences

by Camillo Bruni

Cool, For me the default config dir is still in "~/.pharo/" so that would be cool if added... cami On 2011-12-13, at 11:37, Benjamin wrote: > New version: > > Now there is a hierarchy for the setting file > > - first it lloks in the image diretory for st files > - if none is found, it looks into > ~/.config/pharo/${VERSION} > - if none is found it looks into > ~/.config/pharo/general > > We could also add a look into > ~/.pharo/ > > > > Gofer new > squeaksource: 'StartupPreferences'; > package: 'StartupPreferences'; > load. > > Ben > > On Dec 1, 2011, at 6:50 PM, StÃ©phane Ducasse wrote: > >> me too. >> >> Stef >> >> On Dec 1, 2011, at 6:38 PM, Camillo Bruni wrote: >> >>> Yeah I would really love to see this. >>> >>> maybe with a fixed lookup chain >>> >>> 1. Settings from the Image directory/startup.st >>> 2. Settings from ~/.pharo/$VERSION/startup.st >>> 3. Settings from ~/.pharo/startup.st >>> >>> cami >>> >> >> >

Dec. 13, 2011

[Pharo-project] hasPoolVarNamed: semantics :(

by StÃ©phane Ducasse

Hi guys Class>>hasPoolVarNamed: aString "Return whether the receiver has a pool variable named: aString" self hasSharedPools ifTrue: [ self sharedPools do: [:each | (each usesClassVarNamed: aString) ifTrue: [ ^true ]]] ifFalse: [ ^false ]. ^false So this means to me that a subclass of a shared pools user does not inherit the fact that its superclass effectively use a sharedPool. I would prefer that this would be the inverse. self assert: (RootClassPoolUser hasPoolVarNamed: 'Author'). "a subclass " self assert: (SubclassPoolUser hasPoolVarNamed: 'Author'). What do you think? may be we should rename it hasLocalPoolvarNamed: especially since we have usesPoolVarNamed: which takes into account the hierarchy only when the class starts to use a shared pool (oh boy) and is bogus (I wrote probably that code of course without tests. Now I have them.). Class>>usesPoolVarNamed: aString "Return whether the receiver has a pool variable named: aString" self hasSharedPools ifTrue: [ self allSharedPools do: [:each | (each usesClassVarNamed: aString) ifTrue: [^true]]] ifFalse: [^false]. ^false I wrote it now with tests as follows: Class>>usesPoolVarNamed: aString "Return whether the receiver has a pool variable named: aString" self allSharedPools do: [:each | (each usesClassVarNamed: aString) ifTrue: [^true]]. ^ false Stef

Dec. 13, 2011

Re: [Pharo-project] Startup Preferences

by Benjamin

On Dec 13, 2011, at 2:51 PM, Sean P. DeNigris wrote: > > Benjamin Van Ryseghem-2 wrote >> >> - first it lloks in the image diretory for st files >> > > Any .st file (not good) or just startup.st? right now it's any, but easily good be changed ;) Ben > > -- > View this message in context: http://forum.world.st/Startup-Preferences-tp4129591p4190520.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 13, 2011

[Pharo-project] allSharedPools

by StÃ©phane Ducasse

This is a pity that allSharedPools does not return an ordered unique collection. Class>>allSharedPools "Answer a Set of the pools the receiver shares, including those defined in the superclasses of the receiver." | aSet | ^self superclass == nil ifTrue: [self sharedPools copy] ifFalse: [aSet := self superclass allSharedPools. aSet addAll: self sharedPools. aSet] since sharedPools returns now an orderedCollection I doubt that the uniqueness will the guaranteed. Behavior>>allSharedPools "Answer a Set of the names of the pools (Dictionaries or SharedPool subclasses) that the receiver and the receiver's ancestors share." ^superclass allSharedPools Now on a metaclass we will climb up the inheritance chain for nothing so I would define allSharedPools as follows ClassDescription>>allSharedPools "Answer a Set of the pools the receiver shares, including those defined in the superclasses of the receiver." ^ OrderedCollection new Tell me what you think? Stef

Dec. 13, 2011

[Pharo-project] sharedPools

by StÃ©phane Ducasse

Hi guys I would like to see how we can clean the protocols. Behavior>>sharedPools "Answer a Set of the names of the pools (Dictionaries) that the receiver shares. 9/12/96 tk sharedPools have an order now" ^ OrderedCollection new => I will update the comment (this is not a set nor with names!) => I would like to move down to classDescription such methods because all the other methods are defined there or in Class. Class>>sharedPools "Answer a Set of the pool dictionaries declared in the receiver." sharedPools == nil ifTrue: [^OrderedCollection new] ifFalse: [^sharedPools] => I will update the comment TraitBehavior>>sharedPools ^ Dictionary new oops! I would be good to have polymorphic results! I will return ^ OrderedCollection new Now I'm not sure if it makes sense (but this is probably better) that RBClass returns also a polymorphic results. I have the impression that we get an orderedCollection too. RBClass>>sharedPools ^ self allPoolDictionaryNames collect: [ :each | Smalltalk globals at: each asSymbol ifAbsent: [ Dictionary new ] ] Ring seems to miss sharedPools. Stef

Dec. 13, 2011

[Pharo-project] Message cascades: can they be always transformed into a sequence?

by Stefan Marr

Hi: I got a little problem with message cascades, and since I already missed a few details the first time, I wonder whether I am overlooking something now again. My question is, whether it is always possible to flatten a cascade into a surrounding sequence of statements (method/block). I am introducing temporary variables for that, and am wonder whether there could be anything I am overlooking with respect to the evaluation order. Thus, are there constructs where I would change evaluation order by pulling out normal sends and put the results into temporary variables? I obviously need to make sure that if I flatten them, that I order receivers and arguments correctly. Is there anything else that could hinder flattening? (Ah, and I am happy to ignore reflection, thisContext, or exceptions.) Here two examples: ---> original: testCascadedSends | assoc | assoc := Association key: #foo value: 0. assoc value: (1 + 2); value: assoc value + 2; value: assoc value + 5. self assert: 10 equals: assoc value. testCascadedNotInSequence | assoc | assoc := Association key: #foo value: 0. assoc value: (assoc value: 1; value: 2; yourself). self assert: assoc equals: assoc value. <--- ---> transformed: testCascadedSends | assoc t* | assoc := Association key: #foo value: 0. assoc value: (1 + 2). t1 := assoc value. assoc value: t1 + 2. t2 := assoc value. assoc value: t2 + 5. self assert: 10 equals: assoc value. testCascadedNotInSequence | assoc t* | assoc := Association key: #foo value: 0. assoc value: 1. assoc value: 2. t1 := yourself. assoc value: t1. self assert: assoc equals: assoc value. <--- Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Dec. 13, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by Schwab,Wilhelm K

Henry, Of course the old data do no know how to turn themselves into the current format. But they do/should carry with them version information (can be as simple as an integer bumped with each change); the system uses that to tell which incremental reshapes to apply. It works like a charm. Putting the conversion methods in the deserializer is _possible_, but it becomes a huge mess over time, risks collisions, complicates packaging for everything that uses it, and the code is FAR better placed in the classes that are changing over time. The latter becomes really obvious when one starts to use proxies. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] Sent: Tuesday, December 13, 2011 5:55 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cleaning up SmartRefStream use On 11.12.2011 19:50, Schwab,Wilhelm K wrote: When I last looked at SmartReferenceStream, it did two things that were bad: (2) reshape code was placed in SRS itself, not in the class that is changing shape. The thing that is being deserialized (which is when problems become apparent) should be in charge of the change. It simplifies both packaging (fewer loose methods to consider, and reduced opportunity for name collisions) and it also helps with using proxies for special circumstances. I'm not sure I understand/agree with what you are saying. What has been serialized is (almost) always an older version than what you are loading into, in which case I can't really see how it can answer the question "How do I turn into the current version?" correctly. Maybe there needs to be a split? Serialized version knows how to install itself as older versions (incase that's what you load into), while the image takes care if version in memory is newer than serialized? TBH, I also feel it's better to put the "import old versions" functionality as methods on the class itself rather than have an omnipotent materializer with special methods for installing all versions of all known classes in the system, I mean, exactly in the serializer/materializer do you intend to put such logic for custom user classes? Cheers, Henry

Dec. 13, 2011

Re: [Pharo-project] Startup Preferences

by Esteban Lorenzano

I wouldn't look in much places, that ambiguity is bad in the mid term... I would look just on ~/.pharo (the "config" name is bad: too generic) Cheers, Esteban El 13/12/2011, a las 11:21a.m., Sven Van Caekenberghe escribiÃ³: > > On 13 Dec 2011, at 11:37, Benjamin wrote: > >> Now there is a hierarchy for the setting file >> >> - first it lloks in the image diretory for st files >> - if none is found, it looks into >> ~/.config/pharo/${VERSION} >> - if none is found it looks into >> ~/.config/pharo/general >> >> We could also add a look into >> ~/.pharo/ > > Will looking in a lot of places not slow down the startup ? >

Dec. 13, 2011