2002.12.31.txt

Hello,

Here is the latest Caml Weekly News, weeks 17 to 31 December, 2002.
Happy new year !

1) The Use of C--?
2) ocaml embedded scripting language
3) Ensemble version 1.40 released
4) camlgl - OpenGL bindings for OCaml
5) Summary: LablGL vs CamlGL
6) ocamldefun : first release
7) lablgtk, lablgl, lablglut on win32/mingw
8) First alpha release of LablGTK2

======================================================================
1) The Use of C--?
----------------------------------------------------------------------
Jeffrey Palmer asked:

Has been any discussion on the possibility of using C--
(http://www.cminusminus.org) as a compiler back-end for O'Caml? (I took
a look through the archives, but didn't see anything relevant.) I'm not
suggesting that things would be better or worse than they are now, I'm
just interested in the thoughts of the O'Caml team.

Since there's already a back-end that generates very efficient native
code, is there any benefit to moving to this type of model? Are there
specific issues that have been addressed in the existing native code
generator that preclude the use of C--?

Norman Ramsey answered:

> Has been any discussion on the possibility of using C--
> (http://www.cminusminus.org) as a compiler back-end for O'Caml? (I
> took a look through the archives, but didn't see anything relevant.) 

The C-- team are keenly interested in this possibility.  Fermin Reig
wrote some code for OCaml that emits a version of C-- that looks
somewhat different from our current version.  We have hopes of
adapting that in the future, but right now we are more concerned with
getting our C-- to work better.  (Right now it runs hello world on
three platforms, but it doesn't actually do anything useful.)

Dmitry Bely and Fermin Reig pointed out:

Xavier Leroy already expressed his thoughts C--/Ocaml this some time
ago (hint: search for "C--" in the archive):

http://caml.inria.fr/archives/200106/msg00037.html

======================================================================
2) ocaml embedded scripting language
----------------------------------------------------------------------
Eric Merritt asked and Norman Ramsey answered:
(to see the thread in context, point your web browser to:
http://caml.inria.fr/archives/200212/msg00153.html)

> >  It has to do with the type system more then anything
> > else. I use a stack to handle data that the
> > interpreted process is manipulating...
> >
> >  Ok this is all fine and dandy, until a few months
> > from now when I want to add a new type say File of
> > Unix.file_descr. The word implementations to support
> > the new type wouldn't actually be a problem. However,
> > extending the type seems to be impossible.

This is a hard problem, to my knowledge not solved in the literature.
There are instances of interpreters that provide type-extensibility,
but none that also support separate compilation.  We have solved this
problem through some heavy use of ML modules.  I am still working on
the paper that describes this solution.  But you can get some hints
from an unpublished manuscript `Toward A Calculus of Signatures' at
  http://www.eecs.harvard.edu/~nr/pubs/sigcalc-abstract.html
The part you want is the extended example in Section 2.

======================================================================
3) Ensemble version 1.40 released
----------------------------------------------------------------------
Ohad Rodeh announced:

List,
   A new release is now available from the system homepage at
   http://www.cs.cornell.edu/Info/Projects/Ensemble,
enjoy!


  RELEASE_NOTES for Ensemble version 1.40

Author: Ohad Rodeh
Last updated: 19/December/2002

RELEASE_NOTES

  This release primarily solves a long standing problem with the use
of DLLs on win32 platforms. CE was rewritten so as to compiled into a
DLL instead of a static library. Since JNI requires shared libraries,
this finally allows cejava to work on win32 and not just Unix. The
second problem solved in this release is the gossip bug on win32, this
was due to problems with UDP sockets.

The major change in the CE API is in memory allocation
conventions. Instead of the application allocating memory chunks, such
as arrays of destinations and vectors pointing to C-memory chunks, CE
now copies these auxiliary buffers into its own memory areas. This
completely separates the memory areas used by the application and
CE/Ensemble. The only sharing occurs for message bodies which are not
copied. To this end the application must set the message alloc/free
functions used by CE for messages, for example:

    ce_set_alloc_fun((mm_alloc_t)malloc);
    ce_set_free_fun((mm_free_t)free);

will allows messages allocated by the application using malloc to freed
by Ensemble.

The API change would require CE applications to be modified for the new
memory conventions, which is not a "good thing". This was done primarily
to allow using DLLs, where each DLL keeps a private copy of LIBC.
Therefore, memory allocated by one DLL (the application) cannot be freed
by another DLL (CE). In the longer term, it separates the application
and library from each other and should make developement easier. It also
saves allocations for iovector arrays and destination arrays on the
critical message send path.

OCAML COMPILER VERSION
  We are using version 3.06 for this version.

PORTABILITY
  This version was tested on Linux (RedHat 7.1, 7.2, 7.3, i386
  architecture) and   windows XP.

======================================================================
4) camlgl - OpenGL bindings for OCaml
----------------------------------------------------------------------
Nickolay Semyonov-Kolchin announced:

Announcement CamlGL --- OpenGL bindings for Objective Caml

http://www.sf.net/projects/camlgl

Key Features:
- Full OpenGL 1.4 support
- All window system independent ARB extensions supported
- All published NVidia extensions supported (including NV30)
- All ATI extensions supported
- Windows and Linux version
- GLFW bindings
- unsupported Glut and SDL bindings

-----------------------------------------------------------
WARNING

this release was tested under RH8, gcc3.2, NVidia GL 41.91

-----------------------------------------------------------
Details
=======
1. CamlGL loads GL library at runtime. So you can switch between Native/Mesa
without recompiling. (This is currently not supported under Windows)

Gl.set_gl_lib "libGL.so.1"

2. CamlGL uses "plain" naming conversion for functions and enums.

glEnable cgl_lighting; (* glEnable(GL_LIGHTING); *)
glVertex3f 1.0 0.0 0.0; (* glVertex3f(1.0f,1.0f,1.0f); *)
glColor3b 255 255 255; (* glColor3b(255,255,255); *)

3. CamlGL uses Bigarray module for array representation.

let a = Hgl.ba_float_init [|1.0;0.0;3.0|] in
glVertex3fv a;
-------------------------------------------------------------
Notes
======
1. GL_ALL_ATTRIB_BITS

GL_ALL_ATTRIB_BITS declared as 0xFFFFFFFF in NVidia header.
Mesa defines it as 0xFFFF.
We are using Mesa constant.

2. GL_ALL_CLIENT_ATTRIB_BITS and GL_CLIENT_ALL_ATTRIB_BITS

Declared as 0xFFFFFFFF. We are using 0x3FFFFFFF.

3. Functions with standard type string

glGetString: int -> string
glLoadProgramNV: int -> int -> int -> string -> unit
glProgramNamedParameter4{fd}[v]NV: int -> int -> string -> ... -> unit
glGetProgramNamedParameter{fd}vNV: int -> int -> string -> 'a -> unit
glProgramStringARB: int -> int -> int -> string -> unit

4. GL_NV_vertex_array_range

VAR depends on two window system specific functions:
- {glX,wgl}AllocateMemoryNV
- {glX,wgl}FreeMemoryNV

We provide standard bindings for them:
val _glAllocateMemoryNV: int -> float -> float -> float -> tbabyte
val _glFreeMemoryNV: tbaabstract -> unit

See example in demos/simple/vatest.

5. Unimplemented

glMultiModeDrawElementsIBM
glVertexPointerListIBM
glTexCoordPointerListIBM
glNormalPointerListIBM
glIndexPointerListIBM
glFogCoordPointerListIBM
glEdgeFlagPointerListIBM
glSecondaryColorPointerListIBM
glColorPointerListIBM
glTexCoordPointervINTEL
glColorPointervINTEL
glNormalPointervINTEL
glVertexPointervINTEL
glReplacementCodePointerSUN
glGetPointerv
glMultiDrawElements
glGetVertexAttribPointervARB
glMultiDrawElementsEXT
glGetPointervEXT
glGetVariantPointervEXT
glGetVertexAttribPointervNV
glLoadIdentityDeformationMapSGIX
glDeformSGIX

6. Extensions not supported

ARB_pbuffer
ARB_render_texture

======================================================================
5) Summary: LablGL vs CamlGL
----------------------------------------------------------------------
Following the previous message, several comments were posted on the
list (thread start: http://caml.inria.fr/archives/200212/msg00199.html),
resulting in the following summary by Nickolay Semyonov-Kolchin:

Now we have comments from both authors.

Summary:
- LablGL is type-safe, CamlGL is not. 
- LablGL support OGL 1.1, CamlGL support OGL 1.4 with extensions (most
important: shaders [NV,ATI,ARB]).
- LablGL support GLU 1.2, CamlGL has no GLU support.
- LablGL is better for beginners, CamlGL is better for people with prior OGL
knowledge.
- LablGL uses Raw module, CamlGL uses Bigarray.
- LablGL support all Ocaml platforms, CamlGL support only Windows (VC) and
Linux.
- LablGL is better tested.

Everything mentioned?

======================================================================
6) ocamldefun : first release
----------------------------------------------------------------------
Julien Signoles announced:

I'm happy to announce the first release of ocamldefun, a defunctorizer
tool for Objective Caml.

ocamldefun takes as input an ocaml program and it unfolds the functor
applications of this program in order to :
        - gain execution time
        - ease the job of static analysis tools.

More information are given on the web page dedicated to ocamldefun :
        http://www.lri.fr/~signoles/ocamldefun/index.en.html

You can contact me for bug reports and/or feedbacks at the following
adress :
        Julien.Signoles@lri.fr

======================================================================
7) lablgtk, lablgl, lablglut on win32/mingw
----------------------------------------------------------------------
SooHyoung Oh announced:

If you want to use ocaml lablgtk, lablgl, lablglut bindings on win32/mingw,
please visit http://www.taglib.co.kr/ocaml/win32.html .

It includes
- lablgtk on win32/mingw: with some screen shots
- lablgl on win32/mingw without labltk, togl
- lablglut on win32/mingw: with some screen shots

Wish list
- gtkglarea

then added:

I put lablgtk win32/mingw version 0.2 just now in the page.
You can find native code related stuffs (cmxa, ...) and examples in it.

Dmitry Bely remarked:

BTW, I am bulding both Ocaml and lablgtk with gcc 3.2/mingw (with
-mno-cygwin -mms-bitfields) without a problem. So you probably should
mention gcc 3.2 as a supported compiler in your docs.

======================================================================
8) First alpha release of LablGTK2
----------------------------------------------------------------------
Jacques Garrigue announced:

As promised, here is a

    First alpha release of LablGTK2, an interface to GTK2

GTK2 represents a new step for GTK, with full internationalization,
and decent text and tree widgets (at last!)

LablGTK2 is still experimental code, many new methods are not
interfaced, and for the interfaced ones the API may change. However
curious people may get a look at it, report bugs and make requests.  

What is done:
  * signals work (using the new calling scheme)
  * the new text widget is interfaced (thanks to Benjamin Monate)
  * conversion functions are provided to and from Utf8 (used
    internally by GTK2)
  * gdkpixbuf is included

What is not done:
  * the new tree and list widgets are not interfaced
  * many methods are missing, or not accessible due to API changes
  * extensions (gtkgl, glade, gtkxmhtml) are not supported yet
  * not tested on windows (but should work with minimum effort)

As usual you may find it at

   http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html

======================================================================
Old cwn
----------------------------------------------------------------------

If you happen to miss a cwn, you can send me a message
(alan.schmitt@inria.fr) and I'll mail it to you, or go take a look at
the archive (http://pauillac.inria.fr/~aschmitt/cwn/). If you also wish
to receive it every week by mail, just tell me so.

======================================================================

Alan Schmitt