Native multithreaded LablGTK2?

Native multithreaded LablGTK2?

[Kaspar Rohrer]

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

I'm trying to build a multithreaded application (my own, written from  
scratch) using Ocaml, Lablgtk2, and Lablgl. I use Omake as the build  
system, and the project consists of several different Ocaml libraries  
(my own as well as 3rd party).

Here's the error I get when I try to compile the application:

Files /Users/krohrer/godi/lib/ocaml/pkg-lib/lablgtk2/gtkThread.cmx
and /Users/krohrer/godi/lib/ocaml/pkg-lib/lablgtk2/gtkThread.cmx
both define a module named GtkThread

This only happens when I try to compile a native code application, as  
opposed to byte code.

Now, my knowledge of the ocaml library system is somewhat limited. So  
I thought I'd ask here, in the hope that if this is really a lablgtk2/ 
godi/omake error, somebody will tell me.
Any ideas on this one?

Thanks in advance
- Kaspar Rohrer

PS: Currently the application is single threaded, but due to output  
redirection using pipes, I get the occassional freeze. (Pipe gets  
flooded!)

[-- Attachment #2: Type: text/html, Size: 2328 bytes --]

Re: [Caml-list] Native multithreaded LablGTK2?

[Julien Moutinho]

On Sun, Jul 29, 2007 at 09:16:08PM +0200, Kaspar Rohrer wrote:
> I'm trying to build a multithreaded application (my own, written from 
> scratch) using Ocaml, Lablgtk2, and Lablgl. I use Omake as the build 
> system, and the project consists of several different Ocaml libraries (my 
> own as well as 3rd party).
>
> Here's the error I get when I try to compile the application:
>
> Files /Users/krohrer/godi/lib/ocaml/pkg-lib/lablgtk2/gtkThread.cmx
> and /Users/krohrer/godi/lib/ocaml/pkg-lib/lablgtk2/gtkThread.cmx
> both define a module named GtkThread
Sounds like you end up with a doubloon amongst the dependences.

> This only happens when I try to compile a native code application, as 
> opposed to byte code.
That's because ocamlc removes doubloons for you, while ocamlopt does not.

$ echo "let f () = print_endline \"Namaste\"" > dep.ml
$ ocamlc -c dep.ml
$ ocamlopt -c dep.ml
$ echo "Dep.f ()" > file.ml
$ ocamlc -o file dep.cmo dep.cmo file.ml && ./file
Namaste
$ ocamlopt -o file.opt dep.cmx dep.cmx file.ml && ./file.opt
Files dep.cmx and dep.cmx both define a module named Dep

> Now, my knowledge of the ocaml library system is somewhat limited. So I 
> thought I'd ask here, in the hope that if this is really a 
> lablgtk2/godi/omake error, somebody will tell me.
> Any ideas on this one?
Check the META.lablgtk2 file:
$ ocamlfind query lablgtk2 -format "%A" -predicates native,mt
lablgtk.cmxa gtkThread.cmx

If you get this, lablgtk2 is not likely to be guilty.

For I have never used neither Omake nor Godi, cannot help more.
Nonetheless, if I were you I would dive into Omake...

> PS: Currently the application is single threaded, but due to output 
> redirection using pipes, I get the occassional freeze. (Pipe gets flooded!)
Weird.

Re: [Caml-list] Native multithreaded LablGTK2?

[Kaspar Rohrer]

On 30.07.2007, at 07:40, Julien Moutinho wrote:
> Check the META.lablgtk2 file:
> $ ocamlfind query lablgtk2 -format "%A" -predicates native,mt
> lablgtk.cmxa gtkThread.cmx
>
> If you get this, lablgtk2 is not likely to be guilty.
Here's what I get, so I suppose lablgtk2 is not guilty:

 > ocamlfind query lablgtk2 -format "%A" -predicates native,mt
lablgtk.cmxa lablglade.cmxa lablgnomecanvas.cmxa lablgnomeui.cmxa  
lablpanel.cmxa gtkInit.cmx gtkThread.cmx

>
> For I have never used neither Omake nor Godi, cannot help more.
> Nonetheless, if I were you I would dive into Omake...
Hm, maybe the error is in how I use Omake. I'll look into.

>> PS: Currently the application is single threaded, but due to output
>> redirection using pipes, I get the occassional freeze. (Pipe gets  
>> flooded!)
> Weird.
No, not at all. The redirection happens in the same thread, so if the  
pipe buffer is full, all write operations will block. And because the  
application is single threaded, the reader never gets a chance to  
empty the pipe. Thus, freeze.

I'm piping stdout, because that's the only way I was able to redirect  
stdout to a gtk text widget (using a GIOchannel: GMain.Io.*). If  
anybody has a better idea, I'd be glad to hear it. I was originally  
thinking of  an out_channel that writes to a buffer instead of a  
file, but the Ocaml standard library seems to be missing this  
functionality. Or is it?

Anyway, thanks a lot for your help. I appreciate it.

Re: [Caml-list] Native multithreaded LablGTK2?

[Julien Moutinho]

On Mon, Jul 30, 2007 at 10:01:47AM +0200, Kaspar Rohrer wrote:
>>> PS: Currently the application is single threaded, but due to output
>>> redirection using pipes, I get the occassional freeze. (Pipe gets flooded!)
>> Weird.
> No, not at all. The redirection happens in the same thread, so if the pipe 
> buffer is full, all write operations will block. And because the 
> application is single threaded, the reader never gets a chance to empty the 
> pipe. Thus, freeze.
Oki douki, it's just that I did not undertand why you use std(in|out)
to communicate between threads... But you use them because you want
a buffering machinery and you have only looked at Pervasives, right?

> I'm piping stdout, because that's the only way I was able to redirect 
> stdout to a gtk text widget (using a GIOchannel: GMain.Io.*). If anybody 
> has a better idea, I'd be glad to hear it. I was originally thinking of  an 
> out_channel that writes to a buffer instead of a file, but the Ocaml
> standard library seems to be missing this functionality. Or is it?
You have [Stream.t], [Buffer.t] and [GText.buffer] at your service.

HTH.

Re: [Caml-list] Native multithreaded LablGTK2?

[Kaspar Rohrer]

On 30.07.2007, at 13:57, Julien Moutinho wrote:

> Oki douki, it's just that I did not undertand why you use std(in|out)
> to communicate between threads... But you use them because you want
> a buffering machinery and you have only looked at Pervasives, right?
No, the problem is of a different nature: I want to capture standard  
output and display it in a (log) window in my Gtk application. I'm  
aware that I could just use custom output functions, but the main  
problem here is that I've embedded a Scheme interpreter (Ocs,  
actually: http://will.iki.fi/software/ocs/) which writes to stdout by  
default. Now, of course I could adapt Ocs to suit my needs. But I  
have no intention to do so at the moment (although it would be  
relatively straight forward by extending Ocs_port).

>> I'm piping stdout, because that's the only way I was able to redirect
>> stdout to a gtk text widget (using a GIOchannel: GMain.Io.*). If  
>> anybody
>> has a better idea, I'd be glad to hear it. I was originally  
>> thinking of  an
>> out_channel that writes to a buffer instead of a file, but the Ocaml
>> standard library seems to be missing this functionality. Or is it?
> You have [Stream.t], [Buffer.t] and [GText.buffer] at your service.
>
> HTH.
I actually already use a GText.buffer. In conjunction with piping and  
GMain.Io.add_watch, I am able to redirect standard output to the  
buffer and thus display it in a text widget. But this only works  
reliably if the application is multithreaded, because pipes have a  
fixed size buffer (something around 5000 bytes IIRC). Now, if the  
buffer was able to capture all output, this would work for a single  
thread also. Because writes to the buffer would never block, unlike  
writes to a pipe.
I might be wrong on all of the above though, as I am far from an  
expert on either Gtk or multithreading.

Anyway, thanks again. I really apreciate any help I can get.

Re: [Caml-list] Native multithreaded LablGTK2?

[Kaspar Rohrer]

On 30.07.2007, at 07:40, Julien Moutinho wrote:

> Check the META.lablgtk2 file:
> $ ocamlfind query lablgtk2 -format "%A" -predicates native,mt
> lablgtk.cmxa gtkThread.cmx
>
> If you get this, lablgtk2 is not likely to be guilty.
Ok, I rechecked this: I think the lablgtk2 META file is the culprit:
I'm using OpenGL. So if I add the lablGL predicate, I effectively get  
this:

$ ocamlfind query lablgtk2 -format "%A" -predicates native,mt,lablGL
lablgtk.cmxa lablgtkgl.cmxa lablglade.cmxa lablgnomecanvas.cmxa  
lablgnomeui.cmxa lablpanel.cmxa gtkInit.cmx gtkThread.cmx gtkThread.cmx

Which explains the error. But how would I fix this?

$ more META
description = "Bindings for gtk2"
requires=""
requires(lablGL)="lablGL"
version="20051028"
archive(byte)="lablgtk.cma  lablglade.cma lablgnomecanvas.cma  
lablgnomeui.cma lablpanel.cma gtkInit.
cmo"
archive(native)="lablgtk.cmxa  lablglade.cmxa lablgnomecanvas.cmxa  
lablgnomeui.cmxa lablpanel.cmxa g
tkInit.cmx"
archive(byte,lablGL)="lablgtk.cma lablgtkgl.cma  lablglade.cma  
lablgnomecanvas.cma lablgnomeui.cma l
ablpanel.cma gtkInit.cmo"
archive(native,lablGL)="lablgtk.cmxa lablgtkgl.cmxa  lablglade.cmxa  
lablgnomecanvas.cmxa lablgnomeui
.cmxa lablpanel.cmxa gtkInit.cmx"
archive(byte,mt) += "gtkThread.cmo"
archive(native,mt) += "gtkThread.cmx"
archive(byte,lablGL,mt) += "gtkThread.cmo"
archive(native,lablGL,mt) += "gtkThread.cmx"
archive(toploop,mt) += "gtkThInit.cmo"

Re: [Caml-list] Native multithreaded LablGTK2?

[Julien Moutinho]

On Mon, Jul 30, 2007 at 10:22:17AM +0200, Kaspar Rohrer wrote:
> On 30.07.2007, at 07:40, Julien Moutinho wrote:
>
>> Check the META.lablgtk2 file:
>> $ ocamlfind query lablgtk2 -format "%A" -predicates native,mt
>> lablgtk.cmxa gtkThread.cmx
>>
>> If you get this, lablgtk2 is not likely to be guilty.
> Ok, I rechecked this: I think the lablgtk2 META file is the culprit:
> I'm using OpenGL. So if I add the lablGL predicate, I effectively get this:
>
> $ ocamlfind query lablgtk2 -format "%A" -predicates native,mt,lablGL
> lablgtk.cmxa lablgtkgl.cmxa lablglade.cmxa lablgnomecanvas.cmxa 
> lablgnomeui.cmxa lablpanel.cmxa gtkInit.cmx gtkThread.cmx gtkThread.cmx
>
> Which explains the error. But how would I fix this?

Perhaps, you can modify lablgtk2/META,
doing this:
	- archive(byte,mt) += "gtkThread.cmo"
	- archive(native,mt) += "gtkThread.cmx"
	+ archive(byte,mt,-lablGL) += "gtkThread.cmo"
	+ archive(native,mt,-lablGL) += "gtkThread.cmx"
or that:
	- archive(byte,lablGL,mt) += "gtkThread.cmo"
	- archive(native,lablGL,mt) += "gtkThread.cmx"
at your choice.

By the way, here are the METAS in Debian Sid:

	$ cat `ocamlc -where`/lablgtk2/META
	version="2.6.0"
	requires(mt) = "threads"
	requires(mt,mt_vm) = "threads.vm"
	requires(mt,mt_posix) = "threads.posix"
	directory="+lablgtk2"
	archive(byte) = "lablgtk.cma"
	archive(native) = "lablgtk.cmxa"
	archive(byte,mt) += "gtkThread.cmo"
	archive(native,mt) += "gtkThread.cmx"

	package "init" (
	  requires = "lablgtk2"
	  archive(byte) = "gtkInit.cmo"
	  archive(native) = "gtkInit.cmx"
	)

	package "glade" (
	  requires = "lablgtk2"
	  archive(byte) = "lablglade.cma"
	  archive(native) = "lablglade.cmxa"
	)

	package "gtkspell" (
	  requires = "lablgtk2"
	  archive(byte) = "lablgtkspell.cma"
	  archive(native) = "lablgtkspell.cmxa"
	)

	$ cat `ocamlc -where`/lablGL/META
	version="1.00"
	directory="+lablgl"
	archive(byte) = "lablgl.cma"
	archive(native) = "lablgl.cmxa"

	package "togl" (
	  requires = "labltk lablgl"
	  archive(byte) = "togl.cma"
	  archive(native) = "togl.cmxa"
	)

	package "glut" (
	  requires = "lablgl"
	  archive(byte) = "lablglut.cma"
	  archive(native) = "lablglut.cmxa"
	)

At first sight, they seem less comprehensive, but more accurate...

Re: [Caml-list] Native multithreaded LablGTK2?

[Kaspar Rohrer]

On 30.07.2007, at 12:01, Julien Moutinho wrote:
> Perhaps, you can modify lablgtk2/META,
> doing this:
> 	- archive(byte,mt) += "gtkThread.cmo"
> 	- archive(native,mt) += "gtkThread.cmx"
> 	+ archive(byte,mt,-lablGL) += "gtkThread.cmo"
> 	+ archive(native,mt,-lablGL) += "gtkThread.cmx"
> or that:
> 	- archive(byte,lablGL,mt) += "gtkThread.cmo"
> 	- archive(native,lablGL,mt) += "gtkThread.cmx"
> at your choice.
Yeah, I'll try that and see if it works.

> By the way, here are the METAS in Debian Sid:
> [...]
> At first sight, they seem less comprehensive, but more accurate...

So that would mean that the lablgtk2 package included in Godi is  
broken / outdated? Maybe I should file a bug report then. It seems to  
me that Godi is not used very often anyway, as most of the Ocaml  
packages seem to be readily available on most Linux distros (I'm on  
Mac OS X, so I can't check).