[Caml-list] complications with Arg.parse_argv

[Caml-list] complications with Arg.parse_argv

[Kenneth Adam Miller]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

So, I'm using a library that calls Arg.parse to build up it's inputs in
another data structure. I don't want to rewrite any code, and I'm consuming
the library in a different way than how the binary consumes it, which is
just to feed it input from the command line.

Not wanting to replicate code in two locations, I chose to use
Arg.parse_argv, and supplied it with an array that would normally be on the
command line. For some reason, supplying the exact same speclist as what
was used in the original statement that works as a command line tool
doesn't result in the parameters being parsed.

command line tool:
Arg.parse speclist anon usage;
get_program () (* consumes the mutable list that speclist modified *)

(* speclist modifies a mutable list used to hold arguments *)

my code that consumes speclist as a library:

Arg.parse_argv custom_arguments speclist anon usage
get_program () (* exact same function as above, exact same variables to
Arg.parse* *)

For some reason, Arg.parse_argv seems to complete, but when get_program
proceeds, it sees the mutable argument list as being empty. Why?

[-- Attachment #2: Type: text/html, Size: 1324 bytes --]

Re: [Caml-list] complications with Arg.parse_argv

[Gabriel Scherer]

Looking at the parse_argv documentation (man Arg), I see two possible reasons:
- Arg expects the passed string array to start with the name of the
program at index 0; does your custom_arguments array follow this
convention?
- parse_argv takes an (optional) integer reference ~current that tells
it where to start parsing the argument array; by default, it points to
a global mutable reference Arg.current (so that several calls in a row
start on the next element); if your library has used Arg.parse itself
before, Arg.current may be set too far. You should try passing
~current:(ref 0) to make sure you only use local state.

On Mon, Nov 24, 2014 at 6:42 PM, Kenneth Adam Miller
<kennethadammiller@gmail.com> wrote:
> So, I'm using a library that calls Arg.parse to build up it's inputs in
> another data structure. I don't want to rewrite any code, and I'm consuming
> the library in a different way than how the binary consumes it, which is
> just to feed it input from the command line.
>
> Not wanting to replicate code in two locations, I chose to use
> Arg.parse_argv, and supplied it with an array that would normally be on the
> command line. For some reason, supplying the exact same speclist as what was
> used in the original statement that works as a command line tool doesn't
> result in the parameters being parsed.
>
> command line tool:
> Arg.parse speclist anon usage;
> get_program () (* consumes the mutable list that speclist modified *)
>
> (* speclist modifies a mutable list used to hold arguments *)
>
> my code that consumes speclist as a library:
>
> Arg.parse_argv custom_arguments speclist anon usage
> get_program () (* exact same function as above, exact same variables to
> Arg.parse* *)
>
> For some reason, Arg.parse_argv seems to complete, but when get_program
> proceeds, it sees the mutable argument list as being empty. Why?

Re: [Caml-list] complications with Arg.parse_argv

[Kenneth Adam Miller]

[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

*sigh  I fixed it literally the second you sent this email! And you are
right, what fixed it was I put ~current:(ref 0) and it is parsing arguments
now.

On Mon, Nov 24, 2014 at 1:16 PM, Gabriel Scherer <gabriel.scherer@gmail.com>
wrote:

> Looking at the parse_argv documentation (man Arg), I see two possible
> reasons:
> - Arg expects the passed string array to start with the name of the
> program at index 0; does your custom_arguments array follow this
> convention?
> - parse_argv takes an (optional) integer reference ~current that tells
> it where to start parsing the argument array; by default, it points to
> a global mutable reference Arg.current (so that several calls in a row
> start on the next element); if your library has used Arg.parse itself
> before, Arg.current may be set too far. You should try passing
> ~current:(ref 0) to make sure you only use local state.
>
> On Mon, Nov 24, 2014 at 6:42 PM, Kenneth Adam Miller
> <kennethadammiller@gmail.com> wrote:
> > So, I'm using a library that calls Arg.parse to build up it's inputs in
> > another data structure. I don't want to rewrite any code, and I'm
> consuming
> > the library in a different way than how the binary consumes it, which is
> > just to feed it input from the command line.
> >
> > Not wanting to replicate code in two locations, I chose to use
> > Arg.parse_argv, and supplied it with an array that would normally be on
> the
> > command line. For some reason, supplying the exact same speclist as what
> was
> > used in the original statement that works as a command line tool doesn't
> > result in the parameters being parsed.
> >
> > command line tool:
> > Arg.parse speclist anon usage;
> > get_program () (* consumes the mutable list that speclist modified *)
> >
> > (* speclist modifies a mutable list used to hold arguments *)
> >
> > my code that consumes speclist as a library:
> >
> > Arg.parse_argv custom_arguments speclist anon usage
> > get_program () (* exact same function as above, exact same variables to
> > Arg.parse* *)
> >
> > For some reason, Arg.parse_argv seems to complete, but when get_program
> > proceeds, it sees the mutable argument list as being empty. Why?
>

[-- Attachment #2: Type: text/html, Size: 2791 bytes --]