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

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

[Fabrice Le Fessant]

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
-- 
Fabrice LE FESSANT
Scientific Advisor, OCamlPro SAS

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

[Romain Bardou]

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

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

[Malcolm Matalka]

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

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

[Anil Madhavapeddy]

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

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

[Benjamin Canou]

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

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

[Daniel Bünzli]

Le jeudi, 6 février 2014 à 12:31, Benjamin Canou a écrit :
> 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.

The problem of figuring out which functions in the ml are part of the interface and which are not is still solved by this approach (not to mention that you may expose representations you'd like to hide later). Besides you don't get any feel on how the interface is organized type-wise which is one of the quickest way to evaluate the brokenness or beauty of an api.  

As soon as I see a lack of mli files in a published package, I disregard. I equate it with lack of design.  

Best,

Daniel

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

[Benjamin Canou]

Le 06/02/2014 14:06, Daniel Bünzli a écrit :
> As soon as I see a lack of mli files in a published package, I disregard. I equate it with lack of design.
Well, I'm very, very sorry that I disappointed you, my lord.
But do not be worried, I shall compose an mli when comes the time, for I 
would cherish your blessing upon my modest package.

Cheers,

   Benjamin.

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

[Benjamin Canou]

   Dear all,

It seems that my faux olde english is quite poor, and that my message 
reads as an angry attack at Daniel for some people. Of course it is not, 
and Daniel, I apologize if you took it this way too. I'll treat you to a 
pint next time we see each other. I just wanted to react to your quite 
justified criticism, but since I found your tone a bit harsh, I chose to 
reply with a bad joke tone in return. My not so good english and the 
e-mail medium seem to have betrayed me.

So to clarify things, this is not a release announce, I thought that the 
0.1 version number would make it clear, but here again, my mistake. Of 
course, the proper release will include a documented interface. But for 
now, there is no well documented public interface yet, on purpose. The 
library is not frozen because it is still in design stage, and I am not 
sure where to place the abstraction barrier, so I don't want anyone to 
take an interface as granted. I made an early distribution so that my 
blog entry could be backed by something tangible and to collect 
potential users and remarks, as the ones of Romain. In this context, I 
just gave a hint to Romain as how he could hack a bit, in absence of the 
mlis he was searching for.

   Benjamin.

On 06/02/2014 17:07, Benjamin Canou wrote:
> Le 06/02/2014 14:06, Daniel Bünzli a écrit :
>> As soon as I see a lack of mli files in a published package, I 
>> disregard. I equate it with lack of design.
> Well, I'm very, very sorry that I disappointed you, my lord.
> But do not be worried, I shall compose an mli when comes the time, for 
> I would cherish your blessing upon my modest package.
>
> Cheers,
>
>   Benjamin.

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

[Daniel Bünzli]

Le vendredi, 7 février 2014 à 02:36, Benjamin Canou a écrit :

> It seems that my faux olde english is quite poor, and that my message
> reads as an angry attack at Daniel for some people.  

Actually it was not taken as such. I even found it mildly funny; it's true that the last comment of my earlier message was a little bit dry. But I'm already annoyed when people don't document their stuff, so I get even more annoyed if they don't write a mli file which is the primitivest form of documentation.  

Have a good day,  

Daniel

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

[Pierre-Étienne Meunier]

Thanks OCamlPro for making things move forward in the ocaml ecosystem!

However, what is the difference between new backends, and using llvm?
If it results in a clear, well-documented API for the ocaml compiler, that allows to write things like js_of_ocaml as a standalone executable linked with the “Ocamlc API”, I see why it is cool.

Pierre-Étienne Meunier


Em 05/02/2014, à(s) 18:31, Fabrice Le Fessant <fabrice.le_fessant@ocamlpro.com> escreveu:

> 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
> -- 
> Fabrice LE FESSANT
> Scientific Advisor, OCamlPro SAS
> 
> -- 
> 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

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

[Alain Frisch]

On 02/06/2014 11:53 AM, Pierre-Étienne Meunier wrote:
> However, what is the difference between new backends, and using llvm?

Since this work is done by OCamlPro on behalf of LexiFi, let me answer 
this one. This current project is much less ambitious than switching to 
llvm.

Some context: ocamlopt generates machine code by producing some textual 
assembly code and calling an external assembler (gas or masm) to produce 
object files.  The assembly code is produced directly from an 
higher-level intermediate representation defined in 
asmcomp/linearize.mli (which represents a list of pseudo-instructions). 
  The mapping from this representation to assembly language contains 
some logic such as picking concrete opcodes (including special cases 
such as a simplified jump for a self tail-call), maintaining the current 
stack offset, taking into account various compilation mode (debug mode, 
fast/compact mode, pic mode), expanding complex pseudo-instructions into 
several actual assembly opcodes (e.g. to compile switches using jump 
tables), sharing floating point literals, etc.

Since two concrete syntaxes of assembly languages (gas/masm) have to be 
supported, this mapping has to be implemented twice for each CPU 
(amd64/emit.mlp + amd64/emit_nt.mlp, and same for i386/), which adds 
burden when this code evolves (and it still does quite often).

So the project is to add an extra intermediate language between 
linearize.mli and textual assembly language.  This new representation 
can be seen as a symbolic representation of machine code or an AST of 
the generated assembly language.  This will allow to share most code 
from emit.mlp and emit_nt.mlp.  Two "printers" from this new 
representation to source assembly language will be implemented.  In 
addition to reducing the maintenance overhead and reducing the risk of 
having the Windows port lagging behind, this will bring a few more 
advantages:

  - It will be quite easy to have a third "printer", which generates 
direct binary machine code instead of source assembly language.  LexiFi 
already uses such binary backends for x86 and amd64, which (together 
with a COFF object emitter) make it possible to have a version of 
ocamlopt under Windows that does not require an external assembler. 
(And this allows our end-user application to compile source OCaml code 
and dynlink it on the fly, without forcing our customers to install any 
toolchain.)  The new project will greatly facilitate the maintenance of 
these direct binary backends (and this is actually LexiFi's primary 
reason for funding this project).  The same backends would actually be 
of interest to other projects, such as the native toplevel or MetaOCaml.

  - Some low-level optimizations could be performed on the new 
representation (typically, peep-hole optimizations).

  - The project will probably make it easier to maintain or experiment 
with new variants of the backends (I'm thinking about the ia32 port from 
the sse2 branch, i.e. a variant of x86 using sse2 instructions for 
floating point arithmetic instead of x87 instructions).



Alain