caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
To: Florent Monnier <monnier.florent@gmail.com>
Cc: ocaml-opengl <opengl@lists.ocaml.org>, Caml List <caml-list@inria.fr>
Subject: Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml
Date: Thu, 9 May 2013 23:01:53 +0100	[thread overview]
Message-ID: <B6E4B1B39BFF47FBB5BAFF66F0415A1A@erratique.ch> (raw)
In-Reply-To: <CAE1DttDjV7TPyJbHEi37_77su39-LkdtZiQ=utv9mFQBcmdRMw@mail.gmail.com>

Thanks for your comments. A few answers. 

> But I don't like it for xy or xyz triples. I prefer tuples for this
> because it makes it more easy to exchange data between different ocaml
> components and modules. For these I usually prefer something easy to
> exchanges between different ocaml modules than something easy to
> exchange with C. 


It's not only about C, it's also about avoiding boxed representations to reduce memory usage and provide more memory locality. I agree deconstructing these values is more painful than tuples but I hope this encourages you to perform computations vector-wise rather than coordinate-wise -- the implementation of gg does the latter so that its users can work as much as possible vector-wise with reasonable performance, falling back to coordinate-wise computations only in bottlenecks.

> I've also started to play with OpenCV.
> If you have things to share in OCaml I would enjoy to see it, even if
> it's alpha.


Nothing on that front. 
 
> I appreciate the grey background.


In my browser the background is white. In fact I now see that the background of the body is transparent in the stylesheet so that gray must be a default value in your browser...

> What is the license of your CSS, is it the same than your libs?
 
Yes feel free to reuse the stylesheet. Maintaining it is a little bit annoying as ocamldoc's markup tend to change from one version to the other and it's still hard to style because of formatting instructions in the markup and generation patterns that disallow you to distinguish certain case you'd like to (even with the deranged power of css). 

Myself I hope I can eventually drop that in favour of what is happening around opam doc in the OCaml platform [1]; provided they provide a sensitive stylesheet, which for me means reasonably dense vertically, not too wide horizontally and good use of white space instead of box disease -- blame the css border property for that.  

> But if I build the docs from the sources it falls back to default
> ocamldoc's css with plain white uncomfortable background.


Use ./build doc in the distribution to build with the stylesheet.
 
> Also you're providing only linear interpolation.
> Is it that you're not using easing, or is it that you're using another
> module for it?


For now I decided to leave that out of the library. I think there are many ways you'd like to do that depending on the context (e.g. see the links to shaping functions at the bottom of this page [2]). Since I was doubting I left it out. 

The goal of gg is also the keep a certain minimalism -- in fact I was even tempted to split the 2D from the 3D using the module language but eventually thought it was more consistant and less bureaucratic to have everything together.

> Another thing that is only a question of taste, I would enjoy if there
> would be aliases for the functions Size*.d w h with words entirely.
> Sometimes the more readable is the shorter, some other times the
> entire word will help understand what it is. So with aliases we can
> choose what is the more pertinent for the situation.


I dislike libraries that give aliases for the same things. It puts a useless cognitive burden on code readers which have to remember that there are two ways of naming the same thing and it results in inconsistant library usage style. I usually go with shorter names (sometimes too short I agree) because I like code compactness and stick to 80 columns.

Best,

Daniel

[1] http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/platform.html#OPAM Doc (http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/platform.html#OPAM%20Doc)
[2] http://www.flong.com/texts/code/



  reply	other threads:[~2013-05-09 22:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-07  7:04 [Caml-list] ECSCW 2013: Call for Work-in-Progress Announce Announcements
2013-05-08  2:32 ` [Caml-list] standard 3d vector library in OCaml Francois Berenger
2013-05-08 13:55   ` Florent Monnier
2013-05-09 10:23     ` Daniel Bünzli
2013-05-09 20:27       ` [ocaml-opengl] " Florent Monnier
2013-05-09 22:01         ` Daniel Bünzli [this message]
2013-05-10 15:48           ` Florent Monnier
2013-05-10 17:01             ` Daniel Bünzli
2013-05-10 17:11               ` Anthony Tavener
2013-05-10 10:15       ` rixed
2013-05-15  1:08     ` Francois Berenger
2013-05-10  2:10   ` Francois Berenger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B6E4B1B39BFF47FBB5BAFF66F0415A1A@erratique.ch \
    --to=daniel.buenzli@erratique.ch \
    --cc=caml-list@inria.fr \
    --cc=monnier.florent@gmail.com \
    --cc=opengl@lists.ocaml.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).