[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem booting Hemlock



>>>>> On Mon, 09 Mar 92 12:31:40 EST, Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU said:

	RM> Asynchronous VALUE-ERROR in request 2 (last request was 4)
	RM> Code 51.0 [SetFontPath] Value 4.

	RM> I believe that it works to just continue from this error
	RM> (using the "go") command.  Probably we shouldn't try to set
	RM> font paths by default.

OK - I'll try it out.  I thought I would take this opportunity to ask
you about another problem I had.  This isn't really a "bug", but ...

I built Nuprl with CMUCL, and it was SMOOTH.  Everything compiled
nicely.  Nuprl contains an implementation of Cambridge LCF ML, and it
compiles ML source files by translating them to CL, and then compiling
with the CL compiler.

Since ML sources can contain top-level side-effects, it puts all the
top-level declarations into a big progn structure.  Anyway, to make a
long story short, when I tried to compile one of the bigger files of
ML code, CL died with what appeared to be a stack overflow.

I tried unlimiting the stack, but it still died in the same manner.

Again, I understand completely that CMUCL is not supported outside of
CMU, but nevertheless, I thought I would mention it.

The reason why you guys might be interested in Nuprl is because along
with Cambridge HOL, we are one of the most demanding users of LISP
systems I can think of.  The code we generate from ML is very
higher-order, very complex, and is run a LOT.  People build Nuprl
"libriaries" (and HOL "theores") which take a LONG time to execute -
to check the proofs mechanically.  For example, for my thesis I built
a library so big it couldn't fit on a single machine in a quarter Gig
of swap space - I used four of them to build parts, and then loaded
stripped versions onto a single machine.

Anyway, if you would like, I can provide any sort of information you
would like about the problem.  I was very plesed, by the way, that
CMUCL was capable of compiling Nuprl without any hacking.  It is
surprising how many CL's are incapable of handling the code in Nuprl.

Anyway, if you think that your people would be interested in looking
further into this problem, please let me know.

Cheers,
--chet--