[Oberon] Re: Compiler differences

[easlab at absamail.co.za]

Bob Walkden wrote:

> I have recently downloaded the SpreadSheets Gadget package from the 
> ETH FTP
> site. In ETH Plugin Oberon for Windows 2.4 it compiles and runs ok. On
> Native Oberon 2.3.6 running on a Thinkpad 760ED it compiles (with the \2
> switch) but Traps with an index overflow.
> 
> The source code is exactly the same on both machines, of course. It is
> failing in this bit:
> 
> PROCEDURE InitSpreadModel*(obj: SpreadModel);
> VAR
> 	i, j: INTEGER;
> BEGIN
> 	obj.handle := SpreadModelHandler;
> 	obj.width := 2;
> 	obj.height := 2;
> 	NEW(obj.table, obj.width + 1, obj.height + 1);
> 	FOR i := 0 TO obj.width DO
> 		FOR j := 0 TO obj.height DO
> 			obj.table[i, j] := NIL   <------ Trap here
> 		END
> 	END
> END InitSpreadModel;
> 
> This makes a 3x3 spreadsheet.
> Here this is the definition of SpreadModel:
> 
> TYPE
> 	Table = POINTER TO ARRAY OF ARRAY OF Cells.Cell;
> 
> 	(** Model for a SpreadSheet object *)
> 	SpreadModel* = POINTER TO SMDesc;
> 	SMDesc* = RECORD (Gadgets.ObjDesc)
> 		width, height: INTEGER;		(* width and height of the
> table *)
> 		table: Table		(* the table with the cells *)
> 	END;
> 
> As far as I can see, there is no way that code should cause a Trap, so I'm
> assuming there are some differences between the compilers that are causing
> the different behaviours, and that I perhaps need some switch to eliminate
> the differences. However, I can't trace such a switch (I don't want to
> compile without range checks).
> 
> Any ideas?

I don't [want to be forced to] use 'Windows'; but I see no reply
to your query yet.  I too don't remember any Traps from 'the 
SpreadSheets  Gadget package' under V 2.3.6 DOSbased or any 
NO-StandAlone version.

As I remember the trap trace shows the 'trap-cause'.
In your case, the simplistic/obvious suspect is "index out of range".

Do you know about Compiler.Tool >
	f	find error position (select PC line in Trap viewer)
?
Do you know how to trace down through the 
stack-of-proc-calls shown by the trap-trace ?

== Chris Glur.

PS. I worry that as NO forks, the remaining bugs will remain
forever unfixed.

Taking advantage of 'bad conditions' of many ISP fail-to-log-ons,
I've repeatedly confirmed that my previous [over years ?!]
complaint about ppp problems to re-dial when the previous
log-on fails, seems to be cause by the V24/Dialer rather than
the ppp facility.    This because the instruction:
  V24.Stop(1)
clears the inability to properly drive the modem.

As previously noted this same 'clear/reset action' is
needed to eg. use the 2nd ser-port to eg. communicate 
with another box, once the modem [on the same 2nd ser-port]
has been used.   I guess Win users would have no problems, they'd
just reboot ?

Unfortunately [perhaps - I'm not aware yet of problems] V24.Stop(1)
also causes a trap, thus:
TRAP -14  NIL reference ( 00000008H ) (PC Native 11.10.2001)
V24.Available  PC = 1804
	p =  00000000H
	port = 1
PPPMain.Connect  PC = 112
	item =  00000000H
	me =  0026E6A0H
	prno = 0
Oberon.Loop  PC = 8726
	M =  00000010H
	N =  0000000CH
	V =  0046EAA0H
	X = 101
	Y = 109
	ch =  00000000X
	keys = {}
	oldshift = {}
	shift = {}
---------
 which superficially looks related to the 'tasking', as I've previously
raised for this matter.