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 6365F7EE51 for ; Fri, 10 May 2013 17:48:48 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of monnier.florent@gmail.com) identity=pra; client-ip=209.85.212.169; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="monnier.florent@gmail.com"; x-sender="monnier.florent@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of monnier.florent@gmail.com designates 209.85.212.169 as permitted sender) identity=mailfrom; client-ip=209.85.212.169; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="monnier.florent@gmail.com"; x-sender="monnier.florent@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-wi0-f169.google.com) identity=helo; client-ip=209.85.212.169; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="monnier.florent@gmail.com"; x-sender="postmaster@mail-wi0-f169.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMBAPMVjVHRVdSpjWdsb2JhbABSgz7AG3QIFg4BAQEBBwsLCRIGJIIfAQEEAUABGx0BAwELBgULOyIBEQEFARwGiAwBAwkGoF2MPYJ+hF4KGScNWIcuAQUMjWt+MweDVQOXLI9QFimENzo X-IPAS-Result: AtMBAPMVjVHRVdSpjWdsb2JhbABSgz7AG3QIFg4BAQEBBwsLCRIGJIIfAQEEAUABGx0BAwELBgULOyIBEQEFARwGiAwBAwkGoF2MPYJ+hF4KGScNWIcuAQUMjWt+MweDVQOXLI9QFimENzo X-IronPort-AV: E=Sophos;i="4.87,648,1363129200"; d="scan'208";a="13836418" Received: from mail-wi0-f169.google.com ([209.85.212.169]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 May 2013 17:48:47 +0200 Received: by mail-wi0-f169.google.com with SMTP id h11so855881wiv.4 for ; Fri, 10 May 2013 08:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=JDUBcsZxGN8+75YlYIzD2a300PXktsZdNLeX7sR0tKo=; b=fVxv3gimBTBUAT8tPKMfzi5crYwOlsIC8f556vc/omRpKJ1FB2+4f5VwtwYt7DB/uG K6NjvjilburFEm7zj7BYR/APAZAmrmi54ErZ8QsMYBMxLbk1fb9iyzlncniSieVuWhNN +oKtsdalQ+JghdAb0rmiezSfSd/7QBu3n9bFrI4wIk58UOiNJ/FWi/9ZX94zU1InKsjg rS+FOx0xTzZJ942eYn0/DzWZN21Dqeu1mgo5XiVkXuFr9SHw3R1dFuLywlJnA6MlZRaS wRnB8lmKzU9YFTPgNSNavaQOZIF5YIelaFnJlewDSFl1h3LQ6+v0v+mf1qaNThy7arU1 ygYg== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr4866232wid.4.1368200927308; Fri, 10 May 2013 08:48:47 -0700 (PDT) Received: by 10.194.133.133 with HTTP; Fri, 10 May 2013 08:48:47 -0700 (PDT) In-Reply-To: References: <5WRK1WTA-CFLT-K2D2-HI4C-UBS0MHNSFIAY@cs.ucy.ac.cy> <5189B929.2030808@riken.jp> Date: Fri, 10 May 2013 17:48:47 +0200 Message-ID: From: Florent Monnier To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: ocaml-opengl , Caml List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Validation-by: monnier.florent@gmail.com Subject: Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml 2013/5/10, Daniel B=FCnzli: >> 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 deconstruct= ing > 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 do understand. But what I was trying to explain is that I usually have 2 or 3 or even more modules/components/libs each using 3D coordinates. Then it is easy to exchange values that are (float * float * float). Anything else makes things difficult for exchanges and needs to be converte= d. >> I appreciate the grey background. > > In my browser the background is white. In fact I now see that the backgro= und > of the body is transparent in the stylesheet so that gray must be a defau= lt > value in your browser... Indeed, your page is the first one I see with transparent background. It is not recommended to define text color without background color. If the default browser background color is black one would see nothing. >> 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 c= ase > you'd like to (even with the deranged power of css). I know, this is the same for me. > 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 sensit= ive > 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. I was thinking to group html api-docs of many libs together (and maybe even keep all recent versions of the libs) with a css switcher (probably hosted on the ocaml forge). I even thought about a name like "ocamldoc-zen-garden" (inspired from "css-zen-garden"). What would you think about such an idea? >> 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. I would enjoy to know which of these you are considering. [...] > [2] http://www.flong.com/texts/code/ A very good link, thanks a lot! There's a huge amount of content, could you share which you think would be the more interesting for reuse in OCaml? > 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 eventua= lly > thought it was more consistant and less bureaucratic to have everything > together. It seems logic to me to do it the way you've made it. I would only comment that if you add Sizes, BBoxes, then why not also bounding-cirlces / bounding-spheres, complete math for geometry with points, lines, planes, etc. (distances, intersections, projections, etc.) The internal representations for vectors and points are not public, which would imply to integrate these inside your module. Would you accept pull requests for these, or you want to keep the current minimalism? > I dislike libraries that give aliases for the same things. It puts a usel= ess > 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) beca= use > I like code compactness and stick to 80 columns. Maybe a compromise could be found, between one letter function names: Size3.w Size3.h Size3.d and complete names: Size3.width Size3.height Size3.depth could be 3 letters abbreviations: Size3.wid Size3.hei Size3.dep I would recommend not to assume that everyone share the same cognition and tastes than you. --=20 Regards