[squeak-dev] Trunk update hang while installing Compiler-ar.81

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

[squeak-dev] Trunk update hang while installing Compiler-ar.81

Nicolas Cellier
I guess the order of loading matters...
Behavior might differ whether you update every day or every few weeks...
Doesn't this require an intermediate configuration map?

Nicolas



SqueakDebug.log (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Trunk update hang while installing Compiler-ar.81

Andreas.Raab
Nicolas Cellier wrote:
> I guess the order of loading matters...
> Behavior might differ whether you update every day or every few weeks...
> Doesn't this require an intermediate configuration map?

No, there is something strange in your image. From the debug log it is
clear that the failure is in Parser>>method:context:encoder: sending
#new to nil. The only send to #new in that method is the very first line
saying:

        properties := AdditionalMethodState new.

So for some reason AdditionalMethodState must be undefined in your
image. And that is *very* odd since AdditionalMethodState is defined way
earlier (in Kernel-eem.242 loaded via update-ar.14.mcm) than the
Parser>>method:context:encoder: (in Compiler-eem.79 loaded via
update-ar.15.mcm). So the load order should be precisely:

* update-ar.14: Loads Kernel-eem.242 introducing AdditionalMethodState
* update-ar.15: Loads Compiler-eem.79 using AdditionalMethodState
* update-ar.16: Loads Compiler-ar.81 recompiling everything

Can you try updating again to see if this may have been an intermittant
problem (keeping an eye on the transcript to see if there are any server
timeout messages etc). If you still get the problem, can you try loading
the update MCMs manually to see if this makes any difference?

Thanks,
   - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Trunk update hang while installing Compiler-ar.81

Nicolas Cellier
Ah, my fault, I was using an obsolete MCM location:

MCMcmUpdater updateFromRepositories: #(
                'http://squeaksource.com/MCUpdateTest'
        ).

I guess it did work so long because I updated frequently...
I retried successfully with:

MCMcmUpdater updateFromRepositories: #(
                'http://source.squeak.org/trunk'
        ).

Thanks

Nicolas

2009/9/10 Andreas Raab <[hidden email]>:

> Nicolas Cellier wrote:
>>
>> I guess the order of loading matters...
>> Behavior might differ whether you update every day or every few weeks...
>> Doesn't this require an intermediate configuration map?
>
> No, there is something strange in your image. From the debug log it is clear
> that the failure is in Parser>>method:context:encoder: sending #new to nil.
> The only send to #new in that method is the very first line saying:
>
>        properties := AdditionalMethodState new.
>
> So for some reason AdditionalMethodState must be undefined in your image.
> And that is *very* odd since AdditionalMethodState is defined way earlier
> (in Kernel-eem.242 loaded via update-ar.14.mcm) than the
> Parser>>method:context:encoder: (in Compiler-eem.79 loaded via
> update-ar.15.mcm). So the load order should be precisely:
>
> * update-ar.14: Loads Kernel-eem.242 introducing AdditionalMethodState
> * update-ar.15: Loads Compiler-eem.79 using AdditionalMethodState
> * update-ar.16: Loads Compiler-ar.81 recompiling everything
>
> Can you try updating again to see if this may have been an intermittant
> problem (keeping an eye on the transcript to see if there are any server
> timeout messages etc). If you still get the problem, can you try loading the
> update MCMs manually to see if this makes any difference?
>
> Thanks,
>  - Andreas
>
>
>