From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA26120; Tue, 22 Oct 2002 18:11:41 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA26121 for ; Tue, 22 Oct 2002 18:11:40 +0200 (MET DST) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g9MGBd521051 for ; Tue, 22 Oct 2002 18:11:39 +0200 (MET DST) Received: (qmail 61759 invoked from network); 22 Oct 2002 16:06:29 -0000 Received: from adsl-host-sf-228.apexworld.net (HELO checkerlap.d6.com) (66.114.212.228) by relay1.pair.com with SMTP; 22 Oct 2002 16:06:29 -0000 X-pair-Authenticated: 66.114.212.228 Message-Id: <4.3.2.7.2.20021022083244.035ebfb8@mail.d6.com> X-Sender: checker@mail.d6.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Oct 2002 08:56:40 -0700 To: Xavier Leroy , Dmitry Bely From: Chris Hecker Subject: Re: [Caml-list] ocamldebug and windows Cc: caml-list@inria.fr In-Reply-To: <20021022095740.A6289@pauillac.inria.fr> References: <20021021152135.E12164@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [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