- Pharo-dev - lists.pharo.org

latest VM seems stable

by StÃ©phane Ducasse

Hi esteban I did a massive amount of loads (basically loading Moose in Pharo20 all day long) and I used exclusively the latest vm with guille changes on top of latest of Eliot. And I got no smalltinteger problems so far. So this sounds good. Stef

Aug. 11, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Andres Valloud

Ok, thank you. At the risk of being too inquisitive, what do you mean when you say "add a slave into our build server"? Is the implication that a release will include N binaries compiled on N Linux versions? On 8/8/13 8:02 , Esteban Lorenzano wrote: > well... no. > something happened with the build, because it should be executable in a 1.5 years old linux. > > in the middle term, we are going to adopt an approach similar to VW (one VM for one image version), and we will support some years of backward compatibility. > But not infinite, of course, because work is too much :) > > Now... the "latest" VM is unstable. Is not a release and of course it will be problems. > > When we release it, it will be version to run in several versions... it should be as simple as add a slave into our build server. > > cheers, > Esteban > > > On Aug 8, 2013, at 4:54 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 8 August 2013 15:40, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net> wrote: >>> Are you saying the Pharo VM requires glibc version 2.15 of March 2012, and >>> that consequently the Pharo VM as compiled won't run on any Linux distro >>> older than 17 months? >>> >> >> You are not forced to use latest VM, you can always download and use >> 5-year old VM, which will (hopefully) >> work for you. >> :) >> >> Now if platform (linux) moves, we must follow. And that is not a question to me. >> >> -- >> Best regards, >> Igor Stasenko. >> > > . >

Aug. 11, 2013

Re: [Pharo-dev] Understanding Versionner repository selection

by StÃ©phane Ducasse

On Aug 11, 2013, at 6:04 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > El 10/08/2013 14:55, HernÃ¡n Morales Durand escribiÃ³: >> Hi folks, >> I have a *very* simple package with no dependencies whatsoever. Now I'm >> trying to understand Versionner, these are the steps: >> >> 1. I set the ConfigurationOf name >> 2. I choose I don't want to use squeaksource.com >> <http://squeaksource.com>, ok >> 3. Select a repository... >> >> Now that is not clear for me. Which repository are you talking about? >> the repository where I store MY code, or the repository where I would >> like to publish the configuration so is displayed in the Configuration >> Browser (like the MetaRepoForPharo)? >> > > Ok, I choose the MetaRepoForPharo. The ConfigurationOf class is generated with its methods. I consider myself this package as stable, but there is no generated method for #'stable'. Do I need to create it by hand and then Commit to repository? normally not but I do not know the status of Versioner and christophe is on vacation. > > This is another doubt. Where I should add meta information about my package? I just want to put a little description of what it does. Hi all, I wish I could release a first beta of Versionner before my holidays but I'am a bit short. Nevertheless, you will find an archive on this page http://chercheurs.lille.inria.fr/~demarey/Tech/Versionner containing the current status of Versionner. If you want, you can play a bit with it and give me feedback. There are a lot of missing features but tit will come time after time. >From now you can create a new config, release a dev version, update dependencies. See you in 3 weeks, Christophe.

Aug. 11, 2013

Re: [Pharo-dev] Understanding Versionner repository selection

by HernÃ¡n Morales Durand

El 10/08/2013 14:55, HernÃ¡n Morales Durand escribiÃ³: > Hi folks, > I have a *very* simple package with no dependencies whatsoever. Now I'm > trying to understand Versionner, these are the steps: > > 1. I set the ConfigurationOf name > 2. I choose I don't want to use squeaksource.com > <http://squeaksource.com>, ok > 3. Select a repository... > > Now that is not clear for me. Which repository are you talking about? > the repository where I store MY code, or the repository where I would > like to publish the configuration so is displayed in the Configuration > Browser (like the MetaRepoForPharo)? > Ok, I choose the MetaRepoForPharo. The ConfigurationOf class is generated with its methods. I consider myself this package as stable, but there is no generated method for #'stable'. Do I need to create it by hand and then Commit to repository? This is another doubt. Where I should add meta information about my package? I just want to put a little description of what it does. HernÃ¡n

Aug. 11, 2013

about new class organization

by StÃ©phane Ducasse

Hi esteban/ben I'm trying to understand the new class organisation. Now would it be possible to (beside the backward compatibility part) only use protocol instead of category? Because this is quite confusing to have categories that manipulate Protocol objects. I would like to add some queries hasProtocolFor: aSymbol And may be we should do a pass and add some comments to the methods because I could get what some do but by putting a break point. For example, realCategories ^ self protocolOrganizer protocolsNames So tell me what you think because may be I too tired now. Stef

Aug. 10, 2013

Understanding Versionner repository selection

by HernÃ¡n Morales Durand

Hi folks, I have a *very* simple package with no dependencies whatsoever. Now I'm trying to understand Versionner, these are the steps: 1. I set the ConfigurationOf name 2. I choose I don't want to use squeaksource.com, ok 3. Select a repository... Now that is not clear for me. Which repository are you talking about? the repository where I store MY code, or the repository where I would like to publish the configuration so is displayed in the Configuration Browser (like the MetaRepoForPharo)? Cheers, HernÃ¡n

Aug. 10, 2013

Re: [Pharo-dev] pattern for configuration definition

by Erwan Douaille

2013/8/10 Erwan Douaille <douailleerwan(a)gmail.com> > Maybe it's already existing, but why not create a GUI to create > configurations ? > oops, it's called Versionner :) > It will be more easier and Camillo's pattern will be respected > > When i was dealing with configurations on ci, i've seen many > configurations and no ones was similar. > > Force users/dev to create a correct configuration implementing dev/stable > is needed. Of course, one of the first step of the ci project is testing if > the configuration is correct. Else stop process and throw errors. > > I already have a similar discussion with Camillo :) > > > 2013/8/10 Camillo Bruni <camillobruni(a)gmail.com> > >> Before I get into details, >> >> if you create a new Configuration in Pharo, you will get now a pre-filled >> template with lots of comments. >> >> Summary: >> ======== >> >> - only 1 version for development which is updated manually (typically on >> each new commit) >> - for the DEV version, there is a DEV baseline >> - if a new release happens, the dev version and it's baseline are copied, >> the baseline has the same version number as the first version it was >> introduced with. >> - all external projects in separate methods for readability (plus it's >> easier to change the main repos) >> >> It's not much actually, but basically I treat the configuration as normal >> ST code and avoid duplication :). >> I hope my explanation is not clear enough. >> >> On 2013-08-10, at 04:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> > Hi camillo >> > >> > I like the pattern damien told me you are applying for your >> configuration. >> > Could you explain them? >> > I understood: >> > >> > baseline48: spec >> > <version: '4.8-baseline'> >> > >> > spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. >> > â¦ >> > spec project: 'Metanool' with: [ >> > spec >> > className: >> 'ConfigurationOfMetanool'; >> > version: #development; >> > file: 'ConfigurationOfMetanool'; >> > repository: ' >> http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. >> > >> > â¦ >> > >> > => >> > >> > baseline48: spec >> > <version: '4.8-baseline'> >> > >> > spec repository: self repositoryUrlString >> > â¦ >> > spec project: 'Metanool' with: [ >> > spec >> > className: >> 'ConfigurationOfMetanool'; >> > version: #development; >> > file: 'ConfigurationOfMetanool'; >> > repository: ' >> http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. >> > >> > â¦ >> > >> > repositoryUrlString >> > ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. >> > >> > specMetanoolConfiguration: spec >> > >> > spec >> > className: >> 'ConfigurationOfMetanool'; >> > version: #development; >> > file: 'ConfigurationOfMetanool'; >> > repository: ' >> http://www.smalltalkhub.com/mc/Moose/Metanool/main' >> > >> > >> > >> > >> > I like the idea to avoid duplication at the configuration level. >> > Now damien mention a dev and stable baseline >> > >> > Stef >> > >> > >> > >> >> >> > > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com> > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 10, 2013

Re: [Pharo-dev] pattern for configuration definition

by Erwan Douaille

Maybe it's already existing, but why not create a GUI to create configurations ? It will be more easier and Camillo's pattern will be respected When i was dealing with configurations on ci, i've seen many configurations and no ones was similar. Force users/dev to create a correct configuration implementing dev/stable is needed. Of course, one of the first step of the ci project is testing if the configuration is correct. Else stop process and throw errors. I already have a similar discussion with Camillo :) 2013/8/10 Camillo Bruni <camillobruni(a)gmail.com> > Before I get into details, > > if you create a new Configuration in Pharo, you will get now a pre-filled > template with lots of comments. > > Summary: > ======== > > - only 1 version for development which is updated manually (typically on > each new commit) > - for the DEV version, there is a DEV baseline > - if a new release happens, the dev version and it's baseline are copied, > the baseline has the same version number as the first version it was > introduced with. > - all external projects in separate methods for readability (plus it's > easier to change the main repos) > > It's not much actually, but basically I treat the configuration as normal > ST code and avoid duplication :). > I hope my explanation is not clear enough. > > On 2013-08-10, at 04:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Hi camillo > > > > I like the pattern damien told me you are applying for your > configuration. > > Could you explain them? > > I understood: > > > > baseline48: spec > > <version: '4.8-baseline'> > > > > spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. > > â¦ > > spec project: 'Metanool' with: [ > > spec > > className: > 'ConfigurationOfMetanool'; > > version: #development; > > file: 'ConfigurationOfMetanool'; > > repository: ' > http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. > > > > â¦ > > > > => > > > > baseline48: spec > > <version: '4.8-baseline'> > > > > spec repository: self repositoryUrlString > > â¦ > > spec project: 'Metanool' with: [ > > spec > > className: > 'ConfigurationOfMetanool'; > > version: #development; > > file: 'ConfigurationOfMetanool'; > > repository: ' > http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. > > > > â¦ > > > > repositoryUrlString > > ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. > > > > specMetanoolConfiguration: spec > > > > spec > > className: > 'ConfigurationOfMetanool'; > > version: #development; > > file: 'ConfigurationOfMetanool'; > > repository: ' > http://www.smalltalkhub.com/mc/Moose/Metanool/main' > > > > > > > > > > I like the idea to avoid duplication at the configuration level. > > Now damien mention a dev and stable baseline > > > > Stef > > > > > > > > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 10, 2013

Re: [Pharo-dev] pattern for configuration definition

by Camillo Bruni

Before I get into details, if you create a new Configuration in Pharo, you will get now a pre-filled template with lots of comments. Summary: ======== - only 1 version for development which is updated manually (typically on each new commit) - for the DEV version, there is a DEV baseline - if a new release happens, the dev version and it's baseline are copied, the baseline has the same version number as the first version it was introduced with. - all external projects in separate methods for readability (plus it's easier to change the main repos) It's not much actually, but basically I treat the configuration as normal ST code and avoid duplication :). I hope my explanation is not clear enough. On 2013-08-10, at 04:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi camillo > > I like the pattern damien told me you are applying for your configuration. > Could you explain them? > I understood: > > baseline48: spec > <version: '4.8-baseline'> > > spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. > â¦ > spec project: 'Metanool' with: [ > spec > className: 'ConfigurationOfMetanool'; > version: #development; > file: 'ConfigurationOfMetanool'; > repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. > > â¦ > > => > > baseline48: spec > <version: '4.8-baseline'> > > spec repository: self repositoryUrlString > â¦ > spec project: 'Metanool' with: [ > spec > className: 'ConfigurationOfMetanool'; > version: #development; > file: 'ConfigurationOfMetanool'; > repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. > > â¦ > > repositoryUrlString > ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. > > specMetanoolConfiguration: spec > > spec > className: 'ConfigurationOfMetanool'; > version: #development; > file: 'ConfigurationOfMetanool'; > repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' > > > > > I like the idea to avoid duplication at the configuration level. > Now damien mention a dev and stable baseline > > Stef > > >

Aug. 10, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Camillo Bruni

Nicolas Cellier, Are you willing to report and maintain VM bugs on the fogbugz issue tracker? Since you already filed reports on pharo.fogbugz.com I think this is not much of a change. thank you. On 2013-08-09, at 09:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 August 2013 13:28, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> thanks, perfect! >> >> that's very nice, now we have everything in one place. >> Nobody besides Pharo guys touched this issue tracker anyway :) >> > if that would be true, i wouldn't say anything.. > > The truth is that pharo team is most active on it.. yes. But does that > give us right to decide > what to do with it? > > > -- > Best regards, > Igor Stasenko. > <Screen Shot 2013-08-09 at 2.31.15 PM.png>

Aug. 10, 2013