enthymeme has quit [Quit: rcirc on GNU Emacs 23.1.1]
thrasibule_ has quit [Read error: Connection reset by peer]
struktured has quit [Ping timeout: 260 seconds]
drk-sd has quit [Quit: dodo]
struktured has joined #ocaml
brooksbp_ has joined #ocaml
brooksbp has quit [Read error: Operation timed out]
boscop_ has joined #ocaml
philtor has joined #ocaml
philtor has quit [Ping timeout: 248 seconds]
brooksbp has joined #ocaml
drewby has joined #ocaml
brooksbp_ has quit [Ping timeout: 248 seconds]
<drewby>
If I'm running files using "ocaml filename" how can I get a stack trace for exceptions?
Shoggoth has joined #ocaml
<derdon>
drewby: ocamldebug?
<drewby>
does it take .ml files?
<derdon>
dunno, didn't use it yet
derdon has quit [Ping timeout: 246 seconds]
thrasibule has joined #ocaml
yakischloba has quit [Quit: Leaving.]
drewby has left #ocaml []
boscop_ has quit [Ping timeout: 260 seconds]
spicey has joined #ocaml
<spicey>
the compiler is barking at me for having two similarly named elements in different, yet fully qualified, types, like this: http://ocaml.pastebin.com/UJFCPNHK ; what am i missing here?
enthymeme has joined #ocaml
brooksbp_ has joined #ocaml
brooksbp has quit [Ping timeout: 245 seconds]
seafood has quit [Quit: seafood]
jeddhaberstro has quit [Quit: jeddhaberstro]
ulfdoz has joined #ocaml
<orbitz>
spicey: record elements must be uniquely named
<spicey>
Are you sure? it is failing on assignment, not on the definition, so that makes me think that both "globals" and "resources" are created successfully; also, i can freely open any library and not care if their defined type record elements would or would not clash with my types
<spicey>
...or not. it seems that they clash
<orbitz>
spicey: you can rebind naems all you want in ocaml
<orbitz>
it's faiin becaues it thinks foo is part of the resoruces record
<orbitz>
since you rebound the name
<orbitz>
spicey: given how you create a record tehr ei sno way to infer the actual type since all you provide are attribute names
<orbitz>
(if you were allowed to have overlapping attribute names)
seafood has joined #ocaml
<spicey>
yes, now that i think about it, possibility of fun x -> x.foo would get incredibly messy
<spicey>
if .foo could resolve to different types
<orbitz>
spicey: think more about what { foo = [] } means
<orbitz>
spicey: is that a resources? in which case it's a compile rerorr, o ris it a globals in which case it' snot? what if you have another record type with foo as a list? is it tha ttype?
<spicey>
it could be a polymorphic type which would get accepted by any function that needs x.foo :)
thrasibule has quit [Ping timeout: 240 seconds]
yakischloba has joined #ocaml
joewilliams is now known as joewilliams_away
mjonsson has quit [Ping timeout: 246 seconds]
Yoric has joined #ocaml
ulfdoz has quit [Ping timeout: 246 seconds]
kaustuv has joined #ocaml
<kaustuv>
If I want to use a recent OpenGL and SDL, is GLCaml + OCamlSDL the canonical combination? Or is one of the other bindings from OpenGL and/or SDL better?
<Camarade_Tux>
(I usually do a typo or forget *whole* chunk of names, like 75%)
Nepomuk has joined #ocaml
<Camarade_Tux>
before checking your bug report as thought it was certainly not being accepted, and thought maybe a front-end could do it, that's what clang is after all
<Camarade_Tux>
gcc is maybe more modular however
<orbitz>
Does JH still work on HLVM or just talk about it?
_zack has quit [Quit: Leaving.]
Shoggoth has quit [Quit: Ex-Chat]
<Camarade_Tux>
I think he did some work on it not that long ago but dunno if he changed anything in the last two months (haven't read much from him either during that timeframe)
_zack has joined #ocaml
<orbitz>
Do you think HLVM could be a promonent Ocaml implemetnation if he keeps it up?
<Camarade_Tux>
who tried hlvm btw? it's been on my todo list for ages but never tried it
<orbitz>
i have not
<Camarade_Tux>
(and I don't think it would be impossible to have hlvm coexist with ocaml: it currently has less features but sometimes you don't use these in your code and may well use hlvm instead)
<Camarade_Tux>
thelema: I went through your patch quite quickly and it looks pretty nice, with simple changes
<Camarade_Tux>
hmmm, know nothing about camlp* but couldn't this be implemented with it?
<orbitz>
thelema: kind of like F#?
<thelema>
Camarade_Tux: thank you. It's not complete as is - there were more bugs that (I forget who) found afterwards. The full patch exists somewhere in the ocaml-community tree
<thelema>
orbitz: more divergent than F#
<thelema>
Camarade_Tux: it might be possible. you'd end up re-implementing lots of the compiler to do it.
<flux>
wish there was a camlp4-like thingy with more possibility to converse with the compiler :)
<flux>
but I guess if one popped up, it'd be a research project..
th5 has joined #ocaml
<Camarade_Tux>
thelema: as I said, I don't know camlp4 but I thought that maybe you could access the already-bound identifiers
<Camarade_Tux>
maybe a list of identifiers on the disk
<alpounet>
Camarade_Tux, i tried hlvm
<thelema>
Camarade_Tux: actually, I take that back - I don't think you could (reasonably) do it in camlp4, as it'd require looking into any [open]ed namespaces, which would go outside the current file.
<Camarade_Tux>
alpounet: can I take my ocaml code and just use it with hlvm? which kinds of changes would be needed? (besides when using a feature hlvm doesn't support)
<Camarade_Tux>
thelema: yeah, it occured to me that'd be the actual problem (although current namespace would be a start), that's why I thought about using a file disk with all identifiers
<alpounet>
Camarade_Tux, I worked on the main "sample" given with HLVM, which is a toploop for a tiny subset of OCaml
<alpounet>
without type inference
<alpounet>
and last time I checked there was no compiler
<alpounet>
so no OCaml code won't compile that easily
<alpounet>
and since jdh is quite controversed nobody has been helping out on hlvm except me at some point last year
<Camarade_Tux>
I see
derdon has quit [Ping timeout: 264 seconds]
<alpounet>
and supporting a larger subset of OCaml is quite big a work
<alpounet>
List.fold_left comp (fun x -> x+1) [ fun x -> x*2 ; fun x -> x+10 ] 10
<alpounet>
List.fold_left comp (fun x -> x+1) [ fun x -> x*2 ; fun x -> x+10 ] 10;;
<xavierbot>
Characters 47-50:
<xavierbot>
List.fold_left comp (fun x -> x+1) [ fun x -> x*2 ; fun x -> x+10 ] 10;;
<xavierbot>
^^^
<xavierbot>
Warning S: this expression should have type unit.
<xavierbot>
Characters 57-66:
<xavierbot>
List.fold_left comp (fun x -> x+1) [ fun x -> x*2 ; fun x -> x+10 ] 10;;
<xavierbot>
^^^^^^^^^
<xavierbot>
Error: This expression should not be a function, the expected type is
<xavierbot>
int
<f[x]>
let rec x = `A x;;
<xavierbot>
val x : [> `A of 'a ] as 'a =
<xavierbot>
`A
<xavierbot>
(`A
<xavierbot>
(`A
<xavierbot>
(`A
<xavierbot>
(`A
<xavierbot>
(`A
<xavierbot>
(`A
<xavierbot>
(`A
<xavierbot>
(`A
<orbitz>
the unix systems programming in Ocaml makes me wnat to start usign Ocaml for my little shell scripts instead
<Camarade_Tux>
wonders if we could draw ascii-art kitties using the ocaml toplevel and value definitions :-)
<orbitz>
i ahve to normalize a bunch of data for this project i'm doign so I think i'll use ocaml for that :)
<alpounet>
Camarade_Tux, that would definitely be productive :p
<Camarade_Tux>
orbitz: ocaml-fileutils is pretty nice for that too ;-)
<orbitz>
oh nice
<orbitz>
Is crating an Ocaml-platform similar to haskell-platform against the ocaml license? THat seem slike it'd be pretty helpful...
<Camarade_Tux>
alpounet: I think I should really go buy some food, hunger makes me say even more crap than usual ;-)
<Camarade_Tux>
I would say: CDK / Caml Development Kit, used in mldonkey
<alpounet>
orbitz, something like Batteries-on-steroids ?
<Camarade_Tux>
problem is that it's a big monolithic package and not kept up-to-date ("upstream", and in mldonkey sources)
<orbitz>
alpounet: I am thinking like a distirbution of ocaml where you download adn do make install and you now have ocaml, batteries, core, pa_do, etc etc, all that stuff so a user doesn't have to figure otu GODI or anything. and it woudl always be the latest versions and all
<alpounet>
orbitz, I must admit I doubt INRIA would let such a thing happen and that the license is probably restrictive enough for that... but i'm note sure.
<alpounet>
orbitz, I guess gildor's work is heading toward such a direction
<orbitz>
ok
<Camarade_Tux>
what would be problem with the license?
<Camarade_Tux>
(and yes, looks like gildor's doing what you want)
<orbitz>
I was under the impression tehr eis some distirbution restriction on the ocaml source
<alpounet>
Camarade_Tux, well, it would imply an alternative distribution of OCaml
<alpounet>
which I'm not sure INRIA authorizes.
<Camarade_Tux>
it does, definitely
<alpounet>
hm?
<gildor>
orbitz: yes I am doing this kind of thing and I totally have no pb with INRIA restriction because I am part of the CAML consortium
<avsm>
oh excellent. is it "ready" ? i've been meaning to overhaul my macports and openbsd packages for a while
<avsm>
in particular, none of them handle upgrades at all well
<gildor>
it is almost ready, it works and I should release it soon, but there will still a lot of things to do before reaching v1.0
<Camarade_Tux>
btw, yypkg (a binary package manager, mostly meant for windows but cross-platform) has improved quite nicely and I've started to make packages :-)
<gildor>
yypkg is for mingw ?
<Camarade_Tux>
mingw/mingw-w64 libs will work in icc and msvc but I don't use any of these, so yes, it's for mingw in practice
<thelema>
alpounet: My understanding is that INRIA doesn't have a problem with alternate distributions. If we could get our act together, it'd be very reasonable to have an enhanced version of ocaml out there. They'd prefer we not change the compiler, for obvious reasons.
<Camarade_Tux>
anyway, would the community really be able to improve the core compiler even without taking licenses into consideration?
<gildor>
Camarade_Tux: to my mind it is a full time job
<gildor>
Camarade_Tux: I am not even sure to be able to handle it myself without hiring someone
<alpounet>
I dived into the compiler last year
ygrek has joined #ocaml
<alpounet>
when proposing my Jane St SoC
<thelema>
Camarade_Tux: it would be very difficult, but legally possible. The compiler is in QPL - we could distribute modified binaris, and the source distro would have to be patches + INRIA's ocaml.
joewilliams_away is now known as joewilliams
derdon has joined #ocaml
<thelema>
The stdlib is under a more permissive library, we wouldn't even have to maintain patches for it.
<Camarade_Tux>
now, it's true it'll take more and more time and I know I won't be able to do it on my own
<Camarade_Tux>
I would hope that the developpers of the packages help themselves
<gildor>
Camarade_Tux: I am talking about improving the core compiler
<Camarade_Tux>
ah ^^
<Camarade_Tux>
so yeah, we agree on that ;-)
<gildor>
Camarade_Tux: maybe you can consider translating _oasis file to your .SlackBuild files
<flux>
btw, what does the license say if I distribute ocaml 3.12cvs binaries for n900?
<gildor>
flux: patch + binaries are ok
<alpounet>
sources are not
<Camarade_Tux>
gildor: I think the way would be to call oasis to buidl the files and then, install by hand (that's already what's being done for a few packages iirc)
<flux>
gildor, well, I don't need to publish patches then either because I haven't patched anything?
<gildor>
Camarade_Tux: you don't have to call oasis, it produces a standalone setup.ml in the source
<Camarade_Tux>
gildor: does it support DESTDIR or something similar?
<gildor>
Camarade_Tux: off course
<gildor>
of course
<Camarade_Tux>
as I expected, then it's perfect :-)
<gildor>
but for windows DESTDIR is not well implemented
<gildor>
because DESTDIR should be prepended
<gildor>
e.g. DESTDIR:C:\toto with a prefix %PROGRAMFILES% -> C:\toto\C:\Program Files
<gildor>
I don't know how to solve it
<Camarade_Tux>
the problem being the drive specification, as in "c:"?
<gildor>
however, it works as expected on POSIX
<thelema>
flux: binary distribution is ok. Like GPL, you have to make source available. Any source distro has to be original_source + patches
<gildor>
yes, drive specification and DESTDIR don't work together
<gildor>
DESTDIR is POSIX shorthand, not very windows compliant
<Camarade_Tux>
btw, I've always used godi on slackware but I'll maybe make distribution packages with the help of oasis :-)
<gildor>
bocage will be built on top of OASIS and should provide a GODI repository after translation of _oasis files
<gildor>
directly after your upload to forge.ocamlcore.org
f[x] has quit [Ping timeout: 240 seconds]
<Camarade_Tux>
wonder if you could keep '%PROGRAMFILES%' as-is in the path: ntfs seems to accept '%' ; I really don't know if it'd work but maybe...
<gildor>
PROGRAMFILES is expanded when I use it
<gildor>
Sys.getenv PROGRAMFILES
<Camarade_Tux>
that's actually a problem I had with yypkg (haven't implemented the corresponding part but had to think about it), I think I just decided to remove the 'C:' part from the environment variable
Jedai has quit [Ping timeout: 264 seconds]
derdon has quit [Ping timeout: 276 seconds]
barismetin has quit [Remote host closed the connection]
barismetin has joined #ocaml
barismetin has quit [Changing host]
barismetin has joined #ocaml
Jedai has joined #ocaml
brooksbp has joined #ocaml
fschwidom has quit [Remote host closed the connection]
struktured has quit [Ping timeout: 240 seconds]
yakischloba has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
spearalot has quit [Quit: -arividerchi]
<flux>
hm, Genlex.make_lexer : string list -> char Stream.t -> token Stream.t would be nicer if it were make_lexer : (string * 'a) list -> char Stream.t -> 'a token Stream.t and type 'a token = Kwd of 'a | ..
Demitar has quit [Ping timeout: 265 seconds]
lokydor has joined #ocaml
Jedai has quit [*.net *.split]
_andre has quit [*.net *.split]
sgnb has quit [*.net *.split]
sidolin has quit [*.net *.split]
ztfw has quit [*.net *.split]
willb1 has quit [*.net *.split]
Jedai has joined #ocaml
_andre has joined #ocaml
sgnb has joined #ocaml
sidolin has joined #ocaml
ztfw has joined #ocaml
willb1 has joined #ocaml
lokydor has quit [Quit: leaving]
lokydor has joined #ocaml
th5 has quit [Quit: th5]
_zack has quit [Quit: Leaving.]
<avsm>
the main packaging effort i'd like is to make it easier to have multiple installations of the ocaml variants
<avsm>
jocaml, ocamlduce, ocamljava, etc
philtor has joined #ocaml
ikaros has quit [Quit: Leave the magic to Houdini]
bzzbzz has joined #ocaml
<flux>
ubuntu has jocaml packaged, so in theory it's usable as-is for relatively wide audience
<flux>
as is ocamlduce. no ocamljava though :)
<flux>
jocaml is packaged by $binary =~ s/^ocaml/jocaml/ :)
<flux>
(possibly a compilation option)
<flux>
it's nice that the libraries between ocaml/jocaml are binary compatible, but on the other hand jocaml has sacrificed code mobility for it
zhijie1 has joined #ocaml
Snark has joined #ocaml
enthymeme has joined #ocaml
philtor has quit [Ping timeout: 246 seconds]
Demitar has joined #ocaml
ikaros has joined #ocaml
Yoric has quit [Quit: Yoric]
brooksbp_ has joined #ocaml
brooksbp has quit [Ping timeout: 252 seconds]
yakischloba has quit [Quit: Leaving.]
f[x] has joined #ocaml
MrEvil has joined #ocaml
ulfdoz has joined #ocaml
krankkatze has joined #ocaml
f[x] has quit [Ping timeout: 240 seconds]
avsm has quit [Ping timeout: 260 seconds]
f[x] has joined #ocaml
f[x] has quit [Ping timeout: 240 seconds]
f[x] has joined #ocaml
yakischloba has joined #ocaml
ikaros has quit [Ping timeout: 264 seconds]
lokydor has quit [Ping timeout: 258 seconds]
lokydor has joined #ocaml
bzzbzz has quit [Quit: leaving]
ikaros has joined #ocaml
willb1 has quit [Quit: Leaving]
willb1 has joined #ocaml
pimmhogeling has quit [Remote host closed the connection]
willb1 has quit [Client Quit]
barismetin has quit [Quit: Leaving...]
willb has joined #ocaml
fschwidom has joined #ocaml
lokydor has quit [Ping timeout: 258 seconds]
zhijie1 has quit [Quit: Leaving.]
Nepomuk has quit [Quit: Leaving]
Yoric has joined #ocaml
f[x] has quit [Ping timeout: 276 seconds]
f[x] has joined #ocaml
f[x] has quit [Ping timeout: 268 seconds]
f[x] has joined #ocaml
fraggle_ has joined #ocaml
ftrvxmtrx has joined #ocaml
bzzbzz has joined #ocaml
Submarine has joined #ocaml
Snark has quit [Ping timeout: 276 seconds]
boscop_ has left #ocaml []
fschwidom has quit [Remote host closed the connection]
jonafan has quit [Read error: Connection reset by peer]
komar_ has joined #ocaml
yakischloba1 has joined #ocaml
komar_ has quit [Client Quit]
joewilliams is now known as joewilliams_away
joewilliams_away is now known as joewilliams
yakischloba has quit [Ping timeout: 260 seconds]
komar_ has joined #ocaml
komar_ has quit [Client Quit]
jonafan has joined #ocaml
derdon has joined #ocaml
maattd has joined #ocaml
drunK has joined #ocaml
yakischloba1 has quit [Quit: Leaving.]
joewilliams is now known as joewilliams_away
_unK has quit [Ping timeout: 245 seconds]
f[x] has quit [Ping timeout: 276 seconds]
M| has quit [Ping timeout: 276 seconds]
pimmhogeling has joined #ocaml
f[x] has joined #ocaml
drunK is now known as _unK
M| has joined #ocaml
yakischloba has joined #ocaml
Nepomuk has joined #ocaml
_andre has quit [Quit: *puff*]
Submarine has quit [Quit: Leaving]
joewilliams_away is now known as joewilliams
jeddhaberstro has joined #ocaml
fschwidom has joined #ocaml
Nepomuk has quit [Quit: Leaving]
Nepomuk has joined #ocaml
<orbitz>
I noticed Core makes a lot of use of labels (those are paraemters with ~ right?)
<thelema>
yes, core is well-labeled
<orbitz>
do you think this is mostly for documetnation purposes?
<orbitz>
is using labels preferred?
<thelema>
I think it's an internal requirement at Jane Street
Pepe_ has quit [Remote host closed the connection]
<orbitz>
ok
<thelema>
In general, labeled arguments can prevent bugs, but has overhead
<orbitz>
also not sure why they don't label the second parameter
<thelema>
yup. But for folds, sometimes your accumulator is teh same type as the collection you're folding over, and swapping them gives big problems
<orbitz>
String.is_prefix line ~prefix:"Threads:"
<orbitz>
that's a good point
sepp2k has joined #ocaml
<thelema>
labels interfere with partial application, so it's useful to leave trailing arguments unlebeled
<thelema>
*unlabeled
krankkatze has quit [Ping timeout: 246 seconds]
<orbitz>
I've happily found that ocaml is a language where you can sit down with the alngauge ref and actually get something out of it, unlike C++
ikaros has quit [Read error: Connection reset by peer]
ikaros has joined #ocaml
<orbitz>
thelema: are the Label modules autogenerated or have to be manually done? (is it just a diff .mli file?)
brooksbp has joined #ocaml
<thelema>
orbitz: in batteries, the Label submodules are done by hand.
<thelema>
I wouldn't mind a solution that would automate this
<thelema>
s/wouldn't mind/would appreciate/
<thelema>
as the Labels aren't particularly well maintained
brooksb__ has joined #ocaml
brooksbp_ has quit [Ping timeout: 264 seconds]
<orbitz>
hrm
<orbitz>
thelema: think it could eb donw tih camlp4?
<thelema>
probably.
<thelema>
although I don't know how easy it would be.
<orbitz>
maybe i'll look into it for a sumemr rpoject
<orbitz>
think it'd just be esier to make a quick program to fidn top level let's and asdd ~?
brooksbp has quit [Ping timeout: 276 seconds]
<thelema>
I'd appreciate that. If you wanted to make some notes on what it would take, that'd be useful enough for someone else to get started if you don't do it.
<thelema>
I was thinking more along the lines of auto-generating the Labels sumbodules
<flux>
some sort of annotations should probably be used for generating the Labeled version
<thelema>
possibly even by stripping labels off the toplevel declarations and putting the labeled declarations in the Labels module
<flux>
I guess having ~f in List.map can be nice when you want to put the function last
<orbitz>
thelema: so what i have in mind is a program that reads a foo.ml and produces fooLabel.ml with top level let's modfied with labels
<thelema>
flux: yes, that's very true
<flux>
I've recently found, though, that I've uesd the pattern: foo |> List.map **> fun f -> .. .. ..
<orbitz>
flux: what doest aht do?
<flux>
(that .. possibly spanning multiple lines and finally finishing the function)
<flux>
orbitz, it's the same as List.map (fun f -> .. .. ..) foo
<flux>
**> is the same as haskell's $
<orbitz>
ah ok
<orbitz>
is that camlp4?
<flux>
|> is the 'reverse' of function application. so it applies the left side value to the right hand function.
<flux>
no, plain ocaml (but the functions are defined in batteries)
<orbitz>
ok
<orbitz>
does what i described soudn good, and you can do per module/per function annotation to modify how labels are created?
<flux>
I can see that kind of tool being useful
<orbitz>
cool
<orbitz>
added it to my task list
<flux>
atleast if one wants to maintain Label-kind mofules :)
<orbitz>
Should have enough time after this semester
drk-sd has joined #ocaml
ulfdoz has quit [Ping timeout: 265 seconds]
brooksb__ has quit [Quit: Leaving...]
<thelema>
Does my idea of stripping off labels from functions and gathering the labeled versions in a submodule make sense?
<flux>
indeed seems more simpler that way
Nepomuk has quit [Quit: Leaving]
<thelema>
no annotations, should compile w/o camlp4
* thelema
makes a gazillion printers for the toplevel
<thelema>
Any toplevel types you wish were printed nicely?
<flux>
feeling productive?-)
<thelema>
waiting for collaborator to fix bug in his code
krankkatze has joined #ocaml
<orbitz>
thelema: what do you mean by stripping off labels?
<thelema>
I'm definitely doing Sets of (string,int,char,float), Maps from those to those,
<thelema>
orbitz: given a function: "let map ~f v = ..." produce "let map f v = ..." and "module Labels = struct let map ~f v = map f v end"
<thelema>
of course one Labels module per file
<orbitz>
ah ok
<flux>
would it need to work for calls as well?
<orbitz>
so you'd write the labels version, and then move that into a sub Labels module and make the 'top' module the non labeled?
<flux>
so if f1 is written in terms of f2, the unlabeled version of f1 would use the unlabeled version of f2
<flux>
or would the new function simply call the labeled version?
<thelema>
flux: as long as the applications are all total, writing it w/o labels should work.
<flux>
(would inlining remove that indirection?)
<thelema>
the new function would need to call the unlabeled f2
<thelema>
Maybe cross-module inling would remove that indirection. If there was a problem, it'd be fine to use the labeled f2
<flux>
in that case it'd make sense to just call the labeled implementation of f1 when implementing the non-labeled version of it
<orbitz>
I'm off to do some homework, thanks all
<thelema>
flux: yes. Unless the function was recursive, in which case...
pimmhogeling has quit [Remote host closed the connection]
pimmhogeling has joined #ocaml
SEcki has joined #ocaml
lokydor has joined #ocaml
derdon has quit [Read error: Operation timed out]
drunK has joined #ocaml
Yoric has quit [Quit: Yoric]
avsm has joined #ocaml
_unK has quit [Ping timeout: 268 seconds]
drunK is now known as _unK
ygrek has quit [Ping timeout: 245 seconds]
bzzbzz has quit [Quit: leaving]
valross has joined #ocaml
thrasibule has quit [Quit: No Ping reply in 180 seconds.]
thrasibule has joined #ocaml
maattd has quit [Remote host closed the connection]
avsm has quit [Quit: Leaving.]
fschwidom has quit [Remote host closed the connection]
_unK has quit [Remote host closed the connection]
Associat0r has joined #ocaml
yakischloba has quit [Quit: Leaving.]
lokydor has quit [Ping timeout: 258 seconds]
joewilliams is now known as joewilliams_away
SEcki has quit [Remote host closed the connection]
ikaros has quit [Ping timeout: 246 seconds]
ikaros has joined #ocaml
thrasibule has quit [Quit: No Ping reply in 180 seconds.]
thrasibule has joined #ocaml
joewilliams_away is now known as joewilliams
pimmhogeling has quit [Ping timeout: 265 seconds]
krankkatze has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]