Ouch! (Major pain with Oberon-2) 
Author Message
 Ouch! (Major pain with Oberon-2)

Well, here I went *way* out on a limb selling the portability and general
wonderfulness of the Oberon system. Then I just tried to move some image
processing code to SPARC-Oberon (where it ultimately has to run) and
guess what?

        the type BYTE has been *removed* from Oberon-2. (!)

It's not even in the language report. Why is this? Did someone decide
that a one-byte type that went from 0-255 was bad for me? Did it get
moved somewhere else? I'm just trying to make a 2-d array of bytes to hold
indices into a color table. I can't do this with SHORTINTs since they go
from -128 to 127, and I can't use INTEGER since the data comes in the
file as a BYTE stream.

Am I missing something? Or did I bet on the wrong horse, and I'm going to
end up looking like an idiot with code that's cluttered up with ORD &
CHR conversions to & from CHAR variables?

Well, I realize that Dr Wirth & ETH aren't on Earth to please me, but I
feel like I've been *had.*. It never occurred to me that anyone would
willingly break code in a presumably minor revision to a language spec.

-----

Question 2: Has anyone had any success using the floppy backup system in
Oberon-386? I get i/o errors every time I try to use Backup.Format. Any
suggestions?

-greg
---
Greg DeLozier/Senior Scientific Analyst/L{*filter*}Defense Systems



Sat, 28 Oct 1995 01:57:24 GMT  
 Ouch! (Major pain with Oberon-2)
Well, after porting the previous message about the removal of the BYTE
type, I went and re-examined some documentation from all three of the
MSDOS, Mac, and SPARC Oberon systems. Way down in the bottom of the Oberon-2
report is a section about a module called SYSTEM, in which lives a type called
BYTE. It doesn't look like you can do math on this thing, and I'm not
real sure what happens when you have a BYTE with, say, a value of 231 and
want to add it to another byte with a value of 12, but it's still there.

So, considering I had written most of my imaging programs on paper, so far,
I went to investigate this situation on the Mac & MSDOS machines. Now,
the original Oberon report doesn't mention the SYSTEM module, but these
two versions seem to support it, and neither one recognizes the type BYTE
(although the MacOberon document DK*Report.Text mentions the BYTE as both
a predefined type and as a type in SYSTEM.

So, I suppose I can live with this, and have calmed down a bit, but I'm
still pretty confused. What's the best way to do math on 0=255 quantities?
The documents state that SYSTEM.BYTE is type interchangeable with CHAR
and SHORTINT, so it looks like I'll have to something like:

        INTVAR := ORD(BYTE_CAST_AS_CHAR_VAR)

to get unsigned bytes out of this. Not pretty, but not the end of the world
either.

So, when exactly did the predefined type BYTE get dropped from the language?
Is there a better way to deal with this problem?  I suspect that with range
checking and all, there will be a cost in time to using ORD & CHR
conversions. but I'm not sure how bad it will be?

Well, thanks for putting up with all this... back to work for me...

-greg
---
Greg DeLozier/Senior Scientific Analyst/L{*filter*}Defense Systems



Sat, 28 Oct 1995 03:30:28 GMT  
 Ouch! (Major pain with Oberon-2)

Quote:

>Well, here I went *way* out on a limb selling the portability and general
>wonderfulness of the Oberon system. Then I just tried to move some image
>processing code to SPARC-Oberon (where it ultimately has to run) and
>guess what?

>    the type BYTE has been *removed* from Oberon-2. (!)

BYTE has been moved to the SYSTEM module.  It has now become SYSTEM.BYTE.
I believe the general feeling is that if you need to access bytes, on a
byte basis, then you are probably doing something that is non-portable.
In this case, they wanted to do away with the pretense that it _might_ be
portable.

Quote:

>Question 2: Has anyone had any success using the floppy backup system in
>Oberon-386? I get i/o errors every time I try to use Backup.Format. Any
>suggestions?

I've never personally used it.  I have heard of sporadic problems, but the
developer has told me it does work.  (quite some time ago).  Try writing

fairly quickly.

Taylor "I am not intolerant" Hutt
Championing worldwide usage of Oberon-2!



Sat, 28 Oct 1995 04:54:16 GMT  
 Ouch! (Major pain with Oberon-2)

Quote:


>>        the type BYTE has been *removed* from Oberon-2. (!)

>BYTE has been moved to the SYSTEM module.  It has now become SYSTEM.BYTE.

SYSTEM.BYTE is totally useless for mathematical purposes. It's basically
reduced to a storage unit, if I understand correctly.

Quote:
>I believe the general feeling is that if you need to access bytes, on a
>byte basis, then you are probably doing something that is non-portable.
>In this case, they wanted to do away with the pretense that it _might_ be
>portable.

HUGE, ENORMOUS, TREMENDOUS, REALLY AMAZINGLY LARGE DISAGREEMENT HERE!
(Not with Taylor, with the premise...)

I can think of a half dozen portable image file formats, all of which
are successful *because* they are defined down to the byte (and then
some) level. I only know of one file format (original ppm, which writes
out its numbers in ASCII(!)) that can be used for image storage across
architectures without knowledged ot the byte-wise organization of that
file.

OTOH, TIFF, IFF, Sunraster, PCX, etc. are all going to give anyone
using Oberon a major headache, or at least a bigger one than they would
have had with a fully supported BYTE type.

As I've said before, the people at ETH are a truly amazing bunch and
have created a great thing I'm really happy to have. OTOH, I do wish
they had a little more interest in image-related activities. Oh, well.

-greg
---
Greg DeLozier/Senior Scientific Analyst/L{*filter*}Defense Systems



Sat, 28 Oct 1995 08:00:10 GMT  
 Ouch! (Major pain with Oberon-2)

Quote:

>SYSTEM.BYTE is totally useless for mathematical purposes. It's basically
>reduced to a storage unit, if I understand correctly.

As far as I know a byte is an object composed of 8 bits. And not much
more. Oberon is not assembly or C, so it doesn't mix the notion of
'bunch of bits' with number (even though one is the representation of
the other)

Quote:
>HUGE, ENORMOUS, TREMENDOUS, REALLY AMAZINGLY LARGE DISAGREEMENT HERE!
>(Not with Taylor, with the premise...)

>I can think of a half dozen portable image file formats, all of which
>are successful *because* they are defined down to the byte (and then
>some) level. I only know of one file format (original ppm, which writes
>out its numbers in ASCII(!)) that can be used for image storage across
>architectures without knowledged ot the byte-wise organization of that
>file.

So what. Do they use bytes ? No, they use integers from 0 to 255 (kind
of short cardinals :-)
The best thing you can do (given the absence of byte-long unsigned
integers in Oberon) is to use normal integers for 'in-memory use' and
convert them back'n forth when writing/reading to/from a file. I bet
that 1 (one) function for read and 1 (one) for write should be
sufficient to hide the internal representation of those integers in the
file. No big deal !

Quote:
>-greg

        Stefan


Mon, 30 Oct 1995 01:18:12 GMT  
 Ouch! (Major pain with Oberon-2)
Quote:

>BYTE has been moved to the SYSTEM module.  It has now become SYSTEM.BYTE.
>I believe the general feeling is that if you need to access bytes, on a
>byte basis, then you are probably doing something that is non-portable.
>In this case, they wanted to do away with the pretense that it _might_ be
>portable.

Huh???  Every computer system I have ever used had exactly the same
definition of a BYTE.  They all used 8 bits, and had a range of 0 -> 255.
Since when has BYTE been redefined so that it is not portable?


Mon, 30 Oct 1995 23:50:42 GMT  
 Ouch! (Major pain with Oberon-2)
: So what. Do they use bytes ? No, they use integers from 0 to 255 (kind
: of short cardinals :-)
: The best thing you can do (given the absence of byte-long unsigned
: integers in Oberon) is to use normal integers for 'in-memory use' and
: convert them back'n forth when writing/reading to/from a file. I bet
: that 1 (one) function for read and 1 (one) for write should be
: sufficient to hide the internal representation of those integers in the
: file. No big deal !

A very big deal! You just increased the size of a picture by a factor of 2.
This is totally unacceptable considering the normal size of pictures. I often
work with pictures of up to 5 Mb, which fit in my mac's 8 Mb ram. Doubling the
size would slow it down tremendously.

Stephan



Tue, 31 Oct 1995 02:23:56 GMT  
 Ouch! (Major pain with Oberon-2)
THE SOLUTION !!!!

BYTE is now SHORTINT

daniel gerhard



Tue, 31 Oct 1995 01:59:46 GMT  
 Ouch! (Major pain with Oberon-2)
[I wrote]

Quote:

>>SYSTEM.BYTE is totally useless for mathematical purposes. It's basically
>>reduced to a storage unit, if I understand correctly.

[Stefan responded]

Quote:

>As far as I know a byte is an object composed of 8 bits. And not much
>more. Oberon is not assembly or C, so it doesn't mix the notion of
>'bunch of bits' with number (even though one is the representation of
>the other)

So? A 16-bit signed integer is just a bunch of bits, and the operations
defined on it say, basically, we're going to take this bunch of bits
and agree on a transformation from these bits to and from some integer
space. Then these operations will manipulate those bits so as to produce
bit patterns consistent(given our agreed-upon transform) with the analogous
mathematical operations in the integer space. Two-s complement arithmetic
doesn't look a lot like how your grade school teacher added 5 + (-9)
but it provides the same results. So we accept it.

Now, it may be that there's a good reason to have a bit pattern that
goes from -128 to 127 over the course of eight bits, and operations
that act upon this representation. To say that this is the *right*
thing, or the *only* thing these bits can represent mathematically
is silly. Oberon isn't assembly or C (thank God) but it is presented
as a general purpose language, and IMHO, a general purpose language
should facilitate common representations of information, and I happen
to think that a data type that goes from 0..255 in eight bits is
pretty common in a lot of disciplines.

Quote:

>>I can think of a half dozen portable image file formats, all of which
>>...

>So what. Do they use bytes ? No, they use integers from 0 to 255 (kind
>of short cardinals :-)

I don't know if they use the word 'byte', I don't have that documentation
handy. I suspect it's used because it's pretty commonly used. But if they
say "0 to 255 (kind of short cardinals)" I'd still be SOL as far as Oberon
is concerned. I'm not objecting the the lack of the word "BYTE". SHORTCARD
would suit me fine. It's just that BYTE was *IN* there and then taken out
because no-one could see a use for it one fine afternoon, I guess, and so
it went...

Quote:
>The best thing you can do (given the absence of byte-long unsigned
>integers in Oberon) is to use normal integers for 'in-memory use' and
>convert them back'n forth when writing/reading to/from a file. I bet
>that 1 (one) function for read and 1 (one) for write should be
>sufficient to hide the internal representation of those integers in the
>file. No big deal !

Fine, if you're doing exercises for class, or research projects, or a
million other things. However, these images are (excuse the expression)
byte arrays approaching 20 or 30 megabytes (oops, mega-short-cards :-) )
so doubling the size isn't as trivial as it sounds. Especially in the
Oberon we-hate-to-throw-anything-away memory management scheme.

Anyway, thanks for your thoughts.

Quote:
>>-greg

>    Stefan

-greg (again...)


Tue, 31 Oct 1995 07:13:05 GMT  
 Ouch! (Major pain with Oberon-2)

Quote:

>>BYTE has been moved to the SYSTEM module.  It has now become SYSTEM.BYTE.
>>I believe the general feeling is that if you need to access bytes, on a
>>byte basis, then you are probably doing something that is non-portable.
>>In this case, they wanted to do away with the pretense that it _might_ be
>>portable.

>Huh???  Every computer system I have ever used had exactly the same
>definition of a BYTE.  They all used 8 bits, and had a range of 0 -> 255.
>Since when has BYTE been redefined so that it is not portable?

Gee, you're showing your youth :-)

In ye olden days, there were machines that had these entities called
WORDs and they were not 8-bits. The machines were NOT byte-addressable.
But if you wanted to get at one of these in a language like Modula-2 or
Oberon you'd probably be using the closest system type, which is BYTE.
This is not to argue that we burden Oberon with the need to support the
CDC series, or the IBM 360, or any other dinosaur.

On the grounds that everyone knows what a byte is these days, the Oberon
datatype BYTE should never have been moved to SYSTEM.

But I don't think that's the reason ETH moved it to SYSTEM. It probably
has more to do with emphasizing
  o  you can't do math with it
  o  it's usage is limited esp. compared with the other types.
  o  it's common use as in (VAR s: ARRAY OF BYTE) to pass any argument
     type as a parameter _can easily be_ very non-portable.

On another thread, I wonder if Greg Delozier would be happy if he had
an 8-bit and 16-bit SET types to manipulate his image data. Tho', maybe
good ol' 32-bit SET would work too. (This isn't a flame, just a question.)
Sometimes, translating the C way of doing things into Oberon, isn't the
best way to do something in Oberon.

--

"All you need is HEADCLEANER!" -- Einstuerzende Neubauten



Tue, 31 Oct 1995 06:49:35 GMT  
 Ouch! (Major pain with Oberon-2)

Quote:
>THE SOLUTION !!!!

>BYTE is now SHORTINT

No, it isn't. Operations on BYTE were defined from 0-255. SHORTINT is
-128..127.   A *very* different animal, indeed.

Quote:
>daniel gerhard

-greg


Tue, 31 Oct 1995 07:36:03 GMT  
 Ouch! (Major pain with Oberon-2)
This is a longish essay describing my experiences using Oberon to create
an involved bit of software under tight time and cost pressure. I'm
hoping others might find these observations interesting, adn I haven't
seen many people talk about application development under Oberon. I'd
appreciate comments, enlightenment, etc.

I posted a few messages in the middle of the night a few days ago,
describing the troubles I was having with Oberon and the SPARC/Oberon
development system. I thought I'd like to share the outcome of that
all-nighter (!) as it did, in fact turn out pretty well. Actually, I was
planning on posting this sooner, but my baby daughter went and broke her
leg just after my presentation ended, but that's another story.

Anyway, the project involved some involved mathematics, image processing,
simple user interfacing, image display, image i/o, and data display. I
had about two weeks to write this, and some old mathematical code in
Pascal I could steal from, but not much else. My results were, roughly
in the order I did them:

Mathematics coding:
Compared to what else was available, writing 2-d array code in Oberon was
a piece of cake! The ability to pass open arrays made it possible to write
very generalized code, and the Pascal source ported easily. Like an idiot,
I converted all the FOR/DO loops to WHILE statements and *then* found
out that FOR had been reinstated. Oh, well. Most of the conversion effort
went toward removing 'WITH record DO...' constructs, which amounted to
placing the record name in front of lots of things. This was pretty
mechanical, but it took a little while.

Image processing:
Once I got over the *shock* of not having a BYTE type, I finally said
to myself "Hey, it's a SPARCStation. Memory is infinite, right?" and
converted all the images to 16-bit pixels. Since this application uses
24-bit RGB + HSV calculations, we had a storage cost of about 12 bytes per
pixel. Still, it worked.  
Otherwise, writing IP code was very easy, with the open array facility.
A lot of the messing around one has to do in, say, C, to handle 2-d
arrays in the general case is gone in Oberon. Very nice.
I will grudgingly admit that it is easier to write a convolver if
your image data is stored in signed 16 bit ints. But I don't have to
like it!

Image I/O:
I found the file I/O routines to be simple and capable, for reading
raster files. I did have to read rasters into an array of char, and then
use ORD to convert the arrays to arrays of INTEGER, but that wasn't
too bad, and wasn't the file routine's problem. Formatted real output
is sometimes a little odd (i.e. 0 always comes out as 0, even if
formatted to 0.00 like all your other results!) but I could live with it.
I didn't try formatted input using the scanners, but the routines are all
there, and look workable.

Image display:
This was the hard part. First, I decided that I would display a portion of the
image as wide as the user track, and that was that. Then I went and read
the source to SortDemo to understand about update messages and handlers,
and used the Browser a *lot* on Display, Oberon, TextFrame, and some
other things. The end result is a program that can display the image in
a viewer, and if the viewer size is increased, more can be seen, just
like the text editor. It doesn't scroll (yet) and required some (a lot)
trial and error, but it works. I occasionally think it updates too often,
but it hasn't been a problem.

  I was *not* happy about the 16 color restriction, and ended up putting
all the images into a 16 color gray scale for display. I used another unix
utility outside of Oberon to display the color images. I survived, and I've
been told the X version ahs a fix for this.  Also, I am currently updating
the images using Display.Dot. There *must* be a better (i.e. faster)
way, but I don't know what (yet).  

  There's a complete X11 toolkit module in the SPARC system, but code using
this wouldn't be very portable, so I avoided it. I may mess with it someday,
especially if we deliver end products with this system.

User Interface:
The best way to describe it was "what user interface?"   I ended up
making enough routines externally accessible that I just made a text tool,
put it on the system track, and called it a command menu. Nobody gave
me any complaints about it. I did trap mouse clicks in the image window
and worked with them.  You have to think for a while to calculate
where in the image (vs where in the viewer, vs where in the screen) the
mouse was clicked, but it all worked and image interaction was just like
anywhere else...

The input messages return a key 'set' which I haven't been able to find
much documentation on. I just tested against the null set(i.e. is a
button down, or isn't it?)  It worked out fine, but I need more info here.

Performance:
Compiling and linking -- great. I could not have developed so much
code so quickly using any other tool we have here. And we have *lots!*

Running -- pretty good. Things run a good deal faster in some cases
with range checking turned off. I was happy with the speed, though; it
was fast enough to be comparable to execution times of our C & Ada
compilers' generated code.

Development ease:
Well, a few kilolines later, I still *hate* the scroll bars. On
the other hand, the editing features of EdiT (the extension of Edit)
are quite nice and useful. Even things like block indent/undent and
brace matching are included, so I was pretty happy with that. Global
search and replace works well.
The edit/compile/run cycle is very stable. Things don't tend to
crash. I got to trust it so much I didn't really save as often as
I should, but I never lost anything. Very nice.

One big convenience is the ability to recompile modules that use lower-
level modules without even losing the gata in the global variables in the
lower modules. A concrete example: I could read in an image in my Rasters
module and leave it there. Then I could access this image from the
RasterFrame module repeatedly while developing and testing it without
having to execute Rasters.Open again. This saves lots of time, and
makes the local Ada programmers very envious when they think about it
too much...

Support:
I don't know about the world at large, but I've gotten better and more
helpful replies to questions asked about Oberon problems on the net than
we generally get from commercial vendors. Just amazing.

Gripes:
Simple things need to be fixed. For instance, using the delete key
past the beginning of a line (to re-attach it to the previous line)
causes the insertion cursor to just *go away* (!). All the windows
update, and the mouse has to be used to relocate the text insertion cursor.
I think this is pretty screwy behaviour, and I intend to fix it.

While I'm used to the Oberon editors, and can work in them just fine, I
think I do prefer the Cut/Copy/Paste methods more common in the Mac &
Windows (& Motif) worlds. But these can be worked with.

When a module allocates a lot of global data, it doesn't seem to
show up in the System.Watch report. Since this doesn't get freed
(I'm told) I'd like to know about its usage. Perhaps I'm looking in the
wrong place.

Occasionally I get a message about some module not being able to use
another one because it has the "wrong key" or some such thing. I don't
know what this means (though I could guess...) but recompiling everything
in sight generally fixed things, and doesn't take much time.

Compliments:
I find it very convenient to be able to randomly arrange commands in the
various tools to help with development. I felt very quickly that I had things
arranged just perfectly to my liking. That part becomes very natural.

Except for the BYTE business, the language is superb. I was very confident
in the results of my coding efforts, and was please with the neatness
of the results.

The customers (and my boss) were very impressed with how much I got done
in such a short time. I'd credit this to the fast compiler time and the
facility for effortless construction of heirarchical "Command Menus"
(Hey, these are military types. They understand heirarchical command
structures...)

Portability to other platforms is unbelievable. I just took code from
place to place and worked on it wherever I was, be it Mac, PC, SPARC,
wherever... This has drawn a lot of attention around here.

Bottom Line:
------------
I didn't much care for learning the environment, but now that I have
(to some extent) I really am impressed and would be very reluctant
to part with it. OTOH, I've had to do some *fast* dancing around to
get around the partial lack of 256 colors and BYTE types. (To be fair,
256 colors works fine on most of the platforms. This may have been
pilot error, though the documentation is pretty vague on this).

Anyway, the m{*filter*}is if you have the nerve to see it through, Oberon
can let you do heroic things. But it's not for the faint of heart,
and requires a certain amount of digging around to get things figured
out. In the long run, it seems to be with it.

Thanks, by the way, to the people at ETH, who are very helpful, and
to Taylor ("Quote of the day") Hutt, who gave me some very helpful
advice.

-greg
---
Greg DeLozier/Senior Scientific Analyst/L{*filter*}Defense Systems



Tue, 31 Oct 1995 08:44:54 GMT  
 
 [ 41 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Trying to post to this group is a major pain in the

2. Array Storage: row-major, column major, etc.

3. column-major and row-major

4. MAJOR MAJOR bug in TCL 8.4

5. Ouch!

6. Paining partially translucent areas

7. Pain OOOOOOLLLLLLLLEEEEEEEE

8. DLLs, a pain in the @$$, HELP!!

9. LAN to NOVELL growing pains = HELP!

10. Win '95 Pain in the A**

11. Win 95 Pain in the A**

12. Printing in LV 6.1 is a real pain

 

 
Powered by phpBB® Forum Software