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

[Romain Bardou <romain.bardou@inria.fr>]

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,

-- 
Romain Bardou