10:34:46 <Qrntz> wmeyer``, this sounds a bit tedious, noting that ocamlbuild has rules to build .cmxs files already, but thanks on your input — I'll try that
10:35:47 <adrien> Qrntz: "ocamlbuild foo1.cmxs foo2.cmxs foo3.cmxs" doesn't work?
10:43:06 <Qrntz> oops, forgive my ignorance — it actually seems to build .cmxs libs
10:43:29 <Qrntz> adrien, but there are still some problems
10:45:06 <Qrntz> 1) how do I exactly tell ocamlbuild that all .ml files in a certain directory need to be compiled to .cmxs
10:46:11 <Qrntz> 2) is there any way to tell ocamlbuild to symlink them to the proper place? .cmxs plugins end up being compiled to _build/plugins/, but I need them to be in plugins/
11:17:57 <adrien> Qrntz: find $DIR -maxdepth 1 -type f -name '*.ml' | sed -e 's/\.ml$/.cmxs/g' | xargs ocamlbuild
11:18:43 <adrien> for the output dir, I don't know; I think there's a way but I don't know it; but do you actually need that that way? it's a bit dirty
11:19:04 <adrien> I mean, _build keeps things clean and you're probably going to end up with many .cmxs files
11:19:19 <adrien> if you want them to be at runtime for something else, having an intermediate "installation" step might not be bad
11:28:16 <Qrntz> adrien, I need the main executable to dynlink them from an accessible location and that's pretty much it
11:28:33 <Qrntz> not sure if _build/plugins is a good choice
11:29:42 <adrien> you want to build some parts, run something, continue the build process; I'm not aware of an approach that is both simple and clean, no matter the build system ;-)
11:30:16 <Qrntz> thanks for the command — I think I'll write a simple wrapper makefile to just dispatch ocamlbuild commands
11:30:39 <adrien> yup :-)
11:30:39 <Qrntz> well
11:30:50 <Qrntz> thanks on your input anyway
11:30:57 <Qrntz> I'm getting closer to what I have in mind
11:31:18 <adrien> (if you need to strip the path from the files given by "find", there's %P or %p or %f for -printf in find (it would be the _ending_ argument to find)
11:31:45 <Qrntz> I know, I used find for quite a while
13:53:36 <wmeyer``> Qrntz: You can prepare a file with the list called all.itarget and then call ocamlbuild all.otarget
13:53:52 <wmeyer``> Qrntz: That will symlink it
16:05:30 <hongboz> hi, does anyone have any experience to manage serveral versions of ocaml to work together? I have several versions(3.11,3.12.1,svn), I need to test compatibility for different versions. What's the right way to do this?
16:29:36 <mfp> hongboz: this might help https://github.com/hcarty/ocamlbrew (haven't used it though)
16:36:08 <chambart> hongboz: you can install multiple versions by installing multiple godi instances
16:40:06 <hongboz> chambart: I did. and configure the path everywhere. it works anyway :-)
16:46:28 <hongboz> btw: topdirs.cmi was no longer placed in stdlib. so you need to add -I +compiler-libs when you build ocamlfind for dev
18:43:01 <kolera> stupid question: how to I access a particular element of a tuple without using pattern matching?
18:43:33 <thelema> kolera: batteries has Tuple2-Tuple5 with first/second/etc. functions
18:44:18 <thelema> but they're just `let third (a,b,c,d,e) = c`, etc.
18:45:11 <kolera> how about retrieving a value?
18:45:29 <kolera> something like an `nth` function?
18:45:30 <thelema> kolera: ?
18:45:38 <thelema> oh. what would the type be?
18:45:52 <kolera> int * string
18:46:22 <thelema> what would the return type of nth be?
18:46:50 <thelema> the point is that there's no reasonable type for a tuple.nth function
18:47:04 <thelema> at least not one that worked on heterogenous tuples
18:47:17 <thelema> and homogenous tuples are called arrays.
18:47:31 <kolera> fair point
18:48:22 <kolera> dynamic type thinking :\
18:51:16 <adrien> there are built "fst" and "snd" however: ('a * 'b) -> 'a (or 'b)
18:54:02 <kolera> adrien: thanks, that is what i was looking for
18:54:26 <kolera> however, thelema has rightly pointed out my poor reasoning
19:07:15 <SuperNoeMan> hey, I'm on mac os x
19:07:19 <SuperNoeMan> and I'm trying to learn ocaml
19:07:22 <SuperNoeMan> I"m getting this
19:07:28 <SuperNoeMan> error Reference to undefined global Graphics
19:07:52 <thelema> you have to link with graphics.cm[x]a
19:08:05 <SuperNoeMan> after: open Graphics;; open_graph..
19:08:12 <SuperNoeMan> why can't the interpreter do it?
19:08:21 <thelema> SuperNoeMan: ah, in the toplevel. same thing
19:08:27 <thelema> SuperNoeMan: do you have findlib
19:08:29 <SuperNoeMan> I'm using the interactive... how do I make the inter
19:08:56 <SuperNoeMan> dude, I'm totally new: I don't know what you mean by findlib, and I don't understand the part about graphics.cm[x]a where you have the [x] part
19:09:12 <SuperNoeMan> is findlib a utility?
19:09:51 <SuperNoeMan> ah. did port search findlib and some stuff came up, I'm guessing you were going to use findlib to help me
19:09:56 <thelema> try running the "interactive" as "ocaml graphics.cma"
19:10:16 <thelema> I was going to recommend a way to use findlib to load the graphics code into the toplevel
19:10:28 <thelema> but if all you want is graphics...
19:10:54 <Sablier> .cma is bytecode lib and .cmxa native lib
19:10:55 <SuperNoeMan> yeah, I'm just learning, but whatever you have that's extra is good for me,
19:11:13 <SuperNoeMan> so, I'm thinking that findlib will dynamically load the graphics, instead of having to restart the top level
19:11:19 <Sablier> that why [x], in case of using ocamlc or ocamlopt, for ex
19:11:21 <thelema> Instead of that, if you have findlib installed, you can do `#use "topfind";;`
19:11:52 <thelema> and then `#require "graphics";;` to load the graphics package
19:11:59 <SuperNoeMan> ah ok
19:12:02 <SuperNoeMan> cool man
19:12:05 <thelema> ocaml has no real auto-loading
19:12:08 <SuperNoeMan> so this is my first functional language
19:12:39 <thelema> SuperNoeMan: no worries, you're just bumping up against some of ocaml's rough parts
19:12:53 <adrien> SML has support for it iirc, so your reasoning wasn't that poor ;-)
19:12:57 <Anarchos> thelema what is the subject ?
19:13:02 <adrien> kolera: ^
19:13:11 <adrien> (sorry, packet loss skyrocketed)
19:13:14 <thelema> Anarchos: subject for what?
19:13:26 <Anarchos> thelema what is the ocaml's rough parts ?
19:13:31 <thelema> Anarchos: oh, irc. SuperNoeMan is having trouble using graphics in the toplevel
19:14:11 <thelema> "open Foo" doesn't load any libraries or indicate that anything needs to be linked in, it only adds the symbols from module Foo to the current namespace
19:14:40 <thelema> It would be very nice if ocaml had something similar that also indicated linking.
19:15:12 <SuperNoeMan> i don't understand why it's authors wouldn't have put that in there by default
19:15:38 <Anarchos> thelema oh ok. I once was able to launch my OS windows from the toplevel :)
19:16:23 <thelema> SuperNoeMan: it's obvious now in the 21st century, but ocaml goes back to the early 90's, when C's linking model was the right way to do things
19:16:44 <SuperNoeMan> ah yeah.
19:16:48 <SuperNoeMan> link everything statically
19:17:07 <SuperNoeMan> I think it's cool how ocaml can be run interactively, or completely compiled
19:17:12 <SuperNoeMan> and is also in a vm
19:17:49 <SuperNoeMan> that's cool. if only some of the more popular lanaguages had that. like maybe if java was also functional, didn't require every damn thing to be a freaking object, and was also able to be compiled...
19:18:00 <Anarchos> thelema i already read that Knuth advocates for static library since dynamic involves only subtle and tricky algorithm, unneeded nowadays since memory has become cheap
19:18:25 <thelema> java's lack of compilation isn't a real weakness for it, except in very few cases
19:19:04 <thelema> Anarchos: sure, but ocaml still needs extra information outside your program for static linking.
19:20:15 <Anarchos> thelema can you give some details ? I don't get the point
19:20:45 <adrien> Anarchos: NO
19:21:02 <thelema> Anarchos: for instance, if you want to use the graphics library, nothing you write in your source code will prevent you from having to list graphics.cma (or .cmxa) on the command line to link it in.
19:21:06 <adrien> and next, someone is going to mention the sta.li nonsense
19:21:12 <adrien> http://sta.li/
19:21:28 <adrien> "static linux is based on a hand selected collection of the best tools for each task and each tool being statically linked (including some X clients such as st, surf, dwm, dmenu),"
19:21:35 <adrien> they have a wonderful presentation
19:22:01 <everyonemines> links to a paper
19:22:03 <adrien> which is complete crap: last time, I didn't have enough fingers to count how many of their major advantages were in fact completely wrong
19:22:04 <everyonemines> "Address-space randomization is a technique used to fortify systems against buer overow attacks."
19:22:17 <everyonemines> or, you could not have buffer overflow vulnerabilities
19:22:19 <Anarchos> adrien why your big NO ?
19:22:45 <adrien> first use of dynamic libraries? replacement libraries! I've rebuild my mesa yesterday to match the kernel I'm using, and I haven't had to rebuild all the opengl games I'm using
19:22:53 <Qrntz> static linking is the way to go for moderately small executables
19:22:55 <Qrntz> see busybox
19:23:06 <adrien> and for security: imagine having to relink 1000 programs whenever there is a zlib security update
19:23:43 <adrien> and then you have libc functions which have an even bigger impact in the case of a security issue
19:23:45 <Anarchos> adrien i see, but knuth really wrote that !
19:24:27 <adrien> everyonemines: also, ASLR has been proven to not be that effective
19:24:39 <adrien> Knuth also proves code but doesn't guarantee it runs properly
19:25:24 <Anarchos> adrien yes he likes funny joke :)
19:26:02 <adrien> Knuth is a computer scientist, or whatever you want, I've never heard of him administrate any system
19:26:27 <adrien> also, he hasn't seen Qt, KDE libs, webkit-whatever and others
19:26:43 <adrien> (webkit is roughly 20MB as a lib, plus its deps)
19:27:11 <thelema> my issue isn't with static vs. dynamic linking, but with ocaml requiring metadata (linking commands outside source code) for compilation
19:27:14 <Anarchos> adrien don't panic i see your point : dynamic involves maintaining easier :)
19:27:23 <adrien> -rwxr-xr-x 1 root root 47M Nov 27 15:27 /usr/lib64/libwireshark.so.1.1.0*
19:27:24 <adrien> -rwxr-xr-x 1 root root 47M Mar 24 02:54 /usr/lib64/libgcj.so.13.0.0*
19:27:24 <adrien> -rwxr-xr-x 1 root root 110M Jul 5 2011 /usr/lib64/libgtk-x11-2.0.so.0.2400.4*
19:27:35 <adrien> I think that last file is the result of a debug rebuild :-)
19:30:12 <everyonemines> thelema: What system would you want? What's a language that does things right?
19:30:28 <everyonemines> I just copy/paste compilation command from a comment in source.
19:31:21 <thelema> everyonemines: only works for really small projects.
19:32:10 <everyonemines> ocaml doesn't really have a lot of large projects
19:32:20 <thelema> afaik, all the dynamic languages get this right, although I guess they technically don't have linking...
19:32:40 <everyonemines> that doesn't really count does it
19:33:20 <thelema> ocaml has plenty of projects big enough to use multiple source files, in which the "copy/paste compilation command" method doesn't work
19:33:29 <everyonemines> does too
19:33:47 <everyonemines> you can use it with multiple source files
19:33:51 <everyonemines> i have
19:34:29 <thelema> I wouldn't want to do so for batteries
19:34:54 <everyonemines> it's a multi line command with a cd
19:35:09 <thelema> and I wouldn't want to maintain it.
19:35:38 <everyonemines> well, i haven't done anything as big as batteries
19:35:51 <thelema> Ada has a pretty good system for building large projects
19:35:53 <thelema> gnatmake
19:36:42 <everyonemines> module namespacing is really awkward for something like batteries
19:37:10 <everyonemines> you end up with extra files just to hold module names
19:37:29 <thelema> do you mean the batteries.ml file?
19:37:39 <everyonemines> partly
19:38:10 <thelema> what else?
19:38:18 <everyonemines> ...i forget
19:38:41 <everyonemines> i thought there were also submodule files like batteries.ml
19:39:23 <everyonemines> but also, if you want to organize stuff into folders
19:39:25 <thelema> there's something like batteries.ml for extlib compatibility... but it's for people that don't use batteries.ml
19:39:26 <everyonemines> ...you can't
19:39:35 <adrien> hahaha, I was checking sta.li's "faq" page:
19:39:38 <adrien> "Good libraries implement each library function in separate object (.o) files, this enables the linker (ld) to only extract and link those object files from an archive (.a) that export the symbols that are actually used by a program."
19:39:42 <adrien> sure :P
19:39:48 <thelema> yes, the flat namespace of .cmx modules is a bit poor.
19:40:16 <thelema> adrien: feh. too much separation
19:40:29 <everyonemines> adrien: Good thing there's zero overhead for opening and reading small files.
19:50:01 <adrien> I hate most of "suckless" (which sta.li is "part" of) =)
19:55:30 <Anarchos> adrien you make very firm statements :)
19:56:08 <adrien> the basis of suckless is "code sucks, so if we make less of it, the end result will suck less"
19:56:13 <adrien> there's less to suck, so it'll suck less
19:56:28 <adrien> what if the code was made better instead?
19:56:40 <adrien> and they're using C
19:58:34 <Anarchos> adrien and what is wrong with C (just to know, don't fight please :) )
20:02:32 <adrien> nothing is wrong with C, I actually like it
20:03:49 <flux> so, what is the best way of doing GUIs in OCaml at the moment?
20:04:14 <flux> if I need to have a custom widget there in as well? is it still lablgtk, or perhaps some of the reactive libs build on top of it?
20:07:01 <adrien> but don't start something stating that code sucks and is unstable, unreadable, hard to understand, has security issues and other problems when you're doing C (as I've said earlier: my connection is losing packets like hell)
20:08:58 <adrien> flux: detail what you want to do more (much more =) )
20:10:19 <flux> I want to have some buttons and a widget I draw myself, nothing overly complicated. the keyphrase here would be 'fast and easy to get to work' :)
20:12:21 <adrien> graphics? :P
20:12:32 <flux> sure, that would be the widget part
20:12:35 <flux> 2d graphics basically
20:12:45 <flux> vector-graphics
20:12:56 <adrien> but currently, lablgtk or labltk, yes
20:12:56 <adrien> (ltk can have some nice themes now)
20:12:57 <adrien> and I meant Graphics ;-)
20:12:57 <adrien> RAH
20:13:10 <flux> I suppose I'll go with lablgtk then
20:13:30 <adrien> soon, I hope to see nice stuff around the EFLs, but then, that won't be vector :-)
20:13:40 <flux> EFL?
20:13:41 <adrien> hmmm, sfml, maybe; I can't remember if it has stuff for GUIs
20:14:02 <flux> I suppose I could always use opengl for the vector graphics
20:15:17 <adrien> flux: libs for enlightenment.org
21:12:12 <thelema> File "src/batStack.mli", line 34, characters 16-17:
21:12:12 <thelema> Error: Syntax error
21:12:22 <thelema> L34: exception Empty = Stack.Empty
21:12:56 <thelema> The language reference says: http://caml.inria.fr/pub/docs/manual-ocaml/manual016.html#toc55
21:13:04 <thelema> The form exception constr-name = constr gives an alternate name to an existing exception.
21:14:16 <thelema> blah, in module types: " exception constr-decl " is all that's allowed
21:14:31 <thelema> meaning I can't have in my signature an exception from another module
21:16:36 <thelema> meaning I can't have in my signature an exception from another module
21:16:42 <thelema> blah.
21:16:46 <adrien> raise Duplicate
21:16:48 <adrien> :-)
21:17:38 <thelema> in order for BatStack to implement Stack's interface, it must have an exception called Empty, but this exception will not be raised; Stack.Empty will be raised instead
21:22:13 <Anarchos> thelema is there a BatCave module inside the BatStack ?
21:30:24 <thelema> Anarchos: no
21:34:33 <Anarchos> thelema no matter, it was a joke, Robin :)
22:48:41 * ninegrid slaps his knee