caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Daniel Bünzli" <daniel.buenzli@epfl.ch>
To: John Prevost <j.prevost@gmail.com>
Cc: caml-list caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Bigarrays and temporar C pointers
Date: Sun, 16 Jan 2005 13:31:52 +0100	[thread overview]
Message-ID: <999863E4-67BA-11D9-80D7-000393DBC266@epfl.ch> (raw)
In-Reply-To: <d849ad2a0501151828533a957a@mail.gmail.com>


Le 16 janv. 05, à 03:28, John Prevost a écrit :

> Well, assuming you really need to work in this strange way,
Yes, some part of opengl work like this, vertex buffer objects [1]. In  
fact there a lot more things that are not allowed to do while a buffer  
is mapped and it is not possible to enforce every constraints (however  
most, if not all, of these errors just lead to gl errors, not to core  
dumps).

Anyway, thanks for you time and code. Especially for the handling of  
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 = ('a, 'b, c_layout) Array1.t

abstract and replicate Array1.t's "allowed" functionnality in the  
module --- I hope that it won't prevent the optimisations present in  
the compiler for bigarrays.

> set = Array1.set
> get = Array1.get
> ...

The only problem I see is that the user loses the ability to use  
existing bigarray code and the lighter syntax to access/write the  
array. On the other hand I can prevent the user from extracting  
subarrays and I'm on the safe side again.

There's a tradeoff and I cannot make up my mind right now.

Daniel

[1]  
<http://oss.sgi.com/projects/ogl-sample/registry/ARB/ 
vertex_buffer_object.txt>


      reply	other threads:[~2005-01-16 12:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-15 23:40 Daniel Bünzli
2005-01-16  2:28 ` [Caml-list] " John Prevost
2005-01-16 12:31   ` Daniel Bünzli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=999863E4-67BA-11D9-80D7-000393DBC266@epfl.ch \
    --to=daniel.buenzli@epfl.ch \
    --cc=caml-list@inria.fr \
    --cc=j.prevost@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).