Jump to content

Oberon/FAQ

From Wikibooks, open books for an open world

Also refer to the ETH Oberon FAQ.

Q0. Why do some Oberon systems have a flat file system? Isn't a tree structured file system indispensable in highly productive (=8~/) contemporary environments?
A. The tree structured file system came into prominence during the 1950s and '60s when computer memories were miniscule. The tree structure helped with organization of the operating system. Typical memory access is far faster than file access. With current hardware, a data structure can be composed and used in memory with much faster performance than a data structure in a file system. With some focus on choice of meaningful names for files, most users will find the flat file system entirely adequate. Also, an emulated Oberon subsystem can have access to a tree structured file system of the host. Additionally, ETH Oberon running on a bare PC supports the FAT and ISO 9660:1988 file systems, which are tree structured. In reality, a flat file system in Oberon is a benefit rather than detriment.
Q1. Are Oberon and A2 fundamentally the same while having different interfaces?
A. Both systems respect the "simple as possible" principle. Otherwise they differ widely.
Central in Oberon is the task loop implemented in procedure Oberon.Loop. A procedure installed in the loop without backgrounding executes to completion in one pass of the loop. A long-running procedure can appear to the user as a queuing delay. During the long-running procedure, the only activity visible to the user will be output which the programmer has deliberately arranged. To avoid queuing delay, the programmer has the responsibility of implementing background execution. Backgrounding is achieved by dividing a large task into smaller portions which are inserted between other tasks in the loop. Therefore two levels of execution priority exist in Oberon: foreground and background.
Central in A2 is the active objects system (Aos). Processor time is allocated to active objects by time-slicing. This avoids queuing delay by limiting the time interval which a processor devotes to an active object. Time-slicing removes the responsibility for backgrounding from the programmer. Refer to Wikipedia and the thesis of P.J. Muller, section 4.2.3, page 35.
A2 has many aspects and capabilities not in preceding Oberons. Refer to the mailing list at 2022-01-07.
Q2. In ETH Oberon (or A2O) MM+MR opens a viewer with Edit whereas I prefer ET. How can that be fixed?
A. In ETH Oberon open TextFrames.Mod. MM on Edit.Open.
Edit.Open TextFrames.Mod
In the Oberon sub-system of A2.
Edit.Open Oberon.TextFrames.Mod
Change
OpenCmd = "Edit.Open"
to
OpenCmd = "ET.Open"
, MM on Edit.Store, recompile the module (TextFrames.Mod or Oberon.TextFrames.Mod) and reboot. TextFrames and all modules which import it could be reloaded but rebooting is simpler.