Debugging (response 1) 
Author Message
 Debugging (response 1)

Quote:
> Edgar Knapp says:

>> writes:
>> What can I expect in an Oberon programming environment?  How fast are
>> compiles?  Is there a de{*filter*}?  If so, is it integrated?  Are
>> compiles done in RAM, and can you run code directly from RAM?  What
>> features does the de{*filter*} have, if it exists?
> I think you have put your finger on one of the most severe
> shortcomings of the existing (ETH) Oberon environment: its complete
> lack of debugging support. All you get when your program misbehaves
> is a trap viewer with a cryptic summary of the call history and
> variable values.  I can hardly ever figure out anything useful from
> this. Even the old UNIVAC Pascal compiler supplied better error
> messages 15 years ago.
> The Oberon books (Programming in Oberon, Project Oberon, Oberon
> system) are no help either. They have a whopping total of 2 pages or
> so devoted to this.

Rubbish.  The comment abuot a 'cryptic' summary is rather subjective,
and from my experience, just someone who doesn't understand
something.  As a real example, when version 1.2 of the Oberon system
was released from ETH, I wanted to add some files to the system
without having to type 'System.CopyFromDos fn => fn ~' for each file,
so I took a long long look at the filename mapping text file.

When I felt I understood it, I modified it with a binary editor.  I
then proceeded to use the system for several days, then I started to
get NIL pointer assignment errors.

Giddy in my 'bug' discovery, I saved the trap window to a text file,
and promptly mailed it to the developer.  (I am in Baltimore, MD.
The developer is in Zurich.)  Within several hours, I had received
the results:  I had modified FileName.Text by myself.

(Being an Oberon FNG (F..king New Guy) at the time), I was amazed
beyond belief.  From just the trap listing, he was able to determine
EXACTLY what I had done.  This facility is FAR from useless.  In
fact, because it is a PMD, it usually gives better information than a
de{*filter*}.  Couple this with the fact that Oberon does not work in the
single monolithic executable ideology to which most people are
accustomed, a 'de{*filter*}' will not work as expected.

How would you propose to debug something that is an extension of
another system?  It can be done, but to what purpose?

As two other anecdotal pieces of evidence:  A guy where I work LIVES
in the de{*filter*}.  Will run his program, and if it doesn't work, he
jumps right into the de{*filter*} to find out what is wrong.  He spends
more time setting breakpoints than it would take to open a file and
write the information he wants.  His productivity sucks, and his code
is a hodgepodge.

I have been working on a 32bit DOS extender & 32bit flat memory model
Oberon system, and have not been able to use a de{*filter*} at all.  The
assembly language code was a real pain in the arse to figure out
without a de{*filter*} (try doing DPMI calls w/o a good reference & no
de{*filter*}.  Once you switch to PM, you have no access to DOS, so file
& screen output is out of the question.  You have to either figure
out what happened, or write to a printer port directly.)

The Oberon, on the other hand, has been the easiest code in the world
to debug.  I've never been able to work in C++ or C in the way that I
work in Oberon!  (Given that you stay away from the SYSTEM module as
much as possible).

<FLAME ON>
From my experience, people that require de{*filter*}s are usually BF&I
programmers.  They usually do not fully understand what they are
doing, and can usually get it to work on their test cases by tweaking
it after running it thru the de{*filter*}.

This is, of course, the general case.  There are good reasons to have
a hardware de{*filter*} (cracking old Apple ][+ games, for one thing),
but I have never encountered a reason to NEED a de{*filter*} on software
(except, maybe, if you are using some crappy third party library or
tool (Hmmm, ProtoGen perhaps?))
<FLAME OFF>

Taylor "No De{*filter*}s" Hutt
Championing 30 lashes for all C++ lovers!



Sun, 22 Oct 1995 09:21:45 GMT  
 Debugging (response 1)

Quote:

>> Edgar Knapp says:
>> I think you have put your finger on one of the most severe
>> shortcomings of the existing (ETH) Oberon environment: its complete
>> lack of debugging support. All you get when your program misbehaves
>> is a trap viewer with a cryptic summary of the call history and
>> variable values.  I can hardly ever figure out anything useful from
>> this. Even the old UNIVAC Pascal compiler supplied better error
>> messages 15 years ago.

>> The Oberon books (Programming in Oberon, Project Oberon, Oberon
>> system) are no help either. They have a whopping total of 2 pages or
>> so devoted to this.
>Giddy in my 'bug' discovery, I saved the trap window to a text file,
>and promptly mailed it to the developer.  (I am in Baltimore, MD.
>The developer is in Zurich.)  Within several hours, I had received
>the results:  I had modified FileName.Text by myself.

>(Being an Oberon FNG (F..king New Guy) at the time), I was amazed
>beyond belief.  From just the trap listing, he was able to determine
>EXACTLY what I had done.  This facility is FAR from useless.  In
>fact, because it is a PMD, it usually gives better information than a
>de{*filter*}.  Couple this with the fact that Oberon does not work in the
>single monolithic executable ideology to which most people are
>accustomed, a 'de{*filter*}' will not work as expected.

If only the designers of the trap window can figure out the meaning of
its contents, it's useless to me (and from your response I conclude to
you as well).

Quote:
>How would you propose to debug something that is an extension of
>another system?  It can be done, but to what purpose?

>As two other anecdotal pieces of evidence:  A guy where I work LIVES
>in the de{*filter*}.  Will run his program, and if it doesn't work, he
>jumps right into the de{*filter*} to find out what is wrong.  He spends
>more time setting breakpoints than it would take to open a file and
>write the information he wants.  His productivity sucks, and his code
>is a hodgepodge.

What are insinuating? That everyone who uses a symbolic run-time
de{*filter*} is a lousy programmer?

Careful design goes a long way towards correctness. I would be the
last person to dispute that.  But as I am fallible, I tend to be able
to catch my mistakes more easily with a symbolic de{*filter*}. Who are you
to tell me otherwise?

Quote:
>I have been working on a 32bit DOS extender & 32bit flat memory model
>Oberon system, and have not been able to use a de{*filter*} at all.  The
>assembly language code was a real pain in the arse to figure out
>without a de{*filter*} (try doing DPMI calls w/o a good reference & no
>de{*filter*}.  Once you switch to PM, you have no access to DOS, so file
>& screen output is out of the question.  You have to either figure
>out what happened, or write to a printer port directly.)

This is the oberon group, not the MessDOS.acroyms.obscure group.

- Show quoted text -

Quote:
>The Oberon, on the other hand, has been the easiest code in the world
>to debug.  I've never been able to work in C++ or C in the way that I
>work in Oberon!  (Given that you stay away from the SYSTEM module as
>much as possible).

><FLAME ON>
>From my experience, people that require de{*filter*}s are usually BF&I
>programmers.  They usually do not fully understand what they are
>doing, and can usually get it to work on their test cases by tweaking
>it after running it thru the de{*filter*}.

>This is, of course, the general case.  There are good reasons to have
>a hardware de{*filter*} (cracking old Apple ][+ games, for one thing),
>but I have never encountered a reason to NEED a de{*filter*} on software
>(except, maybe, if you are using some crappy third party library or
>tool (Hmmm, ProtoGen perhaps?))
><FLAME OFF>

Get off your high horse. I would like to see Oberon succeed as much as
you. I cannot imagine this success without decent debugging
facilities. And what exists in this respect is ridiculously
inadequate.

Quote:
>Championing 30 lashes for all C++ lovers!

While I despise anything that starts with C myself (or MS for that
matter), your intolerance disgusts me.

Edgar

.
.
.
.
.
.
.
.
.
.
.
.
.
.
--

Purdue University                      
Department of Computer Sciences         +1 (317) 494-6028 (voice)
West Lafayette, IN 47907-1398           +1 (317) 494-0739  (fax)



Wed, 25 Oct 1995 03:19:53 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Debugging (response 2)

2. Function return values revisted (response to response)

3. Python 2.1.1 ASP/Response object does not HONOR Response.End()

4. httplib: response.read() vs response.read(size)

5. Slightly Off Topic : restrictions on the response part in a SOAP-response

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

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

8. Debug/Anti-debug/compression help wanted

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

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

11. debug Python interpreter work with the debug swig dll

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

 

 
Powered by phpBB® Forum Software