[BUG] 0003400: Load Latest Code Updates Gives Walkback

Hi all,

I logged a bug in Mantis about loading latest code updates. I have an
image built upon a fresh 7020 3.9 image and I cannot seem to "load
code updates" to get the 3071 patch. Details are at
http://bugs.impara.de/view.php?id=3400.

It might just be me or my image, but I'm not sure why I get the
walkback about SMBase-gk.63 not found.

Any ideas or do I have to keep building new images from the latest and
greatest to get fixes?

John

--
It's easy to have a complicated idea. It's very very hard to have a
simple idea. -- Carver Mead

I meant to say, I cannot load updates to get the 7021 updates. Doh --
what the heck was thinking when I was typing? That wasn't even close.
;-)

On 3/29/06, John Pierce <[hidden email]> wrote:

--
It's easy to have a complicated idea. It's very very hard to have a
simple idea. -- Carver Mead

Hi all,

Am I missing something here? I cannot seem to load code updates from a
Squeak 3.9 image because Monticello appears to need a file that is not
available on the source.squeakfoundation.org/39a location.

How does the community propose that we keep 3.9 images up to date or
is "load code updates" no longer being used?

John

On 3/29/06, John Pierce <[hidden email]> wrote:

--
It's easy to have a complicated idea. It's very very hard to have a
simple idea. -- Carver Mead

On 30.03.2006, at 02:50, John Pierce wrote:

Do you have updated SqueakMap in the image? I think what
is happening is this: SqueakMap loaded the 2.1 version,
updating to the next alpha then will try to merge in the SqueakMap
changes in the 3.9a repository. For that, it tries to get the common  
ancestor.

Now the repository registered with the in-image SqueakMap pakcages is
wrong (old?) (modules.squeak...), resulting in the error.

> Any ideas or do I have to keep building new images from the latest and
> greatest to get fixes?
>

There is no really good way... the update stream allow to load a script
then then merges with the latest in the 3.9a repository. But that's  
slow,
and sometimes the results are not good... (see earlier discussions on
the list).

for 3.9b we think about using an updates based updatestream for  
making it
easier to track changes.

      Marcus

Yes, I did "open" SqueakMap in my 7020 3.9 image which requires it to
load the latest SqueakMap. There probably is no way around "not doing
this upgrade" if you want to use SqueakMap in 3.9. Right?

> Now the repository registered with the in-image SqueakMap pakcages is
> wrong (old?) (modules.squeak...), resulting in the error.

Yep -- this defintely seems to be happening.

> > Any ideas or do I have to keep building new images from the latest and
> > greatest to get fixes?
>
> There is no really good way... the update stream allow to load a script
> then then merges with the latest in the 3.9a repository. But that's
> slow,
> and sometimes the results are not good... (see earlier discussions on
> the list).

Ok, I was just more or less curious how everyone who is working on
3.9a gets the latest updates. I suspect from your response, it is not
the "update" stream, but rather directly from MC repositories.

> for 3.9b we think about using an updates based updatestream for
> making it
> easier to track changes.

Don't do it on my account. I am just trying to figure out how to work
with the latest and greatest. If there is a good way to keep my image
current that I'm not aware of then let me know.

Thanks,

John

On 02.04.2006, at 20:22, John Pierce wrote:
>
> Yes, I did "open" SqueakMap in my 7020 3.9 image which requires it to
> load the latest SqueakMap. There probably is no way around "not doing
> this upgrade" if you want to use SqueakMap in 3.9. Right?
>

Yes. Or just not use it...

>
> Ok, I was just more or less curious how everyone who is working on
> 3.9a gets the latest updates. I suspect from your response, it is not
> the "update" stream, but rather directly from MC repositories.
>

I personally rebuild my images quite often from scratch, and as a basis,
I use the latest 3.9a. So I don't update my work-image using the  
update stream
at all...  but the images are quite hacked, so rebuilding them from  
scratch
is a good thing to do to make sure that there is a way to re-create  
them at all.

I tend to like the rebuild more then the update way... rebuild
makes sure that there is a defined process of getting form a standard  
image
to whatever you are working on. When you just have one image that is  
updated,
you can come in a situation where moving your stuff into a new image  
will be
a lot of work.

To make the rebuild-from-scratch way really practical, it would be  
nice to
have an automatic build-and-test server. This could rebuild from  
latest (release
or alpha) + add all the cool tools + load your project's source and  
run all the tests.
And all that automatically over night...

>> for 3.9b we think about using an updates based updatestream for
>> making it
>> easier to track changes.
>
> Don't do it on my account. I am just trying to figure out how to work
> with the latest and greatest. If there is a good way to keep my image
> current that I'm not aware of then let me know.
>

updating an image is one of the weak spots of the current 3.9a process.
In a way, it's much better then what we had: loading via the update  
stream
as we did up to 3.8 will overwrite any change you did, MC will do a  
true merge.
The negative side is that merging is of course much slower.

I will put the problem of the wrong SM repository on the TODO.

     Marcus

Hi Marcus,

> I personally rebuild my images quite often from scratch, and as a basis,
> I use the latest 3.9a. So I don't update my work-image using the
> update stream
> at all...  but the images are quite hacked, so rebuilding them from
> scratch
> is a good thing to do to make sure that there is a way to re-create
> them at all.

Ok -- that's what I've been doing. I didn't realize that was the
standard mode of operation for 3.9a.

> To make the rebuild-from-scratch way really practical, it would be
> nice to
> have an automatic build-and-test server. This could rebuild from
> latest (release
> or alpha) + add all the cool tools + load your project's source and
> run all the tests.
> And all that automatically over night...

Well, it may not be exactly what you are looking for, but I did
recently update my 3.9 build script:
http://www.saltypickle.com/Home/18

It presently builds a 3.9a image with my favorite tools and
configurations from a brand new image. It builds images with a boat
load of my favorite packages in about 15 minutes. I suspect it could
be automated to generate nightly builds.

Regards,

John

It's easy to have a complicated idea. It's very very hard to have a
simple idea. -- Carver Mead

>
> Well, it may not be exactly what you are looking for, but I did
> recently update my 3.9 build script:
> http://www.saltypickle.com/Home/18
>
> It presently builds a 3.9a image with my favorite tools and
> configurations from a brand new image. It builds images with a boat
> load of my favorite packages in about 15 minutes. I suspect it could
> be automated to generate nightly builds.

Indeed this would be a good functionality, may be this should be  
added to
the testServer running at: http://testserver.smallhosting.info/

In the context of building a testserver that would automatically take
an image and run the tests (and remove or load some packages).
one of the questions we had is how can we get a list of the packages
to test for example a given dsitribution

On Apr 2, 2006, at 21:56 , stéphane ducasse wrote:

> Indeed this would be a good functionality, may be this should be  
> added to
> the testServer running at: http://testserver.smallhosting.info/

how comes that there are two test runs with different results for  
Squeak3.9alpha-7020?

It looks to me that this testrunner would be useful with just a bit  
more work. What seems missing is
- show delta between two test runs
- sending out reports by mail

Adrian

Yes
they did not have enough time, they are planning to work on that  
during their other projects
but we will see.

Stef

On 2 avr. 06, at 23:03, Adrian Lienhard wrote: