Hi,
How does one apply a changeset to only a few installations of Etoys in use in the field on machines with diverse OS (Linux/Mac/Win)?
Suzanne Guyader uses Etoys to teach art to children and teachers not all of whom use XO. The brush sizes in Paint tool needs to be reverted to 1/3/7/13/26/50 for non-XO images only. I have attached a changeset that I created for this purpose but I don't know how to roll it out on diverse machines.
I suppose I could create a command line script that applies this changeset and updates the image/changeset files but the steps involved are too complex for children. Is there any easy way?
TIA .. Subbu
You can make a project, make this change set default change set for that project and publish the project. Answer yes to include change set in published project.
It's a little more difficult to save the image with the change set included.
Maybe make a button in the project that saves the image with the change set and exits the project,
Karl
On Sun, Jun 23, 2013 at 7:48 AM, K. K. Subramaniam kksubbu.ml@gmail.comwrote:
Hi,
How does one apply a changeset to only a few installations of Etoys in use in the field on machines with diverse OS (Linux/Mac/Win)?
Suzanne Guyader uses Etoys to teach art to children and teachers not all of whom use XO. The brush sizes in Paint tool needs to be reverted to 1/3/7/13/26/50 for non-XO images only. I have attached a changeset that I created for this purpose but I don't know how to roll it out on diverse machines.
I suppose I could create a command line script that applies this changeset and updates the image/changeset files but the steps involved are too complex for children. Is there any easy way?
TIA .. Subbu
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Sunday 23 June 2013 07:54 PM, karl ramberg wrote:
You can make a project, make this change set default change set for that project and publish the project. Answer yes to include change set in published project.
It's a little more difficult to save the image with the change set included.
The difficulty that I have is actually in saving a patched image. Applying a patch is the easier part. I tried a deferred save and quit in the postscript of the changeset but there is still an annoying flash on every start for the postscript residual.
The usual way of using a *.st file to apply the changeset and quit depends on the host OS. If only the image could autoexec a autorun.st file from the default directory on startup then cross-platform field patches would be simpler.
Regards .. Subbu
Hi,
I've done something similar for Physical Etoys that lets us add new source code and/or new files to a published release. This has been very useful for us and the implementation is very simple, so maybe if there is enough interest we could adapt it and include it in Etoys. I'm attaching an *.st file if you want to check it out. It consists on just two classes: PEInstaller and PEModule. PEInstaller takes care of the startup behavior and registering which PEModules have been installed already (so that we don't install something twice). PEModule includes the logic to install (and rollback if something fails) a given module. On each startup the behavior is the following:
1. PEInstaller looks on the default directory for *.pem files that hasn't been installed before. These *.pem files are just renamed zip files. 2. For each *.pem file found, PEInstaller creates a PEModule and installs it, which involves the following steps: 1. Since the *.pem file is just a zip, the PEModule first extracts all its files on the default directory. This allows us to add arbitrary files, not just source code. 2. Then it looks for source code files (*.st, *.cs, or *.mcz) on the extracted files, and it loads them in the image. 3. After installing all modules found, PEInstaller registers them on the "installedModules" class inst var, and saves the image. If an error occured while installing a module, it will rollback all modules installed on this startup (so that we don't leave any file hanging there) and it quits the image.
Cheers, Richo
On Sun, Jun 23, 2013 at 12:09 PM, K. K. Subramaniam kksubbu.ml@gmail.comwrote:
On Sunday 23 June 2013 07:54 PM, karl ramberg wrote:
You can make a project, make this change set default change set for that project and publish the project. Answer yes to include change set in published project.
It's a little more difficult to save the image with the change set included.
The difficulty that I have is actually in saving a patched image. Applying a patch is the easier part. I tried a deferred save and quit in the postscript of the changeset but there is still an annoying flash on every start for the postscript residual.
The usual way of using a *.st file to apply the changeset and quit depends on the host OS. If only the image could autoexec a autorun.st file from the default directory on startup then cross-platform field patches would be simpler.
Regards .. Subbu
______________________________**_________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/**mailman/listinfo/etoys-devhttp://lists.squeakland.org/mailman/listinfo/etoys-dev
Thanks Ricardo,
This looks like a handy feature to be included in Squeak/Etoys. It does a lot more than what I expect but we could explore its implications in this thread.
Merging arbitrary code from defaultDirectory into the stable image looks a bit adventurous to me. The stable image could suffer permanent damage. Extensions in Resources directory should be treated differently from those in defaultDirectory. The former could be merged into the stable image while latter should be loaded on the fly on startup.
Regards .. Subbu
On Tuesday 25 June 2013 01:28 AM, Ricardo Moran wrote:
Hi,
I've done something similar for Physical Etoys that lets us add new source code and/or new files to a published release. This has been very useful for us and the implementation is very simple, so maybe if there is enough interest we could adapt it and include it in Etoys. I'm attaching an *.st file if you want to check it out. It consists on just two classes: PEInstaller and PEModule. PEInstaller takes care of the startup behavior and registering which PEModules have been installed already (so that we don't install something twice). PEModule includes the logic to install (and rollback if something fails) a given module. On each startup the behavior is the following:
- PEInstaller looks on the default directory for *.pem files that hasn't been installed before. These *.pem files are just renamed zip files.
- For each *.pem file found, PEInstaller creates a PEModule and installs it, which involves the following steps:
- Since the *.pem file is just a zip, the PEModule first extracts all its files on the default directory. This allows us to add arbitrary files, not just source code.
- Then it looks for source code files (*.st, *.cs, or *.mcz) on the extracted files, and it loads them in the image.
- After installing all modules found, PEInstaller registers them on the "installedModules" class inst var, and saves the image. If an error occured while installing a module, it will rollback all modules installed on this startup (so that we don't leave any file hanging there) and it quits the image.
Cheers, Richo
On Sun, Jun 23, 2013 at 12:09 PM, K. K. Subramaniam <kksubbu.ml@gmail.com mailto:kksubbu.ml@gmail.com> wrote:
On Sunday 23 June 2013 07:54 PM, karl ramberg wrote: You can make a project, make this change set default change set for that project and publish the project. Answer yes to include change set in published project. It's a little more difficult to save the image with the change set included. The difficulty that I have is actually in saving a patched image. Applying a patch is the easier part. I tried a deferred save and quit in the postscript of the changeset but there is still an annoying flash on every start for the postscript residual. The usual way of using a *.st file to apply the changeset and quit depends on the host OS. If only the image could autoexec a autorun.st <http://autorun.st> file from the default directory on startup then cross-platform field patches would be simpler. Regards .. Subbu _________________________________________________ etoys-dev mailing list etoys-dev@squeakland.org <mailto:etoys-dev@squeakland.org> http://lists.squeakland.org/__mailman/listinfo/etoys-dev <http://lists.squeakland.org/mailman/listinfo/etoys-dev>
etoys-dev@lists.squeakfoundation.org
-
K. K. Subramaniam -
karl ramberg -
Ricardo Moran