01:29 <raboof> when i do 'ocamlopt /usr/lib/ocaml/3.10.2/xml-light/xml-light.cmxa test.ml' i still get 'Unbound module Xml'

01:29 <raboof> how should i 'bind' the module?

01:31 <raboof> oh, i need to include '-I' also

01:42 <raboof> ok, i now got as far as "ocamlopt -I /usr/lib/ocaml/3.10.2/xml-light -I /usr/lib/ocaml/3.10.2/netclient /usr/lib/ocaml/3.10.2/unix.cmxa /usr/lib/ocaml/3.10.2/pcre/pcre.cmxa /usr/lib/ocaml/3.10.2/equeue/equeue.cmxa /usr/lib/ocaml/3.10.2/netsys/netsys.cmxa /usr/lib/ocaml/3.10.2/netstring/netstring.cmxa /usr/lib/ocaml/3.10.2/netclient/netclient.cmxa /usr/lib/ocaml/3.10.2/xml-light/xml-light.cmxa test.ml"

01:43 <raboof> but now '/usr/bin/ld: cannot find -lnetsys' - libnetsys is in /usr/lib/ocaml/3.10.2/netsys/ , how do I add that to the path?

01:46 <raboof> ah, -ccopt...

04:00 <tsuyoshi> you should really use ocamlfind

07:16 <flx_> seconded

07:18 <flx_> with ocamlfind it would be: ocamlfind ocamlc -linkpkg -package xml-light,netclient,pcre test.ml

07:20 <flx_> (you can use "ocamlfind list" to retrieve the list of package names)

07:21 <flx_> while you're at it, stick the '#use "topfind";;'-directive into your ~/.ocamlinit ;)

09:15 <raboof> morning!

09:16 <raboof> still getting started with ocaml, i'm doing the following in a small app: "List.append (parse_entries "http://wiki.linuxaudio.org/feed.php") (parse_items "http://wiki.linuxmusicians.com/feed.php");;"

09:16 <raboof> now parse_items and parse_entries both fetch some webpage and process it

09:16 <raboof> this seems like an ideal thing to do concurrently, right?

09:17 <raboof> what would be the way to do this?

09:27 <raboof> do ocaml have some kind of mapreduce-like 'do_concurrent'-ish helper functions somewhere?

09:30 <Camarade_Tux> that won't happen in parallel if that's what you want

09:31 <Camarade_Tux> (when you mentionned concurrency)

09:44 <flx_> raboof, well, you could make use of streams

09:44 <flx_> raboof, or the lazy lists of Batteries

09:45 <flx_> actually the Enum of Batteries (or ExtLib if you think Batteries is too big of a dependency) will likely do well in this case

10:58 <raboof> flx_: hm, could you give an example?

12:35 <flx_> raboof, I haven't much used them, only perused the documentation

12:35 <flx_> raboof, but Enum is a construct where you can provide a destructive 'next' function, plus it gives a bunch of utility functions

12:36 <flx_> I would expect it to have Enum concatenation, for example

13:14 <raboof> flx_: ok, but that'd still fetch the feeds in series rather than in parallel, right?

13:40 <hcarty> raboof: There are a few options for parallel processing in OCaml. The most commonly used are probably jocaml, ocamlp3l and prelude.ml's parallel List and Array functions.

13:43 <flx_> raboof, it depends on the lower level

13:44 <flx_> raboof, if you can incrementally retrieve and parse the results, everything would be performed in parallel

13:44 <flx_> however it seems likely the interface you use provides the whole contents as a single string

13:44 <flx_> so processing that will likely to take an insignificant time compared to the time (also short ;-)) it took to retrieve it

13:44 <flx_> in this case, when the operations are io-bound, you can use different threads to perform atleast the retrieval part

18:37 <yziquel> hi. concerning writing C wrapper functions: is there any difference between writing CAMLparam2(x,y) and writing CAMLparam0(); CAMLxparam1(x); CAMLxparam1(y);?

18:38 <kaustuv> If you look up the definition of the CAMLparam macros in caml/memory.h, that's how they're implemented, if I remember correctly

18:39 <yziquel> kaustuv: yes and no: CAMLparam2 is implemented as CAMLparam0 and then CAMLxparam2. I want to replace CAMLxparam2 with two CAMLxparam1.

18:39 <yziquel> kaustuv: i'm wondering if this has any weird implications.

18:39 <kaustuv> it's possibly marginally slower, that's all

18:40 <kaustuv> oh, and consumes some extra memory for the list of roots

18:51 <yziquel> humm. not sure this kind of optimisation is worth clobbering the c++ code in my swig module...

18:53 <Camarade_Tux> yziquel: btw, what made you use swig, and how is it going/how do you find swig?

18:57 <yziquel> Camarade_Tux: I'm using Swig because -1- it allows to wrap c++ code rather easily for the end user, specifically when using std::list<uglytype> types -2- i'm wrapping a rather big c++ library -3- the previous swig module thought ocaml is dynamically typed -4- there are already some usefule swig .i interface files.

18:59 <Camarade_Tux> hmmm, I hadn't thought of templates, it's true they are likely very annoying to deal with

18:59 <yziquel> Camarade_Tux: how do i find Swig? well, i believe it's legacy code, but quite useful. it does its job and is flexible to some extent. a perfect solution for c++ would probably be to use GCC XML to parse c++.

19:00 <Camarade_Tux> yziquel: are you writing another swig module for ocaml? that wouldn't use Obj.magic everywhere? (as I've been told)

19:01 <yziquel> Camarade_Tux: the big thing i do not like with Swig is that it is not possible to write a module for a target language without recompiling the whole of swig. a module is written by overriding methods of another class.

19:01 <yziquel> Camarade_Tux: quite ugly.

19:02 <Camarade_Tux> erg, yuck!

19:02 <yziquel> Camarade_Tux: I am writing another Swig module. Won't use Obj.magic everywhere (this statement is rather unfair, though, for the previous module).

19:02 <yziquel> Camarade_Tux: it maps c++ objects to OCaml objects.

19:03 <Camarade_Tux> sounds nice :)

19:07 <yziquel> Camarade_Tux: enjoy: http://paste.lisp.org/display/84180

19:09 <yziquel> it will use Obj.t, though, if it cannot find the types itself (but you can give hints...)

19:10 <yziquel> by the way, how does one tell a class not to generate a type abreviation? is it possible?

19:11 <Camarade_Tux> pretty nice :)

19:11 <yziquel> Camarade_Tux: thanks.

19:11 <yziquel> Camarade_Tux: code is available in the yziquel-ocaml branch of swig on sourceforge.

19:12 <kaustuv> A class or class type will always generate a type abbreviation. You are free to override it, though.

19:13 <Camarade_Tux> yziquel: I might check it out, I'm writing bindings too (actually a binding generator, for gtk*/g* libraries)

19:13 <yziquel> kaustuv: so how can i tell the toplevel (bottom of the pastie) that tok is of type Freeling.tokenizer, and not Freeling.tokenizer_0?

19:13 <yziquel> Camarade_Tux: disclaimer: it's pre-alpha.

19:14 <yziquel> or pre-beta, as you like.

19:16 <kaustuv> Why does it matter that the toplevel prints one or the other side of a type abbreviation? Anyway, as long as you use new tokenizer_0, you might not get what you want. You'll have to write your own function that wraps new tokenizer_0

19:17 <kaustuv> But worrying about this can only lead to madness

19:19 <Camarade_Tux> yziquel: ok :)

19:23 <yziquel> kaustuv: not too worried about this, but well, it would have been nicer.

19:24 <yziquel> kaustuv: i do not understand the "you might not get what you want" and the "you'll have to write your own function". Why?

19:36 <yziquel> kaustuv: ah. ok. a val tokenizer_0 : string -> tokenizer would be better... instead of a class.