Out in the "real world" with Oberon... 
Author Message
 Out in the "real world" with Oberon...

Well, it's pretty late here, and I'm trying to salvage what's left of a
project I envisioned as using Oberon to function as a prototyping environment
for image processing.  At this point, and at this time, I'm extremely
disappointed.

Let me start out by saying that I like the language, and even found the
development environment useful. I wrote some neural network code, got it
working, and from the looks of it, wasn't going to have any trouble with
the rest of the project. This being a SPARC-Oberon system, I had plenty of
memory, an 8-bit frame buffer, (I presumed) control over the color table,
and reasonable file I/O. So I whought I could read in an 8-bit array
and display it on the screen, no sweat.

Well, it's turned out to be a big sweat, and I'm taking a short break to
write down of the highlights in hopes of getting some insight into what
I should do at this point. Basically,

1) As mentioned in previous posts, the BYTE type was removed from the
   language definition and placed into the SYSTEM unit. A value may be
   placed into such a variable, but there is no obvious way to get
   at the value in a type-safe way. So, my code is littered with examples
   of color tables and image arrays being read into arrays of char, and
   then using 'ord' to get the 0-255 value into an integer.

2) In the process of tying to write some code that decompresses RLE
   encoded raster files (basically just translating from known-to-be-
   working-Ada) Oberon hung itself up pretty well. So well, in fact,
   that my SPARCstation refused to run the program again, claiming
   I had an '--- invalid heap size' whenevery I tried to start
   Oberon. Some searching with the unix 'strings' utility found that
    this message lives in Kernel.Obj.
   So, I got out the original tar files for Operon, reloaded the thing,
   and got the same message *from the new copy*. Then I logged out
   and logged in again -- same problem.
   Then the previously stable SPARCstation started having memory error
    messages on the console. Go figure. So I rebooted it.
   Then I went to another SPARC machine and the oberon files worked
   fine, the environment came up without a peep. Sigh. Another hour
   shot, checking everything in sight. Still no idea.

3) So finally, here I am, at one in the morning, and I find out that
   for some reason, it was decided that 16 colors was about all one might
   need to display, and it doesn't matter what color you ask it to draw
   a line or dot in, you get that color mod 16. Double sigh. Buried in
   the pretty much undocumented X11 module are some things that might
   be used to overcome this, but at the expense of portability, and
   definitely not in the time I have left.  Now, nowhere do the
   manuals mention a 16 color limitation, and my previous posts on internet
   haven't mentioned any such thing, and the calls all *look* like they are
   all  set to handle 8-bit color tables. But when it gets down to the
   wire, it looks to me like it's not there.

So I guess I'm pretty disappointed in all this. I suppose one could
tell me to RTFM (I did, every one I could find in three distributions
-- didn't help. I read them mostly on-line, as the PC version only
prints to lasers, and the Mac version isnt quite working for US paper
sizes) but I *did* read them. I also read all the SPE papers. It never
occurred to me that anyone would build something state-of-the-art like
the Ceres and then model a *16-entry* color table? This can't be true,
can it?  So unless I get some inspiration in the next couple of hours,
I'm going to try to convert this to Ada and not think about the people
I'm letting down by not having done that to begin with.

I realize full well that things like Oberon aren't done to please people
like me. And in fact, if it hand't come so close, it probably wouldn't be
a problem. But it's such an amazingly nice thing I hate to be stopped
cold like this. So, let me know what I'm doing wrong here...

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



Sat, 28 Oct 1995 13:22:24 GMT  
 Out in the "real world" with Oberon...

Greg Delozier shares critical path programming troubles:

Quote:
> 3) So finally, here I am, at one in the morning, and I find out that
>    for some reason, it was decided that 16 colors was about all one might
>    need to display, and it doesn't matter what color you ask it to draw
>    a line or dot in, you get that color mod 16. Double sigh. Buried in
>    the pretty much undocumented X11 module are some things that might
>    be used to overcome this, but at the expense of portability, and
>    definitely not in the time I have left.  Now, nowhere do the
>    manuals mention a 16 color limitation, and my previous posts on internet
>    haven't mentioned any such thing, and the calls all *look* like they are
>    all  set to handle 8-bit color tables. But when it gets down to the
>    wire, it looks to me like it's not there.

SPARC:

<path>/oberon -c &

allocates a private color map.  Paint &tc then can use 256 colors.  I am now
here compressing a postscript color output file I hope to use at a conference
soon.  There is some trouble with 2.7 on this, and I have sent Josef e-mail.
He typically is responsive.  I did get the V3.0 when it was accidentally available,
and can verify that those problems are resolved there.  

One detail that bit me:  be sure to write your color map into the pict,
( Pictures.SetColor ) otherwise there is loss. :-)  

I have, IMHO, a pretty slide background
that displays well on a SPARC under 2.7.  It's simply a blue center with a
fade to black at all edges, and a sunset pink pinstripe border.  Aqua letters
give a talk title.

" Paint.LoadColors * "

----


        IMPORT
                Display, MenuViewers, Oberon, PictureFrames, Pictures, Printer , SYSTEM, TextFrames, Viewers;

        CONST
                Menu1 = "System.Close System.Copy System.Grow Paint.Store ";
                width = 1024;
                height = 512;
                stripew = width DIV 100;
                Colors = 128;
                Base = 17;
        (* Slide.Open  name  wide tall  basecolor framecolor *)

        PROCEDURE Open*;
                VAR
                        Vt : Viewers.Viewer;
                        X, Y : INTEGER;
                        pict : Pictures.Picture;
                        center, band, color : INTEGER;
                        r, g, b : INTEGER;
        BEGIN
                ASSERT( Base+Colors < 256, 42 );
                Oberon.AllocateUserViewer(Oberon.Par.vwr.X, X, Y);
                NEW( pict );
                Pictures.Create( pict, width, height, (*1*) 8 (* for color*) );
                Vt := MenuViewers.New(
                                TextFrames.NewMenu( "slide.Pict", Menu1),
                                PictureFrames.NewPicture( pict ),
                                TextFrames.menuH, X, Y); (*open standard menu viewer*)
                FOR color := Display.black TO Display.white DO
                        Display.GetColor ( color, r, g, b );
                        Pictures.SetColor( pict, color, r, g, b );
                END;
                FOR color := Base TO ( Base + Colors - 1) DO
                        Pictures.SetColor( pict, color, 0, 32, 255 - (color-Base) * (height DIV (2*Colors ))  )
                END;
                Pictures.SetColor( pict, Base-1, 255,  171,  171); (*Pink*)
                band := height DIV (2*Colors);
                center := height DIV 2;
                Y := 0;
                FOR color := Base + Colors-1TO Base BY -1 DO
                        Pictures.ReplConst( pict, color, Y, Y, width - 2 * Y, height - 2 * Y, Display.paint  );
                        INC( Y, band )
                END;
                Pictures.ReplConst( pict, Base-1, 5*stripew, 5*stripew, stripew, height-10*stripew, Display.paint );
                Pictures.ReplConst( pict, Base-1, width-6*stripew, 5*stripew, stripew, height-10*stripew, Display.paint );
                Pictures.ReplConst( pict, Base-1, 5*stripew, 5*stripew, width-10*stripew, stripew, Display.paint );
                Pictures.ReplConst( pict, Base-1, 5*stripew, height-6*stripew, width-10*stripew, stripew, Display.paint );
                Pictures.Update ( pict, 0, 0, width, height )          
        END Open;

        (* Convert picture to PS file (*requires modified Printer.Mod*) *)
        PROCEDURE ToPS*;
                VAR
                        v : Viewers.Viewer;
                        name : ARRAY 5 OF CHAR;
                        pict : Pictures.Picture;
        BEGIN
                v := Oberon.MarkedViewer ();
                IF (v.dsc # NIL) & (v.dsc.next IS PictureFrames.Frame )
                THEN
                        name := "none";
                        pict := v.dsc.next (PictureFrames.Frame ).pict;
                        Printer.Open( name,  Oberon.User, Oberon.Password );
                        Printer.Picture( 0, 0, pict.width, pict.height, Display.paint, SYSTEM.VAL( LONGINT, pict ) );
                        Printer.Page ( 1 );
                        Printer.Close
                END
        END ToPS;

END Slide.

--
Aubrey McIntosh  /  Chemistry  /  University of Texas  /  Austin, TX 78712
...another Gaelic learner...



Sat, 28 Oct 1995 18:36:32 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. OOP in the "real world" (SUMMARY)

2. OOP in the "real world"

3. "real-world" bisimulation proofs

4. "real world" functional programming

5. rapid prototyping in the "real world"

6. Lisp in the "real world"

7. "Real world" Scheme use

8. rapid prototyping in the "real world"

9. rapid prototyping in the "real world"

10. rapid prototyping in the "real world"

11. rapid prototyping in the "real world"

12. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

 

 
Powered by phpBB® Forum Software