emmanuelux has quit [Remote host closed the connection]
marblen has joined #ocaml
<ollehar>
why doesn't ocaml support record subtyping?
<hcarty>
ollehar: This is may only be partially correct wrt the official reason - Records have a fixed structure, both externally (code) and internally (runtime).
<hcarty>
ollehar: Objects allow for subtyping and you can do some subtyping with first class modules.
<ollehar>
hcarty: but objects are structural typed, right?
<ollehar>
or perhaps duck-typed...
<ollehar>
damn
<hcarty>
ollehar: Objects are duck-type-like
yacks has joined #ocaml
mattrepl has quit [Quit: mattrepl]
<ollehar>
so wouldn't structural subtyping be "more" typesafe?
madroach has quit [Ping timeout: 248 seconds]
madroach has joined #ocaml
marblen has quit [Quit: marblen]
marblen has joined #ocaml
<hcarty>
More than...?
marblen has quit [Client Quit]
<ollehar>
more than duck typed subtyping
<hcarty>
According to the limited reading I've done, the two are pretty similar. The informal difference seems to be that duck-typing has checks at runtime.
<hcarty>
So in that definition, yes a statically checked type relationship would be more typesafe.
<hcarty>
OCaml's type checking for objects is static (structural typing as you mentioned)
ollehar has quit [Quit: ollehar]
ollehar has joined #ocaml
<ollehar>
sorry, my connection went down
cyball has quit [Read error: Operation timed out]
cyball has joined #ocaml
cdidd has quit [Remote host closed the connection]
weie has joined #ocaml
mikurubeam has quit [Ping timeout: 245 seconds]
Enjolras has quit [Read error: Operation timed out]
Enjolras has joined #ocaml
weie has quit [Read error: Connection reset by peer]
weie has joined #ocaml
ollehar has quit [Ping timeout: 252 seconds]
mattrepl has joined #ocaml
clintnewsom has quit [Quit: clintnewsom]
weie_ has joined #ocaml
weie has quit [Ping timeout: 256 seconds]
mcsquiggedy has quit [Quit: Leaving]
beckerb has joined #ocaml
mikurubeam has joined #ocaml
mattrepl has quit [Quit: mattrepl]
ollehar has joined #ocaml
marblen has joined #ocaml
amaloz has joined #ocaml
amaloz has left #ocaml []
ttamttam has joined #ocaml
ttamttam has left #ocaml []
ttamttam has joined #ocaml
ttamttam has left #ocaml []
BiDOrD has quit [Read error: Operation timed out]
BiDOrD has joined #ocaml
ollehar has quit [Remote host closed the connection]
ollehar has joined #ocaml
adotbrown has quit [Ping timeout: 256 seconds]
k0001_ has joined #ocaml
Yoric has joined #ocaml
<adrien>
morning
k0001_ has quit [Ping timeout: 256 seconds]
k0001 has joined #ocaml
ulfdoz has joined #ocaml
ulfdoz has quit [Client Quit]
ollehar has quit [Ping timeout: 252 seconds]
bobry has quit [Ping timeout: 245 seconds]
lopex has quit [Ping timeout: 245 seconds]
ulfdoz has joined #ocaml
marblen has quit [Quit: marblen]
milosn_ has joined #ocaml
milosn has quit [Ping timeout: 276 seconds]
ulfdoz has quit [Read error: Operation timed out]
Cyanure has joined #ocaml
djcoin has joined #ocaml
ollehar has joined #ocaml
ttamttam has joined #ocaml
marblen has joined #ocaml
mikurubeam has quit [Quit: +1 (Yes.) -1 (No.) i (WTF?)]
noam__ has joined #ocaml
ottbot has quit [Read error: Operation timed out]
noam_ has quit [Ping timeout: 256 seconds]
lopex has joined #ocaml
jbrown has quit [Remote host closed the connection]
anderse has joined #ocaml
hkBst has joined #ocaml
mika1 has joined #ocaml
Cyanure has quit [Remote host closed the connection]
<rixed>
Is there a way with opam to mark a package that was installed as a dependency as a "desired" package, so that it's not removed whenever I remove the other package that originaly pulled it in?
ollehar has quit [Ping timeout: 255 seconds]
<rixed>
sort of a "world" file for opam (à la gentoo)?
<Kakadu>
pin?
jbrown has joined #ocaml
ontologiae has joined #ocaml
<rixed>
installed.roots maybe?
<rixed>
apparently, that the one. thank you nobody :)
<thomasga>
rixed: 'opam install <package>'
<thomasga>
if it is already installed but not in the roots, it will become a root
<thomasga>
(only in recent versions of OPAM)
<thomasga>
but you can also edit installed.roots manually indeed
<Breadmonster>
I mean, I've been programming since I was 10.
<rixed>
thomasga: I tried that but it didn't work. Looks like my opem version is too old already :)
<Breadmonster>
And its only now, seven years later, that I realize that there languages other than C, or Python or Java.
<Kakadu>
Breadmonster: congratulations
<Kakadu>
You are 2 years faster than me :)
<rixed>
Kakadu: pin is different I think. First, it may not add the package in the root file ; second you may not want to pin a version or path to begin with :)
<Kakadu>
rixed: I have misunderstanded and failed. sorry
<rixed>
Breadmonster: for more than 10 years I though OCaml was merely a teaching language used in french schools :)
<rixed>
Kakadu: you'r welcome :)
<Breadmonster>
lol.
<Kakadu>
In the 2nd semester of the University we were joking about Objective Camels :)
<Breadmonster>
I really wanna join University.
Cyanure has joined #ocaml
Breadmonster has quit [Quit: leaving]
<companion_cube>
thomasga: I feel like bench.mli is outdated.. :/
<thomasga>
?
<companion_cube>
sorry, I wanted to hilight thelema -_-
<thomasga>
companion_cube: no idea what you are talking about :-)
<Henri>
Hello, trying to use opam to install/manage Ocaml compilers and packages. opam install camlp5 does not seem to perform the expected task (nothing appears in ~/.opam/system/lib)
tac has left #ocaml []
ttamttam has quit [Quit: ttamttam]
mcsquiggedy has joined #ocaml
Kakadu has joined #ocaml
Yoric has joined #ocaml
myx has quit [Ping timeout: 260 seconds]
ttamttam has joined #ocaml
stevej has quit [Quit: Computer has gone to sleep.]
thomasga has quit [Quit: Leaving.]
ontologiae has quit [Ping timeout: 245 seconds]
deselby has left #ocaml []
djcoin has quit [Quit: WeeChat 0.3.9.2]
Yoric has quit [Ping timeout: 240 seconds]
milosn_ has joined #ocaml
milosn_ has quit [Client Quit]
mcclurmc has quit [Ping timeout: 252 seconds]
k0001 has joined #ocaml
Henri has quit [Quit: Page closed]
k0001_ has joined #ocaml
k0001 has quit [Ping timeout: 260 seconds]
mikurubeam has joined #ocaml
<adrien>
wmeyer`: I'm going to definitely need help for linking of bytecode: I don't understand why it uses dlopen() at _link-time_ to find the primitives and I don't understand how that doesn't prevent bytecode from being portable
<adrien>
and I'm under the impression only contributors from the last millenium know
<adrien>
(sometimes it feels nice to be able to say "last millenium" :P )
<adrien>
I won't have time until saturday evening on sunday but I really need to have that one solved
<adrien>
(because "make opt" in most sources depends on "make all")
<adrien>
or Alain Frisch
<adrien>
I'll probably git/svn blame the corresponding piece of code first
lenstr has quit [Read error: Connection reset by peer]
mikurubeam has quit [Quit: +1 (Yes). -1 (No). i (WTF?).]
<adrien>
argh
<adrien>
I was wrong: custom links _works_
<adrien>
it's not-custom linking that doesn't
<adrien>
doing C and OCaml at once makes reading "!" more difficult
mikurubeam has joined #ocaml
<pippijn>
adrien: the ! operator?
<Kakadu>
pippijn: I think it is N.B. in manuals
<adrien>
! <- negation or reference? :P
<pippijn>
yeah
<pippijn>
adrien: it uses dlopen at link time to find C functions?
<pippijn>
adrien: did you find out why it does that?
<adrien>
no
<adrien>
it's for the bytecode VM but...
<adrien>
wmeyer`: well, if you get the hand on someone or can answer it yourself: why is Dll.synchronize_primitive needed? why is it needed at compile-time?
companion_square has joined #ocaml
companion_square has quit [Client Quit]
<adrien>
hah!
<adrien>
re-reading the code with a fresh eye, it gets the address of the symbol all the time but it doesn't use the result unless at link-time, only when dynamically loading the library
<adrien>
so I can most probably skip the computation \o/
yacks has quit [Quit: Leaving]
Enjolras has quit [Changing host]
Enjolras has joined #ocaml
ttamttam has quit [Remote host closed the connection]
ttamttam has joined #ocaml
smerz has joined #ocaml
<invariant>
Does opam update && opam upgrade && opam install typerex work for anyone?
<invariant>
I don't particularly understand how it is possible that a company which controls the entire platform (opam, typerex, etc.) manages to release something which doesn't even build, let alone work.
<invariant>
I mean, if you want to be taken seriously, don't you first write a test that the basics of the tool work (aka test suite), and run that before you do a public upload?
<invariant>
avsm, I'd say it's the people that publish crap that are annoying.
<invariant>
avsm, but you can have your opinion, just like I have mine.
<avsm>
opam is i) not out of beta yet; ii) still evolving towards a stable 1.0 and iii) supports multiple compiler versions and so has a complex matrix of variance
<invariant>
I am not using it with any unstable compiler.
emmanuelux has joined #ocaml
<invariant>
Saying something is not out of beta yet is a bad excuse for not testing something someone decided to package up.
<avsm>
good for you. bug report, it''ll get fixed
<avsm>
while it's still in beta, we're accepting merge requests much more aggressively than we will when it's stable
<avsm>
breakage happens. report it, and we'll fix it
<avsm>
rant on irc, probably not
<invariant>
The proper way to handle it is to auto-revert bad commits.
<invariant>
Then it gets fixed in 4 minutes.
<avsm>
gee, why didn't I think of that
<invariant>
I don't know, apparently you didn't.
<avsm>
one step backwards, instead of one forwards
* avsm
tunes out of the channel, and hopes to see a bug report, and will happily fix it if so
<invariant>
I assume that at some point it time before the bad commit the program worked for 99%.
<invariant>
A bad commit means it works for 0%.
<avsm>
(typerex depends on compiler internals, so it's highly dependent on the system libs, or the current compiler switch)
<invariant>
So, the way I see it is that you'd rather have that something works for 0% than for 99%.
<invariant>
I think your ability to evaluate what is good and what is not is broken then.
<invariant>
Also, it has been this for 16 days or so.
<avsm>
Generated META file /rambuild/pkg_opro_remote_all4/compiler_system4-packages_typerex/system/lib/META.ocp-bytecode
<avsm>
files: ocp-build.byte ocp-build
<avsm>
ocaml.ocp camlp4.ocpGenerated META file /rambuild/pkg_opro_remote_all4/compiler_system4-packages_typerex/system/lib/META.ocp-build
<avsm>
Generated META file /rambuild/pkg_opro_remote_all4/compiler_system4-packages_typerex/system/lib/META.ocaml-approx
<avsm>
Installing typerex.1.99.3-beta.
<avsm>
installs fine in our test matrix on 3.12.1, 4.00.1, and 4.00.0, and a slightly older snapshot of trunk
<invariant>
I am sure your tests make too many assumptions then.
mcclurmc has joined #ocaml
<invariant>
avsm, Error: bundle "typerex" is already installed
<invariant>
I don't really see why that would be an error, btw.
<invariant>
If I tell the system to install it, and it has already been installed, then it should just say "done".
<jbrown>
invariant: just messing around with it, looks like uninstallation doesn't remove some files. If you remove them manually, installation works again
<avsm>
so uninstallation is broken somewhere then
<invariant>
If you like static type systems so much, why don't you encode that property in a type?
<avsm>
that requires recording the installed files, post 1.0
<avsm>
and has very little to do with static types. it's just complicated due to optional files
<avsm>
and arch-specific files
<avsm>
and depopt-specific files
ollehar has joined #ocaml
<avsm>
and user configuration options
<adrien>
hmmmmm
<invariant>
I am sure that a static structure could be devised.
<invariant>
It might just not be as convenient, however.
* jbrown
wonders what on earth invariant is talking about
gnuvince has joined #ocaml
<invariant>
Thusfar, I have heard that the reason something has been broken for over 2 weeks is that changes are being merged too fast.
<invariant>
All of this continuous deployment stuff only works when you setup the infrastructure for that.
<invariant>
We have established that not even the most basic properties are being tested for (installation, uninstallation). How can you possibly expect that you can do continuous deployment then?
<jbrown>
invariant: I don't think you were paying attention when you were told this is software which is still in development :-). Try godi if you don't like it, heh.
<adrien>
if you run a continuously evolving setup, you know you can expect such issues
<jbrown>
...or your favourite OS's friendly package manager
k0001_ has quit [Ping timeout: 250 seconds]
<invariant>
I don't get the point of releasing broken software to people.
<invariant>
You can release something when you are not aware of any bugs in it and you wrote a test suite. Anything else is just vanity software.
<invariant>
"Look at us, we are building a mediocre package manager! Yeah, it's the best in ocaml land, but only because nobody competent has worked on the problem for OCaml. OMG!"
ttamttam has left #ocaml []
<jbrown>
invariant: uhh... did you get it from a git repository? That's not exactly being "released"
<jbrown>
oh, I see there are tarballs too. Never mind :-p.
<invariant>
jbrown, I am pretty sure that I am not getting it from a git repository.
<invariant>
All I am saying is that if you want feedback, you cannot expect to only get positive feedback.
* jbrown
doesn't have a dog in the fight -- IMO nobody's forcing you to use anything though
<invariant>
jbrown, indeed, I am not. In fact, I don't even use typerex, because it had way too many bugs the last time I tried it.
<invariant>
It smells like typical academic software that never needs to actually do anything.
<jbrown>
I'm using opam for my sekrit pet project, and it works for me, but I guess YMMV. I'd be using debian packages if one of the bits I need didn't have a bug in those (and I wasn't too lazy to report it)
<invariant>
jbrown, opam works for most packages, sure.
<jbrown>
there you go then, heh.
<invariant>
By works, I mean "works".
<avsm>
jbrown: glad to hear you're using it! Citrix and JSC have mostly switched over now too
* jbrown
is hardly a big commercial entity :-p
<invariant>
opam is fundamentally flawed, but I suppose that's for version 5.0.
<avsm>
jbrown: no, but every clued-up user counts.
<invariant>
I like most other stuff which is developed by JSC.
<adrien>
while I can understand frustration, you're being a bit aggressive (aggressivity being currently defined as making people uncomfortable)
<invariant>
They don't have all the fluff and just publish stuff that works.
<invariant>
I would love to see the internal study which says that it was a smart idea to allocate funds for opam development.
<invariant>
I kind of expected more from JSC.
<jbrown>
opam's not JSC's project, is it?
<avsm>
don't let facts get in a way of a good rant, jbrown
<jbrown>
haha
<invariant>
jbrown, AFAIK, they fund related projects.
<invariant>
If in fact JSC is not paying a dime for it, then they have not gone down in my ratings.
anderse has quit [Quit: anderse]
* jbrown
doesn't like the look of Core much (superficially, not tried using it for anything), but that's another matter :-p
<avsm>
we've almost finished an inter-library cross-referencing ocamldoc (it outputs JSON, just need to turn that to HTML). It makes Core/Async much, much, easier to use
<adrien>
as far as I'm concerned, if the name "Core" is really deserved compared to their other libraries, then I'm worried about their size :P
<adrien>
avsm: and then you'll rm -r ocamldoc/ in the compiler? :P
<avsm>
(and there's a uCore being developed which is a js_of_ocaml-friendly micro version of Core adrien :-)
<adrien>
ah, right, I saw you mentionning it on the caml-list
<avsm>
yeah, roughly. Leo's reimplemented the ocamldoc comment parser
<adrien>
well, all I wish for is that ocamldoc, ocamlbuild, camlp4, the debugger, ... move out of the compiler :P
<adrien>
(I've had to disable them for x-compilation)
<adrien>
(and it would be way more flexible)
<avsm>
yeah, that's certainly the longer term goal. there was consensus at the Consortium meeting. but of course, it'll take some time to adapt all the dependencies
<avsm>
how's the x-compilation work going?
<avsm>
i need to look at that soon for a MIPS64 port we're spinning up on an experimental CPU
<adrien>
I hope that after this commit message, I'm _done_
<avsm>
!
k0001 has joined #ocaml
<adrien>
haha, too tired to make a proper commit message :P
<jbrown>
avsm: btw I stuck https://github.com/puppeh/ocaml-sh4 on github -- cross-configure.sh was my (utterly filthy) solution for cross-compiling for that.
<jbrown>
I'm not really planning to do anything with that code, maybe it's interesting to someone though :-).
<avsm>
does qemu do sh4?
<jbrown>
kind of, but at the time at least I couldn't get enough of a system up to be useful
<avsm>
openbsd/vax remains my oddest architecture
<jbrown>
if you have a Sega Dreamcast lying around, it may or may not help. Heh.
<avsm>
ha
<avsm>
i've got a ridiculous number of rPis coming in for the ARM testing. it's a very convenient way to spot latent bugs in C bindings
<adrien>
friend of mine is working on something with 3 or 4 different CPU architectures iirc; I think the devices will be out in not too long if you want to play with such a monster :P
<avsm>
which ones?
<adrien>
I don't remember well but there's ARM for sure and sh4 I think along with some proprietary cores
_andre has quit [Quit: leaving]
<adrien>
bytecode linking fixed! \o/
<adrien>
rah! I need Str for ocaml-findutils!
<wmeyer`>
adrien: thx
<wmeyer`>
i am doing it now
<wmeyer`>
avsm: why rPI, it's v6 ...
<adrien>
almost bedtime for me now, I'm exhausted
<adrien>
wmeyer`: it's a subtle way to have you send him newer hardware :-)
<avsm>
wmeyer: widely deployed; i need to find some a53s for the pool. what's the right reference board now that OMAP5 is discontinued?
<wmeyer`>
adrien: we don't produce hardware! :-)
<wmeyer`>
avsm: a53 is V8 ... no backend, unless Aarch32 :-)
<avsm>
(xen almost boots on the A15 now btw, so we should be able to virtualise the OPAM ARM test pool, which is utterly insane)
<jbrown>
avsm: the fastest ARM boards are probably the odroid-x's or whatever they're called, at the moment, I think.
<wmeyer`>
wish: V8 backend soon!
<jbrown>
it tends to change on a weekly basis, so I might be out of date. Heh.
<adrien>
wmeyer`: you cannot make an architecture without having some test hardware, can you? that'd be crazy :P
<avsm>
yah we're working on getting the rPi dispatcher working fine with about 50 of them, and then will scale out to other variants
<avsm>
(once the test system is good enough to regression test our own stuff, if you see what I mean)
<wmeyer`>
adrien: sure but we don't give our gifts from our customers that would unpolite! :-)
<jbrown>
oh, they're only Cortex-A9s. Huh.
<wmeyer`>
avsm: is it actually possible to build OCaml with 256MB?
<wmeyer`>
i had problems on 512
<avsm>
yeah, just add swap
<jbrown>
I can't build ocaml-4.x on my ac100 (with 512mb), but I'm not sure if it's out of memory or some other problem
<adrien>
disable camlp4 maybe? :P
<avsm>
it's blasted camlp4
<adrien>
wmeyer`: oh ='(
<wmeyer`>
./configue -no-camlp4
<wmeyer`>
but then, which package would you build?
<wmeyer`>
jbrown: exactly
LeNsTR has joined #ocaml
<wmeyer`>
jbrown: out of memory
LeNsTR is now known as lenstr
<wmeyer`>
jbrown: switching off the desktop helps and killing some processes
<wmeyer`>
but actually avsm is for sure rigth adding swap should fix the problem
<wmeyer`>
so maybe it's a deeper problem
<jbrown>
yeah -- I don't quite like the idea of swapping to an SD card though :-). Those things die quickly.
<adrien>
pffft
<adrien>
just use compressed swap ;-)
<jbrown>
I am!
<invariant>
Can you tell me why you need more than 100MB to compile some code?
<wmeyer`>
invariant: please try.
<adrien>
actually I've used compressed memory and it's been working fairly nicely (although I was more in the gigabytes of memory)
osa1 has quit [Quit: Konversation terminated!]
<adrien>
invariant: some constructs are much more expensive than others
<invariant>
wmeyer`, the answer I expect in such cases is "you need, X, Y and Z, and thus it is impossible to do that".
<jbrown>
(and it has SATA, so you can attach a proper hard drive. Woo!)
<invariant>
Let me be more precise. If a compiler uses >100MB of memory, there should be an paper with a proof which says that it is using the minimal amount of memory or slightly more because of tested performance reasons.
<wmeyer`>
Theroem Exactly_invariant: forall X Y Z : Prop -> X /\ Y /\ Z. Proof. admitted. Qed.
<adrien>
invariant: it obviously depends on the size of your input code
<adrien>
it seems to depend a lot on the amount of "let rec ... and ..." you do
<wmeyer`>
it depends on many things, could you imagine that gcc sucks more memory than OCaml?
<adrien>
and, you should build webkit-gtk
<adrien>
it's not difficult
<invariant>
adrien, sure, but nobody was suggesting source files of 10MB.
<wmeyer`>
why? because gcc does not release anything + it parses to the tree headers that weight KLOCs
<adrien>
but it'll show you how much memory compilation and linking can take
<invariant>
In particular 1 million nestings is not expected.
<wmeyer`>
(maybe it releases; but imagine allocation in C)
<adrien>
poor debian people who build it on mips and arm
<adrien>
it takes, respectively, 3 and 2 days before bombing out during linking because the board don't have enough memory :P
<wmeyer`>
so I don't build anything on my AC100 :-)
<adrien>
wmeyer`: they want to release memory but that's something they don't manage to do and iirc it's a reason for them to use C++
<wmeyer`>
basically - I don't.
<adrien>
which is unfortunate because it'll use more memory :P
<wmeyer`>
adrien: linker is another problem
<invariant>
I think the only reason it uses a lot of memory is that it keeps the compiler simpler to maintain.
<invariant>
It has nothing to do with ultimate efficiency limits.
ottbot has quit [Ping timeout: 255 seconds]
<wmeyer`>
adrien: yeah you can use "smart pointers" in C++ - these are good ones, at each assigment they call a method to increase the ref counter.
<adrien>
I'll wait for full correctness of compilers because I ask them for better efficiency
<wmeyer`>
adrien: gcc is buggy as hell i would imagine
k0001 has quit [Ping timeout: 245 seconds]
<adrien>
wmeyer`: yeah, I agree they can have some better memory management but C++ itself uses more memory usually; meaning that until they actually transition, they'll use more memory :P
weie_ has quit [Quit: Leaving...]
<adrien>
but my issue with GCC being in C++ is the build times
<adrien>
I build GCC in 5 minutes on my quad, probably 30 minutes on my laptop; I build llvm in 120 minutes on my laopt
<adrien>
laptop*
<wmeyer`>
adrien: more ram.
<wmeyer`>
clang takes about 6GB
<adrien>
I have 3.5GB (or is it 2.5GB? :P ) and no swap
<adrien>
the process hasn't bombed out
<wmeyer`>
do you use gold?
<adrien>
nope, bfd by default although gold is available
<wmeyer`>
it's rising high, very quickly up to the peak above 6GB
<wmeyer`>
maybe you can do make -j2 if you have 2 cores
<adrien>
parallel build?
<wmeyer`>
yes
<adrien>
ah
<adrien>
I'm not sure about the numbers anymore so I'll let my laptop do a build tomorrow during the day :-)
<wmeyer`>
adrien: i had 4GB and asked for more at work - immediatelly my life become much simplier
<wmeyer`>
and less hectic - less coffee.
<adrien>
hah
<adrien>
I had 1GB
<adrien>
got 2GB fairly quickly and then 4GB (on a laptop)
<invariant>
I wish you all had 500MB. 400MB run your DE and 100MB for the rest ;)
<adrien>
and then I hijacked the dual dual-core with 16GB of memory, of which some is dead but ECC catches it :D
<invariant>
Does ECC actually reallocate physically?
<adrien>
actually it's pretty funny: according to the error messages it seems the error is only discovered when the data in in the L3 cache
<invariant>
Or perhaps that's only done in software?
<adrien>
so we've been wondering if the process of checking the data from the RAM is asynchronous and the error is then raised a posteriori
<adrien>
before the data is used but after it has been sent to the CPU
<adrien>
which would make sense performance-wise but seems more difficult to implement
noam has joined #ocaml
noam__ has quit [Ping timeout: 245 seconds]
Kakadu has quit []
ottbot has joined #ocaml
ollehar has quit [Ping timeout: 245 seconds]
amaloz has joined #ocaml
mattrepl has quit [Quit: mattrepl]
anderse has joined #ocaml
Guest34021 has quit [Quit: WeeChat 0.3.0]
Anarchos has joined #ocaml
thomasga has joined #ocaml
thomasga has quit [Client Quit]
adrien_o1w has joined #ocaml
adrien_oww has quit [Ping timeout: 276 seconds]
Yoric has joined #ocaml
Cyanure has quit [Remote host closed the connection]
adotbrown has joined #ocaml
k0001 has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
smerz has quit [Ping timeout: 245 seconds]
anderse has quit [Quit: anderse]
smondet has quit [Read error: Operation timed out]
k0001_ has joined #ocaml
k0001 has quit [Ping timeout: 264 seconds]
Yoric has quit [Ping timeout: 264 seconds]
clintnewsom has quit [Quit: clintnewsom]
oriba has joined #ocaml
q66 has quit [Remote host closed the connection]
gnuvince has quit [Read error: Connection reset by peer]
pkrnj has joined #ocaml
emmanuelux has quit [Remote host closed the connection]