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

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

Commit permissions to Pharo30Inbox

by Juraj Kubelka

Hi, can someone give me a commit permissions to Pharo30Inbox? My account is http://smalltalkhub.com/#!/~JurajKubelka Thank you, Jura

Nov. 15, 2013

Re: [Pharo-dev] Getting Pharo3 green...

by StÃ©phane Ducasse

thanks a lot sven! >> 2) ZnServerTests>>testEntityTooLarge >> ZnServerTests>>testHeaderLineTooLong >> ZnServerTests>>testRequestLineTooLong >> - only on Win >> - there seems to be already a workaround? >> - https://pharo.fogbugz.com/f/cases/10908/ > > Yes, I will prepare a new Zinc update over the weekend, but I have to carefully check all versions of all packages, all diffs in both directions. > > It is coming ;-)

Nov. 15, 2013

Re: [Pharo-dev] Getting Pharo3 green...

by StÃ©phane Ducasse

thanks a lot sven! >> 2) ZnServerTests>>testEntityTooLarge >> ZnServerTests>>testHeaderLineTooLong >> ZnServerTests>>testRequestLineTooLong >> - only on Win >> - there seems to be already a workaround? >> - https://pharo.fogbugz.com/f/cases/10908/ > > Yes, I will prepare a new Zinc update over the weekend, but I have to carefully check all versions of all packages, all diffs in both directions. > > It is coming ;-)

Nov. 14, 2013

Re: [Pharo-dev] A thought about backporting

by kilon alios

Pharolauncher does make it clear which specific release the user downloads. Of course would not hurt to add the release to the name of the version or the name of the download. Also I used to like the notification pop up window when I first opened the image , there the specific release could be shown , maybe even a log with new changes , bug fixes, so the user is aware what exactly has downloaded. Now when you open the image you are welcomed with an empty white space and pharo logo which I think is a bit too empty for my taste. On Thu, Nov 14, 2013 at 10:22 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Yes this is probably a good idea to proceed like that. > > Stef > > On Nov 14, 2013, at 9:12 PM, 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. 14, 2013

Re: [Pharo-dev] A thought about backporting

by StÃ©phane Ducasse

Yes this is probably a good idea to proceed like that. Stef On Nov 14, 2013, at 9:12 PM, 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. 14, 2013

Re: [Pharo-dev] [Pharo-users] State of Flamel?

by StÃ©phane Ducasse

We should change that and use the properties of the node. Stef On Nov 14, 2013, at 8:52 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 14 nov. 2013, at 19:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Gisela is busy preparing a workshop in argentina and working. >> Now did you try to load it? >> I do not know if there is an automated jenkins build. > > Gisela contacted me, and I managed to load the newest version. > AST-Core is changed in Flamel by adding instance variables to RBProgramNode. > That breaks each time AST-Core changes in Pharo. > Still 2 failing tests (already on Trello), and the transformation needs work. > > Stephan > >

Nov. 14, 2013

Re: [Pharo-dev] Getting Pharo3 green...

by Sven Van Caekenberghe

On 14 Nov 2013, at 15:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 2) ZnServerTests>>testEntityTooLarge > ZnServerTests>>testHeaderLineTooLong > ZnServerTests>>testRequestLineTooLong > - only on Win > - there seems to be already a workaround? > - https://pharo.fogbugz.com/f/cases/10908/ Yes, I will prepare a new Zinc update over the weekend, but I have to carefully check all versions of all packages, all diffs in both directions. It is coming ;-)

Nov. 14, 2013

Re: [Pharo-dev] A thought about backporting

by Torsten Bergmann

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. 14, 2013

Re: [Pharo-dev] [Pharo-users] State of Flamel?

by Gisela Decuzzi

Hi Stephan, thanks for testing it, when I have some time I will work in the transformation because is a big missing feature. If you want to contribute with the project tell me your smalltalkhub user to add you :) Sorry for the lack of support, as Stef said I'm in the middle of a workshop planning for this saturday. 2013/11/14 Stephan Eggermont <stephan(a)stack.nl> > > On 14 nov. 2013, at 19:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Gisela is busy preparing a workshop in argentina and working. > > Now did you try to load it? > > I do not know if there is an automated jenkins build. > > Gisela contacted me, and I managed to load the newest version. > AST-Core is changed in Flamel by adding instance variables to > RBProgramNode. > That breaks each time AST-Core changes in Pharo. > Still 2 failing tests (already on Trello), and the transformation needs > work. > > Stephan > > > >

Nov. 14, 2013