[developers] [spr30362] bug using climxm (with attachment)

[Stephan Oepen]

hi again, andreas (and other ACL supporters),

we were jointly trying to incorporate your CLIM patches into production
status last week, and so far failed, in part for the reasons summarized
by francis.  i am glad you can reproduce the issue he reports, at least
as far as displaying korean in various CLIM contexts is concerned.  the
input of japanese is probably a separate problem, though would be great
to see eliminated too.

however, there is another serious problem related to your patch; it was
first observed by berthold crysmann on 11-oct-06: with the patch loaded
and when running ACL within the emacs(1) -- Lisp interface, we reliably
run into the following condition:

  Error: Trying to operate on a background stream:
  #<EXCL::BACKGROUND-STREAM fd LAZY @ #x447e7c4a>

as berthold reports, using both the CLIM patch and ELI is required for
this problem to arise.  with either just your path or ELI, things work
fine.  hence, i suspect an interaction with multi-processing?

i tried gatherting a little more information and found that the error()
is thrown in a Lisp background (i.e. non-listener) process, outputting
to `t' as its stream.  i attach a session log, where the code executing
in the background process at the time of the error() was:

  (when verbose
    (format 
     *tsdb-io*
     "~&create-cache(): write-through mode for `~a'.~%"
     data)
    (force-output *tsdb-io*))

as you will see in the log, the stream causing the error() is:

  A TENURED EXCL::BACKGROUND-STREAM @ #x447e59a2 = \
    #<EXCL::BACKGROUND-STREAM fd LAZY @ #x447e59a2>
   0 Class --------> #<STANDARD-CLASS EXCL::BACKGROUND-STREAM>
   1 J-WRITE-BYTE -> #<Function DUAL-CHANNEL-WRITE-BYTE>
   2 J-READ-BYTE --> #<Function DUAL-CHANNEL-READ-BYTE>
   3 J-UNREAD-CHAR -> #<Function DUAL-CHANNEL-UNREAD-CHAR>
   4 J-WRITE-CHARS -> #<Function (:EFFT EXCL:DC-WRITE-CHARS :LATIN1-BASE)>
   5 J-WRITE-CHAR -> #<Function (:EFFT EXCL:DC-WRITE-CHAR :LATIN1-BASE)>
   6 J-READ-CHARS -> #<Function (:EFFT EXCL:DC-READ-CHARS :LATIN1-BASE)>
   7 J-READ-CHAR --> #<Function (:EFFT EXCL:DC-READ-CHAR :LATIN1-BASE)>
   8 J-LISTEN -----> #<Function (:EFFT EXCL:DC-LISTEN :LATIN1-BASE)>
   9 REREAD-COUNT -> fixnum 0 [#x00000000]
  10 LAST-CHAR-READ-SIZE -> fixnum 0 [#x00000000]
  11 ENCAPSULATED-CHAR-READ-SIZE -> fixnum 0 [#x00000000]
  12 XPSTRUCT -----> The symbol NIL
  13 DRIBBLE-OUT --> The symbol NIL
  14 MELDED-STREAM -> #<EXCL::BACKGROUND-STREAM  fd LAZY @ #x447e59a2>
  15 MELDING-BASE -> #<EXCL::BACKGROUND-STREAM  fd LAZY @ #x447e59a2>
  16 EXTERNAL-FORMAT -> EXCL:EXTERNAL-FORMAT struct = <...>
  17 RECORDINGP ---> The symbol NIL
  18 OUTPUT-RECORDING -> The symbol NIL
  19 CONTROL-OUT --> simple T vector (32) = #(NIL NIL NIL ...)
  20 CONTROL-IN ---> simple T vector (32) = #(NIL NIL NIL ...)
  21 OUTPUT-HANDLE -> The symbol :LAZY
  22 INPUT-HANDLE -> The symbol :LAZY
  23 PLIST --------> (:DUMPLISP-GENERATION-TICK 1), \
    a proper list with 2 elements
  24 CO-STATE -----> The symbol NIL
   ...
  38 INIT-INDIR-OUT -> #<Function ILLEGAL-OUTPUT-TO-BACKGROUND-STREAM>

can any of the developers make sense of this?  maybe there is something
in the above that looks really surprising to you?

                                          with thanks in advance  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at csli.stanford.edu; oe at ifi.uio.no; oepen at idi.ntnu.no ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stream.log
Type: application/octet-stream
Size: 17488 bytes
Desc: not available
URL: <http://lists.delph-in.net/archives/developers/attachments/20070311/4368e3cb/attachment.obj>