gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] new language, arch, furth, etc.


From: Jeremy Shaw
Subject: Re: [Gnu-arch-users] new language, arch, furth, etc.
Date: Tue, 20 Jul 2004 13:26:42 -0700
User-agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 20 Jul 2004 12:17:30 -0700 (PDT),
Tom Lord wrote:

> Here's an example.  I will give you the following programming problem
> to solve:
> 
>       Using all new code (nothing copied from arch), write a library
>         routine that reads a log file, extracts a particular header,
>         and gives back a data structure that is a "natural"
>         representation of the data it contains.
> 
>         Your program must not "know" about any specific arch headers.

This isn't just a hypothetical example either. The folks who had to
implement a tla backend to our autobuilder complain about this exact
problem. There is no spec for what headers even exist or what they
mean, how to display them, etc. So they try to write reports based on
all the new patch logs since the last build and it's a big guessing
game. Everytime they think they got it figured out, some new header
they have never seen before pops up. So then they have to good back
and add a special case to display that header in a meaningful
manner...

It would be nice if all config files included:

(1) A spec similar in principal to a DTD with detailed information
    about the specific fields, value, and types included in that
    config.

(2) Self documenting help file contents -- similar to how all emacs
    functions are (supposed to be) documented via C-h f.

(3) Formatting hints -- not really sure how this would work. If anyone
    is familiar with john hughes pretty printer stuff, that *might*
    make a good model.

The Design of a Pretty-printing Library, John Hughes
http://www.cs.chalmers.se/~rjmh/Papers/pretty.ps

    With the printing printing library you specify hints about how
    each data type should be layed out. Then a layout engine actually
    does the layout for a specific medium, such as text, html, pdf,
    etc.

    This is similar, but not quite the same as, using html+css, where
    the html specifies structure, but the css specifies layout. With
    html/css, html theorectically only specifies structure, and css
    details all the layout information.

    I think we might want something where you specify layout hints on
    a per 'data type' basis, and the layout engine uses those hints to
    intelligently render data types it has never seen before.

The above three requirements would allow you to write very powerful
tools that edit, manipulate, validate, and display config files. This
would be especially useful in the realms of making config files
sensible to new users, or writing graphical front-ends to arch.

Jeremy Shaw.





reply via email to

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