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!)
notyouravgjoel has joined #ocaml
jonafan has quit [Read error: 110 (Connection timed out)]
dwmw2_BOS has quit ["tin can..."]
hkBst has quit ["Konversation terminated!"]
ecc_ has joined #ocaml
goalieca has joined #ocaml
LordMetroid has quit [Connection timed out]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
notyouravgjoel has quit ["This computer has gone to sleep"]
ecc_ has quit ["leaving"]
ecc has quit ["leaving"]
Tetsuo has quit ["Leaving"]
shortcircuit has quit [Read error: 110 (Connection timed out)]
mwc has joined #ocaml
ecc has joined #ocaml
Snrrrub__ has joined #ocaml
Snrrrub has quit [Connection timed out]
heash has joined #ocaml
heash has left #ocaml []
mrsolo has quit ["Leaving"]
xavierbot has quit [Read error: 110 (Connection timed out)]
Snrrrub__ has quit [Read error: 110 (Connection timed out)]
ben_ has joined #ocaml
shortcircuit has joined #ocaml
mrsolo has joined #ocaml
shortcircuit has quit [Read error: 110 (Connection timed out)]
ben_ has quit []
jeffwheeler has joined #ocaml
ecc has quit [brown.freenode.net irc.freenode.net]
mwc has quit [brown.freenode.net irc.freenode.net]
pattern has quit [brown.freenode.net irc.freenode.net]
bzzbzz has quit [brown.freenode.net irc.freenode.net]
petchema has quit [brown.freenode.net irc.freenode.net]
szell` has quit [brown.freenode.net irc.freenode.net]
Illocution has quit [brown.freenode.net irc.freenode.net]
jeremiah has quit [brown.freenode.net irc.freenode.net]
ikatz has quit [brown.freenode.net irc.freenode.net]
jdavis_ has quit [brown.freenode.net irc.freenode.net]
rwmjones has quit [brown.freenode.net irc.freenode.net]
Smerdyakov has quit [brown.freenode.net irc.freenode.net]
ecc has joined #ocaml
mwc has joined #ocaml
pattern has joined #ocaml
bzzbzz has joined #ocaml
petchema has joined #ocaml
szell` has joined #ocaml
rwmjones has joined #ocaml
Illocution has joined #ocaml
jeremiah has joined #ocaml
ikatz has joined #ocaml
jdavis_ has joined #ocaml
Smerdyakov has joined #ocaml
Nutssh has joined #ocaml
Smerdyakov has quit [brown.freenode.net irc.freenode.net]
ikatz has quit [brown.freenode.net irc.freenode.net]
Illocution has quit [brown.freenode.net irc.freenode.net]
bzzbzz has quit [brown.freenode.net irc.freenode.net]
mwc has quit [brown.freenode.net irc.freenode.net]
ecc has quit [brown.freenode.net irc.freenode.net]
petchema has quit [brown.freenode.net irc.freenode.net]
szell` has quit [brown.freenode.net irc.freenode.net]
rwmjones has quit [brown.freenode.net irc.freenode.net]
jdavis_ has quit [brown.freenode.net irc.freenode.net]
jeremiah has quit [brown.freenode.net irc.freenode.net]
pattern has quit [brown.freenode.net irc.freenode.net]
ecc_ has joined #ocaml
bzzbzz has joined #ocaml
pattern has joined #ocaml
ikatz has joined #ocaml
Illocution has joined #ocaml
petchema has joined #ocaml
jdavis_ has joined #ocaml
rwmjones has joined #ocaml
Smerdyakov has joined #ocaml
mwc has joined #ocaml
jeremiah has joined #ocaml
mwc has quit [Read error: 104 (Connection reset by peer)]
mwc has joined #ocaml
det has quit [Read error: 110 (Connection timed out)]
jeffwheeler has left #ocaml []
goalieca has quit [Remote closed the connection]
evn_ has joined #ocaml
goalieca has joined #ocaml
|Catch22| has quit []
evn_ has quit []
AxleLonghorn has joined #ocaml
shortcircuit has joined #ocaml
ben_ has joined #ocaml
AxleLonghorn has left #ocaml []
goalieca has quit [Remote closed the connection]
goalieca has joined #ocaml
bluestorm has joined #ocaml
ttamttam has joined #ocaml
mwc has quit ["Leaving"]
ita has joined #ocaml
ygrek has joined #ocaml
<TFK> Memory-profiling, old-skool style - comment out code and see if it still leaks :D
<TFK> It's not GSL, apparently. Which brings me back to the fact that I create lots and lots of small types ("genomes" from arrays).
<flux> tfk, maybe you could add finalizers to suspicious blocks
<bluestorm> small types, or small values ?
<flux> and issue gc manually
<flux> and check out which blocks don't get finalized
Linktim has joined #ocaml
<TFK> bluestorm, the type is a genome length integer and a ~256-byte string.
<TFK> Finalizers, I'll look into that.
<bluestorm> hm, you encode different array lengths at the type level ?
<TFK> What do you mean?
<bluestorm> hm. i'll refrain from disturbing you by asking stupid questions about your code
<TFK> That's OK, I ask stupid newbie questions here all the time ;-)
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
Amorphous has quit [Read error: 104 (Connection reset by peer)]
Amorphous has joined #ocaml
ben_ has quit [Read error: 110 (Connection timed out)]
<TFK> flux, it appears that simply calling Gc.full_major alleviates most of the problem.
love-pingoo has joined #ocaml
<TFK> Memory still rises though, but slowly...
<flux> tfk, it still does suggest that you keep hold of something, if your actual memory requirements don't increase..
<flux> tfk, maybe you could adjust the gc parameters to get better behavior
Tetsuo has joined #ocaml
bongy has joined #ocaml
<bluestorm> TFK: do you have some relatively simple code to show ?
<TFK> It's 700 lines
<bluestorm> btw. , have you used Gc.print_stat yet ?
<TFK> Not yet.
<bluestorm> imho it's a bit verbose if you're not familiar with those GC-things, but quite useful
goalieca has quit ["(keep your stick on the ice)"]
<TFK> flux, how would I tweak the GC to make it run more often (which is apparently what I need, using Gc.create_alarm a major cycle isn't run until I call it... why?)?
<flux> tfk, dunno, have you checked out the parameters?-)
<flux> there should be some thresholds you can adjust..
<flux> an nonrelated to that, I just wrote a nice useful(?) tool (based on pango's annotator.ml): http://modeemi.cs.tut.fi/~flux/software/grep-annot/
<flux> usage: grep-annot bar_type *.ml
<flux> and it performs a grep of all the .ml-files as if their corresponding .annot-files were merged in
<bluestorm> TFK: there are different things you can tweak
<flux> hm, the binary should really be named grep-annot..
<flux> so to find every place where floats are used, just grep-annot float *.ml
<bluestorm> TFK: i guess you could try to reduce the space_overhead field of Gc.control
<bluestorm> but adding Gc.full_major () at good places in the code is probably a decent (and more flexible) idea too
<TFK> I'll try that. But it bothers me that the Gc is stalled for so long...
<bluestorm> why do you think it should run more often ?
<pango> TFK: major collection is done incrementally
<TFK> Incrementally?
<pango> alarm is called, I think, only when a cycle is completed
<TFK> bluestorm, well, when your program doubles and triples in RAM for no other reason that the GC doesn't run :-)
<bluestorm> hm
<bluestorm> have you tried do force minor collections instead ?
<pango> you should have a look at chapter 9 of "developping applications with objective caml": http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora082.html
<pango> it's a gentle introduction to OCaml's gc
<TFK> pango, I will, thanks.
<TFK> bluestorm, nope. Anyway, doesn't a major collection execute a minor collection as well?
<pango> that's the other way around, minor collection is followed by a slice of the major collection
<bluestorm> yes, but it's overkill if the data you want to collect is only in the "recent objects" pool
<bluestorm> wich is usually the case
<TFK> Hmm, live_words doesn't appear to grow. I guess Ubuntu's System Monitor is leading me astray?
<bluestorm> what about minor_words ?
<TFK> Is growing, but it's also the stuff that's already been collected, no?
<bluestorm> isn't
<bluestorm> a gross picture would be : it's a two-generation GC, you've two pool of live objects : the minor, where you've got the young and little objects, and the major, where you have to old, big objects
<bluestorm> allocated values start in the minor pool, and if they survived some minor collections, they got "promoted"
<bluestorm> that's useful because in functional programming, you allocate a lot of small object with a very short life
<bluestorm> thus, frequent minor collections are very useful, and they do not have to scan the pool of older objects, wich are less likely to get freed
<pango> actually increasing minor heap to make them less frequent can give better performance
<TFK> Well, it appears that in between me invoking minor collections, some stuff gets promoted, and RAM usage still grows.
<bluestorm> TFK: if you have a *leak*
<flux> bluestorm, hmm, for a game, would it be a bad idea to cal Gc.minor () after each drawn frame? (drawing a frame may require constructing quite a few temporary objects)
<bluestorm> you can't handle it by GC-tuning only
<TFK> bluestorm, or if I'm not invoking a major collect, as I understand it.
<pango> because it lowers to ratio of promoted objects, and lessen major collection's work
<bluestorm> pango: what i've tried on a few code of mine that had problems of GC overwork
<TFK> Anyway, minor collects *are* getting called constantly, no matter what I do (at least print_stats says so).
<bluestorm> was to increase the minor_heap_size
<bluestorm> (and the major_heap_increment)
<pango> TFK: size of major collection's slices should be driven by space_overhead
<bluestorm> you should lessen space_overhead
<bluestorm> it's a percentage, so try 60 for example
<TFK> I'll do that.
<bluestorm> (default is 80)
<bluestorm> but if you do that, the GC will have to work more, so you'll have a bit more CPU usage
<bluestorm> flux: i think the GC can handle that himself
<TFK> Better than blasting my RAM away ;-)
<flux> I've had one case where I had to adjust Gc parameters to reduce cpu consumption.. I'm just wondering if a well-put explicit minor collection would've helped as much.
<bluestorm> hm
<bluestorm> in the gc-use-your-cpu case i've seen, i actually allocated a lot of long-lived objects
<pango> flux: explicitly calling the gc most often results in lower performance
<bluestorm> and the cpu waste was caused by little promotions occuring too often
<flux> at each cycle the program discarded all the memory it had allocated
<bluestorm> so as pango say, the way to handle that was to actually increase the minor slices work, so that they would run less often
<bluestorm> +s
<flux> so in theory if the gc was well-placed, there would be very few roots to follow
<flux> wouldn't that make the gc fast?
<bluestorm> hm, you could try
<bluestorm> i guess it really depends on the project you have
<pango> flux: the only reason, in a game, could be to try to avoid collection happening at a "wrong time" (visible latency), but that looks like deep magic
* pango wonders if, say, freetennis, explicitly calls the gc
<flux> actually it was a different problem in the case I had in my mind.. I solved its performance problem with Gc.minor_heap_size = 1 lsl 18, I guess the default minor heap size is smaller?
<bluestorm> hm
<flux> I tried out without that change, with that change and without that change with explicit Gc.minor; only the middle one produced an effect
<bluestorm> i have used even bigger value
<flux> I think I found that value by iteration
<bluestorm> at the cost of increased memory consumption, i got quite major performance impromevent
<bluestorm> (i use 22 to 24 iirc)
<flux> anyway, the problem existed only because the cpu was 200MHz and the program was pegging the cpu; the from from 15% to 13% is hardly relevant on modern hardware. but I guess at times it could have a larger effect.
<bluestorm> flux: this kind of minor-collection-related slowdown can be seen easily when profiling
<bluestorm> (native profiling, i mean)
<bluestorm> when your first time-consuming function is gc-related
<flux> yes, that's how I found it
<flux> it still did consume a lot cpu, though
<flux> which is sort of ridicilous when a "mark" and "release"-kind of memory management would be able to do the same with 0% overhead ;)
<flux> has region inference found itself into any compilers other than mlkit?
<bluestorm> haven't heard of any
<flux> theoretically that should do it.. if lucky.
<flux> but I wouldn't mind if I had to manually annotate some pools, maybe that would give the compiler a better chance
<TFK> space_overhead does seem to help in that a full major cycle is eventually called, but live_words stays the same o_O
<pango> in compaction hels but major collection doesn't, maybe you have a bad case of memory fragmentation
<pango> s/in/if/
<TFK> compaction never got executed anyway
ita is now known as ita|zzz
<TFK> when I called full_major manually, live_words stayed constant without any compactions.
<pango> aha, yes, full_major doesn't call compaction
<TFK> This makes no sense whatsoever :-(
Yoric[DT] has joined #ocaml
<Yoric[DT]> hi
<TFK> hullo
<TFK> hmmm, if live_words remain constant but fragments are rising, will it still indicate an increase in RAM usage in the System Monitor?
* Yoric[DT] has never looked at the internals of OCaml's gc.
<flux> tfk, how long are you running the program?
<TFK> a few minutes?
<TFK> Eventually it should run a few hours.
<pango> I think ram usage should more or less follow heap_words metric
<pango> that could depend on underlying malloc()/free() implementation
<love-pingoo> (unless you're interfacing with some C code of course)
<TFK> heap_words remain constant if I call major_collect all the time.
<pango> yes, there's also out-of-heap allocations
<TFK> Let me try that without GSL, then.
<love-pingoo> is it a large program ? can we have a look ?
<flux> could the GSL bindings have a bug?
<love-pingoo> if you don't have any C code around, there should be a simple (high-level) explaination
<TFK> It's 700 lines of code, it's logically not difficult but I doubt you'd want to look at it.
<love-pingoo> sounds too large for a quick glance, yup
<flux> tfk, I think your best (well, easiest) bet would be to proceed chatting with the guy who wrote/ported the heap debugger, and find out how to make it work for you :)
<TFK> heh...
<love-pingoo> oh, we used that heap debugger
<TFK> and who wrote it?
<TFK> oh, you mean heapstats
<love-pingoo> fabrice le fessant
<TFK> Does he speak English?
jderque has joined #ocaml
<love-pingoo> sam had to write a patch for it to work on 3.10 (or was it 3.09)
<love-pingoo> TaXules: yes he does :)
<TFK> I guess I'll write him, then...
<love-pingoo> but really, going to heapstat should be the last attempt
<flux> why? it could almost instantaneously point to the right direction?
<love-pingoo> it's painful to use and it doesn't help if the problem is on the C side
<flux> it would point out that too, no?
<flux> I haven't tried to use it, so I don't know about that.. it does require recompiling everything (?) with it, though?
<TFK> Anyway, substituting GSL for OCaml's Random doesn't help.
<love-pingoo> it would tell you how many custom blocks of which kind are allocated
<love-pingoo> but doesn't inspect inside them
<flux> I suppose if it's only a single module tfk is developing, it wouldn't help much
<love-pingoo> TFK: what kind of program is it ?
<TFK> I'm porting Nanopond, an Artificial Life simulator, to OCaml.
<love-pingoo> so you're creating lots of entities and have them live
<TFK> The port is basically ready (as it was half a year ago), but yesterday I finally got around looking into its peculiar RAM usage.
<love-pingoo> then they die
<TFK> Yes, I'm creating lots and lots of objects.
<love-pingoo> sure they can be reclaimed by the GC once dead ?
<TFK> More specifically, I'm converting Arrays to "genome" and vice versa.
<love-pingoo> no global table of all entities ?
<TFK> Where "genome" is an int and a string of ~256 bytes.
<TFK> I have a matrix of "cells", but they're all mutable, so I don't create new cells, only change their attributes.
<love-pingoo> mmm
<love-pingoo> and the memory keeps growing ?
<love-pingoo> are you on 32 or 64 bits ?
<TFK> Well, when I call Gc.major_full every 1e5 iterations, it grows really, really slowly, makes me suspect System Monitor is leading me astray.
<TFK> 64
<love-pingoo> and if you don't call it ?
olleolleolle has joined #ocaml
<bluestorm> TFK: i think you could/should make the code available (if you intend to open-source it eventually, of course)
<TFK> And if I don't call it, memory grows pretty fast.
<love-pingoo> there was a funny bug on 64bits, recently.. I think it only caused an initial silly huge consumption of memory, but let me check
<TFK> bluestorm, I'm planning to (Nanopond is GPL anyway), I just want to iron it out first :-)
<TFK> Another curious thing: when I changed space_overhead, full major got called on its own eventually, but didn't release any memory.
<TFK> (at least, whatever create_alarm registered was called)
<love-pingoo> (http://caml.inria.fr/mantis/view.php?id=4448 but I don't think it's related)
<bluestorm> TFK: release early, release often
<TFK> Well... besides performance, I want to understand the problem.
<bluestorm> bogus argument :)
<TFK> Understanding the problem is not important?
<bluestorm> of course it is, but understanding it after a release makes no difference
<TFK> after a release?
olleolleolle has quit []
sgnb has joined #ocaml
mattam has quit ["Lost terminal"]
mattam has joined #ocaml
ita|zzz is now known as ita
Linktim has quit [Read error: 104 (Connection reset by peer)]
Linktim has joined #ocaml
ofaurax has joined #ocaml
olleolleolle has joined #ocaml
coucou747 has joined #ocaml
TFK has quit ["Leaving"]
marmottine has joined #ocaml
love-pingoo has quit ["Connection reset by pear"]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
jderque has quit ["zoo"]
olleolleolle has quit []
jlouis_ has joined #ocaml
ardor has joined #ocaml
<ardor> hi guys
jlouis has quit [Read error: 110 (Connection timed out)]
jderque has joined #ocaml
LordMetroid has joined #ocaml
ita has quit [Remote closed the connection]
dwmw2_gone has joined #ocaml
linktim_ has joined #ocaml
olleolleolle has joined #ocaml
olleolleolle has quit []
Linktim has quit [Read error: 110 (Connection timed out)]
olleolleolle has joined #ocaml
linktim__ has joined #ocaml
linktim_ has quit [Read error: 110 (Connection timed out)]
linktim_ has joined #ocaml
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
pango_ has joined #ocaml
linktim__ has quit [Read error: 110 (Connection timed out)]
linktim_ has quit [Read error: 110 (Connection timed out)]
jderque has quit ["leaving"]
bongy has quit ["Leaving"]
robyonrails has joined #ocaml
pango has quit [Remote closed the connection]
Morphous has joined #ocaml
LordMetroid has quit ["Leaving"]
Amorphous has quit [Connection reset by peer]
jlouis has joined #ocaml
Morphous has quit [Read error: 110 (Connection timed out)]
waxblood_ has joined #ocaml
<waxblood_> What's the ocaml function to parse and evaluate ocaml code?
<bluestorm> there isn't
<thelema|away> waxblood_: sorry, no can do.
thelema|away is now known as thelema
<bluestorm> usually you can do without that kind of things
<bluestorm> if you _really_ want something like that, have a look at MetaOCaml
det has joined #ocaml
<thelema> the ocaml runtime doesn't include an ocaml interpreter/compiler
<bluestorm> but most probably you're too used to dynamic scripting languages, and you use that kind of things where you could do differently (and, imho, better)
Amorphous has joined #ocaml
<waxblood_> bluestorm: I like to do genetic programs, and I wanted to see if Ocaml can do that kind of things - I like its syntax and type-system
<bluestorm> hm
<bluestorm> you could do that, but it would be ugly
<waxblood_> and with Metaocaml?
<bluestorm> (basically, once you've a representation of an ocaml program, write that into a file, and then compile/execute it)
<bluestorm> i don't know MetaOCaml enough
<bluestorm> but i'm not sure
<bluestorm> (i don't know MetaOCaml at all, actually)
<bluestorm> but the compilation approach seems praticable
<bluestorm> although maybe a bit too heavy for a "genetic" use
<bluestorm> got to go, anyway
<thelema> bluestorm: making your own simple language with an ocaml representation and a simple interpreter is very easy in OCaml - try that method of genetic programming
jlouis_ has quit [Read error: 110 (Connection timed out)]
robyonrails has quit ["Leaving"]
<waxblood_> thelema: interesting link ^^
<thelema> 1st google result on "ocaml genetic programming"
<Smerdyakov> waxblood_, I think you have an understanding gap if you believe a language can't be used to implement genetic programming if it doesn't support loading of code from source.
<waxblood_> thelema: results for "ocaml eval" or "ocaml repl" where less informative, so I got a little discouraged
<Smerdyakov> waxblood_, again, if you think those were important Google searches to understand whether OCaml can be used for genetic programming, you have an understanding problem.
<thelema> waxblood_: glad you checked here.
<thelema> Smerdyakov: that's how it's done in other languages. he just didn't know.
<waxblood_> exactly.
<ardor> What do you guys think of F#
<Smerdyakov> I have to hold my ground and say it's worth some rethinking if a person can't conceive of another way of doing genetic programming.
<waxblood_> Smerdyakov, I wanted eval just to perform some little experiment with ocaml, genetic programming was a second goal
<Smerdyakov> waxblood_, OK.
<thelema> ardor: I approve of more people using ocaml-like programming styles. I haven't used it myself.
<ardor> What IDE do you use for Ocaml ?
<thelema> ardor: emacs
<Smerdyakov> Almost all OCaml programmers use Emacs.
<waxblood_> I'd check out cameleon, if it run on my Ubuntu Gutsy :(
<ardor> does emacs do autocomplete?
jderque has joined #ocaml
<thelema> ardor: alt-/ (or in emacspeak, M-/)
waxblood_ has quit ["Leaving"]
szell has joined #ocaml
thermoplyae has joined #ocaml
szell has quit [brown.freenode.net irc.freenode.net]
Snark_ has joined #ocaml
szell has joined #ocaml
Smerdyakov has quit ["BRB"]
Smerdyakov has joined #ocaml
Snrrrub__ has joined #ocaml
Snrrrub___ has joined #ocaml
LordMetroid has joined #ocaml
Snrrrub__ has quit [Read error: 110 (Connection timed out)]
Sapan has joined #ocaml
<Sapan> anyone know of a way to convert from Unix.file_descr -> int ?
<rwmjones> Sapan, Obj.magic :-)
<rwmjones> they're the same thing
<Sapan> rwmjones: i need to pass one to an external C function definition. Would Int_val () from C see the right value?
ttamttam has left #ocaml []
<rwmjones> Sapan, no
<rwmjones> erm, sorry yes
<rwmjones> or would it
* rwmjones checks
* Sapan is checking as well
<rwmjones> Sapan, yes it would work
<rwmjones> Unix.file_descr is just an int
<rwmjones> an OCaml int
<rwmjones> so Int_val will work fine
<Sapan> ok, thanks
<pango_> on unixen only
ita has joined #ocaml
Smerdyakov has quit ["Leaving"]
Smerdyakov has joined #ocaml
Snark_ has quit ["Ex-Chat"]
Yoric[DT] has quit [Read error: 113 (No route to host)]
<bluestorm> oh
<bluestorm> i thought he specifically wanted to "genetically" create 'ocaml programs'
Snrrrub___ is now known as Snrrrub
jderque has quit ["leaving"]
jlouis_ has joined #ocaml
|Catch22| has joined #ocaml
Yoric[DT] has joined #ocaml
goalieca has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
marmottine has quit [Remote closed the connection]
marmottine has joined #ocaml
<Yoric[DT]> Does anyone know if there's a %identity-style primitive for applying a function to an argument ?
<bluestorm> is that not just identity ?
Yoric_ has joined #ocaml
Yoric[DT] has quit [Nick collision from services.]
Yoric_ is now known as Yoric[DT]
<Yoric[DT]> Back from X freeze
<ita> Yoric[DT]: [22:21] <bluestorm> is that not just identity ?
<Yoric[DT]> Just trying to check if there's anything better.
* Yoric[DT] is still fighting with the performances of his exception library.
<Smerdyakov> My goodness. A rare use of non-idiomatic English by Yoric, with "performances" in place of "performance"! ;)
<bluestorm> :D
<Yoric[DT]> Should I have written performance ?
<Yoric[DT]> Or is that a pun related to acting ?
<Smerdyakov> Yes, and also avoid spaces before question marks. :P
<Smerdyakov> It's not a pun. "Performance" is never pluralized in the context of computer efficiency measurement.
<Yoric[DT]> Thanks for the tips.
<ita> no wonder your code is acting weird
<Yoric[DT]> Somehow, being nicknamed Yoric, I tend to attract acting-related puns :)
<Smerdyakov> But, seriously, your English rocks. You're French, right?
<Yoric[DT]> I am.
<Smerdyakov> These other clowns in here should take a lesson from you. :P
<Yoric[DT]> And thanks.
* Yoric[DT] starts to blush.
<bluestorm> My goodness. A rare compliment from Smerdyakov.
<ita> Smerdyakov: :-)
ita has quit [Remote closed the connection]
ygrek has quit [Remote closed the connection]
eelte has joined #ocaml
goalieca has quit [Remote closed the connection]
goalieca has joined #ocaml
l_a_m has quit [Remote closed the connection]
marmottine has quit ["Quitte"]
Yoric[DT] has quit ["Ex-Chat"]
eelte has quit [Remote closed the connection]
thermoplyae has quit ["daddy's in space"]
hcarty has quit [Remote closed the connection]