[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: ITLA
[Gnu-arch-users] Re: ITLA
Mon, 01 Mar 2004 20:14:29 +0100
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
Tom Lord <address@hidden> writes:
> > I'm not totally clear what you mean here, and how that relates to an
> > Arch<->CVS gateway. Anyway, you might be interested in my ITLA
> > thingy.
> You appear to have left out the footnote.
Indeed:  http://stud3.tuwien.ac.at/~e9926584/ITLA
> I'd like to point out some info about the ITLA idea. ITLA is not, at
> it's core, tla specific -- it's a generic engine for making
> interactive Scheme programs, both CLI and GUI.
I obviously missed the initial discussion. Big thanks for pointing
> The ITLA framework is one of the target applications for Pika Scheme
> but it will be a long time before Pika is ready to start implementing
> it. There's no reason not to start on the framework earlier, using
> Guile (and many good reasons to do so).
I'll quote parts of your initial ITLA mail here, adding my view how
things would/could look like when *I*'d do this in Guile, building
upon/integrating my ITLA stuff.
| Each interactive command will be defined by an ordinary Scheme
| procedure supplemented with a _declaration_. The declaration lists:
| ~ the name of the command
| ~ a documentation string for the command
| ~ a list of options and parameters to the command, each
| specified by:
| + a parameter name
| + a "type declaration" (e.g., "string", or "new-archive-name",
| or "existing-archive-name", or "archive-name".)
| + a description of how it is parsed from options and
| arguments provided on command lines
| + a default value
| + an optional prompt string
| + an optional help string for the parameter
| ~ a "type declaration" for the output of the command
I'd make the declaration result in registering a GOOPS class instance
somewhere. Type declarations would map to classes directly, along with
generics that deal with I/O, completion, etc.
| The "main loop" of itla reads partially specified command lines,
| looks up the interactive command, parses any options and arguments
| already provided, and enters a generic "argument editor" that
| prompts for the remaining arguments
| Once the parameter editor is done collecting parameters, the
| procedure that defines the command is called. Typically, it
| works by running tla as a subprocess.
This is the part on which "my" ITLA focuses currently: Offering a
GOOPS-based scripting interface to tla.
| It can also recursively
| invoke the command loop to run particular commands (e.g., import
| might recursively call "prepare-tree" and/or "make-archive").
Right now, I use the Guile repl (as can be seen from the screen-shot
at ), which is of course not the most user-friendly thing to do
| The rationale for this approach is four-fold:
Full ACK here.
| * Usefulness for GUIs
| There is nothing that says that the parameter editor and output
| handler have to be TTY programs -- nothing that says they have
| to do their work by printing prompts and reading keyboard input.
| For example, a GUI might include an alternative form of the
| parameter editor that knows how to translate _any_ command
| declaration into a "form".
| That approach can make writing a complete GUI a much smaller task
| and effort can focus on generic parts that help the entire
| interface (such an an "archive name selector").
| It also means that a GUI can automatically just "work" as new
| commands are added to itla. For example, after I load a set
| of extensions defining commands specific to the tla project,
| these can automatically appear on a menu or toolbar and immediately
| have a GUI interface.
I'd use Guile-GObject here.
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Latein ist das humanoide Äquivalent zu Fortran.
-- Alexander Bartolich in at.linux
- [Gnu-arch-users] Re: ITLA,
Andreas Rottmann <=