Nabble - Caml Discuss

Re: Re: Serialisation of PXP DTDs

2008-10-23T15:50:51Z

On Fri, Oct 24, 2008 at 12:18:50AM +0200, Gerd Stolpmann wrote:

>
> Am Donnerstag, den 23.10.2008, 23:05 +0200 schrieb Mauricio Fernandez:
> > I have been working for a while on a self-describing, compact, extensible
> > binary protocol, along with an OCaml implementation which I intent to release
> > in not too long.
> >
> > It differs from sexplib and that bin-prot in two main ways:
> > * the data model is deliberately more limited, as the format is meant to be
> > de/encodable in multiple languages.
> > * it is extensible at several levels, achieving both forward and backward
> > compatibility across changes in the data type
> >
> > You can think of it as an extensible Protocol Buffers[1] with a richer data
> > model (albeit not in 1:1 accordance with OCaml's for the above mentioned
> > reason).
>
> Have you looked at ICEP (see zeroc.com)? It has bindings for many
> languages, even for Ocaml (http://oss.wink.com/hydro/).
>
> It is, however, not self-describing. Anyway, you may find there ideas
> for portability.

I've just taken a quick look at the manual (in particular, the definition of
the Slice language and the Data Encoding section of the Ice protocol). Even
though it solves a different problem, it looks very interesting --- both as a
source of inspiration, as you say, and for its intended use as a middleware
technology. Thanks a lot for the reference.

Regards,
--
Mauricio Fernandez - http://eigenclass.org

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [OSR] Exceptionless error management

2008-02-05T03:36:48Z

Bünzli Daniel wrote:
> Still I think this is a little bit sad. Using polymorphic variants
> isn't that bad at all as long as we just use the following _closed_
> type [ `Value of ... | `Error of ... ]. This would allow us to move
> forward despite that fact that Pervasives is frozen (and no I'm not
> interested in forking it).
But Pervasives is not *that* frozen. If I understand things well, the
main concern of Inria is having to maintain the would-be additions and
changes to Pervasives. An Ok | Error variant doesn't look like it will
entail heavy maintenance charges. So they may accept to add it.

(I don't think there are backwards-compatibility problems either as
user-defined Ok|Error would hide a Pervasives-defined one in all
contexts I can think of.)

Frédéric

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Interface manipulation patches

2007-07-18T11:18:05Z

Le 18 juil. 07 à 16:24, Chris King a écrit :

> Back in December Piotr Wieczorek sent a couple patches for the O'Caml
> compiler to the mailing list [1]. They dealt mostly with manipulating
> interfaces, in particular adding the ability to
>
> 1) "export" a module when packing
> 2) treat .cmis as module types
> 3) import interfaces sans selected fields
> 4) retype .cmo files
>
> These patches are great for a library developer... in the library I am
> currently developing (O'Caml RT) I have an immediate use for (1), (3),
> and (4), and I have had a need for (2) in the past.
>
> I'm wondering if these patches have been considered for inclusion in
> the official O'Caml tree, and, if not, what it would take to get them
> included.

Would be very nice indeed ! I love (3)...

--
Vincent Aravantinos
PhD Student in Computer Science
LIG - CAPP Team

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Functors and sharing a symbol table between a Menhir parser and ocamllex lexer

2007-05-01T04:34:48Z

I want to pass a symbol table to my Menhir parser since I want to run
several parsers in parallel and don't want any shared state.

I have this in the header of my ocamllex lexer:

module P = EasyParser.Make
(
struct
type t = EasySymtab.symtab_t
let putsym = EasySymtab.putsym
let infer_type = EasyCheck.infer_type
let symtype = EasyCheck.symtype
end
)

rule token tab = parse
...

Above are functions that take a symbol table as their first argument
and the lexer (token) takes the symbol table as well.

In my parser test harness I have:

let parse str =
let lexbuf = Lexing.from_string str in
let ast = EasyLexer.P.program (EasyLexer.token (symtab ())) lexbuf in
List.map EasyLocStrip.strip_stmt ast

How do I ensure that the lexer and the parser use the same symbol table?

I thought I could parameterize the parser on curried functions like
"putsym tab" but then how do I make sure that all functions in Make
above take the same tab?

If that works than I need to ensure that EasyLexer.token in my parse
function takes the same tab that was used by EasyParser.Make.

Any suggestions?

Thanks, Joel

--
http://wagerlabs.com/

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Fixed GMenu?

2007-03-07T00:42:12Z

Ewen Maclean wrote:
> I am currently adding a GMenu.menu_bar to a vbox within a window. The
> problem is that when I resize the window the menu bar also resizes
> proportionately. Is there a way of fixing the height so that it doesn't
> resize when the window resizes?
>
> Many thanks in advance

I do this a little differently - and don't have your problem. I use
add_ui_from_string on a "UI manager" instance (from GAction.ui_manager
()), since building up a menu bar and dropdowns seemed easier this way.

Then I build up an hbox with the resulting menu widget and a couple of
other controls and pack *that* into the vbox, followed by the rest of
my window contents and status bar widget.

In any case, the undesirable menu bar resizing does not occur for me.

Finally, you might check out the LablGTK mailing list (there is one)
in the cc list, as they are a little more focused on things LablGTK.

Robert Roessler
roessler@...
http://www.rftp.com

GtkHRuler and GtkVRuler properties on new widgets

2006-10-06T05:49:32Z

Hi.

I am still working on the port of GtkDatabox to lablgtk. This time I am
having difficults with two properties of the GtkDatabox widget: "hruler"
and "vruler". Probably the difficults come from the fact that lablgtk
does not have one class for each of GtkRuler, GtkHRuler and GtkVRuler,
but only a single class: GRange.ruler.

So far I have the following definitions. Please, look where I have
annoted with the comment (* is this correct? *), and see if I am doing it
right.

(* gtkDatabox.props *)

prefix "Gtk"

header {
type databox_t = [Gtk.drawing_area|`databox]
}

classes {
GtkAdjustment "Gtk.adjustment obj"
GtkHRuler "Gtk.ruler Gtk.obj" (* is this correct? *)
GtkVRuler "Gtk.ruler Gtk.obj" (* is this correct? *)
}

class Databox type "databox_t Gtk.obj" set wrap wrapsig : DrawingArea {
"enable-selection" gboolean : Read / Write
"enable-zoom" gboolean : Read / Write
"hadjustment" GtkAdjustment : Read / Write
"vadjustment" GtkAdjustment : Read / Write
"hruler" GtkHRuler : Read / Write (* is this correct? *)
"vruler" GtkVRuler : Read / Write (* is this correct? *)

signal selection_changed
}

(* gDatabox.mli *)

class databox_signals : 'a Gtk.obj ->
object
inherit GObj.widget_signals
constraint 'a = [> GtkDatabox.databox]
val obj : 'a Gtk.obj
method selection_changed : callback:(unit -> unit) -> GtkSignal.id
end

class databox : 'a Gtk.obj ->
object
inherit GObj.widget
constraint 'a = [> GtkDatabox.databox]
val obj : 'a Gtk.obj
method as_databox : GtkDatabox.databox Gtk.obj
method enable_selection : bool
method set_enable_selection : bool -> unit
method enable_zoom : bool
method set_enable_zoom : bool -> unit
method hadjustment : GData.adjustment
method set_hadjustment : GData.adjustment -> unit
method vadjustment : GData.adjustment
method set_vadjustment : GData.adjustment -> unit
method hruler : GRange.ruler (* is this correct? *)
method set_hruler : GRange.ruler -> unit (* is this correct? *)
method vruler : GRange.ruler (* is this correct? *)
method set_vruler : GRange.ruler -> unit (* is this correct? *)
method event : GObj.event_ops
method connect : databox_signals
end

val databox :
?packing:(GObj.widget -> unit) ->
?show:bool ->
unit ->
databox

(* gDatabox.ml *)

open GObj

open GtkDatabox
open OgtkDataboxProps

class databox_signals (obj : [> GtkDatabox.databox] Gtk.obj) = object
inherit GObj.widget_signals_impl obj
inherit databox_sigs
end

class databox (obj : [> GtkDatabox.databox] Gtk.obj) = object
inherit [_] GObj.widget_impl obj
method as_databox : GtkDatabox.databox Gtk.obj =
(obj :> GtkDatabox.databox Gobject.obj)
inherit databox_props
method event = new GObj.event_ops obj
method connect = new databox_signals obj
end

let databox ?packing ?show () =
let w = Databox.create [] in
pack_return (new databox w) ~packing ~show

Compilation fails with the message:

$ make opt
[...]
ocamlc.opt -I +lablGL -w s -c gDatabox.ml
The implementation gDatabox.ml does not match the interface gDatabox.cmi:
Class declarations do not match:
class databox :
([> GtkDataboxProps.databox_t ] as 'a) Gtk.obj ->
object
val obj : 'a Gtk.obj
method add : graph -> bool
method as_databox : GtkDatabox.databox Gtk.obj
method as_widget : Gtk.widget Gtk.obj
method coerce : GObj.widget
method connect : databox_signals
method destroy : unit -> unit
method drag : GObj.drag_ops
method enable_selection : bool
method enable_zoom : bool
method event : GObj.event_ops
method get_oid : int
method hadjustment : GData.adjustment
method hruler : Gtk.ruler Gtk.obj
method misc : GObj.misc_ops
method private obj : 'a Gtk.obj
method set_enable_selection : bool -> unit
method set_enable_zoom : bool -> unit
method set_hadjustment : GData.adjustment -> unit
method set_hruler : Gtk.ruler Gtk.obj -> unit
method set_vadjustment : GData.adjustment -> unit
method set_vruler : Gtk.ruler Gtk.obj -> unit
method vadjustment : GData.adjustment
method vruler : Gtk.ruler Gtk.obj
end
does not match
class databox :
([> GtkDatabox.databox ] as 'a) Gtk.obj ->
object
val obj : 'a Gtk.obj
method add : graph -> bool
method as_databox : GtkDatabox.databox Gtk.obj
method as_widget : Gtk.widget Gtk.obj
method coerce : GObj.widget
method connect : databox_signals
method destroy : unit -> unit
method drag : GObj.drag_ops
method enable_selection : bool
method enable_zoom : bool
method event : GObj.event_ops
method get_oid : int
method hadjustment : GData.adjustment
method hruler : GRange.ruler
method misc : GObj.misc_ops
method set_enable_selection : bool -> unit
method set_enable_zoom : bool -> unit
method set_hadjustment : GData.adjustment -> unit
method set_hruler : GRange.ruler -> unit
method set_vadjustment : GData.adjustment -> unit
method set_vruler : GRange.ruler -> unit
method vadjustment : GData.adjustment
method vruler : GRange.ruler
end
The method hruler has type Gtk.ruler Gtk.obj but is expected to have type
GRange.ruler
Type Gtk.ruler Gtk.obj = Gtk.ruler Gobject.obj is not compatible with type
GRange.ruler =
< as_widget : Gtk.widget Gtk.obj; coerce : GObj.widget;
connect : GObj.widget_signals; destroy : unit -> unit;
drag : GObj.drag_ops; event : GObj.event_ops; get_oid : int;
lower : float; max_size : float; misc : GObj.misc_ops;
position : float; set_lower : float -> unit;
set_max_size : float -> unit;
set_metric : Gtk.Tags.metric_type -> unit;
set_position : float -> unit; set_upper : float -> unit;
upper : float >
make: *** [gDatabox.cmo] Error 2

I will be grateful for any help on this problem.

Regards,

Romildo

Re: Help on a port of GtkDatabox with lablgtk

2006-10-05T23:53:43Z

From: j.romildo@...

> module T = struct
> type databox = [Gtk.drawing_area|`databox]
> type graph = [`graph]
> type xyc = [graph|`xyc]
> type points = [xyc|`points]
> end
>
> external graph_add
> : [> T.databox] Gtk.obj -> [> T.graph] Gobject.obj -> bool
> = "ml_gtk_databox_graph_add"
>
> class virtual graph (obj : [> T.graph] Gobject.obj) = object
> method as_graph : T.graph Gobject.obj = obj
> end
>
> class xyc (obj : [> T.xyc] Gobject.obj) = object
> inherit graph obj
> end

[..]

> Unfortunatly I was not clever enough to write correct ocaml code, hence
> it is not accepted by the compiler, which says:
>
> $ ocamlopt -I . -c -i databox.ml
> File "databox.ml", line 19, characters 16-19:
> This expression has type ([> T.xyc ] as 'a) Gobject.obj
> but is here used with type T.graph Gobject.obj
> Type 'a = [> `graph | `xyc ] is not compatible with type T.graph = [ `graph ]

You need a coercion in the definition of graph:

method as_graph = (obj :> T.graph Gobject.obj)

Indeed, without this coercion, the polymorphism of the obj parameter
is lost, and the class type of graph would be:

class virtual graph : T.graph Gobject.obj ->
object method as_graph : T.graph Gobject.obj end

which causes your type error.

Jacques Garrigue

Help on a port of GtkDatabox with lablgtk

2006-10-05T15:14:11Z

Hello.

The GtkDatabox library (http://www.eudoxos.net/gtk/gtkdatabox/) defines
the folowing class hierarchy:

GObject
GtkDataboxGraph
GtkDataboxXYCGraph
GtkDataboxPoints
GtkDataboxLines
GtkDataboxMarker
GtkDataboxCrossSimple
GtkDataboxBars
GtkDataboxGrid

GtdDrawingArea
GtkDatabox

The class GtkDatabox has the method add, whose C prototype is

gboolean
gtk_databox_graph_add (GtkDatabox *box, GtkDataboxGraph *graph)

I am attempting to port the library to ocaml using lablgtk (the latest
snapshot: lablgtk2-20060908).

Therefore I have the following definitions in ocaml:

module T = struct
type databox = [Gtk.drawing_area|`databox]
type graph = [`graph]
type xyc = [graph|`xyc]
type points = [xyc|`points]
end

external graph_add
: [> T.databox] Gtk.obj -> [> T.graph] Gobject.obj -> bool
= "ml_gtk_databox_graph_add"

class virtual graph (obj : [> T.graph] Gobject.obj) = object
method as_graph : T.graph Gobject.obj = obj
end

class xyc (obj : [> T.xyc] Gobject.obj) = object
inherit graph obj
end

class databox (obj : [> T.databox] Gtk.obj) = object
inherit [_] GObj.widget_impl obj
method as_databox : T.databox Gtk.obj = obj
method add g = graph_add obj g#as_graph
end

The code is simplified, as at the moment I am not interesting in the
properties and signals of GtkDatabox, as well as the functions to create
the objects of the relevant classes.

Unfortunatly I was not clever enough to write correct ocaml code, hence
it is not accepted by the compiler, which says:

$ ocamlopt -I . -c -i databox.ml
File "databox.ml", line 19, characters 16-19:
This expression has type ([> T.xyc ] as 'a) Gobject.obj
but is here used with type T.graph Gobject.obj
Type 'a = [> `graph | `xyc ] is not compatible with type T.graph = [ `graph ]

And finally I coming to these mailing lists to ask for help on how to
solve this problem.

I am willing also get advices on how to conduct this port.

Regards,

Romildo

PS: Unfortunatly I am short of time, and would like to get answers as
soon as possible. But I do not want to make pressure on you. Anyway
it is still better to get delayed answers, that no answer at all.

lablgtk internals: understand *.props files

2006-10-04T14:52:42Z

Hello.

I want to add bindings for a Gtk based library (GtkDatabox) in lablgtk,
but the lack of documentation of lablgtk internals makes it difficult.

For now I have a question regarding property declaration files
(*.props). What are the meaning of the different "modifiers" that one
can see on those files, when declaring a class? In particular, what are
"set", "wrap", "wrapsip", "type", ... for in a class declaration?

For instance, gtkMisc.props has the following declaration:

class TipsQuery set wrap wrapsig : Label { ... }

Romildo

Re: Re: missing gtk_button_set_image in lablgtk

2006-10-04T03:29:39Z

On Tue, Oct 03, 2006 at 09:12:58PM +0200, Olivier Andrieu wrote:
Content-Description: message body and .signature
> Olivier Andrieu [Tuesday 3 October 2006] :
> > Here is a patch, with a bunch of other missing properties of
> > GtkButton.

> Index: gtkButton.props
> ===================================================================
> RCS file: /net/yquem/devel/caml/repository/bazar-ocaml/lablgtk/src/gtkButton.props,v
> retrieving revision 1.5
> diff -u -r1.5 gtkButton.props
> --- gtkButton.props 16 Sep 2006 10:33:02 -0000 1.5
> +++ gtkButton.props 3 Oct 2006 19:11:02 -0000
> @@ -11,10 +11,14 @@
> }
>
> class Button set wrap wrapsig : Bin {
> + "focus-on-click" gboolean : Read / Write / NoSet
> + "image" GtkWidget_opt : Read / Write / NoSet

It seems that defining image this way, as a property, will force the
type of set_image to GObj.widget option -> unit, while one may expect it
to be GObj.widget -> unit , from the Gtk API documentation.

Maybe the property image-position should be defined too.

> "label" gchararray : Read / Write / Construct
> "use-stock" gboolean : Read / Write / Construct
> "use-underline" gboolean : Read / Write / Construct
> "relief" GtkReliefStyle : Read / Write
> + "xalign" gfloat : Read / Write / NoSet
> + "yalign" gfloat : Read / Write / NoSet
> signal activate / NoWrap
> signal clicked
> signal enter
> Index: gButton.mli
> ===================================================================
> RCS file: /net/yquem/devel/caml/repository/bazar-ocaml/lablgtk/src/gButton.mli,v
> retrieving revision 1.34
> diff -u -r1.34 gButton.mli
> --- gButton.mli 16 Sep 2006 10:33:02 -0000 1.34
> +++ gButton.mli 3 Oct 2006 19:11:02 -0000
> @@ -25,6 +25,14 @@
> method use_underline : bool
> method grab_default : unit -> unit
> method event : event_ops
> + method set_focus_on_click : bool -> unit
> + method focus_on_click : bool
> + method image : GObj.widget option (** @since GTK 2.6 *)
> + method set_image : GObj.widget option -> unit (** @since GTK 2.6 *)

Is this really the type we want for set_image? I am not sure.

> + method set_xalign : float -> unit (** @since GTK 2.4 *)
> + method xalign : float (** @since GTK 2.4 *)
> + method set_yalign : float -> unit (** @since GTK 2.4 *)
> + method yalign : float (** @since GTK 2.4 *)
> end
>
> (** @gtkdoc gtk GtkButton *)

Comparing with the types for label (string), and set_label (string ->
unit), option is not used. But probably because here an empty string may
be used for un unset label. Although the API doc. says that "If the
label text has not been set the return value will be NULL". So, in C, an
unset label would return a NULL pointer, instead of the empty string "".

Romildo

Re: Re: missing gtk_button_set_image in lablgtk

2006-10-03T13:12:58Z

Olivier Andrieu [Tuesday 3 October 2006] :
> Here is a patch, with a bunch of other missing properties of
> GtkButton.

Oops, here is a real patch.

--
Olivier

Index: gtkButton.props
===================================================================
RCS file: /net/yquem/devel/caml/repository/bazar-ocaml/lablgtk/src/gtkButton.props,v
retrieving revision 1.5
diff -u -r1.5 gtkButton.props
--- gtkButton.props 16 Sep 2006 10:33:02 -0000 1.5
+++ gtkButton.props 3 Oct 2006 19:11:02 -0000
@@ -11,10 +11,14 @@
}

class Button set wrap wrapsig : Bin {
+ "focus-on-click" gboolean : Read / Write / NoSet
+ "image" GtkWidget_opt : Read / Write / NoSet
"label" gchararray : Read / Write / Construct
"use-stock" gboolean : Read / Write / Construct
"use-underline" gboolean : Read / Write / Construct
"relief" GtkReliefStyle : Read / Write
+ "xalign" gfloat : Read / Write / NoSet
+ "yalign" gfloat : Read / Write / NoSet
signal activate / NoWrap
signal clicked
signal enter
Index: gButton.mli
===================================================================
RCS file: /net/yquem/devel/caml/repository/bazar-ocaml/lablgtk/src/gButton.mli,v
retrieving revision 1.34
diff -u -r1.34 gButton.mli
--- gButton.mli 16 Sep 2006 10:33:02 -0000 1.34
+++ gButton.mli 3 Oct 2006 19:11:02 -0000
@@ -25,6 +25,14 @@
method use_underline : bool
method grab_default : unit -> unit
method event : event_ops
+ method set_focus_on_click : bool -> unit
+ method focus_on_click : bool
+ method image : GObj.widget option (** @since GTK 2.6 *)
+ method set_image : GObj.widget option -> unit (** @since GTK 2.6 *)
+ method set_xalign : float -> unit (** @since GTK 2.4 *)
+ method xalign : float (** @since GTK 2.4 *)
+ method set_yalign : float -> unit (** @since GTK 2.4 *)
+ method yalign : float (** @since GTK 2.4 *)
end

(** @gtkdoc gtk GtkButton *)

Re: missing gtk_button_set_image in lablgtk

2006-10-03T13:01:21Z

j.romildo@... [Tuesday 3 October 2006] :
>
> On Tue, Oct 03, 2006 at 10:34:39AM -0300, j.romildo@... wrote:
> > Hello.
> >
> > I am using lablgtk to write the GUI for an application I am
> > developing. Currently I want to set the image associated with a
> > button, but it seems that lablgtk does not have support for the
> > Gtk API function gtk_button_set_image. So I am writing to request
> > this support in the next version of lablgtk.
>
> I have written the attached to add the methos image and set_image
> to class Button of gtklabel. But I did not get the types correct
> for the GtkWidget* from the Gtk+ API. Maybe someone has a clue on
> how those methods should be typed.
>
> In Gtk+ the functions have the prototypes:
>
> GtkWidget* gtk_button_get_image (GtkButton *button);
>
> void gtk_button_set_image (GtkButton *button, GtkWidget *image);
>
> The idea is to have two new methods in the class button (files
> gButton.mli and gButton.ml):
>
> image : <lablgtk type equivalent to GtkWidget*> option
>
> set_image : <lablgtk type equivalent to GtkWidget*> -> unit
>
> and two extern functions in module Button of file gtkButton.ml:

No need to, since "image" is defined as a property. You just have to
modify gtkButton.props and propcc will generate the code, and add the
new methods in gButton.mli.

Here is a patch, with a bunch of other missing properties of
GtkButton.
--
Olivier

Repository : andrieu@...:/net/yquem/devel/caml/repository
Module : bazar-ocaml/lablgtk
Working dir: ~/src/caml/lablgtk/lablgtk-camlcvs/

In directory .:
In directory src:
* Modified src/gButton.mli
* Modified src/gtkButton.props

--------------------- End ---------------------
-- last cmd: cvs -f -z3 diff -u src/gtkButton.props src/gButton.mli --

Patch available for missing gtk_button_set_image in lablgtk

2006-10-03T12:52:50Z

On Tue, Oct 03, 2006 at 02:37:55PM -0300, j.romildo@... wrote:

> On Tue, Oct 03, 2006 at 10:34:39AM -0300, j.romildo@... wrote:
> > Hello.
> >
> > I am using lablgtk to write the GUI for an application I am
> > developing. Currently I want to set the image associated with a button,
> > but it seems that lablgtk does not have support for the Gtk API function
> > gtk_button_set_image. So I am writing to request this support in the
> > next version of lablgtk.
>
> I have written the attached to add the methos image and set_image to
> class Button of gtklabel. But I did not get the types correct for the
> GtkWidget* from the Gtk+ API. Maybe someone has a clue on how those
> methods should be typed.

I have reworked the patch and it is working now. So I will be glad if it
as accepted upstream.

Regards.

Romildo

Only in lablgtk-2.6.0.new: config.log
Only in lablgtk-2.6.0.new: config.make
Only in lablgtk-2.6.0.new: config.status
diff -ur lablgtk-2.6.0.orig/src/gButton.ml lablgtk-2.6.0.new/src/gButton.ml
--- lablgtk-2.6.0.orig/src/gButton.ml 2004-06-01 09:06:42.000000000 -0300
+++ lablgtk-2.6.0.new/src/gButton.ml 2006-10-03 15:39:02.000000000 -0300
@@ -14,6 +14,11 @@
inherit button_props
method private obj = obj
method clicked () = Button.clicked obj
+ method image =
+ match Button.image obj with
+ | Some x -> Some (new widget x)
+ | None -> None
+ method set_image w = Button.set_image obj (as_widget w)
method grab_default () =
set Widget.P.can_default obj true;
set Widget.P.has_default obj true
diff -ur lablgtk-2.6.0.orig/src/gButton.mli lablgtk-2.6.0.new/src/gButton.mli
--- lablgtk-2.6.0.orig/src/gButton.mli 2004-07-05 07:05:47.000000000 -0300
+++ lablgtk-2.6.0.new/src/gButton.mli 2006-10-03 15:36:36.000000000 -0300
@@ -14,6 +14,8 @@
inherit GContainer.bin
constraint 'a = [> button]
val obj : 'a obj
+ method image : widget option
+ method set_image : widget -> unit
method clicked : unit -> unit
method set_relief : Tags.relief_style -> unit
method relief : Tags.relief_style
diff -ur lablgtk-2.6.0.orig/src/gtkButton.ml lablgtk-2.6.0.new/src/gtkButton.ml
--- lablgtk-2.6.0.orig/src/gtkButton.ml 2004-05-09 11:39:14.000000000 -0300
+++ lablgtk-2.6.0.new/src/gtkButton.ml 2006-10-03 15:36:36.000000000 -0300
@@ -17,6 +17,8 @@
match stock with None -> label, None
| Some id -> Some (GtkStock.convert_id id), Some true in
make_params ~cont p ?label ?use_underline:use_mnemonic ?use_stock
+ external image : [>`button] obj -> (Gtk.widget Gtk.obj) option = "ml_gtk_button_get_image"
+ external set_image : [>`button] obj -> Gtk.widget Gtk.obj -> unit = "ml_gtk_button_set_image"
external pressed : [>`button] obj -> unit = "ml_gtk_button_pressed"
external released : [>`button] obj -> unit = "ml_gtk_button_released"
external clicked : [>`button] obj -> unit = "ml_gtk_button_clicked"
diff -ur lablgtk-2.6.0.orig/src/ml_gtkbutton.c lablgtk-2.6.0.new/src/ml_gtkbutton.c
--- lablgtk-2.6.0.orig/src/ml_gtkbutton.c 2004-05-09 11:39:14.000000000 -0300
+++ lablgtk-2.6.0.new/src/ml_gtkbutton.c 2006-10-03 15:36:36.000000000 -0300
@@ -58,6 +58,16 @@
ML_2 (gtk_button_set_label, GtkButton_val, String_val, Unit)
ML_1 (gtk_button_get_label, GtkButton_val, Val_optstring)
*/
+ML_2 (gtk_button_set_image, GtkButton_val, GtkWidget_val, Unit)
+CAMLprim value ml_gtk_button_get_image (value b)
+{
+ CAMLparam1(b);
+ CAMLlocal1(res);
+ GtkWidget* tmp;
+ tmp = gtk_button_get_image(GtkButton_val(b));
+ res = Val_option(tmp,Val_GtkWidget);
+ CAMLreturn(res);
+}

/* gtktogglebutton.h */

Re: missing gtk_button_set_image in lablgtk

2006-10-03T11:37:55Z

On Tue, Oct 03, 2006 at 10:34:39AM -0300, j.romildo@... wrote:
> Hello.
>
> I am using lablgtk to write the GUI for an application I am
> developing. Currently I want to set the image associated with a button,
> but it seems that lablgtk does not have support for the Gtk API function
> gtk_button_set_image. So I am writing to request this support in the
> next version of lablgtk.

I have written the attached to add the methos image and set_image to
class Button of gtklabel. But I did not get the types correct for the
GtkWidget* from the Gtk+ API. Maybe someone has a clue on how those
methods should be typed.

In Gtk+ the functions have the prototypes:

GtkWidget* gtk_button_get_image (GtkButton *button);

void gtk_button_set_image (GtkButton *button, GtkWidget *image);

The idea is to have two new methods in the class button (files
gButton.mli and gButton.ml):

image : <lablgtk type equivalent to GtkWidget*> option

set_image : <lablgtk type equivalent to GtkWidget*> -> unit

and two extern functions in module Button of file gtkButton.ml:

external set_image : [>`button] obj ->
<type equivalent to GtkWidget*> -> unit
= "ml_gtk_button_set_image"

external image : [>`button] obj ->
<type equivalent to GtkWidget*> option
= "ml_gtk_button_get_image"

Any help is welcome.

Romildo

diff -ur lablgtk-2.6.0.orig/src/gButton.ml lablgtk-2.6.0.new/src/gButton.ml
--- lablgtk-2.6.0.orig/src/gButton.ml 2004-06-01 09:06:42.000000000 -0300
+++ lablgtk-2.6.0.new/src/gButton.ml 2006-10-03 12:19:56.000000000 -0300
@@ -14,6 +14,8 @@
inherit button_props
method private obj = obj
method clicked () = Button.clicked obj
+ method image = Button.image obj
+ method set_image image = Button.set_image obj image
method grab_default () =
set Widget.P.can_default obj true;
set Widget.P.has_default obj true
diff -ur lablgtk-2.6.0.orig/src/gButton.mli lablgtk-2.6.0.new/src/gButton.mli
--- lablgtk-2.6.0.orig/src/gButton.mli 2004-07-05 07:05:47.000000000 -0300
+++ lablgtk-2.6.0.new/src/gButton.mli 2006-10-03 12:20:24.000000000 -0300
@@ -14,6 +14,8 @@
inherit GContainer.bin
constraint 'a = [> button]
val obj : 'a obj
+ method image : Gtk.widget option
+ method set_image : Gtk.widget -> unit
method clicked : unit -> unit
method set_relief : Tags.relief_style -> unit
method relief : Tags.relief_style
diff -ur lablgtk-2.6.0.orig/src/gtkButton.ml lablgtk-2.6.0.new/src/gtkButton.ml
--- lablgtk-2.6.0.orig/src/gtkButton.ml 2004-05-09 11:39:14.000000000 -0300
+++ lablgtk-2.6.0.new/src/gtkButton.ml 2006-10-03 12:15:32.000000000 -0300
@@ -17,6 +17,8 @@
match stock with None -> label, None
| Some id -> Some (GtkStock.convert_id id), Some true in
make_params ~cont p ?label ?use_underline:use_mnemonic ?use_stock
+ external set_image : [>`button] obj -> Gtk.widget -> unit = "ml_gtk_button_set_image"
+ external image : [>`button] obj -> Gtk.widget option = "ml_gtk_button_get_image"
external pressed : [>`button] obj -> unit = "ml_gtk_button_pressed"
external released : [>`button] obj -> unit = "ml_gtk_button_released"
external clicked : [>`button] obj -> unit = "ml_gtk_button_clicked"
diff -ur lablgtk-2.6.0.orig/src/ml_gtkbutton.c lablgtk-2.6.0.new/src/ml_gtkbutton.c
--- lablgtk-2.6.0.orig/src/ml_gtkbutton.c 2004-05-09 11:39:14.000000000 -0300
+++ lablgtk-2.6.0.new/src/ml_gtkbutton.c 2006-10-03 12:14:54.000000000 -0300
@@ -58,6 +58,16 @@
ML_2 (gtk_button_set_label, GtkButton_val, String_val, Unit)
ML_1 (gtk_button_get_label, GtkButton_val, Val_optstring)
*/
+ML_2 (gtk_button_set_image, GtkButton_val, GtkWidget_val, Unit)
+CAMLprim value ml_gtk_button_get_image (value b)
+{
+ CAMLparam1(b);
+ CAMLlocal1(res);
+ GtkWidget* tmp;
+ tmp = gtk_button_get_image(GtkButton_val(b));
+ res = Val_option(tmp,Val_GtkWidget);
+ CAMLreturn(res);
+}

/* gtktogglebutton.h */

Lablgtkmathview installation : findlib problem ?

2006-04-22T14:43:12Z

I'd like to install lablgtkmathview, a wrapper for the widget
gtkmathview. Problem is : it needs gmetadom, qhich works with findlib. I
have some difficulties to work out how findlib works.

I tried to install lablgtk2 with the option
--withdir=/usr/lib/ocaml/site-lib/, but now I can't compile
lablgtkmathview. Anyway I try it, I can't mix packages using findlib and
packages not using it.

How do you fix those problems yourself ?

Thanks for any help.

\bye

--

Nicolas FRANCOIS
http://nicolas.francois.free.fr
A TRUE Klingon programmer does NOT comment his code

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: lablgtk2 : connecting scroll bar adjustments to a view widget.

2006-03-28T02:17:39Z

Erik de Castro Lopo [Tuesday 28 March 2006] :
>
> HI all,
>
> I posted this to the lablgtk list but received no reply. I'm hoping
> someone here might be able to answer this.
>
> I have a pair of view objects and I'd like to connect a GData.adjustment
> to them. I think this has something to do with this method:
>
> method set_scroll_adjustments :
> callback:(GData.adjustment option -> GData.adjustment option -> unit)
> -> GtkSignal.id

Not quite. Apparently this signal is not meant to be connected by
application code but is used by widget implementations.

> but I can't figure out how to use it. Anyone have a clue how to do
> this?

What you'd need is the gtk_widget_set_scroll_adjustments() function
(which will emit the set_scroll_adjustments signal you've
mentionned). Unfortunately this function is not wrapped in lablgtk.

All is not lost however, you can still use the GtkScrolledWindow
convenience widget to implement some "linked scrollbars" setup. You
simply need to tell the second scrollbar you create to reuse the
GtkAdjustment object of the first scrollbar. (Untested) Pseudo-code
follows:
,----
| let pane = GPack.paned `HORIZONTAL ~packing () in
|
| let scroll_win_1 =
| GBin.scrolled_window
| ~packing:pane#add1 () in
| let scroll_win_2 =
| GBin.scrolled_window
| ~vadjustment:scroll_win_1#vadjustment
| ~packing:pane#add2 () in
|
| let text_view_1 = GText.view ~packing:scroll_win_1#add () in
| let text_view_2 = GText.view ~packing:scroll_win_2#add () in
| ...
`----

This is not exactly what you wanted (there are 2 scrollbars) ; you'd
need gtk_widget_set_scroll_adjustments() for a
one-scrollbar-two-textviews setup.

cf. http://developer.gnome.org/doc/API/2.0/gtk/GtkScrolledWindow.html#desc
for a more detailed description of how scrollable widgets are managed.

--
Olivier

Re: Re: async networking

2006-02-07T20:29:17Z

On Tue, 2006-02-07 at 13:29 -0800, Rick Richardson wrote:

> My only interest lies in high performance networking, specifically in a
> high connection / low data volume scenario (at this juncture at least).
> The optimal solution is some form of iocp with multiple threads (1 per
> open socket initiated at startup).

The optimal solution is to use MLton, Haskell, or Felix,
which all give you a threading API without needing pthreads.

Ocaml bytecode with vmthreads does too, but I think it needs to be
fixed to schedule using event notifications instead of select.

--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Re: async networking

2006-02-07T20:18:01Z

On Wed, 2006-02-08 at 11:03 +1300, Jonathan Roewen wrote:

> > The multiple serving threads could actually make for an simple api,
> > actually. A simple function to add a receive callback for a port would
> > be all you'd need. You could even pass in a buffer to that callback that
> > a person could respond directly to for socket send, since the same
> > thread is handling the send requests as well.
>
> I haven't checked the systhreads implementation (as I don't use it),
> but if it's anything similar to the vmthreads implementation, it is
> not very high performance.
>
> For example: to reschedule a thread, vmthreads a) uses select (not
> sure if this is a problem), and b) does a linear search for a runnable
> thread (I can't remember if it stops early, I'd have to have another
> check).
>
> The point is, in this case, you'd need to rewrite it to use thread
> queues for the various states to get something closer to an O(1)
> scheduler.

I technically don't need to officially reschedule.. since they will all
be doing the same thing, I'll sleep the thread, then when data becomes
available pass it the new fd and wake it up. A simple queue would be
fine for that.

>
> Jonathan

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

How to write efficient threaded programs on OCaml

2006-02-07T15:15:47Z

Hi,

I was wondering if some among you would like to share some hints about
how to write efficient multithreaded applications in OCaml. Indeed,
for example, the following concurrency test shows OCaml performing
quite poorly:
http://shootout.alioth.debian.org/debian/benchmark.php?test=chameneos&lang=all
A qprof profiling reveals that OCaml is spending 63-73% of its time on
the function caml_process_pending_signals and 13-18% on
pthread_cond_signal. Is there a way to improve the performance of
this code ?

Now maybe this is not to be considered like a good analogous of a
possible "real life" application. Hence my question: what do people
do to get decent performance in these cases?

Cheers,
ChriS

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Re: async networking

2006-02-07T14:03:31Z

> The multiple serving threads could actually make for an simple api,
> actually. A simple function to add a receive callback for a port would
> be all you'd need. You could even pass in a buffer to that callback that
> a person could respond directly to for socket send, since the same
> thread is handling the send requests as well.

I haven't checked the systhreads implementation (as I don't use it),
but if it's anything similar to the vmthreads implementation, it is
not very high performance.

For example: to reschedule a thread, vmthreads a) uses select (not
sure if this is a problem), and b) does a linear search for a runnable
thread (I can't remember if it stops early, I'd have to have another
check).

The point is, in this case, you'd need to rewrite it to use thread
queues for the various states to get something closer to an O(1)
scheduler.

Jonathan

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Re: async networking

2006-02-07T13:29:35Z

On Tue, 2006-02-07 at 18:44 +0100, Bardur Arantsson wrote:

> skaller wrote:
> > On Mon, 2006-02-06 at 19:34 +0100, Bardur Arantsson wrote:
> >
> >> However, if you want very high-performance networking
> >> you'd be better off with something closer to the metal, i.e. something
> >> like a libevent wrapper
> >
> > Argg no. Libevent isn't a library, it doesn't control invert.
> > It is a monolithic framework. Therefore it is not very useful because
> > your code will no longer be composable. In particular,
> > there is no way to compose two such frameworks, for example
> > you cannot use it with an event driven GUI framework.
> >
>
> Note that I said 'high-performance'.
>
> Point #1: select() and anything based on it (I believe Equeue still is
> though I haven't looked at it for quite a while) is woefully inadequate
> for high performance I/O except in very specific circumstances.

My only interest lies in high performance networking, specifically in a
high connection / low data volume scenario (at this juncture at least).
The optimal solution is some form of iocp with multiple threads (1 per
open socket initiated at startup). I think at some level of high
performance networking the whole file analogy goes out the window.

The multiple serving threads could actually make for an simple api,
actually. A simple function to add a receive callback for a port would
be all you'd need. You could even pass in a buffer to that callback that
a person could respond directly to for socket send, since the same
thread is handling the send requests as well.

>
> Point #2: It is not customary for UI applications to require
> particularly high-performance I/O, thus rendering the non-composability
> issue moot.
>
> I'm _not_ recommending libevent for general use, just if you want high
> performance with an easily switchable backend implementation.
>
> Cheers,
>

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Re: async networking

2006-02-07T12:51:15Z

2006/2/7, Bardur Arantsson <spam@...>:

> Gerd Stolpmann wrote:
> > Yes, the default Equeue implementation bases simply on select(). It is,
> > however, possible to develop alternate implementations. Currently, there
> > are three of them which integrate into the event loops of labltk,
> > lablgtk1 and lablgtk2. One could, for example, easily add an
> > implementation for advanced kernel interfaces like epoll.
>
> Actually, it might be quite interesting to see one based on
> poll()/epoll(), but I suspect it wouldn't matter much compared to all
> the other stuff that's going in the Equeue code. This is just a very
> vague hunch, though.

I believe that labgtk (and so equeue over lablgtk) use poll. Note that
you are adding another layer : glib, so you might not have gain a lot.

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Re: async networking

2006-02-07T12:30:29Z

Am Dienstag, den 07.02.2006, 20:43 +0100 schrieb Bardur Arantsson:

> > Yes, the default Equeue implementation bases simply on select(). It is,
> > however, possible to develop alternate implementations. Currently, there
> > are three of them which integrate into the event loops of labltk,
> > lablgtk1 and lablgtk2. One could, for example, easily add an
> > implementation for advanced kernel interfaces like epoll.
>
> Actually, it might be quite interesting to see one based on
> poll()/epoll(), but I suspect it wouldn't matter much compared to all
> the other stuff that's going in the Equeue code. This is just a very
> vague hunch, though.

The Equeue core is quite light-weight, there are just some modules on
top of it that make life easier at the user's option. So it would
matter.

> > select() is, as far as I know, only bad if the file descriptors are
> > linked with many different processes, because all that processes must be
> > waked up in order to check the descriptors (even if no I/O can happen).
> > But if you only have Internet sockets, I expect that select() performs
> > well.
>
> There are lots of problems with select(). For example, it generally
> requires copying the file descriptor sets from user-space to kernel
> space for every select() invocation, the scanning of active file
> descriptors afterward can be inefficient(*), from OCaml it also causes
> more pressure on the GC through list allocations for result sets, etc. etc.

That depends all very much on the average data case. E.g. if all the
descriptors generate events at the same time, there is nothing bad with
select(). If the typical case is that only very few descriptors "fire"
it has very much overhead.

The poll() interface fixes a number of these issues. Anyway, in practice
it is not much better than select() just because it is also based on
passive iteration. One needs an actively notifying interface to improve
that.

> Sure, but not at the level I'm talking. I'm talking about saturating
> high-bandwidth links, ultra-low latency -- though usually not at the
> same time, obviously ;). You know, the kind of stuff you might even
> consider using C/C++ (shudder) for just to avoid GC.

Given that data also needs to be processed by the application, it would
be quite interesting whether the choice of the language makes a
difference here. I would guess the time for GC can be kept low in
relation to the costs for context switches, even for the
high-performance case.

And in O'Caml one can prefer to program in a style that reduces the load
on the GC. A much nicer alternative than considering C/C++ too early.

> > I think there is another point why it is a bad idea to distinguish
> > between, say UI and server applications. Network components should be
> > shareable between all types of applications.
>
> Yup. Though all non-blocking I/O has the basic problem of "one event
> loop to rule them all" unless you go with several threads, each running
> their own event loop... At which point you might as well have each of
> those components just using regular blocking I/O and using threads as
> appropriate. Note, I'm not talking about performance characteristics
> here, just design. Also, exception handling and such can be handled much
> more nicely with a threaded design since they don't "invert" the control
> logic the same way non-blocking I/O tends to do.

Really? From my experience I would say that exception handling is much
easier in the non-blocking case. Exceptions may raise complicated
synchronisation issues in the threaded design.

Gerd
--
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@... http://www.gerd-stolpmann.de
Telefon: 06151/153855 Telefax: 06151/997714
------------------------------------------------------------

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: async networking

2006-02-07T11:43:57Z

Gerd Stolpmann wrote:

> Am Dienstag, den 07.02.2006, 18:44 +0100 schrieb Bardur Arantsson:
>> skaller wrote:
>>> On Mon, 2006-02-06 at 19:34 +0100, Bardur Arantsson wrote:
>>>
>>>> However, if you want very high-performance networking
>>>> you'd be better off with something closer to the metal, i.e. something
>>>> like a libevent wrapper
>>> Argg no. Libevent isn't a library, it doesn't control invert.
>>> It is a monolithic framework. Therefore it is not very useful because
>>> your code will no longer be composable. In particular,
>>> there is no way to compose two such frameworks, for example
>>> you cannot use it with an event driven GUI framework.
>>>
>> Note that I said 'high-performance'.
>>
>> Point #1: select() and anything based on it (I believe Equeue still is
>> though I haven't looked at it for quite a while) is woefully inadequate
>> for high performance I/O except in very specific circumstances.
>
> Yes, the default Equeue implementation bases simply on select(). It is,
> however, possible to develop alternate implementations. Currently, there
> are three of them which integrate into the event loops of labltk,
> lablgtk1 and lablgtk2. One could, for example, easily add an
> implementation for advanced kernel interfaces like epoll.

Actually, it might be quite interesting to see one based on
poll()/epoll(), but I suspect it wouldn't matter much compared to all
the other stuff that's going in the Equeue code. This is just a very
vague hunch, though.

[--snip--]
>
> select() is, as far as I know, only bad if the file descriptors are
> linked with many different processes, because all that processes must be
> waked up in order to check the descriptors (even if no I/O can happen).
> But if you only have Internet sockets, I expect that select() performs
> well.

There are lots of problems with select(). For example, it generally
requires copying the file descriptor sets from user-space to kernel
space for every select() invocation, the scanning of active file
descriptors afterward can be inefficient(*), from OCaml it also causes
more pressure on the GC through list allocations for result sets, etc. etc.

(*) If your file descriptor set has large "holes" -- which can develop
if clients have very variable connection lifetimes -- you'll end up
scanning lots of memory you don't really need to scan. Algorithmically
it's all still O(n), but the constants can be _very_ different.

>
>> Point #2: It is not customary for UI applications to require
>> particularly high-performance I/O, thus rendering the non-composability
>> issue moot.
>
> There are many aspects of high performance, for example throughput,
> latency, and whether a low or high number of descriptors are watched.

Sure. It's just that select() sucks performance-wise for most purposes.
The alternatives like the OpenBSD kqueue and poll() are usually much better.

> UI applications are often interested in low latency for a moderate number
> of descriptors.

Sure, but not at the level I'm talking. I'm talking about saturating
high-bandwidth links, ultra-low latency -- though usually not at the
same time, obviously ;). You know, the kind of stuff you might even
consider using C/C++ (shudder) for just to avoid GC.

>
> I think there is another point why it is a bad idea to distinguish
> between, say UI and server applications. Network components should be
> shareable between all types of applications.

Yup. Though all non-blocking I/O has the basic problem of "one event
loop to rule them all" unless you go with several threads, each running
their own event loop... At which point you might as well have each of
those components just using regular blocking I/O and using threads as
appropriate. Note, I'm not talking about performance characteristics
here, just design. Also, exception handling and such can be handled much
more nicely with a threaded design since they don't "invert" the control
logic the same way non-blocking I/O tends to do.

> For example, an HTTP component is useful for both, so why should we develop an extra one for
> specific needs of high performance?
>

Sometimes you just need that last bit of performance where a "nice"
implementation just won't do.

Cheers,

--
Bardur Arantsson
<bardurREMOVE@...>
<bardurREMOVE@...>

[Postmodernism] is more like a three year old throwing his blocks
around the room because he got frustrated with his failed
attempts to stack them higher.
Black Parrot @ http://slashdot.org

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: Re: async networking

2006-02-07T11:01:08Z

Am Dienstag, den 07.02.2006, 18:44 +0100 schrieb Bardur Arantsson:

Yes, the default Equeue implementation bases simply on select(). It is,
however, possible to develop alternate implementations. Currently, there
are three of them which integrate into the event loops of labltk,
lablgtk1 and lablgtk2. One could, for example, easily add an
implementation for advanced kernel interfaces like epoll. Or one that
sits upon libevent. There is, however, the basic design decision that
all events pass the same queue. This mainly has a certain scheduling
effect (application-driven scheduling), and increases latency if the
queue gets too long, but shows good behaviour under high load.

select() is, as far as I know, only bad if the file descriptors are
linked with many different processes, because all that processes must be
waked up in order to check the descriptors (even if no I/O can happen).
But if you only have Internet sockets, I expect that select() performs
well.

> Point #2: It is not customary for UI applications to require
> particularly high-performance I/O, thus rendering the non-composability
> issue moot.

There are many aspects of high performance, for example throughput,
latency, and whether a low or high number of descriptors are watched. UI
applications are often interested in low latency for a moderate number
of descriptors.

I think there is another point why it is a bad idea to distinguish
between, say UI and server applications. Network components should be
shareable between all types of applications. For example, an HTTP
component is useful for both, so why should we develop an extra one for
specific needs of high performance?

Gerd

> I'm _not_ recommending libevent for general use, just if you want high
> performance with an easily switchable backend implementation.
>
> Cheers,
>
--
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@... http://www.gerd-stolpmann.de
Telefon: 06151/153855 Telefax: 06151/997714
------------------------------------------------------------

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: async networking

2006-02-07T09:44:54Z

skaller wrote:

> On Mon, 2006-02-06 at 19:34 +0100, Bardur Arantsson wrote:
>
>> However, if you want very high-performance networking
>> you'd be better off with something closer to the metal, i.e. something
>> like a libevent wrapper
>
> Argg no. Libevent isn't a library, it doesn't control invert.
> It is a monolithic framework. Therefore it is not very useful because
> your code will no longer be composable. In particular,
> there is no way to compose two such frameworks, for example
> you cannot use it with an event driven GUI framework.
>

Note that I said 'high-performance'.

Point #1: select() and anything based on it (I believe Equeue still is
though I haven't looked at it for quite a while) is woefully inadequate
for high performance I/O except in very specific circumstances.

Point #2: It is not customary for UI applications to require
particularly high-performance I/O, thus rendering the non-composability
issue moot.

I'm _not_ recommending libevent for general use, just if you want high
performance with an easily switchable backend implementation.

Cheers,

--
Bardur Arantsson
<bardurREMOVE@...>
<bardurREMOVE@...>

- Your Honor, let the record reflect that the Defense just grazed
my Johnson.
John, 'Ally McBeal'

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: look for solution OCaml task

2006-02-07T01:26:38Z

skaller wrote:
> On Mon, 2006-02-06 at 10:25 +0100, Alessandro Baretta wrote:

> But if I ran a software engineering class I'd FAIL anyone
> that didn't .. not that I could actually understand the question .. :)

Actually, neither did I. See the value of formal specification languages? Why
not specify this task by writing an Ocaml class providing a reference
implementation?

Alex

--
*********************************************************************

Ing. Alessandro Baretta

Studio Baretta
http://studio.baretta.com/

Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering

tel. +39 02 370 111 55
fax. +39 02 370 111 54

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: OCaml & .NET

2006-02-06T11:19:37Z

Sigh - one more email that went to the person insteat of the list...

William W Smith wrote:
> Has anyone tried porting OCaml to managed code as a
> Microsoft .NET family language?
>
> A related question is whether there any library sets
> to access the windows API or MFC directly?

Well, everyone else has already mentioned F# (but do note that it is
not full OCaml)...

Regarding your other question, there is also a somewhat/largely
complete (depending on your POV/needs) library for Win32 API access:

http://sourceforge.net/projects/ocaml-win32

Robert Roessler
roessler@...
http://www.rftp.com

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: async networking

2006-02-06T10:34:35Z

Gerd Stolpmann wrote:
> Maybe you interested in my equeue library for multiplexing I/O. There is
> now a lot of code using equeue (HTTP client, FTP client, RPC
> implementation), so I think it is very stable.
>
> http://www.ocaml-programming.de/programming/equeue.html
>

If you want ease of use and all-round stability I can also recommend
Gerd's Equeue. However, if you want very high-performance networking
you'd be better off with something closer to the metal, i.e. something
like a libevent wrapper combined with a memory-mapped ring buffer to
avoid unnecessary copying and minimize the costs associated with string
allocation and GC. I have developed a highly efficient ring buffer
library (ocaml-rbuffer) which can be downloaded at

http://www.imada.sdu.dk/~bardur/personal/45-programs/index.html

Cheers,

--
Bardur Arantsson
<bardurREMOVE@...>
<bardurREMOVE@...>

- Sometimes I think Trent just needs a cup of hot chocolate and a
blankie.
Tori Amos commenting on Nine Inch Nails

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Soutiens les aveugles et déficients visuels

2006-02-06T07:17:38Z

Bonjour,

Comme d’autres copains avant moi je transmets cette chaîne de solidarité pour aider une association (CLIQUEZ-ICI: http://www.unadev.org pour accèder au site internet) connue en France et qui fait de très grandes choses. J’ai 14 ans et avec mon ecole, on a participé au Marchathon.

J’ai lu une histoire trop forte sur un garçon de 12 ans qui à marché et courru sur 24 km. Je ne suis pas arrivé à faire 10 kms, la honte.
Le Marchathon est une idée de rassemblement et de solidarité exemplaire. En 10 ans, 12 aveugles ont reçu leur chien grâce à ce mouvement du cœur. Bravo à l’UNADEV.

J’ai été sur leur site et j’ai découvert que L'UNADEV (Union des Aveugles et Déficients Visuels), a été créée en 1929, est une association reconnue d'intérêt général. Elle est membre de la Fédération des Aveugles et Handicapés Visuels de France, reconnue d'utilité publique (décret du 27 août 1921). L'UNADEV a pour but l'aide et l'entraide des handicapés visuels, par ses propres œuvres, la représentation et la défense de leurs intérêts, et d'une manière générale, l'amélioration de leur quotidien, notamment par l'utilisation des lois existantes ou à venir. Son action s'étend au plan national.

J’ai appris que l’UNADEV était en train de refaire leur site web, il sortira en février tout beau, tout neuf avec une plate forme de dons en ligne.

www.unadev.org

S’il vous plait, faites passer ce message à 10 personnes qui ont comme vous et nous, du cœur et donnez pour l’UNADEV. Je compte sur vous.

Merci.

Léo

--------------------------------------------------------------------------------
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez la version beta.
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Wear this gold gift piece and show the world.

2006-02-06T07:06:56Z

Heya Greg,

I came across these great chronometers a moment ago and I thought you would
like to know.

I know that you have a distingished elegance and also how you welcome a
superb discount. at www.aarp.nc.G.htqs.org/lop/

I see you being frugal on nice things every month. This is not too
expensive so that you can let yourself go!

Give me ur thoughts,
Kyya

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs