Update stuck at #10457

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Update stuck at #10457

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Update stuck at #10457

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Update stuck at #10457

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Update stuck at #10457

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Update stuck at #10457

Michael Roberts-2
In reply to this post by Lukas Renggli
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 <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Update stuck at #10457

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 <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project