[Due to the recent s/n and flaming, I feel it necessary to caveat the 
following mail: I'm not trying to flame, these are just questions about 
engineering tradeoffs, and I love ocaml and motherhood and apple pie (or 
tart tatin or whatever is patriotic in France, which actually happens to be 
my favorite country, but I digress!).]

>It is true that time-travel in the presence of I/O is, in general,
>impossible.  (You can't "un-send" the network packets that were
>already sent!)  However, I'd like it to work at least for programs
>that read or write regular files, as in the example above.  Under
>Unix, fork() gets us 90% there -- there is still an issue with the
>reading/writing position being shared (not duplicated) between the
>parent and child process, but we are considering hacks to work around
>this.

Is all of this really worth it when compared to having a cross-platform 
"normal" debugger, especially if that debugger architecture could work on 
native code as well?  In other words, it seems like we're giving up a lot 
for this time-traveling feature.  I've played with it a bit, and it seems 
fine, but the fact that it's central to the debugger architecture makes 
some other things harder (like porting it :).

What was the impetus for doing it?  I'd assume the person who wrote the 
debugger thought it was cool and/or had it as a research project, and so 
that's what got written.  Which is fine, I'm not really complaining, I'm 
just trying to understand it.

I was also surprised that the debugger couldn't eval and link in arbitrary 
ocaml code, especially since a) the debugger works only on bytecode, and b) 
caml already has a toplevel.

Has anyone looked at writing a debugging plugin for gdb or something?  My 
program can't run in bytecode because it's got feedback loops based on 
framerate, so I have to run in native.  It'd be nice to be able to debug 
above the _Unix__fun_1470 level.  It seems like the native code gc frames 
have a fair amount of information in them (values on the stack pointing to 
the heap), and you could augment that info for unboxed values on the stack, 
etc.

I don't know how easy it is to extend gdb, though.

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners