smimou changed the topic of #ocaml to: Dicussions about the OCaml programming language | http://caml.inria.fr/
smimou has quit ["bli"]
revision17 has joined #ocaml
revision17 has quit [Client Quit]
_JusSx_ has quit [Client Quit]
jdev has joined #ocaml
<llama32>
does anyone know of an efficient [native compiled] ML that supports dynamic linking?
stevan has joined #ocaml
pango has quit [Remote closed the connection]
<malc_>
ocaml 3.04
sponge45 has joined #ocaml
fik has quit ["Leaving"]
mikeX_ has quit ["leaving"]
sponge45 has quit [Remote closed the connection]
khaladan has quit [Connection timed out]
malc_ has quit ["leaving"]
llama32 has quit [Read error: 145 (Connection timed out)]
Ballin_05 has joined #ocaml
<Ballin_05>
~lo
llama32 has joined #ocaml
llama32 has quit ["Leaving"]
jacobian_ has quit [Read error: 110 (Connection timed out)]
jacobian_ has joined #ocaml
wy has quit ["离开"]
johnnowak has joined #ocaml
dbueno has quit ["Leaving"]
Smerdyakov has quit ["Leaving"]
MisterC has joined #ocaml
Skal has quit [Read error: 60 (Operation timed out)]
ziggurat has joined #ocaml
ramkrsna has quit [Remote closed the connection]
ramkrsna has joined #ocaml
ikaros_ has joined #ocaml
ikaros has quit [Read error: 110 (Connection timed out)]
llama32 has joined #ocaml
zak_ has joined #ocaml
llama32 has quit [Connection timed out]
cmeme has quit [Connection timed out]
cmeme has joined #ocaml
_velco has joined #ocaml
_fab has joined #ocaml
revision17 has joined #ocaml
velco has joined #ocaml
levi_home has joined #ocaml
zak_ has quit ["Leaving"]
slipstream-- has joined #ocaml
love-pingoo has joined #ocaml
slipstream has quit [Read error: 110 (Connection timed out)]
pango has joined #ocaml
revision17_ has joined #ocaml
ppsmimou has quit ["Leaving"]
ziggurat has quit ["Leaving"]
revision17 has quit [Read error: 110 (Connection timed out)]
ppsmimou has joined #ocaml
ppsmimou has quit [Read error: 104 (Connection reset by peer)]
malc_ has joined #ocaml
ppsmimou has joined #ocaml
<love-pingoo>
any idea/experience of why/how-to-know-why an ocaml program would suddenly without any reason increase its memory consumption by 600% ?
<love-pingoo>
(not pure ocaml, though.. we have bindings)
<flux__>
I would like to suggest a bug..
<flux__>
unfortunately I don't have a suggestion on how to debug it
<flux__>
the ocaml threads stalling -problem I had earlier might actually turn out to be a bug (of one thread dying due to an uncaught exception), so my trust to ocaml is rising slightly again ;-)
<love-pingoo>
OCaml has had some bugs on threads and signals management
<love-pingoo>
but last time I had problems with that, it was my fault (I was using forks and threads at the same time)
<flux__>
threads and signal management combined?
<flux__>
or just both features?
<love-pingoo>
mmm actually I just know that a bug in the handling of signals was closed in 3.09
<love-pingoo>
a race condition or something, maybe a deadlock..
<love-pingoo>
I'm not sure about threads
<flux__>
I have 200+ threads, so.. they aren't doing much, though, although I wouldn't mind if it would scale beyond one cpu :-).
johnnowak has quit []
<love-pingoo>
flux__: that's a lot
<love-pingoo>
can't you multiplex tasks into less threads ?
<flux__>
I could fold a half of them into one thread
<flux__>
folding the rest of them into one thread would be a bigger task (convert into continuation passing style etc)
<flux__>
I'm expecting 200 more threads though, so maybe I should actually investigate atleast the first option more, though
<love-pingoo>
it'd be interesting to ask for other people's experience with that many threads on the caml-list
<love-pingoo>
for my part I found my app more stable when I managed to cut down the number of threads (say, from 12 to 6)
<love-pingoo>
and the telnet interface became much more responsive, since no thread creation was involved in the handling of one client
* love-pingoo
wishes there were a graphical tool for visualization ocaml's heap on the fly...
<malc_>
actually there was soemthing of that kind
<love-pingoo>
any pointer/name ?
<Ballin_05>
is ocaml fat enough for game programming ?
<malc_>
nope. but if something like this was mentioned it was on ocaml ml. so you can search there.
<Ballin_05>
fast*
<malc_>
dubious question at best
<flux__>
love-pingoo, well, I don't actually have much experience on that, because there isn't an easy way to interact with the program..
<flux__>
I've pondered about adding a telnet-interface for debugging and other needs..
<love-pingoo>
Ballin_05: there are some games in perl... so speed is not the only question :)
<Ballin_05>
lol
<Ballin_05>
well this would be a 3D kinda deal
<flux__>
with your own 3d engine?
<love-pingoo>
freetennis is written in caml, afaik
<flux__>
maybe ocaml isn't fast enough for a software rasterizer
<Ballin_05>
hmmm
<flux__>
but I would expect it to be plenty fast for everything else..
<Ballin_05>
i would use
<Ballin_05>
opengl or something
<love-pingoo>
I think it's good enough. Freetennis uses openGL.
<Ballin_05>
hmmmm i seee
<Ballin_05>
this would be a high quality game with high quality textures :D
<pango>
love-pingoo: there's a compiler patch called memprof-ocaml... ftp://ftp.berlios.de/pub/mldonkey/pango/goodies/memprof-ocaml/
<love-pingoo>
I believe that there's more to gain in using openGL in a clever way than in switching to C (or at least not enough for justifying what you loose).
<Ballin_05>
i already have a good portion of the game written tooo
<love-pingoo>
pango: I also found "display" by filiatre, it only shows one value's representation, not the whole heap
<love-pingoo>
Ballin_05: written in caml ?
<love-pingoo>
you can also write the core in C and the game logic in caml
<Ballin_05>
nope C++
<Ballin_05>
alot of games use scripting languages for game logic
<love-pingoo>
yup
<Ballin_05>
D might be good too
<love-pingoo>
but ocaml is faster, so you can afford to do more stuff with it
<Ballin_05>
its actually faster then c++
<flux__>
wait a year and it'll be much faster again :-)
<love-pingoo>
depends on how you code: C++ is a superset of C, which is said to be faster than OCaml
<Ballin_05>
huh why ?
<flux__>
intel vs amd -race..
<Ballin_05>
i c
<Ballin_05>
well i kinda want to do the whole thing in D or Ocaml :D with a opengl bidning of course
<Ballin_05>
or SDL or something
ikaros_ is now known as ikaros
<ikaros>
since those two languages are pretty different you should have a favourite.. pick it ;)
<love-pingoo>
pango: that memprof-ocaml sounds interesting
<love-pingoo>
did you use it ? do you know if it's still working on 3.09 ?
<love-pingoo>
pango: didn't see the "pango" in the path.. I guess you used it :)
<pango>
I tried the version for 3.07 and failed at the time (didn't insist much, either); I haven't tried the version updated for 3.08.3
buluca has joined #ocaml
<flux__>
where's that version?
<flux__>
I find only the 3.07-version
<flux__>
I suppose one could downgrade to 3.07 for memory profiling
<pango>
flux__: see url above... updated by spiralvoice
<flux__>
oh, right
<love-pingoo>
I don't have much time for debugging these days so I'm looking for the lazy solution.. but I guess I'm dreaming and I can afford compiling a downgraded ocaml
<flux__>
does it patch against 3.09?
<flux__>
that's a very interesting piece of work, though
<flux__>
if it works :)
<love-pingoo>
it's a pity that lefessant spent only three days on it, as he claims
<love-pingoo>
he should have gotten into the crystal team, so his tool may now be mainstream
<ppsmimou>
love-pingoo: the patch is mostly applying
<ppsmimou>
(to 3.09.3)
<ppsmimou>
I guess it should be doable to update it
<love-pingoo>
cool
<love-pingoo>
I was trying on 3.08.3
<love-pingoo>
after all, liquidsoap compiles with 3.08.3
<love-pingoo>
ppsmimou: interested in packaging memprof-ocaml-3.09.3 ?
<setog3>
does we have a vect.length do know the lenght of a vector in a matrix ?
<pango>
isn't a matrix just an array of arrays ?
<setog3>
I use p
<setog3>
let v = [|1; 2; 3; 4|];;
<setog3>
p
<setog3>
p
<setog3>
p
<setog3>
p
<setog3>
p
<setog3>
arf
<setog3>
Array.make_matrix <-- I use this
<pango>
that returns an 'a array array
_velco has quit ["I'm outta here ..."]
<setog3>
hmm .. yes
<setog3>
and to get the number of column ?
<setog3>
a lenght array .. not sure
<pango>
if you use Array.length on the matrix, you'll get the "major" size, as I understand
_JusSx_ has quit [Client Quit]
<pango>
to get the "minor" size, you can run Array.length on any element of that array... make_matrix always create rectangular matrices
mon has joined #ocaml
<setog3>
yes rectangular but not square ;D .. so I must use Array.length on matrix.(0) for example
<pango>
yes
klapmuet1 has quit [Read error: 110 (Connection timed out)]
llama32 has joined #ocaml
shawn has quit ["This computer has gone to sleep"]
_JusSx_ has joined #ocaml
stevan_ has joined #ocaml
bluestorm has joined #ocaml
stevan has quit [Read error: 110 (Connection timed out)]
Demitar_ has joined #ocaml
Demitar has quit [Read error: 110 (Connection timed out)]
david_koontz has quit ["Leaving"]
<llama32>
hmmm
<llama32>
i cant 'a :: 'a list??
<llama32>
is there another way to do that? [i would assume so :|]
smimou has joined #ocaml
<malc_>
llama32: huh?
<llama32>
well a list is just (a :: (b :: (c :: ()))) right?
<malc_>
erm.. no () is a unit you mean []
<malc_>
but in general yeah
mikeX has joined #ocaml
<pango>
:: is right associative, so you don't need the parens... a :: b :: c :: [] is ok too
<llama32>
ah sorry
<pango>
and should be the same as [a;b;c]
<llama32>
i don't get why i can't a :: (some list of same type as a here)
<llama32>
This expression has type string * data but is here used with type
<llama32>
(string * data) list
<pango>
what's the error like ?
<pango>
the error is about the right part of the expression I guess ?
<malc_>
apparently ocaml infers the type of your second argument to :: as string * data
<mikeX>
are you sure it's 'a and not 'a list?
<llama32>
the second argument is 'a list, first argument is 'a
<llama32>
but i don't see why it shouldn't work
<pango>
but OCaml doesn't agree ;)
<mikeX>
well ocaml is not wrong if that's what you are saying : )
<malc_>
just do a `let x : (string * data) list = your_second_argument in ...'
<llama32>
it's complaining about the first argument being used as a list though... but unless the second argument is a list list, this shouldn't be happening should it :s
<mikeX>
llama32: it would help if you pasted the code somewhere
<pango>
flux__: I'm sure it would have useful uses ;)
<pango>
"16.8.7 Fine-tuning the debugger"
scanpat has joined #ocaml
<llama32>
anyone know if f# works on mono? or if there are attempts to make some other decent functional language for mono?
<llama32>
nemerle just looks like someone shat a closure onto C#
shawn has joined #ocaml
_fab has quit [Read error: 104 (Connection reset by peer)]
scanpat has quit ["Parti"]
<mellum>
Does anybody know about publications comparing reference counting and "real" GC? In particular I'm looking for those that support my assumption that reference counting is basically always a bad idea :)