[armedbear-devel] ticket #124: SBCL build host / "the" pretty printer issue

[Erik Huelsmann]

Talking to Mark on IRC, we were discussing about how to restore ABCL's
capability of being an SBCL buildhost. We were a buildhost some years back:
it was one of the things Peter Graves used to stress test ABCL's
conformance. However, we've not been able to build SBCL for quite some time
now, as ticket #124 [1] witnesses.

In IRC Mark kept referring to this problem as "the issue with our Gray
streams conformance". I'm writing this mail to explain that our "Gray
streams conformance" is not the issue that's causing this breakage.


Basically, we have two issues with our streams:

1. Gray streams conformance
2. Our pretty printer implementation

While our Gray streams conformance may not be ideal - I'd have to
investigate where we stand exactly on that issue - our pretty printer is
breaking our ability to build SBCL. (Our Gray streams conformance is good
enough to support flexi-streams, so, that's good enough for me.)


The usual way a pretty printer is implemented -and that's the way SBCL
implements it as well- is by wrapping a stream around the stream which is
being pretty printed to. That way, the pretty printer receives all output
being printed and is in a position to appropriately add tabbing, indenting
and other formatting. Then it sends the output to the actual target stream.

Now, our implementation is a little bit different, but different enough to
cause problems, I guess. We wrap the stream being printed to, however, we
wrap the stream with a structure object instead of another stream.

Then, in order to mitigate the negative effects from our wrapping using a
structure-object (XP-STRUCTURE). On the Java side of things, input values
are being checked to be a STREAM, however, this XP-STRUCTURE isn't a derived
class from a class which is a stream. So, our Java side type checking fails.

Any conforming code should expect the stream argument to PRINT-OBJECT to be
a stream (but it cannot make more assumptions than that), an expectation we
violate.

Possibly, there are other spots where we fail to meet the STREAMP checks.


My idea to resolve the situation would be to create streams the way SBCL
does it: SBCL knows two types of streams: Gray streams and ansi-streams.
Anything not an ansi-stream follows the Gray stream dispatch path.

ANSI-STREAM is a structure-object which holds slots for input and output
functions. The pretty printer structure includes the ANSI-STREAM structure
by virtue of which it becomes a stream itself. The STREAM type is simply
DEFTYPEd to be equal to ANSI-STREAM.


The I/O routines (it only sets the output routine) simply forwards its
writes to the to the wrapped stream. This way, their pretty printer wrapper
stream doesn't violate any of the expectations user code may have about the
STREAM argument of PRINT-OBJECT.


My idea would be that we should investigate if and how we can implement a
similar approach.


Mark or anybody else, could you comment on the above?



Bye,


Erik.


[1] http://trac.common-lisp.net/armedbear/ticket/124
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20110823/d0b30d57/attachment.html>