<Algebr>
So I've seen some bytecode that for jump instructions for functions, relative addressing is used, but I don't understand the necessity of that, why can't one just use absolute addressing?
<Algebr>
or rather used in branch instructions
lordkryss has quit [Quit: Connection closed for inactivity]
zz_flazz has quit [Ping timeout: 240 seconds]
ivan\ has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
oriba has quit [Quit: oriba]
_5kg has joined #ocaml
dsheets has quit [Ping timeout: 244 seconds]
thomasga has quit [Quit: Leaving.]
philtor_ has quit [Ping timeout: 256 seconds]
q66 has quit [Quit: Leaving]
ivan\ has joined #ocaml
pyon has quit [Quit: Fiat justitia ruat caelum.]
Algebr has quit [Remote host closed the connection]
travisbrady has joined #ocaml
_5kg has quit [Ping timeout: 250 seconds]
pyon has joined #ocaml
philtor has joined #ocaml
_5kg has joined #ocaml
zpe has joined #ocaml
zpe has quit [Ping timeout: 240 seconds]
jpdeplaix` has quit [Ping timeout: 250 seconds]
samrat has joined #ocaml
samrat has quit [Client Quit]
jpdeplaix` has joined #ocaml
ygrek has joined #ocaml
claudiuc_ has quit [Remote host closed the connection]
koderok has joined #ocaml
manizzle has quit [Ping timeout: 256 seconds]
tac-tics has joined #ocaml
tac_ has joined #ocaml
tac-tics has quit [Quit: Leaving]
tac_ has quit [Read error: Connection reset by peer]
tac_ has joined #ocaml
tac-tics has joined #ocaml
tac_ has quit [Remote host closed the connection]
tac_ has joined #ocaml
zpe has joined #ocaml
zpe has quit [Ping timeout: 256 seconds]
koderok has quit [Ping timeout: 240 seconds]
fantasticsid has joined #ocaml
Patchou has joined #ocaml
Tamae has quit [Ping timeout: 245 seconds]
orbitz has quit [Ping timeout: 250 seconds]
manizzle has joined #ocaml
orbitz has joined #ocaml
zpe has joined #ocaml
travisbrady has quit [Quit: travisbrady]
zpe has quit [Ping timeout: 240 seconds]
philtor has quit [Ping timeout: 245 seconds]
tac_ has quit [Quit: Leaving]
tac_ has joined #ocaml
samrat has joined #ocaml
<whitequark>
you need relocation then
jao has quit [Ping timeout: 250 seconds]
_whitelogger_ has joined #ocaml
deavidsedice has quit [Read error: Connection reset by peer]
deavid has joined #ocaml
pippijn has quit [Ping timeout: 256 seconds]
adrien has quit [Ping timeout: 256 seconds]
adrien has joined #ocaml
vbmithr_ has quit [Ping timeout: 260 seconds]
NoNNaN has quit [Ping timeout: 264 seconds]
bacam has quit [Ping timeout: 256 seconds]
patronus has quit [Read error: Connection reset by peer]
pippijn has joined #ocaml
bacam has joined #ocaml
vbmithr has joined #ocaml
Cypi has quit [Ping timeout: 272 seconds]
Cypi has joined #ocaml
axiles has joined #ocaml
NoNNaN has joined #ocaml
patronus has joined #ocaml
samrat has quit [Quit: Computer has gone to sleep.]
skchrko has joined #ocaml
siddharthv_away is now known as siddharthv
zpe has joined #ocaml
studybot has quit [Remote host closed the connection]
studybot has joined #ocaml
zpe has quit [Ping timeout: 264 seconds]
samrat has joined #ocaml
samrat has quit [Client Quit]
philtor_ has joined #ocaml
badon has quit [Ping timeout: 244 seconds]
badon has joined #ocaml
ggole has joined #ocaml
Guest46943 has quit [Quit: leaving]
Simn has joined #ocaml
tac_ has joined #ocaml
skchrko has quit [Ping timeout: 250 seconds]
skchrko has joined #ocaml
philtor_ has quit [Ping timeout: 245 seconds]
samrat has joined #ocaml
tac-tics has joined #ocaml
ygrek has quit [Ping timeout: 244 seconds]
siddharthv is now known as siddharthv_away
Hannibal_Smith has joined #ocaml
manizzle has quit [Ping timeout: 245 seconds]
<whitequark>
why does Obj.add_offset accept int32?..
manizzle has joined #ocaml
tac_ has quit [Ping timeout: 244 seconds]
azynheira has joined #ocaml
hhugo has joined #ocaml
Hannibal_Smith has quit [Quit: Sto andando via]
darroyo has quit [Ping timeout: 245 seconds]
azynheira has quit [Read error: Connection reset by peer]
azynheira has joined #ocaml
azynheira has quit [Read error: Connection reset by peer]
<def`>
design of the original ocaml abstract machine, it has been refined since but all the great ideas are there, it might help you understand the behaviors of closure and bytecode
<whitequark>
I see, thanks
<def`>
dsheets: I never realised that before, but it is not possible to expose exception rebinding in mli files
<whitequark>
companion_cube: no, they're not lambda-lifted
<whitequark>
at the point of closure creation, the upvalues are stuffed into the closure block
<whitequark>
which is, (code, up1, up2, ...)
<dsheets>
def`, hmm... w
skchrko has joined #ocaml
<dsheets>
def`, what Obj field should i grab for the unique id?
<def`>
exception are dynamic entities by nature, they are not subject to the restriction of always having a meaningful path like types
<def`>
dsheets: depends on whether you are on <=4.01 or 4.02
<def`>
4.01, they don't have unique ids. exceptions equality is computed by physical equality of their string tag
sagotch has quit [Remote host closed the connection]
<dsheets>
oh, right, that's... sad
<def`>
(exception declaration always allocate a string which value is the name of the exception, exception matching tests physical equality between strings)
<companion_cube>
whitequark: it's the same as lifting+partial application?
BitPuffin has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 245 seconds]
<dsheets>
try_with ~extract_exn:true is the magic invocation
<dsheets>
or the extract_exn function if you want to keep the extra Core/Async stuff
pootler has joined #ocaml
<dsheets>
wow... async really seems to bork the Unix_error path: "((filename ./bar))" vs "./bar"
darroyo has joined #ocaml
eikke__ has quit [Ping timeout: 245 seconds]
pootler has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
darroyo has quit [Ping timeout: 244 seconds]
<def`>
sexp ftw
thomasga has quit [Quit: Leaving.]
George__ has quit [Ping timeout: 246 seconds]
sagotch has joined #ocaml
_andre has joined #ocaml
tane has joined #ocaml
pango has quit [Ping timeout: 240 seconds]
typedlambda has quit [Ping timeout: 250 seconds]
typedlambda has joined #ocaml
eikke__ has joined #ocaml
<ggole>
Why would you lambda lift a closure? That would just require extra code to move everything into the arguments.
<ggole>
Better (not to mention simpler) to just access them directly.
nojb has joined #ocaml
<ggole>
Even worse, if you had many "arguments" you would end up taking a value from memory (in the closure) into a register and then putting back into memory (on the stack) and then taking it from memory again to use it.
darkf has quit [Quit: Leaving]
<whitequark>
companion_cube: um, what?
<whitequark>
I don't care what is it equivalent to, I care about specific representation
<companion_cube>
ah
<whitequark>
and in the specific representation there is no lifting or application
<companion_cube>
application is defined in C, I believe (caml_apply, caml_apply2...)
<companion_cube>
but the representation is the same as what lifting+apply would yield
<ggole>
Those are assembly iirc
<ggole>
Along with caml_tuplifyN
<companion_cube>
the n first arguments correspond to captured values
<whitequark>
the representation is not the same at all
<companion_cube>
hmm, how does partial application work then?
<whitequark>
at the site of partial application, a closure is created with code=caml_curryN and the arguments in environment
<pgomes>
Hi,
<pgomes>
Is there a smallfoot print ocaml that can be used in embedded systems ?
<companion_cube>
whitequark: oh. my bad then.
<companion_cube>
I thought partial application would just "push" values on the block until enough were present to actually execute the function
dsheets has quit [Ping timeout: 240 seconds]
<ggole>
If you left space in the block to be filled in like that, values from multiple invocations of the partially applied function would collide
<whitequark>
how would you resize the block upwards?
<whitequark>
also, that
<ggole>
Seems like checking would be slow, too
<companion_cube>
no, you'd copy the block
<companion_cube>
I didn't mean push on the original block
<whitequark>
that would be slow as hell
<companion_cube>
basically that must be "copy block + add values at its end" rather than making a linked list of blocks
<companion_cube>
whitequark: I don't know, you wouldn't have curryN
<whitequark>
and ?
<whitequark>
what benefit does lack of curryN have?
<companion_cube>
you only apply one function?
<companion_cube>
I don't see why it would be so slow
<ggole>
You need code to do the copying
<ygrek>
pgomes, yes, look for ocapic
<ggole>
Better to have it in one place in curryN
<companion_cube>
caml_apply should be responsible for doing the copying, I suppose
<whitequark>
okay, I need to study lambda_term
eikke__ has quit [Ping timeout: 240 seconds]
agarwal1975 has quit [Quit: agarwal1975]
<ggole>
companion_cube: er, what do you mean? AFAIK caml_applyN isn't involved in partial application.
<companion_cube>
I should stop saying nonsense
<ggole>
Well, the caml_fooN stuff is rather confusing
<companion_cube>
the point where the closure is applied to n arguments is where, somehow, the block should be copied and arguments added — unless enough arguments are present
<whitequark>
companion_cube: I'm not sure what gives you this idea. It's rather odd
<companion_cube>
f x y z ← if f waits for ≤ 3 args, apply it; otherwise copy f's closure block and add [x;y;z] to it
<companion_cube>
whitequark: the idea of copying closures?
nojb` has joined #ocaml
<whitequark>
yes
<ggole>
That's what caml_applyN already does, iirc
<companion_cube>
I don't know, it seems natural to me
<ggole>
But caml_applyN is only necessary for indirect calls: partial application of a known function can be more efficient
<companion_cube>
of course
<companion_cube>
if you know the function, you know how many arguments are missing
<ggole>
That's why we have both caml_curryN and caml_applyN, I think
<companion_cube>
so, if f is binary, f x y z would apply f to [x;y] directly, then apply (dynamically) the result to z
<companion_cube>
I think the only point where we diverge is how to represent a partially applied function
<ggole>
All (unknown) functions are represented the same way
<companion_cube>
i.e. one that lacks some arguments. You say list of blocks, I say one block+copy
<ggole>
Otherwise you wouldn't know how to call them
<companion_cube>
and if f is ternary, block2 would instead evaluate to (f x y z) directly
<ggole>
Actually that second one won't work
<ggole>
(Unless you do some expensive things at indirect call sites.)
<ggole>
The problem is that f needs to get all its arguments in the right places
<ggole>
There needs to be a fragment of code that takes the values from the block and places them in the registers in which f expects them before jumping to f
<ggole>
And (afaict) that's caml_curryN
<ggole>
so you have [caml_curry3; f; x; y; z]
<companion_cube>
I think that should be inlined at call site
<companion_cube>
depending on the arity of f
<companion_cube>
(should be immediate to check given f's block)
<ggole>
The call site doesn't know the arity
samrat has quit [Quit: Computer has gone to sleep.]
<ggole>
It knows the arity of the call, not the incoming function
<companion_cube>
well, you have n arguments y_1,...,y_m and a block [f/m,x_1,...,n_m]
<companion_cube>
err
<companion_cube>
n arguments y_1,...,y_m and [f/m,x_1,...,n_k] (k<m)
<ggole>
Yes, and it calls caml_applyN to handle the details
<companion_cube>
if n+k >= m, then you make a direct call
<companion_cube>
otherwise you build a new closure
<ggole>
That would be too much code at every unknown call site
<ggole>
You *could* inline, but you would lose for sure.
<companion_cube>
not sure: it's 3 way and you could call 3 routines depending on the case
<companion_cube>
1/ k+n < m, create a new block
<companion_cube>
2/ k+n = m, direct call without closure (fast)
<companion_cube>
3/ k+n > m, direct call + caml_applyN with (k+n-m) remaining args
<ggole>
What do you mean, direct call without closure? The closure is the thing you are invoking!
elfring has quit [Quit: Konversation terminated!]
<companion_cube>
yes, the direct call has to unpack the closure
<companion_cube>
but you don't have to worry about leftovers
<ggole>
I think we have a misunderstanding about the meaning of the term "direct call".
jbrown has joined #ocaml
jjwatt has quit [Remote host closed the connection]
<companion_cube>
yes sorry, you have to do some work before you jump to f
<companion_cube>
but it's something you have to do in any case
<companion_cube>
unpack x_1,...,x_k to registers/stack, as requested by f, then jump to f
BitPuffin has joined #ocaml
<ggole>
And alloc a block if the arity of f is greater
<companion_cube>
that is the case 3/
<companion_cube>
err, 1/
<companion_cube>
sorry
elfring has joined #ocaml
<ggole>
And then there's caml_tuplifyN, but nobody likes him.
<whitequark>
what does tuplify do?
<ggole>
Funcs on a single tuple take the elements of the tuple in registers
pango has joined #ocaml
<ggole>
A closure of that function has to know to unpack the incoming tuple into regs.
<ggole>
That's done by caml_tuplifyN
<whitequark>
oh, so f(x,y) is as fast as "f x y"? cool
<ggole>
Only if f is a known call
<ggole>
But yeah
<companion_cube>
so I still don't see why my way would be too slow :/
darroyo has joined #ocaml
<ggole>
You mean lambda lifting or the block copying stuff?
badon_ has joined #ocaml
badon has quit [Ping timeout: 250 seconds]
badon_ is now known as badon
<companion_cube>
copying the block
typedlambda has quit [Ping timeout: 250 seconds]
englishm has joined #ocaml
typedlambda has joined #ocaml
<ggole>
Well, I think copying is necessary in some cases
tac_ has joined #ocaml
agarwal1975 has joined #ocaml
<mrvn>
You can also build your functions starting with a header that unpacks from a block into regs followed by code that assumes args are already in regs and save both entry points. Then the compiler can pick the right entry point depending on local knowledge.
<mrvn>
or more entry points depending on how many args are already in regs (putting the last arg in r0)
<ggole>
How would you partially apply an unknown function?
<ggole>
You wouldn't know the entry points.
<ggole>
Although I guess you could fall back on the existing scheme in that case.
huza has joined #ocaml
<mrvn>
ggole: An unknown function is a closure, meaning a block with a pointer to the entry points, number of args needed and present and args. You either fill in more args or call one of the entry points.
tane has quit [Quit: Verlassend]
<ggole>
Knowing an entry point would not allow you to calculate another, so how would you "fill in more args"?
<mrvn>
if (have_args < need_args - stored_args) { args[stored_args++] = r0; args[stored_args++] = r1; ... up to have_args }
<mrvn>
actually, you have to copy the closure block because it has to be reusable
<ggole>
Right, and which code pointer do you give it?
<mrvn>
ggole: None. no code gets called. The new closure block keeps the same entry pointer table as the old one
<ggole>
I don't think that works
dsheets has joined #ocaml
<mrvn>
The interesting case if when applyN() gets called with enough arguments. Say (f x y z) gets called where f is a closure. Then you call f->entry[3] because 3 args are already in regs.
<mrvn>
s/if/is/
<mrvn>
The calling convention has to be such that applyN(f, x, y, z) has x, y and z in the regs a call to f expects.
<ggole>
Oh I see, a vector of entry points.
<mrvn>
ggole: yes.
<mrvn>
ggole: you need at least 2 entry points. One for copy all args and one for all args in regs. You can have more. Ocaml allows up to 5 args in regs so the vector wouldn't be large.
<ggole>
You would have to choose between copying it into every block or pointing at it, and I don't think either is really wonderful.
<ggole>
Should work though.
<mrvn>
ggole: you point to it.
<mrvn>
Youri: can also just point to the real entry point knowing that copying each arg offsets the entry by X bytes if the arch is that uniform
<mrvn>
s/Youri:/you/
<mrvn>
(why did I hit tab?)
<ggole>
I don't think you can, because there could be more arguments
<ggole>
(Unless the calling sequence checks for that.)
<mrvn>
ggole: if the application is partial you alway copy into a closure block.
<ggole>
Consider applying a function taking three args and producing a function that takes two args
<ggole>
You give it 5 arguments: f->entry[5] is not going to be valid
<mrvn>
ggole: then (have_args < need_args - stored_args)
<mrvn>
oh you mean (fun x y z -> ... fun a b -> ...)
<ggole>
Yeah
<ggole>
You could make it work
<ggole>
But it would still be a bit expensive
<mrvn>
In that case (have_args > need_args - stored args). Then you have to reshuffle.
<mrvn>
You need to store the 2 args, copy the 3 other args into the right regs, call entry[3], take the result and applyN(res, a, b)
<mrvn>
It's much easier if you only ever handle one arg for a function. Apply each argument one by one.
<mrvn>
(and so much slower)
<ggole>
Yeah
<ggole>
I think the existing scheme is pretty reasonable
tane has joined #ocaml
contempt has joined #ocaml
huza has quit [Quit: WeeChat 0.3.8]
eikke__ has joined #ocaml
jsvgoncalves has joined #ocaml
<mrvn>
it works. don't mess with it. :)
nojb` has quit [Ping timeout: 240 seconds]
contempt has quit [Ping timeout: 245 seconds]
shinnya has quit [Ping timeout: 272 seconds]
rand000 has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
tane has quit [Quit: Verlassend]
_0xAX has quit [Remote host closed the connection]
eikke__ has quit [Ping timeout: 272 seconds]
<sagotch>
I might be wrong, but a special annotation in comment before a function allow to hide some warnings. What is the syntax?
<pgomes>
Hi
<pgomes>
Is it possible to pass anotations to Emacs in order not to have to write the long compilation line all the time ?
Simn has quit [Ping timeout: 240 seconds]
NoNNaN has quit [Remote host closed the connection]
pango has quit [Ping timeout: 264 seconds]
samrat has joined #ocaml
englishm has quit [Remote host closed the connection]
englishm has joined #ocaml
englishm has quit [Remote host closed the connection]
englishm has joined #ocaml
pango has joined #ocaml
rand000 has quit [Quit: leaving]
<ggole>
pgomes: use a build system
contempt has joined #ocaml
travisbrady has joined #ocaml
contempt has quit [Ping timeout: 250 seconds]
contempt has joined #ocaml
pango has quit [Ping timeout: 260 seconds]
contempt has quit [Ping timeout: 250 seconds]
samrat has quit [Quit: Computer has gone to sleep.]
samrat has joined #ocaml
contempt has joined #ocaml
pango has joined #ocaml
<pgomes>
and call the makefile from the Emacs compile ?
<ggole>
Yeah. M-x compile has "make -k" as the default already.
<ggole>
Alternatively you could use ocamlbuild
<pgomes>
ok
<pgomes>
I thought I could just pick some annotations and pass it to emacs automagically
<pgomes>
in order to have the shortest compile-test cycle
<flux>
if you don't want to use a build system, just use a build.sh
<pgomes>
yeah
<flux>
ocamlbuild can work for simple programs without any configuration, btw
<ggole>
For simple cases ocamlbuild is very simple
<pgomes>
yeah ... let me try
<flux>
I suppose it would be cool if ocamlbuild, or something, was able to retrieve dependencies by mere reference to a module :-o
travisbrady has quit [Quit: travisbrady]
<pgomes>
that would be very nice!
<pgomes>
do a simple parsing and infer dependencies
<pgomes>
from it
<ggole>
That's what it does, for the most part
<flux>
but it doesn't infer -package dependencies
<ggole>
You'll have to tell it about packages though
<ggole>
Right.
<pgomes>
ok
<ggole>
Ah, that's what you meant
<pgomes>
basically yes :P
<flux>
it's not really that much trouble to work with, I think
<flux>
and it's not that easy problem to make automatic, considering the corner cases
<flux>
simple parsing won't do
<pgomes>
true
<pgomes>
"as simple as possible I meant"
<pgomes>
to be faithful to the KISS principle...
contempt has quit [Remote host closed the connection]
contempt has joined #ocaml
<def`>
but kiss is not a about automagic
<def`>
-a
<pgomes>
no, is about to keep it simple
<oriba>
How does labltk's entry_indexs look like? i did not found documentation of this type.
sagotch has quit [Remote host closed the connection]
mort___ has joined #ocaml
mort___ has quit [Client Quit]
ygrek has joined #ocaml
<companion_cube>
mrvn: looks like you think the same as me about closures
contempt has quit [Ping timeout: 250 seconds]
srax has quit [Quit: irc.frenode.net]
contempt has joined #ocaml
srax has joined #ocaml
eikke__ has joined #ocaml
George__ has joined #ocaml
samrat has quit [Quit: Computer has gone to sleep.]
contempt has quit [Remote host closed the connection]
contempt has joined #ocaml
travisbrady has joined #ocaml
eikke__ has quit [Ping timeout: 256 seconds]
jsvgoncalves has quit [Read error: Connection reset by peer]
contempt has quit [Remote host closed the connection]
samrat has quit [Quit: Computer has gone to sleep.]
hhugo has quit [Quit: Leaving.]
hhugo has joined #ocaml
rand000 has quit [Quit: leaving]
thomasga has quit [Quit: Leaving.]
jwatzman|work has joined #ocaml
samrat has joined #ocaml
tane has quit [Quit: Verlassend]
cthuluh has quit [Ping timeout: 245 seconds]
julm has quit [Ping timeout: 245 seconds]
pgomes has joined #ocaml
samrat has quit [Ping timeout: 250 seconds]
samrat has joined #ocaml
arjunguha has joined #ocaml
troutwine_away is now known as troutwine
Kakadu has quit [Quit: Page closed]
ollehar has quit [Quit: ollehar]
srcerer_ is now known as srcerer
oriba_ has quit [Quit: oriba_]
zarul has quit [Ping timeout: 255 seconds]
q66 has joined #ocaml
_0xAX has joined #ocaml
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
zarul has joined #ocaml
zarul has joined #ocaml
zarul has quit [Changing host]
arjunguha has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
locallycompact has quit [Ping timeout: 250 seconds]
arjunguha has joined #ocaml
thomasga has joined #ocaml
thomasga has quit [Quit: Leaving.]
troutwine is now known as troutwine_away
thomasga has joined #ocaml
dsheets has quit [Ping timeout: 255 seconds]
thomasga has quit [Client Quit]
thomasga has joined #ocaml
jao has quit [Remote host closed the connection]
thomasga has quit [Client Quit]
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
travisbrady has quit [Quit: travisbrady]
thomasga has joined #ocaml
George_ has quit [Quit: Page closed]
<whitequark>
match-with-exception is so great
* whitequark
is rewriting half of utop because it can't be wrangled into doing what he needs, and the other half because he doesn't like how it's written
hhugo has quit [Quit: Leaving.]
thomasga has quit [Client Quit]
<adrien>
2/lastlog btw
<whitequark>
adrien: hm?
thomasga has joined #ocaml
malo has quit [Remote host closed the connection]
thomasga has quit [Client Quit]
thomasga has joined #ocaml
thomasga has quit [Client Quit]
travisbrady has joined #ocaml
manizzle has quit [Ping timeout: 260 seconds]
<Drup>
whitequark: what do you want to do with it ? :p
<whitequark>
with what?
<Drup>
utop
<Drup>
(are you rewriting half of lambda-term too ? :D)
<adrien>
ergh
<adrien>
-ECHAN
<whitequark>
no, lambda-term is cool
<whitequark>
I've just finished reading all of it
<Drup>
yeah
<Drup>
I think it lacks a good manual
<whitequark>
although it does seem like it's just a part of utop, factored out
<Drup>
and widgets lack flexibility
<Drup>
oh yes clearly
<whitequark>
either way, lambda-term provides pretty much all I need
<whitequark>
except I don't see a way to disable the annoying completion box
<Drup>
oh, that's easy
<Drup>
1) don't use LTerm_readline.term, only readline
<Drup>
2) or put show_box at false.
<Drup>
(by inheriting)
<Drup>
lambda-term is build in a way that you inherit the widget you want to change and bake your stuff by overwriting methods
<whitequark>
oh, great, that worked
<whitequark>
I figured, yes
<Drup>
whitequark: I think LTerm_readline is old and wouldn't be rewritten like that with the current widget system
<Drup>
(and the widget system is *very* nice)
thomasga has joined #ocaml
<Drup>
whitequark: so, you didn't answer, why are you hacking utop ? :D
<whitequark>
Drup: the debugger thing
<Drup>
nice
<whitequark>
it needs a toplevel part
<whitequark>
but utop is 1) really not customizable
<whitequark>
2) about 40% of utop is working around various crap in pre-4.02
<whitequark>
like omg it duplicates half of error messages in the compiler WHY
<whitequark>
(why : the compiler didn't have Location.error_of_exn.)
<Drup>
and the code printer is not nice too
<whitequark>
yes, I want to make colorized input and output
<Drup>
it relex the output of the toplevel, or something
<companion_cube>
whitequark: so you're going to contribute back to utop?
<Drup>
it's quite .. ugh
<companion_cube>
or roll your own?
travisbrady has quit [Quit: travisbrady]
<companion_cube>
I'd love a utop with debugging included
<whitequark>
companion_cube: no, it's a separate project that is mostly a superset of utop
<whitequark>
it's really not mergeable into utop for various reasons, starting with the fact that I'm not going to support pre-4.02
<companion_cube>
but maybe utop's maintainers would be interested by the result
<companion_cube>
oh
<whitequark>
it's technically feasible, but a horrible pain in the ass
<Drup>
whitequark: I would advise you to do the same thing than me, for code coloration
<whitequark>
and it makes a codebase practically unmaintainable
<Drup>
(the bleeding eye thingy, you know what)
<whitequark>
um
<whitequark>
what?
<Drup>
Format+tags
thomasga has quit [Client Quit]
* companion_cube
guesses it's going to be a field testing of ppx_deriving
<whitequark>
oh
<whitequark>
Drup: nope, simpler
<whitequark>
I'll just lex the code and colorize it according to tokens
<Drup>
ok, so like utop
<Drup>
(it's not really simpler, in fact)
<whitequark>
hm
<Drup>
(because it doesn't do formatting)
<whitequark>
yes, sorta like utop
<whitequark>
Drup: so I would need that for three things
_0xAX has quit [Remote host closed the connection]
<Drup>
(let me reformulate : it's horrible to do formatting with this method)
<whitequark>
what do you mean by "formatting" ?
<whitequark>
indents and so?
<Drup>
yes
<whitequark>
uh, I definitely won't going to ident like that
<whitequark>
I'll start Pprintast initially
<whitequark>
and if it's too horrible--I heard it is--I'll just rewrite it properly
<whitequark>
but pretty-printer and colorizer will be just separate.
<Drup>
and you will use Format :p
<whitequark>
sure ?
<Drup>
unless you want to rewrite a boxing model for ascii
<Drup>
but seriously, I wouldn't do that
<whitequark>
I don't think Format is bad
<jerith>
Format is nice.
<whitequark>
it's sorta quirky, but it's very usable
<Drup>
right, so you will use the tag thingy, because it plugs into Format directly :3
<whitequark>
why would I want to use tag thingy?
<Drup>
to color the code !
<whitequark>
I have no desire to manually mark every keyword with the keyword tag or something
<Drup>
bah, we will see
Kakadu has joined #ocaml
<whitequark>
I'll just lex the string, get the token locations, and then put the relevant attributes in LTerm_text.t
<whitequark>
like utop does the underline thing
<whitequark>
you will recognize my brilliance, in time
<Drup>
:p
<whitequark>
:p
<companion_cube>
val whitequark [@@brilliant]
<Drup>
gasche is on a merging spree
<whitequark>
did gasche return from a vacation or something?
<Drup>
he just closed 5+ PR on the ocaml repo, so, I guess ?
philtor_ has joined #ocaml
<whitequark>
hhaahhaha, his commit comments are awesome
<whitequark>
"Using Obj.magic to convert between functions would give a very bad example to users considering a migration, which are very quick to imitate any moral turpitude found in the standard library."
<wieczorek>
but they have a bitstring library, which is popular and usable.
<whitequark>
what does the bitstring library do?
<wieczorek>
bytestring*
<whitequark>
oh
<Drup>
Wieczorek: why "not batteries" by the way ?
<Drup>
(just pure curiosity)
<wieczorek>
I used batteries in my last project. After some time I started to see batteries as tricky hack to extend standard library in ,,nice way''.
<wieczorek>
I found some problems, especially when I was using io.
<whitequark>
Drup: I wonder if a toplevel should display warnings
<Drup>
it's ... not false.
<Drup>
batterie's IO is horrible :/
<wieczorek>
Maybe it is easy for someone who is familiar with batteries, but when I found a conflict between channel type from stdlib and from batteries
<wieczorek>
then i really had not idea what should I do.
<wieczorek>
Did anyone use a Core library?
cody__ has joined #ocaml
<Drup>
whitequark: I'm not sure
<wieczorek>
any good feelings?;]
BitPuffin has quit [Ping timeout: 240 seconds]
<Drup>
I have mostly bad feelings about Core's *documentation*
<whitequark>
Wieczorek: Core is nice in a lot of respects, but it sometimes feels bloated and underdocumented
<wieczorek>
eh.
<Drup>
no feeling about the library, since I don't use it, since there is no documentation.
<whitequark>
Drup: harsh.
<wieczorek>
Ok, so I am not going to use it ;]
<Drup>
yes.
<whitequark>
Wieczorek: I would recommend you to try.
<Kakadu>
Wieczorek: Core uses labeled arguments a lot. Most people don't like it but I do
<Drup>
kakadu: actually, I like this part
<Kakadu>
btw, do we have labeled version of batteries?
<Drup>
I think most modules have a Labeled version
<wieczorek>
kakadu: in the latest version of batteries I saw a labeled versions of some modules.
<wieczorek>
kakadu: I also like labelled arguments.
<whitequark>
Drup: I don't use Batteries because of the smurf syndrome, mainly
troutwine_away is now known as troutwine
<wieczorek>
I would like to see labelled variant constructors.
<jerith>
Is there ever any reason to not have labeled arguments?
<whitequark>
jerith: currying
<jerith>
Can't you do that with labels?
<Drup>
currying ?
<whitequark>
there's something broken
<Drup>
no, not with currying
<whitequark>
which is why we have separate List and ListLabels
<wieczorek>
Type deduction is not nice sometime.
<wieczorek>
For example
<jerith>
Ah.
<Drup>
there is something broken with high order functions, though
<wieczorek>
well, maybe it is not strictlyu related to type deduction, but .. you will choose better name when I write example
<Drup>
if your function except something of type foo -> bar
<wieczorek>
module type Driver = sig val f : ~foo:string -> int end
<Drup>
you can't give something of type ~bla:foo -> bar
<wieczorek>
no
<wieczorek>
module type Driver = sig val f : string -> int end
<wieczorek>
real_f : ~foo:string -> int
<wieczorek>
module RealDriver : Driver = struct
<wieczorek>
(*do not work*) let f = real_f
<wieczorek>
(*work*) let f x = real_f x
<Drup>
( whitequark : more seriously, ignoring the bloat factor, which is quite annoying too, the documentation is really the main reason for me to disregard Core)
<wieczorek>
end
<wieczorek>
btw: I found one think in the Batteries library which was wonderful try for me
<Drup>
whitequark: what is the smurf syndrome, in the case of batteries ? :D
<wieczorek>
the BatEnum, trying to produce iterators for containers.
<whitequark>
Drup: bat_bar BatFoo.bat_foo
<whitequark>
fffuuuuuu
<Drup>
bat_foo ? where ?
<Drup>
BatFoo, yes, sure
<whitequark>
well, not bat_foo
<whitequark>
but BatFoo, yeah, screw that
<Drup>
oh, come on !
samrat has quit [Quit: Computer has gone to sleep.]
<Drup>
whitequark: there is an ocaml thing instead of a gem, to encode keys
<companion_cube>
when I release, i have a Makefile target to update the doc
<jerith>
But I've only done that for Python stuff, which is really easy with Sphinx.
<companion_cube>
it's pretty simple
<whitequark>
Drup: I have the gem though
<wieczorek>
Drup: what is a difference between L-system and context-free grammar?
rgrinberg has joined #ocaml
<Drup>
the difference is subtle, but the class of recognize languages is different
<wieczorek>
I see that there are not partition to terminals and variables.
<Drup>
there is
<wieczorek>
hm
<Drup>
when you look at some recognized word, with a context free grammar, you can obtain a new recognized word by replacing *one* token by the rhs of the corresponding rule
<wieczorek>
jerith: nice project
<Drup>
with a Lsystem, you can't replace *one* token, you have to replace *every* token of the word
<wieczorek>
Hm
troutwine_away is now known as troutwine
<jerith>
Wieczorek: Thanks. I still need to rewrite all the code I wrote a couple of weeks ago when I didn't know OCaml very well.
manizzle has joined #ocaml
<Drup>
basically, it makes all variations of +_i=1..k (u_i)^n trivial to recognize
<wieczorek>
I will study definition later.
<wieczorek>
Anyone know what is planned for next release of ocaml?
<Kakadu>
there is a changelog
<Kakadu>
in 4.02 branch
<Drup>
lot's of cool stuff :D
arjunguha has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<wieczorek>
I was thinking about something in this style, but of course I was thinking about big picture, not about details and how it really should look like.
<wieczorek>
Ok, are authors working on it?
<wieczorek>
Oh 2014, it is fresh.
<ggole>
I wouldn't mind abstraction over patterns
<wieczorek>
what it means?
<ggole>
That instead of writing the same pattern with slightly different parts, you can name it once and pass the different bits as arguments.
<wieczorek>
(I also would like to have better thread-support on ocaml --- yes I know what is a LWT and I understand the difference between concurrency and paralellism, I like concurrency, but still, I would like to have real threads).
thomasga has joined #ocaml
<wieczorek>
ggole: something like this?:
<wieczorek>
let f n = function | MyVariant(@n, m) -> n+m
<wieczorek>
?
<whitequark>
ggole: you can do that with ppx!
elfring has quit [Quit: Konversation terminated!]
<wieczorek>
ppx = camlp4?
<whitequark>
no, it's the replacement for camlp4
troutwine is now known as troutwine_away
<ggole>
whitequark: hmm, could you use things across module boundaries?
<Drup>
whitequark: it would be better baked into the language
<wieczorek>
But I don't see influence from ocaml industry.
<jerith>
Core?
<wieczorek>
and I see a bad influence from some weird world.
<whitequark>
Wieczorek: there's plenty of very high-quality OCaml projects written by lone developrs, too
<whitequark>
for example, dbuenzli
<whitequark>
his code is probably among the best in whole ecosystem
<wieczorek>
whitequark: I am not telling that each project must be bad written because it is in ocaml, of course it would be silly.
<whitequark>
and you have clearly never seen e.g. nodejs or ruby libraries
<wieczorek>
but I am trying to speak about some tendency.
<wieczorek>
oh
<whitequark>
because it is a cesspool basically
<wieczorek>
and new think in ocaml
<Drup>
Wieczorek: Also, your vision of the industry is a bit .. idyllic, I think
<wieczorek>
some convension that values started by prefix _ are local.
<wieczorek>
when I saw this I started to thinking that I am writing in java script.
<Drup>
what's wrong with this convetion ?
<wieczorek>
It is convension, not the language feature.
<Drup>
it's actually a language feature
<Drup>
it disables the warning
<wieczorek>
And it is exactly what makes me angry.
<Drup>
why ?
<jerith>
I tend to use _foo instead of _ when it's useful to name the thing I'm ignoring.
<wieczorek>
Because NAME of variable drives the language behaviour
<wieczorek>
it is like assuming that all arguments prefixed by int_ must have the int type
<Drup>
and ? it's done in lot's of langages
<wieczorek>
In java script>
<wieczorek>
?
<wieczorek>
I would prefer to see for example
<wieczorek>
private let x = ...
<wieczorek>
not let _x =
<ggole>
Er, what?
<ggole>
_foo indicates an unused variable by convention
<Drup>
Wieczorek: it's not private
<jerith>
How would that work for "let foo, _bar, baz = ..."?
<wieczorek>
jerith: dunno
<wieczorek>
Drup: what means it is not private?
<Drup>
Wieczorek: it's ignored, not private
<ggole>
If you want things to be hidden then write a .mli (or use scoping, or whatever).
<wieczorek>
Drup: what it means it is not private.
<Drup>
it has nothing to do with privacy
thomasga has quit [Quit: Leaving.]
<wieczorek>
[why I am not chaning verb order in questions? eh]
<wieczorek>
[why am I not changing the order of verb in questions? eh]
<wieczorek>
SO maybe I do not understand
<jerith>
Wieczorek: I think it's a Polish grammar thing.
<wieczorek>
what means _foo ?
<Drup>
Wieczorek: _foo is a variable that is, by convention, not used, but named for ease of reading
* companion_cube
tends to name _foo functions that are not exported
<Drup>
additionally, it silences the warning about unused variables
<jerith>
Wieczorek: The _ prefix suppresses the unused variable compiler warning.
<companion_cube>
and by default such functions in a .ml aren't exported
<wieczorek>
Ok, it is not included in interface, it is what I understood as private.
<wieczorek>
So I do not agry that it is a good feature.
<companion_cube>
it's a mere detail?
<Drup>
Wieczorek: nothing to do with interfaces
<wieczorek>
It is like hardcode in hindley-milney system unification, that all type variables which start with 'int_' should unify with int. Madness.
<Drup>
beh
<ggole>
Eh? _foo isn't exported?
<jerith>
Wieczorek: It's not like that at all.
<Drup>
ggole: _foo is exported if you want it
<orbitz>
Can I include a module in a sig?
<companion_cube>
orbitz: you mean the type of a module?
<ggole>
Is this at .ml level or for structures too? I'm not seeing the behaviour.
<companion_cube>
include module type of Foo
<Drup>
ggole: this behaviour doesn't exists
<ggole>
...
<ggole>
Oh, I see
<wieczorek>
so
<wieczorek>
_prefix supress only warning?
<Drup>
yes
<wieczorek>
Ok
<wieczorek>
Okey, I could accept this.
<orbitz>
companion_cube: I have a functor and i want to do module Foo : sig include FunctorArg.Foo end
<Drup>
Wieczorek: and the source of this convention is the fact that "_" is the ignore pattern
jao has quit [Ping timeout: 245 seconds]
<wieczorek>
Ok, I can tolerate this.
<Drup>
so if you pattern match "Foo (bla, _ , blo)"
<wieczorek>
but before real acceptance I need to take some days :D
<Drup>
x)
<wieczorek>
pff
<wieczorek>
I feel much better that I does not work as I previously think.
<Drup>
Wieczorek: there are lot's of convetion and naming stuff in ocaml, you just don't know them yet
<wieczorek>
I feel much better that it does not work as I previously think.*
<wieczorek>
Could you give me another example of common convention?
<Drup>
but the ocaml community is less vocal about "how you should do it™" than other communities (like Python, to name one)
<companion_cube>
module Foo = struct let x = 1 let _y = 2 end ;; ← doesn't export _y
<Drup>
really ? O_o
<companion_cube>
orbitz: module type of
<ggole>
Does here?
<ggole>
module Foo : sig val x : int val _y : int end
<Drup>
companion_cube: fuck, this is ugly X_x
<wieczorek>
Drup: hehehehe
englishm has quit [Remote host closed the connection]
<wieczorek>
Ok, so I feel like java script programmer.
<companion_cube>
ggole: I get module Foo : sig val x : int end
<ggole>
companion_cube: which version?
<companion_cube>
4.01
englishm has joined #ocaml
<ggole>
4.02 and a bit here... wonder if it changed.
<Drup>
Wieczorek: why javascript ? :p
<wieczorek>
Drup: I see JS as nightmare
<wieczorek>
# module Foo = struct let x = 1 let _y = 2 end ;;
<wieczorek>
module Foo : sig val x : int val _y : int end
<companion_cube>
OCaml doesn't have anything to do with javascript
<wieczorek>
I did not understand something
<wieczorek>
_y is exported
<wieczorek>
OCaml version 4.01.0
<ggole>
4.01.0 gives the same behaviour, wtf?
<companion_cube>
I'm on utop
<ggole>
Is this some camlp4 nonsense?
<ggole>
Ah
<Drup>
something is wrong =__=
<ggole>
That could be it
englishm has quit [Remote host closed the connection]
<companion_cube>
ok
<companion_cube>
it doesn't display it
<companion_cube>
but ._y is reachable
<ggole>
...huh
<Drup>
ok
<Drup>
burn utop :O
<companion_cube>
:D
<wieczorek>
I confirm, Utop don't want to show _y
<ggole>
That's kind of pushy of utop
<wieczorek>
utop # module Foo = struct let x = 1 let _y = 2 end ;;
<wieczorek>
module Foo : sig val x : int end ─( 21:36:51 )─< command 1 >─────────────────────────────────────────────────────────────────────────────{ counter: 0 }─utop # Foo._y;;
<companion_cube>
ok, I was confused because of utop then
englishm_ has joined #ocaml
<ggole>
Deciding which bindings you get to see
<wieczorek>
- : int = 2
<wieczorek>
I would never expect that toplevel would decide what you want to see.
<wieczorek>
what do you want to see*
<Drup>
give me a sec, bug report time.
<wieczorek>
;]
MercurialAlchemi has joined #ocaml
<ggole>
(btw, opam switch ♥)
<wieczorek>
I very like utop
<wieczorek>
but it's bindings are not compatible with xterm ;[
<Drup>
Wieczorek: you can customize them !
<Drup>
(feature not very documented)
Trollinator has joined #ocaml
<wieczorek>
Yes, but I am too lazy, I would rather to blame utop.
<wieczorek>
Drup: do you have more interesting papers?
<Trollinator>
you're lazy? Like, a thunk or something?
<wieczorek>
Yes, like thunk.
<wieczorek>
If I would have a configuration for utop, I would store them and use in future.
<wieczorek>
If I would do a configuration for utop, I would store them and use in future.*
<wieczorek>
Drup: could you aggregate interesting papers on some web-page? I know that people are pushing many stuff to reddit and other stuff. But I cannot use reddit, twitter, facebook. I am compatible with old internet only.
papna has joined #ocaml
<wieczorek>
Drup: but I would like to see some fresh papers related to ocaml
<Drup>
# module type Foo = sig val x : int val _y : int end ;;
<whitequark>
pgomes: it really depends on use case
<whitequark>
for general purpose applications, they're comparable
<pgomes>
Yes, that was basically my question ...
<whitequark>
if you do something like intensive graphics processing, then well-written C++ will be far ahead
<wieczorek>
pgomes: If you want to write algorithms for contests, then you should not use ocaml unless you are very good at ocaml.
<pgomes>
in the overall ... you got more or less the same performance ...
<pgomes>
no contest ...
<pgomes>
production code
<Drup>
actually, for contest, it depends a lot
<pgomes>
contests are for Misses:P
<whitequark>
there's no parallelism (instruction-level or thread-level) in OCaml, the compiler is not as aggressive at optimizations, and you can't do your own memory-management
<whitequark>
but for the vast majority of applications that doesn't matter
<wieczorek>
But what your production code needs to do?
<wieczorek>
pgomes: for example in my work we are producing control-plane for LTE BTS, and we don't have big ,,code performance'' constraints which forces us to use fastest language in the world.
<companion_cube>
then it should be fine
<wieczorek>
pgomes: of course we use C++, but I could see ocaml here
<Drup>
(most people don't)
<whitequark>
Wieczorek: oh wow, LTE BTS
<whitequark>
not at ST-E by any chance?
<pgomes>
Really in EMBEDDED systems?
<wieczorek>
Well, maybe some call BTS an embedded system
<wieczorek>
but it is not a microchip which runs on freezer
<pgomes>
its maybe a raspberry pi alike ...
<wieczorek>
it is a not slow hardware which run linux, and we produce code for linux.
<wieczorek>
on control-plane
<pgomes>
I am asking this because I work with embedded telecoms eq.
<Drup>
hard realtime is complicated because GC
<whitequark>
if you use linux userspace, you've already lost on hard-RT
<pgomes>
Not all parts need to be hard real time
<pgomes>
only for example traffic protection
<pgomes>
and we could put that into kernel no?
travisbrady has joined #ocaml
<pgomes>
kernel space driver
<whitequark>
there is linux-RT, but it's basically a kernel module that runs in very tight constraints even for a kernel module
troutwine_away is now known as troutwine
<pgomes>
yea there are real time extensions for linux
<wieczorek>
writing driver for kernel in high level language? Forgot this idea.
<Drup>
pgomes: on top of mirage
<pgomes>
no no
<Drup>
that would be so *awesome*
<whitequark>
Wieczorek: you can do that in Rust.
<pgomes>
no .. have the userspace glue to the driver in Ocaml
<whitequark>
and still actually have hard-RT constraints if you want!
<wieczorek>
whitequark: I will check it
locallycompact has joined #ocaml
<wieczorek>
What do you understand by hard-RT constraints?
<pgomes>
50ms protection evens
<pgomes>
events for example
<wieczorek>
I don't believe that any time-sharing system like any unix can be real hard-real-time os
<wieczorek>
because time-sharing and hard-real-time is not compatible.
<whitequark>
Wieczorek: Rust as a language does not have a runtime or GC that forces nondeterminism on you
<pgomes>
butof course
<whitequark>
well, QNX is a time-sharing system with hard-RT constraints, no?
<wieczorek>
soft-RT
<whitequark>
ah, I see
<pgomes>
Soft maybe ... Like you have with Erlang
<whitequark>
anyway, what I really mean is that in Rust, everything is expressible that is expressible in C
<whitequark>
and also much more
<whitequark>
which makes it awesome
<wieczorek>
I think that hard real-time when we have a real constraints, like something bust be handled in less than 0.5s because people die.
<pgomes>
and it is not even the time scale
<wieczorek>
For example human-detector in factory signals that someone enters restricted are and some robot-arm should be stopped very fast.
<companion_cube>
whitequark: actually I'm surprised, why didn't you go to rust rather than ocaml? :)
<whitequark>
hard-RT is when the system not responding in time results in system failure
<whitequark>
soft-RT is when not responding in time results in quality of service degradation
<pgomes>
is the rigour to which everything is stopped to attend the the "real time"
<whitequark>
it isn't really related to people dying or something
<pgomes>
so we know that that priority stuff will be handled no matter what is running
<whitequark>
companion_cube: 1) OCaml works for twenty years and will work for twenty years more
<wieczorek>
whitequark: you have right, but it is good use case for me
_andre has quit [Quit: leaving]
<wieczorek>
why we need this distinction.
<whitequark>
2) Rust is a systems programming language more than an application one
<wieczorek>
and why QNX and rest does not fullfill this requirements.
<whitequark>
I don't want the region fuckery when I just want to concatenate lists
<wieczorek>
hehehe
<companion_cube>
I'm not so sure, rust might be suitable for higher level applications
<wieczorek>
------------------------------------
<wieczorek>
Maybe we should focus on pgomes
<ggole>
Yeah, structural sharing seems to be an issue
<companion_cube>
especially if you use GC pointers and such
<pgomes>
no no
<whitequark>
companion_cube: it totally is
<pgomes>
I was explaining my point :P
<whitequark>
but it is in my view not the best language for stuff like web backends
<whitequark>
because it strives to provide a lot of complex machinery which is basically unused there
<companion_cube>
why not? it's going to have a lot more libraries than Ocaml, I believe
<whitequark>
and it gets in the way.
<wieczorek>
Drup: I have another question
<whitequark>
I'm not convinced webdev without GC is convenient
<wieczorek>
Drup: is there any tutorial how to use debugger in ocaml? I found that there is debugger, but I dont know if it is usable and how to use it.
<whitequark>
Wieczorek: it is absolutely terrible
<wieczorek>
Drup: and I wonder if there exists good debugger for FP
<pgomes>
ahahah
<whitequark>
in fact it is terrible enough that I don't call it a debugger
<whitequark>
and I'm writing a good one right now
<wieczorek>
Drup: I used a debugger in Haskell's ghci and it was hardly-usable
<wieczorek>
hehehehe
<whitequark>
but that will take some time
<wieczorek>
I expected this opinion :D
<wieczorek>
whitequark: Could I help you? I am familiar with low-level stuff related to asm/OS
<whitequark>
Wieczorek: I already figured out most of low-level things
<whitequark>
and, I'm familiar with it too :p
<ggole>
How can you say the debugger is terrible? It has time-travel!
<wieczorek>
Ok, and could I help you?
* ggole
never uses it
<whitequark>
Wieczorek: probably not, it's a job for a single man
<wieczorek>
whitequark: OK, I will start competitionary project.
<wieczorek>
only because you dont wanted me in your team
<pgomes>
:P
<whitequark>
*facepalm*
<Drup>
solo developer, in ocaml's farewest, a duel between him and the desert.
<wieczorek>
and I will write debugger for ocaml in Haskell
<pgomes>
:-)
troutwine is now known as troutwine_away
MercurialAlchemi has quit [Ping timeout: 250 seconds]
<wieczorek>
Ok
<wieczorek>
I am going out here
<wieczorek>
thanks for discussions and your time
<wieczorek>
see you
hhugo has joined #ocaml
wieczorek has quit [Quit: leaving]
shallow is now known as potlesk
hhugo has quit [Quit: Leaving.]
<pgomes>
bye
<pgomes>
thanks a lot :P
pgomes has left #ocaml ["Leaving"]
malo has joined #ocaml
MercurialAlchemi has joined #ocaml
BitPuffin has joined #ocaml
Trollinator has quit [Ping timeout: 244 seconds]
Mercuria1Alchemi has joined #ocaml
AltGr has left #ocaml [#ocaml]
axiles has quit [Remote host closed the connection]