re to re : standard stream redirection

[BAECHLER%CLSEPF51.BITNET@cunyvm.cuny.edu]

  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
  have).

3)  I recived a second solution which is the following:

    (defmethod (:character-width fs:nfile-output-character-stream)
        (&rest ignore)
      1)

     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
  functions called.

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)
    other people.

  _ 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
    people.

  _ 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
    procedure !