- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] pharo 3.0 versionner and creating a development version

by Norbert Hartl

Am 11.02.2014 um 16:43 schrieb Christophe Demarey <Christophe.Demarey(a)inria.fr>: > > Le 11 fÃ©vr. 2014 Ã 16:15, Norbert Hartl a Ã©crit : > >> >> Am 11.02.2014 um 14:48 schrieb Christophe Demarey <Christophe.Demarey(a)inria.fr>: >> >>> Hi Norbert, >>> >>> Le 11 fÃ©vr. 2014 Ã 11:05, Norbert Hartl a Ã©crit : >>> >>>> I try really hard to move to 3.0 at the moment. To me versionner became that important that this is a requirement for me to change the version. Iâm testing the bleeding edge version of versionner in 3.0 and this looks really cool. But somehow I cannot create a development version of my project. Whatever I try the only thing I can achieve is that versionner is producing a new baseline method. I used all of the three buttons at the top and did also examine all of the menus (those that work). >>>> >>>> Any hints? >>> >>> I wrote a small documentation on Versionner: http://chercheurs.lille.inria.fr/~demarey/Tech/Versionner. >>> With Versionner, a development version is always a baseline. If none is found, it will create one from the selected version. >>> Why is it a baseline? because you don't want to update your configuration each time you publish new packages. >>> >>> When you are ready to release, Versionner creates: >>> a numbered version with fixed packages revisions, >>> and the next development version (a baseline). >>> >>> Tell me if you need more information. >> >> Iâm not sure I understand. On the symbolic version front we have bleedingEdge that is loading a baseline without exact version information (it loads the newest packages). Then we have development versions that have specific package versions but are not released (not tagged stable). And we have releases that have a sense of to-be-published. >> Now we have only baselines/development and released versions? > > Yes. It is quite strange to have three levels of stability. A few users use that and we tried to find a simple process to manage configurations. > As in many other languages, you develop, release, then develop again. > In another way, I can also understand that you prefer another process or that you need an "extra" level. > >> I liked to have the three levels because it matches all the requirements in my workflow. That is baseline = development, development = be used by other projects/collaborators before it is released, stable = ready to be released. > > your definition of the development version looks like a release-candidate. Why not publish (yes release ;) ) a RC version for this purpose? > >> Anyway if it is the case that there is only baseline and released version I do not understand why the versions are having the blessing development. How are those supposed to be tagged stable? > > They shouldn't. I fixed that friday and it will be integrated soon. > >> At the moment I find it quite confusing how it is. I need maybe one or two more hints. > > I understand. Versionner was thought to encourage people to follow a workflow that may be different of their current one. > But there is still place to discussion, move and adding some other functionalities. > > Versionner needs feedback and will evolve from feedback. > Ok. What I wrote above is just what Iâm used to and what is my current way of working. But I must confess that this extra level of mine is probably not necessary. At least it complicates things and you can always argue that if you want three then the next one wants to have four levels. I need to think about a way how to build up my workflow on top of versionner not within. thanks for the great work! The new UI looks really great! Norbert

Feb. 11, 2014

Re: [Pharo-dev] [Esug-list] Smalltalk dialects and GSoC

by Igor Stasenko

On 11 February 2014 18:08, Paolo Bonzini <bonzini(a)gnu.org> wrote: > Il 11/02/2014 17:53, Bert Freudenberg ha scritto: > >> I think a Newspeak<->Smalltalk translator, written in Smalltalk, would be >>> eligible for GSoC under the ESUG organization. >>> >>> If it were to be written in Newspeak, I would still want to have it >>> in the ideas list. Perhaps the student itself could propose to use >>> Smalltalk instead, or it could be a backup in case we lose a student due >>> to conflicts with other organizations. However, the chances for it to >>> get into the program would be slimmer. >>> >> >> How about a project for a new or extended Smalltalk VM? Written in >> non-Smalltalk, but running a Smalltalk, e.g. Squeak? >> > > Of course, everything must be considered on a case-by-case basis. There > is no hard and fast rule. > > Right. I didn't said it's easy to correctly/perfectly draw a line. But you have to draw it.. and once you did, you will always have chances to find someone left aboard and screaming about bias and blatantly unethical behavior, instead of peacefully discussing and providing arguments. > With my GNU Smalltalk hat on, I would redirect VM ideas to the GNU > organization, and only use ESUG slots for projects that have more porting > potential. But I understand that not all dialects have the same > opportunity. > > No, i think any Smalltalk VM is clearly a good topic to run under ESUG umbrella. > > Paolo > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- Best regards, Igor Stasenko.

Feb. 11, 2014

Re: [Pharo-dev] pharo 3.0 versionner and creating a development version

by Christophe Demarey

Le 11 fÃ©vr. 2014 Ã 16:15, Norbert Hartl a Ã©crit : > > Am 11.02.2014 um 14:48 schrieb Christophe Demarey <Christophe.Demarey(a)inria.fr>: > >> Hi Norbert, >> >> Le 11 fÃ©vr. 2014 Ã 11:05, Norbert Hartl a Ã©crit : >> >>> I try really hard to move to 3.0 at the moment. To me versionner became that important that this is a requirement for me to change the version. Iâm testing the bleeding edge version of versionner in 3.0 and this looks really cool. But somehow I cannot create a development version of my project. Whatever I try the only thing I can achieve is that versionner is producing a new baseline method. I used all of the three buttons at the top and did also examine all of the menus (those that work). >>> >>> Any hints? >> >> I wrote a small documentation on Versionner: http://chercheurs.lille.inria.fr/~demarey/Tech/Versionner. >> With Versionner, a development version is always a baseline. If none is found, it will create one from the selected version. >> Why is it a baseline? because you don't want to update your configuration each time you publish new packages. >> >> When you are ready to release, Versionner creates: >> a numbered version with fixed packages revisions, >> and the next development version (a baseline). >> >> Tell me if you need more information. > > Iâm not sure I understand. On the symbolic version front we have bleedingEdge that is loading a baseline without exact version information (it loads the newest packages). Then we have development versions that have specific package versions but are not released (not tagged stable). And we have releases that have a sense of to-be-published. > Now we have only baselines/development and released versions? Yes. It is quite strange to have three levels of stability. A few users use that and we tried to find a simple process to manage configurations. As in many other languages, you develop, release, then develop again. In another way, I can also understand that you prefer another process or that you need an "extra" level. > I liked to have the three levels because it matches all the requirements in my workflow. That is baseline = development, development = be used by other projects/collaborators before it is released, stable = ready to be released. your definition of the development version looks like a release-candidate. Why not publish (yes release ;) ) a RC version for this purpose? > Anyway if it is the case that there is only baseline and released version I do not understand why the versions are having the blessing development. How are those supposed to be tagged stable? They shouldn't. I fixed that friday and it will be integrated soon. > At the moment I find it quite confusing how it is. I need maybe one or two more hints. I understand. Versionner was thought to encourage people to follow a workflow that may be different of their current one. But there is still place to discussion, move and adding some other functionalities. Versionner needs feedback and will evolve from feedback. Thanks, Christophe.

Feb. 11, 2014

Re: [Pharo-dev] pharo 3.0 versionner and creating a development version

by Sean P. DeNigris

It's hard to think this one through without use casesâ¦ On the positive, it may be better to mark every numbered version as #'release' and then use semantic versioning to update if you run into trouble (i.e. release 2.0 and if you have to adjust the packages, 2.0.1). Because now that we have stable versions, there seem to be two competing systems - the tag of the numbered version and the symbolic version. In practice, it looks like a lot of numbered versions never get updated (i.e. versions that are symbolic #'stable' are not #'release' in the version spec) ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-3-0-versionner-and-creating-a-development-versi… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 11, 2014

Re: [Pharo-dev] GSoC: call for ideas

by Yuriy Tymchuk

On 11 Feb 2014, at 17:12, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On 11 Feb 2014, at 16:51, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 11 Feb 2014, at 16:49, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>>> 4. Preferences persistence. >>>> Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. >>>> easy - advanced >>>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> >>> In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. >> >> Did you implement it? > > I did, months ago :) > > Ben Câest cool. Thank you Ben. I had some more ideas like making a common STON format for prefs. But maybe you have some more ideas. Or we can just kill this proposal. Uko > >> >> Uko >> >>> >>> Ben >>> >> >

Feb. 11, 2014

Re: [Pharo-dev] GSoC: call for ideas

by Esteban Lorenzano

On 11 Feb 2014, at 17:12, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On 11 Feb 2014, at 16:51, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 11 Feb 2014, at 16:49, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>>> 4. Preferences persistence. >>>> Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. >>>> easy - advanced >>>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> >>> In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. >> >> Did you implement it? > > I did, months ago :) year(s) ago, in fact :) > > Ben > >> >> Uko >> >>> >>> Ben >>> >> >

Feb. 11, 2014

Re: [Pharo-dev] GSoC: call for ideas

by Benjamin

On 11 Feb 2014, at 16:51, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 11 Feb 2014, at 16:49, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >>> 4. Preferences persistence. >>> Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. >>> easy - advanced >>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> >> In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. > > Did you implement it? I did, months ago :) Ben > > Uko > >> >> Ben >> >

Feb. 11, 2014

Re: [Pharo-dev] GSoC: call for ideas

by Yuriy Tymchuk

On 11 Feb 2014, at 16:49, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> 4. Preferences persistence. >> Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. >> easy - advanced >> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > > In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. Did you implement it? Uko > > Ben >

Feb. 11, 2014

Re: [Pharo-dev] GSoC: call for ideas

by Benjamin

> 4. Preferences persistence. > Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. > easy - advanced > Yuriy Tymchuk <yuriy.tymchuk(a)me.com> In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. Ben

Feb. 11, 2014

Re: [Pharo-dev] [Esug-list] Unethical behaviour on GSoC 2010 (was The truth on GSOC, ESUG and bad attitude)

by Igor Stasenko

On 11 February 2014 10:07, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hi Igor and all! > > On 02/10/2014 11:56 PM, Igor Stasenko wrote: > [SNIP] > > Just to give you +1 on the Smalltalk family part. I mean, hell, >> we even share the VM! >> >> And I am not sure people understand how important this has been >> for us Squeak/Pharooners, AFAIK a LOT of the work from Eliot has >> been done through Newspeakish money, right? >> >> >> Yes. I've worked for Cadence twice. Once in 2007 to 2008 where I >> first worked on the Squeak interpreter and added immutability. Form >> there, now familiar with VMMaker I went to Qwaq and got to create >> Cog. I'm now back at Cadence and able to continue to work on Cog. >> In particular, Spur has only been possible because of my boss at >> Cadence, Yaron Kashai. At Cadence we're using Newspeak to implement >> systems for SoaC integration. Without Newspeak there would be no >> Spur. WIthout Newspeak the Cog VM would not be nearly as developed >> or reliable. >> >> I don't want to stoke the flames but I do hope that the community >> will consider Newspeak as part of the Smalltalk family. It is >> definitely a blood relative. Don't treat it like a black sheep. >> >> >> I am not arguing whether Newspeak belongs to smalltalk family or not >> (clearly it is). >> The point is that 'S' letter in ESUG stands for Smalltalk, not Newspeak. >> (else we should be naming it properly - ENUG). >> So, the question is whether any non-smalltalk project is eligible to run >> and compete (because there is limited number of slots) with smalltalk >> projects under ESUG umbrella? >> > > Well, first of all I was actually *not* talking about that particular > incident (whatever took place, I have no idea) - my mistake to not make > that clear - I merely wanted to note that we should stick together as a > family *in general*. Gilad should really feel that IMHO. > > Nevertheless just like Dennis noted - Pharo doesn't start with an "S" - > hell, it even uses the phrase "Smalltalk inspired" to distance itself and > make clear that hey, this is not a Smalltalk! > > And Pharo has Traits so is it "Smalltalk"? :) Amber doesn't even have > globals (!) so is Amber "a Smalltalk"? > > And the fact that Newspeak actually *shares the VM* with Pharo and Squeak > - that indicates a pretty strong connection, don't you think? Much stronger > than Amber many would argue... And oh, Amber actually *claims* to be a > Smalltalk ;) On the other hand it wants to be compatible with Pharo which > claims to be only "inspired"... oh, darnit! > > Just kidding (well, 50% serious perhaps) Igor, I get what you mean, just > getting a bit philosophical here, I haven't had my morning coffee... :) > > Nothing philosophical here. Pharo, Amber are smalltalk dialects. Newspeak is not. It is brand new language. Different syntax, different semantics. The fact that it uses VM which can run smalltalk doesn't makes any difference. There's a number of Smalltalks impemented on top of JVM, and CLR platforms. Following your logic, then such implementations should be eligible to run under 'java/C# GSoC umbrella'? And let me be clear: i am not against Newspeak or any other language or person(s) who invested a lot into it and keep investing. They are doing good things in exploring and pushing forward original ideas and enriching our computing world. But as to me it is clear example, where ESUG should draw a line. -- Best regards, Igor Stasenko.

Feb. 11, 2014