[Openmcl-devel] slow read-char
erik at adaptations.com
Wed Jul 26 15:28:40 EDT 2006
It looks like, as predicted, cvs bleeding is busted -- even using the
new test image.
compile-ccl gets to
Read error between positions 0 and 726 in /usr/local/ccl/ccl/lib/
> Error: Unknown type specifier: BASIC-STREAM
> While executing: %%TYPEP, in process listener(1).
and then dies, leaving the REPL in a sad unusable state.
Dare I guess this is a boostrapping issue? Some of the stream code
has already been loaded that requires BASIC-STREAM, but basic stream
hasn't been loaded yet, or incompatible streams have already been
created, or something like that? Is this a matter of magically
creating a compatible image, or can it be solved by changing the
build procedure, or is such an outlier case (messing with system
fundamentals) that you'd rather just special-case it? I would hope
that rebuild-ccl (thanks for that!) would be able to handle
reconstructing the system from pieces. Perhaps a very primitive lisp
that doesn't rely on high(er) level functionality (single-threaded,
just reads bytes, etc.) could be invoked to rebuild the system, even
from the Unix command line? But what the bleep do I know.
On Jul 22, 2006, at 5:03 AM, Gary Byers wrote:
> On Sat, 22 Jul 2006, Eric Marsden wrote:
>>>>>>> "gb" == Gary Byers <gb at clozure.com> writes:
>> gb> It's tricky to bootstrap a few of those changes (I actually
>> gb> to produce images that were much less functional than yours
>> seems to
>> gb> be ...).
>> I have finally found a lisp implementation that is even harder to
>> build than CMUCL ; at least CMUCL developers generally provide
>> bootstrap files that help automate the build process :-)
> There are now bootstrapping images for 32/64-bit DarwinPPC and
> x86-64 Linux in the testing directory; if anyone wants LinuxPPC
> images, please let me know.
> I also tagged the current bleeding-edge tree (whose contents match
> those images) with the tag "work_in_progress_060720". This may
> make it easier for anyone who wants to insulate themselves from
> subsequent changes to do so. (Recall that CVS tags are "sticky"
> and that it may be necessary to clear them in order to get back
> in synch with the head.)
> Hopefully, these will become obsolete (incompatible with bleeding-edge
> CVS and unable to easily build from it) later today (or as soon as
> I can check in the next round of incompatible, difficult to bootstrap
> low-level stream changes.)
> Since this is likely to be pretty volatile - and since I don't really
> have a better way of keeping all platforms in synch without checking
> in a lot of incremental (aka half-finished) changes, I think that the
> advice that I gave the other day still holds: it's likely to be
> tricky to build the lisp from CVS while these changes are taking
> place, it's still not likely to take more than a few days, and when
> that dust settles I'd certainly -want- to provide images and/or
> snapshot tarballs to make it easy for people to use and test the new
> Aside from the fact that it's evidence of a step in the right
> direction, I don't think that the 060720 code is particularly
> interesting. If people are concerned about I/O performance and
> want to see evidence of that first step, then I suppose that
> these images might be of greater interest.
>> Eric Marsden
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel