Re: [Caml-list] OCamlPro Highlights: Dec 2013 & Jan 2014

[Benjamin Canou <benjamin.canou@gmail.com>]

   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,
>