2011-09-05

<hcarty> Unless that what the code you pastebin'd is...
<hcarty> NaCl: Do you get the same assert with the gtk_demo that comes with cairo2?
<hcarty> Christophe Troestler may be able to provide some insight
<hcarty> It may be worth sending an email/submitting a bug report to the forge
<hcarty> NaCl: Please leave a note if you find out what the problem was! I'll do the same if I can find it.
<hcarty> s/look/looks/
<hcarty> Nevermind... look like cairo2
<hcarty> NaCl: Are you using cairo or cairo2 on the OCaml side?
<hcarty> The callback would call queue_draw and that would trigger the assert - immediately if Gc.full_major was called first.
<hcarty> I was using Gtk-light for this project, so I used a wrapper function.
<hcarty> NaCl: GtkBase.Widget.queue_draw I think
<hcarty> I'm not really sure how to test it either. I don't seem to get the problem from expose events, but I do when a redraw is triggered from a callback. That may be luck of the draw though.
<hcarty> NaCl: BTW - I think that Cairo's x.y.z versions are development versions when y is odd
<hcarty> NaCl: ^^
<hcarty> adrien: I ran into the same refcount problem. I don't know if it is a Cairo 1.10.2 problem or a ocaml-cairo2 problem as I moved to those version from Cairo 1.2.x and ocaml-cairo-original at the same time.

2011-09-04

<adrien> hcarty: did you ever touch cairo2's gtk interface? =)
<hcarty> So the full view was always fixed and the zoomed in view panned according to user input in the full view.
<hcarty> I don't remember which.
<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 have not done that. I used a second drawing area with a zoomed-out view.
<hcarty> A range bar, or perhaps a slider, which controlled the zoom level of a plot displayed in the drawing area
<hcarty> I don't remember if it was with gtk-light, but that small application was one of my targets
<hcarty> Oh, right. I've done something like that before.
<hcarty> adrien: Range bars?
<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.
<adrien> hcarty: hmmm, would you happen to have put range bars around a drawing_area?
<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
<hcarty> adrien: I've tried to build ocamleditor under Linux multiple times, sadly without any success. It looks promising.

2011-08-28

<hcarty> Ok, thanks
<hcarty> ygrek: Would you recommend your ocurl fork or the original sf.net-hosted ocurl at this point?
<hcarty> Not the Ubuntu package, but ocurl from source (assuming you installed OCaml from source)
<hcarty> Manually install ocurl
<hcarty> You can't use the Ubuntu packages with your manually installed OCaml
<hcarty> You don't have ocurl installed manually
<hcarty> Your manually installed stuff seems to be found anyway
<hcarty> ocurl: Along with all of the other OCaml-related packages you have installed (libraries, etc.)
<hcarty> Remove any Ubuntu packages with ocaml (or caml) in the name
<hcarty> If you want to use Ubuntu's packaged libraries then you should stick with the Ubunut-supplied version. If not, stick with however you installed 3.12.0
<hcarty> It sounds like one was installed with the Ubuntu packages (3.11.2) and 3.12.0 was installed some other way.
<hcarty> It depends on what you want to keep and how you installed each version
<hcarty> Then you have multiple versions installed :-)
<hcarty> ocurl: Or 'which ocamlfind' to see if you are running something other than /usr/bin/ocamlfind
<hcarty> ocurl: Do you have multiple OCaml installs by any chance?
<hcarty> (assuming Debian or Ubuntu)
<hcarty> ocurl: dpkg -l |grep ocaml lists libcurl-ocaml and libcurl-ocaml-dev?
<hcarty> Time to update oasis-db with the latest.
<hcarty> flux: Ah, it looks like my zed, lambda-term and utop are not the most up to date versions.
<flux> hcarty, it's a binary lambda-term module installs
<hcarty> flux: lambda-term-actions where?
<flux> hcarty, lambda-term-actions lists which actions are available
<flux> hcarty, no, but I put C-w: kill-prev-word\nM-b: prev-word\nM-f: next-word\n into ~/.lambda-term-inputrc
<hcarty> flux: Do you know of a list of configuration options for utop/lamdba-term?

2011-08-25

<thelema> _habnabit: hcarty's solution seems reasonable to me
<hcarty> adrien: Ah, too slow!
<hcarty> Or change val i = 1 to method i = 1
<hcarty> Nope :-)
<hcarty> method get_i = i
<hcarty> _habnabit: ... method add x = {< i = i + x#i >} ... but i needs to be a method in that case, or have an accessor
<_habnabit> hcarty, right, but if it takes an integer. not an int.
<hcarty> _habnabit: ... method add x = {< i = i + x >} ... or something along those lines may do what you want
<Anarchos> hcarty you might be right
<hcarty> adrien, Anarchos: I don't think a class can - I think they are limited to value definitions and methods.
<hcarty> zorun: No problem. My guess is that this is, in part, because of the license differences (LGPL vs QPL)
<hcarty> Anything messing with the toplevel directly will presumably need to link with core pieces of OCaml
<hcarty> zorun: I don't think that the toplevel bits are normally exposed
<hcarty> Just warning ahead of time
<hcarty> Not needed, but handy.
<hcarty> thelema: Yep. It would be handy to have a collection of those tarballs all together to speed up the process.
<thelema> hcarty: it should be just a matter of re-uploading the tarballs
<hcarty> gildor: That would allow a few of us to quickly re-populate the next version/replacement
<hcarty> gildor: the odb/oasis-db site is wiped, it would be useful to have a dump of all of the existing packages available.
<hcarty> gildor: An oasis-db request - if/when the data currently driving
<hcarty> I have not
<hcarty> That is true I suppose.
<hcarty> They are similar, but utop has better context-sensitive completion
<hcarty> Skip it for utop :-)
<hcarty> flux: It's a step up from lwt-toplevel, if you're used that before
<flux> hcarty, nice. I guess I should try it.
<hcarty> flux: It's quite nice, and installable with odb, given a small amount of extra effort.
<hcarty> flux: I've used (and I use!) utop a lot now

2011-08-23

<hcarty> DimitryKakadu: For classes vs modules - It is probably fine to use either. If one feels more natural or easier to you then go with that.

2011-08-22

<adrien> hcarty: I haven't had much to do actually
<hcarty> adrien: If you have time to write up something like that, of course
<hcarty> adrien: Do you have a recipe to make this work? I'm sure it would be of interest to other folks.
<adrien> hcarty: thanks =)
<hcarty> adrien: Well done :-)

2011-08-20

<Rakko> hcarty: I don't see a book linked besides the manual
<hcarty> The official manual is actually quite readable. And there is an out of print book linked from the main OCaml site which is pretty good as well.
<hcarty> Hickey's book/PDF is quite nice
<hcarty> e
<hcarty> Rakko: Yes, that's the on
<hcarty> Rakko: I've heard that Practical OCaml is awful
<hcarty> Rakko: Hello

2011-08-19

<hcarty> It's ok, I just don't want to take credit for his good work :-)
<hcarty> thelema: I think someone else made that fix... but it was made and available through odb before I spent any time with 3.12.1
<thelema> NaCl: hcarty fixed that so well that I never even saw the problem.
<hcarty> Don't know the link off hand
<hcarty> NaCl: Browser -> Ctrl-K -> ocaml batteries -> enter :-)
<NaCl> hcarty: link me
<hcarty> Previous versions didn't play nicely with OCaml 3.12.1
<hcarty> NaCl: I think you need 1.4.1
<hcarty> NaCl: Are you using the latest version of Batteries?
<adrien> hcarty: well, I've fixed these issues
<hcarty> adrien: You may be able to work around it in the _oasis file
<adrien> hcarty: thanks, so I can't hack around it in the configure stage :P
<hcarty> adrien: Yes
<hcarty> thelema: Doesn't make stop once an error result is returned?
<thelema> hcarty: failing to uninstall shouldn't cause the entire make process to fail
<hcarty> thelema: It would fail, which would cause the entire make process to fail. If this uninstall is a prerequisite of the install target then they would be stuck.
<hcarty> A user may want to install a library which exists in a system location, but install it somewhere else where they have permission.
<thelema> hcarty: oops, you're right.
<hcarty> thelema: I've used it for a few libraries and I get the standard "this library already exists" error from ocamlfind if I try to "make install" twice without "make uninstall" between
<hcarty> thelema: I don't think oasis removes existing installs
<thelema> hcarty: this means that oasis and batteries are doing the wrong thing, and that odb needs to step up to uninstall a package before reinstalling
<hcarty> thelema: But a "make uninstall" target is (always?) welcome
<hcarty> thelema: Probably not

2011-08-18

<hcarty> Whoever it was released their code/patches
<hcarty> accel_: I think someone did something for using OCaml to write iPhone applications. I don't know if that involves cocoa.

2011-08-16

<hcarty> Which is part of why that notation is so handy :-)
<adrien> hcarty: exactly
<hcarty> adrien: True... 50 places is not enough if you have 1e-200
<hcarty> qdl: Then it's not an issue
<hcarty> qdl: Keep track of the precision of your calculations
<hcarty> qdl: It is if you spell it "Printf.sprintf"
<hcarty> qdl: Printf.sprintf
<hcarty> qdl: You can use sprintf if you want more control over the format
<hcarty> thelema, NaCl: This sounds like something which would be helpful once there are 10s of mirrors, rather than 1 or 2
<hcarty> thelema: One mirror would be plenty to start out
<hcarty> thelema: Completely agreed.\
<thelema> hcarty: we should delay this over-engineering until we have enough mirrors to make a mirrorlist worthwhile, no?
<hcarty> thelema: odb could avoid downloading a mirror list unless the hard coded mirrors are not available
<hcarty> Since you could presumably pull packages from there as well
<hcarty> Although, if you have one mirror you can pull a list from you may not need the rest
<hcarty> thelema: Each server could hold a list of mirrors, and odb could come pre-loaded with a set of mirrors hard-coded.
<thelema> hcarty: todo: mirror system for odb -- there'll still have to be a toplevel server with the mirror list
<hcarty> Unofficial mirrors could pull specific content at regular intervals
<hcarty> "Official" mirrors could be pushed to each time a package update occurs
<hcarty> thelema: Looks like it. One of the pitfalls of a development system I suppose
<thelema> hcarty: I guess we'll have to wait for gildor to get back from vacation...
<hcarty> http://oasis.ocamlcore.org/dev/odb/ -- yep, a 503 error
<hcarty> Reliability
<thelema> hcarty: why mirror odb?
<hcarty> thelema: A mirror of oasis-db would be ideal, but that requires more infrastructure on the mirror side
<thelema> hcarty: isn't a better solution to have a mirror of oasis-db?
<thelema> hcarty: is oasis-db down?
<hcarty> thelema: A simple, static mirror updated by cron or similar, would hopefully not be too much to maintain.
<hcarty> thelema: A reasonably near-term goal for odb may be to have a mirror of the odb-relevant portions of the oasis-db site
<hcarty> That's a bummer
<hcarty> NaCl: Thanks. It looks like the forge is up, but the oasis-db site is down
<hcarty> Is ocamlcore down?

2011-08-12

<hcarty> Didn't think so... it was worth a shot!
<hcarty> Could you provide the whole thing as a Linux VM image?
<hcarty> adrien: So Windows support may not be there yet
<hcarty> adrien: I know the authors use a patched oasis to support .cmxs generation
<hcarty> But if there isn't a need, then it may not be worth the effort.
<hcarty> If you have 5 functions to wrap for something you want to do, wrap and release those 5. If someone else needs 5 more, hopefully they wrap and contribute those :-)
<hcarty> NaCl: If you do go through with it, 10% coverage is not a bad place to start.
<hcarty> NaCl: That Christophe puts a lot of effort into the software he releases :-)
<hcarty> It probably helps that it is based on the existing C and Python Cairo tutorials.
<hcarty> The tutorial is also relatively complete, which is nice (and rare for OCaml modules)
<hcarty> There is a gtk_demo.ml file
<hcarty> At this point I think the new (Christophe Troestler) bindings are a bit more complete. I'm not sure that they support Pango though, which is supported by the original bindings.
<adrien> hcarty: yeah, it's tricky and afaik, Archimedes' result is not perfect, but it exists and I can probably find proper settings for it
<hcarty> adrien: Christophe Troestler wrote new Cairo bindings after finding a number of GC and segfault issues with the previously existing bindings
<hcarty> But I agree that most (all?) available plotting libraries are severely lacking
<hcarty> adrien: Intelligent removal of plotted points is a tricky thing to get right
<hcarty> bitbckt: It would definitely be a worthwhile addition
<hcarty> bitbckt: I emailed the findlib author to ask about the possibility of adding version support. I don't remember if I heard anything back.

2011-08-11

<bitbckt> thelema, hcarty: it would be nice if findlib used version numbers in installed packages' root dirs. So you could install multiple versions and choose at compile/link time.
<hcarty> thelema: That seems like a reasonable change to make if the findlib name is changing as well
<hcarty> You would need to change the oasis package name as well, I suppose.
<hcarty> Ah, right.
<hcarty> Would it show up as a different package, since the findlib name is different?
<hcarty> I like it
<hcarty> batteries3, etc.
<hcarty> I would be happy with batteries = v1, batteries2 = v2
<hcarty> thelema: I've been thinking about that. It would make it possible/easier to have both v1 and v2 installed together
<thelema> hcarty: any opinion on making batteries v2.0 use a different ocamlfind package name?
<hcarty> adrien: Ah, drat.
<adrien> hcarty: no, because when I tried to do that in the CMakeList file, it would automatically disable qt
<hcarty> adrien: Did you try forcing static linking in the PLplot build? That's currently doesn't work with the OCaml bindings, but it should work with C++.
<hcarty> I agree that --no-godi makes more sense that --godi, given how it works
<hcarty> thelema: That looks like a nice set up updates
<hcarty> thelema: Glad I could help. I'm sorry that they weren't part of a pull request. I haven't had a chance to sit and hack properly.
<thelema> hcarty: many improvements to odb just pushed - thanks for the patches.
<hcarty> Nevermind - that exception is not coming from Batteries
<hcarty> This is odd (and unrelated to PLplot...) - I'm getting Invalid_argument("Key/value not found") from BatMap.StringMap.iter.
<hcarty> adrien: I understand - good luck in wrapping this up!
<hcarty> adrien: They can probably give better assistance than I can
<hcarty> adrien: If you do have feedback on PLplot on Windows, I'm sure the folks on the mailing list will be happy to hear about it
<hcarty> I doubt that will happen any time soon though, unfortunately.
<hcarty> One Of These Days I should setup a Windows VM to test PLplot + OCaml + Cairo + Gtk under that environment
<hcarty> NaCl: Yes, I think those were part of the reason for the move
<NaCl> hcarty: windows doesn't have a sh script interpreter
<hcarty> adrien: My understanding is that KDE's choice to use CMake was an influence. And the previous autoconf/autotools/whatever-it-is-called build system was apparently too fragile when porting to different platforms.
<adrien> hcarty: that was maybe a bad design decision on their end then
<hcarty> NaCl: My guess is that a lot of the complexity in CMake comes from the languages it targets
<hcarty> adrien: CMake is supposedly easier to work with when targeting native compilation on multiple platforms. But the CMake language is kind of awful.
<hcarty> adrien: And I agree regarding CMake, but the decision was made before I joined the project
<hcarty> adrien: Depending on your target, jqplot is a relatively simple Javascript option
<hcarty> It's not hard to do, but it is not included in PLplot out of the box
<hcarty> Panning, for example, requires you to write the appropriate code to update the plot and/or display.
<hcarty> Honestly, I think matplotlib may give you panning and such for fewer lines of code than PLplot. PLplot has a lot of nice features, but the widget support is pretty bare-bones.
<hcarty> Sounds reasonable - I'm sorry I can't be more help!
<adrien> hcarty: yeah, that is what is currently failing, but I'm going to see what is going on during the compilation
<hcarty> examples/c/ if you are going to use Cairo (or examples/ocaml/)
<hcarty> If you are going to use Qt
<hcarty> adrien: The examples/c++/ directory should have something to start from
<hcarty> I know that PLplot has been used that way with both Qt and Cairo/Gtk under Linux
<hcarty> I'm pretty sure the PLplot C++ interface + Qt has been used that way on Windows
<hcarty> But it's not tested, and anything Windows-specific is not handled
<hcarty> It may work - I don't think that there is anything to prevent it
<hcarty> adrien: None, only Linux and OSX
<adrien> hcarty: saw any report of plplot and ocaml on windows?
<hcarty> adrien: My first guess is that's not good.
<adrien> hcarty: ................. test application exits with status code 1
<hcarty> adrien: Of course!
<hcarty> There are build instructions but that's about it
<hcarty> adrien: Not that I know of. There was some talk about putting a binary distribution together, but I don't think any of the developers use Windows regularly
<adrien> hcarty: no windows binaries?
<hcarty> ... and, of course, the fact that it's python :-)
<hcarty> matplotlib was a contender for a while, but I couldn't stand the API. It quite possible that reaction was due to not spending enough time with it...
<hcarty> adrien: Indeed! That is part of why I started using PLplot initially.
<adrien> hcarty: well, it might be ok after all: I had been using applications (as opposed to libraries) and forgot that with libraries, I have a better control over what I can send
<hcarty> adrien: Yes, you are correct - PLplot will do what you ask it to without any attempt to simplify the data
<adrien> hcarty: or is it my duty?
<adrien> hcarty: about plplot, if I give it 100000000000000000000000000000 points but my display can only accomodate 1000 points, will it skip some of the points automatically?

2011-08-10

<hcarty> gildor: I built GODI from that rocketboost package recently and it worked without any errors
<gildor> is there any GODI specialist aroun (hcarty ?)
<technomancy> hcarty: oh yeah, good point. I will give that a shot later.
<hcarty> technomancy: You could probably do a relatively simple backport if you've built Debian/Ubuntu packages from source before
<hcarty> technomancy: Cairo won't tie you to a windowing system at all
<hcarty> gildor: Take your time - I look forward to the update
<gildor> hcarty: but it takes time because I have a problem with libc6 version mismatch between my computer and the server
<gildor> hcarty: which includes _oasis online edit and synchronization with debian
<gildor> hcarty: thx, when I'll have time I'll update to my current version (~alpha3)
<hcarty> gildor: I have been enjoying the oasis-db web interface. oasis-db-web + oasis have made it very convenient to add new packages.
<hcarty> gildor: Thank you!
<gildor> hcarty: fixed
<hcarty> The URL currently on the oasis-db/odb page is a redirect to that URL. curl grabs the redirect HTML rather than following the redirect.
<hcarty> gildor: I think it changed relatively recently
<gildor> hcarty: what is the right URL ?
<hcarty> gildor: The curl issue is the URL given to retrieve odb.ml
<gildor> hcarty: it seems like a problem in odb DB, you should ask thelema to fix it ?
<hcarty> gildor: 3.12.0 complains about a signature mismatch for the find function. 3.12.1 does not on my system.
<hcarty> gildor: But I want to confirm that before I put a lot of effort into upgrading outside of a test environment
<hcarty> gildor: http://vpaste.net/t00kx -- This seems to work on 3.12.1 but fail on 3.12.0
<gildor> hcarty: what is the problem ?
<hcarty> Hopefully with Batteries available as well
<hcarty> Is anyone here using 3.12.0?
<hcarty> I'm hoping 3.12.1 fixes most or all of them. It's a useful bit of syntax.
<hcarty> 3.12.0 seems to have a lot of trouble with "module type of..."
<hcarty> adrien: You're welcome, and good luck :-)
<hcarty> adrien: Maybe ocamlnet?
<hcarty> adrien: I don't know that there are any byte-order functions in the stdlib
<hcarty> flux: If you are interested in Debian packages for PLplot: http://sourceforge.net/mailarchive/message.php?msg_id=27926177
<hcarty> gildor: If you get a chance to update it, the odb download instructions at http://oasis.ocamlcore.org/dev/odb/ fail
<hcarty> _habnabit: You can play with the *.print functions' optional parameters. Those allow you to choose what strings to use to separate values in a list or set, for example.

2011-08-09

<hcarty> Oh, right, I forgot about that
<hcarty> The functions take a bit of getting used to, but they work very well together and can be easily implemented for your own types.
<hcarty> Parent_structure.print Child1.print Child2.print ... stdout; is another way to use the print functions, without bothering with *printf
<hcarty> Everything should. If it doesn't then it's probably a bug.
<hcarty> Something like: Map.print (Tuple.print (Option.print String.print) StringSet.print) (....
<hcarty> That should still be quite workable by combining the appropriate *.print functions.
<hcarty> See the matching Foo.print functions to get some nice console output
<hcarty> _habnabit: ^^ Would something like that help?
<hcarty> BatPrintf.printf "%a%!" (List.print Int.print) my_int_list;
<hcarty> I don't think that there is, beyond the printing infrastructure.
<hcarty> If you find references to it then a bug report would be helpful to eliminate those
<hcarty> _habnabit: It was dropped sometime before the 1.0 release
<ygrek> hcarty, thelema, http://paste.in.ua/2880/
<hcarty> I haven't used it, but it looks interesting
<hcarty> technomancy: ANSITerminal may do what you want from a terminal
<hcarty> It looks like xlib uses a custom Makefile to build, so it may not work in odb without significant tweaking
<ygrek> hcarty, it is easy to track just looking at the code
<hcarty> technomancy: Cairo may be a reasonable alternative, but it is not ready to go in odb yet due to lablgtk2 not being ready for odb yet
<hcarty> technomancy: I don't know of any package for the OCaml xlib library
<hcarty> ygrek: thelema may be able to track it down if you submit a bug on github
<hcarty> ygrek: Yes, I've seen that before too. I'm not sure where it comes from.
<hcarty> ygrek: The latest version has a flag to let you pass options into the underlying package builds. That may help.'
<ygrek> hcarty, what I miss in odb is --verbose
<hcarty> (that was the next package I turned to odb for...)
<hcarty> Adding basic highlighting and better completion
<hcarty> avsm: utop seems to be lwt-toplevel++
<bitbckt> hcarty: nope )
<hcarty> bitbckt: There isn't much need for anything beyond OCaml + findlib + oasis then :-)
<hcarty> avsm: It builds on oasis-db's server side components
<bitbckt> hcarty: Reasonable idea. I maintain an OS package for ocaml, ocamlfind and oasis and go from there.
<hcarty> avsm: odb is in a usable, if limited, state
<hcarty> bitbckt: I used odb for the first time in order to get oasis up and running
<hcarty> ygrek: If there are no backwards-incompatible changes then it could be pushed over. Ideally someone would so some basic tests first.
<hcarty> And the yearly OCaml meetings have been quite nice from the videos and presentations I've seen online
<hcarty> There have been some positive steps from the core OCaml folks, such as built-in support for ocamlfind in ocamlbuild.
<bitbckt> hcarty: I know.
<hcarty> bitbckt: ^^
<hcarty> technomancy: X. Leroy has made it clear that packaging is a community job in their eyes. Their blessing seems to comes in the form of trying not to interfere :-)
<bitbckt> hcarty: that's right.