[Ecls-list] [ltk-user] LTK and ECLS

[Marko Kocić]

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 at gmail.com>:
> ---------- Forwarded message ----------
> From: Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com>
> Date: 2008/8/19
> Subject: Fwd: [Ecls-list] [ltk-user] LTK and ECLS
> To: Marko Kocić <marko.kocic at gmail.com>, "Thomas F. Burdick"
> <tburdick at 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 at 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 at common-lisp.net>, The
> ECL List <ecls-list at lists.sourceforge.net>
>
>
> 2008/8/15 Thomas F. Burdick <tburdick at 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
>