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

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

Re: [Pharo-project] Squeaksource not synchronized

by Marcus Denker

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, Stef and I are going to talk at ESUG about the procedures/recommendations/tools for managing configurations in Pharo. 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:) Dale ----- Original Message ----- | From: "Damien Pollet" <damien.pollet(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, August 17, 2011 12:56:10 AM | Subject: Re: [Pharo-project] Policy for storing metacello configurations | | On 17 August 2011 08:59, Max Leske <maxleske(a)gmail.com> wrote: | > 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â¦). | | The MetacelloConfiguration belongs to the project and is under | responsibility of the developers, so one should be in the project's | repo. | | MetacelloRepository is the central well-known place, so maybe only | versions with a stable release really need to be there? | | There will be other well-known places, the idea is to have a curated | one for each version of Pharo I believe. | | In any case, maybe part of this should be docuplemented into | MetacelloToolBox ? | | (PS. toolbox is a proper english word, so that capital B in the class | name is unnecessary :) | -- | Damien Pollet | type less, do more [ | ] http://people.untyped.org/damien.pollet | |

Aug. 17, 2011

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

by Dale Henrichs

Max, You have reason to complain... Not all projects use Metacello so there are still cases where the configuration is only found in the MetacelloRepository. Sometimes developers forget to copy the configurations to the MetacelloRepository. And so on.... In self defense: 1. Use the configuration found in the project repository. 2. Use the configuration found in MetacelloRepository If there are configs in both places and they are not in synch, contact the project maintainers and let them know. If you want to _know_ which config file is later (and whether or not they are even related), you can look at the history for both files and compare UUIDs or find a common ancestor based on UUID. Examining the ancestry of a version is the only way to know how two different mcz relate to one another. If you have two mcz files with a common ancestor, you are still confronted by a dilemma as to which one should you use.... With all that said, I am interested in knowing what was "wrong" with the configurations. Were they two unrelated branches of a configuration or was one configuration way out of date with respect to the other, or??? I'm asking because from a Metacello perspective once a Metacello version is released it should never be changed and that means that for released versions it doesn't matter whether or not you are using the latest configuration, unless the configurations are way out of date. If you are usinga Metacello version that is still under #development then it does matter whether or not you are using the latest configuration. Dale ----- Original Message ----- | From: "Max Leske" <maxleske(a)gmail.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, August 16, 2011 11:59:59 PM | Subject: [Pharo-project] Policy for storing metacello configurations | | 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

[Pharo-project] Squeaksource not synchronized

by Torsten Bergmann

>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. 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

Aug. 17, 2011

Re: [Pharo-project] Squeaksource not synchronized

by Fabrizio Perin

It seems not working. Could you please double check? I don't know how to proceed. Someone have any idea? 2011/8/17 Fabrizio Perin <fabrizio.perin(a)gmail.com> > I will try to run a script that should fix it now. So SS will be down for > some minuts > > cheers, > > Fabrizio > > > 2011/8/17 Torsten Bergmann <astares(a)gmx.de> > >> Trouble with SqS again: >> >> JQWidgetBox-Dynatree-Core-tbn.1.mcz >> JQWidgetBox-Dynatree-Core-tbn.2.mcz >> JQWidgetBox-Dynatree-Core-tbn.3.mcz >> JQWidgetBox-Dynatree-Dev-tbn.1.mcz >> JQWidgetBox-Dynatree-Dev-tbn.2.mcz >> JQWidgetBox-Dynatree-Dev-tbn.3.mcz >> >> I saved them yesterday to SqS - then later Squeaksource went down and was >> restarted. I was not able to find them today using the web ui. >> So I tried to upload them using the squeaksource web ui - but >> failed since it complained that "they are not in mcz format" (???) >> >> So I used the "Copy" functionality from MetacelloBrowser to >> copy them from the local cache to squeaksource. >> This worked and now they are in the repo >> http://www.squeaksource.com/JQueryWidgetBox >> when I look at the repo using the Monticello browser from the image. >> >> But still they are not visible in the squeaksource web ui of the project: >> http://www.squeaksource.com/JQueryWidgetBox.html >> >> The other two from today >> >> JQWidgetBox-Dynatree-Core-tbn.4.mcz >> JQWidgetBox-Dynatree-Dev-tbn.4.mcz >> >> are visible in both (Monticello and Squeaksource web ui) - correct. >> >> Looks like the contents on disk is not in sync with the data the >> squeaksource image holds. >> >> Any idea? >> >> Bye >> T. >> -- >> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! >> Jetzt informieren: http://www.gmx.net/de/go/freephone >> >> >

Aug. 17, 2011

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

by HernÃ¡n Morales Durand

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 and -For this execution context (or "session") -Always Why? Because I'm working in other parts of the code and now I don't want to care deprecations in an unrelated package/class, but I know later I'd like to see them. HernÃ¡n

Aug. 17, 2011

[Pharo-project] primitiveSetGCSemaphore puzzle

by Igor Stasenko

I am a bit puzzled with this primitive. There is no sender of #setGCSemaphore: semaIndex in image, and VM seems like using it for signaling semaphore as a post-GC action. I expected that it is finalization process, which should use that guy.. but no, it just using special objects array indice: restartFinalizationProcess ... FinalizationSemaphore := Smalltalk specialObjectsArray at: 42. ... Apparentlly , each time we have GC, the finalization semaphore is signaled. So, it makes me wonder, how it working because i see that VM signals semaphore in postGCAction, which should be set by the mentioned primitive. -- Best regards, Igor Stasenko AKA sig.

Aug. 17, 2011