- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Startup Preferences

by Tudor Girba

I would like to have it first look in the local folder :). For the global place, I also believe that there should be only one, and ~/.pharo sounds the best to my ears. Cheers, Doru On 13 Dec 2011, at 20:48, Benjamin wrote: > Guys, I am ok for any proposition but please try to find only one together :) > > some of you are for ~/.config/pharo/bla others for ~/.pharo/bla > > some of you are for multi location, other for only one. > > > Personally I am for ~/.pharo and for multi locations :) > > > Waiting for your arguments ;) > > > Ben > > > On Dec 13, 2011, at 5:57 PM, Camillo Bruni wrote: > >> 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 >>>>> >>>> >>>> >>> >> >> > > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Dec. 13, 2011

Re: [Pharo-project] hasPoolVarNamed: semantics :(

by Eliot Miranda

On Tue, Dec 13, 2011 at 2:04 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/12/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > I just came back to eater after 7 hours of train > > > > http://code.google.com/p/pharo/issues/detail?id=5101 > > > > Ah yes, you probably wrote original code after 15h of airplane and 8h > time difference ;) > > I wonder if SharedPool were inherited in original st-80 ? > Yes. But IIRC SharedPools were *not* inherited in pre-Namespace VisualWorks, and they don't exist in Namespaced VW. Here's the class variable lookup method in Smalltalk-80 V2: Behavior>scopeHas: varName ifTrue: assocBlock "Look up varName in this class, its superclasses, and Smalltalk. If it is there, pass the association to assocBlock, and answer true; else answer false." | assoc | self withAllSuperclasses do: [:sup | (sup poolHas: varName ifTrue: assocBlock) ifTrue: [^true]]. assoc _ Smalltalk associationAt: varName ifAbsent: []. assoc == nil ifFalse: [assocBlock value: assoc. ^true]. ^false > Nicolas > > > On Dec 13, 2011, at 10:33 PM, Sean P. DeNigris wrote: > > > >> > >> StÃ©phane Ducasse wrote > >>> > >>> What do you think? may be we should rename it > >>> hasLocalPoolvarNamed: > >>> > >> > >> That sounds clearer. #has vs. #uses is more subtle and potentially > >> confusing. > >> > >> -- > >> View this message in context: > http://forum.world.st/hasPoolVarNamed-semantics-tp4191675p4192155.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > > > > > > -- best, Eliot

Dec. 13, 2011

Re: [Pharo-project] hasPoolVarNamed: semantics :(

by Nicolas Cellier

2011/12/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I just came back to eater after 7 hours of train > > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5101 > Ah yes, you probably wrote original code after 15h of airplane and 8h time difference ;) I wonder if SharedPool were inherited in original st-80 ? Nicolas > On Dec 13, 2011, at 10:33 PM, Sean P. DeNigris wrote: > >> >> StÃ©phane Ducasse wrote >>> >>> What do you think? may be we should rename it >>> Â Â Â hasLocalPoolvarNamed: >>> >> >> That sounds clearer. #has vs. #uses is more subtle and potentially >> confusing. >> >> -- >> View this message in context: http://forum.world.st/hasPoolVarNamed-semantics-tp4191675p4192155.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

Dec. 13, 2011

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

by StÃ©phane Ducasse

> Stefan you should pay attention to what is the receiver of a cascade because this is really the receive of the first message involved in the cascade. OrderedCollection new add: 35; add: 45; yourself this is anOrderedCollection and not OrderedCollection but you probably know that. Stef > No. Cascades are simply a syntactic sugar for binding to a temporary, so > > expr message1; ...; messageN > > is syntactic sugar for > > | t | > ... > t := expr. > t message1. > ... > t messageN. > > The implementation simply creates an anonymous temporary on the stack and reads it using dup, effectively push expr, dup, send, dup, send, pop. > > > 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 > > > > > > -- > best, > Eliot >

Dec. 13, 2011

Re: [Pharo-project] Old smalltalker is slightly lost

by StÃ©phane Ducasse

Hi kasper Welcome :) I hope you are going well. Do you need interaction with the forms you will draw? Do you want to define your own interaction? Do you just want to draw on the canvas? to get a canvas Display getCanvas fillRectangle: (0@0 corner: 100@100) color: Color red Have a look at Canvas Api (it is vintage but works). We are about to release a new canvas to support vector graphics Stef On Dec 13, 2011, at 5:59 PM, KasperOsterbye wrote: > 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] allSharedPools

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=5101 check :) About the copy I do not know. > > > On Tue, Dec 13, 2011 at 5:01 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > 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. > > > > I have just tested, and of course, it includes duplicates. Why not a simply: > > 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]) asSet > > ? > > BTW, why it does a copy ? > > > 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 > > > I think it answers a list of SharedPool subclasses, not names. > > > 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 > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 13, 2011

Re: [Pharo-project] hasPoolVarNamed: semantics :(

by StÃ©phane Ducasse

I just came back to eater after 7 hours of train http://code.google.com/p/pharo/issues/detail?id=5101 On Dec 13, 2011, at 10:33 PM, Sean P. DeNigris wrote: > > StÃ©phane Ducasse wrote >> >> What do you think? may be we should rename it >> hasLocalPoolvarNamed: >> > > That sounds clearer. #has vs. #uses is more subtle and potentially > confusing. > > -- > View this message in context: http://forum.world.st/hasPoolVarNamed-semantics-tp4191675p4192155.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 13, 2011

Re: [Pharo-project] ZnUrl vs furl

by StÃ©phane Ducasse

Excellent now can you open an issue and provide add these examples in the ZnUrl class comment? Stef On Dec 13, 2011, at 2:23 PM, Sven Van Caekenberghe wrote: > I came across this: > > https://github.com/gruns/furl > > a small Python library that makes parsing and manipulating URLs simple. > > And this would be some equivalent manipulations using ZnUrl: > > | url | > url := 'http://www.google.com/?one=1&two=2' asZnUrl. > url queryAt: 'three' put: '3'. > url queryRemoveKey: 'one'. > url > > => > > http://www.google.com/?two=2&three=3 > > > | url | > url := 'http://www.google.com' asZnUrl. > url addPathSegment: 'some encoding here'. > url queryAt: 'and some encoding' put: 'here, too'. > url > > => > > http://www.google.com/some%20encoding%20here?and%20some%20encoding=here%2C%… > > So I guess our base Url object does not need an extra library to make manipulations easier. > > Sven > > >

Dec. 13, 2011

Re: [Pharo-project] hasPoolVarNamed: semantics :(

by Sean P. DeNigris

StÃ©phane Ducasse wrote > > What do you think? may be we should rename it > hasLocalPoolvarNamed: > That sounds clearer. #has vs. #uses is more subtle and potentially confusing. -- View this message in context: http://forum.world.st/hasPoolVarNamed-semantics-tp4191675p4192155.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2011

Re: [Pharo-project] Cleaning up SmartRefStream use

by Schwab,Wilhelm K

Henry, Sounds good :) 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 4:12 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cleaning up SmartRefStream use On 13.12.2011 15:35, Schwab,Wilhelm K wrote: 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 Then we agree on all points, I just misread what you'd written :) Cheers, Henry ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no<mailto:henrik.s.johansen@veloxit.no>] Sent: Tuesday, December 13, 2011 5:55 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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