braibant has quit [Read error: Connection reset by peer]
braibant has joined #ocaml
ulfdoz_ has joined #ocaml
ulfdoz has quit [Ping timeout: 264 seconds]
ulfdoz_ is now known as ulfdoz
rwmjones has quit [Read error: Operation timed out]
emmanuelux has quit [Ping timeout: 252 seconds]
rwmjones has joined #ocaml
okhra has joined #ocaml
ski has quit [Ping timeout: 272 seconds]
ski has joined #ocaml
okhra has quit [Quit: Leaving]
BiDOrD has quit [Read error: Operation timed out]
BiDOrD has joined #ocaml
wormphlegm has quit [Read error: Connection reset by peer]
wormphlegm has joined #ocaml
leoncamel has joined #ocaml
ankit9_ has joined #ocaml
cacho has joined #ocaml
Progster has joined #ocaml
ankit9_ has quit [Client Quit]
pango is now known as pangoafk
Cyanure has joined #ocaml
Progster has quit [Ping timeout: 245 seconds]
ontologiae has joined #ocaml
yezariaely has left #ocaml []
emmanuelux has joined #ocaml
emmanuelux has quit [Read error: Operation timed out]
yezariaely has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
djcoin has joined #ocaml
ontologiae has quit [Ping timeout: 250 seconds]
ontologiae has joined #ocaml
edwin has joined #ocaml
edwin has left #ocaml []
ftrvxmtrx has joined #ocaml
ontologiae has quit [Ping timeout: 252 seconds]
mika1 has joined #ocaml
sepp2k has joined #ocaml
Submarine has joined #ocaml
madroach has joined #ocaml
Derander has quit [Ping timeout: 248 seconds]
mcclurmc_away is now known as mcclurmc
Derander has joined #ocaml
ankit9_ has joined #ocaml
xcombelle has joined #ocaml
thomasga has joined #ocaml
Sablier has quit [Ping timeout: 246 seconds]
ontologiae has joined #ocaml
hongboz has joined #ocaml
avsm has joined #ocaml
<avsm>
if anyone is running macos x 10.8, i could use a test run...
beckerb has joined #ocaml
ankit9_ has quit [Quit: Leaving]
avsm has quit [Quit: Leaving.]
fds has quit [Ping timeout: 260 seconds]
georg has joined #ocaml
<georg>
hello
<georg>
yesterday I asked about shared libary creation and -fPIC enabled libasmrun
hongboz has quit [Ping timeout: 272 seconds]
<georg>
I now compiled ocaml by hand with the approriate flag. It took me a while to convince ocamlbuild and find to work with my own version in /usr/local/lib/ocaml.
<georg>
It works and I can build a shared libary on my linux 64 bit machine
<georg>
A small test libary works fine, but a larger project fails. Do you know whether I have to recompile also the libaries (like batteries) with the fpic enabled ocaml?
avsm has joined #ocaml
Cyanure has quit [Remote host closed the connection]
<f[x]>
georg, yes
<f[x]>
at least all libs with C bindings I suppose
<mfp>
georg: AFAIK ocamlopt generates PIC code by default on AMD64 (check with ocamlopt -h 2>&1 | grep PIC)
<f[x]>
convincing ocamlbuild is easy - just set PATH
<adrien>
georg: do you have both /usr/local/bin/ocaml and /usr/bin/ocaml?
<adrien>
and who's op on the channel? /topic needs a refresh
<mfp>
f[x]: are you sure? AFAIK: (1) ocamlopt does -fPIC by default, and (2) ocamlc -c calls gcc with -fPIC ... even when libasmrun is not compiled with -fPIC
<f[x]>
mfp, indeed, you are right
<f[x]>
so it is only the problem that libasmrun is compiled without PIC by default?
<f[x]>
for performance reasons?
<mfp>
I guess so
<mfp>
it'd be nice if the a PIC-enabled libasmrun were built, installed and used when doing -output-obj
<fasta>
Doesn't ocamlbuild need to stat each file for every incremental build?
<mfp>
the same way the gprof-enabled one is when using -p
<fasta>
If so, why do you even consider using it?
<adrien>
everything needs to stat each file
<fasta>
adrien: no
<adrien>
or you'll be left with things that aren't updated
<fasta>
adrien: inotify solves that
<adrien>
no
<adrien>
it won't work between reboots
<pippijn>
fasta: yes
<adrien>
also, ocamlbuild will stat files
<fasta>
adrien: you can use a database for that.
<pippijn>
ocamlbuild is worse than almost everything
<adrien>
but if their content hasn't changed, it won't rebuild them, nor will it rebuild files which depend on it
<pippijn>
because it stats everything
<adrien>
which is *WAY* better
<fasta>
adrien: build systems have evolved.
<pippijn>
not just the things it knows about
<fasta>
adrien: OCamlbuild is just 1970s tech.
<pippijn>
fasta: worse
<pippijn>
make is better
<adrien>
ok, you two, hold on a minute, will you,
<adrien>
?
<fasta>
pippijn: I believe you immediately.
<pippijn>
if you have a directory with 3000 text files ocamlbuild never needs to touch, it will stat them anyway
<fasta>
I just don't get why people A) create such crappy tools B) use such crappy tools.
<adrien>
12:12 ~/projects/caravel % find -type f | wc -l
<fasta>
Tup might not be the last word, but it is really close.
<fasta>
Is anyone still doing anything on multi-core shared memory OCaml?
<adrien>
ocamlnet
<fasta>
Or are all projects dead in that area?
<adrien>
fasta: my point with the linux kernel is that it is written in such a way that it cannot avoid most rebuilds
<fasta>
Is ocamlnet basically CSP?
<adrien>
CSP?
<fasta>
Communicating Seq. Proc.
<fasta>
adrien: isn't that largely to the whole '#include' semantics?
<adrien>
yes
xcombelle has quit [Quit: I am a manual virus, please copy me to your quit message.]
<adrien>
that's the issue
<f[x]>
> if you have a directory with 3000 text files ocamlbuild never needs to touch, it will stat them anyway
<f[x]>
learn -traverse
<f[x]>
nobody forces you to use ocamlbuild
<f[x]>
this whole discussion is pointless and non-constructive
<f[x]>
if you know how to make ocamlbuild better (which I doubt) - do it
<f[x]>
if you want to rant - do it in your blog
<fasta>
f[x]: I am sorry, but that has absolutely nothing to do with what we are talking about.
<fasta>
f[x]: yours is some cheap hack.
<fasta>
f[x]: I talked about an actual solution.
<f[x]>
inotify is not available everywhere
<f[x]>
still you can implement it
<fasta>
f[x]: Windows, Mac, and Linux support not enough?
<f[x]>
no
<fasta>
f[x]: so, write a small compiler to compile to ocamlbuild for your broken platforms.
<f[x]>
you propose me to write something?
<fasta>
f[x]: no
<f[x]>
so, where is the code?
<fasta>
f[x]: you appear to not see the obvious benefits.
<fasta>
I'd say you never worked on any project where compile time was measured in minutes.
<fasta>
Or you are just really patient.
<f[x]>
missed
<f[x]>
and as adrien pointed out stating files is not a problem
<f[x]>
and I have actually contributed ocamlbuild-speedup patches to mantis
<f[x]>
where is yours?
<fasta>
...
<fasta>
Which part of 'why repair a broken design' don't you get?
<flux>
I'm working in a project at work that takes 5 minutes to link. that is, it's 5 minutes after any kind of modification.
<fasta>
flux: and you think that's great?
<flux>
obviously that sucks
<fasta>
flux: are you already incrementally linking?
<f[x]>
fasta, I don't get the part that includes ranting on irc instead of writing code
<fasta>
f[x]: when you have no argument anymore, you claim I rant. Good argumentation.
<flux>
well, I haven't touched the build system, but the system is built of subsystems that don't interact with each other and it creates libraries of those systems
<fasta>
I think 5 minutes edit-compile-run cycles only show that something went really wrong somewhere.
<f[x]>
I really miss the point. You think you know how to speedup ocamlbuild. Why do you need to convince anyone else in this?
<flux>
I should mention it's c++
<fasta>
f[x]: I don't I said that.
<fasta>
f[x]: I said that I don't get why people use broken tools when better things are available.
<f[x]>
obv our definitions of better are different
<fasta>
One is asymptotically optimal builds with small constant factors and the other one is not.
<fasta>
You can always use two build systems.
<fasta>
One for deployment on a generic target.
<f[x]>
one is manual dependency handling and the other is automatic
<fasta>
And one for development.
Tobu has quit [Ping timeout: 272 seconds]
<fasta>
I think Tup can be trivially as automatic as ocamlbuild is.
<f[x]>
see
<orbitz>
Makefiles are the future!!!
<f[x]>
ocamlbuild is already automatic
<f[x]>
and I am lazy
<fasta>
f[x]: what specifically is automatic about it?
<f[x]>
it is good enough for me
<fasta>
Yeah, I suppose for most people a Fiat Panda is also good enough.
<f[x]>
automatic means manual configuration for 35KLoC project is seven lines in _tags
<f[x]>
fasta, yep
<f[x]>
that only proves that people are different
<f[x]>
but that of course doesn't mean that somebody shoud stop working on f1 ferrari
<fasta>
f[x]: what other tools do you use? E.g. editor, etc.
<f[x]>
vim
* f[x]
gets ready
<fasta>
f[x]: does that have some kind of type-sensitive completion mode?
<f[x]>
no :)
ontologiae has quit [Read error: Connection reset by peer]
<fasta>
f[x]: so, you just internalized lots of modules in your head?
<f[x]>
yes
<fasta>
f[x]: what do those 35KLoC do?
<f[x]>
database, parser, server
ontologiae has joined #ocaml
<fasta>
f[x]: I meant what application.
<f[x]>
nothing more specific than that
_andre has joined #ocaml
avsm has quit [Read error: Connection reset by peer]
avsm has joined #ocaml
<georg>
Hi again, sorry I was away...
<georg>
mfp:Yes I cheched and ocamlopt uses -fPIC by default
<georg>
adrien: do you have both /usr/local/bin/ocaml and /usr/bin/ocaml? Yes I have. I think I am sure that the right binaries are used, but the batteries and other libs are only in /usr/lib/ocaml
<georg>
mfp: "it'd be nice if the a PIC-enabled libasmrun were built, installed and used when doing -output-obj" Yes indeed.
hongboz has joined #ocaml
mcclurmc is now known as mcclurmc_away
gnuvince has quit [Ping timeout: 244 seconds]
Progster has joined #ocaml
sepp2k has quit [Quit: Leaving.]
bobzhang` has joined #ocaml
<adrien>
georg: you should *ABSOLUTELY* *NEVER* have two installations of ocaml in your PATH at the same time
<adrien>
well, not before you know the tools _well_
<georg>
adian:well should I uninstall the ocaml packages then? But then all the tool like ocamlfind and so on are also missing
hongboz has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
bobzhang` has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
<f[x]>
georg, the easiest way is to have new ocamlfind for each ocaml installation
<f[x]>
don't mix and match ocaml installation - treat each of them as completely separate from others
<georg>
Another question: Can I not simply substitute the libasmrun.a with the new one and keep all the rest of the system
<georg>
f[x]: I understand, I will try, but it is not that easy to get everything installed by hand
<adrien>
georg: unless you've taken some care, mixing installations is a bit risky
<adrien>
so unless you know well what you're doing, don't take risks
<f[x]>
georg, yes
<f[x]>
that's why people lean toward package managers or self-written bash scripts..
<adrien>
I like godi too
<georg>
Would it be possible to get everythiung with godi?
<adrien>
define "everything"
<f[x]>
currently there are at least : godi odb opam
<georg>
adrien: sorry: I mean, ocamlc..., ocamlfind, ocamlbuild, batteries, that is about it
<georg>
Ah, I mean ocaml with -fpic ;-)
<adrien>
I never know for batteries but I'd expect godi to have batteries 2
<adrien>
georg: I haven't followed everything for -fPIC
<adrien>
it's not on by default and you have to do it by yourself?
<georg>
The problem is that I need ocaml tp be compiled with -fPIC option on my Linux 64 bit, because I need ocaml code as a libary to be called from C.
<georg>
Yes, exactly.
<georg>
It seem to bring a slight performance drop, that's why it is not on by default
<adrien>
how have you "fixed" it so far?
<f[x]>
georg, btw, have you seen PR#5693
<adrien>
yes, there's a perf impact
<adrien>
configuring ocaml with ./configure -cc 'gcc -fPIC' should do what you need
<georg>
f[x]: I have seen this bug, but it only affects MAC, as far as I see
<georg>
adrien: yes I got that so far. everything is fine
<f[x]>
georg, indeed
<georg>
I have my lib and I can link against it
<georg>
I have it running on 32bit without problems, on 64bit it segfaults
<adrien>
georg: godi will be a bit harder to "mod"
<georg>
I tried a simple version of the libary (ocaml side is very simple) and it works
<georg>
The larger program with some ocaml libaries and so on does not.
<georg>
The debugger is not very helpful either.
<georg>
Maybe it is really a problem of Marschalling and where I have some bugs.
<georg>
Sorry I have to leave now. Thanks for you help so far!
Ptival has quit [Read error: Connection reset by peer]
Ptival has joined #ocaml
mcclurmc_away is now known as mcclurmc
gnuvince has joined #ocaml
Cyanure has joined #ocaml
Cyanure has quit [Remote host closed the connection]
leoncamel has quit [Remote host closed the connection]
Tobu has joined #ocaml
smondet has joined #ocaml
zorun_ has joined #ocaml
zorun has quit [Ping timeout: 252 seconds]
Tobu has quit [Ping timeout: 272 seconds]
avsm1 has joined #ocaml
avsm has quit [Read error: Connection reset by peer]
zorun_ is now known as zorun
mnabil has joined #ocaml
Tobu has joined #ocaml
mnabil has quit [Read error: Connection reset by peer]
<hcarty>
pippijn, adrien: If you want to have ocamlbuild not look at unused files, you can tell it to ignore them
mnabil has joined #ocaml
<adrien>
hcarty: I'm fine with the speed as far as I'm concerned ;-)
<adrien>
linking against gtk+-2 and everything else takes 1.5 seconds out of the 7.5 seconds builds of caravel
smondet has quit [Read error: Connection reset by peer]
smondet has joined #ocaml
mika1 has quit [Quit: Leaving.]
<hcarty>
adrien: You've had the wool pulled over your eyes! How can you be fine with that???
_key_ has joined #ocaml
<hcarty>
adrien: 7.5 seconds isn't bad
<_key_>
hi, i am thinking about trying out ocaml 4.0.0 and was googling about the parallelisation. is there a method to parallelize List.map?
<hcarty>
_key_: Not in the core stdlib, but there are other libraries which support that
<thelema_>
_key_: there's a number of libraries to do so, but nothing built in
<_key_>
thelema_: ok, thanks. will have a look
<hcarty>
_key_: Parmap, Functory, preludeml - these all provide something out of the box
<hcarty>
_key_: There are zeromq and MPI bindings as well for more complex tasks.
<adrien>
hcarty: yeah, I've worked a bit on making it faster (skip .cmo file generation, which turns out to not save that much speed)
<adrien>
avoiding camlp4 saved a _lot_ of time in yypkg (half the time I thinkà
<thelema_>
adrien: what were you using camlp4 for?
<adrien>
hcarty: but, "the wool pulled over my eyes"? I had never heard that :P
<adrien>
thelema_: sexplib
<thelema_>
adrien: ah.
<adrien>
hand-written now ;p
<adrien>
but I could probably have made it run only on my "types.ml" file ;-)
<adrien>
but iirc, my object code is also much smaller now
mnabil has quit [Remote host closed the connection]
<thelema_>
I wonder if sexplib's camlp4 is native compiled by default...
<hcarty>
adrien: It effectively means "You've been fooled/misled" - I'm not sure what the origin is though :-)
<adrien>
thelema_: really, I think I was using it on _all_ files and that was useless
<adrien>
probably the biggest speed improvement one could get
<Hodapp>
do people often use OCaml for parallel code, whether that's SIMD, multi-thread/multi-process, or whatever?
<hcarty>
Hodapp: I do
<hcarty>
Hodapp: And there are enough libraries supporting it that I expect others do as well
<Hodapp>
hcarty: what do you use?
zorun has quit [Quit: good luck Skhaen]
<hcarty>
Hodapp: A fork-based parallel List.map/iter for simple tasks that I want to perform more quickly; zeromq or MPI for distributed work
<Hodapp>
multiprocess then for the former?
<hcarty>
Yes
zorun has joined #ocaml
<hcarty>
Lwt for concurrency without parallel processing and/or execution of external processes in parallel
<hcarty>
Hodapp: I'm moving away from MPI to zeromq as it's more appropriate for what I'm currently working on.
avsm1 has quit [Quit: Leaving.]
<Hodapp>
0MQ does look pretty awesome, at least from my distant watched-a-few-lectures, read-a-few-papers view
braibant has quit [Quit: Leaving.]
mnabil has joined #ocaml
_key_ has quit [Quit: _key_]
mnabil has quit [Remote host closed the connection]
rhodesd has joined #ocaml
<hcarty>
diml: Do you know when you expect to release an updated utop?
mcstar has joined #ocaml
<hcarty>
And oh wow - utop v.Next looks like it may have a pretty GUI toplevel environment...
<Drakken>
Speaking of parallelism, is there any sign of a parallel gc on the horizon?
<hcarty>
Drakken: No
<hcarty>
Drakken: The least thing I read on that front was talk of having one GC per thread, or something along those lines. I don't know if that was anything more than an idea being thrown around though.
<Drakken>
Is there a theoretical or policy reason for that, or is it just a matter of time and funding?
<Drakken>
(hcarty)
<hcarty>
Drakken: Philosophical and complexity issues are the main points from what I've read. Time and funding may factor in as well.
<thelema_>
hcarty: well said
thomasga has quit [Quit: Leaving.]
<Drakken>
What's the philosophical argument against parallel programming?
ftrvxmtrx has quit [Quit: Leaving]
<Drakken>
Is that not considered a priority for OCaml?
xcombelle has joined #ocaml
<thelema_>
Drakken: parallel programming is fine. shared memory parallelism is the "not a priority"
<Drakken>
thelema_ does that mean each thread can run on a separate core with one-gc-per-thread?
<hcarty>
Drakken: s/thead/process/ -- then yes
<hcarty>
thelema_: Thanks - I had stepped away
<thelema_>
hcarty: we're all here to help the community, fielding questions and all
<Drakken>
Hmm. Maybe that's okay for big websites. I guess forking for a whole page request isn't too bad.
<thelema_>
Drakken: it's not necessary to fork.
<thelema_>
for websites, where IO wait makes threading useful, the current threading model built into ocaml works just fine.
<thelema_>
it's pretty trivial to have one process started for each core and to distribute requests among them
<Drakken>
Don't you need some kind of separate executables to create processes?
<thelema_>
no
<thelema_>
you can just run the same executable multiple times
<thelema_>
maybe with a command-line parameter to get them listening on different ports or domain sockets
Progster has quit [Ping timeout: 260 seconds]
<bitbckt>
it's more typical to let the children all listen/accept on a single socket and let the kernel listen queue load balance among them.
<thelema_>
bitbckt: sounds good to me.
<Drakken>
thelema_ my sloppy language. I meant separate system calls, not that there have to be lots of separate executable files.
djcoin has quit [Quit: WeeChat 0.3.2]
<thelema_>
I don't understand the question - what separate system calls?
avsm has joined #ocaml
Progster has joined #ocaml
<Drakken>
Maybe that's more sloppy language. By "system call" I meant "starting a new process".
<thelema_>
sure, but you don't need to start a new process for each request
<thelema_>
just start a pool of processes and have them work on requests
<bitbckt>
the same would be true in the presence of threads: don't start a new thread for each request, use a thread pool.
<Drakken>
So is there any basis for all the internet chatter I see about parallel GC? People seem to think it's important, but that would only be for applications that are so fine-grained that even talking to another process would be too slow.
<thelema_>
there'
<thelema_>
s applications for which it's useful
<thelema_>
web servers are not among those
<bitbckt>
to be clear, parallelizing a GC is different from a _concurrent_ GC.
<bitbckt>
a parallel GC reduces pause times by utilizing multiple threads during GC activity; a concurrent GC runs along with mutator threads, and may also be parallel.
Yoric has joined #ocaml
<Drakken>
Maybe it's not as important as the new features INRIA has been working on, like GADTs and first-class modules.
<hcarty>
Drakken: Not to the OCaml core folks at least :-)
ontologiae has quit [Read error: Operation timed out]
Yoric has quit [Ping timeout: 255 seconds]
Yoric has joined #ocaml
<Drakken>
hcarty the question is what's important to users. I hope that's what the OCaml devs are focussing on.
<Drakken>
It's not necessarily so bad for users to be worried about multi-core processing if there's at least an explanation of how to do it in OCaml.
<hcarty>
Drakken: The users in the Caml Consortium have a large influence on what ends up in the language
<hcarty>
Drakken: At this point I think that there are a nice selection of methods for concurrency and parallelism in OCaml. They could certainly be more effectively advertised.
<Drakken>
That'
<Qrntz>
I wish JoCaml got the attention it deserves
<Drakken>
hcarty that's what I want to know: which applications really suffer from a lack of multi-core GC, and how do deal with the ones that aren't too much of a problem.
Yoric has quit [Ping timeout: 244 seconds]
<hcarty>
Drakken: That's easier to address the other way around - propose an application which would benefit from some form of parallelism, then assess which method(s) will work for that application.
<hcarty>
There aren't applications which _can't_ be done due to a lack of concurrent GC, it's just a question of which ones fall to an unacceptable level of performance
<adrien>
but having a concurrent GC with one thread will decrease the performance quite a lot
<adrien>
unless you've seggregated the data in several zones, your threads will work on the same data
<adrien>
so you'll get contention, you'll need checks, ...
<adrien>
and once you go in "32 cores", you'll be paying a hefty price
<adrien>
so, at least, you need to separate allocations
<bitbckt>
hcarty: well put.
ftrvxmtrx has joined #ocaml
cdidd has quit [Ping timeout: 244 seconds]
<avsm>
the other issue with a concurrent/parallel gc is backwards compat. the FFI would almost certainly need a change, which is quite the effort...
<avsm>
and marius will be pleased, as its an implementation of concurrent ml ;-)
<Drakken>
hcarty I don't know what applications I might have to or want to work on in the future. I love the mostly-functional approach of OCaml, and it would be nice to know that I can get the maximum possible performance out of it in all applications.
<bitbckt>
it's always nice when marius is pleased...
<hcarty>
Drakken: You can get good performance for most applications. I'm not sure that any language can do much better than that on its own, short of the C and assembly worlds.
<adrien>
avsm: hahaha, true; and considering that many FFIs today are not very safe (how can we know they're safe?), an additional difficulty would make it worse probably
<avsm>
adrien: there was a cool CIL-based static analyser for the OCaml FFI a few years ago. Safire or something?
<adrien>
oh, right
<adrien>
I think it was only reachable through archive.org already one or two years ago
<adrien>
I'm going to put safire back on my todo-list and quite high in it
* avsm
gets back to figuring out wtf malloc is randomly segfauling on 10.8 osx
<avsm>
got it
<avsm>
ah, the old 'hacked CIL tree'. this is going to fun to merge
<adrien>
"Saffire is implemented as a combination of camlp4 and a CIL module"
<adrien>
that might be an issue
<thelema_>
old camlp4 - means you get to use camlp5
<bitbckt>
... wee.
<adrien>
avsm: hmmm, considering the manpower and the need, it might be good to work on that inside a virtual machine that can be redistributed
<adrien>
I think we want to avoid doing it even twice
<adrien>
well, B movie, pizza, crisps, ice cream and soda night, I'm going to leave the computer soon :P
<avsm>
adrien: my todo list is epic. i'm just loading it up before i start my california sabbatical in a week, so feel free to start without me ;-)
<adrien>
(fried brain: I've spent the week on system stuff and the different components are all currently broken in a different way each, and I know well none of them)
<Drakken>
hcarty other languages are also missing a lot of complexity-management features that OCaml has, and there are probably more that are worth working on.
<adrien>
avsm: well, mine starts with roughly a hundred packages of free software on windows, and real-world FRP; it's going to be fun too ;-)
<adrien>
but I think I have quite a big need for saffire
<adrien>
and enjoy ;-)
alpounet has quit [Ping timeout: 260 seconds]
<bitbckt>
avsm: you should swing by the twoffice, if you're in the area.
Cyanure has joined #ocaml
<avsm>
bitbckt: definitely, will ping you; need to caffeinate up with jake and marius too. commuting down to stanford most days, but will probably just work from sf a few days a week
thomasga has joined #ocaml
thomasga has quit [Client Quit]
mcclurmc_away is now known as mcclurmc
ontologiae has joined #ocaml
xcombelle has quit [Quit: I am a manual virus, please copy me to your quit message.]
pangoafk is now known as pango
avsm has quit [Quit: Leaving.]
Cyanure has quit [Remote host closed the connection]
<hcarty>
-warn-error A is a painful thing, at least in release versions software
<hcarty>
It seems like omake in particular manages to break with each new OCaml release.
<thelema_>
omake always struck me as... overly complex and fragile
<hcarty>
thelema_: That's been my experience. Unfortunately it is still used in some projects, including camlimages.
<hcarty>
And I'd like to try out the latest camlimages version on OCaml 4.0 to see if it works.
<thelema_>
really? I thought that the git tree used ocamlbuild
<thelema_>
n/m, I'm wrong
<thelema_>
and it's hg, apparently
<hcarty>
Yep
<hcarty>
If '-warn-error A' is removed from the build then omake builds and installs under 4.00.0