May 2020 - Oberon - mailman3.inf.ethz.ch

Wanted: Oberon Syntax in TextMate, Sublime Text or Atom Grammar
by Treutwein Bernhard 01 Jan '22

01 Jan '22

Does somebody have grammars for Oberon / Oberon-2 / Component Pascal / Active Oberon as grammar for TextMate / Sublime Text / Atom Background: Github wrongly classifies Oberon / Oberon-2 / Component Pascal / Active Oberon as Modula-2. I opened quite some tiome ago an issue in the github/linguist project (https://github.com/github/linguist/issues/3888) and they don't accept EBNF grammars. -- Bernhard Treutwein

6 9

PO2013 - Colour Ergonomy
by Tomas Kral 30 Jun '20

30 Jun '20

Hi, I was toying with colours on FPGA board lately. In your experience, what colour combination (dirt & backdrop) causing least eye fatigue? I realised it may even vary for day light, or night (being night owls like me). I know, PO2013 specifies SW[7] that does screen invert. FPGA RGB tends to have brightish colours, it may well boil down to ones monitor settings. Or even if its CRT, or modern LED. -- Tomas Kral <thomas.kral(a)email.cz>

2 5

Re: [Oberon] ... MOD 65536
by Hans Klaver 07 Jun '20

07 Jun '20

I wrote: > Now also in Oberon System V5 Hennessy.Mod can be used with ...MOD 65535 in procedure Rand. > All reference output is as it should be. This should be: Now also in Oberon System V5 Hennessy.Mod can be used with ...MOD 65536 in procedure Rand. All reference output is as it should be. -- Hans

9 36

Re: [Oberon] PO2013 - SD Image Tool
by John R. Strohm 02 Jun '20

02 Jun '20

That would be expected behavior if the switches, when closed, grounded the connecting pins. --- thomas.kral(a)email.cz wrote: From: Tomas Kral <thomas.kral(a)email.cz> To: oberon(a)lists.inf.ethz.ch Subject: Re: [Oberon] PO2013 - SD Image Tool Date: Sat, 23 May 2020 11:24:09 +0200 Hi, Some progress made. This is truly blank system. 7| Watch Modules space (bytes) 47296 9 % Heap speace 0 0 % Disk sectors 1 0 % Switches: swi0 = 0 , swi1 = 1 Time 285507~ EDIT On the board sw0 is on, while sw1 is off, is this a typo in Oberon0 code?

5 18

PO2013 - Modules.Load - recursion
by Tomas Kral 02 Jun '20

02 Jun '20

Hi, Following up from `PO2013 - SD Image Tool'. Module Oberon imports MenuViewers, TextFrames, both depend back on Oberon, which is not loaded, but to be loaded. Oberon -> MenuViewers -> Oberon .... Modules.Load recursion terminates. But how about this example, it even needs a trick to get modules M0,M1 compiled. But recursion during load does not terminate? MODULE M0; IMPORT M1, Out; PROCEDURE Load*; END Load; PROCEDURE Echo*; BEGIN Out.String("M0 echo"); Out.Ln END Echo; BEGIN M1.Echo END M0. MODULE M1; IMPORT M0, Out; PROCEDURE Echo*; BEGIN Out.String("M1 echo"); Out.Ln END Echo; BEGIN M0.Echo END M1. M0.Load -- Tomas Kral <thomas.kral(a)email.cz>

2 2

PO2013 - Texts
by Andreas Pirklbauer 01 Jun '20

01 Jun '20

> Yet, Is there a "1" after text tag as per comment? > > (* TextBlock = TextTag "1" offset run {run} "0" len {AsciiCode}. > run = fnt [name] col voff len. *) As per syntax defined in the book Project Oberon 2013 and the comment above TextSection = ident header {char}. # ident = TextTag header = type offset run {run} null length. # type = “1" run = font [name] color offset length. the “1” stands for the “type” field, which is supposed to by a “type discriminator”. However, there is no “1” in the actual file. I.e., it’s just not implemented in PO 2013. Note: It wasn’t implemented in Ceres-Oberon either.

3 2

PO2013 - ORB object allocation
by Andreas Pirklbauer 31 May '20

31 May '20

> A little exercise with added SW[5] to GC, to disable/enable collection > at runtime and watch how the heap builds up. It is not very precise, > but carries the idea, I hope. One can get a 100% precise (byte-for-byte) picture by temporarily adding a byte counter to ORB, incrementing it in ORB.NewObj, and printing the sum at the end of a compilation.

1 0

PO2013 - ORB object allocation
by Tomas Kral 31 May '20

31 May '20

Hi, Taking from earlier subject re `Compiler takes less heap space'.(http://lists.inf.ethz.ch/pipermail/oberon/2020/014343.html) A little exercise with added SW[5] to GC, to disable/enable collection at runtime and watch how the heap builds up. It is not very precise, but carries the idea, I hope. GC off, ORB object allocation Initial heap Heap space 35584 13% ObjDesc*= RECORD class*, exno*, lev*: INTEGER; expo*, rdo*: BOOLEAN; ... compiling Oberon 1701 288 A89CCEE2 System.Watch Heap space 199648 76% ObjDesc*= RECORD class*, exno*: BYTE; expo*, rdo*: BOOLEAN; lev*: INTEGER; ... compiling Oberon 1755 288 A89CCEE2 System.Watch Heap space 146848 56% -- Tomas Kral <thomas.kral(a)email.cz>

1 0

PO2013 - Modules.Load - recursion
by Andreas Pirklbauer 31 May '20

31 May '20

> 1. Catch the cyclic import during compilation. This would > require modifying module ORB. It has been done before. > Not that hard. about 25-50 additional lines. I have been asked how to avoid cyclic imports. Here is one way how to do it (see the references [1] - [4] at the end): One needs to essentially store "module anchors" of *all* imported (including re-imported) modules in the symbol files and propagate such anchors across the entire import/export hierarchy. There is just one small subtlety that absolutely needs to be addressed, if you really want a solution that works in *all* possible cases: re-exports and re-imports: In Oberon, a type T0 exported by a module M0 and imported by a module M1 can be *re-exported* by M1 (for example as a type of a non-exported record field) *and* their imports in another client module M2 - which imports M1 - may be hidden. These so-called "re-imports" absolutely need to be traced across the module hierarchy and one way to do that is by propagating using module descriptions called “module anchors” (essentially module name and key). For some possible implementations of the full solution, see [1] - [4]. As one can see, the general problem of detecting cyclic imports *at compile time* has actually been solved immediately after Oberon was originally developed on Ceres around 1990, see [1]. I remember vivid discussions on that at the CS institute in Zurich around this time. A corollary is that *if* one implements the full solution, one no longer needs to replace the simple recursive module loader by an iterative one, as now the compiler *guarantees* that cyclic imports can never occur. However, when the original Oberon system (and PO 2013) was built, it was (probably) felt that this general solution is overkill. Here is why: Since the *language* also does not *allow* cyclic imports - except when you construct a pathological case like in the last post - why solving the general problem? A classic Wirthian simplification: No need to detect cyclic imports at compile time because the language does not allow them. Therefore, a simple and easy-to-understand recursive module loader suffices. One may agree or disagree with this. After all, the extra cost of the full solution is only 25-50 lines. But it’s the approach chosen in PO13. References: [1] Griesemer R. On the Linearization of Graphs and Writing Symbol Files. Computersysteme ETH Zürich, Technical Report No. 156a (1991) [2] The OP2 compiler. Essentially implements [1] [3] The oberonc compiler. Essentially implements [1]. (see http://github.com/lboasso/oberonc) [4] ORB13CheckCyclicImports.Mod, ORP13CheckCyclicImports.Mod at http://github.com/andreaspirklbauer/Oberon-test-module-aliases. This solution works on PO 2013, but as a proof-of-concept only. The implementation cost is ~25 additional lines to module ORB. But it essentially just retrofits the implementation of [1] by mimicking module anchors in the symbol table itself (instead of using a separate global module (called GMod or similar). So the module anchors (=module descriptions, essentially name and key) come as an *afterthought*. This solution is therefore not recommended. If you want to check for all cyclic imports (including cyclic imports among re-exported and re-imported modules) in a “clean” way, use the "module table” model of [1], [2] or [3]

1 0

PO2013 - Modules.Load - recursion
by Andreas Pirklbauer 30 May '20

30 May '20

> But recursion during load does not terminate? > > MODULE M0; > IMPORT M1, Out; > PROCEDURE Load*; END Load; > PROCEDURE Echo*; BEGIN Out.String("M0 echo"); Out.Ln END Echo; > BEGIN M1.Echo > END M0. > > MODULE M1; > IMPORT M0, Out; > PROCEDURE Echo*; BEGIN Out.String("M1 echo"); Out.Ln END Echo; > BEGIN M0.Echo > END M1. Since modules M0 and M1 can only be compiled using a tricky sequence of editing and compilation steps, isn’t an endless recursion in the loader a perfectly acceptable solution for such a pathological case? PS: There are at least two ways to avoid the endless recursion: 1. Catch the cyclic import during compilation. This would require modifying module ORB. It has been done before, not that hard. about 25-50 additional lines. 2. An iterative module loader. This too has been done. Just not in PO 2013.

1 0