[Gnu-arch-users] is there demand for itla?

[Tom Lord]

I've been thinking a lot since it came up about how to actually 
build itla.

I believe it would be about 1-3 month's work to get a useful first
release that is then fairly easy to extend.  I also think it would
wind up eventually being a very handy tool for writing an arch GUI and
for writing overarch-style functionality.

The question I'm stuck on is how much "demand" there is for itla.
Opinions?  Ideas? Rants?  Tips?   I think it's a pretty exciting idea 
but I'm not sure what priority to give it relative to other projects.

Enclosed is a fresh description of what itla would do initially, how
it would work, and then how it could help with GUIs.


-t
https://www.paypal.com/xclick/business=lord%40emf.net&item_name=support+for+arch+and+other+free+software+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD


                                 ITLA


ITLA is the name for a proposed program which acts as an extensible,
interactive front end to tla.  It could be used for a long-lived
interactive session (like GDB), or for one shot commands.

Two properties that would make it interesting in the short term are:
interactive argument processing and higher level commands.

* interactive command processing

  For example, if you run:

        % itla get

  it might prompt:

        archive? (address@hidden): 
        category?: tla
        branch? (devo):
        version? (1.1): 
        output dir? (tla--devo--1.1): tla

        * getting tla--devo--1.1 
          to directory tla

  As it gets fancier, completion will be added.  For example, if
  the user types a question mark to the prompt:

     category?: ?

    $1  AboutRegexpsDotCom         $18  elisp
    $2  AboutThisLibrary           $19  file-utils
    $3  ArchRevCtl                 $20  ftp-utils
    $4  AuthData                   $21  hackerlab
    $5  LabNotes                   $22  labnotes
    $6  LabNotesSystem             $23  larch-utils
    $7  Labnotes                   $24  liblarch
    $8  LibHackerlab               $25  libwsi
    $9  LibUnexec                  $26  package-framework
   $10  PackageFramework           $27  scm
   $11  SystasScheme               $28  shell-utils
   $12  arch                       $29  systas
   $13  dists                      $30  text-utils
   $14  docs-hackerlab             $31  tla
   $15  docs-larch                 $32  unexec
   $16  docs-package-framework     $33  web-pages
   $17  docs-tla

    category?: $31

  or if readline support is enabled, tab-based category completion.



* higher level commands

  For example, Zander suggested a higher-level `import' command
  that would help do an initial import:


        % itla import

        The current tree is not initialized.

        Init now? [y/n]: y

        * doing "itla init-tree"

        archive? (address@hidden):
        category?: new-project
        [...]

        * doing "itla prepare-inventory"

        tagging method? (*tagline*, explicit, names, help): 
        [....]

  This could conceivably allow projects to publish project-specific
  interfaces to their patch flow (i.e., getting into "overarch"
  functionality):

        % itla
        (itla) install-project-rules \
               http://regexps.srparish.net/{archives}/address@hidden

         WARNING: this command will run programs downloaded
           from that URL.  Those programs can modify files and
           make other changes to your system.
         WARNING: are you SURE you want to do this? (yes/no): yes


         loading project rules ...
         ... done

         * updating ~/.itla
         * registering upstream archive(s)


         (itla) locally-mirror tla
         location for your mirrors?: /usr/lord/{archive}

         * reregistering upstream archive(s)
         * creating mirror archive(s)
         * tagging versions(s)

         cache base revisions? (yes, no, help): yes

         * caching dists--devo--1.0
         * caching package-framework--devo--1.0
         [....]


        (itla) start-patch tla
        branch name for patch?:  issue357
        output directory?: ~/wd/tla-issue357

        * making branches
        * building project tree
        [...]

        (itla) cd ~/wd/tla-issue357
        (itla) shell emacsclient
        [hack hack hack]

        (itla) cmt

        No log file provided.  Write one now? (y/n): y
        [...edit edit edit ...]

        * committing changes to src/libhackerlab
        * committing changes to src/tla

        (itla) submit-patch
        * preparing email

          From: address@hidden
          Subject: [PATCH] tla-1.1

          * Summary: fix issue357
          * Creator: address@hidden
          * X-merge-from-archive: address@hidden
          * X-merge-from-branch: issue357

          [...]

        send message? [y/n]: y
        * patch submitted

        (itla)


* How it Would Work

  ITLA would be written as an "extensible shell".

  Most likely, especially since arch is a GNU project, in Guile.
  SCSH, MzScheme, and Systas Scheme are other possibilities.

  It's architecture would somewhat resemble Emacs' in the following
  way:

  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

  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.   It can also recursively
  invoke the command loop to run particular commands (e.g., import 
  might recursively call "prepare-tree" and/or "make-archive").

  The rationale for this approach is four-fold:

  1) Experience with Emacs shows that this declarative approach
     makes it easier to write new commands -- easier than having
     to have each command explicitly prompt for and read parameters.

  2) Experience with Emacs shows that this leads to a more uniform
     interface:  the generic "parameter editor" works the same way
     for all commands.

  3) Experience with Emacs shows that this leads to better code 
     re-use.   For example, improvements to completion-handling
     for reading archive names are made to the generic parameter 
     editor, and as a direct result all commands that take archive
     parameters benefit.

  4) Because interaction is _data_driven_ rather than code driven,
     it is possible to replace the generic parameter editor (and
     generic output handler) with "something else".

  The last point brings us to:


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




(Background: 
 http://mail.gnu.org/archive/html/gnu-arch-users/2003-11/msg00281.html
 http://mail.gnu.org/archive/html/gnu-arch-users/2003-11/msg00282.html)