genparse-users

Re: [Genparse-users] #mandatory directive

[<li...@mi...>]

On Wed, Oct 31, 2007 at 04:01:48PM -0500, Mike Borella wrote:
> Michael Geng wrote:
> >Hi Mike,
> >
> >now that Genparse supports a quite universal usage() function I'm
> >thinking about removing the #mandatory directive because it provides
> >no extra functionality that can't be defined in a #usage section as 
> >well. For example
> >
> >#mandatory xyz
> >
> >does the same as
> >
> >#usage_begin
> >usage: __PROGRAM_NAME__ __OPTIONS_SHORT__ xyz
> >__GLOSSARY__
> >#usage_end
> >
> >How important is the #mandatory directive to you?
> >
> >Michael
> >
> 
> I don't know how many programs use mandatory but I would suggest phasing 
> it out more slowly and/or providing a simple perl script that would 
> modify old genparse files to replace #mandatory with #usage.
> 
> I am in favor of getting rid of redundant features...to many software 
> people are afraid to and as a result software is more complex than it 
> needs to be.
> 
> Thanks,
> Mike
> 
> -- 
> Mike Borella
> http://www.borella.net/mike

So I will keep #mandatory for now but print a warning if it is used.
In the documentation I will mark it as deprecated.

Michael

[Genparse-users] #mandatory directive

[<li...@mi...>]

Hi Mike,

now that Genparse supports a quite universal usage() function I'm
thinking about removing the #mandatory directive because it provides
no extra functionality that can't be defined in a #usage section as 
well. For example

#mandatory xyz

does the same as

#usage_begin
usage: __PROGRAM_NAME__ __OPTIONS_SHORT__ xyz
__GLOSSARY__
#usage_end

How important is the #mandatory directive to you?

Michael

[Genparse-users] More integer types in Genparse

[<li...@mi...>]

Hi Mike,

presently the only integer type genparse can handle is int. I 
suggest to add a new command line switch -g / --gnulib which allows
to use the GNU Compatibility Library (Gnulib, see
http://www.gnu.org/software/gnulib/). If this switch is set then
Genparse will support the following types:

long int
unsigned long int
intmax_t  (which is defined as          long long int in Gnulib)
uintmax_t (which is defined as unsigned long long int in Gnulib)
double

Gnulib provides conversion functions for all these types. Here's an 
example Genparse file (for the tail command of the GNU Coreutils):

NONE / pid=PID	ulong	[...PID_T_MAX]	0
			"with -f, terminate after process ID, PID dies"
			__ERR_MSG__("%s: invalid PID")

And this is the generated code:

        case 258:
          if (xstrtoul (optarg, NULL, 10, &my_args->pid, NULL) != LONGINT_OK
              || my_args->pid > PID_T_MAX)
            error (EXIT_FAILURE, 0, _("%s: invalid PID"), optarg);
          break;

error () is also defined in Gnulib.

Michael

[Genparse-users] #gp_include and other extensions

[<li...@mi...>]

Hi Mike,

I want to add some more features/changes to Genparse in order to be able to
apply Genparse to the GNU coreutils:

1. A new directive #gp_include which will include other Genparse files 
   into the main Genparse files.

2. A __NEW_PRINT__ directive in the #usage section. This allows to 
   partition the help text into multiple print commands. Especially
   for translations it is more practical to have sections of not 
   more than 6-7 lines.

3. A __COMMAND__ directive in the #usage section. Can be used for 
   adding a function call to the usage section.

4. A __NL__ directive in the #usage section. Allows to break lines
   manually while automatic line breaking is on (#break_lines 
   directive).

5. A new global directive #export_long_options which adds a function
   get_long_options () which exports the long_options array used by 
   getopt_long. This is required because the GNU glibc uses it for
   printing errors.

6. Add a space before opening braces. For example write f () instead 
   of f(). The GNU coding style recommends this. I want to change this
   both in the generated and the genparse source code for consistency.

7. Add GPL preambles to all Genparse source files.

Michael

Re: [Genparse-users] Automatically breaking lines on the Genparse help screen

[Mike B. <mi...@bo...>]

No problem.

Mike

Michael Geng wrote:
> Mike,
> 
> I'm presently trying Genparse on the GNU Coreutils. They have strict tests
> and I'm having trouble to pass "make distcheck" if the time stamp alwas 
> changes. But I agree that the full header as Genparse generates it now is 
> useful and for this reason the default will be to create it the same way as 
> it was before.
> 
> Michael
> 
> On Wed, Sep 12, 2007 at 06:36:56PM -0500, Mike Borella wrote:
>> Michael,
>>
>> These options seem fine.  Any reason not to include the header info? 
>> Its not necessary but I also found it useful.  Did someone request the 
>> option to remove it?
>>
>> Michael Geng wrote:
>>> Hi Mike,
>>>
>>> I want to introduce a new global definition "#break_lines" to the Genparse 
>>> file. It takes an integer argument specifying the page width and 
>>> automatically breaks lines on the help screen to this width. E.g. 
>>> #break_lines 80 would automatically format all output printed by the 
>>> usage() function to a width of 80 characters.
>>>
>>> ====================================
>>>
>>> Additionally I would like to introduce a new command line switch
>>>
>>> s / static-headers      flag    "Keep headers of generated files static. 
>>> Don't add"
>>>                                "creation date, username, kernel version 
>>>                                etc."
>>>
>>> which removes those lines in the header of the generated parser files 
>>> which are
>>> frequently changing. Below is a Genparse header as it has been generated 
>>> up to now
>>> (and will continue to be generated if the command switch is not set):
>>>
>>> /******************************************************************************
>>> **
>>> ** mycopy4_clp.cc
>>> **
>>> ** Sun Sep  9 11:55:55 2007
>>> ** Linux 2.6.19 (#1 Sun Jan 21 11:52:23 CET 2007) i686
>>> ** linux@mgpc (Michael Geng)
>>> **
>>> ** Definition of command line parser class
>>> **
>>> ** Automatically created by genparse v0.6.9
>>> **
>>> ** See http://genparse.sourceforge.net for details and updates
>>> **
>>> ******************************************************************************/
>>>
>>> If you invoke genparse with -s or --static-headers then the complete 
>>> header would look like this:
>>>
>>> /******************************************************************************
>>> **
>>> ** mycopy4_clp.cc
>>> **
>>> ** Definition of command line parser class
>>> **
>>> ** Automatically created by genparse v0.6.9
>>> **
>>> ** See http://genparse.sourceforge.net for details and updates
>>> **
>>> ******************************************************************************/
>>>
>>> Michael
>>>
>>
>> -- 
>> Mike Borella
>> http://www.borella.net/mike
>>
> 


-- 
Mike Borella
http://www.borella.net/mike

Re: [Genparse-users] Automatically breaking lines on the Genparse help screen

[<li...@mi...>]

Mike,

I'm presently trying Genparse on the GNU Coreutils. They have strict tests
and I'm having trouble to pass "make distcheck" if the time stamp alwas 
changes. But I agree that the full header as Genparse generates it now is 
useful and for this reason the default will be to create it the same way as 
it was before.

Michael

On Wed, Sep 12, 2007 at 06:36:56PM -0500, Mike Borella wrote:
> Michael,
> 
> These options seem fine.  Any reason not to include the header info? 
> Its not necessary but I also found it useful.  Did someone request the 
> option to remove it?
> 
> Michael Geng wrote:
> >Hi Mike,
> >
> >I want to introduce a new global definition "#break_lines" to the Genparse 
> >file. It takes an integer argument specifying the page width and 
> >automatically breaks lines on the help screen to this width. E.g. 
> >#break_lines 80 would automatically format all output printed by the 
> >usage() function to a width of 80 characters.
> >
> >====================================
> >
> >Additionally I would like to introduce a new command line switch
> >
> >s / static-headers      flag    "Keep headers of generated files static. 
> >Don't add"
> >                                "creation date, username, kernel version 
> >                                etc."
> >
> >which removes those lines in the header of the generated parser files 
> >which are
> >frequently changing. Below is a Genparse header as it has been generated 
> >up to now
> >(and will continue to be generated if the command switch is not set):
> >
> >/******************************************************************************
> >**
> >** mycopy4_clp.cc
> >**
> >** Sun Sep  9 11:55:55 2007
> >** Linux 2.6.19 (#1 Sun Jan 21 11:52:23 CET 2007) i686
> >** linux@mgpc (Michael Geng)
> >**
> >** Definition of command line parser class
> >**
> >** Automatically created by genparse v0.6.9
> >**
> >** See http://genparse.sourceforge.net for details and updates
> >**
> >******************************************************************************/
> >
> >If you invoke genparse with -s or --static-headers then the complete 
> >header would look like this:
> >
> >/******************************************************************************
> >**
> >** mycopy4_clp.cc
> >**
> >** Definition of command line parser class
> >**
> >** Automatically created by genparse v0.6.9
> >**
> >** See http://genparse.sourceforge.net for details and updates
> >**
> >******************************************************************************/
> >
> >Michael
> >
> 
> 
> -- 
> Mike Borella
> http://www.borella.net/mike
> 

Re: [Genparse-users] Automatically breaking lines on the Genparse help screen

[Mike B. <mi...@bo...>]

Michael,

These options seem fine.  Any reason not to include the header info? 
Its not necessary but I also found it useful.  Did someone request the 
option to remove it?

Michael Geng wrote:
> Hi Mike,
> 
> I want to introduce a new global definition "#break_lines" to the Genparse 
> file. It takes an integer argument specifying the page width and automatically 
> breaks lines on the help screen to this width. E.g. #break_lines 80 would 
> automatically format all output printed by the usage() function to a width of 
> 80 characters.
> 
> ====================================
> 
> Additionally I would like to introduce a new command line switch
> 
> s / static-headers      flag    "Keep headers of generated files static. Don't add"
>                                 "creation date, username, kernel version etc."
> 
> which removes those lines in the header of the generated parser files which are
> frequently changing. Below is a Genparse header as it has been generated up to now
> (and will continue to be generated if the command switch is not set):
> 
> /******************************************************************************
> **
> ** mycopy4_clp.cc
> **
> ** Sun Sep  9 11:55:55 2007
> ** Linux 2.6.19 (#1 Sun Jan 21 11:52:23 CET 2007) i686
> ** linux@mgpc (Michael Geng)
> **
> ** Definition of command line parser class
> **
> ** Automatically created by genparse v0.6.9
> **
> ** See http://genparse.sourceforge.net for details and updates
> **
> ******************************************************************************/
> 
> If you invoke genparse with -s or --static-headers then the complete header 
> would look like this:
> 
> /******************************************************************************
> **
> ** mycopy4_clp.cc
> **
> ** Definition of command line parser class
> **
> ** Automatically created by genparse v0.6.9
> **
> ** See http://genparse.sourceforge.net for details and updates
> **
> ******************************************************************************/
> 
> Michael
> 


-- 
Mike Borella
http://www.borella.net/mike

[Genparse-users] Automatically breaking lines on the Genparse help screen

[<li...@mi...>]

Hi Mike,

I want to introduce a new global definition "#break_lines" to the Genparse 
file. It takes an integer argument specifying the page width and automatically 
breaks lines on the help screen to this width. E.g. #break_lines 80 would 
automatically format all output printed by the usage() function to a width of 
80 characters.

====================================

Additionally I would like to introduce a new command line switch

s / static-headers      flag    "Keep headers of generated files static. Don't add"
                                "creation date, username, kernel version etc."

which removes those lines in the header of the generated parser files which are
frequently changing. Below is a Genparse header as it has been generated up to now
(and will continue to be generated if the command switch is not set):

/******************************************************************************
**
** mycopy4_clp.cc
**
** Sun Sep  9 11:55:55 2007
** Linux 2.6.19 (#1 Sun Jan 21 11:52:23 CET 2007) i686
** linux@mgpc (Michael Geng)
**
** Definition of command line parser class
**
** Automatically created by genparse v0.6.9
**
** See http://genparse.sourceforge.net for details and updates
**
******************************************************************************/

If you invoke genparse with -s or --static-headers then the complete header 
would look like this:

/******************************************************************************
**
** mycopy4_clp.cc
**
** Definition of command line parser class
**
** Automatically created by genparse v0.6.9
**
** See http://genparse.sourceforge.net for details and updates
**
******************************************************************************/

Michael

Re: [Genparse-users] [PATCH] Command line parsing of ls with genparse

[<li...@mi...>]

On Tue, Aug 28, 2007 at 09:08:51PM -0600, Eric Blake wrote:
> According to Michael Geng on 8/28/2007 12:33 PM:
> > 
> > In the present version of genparse new strings are always printed
> > in new lines. For example (also from the ls commmand):
> > 
> > d / directory			flag	"list directory entries instead of contents,"
> > 					"  and do not dereference symbolic links"
> 
> Why not make genparse a bit smarter, and let the user supply free-form
> text as the option description.  Genparse should then wrap it to fit an
> 80-column screen before generating the resulting usage() in the .c file.
> Then the above example would simply be:
> 
> d / directory	flag \
> "list directory entries instead of contents, and do not dereference
> symbolic links"
> 
> with the __GNU_GLOSSARY__(29) being the formatting hint of where the
> auto-wrapping should occur in the output English text.

I think that's a good idea. How about adding a --linebreak[=width] command 
line switch to genparse which enables breaking lines on the help screen 
automatically to the specified width or 80 columns if --linebreak is given
without argument?

Michael

Re: [Genparse-users] Multiple global functions?

[<li...@mi...>]

On Mon, Aug 27, 2007 at 11:05:14AM -0500, Mike Borella wrote:
> I don't think there was any rationale for the single global callback 
> function except that it kept things simple at first.  Now that the 
> program is much more sophisticated, I think that multiple callbacks 
> would be fine.
> 
> The #exit directive seems useful as well.
> 
> Thanks,
> Mike
> 
> Michael Geng wrote:
> >Hi Mike,
> >
> >In the genparse info file in the description of the global functions I 
> >found:
> >"Only 1 global callback function is allowed." In the example in the info 
> >pages
> >I found "There may be more than one global callback - all will be called 
> >in the parser function."
> >
> >I do not remember if I was the one who wrote that only 1 global callback 
> >function is allowed - but that's how I always thought about it. Is there a 
> >reason for more than 1 global callback function? The user can program what
> >he wants in that callback function, he can of course also call other 
> >functions from there if he likes.
> >
> >----------------------
> >
> >Another topic: I'm proposing to add an #exit_value macro to the list of
> >possible global definitions in the genparse file. For example
> >
> >#exit_value -2
> >
> >in case of a failure the generated parser would then call exit(-2). 
> >
> >Or with
> >
> >#exit_value MY_EXIT_CODE
> >
> >the program would call exit(MY_EXIT_CODE) which makes sense if MY_EXIT_CODE
> >is defined in one of the include files.
> >
> >Michael
> >
> 
> 
> -- 
> Mike Borella
> http://www.borella.net/mike

Hi Mike,

no, I don't want to add the possibility to have multiple global callback 
functions now, it's just the opposite: I want to keep genparse simple and
allow only 1 global callback because I don't see a requirement for more. 
I'm interpreting your answer such that you don't care much about it :-)

Michael

Re: [Genparse-users] Multiple global functions?

[Mike B. <mi...@bo...>]

I don't think there was any rationale for the single global callback 
function except that it kept things simple at first.  Now that the 
program is much more sophisticated, I think that multiple callbacks 
would be fine.

The #exit directive seems useful as well.

Thanks,
Mike

Michael Geng wrote:
> Hi Mike,
> 
> In the genparse info file in the description of the global functions I found:
> "Only 1 global callback function is allowed." In the example in the info pages
> I found "There may be more than one global callback - all will be called in 
> the parser function."
> 
> I do not remember if I was the one who wrote that only 1 global callback 
> function is allowed - but that's how I always thought about it. Is there a 
> reason for more than 1 global callback function? The user can program what
> he wants in that callback function, he can of course also call other 
> functions from there if he likes.
> 
> ----------------------
> 
> Another topic: I'm proposing to add an #exit_value macro to the list of
> possible global definitions in the genparse file. For example
> 
> #exit_value -2
> 
> in case of a failure the generated parser would then call exit(-2). 
> 
> Or with
> 
> #exit_value MY_EXIT_CODE
> 
> the program would call exit(MY_EXIT_CODE) which makes sense if MY_EXIT_CODE
> is defined in one of the include files.
> 
> Michael
> 


-- 
Mike Borella
http://www.borella.net/mike

[Genparse-users] Multiple global functions?

[<li...@mi...>]

Hi Mike,

In the genparse info file in the description of the global functions I found:
"Only 1 global callback function is allowed." In the example in the info pages
I found "There may be more than one global callback - all will be called in 
the parser function."

I do not remember if I was the one who wrote that only 1 global callback 
function is allowed - but that's how I always thought about it. Is there a 
reason for more than 1 global callback function? The user can program what
he wants in that callback function, he can of course also call other 
functions from there if he likes.

----------------------

Another topic: I'm proposing to add an #exit_value macro to the list of
possible global definitions in the genparse file. For example

#exit_value -2

in case of a failure the generated parser would then call exit(-2). 

Or with

#exit_value MY_EXIT_CODE

the program would call exit(MY_EXIT_CODE) which makes sense if MY_EXIT_CODE
is defined in one of the include files.

Michael

Re: [Genparse-users] Optional arguments

[<li...@mi...>]

On Sun, Jul 29, 2007 at 09:32:09AM -0500, Mike Borella wrote:
> Michael Geng wrote:
> >Hi Mike,
> >
> >I think one of the most obvious missing features of Genparse is that
> >it doesn't yet support optional arguments. getopt_long supports
> >optional arguments however.
> >
> >I want to implement it by allowing an optional * both after the
> >short and the long option. 
> >
> >Examples:
> >
> >o* / oparam*	string	"Both short and long option have an optional 
> >argument."
> >p* / pparam	string	"Short option has an optional argument,"
> >                        "long option requires an argument."
> >q / qparam*	string	"Short option reqires an argument,"
> >                        "long option has an optional argument."
> >
> >Michael
> >
> 
> Does this mean that these arguments could be both flag as well as 
> parameterized?

That's a good point. For indicating if the option was specified at
all I don't see another solution than adding a flag to every optional
argument in the arg_t struct. So the above example will lead to the 
following arg_t struct:

struct arg_t
{
  char * o;
  bool o_flag;
  char * p;
  bool p_flag;
  char * q;
  bool q_flag;
};

Everything will stay compatible however because only optional arguments
require both value and flag so the implementations for mandatory arguments
or arguments with an explicit flag type will not be changed.

Michael

Re: [Genparse-users] Optional arguments

[Mike B. <mi...@bo...>]

Michael Geng wrote:
> Hi Mike,
> 
> I think one of the most obvious missing features of Genparse is that
> it doesn't yet support optional arguments. getopt_long supports
> optional arguments however.
> 
> I want to implement it by allowing an optional * both after the
> short and the long option. 
> 
> Examples:
> 
> o* / oparam*	string	"Both short and long option have an optional argument."
> p* / pparam	string	"Short option has an optional argument,"
>                         "long option requires an argument."
> q / qparam*	string	"Short option reqires an argument,"
>                         "long option has an optional argument."
> 
> Michael
> 

Does this mean that these arguments could be both flag as well as 
parameterized?

-- 
Mike Borella
http://www.borella.net/mike

[Genparse-users] Optional arguments

[<li...@mi...>]

Hi Mike,

I think one of the most obvious missing features of Genparse is that
it doesn't yet support optional arguments. getopt_long supports
optional arguments however.

I want to implement it by allowing an optional * both after the
short and the long option. 

Examples:

o* / oparam*	string	"Both short and long option have an optional argument."
p* / pparam	string	"Short option has an optional argument,"
                        "long option requires an argument."
q / qparam*	string	"Short option reqires an argument,"
                        "long option has an optional argument."

Michael

Re: [Genparse-users] More changes on the usage() function

[<li...@mi...>]

On Mon, Jul 09, 2007 at 05:01:05PM -0500, Mike Borella wrote:
> Does this mean that you can't define your own -i option?
> 
> Mike

I'm afraid you are confusing the Genparse file of Genparse itself 
and the Genparse file of the program for which you want to write a 
command line parser.

I'm proposing to add the following line to the Genparse file for
Genparse:

i / internationalize	flag	"Put internationalization macro _() around text output."

If you invoke Genparse with the -i or --internationalize option
then it will add the internationalization macro _() around output
text like the help text in the usage() function. 

But of course you can still have a -i option in the Genparse file
for the program for which you want to generate a command line parser.

Do you understand or did I completely confuse you now? Do you know
about internationalization using the GNU gettext command? 

Michael

> Michael Geng wrote:
> >On Sun, Jul 08, 2007 at 02:48:02PM -0500, Mike Borella wrote:
> >>Michael,
> >>
> >>I like passing the status to the usage() function.  However I was a 
> >>little confused with the -i option especially since the example already 
> >>uses the -i option.  Would that have to change?
> >
> >The Genparse file below is from the mycopy3 example. Genparse itself 
> >doesn't yet have a -i option, so there's no conflict.
> >
> >Michael
> >
> >>Michael Geng wrote:
> >>>Hi Mike,
> >>>
> >>>this is the usage() function of the mycopy3 example as it is now:
> >>>
> >>>void usage(char *executable)
> >>>{
> >>> printf("\
> >>>usage: %s [ -iohv ] file\n\
> >>>  [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
> >>>         Number of times to output <file>.\n\
> >>>         File should be text format!\n\
> >>>  [ -o ] [ --outfile ] (type=STRING)\n\
> >>>         Output file.\n\
> >>>  [ -h ] [ --help ] (type=FLAG)\n\
> >>>         Display help information.\n\
> >>>  [ -v ] [ --version ] (type=FLAG)\n\
> >>>         Output version.\n", executable);
> >>>
> >>> exit(1);
> >>>}
> >>>
> >>>I propose to change it like this:
> >>>
> >>>void usage(int status, char *executable)
> >>>{
> >>> if (status != EXIT_SUCCESS)
> >>>   fprintf(stderr, "Try `%s --help' for more information.\n",
> >>>           executable);
> >>> else
> >>>   {
> >>>     printf("\
> >>>usage: %s [ -iohv ] file\n\
> >>>  [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
> >>>         Number of times to output <file>.\n\
> >>>         File should be text format!\n\
> >>>  [ -o ] [ --outfile ] (type=STRING)\n\
> >>>         Output file.\n\
> >>>  [ -h ] [ --help ] (type=FLAG)\n\
> >>>         Display help information.\n\
> >>>  [ -v ] [ --version ] (type=FLAG)\n\
> >>>         Output version.\n", executable);
> >>>   }
> >>> exit(status);
> >>>}
> >>>
> >>>Another proposal is to add a new command line switch 
> >>>-i / --internationalization and put the internationalization 
> >>>macro _() around strings in the usage() function. Invoking
> >>>Genparse with -i set would result in the following usage()
> >>>function:
> >>>
> >>>void usage(int status, char *executable)
> >>>{
> >>> if (status != EXIT_SUCCESS)
> >>>   fprintf(stderr, _("Try `%s --help' for more information.\n"),
> >>>           executable);
> >>> else
> >>>   {
> >>>     printf(_("\
> >>>usage: %s [ -iohv ] file\n\
> >>>  [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
> >>>         Number of times to output <file>.\n\
> >>>         File should be text format!\n\
> >>>  [ -o ] [ --outfile ] (type=STRING)\n\
> >>>         Output file.\n\
> >>>  [ -h ] [ --help ] (type=FLAG)\n\
> >>>         Display help information.\n\
> >>>  [ -v ] [ --version ] (type=FLAG)\n\
> >>>         Output version.\n"), executable);
> >>>   }
> >>> exit(status);
> >>>}
> >>>
> >>>Michael
> >>>
> >>
> >>-- 
> >>Mike Borella
> >>mike at borella dot net
> >>http://www.borella.net/mike
> >>
> >
> 
> 
> -- 
> Mike Borella
> mike at borella dot net
> http://www.borella.net/mike
> 

Re: [Genparse-users] More changes on the usage() function

[<li...@mi...>]

On Sun, Jul 08, 2007 at 02:48:02PM -0500, Mike Borella wrote:
> Michael,
> 
> I like passing the status to the usage() function.  However I was a 
> little confused with the -i option especially since the example already 
> uses the -i option.  Would that have to change?

The Genparse file below is from the mycopy3 example. Genparse itself 
doesn't yet have a -i option, so there's no conflict.

Michael

> Michael Geng wrote:
> >Hi Mike,
> >
> >this is the usage() function of the mycopy3 example as it is now:
> >
> >void usage(char *executable)
> >{
> >  printf("\
> >usage: %s [ -iohv ] file\n\
> >   [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
> >          Number of times to output <file>.\n\
> >          File should be text format!\n\
> >   [ -o ] [ --outfile ] (type=STRING)\n\
> >          Output file.\n\
> >   [ -h ] [ --help ] (type=FLAG)\n\
> >          Display help information.\n\
> >   [ -v ] [ --version ] (type=FLAG)\n\
> >          Output version.\n", executable);
> >
> >  exit(1);
> >}
> >
> >I propose to change it like this:
> >
> >void usage(int status, char *executable)
> >{
> >  if (status != EXIT_SUCCESS)
> >    fprintf(stderr, "Try `%s --help' for more information.\n",
> >            executable);
> >  else
> >    {
> >      printf("\
> >usage: %s [ -iohv ] file\n\
> >   [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
> >          Number of times to output <file>.\n\
> >          File should be text format!\n\
> >   [ -o ] [ --outfile ] (type=STRING)\n\
> >          Output file.\n\
> >   [ -h ] [ --help ] (type=FLAG)\n\
> >          Display help information.\n\
> >   [ -v ] [ --version ] (type=FLAG)\n\
> >          Output version.\n", executable);
> >    }
> >  exit(status);
> >}
> >
> >Another proposal is to add a new command line switch 
> >-i / --internationalization and put the internationalization 
> >macro _() around strings in the usage() function. Invoking
> >Genparse with -i set would result in the following usage()
> >function:
> >
> >void usage(int status, char *executable)
> >{
> >  if (status != EXIT_SUCCESS)
> >    fprintf(stderr, _("Try `%s --help' for more information.\n"),
> >            executable);
> >  else
> >    {
> >      printf(_("\
> >usage: %s [ -iohv ] file\n\
> >   [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
> >          Number of times to output <file>.\n\
> >          File should be text format!\n\
> >   [ -o ] [ --outfile ] (type=STRING)\n\
> >          Output file.\n\
> >   [ -h ] [ --help ] (type=FLAG)\n\
> >          Display help information.\n\
> >   [ -v ] [ --version ] (type=FLAG)\n\
> >          Output version.\n"), executable);
> >    }
> >  exit(status);
> >}
> >
> >Michael
> >
> 
> 
> -- 
> Mike Borella
> mike at borella dot net
> http://www.borella.net/mike
> 

Re: [Genparse-users] Descriptive name for long options

[Mike B. <mi...@bo...>]

Very cool.  Looks good to me.

Mike

Michael Geng wrote:
> Hi Mike,
> 
> the ls command has a parameter --block-size. If you invoke 
> ls --help you see the following description:
> 
> ...
>       --block-size=SIZE      use SIZE-byte blocks
> ...
> 
> I want to make it possible to add such an optional designation 
> like "=SIZE" in the ls example above after a long option in the 
> Genparse file which can then be referred to in the following 
> descriptive text on the help screen.
> 
> In the genparse file the following would be allowed:
> 
> NONE / block-size=SIZE		int	"use SIZE-byte blocks"
> 
> The corresponding line in the genparse style help screen would 
> look like this
> 
>    [ --block-size=SIZE ] (type=INTEGER)
>           use SIZE-byte blocks
> 
> This optional descriptive name could be stored in a new string 
> _opt_name to the Clparam struct. It would only be used in the
> usage() function, nowhere else. And everything stays compatible
> because giving an opt_name string in the Genparse file is of 
> course optional.
> 
> Michael
> 


-- 
Mike Borella
mike at borella dot net
http://www.borella.net/mike

Re: [Genparse-users] More changes on the usage() function

[Mike B. <mi...@bo...>]

Michael,

I like passing the status to the usage() function.  However I was a 
little confused with the -i option especially since the example already 
uses the -i option.  Would that have to change?

Thanks,
Mike

Michael Geng wrote:
> Hi Mike,
> 
> this is the usage() function of the mycopy3 example as it is now:
> 
> void usage(char *executable)
> {
>   printf("\
> usage: %s [ -iohv ] file\n\
>    [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
>           Number of times to output <file>.\n\
>           File should be text format!\n\
>    [ -o ] [ --outfile ] (type=STRING)\n\
>           Output file.\n\
>    [ -h ] [ --help ] (type=FLAG)\n\
>           Display help information.\n\
>    [ -v ] [ --version ] (type=FLAG)\n\
>           Output version.\n", executable);
> 
>   exit(1);
> }
> 
> I propose to change it like this:
> 
> void usage(int status, char *executable)
> {
>   if (status != EXIT_SUCCESS)
>     fprintf(stderr, "Try `%s --help' for more information.\n",
>             executable);
>   else
>     {
>       printf("\
> usage: %s [ -iohv ] file\n\
>    [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
>           Number of times to output <file>.\n\
>           File should be text format!\n\
>    [ -o ] [ --outfile ] (type=STRING)\n\
>           Output file.\n\
>    [ -h ] [ --help ] (type=FLAG)\n\
>           Display help information.\n\
>    [ -v ] [ --version ] (type=FLAG)\n\
>           Output version.\n", executable);
>     }
>   exit(status);
> }
> 
> Another proposal is to add a new command line switch 
> -i / --internationalization and put the internationalization 
> macro _() around strings in the usage() function. Invoking
> Genparse with -i set would result in the following usage()
> function:
> 
> void usage(int status, char *executable)
> {
>   if (status != EXIT_SUCCESS)
>     fprintf(stderr, _("Try `%s --help' for more information.\n"),
>             executable);
>   else
>     {
>       printf(_("\
> usage: %s [ -iohv ] file\n\
>    [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
>           Number of times to output <file>.\n\
>           File should be text format!\n\
>    [ -o ] [ --outfile ] (type=STRING)\n\
>           Output file.\n\
>    [ -h ] [ --help ] (type=FLAG)\n\
>           Display help information.\n\
>    [ -v ] [ --version ] (type=FLAG)\n\
>           Output version.\n"), executable);
>     }
>   exit(status);
> }
> 
> Michael
> 


-- 
Mike Borella
mike at borella dot net
http://www.borella.net/mike

[Genparse-users] More changes on the usage() function

[<li...@mi...>]

Hi Mike,

this is the usage() function of the mycopy3 example as it is now:

void usage(char *executable)
{
  printf("\
usage: %s [ -iohv ] file\n\
   [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
          Number of times to output <file>.\n\
          File should be text format!\n\
   [ -o ] [ --outfile ] (type=STRING)\n\
          Output file.\n\
   [ -h ] [ --help ] (type=FLAG)\n\
          Display help information.\n\
   [ -v ] [ --version ] (type=FLAG)\n\
          Output version.\n", executable);

  exit(1);
}

I propose to change it like this:

void usage(int status, char *executable)
{
  if (status != EXIT_SUCCESS)
    fprintf(stderr, "Try `%s --help' for more information.\n",
            executable);
  else
    {
      printf("\
usage: %s [ -iohv ] file\n\
   [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
          Number of times to output <file>.\n\
          File should be text format!\n\
   [ -o ] [ --outfile ] (type=STRING)\n\
          Output file.\n\
   [ -h ] [ --help ] (type=FLAG)\n\
          Display help information.\n\
   [ -v ] [ --version ] (type=FLAG)\n\
          Output version.\n", executable);
    }
  exit(status);
}

Another proposal is to add a new command line switch 
-i / --internationalization and put the internationalization 
macro _() around strings in the usage() function. Invoking
Genparse with -i set would result in the following usage()
function:

void usage(int status, char *executable)
{
  if (status != EXIT_SUCCESS)
    fprintf(stderr, _("Try `%s --help' for more information.\n"),
            executable);
  else
    {
      printf(_("\
usage: %s [ -iohv ] file\n\
   [ -i ] [ --iterations ] (type=INTEGER, range=0..., default=1)\n\
          Number of times to output <file>.\n\
          File should be text format!\n\
   [ -o ] [ --outfile ] (type=STRING)\n\
          Output file.\n\
   [ -h ] [ --help ] (type=FLAG)\n\
          Display help information.\n\
   [ -v ] [ --version ] (type=FLAG)\n\
          Output version.\n"), executable);
    }
  exit(status);
}

Michael

[Genparse-users] Descriptive name for long options

[<li...@mi...>]

Hi Mike,

the ls command has a parameter --block-size. If you invoke 
ls --help you see the following description:

...
      --block-size=SIZE      use SIZE-byte blocks
...

I want to make it possible to add such an optional designation 
like "=SIZE" in the ls example above after a long option in the 
Genparse file which can then be referred to in the following 
descriptive text on the help screen.

In the genparse file the following would be allowed:

NONE / block-size=SIZE		int	"use SIZE-byte blocks"

The corresponding line in the genparse style help screen would 
look like this

   [ --block-size=SIZE ] (type=INTEGER)
          use SIZE-byte blocks

This optional descriptive name could be stored in a new string 
_opt_name to the Clparam struct. It would only be used in the
usage() function, nowhere else. And everything stays compatible
because giving an opt_name string in the Genparse file is of 
course optional.

Michael

Re: [Genparse-users] Simplifying command line parsing with Genparse

[<li...@mi...>]

On Sat, Jun 16, 2007 at 07:23:09PM +0200, Michael Geng wrote:
> On Thu, Jun 07, 2007 at 02:44:38PM +0200, Jim Meyering wrote:
> > However, before I even consider it seriously, it'll need
> > some improvements:
> > 
> >   - it must detect any and all write failures[*]
> 
> I just added a new release of genparse 
> (http://sourceforge.net/project/showfiles.php?group_id=4341&package_id=4354&release_id=516584)
> which now also checks file write and close operations, not only
> file open operations as it was before.
> 
> >   - packaging so that I can run ./configure && make && make check, and
> >       if I don't happen to have cppunit infrastructure, gcj or something
> >       similar, it should tell me about it directly, rather than causing
> >       harder-to-diagnose build failures.
> 
> I went through all these tools and updated configure.ac (and related files)
> such that you get a warning if something is missing but you can still
> compile genparse. For example if you don't have gcj installed then it 
> automatically removes the java example from the list of build targets.
> It now checks for cunit, cppunit, junit, gcj, doxygen, texi2html, texi2pdf 
> and man2html.
> 
> >   - one of the generated .c files I looked at calls strdup but doesn't
> >       check for a NULL return value or (less important) attempt to avoid
> >       the leak when the corresponding --backup=S option appears twice or more.
> 
> I'm working on that and I'll let you know when this is finished.

I again released a new version of genparse (0.6.5) which doesn't allocate
any memory on the heap any more because I think this is a better concept.
So it doesn't generate any calls to strdup() or malloc() any more. As a
consequence the parser function changed from 

struct arg_t *Cmdline(int argc, char *argv[]) 

to

void Cmdline(struct arg_t *my_args, int argc, char *argv[]). 

See the Genparse examples page (http://genparse.sourceforge.net/examples.html) 
which is also updated.

> 
> >   - not exactly essential, but highly recommended: it should work
> >       with the latest autoconf and automake
> 
> I'm using autoconf version 2.59 and automake 1.9.5. Aditionally I renamed 
> configure.in to configure.ac which appears to be the standard today and 
> removed acconfig.h because it appears to be deprecated. This might have
> produced some warnings before. 
> 
> > [*] with genparse-0.6.3, I get this:
> > 
> >   $ strace -o log -e write ./genparse -o /full/tmp/foo ../examples/ls.gp \
> >     && echo exit status 0
> >   creating /full/tmp/foo.h...done
> >   creating /full/tmp/foo.c...done
> >   exit status 0
> >   $ tail -2 log
> >   write(3, "/*******************************"..., 80) = -1 ENOSPC (No space left on device)
> >   write(1, "creating /full/tmp/foo.c...done\n", 32) = 32
> > 
> > The two files it claims to have created are both empty,
> > and genparse exited successfully.
> > This means genparse is not detecting write or close failures.
> > 
> > Note that in the example above, /full/tmp is a full file system that still
> > has free inodes, so open can create new files, but writes always fail.
> 
> I could verify this behavior and I hope it's fixed now. Now it tells you
> that it can't write to the file and returns with a non zero exit status.
> 
> Thanks again for your input,
> Michael
> 
> 
> _______________________________________________
> Bug-coreutils mailing list
> Bug...@gn...
> http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [Genparse-users] Simplifying command line parsing with Genparse

[<li...@mi...>]

On Thu, Jun 07, 2007 at 02:44:38PM +0200, Jim Meyering wrote:
> However, before I even consider it seriously, it'll need
> some improvements:
> 
>   - it must detect any and all write failures[*]

I just added a new release of genparse 
(http://sourceforge.net/project/showfiles.php?group_id=4341&package_id=4354&release_id=516584)
which now also checks file write and close operations, not only
file open operations as it was before.

>   - packaging so that I can run ./configure && make && make check, and
>       if I don't happen to have cppunit infrastructure, gcj or something
>       similar, it should tell me about it directly, rather than causing
>       harder-to-diagnose build failures.

I went through all these tools and updated configure.ac (and related files)
such that you get a warning if something is missing but you can still
compile genparse. For example if you don't have gcj installed then it 
automatically removes the java example from the list of build targets.
It now checks for cunit, cppunit, junit, gcj, doxygen, texi2html, texi2pdf 
and man2html.

>   - one of the generated .c files I looked at calls strdup but doesn't
>       check for a NULL return value or (less important) attempt to avoid
>       the leak when the corresponding --backup=S option appears twice or more.

I'm working on that and I'll let you know when this is finished.

>   - not exactly essential, but highly recommended: it should work
>       with the latest autoconf and automake

I'm using autoconf version 2.59 and automake 1.9.5. Aditionally I renamed 
configure.in to configure.ac which appears to be the standard today and 
removed acconfig.h because it appears to be deprecated. This might have
produced some warnings before. 

> [*] with genparse-0.6.3, I get this:
> 
>   $ strace -o log -e write ./genparse -o /full/tmp/foo ../examples/ls.gp \
>     && echo exit status 0
>   creating /full/tmp/foo.h...done
>   creating /full/tmp/foo.c...done
>   exit status 0
>   $ tail -2 log
>   write(3, "/*******************************"..., 80) = -1 ENOSPC (No space left on device)
>   write(1, "creating /full/tmp/foo.c...done\n", 32) = 32
> 
> The two files it claims to have created are both empty,
> and genparse exited successfully.
> This means genparse is not detecting write or close failures.
> 
> Note that in the example above, /full/tmp is a full file system that still
> has free inodes, so open can create new files, but writes always fail.

I could verify this behavior and I hope it's fixed now. Now it tells you
that it can't write to the file and returns with a non zero exit status.

Thanks again for your input,
Michael

Re: [Genparse-users] Simplifying command line parsing with Genparse

[<li...@mi...>]

On Mon, Jun 11, 2007 at 06:01:51PM -0500, Mike Borella wrote:
> Michael,
> 
> Thanks for the note.  If I understand correctly, you are changing the 
> generated code so that is does not allocate any memory.  This is a good 
> technique that I have actually required of my vendors from time to time. 
>  It certainly helps with the debugging.

One more argument for doing this change is that then the C code will be
closer to the C++ code because the C++ code doesn't allocate any memory 
right now. 

> I'm a bit embarrassed that I never thought of this 7 years ago :)
> 
> Will the user of genparse now have to allocate memory before calling the 
> genparse functions?  If so we should document that very clearly.

I absolutely agree. I plan to look through the man and info pages and I 
will have to regenerate the C examples. 

My question is: Do we really have to support both solutions (the existing
one which allocates memory) and the new one (which doesn't allocate any 
memory)? The problem with throwing away the old solution is that this would
break compatibility. How popular is Genparse today? Can we still afford to 
make incompatible changes? Will it be a problem for you personally, Mike? 
The big advantage of dropping the old memory allocating solution is simplicity.
The code will become simpler and we avoid adding one more command line option
to Genparse. I would vote for dropping the old solution and not confuse any
users with 2 different implementations for the C output.

Michael

Re: [Genparse-users] Simplifying command line parsing with Genparse

[Mike B. <mi...@bo...>]

Michael,

Thanks for the note.  If I understand correctly, you are changing the 
generated code so that is does not allocate any memory.  This is a good 
technique that I have actually required of my vendors from time to time. 
  It certainly helps with the debugging.

I'm a bit embarrassed that I never thought of this 7 years ago :)

Will the user of genparse now have to allocate memory before calling the 
genparse functions?  If so we should document that very clearly.

Thanks,
Mike

Michael Geng wrote:
> Hi Mike,
> 
> I suggested to use Genparse for command line parsing in the 
> GNU Coreutils. I very quickly got a reply from Jim Meyering
> from the Coreutils team. See 
> http://lists.gnu.org/archive/html/bug-coreutils/2007-06/msg00035.html 
> for the thread on the Coreutils mailing list. I don't think
> it is appropriate to post all the Genparse problems to the Coreutils
> mailing list. But I'm posting to the "genparse-users" mailing list 
> in order to make it available to a broader audience. 
> 
> In this email I'm focusing on only 1 of Jim's concerns. See
> my comments below.
> 
> On Thu, Jun 07, 2007 at 02:44:38PM +0200, Jim Meyering wrote:
>> li...@mi... (Michael Geng) wrote:
>>> would it be an option to use Genparse (http://genparse.sourceforge.net/)
>>> for command line parsing in the GNU Coreutils?
>>>
>>> I'm one of the developers of Genparse and I recently used some of the
>>> well known Coreutils as an exercise for testing Genparse (see
>>> http://genparse.sourceforge.net/examples.html). Using Genparse for
>>> generating the command line parsing code could reduce the amount of
>>> coreutils source code because the input to Genparse is a short config
>>> file only. The overhead of writing the parser code would be delegated
>>> to the tool then.
>>>
>>> The Genparse generated parsers call getopt() (or getopt_long()) exactly
>>> the same way the Coreutils's command line parsers do it today. This
>>> wouldn't be changed. So the code Genparse generates will be very similar
>>> to the existing hand written parsers of the individual Coreutils tools.
>>> But calling getopt() is only part of the work, preparing and evaluating
>>> the results of getopt() also causes coding work which could be delegated
>>> to Genparse. Genparse also automatically generates a help screen which
>>> would no longer have to be done manually.
>> Hi Michael,
>>
>> Genparse looks promising.
>> I like the examples.  But there are almost 100 programs in the
>> coreutils.  If genparse can really handle all of those use cases
>> without causing any significant degradation in the tools, then
>> it will be hard to object.
>>
>> How does it deal with internationalization?
>>
>> However, before I even consider it seriously, it'll need
>> some improvements:
>>
>>   - it must detect any and all write failures[*]
>>   - packaging so that I can run ./configure && make && make check, and
>>       if I don't happen to have cppunit infrastructure, gcj or something
>>       similar, it should tell me about it directly, rather than causing
>>       harder-to-diagnose build failures.
>>   - one of the generated .c files I looked at calls strdup but doesn't
>>       check for a NULL return value or (less important) attempt to avoid
>>       the leak when the corresponding --backup=S option appears twice or more.
> 
> I guess Jim looked into the mv example 
> (http://genparse.sourceforge.net/examples/mv_clp.c). 
> 
> I propose not to allocate any memory dynamically in Genparse at all and use 
> the stack instead. malloc() and strdup() might not be fast enough in all 
> applications. For instance in the mv command I can hardly imagine that it 
> is acceptable to have a call to malloc() for allocating the arg_t struct 
> which would have to be executed with every call to mv no matter what 
> command line switches or arguments were specified. By the way, the result
> of this call to malloc() is also not checked for failure.
> 
> In principle the Coreutils implementation of the mv command does it
> similarly: The optind pointer which is returned by getopt_long() is first 
> stored in a variable on the heap and later the content of the string is
> copied to a string with strdup() which allocates from the heap. In order 
> to leave the freedom to do so to the user of Genparse it is required that 
> Genparse uses only the stack.
> 
>>   - not exactly essential, but highly recommended: it should work
>>       with the latest autoconf and automake
>>
>>
>> [*] with genparse-0.6.3, I get this:
>>
>>   $ strace -o log -e write ./genparse -o /full/tmp/foo ../examples/ls.gp \
>>     && echo exit status 0
>>   creating /full/tmp/foo.h...done
>>   creating /full/tmp/foo.c...done
>>   exit status 0
>>   $ tail -2 log
>>   write(3, "/*******************************"..., 80) = -1 ENOSPC (No space left on device)
>>   write(1, "creating /full/tmp/foo.c...done\n", 32) = 32
>>
>> The two files it claims to have created are both empty,
>> and genparse exited successfully.
>> This means genparse is not detecting write or close failures.
>>
>> Note that in the example above, /full/tmp is a full file system that still
>> has free inodes, so open can create new files, but writes always fail.
>>
>>
>> _______________________________________________
>> Bug-coreutils mailing list
>> Bug...@gn...
>> http://lists.gnu.org/mailman/listinfo/bug-coreutils
> 


-- 
Mike Borella
mike at borella dot net
http://www.borella.net/mike