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 26B247EEEF for ; Wed, 24 Jun 2015 18:02:47 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.218.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.218.48 as permitted sender) identity=mailfrom; client-ip=209.85.218.48; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oi0-f48.google.com) identity=helo; client-ip=209.85.218.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-oi0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOAgBR1IpVlDDaVdFbhEQGgxipG4YPk20HTAEBAQEBARIBAQEBBwsLCR8whDsRHQEbHgMSCQc3AiQBEQEFASI1h3cBAxKnPoMxPjGLP4FrgnmLLgoZJw1XhTYBBQ6TMYFDBZQFi1GWbRIjgQ0JF4QlIjGCSAEBAQ X-IPAS-Result: A0DOAgBR1IpVlDDaVdFbhEQGgxipG4YPk20HTAEBAQEBARIBAQEBBwsLCR8whDsRHQEbHgMSCQc3AiQBEQEFASI1h3cBAxKnPoMxPjGLP4FrgnmLLgoZJw1XhTYBBQ6TMYFDBZQFi1GWbRIjgQ0JF4QlIjGCSAEBAQ X-IronPort-AV: E=Sophos;i="5.13,672,1427752800"; d="scan'208";a="137676684" Received: from mail-oi0-f48.google.com ([209.85.218.48]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jun 2015 18:02:46 +0200 Received: by oiax193 with SMTP id x193so33121343oia.2 for ; Wed, 24 Jun 2015 09:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oeqSeWCMYBhwrD1XSmSE9gwHaFirk37iyttOEx/nmWo=; b=m0XrQfW1syKXQWqOFfjjc62vqfn3+xCHQb0w2Uj61DDW+dbS6RAicgVnFqAeU47i2M uvNh/scHwwwcF+CnUvP/MEgtqiSo3AXvYrOtb8OZXIECwFonVZv1nA1T4jrwhCLhCyCU w/kruhkN/7/al8SSVJ9VkCLmGWRtPWPnyOr/J0eN132Wg2H8fzmwseT+XYD4Pw4cSNFj V+67GSHpCpNPsPguplDq8IWSazeMnm/2wgsIr5Kns8/BRizax4WoVmUcq0toDL9xDPjC gjy3WaAiV1Gy7SbgNgpcOc4CPRQ53d9r9JkhMEDmKfOVyzNfswuXQdrOA3NbLwY9zHQu 2PbA== MIME-Version: 1.0 X-Received: by 10.182.210.165 with SMTP id mv5mr35078470obc.82.1435161764913; Wed, 24 Jun 2015 09:02:44 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Wed, 24 Jun 2015 09:02:44 -0700 (PDT) Date: Wed, 24 Jun 2015 12:02:44 -0400 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=001a11c24894316a6f051945a3d3 Subject: [Caml-list] Core Overlay --001a11c24894316a6f051945a3d3 Content-Type: text/plain; charset=UTF-8 I'm trying to upgrade a library that has a lot of existing code that makes calls to List.map; the core overlay is really nice, and I'd like to make use of a tail recursive implementation because that much is pretty much imperative. I've refactored the code of the library to make sure that the compiler identifies the list and the operation types being from Core.List, recompiled, opam pinned the project. But I keep getting blowups. I've executed the code in gdb, and gotten a backtrace with the stack overflow and I can see that it's still going to List.map. So I'm thinking it has to be one of a few errors: I've fixed it, but it's linking against a different, older version of the library. * Problem with this is, the makefile generates ocamlfind calls, and those resolve the package correctly. I've check the file dates, removed the packages and readded them a multi-tude of times. Unless there's some invisible /usr/local compiler selection over the opam stuff despite it being specifically pointed there, I don't see how this could be. But I could be wrong. I've fixed the library some, but it some how resolves to a Pervasives type that's not tail recursive somewhere in the library that I missed. * I still don't see how this could be. I'm looking in the gdb backtrace, and I can see where it flows from my code into the library-the library. I've tracked the naming convention down to the exact function definition and checked via Emacs Merlin that it's the type it should be. I've fixed the library correctly, but somehow a mismatch between pervasives and Core definitions causes some fallback to the pervasives via some kind of invisible typing rules or language specifics that I don't know about. * Maybe, but wouldn't the compiler complain if it expected a Core.Std.List.t and got a list instead? --001a11c24894316a6f051945a3d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm trying to upgrade a library that has a lot of exis= ting code that makes calls to List.map; the core overlay is really nice, an= d I'd like to make use of a tail recursive implementation because that = much is pretty much imperative.

I've refactored the = code of the library to make sure that the compiler identifies the list and = the operation types being from Core.List, recompiled, opam pinned the proje= ct. But I keep getting blowups. I've executed the code in gdb, and gott= en a backtrace with the stack overflow and I can see that it's still go= ing to List.map.

So I'm thinking it has to be = one of a few errors:

I've fixed it, but it'= ;s linking against a different, older version of the library.
* P= roblem with this is, the makefile generates ocamlfind calls, and those reso= lve the package correctly. I've check the file dates, removed the packa= ges and readded them a multi-tude of times. Unless there's some invisib= le /usr/local compiler selection over the opam stuff despite it being speci= fically pointed there, I don't see how this could be. But I could be wr= ong.

I've fixed the library some, but it some = how resolves to a Pervasives type that's not tail recursive somewhere i= n the library that I missed.
* I still don't see how this cou= ld be. I'm looking in the gdb backtrace, and I can see where it flows f= rom my code into the library-the library. I've tracked the naming conve= ntion down to the exact function definition and checked via Emacs Merlin th= at it's the type it should be.


= I've fixed the library correctly, but somehow a mismatch between pervas= ives and Core definitions causes some fallback to the pervasives via some k= ind of invisible typing rules or language specifics that I don't know a= bout.
* Maybe, but wouldn't the compiler complain if it expec= ted a Core.Std.List.t and got a list instead?
--001a11c24894316a6f051945a3d3--