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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 3CD1E7F7C2 for ; Thu, 6 Feb 2014 11:25:53 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=74.125.82.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mmatalka@gmail.com designates 74.125.82.48 as permitted sender) identity=mailfrom; client-ip=74.125.82.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f48.google.com) identity=helo; client-ip=74.125.82.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-wg0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooCAB5i81JKfVIwlGdsb2JhbABZgmtZg1i7bIEHFg4BAQEBBwsLCRIqgiUBAQQBIwQZARsdAQMBCwYFCw0CAgUhAgIPAQQPEQEFAQ4BExOHcAEDCQgBBAihE4wLU4MJk2EKGScNZIgpEQEFDIEdjR4zB4JvgUkEmCuBMo8CQYRZ X-IPAS-Result: AooCAB5i81JKfVIwlGdsb2JhbABZgmtZg1i7bIEHFg4BAQEBBwsLCRIqgiUBAQQBIwQZARsdAQMBCwYFCw0CAgUhAgIPAQQPEQEFAQ4BExOHcAEDCQgBBAihE4wLU4MJk2EKGScNZIgpEQEFDIEdjR4zB4JvgUkEmCuBMo8CQYRZ X-IronPort-AV: E=Sophos;i="4.95,793,1384297200"; d="scan'208";a="48001807" Received: from mail-wg0-f48.google.com ([74.125.82.48]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Feb 2014 11:25:52 +0100 Received: by mail-wg0-f48.google.com with SMTP id x13so1133443wgg.27 for ; Thu, 06 Feb 2014 02:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=ReJ/9fQeO3xwBFfNOb9IE70N1/khfH3ePtgfHNOlUnU=; b=yXCpiljnFN5NbxasB+bJPHQt4/a/f1zr6I/6h2BPVXTgKAut+rg5Nr0SXTkef5shKm yQ0dFSbI3ibOYIBOM2Sme06RfqXE3OhH0iPLgFbmX7EEdb5SNr/QeCIMpSZEJfutVNos nqOzBbbqw70UeOrFAUhQEPlwpR4JkV5PpDeSn6oqCCqQDy5lK20bVHsVUvAW0b+AbbPe 1P3bDGHCnBm4aH5bjSMZUl4wjv4ZXaLRZEMq3+1gPICiKRIHpftEtcmwP2X1mP++32vj /yMcR1x2u06MzsJONpB4cKyfCFcHuvI0l+vm+FVMnWcL1z3sqc80OR94rzW1/2flOlYQ HQJw== X-Received: by 10.194.219.1 with SMTP id pk1mr5326111wjc.36.1391682352186; Thu, 06 Feb 2014 02:25:52 -0800 (PST) Received: from localhost ([2a01:7e00::f03c:91ff:fe70:2696]) by mx.google.com with ESMTPSA id pm2sm39729608wic.0.2014.02.06.02.25.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2014 02:25:50 -0800 (PST) From: Malcolm Matalka To: Romain Bardou Cc: Fabrice Le Fessant , Ocaml Mailing List References: <52F35934.5070306@inria.fr> Date: Thu, 06 Feb 2014 10:25:49 +0000 In-Reply-To: <52F35934.5070306@inria.fr> (Romain Bardou's message of "Thu, 06 Feb 2014 10:43:16 +0100") Message-ID: <87sirw1qs2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] OCamlPro Highlights: Dec 2013 & Jan 2014 I haven't use either, but what is the important differences between crunch and ocamlres? Romain Bardou writes: > 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 > > 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 =3D > try > Hashtbl.find included_resources path > with Not_found -> > let ch =3D 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 = =E2=80=94 > 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, > > --=20 > Romain Bardou