Debugging in Oberon 
Author Message
 Debugging in Oberon

While working on my lastest Oberon System 3 project (a PacMan game),
I've come to the following conclusion, that the debugging facilities
in Oberon Sys 3 are inadequete at best, and just plain suck at
worst.  

Actually I've come full circle in this conclusion.  When I first
tried Oberon (way back when there was only 1 Oberon system), I
was slightly intimidated by the "Trap" window that would on
occasion pop up and glare at me with all it's information and
little explanation of what any of it meant.  Of course these
were traps from other people's programs (mostly without source
code), so of course it was useless to me.  

When I got a hold of Oberon/F (the first Oberon that I did some
serious programming in) I began to see the usefullness of the trap
window.  Oberon/F has one of the best post-mordem de{*filter*}s I've
seen.  I can click on one of the hot-links and go directly to the
source code (if it was available), all the data structures are
completely visable.

The debugging facilities in Oberon V4 have come along nicely
too. (Well at least V4 for Windows 3.1 and Windows 95.  I'm
still hoping V4 will get "unified" one of these days.)  Instead
of using hotlinks like Oberon/F, it uses Folds to hide the
nesting of the different data structures.  My gut instict tells
me that this could be a problem for data structures with cycles
(when a Fold in a trap window reaches a cycle, does it stop,
or keep inserting more folds?), but I've never tested that.
The Win 95 version even has a runtime de{*filter*}.  I have heard
some "purists" in this NG claim that Wirth was somehow against
runtime de{*filter*}s.  From reading his work, however, I got the
impression that he didn't implement it for time considerations,
then later decided that there were some advantages to working
without one.

Oberon System 3, however, seems stuck in the Oberon debugging
dark ages.  The main problem is that the trap window only shows
simple variables.  If you have a pointer, you only get the
address it is pointing to, and NONE of the member variables.
If your program is heavily object-oriented, it's highly
possible that the "nil reference" that caused the trap is
buried 1, 2 or 3 levels deep in your data structure.  But
all you'll get from the System 3 window is the value of
the pointer to the structure, which will probably look just
fine.  This leaves only the tried and true "trace statement"
method for ferreting errors.  I would try to change this
on my own, but for some reason the System module is not
included in the System 3 source code.  I hope the System 3
guys will either update the debugging facilities or make
the System module accessable so somebody else can.

*Mycroft*



Tue, 29 Feb 2000 03:00:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Debugging in Oberon

2. Debug/Kill + Debug/Run = RB Crash

3. can someone email me Debug.com not debug.exe

4. Debug/Anti-debug/compression help wanted

5. can someone please send me debug.com and not debug.exe

6. LE, SYM,SEPARATE, and debugging withOUT the debug tool

7. debug Python interpreter work with the debug swig dll

8. Python-2.1 Debug libs zip is missing tcl &tk debug libs

9. Debug won't debug

10. Frage Oberon 3 / Question Oberon 3

11. CD-Oberon - Oberon/F

12. CD-Oberon Oberon 3 Printer Problem

 

 
Powered by phpBB® Forum Software