August 2026 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Export of Oberon Mail.SendCmd().
by Joerg 30 Oct '26

30 Oct '26

Generally, re-using code instead of copying is a good approach. If you do so, then the whole code of Mail is imported in News. Possible but perhaps there is even a better approach to re-use code. What about this: try to separate all common code in an own module (e.g call it Communication.Mod or MsgBase.Mod or Utilities.Mod or so) and import this new module in Mail and in News. br Jörg > Am 14.06.2023 um 19:53 schrieb peter(a)easthope.ca: > > Hello again, > > Several procedures in Mail are used in Oberon News. Rg.: > Mail.ParseContent(), Mail.DecodeMessage() & Mail.GetSetting(). > > Is export of SendCmd() and use in News objectionable? > Ie. in Mail, change PROCEDURE SendCmd(...) to PROCEDURE SendCmd*(...). > > Thanks, ... P. > > - > mobile: +1 778 951 5147 > VoIP: +1 604 670 0140 > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Why are `*` and `^` interpreted by individual Oberon commands?
by նորայր 08 Sep '26

08 Sep '26

Hello, I have been thinking about the design of command arguments in the Oberon System, and I would be interested to hear the reasoning behind one particular choice. When I execute something like ``` Compiler.Compile * ``` the system does not expand `*` into some representation of the marked viewer and then pass that to `Compiler.Compile`. Instead, the `Compile` procedure receives the command arguments and itself recognizes `*` and obtains the appropriate text from the marked viewer. Similarly, with ``` Compiler.Compile ^ ``` it is the command procedure itself that interprets `^` and obtains the current selection. I find this interesting when comparing it with the Unix shell model. For example, with ``` ls * ``` the shell expands `*` first, and `ls` receives the resulting list of filenames. `ls` does not need to know that the user originally typed `*`. So I am wondering: why was the Oberon command system designed so that conventions such as `*` and `^` are interpreted by individual commands rather than by the system or command interpreter? It seems that system-level expansion could make commands simpler and establish a common argument mechanism: a command could receive a text/file argument without needing to know whether the user specified it by name, by `*`, by `^`, or perhaps by some future mechanism. On the other hand, I suspect there may be a reason why this would not fit the Oberon model. Perhaps `*` and `^` are intentionally not "argument expansion" at all, but ways for a command to interact with the state of the user interface, and therefore their interpretation belongs to the command. Was this an explicit design decision? And are there advantages to having commands interpret these conventions themselves rather than putting such interpretation into the command execution mechanism? I would be very interested in how people familiar with the Oberon system design think about this distinction. Thank you, norayr

3 4

New ARM board with Oberon-2 firmware
by Liam Proven 17 Aug '26

17 Aug '26

https://linuxgizmos.com/blue-pill-style-stm32c5-board-adds-oberon-2-firmwar… I know nothing at all about this but thought it might be interesting. The design is here: https://github.com/tenko/STM32C5-eval-board This tells me that the Oberon is ECS https://ecs.openbrace.org/ -- Liam Proven ~ Profile: https://about.me/liamproven ~ LinkedIn/X/FB: lproven Email: lproven(a)cix.co.uk ~ Google: lproven(a)gmail.com IoM: (+44) 7624 227612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

1 0

The 2013 Project Oberon System running on RISC-V instead of RISC-5
by Rochus Keller 06 Aug '26

06 Aug '26

Hello everyone In case anyone is interested, I recently migrated the Project Oberon System available on http://www.projectoberon.com to Oberon 90 so it compiles with my OP2 version with the RISC-V backend. The project also includes a virtual machine similar to the architecture Wirth described in his new version of the Project Oberon book, but using the RISC-V instead of the RISC-5 instruction set. See https://github.com/rochus-keller/OberonSystem/tree/op2-rv32 for more information. There is a precompiled version for Linux x64 so far. Best regards Rochus Keller

3 3

Re: [Oberon] The 2013 Project Oberon System running on RISC-V instead of RISC-5
by peter＠easthope.ca 06 Aug '26

06 Aug '26

Rochus, From: Rochus Keller <me(a)rochus-keller.ch> Date: Wed, 05 Aug 2026 16:11:12 +0200 > ... I recently migrated the Project Oberon System available on > http://www.projectoberon.com to Oberon 90 so it compiles with my OP2 > version with the RISC-V backend. Wonderful project. Thanks! Please excuse a naive question. In my current thinking, the file system in Oberon and the file system in the host environment are independent. Correct? Communication between the two file systems is limited to a dedicated copy command or possibly an ftp command. Correct? Thx, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 778 508 0020 <= decommissioned Bcc: peter at e a s t h o p e dot c a projects: en.wikibooks.org/wiki/User:PeterEasthope

3 6

Re: [Oberon] clock_gettime / Traps on 32-bit Puppy Linux
by peter＠easthope.ca 01 Aug '26

01 Aug '26

Michael, From: Michael Schierl <schierlm(a)gmx.de> Date: Sun, 2 Aug 2026 00:15:34 +0200 > Okay, at some point curiosity won and I added lots of trace calls to > Linux.Unix.Mod's thread start and exit sequence. It send me down > writing test programs to test pthread thread local storage, ... Considering my skill level, you're investigation is super-human. > Maybe xopup comes with the proper debugger tools that one could > use to trace this down, I just cannot run it due to not having an > XO. Pardon ignorance but is the problem limited to this and possibly other Puppy Linuxes? Not affecting all 32 bit systems? Thanks, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 778 508 0020 <= decommissioned Bcc: peter at e a s t h o p e dot c a projects: en.wikibooks.org/wiki/User:PeterEasthope

2 1

Re: [Oberon] clock_gettime
by peter＠easthope.ca 01 Aug '26

01 Aug '26

From: Felix Friedrich <felixf(a)ethz.ch> Date: Thu, 16 Jul 2026 08:15:45 +0200 > ... set AOSCONFIG="TraceModules 1" ... before starting A2? Yesterday without "TraceModules 1". https://easthope.ca/A2trap2026.07.15.txt Today with "TraceModules 1". https://easthope.ca/A2trap2026.07.16.txt This Linux with Busybox has limitations not present in most Linuxes. The failure occurs early in A2 startup and I should find a way to follow that? Thx, ... P. -- mobile: +1 778 951 5147 VoIP: +1 778 508 0020 <= decommissioned Bcc: peter at e a s t h o p e dot c a projects: en.wikibooks.org/wiki/User:PeterEasthope

3 4

Re (2): A2 start. Was "clock_gettime."
by peter＠easthope.ca 01 Aug '26

01 Aug '26

> ... asked ChatGPT (you can follow along at > <https://chatgpt.com/share/6a6d2167-ab74-83ed-8fa6-63c4041ea7fa> ... Probably look on the next weekend. I'm not anxious to admit but AI does help in some cases. > Feel free to try it and tell me how far it works for you. Yes. Will try the patch. Thanks! ... P. -- mobile: +1 778 951 5147 VoIP: +1 778 508 0020 <= decommissioned Bcc: peter at e a s t h o p e dot c a projects: en.wikibooks.org/wiki/User:PeterEasthope

1 0