From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 507E0BC8C for ; Sun, 16 Jan 2005 13:32:06 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0GCW5wZ000806 for ; Sun, 16 Jan 2005 13:32:05 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA11430 for ; Sun, 16 Jan 2005 13:32:05 +0100 (MET) Received: from mail17.bluewin.ch (mail17.bluewin.ch [195.186.18.64]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0GCW5kP000803 for ; Sun, 16 Jan 2005 13:32:05 +0100 Received: from [10.0.1.2] (81.63.123.229) by mail17.bluewin.ch (Bluewin AG 7.0.035) id 41DEA2BD000B6216; Sun, 16 Jan 2005 12:32:04 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <999863E4-67BA-11D9-80D7-000393DBC266@epfl.ch> Content-Transfer-Encoding: quoted-printable Cc: caml-list caml-list From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Re: [Caml-list] Bigarrays and temporar C pointers Date: Sun, 16 Jan 2005 13:31:52 +0100 To: John Prevost X-Mailer: Apple Mail (2.619) X-Miltered: at concorde with ID 41EA5EC5.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41EA5EC5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; epfl:01 caml-list:01 bigarrays:01 pointers:01 prevost:01 buffer:01 buffer:01 occuring:01 compiler:01 bigarrays:01 bigarray:01 syntax:01 ...:98 abstract:01 exceptions:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: Le 16 janv. 05, =E0 03:28, John Prevost a =E9crit : > Well, assuming you really need to work in this strange way, Yes, some part of opengl work like this, vertex buffer objects [1]. In =20= fact there a lot more things that are not allowed to do while a buffer =20= is mapped and it is not possible to enforce every constraints (however =20= most, if not all, of these errors just lead to gl errors, not to core =20= dumps). Anyway, thanks for you time and code. Especially for the handling of =20 exceptions occuring in the callback which I completely forgot. In fact I didn't consider, as you suggest, to make the type > type ('a, 'b) data =3D ('a, 'b, c_layout) Array1.t abstract and replicate Array1.t's "allowed" functionnality in the =20 module --- I hope that it won't prevent the optimisations present in =20 the compiler for bigarrays. > set =3D Array1.set > get =3D Array1.get > ... The only problem I see is that the user loses the ability to use =20 existing bigarray code and the lighter syntax to access/write the =20 array. On the other hand I can prevent the user from extracting =20 subarrays and I'm on the safe side again. There's a tradeoff and I cannot make up my mind right now. Daniel [1] =20