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

Nimrod is not Oberon
by Stefan Salewski 02 Oct '14

02 Oct '14

Yes, I am still subscribed to this list... And I noticed that "Oberon on FPGA" project, but have not read much about it. Recently, when I was looking about some news about Mozillas Rust language, I discovered Nimrod, a language which looks similar to Modula/Oberon, with some interesting new features. Nimrod is not very popular now, some people simple do not like the Wirthian style syntax. (And of course there are many other interesting new languages available now, Mozillas Rust with C syntax, Julia for numerical computing, Haskell -- not really new, but still modern...) But maybe someone of you may be interested in Nimrod. Of course it is no operating system, just a modern language. Keywords: Wirthian syntax, with Python indentation, system- and high-level programming, garbage-collector which still allows time critical applications, advanced generics, templates, high-level macros. Good support for parallel processing. Speed seems to be close to C. Currently Compiler generates C intermediate code. Currently there is no wikipedia entry (was rejected) so it is difficult to discover it. There was an article in DrDobbs Journal recently, and of course there is a homepage with a tutorial. http://nimrod-lang.org/ http://www.drdobbs.com/open-source/nimrod-a-new-systems-programming-languag… Not a high rank at http://langpop.corger.nl/ but Oberon is not listed at all ;-) Best regards Stefan Salewski

3 3

Re (2): Re (2): Oberon.OpenDisplay
by peter＠easthope.ca 01 Jun '14

01 Jun '14

From: eas lab <lab.eas(a)gmail.com> Date: Mon, 26 May 2014 04:55:15 +0200 > So can you tell me how to set the frame [of User + System track] narrower, ... I referred to OpenDisplay in NO where DW is the full width of the screen. > ... ETHO on top of Linux. That's the Oberon subsystem in UnixAos? If so please refer to http://carnot.yi.org/ComputerSystems.html#OLPC . Particularly the last bullet before "Requirements ..." It explains two methods to open a smaller Oberon subsystem inside the Aos boundary and then magnify the Oberon. Legibility was improved for me. If someone has an automated way of magnifying, that will help more. The whole process should be the same for the Oberon subsystem in native A2 but I haven't tested. I'll be revising that page soon. If you have any suggestions, please reply. > Lately I've seen, for the first time 2 <buttons> on the extreme left of > of the menu-frame, ... "extreme right" isn't it? NO has them also. In the text document viewer. > Why didn't they put them on the left, next to the > existing ones? Search me. I tend to prefer the plain old Text viewer. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://carnot.yi.org/ Bcc: peter at easthope. ca

2 1

Obstacles when programming in RISC Oberon and proposed patches
by Michael Schierl 30 May '14

30 May '14

Hello, in general I like the simplicity of Oberon (and that you usually can find the cause of some problems quickly since Oberon itself is written all in Oberon and small enough to find what you search) but at some places, I think Oberon could be more pleasurable without making it a lot more complex. Therefore I prepared a few patches - if you like them, feel free to incorporate them, and if not, I can still use them :) If there is a better place to submit patches (or Git pull requests) like this, feel free to tell me. 1. Uninitialized local variables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When something is allocated on the heap with NEW, all bytes are zeroed out (in Kernel.New). Variables declared at the top of the module are also zeroed out (in Modules.Load). Only local variables that live on the stack are not zeroed out, but stay what they are. It is easy to miss an initialization, resulting in a program that "sometimes works". On the other hand, it is also easy to patch the compiler to zero out these stack areas: https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/init… When recompiling all Oberon from scratch and using it for a few days, you will notice that System.Clear is no longer working (since its "buf" variable was not initialized). Before it worked most of the time, but TRAPped sometimes... Patch to fix: https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/syst… 2. Allocation failures and Garbage Collection ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One of the disadvantages of Oberon's simple garbage collector (but still complex enough that I did not find time to wrap my head around it) is that it can only run "between" commands. So, when you compile something while 30% of the heap are used an allocation fails during compilation, it is not possible to run the GC to collect these 30% and then continue with compilation. Basically I guess the reason is that objects referenced from stack are ignored by the garbage collector, so it would collect "live" objects if it was run from within Kernel.New (but I'm not sure there, correct me if I'm wrong). As I said, the GC is too complex for me to "fix" (and probably it would make it even more complex if it was fixed), so I'm trying a different approach. In practice, it is no big deal to just run System.Collect followed by a recompilation if this situation arises. The largest problem is when running own code, whether the TRAP is a real programming error or just some allocation failure in the middle of some core library. Therefore I created a patch which will check in Oberon.Loop if there was a failed allocation since the last invocation and prints a message to Oberon.Log: https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/log-… That way, it is clearly visible whenever allocation fails and it may be a good idea to just re-run the command after garbage collection. 3. Trap Backtraces ~~~~~~~~~~~~~~~~~~ Sometimes, when programming, you get some TRAP null dereference somewhere deep in Texts of Files or another system module and need to add some debugging statements to find out which of your calls to these modules passed the NIL value. This is a tedious task, and other programming languages like C or Java have a simple solution for it: On an assertion or breakpoint, scan the stack for pointers to code that are directly behind a branch (BL or BLR in case of RISC Oberon), and print the offsets of these instructions. In case of C, you'll get some false positives sometimes, but in practice that does not matter as it is still a lot better than having no backtrace at all (in Java, the frames are linked and therefore the JVM can tell exactly which of the values are return pointers and which are data, therefore a backtrace is "exact" there). I think it got most popular by laxly configured Java webservers, which often print long stack traces on its HTTP 500 error pages visible to customers. In combination with debug symbols, these offsets can also be decoded back to original line numbers. Oberon does not have debug symbols, but traps already use some unused bits in the BLR instruction to encode the position where the trap occurred. So it is easy to change the other BLR instructions to include the position at the same place. BL instructions, however, don't have enough free bits to encode the position, so I decided to prefix every BL instruction by a dummy BLR instruction that uses condition flags 0FH (which can never be fulfilled) and encode the position in there. To make the lines of the backtrace easier "followable", the position is printed as 123@ModuleName, and Edit.Locate is enhanced to detect this syntax and if the marked viewer does not have ModuleName.Mod open, open a new viewer with that module and locate the position in there. This can certainly be enhanced to scan for an open viewer and use it, but in practice where there are no more than 2 or 3 different interesting modules in the backtrace, this simple solution suffices for me. Patch is here: https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/trap… Tell me what you think about it - or if you have ideas to solve these problems in a better way :) Regards, Michael

3 5

Re: [Oberon] Re (2): Project Oberon: New Edition
by eas lab 26 May '14

26 May '14

Some ideas on HCI: we techies overlook it's importance; which is demonstarted by stupid notation like "a better experience". What's that ? It needs to be analysed. There's a Swiss HCI specialist who AFAIK is/was associated with ETHO. Focus on the human psychology, not the computer hardware. Although we all differ, some basic evolved human attributes are: short-term memory limited to ca. 3 items; recognision is mot limited by memory. This automatically leads to the menu-concept, which TUI has. We all learned to read and are forced to exercise it in daily life, so menu-items are conveniently: recognisable test-strings. Lifting your arm to point to a screen, is only for short/baby tasks. Perhaps with mobile-devices you can rest your arm. Although the reflexive chording-at-the-mouse position can't be equaled, probably <verb> <noun>...<noun> notation can be efficient. Many tasks can use this. Like: verb:ReplaceAllUntilNextVerb To From1 ...FromN But can mobile devices conveniently/accurately select a text-stretch? ---------------- The other essential capability, where ETHO excels is multiple files simultaneously visible/accessible. Most non-trival tasks needs 4,5,6 files visible/accessible at once. == Chris Glur. On 12/22/13, peasthope(a)shaw.ca <peasthope(a)shaw.ca> wrote: > Claudio and everyone, > > From: Claudio Nieder <private(a)claudio.ch> > Date: Sun, 22 Dec 2013 02:40:43 +0100 >> ... unnecessary fragmentation. > > Yes, fragmentation is probably the biggest obstacle to efficient > use of computing. > >> Some people on this list care mostly about the TUI and are happy >> having that with any other kind of OS running beneath of it. >> Others might even hate the TUI because the mouse-interclicks >> cannot be translated to touch screens ... > > There is a very simple and effective way of integrating the familiar > Oberon TUI with the gestural touchscreen approach. The result, I > believe, is more powerful than any extant interface. > > I have a description of this interface and am working on a prototypical > implementation. To avoid pre-emption of the ideas by commercial > interests, details have not yet been published. > > Best Regards, ... Peter E. > > -- > 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 > Tel +1 360 639 0202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon >

5 5

Re (2): Oberon.OpenDisplay
by peter＠easthope.ca 26 May '14

26 May '14

From: =?utf-8?Q?J=C3=B6rg_Straube?= <joerg.straube(a)iaeth.ch> Date: Sat, 17 May 2014 08:37:18 +0400 > Standard Oberon display has a User track on the left and a System track on the right. > W0 is the width of the User track, DW-W0 is the width of the System track. Thanks. I was stuck in an inane mental block about the meaning of W0. > Read chapter 4.6 in > http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf The next day I realized that the definition of Oberon.OpenDisplay is also clear about the widths. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://carnot.yi.org/ Bcc: peter at easthope. ca

2 1

ETHO is an engineer's tool,
by eas lab 24 May '14

24 May '14

rather than just a F/B twitter app. This is ETHO:ALO for rPi, still being ported/developed, building on decades of proven/tested work. Select a task to test the current capabilities of ETHO:ALO Traversing the Dir-tree ? OFSTools.Mount home LinuxFS /home/ ~ System.Directory home:* ==... 31 files System.Directory home:*\d ==... shows which are dirS [4096 size] => select one: home:Suspend 26.11.2012 01:30:18 159086 klux /home/Suspend == unix format EditTools.OpenUnix /home/Suspend =?=> took few seconds to laod this 159K TextFrame; but looks good. -- ! Now for a task where ETHO excels (sp?) /home/Suspend has got bad M$ chars, eg. 2 lines look like:-- point. A user typically employs this facility via an interactive interâÄé face supplied jointly by the operating system kernel's terminal driver but should read: [such problems mess my TextToSpeech] point. A user typically employs this facility via an interactive inter- face supplied jointly by the operating system kernel's terminal driver It's difficult to replace these non-ASCII chars with *nix [let's see if this works: Hex.Open Suspend == WOW, yes! Now just paste from <the Hex.Open Viewer>; OK, I remember that <Hex.Open Viewer> is 'abnormal': contents can't be selected. But I can see the 3-bad-chars: âÄé == E2 80 90 <-- nonASCII. AND in ETHO you can color them -- but when this mail is posted, they may become invisible?] So now, ETHO:ALO simply replaces the 3badChars with "-", via 2 mouse operations. Interestingly, the find/replaceALL was much faster than the LoadViewer. ===> So, Store the fixed file, and let's walk-thru /usr -- OFSTools.Mount usr LinuxFS /usr/ ~ System.Directory usr:*\d == ... usr:lib 06.02.2014 08:34:13 12288 11 files use 68K bytes -- OFSTools.Mount usr:lib LinuxFS /usr/lib/ ~ System.Directory usr:lib*\d == usr:lib 06.02.2014 08:34:13 12288 =?=> only one; why not print "1 files use 12K bytes" Lets go to Linux mc to see ? No, /usr/lib/ has many files & sub-dirs. What have I done wrong? ALO chose the name "usr:lib" for /usr/lib/, so I should NOT use that. Let's try: OFSTools.Mount UsrLib LinuxFS /usr/lib/ ~ == UsrLib: OFSLinuxFiles: Can't open directory IIRC, LNO OFSTools.Mount adds an entry to: System.Watch But here:ALO, I get only:- System.Watch 18387K of 22528K memory free 18028K contiguous memory free It could be a problem, if the list-of-mounted can't be shown? -- Let's reStart ALO:b140523 to see if we can: OFSTools.Mount UsrLib LinuxFS /usr/lib/ ~ Yes ! == UsrLib: mounted System.Directory UsrLib:*\d == ... UsrLib:coreutils 28.10.2012 22:54:57 4096 <- a dir UsrLib:aspell 28.10.2012 23:33:44 12288 <- probable TxtFile? ... 228 files use 135605K bytes <- that's better! -- Hex.Open UsrLib:aspell == TRAP 103 HALT statement Hex.Open aspell == TRAP 103 HALT statement klux aspell == TRAP 103 HALT statement klux UsrLib:aspell == TRAP 103 HALT statement -- => reStart ALO:b140523 to see if we can: OFSTools.Mount UsrLib LinuxFS /usr/lib/ ~ == ok Hex.Open UsrLib:aspell == TRAP 103 HALT statement EditTools.OpenUnix aspell ==TRAP 103 HALT statement EditTools.OpenUnix oberon.log == ... ListModels loaded. Hex loaded. Received Trap nr. -103 at Trap handling level 0 ... TextDocs loaded. EditTools loaded. Received Trap nr. -103 at Trap handling level 0 Processor State: R0 = 00000000H R1 = 0008ACFCH R2 = 00000000H R3 = 00000000H R4 = BEA03FF0H R5 = 012F89FCH R6 = 012F87BCH R7 = 00081200H R8 = 00081200H R9 = 0129B600H RA = 00000009H RB = BEA0401CH FP = BEA04024H SP = 00000240H LR = 010000BCH CPSR= 0008BE6CH DefaultTrapHandler: Received signal nr. -103 in Kernel PC=000849A4H (00003718H) Kernel PC = 00004944 ... Interesting insight to ARM's 12 registers? == Tea time.

1 0

ALO [for rPi] becoming quiet usable,
by eas lab 24 May '14

24 May '14

and well past the 'proof of concept' stage. Like a child, that extends it's capability by usage and refinement. Version 140423 Projects tested:- 1. Modify & Compile 'Hello World ==OK 2. A major capability still missing is <Edit.Open/Store Acsii> currently I use *nix to convert textFiles between Linux <-> ETHO. 3. Access Files from WHOLE-Tree, by: navigate to required file [I use mc] & call script: MkSlnk <FileName> <YourChosenName> [mc needs 1 key-stroke for <FileName>]. This appends, to your ProjectFile: <YourChosenName> <FileName> So your ProjectFile may look like:-- Project Apples ============= AppleMeds /home/Jon/Fruit/Aples/Diseases AppleMarket /home/Jil/Econ/FruitSales ... Project Legal ============= ResJudicata /mnt/media/Legal/SCA/2009/TLC ..... Project nextOne ============ ... So if you need the file: /home/Jil/Econ/FruitSales you just klux: AppleMarket This keeps the ETHO method of MenuDriven & few kliks. Just like a *.Tool Version 140508 Projects tested:-- Runs without need for `xhost +` After updating Oberon.Text , [new feature] able to:OFSTools.Mount Linux LinuxFS /home/ ~ -> System.Directory Linux:* == Good !! -> System.Directory Linux:*\d == Yes !! But I can't paste the results here, because mouseSelect does not SHOW. Only after much messing, did I realise that it DOES select. This could be a difficult problem to debug?! BTW, it took me a long time to remember that you are allowed to key in: `System.Directory ^` if you can't paste it. Thanks for good job by Peter Matthias. == Chris Glur.

2 5

NEW on POINTER TO RECORD always results in NIL (RISC Oberon) - bug?
by Michael Schierl 22 May '14

22 May '14

[I tried to post this message about a month ago and never received any feedback - seems that it never got approved. Now that I'm subscribed to the list, I'll try again :)] Hello, When trying to compile this short example in RISC Oberon (using the Windows emulator/distribution from projectoberon.com) ------------------------------------------- MODULE BugTest; IMPORT Texts, Oberon; TYPE P1 = POINTER TO P1Desc; P1Desc = RECORD a: INTEGER END; P2 = POINTER TO RECORD a: INTEGER END; PROCEDURE DebugPrint(VAR str : ARRAY OF CHAR); VAR w : Texts.Writer; BEGIN Texts.OpenWriter(w); Texts.WriteString(w,str); Texts.WriteLn(w); Texts.Append(Oberon.Log, w.buf); END DebugPrint; PROCEDURE TestAlloc*(); VAR v1: P1; v2: P2; v3: POINTER TO P1Desc; v4: POINTER TO RECORD a: INTEGER END; BEGIN NEW(v1); IF v1 # NIL THEN DebugPrint("OK1") ELSE DebugPrint("NIL1") END; NEW(v2); IF v2 # NIL THEN DebugPrint("OK2") ELSE DebugPrint("NIL2") END; NEW(v3); IF v3 # NIL THEN DebugPrint("OK3") ELSE DebugPrint("NIL3") END; NEW(v4); IF v4 # NIL THEN DebugPrint("OK4") ELSE DebugPrint("NIL4") END; END TestAlloc; END BugTest. ------------------------------------------- It always outputs "OK1 OK2 OK3 NIL4" into the Log (I'd have expected that it printed OK4 as well). Is that a bug in the compiler, or actually intended behavior? The actual code I'm using is a bit more complex (I'm playing with adding paravirtualized clipboard support and some more things to the emulator; if I ever get it working fine, I'll release patches of course, unless anyone beats me to it [edit: which I succeeded and a changed version that did not require the kludge that made me find this bug was successfully merged into Peter De Wachter's emulator]), and it took me quite some time to track down that issue... Regards, Michael

5 6

ORL.Mod
by Charles Perkins 19 May '14

19 May '14

I would like to be able to create the inner core startup binary image that is loaded by the RISC5 boot loader from the flash. Does anyone have a copy of the ORL.Mod file that they can share with me or can it be made generally available? Chuck

3 6

Oberon.OpenDisplay
by peter＠easthope.ca 17 May '14

17 May '14

When a display is wider than 640 pixels, Oberon.OpenDisplay opens the left boundary of the displayed area a distance to the right of the y axis. Specifically, Oberon.Mod has W0 := DW DIV 8 * 5; IF W0 < 400 THEN W0 := 0 END; OpenDisplay(W0, DW - W0, DH); For example, if DW = 1024 and DH = 768 then W0 = 640 and OpenDisplay(640, 380, 768); is executed. Why not just OpenDisplay(0, 1024, 768); or, in general, OpenDisplay(0, DW , DH); for any size of display? There must be a sound reason but it escapes me at present. Thanks, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://carnot.yi.org/ Bcc: peter at easthope. ca

3 3