April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Closure compiler

by Michael van der Gulik

On 4/9/09, Marcus Denker <denker(a)acm.org> wrote: > > On 07.04.2009, at 21:50, Michael van der Gulik wrote: > >> On 4/8/09, Marcus Denker <denker(a)acm.org> wrote: >>> >>> On 07.04.2009, at 16:31, Alexandr Batalshikov wrote: >>> >>>> Hi, >>>> >>>> I see in pharo0.1-10268dev09.04.1.image: >>>> >>>> Compiler class>>closureParserClass >>>> ^self error: 'not installed'. >>>> >>>> That is right? >>>> How to install "closureParserClass"? >>>> >>> >>> these are leftovers from the NewCompiler ClosureCompiler. We will >>> clean this up soon. >> >> What is the story with the NewCompiler? Does Pharo include it? Or are >> you moving to Eliot's modification of the old compiler with closure >> support? > > > We integrated Eliot's work into Pharo for now. The actual closure > realization is > different but similar, so there is no reason to not to use his. The > old "ClosureCompiler" > then will be renamed "NewCompiler" and fixed to generate code for > Eliot's closures. > > The NewCompiler is a bit more modular/easier to understand and > butcher, we used > in for many experiments already and we will definitly port it. I wonder if it is worth splitting the NewCompiler (which really does need a better name) into two packages: the front end and the back end. Later this year (or next) I plan to do some hacking on the NewCompiler for integration into SecureSqueak. I'll post something on the NewCompiler mailing list when I get that far; I'll try to contribute stuff back to the NewCompiler project so hopefully they'll percolate through to Pharo, Squeak and other users. Gulik. -- http://gulik.pbwiki.com/

April 8, 2009

Re: [Pharo-project] Undefined symbol using Exupery VM

by Bryce Kampjes

On Wed, 2009-04-08 at 14:10 +0200, Damien Cassou wrote: > On Tue, Apr 7, 2009 at 10:34 PM, Bryce Kampjes > <bryce(a)kampjes.demon.co.uk> wrote: > > OK, I know whats wrong, the VMMaker I merged from was from February, the > > latest when I assembled that image. The primitive you're using was > > introduced in a version from 28 March. It's an IP6 primitive that looks > > like it's been around for a few years but not in the official source. > > > > I'll try to get a new Linux VM out in the next week. > > Thank you Bryce. We need you to have a working and recent VM, thank > you very much. Here's a VM that should have the IP6 primitives in it: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15.1-linux.tz It's also got a VMMaker fix for alpha channel bitlblts. Not sure if that's the entire fix needed. I'll rebuild again using latest C sources in a few weeks. Bryce

April 8, 2009

Re: [Pharo-project] Integrate changes from Cuis (was Fwd: [squeak-dev] Cuis update - Separate change sets for goodies available)

by StÃ©phane Ducasse

Hi adrian I checked a bit more carefully some changes and they are based on squeak 3.7. So special care would have to be taken with this fork. Stef > There probably are a couple of interesting improvements/fixes in the > work of Juan. > > I created an issue: http://code.google.com/p/pharo/issues/detail? > id=717 > > Adrian > > Begin forwarded message: > >> From: Juan Vuletich <juan(a)jvuletich.org> >> Date: April 6, 2009 3:28:28 PM GMT+02:00 >> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> >> Subject: [squeak-dev] Cuis update - Separate change sets for goodies >> available >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >>> >> >> Hi Folks, >> >> I've just uploaded http://www.jvuletich.org/Cuis/Cuis1.0-0169.zip . >> I did some refactoring and cleanup in ScrollPane and ScrollBar. Now >> Browser openBrowser takes almost half the time! I also added back >> the preference for scrollbars on left. So, Klaus, you don't need to >> do it. >> >> (These were already in previous release, 0166: I removed the Old >> prefix from Morphic classes, to ease loading code from other Squeak >> distributions. I also changed fonts to use just 16bpp and not 32. >> The difference is invisible to my eyes, and they use half the space. >> And I fixed the #isMorphic bug reported by Klaus. ) >> >> I also uploaded http://www.jvuletich.org/Cuis/ >> CuisUpdatesUpTo0169.zip . This file includes the change sets of the >> last year. I don't have older ones available in cs form, but most >> goodies and tweaks that could be useful for other Squeak >> distributions are here. This http://www.jvuletich.org/Cuis/CategoriesAndChangeSets.txt >> is the detail of which changesets belong to which of the following >> categories: >> >> - Rename class and update references goodie >> - Process scheduling enh >> - MessageTally enh >> - Logging and ChangeSet enhancements >> - Dan's == with SmallIntegers >> - Affected class categories goodie >> - Protocol Catcher goodie >> - Nicer Cursors >> - Chronology enh >> - Parser enh >> - ProgressBar enh >> - Text cleanup and refactoring >> - ScrollPane and ScrollBar cleanup & refacto >> - NiceFonts >> - Code authorship and relicensing >> - Focus navigation and enh >> - Pointer explorer goodie >> - Code evaluation fixes >> - Remote cursor sender goodie >> - Semaphores, Delays and Processes >> - Misc goodies and lesser tweaks >> - Cleanup >> - Morphic / LightWidgets >> >> Comments welcome. >> >> Cheers, >> Juan Vuletich >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 8, 2009

Re: [Pharo-project] Closure compiler

by Marcus Denker

On 07.04.2009, at 21:50, Michael van der Gulik wrote: > On 4/8/09, Marcus Denker <denker(a)acm.org> wrote: >> >> On 07.04.2009, at 16:31, Alexandr Batalshikov wrote: >> >>> Hi, >>> >>> I see in pharo0.1-10268dev09.04.1.image: >>> >>> Compiler class>>closureParserClass >>> ^self error: 'not installed'. >>> >>> That is right? >>> How to install "closureParserClass"? >>> >> >> these are leftovers from the NewCompiler ClosureCompiler. We will >> clean this up soon. > > What is the story with the NewCompiler? Does Pharo include it? Or are > you moving to Eliot's modification of the old compiler with closure > support? We integrated Eliot's work into Pharo for now. The actual closure realization is different but similar, so there is no reason to not to use his. The old "ClosureCompiler" then will be renamed "NewCompiler" and fixed to generate code for Eliot's closures. The NewCompiler is a bit more modular/easier to understand and butcher, we used in for many experiments already and we will definitly port it. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

April 8, 2009

Re: [Pharo-project] Schedule slippage

by Schwab,Wilhelm K

Stef, Feature creep is always a problem, at least for good projects - junk can always be released on a schedule :) Among many other items, you have tackled closures, which is a good thing. Given the choice, I would probably do underscores in 1.0 (they hit home pretty firmly). While 1.0 is "late," there are now monthly developer and web images, the VMs are easy to find, and the system is improving. As long as the system is getting better, (relatively) stable and functional images continue to be offered along the way, and the development schedule makes good sense (I think it does), exactly what you choose to call 1.0 is not of great importance. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Wednesday, April 08, 2009 9:18 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Schedule slippage We know. The problem is that we do not want to let code rot because we do not have the work load to deal with it. For closure the more we waited the more it becomes a problem and painful. We decided that we will include the event cleaning made by mike. After the large part is the MIT cleaning. Now please join and help fixing the pending points. > Can we do something about the way schedule slippage is handled? > There is a lot of feature creep, and we are taking too small > slippages. > > Based on yesterdays weather, 1.0 is not going to be released in May > 2009. > > Issues were closed after on average 30 days, 48% within a week, but > 10% took 85 days or longer. > Of the new,started,accepted, fixed issues for 1.0 40% is 280 days > old. > > Stephan > > > > > > _______________________________________________ > 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

April 8, 2009

Re: [Pharo-project] Schedule slippage

by Adrian Lienhard

On Apr 8, 2009, at 15:31 , stephan(a)stack.nl wrote: > Adrian wrote: >> Thanks for the stats. How did you produce them? > > From the csv output of the issue tracker. I used an old Delphi hack > and a calculator, but if you're interested in generating some kind of > burn-down chart, I can do a Pharo version. (or a DabbleDB one, I > guess) Sure, that would be interesting to track our progress! > >> One way to alleviate the problem is if more people help. There is >> work for everybody. > > I know, but that's not likely to solve this problem. > More people = more scope creep. There's certainly a tendency for more feature creep, but as we control what makes it into a milestone, its not that just anybody can add new stuff. > The issue is that if Pharo is to be a professional development tool, > the release schedule should be somewhat reliable. If we miss a > milestone, > just adding another month to the schedule isn't working very well. I agree, there's room for improvement. One difficulty is that the available resources are hard to plan in advance as everybody is working on a voluntary basis. For example, I couldn't do much the last three weeks due to high priority work at my company, Marcus is moving, etc. Cheers, Adrian

April 8, 2009

Re: [Pharo-project] Schedule slippage

by StÃ©phane Ducasse

We know. The problem is that we do not want to let code rot because we do not have the work load to deal with it. For closure the more we waited the more it becomes a problem and painful. We decided that we will include the event cleaning made by mike. After the large part is the MIT cleaning. Now please join and help fixing the pending points. > Can we do something about the way schedule slippage is handled? > There is a lot of feature creep, and we are taking too small > slippages. > > Based on yesterdays weather, 1.0 is not going to be released in May > 2009. > > Issues were closed after on average 30 days, > 48% within a week, but 10% took 85 days or longer. > Of the new,started,accepted, fixed issues for 1.0 40% is 280 days > old. > > Stephan > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 8, 2009

Re: [Pharo-project] Schedule slippage

by stephan＠stack.nl

Adrian wrote: > Thanks for the stats. How did you produce them? From the csv output of the issue tracker. I used an old Delphi hack and a calculator, but if you're interested in generating some kind of burn-down chart, I can do a Pharo version. (or a DabbleDB one, I guess) > One way to alleviate the problem is if more people help. There is > work for everybody. I know, but that's not likely to solve this problem. More people = more scope creep. The issue is that if Pharo is to be a professional development tool, the release schedule should be somewhat reliable. If we miss a milestone, just adding another month to the schedule isn't working very well. Stephan

April 8, 2009

Re: [Pharo-project] Schedule slippage

by Adrian Lienhard

Great! First please sign the license agreement if not already done: http://code.google.com/p/pharo/wiki/ListOfOkCommitters Second, have a look at open issues tagged for milestone 1.0: http://code.google.com/p/pharo/issues/list?can=2&q=milestone:1.0 Third, check out how to contribute changes: http://code.google.com/p/pharo/wiki/HowToContribute And please don't hesitate to ask questions on the mailing list. Thanks, Adrian On Apr 8, 2009, at 14:58 , John Toohey wrote: > I would like to get involved in getting 1.0 shipped, but am not sure > where to start. Are there some guidelines available somewhere? > > > On Wed, Apr 8, 2009 at 08:33, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> Hi Stephan, >> >> Thanks for the stats. How did you produce them? >> >> You are right that we have feature creep (like closures, which were >> planned for 1.1) and many issues have been open for quite a while. >> One >> way to alleviate the problem is if more people help. There is work >> for >> everybody. >> >> Looking forward to your contributions ;) >> Adrian >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> On Apr 8, 2009, at 14:13 , stephan(a)stack.nl wrote: >> >>> Can we do something about the way schedule slippage is handled? >>> There is a lot of feature creep, and we are taking too small >>> slippages. >>> >>> Based on yesterdays weather, 1.0 is not going to be released in May >>> 2009. >>> >>> Issues were closed after on average 30 days, >>> 48% within a week, but 10% took 85 days or longer. >>> Of the new,started,accepted, fixed issues for 1.0 40% is 280 days >>> old. >>> >>> Stephan >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > -JT > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 8, 2009

Re: [Pharo-project] Schedule slippage

by John Toohey

I would like to get involved in getting 1.0 shipped, but am not sure where to start. Are there some guidelines available somewhere? On Wed, Apr 8, 2009 at 08:33, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Stephan, > > Thanks for the stats. How did you produce them? > > You are right that we have feature creep (like closures, which were > planned for 1.1) and many issues have been open for quite a while. One > way to alleviate the problem is if more people help. There is work for > everybody. > > Looking forward to your contributions ;) > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > On Apr 8, 2009, at 14:13 , stephan(a)stack.nl wrote: > >> Can we do something about the way schedule slippage is handled? >> There is a lot of feature creep, and we are taking too small >> slippages. >> >> Based on yesterdays weather, 1.0 is not going to be released in May >> 2009. >> >> Issues were closed after on average 30 days, >> 48% within a week, but 10% took 85 days or longer. >> Of the new,started,accepted, fixed issues for 1.0 Â 40% is 280 days >> old. >> >> Stephan >> >> >> >> >> >> _______________________________________________ >> 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 > -- -JT

April 8, 2009