caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Anil Madhavapeddy <anil@recoil.org>
To: Tom Ridge <tom.j.ridge+caml@googlemail.com>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] String, Array, Bigarray.char
Date: Thu, 9 May 2013 10:21:39 -0400	[thread overview]
Message-ID: <D67B16F7-4C6F-457A-827E-DCF618AB5024@recoil.org> (raw)
In-Reply-To: <CABooLwM61nyxVtj0tFzJ9hS=oNsdESTmer8MW63nVF2zLyQKgg@mail.gmail.com>

You should look at either Lwt or Core/Async, which both provide wrappers
over Bigarray, and asynchronous alternatives to using Unix and threads.

Lwt_bytes: http://ocsigen.org/lwt/api/Lwt_bytes
Bigstring: https://ocaml.janestreet.com/ocaml-core/latest/doc/core/Bigstring.html

The choice between them depends on your situation.  Lwt is an add-on
library that interops with existing code well, whereas Core is a more
complete stdlib replacement (with vastly more features/datastructures).

-anil

On 9 May 2013, at 10:14, Tom Ridge <tom.j.ridge+caml@googlemail.com> wrote:

> Although I see that this won't be so easy because various functions
> such as Unix.write have the buffer argument being of type string :(
> 
> So at various points I seem to be forced to use strings. I suppose one
> alternative is to reimplement the functions I use (such as Unix.write)
> to work with arrays. Does anyone know if this has been done elsewhere?
> 
> 
> On 9 May 2013 15:07, Tom Ridge <tom.j.ridge+caml@googlemail.com> wrote:
>> Thanks for this information.
>> 
>> I guess I will probably end up using arrays as much as possible. In
>> various places I have used strings as though they were immutable
>> arrays of byte. I guess the advantage of this approach is that strings
>> seem more familiar than arrays (especially Bigarrays). But it is
>> probably not much of a big deal to move to using arrays everywhere.
>> 
>> Thanks once again
>> 
>> Tom
>> 
>> 
>> On 9 May 2013 14:44, Anil Madhavapeddy <anil@recoil.org> wrote:
>>> On 9 May 2013, at 09:32, Tom Ridge <tom.j.ridge+caml@googlemail.com> wrote:
>>>> 
>>>> Quick question: I am working a lot with arrays of byte, which at
>>>> various points I want to view as strings, and at various points I want
>>>> to view as arrays. The exact types involved should be discernible from
>>>> the code below.
>>>> 
>>>> I have some conversion functions e.g.:
>>>> 
>>>> type myfusebuffer = (char, Bigarray.int8_unsigned_elt,
>>>> Bigarray.c_layout) Bigarray.Array1.t
>>>> 
>>>> module A = Bigarray.Array1
>>>> 
>>>> (* convenience only; don't use in production code *)
>>>> let array_of_string bs = (
>>>>   let arr = (Array.init (String.length bs) (String.get bs)) in
>>>>   let contents = A.of_array Bigarray.char Bigarray.c_layout arr in
>>>>   contents)
>>>> let (_:string -> myfusebuffer) = array_of_string
>>>> 
>>>> This presumably takes O(n) time (where n is the length of the string
>>>> bs). My question is: is there functionality to move values between
>>>> these types at cost O(1)? Basically, I'm hoping that String is
>>>> implemented as A.of_array Bigarray.char Bigarray.c_layout or
>>>> similar...
>>> 
>>> Strings are represented as normal OCaml values within the OCaml heap,
>>> whereas Bigarrays are simply pointers to externally allocated memory
>>> (via malloc).  You do therefore need to copy across them in most cases.
>>> One quick solution is to define a subset of the String module that uses
>>> the Bigarray accessor functions, but this isn't ideal (especially when
>>> external libraries that use strings are involved).
>>> 
>>> Your fusebuffer type probably means that you're working with filesystem
>>> data.  Can you just use Bigarrays for everything, with copies to strings
>>> only when you absolutely need to?  We haven't released this out of beta
>>> yet, but the cstruct camlp4 extension helps map C structures to OCaml:
>>> https://github.com/mirage/ocaml-cstruct
>>> 
>>> -anil
>>> 
>>> 
>>> 
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 


  reply	other threads:[~2013-05-09 14:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-09 13:32 Tom Ridge
2013-05-09 13:44 ` Anil Madhavapeddy
2013-05-09 14:07   ` Tom Ridge
2013-05-09 14:14     ` Tom Ridge
2013-05-09 14:21       ` Anil Madhavapeddy [this message]
2013-05-09 14:30         ` Tom Ridge
2013-05-09 16:29         ` ygrek
2013-05-09 14:29       ` Markus Mottl
2013-05-09 14:25 ` Markus Mottl
2013-05-10 23:42 ` Goswin von Brederlow

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=D67B16F7-4C6F-457A-827E-DCF618AB5024@recoil.org \
    --to=anil@recoil.org \
    --cc=caml-list@inria.fr \
    --cc=tom.j.ridge+caml@googlemail.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).