<br><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Basically, we have two issues with our streams:</div><div><br></div><div>1. Gray streams conformance</div><div>2. Our pretty printer implementation</div><div><br></div><div>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.)</div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Possibly, there are other spots where we fail to meet the STREAMP checks.</div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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. </div>
<div><br></div><div><br></div><div>My idea would be that we should investigate if and how we can implement a similar approach.</div><div><br></div><div><br></div><div>Mark or anybody else, could you comment on the above?</div>
<div><br></div><div><br></div><div><br></div><div>Bye,</div><div><br></div><div><br></div><div>Erik.</div><div><br></div><div><br></div><div>[1] <a href="http://trac.common-lisp.net/armedbear/ticket/124">http://trac.common-lisp.net/armedbear/ticket/124</a></div>