On 12/12/07 06:55, [email protected] wrote:
The three process approach is interesting if not also a bit
heavyweight and prone to the problems of the kind you mention. However
it is general.
Another approach which stays within one process is gdb annotations or
its follow on. Debugger output is in a different annotation from
program output so you know where you are. I'm not sure how waiting for
input is handled though.
One thing people who use shells miss in a debugger shell is command
completion. Python's stock debugger doesn't have it (at least not for
2.5.1) although ipython does; Ruby's shell, irb, can add this easily
too. In pydb there is a "complete" command which lists possible
completions for at least commands and subcommands. As with readline,
this is often bound to the <tab> key. Complete returns a list of
possible completions and then it is up to the front-end to figure out
the best way to display this.
It's kind of hard to describe this so you may get a better sense by
trying say pydb. The last release of pydb doesn't have gdb annotations
but what is in CVS does. And even here it lags a little behind what is
in ruby-debug's SVN. In particular ruby-debug is tagging program
output, while in pydb this still is more inferential since it appears
somewhere around the prompt which is tagged. However if this is of
interest and it is of interest, let me know and I can try to bring the
code more in line with the Ruby debugger code.
On Dec 11, 1:07 pm, cthoday <[email protected]> wrote:
On Dec 11, 11:11 am, "[email protected]"
<[email protected]> wrote:
On Dec 10, 11:05 am, cthoday <[email protected]> wrote:
.
There is a Smart Terminal that allows interactive shells to operate
within a wx.TextCtrl. On Unix such programs need to be connected to a
pseudo terminal if they are to operate in interactive rather than
batch mode. However, the easy way to connect a Python program to
another process is by pipes. I have solved this by writing a small C
program to copy to and from the subprocess via the pseudo terminal.
ddd and Emacs typically work this way - using a subprocess via a
pseudo terminal.
Python has a pseudo tty module but I could not get it to do what I
wanted. The basic problem is that the shell thinks it is controlling a
VDU terminal but the application program cannot find out what mode the
shell is working in. If it is working in canonical mode then the line
is composed in the application before being sent to the shell. In raw
mode the application must send individual characters and compose the
line from the responses it gets. There may be no response if the input
was a password. Some responses do not work as might be expected. For
example the response to Backspace is Backspace, Space, Backspace. The
first Backspace moves the cursor to the left, the Space replaces the
character to be erased (provided it is not in Insert mode) and the
second Backspace move back over the Space.
There is no means for the application program to determine whether or
not the shell is waiting for input. The shell assumes that the
terminal has displayed the prompt but it may be waiting in a buffer.
If it assumed that no buffering is used then multiple lines of output
from the program running in the shell may be painfully slow to display
in the application. The solution uses three processes: one copies from
the pipe to the tty, another copies from the tty to the pipe and the
third runs the shell. This works well except that it sometimes leaves
zombie processes if a process terminates abnormally.
Shells that use GNU readline operate in raw mode but those that do not
have this facility provide a very poor experience for the user. In
this case I implement some basic line editing so that the user can at
least correct mistakes with Backspace. Shells that do not have line
editing include PHP and OCaml but, in the latter case, the shell comes
with the "ledit" command which solves the problem.
nov 18 sapm
--
---
You received this message because you are subscribed to the Google Groups "pyxides" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/pyxides/492d7c4b-bb37-4344-970a-9709b3d5e282%40gmail.com.
