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

Re: [Pharo-project] Semantic Versioning

by Dale Henrichs

Francois, Regarding the mutability of Metacello configurations ... you are right that it is tempting, but one should never modify a version that has been marked as #released ... it is a convention. One of the appeals of git/github is that a git commit is immutable so all of the artifacts in a commit are guaranteed. Even with git, tags (the only real place to use a version string) are not immutable ... by convention you don't change tags. In the end there is no replacement for discipline... Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde(a)gmail.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Monday, May 14, 2012 9:02:25 AM | Subject: Re: [Pharo-project] Semantic Versioning | | | > So if I fix | > a bug, and now Pharo 1.3 will have to load package.pharo13.3 and | > Squeak | > package.squeak43.5, I would declare 1.3.1 in my config with the new | > packages. Does that sound right? | | Yep, sounds right. | What if you only need the bug fix in the Pharo version and not the | Squeak one? The package becomes 1.3.1 in Squeak but is identical to | 1.3.0. No big deal I guess... | | My main concern at the moment is that a MetacelloConfig is always | modifiable. It is tempting to fix a version that is already | distributed | and thus confuse everyone. | | A release should maybe be a complete new entity (and not editable) | hosted somewhere else than in the code repository. The Fuel gsoc | would | probably help a lot for that. We can maybe imagine something Ã la | Ruby gems? | |

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Sean P. DeNigris

fstephany wrote > > What if you only need the bug fix in the Pharo version and not the > Squeak one? The package becomes 1.3.1 in Squeak but is identical to > 1.3.0. No big deal I guess... > Well, we're versioning the *project* i.e. the config, not the package, so I don't think there's a conflict. fstephany wrote > > My main concern at the moment is that a MetacelloConfig is always > modifiable. It is tempting to fix a version that is already distributed > and thus confuse everyone. > Yes, this would be a big problem and violates the spirit of Metacello. Just as bad is the fact that Metacello configs are copied all over the place. Is the ConfigurationOf that I download from SqS/projectName the same one as SqS/MetacelloRepository the same as SqS/WhateverForPharo1.4... IMO it's absolutely essential to have one master, and read-only copies everywhere elsewhere. fstephany wrote > > We can maybe imagine something Ã la Ruby gems? > That would be awesome!!! Metacello is sooo young and we've already had so much progress. I'm sure that won't be far off... -- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055p4630164.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

Sean P. DeNigris wrote > > [:barValArg | | barVal return newBarSize | > barVal := barValArg. > return := nil. > ... > "new fun stuff here" > barVal == #current ifTrue: [ return := barSize ]. > barVal == #label ifTrue:[ return := (labels at: slot) contents ]. > barVal == #setMax ifTrue: [ return := maxValue. maxValue := minValue ]. > barVal == #setMin ifTrue: [ return := minValue. minValue := maxValue ]. > barVal == #increment ifTrue: [return := barVal := barSize + 1]. > barVal == #decrement ifTrue: [ return := barVal := barSize - 1]. > (barVal isString and: [barVal isSymbol not]) ifTrue: [ > (labels at: slot) contents: barVal. > barVal := #refresh]. > barVal == #refresh ifTrue: [self currentWorld displayWorld. return := > true]. > ... > return] > I think we should consider this alternate Class implementation. A block with its own custom method lookup mechanism ;-) -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Francois Stephany

> So if I fix > a bug, and now Pharo 1.3 will have to load package.pharo13.3 and Squeak > package.squeak43.5, I would declare 1.3.1 in my config with the new > packages. Does that sound right? Yep, sounds right. What if you only need the bug fix in the Pharo version and not the Squeak one? The package becomes 1.3.1 in Squeak but is identical to 1.3.0. No big deal I guess... My main concern at the moment is that a MetacelloConfig is always modifiable. It is tempting to fix a version that is already distributed and thus confuse everyone. A release should maybe be a complete new entity (and not editable) hosted somewhere else than in the code repository. The Fuel gsoc would probably help a lot for that. We can maybe imagine something Ã la Ruby gems?

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Sean P. DeNigris

Philippe Marschall-2 wrote > > I don't think you'd be happy with the consequences. First you'd have to > define what is API which is hard because everything is public in > Smalltalk > Right, first you'd have to specify public packages/categories or individual classes (which would be helpful with of without semantic versioning. I sometimes find it difficult to know what classes I'm supposed to use in a library when private helper classes pollute the package/category). Then, any method there that's not in 'private' would be API. Philippe Marschall-2 wrote > > And then you have to live by it which means you have much > less freedom how you version things. > You'd have less freedom to choose the exact numbering, but that's the whole point! To agree on and stick to a system, losing a little control, but gaining clarity and usability (b.t.w. then Metacello could say "load this dependency version 2.x.x" and know that it'd get all the bug fixes but wouldn't break anything). -- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055p4630152.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Camillo Bruni

I know :D nice no? :D Specific class please!! It's specially nice when you want to inspect it and figure out on how to use it :/ On 2012-05-14, at 16:56, Sean P. DeNigris wrote: > Holy crap, SystemProgressMorph's "instance creation" method doesn't return an > instance at all but a block. I really wish I understood this design decision > before I try to cut all this out. Yikes, check out > SystemProgressMorph>>label:min:max: > > label: shortDescription min: startMinValue max: startMaxValue > "Answer the block that updates the progress bar." > > "some fun stuff added (by kph) > > - bar value: #label. - tell me my current label. > - bar value: 'newLabel'. - enable changing the label from within the > workBlock > - bar value: #increment. - enable progress by one without keeping a counter > - bar value: #decrement. - go backwards (if you really have to, useful for > an abort, or rollback)! > > - bar value: newBigNum. - change the max on the fly - when you find there > is more to do. > - bar value: (bar value: #setMax) + 20 - change the max on the fly - when > you find there is more/less to do. > - bar value: (bar value: #setMin) - 20 - change the min on the fly - not > sure why you would want to. > " > | slot range barSize lastRefresh maxValue minValue bar| > maxValue := startMaxValue. > minValue := startMinValue. > ((range := maxValue - minValue) <= 0 or: [(slot := self nextSlotFor: > shortDescription) = 0]) > ifTrue: [^[:barVal| 0 ]]. > self recenter. > self openInWorld. > barSize := -1. "Enforces a inital draw of the morph" > lastRefresh := Time millisecondClockValue. > bar := bars at: slot. > ^[:barValArg | | barVal return newBarSize | > barVal := barValArg. > return := nil. > bar := bars at: slot. > "new fun stuff here" > barVal == #current ifTrue: [ return := barSize ]. > barVal == #label ifTrue:[ return := (labels at: slot) contents ]. > barVal == #setMax ifTrue: [ return := maxValue. maxValue := minValue ]. > barVal == #setMin ifTrue: [ return := minValue. minValue := maxValue ]. > barVal == #increment ifTrue: [return := barVal := barSize + 1]. > barVal == #decrement ifTrue: [ return := barVal := barSize - 1]. > (barVal isString and: [barVal isSymbol not]) ifTrue: [ > (labels at: slot) contents: barVal. > barVal := #refresh]. > barVal == #refresh ifTrue: [self currentWorld displayWorld. return := > true]. > (barVal == SmallInteger maxVal or: [ barVal == #finished ]) ifTrue: > [return := slot]. > return ifNil: [ > barVal > maxValue ifTrue: [return := maxValue := barVal]. > barVal < minValue ifTrue: [return := minValue := barVal]. > (barVal between: minValue and: maxValue) > ifTrue: [newBarSize := (barVal - minValue / range * BarWidth) truncated. > newBarSize = barSize > ifFalse: [barSize := newBarSize. > (Time millisecondsSince: lastRefresh) > 25 > ifTrue: [barVal := #refresh ]]]. > barVal == #refresh ifTrue: [ > ((bar valueOfProperty: #useStripes) ifNil: [false]) > ifTrue: [bar fillStyle origin: bar position - ((Time > millisecondClockValue // 50 \\ 30) @ 0)]. > bar barSize: barSize. > self currentWorld displayWorld. > lastRefresh := Time millisecondClockValue]]. > return] > > -- > View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Sean P. DeNigris

fstephany wrote > > I'm wondering though how that can work in a multi dialects ecosystem Hmm... good point. I'm thinking this is handled by Metacello already. IOW, my project's Metacello version 1.3 means "these are the packages you load for 1.3 in all supported platforms, e.g. Pharo 1.3, Squeak 4.3". So if I fix a bug, and now Pharo 1.3 will have to load package.pharo13.3 and Squeak package.squeak43.5, I would declare 1.3.1 in my config with the new packages. Does that sound right? -- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055p4630150.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

Holy crap, SystemProgressMorph's "instance creation" method doesn't return an instance at all but a block. I really wish I understood this design decision before I try to cut all this out. Yikes, check out SystemProgressMorph>>label:min:max: label: shortDescription min: startMinValue max: startMaxValue "Answer the block that updates the progress bar." "some fun stuff added (by kph) - bar value: #label. - tell me my current label. - bar value: 'newLabel'. - enable changing the label from within the workBlock - bar value: #increment. - enable progress by one without keeping a counter - bar value: #decrement. - go backwards (if you really have to, useful for an abort, or rollback)! - bar value: newBigNum. - change the max on the fly - when you find there is more to do. - bar value: (bar value: #setMax) + 20 - change the max on the fly - when you find there is more/less to do. - bar value: (bar value: #setMin) - 20 - change the min on the fly - not sure why you would want to. " | slot range barSize lastRefresh maxValue minValue bar| maxValue := startMaxValue. minValue := startMinValue. ((range := maxValue - minValue) <= 0 or: [(slot := self nextSlotFor: shortDescription) = 0]) ifTrue: [^[:barVal| 0 ]]. self recenter. self openInWorld. barSize := -1. "Enforces a inital draw of the morph" lastRefresh := Time millisecondClockValue. bar := bars at: slot. ^[:barValArg | | barVal return newBarSize | barVal := barValArg. return := nil. bar := bars at: slot. "new fun stuff here" barVal == #current ifTrue: [ return := barSize ]. barVal == #label ifTrue:[ return := (labels at: slot) contents ]. barVal == #setMax ifTrue: [ return := maxValue. maxValue := minValue ]. barVal == #setMin ifTrue: [ return := minValue. minValue := maxValue ]. barVal == #increment ifTrue: [return := barVal := barSize + 1]. barVal == #decrement ifTrue: [ return := barVal := barSize - 1]. (barVal isString and: [barVal isSymbol not]) ifTrue: [ (labels at: slot) contents: barVal. barVal := #refresh]. barVal == #refresh ifTrue: [self currentWorld displayWorld. return := true]. (barVal == SmallInteger maxVal or: [ barVal == #finished ]) ifTrue: [return := slot]. return ifNil: [ barVal > maxValue ifTrue: [return := maxValue := barVal]. barVal < minValue ifTrue: [return := minValue := barVal]. (barVal between: minValue and: maxValue) ifTrue: [newBarSize := (barVal - minValue / range * BarWidth) truncated. newBarSize = barSize ifFalse: [barSize := newBarSize. (Time millisecondsSince: lastRefresh) > 25 ifTrue: [barVal := #refresh ]]]. barVal == #refresh ifTrue: [ ((bar valueOfProperty: #useStripes) ifNil: [false]) ifTrue: [bar fillStyle origin: bar position - ((Time millisecondClockValue // 50 \\ 30) @ 0)]. bar barSize: barSize. self currentWorld displayWorld. lastRefresh := Time millisecondClockValue]]. return] -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] bug on dictionary?

by Camillo Bruni

On 2012-05-14, at 16:22, Sven Van Caekenberghe wrote: > > On 14 May 2012, at 16:10, Camillo Bruni wrote: > >> maybe we should even start considering again replacing dict + set with something more >> standard that internally relies on buckets instead of associations. >> >> I've shown in my master thesis that the bucket implementation performs slightly better >> or the at least the same in various use-cases. > > Better implementations would always be welcome. > > For example, choosing between regular and small dictionary should be an automatic internal detail. - been there done that :P in our Pinocchio Dictionary we did that :) > Exposing associations as an implementation details is of course wrong. - exactly, they're a nice interface but that should be all > But one could keep the association concept at the API level and do a more intelligent implementation. > > But that doesn't change the value of the original issue: > > Dictionary>>#add: > > and > > Dictionary>>#addAll: > > do conflict in a certain sense. > > Sven

May 14, 2012

Re: [Pharo-project] bug on dictionary?

by Sven Van Caekenberghe

On 14 May 2012, at 16:10, Camillo Bruni wrote: > maybe we should even start considering again replacing dict + set with something more > standard that internally relies on buckets instead of associations. > > I've shown in my master thesis that the bucket implementation performs slightly better > or the at least the same in various use-cases. Better implementations would always be welcome. For example, choosing between regular and small dictionary should be an automatic internal detail. Exposing associations as an implementation details is of course wrong. But one could keep the association concept at the API level and do a more intelligent implementation. But that doesn't change the value of the original issue: Dictionary>>#add: and Dictionary>>#addAll: do conflict in a certain sense. Sven

May 14, 2012