- Oberon - mailman3.inf.ethz.ch

Syntax highlighting justified?
by peter＠easthope.ca 27 Nov '24

27 Nov '24

From: Paul Reed paulreed at paddedcell.com, Thu Nov 21 19:15:40 CET 2024 > Personally I agree with where you're coming from. So I've reverted the hightlighting edit and added an explanatory note highlit with a green background. =8~/ https://en.wikibooks.org/wiki/Oberon/The_Oberon_System,_V1_and_V2#Sources_i… Hypocritical but I wanted to make it obvious. If the green is too much, happy to remove it. I'd rather cite Wirth's sources in a more permanent and tamper proof location. At present, don't know of any. Feedback welcome, thanks, ... P. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Re (2): Syntax highlighting justified?
by peter＠easthope.ca 21 Nov '24

21 Nov '24

Paul, Thanks for replying. From: Paul Reed <paulreed(a)paddedcell.com> Date: Thu, 21 Nov 2024 18:15:40 +0000 > Maybe it was an AI. :) Let's call it automated chaos. =8~) > Personally I agree with where you're coming from. Also in my experience > Prof. Wirth was pretty scathing about arguments which in the end boiled > down to matters of taste. Right oh. For reference by others, will leave for a few days before reverting. Additional replies welcome. Besides adding a note that the styling is Wirth's and to please not change, edit protection may be possible. Can investigate. A third way to preserve Wirth's orginals is to put in Wikisource. It's expressed in HTML (it's on the Web) but but presented as the original (resistant to tampering as PDF is). https://en.wikisource.org To me, Wikisource would honor Wirth's work but won't consider it without approval of Wirth's family and academic authorities. I acknowledge that original publications remain available from bookstores and libraries and the wikibook isn't necessary. My argument is about accessibility. Most of the population of the world doesn't have convenient access to an academic library and out-of-print books can be expensive. Always open to debate. Thanks & BR! ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Re: [Oberon] Syntax highlighting justified?
by Paul Reed 21 Nov '24

21 Nov '24

Hi Peter, > A recent edit of Oberon/V2/Input in the wikibook replaced my style tag > with tag 'syntaxhighlight lang="oberon2"'. Ugh! For so many reasons. > You'll see that the edit was made from an address rather than from an > authenticated account. Maybe it was an AI. :) > My original styling was crafted to imitate the appearance in Wirth's > book. Black text in the Times New Roman font. syntaxhighlight uses a > Helvetica (?) font with keywords colored green. Personally I agree with where you're coming from. Also in my experience Prof. Wirth was pretty scathing about arguments which in the end boiled down to matters of taste. HTH, Paul

1 0

Syntax highlighting justified?
by peter＠easthope.ca 21 Nov '24

21 Nov '24

Hi, A recent edit of Oberon/V2/Input in the wikibook replaced my style tag with tag 'syntaxhighlight lang="oberon2"'. Links to the two versions are at the top of the history page. https://en.wikibooks.org/w/index.php?title=Oberon/V2/Input&action=history If the two versions are marked, a click on "Compare selected revisions" will show the changes side by side. You'll see that the edit was made from an address rather than from an authenticated account. My original styling was crafted to imitate the appearance in Wirth's book. Black text in the Times New Roman font. syntaxhighlight uses a Helvetica (?) font with keywords colored green. I appreciate the eagerness of an itinerant editor to help but sometimes "help" misses an intention. My instinct is to keep Wirth's styling. (A note about that at the top of the page may be justified.) What do experts say? Leave syntaxhightlight? Revert to Wirth's styling. Thanks, ... P. L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Announcement: Oberon for the Raspberry Pi Pico and Pi Pico 2
by Chris Burrows 08 Nov '24

08 Nov '24

We recently released Astrobe for RP2040 which can be used to write Oberon software to run on the Raspberry Pi Pico microcontroller boards. This will be followed up later this month by the release of Astrobe for RP2350 which targets the new Raspberry Pi Pico 2 boards. For more details see the Astrobe forum announcement: https://www.astrobe.com/forum/viewtopic.php?f=3&t=799 The RP2040 is based on an Arm Cortex-M0+ processor whereas the RP2350 uses the more powerful Arm Cortex-M33 design. During testing we came up with the following performance comparison: https://www.astrobe.com/forum/viewtopic.php?f=19&t=803 The test program that we ran was originally written in Modula-2 by Wirth for his Lilith computer. It is documented in Appendix 2 of the *ETH Report Nr 40 - The Personal Computer Lilith* (The Yellow Report). Apr 1981. N. Wirth which you can download from: https://www.astrobe.com/Modula2/ The results shown there indicate (taken with a huge grain of salt) that the Pi Pico is ~ 50x faster, and the Pi Pico 2 is ~ 100x faster than a Lilith. The price comparison of the systems is even more impressive at ~ 5000x: The Lilith cost ~ $US 8000 (~ $US 25,000 today) whereas you can get a Pi Pico 2 for $US 5 Regards, Chris Burrows -- CFB Software https://www.astrobe.com

1 0

Ceres-3 on Vintage Computer Festival Europa
by Pablo Cayuela 10 Sep '24

10 Sep '24

In the recent event Vintage Computer Festival Europa, the hardware developer Udo Möller presented his reconstruction of the Ceres-3 recreated on FPGA based on his NS32k CPU clone: https://www.youtube.com/watch?v=cEdHiE-HoGE&t=2145s I hope you enjoy it! Prof. Pablo Cayuela

2 2

lfs for the A2 repository.
by peter＠easthope.ca 16 Aug '24

16 Aug '24

Hi, Appears my local A2 repository is up to date. root@imager:~/A2# git pull origin main hint: Pulling without specifying how to reconcile divergent branches is hint: discouraged. ... >From https://gitlab.inf.ethz.ch/felixf/oberon * branch main -> FETCH_HEAD Already up to date. This is the tracking report. root@imager:~/A2# git lfs track Listing tracked patterns ARM/ARM.A2/*.bin (ARM/ARM.A2/.gitattributes) Linux32.zip (.gitattributes) Linux64.zip (.gitattributes) LinuxARM.zip (.gitattributes) Win32.zip (.gitattributes) Win64.zip (.gitattributes) *.bin (.gitattributes) *.zip (.gitattributes) linux*.zip (.gitattributes) Listing excluded patterns Now I want to retrieve the latest Linux64.zip. git lfs fetch Linux64.zip Invalid remote name "Linux64.zip": invalid remote name: "/home/root/A2/Linux64.zip" Linux64.zip isn't currently available? Another problem? Thanks, ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Working directory in A2.
by peter＠easthope.ca 26 Jul '24

26 Jul '24

Hi, In Guenter's UnixAOS the working directory is obtained by "cd workingDirectory". In repository A2 on Linux, the working directory is set by this line in oberon.ini. Files.SetWorkPath <path>~ The installed "Files.SetWorkPath work~" is relative to the A2 starting directory and "Files.SetWorkPath /home/me/A2/Linuz64/work~" is an absolute location. Correct? In A2, Files > Files shows WORK. With the last setting above, a click on WORK lists the files in the working directory. WORK is capitalized for similarity to a volume in ETH Oberon? Another meaning? Thanks, ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Fighting a dragon ...
by Hans Klaver 18 Jul '24

18 Jul '24

Hi all, The dragon curve is an interesting space filling curve that you can approximate by endlessly folding a slip of paper. Apparently I'm not the only one who is fascinated by it; Don Knuth has one decorating a wall in his home: https://www.youtube.com/watch?v=v678Em6qyzk (and yes, it has a bug). When making a program to draw dragon curves of different orders for Oberon V5 (Project Oberon 2013) I noticed that odd order dragons look well and healthy but even order dragons degrade into shapeless worms (see the two screenprints on my github page for dragons of order 9 and 10). The same algorithm in BASIC and Python produces nice dragons of all orders, albeit MUCH slower that my Project Oberon version. For the source files and screenprints see: https://github.com/hansklav/Fractals-in-Oberon-07/tree/main/Dragon-curves First I suspected that a difference between Oberon's MOD operator versus BASIC's MOD and Python's % operators was the culprit, so I made a function REM to mimic them, but that had no effect. Then I pinpointed a problem in the way the Oberon V5 compiler handles an expression for certain values of its variables in my code. Please run the following two commands in Oberon V5, and behold that they unexpectedly give different results: MODULE TestDragon; (* hk 11 July 2024 *) IMPORT Math, Out; (* For Math.power see: https://github.com/hansklav/Oberon-07/blob/master/Math.Mod *) CONST pi = 3.1415926535; p = 4.0; (* order of dragon curve *) PROCEDURE Correct*; (* TestDragon.Correct *) (* correct result for x2 *) VAR h, x1, x2: REAL; s: INTEGER; BEGIN s := 0; x1 := 7.499998E-01; h := 2.500000E-01; Out.String("s = "); Out.Int(s, 2); Out.String(" h ="); Out.Real(h, 14); Out.Ln; x2 := x1 + h * Math.cos( (FLT(s) - p/2.0) * pi/2.0 ); (* <-- expression tested *) Out.String("x1 ="); Out.Real(x1, 14); Out.Ln; Out.String("x2 ="); Out.Real(x2, 14); Out.Ln; Out.Ln END Correct; PROCEDURE Incorrect*; (* TestDragon.Incorrect *) (* incorrect result for x2 *) VAR h, x1, x2: REAL; s: INTEGER; BEGIN s := 0; x1 := 7.499998E-01; h := Math.power(2.0, -p/2.0); (* the result for h from Math.power() is correct: *) Out.String("s = "); Out.Int(s, 2); Out.String(" h ="); Out.Real(h, 14); Out.Ln; x2 := x1 + h * Math.cos( (FLT(s) - p/2.0) * pi/2.0 ); (* <-- why incorrect result?? *) Out.String("x1 ="); Out.Real(x1, 14); Out.Ln; Out.String("x2 ="); Out.Real(x2, 14); Out.Ln; Out.Ln END Incorrect; END TestDragon. The first command gives the correct result (0.4999998), which can easily be verified by pasting the following line in https://www.wolframalpha.com/ : 7.499998E-01 + 2.500000E-01 * cos((0 - 4/2) * pi/2.0) But why the same expression in the second command gives a wrong result (0.6249998) for the same values of its variables as the first command escapes me. Could anyone give an explanation?? Because I cannot reproduce this incorrect behaviour using the OBNC compiler, I suspect a compiler error. Regards, Hans Klaver

4 22

WinAos on ARM
by Hürlimann Bruno 09 Jul '24

09 Jul '24

ETH PlugIn Oberon for WindowsTM / WinAos 2.03 050530 on Windows ?? Version 6.2.9200 h@HEA43 Hello I work with WinAos and have switched to an ARM processor. Now the system is no longer stable. System functions such as Edit.Store lead to crashes. Is there an AOS version for ARM processors and how can I download this EXE file? Greetings Bruno Hürlimann

1 0