Integrated debugger in Oberon? 
Author Message
 Integrated debugger in Oberon?

I've been programming for years using Turbo Pascal 5.0 on an 80386 AT
clone, and have long been awaiting a 32-bit version of this compiler.
Having become somewhat impatient, I've begun thinking about other
options.  I don't know anything about Oberon (except that it's an
outgrowth of Pascal and Modula-2), nor do I know anything to speak of
about Modula-2, nor do I know anything about object-oriented programming.
But I do know that Borland's fast compilation and integrated environment
vastly sped up my development time.

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?  What benefits would I have in learning
Oberon, rather than, for instance, waiting for Borland's 32-bit Pascal for
NT, or getting C++ and OS/2 or some version of Unix and learning those?

Any help would be appreciated.

------------------------------------------------------------------------



Thu, 19 Oct 1995 09:37:46 GMT  
 Integrated debugger in Oberon?

Quote:

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

Compiles are blazingly fast. The relevance of your "in RAM" questions
I fail to see.

Quote:
>What benefits would I have in learning
>Oberon, rather than, for instance, waiting for Borland's 32-bit Pascal for
>NT, or getting C++ and OS/2 or some version of Unix and learning those?

Oberon is a superbly designed language. It is simple, regular, modular,
i.e. by these criteria the exact opposite of C++. The Oberon
Development Environment is not as clearly a winner, but I heard that
there are a number of other implementation efforts underway.  Let's
hope we can then edit, compile, run, and debug Oberon with standard
tools (e.g. emacs, gdb), in resizable, movable windows.

Edgar

--

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



Thu, 19 Oct 1995 12:00:46 GMT  
 Integrated debugger in Oberon?

Quote:

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

Although I cannot comment on the UNIVAC Pascal Compiler's error-messages
(how do you connect the compiler and de{*filter*} here??), I just can say that
the trap-info contains the state of the program when the trap occurred. You
can in addition see the value of the variable instances, the location within
the code, where the error occurred as well as some module information. This
follows exactly the policy pursued at ETH that de{*filter*}s must not be used to
develop prgrams. As a consequence there is not a lot of support for such a
tool. (If I remember well though, and I probably do, there were some thesises
on symbolic de{*filter*}s, but I do not know what happened to the result.

Quote:
>Oberon is a superbly designed language. It is simple, regular, modular,
>i.e. by these criteria the exact opposite of C++. The Oberon
>Development Environment is not as clearly a winner, but I heard that
>there are a number of other implementation efforts underway.  Let's
>hope we can then edit, compile, run, and debug Oberon with standard
>tools (e.g. emacs, gdb), in resizable, movable windows.

emacs and gdb are unlikely. Windows are RESIZABLE and MOVABLE. What you
probably mean is overlapping windows instead of tiling windows. These you
probably will not get. Honestly, why would you want overlapping windows?
The algorithms to handle them do not correspond to the additional profit
you get from the overlapping windows.

Thomas



Thu, 19 Oct 1995 19:47:55 GMT  
 Integrated debugger in Oberon?

Quote:
>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?  What benefits would I have in learning
>Oberon, rather than, for instance, waiting for Borland's 32-bit Pascal for
>NT, or getting C++ and OS/2 or some version of Unix and learning those?

For the ETHZ-Version of the Oberon-System see the other postings.

For the Amiga a comercial version of the Oberoncompiler exists and You can
buy a source-level de{*filter*}. But You never get the complete system for the
Amiga.

Sven
--
Internet:                               | Yellow Post:
                                        |     Sven Gohlke                    

                                        |     12167 Berlin



Thu, 19 Oct 1995 20:43:32 GMT  
 Integrated debugger in Oberon?

Quote:


>Although I cannot comment on the UNIVAC Pascal Compiler's error-messages
>(how do you connect the compiler and de{*filter*} here??), I just can say that
>the trap-info contains the state of the program when the trap occurred. You
>can in addition see the value of the variable instances, the location within
>the code, where the error occurred as well as some module information. This
>follows exactly the policy pursued at ETH that de{*filter*}s must not be used to
>develop prgrams. As a consequence there is not a lot of support for such a
>tool. (If I remember well though, and I probably do, there were some thesises
>on symbolic de{*filter*}s, but I do not know what happened to the result.

Then the (UNIVAC) compiler generated code for run-time error handling
to produce an executable. Do you see the connection now?

In theory, yes, you are supposed to be able to see variable values,
etc. But structured variables (except strings) are not displayed, and
the hex value of the processor's program counter is meaningless. Wirth
and Gutknecht have the guts to call this "A Facility for Symbolic
Debugging" (Section 12.9 of Project Oberon).  Why not be honest and
say "we don't supply a de{*filter*} and here are our reasons"?

Quote:
>emacs and gdb are unlikely. Windows are RESIZABLE and MOVABLE. What you
>probably mean is overlapping windows instead of tiling windows. These you
>probably will not get. Honestly, why would you want overlapping windows?
>The algorithms to handle them do not correspond to the additional profit
>you get from the overlapping windows.

First of all, Oberon viewers are not windows. Secondly, viewers are
not freely resizable. Pray tell how to change the width of a viewer?
Viewers are not freely movable either. How do you center a viewer on
the screen, for instance? Viewers do overlap, though. If you open a
second viewer in a track, the first one is partly obscured. Please
think before responding.

How can you tell how much I profit from "real" windows (such as on the
Mac or under X)? For instance, I arrange my (20 or 30) windows so that
I can at all times get most of them foremost with a single click. Have
you ever tried that in Oberon? What kind of excuse is: "Sorry, the
algorithms are too complex"?

Edgar

--

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



Fri, 20 Oct 1995 02:00:12 GMT  
 Integrated debugger in Oberon?

Quote:

>the code, where the error occurred as well as some module information. This
>follows exactly the policy pursued at ETH that de{*filter*}s must not be used to
>develop prgrams. As a consequence there is not a lot of support for such a
>tool. (If I remember well though, and I probably do, there were some thesises
>on symbolic de{*filter*}s, but I do not know what happened to the result.

Just what exactly is the reason for this policy at ETH?  Is the
purpose to encourage people to choose design methodologies that will
have less chance of a bug in the first place?  That's a good idea.

Or is it to force them to spend hours poring over a listing to find
the trivial typo that changed one variable name into another?  That's
not such a good idea...

Quote:
>emacs and gdb are unlikely. Windows are RESIZABLE and MOVABLE. What you
>probably mean is overlapping windows instead of tiling windows. These you
>probably will not get. Honestly, why would you want overlapping windows?
>The algorithms to handle them do not correspond to the additional profit
>you get from the overlapping windows.

Overlapping windows are incredibly useful.  Given rectangular bitblt
and the ability to allocate off-screen bitmaps, the "algorithms to
handle them" comprise only around a thousand lines of code.
Lest anybody think I am making this figure up, the code in Plan 9
that does overlapping windows is 1031 lines of C.  The algorithms
are very simple if you do them right.  (See Pike, "Graphics in
Overlapping Bitmap Layers", Transactions on Graphics 2(2).)


Fri, 20 Oct 1995 03:39:53 GMT  
 Integrated debugger in Oberon?

Quote:



>In theory, yes, you are supposed to be able to see variable values,
>etc. But structured variables (except strings) are not displayed, and
>the hex value of the processor's program counter is meaningless. Wirth
>and Gutknecht have the guts to call this "A Facility for Symbolic
>Debugging" (Section 12.9 of Project Oberon).  Why not be honest and
>say "we don't supply a de{*filter*} and here are our reasons"?

Admitted, I also would support having a "free-er" voice raising here.

Quote:
>>emacs and gdb are unlikely. Windows are RESIZABLE and MOVABLE. What you
>>probably mean is overlapping windows instead of tiling windows. These you
>>probably will not get. Honestly, why would you want overlapping windows?
>>The algorithms to handle them do not correspond to the additional profit
>>you get from the overlapping windows.
>First of all, Oberon viewers are not windows. Secondly, viewers are
>not freely resizable. Pray tell how to change the width of a viewer?
>Viewers are not freely movable either. How do you center a viewer on
>the screen, for instance? Viewers do overlap, though. If you open a
>second viewer in a track, the first one is partly obscured.

If you actually read the original message you realize that the person
there was comaplining about having movable and resizable windows. So
from my experience with the system I have to assume he means freely
movable and partially overlappable. I "confess" not having been clear
on this issue. Before I left the Ceres and Oberon operating system
the widht, more correctly the ratio between user-track and system-track
could be adjusted. Of course this effected ALL windows/viewers.

Quote:
>Please think before responding.

This one's got forwarded to /dev/null

Quote:
>How can you tell how much I profit from "real" windows (such as on the
>Mac or under X)? For instance, I arrange my (20 or 30) windows so that
>I can at all times get most of them foremost with a single click. Have
>you ever tried that in Oberon? What kind of excuse is: "Sorry, the
>algorithms are too complex"?

One of the first rules we learned back in CS undergrad-courses was the
80-20-rule. For 20 percent of the functionality we spend 80 percent of
the time to develop and to run. Having this in mind I gotta say it is
not worth implementing these algorithms especially not if an environment
for students, to practice in has to be created.

Thomas



Fri, 20 Oct 1995 02:54:35 GMT  
 Integrated debugger in Oberon?
Quote:

>What you
>probably mean is overlapping windows instead of tiling windows. These you
>probably will not get. Honestly, why would you want overlapping windows?

Well, I for one am not so concerned about overlapping as movable in two
dimensions. If there's a way to move the division between the tracks
by a few pixels, I haven't been able to find it. I'd like to be able to
edit on a slightly wider window from time to time without losing the system
track.
-greg
---
Greg DeLozier/Senior Scientific Analyst/L{*filter*}Defense Systems


Fri, 20 Oct 1995 10:56:56 GMT  
 Integrated debugger in Oberon?

Quote:

>>the code, where the error occurred as well as some module information. This
>>follows exactly the policy pursued at ETH that de{*filter*}s must not be used to
>>develop prgrams. As a consequence there is not a lot of support for such a
>>tool. (If I remember well though, and I probably do, there were some thesises
>>on symbolic de{*filter*}s, but I do not know what happened to the result.
>Just what exactly is the reason for this policy at ETH?  Is the
>purpose to encourage people to choose design methodologies that will
>have less chance of a bug in the first place?  That's a good idea.
>Or is it to force them to spend hours poring over a listing to find
>the trivial typo that changed one variable name into another?  That's
>not such a good idea...

The former is the idea. People should be taught developping a program
and by doing so avoiding the mistakes in the first place. Profs realized
that the better the de{*filter*} environment, the more students just go and
gamble until they have a program which mostly fails to resist/pass the
test from the TAs. (Assistants may have some better environment as I
pointed out in my original article, since there are moments you really
need a good de{*filter*}.)
Sidenote: Developers are actually also aware that the faster the edit-
compile-run cycle the less students actually think BEFORE compiling and
executing. But this seems not to be changeable...

Quote:
>Overlapping windows are incredibly useful.  Given rectangular bitblt

I am willing to change my opinion, although I have never really missed
overlapping windows as long as I could tile them. However instead of
just hearing "they are useful" I'd like to get to know WHY they are
useful and HOW OFTEN they are.

Thomas



Fri, 20 Oct 1995 13:22:10 GMT  
 Integrated debugger in Oberon?

Quote:

>The former is the idea. People should be taught developping a program
>and by doing so avoiding the mistakes in the first place. Profs realized
>that the better the de{*filter*} environment, the more students just go and
>gamble until they have a program which mostly fails to resist/pass the
>test from the TAs. (Assistants may have some better environment as I
>pointed out in my original article, since there are moments you really
>need a good de{*filter*}.)

Ah, so there ARE moments when you really need a good de{*filter*}.

For pedagogical reasons, it may indeed be desirable to not have a
de{*filter*} in a teaching system.  I can certainly see arguments in favor
of this.  However, what's appropriate for a teaching system and what's
appropriate for a production software development environment are two
different things.

Oberon seems like a very nice language, and I would really like to
develop some serious programs in it.  However, I have no desire to
waste my time fighting with an environment that's been crippled for
pedagogical reasons.  If all Oberon implementors insist on providing
pedagogically crippled environments, then in order to serious work
I'd first have to create an Oberon system of my own.  Now that might
be fun, but I have lots of other things to do...

Quote:
>>Overlapping windows are incredibly useful.  Given rectangular bitblt
>I am willing to change my opinion, although I have never really missed
>overlapping windows as long as I could tile them. However instead of
>just hearing "they are useful" I'd like to get to know WHY they are
>useful and HOW OFTEN they are.

I can't speak for other people, but this is why overlapping windows
are essential for me: I get eye strain from the microscopic fonts that
many people use.  I need a medium sized font, with calligraphic
strokes, to avoid squinting.  (The Syntax font that comes with Oberon
is just horrible, IMHO.)  I generally work with just three windows: a
full height window containing whatever I'm editing, a command window,
and a window containing online documentation.  With the fonts I use,
the screen is not wide enough to accomodate the editor and the doc
window simultaneously.  Consequently I need to overlap them.

(Oh yeah, I forgot about the window for reading news... :-)
--

In Hell they run VMS.



Fri, 20 Oct 1995 15:43:50 GMT  
 Integrated debugger in Oberon?

Quote:
>Ah, so there ARE moments when you really need a good de{*filter*}.

I have never really stated the contrary!

Quote:
>For pedagogical reasons, it may indeed be desirable to not have a
>de{*filter*} in a teaching system.  I can certainly see arguments in favor
>of this.  However, what's appropriate for a teaching system and what's
>appropriate for a production software development environment are two
>different things.
>Oberon seems like a very nice language, and I would really like to
>develop some serious programs in it.  However, I have no desire to
>waste my time fighting with an environment that's been crippled for
>pedagogical reasons.  If all Oberon implementors insist on providing
>pedagogically crippled environments, then in order to serious work
>I'd first have to create an Oberon system of my own.  Now that might
>be fun, but I have lots of other things to do...


to spread it for several reasons, but if it exists they might not mind
handing it out on request.

Quote:
>>I am willing to change my opinion, although I have never really missed
>>overlapping windows as long as I could tile them. However instead of
>>just hearing "they are useful" I'd like to get to know WHY they are
>>useful and HOW OFTEN they are.
>I can't speak for other people, but this is why overlapping windows
>are essential for me: I get eye strain from the microscopic fonts that
>many people use.  I need a medium sized font, with calligraphic
>strokes, to avoid squinting.  (The Syntax font that comes with Oberon
>is just horrible, IMHO.)  I generally work with just three windows: a
>full height window containing whatever I'm editing, a command window,
>and a window containing online documentation.  With the fonts I use,
>the screen is not wide enough to accomodate the editor and the doc
>window simultaneously.  Consequently I need to overlap them.

The font is at least bad. However if you knew the trouble there was to
convince certain people that a scroll bar indicating the relative position
within the document is actually needed you won't take the effort to
ask for a biger font....

You still fail to tellme why you need partially overlapping windows [in
the sense I pointed out: lower right corner with upper left corner] as
opposed to tiling. [Before you flame, I know they also overlap partially,
but not in the general way.]

Thomas



Fri, 20 Oct 1995 17:09:49 GMT  
 Integrated debugger in Oberon?
It's a simple matter of real-estate management. If I'm allowed arbitrarily
overlapping windows, I can effect many more types of allocations of screen real
estate than if I'm not. With MacOberon on my small monitors (two 13" ones), I
have a terrible time, even though one is ok for simultaneous read/edit/compile
activity elsewhere (e.g. MPW).

In fact, I don't think I've ever used a tiled window arrangement, even with a
21" monitor and 1280x1024 pixel dimensions. It's just too wasteful in the
general case, and, as was pointed out previously, the code to support it isn't
nearly as hard as many make it.
--

-- Bob



Mon, 23 Oct 1995 11:16:45 GMT  
 Integrated debugger in Oberon?

Quote:

>>Oberon seems like a very nice language, and I would really like to
>>develop some serious programs in it.  However, I have no desire to
>>waste my time fighting with an environment that's been crippled for
>>pedagogical reasons.  If all Oberon implementors insist on providing
>>pedagogically crippled environments, then in order to serious work
>>I'd first have to create an Oberon system of my own.  Now that might
>>be fun, but I have lots of other things to do...

>to spread it for several reasons, but if it exists they might not mind
>handing it out on request.

The Oberon compiler for the Amiga (Oberon-2) comes with a source level
de{*filter*}.

Peter Braeuer



Mon, 23 Oct 1995 13:34:56 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Debugger for Oberon-System?

2. Debuggers, Static Debuggers, and Algebraic Steppers

3. using python debugger (pdb) inside emacs debugger mode ...

4. Frage Oberon 3 / Question Oberon 3

5. CD-Oberon - Oberon/F

6. CD-Oberon Oberon 3 Printer Problem

7. Oberon System 3 / Native Oberon projects

8. inquiry about Visual Oberon/PC Native Oberon System 3

9. Native Oberon: Getting DOS based installation out of Oberon-0

10. Oberon-2 in Native Oberon System 3

11. modula2-to-Oberon, C++-to-Oberon

12. oberon kernel sources (Article 4814 in comp.lang.oberon)

 

 
Powered by phpBB® Forum Software