No subject
Tue Jan 7 01:15:04 PST 2014
ic-multicast/diff>
## core_bench
- Added support for saving inline benchmark measurements to tabular
files for easy loading into Octave.
## core_extended
- Cleaned up the `Stats_reporting` module
## core_kernel
- Moved all of the `Gc` module into `Core_kernel`.
Part of the `Gc` module used to be in `Core` because it used
threads. But it doesn't use threads anymore, so can be all in
`Core_kernel`.
- Made `Stable.Map` and `Set` have `with compare`.
- Added `String.rev`.
Closes janestreet/core#16
We will not add `String.rev_inplace`, as we do not want to encourage
mutation of strings.
- Made `Univ_map.Key` equivalent to `Type_equal.Id`.
- Added `Univ.view`, which exposes `Univ.t` as an existential, `type t
=3D T : 'a Id.t * 'a -> t`.
Exposing the existential makes it possible to, for example, use
`Univ_map.set` to construct a `Univ_map.t`from a list of `Univ.t`s.
This representation is currently the same as the underlying
representation, but to make changes to the underlying representation
easier, it has been put in a module `Univ.View`.
=20=20=20=20=20=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2) wrapping a string in an in_channel
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00003.html>
------------------------------------------------------------------------
** Martin DeMello asked and Gerd Stolpmann replied:
> Does OCaml have any equivalent to ruby's StringIO, to wrap an
> in_channel around a string and then treat it as if it were a file?
With the standard library this is not possible.
When I need such a feature, I normally use OCamlnet's channel objects:
<http://projects.camlcity.org/projects/dl/ocamlnet-3.7.3/doc/html-main/Netc=
hannels_tut.html>
<http://projects.camlcity.org/projects/dl/ocamlnet-3.7.3/doc/html-main/Netc=
hannels.html>
<http://www.ocaml-programming.de/rec/IO-Classes.html>
=20=20=20=20=20=20
** Hezekiah M. Carty also suggested:
Batteries provides something similar with its BatIO.input_string
function. It returns the Batteries equivalent to an in_channel.
=20=20=20=20=20=20
** John Whitington also suggested:
Here's another example of wrapping IO around strings, bigarrays, etc as
a record of functions:
<https://github.com/johnwhitington/camlpdf/blob/master/pdfio.ml>
Here's a type:
type input =3D
{pos_in : unit -> pos;
seek_in : pos -> unit;
input_char : unit -> char option;
input_byte : unit -> int;
in_channel_length : pos;
set_offset : pos -> unit;
caml_channel : in_channel option;
source : string}
It's good to add the 'source' field - which is an arbitrary string for
debugging purposes. Of course, if the input came from a file, we would
use the file name.
The caml_channel field optionally stores a channel this input was
derived from. So, we can still drill down and use fast functions from
the standard library such as Pervasives.really_input.
(The set_offset field is a nasty PDF-related hack: a PDF file can have
garbage bytes preceding the header, and PDF absolute byte offsets are
offsets from the header, so every read and write might have to be
offset)
Functions in records as an abstraction don't seem to be a speed problem.
The use of option-returning functions like input_char above rather than
exception-raising ones or minus-one-as-exception functions like
input_byte above is big, though, if the data processed is large enough,
due to garbage collection.
=20=20=20=20=20=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
3) OpenGL {3,4} and OpenGL ES {2,3} bindings, testers welcome
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00008.html>
------------------------------------------------------------------------
** Daniel B=C3=BCnzli announced:
I made thin, low-level, ocaml-ctypes bindings to OpenGL 3.{2,3},
4.{0,1,2,3,4} and OpenGL ES {2,3}. They are automatically generated
from the offical XML representation of the OpenGL Registry [1].
These bindings are neither tested nor used and interfaces are still
subject to change. Testers are welcome; report any problems you may
encounter on github's infrastructure. Have a look at the readme to
understand how these libraries are structured:
<https://github.com/dbuenzli/tgls/blob/master/README.md#supported-opengl-=
versions>
The documentation of the bindings is here:
<http://erratique.ch/software/tgls/doc/>
To install (only tested on osx with OpenGL 3.2 and linux or raspberry=20
pi with OpenGL ES 2 so far) you'll need `curl` and `xmlm` installed on=20
your system. This is only for this pre-release, actual distribution will
have the generated bindings. Then:
opam repo add erratique-u <http://erratique.ch/software/opam/unreleased>
opam update && opam install xmlm tgls
Sample code (needs tsdl, `opam install tsdl`), is in the directory=20
`opam config var tgls:doc`.
If you want to hack the source first have a read at:
<https://github.com/dbuenzli/tgls/blob/master/DEVEL.md>=20
then:
git clone <http://github.com/dbuenzli/tgls>=20
cd tgls && ./build support && ./build trigl3.native && ./trigl3.native
A few notes:
* This time the cryptic acronym is [T]hin bindings to Open[GL] librarie[S].
No need to waste everybody's time with alternate name suggestions:
it won't change.=20
* ocaml-ctypes was used as this was the shortest path to get the
work done, using it should also solve the problem of getting the
OpenGL function pointers. However the support for reading and making
sense of the OpenGL registry being done, regular OCaml stubs could
also be generated in the future if ctypes turns out to be a
bottleneck.
* There's one OCaml library per major OpenGL release (which correspond
to GPU hardware generations). Such a library has all the entry
points and enumerants for supporting all the core (and only core)
profiles of each minor releases of the major release. If you are
programming with let's say 4.3 context it's your duty not to use a
4.4 entry point/enumerant.
* I tried to include the C OpenGL libraries link flags in the OCaml ones
so that OCamler's can just use the package with ocamlfind to
build. Please report anything that may be missing. The current logic
is as follows. On Darwin for tgl{3,4} we link against the OpenGL
framework and nothing is done for tgles{2,3}. On linux pkg-config is
used when packages can be found: gl for tgl{3,4}, glesv2 for tgles2
and glesv3 (does that exist ?) for tgles3. Raspberry pi is like
linux but tgles2 links to the pi's GLESv2 library located in
/opt/vc/lib (would be nice from them to use pkg-config).=20
* A single type represents all GLenums. Types for subsets could=20
be devised to enhance the signature/documentation of functions. This
was not done for now since it seems the data from the registry is
not clean/up to date (according to the registry's manual). However,
the documentation links to the entry point's documentation and
indicates the name of argument variables which should help to invoke
the functions correctly (could have automatically derived labelled
arguments but I thought that doing so systematically would result in
a cumbersome API).
* The binding is very raw and can be unsafe. It could
be made safer by either:
1) Making more manual work, checking some bounds, automatically
deriving some arguments for sizes. Doing that automatically in
general is non trivial: for OpenGL 4.4 there are ~300 out of ~550
entry points with pointer arguments, the registry has an
attribute that should describe how the length of the pointer is
to be determined but according to the registry's manual its
syntax is poorely defined.
2) Devising higher-level APIs that ensure type safety.=20
I tend to lean in favour of 2) OpenGL being so low-level and
tiresome (rendering a colored triangle in "modern" OpenGL is a few
hunderds of loc) that you'll anyway build an abstraction
(a.k.a. rendering engine) on top of it.
* Binding generation is almost entirely automatic and type directed.=20
At the moment for OpenGL 4.4 there are only 7 out of 543 entry
points that are manually devised. One thing that did require manual
work though, was to enrich the registry information to indicate
whenever null pointers can be specified for pointer arguments to map
them to option types as the registry does unfortunately not specify that.
* There's no direct for support compatibility profiles or extensions.=20
Nowadays it's easy enough to use directly ocaml-ctypes (extensions
usually add only a few entry points and/or enumerants). Alternatively=20
tgls' generation infrastructure could be used as the extensions are also=
=20
described in the registry but that may be overkill (some steps have been=
=20
done in that direction but it's not a priority right now for me).
I hope tgls can be a good starting point to get up to date OCaml
OpenGL bindings as work for supporting new versions should be minimal
provided they update the XML registry (which they should do since they
use it to generate the C headers). A first release will be done in a
few months, after the bindings will have been used a little bit by
myself. Meanwhile your feedback is welcome.=20
Best,
Daniel
[1] <http://www.opengl.org/registry/#specfiles>
=20=20=20=20=20=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
4) How to see an OCaml change in a browser
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-01/msg00014.html>
------------------------------------------------------------------------
** Jakob Lichtenberg asked and Jeremy Yallop replied:
> How can I look at source code change for:
>
> PR#5312: command-line arguments @reponsefile auto-expansi=
on
> feature
>
> In a web browser?
You can find it here:
<https://github.com/ocaml/ocaml/commit/8c9ef9f24>
(Searching for the PR number by running 'git log --grep=3D5312' in a
clone of the OCaml repository returns the revision number, 8c9ef9f24.)
=20=20=20=20=20=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5) Other OCaml News
------------------------------------------------------------------------
** From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the OCaml Weekly News the links to =
the
recent posts from the ocamlcore planet blog at <http://planet.ocaml.org/>.
OCaml: the bugs so far:
<http://roscidus.com/blog/blog/2014/01/07/ocaml-the-bugs-so-far/>
When QuickCheck Fails Me:
<http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/quickcheck_fail.=
html>
Presenting Decks:
<http://openmirage.org/blog/decks-n-drums>
Fedora 21 has a working OCaml ARM64:
<http://rwmj.wordpress.com/2013/12/31/fedora-21-has-a-working-ocaml-arm64=
/>
=20=20=20=20=20=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Old cwn
------------------------------------------------------------------------
If you happen to miss a CWN, you can send me a message
(alan.schmitt at polytechnique.org) and I'll mail it to you, or go take a look=
at
the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the
archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
More information about the caml-news-weekly
mailing list