alexyk has quit [Read error: 110 (Connection timed out)]
chickenzilla has quit [Read error: 110 (Connection timed out)]
alexyk has joined #ocaml
<Camarade_Tux>
llvm compilation speed is important because it is used for real-time graphic rendering
smimou has joined #ocaml
Camarade_Tux has quit ["Leaving"]
slash_ has quit ["leaving"]
tarbo2_ has joined #ocaml
tarbo2 has quit [Read error: 110 (Connection timed out)]
alexyk has quit []
<Yoric[DT]>
'night everyone
Yoric[DT] has quit [Read error: 54 (Connection reset by peer)]
alexyk has joined #ocaml
<brendan>
# #load "camlp4o.cma";;
<brendan>
Error: Reference to undefined global `Dynlink'
<brendan>
this is ocaml 3.11.0 on a mac. Any clues?
alexyk has quit []
Smerdyakov has quit ["Leaving"]
jeddhaberstro has quit []
palomer has joined #ocaml
<palomer>
hullo
<palomer>
could someone explain ocamlfindlib in a nuttshell?
<palomer>
err, nutshell
<palomer>
I'm confused by the archive variable in META files
<palomer>
what's an archive file?
<hcarty>
brendan: You need to load the dynlink module first ... camlp4 3.11 requires Dynlink
<brendan>
aha. thanks!
<hcarty>
palomer: The archive file is the .cmo, .cmx, .cma or .cmxa for the library
ched_ has quit [Read error: 110 (Connection timed out)]
ched__ has joined #ocaml
<palomer>
ahh, righto
<palomer>
I'm using ocamlc -a -o to merge archive files
<palomer>
how do I do it for natively compiled binary files?
<hcarty>
palomer: I've always taken the wimpy way out and used OCamlMakefile or ocamlbuild. The manual and man pages should have the information you need though.
<palomer>
im using omake
<palomer>
(and make)
<hcarty>
omake should have support for that more or less automatically. I have not personally used it for my own projects though.
<hcarty>
I'm off for the night though. Best of luck.
<palomer>
ahh, got it
<palomer>
ocamlopt
<palomer>
night!
alexyk has joined #ocaml
palomer has quit [Remote closed the connection]
palomer has joined #ocaml
<palomer>
hrmph
<palomer>
how do I get omake to check if a library is installed (so it can remove it before installing it again) using ocamlfind?
<thelema>
ocamlfind list | grep <libraryname>
seafood has quit [Read error: 60 (Operation timed out)]
jamii_ has joined #ocaml
willb has quit [Read error: 60 (Operation timed out)]
wsmith84 has joined #ocaml
<palomer>
hrmph
<palomer>
anyone know of a library that uses omake?
<mrvn>
The indent is what tuareg-mode in (x)emacs does.
<mrvn>
And I would use different variable names to avoid confusing people with shaddowed bindings.
<vaasu>
yea.. thats poor code..
<mrvn>
vaasu: you should have just written let f x = 5
filp has quit ["Bye"]
<vaasu>
i agree
<mrvn>
% cat tmp/hello
<mrvn>
cat: tmp/hello: Function not implemented
<mrvn>
Still a long way to go.
<vaasu>
i came from a scheme background and absence of parenthesis made me crazy :-)
<mrvn>
I hate that constructors take tuppels instead of being curried.
<Alpounet>
mattam, thanks for your advice ;)
<Alpounet>
Can anybody tell me more about why OCaml doesn't support well parallel programming ? Indeed, I've not put my nose into such problems for the moment...
<mrvn>
Alpounet: like concurrent multithreading?
mfp has quit [Read error: 104 (Connection reset by peer)]
<mbishop>
Alpounet: Well, OCaml has fork/join, and it has more elaborate concurrency like coThreads and a Thread module and stuff, but the real problem is that the GC is single threaded
<mrvn>
so only one thread can run ocaml code at any one time.
<Alpounet>
Okay...
<Alpounet>
Even with native code ? Isn't there some workaround ?
<mrvn>
Alpounet: write a new GC.
animist has quit ["Leaving"]
<mbishop>
The weird thing is, I saw this page about some meeting of computer scientists and what they think the future is of CS and such
<Alpounet>
Yeah, but I mean even when compiling with ocamlopt, don't we get a parallel/concurrent-aware GC ?
<mbishop>
and Xavier Leroy was there
<mrvn>
Alpounet: nope
<mbishop>
he said the thinks the future is concurrency...and yet he refused to make a multi threaded GC
<mbishop>
;/
<mrvn>
mbishop: I think it just isn't easy to do so.
<Alpounet>
mbishop, really, REALLY, weird. Do you know why he refused ?
<mbishop>
Perhaps he is developing some new language in secret
<mbishop>
Alpounet: no, I remember a post somewhere though, probably on the mailing list
<Alpounet>
Ok.
<Alpounet>
In fact, I've a project around HLVM and OCaml...
<mbishop>
mrvn: A lot of language implementations are getting concurrency GCs, hell some have had them since the 90s, but I think the real problem is the structure of OCaml
<mbishop>
internally, that is
<Alpounet>
Still at thinking stage, but will get soon more concrete
<mbishop>
probably would need an entire rewrite or something
* mbishop
shrugs
<mrvn>
mbishop: do you mean the implementation or the language itself?
<mbishop>
the implementation
<mbishop>
but I'm guessing
<Alpounet>
mrvn, I think he means about the INRIA implementation, the compilers
<Alpounet>
isn't it ?
<mrvn>
The language itself needs a concurrency update too. Things for atomicity and thread communications.
<mbishop>
well, there is only one implementation
<mbishop>
mrvn: couldn't that be done with camlp4 magic or something?
<mrvn>
or plain ocaml. Just should be in the standard lib
sitaktif has quit [Read error: 110 (Connection timed out)]
<mrvn>
Things like "run xyz with lock"
<mbishop>
yeah I guess, although we know the standard lib isn't the greatest, which is why we have Batteries
<mbishop>
which is really nice :)
<Alpounet>
Yeah?
<Alpounet>
.*
<mrvn>
For classes it might be nice to make a class atomic.
<mrvn>
i.e. only one thread might run a method at any one time.
<mrvn>
I only see one minor change for virtual values in classes since 2.02 that I would consider a language change.
mfp has joined #ocaml
<mrvn>
That's like 10 years.
<mrvn>
Maybe it is time for an ocaml 4.0 with concurent multithreading, batteries and a few tidbits.
<flux>
mbishop, concurrent gc is unlikely fly when you go beyond, say, 8 cores
<flux>
mbishop, perhaps that's the reason
<flux>
but in the meanwhile, while we aren't still in a few cores, it'd be nice :)
<flux>
s/n't//
* mbishop
shrugs
<mrvn>
flux: depends on how much you share variables.
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
<mrvn>
I would think every core gets its own heap and as long as you stay in there it should be just as fast as single core.
<flux>
mrvn, does java work that way?
<mrvn>
no idea.
Mr_Awesome has joined #ocaml
<flux>
I suppose java is the highend of gc at the moment?
<flux>
and it i smy understanding it is totally unsuitable for high allocation rates of ml
<mrvn>
I bet there are tons of papers about multicore GCs.
<flux>
indeed
<mrvn>
flux: Most allocations in ocaml are pretty local. Tons of short lived objects. That shouldn't matter for multi core.
<flux>
mrvn, well, are there efficient concurrent gc implementations for some ml then?
<mrvn>
again no idea. I'm just a user. :)
<flux>
"just make it work!"
<mrvn>
exactly.
<flux>
well, I'm of the opinion and 'making it work' has something to do with switching away from the shared memory concurrency to something more similar to mpi :)
<flux>
and in that kind of world threads indeed aren't very useful
<flux>
they can be, though, for writing concurrent code in the small
<mrvn>
I think there should be concurrent memory and slow shared memory.
<mrvn>
Things for multi-core systems and things for clusters.
<flux>
in the end the cores will use some kind of message passing anyway. why fake shared memory in that case?
<mfp>
I'd rather have per-thread heaps + message passing with JoCaml + limited support for shared mem via Bigarray and friends
<mrvn>
flux: because dual/quad core chips do share memory.
<mrvn>
message passing means you need complicated proxy objects in each cores GC.
<flux>
mrvn, do they share cache too?
<mrvn>
Then on each access you have to check if you have a proxy or real object, fetch the real object and restartthe function.
<mrvn>
flux: depends. some do, some dont
<flux>
mrvn, because keeping the cache coherent does involve message passing
<mrvn>
but that is hardware
<flux>
so is the CPU :)
<mrvn>
using or not using it costs you nothing. emulating it in software slows you down.
<mrvn>
Plus it costs you ram and cache lines in the shared case.
<flux>
it does cost in the sense that you need to do a lot of stuff to pass a message from a process to another one
<flux>
while there could be much lower level protocol features to do just that
<mrvn>
flux: imagine having to do that for every element of a list in List.iter
<mrvn>
esspecially with immutable objects just sharing the address is so much simpler.
<flux>
mrvn, what do you mean? some memory is local (in cache) already, of course such common use case should remain hardware accelerated
<maxote>
i will wait for OCaml-4.0 supporting the parallel process on multicores
<mrvn>
flux: Say core 1 creates a list and the core 2 runs List.iter
<hcarty>
mrvn: preludeml has some wrapper functions which support forking for parallel map/iter/etc
<mrvn>
flux: for every element of the list you would have to send a message to core 1 to get the content.
<flux>
mrvn, if you want to run the iterations in lockstep
<mrvn>
flux: the iterations are done sequentially. The problem is accessing the data.
<flux>
I don't see why sending an object to another cpu must mean copying byte by byte
<mrvn>
flux: doesn't matter how you send it. As long as you don't send deep copies that means a message per list element.
<flux>
mrvn, it might mean that currently too
<mrvn>
but in hardware and way chicker.
<mrvn>
quicker
<flux>
way quicker than what?
<mrvn>
than you sending a message in software
<flux>
I don't see why that must be true, if the cpu's would have primitives for doing just that
<mrvn>
Because at a minimum you have some shared memory at least as big as a list element and then you need extra inteleigence to generate and parse messages.
<mrvn>
You will never get that as fast as accessing 2 64bit values in memory.
<mrvn>
Message passing has to be on a higher level so you can do intelligen messages. Like when you want to List.iter a list then request a deep copy of the list and not each element.
<flux>
instructions that don't otherwise obstruct the control flow could be essentially free, parallelised with other instructions
<mrvn>
Or when you want to run Hashtbl.find then tell the other core to run it and pass the entry back.
sitaktif has joined #ocaml
<mrvn>
flux: passing a message will always mean a barrier.
<mrvn>
flux: I think snooping the cache of another core is even faster than accessing uncached memory.
<mrvn>
Would be such a waste not to use it.
<flux>
do they use plain snooping when you have more than two cores?
<mrvn>
For that you should read the specs.
chickenzilla has joined #ocaml
vpalle has quit [Connection timed out]
<kaustuv>
An e-mail I sent to the batteries list seems to have bounced. Do I resend it or wait for some moderator to take care of it?
vaasu has quit []
Proteus has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
<kaustuv>
salut
Alpounet has quit [Read error: 110 (Connection timed out)]
bluestorm has joined #ocaml
jeddhaberstro has joined #ocaml
Alpounet has joined #ocaml
<Alpounet>
Back, sorry.
<Alpounet>
kaustuv, IMO, resend.
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
Mr_Awesome has joined #ocaml
<kaustuv>
Yoric[DT]: a property list is as close as we can get in OCaml as a List<Object> in Java. It is more powerful than a list of values of a polymorphic variant type because the types of the things in (the containers in) the list is not statically known.
alexyk has joined #ocaml
<Alpounet>
kaustuv, don't you then loose typing securities ?
<Alpounet>
And in many cases, the choice of an Object container, e.g, is bad... But in Java, for the moment, they don't really have alternatives.
<kaustuv>
No, they are type safe. The projection from the container type checks that the thing it is projecting was created with an object of the same type.
<Alpounet>
Okay.
Snark has quit ["Ex-Chat"]
<mrvn>
% cat tmp/hello
<mrvn>
Hello World!
<mrvn>
*juhey* one more callback
slash_ has quit ["leaving"]
slash_ has joined #ocaml
slash_ has quit ["leaving"]
slash_ has joined #ocaml
slash_ has quit [Client Quit]
chickenzilla has quit ["J'y trouve un goût d'pomme."]
chickenzilla has joined #ocaml
slash_ has joined #ocaml
Camarade_Tux has quit ["Leaving"]
Camarade_Tux has joined #ocaml
animist has joined #ocaml
ttamttam has left #ocaml []
jeddhaberstro has quit []
wsmith84 has joined #ocaml
itewsh has joined #ocaml
schmx has quit [Read error: 104 (Connection reset by peer)]
sporkmonger has quit [Read error: 145 (Connection timed out)]
kg4qxk has quit [Remote closed the connection]
kg4qxk has joined #ocaml
itewsh has quit ["There are only 10 kinds of people: those who understand binary and those who don't"]
chickenzilla` has joined #ocaml
chickenzilla has quit [Read error: 110 (Connection timed out)]
Camarade_Tux has quit ["Leaving"]
chickenzilla` is now known as chickenzilla
alexyk has quit []
_zack has joined #ocaml
_zack has left #ocaml []
willb has quit [Read error: 110 (Connection timed out)]