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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 68EB17FD02 for ; Mon, 27 Apr 2015 17:07:54 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of agarwal1975@gmail.com) identity=pra; client-ip=74.125.82.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of agarwal1975@gmail.com designates 74.125.82.47 as permitted sender) identity=mailfrom; client-ip=74.125.82.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f47.google.com) identity=helo; client-ip=74.125.82.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="postmaster@mail-wg0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CTAgC+Tz5VnC9SfUpCGoJFgRpcBYMVwnsqCYFShgQCgSsHOBQBAQEBAQEBEQEBAQEBBg0JCSEuhCEBAQMBEhEdARsdAQMBCwYFCzcCAiIBEQEFARwGEyKHdAEDCQgNOKZHPjGLOYFrgnaIeAoZJw1VhGwBAQEBBgEBAQEBARYBBQ6KKIEChDpHBAeCaIFFBZVWhjiBX5I4EiOBDAmCKR2BbSIxAYJDAQEB X-IPAS-Result: A0CTAgC+Tz5VnC9SfUpCGoJFgRpcBYMVwnsqCYFShgQCgSsHOBQBAQEBAQEBEQEBAQEBBg0JCSEuhCEBAQMBEhEdARsdAQMBCwYFCzcCAiIBEQEFARwGEyKHdAEDCQgNOKZHPjGLOYFrgnaIeAoZJw1VhGwBAQEBBgEBAQEBARYBBQ6KKIEChDpHBAeCaIFFBZVWhjiBX5I4EiOBDAmCKR2BbSIxAYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,657,1422918000"; d="scan'208";a="113692376" Received: from mail-wg0-f47.google.com ([74.125.82.47]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 Apr 2015 17:07:53 +0200 Received: by wgin8 with SMTP id n8so119263363wgi.0 for ; Mon, 27 Apr 2015 08:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q9gwJI8hOvgfN80A0Myw6udKzb/CwivH6PPJ6KHoLnM=; b=OJHEGKg7U7+79kExSTVTUjuy00NYP463v45ArJQy3bROZGAQBCbQHebzzO+Ndmk60A XlwV+WrnBjCuqzklZcZs3F6uH5uskiPiFXtXUQNBeE8tGXC1in6qyQcsuvPshJ2/o5IE 6M2k2e69qcFU+UVfTl8ECFxQchpc4mtm1qPB0yBBBnhSEthFyPLlRelyNBlHJGM/sun8 vfFR7+CJeuarbUSevXyEyPKllEhB5n4tJuG8Ttj7hjmdXQ5rnvtGw/skJo68VCvCNm+C FsHZRUf+kv6J8rPLIB2tna15jGdXPBxWfjksq5JEC09VYv8J8HIXP8Wp6+QGif67jFoU sCGg== X-Received: by 10.181.13.113 with SMTP id ex17mr21945701wid.12.1430147273633; Mon, 27 Apr 2015 08:07:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.187.136 with HTTP; Mon, 27 Apr 2015 08:07:33 -0700 (PDT) In-Reply-To: References: From: Ashish Agarwal Date: Mon, 27 Apr 2015 11:07:33 -0400 Message-ID: To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: Caml List Content-Type: multipart/alternative; boundary=f46d043c7f0c38b65c0514b61c95 Subject: Re: [Caml-list] inconsistent assumptions over interface --f46d043c7f0c38b65c0514b61c95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > server code with client code, both seem to have a different Eliommod_parameters module Right, thanks! This explains it. There are two Eliommod_parameters interfaces. We have client/eliom_pervasives.cmi compiled agains the client one, and _server/foo.cmi compiled against the server one. And then I'm mixing them somehow. > Usually in these cases it's a good idea to have a look at the hash of the inconsistent .cmi files with ocamlobjinfo and try to locate the corresponding .cmi in the included dirs to get a better idea of what's going on. Great suggestion. I'll try this. On Mon, Apr 27, 2015 at 11:02 AM, Daniel B=C3=BCnzli wrote: > > It's Eliom related, though I don't know why that would matter. > > > > # Error: The files ~/.opam/4.02.1/lib/eliom/client/eliom_pervasives.cmi > > # and ../_server/foo.cmi make inconsistent assumptions > > # over interface Eliommod_parameters > > Don't know anything about eliom but it seems that you are trying to > compile server code with client code, both seem to have a different > Eliommod_parameters module. I don't know if the Eliommod_parameters cmi a= re > supposed to be the same in both cases (if there's a discrepancy that didn= 't > use to exist it may be due to compiling with `-keep-locs` which could > result in problems along the line of [1,2] but I don't know how eliom's > source is structured). > > Usually in these cases it's a good idea to have a look at the hash of the > inconsistent .cmi files with ocamlobjinfo and try to locate the > corresponding .cmi in the included dirs to get a better idea of what's > going on. > > Best, > > Daniel > > [1] https://github.com/ocamllabs/ocaml-ctypes/issues/283 > [2] http://caml.inria.fr/mantis/view.php?id=3D6311#c13598 > > > > --f46d043c7f0c38b65c0514b61c95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0ser= ver code with client code, both seem to have a different Eliommod_parameter= s module

Right, thanks! Thi= s explains it. There are two=C2=A0Eliommod_parameters interfaces. We have=C2=A0client/eliom_pervasives.cmi compiled agai= ns the client one, and=C2=A0_server/foo.cmi compiled against the server one. And then I'm mixi= ng them somehow.

>= =C2=A0Usually in these = cases it's a good idea to have a look at the hash of the inconsistent .= cmi files with ocamlobjinfo and try to locate the corresponding .cmi in the= included dirs to get a better idea of what's going on.

Great suggestion. I'll try this.=

<= /div>


On Mon, Apr 27= , 2015 at 11:02 AM, Daniel B=C3=BCnzli <daniel.buenzli@erratique= .ch> wrote:
> It's Eliom related, though I don't know why that would matte= r.
>
> # Error: The files ~/.opam/4.02.1/lib/eliom/client/eliom_pervasives.cm= i
> # and ../_server/foo.cmi make inconsistent assumptions
> # over interface Eliommod_parameters

Don't know anything about eliom but it seems that you are trying= to compile server code with client code, both seem to have a different Eli= ommod_parameters module. I don't know if the Eliommod_parameters cmi ar= e supposed to be the same in both cases (if there's a discrepancy that = didn't use to exist it may be due to compiling with `-keep-locs` which = could result in problems along the line of [1,2] but I don't know how e= liom's source is structured).

Usually in these cases it's a good idea to have a look at the hash of t= he inconsistent .cmi files with ocamlobjinfo and try to locate the correspo= nding .cmi in the included dirs to get a better idea of what's going on= .

Best,

Daniel

[1] https://github.com/ocamllabs/ocaml-ctypes/issues/283
[2] http://caml.inria.fr/mantis/view.php?id=3D6311#c13598




--f46d043c7f0c38b65c0514b61c95--