Re: [MirageOS-devel] Unix.tm, CLOCK: date handling in MirageOS

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

Le lundi, 22 juin 2015 Ã 16:50, Anil Madhavapeddy a Ãcrit :
> > An alternative would be to extract a Bos.OS.Time as an independent module 
> > Ptime for POSIX time that just provides what Bos.OS.Time provides [1] along 
> > with the above functions.
>  
> And that would solve the above problem indeed, perhaps with a module alias 
> for the existing Bos.OS.Time module.

If there's enough interest this could be done.

> Do you have any thoughts on the jsoo linking hack that you used in jsont? I 
> liked how I could compile JSON pickler combinators efficiently using the 
> native JSON or Jsonm parsers depending on which OS (Unix vs JavaScript) was 
> in use. I imagine something similar is needed to efficiently pick the best 
> platform clock.  
I don't have these things in my head right at the moment but from what I 
remember:

In fact in jsont and in mtime there's is no backend linking trick. I just 
compile two different library and it's up to you to use the one you want. This 
has the following pluses and minus:

+ Backend-dependent usage by the end user is easy. Just use the package with 
the backend you need. I think this is good for application developers. It also 
works well for mixed backend projects like jsoo projects often are: browser 
client/server. In the jsont case it's especially nice since your data 
descriptions can be shared by the client/sever part and simply recompiled and 
linked against the appropriate backend package (but doing that with our current 
build tools is not entirely nice).

+ Implementation is straightforward. Especially if you have backend dependent 
functions.  

- Build-wise you need to symlink the common interface and sources common to the 
two libraries. However it creates all kinds of problems with tools like 
ocamlbuild whose project's parts build isolation cannot be expressed by _tags 
files without leading to all kinds of problems. See the comments in mtime's 
_tags file, which means that actual build invocation need to be backed by 
appropriate -I flags:

https://github.com/dbuenzli/mtime/blob/bf5326497cd929e4e162cbf631c380f84a1f9177/_tags
https://github.com/dbuenzli/mtime/blob/bf5326497cd929e4e162cbf631c380f84a1f9177/build#L19-L20

Still, symlinking things in your sources is a little bit awkward, ugly and 
Windows unfriendly. A decent build system should allow us to mix and match 
sources into well isolated silos for compiling. This means moving away of the 
"your build tree" is a replica of your source tree. While this does have 
disadvantage â e.g. makes it less straightfoward to understand what happens: 
you always need to understand the build description of the project as the 
source tree no longer necessarily hints at the build products; it will also 
certainly create problems with tools like merlin â but I still think it's the 
way to go.

- It is not possible to code a library that is backend independent and uses the 
common interface abstractly (by cmx hiding). This means even if your library 
doesn't use backend dependent functions you will have to provide a version of 
your library for each of the original library backends. OTOH if you build 
system easily allows you to mix and match sources, it can make the creation of 
each of these versions relatively painless.  

In a library like useri there is a backend linking trick. This has the 
following pluses and minuse:

- Backend-dependent usage is slightly tricky, you first have to link-in the 
backend specific package and then the package that has the common part. The 
order is important and you need to specify two names.  

- Implementation may not be straightforward if you have backend dependent 
functions. IIRC I had to resort to universal types in order to store backend 
specific handles in the common data type.

- Build system is as fucked up as above.

+ It is possible to code libraries that are backend independent by just linking 
against the common interface but OTOH you loose inlining (cmx hiding).

In the end I think there are still less issue if you don't use backend linking 
tricks and go the jsont and mtime route, but we should certainly discuss this 
further at some point.  

> If only we had a build system that could deal with all these permutations :)
One can dream...

Best,

Daniel



_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel