Regrets -- Bruce, et al, I am out of the office tomorrow. Go ahead
and try stuff in the client/ dir, then; if the changes are going to be
big, just "cvs tag" first, so we have a marker before them.
I'll be coding Thursday, in a big way. :-)
Good luck,
-K
Bruce Korb <bkorb@cruzio.com> writes:
> My proposal is to *not* do anything significant. :-)
> Instead, it is merely to isolate it so that experimentation
> becomes easy. Then, I will experiment a little bit and
> come up with a proposal. Whatever proposal would be something
> that specified the acceptable/required options to an
> option processing engine that would be driven by that
> something, rather than command name. The resulting state
> would get handed back to the implementation procedures in
> any of a myriad of ways.
>
> For the time being, this is far and away the most trivial
> to implement and use for an experimental framework:
>
> typedef struct svn_cl__opt_state_t {
> svn_string_t *xml_file;
> svn_string_t *target;
> svn_string_t *ancestor_path;
> svn_boolean_t force;
> svn_cl__command cmd;
> const char *use_text;
> } svn_cl__opt_state_t;
>
> a pointer to this struct gets added to the command descriptor.
> The option processing routine takes this ptr as an argument, instead
> of the addresses of each of the fields. It is trivial and gets me
> closer to where I want to go, even if the destination still has haze.
>
> > 3. Remaining arguments are files and dirs. Have a single function
> > that removes redundancies from this set (if you're recursing
> > into bar anyway, then mentioning bar/foo.c is pointless), and
> > passes it along to the command as the keys in a hash table.
>
> cute idea. Certainly not today, tho.
>
> > Greg Stein <gstein@lyra.org> writes:
> > > I'd suggest passing the options information to the command in
> > > a hash table. The command can simply do something like
> > > apr_hash_get(hash, "v") to get the information.
>
> > > Throw in a bit of default value handling, long/short option
> > > handling, and you're set.
>
> Yeah, easy. It's only software. But too ambitious for tonight.
>
> > > The second part would be determining what is possible for a given command
> > > and providing errors/warnings for options that don't match up properly.
>
> Right now, I'll do that just with the command code enumeration.
> The real implementation will do something better.
>
> > > On Tue, Nov 14, 2000 at 03:45:43PM -0600, Karl Fogel wrote:
> > > > Actually (I apologize if I'm just being dense, here) I'm not sure I
> > > > understand the proposal completely..
>
> Probably because it is a baby step proposal and you are looking
> for a stride instead? :)
>
> > > > I like the idea that only main() has to parse the options, and then
> > > > passes along the information postparsed to the subcommand, especially
> > > > given that so many options have a common meaning across subcommands.
> > > >
> > > > However, I don't understand the mechanism by which this is happening;
> > > > specifically, the mechanism by which main() passes the information
> > > > along. It sounds like it's at least partially genericized,
>
> Not a bit of that. The code will be essentially unchanged, except
> the main() routine will have access to the command code enumeration
> and will pass it to the arg processing routine, instead of the
> separate command procedures. This is a _very_ tiny step.
>
> > > > How are those [data] passed? Are we going to make the
> > > > subcommand procedure type variadic?
>
> One big struct.
>
> > > > As an experiment, could you try writing the log entry in advance and
> > > > posting it?
>
> Humm. This was *supposed* to be a first approximation:
>
> > > > > In preparation for ultimately doing some sort of
> > > > > table thingey for options, I want to lay some ground work
> > > > > now. To do this, I want to make a struct type that
> > > > > contains all the data currently used in the client
> > > > > options, plus the command enumeration type. Each
> > > > > command table entry would have a pointer to a struct
> > > > > of this type with just the command enumeration filled
> > > > > in. The current option processing code would be called
> > > > > from main() instead of the command procedures. The command
> > > > > procedures would receive only command arguments (the
> > > > > options stripped off). With this done, changing the
> > > > > underlying option processing should no longer perterb
> > > > > much of any other code (especially the command implementation
> > > > > procedures.)
>
> static svn_cl__cmd_desc_t cmd_table[] = {
> /* add */
> { "add", NULL, svn_cl__add, &add_cmd_opt_state },
> { "ad", "add", svn_cl__add, &add_cmd_opt_state },
> { "new", "add", svn_cl__add, &add_cmd_opt_state },
> .....[etc.]
Received on Sat Oct 21 14:36:14 2006