On April 10, 2009, Bert Freudenberg wrote:
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.
yes...
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.
well I ment RAM for Squeak + etoys image size. You are addressing image size below - I think you are saying currently whole image is in memory (which I assumed) but also there may be a way to load to memory only those pieces of the image that are referenced, is that correct? That would be very interesting. Out of my skill area, but interesting :) Worth adding to the squeakland bug list as enhancement , I should add it.
MIlan
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 -