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 ADADC7F7C4 for ; Thu, 6 Feb 2014 11:57:43 +0100 (CET) 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: AmoGAAdq81JZELGaY2dsb2JhbABZg0SqFIE7k3WBHwMYFQY+giUBAQQBJ0cLBQsLDgoNISEkBAENBhMSh18DCQgECcUjAwqJDReMZIFjMweDJIEUBJY/gWyBMossiHA X-IPAS-Result: AmoGAAdq81JZELGaY2dsb2JhbABZg0SqFIE7k3WBHwMYFQY+giUBAQQBJ0cLBQsLDgoNISEkBAENBhMSh18DCQgECcUjAwqJDReMZIFjMweDJIEUBJY/gWyBMossiHA X-IronPort-AV: E=Sophos;i="4.95,793,1384297200"; d="scan'208";a="57117418" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail2-smtp-roc.national.inria.fr with SMTP; 06 Feb 2014 11:57:42 +0100 Received: (qmail 1908 invoked by uid 634); 6 Feb 2014 10:57:41 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from volstagg-0.srg.cl.cam.ac.uk (HELO flick.office) (128.232.32.232) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Thu, 06 Feb 2014 10:57:40 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Anil Madhavapeddy In-Reply-To: <87sirw1qs2.fsf@gmail.com> Date: Thu, 6 Feb 2014 10:57:39 +0000 Cc: Romain Bardou , Fabrice Le Fessant , Ocaml Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <52F35934.5070306@inria.fr> <87sirw1qs2.fsf@gmail.com> To: Malcolm Matalka X-Mailer: Apple Mail (2.1812) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] OCamlPro Highlights: Dec 2013 & Jan 2014 OCamlRes is a much more principled library than crunch -- which just prettyprints a giant pattern match of strings from a filesystem tree. One differentiator of crunch is that it exposes a more system-like interface, to match the other "real" backends in Mirage (i.e. a Lwt_cstruct iterator based on Bigarrays, rather than a string). I have no problem migrating to ocplib-res eventually, except for a query I've raised on their bugtracker about the licensing: https://github.com/OCamlPro/ocp-ocamlres/issues/2 best, Anil On 6 Feb 2014, at 10:25, Malcolm Matalka wrote: > I haven't use either, but what is the important differences between > crunch and ocamlres? >=20 > Romain Bardou writes: >=20 >> On 05/02/2014 18:31, Fabrice Le Fessant wrote: >>> Hi, >>>=20 >>> Here is the link to OCamlPro's report on its activities in January >>> 2014 on OCaml: >>>=20 >>> http://www.ocamlpro.com/blog/2014/02/05/monthly-2014-01.html >>>=20 >>> --Fabrice >>>=20 >>=20 >> Interesting read. >>=20 >> Regarding OCamlRes... >>=20 >> - It like the idea. I already have one use case: images for my GTK icons. >>=20 >> - There is no .mli in your src directory, it makes your code less >> readable (even empty .mli files are interesting, they tell the reader >> that the module is the main module). >>=20 >> - Because of the above I was not able to find out what ocplib-ocamlres >> provided. >>=20 >> - Maybe this is handled by ocplib-ocamlres, but it would be nice if >> there was a way to include resources in the executable at first, and >> then, if the project becomes bigger, have a way to externalize (some of) >> those resources without changing the code. So we would have some >> function such as: >>=20 >> val load_resource: string -> string >>=20 >> taking the resource path (e.g. "res/a/x/test.int") and returning the >> contents of the file, either by actually reading an external file, or >> just by returning a string which was included at compile-time. It could >> be as simple as: >>=20 >> let load_resource path =3D >> try >> Hashtbl.find included_resources path >> with Not_found -> >> let ch =3D open_in path in >> ... >>=20 >> where included_resources is a hash table filled by ocp-ocamlres. (I >> don't think it is very interesting to keep the directory hierarchy, but >> maybe it is for some use cases.) >>=20 >> - I would probably write a file containing the list of resource files I >> want to include (one per line), and in my build system, add a rule >> saying how to obtain an .ml file from it using ocp-ocamlres. It would >> protect the user from including trash such as Emacs autosaves (~ files = =97 >> although mines are in a different directory :) ) or Windows Thumbs.db >> files or whatever. You can't be sure what's inside your "res" directory! >> Maybe your tool could read such a file itself to make it easier and more >> unified. >>=20 >> Cheers, >>=20 >> --=20 >> Romain Bardou >=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