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

Re: [Pharo-project] Schedule slippage

by Adrian Lienhard

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

April 8, 2009

Re: [Pharo-project] Closure compiler

by Damien Cassou

On Wed, Apr 8, 2009 at 1:53 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Â Â Â Â if you need fixtemps and other friends in blockclosure so that the > old code can load > Â Â Â Â we can create a package for that. I guess it's not necessary because I implemented them in DynamicBindings and KomHttpServer. -- Damien Cassou http://damiencassou.seasidehosting.st

April 8, 2009

Re: [Pharo-project] [ANN][Dev-Images] April 2009 versions

by Damien Cassou

On Wed, Apr 8, 2009 at 2:42 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > I just tried the April web image. Â The cosmetic changes to the debugger are appreciated (most importantly the background under the buttons, making the top of the text pain obvious when scrolled). Â Am I guilty of wishful thinking, or is the speed improved? Things are improving in all directions. It is normal that some side effects are speed improvements, but this is not a rule :-D -- Damien Cassou http://damiencassou.seasidehosting.st

April 8, 2009

[Pharo-project] Schedule slippage

by stephan＠stack.nl

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

April 8, 2009

Re: [Pharo-project] Compiler class>>closureParserClass

by Damien Cassou

On Wed, Apr 8, 2009 at 12:29 AM, Marcus Denker <denker(a)acm.org> wrote: >> 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. http://code.google.com/p/pharo/issues/detail?id=715 -- Damien Cassou http://damiencassou.seasidehosting.st

April 8, 2009

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

by Damien Cassou

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. -- Damien Cassou http://damiencassou.seasidehosting.st

April 8, 2009

Re: [Pharo-project] Closure compiler

by StÃ©phane Ducasse

my questions was if you need fixtemps and other friends in blockclosure so that the old code can load we can create a package for that. Stef On Apr 8, 2009, at 1:45 PM, Lukas Renggli wrote: >> lukas do you want that we produce a backward compatibility layer so >> that old seaside code loads in pharo? > > Sorry, I probably misunderstood your previous mail. > > After loading Seaside with the script above load: > > - Seaside-Closures-lr.1 from the Seaside 2.9 repository > > - DynamicBindings-damiencassou.9 > - KomHttpServer-damiencassou.47 from the Kom repository > > And then you should have a Seaside with closures. > > Note that two tests for partial continuations fail, because they > assume the old Squeak block behavior. Ignore them, these tests are > wrong. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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 Lukas Renggli

I noticed that #argumentCount is missing in the class BlockClosure. #argumentCount is part of ANSI and Seaside depends on it (for now it is part of Seaside-Closures). Furthermore the following messages are missing #valueWithExit, #valueSuppressingAllMessages, #valueWithEnoughArguments: on BlockClosure, I guess these are used at various places within Pharo. All the mentioned methods can be copied verbatim from BlockContext. Lukas On Wed, Apr 8, 2009 at 1:45 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> lukas do you want that we produce a backward compatibility layer so >> that old seaside code loads in pharo? > > Sorry, I probably misunderstood your previous mail. > > After loading Seaside with the script above load: > > - Seaside-Closures-lr.1 from the Seaside 2.9 repository > > - DynamicBindings-damiencassou.9 > - KomHttpServer-damiencassou.47 from the Kom repository > > And then you should have a Seaside with closures. > > Note that two tests for partial continuations fail, because they > assume the old Squeak block behavior. Ignore them, these tests are > wrong. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

April 8, 2009

Re: [Pharo-project] Closure compiler

by Lukas Renggli

> lukas do you want that we produce a backward compatibility layer so > that old seaside code loads in pharo? Sorry, I probably misunderstood your previous mail. After loading Seaside with the script above load: - Seaside-Closures-lr.1 from the Seaside 2.9 repository - DynamicBindings-damiencassou.9 - KomHttpServer-damiencassou.47 from the Kom repository And then you should have a Seaside with closures. Note that two tests for partial continuations fail, because they assume the old Squeak block behavior. Ignore them, these tests are wrong. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

April 8, 2009

Re: [Pharo-project] Closure compiler

by Lukas Renggli

> lukas do you want that we produce a backward compatibility layer so > that old seaside code loads in pharo? No, I don't think it is necessary. The way builder.seaside.st creates the load scripts assuming that the compiler throws warnings for uppercase inst-vars only. However the closure compiler now also throws a warning when a variable is undeclared (yeah, there is at least one bug in Seaside2.9alpha3), whereas the previous compiler silently ignored it. I changed my exception handler to tell the compiler to ignore it as well (what is the default, when you don't catch warnings anyway). Lukas -- Lukas Renggli http://www.lukas-renggli.ch

April 8, 2009