November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] A thought about backporting

by StÃ©phane Ducasse

The point of noury is that it is better to have 2.0 and 2.1 and 2.2 and as few as possible and to have that as a public interface. After people can really pick a given version. Stef > You already have a complete list of the images here: > > http://files.pharo.org/image/20/ > http://files.pharo.org/image/30/ > > I don't think that the platform/oneclick builds should be the main deployment artifacts. > > I assume that if you have a decent project you will use a CI service to build your project, > which means you can easily fix the image version by using the links above. > > On 2013-11-14, at 21:12, Torsten Bergmann <astares(a)gmx.de> wrote: >> If a backport happens it can mean two things to a user: >> >> POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...) >> NEGATIV: a possible broken API introduced by a backport >> >> It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip" >> from http://files.pharo.org/platform directly after the "big announcement" and half year >> later (after backports happened) he may be surprised since it results in different images >> and may lead to problems. Not directly in the image but it can happen when loading other >> packages that could be broken by the backport. >> >> >> On one side we want a "reproducible" reliable version announced as "official release" at one point >> in time on the other hand we want to be able to backport fixes and make the experience better >> so Pharo 2.0 is not really fix. >> >> >> IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but >> for the artefacts (in the build folder) and on the download page we should provide the >> FULL VERSION: >> >> MAJOR.MINOR-BUILD >> >> As you know we already use this for our development: the build is our update number which is also >> easily reproducible (we have release mails like for 20627) and in the near future with projects >> like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/ >> it will be even easier to get a specific image version. >> >> >> So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we >> should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way >> people could spot the difference to old downloads more easily. >> >> One often see's download pages of open source projects stating "Download latest here" and >> "Download previous versions here" with a list of older releases. >> By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want. >> >> My proposal: lets use the update number more often. It would also help when people report bugs >> to know about the specific update number. >> >> It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the >> newer one with the backports?" cycle ;) >> >> Thx >> T. >> >> >>> Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr >>> Von: "Noury Bouraqadi" <bouraqadi(a)gmail.com> >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Betreff: [Pharo-dev] A thought about backporting >>> >>> Hi, >>> >>> Here is a thought I want to share with you. >>> Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system. >>> >>> I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer? >>> There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one). >>> >>> Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough. >>> Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version. >>> >>> Noury >>> Ecole des Mines de Douai >>> http://car.mines-douai.fr/noury >>> -- >>> >>> >>> >>> >>> >> >

Nov. 15, 2013

Re: [Pharo-dev] A thought about backporting

by btc＠openinworld.com

Nov. 15, 2013

Do not forget to sign the Pharo License Agreement

by StÃ©phane Ducasse

Hi guys we have now 183 contributors or past contributors that signed the license. Please do not forget to sign yours: http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf Stef

Nov. 15, 2013

how-to-contribute points to null

by StÃ©phane Ducasse

http://www.pharo-project.org/community/how-to-contribute point to https://pharo.fogbugz.com/default.asp?W39 which does not exist Stef

Nov. 15, 2013

Re: [Pharo-dev] ClassCommented is only announced if string is a RemoteString

by StÃ©phane Ducasse

yes code violates any idea of encapsulation. SourcesArray at: 2 :) Stef On Nov 15, 2013, at 10:46 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > I was trying to figure out how to delegate somebody else the knowledge of the file number: > > RemoteString newString: aString onFileNumber: 2 > > I was thinking in a replacement like: > > SourceFiles newRemoteStringWith: aString > > or: > > SourceFiles oldRemoteStringAt: aSourcePointer > > And let a SourceFileArray instance decide what's the file number. > > But it's not so easy. In other methods (I think related to condensing the file or filing out), it's also specified the filestream: > > RemoteString newString: self organization classComment onFileNumber: 2 toFile: aFileStream > > MartÃn > > > On Thu, Nov 14, 2013 at 7:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I hate this code. > I had to work with it so many times when I extracted all the squeak version to load them in VW to be analysed > in Moose (and sadly nobody did anything with them) I should have started to publish ideas on them - silly me. > > Stef > > On Nov 14, 2013, at 5:52 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> Hi >> >> Any idea why the "aString isKindOf: RemoteString" is there? >> >> In TClassDescription: >> >> classComment: aString stamp: aStamp >> "Store the comment, aString or Text or RemoteString, associated with the class we are organizing. Empty string gets stored only if had a non-empty one before." >> >> | pointer header file oldCommentRemoteString oldComment oldStamp | >> oldComment := self organization classComment. >> oldStamp := self organization commentStamp. >> >> (aString isKindOf: RemoteString) ifTrue: [ >> SystemAnnouncer uniqueInstance >> class: self >> oldComment: oldComment >> newComment: aString string >> oldStamp: oldStamp >> newStamp: aStamp. >> ^ self organization classComment: aString stamp: aStamp]. >> >> oldCommentRemoteString := self organization commentRemoteStr. >> (aString size = 0) & (oldCommentRemoteString isNil) ifTrue: [^ self organization classComment: nil]. >> "never had a class comment, no need to write empty string out" >> >> pointer := oldCommentRemoteString >> ifNil: [0] >> ifNotNil: [oldCommentRemoteString sourcePointer]. >> >> (file := SourceFiles at: 2) ifNotNil: [ >> file setToEnd; cr; nextPut: $!. "directly" >> "Should be saying (file command: 'H3') for HTML, but ignoring it here" >> header := String streamContents: [:strm | strm nextPutAll: self name; >> nextPutAll: ' commentStamp: '. >> aStamp storeOn: strm. >> strm nextPutAll: ' prior: '; nextPutAll: pointer printString]. >> file nextChunkPut: header]. >> >> self organization >> classComment: (RemoteString newString: aString onFileNumber: 2) >> stamp: aStamp. >> >> SystemAnnouncer uniqueInstance >> class: self >> oldComment: oldComment >> newComment: aString >> oldStamp: oldStamp >> newStamp: aStamp >> >> (nice method eh!) >> >> MartÃn > >

Nov. 15, 2013

Re: [Pharo-dev] ClassCommented is only announced if string is a RemoteString

by Martin Dias

I was trying to figure out how to delegate somebody else the knowledge of the file number: RemoteString newString: aString onFileNumber: 2 I was thinking in a replacement like: SourceFiles newRemoteStringWith: aString or: SourceFiles oldRemoteStringAt: aSourcePointer And let a SourceFileArray instance decide what's the file number. But it's not so easy. In other methods (I think related to condensing the file or filing out), it's also specified the filestream: RemoteString newString: self organization classComment onFileNumber: 2 > toFile: aFileStream MartÃn On Thu, Nov 14, 2013 at 7:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I hate this code. > I had to work with it so many times when I extracted all the squeak > version to load them in VW to be analysed > in Moose (and sadly nobody did anything with them) I should have started > to publish ideas on them - silly me. > > Stef > > On Nov 14, 2013, at 5:52 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi > > Any idea why the "aString isKindOf: RemoteString" is there? > > In TClassDescription: > > classComment: aString stamp: aStamp >> >> "Store the comment, aString or Text or RemoteString, associated with >>> the class we are organizing. Empty string gets stored only if had a >>> non-empty one before." >> >> >>> | pointer header file oldCommentRemoteString oldComment oldStamp | >> >> oldComment := self organization classComment. >> >> oldStamp := self organization commentStamp. >> >> >>> (aString isKindOf: RemoteString) ifTrue: [ >> >> SystemAnnouncer uniqueInstance >> >> class: self >> >> oldComment: oldComment >> >> newComment: aString string >> >> oldStamp: oldStamp >> >> newStamp: aStamp. >> >> ^ self organization classComment: aString stamp: aStamp]. >> >> >>> oldCommentRemoteString := self organization commentRemoteStr. >> >> (aString size = 0) & (oldCommentRemoteString isNil) ifTrue: [^ self >>> organization classComment: nil]. >> >> "never had a class comment, no need to write empty string out" >> >> >>> pointer := oldCommentRemoteString >> >> ifNil: [0] >> >> ifNotNil: [oldCommentRemoteString sourcePointer]. >> >> (file := SourceFiles at: 2) ifNotNil: [ >> >> file setToEnd; cr; nextPut: $!. "directly" >> >> "Should be saying (file command: 'H3') for HTML, but ignoring it here" >> >> header := String streamContents: [:strm | strm nextPutAll: self name; >> >> nextPutAll: ' commentStamp: '. >> >> aStamp storeOn: strm. >> >> strm nextPutAll: ' prior: '; nextPutAll: pointer printString]. >> >> file nextChunkPut: header]. >> >> self organization >> >> classComment: (RemoteString newString: aString onFileNumber: 2) >> >> stamp: aStamp. >> >> SystemAnnouncer uniqueInstance >> >> class: self >> >> oldComment: oldComment >> >> newComment: aString >> >> oldStamp: oldStamp >> >> newStamp: aStamp >> >> > (nice method eh!) > > MartÃn > > >

Nov. 15, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30575 Home: https://github.com/pharo-project/pharo-core

Nov. 15, 2013

[pharo-project/pharo-core] 757631: 30575

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 757631a3f7e630103779cbc661bedf866f9a0930 https://github.com/pharo-project/pharo-core/commit/757631a3f7e630103779cbc6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-15 (Fri, 15 Nov 2013) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script231.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30575.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/InstanceVariableEyeElement.class/instance/menu/customSubMenu_.st M Tools.package/MetacelloConfigurationBrowserPane.class/README.md M Tools.package/MetacelloConfigurationBrowserPane.class/instance/menu/configurationListMenu_.st M Tools.package/MetacelloConfigurationBrowserToolbar.class/README.md Log Message: ----------- 30575 12168 Menu actions of MetacelloConfigurationBrowser do not fit buttons https://pharo.fogbugz.com/f/cases/12168 12169 Inspector contextual menu raises DNU MenuModel>>#add:target:selector: https://pharo.fogbugz.com/f/cases/12169 http://files.pharo.org/image/30/30575.zip

Nov. 15, 2013

Re: [Pharo-dev] A thought about backporting

by Camillo Bruni

You already have a complete list of the images here: http://files.pharo.org/image/20/ http://files.pharo.org/image/30/ I don't think that the platform/oneclick builds should be the main deployment artifacts. I assume that if you have a decent project you will use a CI service to build your project, which means you can easily fix the image version by using the links above. On 2013-11-14, at 21:12, Torsten Bergmann <astares(a)gmx.de> wrote: > If a backport happens it can mean two things to a user: > > POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...) > NEGATIV: a possible broken API introduced by a backport > > It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip" > from http://files.pharo.org/platform directly after the "big announcement" and half year > later (after backports happened) he may be surprised since it results in different images > and may lead to problems. Not directly in the image but it can happen when loading other > packages that could be broken by the backport. > > > On one side we want a "reproducible" reliable version announced as "official release" at one point > in time on the other hand we want to be able to backport fixes and make the experience better > so Pharo 2.0 is not really fix. > > > IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but > for the artefacts (in the build folder) and on the download page we should provide the > FULL VERSION: > > MAJOR.MINOR-BUILD > > As you know we already use this for our development: the build is our update number which is also > easily reproducible (we have release mails like for 20627) and in the near future with projects > like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/ > it will be even easier to get a specific image version. > > > So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we > should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way > people could spot the difference to old downloads more easily. > > One often see's download pages of open source projects stating "Download latest here" and > "Download previous versions here" with a list of older releases. > By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want. > > My proposal: lets use the update number more often. It would also help when people report bugs > to know about the specific update number. > > It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the > newer one with the backports?" cycle ;) > > Thx > T. > > >> Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr >> Von: "Noury Bouraqadi" <bouraqadi(a)gmail.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: [Pharo-dev] A thought about backporting >> >> Hi, >> >> Here is a thought I want to share with you. >> Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system. >> >> I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer? >> There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one). >> >> Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough. >> Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version. >> >> Noury >> Ecole des Mines de Douai >> http://car.mines-douai.fr/noury >> -- >> >> >> >> >> >

Nov. 15, 2013

Re: [Pharo-dev] Commit permissions to Pharo30Inbox

by Marcus Denker

On 15 Nov 2013, at 02:36, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Hi, > > can someone give me a commit permissions to Pharo30Inbox? > > My account is http://smalltalkhub.com/#!/~JurajKubelka Done Marcus

Nov. 15, 2013