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

Re: [Pharo-project] Squeaksource not synchronized

by Fabrizio Perin

do you want the entire folder or just the missing files? 2011/8/17 Marcus Denker <marcus.denker(a)inria.fr> > > On Aug 17, 2011, at 6:02 PM, Torsten Bergmann wrote: > > >> It seems not working. Could you please double check? I don't know how to > >> proceed. Someone have any idea? > > > > It's not there yet. Still wrong. > > > > Maybe you could delete the core/dev 1-3 mcz's on the hard disk > > and I reimport them. > > > > Yes, we can copy the package from SqueakSource, delete them there and send > them to the authors... > > Fabrizio, do you do that or should I? > > > Andreas Raab also seems to miss packages: > > > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/161238.h… > > > > Bye > > T. > > -- > > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > > > -- > Marcus Denker -- http://marcusdenker.de > > >

Aug. 17, 2011

Re: [Pharo-project] Policy for storing metacello configurations

by Dale Henrichs

Damien and others, I am hoping to have a set of relatively informal discussions of "Metacello and collaboration" on Saturday and Sunday at Camp Smalltalk with additional discussions throughout the week. I'll send mail to the Metacello mailing list[1] and tweet[2] about times and locations, which might end up being "meet now at the table in the lobby":). I'll also try to take notes and share info on the mailing list... If you have ideas and opinions I'm interested in hearing them, so come one up to me if the time is right we'll start an impromptu discussion group. If you won't be attending ESUG, then now would be a good time to send mail to the Metacello mailing list with your ideas and we can use them as topic in the discussions ... Dale [1] http://groups.google.com/group/metacello/ [2] http://twitter.com/#!/metacello ----- Original Message ----- | From: "Damien Pollet" <damien.pollet(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, August 17, 2011 10:34:06 AM | Subject: Re: [Pharo-project] Policy for storing metacello configurations | | On 17 August 2011 19:04, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Stef and I are going to talk at ESUG about the | > procedures/recommendations/tools for managing configurations in | > Pharo. | | Cool, I'm interested too (though probably to obsessive-compulsive to | have a useful point of view) | | > I (almost) apologize for naming the class MetacelloToolBox, but | > what do you expect from a person who makes up names all the time? | > With project names like Metacello or tODE and a blog called | > '(gem)Stone Soup' it's not always clear whether I'm making a | > mistake or a statement:) | | MetacelloToolRectangleMorph. That would have been a statement :) | | -- | Damien Pollet | type less, do more [ | ] http://people.untyped.org/damien.pollet | |

Aug. 17, 2011

Re: [Pharo-project] Policy for storing metacello configurations

by Bernat Romagosa

Great, really! :) So, ideally we'd have ONE single config repo (MetacelloRepository), and Gofer project would look there, is that it? 2011/8/17 Dale Henrichs <dhenrich(a)vmware.com> > Bernat, > > A while ago, Esteban Lorenzano released the GoferProjectLoader[1] that > extends Gofer and allows one to load configurations. For example: > > Gofer project > load: 'Seaside30'; > load: 'Pier2'. > > loads the latest version of Seaside30 and then Pier2 ... there are options > for further control ... > > By default 'Gofer project' looks in the MetacelloRepository, which works > but right now subject to problems like the original complaint that started > this thread... > > Stef and I will be talking about the process and implementation for > "...looking up which repo and version are the suitable ones" so hopefully > we'll come out of ESUG with a plan of action to take care of this problem... > > Dale > > > [1] http://forum.world.st/ANN-Gofer-Project-Loader-1-0-BETA-td1596415.html > > ----- Original Message ----- > | From: "Bernat Romagosa" <tibabenfortlapalanca(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, August 17, 2011 11:30:30 AM > | Subject: Re: [Pharo-project] Policy for storing metacello configurations > | > | I'm not sure whether this is one of the goals of the community or > | whether maybe someone's already heading in this direction, but > | something like Gofer install: #myPackage that looked up which repo > | and version are the suitable ones would really rock big time. The > | apt-get of Pharo, call it... > | > | > | To go on with the apt metaphor, Gofer search: 'whatever' could return > | a list of packages the descriptions/names of which matched > | 'whatever'. > | > | > | What do you think? > | > | > | > | 2011/8/17 Johan Brichau < johan(a)inceptive.be > > | > | > | Maybe a bit of wishful thinking butâ¦ > | > | Ideally, I think of the metacellorepository as a kind of 'smart > | folder' where all metacello configurations of public repositories > | are automatically included. > | Something like a smart mail folder on mac mail. > | > | Having two locations with the same package almost always leads to > | confusion / mistakes / forgetting / etcâ¦ > | > | Would such an 'automatic' repository be possible to implement in > | squeaksource3 and/or smalltalk hub? > | > | Johan > | > | > | > | > | On 17 Aug 2011, at 20:01, StÃ©phane Ducasse wrote: > | > | > > | > The policy should be > | > - put a configurationOf in your package > | > - publish when you want a copy of it in metacellorepository > | > > | > I will sit with dale sunday because we want the "publish" to copy > | > all the dependent package also in the > | > DistributionMetacelloRepository > | > > | > On Aug 17, 2011, at 8:59 AM, Max Leske wrote: > | > > | >> I would like to complain a bit about the current way Metacello > | >> configurations are distributed in different repositories. I ended > | >> up using the wrong configuration for two different projects twice > | >> in just two days. Apart from the date in the configuration file > | >> (and possibly the version number, although that's not as > | >> reliable) there's no easy way to tell which configuration is the > | >> most recent. > | >> > | >> Some people seem to have adopted MetacelloRepository as the > | >> standard repository for all configurations, others keep the > | >> configuration for a project in the project repositories and a > | >> third group uses both repositories (where one repository contains > | >> outdated versions of courseâ¦). > | >> > | >> Can we please agree on a simple policy on where to store the > | >> configuration for a project? I am sure that this would make life > | >> easier for all of us. > | >> > | >> Cheers, > | >> Max > | > > | > > | > | > | > | > | > | > | -- > | Bernat Romagosa. > | > > -- Bernat Romagosa.

Aug. 17, 2011

[Pharo-project] Aida ToDo example ready

by Janko MivÅ¡ek

Dear Smalltalkers, As part of comparison of web frameworks [1] Hannes Hirzel proposed to make a concrete example of web app in all three frameworks [2]. He proposed a ToDo example and here it is, an Aida version of it! I also prepared a short description with screenshots and code snippets, together of installation on Pharo, so you can try it by yourself: http://www.aidaweb.si/todo-description Please review this description and study the code, I really like to hear your opinion! To install in on recent Pharo, first download Pharo one-click: https://gforge.inria.fr/frs/download.php/28437/Pharo-1.2.1-OneClick.zip Then run following script: Gofer new squeaksource: 'AidaAddons'; package: 'ConfigurationOfAidaToDoExample'; load. (Smalltalk at: #ConfigurationOfAidaToDoExample) load. Aida will start running immediately, open in web browser a ToDo example at: http://localhost:8888/todo Best regards Janko [1] http://forum.world.st/Comparison-of-Aida-Web-Seaside-and-Iliad-web-framewor… [2] http://forum.world.st/Comparison-by-example-tt3619333.html -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Aug. 17, 2011

Re: [Pharo-project] Policy for storing metacello configurations

by StÃ©phane Ducasse

What I would like is that the published conf in the distro projects should get loaded, tests run.... automatically. Stef On Aug 17, 2011, at 8:14 PM, Johan Brichau wrote: > Maybe a bit of wishful thinking butâ¦ > > Ideally, I think of the metacellorepository as a kind of 'smart folder' where all metacello configurations of public repositories are automatically included. > Something like a smart mail folder on mac mail. > > Having two locations with the same package almost always leads to confusion / mistakes / forgetting / etcâ¦ > > Would such an 'automatic' repository be possible to implement in squeaksource3 and/or smalltalk hub? > > Johan > > On 17 Aug 2011, at 20:01, StÃ©phane Ducasse wrote: > >> >> The policy should be >> - put a configurationOf in your package >> - publish when you want a copy of it in metacellorepository >> >> I will sit with dale sunday because we want the "publish" to copy all the dependent package also in the DistributionMetacelloRepository >> >> On Aug 17, 2011, at 8:59 AM, Max Leske wrote: >> >>> I would like to complain a bit about the current way Metacello configurations are distributed in different repositories. I ended up using the wrong configuration for two different projects twice in just two days. Apart from the date in the configuration file (and possibly the version number, although that's not as reliable) there's no easy way to tell which configuration is the most recent. >>> >>> Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦). >>> >>> Can we please agree on a simple policy on where to store the configuration for a project? I am sure that this would make life easier for all of us. >>> >>> Cheers, >>> Max >> >> > >

Aug. 17, 2011

Re: [Pharo-project] Policy for storing metacello configurations

by Dale Henrichs

Bernat, A while ago, Esteban Lorenzano released the GoferProjectLoader[1] that extends Gofer and allows one to load configurations. For example: Gofer project load: 'Seaside30'; load: 'Pier2'. loads the latest version of Seaside30 and then Pier2 ... there are options for further control ... By default 'Gofer project' looks in the MetacelloRepository, which works but right now subject to problems like the original complaint that started this thread... Stef and I will be talking about the process and implementation for "...looking up which repo and version are the suitable ones" so hopefully we'll come out of ESUG with a plan of action to take care of this problem... Dale [1] http://forum.world.st/ANN-Gofer-Project-Loader-1-0-BETA-td1596415.html ----- Original Message ----- | From: "Bernat Romagosa" <tibabenfortlapalanca(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, August 17, 2011 11:30:30 AM | Subject: Re: [Pharo-project] Policy for storing metacello configurations | | I'm not sure whether this is one of the goals of the community or | whether maybe someone's already heading in this direction, but | something like Gofer install: #myPackage that looked up which repo | and version are the suitable ones would really rock big time. The | apt-get of Pharo, call it... | | | To go on with the apt metaphor, Gofer search: 'whatever' could return | a list of packages the descriptions/names of which matched | 'whatever'. | | | What do you think? | | | | 2011/8/17 Johan Brichau < johan(a)inceptive.be > | | | Maybe a bit of wishful thinking butâ¦ | | Ideally, I think of the metacellorepository as a kind of 'smart | folder' where all metacello configurations of public repositories | are automatically included. | Something like a smart mail folder on mac mail. | | Having two locations with the same package almost always leads to | confusion / mistakes / forgetting / etcâ¦ | | Would such an 'automatic' repository be possible to implement in | squeaksource3 and/or smalltalk hub? | | Johan | | | | | On 17 Aug 2011, at 20:01, StÃ©phane Ducasse wrote: | | > | > The policy should be | > - put a configurationOf in your package | > - publish when you want a copy of it in metacellorepository | > | > I will sit with dale sunday because we want the "publish" to copy | > all the dependent package also in the | > DistributionMetacelloRepository | > | > On Aug 17, 2011, at 8:59 AM, Max Leske wrote: | > | >> I would like to complain a bit about the current way Metacello | >> configurations are distributed in different repositories. I ended | >> up using the wrong configuration for two different projects twice | >> in just two days. Apart from the date in the configuration file | >> (and possibly the version number, although that's not as | >> reliable) there's no easy way to tell which configuration is the | >> most recent. | >> | >> Some people seem to have adopted MetacelloRepository as the | >> standard repository for all configurations, others keep the | >> configuration for a project in the project repositories and a | >> third group uses both repositories (where one repository contains | >> outdated versions of courseâ¦). | >> | >> Can we please agree on a simple policy on where to store the | >> configuration for a project? I am sure that this would make life | >> easier for all of us. | >> | >> Cheers, | >> Max | > | > | | | | | | | -- | Bernat Romagosa. |

Aug. 17, 2011

Re: [Pharo-project] Policy for storing metacello configurations

by Bernat Romagosa

I'm not sure whether this is one of the goals of the community or whether maybe someone's already heading in this direction, but something like Gofer install: #myPackage that looked up which repo and version are the suitable ones would really rock big time. The apt-get of Pharo, call it... To go on with the apt metaphor, Gofer search: 'whatever' could return a list of packages the descriptions/names of which matched 'whatever'. What do you think? 2011/8/17 Johan Brichau <johan(a)inceptive.be> > Maybe a bit of wishful thinking butâ¦ > > Ideally, I think of the metacellorepository as a kind of 'smart folder' > where all metacello configurations of public repositories are automatically > included. > Something like a smart mail folder on mac mail. > > Having two locations with the same package almost always leads to confusion > / mistakes / forgetting / etcâ¦ > > Would such an 'automatic' repository be possible to implement in > squeaksource3 and/or smalltalk hub? > > Johan > > On 17 Aug 2011, at 20:01, StÃ©phane Ducasse wrote: > > > > > The policy should be > > - put a configurationOf in your package > > - publish when you want a copy of it in metacellorepository > > > > I will sit with dale sunday because we want the "publish" to copy all the > dependent package also in the DistributionMetacelloRepository > > > > On Aug 17, 2011, at 8:59 AM, Max Leske wrote: > > > >> I would like to complain a bit about the current way Metacello > configurations are distributed in different repositories. I ended up using > the wrong configuration for two different projects twice in just two days. > Apart from the date in the configuration file (and possibly the version > number, although that's not as reliable) there's no easy way to tell which > configuration is the most recent. > >> > >> Some people seem to have adopted MetacelloRepository as the standard > repository for all configurations, others keep the configuration for a > project in the project repositories and a third group uses both repositories > (where one repository contains outdated versions of courseâ¦). > >> > >> Can we please agree on a simple policy on where to store the > configuration for a project? I am sure that this would make life easier for > all of us. > >> > >> Cheers, > >> Max > > > > > > > -- Bernat Romagosa.

Aug. 17, 2011

Re: [Pharo-project] [squeak-dev] new Cog VMs available

by Lukas Renggli

Hi Eliot, This is great news. I am totally happy that I can get accurate coverage data again :-) Unfortunately there is a new problem: The VM sometimes crashes when running the coverage analysis. I am using the same test setup (http://jenkins.lukas-renggli.ch/job/PetitParser/lastSuccessfulBuild/artifac…) that I described in my previous mail. Using the TestRunner about 1 in 5 times running the coverage analysis on AST-Tests-Semantics crashes the VM. Programmatically it also happens, but even less often: runner := TestRunner new. runner categoryAt: 8 put: true. runner runCoverage I've also attached the "crash.dmp" the VM generates. Anyway, cog rocks. Thanks a lot for your continuous efforts on making it the best Smalltalk VM out there. Lukas On 17 August 2011 03:09, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > inÂ http://www.mirandabanda.org/files/Cog/VM/VM.r2487/. > Fix bugs described in the "[Pharo-project] Troubles with #flushCache and > #run:with:in:" thread http://lists.gforge.inria.fr/pipermail/pharo-project/ > 2011-July/050858.html. Â The PIC machinery wrongly treated invoke-as-method > sends as MNUs. > Closely related, finally fully implement PIC MNU cacheing where, by calling > a > special abort, a PIC is able to record that a gven selector is an MNU for a > particular class. Â Speeds up a simple MNU benchmark by 33% (with more > performance the deeper the receiver's cass hierarchy is). > On Mac fix mis-editing of Info.plist to insert revision info so that VM .app > once again starts on 10.5.x. > -- > best, > Eliot > > > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 17, 2011

Re: [Pharo-project] Policy for storing metacello configurations

by Johan Brichau

Maybe a bit of wishful thinking butâ¦ Ideally, I think of the metacellorepository as a kind of 'smart folder' where all metacello configurations of public repositories are automatically included. Something like a smart mail folder on mac mail. Having two locations with the same package almost always leads to confusion / mistakes / forgetting / etcâ¦ Would such an 'automatic' repository be possible to implement in squeaksource3 and/or smalltalk hub? Johan On 17 Aug 2011, at 20:01, StÃ©phane Ducasse wrote: > > The policy should be > - put a configurationOf in your package > - publish when you want a copy of it in metacellorepository > > I will sit with dale sunday because we want the "publish" to copy all the dependent package also in the DistributionMetacelloRepository > > On Aug 17, 2011, at 8:59 AM, Max Leske wrote: > >> I would like to complain a bit about the current way Metacello configurations are distributed in different repositories. I ended up using the wrong configuration for two different projects twice in just two days. Apart from the date in the configuration file (and possibly the version number, although that's not as reliable) there's no easy way to tell which configuration is the most recent. >> >> Some people seem to have adopted MetacelloRepository as the standard repository for all configurations, others keep the configuration for a project in the project repositories and a third group uses both repositories (where one repository contains outdated versions of courseâ¦). >> >> Can we please agree on a simple policy on where to store the configuration for a project? I am sure that this would make life easier for all of us. >> >> Cheers, >> Max > >

Aug. 17, 2011

Re: [Pharo-project] <deprecated> annotation?

by Philippe Marschall

On 17.08.2011 16:05, HernÃ¡n Morales Durand wrote: > Hi Lukas, Igor > > 2011/8/17 Lukas Renggli <renggli(a)gmail.com>: >>>>> How would that help anybody to find out whether they are relying on >>>>> deprecated methods? This seems like a big step backwards form a user >>>>> point of view. Suddenly a method is gone and you didn't get a warning. >>>>> You are you supposed to check for deprecated methods? Debug each and >>>>> every one of your message sends? >>>> >>>> +1, such an annotation is totally counterproductive. >>> >>> Provide an alternative. >>> Imagine that we're want to deprecate Array>>at: >> >> Disable the deprecateded notifications in the system settings. Like >> this you acknoledge that you use outdated code; and if this gets too >> annoying you might want to actually fix it. >> > > What I don't like of disabling deprecations is that is black or white. > You get deprecations or you don't get at all. My view is that > deprecations are context dependent, I want to disable them: > -For this package > -For this class That's a good point. Cheers Philippe

Aug. 17, 2011