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

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

Re: [Gnu-arch-users] Re: tla update


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: tla update
Date: Sat, 13 Sep 2003 14:57:19 -0700 (PDT)

    > From: =?iso-8859-1?q?Michael_Teichgr=E4ber?= <address@hidden>

    > I have tested this by extending struct vu_handler (maybe this is no
    > good idea) to

    >     struct vu_handler
    >     {
    >       struct vu_fs_discipline * vtable;
    >       void * closure;
    >       struct {
    >         int indent;
    >         int column0;
    >       } printfmt_settings;
    >     };

    > , modifying printfmt_va_list as explained, and enclosing three
    > printfmt occurences in cmd-update.c like this:
    > 
    >   printfmt_set_indent (1 /* fd */, 0);
    >         safe_printfmt (1, "\n* reapplying local changes\n");
    >   printfmt_set_indent (1, 2);

    > With a similar function one could prepend each line of output from a
    > subcomponent with a prefix string.

Let's say it's an _interesting_ idea.

There's a pattern that crops up from time to time wherein you have
some program that wants to do just "free-form" human readable output.
At the same time, you'd like it to do machine-parsable output so that
the output is programmatically useful as a (conceptual) "return value" 
from an invocation.  (GDB is another example of a program where this
pattern crops up.)

Whenever practical, obviously, you just want really simple output
formats.  (E.g., a list of values, one per line.)  It doesn't always
work out that way, though -- as in tla (or GDB) where you wind up
wanting to "compose" outputs to form more complex outputs and so
forth.

I'm all in favor of adding a little bit of goo to the printfmt
family of functions to better structure output.   I'm not too
confident that your particular first-pass hack of adding an
indent-level to printfmt is the right design.

-t





reply via email to

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