<usualsuspect>
The problem is searching for the longest sequence of this collatz conjecture thing
cago has quit [Ping timeout: 246 seconds]
<usualsuspect>
I'm not sure if that matters, my program locks up around number 77577 but if I manually try these in another script (same code) it works
<usualsuspect>
so I suspect my recursion is causing problems
<fasta_>
thelema: can odb check for new versions?
<fasta_>
thelema: because odb needs --force foo to install the newer version of foo
hkBst has quit [Quit: Konversation terminated!]
<fasta_>
thelema: it's also not clear whether --info contacts a server.
<fasta_>
thelema: in the --help it should say something like 'using the Internet or using local information'
<usualsuspect>
I don't get it, I've switched all constructs but somewhere around 77500 is a magic number where it just dies
<usualsuspect>
What's a good solution to looper over numbers 1 .. 1,000,000?
<usualsuspect>
I don't have a tail-recursive range function
<usualsuspect>
I tried to replace it with a recursive function that simply calls itself with i+1
<usualsuspect>
but that too dies around the same mark
<mfp>
usualsuspect: runs for me with a 8 MB stack; also AFAICS your functions are properly tail-recursive
<usualsuspect>
is 8MB stack standard of a special param?
<fasta_>
usualsuspect: works for me.
<fasta_>
usualsuspect: last line is Checking 1000001
<usualsuspect>
Yeah, <= is wrong ;)
<usualsuspect>
then my OCaml must be broken
<usualsuspect>
In fact I have 3.11.2
<mfp>
oh, this one is obviously not a tail call but it doesn't look harmful > let steps = calc start 1 in
<usualsuspect>
mh
emmanuelux has joined #ocaml
<mfp>
usualsuspect: you can try to change your stack size with ulimit -s (and maybe the l option in OCAMLRUNPARAM, but can't remember if it applied only to bytecode, see man ocamlrun) and see if the depth changes
<usualsuspect>
I'll give it a try, although I don't even get a Stack Overflow, it just keeps looping
<usualsuspect>
It's partially prints a line but that's it, CPU at 100% and no further output
<usualsuspect>
That's okay though, I'll try it somewhere else where I can upgrade OCaml
<usualsuspect>
I have to say, OCaml/fp is fantastic, it's something completely different (in a good way) after writing imperative stuff for years :)
eni has joined #ocaml
eni has quit [Client Quit]
eni has joined #ocaml
<fasta_>
mfp: don't you think it's kind of a bad thing that a program just dies?
<fasta_>
mfp: IMHO, it should never die.
<fasta_>
mfp: it should simply switch to heap allocating stack frames.
<fasta_>
It could also output a warning like 'now entering heap allocating stack frames mode'.
<fasta_>
But failing is a failure on the RTS developers, imho.
thomasga has joined #ocaml
<_andre>
hello
<flux>
fasta_, well, I suppose it still doesn't matter, as you can have just as much stack as you like..
<_andre>
i'm writing stubs for a C library that takes callbacks and uses pthreads internally
<_andre>
what are the guidelines for using caml_c_thread_register()?
<fasta_>
flux: I think the point of a computer is that it understands a formal language.
<fasta_>
flux: I don't think stack size is part of the OCaml specification.
<fasta_>
flux: or if it is, it's a bad spec.
<_andre>
is it just a matter of doing caml_c_thread_register(); caml_callback(...); caml_c_thread_unregister(); ?
emmanuelux has quit [Ping timeout: 268 seconds]
pollux has quit [Ping timeout: 265 seconds]
<_andre>
hmm i'm getting a segfault on caml_c_thread_register
<diml>
_andre: you also need caml_acquire/release_runtime_system
<diml>
also, make sure that the Thread module is initialized before calling caml_c_thread_register
<_andre>
diml: thanks. do i need to call any function from the Thread module or is it just a matter of compiling with -thread?
<diml>
_andre: toplevel declaractions of the Thread module must be executed before the first call to caml_c_thread_register, if you have a reference to Thread in the module of your library it should work
ftrvxmtrx has quit [Quit: Leaving]
eni has quit [Ping timeout: 248 seconds]
<diml>
_andre: i did that once, i added "let _ = Thread.self ()" at the beginning of the module
<_andre>
it's not segfaulting now, but caml_c_thread_register seems to block forever
usualsuspect has quit [Quit: leaving]
gnuvince has quit [Ping timeout: 256 seconds]
gnuvince has joined #ocaml
jave has quit [Read error: Connection reset by peer]
jave has joined #ocaml
avsm has joined #ocaml
pangoafk is now known as pango
Anarchos has joined #ocaml
sepp2k has quit [Ping timeout: 246 seconds]
ftrvxmtrx has joined #ocaml
pango has quit [Remote host closed the connection]
pango has joined #ocaml
thomasga has quit [Quit: Leaving.]
sepp2k has joined #ocaml
Yoric has quit [Ping timeout: 252 seconds]
eikke has quit [Ping timeout: 245 seconds]
cdidd has joined #ocaml
mfp has quit [Ping timeout: 252 seconds]
<_habnabit>
I appear to be running into issues with hashtbls getting too big; I just got a Stack_overflow where every entry on the stack was in hashtbl.ml
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
<_habnabit>
maybe I should just use maps for everything always
<mfp>
_habnabit: doesn't that mean you're running into worst-case behavior (several thousand elements in the same bucket), i.e. dysfunctional hash function anyway?
<_habnabit>
maybe!
<_habnabit>
guess I should figure that out
fraggle_ has quit [Remote host closed the connection]
avsm has quit [Quit: Leaving.]
fraggle_ has joined #ocaml
paradoja has joined #ocaml
<_habnabit>
mfp, hmm, I don't know what the distribution is supposed to look like, but I made a histogram of the bucket sizes in a typical (but smaller) hashtbl