gildor changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | OCaml 3.12.1 http://bit.ly/nNVIVH
<NaCl> thelema: well, this officially makes no sense
<NaCl> firefox does not recognize the ceritificate heirarchy here
<thelema> NaCl: broken firefix...
<thelema> *firefox
<NaCl> konqueror fails the same way
dcolish has quit [Quit: Coyote finally caught me]
<thelema> odd.
<NaCl> firefox config is irrelevant, it still fails without it
junsuijin has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
wtetzner has quit [Remote host closed the connection]
<NaCl> gildor: https://www.sslshopper.com/ssl-checker.html#hostname=forge.ocamlcore.org
sebz has quit [Quit: Computer has gone to sleep.]
wtetzner has joined #ocaml
sebz has joined #ocaml
ttblrs has quit [Ping timeout: 260 seconds]
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
jimmyrcom has quit [Ping timeout: 250 seconds]
sebz has joined #ocaml
seafood_ has joined #ocaml
<adrien> well, was Yoann Padioleau also had an issue when using brz, might not be unrelated
sebz has quit [Quit: Computer has gone to sleep.]
<flux> works for me (TM)
sebz has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
junsuijin has quit [Quit: Leaving.]
ygrek has joined #ocaml
sebz has joined #ocaml
seafood_ is now known as seafood
seafood has quit [Quit: seafood]
patronus_ has joined #ocaml
zzz_ has joined #ocaml
Cyanure has joined #ocaml
patronus has quit [Read error: Connection reset by peer]
zzz_` has quit [Remote host closed the connection]
joewilliams_away has quit [Quit: ZNC - http://znc.sourceforge.net]
joewilliz has joined #ocaml
Yoric has joined #ocaml
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
ftrvxmtrx has joined #ocaml
sebz has quit []
Snark has joined #ocaml
Yoric has quit [Quit: Leaving.]
lopex has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
BiDOrD_ has joined #ocaml
BiDOrD has quit [Ping timeout: 240 seconds]
ftrvxmtrx has joined #ocaml
surikator has joined #ocaml
spearalot has joined #ocaml
lopex has quit [Ping timeout: 268 seconds]
ygrek has quit [Ping timeout: 245 seconds]
lopex has joined #ocaml
Yoric has joined #ocaml
ygrek has joined #ocaml
<adrien> even though I believe using gtk is fine, I think we could have a better toolkit (not qt, something in ocaml)
<adrien> actually, I'm still supposed to look at enlightenment
lopex has quit []
ikaros has joined #ocaml
Yoric has quit [Quit: Leaving.]
<adrien> I didn't know ocamleditor was that advanced: http://ocamleditor.forge.ocamlcore.org/main_window.png
spearalot has quit [Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/]
surikator has quit [Quit: Computer is sleeping. I'm probably not.]
Yoric has joined #ocaml
<flux> while an ocaml-based toolkit would be nice, I think it would be a major undertaking; perhaps too major to advance beyond mediocrity
<adrien> agreed, unfortunately
<Yoric> Well, it's always possible to write a high-level OCaml API with a back-end based on some existing toolkit.
<adrien> that's what I hope to have with the enlightenment libraries, they _should_ be saner
spearalot has joined #ocaml
<adrien> the french community is also very active (at least on IRC) and that makes it easier to find someone to hit with a stick when something is wrong =)
<adrien> hmpf, I'm stupid, I was going to start a new library to complement lablgtk2 when I can complement it directly
<Yoric> :)
<adrien> goal is to get a message each time a glib signal is emitted, will be useful when wondering which signal to connect to
surikator has joined #ocaml
surikator has quit [Client Quit]
jimmyrcom has joined #ocaml
Dynetrekk has left #ocaml []
yroeht has quit [Ping timeout: 260 seconds]
milosn_ has quit [Ping timeout: 258 seconds]
ikaros has quit [Quit: Ex-Chat]
zorun has quit [Ping timeout: 240 seconds]
zorun has joined #ocaml
<hcarty> adrien: I've tried to build ocamleditor under Linux multiple times, sadly without any success. It looks promising.
ygrek has quit [Ping timeout: 245 seconds]
<adrien> first time there is an ocaml program that only builds on windows? :P
<hcarty> adrien: I started a simple Gtk wrapper a while ago but I haven't had time to do more with it: https://forge.ocamlcore.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=gtk-light/gtk-light.git;a=blob_plain;f=basic_gui_test.ml;hb=HEAD
<adrien> hcarty: hmmm, would you happen to have put range bars around a drawing_area?
<hcarty> lablgtk2 hidden behind a light syntax + FRP would make for a nice toolkit I think. FrGui had some of that but was sadly abandoned.
<hcarty> adrien: Range bars?
<adrien> scrolling bars
<hcarty> Oh, right. I've done something like that before.
<adrien> right, (labl)gtk's api is simply too big for most uses
<hcarty> I don't remember if it was with gtk-light, but that small application was one of my targets
<hcarty> A range bar, or perhaps a slider, which controlled the zoom level of a plot displayed in the drawing area
<adrien> because I've tried doing so and have failed so far but I'm adding them to an already existing application and that's not the best way to learn
<adrien> s/to learn/for a first time/
uo3 has joined #ocaml
<adrien> hmm, no, rather, vertical and horizontal adjustments
<adrien> for scrolling/panning
<hcarty> I have not done that. I used a second drawing area with a zoomed-out view.
<hcarty> And then updated a zoomed-in drawing area view based on the location of the mouse, or possibly the location of mouse clicks
<hcarty> I don't remember which.
<hcarty> So the full view was always fixed and the zoomed in view panned according to user input in the full view.
<adrien> okay
<adrien> well, I'll probably see next week, but I'll start from scratch and learn from there
milosn has joined #ocaml
spearalot has quit [Ping timeout: 260 seconds]
ttblrs has joined #ocaml
<uo3> Hello everybody. I'm looking for some graphic lib with non-native gui and VRAM locking. What can you advise me?
oriba has joined #ocaml
<adrien> bah, I can't get it to list the signals while I managed to do it inside cowboy/glib
yroeht has joined #ocaml
uo3 has quit [Remote host closed the connection]
dcolish has joined #ocaml
<adrien> and it's quite annoying when a you end up converting between C unsigned ints and ocaml signed ints
<adrien> and I really must learn how to raise exceptions from C =)
<NaCl> woohoo http://caml.inria.fr is down
<adrien> yeah \o/ spent god knows how long on a stupid mistake in my C bindng
<adrien> I was taking the "value type" argument and passing it to a C function directly without converting it
Yoric has quit [Quit: Leaving.]
oriba has quit [Quit: oriba]
hto has joined #ocaml
Yoric has joined #ocaml
lopex has joined #ocaml
<adrien> damn, I have to give up, there's a function I can't bind myself ='(
Yoric has quit [Client Quit]
zorun has quit [Ping timeout: 268 seconds]
zorun has joined #ocaml
hto has quit [Quit: Lost terminal]
<NaCl> adrien: awwwww
Cyanure has quit [Ping timeout: 240 seconds]
<adrien> NaCl: oh? really? you want to bind GSignalEmissionHook to lablgtk2? \o/
<NaCl> I'd rather have "device" :P
<NaCl> since most of what I'd be doing is transferring UI stuff to gtk stuff
<NaCl> s/gtk/vector mapping/
<adrien> ah, right
<adrien> today or is tomorrow fine?
<NaCl> once I figure out how to do it, anyway
dmhouse has joined #ocaml
Morphous is now known as Amorphous
mdelaney has quit [Quit: mdelaney]
<NaCl> is the cairo guy here?
<NaCl> adrien: ^
<adrien> Christophe Troestler, no afaik
<adrien> others, maybe
<NaCl> lots of stuff is missing. xD
<adrien> some modules in particular?
<NaCl> naw
<NaCl> just incomplete docs
<NaCl> missing images that make the docs make more sense. xD
<adrien> ah, definitely
<adrien> it's an issue with bindings that follow the API of the original library very closely, they tend to refer to the original documentation which is in a separate location
<adrien> we need an easy way to retrieve it and copy it
Yoric has joined #ocaml
<NaCl> actually, in this case, it is just making sure that the images match http://www.tortall.net/mu/wiki/CairoTutorial
<adrien> hmmm, I can't see the issue
<NaCl> eh?
* NaCl is probably an idio
<NaCl> t
zzz_ has quit [Remote host closed the connection]
zzz_ has joined #ocaml
<NaCl> adrien: do the docs get generated on installation?
<NaCl> s/docs/images
<adrien> no idea
<adrien> ah, you mean the documentation on your own computer?
<NaCl> yes
<NaCl> local docs
<adrien> never took a look at these
<flux> me makes pretty? picture with ocaml: http://www.modeemi.fi/~flux/colors.png
<flux> ..took only 5 minutes to render that, perhaps the next step is to optimize it a bit..
<NaCl> flux: GL?
<flux> nope, plain CPU
<flux> actually a pixel shader would likely boost that like 1000 times
<NaCl> that looks ominously like a GL tutorial. :P
<flux> well, it's doing something completely different
<adrien> flux: heheh :P
<adrien> what's the data
* NaCl is looking at making handwriting processing application
<flux> there are four values placed on a 2d surface, and for each pixel its color is based on how far it is to the other data points
<flux> considering that the obstacles make the distance longer
* NaCl has to process pretty picutres
<flux> so in principle I'm going to convert the floor plan of my house to that and add a certain set of temperature measurements into it
<flux> and it should draw me a continuous color map that has maybe some touch to reality even in points that are not measured
<flux> and while I could just let it render the mapping data for like a day or a week, perhaps I'll just try to make it faster instead..
junsuijin has joined #ocaml
<adrien> well, if you don't make it faster, the rendering will make your computer hotter, which, in turn, will heat your house and make the temperature measurements wrong ;-)
<adrien> plus it's fun
<flux> actually I already know I could make it perhaps 100 times faster by cheating a bit: instead of doing that for each pixel, do it for 1/100 pixels and then gouraud shade the rest
<flux> on the other hand I think my complexities suck, so it may take a very long time to render my house in that :)
<NaCl> adrien: feel free to use the new flamel if you want
<NaCl> or tweak it
<NaCl> or suggest patches
<flux> adrien, well it wouldn't matter, I only need to consider the locations of temperature measurement points, not heat sources :)
<adrien> flux: the task doesn't seem to require a huge complexity
<flux> adrien, no, but its implementation involves scanning the points many times
<adrien> NaCl: I think I could use a few pretty pictures =)
<adrien> flux: is it possible to reduce that?
<flux> adrien, for example each added vertex is calculated its distance from all points, and that calculation involves iterating all other vertices: boom, O(n^2)
<flux> sure. I could use BSP to cut down that number.
<NaCl> adrien: I changed how files are named to use full date-time
<adrien> so O(n^4) in the end?
<NaCl> instead of unix time
<adrien> or rather O(n^2 * m^2)
<flux> actually that part of calculation is so fast anyway, so it's not critical. but that calculation that I do for each pixel, that could benefit from the BSP.
<NaCl> which makes file names huge
<adrien> NaCl: indeed :P
<flux> becaue that calculates for each pixel and for each vertex if it can see them, by scanning all edges -> O(num_pixels * n^2)
* NaCl can't get cairo to draw anything. :(
<adrien> are you flushing?
<NaCl> uh, no
Snark has quit [Quit: Quitte]
<adrien> "close" or something like that
hto has joined #ocaml
<NaCl> uh, where?
Yoric has quit [Quit: Leaving.]
<flux> yeah, I've closed or flushed the cairo context somehow before saving
<adrien> "stroke"
<NaCl> I've been doing that to no effect
<NaCl> on click: move_to point
<NaCl> on motion: line_to point ; move_to point
<NaCl> on release: stroke
ttamttam has joined #ocaml
<adrien> do you "reload" the cairo stuff on the drawing_area?
<NaCl> reload?
<adrien> the contents of the cairo context and the gtk drawing area are not synchronized I think
* NaCl thinks he disabled double-buffering
<adrien> I'm not sure it's not a separate thing
<NaCl> wait. how often do I need to create new cairo contexts?
<adrien> can't you reuse the same all the time?
<NaCl> gtk_demo.native: cairo-surface.c:637: cairo_surface_destroy: Assertion `((*&(&surface->ref_count)->ref_count) > 0)' failed.
<NaCl> that's what happens when you recycle the same one over and over. :P
<adrien> can I see the code?
<NaCl> for the deom?
<NaCl> sec
<NaCl> this is most invonvenient
<NaCl> *inconvenient
<adrien> woops, indeed, ended up crashing here
<NaCl> adrien: looks like the contexts aren't being cleaned up.
<adrien> I haven't read the code yet but I don't understand at all how the application behaves :P
* NaCl senses slightly that the application would be best written in C.
<NaCl> due to the increased number of examples
<NaCl> wat. this does not explain how to draw stuff immediately, at demand
_habnabit has quit [*.net *.split]
<NaCl> (hwr.native:21520): Gtk-WARNING **: Events of type GDK_EXPOSE cannot be synthesized. To get the same effect, call gdk_window_invalidate_rect/region(), followed by gdk_window_process_updates().
<adrien> _much_ faster to make it crash by calling Gc.full_major inside the expose handler
* NaCl was supposed to know this how?
<NaCl> adrien: I'm trying to cause an expose event
<NaCl> trigger a drawing update on a mouse motion
<adrien> "cairo_surface_destroy" means it's happening inside a finalization function (which seem to be triggered by a full major and not only a compact as I thought \o/ ), and since Gc.compact () ist verboten in lablgtk, I fell back to full_major
<NaCl> Well, that solves that problem
<NaCl> still doesn't solve the painting problem, though
_habnabit has joined #ocaml
Reaganomicon has joined #ocaml
* NaCl may have to make a backingstore
<adrien> it looks like a serious bug in cairo(_gtk), the example is enough to make it crash
<NaCl> looks like ocaml may not work out all that well for this, after all
* NaCl does something else for a bit
ftrvxmtrx has quit [Read error: Connection reset by peer]
ftrvxmtrx has joined #ocaml
Yoric has joined #ocaml
Anarchos has joined #ocaml
<adrien> NaCl: sounds pretty obvious actually
<adrien> /* The only way to create a context is from a surface. To express the
<adrien> non-gtk API: cr = cairo_create(SURFACE_VAL(vsurf));
<adrien> gtk API: cairo_t *cr = gdk_cairo_create(GdkDrawable_val(vdrawable));
<adrien> comment doesn't hold for the gtk API
<NaCl> eh?
<adrien> and since the surface had never had its refcount increased, it can't be decreased
<adrien> or work around it, I don't know
* NaCl is not looking into tweaking API
<NaCl> s
<adrien> it's only adding one line I think
<adrien> of C
<adrien> but that's probably not the best solution
<adrien> because that relies on the fact that a refcount of 0 in the finalizer can only be achieved by using gtk
<adrien> I don't know if that's true
<adrien> you need to ask someone more knowledgeable about the project_s_
<adrien> also, the check might not be a bad thing in any case
<adrien> a potential memleak is better than aborting the program
<adrien> I hate how you can completely mispell a function name in C and still get the thing to compile
sebz has joined #ocaml
<adrien> line 55 of cairo_ocaml_types.c, insert this before the call to cairo_surface_destroy: if (cairo_surface_get_reference_count(surface) > 0)
<adrien> and spam some of the maintainers until they fix the issue and release a new tarball ;-)
<adrien> hcarty: did you ever touch cairo2's gtk interface? =)
Yoric has quit [Quit: Leaving.]
spearalot has joined #ocaml
<NaCl> adrien: still crashes
<adrien> you recompiled, reinstalled, recompiled your app?
<NaCl> moved to a different machine
<NaCl> yup, still fails
<adrien> because it fixed the issue at once for me, also you shouldn't get the same assert since the test is specifically for that
ikaros has joined #ocaml
<adrien> I _really_ can't make it crash
<NaCl> line 54 of cairo_ocaml_types.c is now if (cairo_surface_get_reference_count(surface) > 0)
<adrien> and line 55?
<NaCl> cairo_surface_destroy(surface);
<adrien> and you get the same assert error when it dies?
<NaCl> gtk_demo.native: cairo-surface.c:637: cairo_surface_destroy: Assertion `((*&(&surface->ref_count)->ref_count) > 0)' failed.
<NaCl> sure looks like it
<adrien> I'm pretty sure it's not using the new code when compiling
<adrien> uncomment one of the fprintf and see whether it gets displayed
dmhouse has quit [Remote host closed the connection]
<NaCl> up
<NaCl> yup
<NaCl> it displays them
* NaCl was just resizing it repeatedly for a few seconds
<NaCl> not immediately
<NaCl> takes a while
ttamttam has quit [Ping timeout: 260 seconds]
<NaCl> then my terminal gets flooded
<NaCl> then very soon after (maybe immediately) the program aborts
<adrien> I can't make it crash anymore here
* NaCl shrugs
* NaCl considers using C
<adrien> I also put an else clause to the test to see when it was _not_ destroying the surface
<adrien> fprintf(stderr, "NOT DESTROY surface\n"); fflush(stderr);
<adrien> can you add it to see if it tries destroying it only once or all the time?
<NaCl> never
<NaCl> never once destroys it
<NaCl> fails to destroy it, I mean
<adrien> hah, got it!
<adrien> but it might be another path
<adrien> calling Gc.full_major in the expose callback avoided the issue
<NaCl> indeed it does
<NaCl> and the calls now alternate
<NaCl> printfs, I mean
<adrien> according to the fprintf() calls, the crash happens when calling cairo_destroy() and not cairo_surface_destroy()
<NaCl> Ok, so...?
Yoric has joined #ocaml
<adrien> NaCl: could that second bug be in cairo itself?
<NaCl> you mean the painting one?
<adrien> the one which is avoided by Gc.full_major and which happens when calling cairo_destroy()
<NaCl> I have no way to confirm that
* NaCl would much rather be writing software, not finding bugs in other software
Yoric has quit [Client Quit]
<adrien> I agree this is really annoying
<NaCl> I could attempt to verify it
mdelaney has joined #ocaml
<adrien> I see mostly two possibilities: 1- cairo_surface_destroy() should actually never assert, 2- cairo_destroy() should check the reference count of the surface before calling cairo_surface_destroy()
<NaCl> I have the most recent version here
<adrien> another possibility is that something "broke" in the value that is stored on the ocaml side but I don't think it's very likely
<NaCl> system monitor suggests no memory leak is occuring
<adrien> http://linuxtesting.org/upstream-tracker/changelogs/cairo/current/changelog.html mentions a recent issue with that (although unrelated)
<adrien> shows the reference counting stuff in C is a mess
<adrien> so errors can creep in quite easily I think
<NaCl> huge library is huge
<NaCl> uh
<NaCl> adrien: what version do you have?
<NaCl> of cairo
<adrien> 1.10.2
<NaCl> http://cgit.freedesktop.org/cairo/ says there is a tagged tarball for 1.11.2
<adrien> tarball? I only know about git :P
<NaCl> uh, ok
<adrien> right, huge library is really slow to fetch
sebz has quit [Quit: Computer has gone to sleep.]
* NaCl does not like it when his connection is throttled down to dialup speeds
<NaCl> library does not have any included examples
surikator has joined #ocaml
mdelaney has quit [Read error: Connection reset by peer]
mdelaney_ has joined #ocaml
<adrien> NaCl: well, right now, I can't say more and I need to sleep
<NaCl> kk
<NaCl> sleep well
* NaCl was going to look at this more tomorrow anyway
<adrien> if I were to continue, I'd probably make a reproducer in C
<NaCl> I was thinking about that, but ATM, I'm feeling lazy
<adrien> this is actually also an issue for me so I'll probably look at it again tomorrow (to make the reproducer)
<adrien> we'll see how it goes but currently, I'm not in a happy mood
<NaCl> I could do it tonight, but you know more about this than I do. xD
<adrien> my approach would be copying the C stubs
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
oriba has joined #ocaml
struktured has quit [Ping timeout: 245 seconds]
everyonemines has joined #ocaml
spearalot has quit [Quit: Computer has gone to sleep]
BiDOrD_ has quit [Ping timeout: 240 seconds]
sebz has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
BiDOrD has joined #ocaml
struktured has joined #ocaml
ftrvxmtrx has joined #ocaml
Amorphous has quit [Read error: Operation timed out]
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
Amorphous has joined #ocaml
hto has quit [Read error: Operation timed out]
struktured has quit [Quit: Konversation terminated!]
struktured has joined #ocaml
hto has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
wormphlegm has joined #ocaml
sebz has joined #ocaml
joewilliz is now known as joewilliams_away
ikaros has quit [Quit: Ex-Chat]
Reaganomicon has quit [Read error: Connection reset by peer]
<everyonemines> I get the impression that in ocaml, like with lisp, you're expected to write a bunch of standard code for yourself to reuse. Are there any "personal libraries" that people have released?
<_habnabit> Batteries
<everyonemines> I know about batteries. That's not quite what I mean.
<_habnabit> How isn't it?
<everyonemines> Batteries is like an extended version of the ocaml standard library.
<everyonemines> Even with that, you still need to write a bunch of stuff to begin coding efficiently in your own personal way.
<everyonemines> I'm talking about personal code collections that people use for their projects which they released.
<_habnabit> I really don't understand the distinction you're trying to draw here.
<everyonemines> Suppose you deal with arrays a lot. Do you write Array.length every time? Or do you make an abbreviation?
<_habnabit> I've made local module abbreviations, but nothing I'd want global, or something that was more than two lines, or wasn't in batteries.
<everyonemines> What I want is some samples of the infrastructure code that people have written for themselves.
<everyonemines> to get some ideas for what might be helpful
everyonemines has left #ocaml []
everyonemines has joined #ocaml
ulfdoz_ has joined #ocaml
ulfdoz has quit [Ping timeout: 252 seconds]
ulfdoz_ is now known as ulfdoz
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
sebz has quit [Client Quit]
lopex has quit []