December 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issues 142 & 144

by StÃ©phane Ducasse

> > http://code.google.com/p/pharo/issues/detail?id=144 in 10200 :) Stef

Dec. 22, 2008

Re: [Pharo-project] Issue tracker & dev images

by StÃ©phane Ducasse

On Dec 22, 2008, at 6:30 PM, Stefan Schmiedl wrote: > On Mon, 22 Dec 2008 12:50:36 +0100 > Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> not sure... We have to take care that we do not end like Squeak >> Mantis with literally thousands of open bug reports. >> If we use the same tracker for Pharo-Core and Pharo, I strongly >> suggest that we tag the reports to clearly separate them. > > Speaking from the point of view of a user stumbling upon a bug, > which seems to be my special gift :-), I'm pretty good at that in any software or hardware and life :) > a single point of entering > bug reports is extremely helpful. I don't want to have to ask "where > does this bug go?" as I'll probably not be able to easily decide if > it belongs to the base or dev image. If reporting a bug is too much > work, I might be too lazy to even start reporting it or just not have > the time to do it right. > > bugs.gentoo.org is quite easy to use in this regard, as bugs can be > (and are) reassigned to other parts than they were reported for. Indeed but may be there more ubuntuers than squeakers so we should take care. > > > s. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 22, 2008

Re: [Pharo-project] Universes and Installer?

by StÃ©phane Ducasse

Scriptloader is our internal code to publish release. It is not for public consumption. It works well but only for us. For the rest we should Installer and I'm waiting damien to write some text on Sake and Packages so that I finally understand them. Stef On Dec 22, 2008, at 5:09 PM, Bill Schwab wrote: > It makes a lot of sense to use MC, universes, etc. rather than re- > write > them; no argument there. Would it help to roll ScriptLoader into > Installer? Installer _looks_ to me as though it tries to be a > much-needed facade over the various options for sharing code. The > problem is complex, so must be the solution, but I think it would help > to have a single entry point even if it is merely a facade. > > Bill > aka Confused Smalltalker :) > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> alexandre(a)bergel.eu 12/22/08 10:39 AM >>> > Works. Thanks! > > Alexandre > > > On 22 Dec 2008, at 12:26, Damien Cassou wrote: > >> On Mon, Dec 22, 2008 at 4:18 PM, Alexandre Bergel >> <Alexandre.Bergel(a)inria.fr> wrote: >>> If I execute "Installer universe" in a workspace, an error >>> "Universes >>> code not present" is signaled . >>> Does this mean that only a subset of Installer is present in Pharo- >>> Core? >> >> >> No, you have the complete Installer package. However, Installer needs >> some back-ends. Depending on what you want to, you will need >> SqueakMap, Monticello, Sake and Universes. >> >>> On the Installer squeaksource repository there is a package >>> Universes. >>> It looks like to be the right candidate. However, some extensions on >>> StringSocket need to be present. I do not know where to get them >>> from. >> >> You could use the dev images but I guess you won't do it. So, just >> execute: >> >> ScriptLoader new installingUniverse >> >>> http://www.squeaksource.com/Installer.html does not say much on >>> this. >>> Keith? Do I miss something? >> >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 >

Dec. 22, 2008

Re: [Pharo-project] Inclusion of OB-Tools inside Pharo

by StÃ©phane Ducasse

I was not questioning the presence of RB engine Now people can join to help improving. Gwenael is cleaning the parser and scanner for example > Stef, > > One nice thing about the new browser is the RB integration. Given my > general aversion to having it rewrite my code (showing no respect at > all > for the dated comments therein), I'm an unlikely advocate. Still, I > use > the RB for up/down refactorings (no rewrites needed), and will > sometimes > turn it loose on new code that has not had time to accumulate comments > of value. Others would consider its absence a showstopper. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 12/22/08 7:05 AM >>> > I think that we should pay attention of the ratio > of effort and number of people participating. > > My take would be to not include tools if they are not complete > and at the same time may be create a group of people working on an > specific > issue for the next milestone. > In the long run I would like to have less little bug fixes vs main > improvements > even if the little fixes are important. > one of the question is how can we make significant progress as an open > source project. > > Stef > > > On Dec 22, 2008, at 11:30 AM, Michael Roberts wrote: > >> I'm interested at least in a discussion on the OB debugger. This is >> because >> >> 1) there are definitely some bugs in the core debugger. Is it worth >> trying to fix them? I think yes, but I'm not sure I have the skills >> to identify and fix them. I just know from using the core debugger it >> sure does some strange things. >> 2) The core debugger is missing features: stack variables, arguments, >> breakpoints. How hard is it to modify the core one? >> 3) do we have enough volunteer effort to maintain two debuggers? I'm >> not sure we do. >> >> I have only briefly used the ob debugger and I got a bit confused >> with >> part of the UI so i'll need to look at it some more. What are folks >> thoughts on this key part of functionality? >> >> Then more generally i'm not sure it makes sense to have different >> tools in the core vs the dev image. I have to admit to not fully >> understanding the 1.0 release plan but looking fwds to say 2.0, 3.0 >> there would be benefit from pushing OB + tools into the core and just >> maintaining a single high quality set of tools across all variant >> images? >> >> cheers, >> >> Mike >> >> On Mon, Dec 22, 2008 at 10:00 AM, Damien Cassou > <damien.cassou(a)gmail.com >>> wrote: >>> On Sun, Dec 21, 2008 at 11:44 PM, Bill Schwab >>> <BSchwab(a)anest.ufl.edu> wrote: >>>> Sounds good. And in that case (OB Tools at the end of the list), >>>> I urge >>>> serious attention to having a notifier. Learning from history, >>>> and all >>>> that. >>> >>> Hi Bill, >>> >>> I decided to load OB-Tools (a reimplementation of some tools using >>> the >>> ob framework) inside the pharo-dev images. I put OB-Tools inside the >>> list of packages that will be part of the official Pharo >>> distribution. >>> This was a mistake because no discussion happened about this package >>> at all on this mailing list. I've just moved OB-Tools to the list of >>> pending packages. Now, we have to discuss (in this new thread): >>> >>> - Do we want an OB-based version of the tools inside Pharo? >>> - Do we want all tools implemented by Lukas or just some of them? >>> - What features are missing? >>> - What are the bugs? >>> - Who maintains this package? >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> _______________________________________________ >>> 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 >

Dec. 22, 2008

Re: [Pharo-project] Issues 142 & 144

by StÃ©phane Ducasse

Thanks I was thinking that for the Author class it would be good to fix once for all. May be you can join mike which was started to work on that. Stef On Dec 22, 2008, at 5:30 PM, HernÃ¡n Morales Durand wrote: > http://code.google.com/p/pharo/issues/detail?id=142 > http://code.google.com/p/pharo/issues/detail?id=144 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 22, 2008

Re: [Pharo-project] Issue tracker & dev images

by Stefan Schmiedl

On Mon, 22 Dec 2008 12:50:36 +0100 Adrian Lienhard <adi(a)netstyle.ch> wrote: > not sure... We have to take care that we do not end like Squeak > Mantis with literally thousands of open bug reports. > If we use the same tracker for Pharo-Core and Pharo, I strongly > suggest that we tag the reports to clearly separate them. Speaking from the point of view of a user stumbling upon a bug, which seems to be my special gift :-), a single point of entering bug reports is extremely helpful. I don't want to have to ask "where does this bug go?" as I'll probably not be able to easily decide if it belongs to the base or dev image. If reporting a bug is too much work, I might be too lazy to even start reporting it or just not have the time to do it right. bugs.gentoo.org is quite easy to use in this regard, as bugs can be (and are) reassigned to other parts than they were reported for. s.

Dec. 22, 2008

Re: [Pharo-project] Universes and Installer?

by Adrian Lienhard

On Dec 22, 2008, at 17:47 , Keith Hodges wrote: > Bill Schwab wrote: >> It makes a lot of sense to use MC, universes, etc. rather than re- >> write >> them; no argument there. Would it help to roll ScriptLoader into >> Installer? > Installer works for all commonly used Squeak images, so you would > need a > ScriptLoader for each image that people are using. > > Coincidentally that is almost exactly the way Sake/Packages already > works, except that it is aware of dependencies and can sort a list of > items that it is asked to load in order to honour dependencies. The > functions that ScriptLoader performs should really be rolled into the > Packages-Library class PacakgesPharo01, for Sake/Packages which is a > repository of "scripts" for loading things (most definitions simply > supply a url rather than a script). uh, sure? The main purpose of ScriptLoader is to support the generation of new updates. I recently implemented support for almost the complete process from detecting new changes, simulate the update for testing, pushing changes to SqueakSource and generating the scripts and cs files for the update stream. People started adding #loadOB methods on the class side of ScriptLoader -- I guess, these may be better handled by Sake/Packages. Adrian

Dec. 22, 2008

Re: [Pharo-project] Inclusion of OB-Tools inside Pharo

by Bill Schwab

David, The glaring examples are probably comments in cascades. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> pennell.david(a)gmail.com 12/22/08 11:48 AM >>> Bill, Can you give an example of the kind of comments that RB doesn't respect for you? I've used RB extensively on VW, but not much at all on Squeak yet. It had problems with end of line comments, but didn't do badly with comments on there own line. I adopted to its limitations rather than try to fix it because the benefits were so large and I was too busy/lazy/etc. -david On Mon, Dec 22, 2008 at 8:34 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Stef, > > One nice thing about the new browser is the RB integration. Given my > general aversion to having it rewrite my code (showing no respect at all > for the dated comments therein), I'm an unlikely advocate. Still, I use > the RB for up/down refactorings (no rewrites needed), and will sometimes > turn it loose on new code that has not had time to accumulate comments > of value. Others would consider its absence a showstopper. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > >>> stephane.ducasse(a)inria.fr 12/22/08 7:05 AM >>> > I think that we should pay attention of the ratio > of effort and number of people participating. > > My take would be to not include tools if they are not complete > and at the same time may be create a group of people working on an > specific > issue for the next milestone. > In the long run I would like to have less little bug fixes vs main > improvements > even if the little fixes are important. > one of the question is how can we make significant progress as an open > source project. > > Stef > > > On Dec 22, 2008, at 11:30 AM, Michael Roberts wrote: > > > I'm interested at least in a discussion on the OB debugger. This is > > because > > > > 1) there are definitely some bugs in the core debugger. Is it worth > > trying to fix them? I think yes, but I'm not sure I have the skills > > to identify and fix them. I just know from using the core debugger it > > sure does some strange things. > > 2) The core debugger is missing features: stack variables, arguments, > > breakpoints. How hard is it to modify the core one? > > 3) do we have enough volunteer effort to maintain two debuggers? I'm > > not sure we do. > > > > I have only briefly used the ob debugger and I got a bit confused with > > part of the UI so i'll need to look at it some more. What are folks > > thoughts on this key part of functionality? > > > > Then more generally i'm not sure it makes sense to have different > > tools in the core vs the dev image. I have to admit to not fully > > understanding the 1.0 release plan but looking fwds to say 2.0, 3.0 > > there would be benefit from pushing OB + tools into the core and just > > maintaining a single high quality set of tools across all variant > > images? > > > > cheers, > > > > Mike > > > > On Mon, Dec 22, 2008 at 10:00 AM, Damien Cassou > <damien.cassou(a)gmail.com > > > wrote: > >> On Sun, Dec 21, 2008 at 11:44 PM, Bill Schwab > >> <BSchwab(a)anest.ufl.edu> wrote: > >>> Sounds good. And in that case (OB Tools at the end of the list), > >>> I urge > >>> serious attention to having a notifier. Learning from history, > >>> and all > >>> that. > >> > >> Hi Bill, > >> > >> I decided to load OB-Tools (a reimplementation of some tools using > >> the > >> ob framework) inside the pharo-dev images. I put OB-Tools inside the > >> list of packages that will be part of the official Pharo > >> distribution. > >> This was a mistake because no discussion happened about this package > >> at all on this mailing list. I've just moved OB-Tools to the list of > >> pending packages. Now, we have to discuss (in this new thread): > >> > >> - Do we want an OB-based version of the tools inside Pharo? > >> - Do we want all tools implemented by Lukas or just some of them? > >> - What features are missing? > >> - What are the bugs? > >> - Who maintains this package? > >> > >> -- > >> Damien Cassou > >> http://damiencassou.seasidehosting.st > >> > >> _______________________________________________ > >> 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 >

Dec. 22, 2008

[Pharo-project] [ANN] 10198 and 10199

by StÃ©phane Ducasse

Hi two updates - 10198 forceClass: removal on SUnitGui (pavel krivanek) SmallLand update removal (mike Roberts) More tests on Collection - 10199 DNU eliot Fixes HalosDisable Stef

Dec. 22, 2008

Re: [Pharo-project] Inclusion of OB-Tools inside Pharo

by David Pennell

Bill, Can you give an example of the kind of comments that RB doesn't respect for you? I've used RB extensively on VW, but not much at all on Squeak yet. It had problems with end of line comments, but didn't do badly with comments on there own line. I adopted to its limitations rather than try to fix it because the benefits were so large and I was too busy/lazy/etc. -david On Mon, Dec 22, 2008 at 8:34 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Stef, > > One nice thing about the new browser is the RB integration. Given my > general aversion to having it rewrite my code (showing no respect at all > for the dated comments therein), I'm an unlikely advocate. Still, I use > the RB for up/down refactorings (no rewrites needed), and will sometimes > turn it loose on new code that has not had time to accumulate comments > of value. Others would consider its absence a showstopper. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > >>> stephane.ducasse(a)inria.fr 12/22/08 7:05 AM >>> > I think that we should pay attention of the ratio > of effort and number of people participating. > > My take would be to not include tools if they are not complete > and at the same time may be create a group of people working on an > specific > issue for the next milestone. > In the long run I would like to have less little bug fixes vs main > improvements > even if the little fixes are important. > one of the question is how can we make significant progress as an open > source project. > > Stef > > > On Dec 22, 2008, at 11:30 AM, Michael Roberts wrote: > > > I'm interested at least in a discussion on the OB debugger. This is > > because > > > > 1) there are definitely some bugs in the core debugger. Is it worth > > trying to fix them? I think yes, but I'm not sure I have the skills > > to identify and fix them. I just know from using the core debugger it > > sure does some strange things. > > 2) The core debugger is missing features: stack variables, arguments, > > breakpoints. How hard is it to modify the core one? > > 3) do we have enough volunteer effort to maintain two debuggers? I'm > > not sure we do. > > > > I have only briefly used the ob debugger and I got a bit confused with > > part of the UI so i'll need to look at it some more. What are folks > > thoughts on this key part of functionality? > > > > Then more generally i'm not sure it makes sense to have different > > tools in the core vs the dev image. I have to admit to not fully > > understanding the 1.0 release plan but looking fwds to say 2.0, 3.0 > > there would be benefit from pushing OB + tools into the core and just > > maintaining a single high quality set of tools across all variant > > images? > > > > cheers, > > > > Mike > > > > On Mon, Dec 22, 2008 at 10:00 AM, Damien Cassou > <damien.cassou(a)gmail.com > > > wrote: > >> On Sun, Dec 21, 2008 at 11:44 PM, Bill Schwab > >> <BSchwab(a)anest.ufl.edu> wrote: > >>> Sounds good. And in that case (OB Tools at the end of the list), > >>> I urge > >>> serious attention to having a notifier. Learning from history, > >>> and all > >>> that. > >> > >> Hi Bill, > >> > >> I decided to load OB-Tools (a reimplementation of some tools using > >> the > >> ob framework) inside the pharo-dev images. I put OB-Tools inside the > >> list of packages that will be part of the official Pharo > >> distribution. > >> This was a mistake because no discussion happened about this package > >> at all on this mailing list. I've just moved OB-Tools to the list of > >> pending packages. Now, we have to discuss (in this new thread): > >> > >> - Do we want an OB-based version of the tools inside Pharo? > >> - Do we want all tools implemented by Lukas or just some of them? > >> - What features are missing? > >> - What are the bugs? > >> - Who maintains this package? > >> > >> -- > >> Damien Cassou > >> http://damiencassou.seasidehosting.st > >> > >> _______________________________________________ > >> 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 >

Dec. 22, 2008