etoys-dev March 2008

etoys-dev@lists.squeakfoundation.org

20 participants
26 discussions

[Etoys] [ANN] Squeak/Etoys OLPC page available
by Robert Krahn 24 Jul '08

24 Jul '08

Hi -- We are happy to announce our Squeak/Etoys OLPC page at http:// www.swa.hpi.uni-potsdam.de/projects/olpc/ where we are going to publish projects/content developed by our students. Comments are welcomed. Enjoy! Robert Krahn HPI Software Architecture Group http://www.swa.hpi.uni-potsdam.de/

6 12

[Etoys] suppressing auto phrase expansion in playfield
by K. K. Subramaniam 07 Apr '08

07 Apr '08

Hi, I am unable to suppress sprouting of scriptors around dropped phrase tiles in playfields by turning auto-phrase expansion option off. This used to work in the Squeakland images. Is this a bug or is it working as designed? This is in EToys 2.3#1896/non-XO. Subbu

2 1

[Etoys] etoys performance problems
by Ties Stuij 05 Apr '08

05 Apr '08

He lists (crossposting to Etoys and Squeak dev due to relevance for both), One can say that I am sort of taking over from Luke (Gorrie) as OLE Nepal's Etoys performance optimizer (optimizator?). And I'd like to give a status update, but I would especially like some advice on some issues. And the sooner the better. Cause we at OLE Nepal are in dire straits; we've got major performance issues, some of which are Etoys related, and some of which are Squeak related. And the reason for the speed is that we're gonna have to have a working XO build in a few days cause we have to train teachers, and in te beginning of April we're gonna flash a build to the machines of the children of the pilot schools, who will use it in the classrooms. So without further ado, except for this redundant sentence: project loading To start with the known, I've been looking into the project loading times, and have managed to cut them in half by removing the gzipping on the project files and just using the .pr file in stead of the zip which claims to be a .pr. Now this might of course not be the perfect solution for all, I did uncover some practices on which I'd like either the opinion of Squeak people in general or that of the Etoys people in particular. First, I noticed (together with Luke, who showed me the debugging ropes) that in the method asUnzippedStream, on ReadWriteStream, the method upToEndWithProgressBar uses '/' an awful lot to give the the right approximation to the progress bar. It sucked about 20 percent of the total loading time of an activity. So I changed upToEndWithProgressBar for upToEnd. Which seems like a more reasonable default 'cause I'd guess that usually one won't actually use the progress bar functionality. But thats not the end of it Etoys-wise. 'Cause it turns out an Etoys project file is gzipped twice. First the individual file in 'writeForExportWithSources:inDirectory:' and then the containing function writeForExportWithSources:inDirectory: as part of the .pr bundle. And this for a file that already has lots of it's contents compressed, seeing that most of the project file is taken up by jpegs. And this would ideally also be the case for sound files, but more on that later. The size decrease due to zipping in general is not more than 10%. So my question on this topic is: is there an argument for retaining the double zipping? And would there be a general need for a 'just save an uncompressed .pr file, instead of a bundle' option/patch? project deletion/memory growth Our second issue is related to memory growth within the Etoys image that's causing problems for the, let us say, memory-challenged XO. First of all we've got a, say, root project, which enumerates the activities which it reads from a few directories. In that root project we've got a script running that deletes child projects. Or it should anyway. The key method here is okToChange, which i guess is a bit of a misnomer. That is it's got a bunch of code in it that should remove a project and it's content from the image, but it doesn't. To make it concrete: we've got this script running in the root project: unloadActivitiesToFreeSpace Project current children do: [:t1 | t1 okToChange] "or okToChangeSilently, but okToChange is nice for debugging" But after removing a project, executing 'Project allInstances' shows that there is still a reference to the project and when one keeps an eye on the memory usage (with an OSX utility), we see that no memory is deallocated. So the image grows and grows. So my concrete question is: how can one for once and for all delete a project instance. I was hoping to at least find some generic deleteInstance method in the image, but I couldn't find one (I'm a bit of a Squeak newbie). Then it seems to me that the image grows quite fast in general. Is there some known garbage collection problem concerning Squeak or Etoys that I should know about? And related; when I'm gonna try and trim down the image size: any suggestions on where to start? Is there any known fat waiting to be caved off? Sound format Another strategy to trimming down the image size is using a compressed sound format. At the moment we use wav for sound right? If I'm wrong, excuse me, but I haven't had time to investigate the matter to thourougly. Anyways, since a number of activities have quite a few samples in them, ranging from short utterings to long sentences, it would be very worth while if we could use a compressed format. From the mailinglist I read rumours about Ogg plugin and a gstreamer plugin... Is it already possible to use Ogg files in Etoys? If so how? I'd already be happy with general directions. Well that's perhaps a bit more than quite enough questions for one post. I'll save some for later. It goes without saying that any advice on these topics would be greatly appreciated. /Ties

7 22

[Etoys] Pen color categoyry
by karl 03 Apr '08

03 Apr '08

I was playing a little with Etoys and pen use today and found that it's hard to change pen color of SketchMorphs in scripts because their color category in the Viewer is not in use. But many times I may want to change the pen color of a SketchMorph so I thought a Pen Color category could be nice. An other observation is that Pen color change is a little hard to accomplish because the color category give you access to the Player color and you have to remember to change to Players Pen color. A general Pen Color category would make the use a little easier because you would have the indirection already made. What do others think ? Karl

4 8

[Etoys] Animations in Squeak/Scratch and Flash
by Milan Zimmermann 01 Apr '08

01 Apr '08

This thread on Nortel learning: http://xoexperience.blogspot.com/ quote: " I followed with a conversation on the #squeak irc channel. Our conclusion: while it may be "possible" to generate 2D animations with Squeak, the conceptual differences between Squeak and flash are enormous, and this is not a practical option for our illustrator, Phi. To give you an idea of the kind work Phi does, take a look at this. If anyone knows of example animations made with eToys that look as good as what Phi did here, please let us know." reminded me of my wish that Squeak be used instead of Flash :) in addition to it being so nice for exploring.. That aside, I think the person who made the comment is right - I do not think Squeak can be used to create animations shown in there, at least I do not know how to. Does anyone have enough experience with Scratch to comment that perhaps Scratch could be used to create animations similar to those with equivalent or lower effort? Thanks Milan

4 6

Re: [Etoys] DrGeo sluggish
by Hilaire Fernandes 28 Mar '08

28 Mar '08

2008/3/28, John Gilmore <gnu(a)toad.com>: > > The calculus of the figure takes about 10s (the workaround for the > > incomplete implementation of the Squeak closure may take a lot of the > > needed time for the calculus) but then the rendering is pretty fast > > considering the CPU (no floating point unit) > > > FYI, there is a floating point unit in the XO. Oh great. Ok now I am not sure how is done floating point calculus within Squeak. Does it use the hardware resource (FPU) or does Squeak use its own calculus system with Taylor series or so ? Let's hear what Squeak friends say. Hilaire

2 1

[Etoys] Shutdown (was Re: Playing w/ Activity packs in build 702)
by Bert Freudenberg 28 Mar '08

28 Mar '08

On Mar 26, 2008, at 15:02 , Bryan Berry wrote: > In general, Etoys-based activities start pretty quickly but take a > long time to shutdown, literally 2 minutes. This is an issue our team > in Nepal is wrestling w/. Hopefully we will come up w/ a solution that > can be shared. I should ask Hilaire for help w/ this. What takes long is the project saving to the Journal. If you do not need that - take it out, and quitting will be instantaneous. - Bert -

3 2

Re: [Etoys] Shutdown (was Re: Playing w/ Activity packs in build 702)
by Bert Freudenberg 26 Mar '08

26 Mar '08

On Mar 26, 2008, at 15:38 , Hilaire Fernandes wrote: > 2008/3/26, Bert Freudenberg <bert(a)freudenbergs.de>: >> On Mar 26, 2008, at 15:02 , Bryan Berry wrote: >>> In general, Etoys-based activities start pretty quickly but take a >>> long time to shutdown, literally 2 minutes. This is an issue our >>> team >>> in Nepal is wrestling w/. Hopefully we will come up w/ a solution >>> that >>> can be shared. I should ask Hilaire for help w/ this. >> >> >> What takes long is the project saving to the Journal. If you do not >> need that - take it out, and quitting will be instantaneous. > > Why saving in the journal is so long? Saving a project is not optimized for speed. The checking into the datastore only adds a bit of overhead I think, although I did not actually measure it. - Bert -

1 0

Re: [Etoys] etoys performance problems
by Bert Freudenberg 26 Mar '08

26 Mar '08

On Mar 26, 2008, at 9:37 , Hans-Martin Mosner wrote: > Hilaire Fernandes schrieb: >> >> As a concrete simple example, how can I examine the content of this >> project file http://swiki.ofset.org:8000/super/36 (produced with a >> 3.8 >> image)? >> >> It use 3 graphics and I am really curious to know what inside >> the .pr file. >> >> The info I got from the .pr is: >> hilaire@tice:/tmp$ file ENGRENAGE4.001.pr >> ENGRENAGE4.001.pr: gzip compressed data, from FAT filesystem (MS- >> DOS, OS/2, NT) >> >> Once gunzipped, I can't examine the content... >> > Probably the file command is confused about this file. > .pr files are just ZIP files, so you should be able to unzip the > file to > see its contents. The format for .pr files changed over time. Hilaire's ENGRENAGE4.001.pr is indeed just a gzip-compressed object file, after decompressing it begins thus: 'From Squeak3.8 of ''5 May 2005'' [latest update: #6665] on 26 September 2005 at 4:44:57 pm'! !ObjectScanner new initialize! !self smartRefStream! ... followed by the data. Newer .pr files are zipped, and contain yet another .pr file which is a raw image segment. And then there is the new project file format that we are switching to now, it's a high-level text-based project description rather than a direct object serialization. The project loading code is pretty flexible and accepts many combinations of plain/zipped/gzipped refstreams or image segments or s- expressions. - Bert -

1 0

Re: [Etoys] [Fwd: etoy translation next steps]
by Gerhard Steiner 26 Mar '08

26 Mar '08

On Mar 25, 2008, at 19:08 , Gerhard Steiner wrote: >> / > />/ My last downloaded dev-zip was without lang/de/LC_MESSAGES directory, > />/ only a po/etoys-directory (with older de.po + etoy.pot). > / > Yes, you need to create that directory manually. Or copy it from an > etoys installation. Or use the SVN checkout directly which includes a > Makefile for this. > > ------ > > Thank you for the clarification, > I copied the etoys-dev.image + etoy-dev.changes into my "normal" > directory and so etoys-dev is working again with the latest > translation from pootle. > > Is there also a way to test/check/translate the newly inlcuded strings > eg for event theatre or do I have to wait for a pootle update. > > > > best regards > Gerhard Steiner > > > >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

etoys-dev March 2008