<thelema>
there's probably a better way involving the Print module and its associated camlp4 magic, but that's what I use at the moment
<alexyk>
nice, thx!
jakedouglas has quit [Quit: Leaving.]
ulfdoz_ has joined #ocaml
ulfdoz has quit [Ping timeout: 240 seconds]
ulfdoz_ has quit [Quit: Reconnecting]
ulfdoz has joined #ocaml
alexyk has quit [Quit: alexyk]
alexyk has joined #ocaml
alexyk has quit [Client Quit]
jeddhaberstro has quit [Quit: jeddhaberstro]
ttamttam has joined #ocaml
joewilliams is now known as joewilliams_away
Amorphous has quit [Ping timeout: 248 seconds]
ygrek has joined #ocaml
ulfdoz has quit [Ping timeout: 260 seconds]
Amorphous has joined #ocaml
aja has quit [Read error: Connection reset by peer]
ftrvxmtrx has quit [Quit: Leaving]
ygrek has quit [Ping timeout: 245 seconds]
filp has joined #ocaml
oriba has joined #ocaml
oriba has quit [Remote host closed the connection]
Yoric has joined #ocaml
Associat0r has joined #ocaml
Yoric_ has joined #ocaml
Yoric has quit [Ping timeout: 240 seconds]
Yoric_ is now known as Yoric
Yoric has quit [Remote host closed the connection]
Yoric has joined #ocaml
itewsh has joined #ocaml
th5 has joined #ocaml
Snark has joined #ocaml
ygrek has joined #ocaml
rossberg has joined #ocaml
ftrvxmtrx has joined #ocaml
valross has quit [Quit: Ex-Chat]
infoe has quit [*.net *.split]
coucou747 has quit [*.net *.split]
infoe has joined #ocaml
coucou747 has joined #ocaml
chee has quit [Quit: <3 =^.^= ?>]
chee has joined #ocaml
Edward__ has joined #ocaml
chee has quit [Quit: <3 =^.^= ?>]
_andre has joined #ocaml
thrasibule has joined #ocaml
seafood has quit [Quit: seafood]
ftrvxmtrx has quit [Remote host closed the connection]
ftrvxmtrx has joined #ocaml
munga has joined #ocaml
seafood has joined #ocaml
seafood has quit [Quit: seafood]
seafood has joined #ocaml
thrasibule has quit [Ping timeout: 240 seconds]
munga has quit [Quit: Ex-Chat]
fraggle_laptop has quit [Ping timeout: 240 seconds]
seafood has quit [Ping timeout: 260 seconds]
mbishop has quit [Ping timeout: 260 seconds]
f[x] has quit [Ping timeout: 252 seconds]
mbishop has joined #ocaml
adrien has quit [*.net *.split]
LionMadeOfLions has quit [*.net *.split]
hcarty has quit [*.net *.split]
ygrek has quit [Ping timeout: 245 seconds]
hcarty has joined #ocaml
adrien has joined #ocaml
struktured has joined #ocaml
f[x] has joined #ocaml
ygrek has joined #ocaml
filp has quit [Quit: Bye]
iratsu has quit [Ping timeout: 240 seconds]
fraggle_laptop has joined #ocaml
iratsu has joined #ocaml
ikaros has joined #ocaml
iratsu has quit [Ping timeout: 248 seconds]
iratsu has joined #ocaml
ztfw has joined #ocaml
ccasin has joined #ocaml
iratsu has quit [Ping timeout: 240 seconds]
kaustuv has joined #ocaml
<kaustuv>
Batteries 1.2.1 does not compile with OCaml 3.12.0+dev27. Is this expected?
<kaustuv>
Also, what does 'EOI' in this Camlp4 error mean?
<kaustuv>
Parse error: EOI expected after [quotation of type] (in [quotation of type])
<flux>
my guess: end of input?
<flux>
the syntax extensions, if batteries still uses them, have issues with 3.12.0
<kaustuv>
How do I compile Batteries without the syntax extensions?
iratsu has joined #ocaml
ttamttam has quit [Remote host closed the connection]
julm has quit [Read error: Operation timed out]
fremo__ has quit [Read error: Operation timed out]
julm has joined #ocaml
<flux>
patch src/_tags and comment the relevant line out?
ygrek has quit [Ping timeout: 245 seconds]
fremo__ has joined #ocaml
<mfp>
kaustuv: see http://git.debian.org/?p=pkg-ocaml-maint/packages/ocaml-batteries.git;a=blob;f=debian/patches/0002-Fix-build-with-OCaml-3.12.0.patch;h=a90b5127e9655bea7fabe0f895b0e37a55103de4;hb=4a877df96fb54e9b4d38b16db3775ccad4c12abf
<kaustuv>
Apparently it was easier to remove syntax.otarget in the Makefile
<kaustuv>
mfp: thanks, but I would rather live without any camlp4 anyhow. Has this been reported upstream?
<sdschulze>
"But the real challenge is with the SML module system, especially functors and type abstraction in structures, [...]. Here monomorphisation does not appear viable [...]."
<sdschulze>
Can someone elaborate on this?
<sdschulze>
And how can the types in a static programming language be statically unknown?!
<sdschulze>
in a programming language with static typing, that is
<flux>
hmm
<flux>
you are familiar with how polymorphicity works in ML in general, or am I misunderstanding that?
<sdschulze>
I am -- though not so much in the implementation, but a bit in programming language theory.
<flux>
maybe it just refers to on how to separately compile type 'a r = { field: 'a } let apply f a = f { field = a } or possibly some even simpler situation
<flux>
(I didn't read the paper ;-))
ikaros_ has joined #ocaml
<sdschulze>
flux: I'm almost only referring to the paragraph on top of the 2nd column on the 1st page.
<flux>
oh
<flux>
well in that case I'm pretty sure that that's what it's referring to
<flux>
if you have record r represented unboxed in memory, you need to compile a version of apply to each different type
<flux>
not so with uniform (untyped) data representation
<flux>
if it's not that clear with a record, consider let apply_2nd f array = f array.(1)
ikaros has quit [Ping timeout: 265 seconds]
<flux>
basically the way to cope with that is what c++ does with templates..
<flux>
but it has its downsides
<sdschulze>
Yeah, but he says that monomorphisation is usually not a problem.
<sdschulze>
And I naivle don't see any obstacle to monomorphising your code.
sepp2k has quit [Ping timeout: 260 seconds]
<sdschulze>
*naively
<flux>
sure, it can be monomorphised
<flux>
but you basically need something akin to a whole-program compiler to do it, no?
<sdschulze>
Is it that what he's referring to?
<sdschulze>
that I can write a type signature with type variables
<sdschulze>
I.e. those language structures themselves are not the problem, but the fact that they can be compiled seperately?
<flux>
that is how I understand it. the statement that the types of some values aren't known at compile-time seems rather dubious otherwise to me.
<flux>
maybe you can ask him about it :)
<sdschulze>
It's confusing me because this sounds like a rather small problem.
<sdschulze>
whereas the price paid (i.e. boxing) is quite high
<flux>
afaik only mlton does that
<flux>
but perhaps other such compilers exist
<sdschulze>
does what?
<flux>
something similar happens in the F# in .NET, apparently
<flux>
does whole-program compilation and has everything unboxed
<sdschulze>
And, is it faster?
<sdschulze>
The other issue he mentions is that the GC doesn't like unboxed data at all.
<flux>
well, it can be faster when a lot of abstraction exists
<flux>
apparently ocaml's codegen is pretty nice, though, even though it isn't really optimizing
<flux>
perhaps the language shootout can give some idea :)
<sdschulze>
If the more complex GC slows it down, then there's no win.
<sdschulze>
What disappoints me in the shootout is that the system they use doesn't hit the physmem limit.
<sdschulze>
That's why Java performs so well.
<sdschulze>
If I take the OCaml example programs and do some GC tuning, the results get similar.
<sdschulze>
But that's cheating, according to the rules.
sepp2k has joined #ocaml
<sdschulze>
Maybe we should fork OCaml to OCaml-shootout, which occupies more mem by default... :)
<hcarty>
sdschulze: There was a recent blog post about OCaml GC tuning for improved performance...
<flux>
well, I think it would be relatively fair to have a separate ocaml-tuned-gc "language" there
<sdschulze>
If you have -- like me -- only 1 GB of RAM, you will be quite happy with OCaml's standard settings.
<flux>
I was under the impression they are much more traditionally
<flux>
+set
<sdschulze>
The binary-tree benchmark is horribly slow with standard settings.
<flux>
I once wrote a program (that ran on on a pentium 200MHz) that basically discarded everything 30 times per second
<flux>
adjusting GC turned to be a good idea
<sdschulze>
You can watch it getting faster and faster if you give it more mem.
<sdschulze>
Every programmer should at least know that it exists.
<sdschulze>
But back to my original question -- so if I did whole-program optimization and, say, had a reference-counting GC, I could have a completely unboxed program?
<sdschulze>
("unboxed" in the sense of "no type annotations and/or generic code" then)
<sdschulze>
There seems to have been a lot of research on reference counting, recently.
<sdschulze>
There are efficient algorithms for finding reference cycles without the need for a tracing GC.
Yoric has joined #ocaml
<flux>
quite an old paper that was
<flux>
I wonder if things have changed. apparently GHC has a nice GC, that doesn't require tags.
<sdschulze>
I understand the nature of that problem, at least.
<sdschulze>
The GC somehow needs information on what kind of data something is.
<sdschulze>
flux: Do you know about MLton's GC?
ttamttam has joined #ocaml
Ppjet6 has joined #ocaml
<flux>
sdschulze, no
Ppjet6 has quit [Client Quit]
Snark has quit [Quit: Ex-Chat]
ztfw has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]