Hi Bert,
During last month, I spent quite a bit of time getting FreeCell interact via DBus with Sugar Datastore. I tried to create a FreeCellLauncher which would register with AutoStart, so that nothing relies on special names such as FREECELL_ACTIVITY_ID, and could be used as a framework to develop and deploy other Etoys-based Sugar activities. Many of the directions I took were dead ends, mostly because CodeLauncher which Launches the code such as FreeCell.st cannot at the point of it's execution add FreeCellLauncher to AutoStart, at least to the best what I tried. I eventually accepted that used FREECELL_ACTIVITY_ID etc.
So now, FreeCell does persist it's Statistics on Journal, and can be restarted with persisted Statistics from Journal.
Everything is ugly at this point - but I want to make it nicer and generalize things so that they could hopefully serve as a cookbook to deploy Etoys objects as Sugar activities using the same mechanism.
I also plan to write one or two blogs on this topic in http://etoys-and- olpc.blogspot.com/ (started already but only as drafts).
The FreeCell activity is attached, hope this list allows small attachments.
Hope you guys enjoyed Squeakfest Brazil!
Later, Milan
On 27.07.2009, at 02:24, Milan Zimmermann wrote:
Hi Bert,
During last month, I spent quite a bit of time getting FreeCell interact via DBus with Sugar Datastore. I tried to create a FreeCellLauncher which would register with AutoStart, so that nothing relies on special names such as FREECELL_ACTIVITY_ID, and could be used as a framework to develop and deploy other Etoys-based Sugar activities. Many of the directions I took were dead ends, mostly because CodeLauncher which Launches the code such as FreeCell.st cannot at the point of it's execution add FreeCellLauncher to AutoStart, at least to the best what I tried. I eventually accepted that used FREECELL_ACTIVITY_ID etc.
Yes, we do not need launcher classes at all, because we are actually executing a script on startup. That is, yes we need a class that's launching the app, but it would not be triggered by the usual launcher mechanism on image startup but directly from our script document.
So now, FreeCell does persist it's Statistics on Journal, and can be restarted with persisted Statistics from Journal.
Great! I tried it in jhbuild and it indeed created a journal entry :)
There are some meta data properties missing. E.g, the color for the icon should be set to the XO owner's color, which you need to retrieve from the PresenceService:
SugarPresence new getOwner getProperties at: 'color'
And a question I found in your code: "why do we need to check whether the stored values are Strings? We stored them that way..."
Well, the answer is that since Sugar 0.83 the strings we store are converted to byte arrays so when we load them, they are ByteArrays. But some other code assumes that e.g. the title is actually a String so we need to convert there. Also, this does the conversion between utf-8 and WideString, as well as composing accents (Sugar often stores accented characters decomposed into multiple chars). In addition, we are not the only ones modifying these strings, but e.g. the user can modify the description in the Journal.
Everything is ugly at this point - but I want to make it nicer and generalize things so that they could hopefully serve as a cookbook to deploy Etoys objects as Sugar activities using the same mechanism.
Yes, that will be very useful to others.
I also plan to write one or two blogs on this topic in http://etoys- and- olpc.blogspot.com/ (started already but only as drafts).
Yay :)
Here's a couple of notes:
* there is no need for FreeCell.sh because you can put arguments on the exec line in activity.info
* in activity.info, increment activity_version for each new version. Version numbers must be integers. The version number in activity.info should match the xo bundle filename. Version comments go into NEWS (see etoys NEWS)
* we do not really need to customize the OBJECT_ID param name because SugarLauncher>>startUp only looks for ACTIVITY_ID. In fact, the param name does not even need to be customized per activity but it just needs to be something different than "ACTIVITY_ID". Say, "MY_ACTIVITY_ID".
* there is some strange formatting in your code. Some temps lost there names, other methods were saved with style info embedded. How are you developing this?
* Do you have an account here? http://activities.sugarlabs.org/en-US/sugar/addon/4054 I can add you as an author so you can upload releases yourself once they are ready for users
* I did set up a git repository for FreeCell a while ago: http://git.sugarlabs.org/projects/freecell/ If you are familiar with git you might want to contribute right there.
Hope you guys enjoyed Squeakfest Brazil!
Later, Milan
We did, it was a great event. Hopefully someone will write an extended report ...
- Bert -
Hi Bert,
Thanks for detail comments - and more notes inline:
On July 27, 2009, Bert Freudenberg wrote:
On 27.07.2009, at 02:24, Milan Zimmermann wrote:
Hi Bert,
During last month, I spent quite a bit of time getting FreeCell interact via DBus with Sugar Datastore. I tried to create a FreeCellLauncher which would register with AutoStart, so that nothing relies on special names such as FREECELL_ACTIVITY_ID, and could be used as a framework to develop and deploy other Etoys-based Sugar activities. Many of the directions I took were dead ends, mostly because CodeLauncher which Launches the code such as FreeCell.st cannot at the point of it's execution add FreeCellLauncher to AutoStart, at least to the best what I tried. I eventually accepted that used FREECELL_ACTIVITY_ID etc.
Yes, we do not need launcher classes at all, because we are actually executing a script on startup. That is, yes we need a class that's launching the app, but it would not be triggered by the usual launcher mechanism on image startup but directly from our script document.
Yeah, although it seemed sort of nice the FreeCellLauncher would register with Autostart and be launched via startUp but because of the order of code loading and startup it did not work. But playing with it made me understand AutoStart and CodeLoader much better :)
So now, FreeCell does persist it's Statistics on Journal, and can be restarted with persisted Statistics from Journal.
Great! I tried it in jhbuild and it indeed created a journal entry :)
There are some meta data properties missing. E.g, the color for the icon should be set to the XO owner's color, which you need to retrieve from the PresenceService:
Yes, I wonder what the list of "required" meta data is. I will add what I find in the Sugar document.
SugarPresence new getOwner getProperties at: 'color'
And a question I found in your code: "why do we need to check whether the stored values are Strings? We stored them that way..."
Well, the answer is that since Sugar 0.83 the strings we store are converted to byte arrays so when we load them, they are ByteArrays. But some other code assumes that e.g. the title is actually a String so we need to convert there. Also, this does the conversion between utf-8 and WideString, as well as composing accents (Sugar often stores accented characters decomposed into multiple chars). In addition, we are not the only ones modifying these strings, but e.g. the user can modify the description in the Journal.
There are many silly questions and notes in my code, I will clean it up and refactor - but you did pick a question that matters and I did not really understand - so thanks for explaining it. Also the serialization of Statistics is obvious hack but I will probably not change that, I consider this more of an example of how to do an Activity in Etoys, so cleaning up the other stuff and making it somewhat reusable is more important.
Everything is ugly at this point - but I want to make it nicer and generalize things so that they could hopefully serve as a cookbook to deploy Etoys objects as Sugar activities using the same mechanism.
Yes, that will be very useful to others.
I also plan to write one or two blogs on this topic in http://etoys- and- olpc.blogspot.com/ (started already but only as drafts).
Yay :)
Here's a couple of notes:
- there is no need for FreeCell.sh because you can put arguments on
the exec line in activity.info
true! Also based on your comment below, that we do not need activity-specific FREECELL_ACTIVITY_ID just MY_ACTIVITY_ID, for all activities, I can remove much of the stuff I added to the "generic" startup script.
- in activity.info, increment activity_version for each new version.
Version numbers must be integers. The version number in activity.info should match the xo bundle filename.
ah, yes I did not think of it.
Version comments go into NEWS (see etoys NEWS)
- we do not really need to customize the OBJECT_ID param name because
SugarLauncher>>startUp only looks for ACTIVITY_ID. In fact, the param name does not even need to be customized per activity but it just needs to be something different than "ACTIVITY_ID". Say, "MY_ACTIVITY_ID".
yes, I "knew" it but later forgot. Will change.. I am trying to think of a better name, PERSISTABLE_ACTIVITY_ID?
- there is some strange formatting in your code. Some temps lost there
names, other methods were saved with style info embedded. How are you developing this?
Goo question. I first developed it in an image where all changes went to a changeset named mz-free-cell or similar. I just kept saving the image. At some point I file-out the changeset as FreeCell.st, and started loading it using the --document mechanism. At that point, I started just editing FreeCell.st in vi. I also globally added some CTRL-J endlines because when exported, the changeset was missing end of lines.
But anyway, "How to start developing an Etoys-based Sugar Activity" is one of the important things I want to figure out how to describe in the blog: If someone wants to develop a activity similar to FreeCell, how to start? Open Etoys, make changes go to changset, make some changes, file-out, quit, move the file-out to appropriate directory, start FreeCell.sh using the file-out as --document, make some changes etc etc. It IS lots of work just to move the changes around, and difficult to explain, probably a deterrent. Or just keep things in one image and export at the end - but that is hard to test. Or edit the FreeCell.st as a file ... If I am being somewhat understandable here, what is your opinion?
- Do you have an account here? http://activities.sugarlabs.org/en-US/sugar/addon/4054 I can add you as an author so you can upload releases yourself once
they are ready for users
yes - milan.zimmermann@gmail.com
(but, not yet ready)
- I did set up a git repository for FreeCell a while ago: http://git.sugarlabs.org/projects/freecell/ If you are familiar with git you might want to contribute right
there.
Yeah I have a git client :) I will check with you before I put it in, maybe at the end of next weekend - large scale cleanup is needed first :)
Hope you guys enjoyed Squeakfest Brazil!
Later, Milan
We did, it was a great event. Hopefully someone will write an extended report ...
Great to hear! Next few days I plan to check tickets and accomodations in LA for 10,11,12 .
Milan
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 28.07.2009, at 01:00, Milan Zimmermann wrote:
Yes, I wonder what the list of "required" meta data is. I will add what I find in the Sugar document.
Well, pretty much everything Etoys is storing, see SugarLauncher>>propertiesFrom: aProject
The documentation is here:
http://wiki.laptop.org/go/Low-level_Activity_API#Meta_Data
- we do not really need to customize the OBJECT_ID param name because
SugarLauncher>>startUp only looks for ACTIVITY_ID. In fact, the param name does not even need to be customized per activity but it just needs to be something different than "ACTIVITY_ID". Say, "MY_ACTIVITY_ID".
yes, I "knew" it but later forgot. Will change.. I am trying to think of a better name, PERSISTABLE_ACTIVITY_ID?
CUSTOM_ACTIVITY_ID SQUEAK_ACTIVITY_ID SUGAR_ACTIVITY_ID
or in Python spirit _ACTIVITY_ID ;)
- there is some strange formatting in your code. Some temps lost
there names, other methods were saved with style info embedded. How are you developing this?
Goo question. I first developed it in an image where all changes went to a changeset named mz-free-cell or similar. I just kept saving the image. At some point I file-out the changeset as FreeCell.st, and started loading it using the --document mechanism. At that point, I started just editing FreeCell.st in vi. I also globally added some CTRL-J endlines because when exported, the changeset was missing end of lines.
But anyway, "How to start developing an Etoys-based Sugar Activity" is one of the important things I want to figure out how to describe in the blog: If someone wants to develop a activity similar to FreeCell, how to start? Open Etoys, make changes go to changset, make some changes, file-out, quit, move the file-out to appropriate directory, start FreeCell.sh using the file-out as --document, make some changes etc etc. It IS lots of work just to move the changes around, and difficult to explain, probably a deterrent. Or just keep things in one image and export at the end - but that is hard to test. Or edit the FreeCell.st as a file ... If I am being somewhat understandable here, what is your opinion?
I know quite well what you are talking about, and I do not have a good answer yet.
Basically we want to deploy a Squeak application, without shipping a custom image. I think that's a new problem, typically Smalltalk apps ship as customized images.
For developing these apps we want to use all the tools we regularly use. That is, browsers instead of text editors. ChangeSorters or Monticello instead of git. Resuming images instead of loading dead code.
So I think while developing this you might want to run under Sugar in an image set up for development, and for deployment store the "difference" between the original image and your app image in a .xo bundle. Possibly we would have a simple script in the .xo bundle that just runs the start method of your main class while developing (when the class is already in the image). After deploying, it would first load the app, and then invoke the start method.
- Do you have an account here? http://activities.sugarlabs.org/en-US/sugar/addon/4054 I can add you as an author so you can upload releases yourself once
they are ready for users
yes - milan.zimmermann@gmail.com
(but, not yet ready)
I added you.
- I did set up a git repository for FreeCell a while ago: http://git.sugarlabs.org/projects/freecell/ If you are familiar with git you might want to contribute right
there.
Yeah I have a git client :) I will check with you before I put it in, maybe at the end of next weekend - large scale cleanup is needed first :)
You could fork the repository so you do not commit to the mainline immediately. See http://wiki.sugarlabs.org/go/Activity_Team/Git_FAQ
Hope you guys enjoyed Squeakfest Brazil!
Later, Milan
We did, it was a great event. Hopefully someone will write an extended report ...
Great to hear! Next few days I plan to check tickets and accomodations in LA for 10,11,12 .
Milan
Oh great! Wish I could go too, but someone needs to take care of the kids ... and this time it's me.
- Bert -
Bert Freudenberg wrote:
Basically we want to deploy a Squeak application, without shipping a custom image. I think that's a new problem, typically Smalltalk apps ship as customized images.
Funny you should mention that. This is something I am actually working on in my spare time. I do have the outline for a Squeak application bundle that stores binary representations of code (so that the image does not require a Compiler; in fact I want to be able to use that to load one ;-) and optionally, source code. It's nicely small and fast so far (the entirety of Morphic goes into 700k and takes less than a second to load) but the work's only just started so there is a long ways to go here. If someone is seriously interesting in this direction, drop me a note.
Cheers, - Andreas
Andreas Raab wrote:
Bert Freudenberg wrote:
Basically we want to deploy a Squeak application, without shipping a custom image. I think that's a new problem, typically Smalltalk apps ship as customized images.
Funny you should mention that. This is something I am actually working on in my spare time. I do have the outline for a Squeak application bundle that stores binary representations of code (so that the image does not require a Compiler; in fact I want to be able to use that to load one ;-) and optionally, source code. It's nicely small and fast so far (the entirety of Morphic goes into 700k and takes less than a second to load) but the work's only just started so there is a long ways to go here. If someone is seriously interesting in this direction, drop me a note.
This is my number one priority for the second half of 2009. I won't be able to start working on it until late August or September, but have a very brief explanation at http://wiki.squeak.org/squeak/5637
Earlier this year I had proposed a much simpler version of this (http://wiki.squeak.org/squeak/584) which wouldn't have the complicated "swizzling" on load and save nor the multiple viewpoints and new concurrency model. The focus was exactly on fast binary loading and what I thought I could get the Squeak community to agree with as a next step.
Since I was unable to get any interest in the "Squeak friendly" proposal, I decided I might as well go with the more radical design instead. This will involve a significant rewrite of ObjectMemory with an organization using segments (like Self) and fragmented object tables (like "handles" in early Mac software) which I hope will be equally useful for small and large (64 bit) memories.
-- Jecel
etoys-dev@lists.squeakfoundation.org