[squeak-dev] to be deployed Epaati version is out!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] to be deployed Epaati version is out!

Ties Stuij
Well, it took us at OLE Nepal a whole lot of sweat and especially
tears, but finally, after half a year of hard work, we finished the
first build that is actually going to be used by actual Nepali kids,
in an actual classroom setting.

This build, version 10, sports a whopping 47 activities, which is why
it's 105 mb in size. The loading time of individual activities has
also diminished  by quite a bit (sometimes loading is 3 to 4 times as
fast), and memory consumption has been greatly reduced.

And this is just the beginning, because there are a great many much of
activities to be made in the future.

get it here: http://dev.laptop.org/pub/epaati/Epaati-10.xo

For you who never heard about Epaati: it's an activity suite (for now)
geared towards grades 2 and 6 (roughly 8 respectively 12 year old
kids) of the Nepali school system coinciding, not coincidentally,
with the classes which are the focus of our pilot projects. The
subjects covered are Maths and English, and we follow the official
Nepali curriculum so our activities can be integrated seamlessly in
regular sessions.

Which is not to say of course they can not be used by others.
Especially the English activities can be used practically as is by
children with another mother tongue, save for the help text. Also
converting the maths activities should be not a big deal, since not a
lot of Nepali specific text is used, but there are some brambles to be
fished out of the porridge, before we have a smooth mechanism for
translation.

Anyways, have fun with the new and old activities,

/Ties

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: to be deployed Epaati version is out!

Tomeu Vizoso
Hi,

On Mon, Apr 21, 2008 at 10:38 AM, Ties Stuij <[hidden email]> wrote:
...
>  This build, version 10, sports a whopping 47 activities, which is why
>  it's 105 mb in size. The loading time of individual activities has
>  also diminished  by quite a bit (sometimes loading is 3 to 4 times as
>  fast), and memory consumption has been greatly reduced.
...

Riccardo Lucchese has been looking at squeak performance and is
applying for working on performance in Sugar for the Google SoC.

Do you have any particular area in eToys that you would like to see
profiled, analyzed and maybe optimized?

Thanks,

Tomeu

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: to be deployed Epaati version is out!

Bert Freudenberg
In reply to this post by Ties Stuij
On 21.04.2008, at 10:38, Ties Stuij wrote:

> Well, it took us at OLE Nepal a whole lot of sweat and especially
> tears, but finally, after half a year of hard work, we finished the
> first build that is actually going to be used by actual Nepali kids,
> in an actual classroom setting.
>
> This build, version 10, sports a whopping 47 activities, which is why
> it's 105 mb in size. The loading time of individual activities has
> also diminished  by quite a bit (sometimes loading is 3 to 4 times as
> fast), and memory consumption has been greatly reduced.
>
> And this is just the beginning, because there are a great many much of
> activities to be made in the future.
>
> get it here: http://dev.laptop.org/pub/epaati/Epaati-10.xo

Namasté - kudos to the OLE Nepal team, and good luck in your pilots!

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] to be deployed Epaati version is out!

Bert Freudenberg
In reply to this post by Ties Stuij
On 21.04.2008, at 10:38, Ties Stuij wrote:

> This build, version 10, sports a whopping 47 activities, which is why
> it's 105 mb in size.

Why are you including the sources and changes? That's 20 MB you can  
easily shave off.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] to be deployed Epaati version is out!

Ties Stuij
On Mon, Apr 21, 2008 at 10:28 PM, Bert Freudenberg <[hidden email]> wrote:
> On 21.04.2008, at 10:38, Ties Stuij wrote:
>
>
> > This build, version 10, sports a whopping 47 activities, which is why
> > it's 105 mb in size.
> >
>
>  Why are you including the sources and changes? That's 20 MB you can easily
> shave off.

Ah, yes that's true. Didn't think about shrinking hd space consumption
because it hasn't been an issue. But I guess it will soon be once the
children start to amass things. Thanks.

/Ties

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] to be deployed Epaati version is out!

Bert Freudenberg

On 22.04.2008, at 05:38, Ties Stuij wrote:

> On Mon, Apr 21, 2008 at 10:28 PM, Bert Freudenberg <[hidden email]
> > wrote:
>> On 21.04.2008, at 10:38, Ties Stuij wrote:
>>
>>
>>> This build, version 10, sports a whopping 47 activities, which is  
>>> why
>>> it's 105 mb in size.
>>>
>>
>> Why are you including the sources and changes? That's 20 MB you can  
>> easily
>> shave off.
>
> Ah, yes that's true. Didn't think about shrinking hd space consumption
> because it hasn't been an issue. But I guess it will soon be once the
> children start to amass things. Thanks.


Also, Scott very recently (in the 3.0 updates) fixed project saving to  
flush unreferenced players. Projects where becoming larger and larger  
even when deleting stuff ...

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] to be deployed Epaati version is out!

Karl-19
In reply to this post by Ties Stuij
Congratulations !

I have not looked at the latest stuff yet, but it looked impressive a
few weeks back :-)

Karl


Ties Stuij wrote:

> Well, it took us at OLE Nepal a whole lot of sweat and especially
> tears, but finally, after half a year of hard work, we finished the
> first build that is actually going to be used by actual Nepali kids,
> in an actual classroom setting.
>
> This build, version 10, sports a whopping 47 activities, which is why
> it's 105 mb in size. The loading time of individual activities has
> also diminished  by quite a bit (sometimes loading is 3 to 4 times as
> fast), and memory consumption has been greatly reduced.
>
> And this is just the beginning, because there are a great many much of
> activities to be made in the future.
>
> get it here: http://dev.laptop.org/pub/epaati/Epaati-10.xo
>
> For you who never heard about Epaati: it's an activity suite (for now)
> geared towards grades 2 and 6 (roughly 8 respectively 12 year old
> kids) of the Nepali school system coinciding, not coincidentally,
> with the classes which are the focus of our pilot projects. The
> subjects covered are Maths and English, and we follow the official
> Nepali curriculum so our activities can be integrated seamlessly in
> regular sessions.
>
> Which is not to say of course they can not be used by others.
> Especially the English activities can be used practically as is by
> children with another mother tongue, save for the help text. Also
> converting the maths activities should be not a big deal, since not a
> lot of Nepali specific text is used, but there are some brambles to be
> fished out of the porridge, before we have a smooth mechanism for
> translation.
>
> Anyways, have fun with the new and old activities,
>
> /Ties
>
>
>  


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: to be deployed Epaati version is out!

Ties Stuij
In reply to this post by Tomeu Vizoso
On Mon, Apr 21, 2008 at 3:06 PM, Tomeu Vizoso <[hidden email]> wrote:
>  Do you have any particular area in eToys that you would like to see
>  profiled, analyzed and maybe optimized?

Yes! Of course ;o)

Sorry for reacting so late on such an inviting mail.

One of our most pressing problems has to do with continual image
growth, when opening multiple projects. After opening and closing
around 20 projects on an XO, the amount of memory the vm uses
(according to the vm stats), has climbed from 60 to 95 mb, and soon
afterwards we get an out of memory error.

First I thought that old projects were lingering around, but they do
seem to be garbage-collected eventually. There is no reference or
pointer to them to be found in any case. I haven't had the time to do
any space profiling to see who or what could then be the cause of the
trouble.

Furthermore we would still want to see the project loading time of
projects to go down. At the moment our longest loading project still
takes around 36 secs on a good day, while most take around
twenty-something. The latest discussion on which was a bit back on
zipping project files. But that might perhaps have less chance on huge
leaps forward and easy succes, not to mention unrestrained and
neverending gratitude, as might be the result of solving the image
growth problem.

In general what we would like to see is more animation possibilities,
so anything that can make animation more efficient would be very
welcome.

Also anything that has got to do with more effective audio-handling
would be desirable. Right now we're thinking of just referencing audio
from external files, because a number of clips need to be shared, even
compressed, they take up a lot of space in audio-intensive activities
(not to be found in the released bundle, because of said restraints),
and also because everything that needs to be loaded at project loading
time prolongues the project loading.

The same could be said for images, so to rattle on, it would be nice
to pluck these kind of files from some kind of shared resource. That
would definately be an optimization in our situation, but would
perhaps be to specific of a need. I feel that the stuff we do with
Etoys isn't really the stuff that Etoys was intended for which has in
my mind more to do with explorating concepts in stead of delivering
polished applications. But I might be wrong.

Anyhow, any help on this front would of course be greatly welcomed,

/Ties

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: to be deployed Epaati version is out!

Karl-19
Ties Stuij wrote:

> On Mon, Apr 21, 2008 at 3:06 PM, Tomeu Vizoso <[hidden email]> wrote:
>  
>>  Do you have any particular area in eToys that you would like to see
>>  profiled, analyzed and maybe optimized?
>>    
>
> Yes! Of course ;o)
>
> Sorry for reacting so late on such an inviting mail.
>
> One of our most pressing problems has to do with continual image
> growth, when opening multiple projects. After opening and closing
> around 20 projects on an XO, the amount of memory the vm uses
> (according to the vm stats), has climbed from 60 to 95 mb, and soon
> afterwards we get an out of memory error.
>
> First I thought that old projects were lingering around, but they do
> seem to be garbage-collected eventually. There is no reference or
> pointer to them to be found in any case. I haven't had the time to do
> any space profiling to see who or what could then be the cause of the
> trouble.
>  

I think there was a fix for this in the etoys 3.0 upadate stream.

> Furthermore we would still want to see the project loading time of
> projects to go down. At the moment our longest loading project still
> takes around 36 secs on a good day, while most take around
> twenty-something. The latest discussion on which was a bit back on
> zipping project files. But that might perhaps have less chance on huge
> leaps forward and easy succes, not to mention unrestrained and
> neverending gratitude, as might be the result of solving the image
> growth problem.
>  

Since you use your own image, epaati, you could just load all the
projects and save the image with them loaded. You would have a giant
image but switching would be quick. External projects is more a feature
of etoys to make projects shareable and keep the image 'clean'.

Karl
> In general what we would like to see is more animation possibilities,
> so anything that can make animation more efficient would be very
> welcome.
>  

> Also anything that has got to do with more effective audio-handling
> would be desirable. Right now we're thinking of just referencing audio
> from external files, because a number of clips need to be shared, even
> compressed, they take up a lot of space in audio-intensive activities
> (not to be found in the released bundle, because of said restraints),
> and also because everything that needs to be loaded at project loading
> time prolongues the project loading.
>
> The same could be said for images, so to rattle on, it would be nice
> to pluck these kind of files from some kind of shared resource. That
> would definately be an optimization in our situation, but would
> perhaps be to specific of a need. I feel that the stuff we do with
> Etoys isn't really the stuff that Etoys was intended for which has in
> my mind more to do with explorating concepts in stead of delivering
> polished applications. But I might be wrong.
>
> Anyhow, any help on this front would of course be greatly welcomed,
>
> /Ties
>
>
>  


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: to be deployed Epaati version is out!

Ties Stuij
On Wed, Apr 23, 2008 at 3:55 PM, karl <[hidden email]> wrote:

> Ties Stuij wrote:
>
> > On Mon, Apr 21, 2008 at 3:06 PM, Tomeu Vizoso <[hidden email]>
> wrote:
> >
> >
> > >  Do you have any particular area in eToys that you would like to see
> > >  profiled, analyzed and maybe optimized?
> > >
> > >
> >
> > Yes! Of course ;o)
> >
> > Sorry for reacting so late on such an inviting mail.
> >
> > One of our most pressing problems has to do with continual image
> > growth, when opening multiple projects. After opening and closing
> > around 20 projects on an XO, the amount of memory the vm uses
> > (according to the vm stats), has climbed from 60 to 95 mb, and soon
> > afterwards we get an out of memory error.
> >
> > First I thought that old projects were lingering around, but they do
> > seem to be garbage-collected eventually. There is no reference or
> > pointer to them to be found in any case. I haven't had the time to do
> > any space profiling to see who or what could then be the cause of the
> > trouble.
> >
> >
>
>  I think there was a fix for this in the etoys 3.0 upadate stream.

That would be great! Any idea which fix?

>  Since you use your own image, epaati, you could just load all the projects
> and save the image with them loaded. You would have a giant image but
> switching would be quick. External projects is more a feature of etoys to
> make projects shareable and keep the image 'clean'.

Unfortunately the XO doesn't have enough ram to make that a feasable
solution in my experience.

/Ties

Reply | Threaded
Open this post in threaded view
|

Sound compression Re: [squeak-dev] Re: to be deployed Epaati version is out!

Karl-19
Hi
I looked at the project and noticed you did not use sound compression.
I think you could save a lot of space using Ogg Vorbis or Speex.
To compress the sounds you do this:
    1 File in attached change set
    2 Open SoundLibraryTool found in Multimedia in ObjectTool
    3 Select the sound to compress
    4 Bring up halo on the SoundLibraryTool
    5 In the halo menu there is a option to compress the sound
    6 goto3

Karl

'From etoys2.3 of 2 December 2007 [latest update: #1849] on 5 January 2008 at 2:19:47 am'! "Change Set: SoundLibraryCompress
Date: 5 January 2008
Author: Karl Ramberg

Add a halo menu item that GSM compress and replace the selected sound Now also OggVorbis and OggSpeex codec. Prevents the default library sounds to be compressed. Stops playing the current sound if its deleted"! !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 1/5/2008 02:18'! addCustomMenuItems: aMenu hand: aHand
        "Add custom menu items to a menu"

        super addCustomMenuItems: aMenu hand: aHand.
        aMenu addTranslatedList: #(
                ('wave editor' edit 'open a tool which, operating with the selected sound as a point of departure, will allow you to construct a new "instrument"')
                ('GSM compress sound' compressWithGSM 'Simple compression')
                ('OggSpeex compress sound' compressWithOggSpeex 'Speech compression') ('OggVorbis compress sound' compressWithOggVorbis 'Music compression') ) translatedNoop ! ! !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 12/6/2007 09:03'! compressWithGSM
        "Compress the sound." self compressWith: GSMCodec! ! !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 12/6/2007 09:03'! compressWithOggSpeex "Compress the sound." self compressWith: OggSpeexCodec! ! !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 12/14/2007 23:19'! compressWithOggVorbis "Compress the sound."        self compressWith: OggVorbisCodec.     ! ! !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 1/5/2008 02:17'! compressWith: aCodec "Compress the sound." | newSound name writer | soundIndex = 0 ifTrue: [^ self inform: 'No sound selected' translated]. name := listBox getList at: soundIndex. (SampledSound universalSoundKeys includes: name) ifTrue: [^ self inform: 'You can not compress this sound' translated]. newSound := currentSound compressWith: aCodec. writer := ByteArray new writeStream. newSound channels do: [:channel | writer nextPutAll: channel]. SampledSound removeSoundNamed: name. SampledSound addLibrarySoundNamed: name bytes: writer contents codecSignature: newSound codecSignature. currentSound := SampledSound soundNamed: name! ! !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 12/15/2007 00:00'! deleteSound "Delete the selected sound, if appropriate." | name | soundIndex = 0 ifTrue: [^ self inform: 'No sound selected' translated]. currentSound pause. name := listBox getList at: soundIndex. (SampledSound universalSoundKeys includes: name) ifTrue: [self inform: 'You can not delete this sound' translated] ifFalse: [ScriptingSystem removeFromSoundLibrary: name]. self soundIndex: 0. listBox updateList! !

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: to be deployed Epaati version is out!

Karl-19
In reply to this post by Ties Stuij
Ties Stuij wrote:
>
>>  I think there was a fix for this in the etoys 3.0 upadate stream.
>>    
>
> That would be great! Any idea which fix?
>  
I think it was this:
http://tinlizzie.org/updates/etoys/updates/1924lingeringPlayers-sw.cs

Karl

Reply | Threaded
Open this post in threaded view
|

Re: Sound compression Re: [squeak-dev] Re: to be deployed Epaati version is out!

Ties Stuij
In reply to this post by Karl-19
On Wed, Apr 23, 2008 at 4:46 PM, karl <[hidden email]> wrote:
> Hi
>  I looked at the project and noticed you did not use sound compression.
>  I think you could save a lot of space using Ogg Vorbis or Speex.

Yes, definitely. And I have actually already fumbled around with
attached changeset, but we had so much to fix and test and so little
time, that we didn't have time to incorporate it. But thanks for the
patch!

>  To compress the sounds you do this:
>    1 File in attached change set
>    2 Open SoundLibraryTool found in Multimedia in ObjectTool
>    3 Select the sound to compress
>    4 Bring up halo on the SoundLibraryTool
>    5 In the halo menu there is a option to compress the sound
>    6 goto3
>
>  Karl
>
> 'From etoys2.3 of 2 December 2007 [latest update: #1849] on 5 January 2008
> at 2:19:47 am'!
>  "Change Set:            SoundLibraryCompress
>  Date:                   5 January 2008
>  Author:                 Karl Ramberg
>
>  Add a halo menu item that GSM compress and replace the selected sound
>  Now also OggVorbis and OggSpeex codec. Prevents the default library sounds
> to be compressed. Stops playing the current sound if its deleted"!
>
>
>  !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 1/5/2008 02:18'!
>  addCustomMenuItems: aMenu hand: aHand
>         "Add custom menu items to a menu"
>
>         super addCustomMenuItems: aMenu hand: aHand.
>         aMenu addTranslatedList: #(
>                 ('wave editor' edit 'open a tool which, operating with the
> selected sound as a point of departure, will allow you to construct a new
> "instrument"')
>                 ('GSM compress sound' compressWithGSM 'Simple compression')
>                 ('OggSpeex compress sound' compressWithOggSpeex 'Speech
> compression')
>                 ('OggVorbis compress sound' compressWithOggVorbis 'Music
> compression')
>         ) translatedNoop
>  ! !
>
>  !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 12/6/2007 09:03'!
>  compressWithGSM
>         "Compress the sound."
>         self compressWith: GSMCodec! !
>
>  !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 12/6/2007 09:03'!
>  compressWithOggSpeex
>         "Compress the sound."
>         self compressWith: OggSpeexCodec! !
>
>  !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 12/14/2007 23:19'!
>  compressWithOggVorbis
>         "Compress the sound."
>         self compressWith: OggVorbisCodec.
>
>         ! !
>
>  !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 1/5/2008 02:17'!
>  compressWith: aCodec
>         "Compress the sound."
>         | newSound name writer |
>         soundIndex = 0
>                 ifTrue: [^ self inform: 'No sound selected' translated].
>         name := listBox getList at: soundIndex.
>         (SampledSound universalSoundKeys includes: name)
>                 ifTrue: [^ self inform: 'You can not compress this sound'
> translated].
>         newSound := currentSound compressWith: aCodec.
>         writer := ByteArray new writeStream.
>         newSound channels
>                 do: [:channel | writer nextPutAll: channel].
>         SampledSound removeSoundNamed: name.
>         SampledSound
>                 addLibrarySoundNamed: name
>                 bytes: writer contents
>                 codecSignature: newSound codecSignature.
>         currentSound := SampledSound soundNamed: name! !
>
>  !SoundLibraryTool methodsFor: 'menu' stamp: 'kfr 12/15/2007 00:00'!
>  deleteSound
>         "Delete the selected sound, if appropriate."
>
>          | name |
>         soundIndex = 0
>                 ifTrue: [^ self inform: 'No sound selected' translated].
>         currentSound pause.
>         name := listBox getList at: soundIndex.
>         (SampledSound universalSoundKeys includes: name)
>                 ifTrue: [self inform: 'You can not delete this sound'
> translated]
>                 ifFalse: [ScriptingSystem removeFromSoundLibrary: name].
>         self soundIndex: 0.
>         listBox updateList! !

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: to be deployed Epaati version is out!

Ties Stuij
In reply to this post by Karl-19
On Wed, Apr 23, 2008 at 4:47 PM, karl <[hidden email]> wrote:
> Ties Stuij wrote:
>  I think it was this:
>  http://tinlizzie.org/updates/etoys/updates/1924lingeringPlayers-sw.cs

Yes I saw this one, but at a quick glance it seemed this is only
relevant when projects themselves are open for a long time,  and
besides this method will only be invoked when saving. Not that it
won't be useful, but it won't solve our problem.

/Ties

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: to be deployed Epaati version is out!

Bert Freudenberg
In reply to this post by Ties Stuij

On 23.04.2008, at 11:01, Ties Stuij wrote:

> On Mon, Apr 21, 2008 at 3:06 PM, Tomeu Vizoso  
> <[hidden email]> wrote:
>> Do you have any particular area in eToys that you would like to see
>> profiled, analyzed and maybe optimized?
>
> Yes! Of course ;o)
>
> Sorry for reacting so late on such an inviting mail.
>
> One of our most pressing problems has to do with continual image
> growth, when opening multiple projects. After opening and closing
> around 20 projects on an XO, the amount of memory the vm uses
> (according to the vm stats), has climbed from 60 to 95 mb, and soon
> afterwards we get an out of memory error.
>
> First I thought that old projects were lingering around, but they do
> seem to be garbage-collected eventually. There is no reference or
> pointer to them to be found in any case. I haven't had the time to do
> any space profiling to see who or what could then be the cause of the
> trouble.
>
> Furthermore we would still want to see the project loading time of
> projects to go down. At the moment our longest loading project still
> takes around 36 secs on a good day, while most take around
> twenty-something. The latest discussion on which was a bit back on
> zipping project files. But that might perhaps have less chance on huge
> leaps forward and easy succes, not to mention unrestrained and
> neverending gratitude, as might be the result of solving the image
> growth problem.
>
> In general what we would like to see is more animation possibilities,
> so anything that can make animation more efficient would be very
> welcome.
>
> Also anything that has got to do with more effective audio-handling
> would be desirable. Right now we're thinking of just referencing audio
> from external files, because a number of clips need to be shared, even
> compressed, they take up a lot of space in audio-intensive activities
> (not to be found in the released bundle, because of said restraints),
> and also because everything that needs to be loaded at project loading
> time prolongues the project loading.
>
> The same could be said for images, so to rattle on, it would be nice
> to pluck these kind of files from some kind of shared resource. That
> would definately be an optimization in our situation, but would
> perhaps be to specific of a need. I feel that the stuff we do with
> Etoys isn't really the stuff that Etoys was intended for which has in
> my mind more to do with explorating concepts in stead of delivering
> polished applications. But I might be wrong.
>
> Anyhow, any help on this front would of course be greatly welcomed,


As a start, please file tickets for each of the issues/ideas so they  
do not get lost.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Sound compression Re: [squeak-dev] Re: to be deployed Epaati version is out!

Karl-19
In reply to this post by Ties Stuij
Ties Stuij wrote:

> On Wed, Apr 23, 2008 at 4:46 PM, karl <[hidden email]> wrote:
>  
>> Hi
>>  I looked at the project and noticed you did not use sound compression.
>>  I think you could save a lot of space using Ogg Vorbis or Speex.
>>    
>
> Yes, definitely. And I have actually already fumbled around with
> attached changeset, but we had so much to fix and test and so little
> time, that we didn't have time to incorporate it. But thanks for the
> patch!
>  
I just tested on the biggest project in the activity folder (IVE5_1_
names of color.015.pr) and the size went from 9259 KB to 2298 KB when I
compressed the sounds with Speex. I did not test any load speeds but I
guess they improve because there is much less bytes to move around.

And you can just keep the halo menu up (toggle the stay up button) when
you compress the sounds.

Karl

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: to be deployed Epaati version is out!

Yoshiki Ohshima-2
In reply to this post by Ties Stuij
  Hello,

I think you used the display scaling a lot...  The biggest problem
with it is that it defaults to 32-bit depth Display and all artwork
loaded into or created became 32-bit depth.  You could look at the
SketchMorphs in it and convert them to 16-bit (or even 8-bit with some
loss of quality) to save the space at runtime and on disk.

  (It looks like halo is disabled in the projects.  How can I get it
back for debugging?)

> One of our most pressing problems has to do with continual image
> growth, when opening multiple projects. After opening and closing
> around 20 projects on an XO, the amount of memory the vm uses
> (according to the vm stats), has climbed from 60 to 95 mb, and soon
> afterwards we get an out of memory error.
>
> First I thought that old projects were lingering around, but they do
> seem to be garbage-collected eventually. There is no reference or
> pointer to them to be found in any case. I haven't had the time to do
> any space profiling to see who or what could then be the cause of the
> trouble.

  I'm playing with Epaati-10 a bit.  Entering
Grade2/Math/Unit4/IIM4_2_money identification.011.pr and coming back
(the instance of Project did get collected, but the accompanying
PasteUpMorph serving as its world along with all objects and players
are lingering.  Now, I'm (again) looking at the issue so hopefully I
get to something...

-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: to be deployed Epaati version is out!

Yoshiki Ohshima-2
>   I'm playing with Epaati-10 a bit.  Entering
> Grade2/Math/Unit4/IIM4_2_money identification.011.pr and coming back
> (the instance of Project did get collected, but the accompanying
> PasteUpMorph serving as its world along with all objects and players
> are lingering.  Now, I'm (again) looking at the issue so hopefully I
> get to something...

  Just a progress report, but the issue is basically around
#rootsIncludingPlayers not finding all classes, and the problem is
caused by a project that has scripts that reference to an object that
was trashed.  Namely,

  - You created object A and object B.
  - You wrote a script C at object B that refers to object A
    (This creates the uniclass for B).
  - You wrote a script D at object A that refers to object B.
    (This creates the uniclass for A).
  - You dismissed/trashed object B.
  - The project was saved.

What happens is that to keep the script D running and project working,
the system exports the object B into the saved project as well.  But
because it is trashed, it is not "in the world", but referenced from
the scripts.

  Epaati loads such a project, and upon exiting the project, it tries
to remove the project.  From #okToChangeSilently,
#rootsIncludingPlayers is called to find the uniclasses used in the
project.  But the logic only looks at the objects in the world, and
overlook the object B and the B's uniclass.

  Because B has a script that refers to A, pretty much everything in
the project is kept because the world is reachable through A's owner
chain.

  I still think Etoys/Smalltalk is almost suitable for what you are
doing, but loading and unloading a lot of project in a session wasn't
a typical use case.  In a sense Epaati is stretching it.  But it is
fixable fortunately.

  One thing we definitely should do is to make #rootsIncludingPlayers
better.  I can think of a few different ways.  One thing you should do
is revisit your projects and make sure that every object refered to
from the project to "live" in the project.
IIM4_2_money identification.011.pr, for example, has quite a few of such objects.

  To check these guys, open a workspace in a fresh epaati.image, and
evaluate:

    old := PasteUpMorph allInstances.

Then load IIM4_2_money identification.011.pr and come back.  In the
same workspace evaluate:

    new := PasteUpMorph allInstances.
    new := (new copyFrom: old size + 1 to: new size).
    new := new select: [:e | e knownName = 'page'].

and look at the submorphs of these pages bound to new.

-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: to be deployed Epaati version is out!

Ties Stuij
In reply to this post by Yoshiki Ohshima-2
On Thu, Apr 24, 2008 at 2:38 PM, Yoshiki Ohshima <[hidden email]> wrote:
>   Hello,
>
>  I think you used the display scaling a lot...  The biggest problem
>  with it is that it defaults to 32-bit depth Display and all artwork
>  loaded into or created became 32-bit depth.  You could look at the
>  SketchMorphs in it and convert them to 16-bit (or even 8-bit with some
>  loss of quality) to save the space at runtime and on disk.

Good tip! Thanks.

>   (It looks like halo is disabled in the projects.  How can I get it
>  back for debugging?)

Press alt+shift+w, select 'OLE' at the top of the menu, and select author mode.

>  > One of our most pressing problems has to do with continual image
>  > growth, when opening multiple projects. After opening and closing
>  > around 20 projects on an XO, the amount of memory the vm uses
>  > (according to the vm stats), has climbed from 60 to 95 mb, and soon
>  > afterwards we get an out of memory error.
>  >
>  > First I thought that old projects were lingering around, but they do
>  > seem to be garbage-collected eventually. There is no reference or
>  > pointer to them to be found in any case. I haven't had the time to do
>  > any space profiling to see who or what could then be the cause of the
>  > trouble.
>
>   I'm playing with Epaati-10 a bit.  Entering
>  Grade2/Math/Unit4/IIM4_2_money identification.011.pr and coming back
>  (the instance of Project did get collected, but the accompanying
>  PasteUpMorph serving as its world along with all objects and players
>  are lingering.  Now, I'm (again) looking at the issue so hopefully I
>  get to something...

Thanks

/Ties

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: to be deployed Epaati version is out!

Yoshiki Ohshima-2
In reply to this post by Yoshiki Ohshima-2
  And, compiling textual code, including class definition, etc. in the
file out part of the project is quite slow.  I noticed that some
projects have seemingly unnecessary class definitions of Players (I
don't know why these are there), and if you can eliminate them in one
way or another (you can see it in the that would help.  The Football
game project has fairly large class.  I would suggest to have the
class be part of the image so that the project doesn't have to compile
the code upon loading.

-- Yoshiki

12