rwmjones changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | Grab Ocaml 3.10.1 from http://caml.inria.fr/ocaml/release.html (featuring new camlp4 and more!)
comglz has joined #ocaml
olleolleolle has quit []
coucou747 has joined #ocaml
comglz has quit ["Lost terminal"]
bluestorm_ has joined #ocaml
bluestorm has quit [Read error: 104 (Connection reset by peer)]
jlouis has joined #ocaml
jpcooper has quit [Remote closed the connection]
__suri has quit []
Tetsuo has quit ["Leaving"]
jlouis_ has quit [Read error: 110 (Connection timed out)]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
LordMetroid has quit ["Leaving"]
bluestorm_ has quit ["Konversation terminated!"]
m3ga has joined #ocaml
ofaurax has quit ["Leaving"]
jlouis_ has joined #ocaml
hsuh has joined #ocaml
Jedai has quit [Read error: 110 (Connection timed out)]
Jedai has joined #ocaml
LordMetroid has joined #ocaml
LordMetroid has quit [Read error: 104 (Connection reset by peer)]
lordmetroid_ has joined #ocaml
lordmetroid_ is now known as LordMetroid
jlouis has quit [Connection timed out]
LordMetroid has quit ["Leaving"]
hsuh has quit [""bye folks""]
mwc has joined #ocaml
|Catch22| has quit [Read error: 113 (No route to host)]
<thelema> anyone here interested in github?
menace has joined #ocaml
menace has quit []
m3ga has quit ["disappearing into the sunset"]
AxleLonghorn has joined #ocaml
jlouis has joined #ocaml
jlouis_ has quit [Read error: 110 (Connection timed out)]
AxleLonghorn has left #ocaml []
TheLittlePrince has joined #ocaml
jdev has joined #ocaml
mwc has quit ["Leaving"]
jlouis_ has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
jlouis has joined #ocaml
m3ga has joined #ocaml
m3ga has quit [Client Quit]
jlouis_ has quit [Read error: 110 (Connection timed out)]
jlouis_ has joined #ocaml
pattern_ has joined #ocaml
jlouis__ has joined #ocaml
Snrrrub has quit [Read error: 110 (Connection timed out)]
AxleLonghorn has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
pattern has quit [Read error: 110 (Connection timed out)]
pattern_ is now known as pattern
jlouis_ has quit [Read error: 110 (Connection timed out)]
olleolleolle has joined #ocaml
jlouis has joined #ocaml
olleolleolle has quit []
jlouis__ has quit [Read error: 110 (Connection timed out)]
AxleLonghorn has quit [Read error: 110 (Connection timed out)]
AxleLonghorn has joined #ocaml
jlouis_ has joined #ocaml
AxleLonghorn has left #ocaml []
jlouis has quit [Read error: 110 (Connection timed out)]
bluestorm has joined #ocaml
Linktim has joined #ocaml
ygrek has joined #ocaml
ygrek has quit [Client Quit]
ygrek has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]> hi
marmottine has joined #ocaml
l_a_m has joined #ocaml
bongy has joined #ocaml
goalieca has quit [Remote closed the connection]
ttamttam has joined #ocaml
Tetsuo has joined #ocaml
hkBst has joined #ocaml
uuuppz has joined #ocaml
jlouis has joined #ocaml
jlouis_ has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]> Performance evaluation in progress... again.
<flux> hm, I need to put a pointer to ocaml data inside a c library structure
<flux> how do I make sure the pointer gets updated, or alternatively that the data doesn't get moved, by gc?
<flux> without globally disabling compacting..
<flux> caml_register_global_root guarantee that the data doesn't get moved?
<uuuppz> I'm a bit stuck...
<uuuppz> let FindMissingColumns(table : DataBaseTable, view : MetaView) =
<uuuppz> [for x in table.Fields -> if FindMapping(view.ClassMappings.ToArray() |> Array.to_list,x)<>null then (x) ]
<uuuppz> I'm getting "This expression has type DataBaseField but is here used with type unit" on the (x)
<uuuppz> sorry for the newbie question :)
<flux> is that F#?
<uuuppz> yeh
<flux> well, I don't know exactly the syntax, but it would seem to me that you are missing the "else" branch
* Yoric[DT] assumes you need some "else" branch.
<flux> else branch by default has type unit
<uuuppz> ah ok
<uuuppz> that makes sense
<uuuppz> ok I had an else
<uuuppz> it was returning () which Ipresume is unit...
<uuuppz> how do I return something that adds nothing to the resulting list?
<uuuppz> without adding a null
<flux> I don't know; in ocaml you would perhaps construct lists (either with value or without), and then finally concatenate all the elements; same could be done with the option type
<flux> I guess there is a way to do "filter" with F# list comprehension
<flux> btw, your type declaration for the function seems very non-ocamlish, unless your purpose is really to pass a tuple as the sole argument to the function
<flux> dunno, perhaps that could be a F# convention
<Yoric[DT]> It exists, I just don't remember how to write it.
<Yoric[DT]> There's a + somewhere, iirc.
<uuuppz> I have no idea
<uuuppz> this is my first attempt at f#
<uuuppz> trying to implement some logic in a c# app I've built
<bluestorm> hm
<bluestorm> wouldn't the option type suit your needs ?
<uuuppz> code generation tool
<flux> I'm thinking the documentation or tutorial giving the information on list comprehension would surely cover filtering too
<bluestorm> or even a concatMap with [] or [x], but's that conceptually a bit overkill
<bluestorm> grmph, didn't see flux's messages
<uuuppz> hm yeh
<uuuppz> not really finding the documentation particularly helpful at present. Think thats because I'm missing some basics
<uuuppz> Your explanation has helped tho...
<uuuppz> thanks.
<bluestorm> uuuppz:
<bluestorm> val map_concat : ('a -> 'b list) -> 'a list -> 'b list
<bluestorm> hmm
<bluestorm> it's strange to see that such a young language already has some "Deprecated" fields in the standard library
<flux> a young language has better chances to revamp interfaces that didn't come right the first time?
<bluestorm> you're right
<bluestorm> on the other hand, they started with a quite mature already library (ie. the OCaml one)
<flux> sigh.. this http://www.linux-nantes.org/~fmonnier/OCaml/ocaml-wrapping-c.php makes things look sooo simple, but..
<bluestorm> they may be something about your problem in the DA-OCaml
<bluestorm> hm
<bluestorm> not sure
<flux> thanks, I didn't think of that (so far being googling gc and ffi-related pages)
<bluestorm> « Therefore, any Objective CAML value manipulated from C must be registered with the Objective CAML garbage collector, if they are to survive the allocation of a new block. These values must be treated as extra memory roots by the garbage collector. To this end, several macros are provided for registering extra roots with the garbage collector. »
<bluestorm> seems pertinent
<bluestorm> « Global variables containing values must be registered with the garbage collector using the register_global_root function. »
<uuuppz> bluestorm: thanks I'm reading
<flux> bluestorm, yes, I'm using that
<flux> but it's not actually a global value, but instead something that I've myself allocated with caml_alloc_small which I return to the user..
ita has joined #ocaml
bongy has quit [Read error: 110 (Connection timed out)]
TheLittlePrince has quit [Client Quit]
jlouis_ has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
musically_ut has joined #ocaml
musicallyut has joined #ocaml
musicallyut has quit [Remote closed the connection]
coucou747 has joined #ocaml
musically_ut has quit [Remote closed the connection]
<flux> whee, apparently I got it to work.. only had to gather better understanding on what caml_register_global_root actually does.
dwmw2_gone is now known as dwmw2
<tsuyoshi> flux: what did you do to get it to work?
<flux> I was registering a value that was allocated with ocaml allocation functions.. now I'm registering a pointer that's allocated by me (well, another c library)
<flux> it's simpler this way anyway
ttamttam has left #ocaml []
<tsuyoshi> huh..? what does registration of a c pointer do?
<flux> the c pointer is actually a "value"
LordMetroid has joined #ocaml
filp has joined #ocaml
<uuuppz> I get a syntax error on 'val' for
<uuuppz> val map_concats : ('a -> 'b list) -> 'a list -> 'b list
Snark_ has joined #ocaml
<uuuppz> oh this is only valid in an interface/object?
<Smerdyakov> Yes, and you can see this and more in the grammar in the manual.
<tsuyoshi> yes
filp has quit ["Bye"]
<Yoric[DT]> uuuppz: there was a recent discussion on this subject in on the mailing-list
hsuh has joined #ocaml
<Yoric[DT]> The closest thing you can get is
<Yoric[DT]> let map_concats ... = ... ;; let map_concats : ('a -> 'b list) -> 'a list -> 'b list = map_concats;;
<thelema> actually there's a way to inline the second definition:
<bluestorm> Yoric[DT]: i don't think that's what he wanted
<thelema> let map_concats : ('a -> 'b list) -> 'a list -> 'b list = fun f l -> ...
<Yoric[DT]> thelema: true.
<Yoric[DT]> bluestorm: What do you think he wanted ?
<bluestorm> you could even use
<bluestorm> let map_concats (f : 'a -> 'b list) (li : 'a list) : 'b list = ...
<Yoric[DT]> That's a bit further from what I understood he wanted.
<bluestorm> i think he just wanted to try that function or something like that, given that he is a beginner
<thelema> uuuppz: simple answer: don't declare your function types except in interfaces - ocaml'll figure them out.
munga has joined #ocaml
<thelema> uuuppz: hello? too much answer?
<bluestorm> :D
<bluestorm> i gave him a link to the jason hickey ocaml introduction
<bluestorm> guess his brain is melting now :-'
<thelema> heh
uuuppz has quit [Read error: 113 (No route to host)]
ben has joined #ocaml
* Yoric[DT] is pondering the ugliness of his latest optimization.
<bluestorm> :D
<Yoric[DT]> I mean, using Camlp4 to introduce an Obj.magic might just be considered bad.
<bluestorm> coming from someone who spent his last three nights dreaming of Obj.magic, it's a bit frightening :-'
<bluestorm> aha.
<Yoric[DT]> Hey, you, get out of my head.
hsuh has quit [Remote closed the connection]
<tsuyoshi> yeah.. Obj.magic kind of turns ocaml back into c
<thelema> sometimes it's useful to subvert the type system. Ya just gotta be *really* sure you know what you're doing.
<tsuyoshi> well the thing is, the best thing about ocaml is the type system
<bluestorm> tsuyoshi: still, sometimes you have to
<bluestorm> there was that Coq guy
<tsuyoshi> you can stop worrying about a whole class of stupid bugs with the type checker...
<bluestorm> that explained that when converting Coq code back into OCaml, you sometimes have to break the type system
<tsuyoshi> and then when you use Obj.magic... you're back to the same anxiety you had with c (or assembly)
<bluestorm> given that (if i understood correctly) the Coq type system is more powerful, and thus allows type-safe code that OCaml wouldn't accept
<tsuyoshi> "it compiles... but does it work?"
<tsuyoshi> oh really.. I haven't looked at coq at all
<Smerdyakov> bluestorm, you understood correctly.
<Smerdyakov> In that case, though, Coq extraction is really using OCaml as a high-level assembly language to avoid re-implementing compilation.
<Smerdyakov> You should think of it as not much different from extracting to C code that you can use with the OCaml FFI.
<letrec> Hi! Say I'm writing something like: let func x = let m =... in if ... then 0 else func2 m x. In Haskell it'd work because of laziness but in ocaml m is always evaluated -- so my program doesn't work. What could I use to work around this? Is not using local variables the only way?
<Smerdyakov> Your example is not clear enough. I suggest real code, without ellipses.
<tsuyoshi> you could write: let func x = if ... then O else let m = ... in func2 m x
<bluestorm> letrec: let func x = if ... then 0 else let m = ... in func2 m x ?
<bluestorm> arg.
<tsuyoshi> ha
<letrec> tsuyoshi: Hey. Ok, I didn't know you can write let m =... in the else body. Ocaml is a strange language :) Thanks.
<Smerdyakov> letrec, why is that strange? It would seem stranger to me to introduce an arbitrary restriction to disallow it.
<tsuyoshi> I don't know haskell too well, but I imagine you could do the same thing in haskell
<bluestorm> letrec: (let foo = bar in baz) is an expression
<bluestorm> you can put that virtually everywhere
<tsuyoshi> it just wouldn't make any difference in haskell where you put it
<letrec> Looks to me that lazyness in Haskell makes it unnecessary to think to this kind of details.
ben has quit []
<Smerdyakov> Sure, and totality in Coq makes it even more unnecessary. :-)
<Smerdyakov> Lazyness also makes is necessary to think carefully about memory usage _everywhere_.
<Smerdyakov> And I think you'll find that there is 0 overhead to "having to think about" where to place local definitions in OCaml.
<Smerdyakov> You're just used to doing things a different way.
<Smerdyakov> IMO, it tends to improve readability to make local definitions as local as possible.
<letrec> I'm assuming an optimizing compiler that does a good job. A good compiler should allow the user not to think to this kind of details.
<Smerdyakov> I don't think there is any benefit to not having to think about it, in real programs.
<tsuyoshi> well if the language was lazy, sure
<bluestorm> hm
<letrec> I'm sure there is in the real-world. I'm a compiler engineer (for C/C++) and I can tell you that the last think the embedded programmers want is to have to think to this kind of things.
<bluestorm> what if you have a space leak, and then suddenly want to add strictness annotations everywhere ? :-'
<letrec> May be different for FP but I'm not sure.
<Smerdyakov> letrec, I think you're just not thinking this through. Show me a real example where it matters and we can talk. OCaml also has optional lazyness that you can apply where it seems to add benefit.
<tsuyoshi> the ocaml compiler doesn't do a whole lot of optimization btw.. most of the speed has simply come from very efficient gc and compiling to native code
<Smerdyakov> letrec, and, at the same time I'm arguing with you about this, I agree with you even more than you do, in that I think that languages like Coq are the right choice. They make Haskell look horribly impure and hard to reason about.
<letrec> My $0.02: engineers in industry like C because it allows messy code. Most people are .. lazy. So Haskell lazyness is a good fit. Having to think to details like the one I ran into require (limited) brainpower. So I don't think they'll like it.
<letrec> I don't know Coq too much, so I'll have a look. Sounds interesting.
<thelema> letrec: haskell lazyness conflicts with my need to control what's going on - in an eager language I can model what'll happen much easier
<Smerdyakov> letrec, I don't think anyone ever has to think about this in real life.
<Smerdyakov> letrec, you are mistakenly taking the translation of Haskell programs as a proxy for OCaml programming from scratch.
hsuh has joined #ocaml
patraic has joined #ocaml
<letrec> thelema: it might be because you're as much a mathematician as a programmer? So it makes sense. But a lot of developers are just programmer and don't want to think formally about their programs.
<Smerdyakov> letrec, please give a concrete example. You're making basic assertions from experience that don't mesh at all with what seems to be the consensus here.
<thelema> letrec: no, it's the non-mathematician in me that likes eagerness, that likes being able to sequence my commands to the computer. I have to dig deep into my mathematical side to make declarative systems work well.
<letrec> Smerdyakov: I'm not willing to give any formal proof of my assertions :) What I'm saying is my understanding, my $0.02 after 10 years in industry. It may well conflict with the mainstream paradigm -- but I have no idea why. Anyway, not very important :)
<Smerdyakov> letrec, who said anything about formal proofs?
<Smerdyakov> letrec, I'm asking for a single example of code demonstrating why it's bad to have to think about placement of local definitions.
jlouis has joined #ocaml
<bluestorm> Smerdyakov: there may be some examples where you have definitions, then a condition, and it temporarily happens that some of the definitions are not needed in one of the condition branch
<Smerdyakov> bluestorm, I need something concrete.
<Smerdyakov> bluestorm, code that compiles.
<bluestorm> :]
<thelema> let also does code sequencing - ala let () = ...
<thelema> Since ocaml allows side-effects, the compiler probably can't look at the resulting value's usage and decide to only execute the code in one branch.
<tsuyoshi> well.. the compiler does check functions to see if they're purely functional
<bluestorm> does it ?
<tsuyoshi> yep
<tsuyoshi> but I don't think it ever just drops code if the result isn't used
<flux> this turned out to be a very critical piece of information (while doing c-bindings that forward ocaml exceptions): http://caml.inria.fr/pub/ml-archives/caml-list/2006/05/097f63cfb39a80418f95c70c3c520aa8.en.html
<bluestorm> flux: there might be a FFI page on ocaml-tutorial.org
<bluestorm> it may be a good idea to add your findings there
jlouis_ has quit [Read error: 110 (Connection timed out)]
<flux> bluestorm, added
AxleLonghorn has joined #ocaml
ben___ has joined #ocaml
Snark_ is now known as Snark
hsuh` has joined #ocaml
hsuh` has quit [Remote closed the connection]
hsuh has quit [Remote closed the connection]
hsuh has joined #ocaml
uuuppz has joined #ocaml
olleolleolle has joined #ocaml
ita has quit [Remote closed the connection]
pango__ has joined #ocaml
pango__ is now known as pango
pango_ has quit [Remote closed the connection]
Morphous has joined #ocaml
ciscbrain has joined #ocaml
munga has quit [Read error: 110 (Connection timed out)]
ben___ has quit []
<letrec> 1::[0];;
<letrec> Why is [0]::1 not working? Is there another operator?
<letrec> Thanks.
<coucou747> letrec> :: concat 'a and 'a list
<coucou747> not 'a list and 'a
<coucou747> it's like a linked list, you have the first element, and a pointer to the next
<letrec> Ok, but if I want to add an element at the end of the list, is there an easy way?
<letrec> Or maybe that is not efficient (that's O(n) I think).
<bluestorm> there isn't
<bluestorm> because it's O(n)
<bluestorm> actually there is a syntaxically easy way
<bluestorm> list @ [elem]
<bluestorm> but you shouldn't use it
<bluestorm> because it defeat the purpose of ocaml simple lists
<bluestorm> you may use other data structures (queues ?), or do differently
<letrec> Ok, but to write tail recursive function it would sometimes be handy
<letrec> But thanks, I see why it is not there -- it is not efficient.
<bluestorm> after a tail recursion you can use "rev" wich is O(n) but reverse all the elements at once
<letrec> Ok.
Amorphous has quit [Connection timed out]
olleolleolle has left #ocaml []
AxleLonghorn has left #ocaml []
notyouravgjoel has joined #ocaml
<notyouravgjoel> whenever i open this code in ocaml1, it goes very, very long
<notyouravgjoel> i'm trying to solve euler problem 3; any help? the goal is to build a very basic sieve of eratosthenes, but using big_int seems to slow things to a halt
<thelema> do you have memory for 600 billion bigints in a linked list?
<thelema> n/m, thought you were iterating up to top and not oldtop.
<thelema> why do you reverse the list each time?
<pango> if it's too slow, I'll give you the result: Exception: Failure "hd".
<notyouravgjoel> oh, shoot; I forgot to take that rev out
<pango> line 19, because I think makerange always return an empty list
jderque has joined #ocaml
<notyouravgjoel> yeah, I just got that exception
<notyouravgjoel> erm, suggestion why it always returns an empty list?
<thelema> line 14
<notyouravgjoel> ugh; thanks.
<notyouravgjoel> I guess i want l, not []. Its taking me a little bit of time to wrap my mind around all this recursion
<thelema> notyouravgjoel: yup, recursion does take a while to understand. And like anything, you just need to practice it.
Snrrrub has joined #ocaml
Snrrrub__ has joined #ocaml
<pango> there's several useless parenthesis, some weird expression ([s;] ? I had to check it does the same thing as [s]), some lack of idiomaticness (ocamlers tend to avoid List.hd and prefer pattern matching), but other than that it should work
<notyouravgjoel> so, its working now, but when i do try to make 600 billion bigints, it definitely dies. I suppose I need to rethink this method of solving euler 3
* pango wonders why xchat2 suggested idiomaticness instead of idiomaticity
<thelema> notyouravgjoel: back to my first question, do you think you have enough ram for 600 billion bigints?
<bluestorm> you don't need any list for that
<thelema> you're trying to find the largest factor of x?
<thelema> my recommendation: start dividing.
linktim_ has joined #ocaml
<bluestorm> btw, in that range you could use float or Int64, instead of big_int
<notyouravgjoel> eh, I was trying to find the primes first; I suppose I only need to go up to the square root of that number
<bluestorm> would probably be faster
<bluestorm> notyouravgjoel: i don't think you need to find the primes
<thelema> notyouravgjoel: sqrt 600Billion would definitely cut down your work...
<thelema> but why worry about only primes. Once you start dividing out small prime factors, only larger prime factors will remain
<notyouravgjoel> ah, that makes sense
<notyouravgjoel> I believe
<thelema> any larger composite factors will not divide because their factors have already been removed from what you're testing.
smimou has quit ["bli"]
<thelema> i.e. once you find x mod 2 = 0 then start testing x/2 for factors
|Catch22| has joined #ocaml
Snrrrub has quit [Read error: 110 (Connection timed out)]
Linktim has quit [Read error: 110 (Connection timed out)]
Waleee has joined #ocaml
__suri has joined #ocaml
smimou has joined #ocaml
TheLittlePrince has joined #ocaml
thermoplyae has joined #ocaml
Waleee has quit []
Waleee has joined #ocaml
coucou747 has quit [Remote closed the connection]
magnus_ has left #ocaml []
coucou747 has joined #ocaml
patraic has quit ["Leaving"]
<thelema> anyone know any shortcuts to finding the period (or repetitive part) of a repeating dataset?
<thelema> i.e. input: [4; 2; 4; 2; 4; 6; 2; 6; 4; 2; 4; 2; 4; 6; 2; 6; 4; 2; 4; 2; 4; 6; 2; 6] output: [4; 2; 4; 2; 4; 6; 2; 6]
<pango> what about having two crawlers, one stepping forward one element at a time, the other two elements at a time, and check if the remaining elements match?
goalieca has joined #ocaml
<thelema> how could the remaining elements ever match? the list isn't infinite.
<thelema> (although I can generate it at an arbitrary size
<pango> if they match up to shortest list length, I think it should work...
<thelema> on the example data: step 1: [4] != [2]
<thelema> step 2: [2;4] = [2;4] ??
<pango> mmh thinking of it, the first crawler may not have to advance at all, you're right
<thelema> so what's the first test? [4] = [4]?
<thelema> no, [4] != [2]
<thelema> [4;2] = [4;2]
* thelema remembers hearing of an easier way to find the period, and then once you have the period, finding the actual repeated data isn't hard
smimou has quit ["bli"]
Snark has quit ["Ex-Chat"]
smimou has joined #ocaml
hcarty has joined #ocaml
delamarche has joined #ocaml
delamarche has quit []
delamarche has joined #ocaml
linktim_ has quit [Remote closed the connection]
grunger has joined #ocaml
delamarche has quit []
delamarche has joined #ocaml
ofaurax has joined #ocaml
<grunger> ocaml is fascinating !
grunger has left #ocaml []
love-pingoo has joined #ocaml
ygrek has quit [Remote closed the connection]
<pango> thelema: I'm about to suggest http://pastebin.be/9515, but even under the hypothesis that the repetition exists, it's not totally trivial to prove that the algorithm always does the right thing :/
pango is now known as pangoafk
<thelema> the way that the list is generated, it's guaranteed to repeat (although the period of repetition isn't easy to know)
dwmw2 is now known as dwmw2_gone
<ciscbrain> hi
<ciscbrain> can you please point me to how this can be expressed in a better way?
<thelema> it's not bad as is.
<thelema> I almost thought of a fold, but you're using xs.(i) and xs.(i+1)
<ciscbrain> how bad would it it be to use lists instead of arrays?
<ciscbrain> I've thought of a zip on xs and tl xs or something
<thelema> you could do a fold_left2 on xs and tl xs
jlouis_ has joined #ocaml
jderque has quit ["leaving"]
<ciscbrain> hmm.. it says it raises Invalid_Argument if they have different lengths
<thelema> yeah, you'd have to cheat that.
<Yoric[DT]> Well, too much work for a Sunday.
<Yoric[DT]> Goodnight everyone.
Yoric[DT] has quit ["Ex-Chat"]
<ciscbrain> thanks
thermoplyae has quit ["daddy's in space"]
hsuh` has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
ofaurax has quit ["dodo"]
delamarche has quit []
hsuh has quit ["realized i had a screen session detached"]
brooksbp has joined #ocaml
hsuh` is now known as hsuh
hsuh has quit [Remote closed the connection]
hsuh has joined #ocaml
delamarche has joined #ocaml
brooksbp has quit []
brooksbp has joined #ocaml
marmottine has quit ["Quitte"]
pangoafk is now known as pango
delamarche_ has joined #ocaml
delamarche_ has quit [Client Quit]
ciscbrain has quit []
delamarche has quit [Read error: 110 (Connection timed out)]
hsuh has quit ["rcirc on GNU Emacs 23.0.60.2"]
love-pingoo has quit ["Connection reset by pear"]
brooksbp has quit []
<coucou747> 42 !
AxleLonghorn has joined #ocaml
hkBst has quit ["Konversation terminated!"]
Snrrrub__ is now known as Snrrrub
jlouis has joined #ocaml
thermoplyae has joined #ocaml
bluestorm has quit ["Konversation terminated!"]
jlouis_ has quit [Read error: 110 (Connection timed out)]
TheLittlePrince has quit [Client Quit]
middayc has joined #ocaml
Tetsuo has quit ["Leaving"]
darinm has joined #ocaml