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

Re: [Pharo-project] [BUG]UndefinedObject(Object)>>doesNotUnderstand: #null

by Andrey Larionov

Sorry, not reproducible in last WebDev. Switch to new image. Thanks. On Mon, Oct 5, 2009 at 20:23, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > On Mon, Oct 5, 2009 at 7:19 AM, Â <anlarionov(a)gmail.com> wrote: >> Almost all refactorings ends with this DNU. Is it platform specific? Or >> maybe i miss something > > could you please describe all the steps to reproduce that from a clean download? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 5, 2009

Re: [Pharo-project] Update stuck at #10457

by StÃ©phane Ducasse

Yes I could but I need to know the correct version of Gofer and then I need to change the installGofer method of scriptLoader. Then this is not simple because I have to code this changes inside the cs else the old version of the script loader will point to an old version of the method. so yes this is possible but I would prefer to avoid it installGofer "self new installGofer" self class loadLatestPackage: 'Gofer' from: 'http://source.lukas- renggli.ch/flair' => installGofer "self new installGofer" ?? + "Postscript: Leave the line above, and replace the rest of this comment by a useful one. Executable statements should follow this comment, and should be separated by periods, with no exclamation points (!!). Be sure to put any further comments in double-quotes, like this one." | gofer packages | repository := MCHttpRepository location: 'http://www.squeaksource.com/Pharo/' user: '' password: ''. "A. Load Gofer" =>>>> compile new methods ScriptLoader new installGofer. "B. Install packages" gofer := Gofer new. gofer url: 'http://www.squeaksource.com/Pharo'. packages := #( "Part 2.1" 'Kernel-MikeRoberts.408' "Part 3" 'CompilerTests-MikeRoberts.21' 'KernelTests-MikeRoberts.150' 'Compiler-MikeRoberts.130' "Part 4" 'Compiler-MikeRoberts.131' "Part 5" 'Kernel-MikeRoberts.409' "Part 6" 'Kernel-MikeRoberts.411' "Part 7" 'System-Changes-MikeRoberts.13' 'System-Download-MikeRoberts.11' 'System-Support-MikeRoberts.89' "Part 8" 'Tools-MikeRoberts.202' "Part 9 - setup recompile" 'System-Support-MikeRoberts.90'). packages do: [:each | gofer copy add: each; load]. "C. Recompile" Utilities initializeClosures. Utilities compileUsingClosures. ! On Oct 5, 2009, at 6:55 PM, Michael Roberts wrote: > I'm hoping something like metacello in our process makes these things > go away ;-) > > can you retrospectively edit the update to point to the exact version? > > Mike > > On Monday, October 5, 2009, Lukas Renggli <renggli(a)gmail.com> wrote: >>> argh >>> lukas changed the gofer interface. >> >> I had to do this, because people have different naming conventions >> for >> packages. Before Gofer worked either for Moose or Seaside, but not >> for both at the same time. To solve the problem you have to follow >> the >> advice in the debugger. You tell Gofer if you specify an exact >> version >> (#addVersion:) or a package name (#addPackage:). If you don't do that >> (by proceeding or using #addPrefix:) the result is pretty much >> undefined. See the Moose mailing list for a lengthy discussion. >> >>> We should hardcode the number... >>> It was working before. >> >> For obvious reasons users of Gofer should always use a fixed version, >> not the "latest" one. >> >> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 5, 2009

Re: [Pharo-project] Update stuck at #10457

by Michael Roberts

I'm hoping something like metacello in our process makes these things go away ;-) can you retrospectively edit the update to point to the exact version? Mike On Monday, October 5, 2009, Lukas Renggli <renggli(a)gmail.com> wrote: >> argh >> lukas changed the gofer interface. > > I had to do this, because people have different naming conventions for > packages. Before Â Gofer worked either for Moose or Seaside, but not > for both at the same time. To solve the problem you have to follow the > advice in the debugger. You tell Gofer if you specify an exact version > (#addVersion:) or a package name (#addPackage:). If you don't do that > (by proceeding or using #addPrefix:) the result is pretty much > undefined. See the Moose mailing list for a lengthy discussion. > >> We should hardcode the number... >> It was working before. > > For obvious reasons users of Gofer should always use a fixed version, > not the "latest" one. > > 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 >

Oct. 5, 2009

Re: [Pharo-project] Update stuck at #10457

by StÃ©phane Ducasse

yes! No problem and for now this is like that. On Oct 5, 2009, at 6:45 PM, Lukas Renggli wrote: >> argh >> lukas changed the gofer interface. > > I had to do this, because people have different naming conventions for > packages. Before Gofer worked either for Moose or Seaside, but not > for both at the same time. To solve the problem you have to follow the > advice in the debugger. You tell Gofer if you specify an exact version > (#addVersion:) or a package name (#addPackage:). If you don't do that > (by proceeding or using #addPrefix:) the result is pretty much > undefined. See the Moose mailing list for a lengthy discussion. > >> We should hardcode the number... >> It was working before. > > For obvious reasons users of Gofer should always use a fixed version, > not the "latest" one. > > 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

Oct. 5, 2009

Re: [Pharo-project] Update stuck at #10457

by Lukas Renggli

> argh > lukas changed the gofer interface. I had to do this, because people have different naming conventions for packages. Before Gofer worked either for Moose or Seaside, but not for both at the same time. To solve the problem you have to follow the advice in the debugger. You tell Gofer if you specify an exact version (#addVersion:) or a package name (#addPackage:). If you don't do that (by proceeding or using #addPrefix:) the result is pretty much undefined. See the Moose mailing list for a lengthy discussion. > We should hardcode the number... > It was working before. For obvious reasons users of Gofer should always use a fixed version, not the "latest" one. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 5, 2009

Re: [Pharo-project] [BUG]UndefinedObject(Object)>>doesNotUnderstand: #null

by Damien Cassou

Hi, On Mon, Oct 5, 2009 at 7:19 AM, <anlarionov(a)gmail.com> wrote: > Almost all refactorings ends with this DNU. Is it platform specific? Or > maybe i miss something could you please describe all the steps to reproduce that from a clean download? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Oct. 5, 2009

Re: [Pharo-project] Update stuck at #10457

by StÃ©phane Ducasse

argh lukas changed the gofer interface. We should hardcode the number... It was working before. Stef On Oct 5, 2009, at 5:24 PM, Adrian Lienhard wrote: > Hi, > > I tried to update from an older image and got stuck in update #10457. > I get a warning with the following text: > > "Please note that adding package references as strings (such as > 'Kernel-MikeRoberts.408') is no longer supported, because Gofer cannot > guess your naming conventions. Adapt your code to either call > #addPackage: (for full package names e.g. Gofer), #addVersion: (for > complete version names, e.g. Gofer-lr.54) or #addPrefix: (for > incomplete version names, e.g. Gofer-lr). This lets Gofer know what > exactly you want, and in return it will more likely do what you > expect." > > I click proceed but the warning appears again. After probably 5x > proceeding I get a MNU: BytecodeAgnosticMethod>>doesNotUnderstand: > #blockExtentsToTempRefs from which I cannot recover. > > Is this a known issue? > > Cheers, > Adrian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 5, 2009

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: Compiler-jcg.85.mcz

by StÃ©phane Ducasse

I do not know. I just thought that we should have a look. > Not sure we want this without due consideration. Eliot deprecated > them. Is there a conversation going on about why the new scheme could > not be used? I'm not subscribed. > Cheers > Mike > > On Monday, October 5, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: >> >> >> Begin forwarded message: >> >>> From: commits(a)source.squeak.org >>> Date: September 30, 2009 10:14:22 AM GMT+02:00 >>> To: squeak-dev(a)lists.squeakfoundation.org >>> Subject: [squeak-dev] The Trunk: Compiler-jcg.85.mcz >>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>> >>> Joshua Gargus uploaded a new version of Compiler to project The >>> Trunk: >>> http://source.squeak.org/trunk/Compiler-jcg.85.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Compiler-jcg.85 >>> Author: jcg >>> Time: 30 September 2009, 1:14:16 am >>> UUID: 21a5f88d-4107-48c3-b41c-d5ea735319a7 >>> Ancestors: Compiler-tfel.84 >>> >>> Revert to lazy-initialization of method properties, which is used by >>> the externally-maintained Prolog package (which loads cleanly into >>> 3.10.2, but not trunk). >>> >>> Part 1 of 2... need to first re-add the #properties method to Parser >>> before changing methods to send it. >>> >>> =============== Diff against Compiler-tfel.84 =============== >>> >>> Item was added: >>> + ----- Method: Parser>>properties (in category 'pragmas') ----- >>> + properties >>> + ^ properties ifNil: [ properties := AdditionalMethodState >>> new ]! >>> >>> >> >> >> _______________________________________________ >> 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

Oct. 5, 2009

[Pharo-project] [update] #10467

by Marcus Denker

10467 ----- Issue 1260: [Regression?] Issue 277 (SelfEvaluating Arrays) wasn't integrated in beta-10462 Issue 987: 'stack top' variable on debugger crashes it Issue 1269: findLastOccurenceOfStringFix has broken a previous WideString patch -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Oct. 5, 2009

[Pharo-project] Update stuck at #10457

by Adrian Lienhard

Hi, I tried to update from an older image and got stuck in update #10457. I get a warning with the following text: "Please note that adding package references as strings (such as 'Kernel-MikeRoberts.408') is no longer supported, because Gofer cannot guess your naming conventions. Adapt your code to either call #addPackage: (for full package names e.g. Gofer), #addVersion: (for complete version names, e.g. Gofer-lr.54) or #addPrefix: (for incomplete version names, e.g. Gofer-lr). This lets Gofer know what exactly you want, and in return it will more likely do what you expect." I click proceed but the warning appears again. After probably 5x proceeding I get a MNU: BytecodeAgnosticMethod>>doesNotUnderstand: #blockExtentsToTempRefs from which I cannot recover. Is this a known issue? Cheers, Adrian

Oct. 5, 2009