On 10.04.2009, at 04:53, Milan Zimmermann wrote:

On April 9, 2009, Bert Freudenberg wrote:
> On 09.04.2009, at 07:15, Milan Zimmermann wrote:
> > On March 18, 2009, Bert Freudenberg wrote:
> > <...>
> >
> > > Etoys is the only pre-installed activity that can open zip files.
> >
> > When
> >
> > > you click on a zip file in the Journal, it opens in Etoys, and Etoys
> > > shows a little menu (probably in the upper-left corner):
> >
> > I just read about content files - Maybe we can make a (temporary)
> > olpc-extract.xo Content (xo) file that would open the zip in Etoys.
>
> Well it does open in Etoys already. There just is no simple way to
> extract to the Journal, yet.

ah I see. I thought there was a way because if I "highlight text and copy" from Etoys and the text appears in Journal, with a few associations. But yes I guess I did not see an example where a file (or files) would be put on clipboard...

Right. It could be added of course, dragging a file out of the ZIP viewer into the clipboard would be possible ... though we do have bigger fish to fry.

> > Probably an overkill in terms of size?
>
> What size do you mean?

i ment squeak size (could be smaller if tool only did zip/unzip). I think that would only be a potential issue if many were kept open. 

You mean RAM? Well it would be nice to compare a Python+GTK activity's memory footprint against Squeak.

Also, it might be time to start optimizing Squeak / Etoys which we have totally neglected in the last years.

One relatively simple thing to increase start-up speed would be to mmap the image and avoid scanning the whole object memory on startup. That way only the pages needed  would be actually loaded into RAM initially, not the whole image. I dabbled with this with Luke while in Nepal, and recently John did the same optimization for the iPhone VM. It's rather probable there is more such low-hanging fruit, if someone bothered to look.

- Bert -