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

Re: [Pharo-project] [Metacello] Best strategy for ConfigurationOfPharo using #stable

by Mariano Martinez Peck

So.... I will add versionString: #stable To all confs directly used by ConfigurationOfPharo. But that's not enough. I should do the same to each of them...and the whole tree...shouldn't I ? Maybe if we set up this, hudson can load the latest baseline instead of #lastVersion as it is doing now... Cheers On Fri, Apr 29, 2011 at 8:34 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > On 04/29/2011 10:10 AM, StÃ©phane Ducasse wrote: > >> dale >> >> My rule of thumb for a literal version spec is that you should >>>> use the #stable symbolic version if the project is loosely >>>> coupled to your project and a specific version otherwise. >>>> OmniBrowser tends to be loosely coupled as you are interested in >>>> getting any old version of OmniBrowser as long as it functions on >>>> the platform. >>>> >>> >>> The rule of thumb for a baseline version spec is to use #stable for >>> all projects (as long as the #stable version is defined), even >>> "tightly coupled" projects. When the baseline version is loaded, >>> you normally don't want to load the "latest code" or all of the >>> projects that you depend upon. >>> >>> The #bleedingEdge symbolic version should be used only when the >>> referenced project is part of your project family. >>> >>> When I load the baseline version for Seaside30, >>> >> >> when you say that "load the baseline": do you mean that you will get >> all the latest versions of the seaside packages? >> > > Yes, I load the baseline version of Seaside30, to pick up the most > recent checkins by the Seaside developers, so I can update the > configuration, port the changes, to GemStone and make a release. > > And when I do that, I don't want the latest OmniBrowser packages:) > > >> >> I want to load the #bleedingEdge versions of Grease, Kom, and >>> Swazoo, because they are part of the project family. I absolutely >>> don't want to load the latest OmniBrowser code, because who knows >>> what you'd get... >>> >>> So for the ConfigurationOfPharo, if you followed my rule of thumb, >>> you would create a baseline version and use the #stable version for >>> all of the projects in the baseline. In the literal version you >>> would use the explicit version, so that you'd have an explicit >>> repeatable specification for a set of projects that were known to >>> work together. >>> >> >> ok you mean that if people want the latest they load the baseline >> else they can just use a literal version and access it via #stable >> > > > I'm not sure what you mean here.... > > The pharo 1.2.2-baseline would include specs that look like this: > > spec > project: 'OB Dev' with: [ > spec > className: 'ConfigurationOfOmniBrowser'; > versionString: #stable; > ...]; > project: 'ScriptManager' with: [ > spec > className: 'ConfigurationOfScriptManager'; > versionString: #stable; > ...]; > project: 'Shout' with: [ > spec > className: 'ConfigurationOfShout'; > versionString: #stable; > ...]; > ....]. > > Loading Pharo 1.2.2-baseline would cause the #stable version for each of > those projects to be loaded ... but remember over time the #stable version > will change and incompatibilities between packages can creep in. By using > #stable versions you will be in better shape than using #bleedingEdge > because the #stable version is known to work. > > Pharo 1.2.2 (literal version) will have corresponding specs that look like > this: > > spec > project: 'OB Dev' with: '1.2.4'; > project: 'ScriptManager' with: '1.2'; > project: 'Shout' with: '1.2.2'; > ....]. > > So that you have driven a stake into the ground stating that these versions > are known to work together (have passed tests as a unit). 5 years in the > future, you will be able ot load Pharo 1.2.2 and get exactly the same > packages every time ... whereas the #stable versions may have drifted over > time ... > > If I am just bringing up a PharoCore1.2 image and I'd like to load the > Pharo dev code, I should load the #stable version of Pharo (which may be > 1.2.2 today and 1.2.3 tomorrow). > > If I want to duplicate the environment that someone is working in I will > ask them for th version of Pharo and load that explicit version to reproduce > the bug or whatever ... > > Dale > -- Mariano http://marianopeck.wordpress.com

May 1, 2011

Re: [Pharo-project] [Metacello] Best strategy for ConfigurationOfPharo using #stable

by Mariano Martinez Peck

> > Mariano, > > My rule of thumb for a literal version spec is that you should use the > #stable symbolic version if the project is loosely coupled to your project > and a specific version otherwise. OmniBrowser tends to be loosely coupled as > you are interested in getting any old version of OmniBrowser as long as it > functions on the platform. > > The rule of thumb for a baseline version spec is to use #stable for all > projects (as long as the #stable version is defined), even "tightly coupled" > projects. When the baseline version is loaded, you normally don't want to > load the "latest code" or all of the projects that you depend upon. > > The #bleedingEdge symbolic version should be used only when the referenced > project is part of your project family. > > When I load the baseline version for Seaside30, I want to load the > #bleedingEdge versions of Grease, Kom, and Swazoo, because they are part of > the project family. I absolutely don't want to load the latest OmniBrowser > code, because who knows what you'd get... > > So for the ConfigurationOfPharo, if you followed my rule of thumb, you > would create a baseline version and use the #stable version for all of the > projects in the baseline. In the literal version you would use the explicit > version, so that you'd have an explicit repeatable specification for a set > of projects that were known to work together. > Thanks Dale for the answer....Now, putting #stable in the versionString of a baseline make sense ONLY because the default is not #stable, isn't it ? I mean, if ConfigurationOfPharo >> baseline13: I am doing: project: 'OB Dev' with: [ spec className: 'ConfigurationOfOmniBrowser'; loads: #('Dev'); file: 'ConfigurationOfOmniBrowser'; repository: ' http://www.squeaksource.com/MetacelloRepository' ]; as you can see, in any baseline of ConfigurationOfPharo I set a version. Hence, if someone does ConfigurationOfPharo project version: '1.3-baseline', then Metacello will load the DEFAULT for 'ConfigurationOfOmniBrowser' which I guess it is not #stable becuase otherwise what you told me doesn't have sense. So, I guess it is #bleedingEdge? I think I have already asked this...sorry I couldn't find it in my gmail... > Developers interested in getting the "latest released version for all > projects" in ConfigurationOfPharo would load the baseline version and then > get the #stable version of all the projects for their platform ... each of > the projects was know to work by itself in an image (that's what the #stable > designation means), but the unknown is whether all of the projects work > together in image ... When you know that, you create a literal version of > ConfigurationOfPharo to commemorate that set of versions.... > > Without looking at the list of projects, it might still make sense to use > #stable in the literal version, but it would be the exception to the rule > ... > > Does this make sense to you? > > Totally :) > Dale > > -- Mariano http://marianopeck.wordpress.com

May 1, 2011

Re: [Pharo-project] I need help with 13380

by Mariano Martinez Peck

On Sun, May 1, 2011 at 10:17 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 1.3- 13380 latest update. > This cannot be possible. The latest PharoCore 1.3 seems to be 13179 So...I guess you tried to create 13180 and you confuse 13380 with 13180 ? cheers mariano > Now I think that this is because my vm has a bug with the refresh of the > screen. if I resize it the system > looks ok. > > Stef > > > On May 1, 2011, at 11:12 PM, Igor Stasenko wrote: > > > On 1 May 2011 22:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi guys > >> > >> I need help. > >> I do not know why the image is so slow at startup and also why I cannot > really bring an interrupt. > >> Tomorrow I'm traveling. So no time to look at that. > >> > > > > It would help to help you, if you elaborate, what 13380 means :) > > > >> Stef > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > > -- Mariano http://marianopeck.wordpress.com

May 1, 2011

Re: [Pharo-project] strange loop

by Igor Stasenko

On 1 May 2011 22:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 1, 2011, at 11:06 PM, Igor Stasenko wrote: > >> On 1 May 2011 21:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> this is strange >>> >>> I was trying to code a simple list of method browser and my browser seems to >>> >>> MorphExtension>>valueOfProperty: aSymbol >>> Â Â Â Â "answer the value of the receiver's property named aSymbol" >>> Â Â Â Â ^ extension ifNotNil: [extension valueOfProperty: aSymbol] >>> >> hmm.. i have different implementation here: >> >> valueOfProperty: aSymbol >> "answer the value of the receiver's property named aSymbol" >> Â Â Â ^ self >> Â Â Â Â Â Â Â valueOfProperty: aSymbol >> Â Â Â Â Â Â Â ifAbsent: [] >> >> and there is no 'extension' ivar in MorphExtension class. >> Or you changed something there? > > > Not that I know. > I was just in plain 13380 > [OT].. wow.. my image is already 300 updates behind.. What the ...! 300 updates. I mean 300. updates!!! And that is in scope of 1.3 development. :))) > >> >>> I end up in a endless loop >>> >>> update: aParameter >>> >>> Â Â Â Â |state| >>> Â Â Â Â aParameter Â ifNil: [^self]. >>> Â Â Â Â getLabelSelector ifNotNil: [ >>> Â Â Â Â Â Â Â Â aParameter == getLabelSelector ifTrue: [ >>> Â Â Â Â Â Â Â Â Â Â Â Â (self labelMorph respondsTo: #font) >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self label: (model perform: getLabelSelector) font: self labelMorph font] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self label: (model perform: getLabelSelector)]]]. >>> Â Â Â Â state := self getModelState. >>> Â Â Â Â (state ~= (self valueOfProperty: #lastState) or: [ >>> Â Â Â Â Â Â Â Â Â Â Â Â ^^^ >>> >>> when I inspect self I get a PluggableButtonMorph >>> but the method shown in the debugger is MoprhExtension?????? >>> >>> Â Â Â Â getStateSelector isNil and: [aParameter == #onOffColor]]) >>> Â Â Â Â Â Â Â Â ifTrue: [self color: self colorToUse. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self setProperty: #lastState toValue: state]. >>> Â Â Â Â aParameter == getEnabledSelector ifTrue: [^self enabled: (model perform: getEnabledSelector)]. >>> Â Â Â Â getColorSelector ifNotNil: [ | cc | >>> Â Â Â Â Â Â Â Â color = (cc := model perform: getColorSelector) >>> Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â color := cc. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self onColor: color offColor: color. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self changed ]]. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > -- Best regards, Igor Stasenko AKA sig.

May 1, 2011

Re: [Pharo-project] I need help with 13380

by Igor Stasenko

On 1 May 2011 22:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I need help. > I do not know why the image is so slow at startup and also why I cannot really bring an interrupt. > Tomorrow I'm traveling. So no time to look at that. > It would help to help you, if you elaborate, what 13380 means :) > Stef > -- Best regards, Igor Stasenko AKA sig.

May 1, 2011

Re: [Pharo-project] suspicion update: method in MorphExtension

by Igor Stasenko

Hey, where you got that? In my image ( Pharo1.3a Latest update: #13097 ) there is no such method (MorphExtension>>#update: ) at all. On 1 May 2011 21:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I have a problem with a PluggableButtonMorph and I end up in this > > MorpExtension>>update: aParameter > > Â Â Â Â |state| > Â Â Â Â aParameter Â ifNil: [^self]. > Â Â Â Â getLabelSelector ifNotNil: [ > Â Â Â Â Â Â Â Â aParameter == getLabelSelector ifTrue: [ > Â Â Â Â Â Â Â Â Â Â Â Â (self labelMorph respondsTo: #font) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self label: (model perform: getLabelSelector) font: self labelMorph font] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self label: (model perform: getLabelSelector)]]]. > Â Â Â Â state := self getModelState. > Â Â Â Â (state ~= (self valueOfProperty: #lastState) or: [ > Â Â Â Â getStateSelector isNil and: [aParameter == #onOffColor]]) > Â Â Â Â Â Â Â Â ifTrue: [self color: self colorToUse. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self setProperty: #lastState toValue: state]. > Â Â Â Â aParameter == getEnabledSelector ifTrue: [^self enabled: (model perform: getEnabledSelector)]. > Â Â Â Â getColorSelector ifNotNil: [ | cc | > Â Â Â Â Â Â Â Â color = (cc := model perform: getColorSelector) > Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â color := cc. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self onColor: color offColor: color. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self changed ]]. > > To me it looks suspicious that MorphExtension does that for all the morph.... > > Stef > -- Best regards, Igor Stasenko AKA sig.

May 1, 2011

Re: [Pharo-project] strange loop

by Igor Stasenko

On 1 May 2011 21:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > this is strange > > I was trying to code a simple list of method browser and my browser seems to > > MorphExtension>>valueOfProperty: aSymbol > Â Â Â Â "answer the value of the receiver's property named aSymbol" > Â Â Â Â ^ extension ifNotNil: [extension valueOfProperty: aSymbol] > hmm.. i have different implementation here: valueOfProperty: aSymbol "answer the value of the receiver's property named aSymbol" ^ self valueOfProperty: aSymbol ifAbsent: [] and there is no 'extension' ivar in MorphExtension class. Or you changed something there? > I end up in a endless loop > > update: aParameter > > Â Â Â Â |state| > Â Â Â Â aParameter Â ifNil: [^self]. > Â Â Â Â getLabelSelector ifNotNil: [ > Â Â Â Â Â Â Â Â aParameter == getLabelSelector ifTrue: [ > Â Â Â Â Â Â Â Â Â Â Â Â (self labelMorph respondsTo: #font) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [self label: (model perform: getLabelSelector) font: self labelMorph font] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [self label: (model perform: getLabelSelector)]]]. > Â Â Â Â state := self getModelState. > Â Â Â Â (state ~= (self valueOfProperty: #lastState) or: [ > Â Â Â Â Â Â Â Â Â Â Â Â ^^^ > > when I inspect self I get a PluggableButtonMorph > but the method shown in the debugger is MoprhExtension?????? > > Â Â Â Â getStateSelector isNil and: [aParameter == #onOffColor]]) > Â Â Â Â Â Â Â Â ifTrue: [self color: self colorToUse. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self setProperty: #lastState toValue: state]. > Â Â Â Â aParameter == getEnabledSelector ifTrue: [^self enabled: (model perform: getEnabledSelector)]. > Â Â Â Â getColorSelector ifNotNil: [ | cc | > Â Â Â Â Â Â Â Â color = (cc := model perform: getColorSelector) > Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â color := cc. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self onColor: color offColor: color. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self changed ]]. > -- Best regards, Igor Stasenko AKA sig.

May 1, 2011

Re: [Pharo-project] suspicion update: method in MorphExtension

by Markus Fritsche

Hi, > When you see things like that, please open a ticket :) been there, done that. Thanks for the pointer. I have my two smalltalk-weeks of the year, so please be patient with me if I come up with more of this sort... :-) Regards, Markus

May 1, 2011

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by GermÃ¡n Arduino

Thanks, a lot of news! 2011/5/1 Sven Van Caekenberghe <sven(a)beta9.be>: > Hi, > > It has been quite a while, but here is another progress report on the Zinc HTTP Components project. > > First of all, Zinc HTTP Components has found a new home: > > Â Â Â Â http://zn.stfx.eu > > and more importantly, it is now self hosted, i.e. the pages you see are served by Zn, and all testing and debugging handlers are now available live. For more information regarding this production quality deploy, please see > > Â Â Â Â http://zn.stfx.eu/#livedemo > > The documentation pages have been updated a bit to better reflect the current status of the project. > > Second, I thank all people who contributed by testing Zn, giving feedback as well as for some of them actual code. Thank you, CÃ©drick BÃ©ler, Philippe Marschall, Esteban Lorenzano, Jan van de Sandt, StÃ©phane Ducasse, Andy Burnett, Norbert Hartl, Paul DeBruicker, HernÃ¡n Morales Durand and Tony Fleig. (I hope I didn't forget anyone). Thanks Lukas Renggli and Marcus Denker for adding Zn to their continuous integration servers. > > Sven > > Here is a list of changes since January of this year: > > - introduction of ZnUrl class > - improved ZnStaticFileServerDelegate > - introduced #asZnMimeType on ZnMimeType, MIMEType & String > - Zinc-AWS proof of concept client > - added lots of comments > - several fixes to Zinc's Seaside adaptor, ZnZincServerAdaptor (encoding issues) > - split of ZnNetworkingUtils from ZnUtils to separate related functionality > - fixed ZnClient class>>#getImageOfType:usingParser:fromUrl: to correctly report responses with unexpected mime types > - promoted ZnFixedClient>>#fixedUrl: to public status and changed it to accept ZnUrl objects as well for more flexibility > Â (allowing users to add query/fragment URL elements in addition to the path) > - ZnUserAgent (and ZnHttpClient) now can follow relative redirect locations > - introduced ZnMultiValueDictionary to allow multiple values to be stored under one key as an array, > Â using it for queries and headers > - changed the redirect behavior for POST/PUT requests: the common practice is to turn these into GET request, > Â see ZnUserAgent>>#method:for:headers:data:imit: and ZnUserAgent>>#prepareRedirect: > - added simple ConfigurationOfZincHTTPComponents > - added ZnByteEncoder to handle single byte encodings that do not map directly to the lower Unicode section > Â (for example Latin2, ISO-8859-2) by reusing the mapping tables from ByteTextConverter > - added #handlesEncoding: and #newForEncoding: protocol to class side of ZnCharacterEncoding hierarchy > - added proper content length computation to ZnMultiPartFormDataEntity (bugfix) > - some code cleanup to ZnEntity content length computation > - added ZnUrl>>#queryDo: ZnApplicationForUrlEncodedEntity>>#fieldsDo: > - added ZnMessage>>#resetEntity: to allow overwriting content type and length when these are already set > - fixed a typo in the ZnMimePart instance creation methods (formdata should be form-data) > - added ZnResponse>>#serverError: > - implemented ZnHTTPSocketFacade class>>#httpPostMultipart:args:accept:request: > - added ZnHTTPSocketFacade class>>#constructMultiPartFormDataEntity: > - extended ZnZincServerAdaptor to handle multipart formdata posts (including file uploads) > - introducing exception hierarchy in Zinc-HTTP-Exceptions > - added ZnResponse>>#isNotModified > - bugfix to Base64 encoding that introduced newlines > - changed ZnZincServerAdaptor>>#defaultCodec to GRNullCodec > - added new logging framework in Zinc-HTTP-Logging, consisting of ZnLogEvent (an Announcment), > Â ZnLogSupport and ZnLogListener and subclasses ZnTranscriptLogger, ZnMemoryLogger and ZnFileLogger > - now using the new logging facilities in Zn[Single|Multi]ThreadedServer, ZnFixedClient and ZnUserAgent > - now using the new logging facilities in Zn[Single|Multi]ThreadedServer, ZnFixedClient and ZnUserAgent > - small fix to ZnUrl>>#printPathOn: to deal with cases where forward slashes are encoded in URLs > - various small changes related to the Gemstone port (byte array literals, Unicode creation) > - fixed an important bug related to reading entities upToEnd > > The latest version now is: > > Name: Zinc-HTTP-SvenVanCaekenberghe.150 > Author: SvenVanCaekenberghe > Time: 1 May 2011, 7:19:13 pm > UUID: 8fe0b470-7728-454d-bc90-fa42d8330817 > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.149 > > > >

May 1, 2011

Re: [Pharo-project] suspicion update: method in MorphExtension

by csrabak＠bol.com.br

Stef, Em 01/05/2011 16:20, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > Hi guys > I have a problem with a PluggableButtonMorph and I end up in this > MorpExtension>>update: aParameter It seems to me it has more than what you suspect. . . There are variables called "getLabelSelector, getStateSelector and getColorSelector" or are "self" missing there? All these tests with if<something> are also very _not_ OO :-| Also, I think my low understanding of Morph in general may be skewing my reasoning, but it seems to me that this method would get better if some knowledgeable person could comment the code! my 0.01999999 > > |state| > aParameter ifNil: [^self]. > getLabelSelector ifNotNil: [ > aParameter == getLabelSelector ifTrue: [ > (self labelMorph respondsTo: #font) > ifTrue: [self label: (model perform: getLabelSelector) font: self labelMorph font] > ifFalse: [self label: (model perform: getLabelSelector)]]]. > state := self getModelState. > (state ~= (self valueOfProperty: #lastState) or: [ > getStateSelector isNil and: [aParameter == #onOffColor]]) > ifTrue: [self color: self colorToUse. > self setProperty: #lastState toValue: state]. > aParameter == getEnabledSelector ifTrue: [^self enabled: (model perform: getEnabledSelector)]. > getColorSelector ifNotNil: [ | cc | > color = (cc := model perform: getColorSelector) > ifFalse: [ > color := cc. > self onColor: color offColor: color. > self changed ]]. > > To me it looks suspicious that MorphExtension does that for all the > morph.... > -- Cesar Rabak

May 1, 2011