From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 26E597FAED for ; Mon, 24 Nov 2014 19:22:52 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.214.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.214.176 as permitted sender) identity=mailfrom; client-ip=209.85.214.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f176.google.com) identity=helo; client-ip=209.85.214.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-ob0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgKAJx2c1TRVdawm2dsb2JhbABbhDwEgwK3NJdPAihvBxYBAQEBAREBAQEBAQYLCwkULoN6CAEBAQMBEhEdARsdAQMBCwYFBAcNKgICIQEBEQEFARwZIoVUgjUBAwkJrhQ9MYs7gXKDEYlyChknDWiFXgEBAQEBBQEBAQEBARYBBQ6OQIFbEQFQB4J5D4FGBYwlkEeCFYE0i3GCd4J0gg8YKYVVKjCBD4E8AQEF X-IPAS-Result: AvgKAJx2c1TRVdawm2dsb2JhbABbhDwEgwK3NJdPAihvBxYBAQEBAREBAQEBAQYLCwkULoN6CAEBAQMBEhEdARsdAQMBCwYFBAcNKgICIQEBEQEFARwZIoVUgjUBAwkJrhQ9MYs7gXKDEYlyChknDWiFXgEBAQEBBQEBAQEBARYBBQ6OQIFbEQFQB4J5D4FGBYwlkEeCFYE0i3GCd4J0gg8YKYVVKjCBD4E8AQEF X-IronPort-AV: E=Sophos;i="5.07,450,1413237600"; d="scan'208";a="109316740" Received: from mail-ob0-f176.google.com ([209.85.214.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Nov 2014 19:22:51 +0100 Received: by mail-ob0-f176.google.com with SMTP id vb8so7437304obc.7 for ; Mon, 24 Nov 2014 10:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=1J1nev2a4HWNLxqSD09ppsXq3wW3ugwOYrEPRK7vEPY=; b=ZiemMW6IPzhWrLRdM71Ne5ilmv8zSrHLEKR4OzWu6F0TAv8IRIzCofAhjl5zMV3cWy 2Q68zEIrQRPum1vr65CvT4SYhuZ/hpnTGXCEPnRnl5zMfHXuBj8amR85GHhxsMEPxMf6 VEHUxji/rrSAzI2vHAVzu1vEdizy2HAOK2838yHx4hyLyzBeZM+HauTcdua6t8EKXaPC SEx2riQ5t9iwSEZeLtmj1YUoXN87UAnfmImfa7D2DTo88+cTVRYaDZMThWP9LaMtN/zg 06ekrKxwtm3PHJna2SzxKP7pCMHWBykLLKDgdL2QTnH59wHgXltfXTS5EEZA/b4TBSRA gclg== MIME-Version: 1.0 X-Received: by 10.60.55.68 with SMTP id q4mr12280258oep.64.1416853370233; Mon, 24 Nov 2014 10:22:50 -0800 (PST) Received: by 10.182.197.1 with HTTP; Mon, 24 Nov 2014 10:22:49 -0800 (PST) In-Reply-To: References: Date: Mon, 24 Nov 2014 13:22:49 -0500 Message-ID: From: Kenneth Adam Miller Cc: caml users Content-Type: multipart/alternative; boundary=089e013a1fe0d4effa05089ee187 Subject: Re: [Caml-list] complications with Arg.parse_argv --089e013a1fe0d4effa05089ee187 Content-Type: text/plain; charset=UTF-8 *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 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 > 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? > --089e013a1fe0d4effa05089ee187 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
*sigh =C2=A0I fixed it literally the second you sent this = email! And you are right, what fixed it was I put ~current:(ref 0) and it i= s parsing arguments now.

On Mon, Nov 24, 2014 at 1:16 PM, Gabriel Scherer <gab= riel.scherer@gmail.com> wrote:
Looking at the parse_argv documentation (man Arg), I see two possible r= easons:
- 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= 9;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 o= n the
> command line. For some reason, supplying the exact same speclist as wh= at 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 *)<= br> >
> (* 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 t= o
> Arg.parse* *)
>
> For some reason, Arg.parse_argv seems to complete, but when get_progra= m
> proceeds, it sees the mutable argument list as being empty. Why?

--089e013a1fe0d4effa05089ee187--