- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Metacello: redefine a group for a platform to add an additional package

by Tudor Girba

Hmm. Perhaps groups are not overridden for separate platforms. You could try defining the 'default' group for each separate platform without defining it for #common. Doru On Thu, Nov 14, 2013 at 3:59 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Dale and others: > > for the "SimplePersistence" project (see STHub) we need to load a > "SimplePersistence-Platform" > project right after the core, but only when we run on Pharo 2.0. > > The spec looks like this: > > > baseline301: spec > <version: '3.0.1-baseline'> > > spec for: #common do: [ > spec blessing: #'baseline'. > spec description: '- Add Platform package for Pharo 2.0'. > spec repository: ' > http://smalltalkhub.com/mc/TorstenBergmann/SimplePersistence/main'. > spec > package: 'SimplePersistence-Core'; > package: 'SimplePersistence-Tests' with: [ > spec requires: #('SimplePersistence-Core' ). ]. > spec > group: 'Core' with: #('SimplePersistence-Core' ); > group: 'Tests' with: #('SimplePersistence-Tests'); > group: 'CI' with: #('Core' 'Tests'); > group: 'default' with: #('Core' ) ]. > > spec for: #'pharo2.x' do: [ > spec package: 'SimplePersistence-Platform' with: > 'SimplePersistence-Platform.pharo20'. > *spec group: 'default' with: #('SimplePersistence-Platform' )* ]. > > > > But when I try in a pharo 2.0#20627 image : > > Gofer new > smalltalkhubUser: 'TorstenBergmann' project: 'SimplePersistence'; > package: 'ConfigurationOfSimplePersistence'; > load > > ConfigurationOfSimplePersistence project development spec inspect > > then the 'default' group is not redefined - and the additional platform > package for Pharo 2.0 is not loaded. > > Any ideas how to achieve that? > > Thx > T. > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 15, 2013