gildor changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | OCaml 3.12.1 http://bit.ly/nNVIVH
ski has quit [Ping timeout: 246 seconds]
ski has joined #ocaml
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
<adrien> 227
<adrien> 12:12 ~/projects/caravel % find -name "*.ml" | wc -l
<adrien> 22
<fasta> I hope its ignorance.
<fasta> it's
<adrien> 12:12 ~/projects/caravel % time pmake
<adrien> [snip]
<adrien> Finished, 89 targets (0 cached) in 00:00:09.
<adrien> pmake 4.22s user 1.80s system 53% cpu 11.278 total
<adrien> _cold_ cache
<adrien> does that sound like a performance issue?
<fasta> adrien: seems _extremely_ slow.
<adrien> slow? do you know what it does?
<adrien> it links against gtk
<fasta> adrien: so?
<fasta> adrien: do you use incremental linking?
<adrien> ld takes the most time
<adrien> clean build with hot cache:
<adrien> pmake 4.31s user 1.60s system 79% cpu 7.391 total
<fasta> Also ld is a piece of shit too.
<adrien> fasta: currently we're talking about ocamlbuild stat()'ing files
<pippijn> adrien: it's usually not a problem, but you can't have any number of files under your source root
<pippijn> adrien: that can be a problem
<adrien> seriously, it's not a peformance problem
<adrien> maybe if you work over nfs
<pippijn> it was a serious performance issue for me
<adrien> (o)profile things and check what takes time; it's not stat'ing files
<fasta> adrien: I compare it to image based development.
<fasta> A good build system allows one to precisely specify rules for when to update.
<pippijn> adrien: ocamlbuild doing nothing: ocamlbuild hm/hm_tokens.mly.in 0.09s user 0.02s system 84% cpu 0.133 total
<fasta> A good build system for the Linux kernel rebuilds it in about 1 second for a source file change.
<adrien> sed 0.00s user 0.00s system 0% cpu 0.010 total
<adrien> that's sed doing nothing
<adrien> pretty long imho
<pippijn> adrien: ocamlbuild doing nothing if my testsuite is under my source root...
<adrien> fasta: NO
<adrien> NO
<adrien> NO
<adrien> AND
<adrien> NO
<pippijn> ocamlbuild hm/hm_tokens.mly.in 8.52s user 0.19s system 98% cpu 8.838 total
<pippijn> hot cache
<pippijn> doing nothing
<fasta> adrien: because?
<adrien> linux kernel is a complete fuckup that includes .h files in almost every possible combination
<adrien> you cannot predict what will have to be rebuilt
<fasta> adrien: you are so wrong.
<adrien> as for building the kernel itself and not only the .o files, I wonder which machine you run on; 40GHz?
<adrien> sure
<adrien> Linux yoda 3.5.0 #55 SMP Mon Jul 23 21:30:19 CEST 2012 x86_64 AMD E-350 Processor AuthenticAMD GNU/Linux
<adrien> and the counter has been reset a number of time
<adrien> s
<fasta> adrien: here: http://gittup.org/gittup/
<fasta> adrien: I am waiting here for your 'OMG, that's so cool'-comments.
<fasta> Or 'hey, that's one build system which doesn't suck!'.
<fasta> Yeah, I know.
<pippijn> it sucks
<pippijn> the syntax is ugly :)
<fasta> pippijn: it sucks, because?
<pippijn> ^
<fasta> pippijn: I used it and it works as advertised.
<pippijn> I know
<pippijn> me too
<pippijn> and I still don't like the syntax
<fasta> pippijn: so, build a compiler.
<adrien> fasta: that's a linux distribution, not a build system afaict
<fasta> adrien: too bad.
<pippijn> adrien: it's a build system
<pippijn> called tup
<fasta> adrien: I thought you were a bit less short-sighted.
<fasta> adrien: there are several of such build systems now.
<adrien> fasta: I'm currently doing 3 things at once, and have several other ones on the backburner, so no, I'm not going to add another one :-)
<fasta> adrien: fair enough.
<adrien> pippijn: link to it, rather than the whole page?
<adrien> whole doc*
<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
<adrien> hcarty: ah, ok :-)
<adrien> :P
<hcarty> thelema_: Cool, thanks
<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...
<bitbckt> ugh. JNI...
mcclurmc is now known as mcclurmc_away
<avsm> indeed... i much prefer multiMLton's approach of region-based cothreads built into the runtime. http://multimlton.cs.purdue.edu/mML/
<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
<bitbckt> yeah, I think that was PLDI '05 or '06.
<bitbckt> '05, I guess...
* bitbckt does math
<avsm> adrien: if you find the sources, would love to try it too.
* 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
<thelema_> nice. Where's the home page?
<thelema_> oh, it's on camlcity?
<hcarty> That's the most official looking site I've found
<thelema_> sorry, for omake, not camlimages
<hcarty> I found it by clicking on the "OMake Home" link from the camlcity site :-)(
<thelema_> News
<thelema_> Version 0.9.8.6 Release Candidate 1 (October 26, 2010) Version 0.9.9 Prerelease (June 20, 2007)
<thelema_> what a world. 0.9.8.6rc1 comes out 3 years after 0.9.9 pre-release
<thelema_> it looks like the last commit (at least as far as their "omake-cvs" mailing list shows) was november 2011. and before that, february
<hcarty> No luck with camlimages. It's having trouble detecting system libraries (libpng, libtiff...)
<thelema_> too bad...
<hcarty> Indeed.
<hcarty> Drat. omake doesn't build with OCaml 3.12.1 due to -warn-error A as well.
<hcarty> I may give up on camlimages for now.
pcavs has joined #ocaml
Anarchos has joined #ocaml
bzzbzz has quit [Read error: Operation timed out]
gnuvince has quit [Ping timeout: 264 seconds]
gnuvince has joined #ocaml
Anarchos has quit [Quit: reboot]
cmake has joined #ocaml
avsm has joined #ocaml
bzzbzz has joined #ocaml
Submarine has quit [Ping timeout: 244 seconds]
<cacho> anybody knows a html parser in ocaml?, yeah, my google habilities are failing (hard)
<pippijn> cacho: I guess you already looked at ocamlnet?
<cacho> pippijn: no, checking right now
<pippijn> it's the first hit on google when I enter "ocaml html parser"
<cacho> looks like what I'm needing
<cacho> pippijn: thanks
<pippijn> your google is broken
<cacho> yeah, I never thought on searching it like that, was more like lexing, yaccing, bisoning :p
<pippijn> yep, your skills are low
<pippijn> don't try to be too smart
<cacho> your google has learn to satisfy your ocamlish needings
<pippijn> bing != google
_andre has quit [Quit: leaving]
avsm has quit [Ping timeout: 244 seconds]
mcstar has quit [Quit: mcstar]
thomasga has joined #ocaml
thomasga has quit [Client Quit]
gnuvince has quit [Ping timeout: 255 seconds]
pcavs has quit [Quit: Leaving.]
smondet has quit [Quit: time to go]
pcavs has joined #ocaml
cdidd has joined #ocaml
ontologiae has quit [Ping timeout: 244 seconds]
Progster has quit [Ping timeout: 260 seconds]