[Ecls-list] CLOS streams
der_julian at web.de
Fri Jun 27 04:40:20 UTC 2003
On Fri, 27 Jun 2003 10:58:17 +0200
Juan Jose Garcia-Ripoll <worm at arrakis.es> wrote:
> No problem. It just complains because, when you are defining these functions,
> the Common-Lisp package is locked. If you do (SI:PACKAGE-LOCK "CL" NIL)
> and (SI:PACKAGE-LOCK "CL" T) before and after your code, everything should
> become quieter.
That does it. :)
> > 2) I think there too many empty lines written. Looks strange sometimes:
> a) Some characters have special meaning in the output. In particular, your
> %print function has to interpret #\Newline not only as a flush character, but
> also as a new line command. See the code I have attached: my implementation
> of %PRINT issues a FRESH-LINE whenever it finds #\Newline, and otherwise
> outputs the character directly to the terminal. Depending on the device which
> you use for output, you may need or not care about this.
%print itself issues a newline whenever it writes something. So that part should be correct.
> b) STREAM-FORCE-OUTPUT may be called any number of times by the lisp
> environement, to ensure that buffers are being flushed, but it does not imply
> that a new line has to be written. Therefore, your STREAM-FLUSH-BUFFER should
> do nothing when the buffer is empty.
Ok, I guessed this, since if it passes "" to %print (which in turn prints a newline), everything is screwed up.
> c) You do not need to detect #\Newline characters in the STREAM-WRITE-CHAR
> routine. This can be done in the %PRINT-ROUTINE. This way, since your routine
> will operate on strings, the check may be compiled faster. Or, if you use C
> routines to output data, you do not even need to care about the #\Newline.
You are suggesting the usage of a full buffer. But then I would have the problem that some output is delayed for quite a long time or I have to clutter lisp code with I/O flushing. Line buffering seems more usable here, since performance is not an issue and complete lines with linebreak are the only thing I can correctly write on the X-Chat console. BTW, X-Chat tends to crash if a really long string is passed to it. :)
> BTW, I am going to build an "examples" directory for ECL. Could I include a
> modified version of the file you have posted to the list?
Yes, of course.
Thanks for your answers.
PS. Sorry for the screwed quoting...
Support strong cryptography.
Key ID : D65B2AB5
Fingerprint: FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Key server : pgp.mit.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
More information about the ecl-devel