[maiko] DSPBOUT, (CHARCODE EOL) - better handling of output to the "BCPL display"

[nbriggs]

I happened to be looking in Maiko's dspsubrs.c, and discovered that there's a DSPBOUT subr, which is responsible for putting out a single character to the (implicitly specified) "BCPL display" stream - that's where those odd strings come from during the loadup process. The BCPL display (aka \TERM.OFD and *STANDARD-OUTPUT* before the window system comes up) in Maiko is bound to Unix stdout. The Lisp code that uses this is mostly in ATERM (e.g., SIMPLEPRINT).

As is to be expected, the Lisp code believes that you end a line with (CHARCODE EOL) - i.e. (CHARCODE CR). This is why the "lines" of output overprint in the loadup process. It's also the case that Maiko never explicitly flushes stdout - so one may well never see the output.

While it might have been nice to have replaced the value of (CHARCODE EOL) (as stored on CHARACTERNAMES -- who knew that (CHARCODE INFINITY) => 8551 ?!) with LF back in the day, I think the best thing to do in the DSPBOUT subr is (a) notice, in Maiko, character 13 being printed and instead output a linefeed (on Unix - and I think even Windows, these days), and (b) flush the output - either on seeing the EOL, or, since it's really infrequently used call, on every character.

Opinions?

[masinter]

If we made an FDEV for Unix stdout then it would have a BOUTFN which called DSPBOUT?
could we DRIBBLE to such a stream?

[nbriggs]

@masinter - no, it's lower level than that - it knows nothing about streams, it takes exactly one 7-bit character and sends it to stdout on each call. If you want a stream interface to stdout for dribbling, just open one -- I do this often. I also dribble to "{unix}/tmp/dribble.txt" if it's big and I plan on saving it.