[Openmcl-devel] new snapshot tarballs (finally)
Gary Byers
gb at clozure.com
Thu Oct 26 22:38:15 PDT 2006
On Thu, 26 Oct 2006, Joshua Moody wrote:
> Gary,
>
> Are you planning on generating new snapshots with this fix incorporated?
>
> Thanks,
>
> jjm
>
I wasn't planning to do so right away (though I do want to keep relatively
current binaries available and to avoid having things get as badly out-of-synch
as they've been the last few months.)
If the notion of rebuilding the lisp from sources is daunting, it needn't be.
If you squint at the documentation on the web site it might make sense; here's
a fairly concise and hopefully correct explanation:
0) ensure that your firewall doesn't block TCP port 2401; you may need to
check with someone locally if you don't know, or you could do:
shell> telnet clozure.com 2401
If that connects, you'll know that you can communicate wth clozure's CVS
server without a firewall blocking access; if it connects, you can get back
to the telnet> prompt by typing ctrl-], and back to the shell by
telnet> quit
If it hangs, your site's firewall blocks access to TCP port 2401; see
Appendix A below ...
1) Assuming that you can connect to the CVS server, connect to it and provide
it with a password. (This is kind of silly, since you're just trying to
get anonymous, read-only access.) You only need to do this once on any
given client machine (though it doesn't hurt to do it more often):
shell> cvs -d :pserver:cvs at clozure.com:/usr/local/tmpcvs/openmcl-dev login
You'll be asked for a password if you haven't logged in from your client
machine/account before; CVS may also warn you that a file named "~/.cvspass"
didn't exist and needed to be created. (This is normal, but the wording
of the message makes the situation sound more alarming than it actually is.)
The anonymous CVS password to all repositories on clozure.com is "cvs".
Once you've done that "login" step - once your ~/.cvspass file exists and
contains a (barely) encrypted copy of that password - you won't be asked
for a password again.
2) cd to the "ccl" directory which contains the untarred version of the most
recent snapshot. From that directory, do:
shell> cvs update
That'll print a lot of progress messages; at this moment, the only file
that's changed since the snapshot archive was built is "level-1/l1-streams.lisp".
If you didn't want to see the progress messages, you could have done:
shell> cvs -q update
in which case CVS will generally only print messages about "interesting"
files (those where the server had a more recent version and your local copy
was updated, those that you've modified locally and differ from the server's
version, and those that you've modified locally (these may contain changes
which conflict with the server's copy; CVS tries to be smart about merging
changes, but doesn't always succeed.)
3) Once your sources are updated, start the lisp and tell it to rebuild itself.
(This has gotten simpler in the 1.1 prereleases.)
Welcome to OpenMCL 1.1-pre-some-recent-date !
? (rebuild-ccl :force t)
You should then see output that looks like:
;Building lisp-kernel ...
;Kernel built successfully.
;Compiling "/usr/local/src/ccl/compiler/nxenv.lisp"...
[ about 100 files later]
;Wrote bootstrapping image: #P"/usr/local/src/ccl/ppc-boot64.image"
;Wrote heap image: #P"/usr/local/src/ccl/dppccl64.image"
NIL
?
The directory names and image file names may differ, but aside from some
messages of the form:
Can't find foo.fasl, loading foo.lisp instead
you should usually not see any warnings and should definitely not see any
errors. Assuming that that runs to completion, you can then:
? (quit)
and when you run the lisp (the one in the bleeding-edge snapshot tree)
again you should find that it's been built from the latest sources (at
the moment, that means that the stream bugs that've been reported and
fixed should be fixed in your image.)
4) The bleeding edge tree (ideally) changes rapidly sometimes. Sometimes,
the nature of those changes makes it very hard to build the lisp from
current sources (even by using a very recent binary.) It's obviously
-possible- to do that, but it's sometimes very tricky - trickier than
just compiling a bunch of files in a fixed order, which is all that
REBUILD-CCL or similar know how to do. (I couldn't think of a way
to bootstrap the recent changes to STRINGs and CHARACTERs without
cross-compiling: what a CHARACTER or a STRING was in the host machine
had to be clearly separated from what those things would be in the
target machine.)
When things start to get out of synch (so that things like REBUILD-CCL
will no longer bootstrap the current source from recent binaries), I'll
try to make binaries (or complete snapshot archives) available. I'm
-usually- pretty good about this; for the last few months, things have
been very much of a moving target and it hasn't been practical to do
that. I think that most of the rearchitecture is done (for a while,
at least), and that most changes are more likely to be of the form
"fix a bug or add a feature" rather than "change what a STRING or a
STREAM is."
Appendix A
If you can't use CVS's "pserver" protocol because a firewall blocks TCP
port 2401, there are other alternatives. You can use an ssh-based CVS
access method that can get through more firewalls, and there's also a
Web-based CVS accesss method. More details are available on the CVS
page of the OpenMCL web site.
If you were asking about making snapshots for some other reason ... well,
never mind.
More information about the Openmcl-devel
mailing list