Hi!

tim Rowledge <tim at rowledge.org> wrote:
> On 10-Jan-06, at 3:48 PM, Avi Bryant wrote:
> > Well, what Timothy may be asking about is the delay when SqueakMap  
> > refreshes the map of available packages.  IIRC, this is done by  
> > loading an image segment, which is a primitive, and so *does* block  
> > the whole VM.
> Fair point and one I didn't think of. The image segment loading  
> primitive is very fast though and is only a small part of the job of  
> loading and integrating a segment. I was thinking of the generic  
> process of loading source packages and compiling them. Should have  
> remembered binary loading.

My guess is still that Tim answered the "right" question. And btw, we
could improve this a bit because it goes like this:

Update the map:

1. Download the latest imagesegment.
2. Load it.

#1 above could be done in a background process (or using the mechanism
Tim mentioned), #2 can not - but it is typically a small part of it.

Load a package:

3. Download it into the cache if not there.
4. Install it using the appropriate mechanism depending on format.

#3 above could be done in a background process, #4 is actually not
SqueakMap code, so for example Monticello could (if it knew how to make
it safely) perform it in a background process.

Now... regarding 1: it wouldn't be much of a job to fix those, but since
I actually want to move away from the ImageSegment model it is probably
not wisely spent dev time. Number 3 on the other hand should be fixed,
and in fact - I want to add more functions for maintaining the local
cache on disk - like for preloading it in the background etc.

So let me give that a shot in the next version, ok? :) And for number 1
- if anyone feel like attacking it and send me code - go right ahead, it
shouldn't be too hard, just fork off the download and then when it is
ready - perform #2 as today.

regards, Göran