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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6EB287EE51 for ; Thu, 9 May 2013 16:21:42 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=mailfrom; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@dark.recoil.org) identity=helo; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="postmaster@dark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMCAO+vi1FZELGagWdsb2JhbABSgz6tbpIYgRAOAQEWJiiCHwEBBAEnRwsFCwsYDSFFEgYTEgmHXwMJCgi1JAMKiBCMUoIjMweCdGEDlyyBJoUTjicg X-IPAS-Result: AtMCAO+vi1FZELGagWdsb2JhbABSgz6tbpIYgRAOAQEWJiiCHwEBBAEnRwsFCwsYDSFFEgYTEgmHXwMJCgi1JAMKiBCMUoIjMweCdGEDlyyBJoUTjicg X-IronPort-AV: E=Sophos;i="4.87,641,1363129200"; d="scan'208";a="16645807" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail2-smtp-roc.national.inria.fr with SMTP; 09 May 2013 16:21:41 +0200 Received: (qmail 28129 invoked by uid 634); 9 May 2013 14:21:41 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from Unknown (HELO [172.20.26.177]) (12.202.122.2) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Thu, 09 May 2013 15:21:40 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 9 May 2013 10:21:39 -0400 Cc: caml-list Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Ridge X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] String, Array, Bigarray.char 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/Bigstrin= g.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 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 :( >=20 > 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? >=20 >=20 > On 9 May 2013 15:07, Tom Ridge wrote: >> Thanks for this information. >>=20 >> 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. >>=20 >> Thanks once again >>=20 >> Tom >>=20 >>=20 >> On 9 May 2013 14:44, Anil Madhavapeddy wrote: >>> On 9 May 2013, at 09:32, Tom Ridge wr= ote: >>>>=20 >>>> 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. >>>>=20 >>>> I have some conversion functions e.g.: >>>>=20 >>>> type myfusebuffer =3D (char, Bigarray.int8_unsigned_elt, >>>> Bigarray.c_layout) Bigarray.Array1.t >>>>=20 >>>> module A =3D Bigarray.Array1 >>>>=20 >>>> (* convenience only; don't use in production code *) >>>> let array_of_string bs =3D ( >>>> let arr =3D (Array.init (String.length bs) (String.get bs)) in >>>> let contents =3D A.of_array Bigarray.char Bigarray.c_layout arr in >>>> contents) >>>> let (_:string -> myfusebuffer) =3D array_of_string >>>>=20 >>>> 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... >>>=20 >>> 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). >>>=20 >>> 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 >>>=20 >>> -anil >>>=20 >>>=20 >>>=20 >=20 > --=20 > 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 >=20