- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
by Esteban Lorenzano March 17, 2010

March 17, 2010

Hi, I want to announce the immediate release of GoferProjectLoader, a Gofer extension to manage Metacello configurations. For all who want to know quickly what is this, here is a small synopsis: GoferProjectLoader is a loader for Metacello configurations (A metacello configuration is a full project load tool, including package/project dependencies with it corresponding versions). GoferProjectLoader automatically scan projects stored on MetacelloRepository, but you can add your private repositories as well. GoferProjectLoader responsibilities include: 1) Install project versions and keep track of them. 2) Update configurations and upgrade projects (if desired). GoferProjectLoader relies on Metacello and Gofer to perform this tasks (In fact, It can be thought as a Gofer extension to understand Metacello packages). To load GoferProjectLoader, you need to do: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGoferProjectLoader'; load. ConfigurationOfGoferProjectLoader project lastVersion load. With this... you'll never need again to perform once and again this repetitive configuration... instead, you can do things like: Gofer project load: 'Seaside30'; load: 'Pier2'. You can see the full documentation here: http://www.smallworks.com.ar/en/community/GoferProjectLoader Now I'm working on the promised page for configurations (Adrian: I really sorry for the delay... I know I promised this a lot of time ago... but time is the tyrant :( ) Cheers, Esteban

9 15

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
by Dale Henrichs March 17, 2010

March 17, 2010

----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | > load involves loading a project into an image in which the project | > does not exist. | > upgrade involves loading a project into an image in which the | > project already is loaded. | > | > Loading is straightforward ... it is what we do all of the time. Add | > a bunch of classes and methods, then run the #initialize methods for | > the new classes. | > | > Upgrading is interesting because besides adding/removing classes and | > methods, you have to worry about completely unloading packages that | > are no longer part of the project. You also have to worry about the | > fact that new classes will get there #initialize methods, but | > preexisitng classes will not ... which can lead to interesting | > results. This may lead to pre/post upgrade doits... | | I easily understand the difference. I was just wondering whether load: | cannot do an update: if the package is present already. Maybe as I | user I should not take care whether a package is already present | before loading it. Just a thought. That is probably a good idea ... the less someone has to think before running a script the better, as long as the 'right thing is done'.

1 0

[Pharo-project] May be there is a problem with ChangeSet
by StÃ©phane Ducasse March 17, 2010

March 17, 2010

Apparently I have methods that are cut.... and I cannot load the file back.... I cannot save with MC either. :( Stef

1 1

[Pharo-project] Fix 1973: PluggableTreeMorph class#on:list:selected:changeSelected: inconsistency
by laurent laffont March 17, 2010

March 17, 2010

in PharoInbox. http://code.google.com/p/pharo/issues/detail?id=1973 Laurent Laffont

1 0

[Pharo-project] Code Freeze 1.1?
by Marcus Denker March 17, 2010

March 17, 2010

Hi, Now with 1.0 done, I think we should think about freezing 1.1. The main reason of course is that 1.1 is *far more pleasent* to use than 1.0. The other thing is that 1.1 did change quite some things that have impact on external code (Preferences, as an example). So I think we should -> start slowing down on 1.1 (Stef suggested that already) -> start polishing (tests...) -> start to look at the Dev image. -> Official code freeze end of March. -> Release if possible end of April (this of course depends on the state of things). Any reasons against? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

8 19

[Pharo-project] eCompletion works on Pharo 1.1
by Lukas Renggli March 17, 2010

March 17, 2010

I fixed eCompletion (and all its long broken tests) to work on Pharo 1.0 and 1.1. http://source.lukas-renggli.ch/unsorted/ECompletion-lr.113 Similar to the refactoring engine the new settings framework is used now. This means to set the preferences you either use Pharo 1.1 or manually use the accessors on the class side of ECPreference. Name: ECompletion-lr.113 Author: lr Time: 17 March 2010, 8:20:03 pm UUID: 0d16cf1e-ff4b-4674-8045-d10cfc2e25d6 Ancestors: ECompletion-lr.112 - fixed all tests - updated to Pharo 1.1 Lukas -- Lukas Renggli http://www.lukas-renggli.ch

2 1

[Pharo-project] [update 1.1] #11277
by stephane ducasse March 17, 2010

March 17, 2010

11277 ----- - Issue 2151: Cleaning of and test for MessageTally. Thanks Alexandre - Issue 2158: Pharo 1.1 deprecation fixes for Refactoring Engine. Thanks Lukas. - SunitGUI fixed priority of coloring test result: if there are errors then red else if there are failures then yellow else -> green - implemented RxMatcher>>split: thanks Fabrizio Stef

1 0

[Pharo-project] Pharo 1.1 deprecation fixes for Refactoring Engine
by Lukas Renggli March 17, 2010

March 17, 2010

Please integrate: <http://code.google.com/p/pharo/issues/detail?id=2158> Name: System-Support-LukasRenggli.263 Author: lr Time: 17 March 2010, 7:30:53 pm UUID: a7e86013-b12d-4d66-bc45-92990f5813f5 Ancestors: System-Support-StephaneDucasse.262 - added 3 more deprecated methods that are required in SmalltalkImage by the refactoring engine: #keyAtValue:, #keysAndValuesDo: and #select: -- Lukas Renggli http://www.lukas-renggli.ch

2 1

Re: [Pharo-project] [Metacello] [ANN] Gofer Project Loader 1.0 (BETA)
by Miguel Enrique CobÃ¡ Martinez March 17, 2010

March 17, 2010

El miÃ©, 17-03-2010 a las 10:38 -0300, Esteban Lorenzano escribiÃ³: > Hi, > I want to announce the immediate release of GoferProjectLoader, a > Gofer extension to manage Metacello configurations. > For all who want to know quickly what is this, here is a small > synopsis: > > > GoferProjectLoader is a loader for Metacello configurations > (A metacello configuration is a full project load tool, > including package/project dependencies with it corresponding > versions). > GoferProjectLoader automatically scan projects stored > on MetacelloRepository, but you can add your private repositories as > well. > GoferProjectLoader responsibilities include: > > > 1) Install project versions and keep track of them. > 2) Update configurations and upgrade projects (if desired). > > > GoferProjectLoader relies on Metacello and Gofer to perform this > tasks (In fact, It can be thought as a Gofer extension to > understand Metacello packages). > > > To load GoferProjectLoader, you need to do: > > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfGoferProjectLoader'; > load. > > > ConfigurationOfGoferProjectLoader project lastVersion load. > > > With this... you'll never need again to perform once and again > this repetitive configuration... instead, you can do things like: > > > Gofer project > load: 'Seaside30'; > load: 'Pier2'. > > > You can see the full documentation here: > http://www.smallworks.com.ar/en/community/GoferProjectLoader > > > Now I'm working on the promised page for configurations... Cool, very good work. Now, what is the possibility to add this to the PharoCore 1.0 release? > > > Cheers, > Esteban -- Miguel CobÃ¡ http://miguel.leugim.com.mx

3 3

March 17, 2010

Hi I started to reimplement the package class is did because the previous one was a bit messy. I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. I started to build a stupid browser to check my api. Doru started to code a Glamour browser to see if this was ok. Now I would really like if - somebody could have a look at the code - develop a simple package browser showing class extensions (it would help me to define a good api to walk though a package). I started to use Momo and this is why I reimplemented the class but so far I get nearly the same interface and I think that I can do better. Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able to release a first version. So far - integration with MC - migrating from packageInfo - event notification are missing. Stef

5 36