Howdy!
I've hit a snag while bundling up a proper EPaati.xo activity bundle. The issue is that when I try to load a project from a file Squeak is trying to cache the project file in (imagedir)/Squeaklets/ and it's failing due to a permissions problem. The directories all have permissions rwxrwxr-x and Sugar seems to run the epaati activity as some "other" user who lacks write permissions.
So I'm looking for a way to either prevent Squeak from caching the projects in Squeaklets/ (waste of time and space in this case -- they're already on disk) or to arrange for the permissions to work out so that Squeak can create Squeaklets/ or will already have it correctly setup.
Any tips?
I'd post the buggy .xo bundle but bandwidth doesn't allow.
Cheers! -Luke
On Jan 31, 2008, at 13:38 , Luke Gorrie wrote:
Howdy!
I've hit a snag while bundling up a proper EPaati.xo activity bundle. The issue is that when I try to load a project from a file Squeak is trying to cache the project file in (imagedir)/Squeaklets/ and it's failing due to a permissions problem. The directories all have permissions rwxrwxr-x and Sugar seems to run the epaati activity as some "other" user who lacks write permissions.
So I'm looking for a way to either prevent Squeak from caching the projects in Squeaklets/ (waste of time and space in this case -- they're already on disk) or to arrange for the permissions to work out so that Squeak can create Squeaklets/ or will already have it correctly setup.
Any tips?
This works fine in the etoys bundle. You must have the startupInUntrustedDirectory preference enabled, in which case not the image directory becomes the default directory, but rather what was passed as SQUEAK_USERDIR environment variable in the etoys-activity script. That script takes care to set it to the activity-writable location ($SUGAR_ACTIVITY_ROOT/data), see
http://wiki.laptop.org/go/Low-level_Activity_API#Writable_Directories
- Bert -
On 31/01/2008, Bert Freudenberg bert@freudenbergs.de wrote:
This works fine in the etoys bundle.
So it's a bit naive of us to derive our image from the Etoys development image without using the ReleaseBuilderSqueakland stuff for "deploymentizing". Changing the startupInUntrustedDirectory preference does fix this, but then I hit more trouble when I tried to load a project with a changeset -- I'm guessing because the .changes file isn't writable.
For now I'll try to steal enough fragments from ReleaseBuilderSqueakland to make everything work.
Going forwards we should probably look closely at what Hilaire has with DrGeoII. For example it might be nice if our "main menu project" included a full changeset of all of our Smalltalk code and also included all the sound clips / fonts / etc that we feel the need for (using installation tricks in the changeset postscript as needed). Then we could use the base etoys.image and once the main menu was loaded we'd know that all the code and other resources that the other projects need is pre-available.
What do you think?
-Luke going into hack and slash mode to just get something published as a reference point :-)
On Feb 1, 2008, at 9:39 , Luke Gorrie wrote:
On 31/01/2008, Bert Freudenberg bert@freudenbergs.de wrote:
This works fine in the etoys bundle.
So it's a bit naive of us to derive our image from the Etoys development image without using the ReleaseBuilderSqueakland stuff for "deploymentizing". Changing the startupInUntrustedDirectory preference does fix this, but then I hit more trouble when I tried to load a project with a changeset -- I'm guessing because the .changes file isn't writable.
For now I'll try to steal enough fragments from ReleaseBuilderSqueakland to make everything work.
Going forwards we should probably look closely at what Hilaire has with DrGeoII. For example it might be nice if our "main menu project" included a full changeset of all of our Smalltalk code and also included all the sound clips / fonts / etc that we feel the need for (using installation tricks in the changeset postscript as needed). Then we could use the base etoys.image and once the main menu was loaded we'd know that all the code and other resources that the other projects need is pre-available.
What do you think?
-Luke going into hack and slash mode to just get something published as a reference point :-)
Sounds like a plan :)
We then just need to work on project loading speed to make that work really nicely.
- Bert -
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Luke Gorrie