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 AC4007F7C2 for ; Thu, 6 Feb 2014 12:31:25 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of benjamin.canou@gmail.com) identity=pra; client-ip=74.125.82.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="benjamin.canou@gmail.com"; x-sender="benjamin.canou@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of benjamin.canou@gmail.com designates 74.125.82.177 as permitted sender) identity=mailfrom; client-ip=74.125.82.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="benjamin.canou@gmail.com"; x-sender="benjamin.canou@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f177.google.com) identity=helo; client-ip=74.125.82.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="benjamin.canou@gmail.com"; x-sender="postmaster@mail-we0-f177.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooCAERy81JKfVKxlGdsb2JhbABZgmtZv0eBCRYOAQEBAQcLCwkSKoIlAQEFJwsBBQgBGxgEAgMMBgULDQkWDwkDAgECARERAQUBDgENEwgCh2wBAxEBBAihD4xegwmTYgoZJw1kiDoBBQyOOzqEOASYK4EyjwJBhFo X-IPAS-Result: AooCAERy81JKfVKxlGdsb2JhbABZgmtZv0eBCRYOAQEBAQcLCwkSKoIlAQEFJwsBBQgBGxgEAgMMBgULDQkWDwkDAgECARERAQUBDgENEwgCh2wBAxEBBAihD4xegwmTYgoZJw1kiDoBBQyOOzqEOASYK4EyjwJBhFo X-IronPort-AV: E=Sophos;i="4.95,793,1384297200"; d="scan'208";a="57123443" Received: from mail-we0-f177.google.com ([74.125.82.177]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Feb 2014 12:31:25 +0100 Received: by mail-we0-f177.google.com with SMTP id t61so1158771wes.8 for ; Thu, 06 Feb 2014 03:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=S4xFVwSFnGtZt1cGCi/BNJrdb0h3FAyj+uhmJaVTVqM=; b=PI+ZmF9aNTTWt73FvwtSnnzJOZcelmZIolVAgd2FGTCMvbN7aedrDDncATdK2QiGba kHWpqLXwY+zzJYNFRauf1LSHtKqiYPWe3FyGpKx0dSbpbRcFTaX6EH+0nq45dl+bXtg0 D4nCoxik5FJDAAbfEsNthQbxj3kFrOT2/SK5DIOWF/BNSujP7AWLX+zJt8IvBnO5n+AS gnNv8Ci3jEqPP/Yv0D4wAjl/EOqcV47/82BET5UyaWzGHWDn4B8hA3VlyUtneOGH0Gay /HyJGoC5ZfzQ3d2p47KrRWp5/gRmTH15UQscOypHXBEPoe9PMiDDwBHzs81Cqi5euJnm aeIA== X-Received: by 10.180.79.73 with SMTP id h9mr6497970wix.3.1391686284721; Thu, 06 Feb 2014 03:31:24 -0800 (PST) Received: from ?IPv6:2001:660:3013:3:9eb6:54ff:fea5:8a99? ([2001:660:3013:3:9eb6:54ff:fea5:8a99]) by mx.google.com with ESMTPSA id t6sm54653033wix.4.2014.02.06.03.31.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 03:31:23 -0800 (PST) Message-ID: <52F3728A.1010408@gmail.com> Date: Thu, 06 Feb 2014 12:31:22 +0100 From: Benjamin Canou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: caml-list@inria.fr References: <52F35934.5070306@inria.fr> In-Reply-To: <52F35934.5070306@inria.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] OCamlPro Highlights: Dec 2013 & Jan 2014 Hi Romain, Thanks for your reactive input. OCamlRes is still in design stage (cf. the version number) and I published it for gathering potential usages and users so it is very welcome. About the lack of mli, the implementation is actually ocamldoc'ed, so a `make doc` and a good browser should make for a reasonable substitute until the interface is well frozen in an mli. For your filesystem overlay use case, this can already be done with a : let load_resource base rpath = try OCamlRes.(Res.find Path.(of_string rpath) MyResources.root) with Not_found -> let fp = open_in (base ^ rpath) in (* read fp *) But I agree that it could be generated automatically in a specific format. Your idea of a master file makes sense. I'm more in favor of polishing the CLI for filtering files, but I think both approaches can coexist. I will put a todo / ideas list on github and I invite you (as well as everyone else) to contribute :) Cheers, Benjamin. Le 06/02/2014 10:43, Romain Bardou a écrit : > On 05/02/2014 18:31, Fabrice Le Fessant wrote: >> Hi, >> >> Here is the link to OCamlPro's report on its activities in January >> 2014 on OCaml: >> >> http://www.ocamlpro.com/blog/2014/02/05/monthly-2014-01.html >> >> --Fabrice >> > Interesting read. > > Regarding OCamlRes... > > - It like the idea. I already have one use case: images for my GTK icons. > > - 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). > > - Because of the above I was not able to find out what ocplib-ocamlres > provided. > > - 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: > > val load_resource: string -> string > > 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: > > let load_resource path = > try > Hashtbl.find included_resources path > with Not_found -> > let ch = open_in path in > ... > > 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.) > > - 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 — > 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. > > Cheers, >