- Oberon - mailman3.inf.ethz.ch

Portings Texts.Mod to Oberon-7, my Artemis project
by Robert Doiel 20 Jun '21

20 Jun '21

This list discussion around Oberon Texts has been inspiring. It is been so inspiring I've create a GitHub repository named Artemis: > Artemis is an Oberon-7 module collection. My hope is > to encourage continued use and development of the Oberon-7 > language and encourage convergence towards compatibility > in implementations of Oberon-7 compilers. This ties back to the Texts discussion in one significant way. I am planning to port both S3 (Native Oberon) Texts.Mod and V4 (Linz) Texts (Texts.Mod, Elem.Mod, etc) to Oberon-7. That code will wind up in Artemis and be used to implement an "ocat" (like Joseph Templ's ocat from ofront) that will work for each of the type of Texts. I've looked at each implementation and I think unifying them is beyond my skill but porting each one would be extremely useful, especially from a preservation point of view. I am not promising fast (or successful) development. I am one of those dreaded hobbyist when it comes to Oberon. I think the collection will be useful as it evolves. It is likely to hold my interest for quite some time. I think it will be especially for useful for fellow novices exploring Oberon-7 on POSIX. https://github.com/rsdoiel/Artemis Feed back welcome, criticism is helpful, pull request exciting. You can reach me on this email list and via GitHub issue (https://github.com/rsdoiel/Artemis/issues) All the best, Robert Doiel

7 11

Re (2): Re (2): Re (2): UEFI
by peter＠easthope.ca 16 Jun '21

16 Jun '21

From: Liam Proven <lproven(a)gmail.com> Date: Tue, 15 Jun 2021 18:57:17 +0200 > IME ... used to be purely for remote management of server hardware. IME is enough to exclude a network connected modern PC from a safety critical application. An unpredictable glitch or failure of a machine which could cause death or serious injury is intolerable. Similarly for an application with significant resources at risk. In banking for example. Similarly where scientific or industrial espionage is possible. The only way to prevent illicit access is make sure there is no back door. Hence a FPGA based embedded system or workstation. A workstation such as being developed by Wojciech. Regards, ... P.L. -- tel: +1 604 670 0140

3 2

Just stumbled across this in connection with my blogpost from last night
by Liam Proven 16 Jun '21

16 Jun '21

http://www.edm2.com/index.php/Oberon -- Liam Proven – Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk – gMail/gTalk/gHangouts: lproven(a)gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

2 2

Re (2): Re (2): UEFI
by peter＠easthope.ca 15 Jun '21

15 Jun '21

From: Liam Proven <lproven(a)gmail.com> Date: Tue, 15 Jun 2021 17:21:12 +0200 > > https://en.wikipedia.org/wiki/Intel_Management_Engine > > Aha! Right. That is an entirely unrelated issue. IME is separate from UEFI. Correct? IME provides another way that an external party might access a machine for a purpose unwanted by the machine owner. UEFI imposes another layer of complexity not intrisic to the user objective but requiring attention for the machine to serve a purpose. In the Oberon philosophy, neither of those is desirable. Regards, ... P.L. -- tel: +1 604 670 0140

4 3

Re (2): UEFI
by peter＠easthope.ca 15 Jun '21

15 Jun '21

From: Liam Proven <lproven(a)gmail.com> Date: Tue, 15 Jun 2021 16:23:28 +0200 > UEFI is not proprietary and it is documented: > https://uefi.org/specifications > > UEFI is derived from EFI. EFI is Intel's firmware for Itanium > computers. EFI is proprietary. UEFI is not. Thanks. > What backdoor problem is this? https://en.wikipedia.org/wiki/Intel_Management_Engine > Is it [Oberon on the Skulski machines] not already? V5 might work now. Fairly sure that none of V4, ETH Oberon and A2 work yet. Regards, ... P.L. -- tel: +1 604 670 0140

2 1

Re: [Oberon] UEFI
by peter＠easthope.ca 15 Jun '21

15 Jun '21

Liam Proven lproven at gmail.com Tue Nov 24 17:21:59 CET 2020 > As such, the fact that UEFI works so badly with non-MS OSes seems > likely to be quite intentional to me, and that it only cooperates with > big enterprise server OS vendors. The situation is difficult for small > FOSS players and not materially improving. > ... > The Oberon community needs to try to ensure that Native Oberon > and/or A2 continue to work on vanilla PC hardware. Liam, does UEFI being proprietary and undocumented mean that Native Oberon or A2 on contemporary machines is impossible without Herculean reverse engineering? Even if UEFI is navigated, the backdoor problem remains. Another motivation to put Oberon on the Skulski machines? Andreas suggested RISC-V. Can it also have a backdoor? Regards, ... P.L. -- tel: +1 604 670 0140

2 1

(small) bug in Fractions.Generate (in SmallPrograms.Mod)
by Hans Klaver 13 Jun '21

13 Jun '21

Hi all, Some time ago I spotted a small but pesky inaccuracy in the output of the command Fractions.Generate (part of SmallPrograms.Mod in the online sources of Project Oberon). Until then I only knew the versions of this program in the books 'Programming in Oberon' and 'Programming, a Tutorial', which give the correct output. Last December I reported this by e-mail to prof. Wirth, but I didn't get any reply. I hope he is doing well. The online version that is part of Project Oberon gives the following output (with => pointing to the correct output): 2 .5'0 3 .3'3 => .'3 4 .25'0 5 .2'0 6 .1'6 7 .1'428571 => .'142857 8 .125'0 9 .1'1 => .'1 10 .1'0 11 .0'90 => .'09 12 .08'3 13 .0'769230 => .'076923 14 .0'714285 15 .0'6 16 .0625'0 I corrected the Oberon-07 source code as follows to let it produce the correct output (corrected lines indicated by (**) ). ORP.Compile @/s Fractions.Generate 16 MODULE Fractions; (*NW 10.10.07; Tabulate fractions 1/n*) IMPORT Texts, Oberon; CONST Base = 10; N = 32; VAR W: Texts.Writer; (* (* Original version, with bug *) PROCEDURE Generate*; VAR i, j, m, r: INTEGER; d: ARRAY N OF INTEGER; (*digits*) x: ARRAY N OF INTEGER; (*index*) S: Texts.Scanner; BEGIN Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(S); IF (S.class = Texts.Int) & (S.i < N) THEN i := 2; WHILE i <= S.i DO j := 0; WHILE j < i DO x[j] := 0; INC(j) END ; m := 0; r := 1; WHILE x[r] = 0 DO x[r] := m; r := Base*r; d[m] := r DIV i; r := r MOD i; INC(m) END ; Texts.WriteInt(W, i, 5); Texts.Write(W, 9X); Texts.Write(W, "."); j := 0; WHILE j < x[r] DO Texts.Write(W, CHR(d[j] + 48)); INC(j) END ; Texts.Write(W, "'"); WHILE j < m DO Texts.Write(W, CHR(d[j] + 48)); INC(j) END ; Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf); INC(i) END END END Generate; *) (* Corrected version *) PROCEDURE Generate*; VAR i, j, m, r: INTEGER; d: ARRAY N OF INTEGER; (*digits*) x: ARRAY N OF INTEGER; (*index*) S: Texts.Scanner; BEGIN Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(S); IF (S.class = Texts.Int) & (S.i <= N) THEN i := 2; WHILE i <= S.i DO j := 0; WHILE j < i DO x[j] := 0; INC(j) END ; m := 0; r := 1; WHILE x[r] = 0 DO INC(m); (**) x[r] := m; r := Base*r; d[m] := r DIV i; r := r MOD i (**) END ; Texts.WriteInt(W, i, 5); Texts.Write(W, 9X); Texts.Write(W, "."); j := 1; (**) WHILE j < x[r] DO Texts.Write(W, CHR(d[j] + 48)); INC(j) END ; Texts.Write(W, "'"); j := x[r]; (**) WHILE j <= m DO Texts.Write(W, CHR(d[j] + 48)); INC(j) END ; Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf); INC(i) END END END Generate; BEGIN Texts.OpenWriter(W) END Fractions. -- Hans Klaver

1 0

Re (2): Oberon Text and new systems;
by peter＠easthope.ca 12 Jun '21

12 Jun '21

Michael, Our preceding two emails were mostly at crossed purposes. Two use cases can be visualized. One, a system where the programming content of computer science can be taught. For that, I understand that V5, Text included, works beautifully. Two, a simple workstation for engineering and science. That's what I understand interests Wojciech. V4 and ETH Oberon have been used in that capacity for over two decades already. Update of V4 and ETH Oberon to run on a FPGA machine is conceivable. From: Michael Schierl <schierlm(a)gmx.de> Date: Tue, 8 Jun 2021 23:02:57 +0200 > So, I would not try to provide any (badly compatible) HTML5 support to > a system like Oberon which tries to be simple and tries to remove what > can be removed. Acknowledged. I don't imagine a Web browser. Rather an alternative to Oberon Text. It exists already in V4 as Web.Open <something>.html and in ETH Oberon as Desktops.OpenDoc <something>.html . Capabilities are very limited but comparable to Text. A few revisions for consistency with HTML5 are visible in https://en.wikibooks.org/wiki/Oberon/A2#Sources,_Tools_and_Configuration_Te… . Sources Oberon.HTML.Mod and Oberon.HTMLDocs.Mod . > By the way, V5 text does not have vertical offsets, so no > subscripts/superscripts. Acknowledged. Vertical offset has no significance in Oberon source Text. Not needed in V5. A few observations. * As ETHO is distributed, the Oberon.Text configuration file, is Oberon Text. The system boots and runs just as well if the file is stored as plain ASCII. * The configuration file in A2 is Configuration.XML. It can be edited with most editors in a contemporary Linux, MacOS or MS Windows system. * Most of the A2 sources in the repository at https://svn-dept.inf.ethz.ch/svn/lecturers/a2/trunk/source/ are plain ASCII. Once authenticated, sources in the left column at https://en.wikibooks.org/wiki/Oberon/A2#Sources,_Tools_and_Configuration_Te… can be displayed with a single mouse click. Simplification of a workstation is possible and worthwhile. Regards, ... P.L. -- tel: +1 604 670 0140 Bcc: peter at easthope. ca

4 5

Re: [Oberon] FPGA based machine? Was, Oberon Text and new systems for science.
by peter＠easthope.ca 12 Jun '21

12 Jun '21

Chris Burrows cfbsoftware at gmail.com Thu Jun 10 09:05:51 CEST 2021 > I'm left wondering: your V4 software will still run today on Windows > 10 running Linz V4 will it not? If not, why not? If it does run OK, > what are you hoping to gain by repeating the exercise on the FPGA? Near 49:50 in lecture "Reviving a computer system of 25 years ago - Wirth, 2014", https://www.youtube.com/watch?v=EXY78gPMvl0 , a similar question was asked, with Prof. WIrth answering "... no side doors and no back doors." As anticipated, cyberattacks have been in the news recently. https://www.power-technology.com/features/the-five-worst-cyberattacks-again… Criminal interference is as much a concern in science and engineering as in banking and commerce. Sooner or later, the Skulski machines might attract serious interest. Regards, ... P.L. -- tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0

Oberon Text and new systems; was Re (n): Question about Oakwood guidelines and design choices
by peter＠easthope.ca 10 Jun '21

10 Jun '21

From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> Date: Mon, 7 Jun 2021 17:21:05 +0000 > Since you said Text, please be aware that there are multiple Text > flavors out there. The section at https://en.wikibooks.org/wiki/Oberon#Oberon_Text is intended to be understandable to a novice. Under the subheading "Additional Details" is the link to https://en.wikibooks.org/wiki/Oberon/Text where the variant systems are addressed in more detail. Sorry to say, V4 is not yet included. =8~( When encountering Text, visualization of the record types was difficult for me. The tables you see in the second page cited above are my way of mitigating difficulty. > 3) I believe that System 3 did about the same as #2 above, but in a > more complex way. In ETH Oberon and in A2, Texts.TextDesc is an extension of Objects.ObjDesc. Consequently, understanding the Text type requires understanding records defined in two modules--Objects and Texts. An additional difficulty for a newbie. In the tables, the extension is represented by background color shading. The display of types concisely in one place should help a novice. > 6) I suspect that porting #2 [V4] to the FPGA Oberon would entail a > complete replacement of the 2013 Text and text frames with the ones > from Linz V4. This will not be easy not because of the code, but > because of the language: "they" changed the language so V4 will no > longer compile. Didn't Andreas discuss or mention that months ago. Three steps to put an "old" system, S, on a new machine. (1) In an extant S, translate the sources into Oberon-07. In the process, the sources can be recompiled by the compiler in S. This is just work; time consuming but not lethal. =8~) (2) In the new system, compile all the sources of S. (3) Install and run the revised S on the new machine. S can be V4 or ETH Oberon or another. > I am afraid that (4+Gadgets) is unlikely to fit into a small memory > footprint. For basic Text functionality, the complete Gadgets machinery is not necessary. Build a system with the Objects module and the Texts module? I haven't evaluated the memory requirement. If someone drafts a V4 section and adds it to https://en.wikibooks.org/wiki/Oberon/Text , the contribution will be welcome. Accept that merciless editing can happen. =8~| Should a universal Oberon Text type be derived from V4, ETH Oberon or V5? Also acknowledge that HTML5 is far more ubiquitous than any Oberon Text type. Hypothetically an Oberon system can be built with plain ASCII text and HTML5 and no Oberon Text. Discussion by the knowledgeale and experienced people can help. Regards, ... P.L. -- tel: +1 604 670 0140 Bcc: peter at easthope. ca

6 7