I've just imported the platforms tree as suited to VMMaker (see http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas and look for the latest VMMaker* file(s) ) to SourceForge (see http://sourceforge.net/projects/squeak) in the hope it might actually work as a way to let people try it out.
Ghu only knows if I managed to do it right; I'm sure a gazillion people will tell me all about it if not. Amongst other things, I have no idea how binary files will have been treated.
Another possible problem is that in the process of editing the CVSROOT/modules file to ad a 'platforms' module, SF appeared to lock up on me. Has this left it in a dead state? Am I about to be the first squeaker to be arrested by the FBI for terrorist hacking because of this? Can anybody else even see the files? (should be under 'squeak/platforms' at the moment)
tim
On Wed, 24 Oct 2001, Tim Rowledge wrote:
I've just imported the platforms tree as suited to VMMaker (see http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas and look for the latest VMMaker* file(s) ) to SourceForge (see http://sourceforge.net/projects/squeak) in the hope it might actually work as a way to let people try it out.
As instructed by the SourceForge page, I opened a terminal window and logged into the CVS server:
cvs -z3 -d:pserver:anonymous@cvs.squeak.sourceforge.net:/cvsroot/squeak co squeakcd squeak/
then checked out the "squeak" module
cvs -z3 -d:pserver:anonymous@cvs.squeak.sourceforge.net:/cvsroot/squeak co squeak
(MacCVS instructions are available upon request. :) )
This seems to have worked, although I don't know how I can test if things are the most recent version.
Ghu only knows if I managed to do it right; I'm sure a gazillion people will tell me all about it if not. Amongst other things, I have no idea how binary files will have been treated.
Well, one data point is that some make-specific files (with resource forks and all) was archived in the "resources.sit" file in the "squeak/platforms/Mac OS/vm" directory. I didn't have any problem extracting this file and using the contents.
Another possible problem is that in the process of editing the CVSROOT/modules file to ad a 'platforms' module, SF appeared to lock up on me. Has this left it in a dead state? Am I about to be the first squeaker to be arrested by the FBI for terrorist hacking because of this? Can anybody else even see the files? (should be under 'squeak/platforms' at the moment)
I don't think you needed to change the modules file. I did get a platforms directory.
-Eric
I've just imported the platforms tree as suited to VMMaker (see http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas and look for the latest VMMaker* file(s) ) to SourceForge (see http://sourceforge.net/projects/squeak)
I should point out the macintosh users can visit http://sourceforge.net/projects/maccvspro to get a cvs client for the macintosh. A wee bit of work, such as setting the Server hostname to cvs.squeak.sourceforge.net and the CVS root to /cvsroot/squeak and anonymous to the CVS user name means you can invoke check out module squeak to pull the source tree.
On Wed, 24 Oct 2001, John M McIntosh wrote:
I should point out the macintosh users can visit http://sourceforge.net/projects/maccvspro to get a cvs client for the macintosh. A wee bit of work, such as setting the Server hostname to cvs.squeak.sourceforge.net and the CVS root to /cvsroot/squeak and anonymous to the CVS user name means you can invoke check out module squeak to pull the source tree.
Indeed. MacCVS is a very nice tool. I created a little page on the Swiki for those people who want to try it out. Check out
http://minnow.cc.gatech.edu/squeak/2106
Please send me comments and/or enhance the page yourself!
-Eric
On Wednesday 24 October 2001 05:18 pm, Tim Rowledge wrote:
I've just imported the platforms tree as suited to VMMaker (see http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas and look for the latest VMMaker* file(s) ) to SourceForge (see http://sourceforge.net/projects/squeak) in the hope it might actually work as a way to let people try it out.
The execute permissions on the Unix configure program seem to have been lost. But the ltmain.sh seems to have retained its permissions.
On Wednesday 24 October 2001 05:18 pm, Tim Rowledge wrote:
I've just imported the platforms tree as suited to VMMaker (see http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas and look for the latest VMMaker* file(s) ) to SourceForge (see http://sourceforge.net/projects/squeak) in the hope it might actually work as a way to let people try it out.
Not just the configure, but the other executable programs in utils (in the unix directory) are not marked as executable.
On Wednesday 24 October 2001 05:18 pm, Tim Rowledge wrote:
I've just imported the platforms tree as suited to VMMaker (see http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas and look for the latest VMMaker* file(s) ) to SourceForge (see http://sourceforge.net/projects/squeak) in the hope it might actually work as a way to let people try it out.
Ghu only knows if I managed to do it right; I'm sure a gazillion people will tell me all about it if not. Amongst other things, I have no idea how binary files will have been treated.
Ok... I couldn't get it to work entirely correctly; here's my notes:
configuration: src directory under Squeak directory platforms directory somewhere else.
Remove the src directory. Start VMMaker. Tell it where the directories are. make a config with all internal. Tell it "generate all". src directory is populated. chmod +x configure util/* ./configure make
error:
gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -DHAVE_CONFIG_H -DUNIX -DSQ_LIBDIR="/usr/local/lib/squeak/3.1a-4164" -I. -I../src/vm -c -o Mpeg3Plugin.o ../src/vm/Mpeg3Plugin.c In file included from ../src/vm/Mpeg3Plugin.c:23: ../src/vm/Mpeg3Plugin.h:1:38: changesForSqueak.h: No such file or directory ../src/vm/Mpeg3Plugin.h:2:30: libmpeg3.h: No such file or directory make: *** [Mpeg3Plugin.o] Error 1
but those headers live in vm/libmpeg
Note that this is not what happened the first time I tried this.
Edited Makefile to add -I ../src/vm/libmpeg -I ../src/vm/libmpeg/audio -I ../src/vm/libmpeg/video to the Mpeg3Plugin make line
interestingly, there are two sets of Makefile lines for each file, so that I get a lot of messages like:
Makefile:554: warning: overriding commands for target `sqUnixExternalPrims.o' Makefile:413: warning: ignoring old commands for target `sqUnixExternalPrims.o'
gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -o squeak squeak.a -lXext -lX11 -lm -ldl -lnsl -L/usr/X11R6/lib -Wl,--export-dynamic -Wl,--rpath -Wl,/usr/local/lib/squeak/3.1a-4164 -Wl,--rpath -Wl,/usr/local/lib/squeak/3.1a-4164 /home/ned/Squeak/3.0/src/../src/vm/Mpeg3Plugin.c:179: undefined reference to `mpeg3_total_astreams' /home/ned/Squeak/3.0/src/../src/vm/Mpeg3Plugin.c:187: undefined reference to `mpeg3_audio_channels'
cd vm/libmpeg chmod +x mkMakefile make
this makes libmpeg3.a
try make again in src, this still doesn't use the .a file so I get lots of undefined references as above.
OK, try again, without the Mpeg3Plugin at all.
rm -rf src mkdir src (not sure this is necessary)
re-start VMMaker (if I don't the directory doesn't get constructed/files copied).
choose "all internal"
remove Mpeg3Plugin from internal list (move to available)
re-generate all
cd src chmod +x configure util/* ./configure make
_now_ I get a squeak...
Ned Konz ned@bike-nomad.com is widely believed to have written:
Ok... I couldn't get it to work entirely correctly; here's my notes:
configuration: src directory under Squeak directory platforms directory somewhere else.
Remove the src directory. Start VMMaker. Tell it where the directories are. make a config with all internal. Tell it "generate all". src directory is populated. chmod +x configure util/* ./configure make
OK, that's about the expected sequence of things except that once FileCopyPlugin is built and available you shouldn't have to do the chmod stuff. Oh, except I see you mentioned that permissions appear to be broken on the SF tree - I'm afraid I have no idea how to fix that other than by checking them out and checking them back after doing chmod. Is there any better way?
error:
gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -DHAVE_CONFIG_H -DUNIX -DSQ_LIBDIR="/usr/local/lib/squeak/3.1a-4164" -I. -I../src/vm -c -o Mpeg3Plugin.o ../src/vm/Mpeg3Plugin.c In file included from ../src/vm/Mpeg3Plugin.c:23: ../src/vm/Mpeg3Plugin.h:1:38: changesForSqueak.h: No such file or directory ../src/vm/Mpeg3Plugin.h:2:30: libmpeg3.h: No such file or directory make: *** [Mpeg3Plugin.o] Error 1
New problem; I've never tried to build Mpeg3Plugin becasue I thought it wasa mac only thing. One of the most recent changes was to 'fix' that. I do vaguely recall seeing a make file for mpeg3 in the directory and somehow it will need integrating into the main unix make stuff. Which reminds me that somebody that actually understands the autoconf stuff needs to work it over. I just hacked until I could make a VM; I'm pretty sure that I remembered to put tpr initials by each edit. Ned? Lex? Anyone?
[snip]
OK, try again, without the Mpeg3Plugin at all.
rm -rf src mkdir src (not sure this is necessary)
It is currently neccessary, unfortunately, to do the rmdir to clean things out. No need for the mkdir though. I'd like to work out a way to cleanly delete unwanted directories, check for file timestamps and only copy newer ones etc, but another day - or another person!
re-start VMMaker (if I don't the directory doesn't get constructed/files copied).
... I should probably stop caching the FileDirectory instances and thereby avoid this. What happens is that the cached subdirectories are assumed to already exist when clearly they don't anymore. Sigh, just another part of file handling that needs reworking.
choose "all internal"
remove Mpeg3Plugin from internal list (move to available)
re-generate all
cd src chmod +x configure util/* ./configure make
_now_ I get a squeak...
Sounds like what I would have expected. Congratulations.
tim
At 3:18 PM -0700 10/25/01, Tim Rowledge wrote:
OK, that's about the expected sequence of things except that once FileCopyPlugin is built and available you shouldn't have to do the chmod stuff. Oh, except I see you mentioned that permissions appear to be broken on the SF tree - I'm afraid I have no idea how to fix that other than by checking them out and checking them back after doing chmod. Is there any better way?
Don't have a CVS system handy to test this assertion, so I'm going only on memory here, but changing permissions in your working directory and then committing should work OK. You might have to use the -f option on your commit to force the change to actually take place if CVS isn't smart enough to notice that the files had changed (you normally can't commit a new version unless you've changed the file. The -f option says 'make a new version anyway.')
Hmm. If I get time this evening I'll move over to OS X, check out the tree and see if I see anything weird. I became way too much of a CVS expert working on GemStone/J; that knowledge might actually be useful here.
-Martin
At 7:28 PM -0700 10/25/01, Martin McClure wrote:
Don't have a CVS system handy to test this assertion, so I'm going only on memory here, but changing permissions in your working directory and then committing should work OK. You might have to use the -f option on your commit to force the change to actually take place if CVS isn't smart enough to notice that the files had changed (you normally can't commit a new version unless you've changed the file. The -f option says 'make a new version anyway.')
Hang on... experimentation indicates that won't work. The easiest way to do it is to chmod the repository files directly, but I'm assuming you don't have permission to do that. I'll continue to look for a way to get those files marked executable.
-Martin
At 9:50 PM -0700 10/25/01, Martin McClure wrote:
At 7:28 PM -0700 10/25/01, Martin McClure wrote:
Don't have a CVS system handy to test this assertion, so I'm going only on memory here, but changing permissions in your working directory and then committing should work OK. You might have to use the -f option on your commit to force the change to actually take place if CVS isn't smart enough to notice that the files had changed (you normally can't commit a new version unless you've changed the file. The -f option says 'make a new version anyway.')
Hang on... experimentation indicates that won't work. The easiest way to do it is to chmod the repository files directly, but I'm assuming you don't have permission to do that. I'll continue to look for a way to get those files marked executable.
Okay, it looks like removing the file and then re-adding it with the execute permission set does the right thing. I used these commands to make a script executable in a small test repository:
mv script foo cvs rm script cvs commit -m "Temporarily removed script while making it executable." mv foo script chmod +x script cvs add script cvs commit -m "Re-added the newly-executable script."
I also noticed that there is a binary file (and there may be others) that CVS doesn't know is binary, platforms/Mac OS/vm/resources.sit
You can mark it binary in CVS by doing:
cd platforms/Mac\ OS/vm cvs admin -kb resources.sit
This should be all you need to do if you originally imported from a Unix client. If you imported from a client platform with different line end conventions the file in the repository may be mangled and should be updated.
-Martin
Martin McClure martin@hand2mouse.com is widely believed to have written:
Okay, it looks like removing the file and then re-adding it with the execute permission set does the right thing. I used these commands to make a script executable in a small test repository:
mv script foo cvs rm script cvs commit -m "Temporarily removed script while making it executable." mv foo script chmod +x script cvs add script cvs commit -m "Re-added the newly-executable script."
OK, I managed to finally make this happen (something must be wrong somewhere in the cycle, since I kept not getting a return prompt frm SF in my shell after doing various cvs commands. <ctl-C> got it back, but ghu only knows what that causes) BUT after doing a clean checkout (empty directory) the permissions are gone again :-(. The SF logs seem to show a successful removla/replacement.
tim
Thanks to a couple of suggestions from Martin, the permissions problem seems to have been solved. SF now has a tolerable platform sources tree.
I've successfully CVS check-outed the tree, loaded the latest VMMaker changeset into a virgin 4411 image and built a unix VM. Seems to me it is ready for combat testing guys.
The changeset is http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas/VMMaker-3-1-version3.c...
The swiki page is http://minnow.cc.gatech.edu/squeak/2105
tim
Ned Konz ned@bike-nomad.com wrote:
On Wednesday 24 October 2001 05:18 pm, Tim Rowledge wrote:
I've just imported the platforms tree as suited to VMMaker (see http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas and look for the latest VMMaker* file(s) ) to SourceForge (see http://sourceforge.net/projects/squeak) in the hope it might actually work as a way to let people try it out.
Not just the configure, but the other executable programs in utils (in the unix directory) are not marked as executable.
If we don't mind tweaking the makefile, then none of this is a big deal -- either the makefile can do the chmod's, or the makefile can invoke the scripts as "sh ./util/foo". Now that I think about it, configure shouldn't actually be in the CVS tree -- if you are using CVS, then you can also grab autoconf. .tar.gz distributions are a different matter.
Anyway, I missed the beginning of this conversation, but did anyone talk to Ian about all this?! Sure Squeak/Unix is free, but good will from its maintainer is a nice thing to have.
-Lex
"Lex Spoon" lex@cc.gatech.edu is widely believed to have written:
If we don't mind tweaking the makefile, then none of this is a big deal -- either the makefile can do the chmod's, or the makefile can invoke the scripts as "sh ./util/foo". Now that I think about it, configure shouldn't actually be in the CVS tree -- if you are using CVS, then you can also grab autoconf. .tar.gz distributions are a different matter.
Ah, but the makefile is _made_ by autoconf.... chicken and egg situation?
Anyway, I missed the beginning of this conversation, but did anyone talk to Ian about all this?! Sure Squeak/Unix is free, but good will from its maintainer is a nice thing to have.
Well VMMaker has been a pretty public project and I've asked Ian things about the make stuff on occasion, so I assume he's aware. Since he actually has a _paying job_ (I want one!) I guess he's busy enough not to be interested in worrying.
tim
Tim Rowledge tim@sumeru.stanford.edu wrote:
"Lex Spoon" lex@cc.gatech.edu is widely believed to have written:
If we don't mind tweaking the makefile, then none of this is a big deal -- either the makefile can do the chmod's, or the makefile can invoke the scripts as "sh ./util/foo". Now that I think about it, configure shouldn't actually be in the CVS tree -- if you are using CVS, then you can also grab autoconf. .tar.gz distributions are a different matter.
Ah, but the makefile is _made_ by autoconf.... chicken and egg situation?
To be pedantic, edit Makefile.in, not Makefile. There's no problem here, *if* we are willing to tweak some files in the source tree.
Well VMMaker has been a pretty public project and I've asked Ian things about the make stuff on occasion, so I assume he's aware. Since he actually has a _paying job_ (I want one!) I guess he's busy enough not to be interested in worrying.
Are you sure, though? He got pretty upset the *last* time people posted his stuff to CVS and started hacking on it without him. I believe he was fairly busy back then, too (though maybe not as much as he is now!).
Anyway, if you decide to go forward, I have a number of other suggestions about that codebase....
-Lex
"Lex Spoon" lex@cc.gatech.edu is widely believed to have written:
Well VMMaker has been a pretty public project and I've asked Ian things about the make stuff on occasion, so I assume he's aware. Since he actually has a _paying job_ (I want one!) I guess he's busy enough not to be interested in worrying.
Are you sure, though? He got pretty upset the *last* time people posted his stuff to CVS and started hacking on it without him. I believe he was fairly busy back then, too (though maybe not as much as he is now!).
Well IIRC it was mainly an issue of not wanting anyone else changing his code; personally I'd be delighted to have other people fixing my bugs for me, but each to their own. It's a free world - at least until Ashcroft gets his way.
Anyway, if you decide to go forward, I have a number of other suggestions about that codebase....
Exactly my point. I'm sure there are lots of improvements that remain to be made in all the code - anything that helps them to be realised seems a good idea to me.
Where we keep 'master' code doesn't really matter though. SF seems to me like a good place since they take responsibility for backing up stuff and providing bandwidth for fetchers. If people want to keep it on a personal site in a zip file, I couldn't really care. What I want to see is the VMMaker stuff adopted so that half-a-meg or more of fragile literal strings can be removed form the image and we can have a better tool for making more interesting VMs. As long as the files for each platform are available in a form suited to VMMaker, that's good enough.
If neccessary I'll arrange that myself, until I get bored. Remember how long it took me to get the exception handling prims accepted? I don't give up easily.....
tim
squeak-dev@lists.squeakfoundation.org
-
Eric Scharff -
Eric Scharff -
John M McIntosh -
Lex Spoon -
Martin McClure -
Ned Konz -
Tim Rowledge