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

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

pattern for configuration definition

by StÃ©phane Ducasse

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] Keyboard events is broken.

by StÃ©phane Ducasse

I will retry and be careful about which vm I use because I had around 3/4 images open to tests snapshotcello. So I may have open it with the old one. Stef > yes, this latest vm should have the problem solved > > On Aug 9, 2013, at 6:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> >>> >>> On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> now can we get a working keyboard? >>> Yes here >>> >>> Hi, >>> >>> Guille built a new vm with an attept of fixing the key combinations problem. >>> Can you test it? >>> >>> http://files.pharo.org/vm/pharo/ >>> >>> (and pick the latest for your platform) >>> >>> Thanks, >>> Esteban >>> >> Esteban did this vm get the fix for SmallInteger? >> Because in the latest moose image >> >> (ConfigurationOfMoose project version: #development) record >> led to problem >> >> Stef >> >

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by StÃ©phane Ducasse

>> >>> well if the bug entry is not tag as ready to include the chance to get it loaded is really low. >>> If people do not pay attention to basics like thatâ¦.We will not make progress. >>> >> it is not ready yet because it is not ready. i will tag it when it will. >> > i meant not *tagged* ready on purpose. ok :)

Aug. 9, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Esteban Lorenzano

yes, this latest vm should have the problem solved On Aug 9, 2013, at 6:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> >> On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> now can we get a working keyboard? >> Yes here >> >> Hi, >> >> Guille built a new vm with an attept of fixing the key combinations problem. >> Can you test it? >> >> http://files.pharo.org/vm/pharo/ >> >> (and pick the latest for your platform) >> >> Thanks, >> Esteban >> > Esteban did this vm get the fix for SmallInteger? > Because in the latest moose image > > (ConfigurationOfMoose project version: #development) record > led to problem > > Stef >

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by Igor Stasenko

On 9 August 2013 18:04, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 August 2013 17:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> well if the bug entry is not tag as ready to include the chance to get it loaded is really low. >> If people do not pay attention to basics like thatâ¦.We will not make progress. >> > it is not ready yet because it is not ready. i will tag it when it will. > i meant not *tagged* ready on purpose. >> Stef >> >> On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Hello, >>> >>> lately we changed the object format of subject class from variableByte >>> to normal one. >>> >>> All projects which using NBExternalStructure can meet certain problems with it, >>> and first which comes is that it may load code cleanly but in fact >>> result in bogus >>> variable subclasses of NBExternalStructure , while it can't because >>> superclass has instance variable. >>> (i suspecting classbuilder bug, but need to verify first). >>> >>> To address that, you need to manually go over all subclasses and double-check. >>> >>> Another thing: since now instances NBExternalStructure can also point >>> to external memory, >>> special care should be taken for #copying. >>> Sending #copy to instance which uses external memory, will create a >>> copy on object memory >>> (and copy all data from external memory into it). This is same >>> behavior as in NBExternalArray. >>> >>> - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) >>> https://pharo.fogbugz.com/default.asp?11395#83020 >>> will do that in nearest time. >>> >>> also note, that in callouts, you cannot pass an instance of >>> NBExternalStructure anymore >>> to function, which uses raw pointer (like void*) anymore. >>> >>> For passing a pointer to structure data for callouts, use >>> myStructure address >>> idiom (or use right struct type, which is preferable). >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by Igor Stasenko

On 9 August 2013 17:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > well if the bug entry is not tag as ready to include the chance to get it loaded is really low. > If people do not pay attention to basics like thatâ¦.We will not make progress. > it is not ready yet because it is not ready. i will tag it when it will. > Stef > > On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Hello, >> >> lately we changed the object format of subject class from variableByte >> to normal one. >> >> All projects which using NBExternalStructure can meet certain problems with it, >> and first which comes is that it may load code cleanly but in fact >> result in bogus >> variable subclasses of NBExternalStructure , while it can't because >> superclass has instance variable. >> (i suspecting classbuilder bug, but need to verify first). >> >> To address that, you need to manually go over all subclasses and double-check. >> >> Another thing: since now instances NBExternalStructure can also point >> to external memory, >> special care should be taken for #copying. >> Sending #copy to instance which uses external memory, will create a >> copy on object memory >> (and copy all data from external memory into it). This is same >> behavior as in NBExternalArray. >> >> - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) >> https://pharo.fogbugz.com/default.asp?11395#83020 >> will do that in nearest time. >> >> also note, that in callouts, you cannot pass an instance of >> NBExternalStructure anymore >> to function, which uses raw pointer (like void*) anymore. >> >> For passing a pointer to structure data for callouts, use >> myStructure address >> idiom (or use right struct type, which is preferable). >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Aug. 9, 2013

Re: [Pharo-dev] Keyboard events is broken.

by StÃ©phane Ducasse

On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> now can we get a working keyboard? > Yes here > > Hi, > > Guille built a new vm with an attept of fixing the key combinations problem. > Can you test it? > > http://files.pharo.org/vm/pharo/ > > (and pick the latest for your platform) > > Thanks, > Esteban > Esteban did this vm get the fix for SmallInteger? Because in the latest moose image (ConfigurationOfMoose project version: #development) record led to problem Stef

Aug. 9, 2013