CLOSURE-HTML 20101006-git fails to compile

[Mark Evenson]

Attempting to install closure-html from Quicklisp produces a stack overflow when the compiler attempts to process the CLEX:DEFLEXER SGML:DTD form on line 89 of "src/parse/sgml-dtd.lisp".

[Mark Evenson]

closure-html still fails with stack overflow:

CL-USER(1): (ql:quickload "closure-html")
To load "closure-html":
  Load 1 ASDF system:
    closure-html
; Loading "closure-html"
;;; Checking for wide character support... yes, using UTF-16.
;;; Building Closure with CHARACTER RUNES
.............
java.lang.StackOverflowError
	at org.armedbear.lisp.Lisp.evalCall(Lisp.java:536)
	at org.armedbear.lisp.Lisp.eval(Lisp.java:506)
	at org.armedbear.lisp.Lisp.progn(Lisp.java:675)
	at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733)
	at org.armedbear.lisp.Lisp.eval(Lisp.java:496)
	at org.armedbear.lisp.Lisp.progn(Lisp.java:675)
	at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451)
	at org.armedbear.lisp.Closure.execute(Closure.java:484)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:785)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
	at org.armedbear.lisp.pprint_160.execute(pprint.lisp:774)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:170)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:739)
	at org.armedbear.lisp.gray_streams_99.execute(gray-streams.lisp:497)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
	at org.armedbear.lisp.dump_form_2.execute(dump-form.lisp:59)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
	at org.armedbear.lisp.dump_form_5.execute(dump-form.lisp:102)

[ehuelsmann]

The problem here is that our DUMP-FORM implementation doesn't handle circularity in the forms being dumped.

Should we forget about using dump-form entirely and use PRINT/PRINT-OBJECT instead?

There is one issue with the proposal above: we want to replace uninterned symbols in the output stream with their #<index>? replacement mnemonics to ensure the same symbol gets inserted everywhere it should. Other than that, it's probably a good idea.

[ehuelsmann]

(In [13600]) Fix #143: Support circularity in serialized forms

-- this enables compilation of CLOSURE-HTML.

[Mark Evenson]

Milestone 0.28 deleted