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

> 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

> 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.

> 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
>
>
>  

> 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.
>  

> 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
>
>
>  

> 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.

>  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! !

> 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,

> 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!
>  

> 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.

>  > 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...