- Pharo-dev - lists.pharo.org

[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

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

by StÃ©phane Ducasse

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 Lukas Renggli

> Â 1. Use the configuration found in the project repository. > Â 2. Use the configuration found in MetacelloRepository The following code would do that automatically (i.e. for Moose): Gofer new squeaksource: 'Moose'; squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 17, 2011

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

by Damien Pollet

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