[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re to re : standard stream redirection
I would like to thank all the people who helped me to solve my
problem. I also have some comments on the solutions that i recived and
i think that they may help other people.
1) My own code does not work neither with 7-1 nor with 7-2, but the
error is not the same: with 7-1, the unclaimed message was
:character-width, with 7-2 it is :set-cursorpos.
2) The first solution i received, was to create a buffer with the
following piece of code:
(defvar *buf* ())
(defun make-buf ()
(setq *buf* (zwei:open-editor-stream :buffer-name "my-temp"
:create-p t :no-redisplay t)))
When i tried it under 7-1, i got the same error message that with my
own code. But it worked under 7-2 (at least the beta-test version we
3) I recived a second solution which is the following:
(defmethod (:character-width fs:nfile-output-character-stream)
With 7-1, it does not work at all: i get the same error, either with
my own code and the first solution i got (the creation of a buffer).
With 7-2 this does not help more. I get the same error message with
my own code, and the first solution i received does still work.
4) I got an bug report with the stack content at the moment of the
error. what i can see is quite strange: near the top of the stack, the
function trace-print is called (which is correct), and at the bottom,
the method :tyo is called, which seems correct. But the :tyo method is
not the one we need: it is not the method defined for bufferd output
stream, it is the one defined for pixel-widt-streams ! Between the two
calls, i found, for example, a creation of an instance of an
indenting-stream. In fact, everything happen as if the trace printer
"believe" that the trace output is an interactive stream.
the bug is probably just at the beginning of the trace, in the first
5) > Problems such as this probably should have been sent to
>Symbolics's CUSTOMER-REPORTS rather than to SLUG.
Yes and no:
_ I think that the indication of a new problem may interest (and warn)
_ I do not mean that this problem should NOT have been reported to
SYMBOLICS'S CUSTOMER-REPORT, i just mean that it may interest other
_ IF ONLY I COULD REPORT IT TO SYMBOLICS'S CUSTOMER-REPORT ! We have
so huge problems with zmail, with the connection between our
symbolics and the VAX/VMS which is used as BITNET node and with the
BITNET sending procedure. I does not want to bother you with our
local problems, but just know that we have a small network of three
machines, that ZMAIL did never succeed to send a message form one
user to another one (the maintenance people form Sybolics coming
from Germany did never succeed to solve the problem in our site);
and that, as the connection via Zmail between our net and the VAXes
of the school does not work, we have to transport files "at hand"
via TELNET through several nodes; that the sending procedure for
BITNET does not handle the files which have lines of more than 80
characters and deletes the control characters used to specify the
page layout, the font and so on. Finally, the destination node for
the customer-report is not recognized as a valid destination by that