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
Hi,
On Mon, Apr 21, 2008 at 10:38 AM, Ties Stuij cjstuij@gmail.com 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
On Mon, Apr 21, 2008 at 3:06 PM, Tomeu Vizoso tomeu@tomeuvizoso.net 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
Ties Stuij wrote:
On Mon, Apr 21, 2008 at 3:06 PM, Tomeu Vizoso tomeu@tomeuvizoso.net 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
On Wed, Apr 23, 2008 at 3:55 PM, karl karl.ramberg@comhem.se wrote:
Ties Stuij wrote:
On Mon, Apr 21, 2008 at 3:06 PM, Tomeu Vizoso tomeu@tomeuvizoso.net
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
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! !
On Wed, Apr 23, 2008 at 4:46 PM, karl karl.ramberg@comhem.se 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 theselected 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! !
Ties Stuij wrote:
On Wed, Apr 23, 2008 at 4:46 PM, karl karl.ramberg@comhem.se 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
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
On Wed, Apr 23, 2008 at 4:47 PM, karl karl.ramberg@comhem.se 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
On 23.04.2008, at 11:01, Ties Stuij wrote:
On Mon, Apr 21, 2008 at 3:06 PM, Tomeu Vizoso tomeu@tomeuvizoso.net 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 -
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
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
Yoshiki Ohshima wrote:
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.
Yes, there should be a similar mechanism as when you delete referenced method in the Browser, that open or list the scripts that references the deleted script or player.
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
We get the environment tested thoroughly here and that is really good.
Karl
Ties,
Please try attached change set. In Epaati-10, it seems to remove almost all objects. (There are uninstanciated uniclasses left; that may have to be removed by calling some methods like:
Player abandonUnnecessaryUniclasses and Player removeUninstantiatedSubclassesSilently
-- Yoshiki
On Thu, Apr 24, 2008 at 2:38 PM, Yoshiki Ohshima yoshiki@vpri.org 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
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
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 -
On Mon, Apr 21, 2008 at 10:28 PM, Bert Freudenberg bert@freudenbergs.de 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
On 22.04.2008, at 05:38, Ties Stuij wrote:
On Mon, Apr 21, 2008 at 10:28 PM, Bert Freudenberg <bert@freudenbergs.de
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 -
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
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
karl -
Ties Stuij -
Tomeu Vizoso -
Yoshiki Ohshima