From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p93FlNXT011501
	for <caml-list@sympa-roc.inria.fr>; Mon, 3 Oct 2011 17:47:23 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AngGABbYiU5APrys/2dsb2JhbABBmTKOT4EFgVMBAQV4EQsYCRMDDwkDAgECAUUTBgIBAcEHhyEEh3edRQ
X-IronPort-AV: E=Sophos;i="4.68,480,1312149600"; 
   d="scan'208";a="122624598"
Received: from elehack.net ([64.62.188.172])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 03 Oct 2011 17:47:17 +0200
Received: from knine.elehack.net (x-134-84-228-145.uofm-secure.wireless.umn.edu [134.84.228.145])
	by elehack.net (Postfix) with ESMTPSA id 2EB7DEF19F
	for <caml-list@inria.fr>; Mon,  3 Oct 2011 10:47:47 -0500 (CDT)
Message-ID: <4E89D902.3050500@elehack.net>
Date: Mon, 03 Oct 2011 10:47:14 -0500
From: Michael Ekstrand <michael@elehack.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
MIME-Version: 1.0
To: caml-list@inria.fr
References: <4E89C577.5040500@elehack.net> <CAP_800oncPw=dma9CRLVE3VF5hMrrX2XCDcGEV-vyKvuZm+YBQ@mail.gmail.com>
In-Reply-To: <CAP_800oncPw=dma9CRLVE3VF5hMrrX2XCDcGEV-vyKvuZm+YBQ@mail.gmail.com>
X-Enigmail-Version: 1.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] Bug in sexplib 7.0.4?

On 10/03/2011 10:30 AM, Markus Mottl wrote:
> On Mon, Oct 3, 2011 at 10:23, Michael Ekstrand <michael@elehack.net> wrote:
>> I'm trying to build code against sexplib 7.0.4, and the code emitted by
>> the syntax extension has unqualified references to the base converters
>> like sexp_of_list and int_of_sexp. The result is that the sexplib-using
>> code fails to compile with undefined references. I've found this trying
>> to rebuild rpmdepsize, and also with some test code I have.
>>
>> Is this a bug in 7.0.4, or are there source-level changes required to
>> build against recent versions of sexplib? It feels more like a bug to
>> me, as I shouldn't need to open a module like Sexplib.Conv to make the
>> generated code work.
> This is indeed intended behavior, which is unfortunately not yet
> well-documented.  The library used to generate code with hard-coded
> module paths to the standard conversion functions.  This made it hard
> to override them.  The new library therefore requires you to "open
> Sexplib.Std" (not Sexplib.Conv btw.) if you are happy with all
> standard converters.  The effort is minimal, makes it explicit what
> conversion functions are being used, and overriding is as easy as
> (automatic) rebinding.

Thank you for the update. Could you add a note to this effect to the
README for a future release?

Thanks!
- Michael