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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Adrian Lienhard -
Lukas Renggli -
Michael Roberts -
Stéphane Ducasse