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 54A6A7F75C for ; Sat, 13 Sep 2014 12:26:27 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of martin.jambon@ens-lyon.org) identity=pra; client-ip=66.111.4.28; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of martin.jambon@ens-lyon.org does not assert whether or not 66.111.4.28 is permitted sender) identity=mailfrom; client-ip=66.111.4.28; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; 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@out4-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.28; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="postmaster@out4-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0BAAwbFFRCbwQcnGdsb2JhbABeg2BXgny2Io98h04BgQkWEAEBAQEBBg0JCRQqhAQBAQQjDwEFCDkBDwsYAgIFIQICDwJGBg0BBwEBF4gjDaVOeIUIkEoBEQaBLIhUhU0HgniBU4tEhxGDNIhjhU4ahz2KOUyCSgEBAQ X-IPAS-Result: Ap0BAAwbFFRCbwQcnGdsb2JhbABeg2BXgny2Io98h04BgQkWEAEBAQEBBg0JCRQqhAQBAQQjDwEFCDkBDwsYAgIFIQICDwJGBg0BBwEBF4gjDaVOeIUIkEoBEQaBLIhUhU0HgniBU4tEhxGDNIhjhU4ahz2KOUyCSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,517,1406584800"; d="scan'208";a="78817210" Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Sep 2014 12:26:26 +0200 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway2.nyi.internal (Postfix) with ESMTP id AA6B320722 for ; Sat, 13 Sep 2014 06:26:24 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 13 Sep 2014 06:26:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=QrhIL2OhgcyAfGgYFyXBD5 M85nA=; b=lZVAexMUX9q6aDjYuwyU2N5q2N6fMTgWQ4tkBmHxIwdnFDbZY8t5+4 zWQZb0cupCkpe0/k5X21i+XdE3ZF4J8kGVSXTN9BdGoT6lfGfwPdYDeVLuXKEl9a w8ENnjEZYxA8mdWB7+KePMMO7woZjn7QbhcjwIhkhP2h7wEXbP1BM= X-Sasl-enc: y4CXEPya9iSSEI/xJuFwReLvmxpZqXVXPfWpg1dbQ3zy 1410603984 Received: from [192.168.2.7] (unknown [67.180.86.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 24D8D680081; Sat, 13 Sep 2014 06:26:24 -0400 (EDT) Message-ID: <54141BCF.60801@ens-lyon.org> Date: Sat, 13 Sep 2014 03:26:23 -0700 From: Martin Jambon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Alain Frisch CC: Caml List , Jeremy Yallop References: <20140905215626.GB3416@annexia.org> <20140905221302.GE3099@annexia.org> <20140905221813.GC3416@annexia.org> <540A3B85.6010609@ens-lyon.org> <540AA0DB.1040202@ens-lyon.org> <540CA84F.8090708@frisch.fr> <540D0642.7090205@ens-lyon.org> In-Reply-To: <540D0642.7090205@ens-lyon.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] segfault in simple program with 4.02 native On Sun 07 Sep 2014 06:28:34 PM PDT, Martin Jambon wrote: > On Sun 07 Sep 2014 11:47:43 AM PDT, Alain Frisch wrote: >> On 9/6/2014 7:51 AM, Martin Jambon wrote: >>> Thanks for the explanation, Jeremy. I guess atdgen will have to use >>> "option refs" after all unless someone has a better idea. >> >> I might be missing some context, but the current code seems to playing >> two different tricks with the type system: using (Obj.magic 0.) as a >> dummy initial default value (to avoid references) and mutating >> normally immutable fields with Obj.set_field. Is that right? > > Yes, exactly. > >> You >> might be able to keep the first trick, but storing the values in local >> references instead of field of the the target record (if those >> references don't espace from the function, they will be represented as >> local mutable variables, whose mutation might actually be more >> efficient than those of the record fields), building the target >> record at the end by reading from those references. > > Christophe Troestler also suggested this solution in a private reply. > I was afraid of the cost of the refs, so it's great to know that > they're optimized away. I think we now have a working implementation for json readers in atdgen (https://github.com/mjambon/atdgen/tree/fix-magic-ocaml402). However, atdgen also supports a binary format called biniou (Intro: http://mjambon.com/biniou.html Spec: https://github.com/mjambon/biniou/blob/master/biniou-format.txt). It is broken for the same reason as the JSON readers, but it is trickier to fix. Biniou allows sharing records and cyclic data. So far readers have been working by first creating a record with uninitialized fields, and then by proceeding with reading the field values. If a reference to the record is found, we just use the record that we already created, even if some of its fields are still unset. The problem here is that we need to create the record before reading its fields. Perhaps we could use the solution proposed by Milan Stanojević earlier in this thread, consisting in creating a private record type with mutable fields and at the end convert it to the normal type using Obj.magic. ... Or we could just drop support for some features, hence the following questions: 1. Does anyone use biniou at all? 2. Does anyone use biniou with cyclic data?