[Caml-list] First alpha release of LablGTK2

[Caml-list] First alpha release of LablGTK2

[Jacques Garrigue]

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

And my best wishes for the coming year,

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] about optionnal argument ?

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

I wonder why optionnal argument are implemented through the option type instead 
of giving a defauklt value ?

Obviously the type should carry the default value which should be a closed 
constant (like None, 0, 0.0, [1;2;3], etc ...) but this would preserve the 
possibility of using optionnal arguments and unboxed int or float arguments
and it will save the None/Some test !


-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] about optionnal argument ?

[Jacques Garrigue]

From: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>

> I wonder why optionnal argument are implemented through the option
> type instead  of giving a default value ?
> 
> Obviously the type should carry the default value which should be a closed 
> constant (like None, 0, 0.0, [1;2;3], etc ...) but this would preserve the 
> possibility of using optionnal arguments and unboxed int or float arguments
> and it will save the None/Some test !

There are several reasons to use optionals rather than defaults.
One is semantical: the meaning of defaults is quite clear with
second-class functions, much less with first-class ones.  If we want
to keep an untyped semantics, your idea of putting the default in the
type is not satisfactory. It would also have other implications: if I
have a list of functions taking optional arguments, does it mean that
they should all have the same defaults?
The optional approach appears to be a nicer fit for first-class
functions: it is not by chance that common lisp has the same
approach.  It is also more expressive: the default value may depend on
the other arguments.

>From the implementation point of view, default arguments with
first-class functions would be also cumbersome: either we depend
strongly on types, and allow to write arbitrary values in types (not
only simple ones, functions too!), or we must think of a way to put
the defaults arguments in the closure when needed. Hairy.

All-in-all, deriving default arguments from optionals is much simpler,
and the extra cost generally doesn't matter.
But you have a good point that if a function is very simple
(arithmetic or data copying) and called very often, then using
optionals with it is maybe not such a good idea. The overloading of
glVertex is a bit of an overkill anyway.
I don't know how glVertex is implemented on the C side, but if it is
only copying its data to a queue, then we may want to optimize the
marshalling.  But again it depends how your data was layed out
originally: if it is in a table, the vector form is best as no copy is
needed. If you have to compute it for each call, then the flat unboxed
calls are best.

Regards,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] about optionnal argument ?

[Nickolay Semyonov-Kolchin]

On Friday 27 December 2002 20:11, Jacques Garrigue wrote:
> I don't know how glVertex is implemented on the C side, but if it is
> only copying its data to a queue, then we may want to optimize the
> marshalling.  But again it depends how your data was layed out
> originally: if it is in a table, the vector form is best as no copy is
> needed. If you have to compute it for each call, then the flat unboxed
> calls are best.
>

This discussion is pointless. There will be almost no perfomance gain after 
gl[Vertex,Normal,Color,etc] call optimization. Immediate mode is slow by 
design. One must use "Vertex Arrays" instead. VAR/VAO will give even more 
speedup.

Nickolay
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners