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

[Pharo-project] squeaksource is down

by Torsten Bergmann

... again -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Aug. 16, 2011

Re: [Pharo-project] [Seaside] seaside #stable on pharo.13?

by Dale Henrichs

Aug. 16, 2011

Re: [Pharo-project] Building vs. Stone carving (was: some explanations about what we are doing :)

by StÃ©phane Ducasse

I agree with what igor said. Now give us or join to build one of these items - a fast way to load package (fuel but there is still some work) - a spec for managing packages (metacello) - a set of tests (we have some but we need more) - a bootstrap (with have a mini image so this could be ok). and we will build and not carve and we will maintain a full set of packages. So we are getting there but this is not good to not test/use all day long what we release. So this will be like that for a moment but our goal is what I mention above: rebuilding from scratch all the pieces all the time and fast and we will get there. Stef On Aug 16, 2011, at 8:21 PM, Torsten Bergmann wrote: > Stef/Mariano wrote: >>> So now we are including several packages in the image so that we do not have two images. >>> >>> I am not against this, but I think it is a must to provide a #shrinkToPharoCore and a hudson associated to that. >> >> yes good idea > > Interesting (nearly silent) switch in the way we build Pharo(core). > > > With one "Core" and several distro packages like "pharo-dev", "seaside" > we once switched to the model anyone is used to in other technology sectors: > building a house or a machine by stacking up/assembling small pieces. > So we had a "start with a base/core and load what you need" model > similar to Linux kernel and distros. So you could pick up what you need. > > I thought this is the right model - since we can cleanly load > and keep images small while checking if something is running > after loading with CI/Hudson. > > But now we extract the kernel/core from the (bloated?) distro. > > For whatever reason I often see this tradition of "Stone carving" in > Smalltalk. One has a large image and strips it down for deployment > (throw out what you do not need). Often you get problems in unloading/ > clean loading again. Classes are referenced across the image without > checking the load order, ... > > > Mmmmhhh ... who shares the same feeling that this is not a good idea! > When there is a #shrinkToPharoCore then there is a pharo core image > anyway - so we always have two images. And we have to test it and > check if packages load cleanly anyway (using CI). > > Can you at least ellaborate what led to this step? Is PharoKernel > the new Pharo Core? Will we test reloading after shrinking? ... > > Thx > T. > > > > > > > > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

Aug. 16, 2011

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

by StÃ©phane Ducasse

Ok you won! But we want a nice comment in all deprecated methods :) Stef On Aug 16, 2011, at 7:55 PM, Igor Stasenko wrote: > Currently i run upon this situation, when annotation is the only > possible choice: > > SmalltalkImage>>vmParameterAt: parameterIndex > "This method is deprecated. > > We're not putting a #deprecated: message here, because then it will > produce a lot of warnings" > > <deprecated> > > ^ self vm parameterAt: parameterIndex > > -- > Best regards, > Igor Stasenko AKA sig. >

Aug. 16, 2011

[Pharo-project] Fwd: [Pharo-fuel] Two nice things I did in 2 hours with Fuel

by StÃ©phane Ducasse

This clearly opens the door to really amazing experiment. Stef > From: Mariano Martinez Peck <marianopeck(a)gmail.com> > Date: August 16, 2011 8:58:03 PM GMT+02:00 > To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > Subject: [Pharo-fuel] Two nice things I did in 2 hours with Fuel > Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > 1) serialize a living debugger, materialize it in another image and continue debugging. > 2) use Fuel to serialize a graph to a bytearray and then store and retrieve that from the Riak NoSQL database :) > > coooool! > > -- > Mariano > http://marianopeck.wordpress.com > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

Aug. 16, 2011

Re: [Pharo-project] seaside #stable on pharo.13?

by Philippe Marschall

On 16.08.2011 12:23, Marcus Denker wrote: > > On Aug 16, 2011, at 12:18 PM, Tudor Girba wrote: > >> Hi, >> >> The ConfiguraitonOfSeaside does not define any #stable version for Pharo 1.3. >> >> Is it intentional or is it simply because the configuration is not up to date? > > > The configuration is not up to date... would be nice to fix it. And it would be good > to have a version that loads a minimal seaside (no OB, which I think this does). That should actually work. You just need to define what you mean with minimal (probably Seaside-Component and Seaside-Canvas and probably Seaside-Flow as well). As long as you stay away from Seaside-Tools-OmniBrowser it shouldn't load OB. Cheers Philippe

Aug. 16, 2011

Re: [Pharo-project] Building vs. Stone carving (was: some explanations about what we are doing :)

by Igor Stasenko

The root of the problem, that we don't have enough resources to maintain two different images: core and dev. So we decided to keep only one release artifact since 1.4. It will be bigger than existing Pharo-Core, but i think smaller than older Pharo-Dev images. It is all about optimizing our workload, and to make sure that things we're releasing is working and well tested. Because in 1.2-1.3 we have issues with this separation (i think you aware of that). Concerning building vs carving: i agree, we should build rather than carving :) But testing that parts of image could be unloaded/thrown away is also useful. On 16 August 2011 20:21, Torsten Bergmann <astares(a)gmx.de> wrote: > Stef/Mariano wrote: >>> So now we are including several packages in the image so that we do not have two images. >>> >>> I am not against this, but I think it is a must to provide a #shrinkToPharoCore and a hudson associated to that. >> >>yes good idea > > Interesting (nearly silent) switch in the way we build Pharo(core). > > > With one "Core" and several distro packages like "pharo-dev", "seaside" > we once switched to the model anyone is used to in other technology sectors: > building a house or a machine by stacking up/assembling small pieces. > So we had a "start with a base/core and load what you need" model > similar to Linux kernel and distros. So you could pick up what you need. > > I thought this is the right model - since we can cleanly load > and keep images small while checking if something is running > after loading with CI/Hudson. > > But now we extract the kernel/core from the (bloated?) distro. > > For whatever reason I often see this tradition of "Stone carving" in > Smalltalk. One has a large image and strips it down for deployment > (throw out what you do not need). Often you get problems in unloading/ > clean loading again. Classes are referenced across the image without > checking the load order, ... > > > Mmmmhhh ... who shares the same feeling that this is not a good idea! > When there is a #shrinkToPharoCore then there is a pharo core image > anyway - so we always have two images. And we have to test it and > check if packages load cleanly anyway (using CI). > > Can you at least ellaborate what led to this step? Is PharoKernel > the new Pharo Core? Will we test reloading after shrinking? ... > > Thx > T. > > > > > > > > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > -- Best regards, Igor Stasenko AKA sig.

Aug. 16, 2011

Re: [Pharo-project] [Seaside] seaside #stable on pharo.13?

by Tudor Girba

Hi, Dale, as the main maintainer of the configuration, would you be available to give a hand with this? Cheers, Doru On 16 Aug 2011, at 13:10, Lukas Renggli wrote: > All the latest packages work well in Pharo 1.3, especially in combination with Zinc (so the dependency to Kom could be removed). > > Lukas > > On Tuesday, 16 August 2011, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On Aug 16, 2011, at 12:18 PM, Tudor Girba wrote: > > > >> Hi, > >> > >> The ConfiguraitonOfSeaside does not define any #stable version for Pharo 1.3. > >> > >> Is it intentional or is it simply because the configuration is not up to date? > > > > > > The configuration is not up to date... would be nice to fix it. And it would be good > > to have a version that loads a minimal seaside (no OB, which I think this does). > > > > -- > > Marcus Denker -- http://marcusdenker.de > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Aug. 16, 2011

[Pharo-project] Building vs. Stone carving (was: some explanations about what we are doing :)

by Torsten Bergmann

Stef/Mariano wrote: >> So now we are including several packages in the image so that we do not have two images. >> >> I am not against this, but I think it is a must to provide a #shrinkToPharoCore and a hudson associated to that. > >yes good idea Interesting (nearly silent) switch in the way we build Pharo(core). With one "Core" and several distro packages like "pharo-dev", "seaside" we once switched to the model anyone is used to in other technology sectors: building a house or a machine by stacking up/assembling small pieces. So we had a "start with a base/core and load what you need" model similar to Linux kernel and distros. So you could pick up what you need. I thought this is the right model - since we can cleanly load and keep images small while checking if something is running after loading with CI/Hudson. But now we extract the kernel/core from the (bloated?) distro. For whatever reason I often see this tradition of "Stone carving" in Smalltalk. One has a large image and strips it down for deployment (throw out what you do not need). Often you get problems in unloading/ clean loading again. Classes are referenced across the image without checking the load order, ... Mmmmhhh ... who shares the same feeling that this is not a good idea! When there is a #shrinkToPharoCore then there is a pharo core image anyway - so we always have two images. And we have to test it and check if packages load cleanly anyway (using CI). Can you at least ellaborate what led to this step? Is PharoKernel the new Pharo Core? Will we test reloading after shrinking? ... Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Aug. 16, 2011

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

by Igor Stasenko

Currently i run upon this situation, when annotation is the only possible choice: SmalltalkImage>>vmParameterAt: parameterIndex "This method is deprecated. We're not putting a #deprecated: message here, because then it will produce a lot of warnings" <deprecated> ^ self vm parameterAt: parameterIndex -- Best regards, Igor Stasenko AKA sig.

Aug. 16, 2011