Luke-SDK - Source Browser and Software Developers Toolkit

[cthoday]

After two years of development I have recently made the first general
release of Luke-SDK which is a general purpose development
environment. Due to problems with the wx.TreeCtrl on Windows I have
concentrated on getting the Linux version into a usable state.

It is aimed at those who are used to a mixed mouse and keyboard style
of editing familiar to Windows users. There are only a few special
key strokes, such as Shift+Ctrl+V for "smart paste", but it is not
necessary to learn a large number of obscure key combinations.

It aims to be usable out-of-the-box without the need for plugins.
There are only two requirements: Python and wxPython. All other
dependencies are optional and assistance is provided for locating the
packages and web sites for the compilers, interpreters, debuggers,
syntax checkers and build systems for the supported languages: Boo, C,
C++, C#, D, Java, JavaScript, Lua, OCaml, Perl, PHP, Pike, Python,
Ruby and Tcl/Tk.

The user interface makes extensive use of context sensitive menus and
every menu starts with a title line that is also a way of obtaining
specific help for the menu. Most dialog boxes have a Help button to
explain what input is required. There are few options so that new
users are not expected to make choices that they may not understand.
Unsuitable defaults that may trap unwary users are avoided.

Any directory can be opened as a project without prior definition as
such. Practically all files in a project can be opened in the IDE or
in an external tool. For example, a .glade file can be opened in the
Glade Interface Designer or edited as an XML file. The project
directory defines the scope of the search-in-files facility that I
consider to be one of the most useful features of the IDE.

Individual developers can benefit from a local version control system
even if they do not have access to a shared repository. This option is
provided by Bazaar-VCS - a Python based system promoted by Canonical.
The project directory tree shows which new or modified files have not
yet been committed to the branch repository. The branch is contained
in a hidden subdirectory within the project and is included in the
backup zip or tar file that should be made for each release.

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.
The class containing the wx.TextCtrl implements most, but not all of
the xterm (VT100) control sequences. The advantage of running the
shell in the interface, rather than in a separate application, is that
you can do so much more with the results than a xterm clone.

In order to enable the user to add tools and wizards with interactive
front-ends I have implemented a set of functions for creating a dialog
without using wxPython directly. This idea is not fully worked out
but is sufficient for basic requirements. With further development it
might be worth considering as a separate Python package.

There is a built-in method of running commands via sudo so tha Linux
system administrators can use it to edit configuration files or i
install software.

[rocky.b...@gmail.com]

On Dec 10, 11:05 am, cthoday <ch...@cthoday.uklinux.net> wrote:
> After two years of development I have recently made the first general

> release of Luke-SDK ...

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

There exists class of gdb-like debuggers, namely pydb (for Python),
rdebug (for Ruby), bashdb (for bash), remake (for GNU make), and of
course gdb for C, C++, Fortran, etc. Issuing commands and parsing
output for any of these is largely the same. So ddd figures out what
commands exist by issuing commands, like "help", and parsing output.
It also does this to figure out what's settable and the type --
integer, boolean, string -- of that variable. For these kinds of
settings, a custom dialog widget is created to allow one to modify the
settings.

Also, for all of the debuggers mentioned except "remake" there another
kind of interaction possible by using what's called in gdb
"annotations". When an "annotation level" of 3 or above is set, those
debuggers tag bits of output to make parsing by such a front-end
easier. So local program output (as opposed to debugger output) is
tagged; the names of local variables and their values is tagged; and
so on. Some of the annotated output may be triggered by debugger
events. For example if one moves up or down a frame, this may trigger
listing the local variables for this frame. In this way, the UI can
update information it may be saving without having to poll the
debugger for the information.

"annotations" in gdb is a little bit deprecated though and there is
newer interface between the debugger side and the UI. However since
it's a bit more complicated none of those debuggers except gdb use it.
And even there in GNU Emacs, the "annotations" are still supported and
used more frequently.

[cthoday]

On Dec 11, 11:11 am, "rocky.bernst...@gmail.com"

<rocky.bernst...@gmail.com> wrote:
> On Dec 10, 11:05 am, cthoday <ch...@cthoday.uklinux.net> 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.

[rocky.b...@gmail.com]

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.

[o lu]

nov 18 sapm