---------- Forwarded message ---------- From: Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com Date: 2008/8/19 Subject: Fwd: [Ecls-list] [ltk-user] LTK and ECLS To: Marko Kocić marko.kocic@gmail.com, "Thomas F. Burdick" tburdick@gmail.com
CC of a message I sent to the ECL list. Since I am not subscribed to the LTK list, could any of you forward it?
Juanjo
---------- Forwarded message ---------- From: Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com Date: Tue, Aug 19, 2008 at 2:36 PM Subject: Re: [Ecls-list] [ltk-user] LTK and ECLS To: Talk about Ltk the Lisp Toolkit ltk-user@common-lisp.net, The ECL List ecls-list@lists.sourceforge.net
2008/8/15 Thomas F. Burdick tburdick@gmail.com:
I'm sending a copy of this to the ECL list, since I can't see what's going wrong from here, nor can I get ecl to build on my system. [...]
Thanks for forwarding this copy.
ECL guys: are the backtraces more usable when loaded from source or from compiled files?
Backtraces are more usable in source files. Compiled files do not keep enough debug information to inspect local variables, blocks, etc.
; loading system definition from /lisp/lib/ltk-0.91/ltk.asd into ; #<ASDF0 package> ;;; Loading "/lisp/lib/ltk-0.91/ltk.asd" ; registering #<SYSTEM LTK 15100376> as LTK ;;; Loading "c:/lisp/lib/ltk-0.91/ltk.lisp" NIL
(setf ltk:*wish-pathname* "c:/Tcl/bin/wish85.exe")
"c:/Tcl/bin/wish85.exe"
;(setf ltk:*debug-tk* t)
(ltk:ltktest)
#<two-way stream 00f0db68>
This has been fixed in CVS today. I sent previously a email explaining the problems, but LTK has to be changed. The line that executes RUN-PROGRAM should now read similar to the SBCL one, because ECL implements the :WAIT argument
#+:ecl(ext:run-program program args :input :stream :output :stream :error :output :wait wt)
Backtrace: LTK:SEND-WISH > ltk::init-wish > lambda > lambda > ltk::use-debugger > ltk::use-trivial-debugger > lambda > l tk:start-wish > ltk:start-wish > ltk:call-with-ltk > ltk:ltktest > si:bytecodes > si:bytecodes > si:bytecodes
That's not the most helpful backtrace I've ever seen
That is because the backtrace only outputs the list of functions. If you run backwards using :p, then you can inspect the variables using :v. However in this case it would not have helped because the error was in the C core, which can only be debugged using GDB.
but it looks like something in send-wish is causing this "Invalid argument" error?
RUN-PROGRAM outputs a two-way-stream. If one of the directions is not used, because we only want to write to or read from a child process, it uses a dummy or "null" stream. The problem is that this dummy stream had the wrong type -- it was a broadcast stream --. This has been fixed in CVS, where the dummy stream now is an I/O stream. I am considering the possibility of releasing a patch, since this is serious enough, but would like to wait until I fix other problems that have been reported recently.
Sorry for the long delay in this answer, but I was on holidays for a week and a half.
Juanjo
-- Instituto de Física Fundamental CSIC, Serrano, 113, Madrid 28040 (Spain) http://juanjose.garciaripoll.googlepages.com
-- Instituto de Física Fundamental CSIC, Serrano, 113, Madrid 28040 (Spain) http://juanjose.garciaripoll.googlepages.com
I just tried LTK with latest Ecls from git repo, and quick ltktest + ltk-eyes says it works ok The only change to LTK is, as Juan suggested, to use :wait parameter.
#+:ecl(ext:run-program program args :input :stream :output :stream :error :output :wait wt)
2008/8/19 Marko Kocić marko.kocic@gmail.com:
---------- Forwarded message ---------- From: Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com Date: 2008/8/19 Subject: Fwd: [Ecls-list] [ltk-user] LTK and ECLS To: Marko Kocić marko.kocic@gmail.com, "Thomas F. Burdick" tburdick@gmail.com
CC of a message I sent to the ECL list. Since I am not subscribed to the LTK list, could any of you forward it?
Juanjo
---------- Forwarded message ---------- From: Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com Date: Tue, Aug 19, 2008 at 2:36 PM Subject: Re: [Ecls-list] [ltk-user] LTK and ECLS To: Talk about Ltk the Lisp Toolkit ltk-user@common-lisp.net, The ECL List ecls-list@lists.sourceforge.net
2008/8/15 Thomas F. Burdick tburdick@gmail.com:
I'm sending a copy of this to the ECL list, since I can't see what's going wrong from here, nor can I get ecl to build on my system. [...]
Thanks for forwarding this copy.
ECL guys: are the backtraces more usable when loaded from source or from compiled files?
Backtraces are more usable in source files. Compiled files do not keep enough debug information to inspect local variables, blocks, etc.
; loading system definition from /lisp/lib/ltk-0.91/ltk.asd into ; #<ASDF0 package> ;;; Loading "/lisp/lib/ltk-0.91/ltk.asd" ; registering #<SYSTEM LTK 15100376> as LTK ;;; Loading "c:/lisp/lib/ltk-0.91/ltk.lisp" NIL
(setf ltk:*wish-pathname* "c:/Tcl/bin/wish85.exe")
"c:/Tcl/bin/wish85.exe"
;(setf ltk:*debug-tk* t)
(ltk:ltktest)
#<two-way stream 00f0db68>
This has been fixed in CVS today. I sent previously a email explaining the problems, but LTK has to be changed. The line that executes RUN-PROGRAM should now read similar to the SBCL one, because ECL implements the :WAIT argument
#+:ecl(ext:run-program program args :input :stream :output :stream :error :output :wait wt)
Backtrace: LTK:SEND-WISH > ltk::init-wish > lambda > lambda > ltk::use-debugger > ltk::use-trivial-debugger > lambda > l tk:start-wish > ltk:start-wish > ltk:call-with-ltk > ltk:ltktest > si:bytecodes > si:bytecodes > si:bytecodes
That's not the most helpful backtrace I've ever seen
That is because the backtrace only outputs the list of functions. If you run backwards using :p, then you can inspect the variables using :v. However in this case it would not have helped because the error was in the C core, which can only be debugged using GDB.
but it looks like something in send-wish is causing this "Invalid argument" error?
RUN-PROGRAM outputs a two-way-stream. If one of the directions is not used, because we only want to write to or read from a child process, it uses a dummy or "null" stream. The problem is that this dummy stream had the wrong type -- it was a broadcast stream --. This has been fixed in CVS, where the dummy stream now is an I/O stream. I am considering the possibility of releasing a patch, since this is serious enough, but would like to wait until I fix other problems that have been reported recently.
Sorry for the long delay in this answer, but I was on holidays for a week and a half.
Juanjo
-- Instituto de Física Fundamental CSIC, Serrano, 113, Madrid 28040 (Spain) http://juanjose.garciaripoll.googlepages.com
-- Instituto de Física Fundamental CSIC, Serrano, 113, Madrid 28040 (Spain) http://juanjose.garciaripoll.googlepages.com
-
Marko Kocić