[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Higher level issues

From: Ben Pfaff
Subject: Re: Higher level issues
Date: Sat, 07 May 2005 09:37:56 -0700
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

John Darrington <address@hidden> writes:

> Looking at the task manager, it seems to be more suited to things
> which are definite tasks rather than ideas which are merely potential
> tasks.  But yes, somewhere to record discussions in a slightly more
> organised fashion than mailing list archives would be useful. The wiki
> idea starts to become tempting ...   

So... I browsed around a little to free wiki hosting sites and
concluded that the best one might be  It
looks like we could create a PSPP wiki there and start using it
almost instantly.  It also has the ability to restrict who can
modify it with ACLs (although we probably don't need that, at
least initially) and the ability to download the entire contents
of a wiki in case we want to migrate away from that site at some

What would you say to creating a PSPP wiki there?

> One such higher-level problem:
> I'd like to see some kind of framework to replace q2c/command.def ---
> There should be  a single source containing the properties of a
> command. Possibly this could be an XML doc, but some special purpose
> thing could be defined.  Then we have a bunch of scripts or other
> program to take this definition file and generate:
>     * The parser, like q2c currently (sort of) does.
>     * The syntax BNF text for the manual.
>     * The brief description for the manual.
>     * Functions to fully implement command line completion.
>     * Brief usage instructions (so we can implement the INFO command).
>     and possibly:
>     * templates for GUI boxes.

Well, we can discuss that.  I think I have different ideas about
the details.  I agree that this would be something for a wiki.

> On the subject of command line completion, this leads to another
> higher level problem:
> To do command line completion properly the lexer will need to be
> written such that it inputs individual tokens rather than an entire
> line.   I remember Ben saying somewhere he wants to go the other way
> and make it input a complete command at a time.  Maybe we'd need to
> have two input streams and a re-entrant lexer.

The lexer needs to be made more flexible anyhow.
"J'avais trouv'e ma religion :
 rien ne me parut plus important qu'un livre.
 La biblioth`eque, j'y voyais un temple."
--Jean-Paul Sartre

reply via email to

[Prev in Thread] Current Thread [Next in Thread]