[Oberon] Static variable overflow (bug?)
chris at cfbsoftware.com
Mon Feb 24 12:40:33 CET 2020
Your viewer also doesn't use the global bitmap, and it isn't exported so
you can remove the declaration. I suspect the problem would then go away as
you will no longer exceed the global variable size limit of 64Kb - each SET
element in the array is four bytes. You would only need the bitmap if you
*were* doing the dot-drawing and using the original algorithm.
On the other hand if you are aware that you don't need the bitmap and are
just puzzled why it fails when max < 16384 I believe it is because the
string constants also use the global space.
From: Hans Klaver [mailto:hklaver at dds.nl]
Sent: Monday, 24 February 2020 9:29 PM
To: Chris Burrows; ETH Oberon and related systems
Subject: Re: [Oberon] Static variable overflow (bug?)
Well, as you can see MyViewer doesn't do any dot-drawing. The only thing it
does is declaring an array of 32 bit entities and creating an emty viewer.
The viewer works fine apart from its menu remaining emty. This is what
Chris Burrows wrote:
If I were you I would have started by looking at the newer graphics examples
supplied with Project Oberon 2013 as a basis for porting the Fern example to
the newer system. The bitmap in the original XYPlane code appears to have
been used for dot-drawing optimisation that is no longer used (necessary?).
Recently I tried to implement XYplane.Mod from the book of Reiser & Wirth
'Programming in Oberon' for Project Oberon. Within Peter de Wachter's RISC
emulator I ran into an overflow problem (leading to the remaining empty of
the menu line of a viewer) that appears to be dependent on which disk image
Otherwise my port works fine (produces the IFS fractal fern as expected).
For those interested I will post it to my github repository.
A minimal module that can reproduce this menu problem can be found below.
When starting the emulator in macOS as follows this problem occurs:
$ ./risc --fullscreen DiskImage/Oberon-2019-01-21.dsk
But the problem does NOT occur when starting thus:
$ ./risc --fullscreen DiskImage/Oberon-2016-08-02.dsk
I do understand that there is a limit to the use of static variables within
the PO version of Oberon, but I would not expect this limit to be reached
this easily, and I would not expect it to appear in newer versions of the
software and not in older.
Does anyone have a clue where to look for the cause of this happening?
(* Test of the menu line of a viewer *)
IMPORT Display, Viewers, Oberon, MenuViewers, TextFrames;
max = 16377; (* If max >= 16367 the frame name disappears; If max >=
16377 the whole menu line disappears! *)
menu = "System.Close System.Copy System.Grow";
XYframe = POINTER TO XYframeDesc;
XYframeDesc = RECORD (Display.FrameDesc) END;
VAR bitmap: ARRAY max OF SET; (* with this variable present the menu may
remain empty! *)
PROCEDURE Restore(F: XYframe);
Oberon.RemoveMarks(F.X, F.Y, F.W, F.H);
Display.ReplConst(Display.black, F.X, F.Y, F.W, F.H, Display.replace);
(* clear *)
PROCEDURE Handle(F: Display.Frame; VAR M: Display.FrameMsg);
VAR F1: XYframe;
CASE F OF XYframe:
CASE M OF
IF <http://m.id/> M.id = Oberon.track THEN
Oberon.DrawMouseArrow(M.X, M.Y) END |
Oberon.RemoveMarks(F.X, F.Y, F.W, F.H); NEW(F1); F1^ := F^;
M.F := F1 |
IF (M.Y # F.Y) OR (M.H # F.H) THEN F.Y := M.Y; F.H := M.H;
VAR F: XYframe; V: Viewers.Viewer; x, y: INTEGER;
NEW(F); F.handle := Handle;
Oberon.AllocateUserViewer(Oberon.Par.vwr.X, x, y);
V := MenuViewers.New(TextFrames.NewMenu("MyViewer", menu), F,
TextFrames.menuH, x, y)
<mailto:Oberon at lists.inf.ethz.ch> Oberon at lists.inf.ethz.ch mailing list for
ETH Oberon and related systems
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon