kaustuv has quit [Remote host closed the connection]
ftrvxmtrx has quit [Ping timeout: 248 seconds]
lopex has joined #ocaml
oriba has joined #ocaml
kaustuv has joined #ocaml
hto_ has quit [Ping timeout: 240 seconds]
ftrvxmtrx has joined #ocaml
vivanov has quit [Ping timeout: 252 seconds]
vivanov has joined #ocaml
Associat0r has quit [Quit: Associat0r]
pdhborges has joined #ocaml
pdhborges has left #ocaml []
munga has quit [Ping timeout: 240 seconds]
philtor has joined #ocaml
<kaustuv>
Thiw works in GODI's version of lablgtk2 (20100909), which seems ancient. It fails for me with liblablgtk2-ocaml-dev (2.14.2) in debian amd64 unstable. Can someone check that it is indeed broken for them in a recent lablgtk2? http://pastebin.com/c9qLXNpp
<kaustuv>
Hmm, there doesn't seem to be any patches in GODI either...
ftrvxmtrx has quit [Quit: Leaving]
ftrvxmtrx has joined #ocaml
vivanov has quit [Ping timeout: 264 seconds]
ftrvxmtrx has quit [Ping timeout: 276 seconds]
<kaustuv>
I feel like a total noob again. How do I get gdb to load the symbols for something like libglib?
ftrvxmtrx has joined #ocaml
avsm has joined #ocaml
ocp has quit [Ping timeout: 276 seconds]
jamii has joined #ocaml
olauzon has joined #ocaml
Yoric has quit [Quit: Yoric]
myu2 has quit [Remote host closed the connection]
<kaustuv>
Ah, I think I found the issue. In the GODI version, GMain.Main.init () is apparently not required to be called explicitly, but it *is* required in the Debian version.
myu2 has joined #ocaml
vivanov has joined #ocaml
<thelema_>
That seems a bug in the godi lablgtk
eikke has quit [Read error: Operation timed out]
<thelema_>
unless there really is no reason to avoid calling Main.init at the start of your program
<kaustuv>
I'm not so sure. The LablGTK2 tutorial also does not mention the .init funciton
<thelema_>
yes, it just says that you should link with a module that auto-runs that function
<thelema_>
and that'd be the difference between godi and debian - the auto-linking of that module
<kaustuv>
This is an amazingly explodey minefield. Who made this design choice?
<kaustuv>
I can't help but think that GODI has the right idea
<thelema_>
GtkInit module doesn't provide any APIS, it just has "let () = GMain.Main.init ()" as a side effect.
jamii has quit [*.net *.split]
dcolish has quit [*.net *.split]
zzz_` has quit [*.net *.split]
romanoffi has quit [*.net *.split]
diml has quit [*.net *.split]
cthuluh has quit [*.net *.split]
schme has quit [*.net *.split]
adrien has quit [*.net *.split]
jamii has joined #ocaml
dcolish has joined #ocaml
zzz_` has joined #ocaml
romanoffi has joined #ocaml
diml has joined #ocaml
cthuluh has joined #ocaml
schme has joined #ocaml
adrien has joined #ocaml
<thelema_>
I agree it should be always one way or the other. Moving GtkInit into what gets linked by default would be the right way to do what GODI does, and removing GtkInit entirely would result in everyone always calling Main.init themselves
<hcarty>
kaustuv: Do either GODI or Debian use an upstream META file and build system, or do they provide their own?
vivanov has quit [Ping timeout: 260 seconds]
vivanov has joined #ocaml
Yoric has joined #ocaml
jamii has quit [Ping timeout: 260 seconds]
myu2 has quit [Remote host closed the connection]
NOUK has joined #ocaml
ulfdoz has joined #ocaml
DOUK has quit [Ping timeout: 240 seconds]
kaustuv_ has joined #ocaml
<kaustuv_>
thelema_: actually the function in GtkInit is: let locale = GMain.Main.init ()
<kaustuv_>
hcarty: there are some META files in the debian/ directory in lablgtk2. Not sure if they are the same as upstream or not
sepp2k has joined #ocaml
kaustuv_ has quit [Quit: Porral 2]
<adrien>
btw, what's the general feeling on that? should the init be automatically linked in or not?
<adrien>
why wouldn't it be?
cthuluh_ has joined #ocaml
cthuluh_ has quit [Remote host closed the connection]
<thelema_>
adrien: I can imagine situations where one doesn't want lablgtk to always initialize on startup, but would want to do some work first and then initialize it.
<adrien>
good point
<thelema_>
hcarty: iirc, there's no META from garrigue
<adrien>
it's really a try and completely untested
<adrien>
afaik, currently, anything compiled with godi's META (and others I guess) will always link libglade.* which is something I'd like to avoid
<hcarty>
kaustuv: GODI and Debian may have each added their own, different linking steps to the build process
<hcarty>
kaustuv: I have no evidence to back that up, beyond GODI acting like it does one thing and Debian acting like it does another.
<hcarty>
Hopefully these kinds of differences will go away once the various upstream projects are properly ocamlfind-ified
<adrien>
I know of 4 different METAs for sure
thomasga has quit [Ping timeout: 246 seconds]
<hcarty>
Fedora may have its own methods, although IIRC most of the Fedora packages are modeled after Debian
* thelema_
thinks we need to ask garrigue to include a META file
<thelema_>
and adrien's git branch seems the best place to start.
<sheets>
thelema_: a simple alist won out in the end
<thelema_>
sheets: glad you resolved this
<sheets>
thelema_: i got sidetracked in type investigations for accurate modeling and forgot some constraints on the data structure. I should have realized sooner that the small number of polyvar tags meant that the keyspace was small and the map structure itself didn't matter. Now I just have parametric polymorphism. I also realized that blessing certain polyvar tags is probably an antipattern for data structures unless you are mixing in fe
thelema has joined #ocaml
thelema_ has quit [Read error: Connection reset by peer]
<jonafan>
i'm actually trying to do some webgl stuff
<sheets>
ok. and you are wanting to program in ocaml?
<jonafan>
yes
<jonafan>
javascript is ... not the best
ocp has joined #ocaml
<sheets>
agreed. we are currently using a javascript layer to interact with webgl and just pushing all the simulation model into ocaml
<flux>
jonafan, while I agree with that, perhaps Haxe is something you want to take a look at
<flux>
although who knows, maybe it is convenient to write js-apps in ocaml as well?
<sheets>
it depends on what platforms you want to target? i don't know about haxe's capabilities but we wanted the potential for one codebase on iOS, browser, and server
<flux>
Haxe's main targets are javascript, flash, and php. apparently it supports c++ as well.
<flux>
so no iOS with haxe :)
<flux>
of course, it's written in ocaml, so you can write new targets ;)
<sheets>
yup. what do you gain from the extra language layer?
<flux>
you mean haxe versus js?
<flux>
I understand some folk prefer static type systems.. ;)
<sheets>
haxe vs js/ocamljs, haxe vs ocaml for server-side
<flux>
in any case, I haven't used Haxe, it just seems interesting
<sheets>
hmm, they say you can target iOS
<flux>
if there's going to be ocaml server side, I'd definitely go with jsocaml (or just plain js perhaps)
<flux>
but if there's going to be a php server side an js client side, perhaps haxe starts to sound like a good idea
<jonafan>
i thought javascript seemed like a decent language before i used it
<adrien>
haxe does some optimization passes, I've read it makes flash code that is faster than what adobe's product do
<adrien>
products*
<sheets>
ocamljs takes the dlambda output and almost directly translates it into js… this means you are shipping the stdlib to every client due to the way modules are packaged as arrays
<sheets>
so your produced js starts at 40kb
<sheets>
this is currently being fixed
<jonafan>
i can deal with that in my case, since the tool is for visualizing 20-30m data files
<sheets>
ocamljs output can be consumed by closure-compiler to get smaller deployables but not radically smaller
<sheets>
js_of_ocaml is also worth checking out. it's with ocsigen and goes from bytecode to js
<sheets>
it's a different set of trade-offs (some math is slower as it emulates ocaml ints inside of js nums) but seems to have more active devs
DOUK has joined #ocaml
<sheets>
I don't know if js_of_ocaml has js inlining but ocamljs does and it is quite handy at times
eikke has joined #ocaml
NOUK has quit [Ping timeout: 276 seconds]
DOUK has quit [Read error: Connection reset by peer]
oriba_ has joined #ocaml
sku has joined #ocaml
oriba has quit [Read error: Operation timed out]
Cyanure has quit [Read error: Operation timed out]
ymasory has quit [Quit: Leaving]
ymasory has joined #ocaml
ymasory has quit [Read error: Connection reset by peer]
ymasory has joined #ocaml
Snark has quit [Quit: Ex-Chat]
<hcarty>
thelema: No luck here with odb.ml + batteries. odb doesn't try to fetch Camomile.
<hcarty>
thelema: This is with a fresh OCaml 3.12.0 + ocamlfind install from source, Ubuntu 10.04 64bit.
ulfdoz has quit [Ping timeout: 276 seconds]
_andre has quit [Quit: leaving]
thomasga has joined #ocaml
hto has joined #ocaml
wieczyk has joined #ocaml
sku has quit [Quit: Leaving]
ocp has quit [Read error: Operation timed out]
<hcarty>
thelema: Ah... nevermind, it looks like the server doesn't provide dependency information