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 C92987EE51 for ; Sat, 11 May 2013 01:42:20 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.17.12; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.17.12; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.17.12; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMDAF2FjVHU4xEMlGdsb2JhbABSgz66d4UpexYOAQEBAQcLCwkSKoIfAQEFJxNPCxgJJQ8FKIgtARYItD8fiGCPL4J0YQOXK4YEjkM X-IPAS-Result: AgMDAF2FjVHU4xEMlGdsb2JhbABSgz66d4UpexYOAQEBAQcLCwkSKoIfAQEFJxNPCxgJJQ8FKIgtARYItD8fiGCPL4J0YQOXK4YEjkM X-IronPort-AV: E=Sophos;i="4.87,651,1363129200"; d="scan'208";a="16818091" Received: from mout.web.de ([212.227.17.12]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 May 2013 01:42:20 +0200 Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MYNrh-1V5alG3se1-00VffZ for ; Sat, 11 May 2013 01:42:19 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1Uawx9-0007z0-9y for caml-list@inria.fr; Sat, 11 May 2013 01:42:19 +0200 Date: Sat, 11 May 2013 01:42:19 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20130510234219.GB29570@frosties> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V02:K0:wJoXKLQjNJI5RQvOD19HrCtSnZcDRmSK8FhXHjaaTN0 99dIbXtiMBC7L373K2t6+XTO+W33vqALyD7yuYzZsFGRBvKSBU pl1aJ3WbkJumbUA6MoRgtCmi94I4KhUj8+fWtOCFenn9i90biI UFfWDdDCY1PY/KJGPBUyUY8KOUicK2IcRzEsPfLAkjf03+jeEb Yta2m2vAkEFjLishRdf0g== Subject: Re: [Caml-list] String, Array, Bigarray.char On Thu, May 09, 2013 at 02:32:20PM +0100, Tom Ridge wrote: > Dear caml-list, > > 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... > > Thanks A Bigarray is a ocaml block with the dimension, size, proxy object (for sub arrays) and pointer to the data. A string on the other hand is a ocaml block with bytes directly in it. Now if you allocate the memory for a Bigarray you can add a bit extra in front so you can also access the array as string. But you run into problems with the GC. Because it might want to free the Bigarrays while something still holds a reference to the string. So realy not a good idea. Since you seem to want to use fuse and bigarrays to implement a filesystem you might want to take a look at: - ExtUnix: type buffer = (int, Bigarray.int8_unsigned_elt, Bigarray.c_layout) Bigarray.Array1.t - ExtUnix.BA: val pread : Unix.file_descr -> int -> ExtUnixSpecific.buffer -> int val pwrite : Unix.file_descr -> int -> ExtUnixSpecific.buffer -> int val read : Unix.file_descr -> ExtUnixSpecific.buffer -> int val write : Unix.file_descr -> ExtUnixSpecific.buffer -> int val get_substr : ExtUnixSpecific.buffer -> int -> int -> string val set_substr : ExtUnixSpecific.buffer -> int -> string -> unit - ExtUnix.BA.BigEndian - ExtUnix.BA.LittleEndian - ExtUnix.BA.HostEndian - libaio-ocaml: http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=libaio-ocaml/libaio-ocaml.git;a=summary pkg-ocaml-maint/packages/libaio-ocaml.git on git.debian.org Bindings for Linux async IO library (libaio) - libfuse-ocaml: http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=libfuse-ocaml/libfuse-ocaml.git;a=summary pkg-ocaml-maint/packages/libfuse-ocaml.git on git.debian.org Bindings for libfuse The fuse bindings are for the lowlevel interface and geared towards async IO. I already convert filenames to strings. Or the stat structures to Bigarray on replies and so on. All of those are comparatively small so copying seems OK. The read callback always uses Bigarray and the write callback reply with string, string array, Bigarray or Bigarray array. I've managed to merge the Bigarray and endian stuff from libaio-ocaml and libfuse-ocaml in extunix but I haven't yet updated libaio-ocaml and libfuse-ocaml to make use of that. So if you plan to use either of those for real let me know and I will find some time to update them. I plan to do that soon and get them added to Debian proper now that wheezy is released anyway. Also if you want to add bindings for the high level fuse interface, implement a high level interface in ocaml directly or add a multithreaded main loop I wouldn't mind patches to that affect. MfG Goswin