May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Mariano Martinez Peck

On Mon, May 17, 2010 at 9:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Unstable is alpha. We called it that way so that people do not start to use > it :) > Ok, we can tag it beta then. > But now we should go beta=releaseCandidate1 > > No, I don't agree. That's not the same. One thing is beta and another thing is a release candidate. > Stef > > On May 16, 2010, at 11:18 PM, Mariano Martinez Peck wrote: > > > > > > > On Sun, May 16, 2010 at 11:16 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > check the network problem. > > But we can release rc1 anytime now. > > > > > > No, please. We are not in a RC yet. We should first go as alpha, then > beta and finally RC. > > We cannot go in a RC with the first build ever. > > > > Cheers > > > > Mariano > > > > > > Stef > > > > On May 16, 2010, at 11:00 PM, Alexandre Bergel wrote: > > > > > Mariano, > > > > > > What is needed for Pharo 1.1? Not much I feel. I produced yesterday a > Pharo1.1 from a core, and it works perfectly, including condenseChange. > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 16 May 2010, at 11:14, StÃ©phane Ducasse wrote: > > > > > >> We are basically ready > > >> Waiting for feedback on network. > > >> > > >> Stef > > >> > > >> > > >> On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: > > >> > > >>> We said that for middle May we were going to freeze 1.1. This means, > no more new features or refactors. Just bug fixes. So, the next steps can > be: > > >>> > > >>> - Release a PharoCore1.1 with the last version we have so far tagged > as alpha1 (please, put this tag in the zip, .image and .changes). This may > be, for example: Pharo-1.1-11360-alpha1.image > > >>> - Build and release a Pharo 1.1 alpha1 based on such core (now we > have almost all dev tools working well in 1.1) > > >>> - Make publish all new VMs (for each OS) > > >>> > > >>> Then the idea is that people/developers start to play with Pharo 1.1. > It may be quite unstable as this is the first release for 1.1. People should > try to load their own packages, adapt them (if necessary) to 1.1, and report > all issues they find (and fixes!!). But they should keep in mind this the > first alpha ;) > > >>> > > >>> With these, we will be testing: new VMs, PharoCore, PharoDev tools, > and external packages (from other people). > > >>> > > >>> Pharo team at the same time, continues to work, fixing and > integrating. We make new versions as we have been doing so far. When we > consider, we release an alpha2....then beta, then RC and finally Pharo 1.1. > > >>> > > >>> now...do you think there is an issue that is so important to be > fixed/included in the first Pharo1.1 even being a first alpha ? > > >>> > > >>> Cheers > > >>> > > >>> Mariano > > >>> _______________________________________________ > > >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Mariano Martinez Peck

On Mon, May 17, 2010 at 9:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/5/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Sun, May 16, 2010 at 11:16 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> check the network problem. > >> But we can release rc1 anytime now. > >> > > > > No, please. We are not in a RC yet. We should first go as alpha, then > beta > > and finally RC. > > We cannot go in a RC with the first build ever. > > > Yes , we can. Its only a conventions, what you calling alpha , beta or RC. > But sure thing, more testing and packaging won't hurt. > > But conventions are important. Listen the name: RELEASE CANDIDATE! Imagine you are going to download a software which is in RELEASE CANDIDATE and has a lot of problems and bugs....is not good for marketing. So...they are just conventions, but they are important. We cannot say this is a release candidate when we haven't even ever created a PharoDev. For example, did you test it? We are not speaking about core. > > Cheers > > > > Mariano > > > > > >> > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010

Re: [Pharo-project] [Metacello] Managing Pharo external packages with Metacello, please read!

by StÃ©phane Ducasse

I like the idea of tags. Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD with all the code included. Stef > I was thinking about the "folders" to store copies of ConfigurationOfXXX > for a given release. I think that this will have problems, for example > for the simplest package that load fine in 3 consecutive release we will > have exactly 3 copies of the ConfigurationOfXXX package (not that the > disk space is a problem). On the other side, if a package has 19 > versions for a given release (lets say RFB has 19 version methods in the > ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a > copy of it will be made. This copy will be full, having the 19 version > methods, or you just take the last version method. Also, what about the > pre/post do its, they will likely be similar or exactly equal between > releases of Pharo. > If you delete the methods, you also lost the history and the opportunity > that new users can learn or use the previous versions. > > Some time ago I proposed the idea that Metacello should have tags to > mark that a version method has been tested in a given fork/release. As > the time pass, the tags in a method will grow to mark the version has > been tested on. > But for this to work, Metacello or the tools (I would prefer Metacello) > must honor this tags and before loading the code in a given image by > comparing what image is being installed on. > > Lets put an example: > > 1. Initial creation of the configuration for package Package for Pharo > 1.0 uploaded to MetacelloRepository: > > ConfigurationOfPackage>>baseline01 > "initial baseline" > > ConfigurationOfPackage>>version01: spec > <version: '0.1'> > > spec for: #common do: [ > spec blessing: #release. > spec worksIn: 'Pharo1.0' > ... ]. > > 2. A new version for Pharo 1.0 (lets say a bug fix): > > ConfigurationOfPackage>>version02: spec > <version: '0.2'> > > spec for: #common do: [ > spec blessing: #release. > spec worksIn: 'Pharo1.0' > ... ]. > > 3. A new Pharo release is made, no changes to the package are needed, > that is, it works correctly in Pharo1.0 and Pharo 1.1 > > ConfigurationOfPackage>>version03: spec > <version: '0.3'> > > spec for: #common do: [ > spec blessing: #release. > spec worksIn: #( 'Pharo1.0' 'Pharo1.1' ) > ... ]. > > At this point the ConfigurationOfPackage has four methods: baseline and > three versions. Also, before loading, Metacello checks the worksIn: > list against a standard release string in the image is working on. If > it match it install the package. That is, if I start with a Pharo1.1 > image and load the configuration, the only possible candidate version > to install is the 0.3, because is the only one marked to work in Pharo1.1. > > 4. A port to Squeak 5 is made. This likely will need a new baseline > because will need squeak specific packages to be included > (compatibility packages) and also maybe a Pharo compatibility package > will be made. Anyway, a new baseline indicating new packages > relationships will be made: > > ConfigurationOfPackage>>baseline02 > "second baseline, it accounts for install in Pharo and Squeak" > > ConfigurationOfPackage>>version04: spec > <version: '0.4'> > > spec for: #common do: [ > spec blessing: #release. > spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' ) > ... ]. > spec for: #squeak do: [ > ... ]. > spec for: #pharo do: [ > ... ]. > > At this point the ConfigurationOfXXX is capable of install the last > version in Squeak and Pharo. > > If I start on Squeak 4.0 then even if I load the > ConfigurationOfPackage, no package will be installed because nobody has tested this. > > If I start on Squeak 5.0 only version 0.4 can be installed. > > If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed > > If I start on Pharo 1.3 no package will be installed > > 5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases > but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1 > > ConfigurationOfPackage>>baseline08 > "second baseline, it accounts for install in Pharo and Squeak" > > ConfigurationOfPackage>>version09: spec > <version: '0.9'> > > spec for: #common do: [ > spec blessing: #release. > spec worksIn: #( 'Pharo1.3' 'Pharo1.4' ) > ... ]. > spec for: #pharo do: [ > ... ]. > > 6. Installing on Squeak 8 is again supported together with support for Squeak 7.0: > > ConfigurationOfPackage>>baseline04 > "third baseline, it accounts for install in Pharo and Squeak" > > ConfigurationOfPackage>>version10: spec > <version: '1.0'> > > spec for: #common do: [ > spec blessing: #release. > spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' ) > ... ]. > spec for: #squeak do: [ > ... ]. > spec for: #pharo do: [ > ... ]. > > So the tags come and go as the support for given forks and releases are > tested. > Different versions of the Package package can work in different forks > and in different releases of those forks. > It is always the job of the interested parties to add support (that is > version methods and baselines, or simply tags to the worksIn: list) for > a package in a given combination. > > What do you think? > > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 17, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by StÃ©phane Ducasse

Elliot believe me we **really** discussed that over more than a year with dale and a couple of others. We pushed metacello contrary to other people that said it was crap and bloated. So may be we are a bit slow and not that smart but we want to give a try to the setup we have in mind. Now we also want to have a list of packages which constitutes pharo-core that will be manage as a pharo-core configuration. Stef

May 17, 2010

Re: [Pharo-project] Issue 2435 - DNU in cleanUpForRelease

by StÃ©phane Ducasse

Thanks We will do that! Stef On May 17, 2010, at 1:18 AM, Torsten Bergmann wrote: > see http://code.google.com/p/pharo/issues/detail?id=2435 > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 17, 2010

Re: [Pharo-project] [squeak-dev] Re: Problem with variable capture in blocks or ? #7532

by StÃ©phane Ducasse

Thanks eliot http://code.google.com/p/pharo/issues/detail?id=2436 In 1.1 | a | a := 4. b := [ :a | a ]. c := b value: a. we cannot shadow a Stef On May 17, 2010, at 2:47 AM, Eliot Miranda wrote: > > > On Sun, May 16, 2010 at 3:32 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Ken - > > Very interesting. Looks like an issue with OutOfScopeNotification. The problem appears to be that this code: > > "..." [ :a | a ]. > "..." a. > > generates an OutOfScopeNotification that is being suppressed in workspaces (I'm not exactly sure why that is). This is of course is interesting because of the highly unusual situation of a temp shadowing a global instead of another temp / ivar. For example, this wouldn't compile: > > | a | > [ :a | a ]. > > But stranglely, this does: > > [ :Object | Object ]. > > so your example code is roughly equivalent to running: > > b := [ :Object | Object ]. > c := b value: Object. > > When you run this line by line it works 'as expected' and when you run it as a single doIt you get the result of c being a "[closure] in UndefinedObject>>DoIt" due to the OutOfScopeNotification. > > Hope this explains the issue - as for how to fix it, I have no clue :-) > > Yes, the bug is that Encoder>>encodeVariable:sourceRange:ifUnknown: doesn't continue from a caught OutOfScopeNotification by answering the ifUnknown: action. Instead it returns the out-of-scope block temp. This is a rather serious compiler bug that I'd left unfixed because it only bites in workspaces (apologies) and I didn't have a small example to analyse before (thanks Ken!). The code generated is actually equivalent to > > b := [ :a | a ]. > c := b value: <temp 0>. > > Since there aren't any temps, temp 0 is top of stack, which just happens to be the closure just created by the preceding bytecode. e.g. look at bytecode 49 in the following: > > a := 4. b := [ :a | a ]. c := b value: a. { a. b. c } thisContext method symbolic > > The fix is simple. When an OutOfScopeNotification is caught the Encoder should still answer what ever it should for an out of scope variable. In Encoder>>encodeVariable:sourceRange:ifUnknown: the statements > > (varNode isTemp and: [varNode scope < 0]) ifTrue: [ > OutOfScopeNotification signal ifFalse: [ ^self notify: 'out of scope']. > ]. > ^ varNode > > should read > > (varNode isTemp and: [varNode scope < 0]) ifTrue: > [^OutOfScopeNotification signal > ifTrue: [action value] > ifFalse: [self notify: 'out of scope']]. > ^varNode > > Find attached: > > !Encoder methodsFor: 'encoding' stamp: 'eem 5/16/2010 17:33'! > encodeVariable: name sourceRange: range ifUnknown: action > | varNode | > varNode := scopeTable > at: name > ifAbsent: > [(self lookupInPools: name > ifFound: [:assoc | varNode := self global: assoc name: name]) > ifTrue: [varNode] > ifFalse: [^action value]]. > range ifNotNil: > [name first canBeGlobalVarInitial ifTrue: > [globalSourceRanges addLast: { name. range. false }]]. > > (varNode isTemp and: [varNode scope < 0]) ifTrue: > [^OutOfScopeNotification signal > ifTrue: [action value] > ifFalse: [self notify: 'out of scope']]. > ^varNode! ! > > P.S. this is probably applicable to any Squeak bytecode compiler (including eToys). The only change in my closure compiler from Andreas' 2003 version was changing "name first isUppercase" to "name first canBeGlobalVarInitial". > > > P.P.S. Again Ken, thanks for a comprehensible example. It always bit me in huge doits I was using to analyse the entire system's compiled methods, and invariably crashed the VM. I never took the time to isolate the bug, I just fixed the doit and continued. Turns out to be very simple. > > best > Eliot > > > Cheers, > - Andreas > > > > On 5/16/2010 12:35 PM, Ken Causey wrote: > Well, it's nothing new but this one has stumped me: > > http://bugs.squeak.org/view.php?id=7532 > > Initially I (and Frank) thought the reporter was mistaken until we > understood that the problem shows up when you execute the main code all > in one do-it. I've since modified the original report to make this > clearer. > > So here it is: > > a := 4. > b := [ :a | a ]. > c := b value: a. > > If you SELECT ALL OF THIS AND EXECUTE IT ALL AT ONE TIME (crucial > detail). The result is that a is 4, b is a BlockClosure, and c is a > BlockClosure not 4 as expected. Execute each statement separately and c > is 4. > > Alternately, from a suggestion from jmckeon, if you specify a different > symbol for the block argument: > > a := 4. > b := [ :d | d ]. > c := b value: a. > > when executed all at one time works as you would expect: a is 4, b is a > BlockClosure, and c is 4. (and d is nil) > > So what's up? > > Ken > > > > > > > <Encoder-encodeVariablesourceRangeifUnknown.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 17, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by StÃ©phane Ducasse

Unstable is alpha. We called it that way so that people do not start to use it :) But now we should go beta=releaseCandidate1 Stef On May 16, 2010, at 11:18 PM, Mariano Martinez Peck wrote: > > > On Sun, May 16, 2010 at 11:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > check the network problem. > But we can release rc1 anytime now. > > > No, please. We are not in a RC yet. We should first go as alpha, then beta and finally RC. > We cannot go in a RC with the first build ever. > > Cheers > > Mariano > > > Stef > > On May 16, 2010, at 11:00 PM, Alexandre Bergel wrote: > > > Mariano, > > > > What is needed for Pharo 1.1? Not much I feel. I produced yesterday a Pharo1.1 from a core, and it works perfectly, including condenseChange. > > > > Cheers, > > Alexandre > > > > > > On 16 May 2010, at 11:14, StÃ©phane Ducasse wrote: > > > >> We are basically ready > >> Waiting for feedback on network. > >> > >> Stef > >> > >> > >> On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: > >> > >>> We said that for middle May we were going to freeze 1.1. This means, no more new features or refactors. Just bug fixes. So, the next steps can be: > >>> > >>> - Release a PharoCore1.1 with the last version we have so far tagged as alpha1 (please, put this tag in the zip, .image and .changes). This may be, for example: Pharo-1.1-11360-alpha1.image > >>> - Build and release a Pharo 1.1 alpha1 based on such core (now we have almost all dev tools working well in 1.1) > >>> - Make publish all new VMs (for each OS) > >>> > >>> Then the idea is that people/developers start to play with Pharo 1.1. It may be quite unstable as this is the first release for 1.1. People should try to load their own packages, adapt them (if necessary) to 1.1, and report all issues they find (and fixes!!). But they should keep in mind this the first alpha ;) > >>> > >>> With these, we will be testing: new VMs, PharoCore, PharoDev tools, and external packages (from other people). > >>> > >>> Pharo team at the same time, continues to work, fixing and integrating. We make new versions as we have been doing so far. When we consider, we release an alpha2....then beta, then RC and finally Pharo 1.1. > >>> > >>> now...do you think there is an issue that is so important to be fixed/included in the first Pharo1.1 even being a first alpha ? > >>> > >>> Cheers > >>> > >>> Mariano > >>> _______________________________________________ > >>> 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

May 17, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by StÃ©phane Ducasse

On May 16, 2010, at 11:17 PM, Mariano Martinez Peck wrote: > > > On Sun, May 16, 2010 at 11:00 PM, Alexandre Bergel <alexandre.bergel(a)inria.fr> wrote: > Mariano, > > What is needed for Pharo 1.1? Not much I feel. I produced yesterday a Pharo1.1 from a core, and it works perfectly, including condenseChange. > > > No, it doesn't work perfectly ;) > All the mails I sent to the mailing list was the "things" I found while building Pharo 1.1. > We still have problems with network for example. Where? The ping did not work in 3.9, squeaktrunk, pharo10 and pharo1.1 so :) lukas sent an email last week and we got NO feedback. > Not too much indeed. I need to update a little some configurations. I just tested with the new vms and today I was testing how to install external packages like seaside to see if the welcome workspace that explains how to install them deserves an update. > > What I need is that someone: > > - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge there are none that are showstoppers > - to create a section in the website specially for 1.1 where we mention we are in alpha1 blah blah I started and we should continue > - in that section we include new VMs. > - For windows it is the same we have for 1.0: http://gforge.inria.fr/frs/download.php/26814/PharoVM-Win32-4.0.2-bin.zip > - For linux: http://squeakvm.org/unix/release/Squeak-4.0.3.2202-linux_i386.tar.gz > - For mac we are waiting a new one from John, but for the moment we should use: ftp://ftp.smalltalkconsulting.com/Squeak%204.2.4beta1U.app.zip > - Finally we add in that section the Pharo image I build. > > I have updated my build scripts to work with Pharo 1.1 and I build a dev, Excellent > > So...once those points are done, I just create the image and update it to website. > > But we will need help from people to test it and report bugs, feedback and all kind of issues. There are still failing and error tests (they are even in PharoCore). > > Cheers > > Mariano > > > Cheers, > Alexandre > > > On 16 May 2010, at 11:14, StÃ©phane Ducasse wrote: > > > We are basically ready > > Waiting for feedback on network. > > > > Stef > > > > > > On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: > > > >> We said that for middle May we were going to freeze 1.1. This means, no more new features or refactors. Just bug fixes. So, the next steps can be: > >> > >> - Release a PharoCore1.1 with the last version we have so far tagged as alpha1 (please, put this tag in the zip, .image and .changes). This may be, for example: Pharo-1.1-11360-alpha1.image > >> - Build and release a Pharo 1.1 alpha1 based on such core (now we have almost all dev tools working well in 1.1) > >> - Make publish all new VMs (for each OS) > >> > >> Then the idea is that people/developers start to play with Pharo 1.1. It may be quite unstable as this is the first release for 1.1. People should try to load their own packages, adapt them (if necessary) to 1.1, and report all issues they find (and fixes!!). But they should keep in mind this the first alpha ;) > >> > >> With these, we will be testing: new VMs, PharoCore, PharoDev tools, and external packages (from other people). > >> > >> Pharo team at the same time, continues to work, fixing and integrating. We make new versions as we have been doing so far. When we consider, we release an alpha2....then beta, then RC and finally Pharo 1.1. > >> > >> now...do you think there is an issue that is so important to be fixed/included in the first Pharo1.1 even being a first alpha ? > >> > >> Cheers > >> > >> Mariano > >> _______________________________________________ > >> 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

May 17, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Igor Stasenko

2010/5/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sun, May 16, 2010 at 11:16 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> check the network problem. >> But we can release rc1 anytime now. >> > > No, please. We are not in a RC yet. We should first go as alpha, then beta > and finally RC. > We cannot go in a RC with the first build ever. > Yes , we can. Its only a conventions, what you calling alpha , beta or RC. But sure thing, more testing and packaging won't hurt. > Cheers > > Mariano > > >> -- Best regards, Igor Stasenko AKA sig.

May 17, 2010

Re: [Pharo-project] [squeak-dev] Re: Problem with variable capture in blocks or ? #7532

by Levente Uzonyi

On Sun, 16 May 2010, Eliot Miranda wrote: > On Sun, May 16, 2010 at 3:32 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > >> Hi Ken - >> >> Very interesting. Looks like an issue with OutOfScopeNotification. The >> problem appears to be that this code: >> >> "..." [ :a | a ]. >> "..." a. >> >> generates an OutOfScopeNotification that is being suppressed in workspaces >> (I'm not exactly sure why that is). This is of course is interesting because >> of the highly unusual situation of a temp shadowing a global instead of >> another temp / ivar. For example, this wouldn't compile: >> >> | a | >> [ :a | a ]. >> >> But stranglely, this does: >> >> [ :Object | Object ]. >> >> so your example code is roughly equivalent to running: >> >> b := [ :Object | Object ]. >> c := b value: Object. >> >> When you run this line by line it works 'as expected' and when you run it >> as a single doIt you get the result of c being a "[closure] in >> UndefinedObject>>DoIt" due to the OutOfScopeNotification. >> >> Hope this explains the issue - as for how to fix it, I have no clue :-) >> > > Yes, the bug is that Encoder>>encodeVariable:sourceRange:ifUnknown: doesn't > continue from a caught OutOfScopeNotification by answering the ifUnknown: > action. Instead it returns the out-of-scope block temp. This is a rather > serious compiler bug that I'd left unfixed because it only bites in > workspaces (apologies) and I didn't have a small example to analyse before > (thanks Ken!). The code generated is actually equivalent to > > b := [ :a | a ]. > c := b value: <temp 0>. > > Since there aren't any temps, temp 0 is top of stack, which just happens to > be the closure just created by the preceding bytecode. e.g. look at > bytecode 49 in the following: > > a := 4. b := [ :a | a ]. c := b value: a. { a. b. c } thisContext method > symbolic > > The fix is simple. When an OutOfScopeNotification is caught the Encoder > should still answer what ever it should for an out of scope variable. In > Encoder>>encodeVariable:sourceRange:ifUnknown: the statements > > (varNode isTemp and: [varNode scope < 0]) ifTrue: [ > OutOfScopeNotification signal ifFalse: [ ^self notify: 'out of scope']. > ]. > ^ varNode > > should read > > (varNode isTemp and: [varNode scope < 0]) ifTrue: > [^OutOfScopeNotification signal > ifTrue: [action value] > ifFalse: [self notify: 'out of scope']]. > ^varNode > > Find attached: > > !Encoder methodsFor: 'encoding' stamp: 'eem 5/16/2010 17:33'! > encodeVariable: name sourceRange: range ifUnknown: action > | varNode | > varNode := scopeTable > at: name > ifAbsent: > [(self lookupInPools: name > ifFound: [:assoc | varNode := self global: assoc name: name]) > ifTrue: [varNode] > ifFalse: [^action value]]. > range ifNotNil: > [name first canBeGlobalVarInitial ifTrue: > [globalSourceRanges addLast: { name. range. false }]]. > > (varNode isTemp and: [varNode scope < 0]) ifTrue: > [^OutOfScopeNotification signal > ifTrue: [action value] > ifFalse: [self notify: 'out of scope']]. > ^varNode! ! > > P.S. this is probably applicable to any Squeak bytecode compiler (including > eToys). The only change in my closure compiler from Andreas' 2003 version > was changing "name first isUppercase" to "name first canBeGlobalVarInitial". > > > P.P.S. Again Ken, thanks for a comprehensible example. It always bit me in > huge doits I was using to analyse the entire system's compiled methods, and > invariably crashed the VM. I never took the time to isolate the bug, I just > fixed the doit and continued. Turns out to be very simple. > > best > Eliot I would also expect the following to compile if temporaries can shadow instance variables: Foo >> #foo | b | a := 1. b := [ :a | a ]. ^b value: a. Where a is an instance variable of Foo. But I get: ^b value: out of scope ->a. Which doesn't make much sense IMHO. Levente > > >> Cheers, >> - Andreas >> >> >> >> On 5/16/2010 12:35 PM, Ken Causey wrote: >> >>> Well, it's nothing new but this one has stumped me: >>> >>> http://bugs.squeak.org/view.php?id=7532 >>> >>> Initially I (and Frank) thought the reporter was mistaken until we >>> understood that the problem shows up when you execute the main code all >>> in one do-it. I've since modified the original report to make this >>> clearer. >>> >>> So here it is: >>> >>> a := 4. >>> b := [ :a | a ]. >>> c := b value: a. >>> >>> If you SELECT ALL OF THIS AND EXECUTE IT ALL AT ONE TIME (crucial >>> detail). The result is that a is 4, b is a BlockClosure, and c is a >>> BlockClosure not 4 as expected. Execute each statement separately and c >>> is 4. >>> >>> Alternately, from a suggestion from jmckeon, if you specify a different >>> symbol for the block argument: >>> >>> a := 4. >>> b := [ :d | d ]. >>> c := b value: a. >>> >>> when executed all at one time works as you would expect: a is 4, b is a >>> BlockClosure, and c is 4. (and d is nil) >>> >>> So what's up? >>> >>> Ken >>> >>> >>> >>> >> >> >

May 17, 2010