- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Metacello] Re: [Seaside] New structure for Seaside30, Magritte2, and Pier2 Metacello configurations

by Dale Henrichs

Mariano, Yes that's what I was thinking. I plan on updating the Seaside config and workspace ... but I wanted to make sure I wasn't headed off in some wild direction first:) I think that the minimum is to have a deployment group that loads just what is needed ... Development becomes a stickier issue, because it isn't always clear what should be included ... I think that with Metacello, one can be very explicit about what pieces one wants to load...it would be nice to have a minimal development group that adds just what is needed to do development (i.e., trying to debug a sticky production problem you'd like to load only what you need and getting examples and a bunch of other stuff isn't something you'd want to load into a production environment ... ). I think that one can leverage groups in Metacello which means that in an application one can afford to use _more_ mcz files...providing fine granularity on what can be loaded (even down to the level of a class per mcz file for things like independent components)...I wouldn't think that everything should be reduced to that fine of a granularity...but there are advantages to breaking things up into smaller loadable chunks... Dale Mariano Martinez Peck wrote: > Hi Dale. I didn't test it, but from the theorical point of view, I > really like it. I hope other people too. I think we have to take > advantage of Metacello features to do this kind of stuff. > > It is very interesting to have two groups: one for the core (and > probably deployment) and one for development. > > If you do this changes, please update the workspace of > ConfigurationOfSeaside explaining this :) > (sorry if you already did it) > > Cheers > > mariano > > On Sun, Jun 27, 2010 at 7:54 PM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@vmware.com>> wrote: > > I am looking for a little feedback on the changes that I have made > to the latest configurations of Seaside30, Magritte2, and Pier2. I > have new versions for each of these configurations queued up for > release (#development blessing), but before releasing them I'd like > to hear if the changes I've made will cause trouble for folks using > Magritte2 and/or Pier2 in their applications. > > In the past, when you referenced Seaside30 from a configuration, the > entire Seaside3.0 release would be loaded, including development > tools, examples, both adaptors (on Squeak/Pharo and > GemStone)...basically the whole kitchen sink. > > With the 3.0.0-alpha5.15 release I've defined several groups for > Seaside3.0 (with feedback from the Seaside devs:): Base, Base Tests, > Development and Development Tests. I will also add a One-click group > to shdow the one-click release. Without going into too much detail, > the Base group defines the set of packages that are needed for a > production release, while the Development group defines the set of > packages that are useful in development (on top of the Base). > > To see how these new groups work out, I have created new versions of > the configurations for Magritte2 and Pier2 that reference the Base > group (plus any other packages that were needed) instead of bringing > in the entire Seaside3.0 release...This is the big change. After > loading the Magritte2 or Pier2 configuration you will need to load > from the Seaside30 configuration any and all packages that you may > need for your own application. > > I haven't released the changes yet, but if you are curious or > concerned you can try out the releases ahead of time ... depending > upon feedback I may go with a different scheme. > > In a fresh image, you can see what will be loaded for production by > executing one or more of the following expressions (note you need to > get the latest version of each of the configs from the SqueakSource > MetacelloRepository...oh and for best results use Metacello > 1.0-beta.27.1): > > (ConfigurationOfMagritte2 project version: '2.0.5') load. > (ConfigurationOfPier2 project version: '2.0.6') load. > (ConfigurationOfPierAddOns2 project version: '2.0.6') load. > > Once you've loaded one of these configs, there will be no > development tools nor any adaptors so at a minimum you'll need to > load one of the following depending upon which adaptor you want to use: > > "All platforms" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-Swazoo'). > "Squeak and Pharo" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-Comanche'). > "GemStone" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-FastCGI'). > > If you want to load in the Seaside development environment then you > would evaluate the following expression: > > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Development'). > > So at this point you can see the direction I'm going with this ... > the Magritte2 and Pier2 configurations are currently aimed at > loading the bare minimum needed for functionality from Seaside3.0 > for Magritte2 and Pier2 with the idea that you'd load the additional > functionality that you want by dealing directly with Seaside30 > configuration (like loading adaptors and development)... > > Pier2 already depends upon the following javascript packages: > > 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' 'JQuery-UI' > > but if you're currently using Magritte2 and javascript, then you'll > need to explicitly load the javascript package(s) that you are using. > > There are other ways that the configs could be structured. This > approach minimizes the coupling between the Seaside3.0 and > Magritte2/Pier2 configurations, which I think is a good thing. > > I've taken the bare minimum step: loading what is required... it > would be reasonable to add 'Dev' groups to both Magritte2 and Pier2 > that would bring in Seaside30 dev support on the other hand, I don't > think it is reasonable to add support for loading the various > Adaptors to Magritte2 and Pier2, so if you're going to have to deal > with the Seaside30 config directly anyway why bother with adding dev > groups ... > > Anyway this is what _I_ think and I am interested in what you folks > think... > > For GemStone folks ... the answer is yes, Magritte2 and Pier2 have > been ported to GemStone/S 64 2.4 finally:). If you've been working > with Seaside3.0 already, you can load the > Magritte2/Pier2/PierAddOns2 configs into a fresh > 1.0-beta.8....otherwise I'll ask you to wait until I announcement. > > Dale > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > <mailto:seaside@lists.squeakfoundation.org> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > >

June 28, 2010

[Pharo-project] [update 1.2] #12023

by StÃ©phane Ducasse

12023 ----- - Issue 2577: Duplicate primInitializeNetwork: method I found the bug in Scriptloader too :) Stef

June 28, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by Johan Fabry

+1 on this. Marcus, we have to talk about Persephone when I'm visiting in Sept! On 28 Jun 2010, at 13:10, Marcus Denker wrote: > > On Jun 28, 2010, at 1:46 AM, Eliot Miranda wrote: > >> Note: The Cog VM crashes on TestObjectsAsMethods. >> >> Yes. I never tried to get this to work. How important is this to people? > > For Research: very. Lots of the experiments we did at SCG used this at least at some > stage of implementing the prototype: > > -> For the AOSTa experiments I looked at it originally > (see http://www.slideshare.net/MarcusDenker/diplom-vortrag-slides) > -> Persephone and therefore Reflectivity: http://scg.unibe.ch/research/reflectivity > -> ChangeBoxes used it: http://scg.unibe.ch/scgbib?query=Denk07c&display=abstract > -> I think ClassBoxes, too > -> The most commonly used implementation of MethodWrappers these days uses it > (and is *much* simpler than the method-compilation-stub-generating one) > > It's a quite nice way to hook into "method execution" without having to resort to compile a stub method. > If you need an "in-image" JIT of some sort, it provides a real nice way of doing this purely from the > image side (no VM change needed): > > http://scg.unibe.ch/scgbib?query=Denk07b&display=abstract > > I think Andreas originally suggested ObjectsAsMethods years ago and I then made sure that it was > integrated in the VM, as the AOStA experiments showed how powerful this can be for experiments. > > AOStA had to use a patched VM, then later persephone could run on a standard VM, which simplified things a lot... > > Yes, stub-methods can do anything (and with care can be faster), and having a good code-generation framework > simplified actually doing this a lot.... e.g. one can use bytesurgeon and do it on the level of bytecode. > (the paper uses MethodWrappers as an example: http://scg.unibe.ch/cgi-bin/scgbib.cgi/abstract=yes?Denk06a) > Or just the RB AST (with the code generator), maybe helped by Helvetia's quoting... > (more on Helevetia's quoting implementation: http://scg.unibe.ch/research/helvetia/languageboxes) > > Nut nevertheless: a MOP for method execution is very valuable not just from an implementation standpoint, even more > from a concepual / thinking point of view. Good MOPs provide a better way of *thinking*, they enable exploration. > > I always rated this as one of those changes that, while being simple, opened up a lot of space for experiments. > > And it showed to me the value of a platform where a change like this is integrated and not ignored. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

June 28, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by Marcus Denker

On Jun 28, 2010, at 1:46 AM, Eliot Miranda wrote: > Note: The Cog VM crashes on TestObjectsAsMethods. > > Yes. I never tried to get this to work. How important is this to people? For Research: very. Lots of the experiments we did at SCG used this at least at some stage of implementing the prototype: -> For the AOSTa experiments I looked at it originally (see http://www.slideshare.net/MarcusDenker/diplom-vortrag-slides) -> Persephone and therefore Reflectivity: http://scg.unibe.ch/research/reflectivity -> ChangeBoxes used it: http://scg.unibe.ch/scgbib?query=Denk07c&display=abstract -> I think ClassBoxes, too -> The most commonly used implementation of MethodWrappers these days uses it (and is *much* simpler than the method-compilation-stub-generating one) It's a quite nice way to hook into "method execution" without having to resort to compile a stub method. If you need an "in-image" JIT of some sort, it provides a real nice way of doing this purely from the image side (no VM change needed): http://scg.unibe.ch/scgbib?query=Denk07b&display=abstract I think Andreas originally suggested ObjectsAsMethods years ago and I then made sure that it was integrated in the VM, as the AOStA experiments showed how powerful this can be for experiments. AOStA had to use a patched VM, then later persephone could run on a standard VM, which simplified things a lot... Yes, stub-methods can do anything (and with care can be faster), and having a good code-generation framework simplified actually doing this a lot.... e.g. one can use bytesurgeon and do it on the level of bytecode. (the paper uses MethodWrappers as an example: http://scg.unibe.ch/cgi-bin/scgbib.cgi/abstract=yes?Denk06a) Or just the RB AST (with the code generator), maybe helped by Helvetia's quoting... (more on Helevetia's quoting implementation: http://scg.unibe.ch/research/helvetia/languageboxes) Nut nevertheless: a MOP for method execution is very valuable not just from an implementation standpoint, even more from a concepual / thinking point of view. Good MOPs provide a better way of *thinking*, they enable exploration. I always rated this as one of those changes that, while being simple, opened up a lot of space for experiments. And it showed to me the value of a platform where a change like this is integrated and not ignored. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 28, 2010

Re: [Pharo-project] [update 1.2] #12020...#12022

by StÃ©phane Ducasse

I'm checking and may be I have a slight bug in the scriptLoader. I will try to investigate it. Stef On Jun 28, 2010, at 5:23 PM, StÃ©phane Ducasse wrote: > 12020 > ----- > - Issue-2448-WideStringDisplayMangled. Part one. Thanks Henrik > > 12021 > ----- > - Issue-2448-WideStringDisplayMangled. Part Two of slice, now with inst var in super, and refactored methods. > Part ONE (ie version 3) needs to be loaded before this one. > (ie. this is needs two separate patches). Thanks Henrik > > 12022 > ----- > - Issue 2597: Versions Browser diff checkboxes. Thanks Gary > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 28, 2010

Re: [Pharo-project] [update 1.2] #12020...#12022

by StÃ©phane Ducasse

I'm checking and may be I have a slight bug in the scriptLoader. I will try to investigate it. Stef On Jun 28, 2010, at 5:23 PM, StÃ©phane Ducasse wrote: > 12020 > ----- > - Issue-2448-WideStringDisplayMangled. Part one. Thanks Henrik > > 12021 > ----- > - Issue-2448-WideStringDisplayMangled. Part Two of slice, now with inst var in super, and refactored methods. > Part ONE (ie version 3) needs to be loaded before this one. > (ie. this is needs two separate patches). Thanks Henrik > > 12022 > ----- > - Issue 2597: Versions Browser diff checkboxes. Thanks Gary > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 28, 2010

[Pharo-project] squeak.org (and expecially source.squeak.org) is down - resolved

by Torsten Bergmann

FYI http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-June/151637.html -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

June 28, 2010

[Pharo-project] [update 1.2] #12020...#12022

by StÃ©phane Ducasse

12020 ----- - Issue-2448-WideStringDisplayMangled. Part one. Thanks Henrik 12021 ----- - Issue-2448-WideStringDisplayMangled. Part Two of slice, now with inst var in super, and refactored methods. Part ONE (ie version 3) needs to be loaded before this one. (ie. this is needs two separate patches). Thanks Henrik 12022 ----- - Issue 2597: Versions Browser diff checkboxes. Thanks Gary Stef

June 28, 2010

Re: [Pharo-project] amount of recheable objects from a root one?

by Noury Bouraqadi

On 27 juin 2010, at 14:41, Mariano Martinez Peck wrote: > Hi folks. I need to do something and I am a little lazy to do it. Maybe someone already did it and can share it with me. I want to take an object X. That object has references to other objects and I imagine that as a graph. > > I need to traverse the graph, and get the final amount of reachable objects from the object X. I mean, the size of that graph. I need to avoid cycles and not count objects already counted. Maybe I can reuse part of SmartRefStream? > Why not using ReferenceStream? It is supposed to handle your problem. Noury

June 28, 2010

Re: [Pharo-project] Panic

by StÃ©phane Ducasse

if you want this code in the next release it should be added in the bugtracker. Stef On Jun 28, 2010, at 4:28 PM, Mariano Abel Coca wrote: > In VAST the name is "Scrub Image". > > What it does is to remove all objects referenced from the UI by redrawing the Transcript and starting a new UI thread, and then making a global GC. That means letting only the global referenced objects alive. > > And here in Mercap we added a "Clean Image" button to also remove singletons and another junk stuff like test resources and seaside adaptors. > > Cheers, > > Mariano. > > > 2010/6/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/6/24 Guillermo Polito <guillermopolito(a)gmail.com> > > Hi, > > I'm attaching a changeset with the "Close All Windows" menu item. I did it sending privateDelete to the windows, and I'm not sure if that's right, hehe. > > I have no idea. > > But it works and I put it where every other window menu item is. > > I would like someone to test it. Bah, Mariano already did it, but if someone else can I will be grateful:). > > Is there an open issue for this? I didn't find it. If there's not I can create it. > > > No, you will have to create it ;) > > > Cheers, > Guille > > > On Thu, Mar 25, 2010 at 2:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > +1 > > On Mar 25, 2010, at 6:28 PM, Oscar Nierstrasz wrote: > > > > > "Panic" does not suggest to me the actual intent. > > > > Some random ideas: > > - "close all" > > - "nuke" > > - "reset" > > - "clear" > > - "wipe" > > - "zap" > > - "tabula rasa" > > ... > > > > - on > > > > > > On Mar 24, 2010, at 22:23, Mariano Martinez Peck wrote: > > > >> I am not sure if Panic is the best name. Do you have better ideas? > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 28, 2010