From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 2874EBB84 for ; Fri, 14 Nov 2008 16:58:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMDANsuHUnAXQImgWdsb2JhbACBbZFsAQEWIrxwgng X-IronPort-AV: E=Sophos;i="4.33,603,1220220000"; d="scan'208";a="19194371" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 14 Nov 2008 16:58:32 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id mAEFwW04008675 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 14 Nov 2008 16:58:32 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMDAKouHUlYvxGEgWdsb2JhbACBbZFsAQEWIrxvgng X-IronPort-AV: E=Sophos;i="4.33,603,1220220000"; d="scan'208";a="31463612" Received: from www.rastageeks.org (HELO mail.rastageeks.org) ([88.191.17.132]) by mail4-smtp-sop.national.inria.fr with ESMTP; 14 Nov 2008 16:58:32 +0100 Received: from leonard.local (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rastageeks.org (Postfix) with ESMTP id 89D29AA25F for ; Fri, 14 Nov 2008 16:58:31 +0100 (CET) From: Romain Beauxis To: OCaml Mailing List Subject: Re: [Caml-list] Big array with data managed by another value Date: Fri, 14 Nov 2008 16:58:30 +0100 User-Agent: KMail/1.9.9 References: <200811141503.43395.toots@rastageeks.org> <4A8FA99F-D6C3-4D99-AC8D-E17CEE94C88F@erratique.ch> <15DBBCF2-79EF-4F08-A589-3E1B9B4EECB5@erratique.ch> In-Reply-To: <15DBBCF2-79EF-4F08-A589-3E1B9B4EECB5@erratique.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200811141658.31079.toots@rastageeks.org> X-Miltered: at discorde with ID 491DA028.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 hashing:01 bigarray:01 bigarray:01 pointer:01 caml-list:01 finalization:01 data:02 data:02 callback:02 callback:02 caml:02 caml:02 external:03 deallocate:03 Le Friday 14 November 2008 16:10:13 Daniel B=FCnzli, vous avez =E9crit=A0: > I think I understood now, the original value was the custom block. > > If you were using the custom block only for finalization issues (not =A0 > serialization, hashing etc.) then one solution would be to replace =A0 > your custom block type by the bigarray itself. An register the =A0 > bigarray with Gc.finalise to deallocate the C pointer at the =A0 > appropriate time. Then you have > > type t =3D bigarray > let to_bigarray x =3D x > > and no problems. Yep, that's my current solution. However, I see little interest to be able to allocate a big array with=20 CAML_BA_EXTERNAL then. The only situation where this would be of some interest is for using a caml= =20 callback from C, where you don't want the callback to finalize your data. But you would never be able to convert a part of a custom data type to big= =20 array. Thanks for your anwsers. R.