RE: [Caml-list] ocamldebug and windows

["Mattias Waldau" <mattias.waldau@abc.se>]

The debugger is 40% of the reason I use ocaml. 
The other two reasons is typing 40%, and resonable speed 20%.

The debugger makes it possible to debug large programs, just litter 
the code with assert, run until assert fails and backstep.
(I spent a lot of time debugging VC++, and there you have to
run, put break point before, run again, move break point....)

Typing makes my program work when they compile.

Resonable speed makes it possible not to have the most complex
algorithms.

Since the debugger has problems under cygwin for larger programs 
(the debugger looses contact), I have even thought buying ibook or
powerbook, 
just to get the debugger work well on a laptop 
(linux and laptops: try getting wlan and acpi to work :-)

I only use the win32-version of ocaml before creating release versions
of 
the program, since cygwin cannot be shipped. (I haven't tried mingw)

/mattias

> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr 
> [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Chris Hecker
> Sent: Tuesday, October 22, 2002 5:57 PM
> To: Xavier Leroy; Dmitry Bely
> Cc: caml-list@inria.fr
> Subject: Re: [Caml-list] ocamldebug and windows
> 
> 
> 
> [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

-------------------
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