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

[Anil Madhavapeddy <anil@recoil.org>]

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 <mmatalka@gmail.com> wrote:

> I haven't use either, but what is the important differences between
> crunch and ocamlres?
> 
> Romain Bardou <romain.bardou@inria.fr> writes:
> 
>> 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
> 
> -- 
> 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