On 10.08.2009, at 03:41, K. K. Subramaniam wrote:
Hi,
I got a SVN error today while updating: "svn: Cannot replace a directory from within"
What happened to Etoys-To-Go.app SVN at svn.squeakland.org/ installers/? There is a Etoys-To-Go/ directory but it has only a few launcher files. Has it been merged into Etoys.app?
"svn log" is your friend:
------------------------------------------------------------------------ r230 | bf | 2009-08-07 12:13:32 +0200 (Fri, 07 Aug 2009) | 1 line
Rename Etoys-To-Go.app to Etoys-To-Go ------------------------------------------------------------------------ r224 | bf | 2009-08-06 23:28:32 +0200 (Thu, 06 Aug 2009) | 1 line
Etoys-To-Go: undelete etoys.sh ------------------------------------------------------------------------ r223 | bf | 2009-08-06 23:25:09 +0200 (Thu, 06 Aug 2009) | 1 line
Etoys-To-Go: remove files that are identical to Etoys ------------------------------------------------------------------------
Would be cool to post SVN commit messages to etoys-notify ... Tim?
So yes, I removed all files that are identical between Etoys.app and Etoys-To-Go.app. This only leaves one file for each platform (Mac, Windows, Unix [*]). Also, there is an "makeEtoysToGo" script that creates Etoys-To-Go.app and zips it for easy download. I even linked it from http://wiki.squeakland.org/display/sq/Etoys+To+Go ;)
- Bert -
[*] I put in a mechanism to support other Unices than i686-Linux, but no other Unix VMs have been bundled yet. Contributions welcome.
On Monday 10 Aug 2009 12:26:08 pm Bert Freudenberg wrote:
"svn log" is your friend:
Only if update works :-(. Anyway I could guess what happened from the server directory. This is a welcome move. I was confused about the future of Etoys2Go.
So yes, I removed all files that are identical between Etoys.app and Etoys-To-Go.app.
Fixes in 2-go launcher etoys.sh have not been merged into etoys.sh.
The changes required for 2Go version are simple enough to be added to README. Whomsoever is prepping a 2Go version can edit text files easily.
Subbu
On 10.08.2009, at 10:42, K. K. Subramaniam wrote:
On Monday 10 Aug 2009 12:26:08 pm Bert Freudenberg wrote:
"svn log" is your friend:
Only if update works :-(.
Actually you can do it without even downloading anything:
svn log -v http://svn.squeakland.org/installers
I guess you tried updating from within the Etoys-To-Go.app directory, which was removed, so that's why svn told you it could not update.
Anyway I could guess what happened from the server directory. This is a welcome move. I was confused about the future of Etoys2Go.
It's not even released, don't declare it dead already ;) I hope it will become the if-all-else-fails version of Etoys that Simply Works.
So yes, I removed all files that are identical between Etoys.app and Etoys-To-Go.app.
Fixes in 2-go launcher etoys.sh have not been merged into etoys.sh.
Yes, somehow I replaced it with an older version. But the one checked in now should be okay, yes?
The changes required for 2Go version are simple enough to be added to README. Whomsoever is prepping a 2Go version can edit text files easily.
Doing it manually is error-prone. The makeEtoysToGo script exports Etoys.app as Etoys-To-Go.app and then exports the Etoys-To-Go files on top of it. Very simple.
But it is unfortunate that we have three copies of the etoys script (the third is npetoysrun which is a bit special).
- Bert -
On Monday 10 Aug 2009 3:26:12 pm Bert Freudenberg wrote:
Actually you can do it without even downloading anything:
svn log -v http://svn.squeakland.org/installers
I guess you tried updating from within the Etoys-To-Go.app directory, which was removed, so that's why svn told you it could not update.
Yes. Thanks for the tip.
It's not even released, don't declare it dead already ;) I hope it will become the if-all-else-fails version of Etoys that Simply Works.
I am sure it will become the preferred way for children. I have been carrying Etoys on a chip for over two years and I can't imagine working any other way now :-).
Yes, somehow I replaced it with an older version. But the one checked in now should be okay, yes?
Looks good. The TMP copy trick can also be merged. It will be a null-op for traditional launch from /usr/share.
Doing it manually is error-prone. The makeEtoysToGo script exports Etoys.app as Etoys-To-Go.app and then exports the Etoys-To-Go files on top of it. Very simple.
etoys.sh is maturing well. We could retain Linux-i686/squeak as a binary and move etoys.sh as Linux-i686/etoys. A small desktop launcher at the top level can override the default settings in this launcher. This would be consistent across platforms. See http://lists.laptop.org/pipermail/etoys/2009-March/003053.html
I haven't figured out how to do such overrides on OSX yet. I am sure there is a way.
Subbu
On 11.08.2009, at 03:49, K. K. Subramaniam wrote:
On Monday 10 Aug 2009 3:26:12 pm Bert Freudenberg wrote:
It's not even released, don't declare it dead already ;) I hope it will become the if-all-else-fails version of Etoys that Simply Works.
I am sure it will become the preferred way for children. I have been carrying Etoys on a chip for over two years and I can't imagine working any other way now :-).
It is useful in certain circumstances. But the preferred way is to have Etoys pre-installed on each machine. Our largest user base is children using XOs, where that's the case. Getting it packaged into every Linux distribution is also almost like pre-installing, and in education-targeted distros like Edubuntu it might well get installed by default. Same for education-targeted laptops - would be great to have it pre-installed on all kids machines, don't you think?
Besides, for viewing projects in the web browser installation is necessary, and the web is the future, you know? ;)
Yes, somehow I replaced it with an older version. But the one checked in now should be okay, yes?
Looks good. The TMP copy trick can also be merged. It will be a null- op for traditional launch from /usr/share.
Having this in the script for fixed installation makes no sense to me at all. If an installation is broken there should not be scripting magic to fix it. Rather, the packaging should be fixed.
Doing it manually is error-prone. The makeEtoysToGo script exports Etoys.app as Etoys-To-Go.app and then exports the Etoys-To-Go files on top of it. Very simple.
etoys.sh is maturing well. We could retain Linux-i686/squeak as a binary and move etoys.sh as Linux-i686/etoys.
The main reason I renamed the squeak binary to "etoys" is so it shows up properly in a process list.
A small desktop launcher at the top level can override the default settings in this launcher. This would be consistent across platforms. See http://lists.laptop.org/pipermail/etoys/2009-March/003053.html
We are not using this batch file approach on Windows. You and I come from a Unix background so shell scripts feel natural to us, and we know they are much more powerful than what other platforms use. Nevertheless, they are alien to Windows or Mac. Launching Etoys should use the preferred method for the platform. No self-respecting app on Windows would have to be started by a batch file, or by a shell script on the Mac.
IMHO of course, I'm just one voice in the group :)
I haven't figured out how to do such overrides on OSX yet. I am sure there is a way.
Only if the Mac VM is changed to interpolate environment variables in its directory specs from Info.plist. I don't think it does this, yet. Besides, as I mentioned earlier, having to launch a Mac app with a script is decidedly user-unfriendly.
- Bert -
On Tuesday 11 Aug 2009 12:25:11 pm Bert Freudenberg wrote:
It is useful in certain circumstances. But the preferred way is to have Etoys pre-installed on each machine...
Nothing in my proposal harms pre-installations. So there is no question of exclusion.
Having this in the script for fixed installation makes no sense to me at all. If an installation is broken there should not be scripting magic to fix it. Rather, the packaging should be fixed.
Installers do not handle run-time issues. Auto-detecting display manager, framebuffer, desktop manager, sound subsystems, giving sensible dialogs on error conditions and so on are best handled in a script rather than a binary. These changes are expected when, say, Etoys is launched from a mounted volume/share by different clients.
We are not using this batch file approach on Windows....
Looks like you skipped the initial part: "Blaming the breakage on Vista is unfair..."
Batch files are not required for pre-installed code or for situations where runtime environment does not change post-install (e.g XO, personal notebooks). In my situation and in the topic quoted, the runtime env was different from what Installers assumed for fairly valid reasons. Editing paths in a small files was something that teachers could handle so I opted for a short batch file.
Subbu
On Monday 10 Aug 2009 3:26:12 pm Bert Freudenberg wrote:
So yes, I removed all files that are identical between Etoys.app and Etoys-To-Go.app.
Fixes in 2-go launcher etoys.sh have not been merged into etoys.sh.
Yes, somehow I replaced it with an older version. But the one checked in now should be okay, yes?
Two minor tweaks in attached patch. They should work on all Unix/Linux systems.
Subbu
On 11.08.2009, at 17:09, K. K. Subramaniam wrote:
On Monday 10 Aug 2009 3:26:12 pm Bert Freudenberg wrote:
Fixes in 2-go launcher etoys.sh have not been merged into etoys.sh.
Yes, somehow I replaced it with an older version. But the one checked in now should be okay, yes?
Two minor tweaks in attached patch. They should work on all Unix/Linux systems.
I committed your mkdir improvement, thanks.
But the var expansion magic is unnecessarily clever IMHO, less readable than being explicit. Besides, written like this, the variables would not be exported to the environment.
- Bert -
On Tuesday 11 Aug 2009 9:06:44 pm Bert Freudenberg wrote:
But the var expansion magic is unnecessarily clever IMHO, less readable than being explicit.
I didn't mean to use any special magic. The idiom : ${SQUEAK_USERDIR:=$HOME/.etoys} dates back to original Bourne shell and is portable across all shells. See sh man page for "assign default values". Anyway, I will leave it to you.
Besides, written like this, the variables would not be exported to the environment.
Nice catch! $ export SQUEAK_USERDIR SQUEAK_SECUREDIR
Subbu
On 12.08.2009, at 03:02, K. K. Subramaniam wrote:
On Tuesday 11 Aug 2009 9:06:44 pm Bert Freudenberg wrote:
But the var expansion magic is unnecessarily clever IMHO, less readable than being explicit.
I didn't mean to use any special magic. The idiom : ${SQUEAK_USERDIR:=$HOME/.etoys} dates back to original Bourne shell and is portable across all shells.
Maybe. I call executing an anonymous command with an argument that as a side-effect creates and assigns a variable, but only if the variable did not exist before, "magic".
See sh man page for "assign default values". Anyway, I will leave it to you.
Besides, written like this, the variables would not be exported to the environment.
Nice catch! $ export SQUEAK_USERDIR SQUEAK_SECUREDIR
Subbu
I'm for leaving it like it is. It's even a line less ;)
- Bert -
On Aug 10, 2009, at 2:56 AM, Bert Freudenberg wrote:
Would be cool to post SVN commit messages to etoys-notify ... Tim?
SVN is currently on tinlizzie ... remind me when we move it to the squeakland server.
Either way, SVN can email the changes to the list, just add the "from" address to the list.
Tim
On 31.08.2009, at 16:19, Timothy Falconer wrote:
On Aug 10, 2009, at 2:56 AM, Bert Freudenberg wrote:
Would be cool to post SVN commit messages to etoys-notify ... Tim?
SVN is currently on tinlizzie ...
I don't think so:
Faust:~ bert$ host tinlizzie.org tinlizzie.org has address 208.82.117.98
Faust:~ bert$ host svn.squeakland.org svn.squeakland.org has address 208.49.99.252
Faust:~ bert$ host 208.49.99.252 252.99.49.208.in-addr.arpa domain name pointer mail.vpri.org.
But it's a VPRI server nontheless.
remind me when we move it to the squeakland server.
Okay.
Either way, SVN can email the changes to the list, just add the "from" address to the list.
Okay. Can someone with access to that machine add the commit hook?
- Bert -
etoys-dev@lists.squeakfoundation.org