[Oberon] Fwd: IDE with integrated source level debugger andLuaJIT VM running the Oberon System

[rochus.keller at bluewin.ch]

@ Michael Schierl

Thank you very much for your tests and your feedback. I was able to identify the cause of the crash: in Project::findSymbolBySourcePos a check for i.value().d_mod.isNull() was missing which I added now. 

>> you should probably also add some autosave feature
Of course I would prefer to have an editor which doesn't crash ;-) From the other development environments I implemented I'm confident that this is feasible. It's a bit more challenging in this project because I'm not actually an Oberon programmer and my use of the IDE was quite limited up to now (migrating the Oberon System to evaluate the compiler). But I can fix the issues if I get reports like yours.

>> Type guards seem to be lax (duck type-ish).
Ok, I will have a look at it and add more checks to the validator.

>> and as a consequence to a crash.
LuaJIT is a dynamically typed VM; it doesn't depend on the type checking; if something is nil which shouldn't the IDE and runtime will show a stack trace but should actually not crash.

>> However, recursive pointers are not really clear in the view 
I could add the "physical address" of the lua table to which the reference points as a hex number. The number is not meaningful by itself but could help to distinguish the pointers.

Best
R.
_______________________________
From: Michael Schierl
Sent on: Sat, 15 Feb 2020 19:58:19 +0100
To: rochus.keller at bluewin.ch ; ETH Oberon and related systems
Cc: 
Subject: Re: [Oberon] Fwd: IDE with integrated source level debugger andLuaJIT VM running the Oberon System

Hello Rochus,


Am 15.02.2020 um 02:59 schrieb rochus.keller at bluewin.ch:
> Correction: I posted the wrong link to the Windows binary. Here is the one to the IDE: http://software.rochus-keller.info/OberonIDE_win32.zip

First impression: Quite nice.


Some feedback:

1) Being able to navigate the stack and looking at local variables of
other stack frames is very useful. However, recursive pointers are not
really clear in the view (i.e. when x.next == y and y.next == x).

2) Type guards seem to be lax (duck type-ish). In other words v(T2).q
does not trap if the actual type of v has a field q, even if it is
another type than T2 that has this field. I did not test how type tests
(v IS T2) behave, but I fear they behave the same way. I also did not
test if this can lead to type confusion (storing a value in a variable
of different type) and as a consequence to a crash.

3) While typing inside the editor (having an incomplete command with
syntax errors), the IDE crashed without warning and the file was lost.
Apart from fixing the crash bug (probably due to error highlighting),
you should probably also add some autosave feature so the file is not
lost in case of such a crash. I was able to reproduce the issue with
this short file, when trying to place the cursor after the colon in the
(only) line that start with BEGIN and ends with a colon:


MODULE Crash;

TYPE T1 = RECORD END;
  T2 = RECORD q: INTEGER END;

PROCEDURE Foo*;
VAR v: T1;
BEGIN v(T2).q :
TRAPIF(TRUE)
END Foo;

END Crash.


Regards,


Michael