[Openmcl-devel] new snapshot tarballs (finally)

Joshua Moody moody at ISI.EDU
Fri Oct 27 11:57:41 PDT 2006

Hi Gary,

I actually needed to rebuild the linux x86 version.  I used cvs and  
the snapshot to accomplish this.

My tests pass and SLIME + Emacs + OpenMCL work as expected.

Thanks for the pointers.


On Oct 26, 2006, at 10:38 PM, Gary Byers wrote:

> 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"
> ?
>    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  
>    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  
>    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