October 2016 - Oberon - mailman3.inf.ethz.ch

Source code browser in NO
by Srinivas Nayak 25 Mar '17

25 Mar '17

Dear All, Do we have any source code browser in NO? I see we have Definitions browser in NO. Using Watson, if we create *.Def and *.Def.html, we can browse through Definitions. Anything similar for source code? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

4 5

Re: [Oberon] Concurrency support in Oberon
by John R. Strohm 25 Nov '16

25 Nov '16

No, Oberon has no concurrency support in the language. The Oberon system provides a simple event loop, that allows programmers to do simple round-robin run-til-done scheduling. --- sinu.nayak2001(a)gmail.com wrote: From: Srinivas Nayak <sinu.nayak2001(a)gmail.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: [Oberon] Concurrency support in Oberon Date: Thu, 21 Jan 2016 20:27:05 +0530 Dear All, We had Pascal, We came to its successor Modula-2. Then we came to its successor Oberon. But do we still have the concurrency programming support in Oberon, which was present in Modula-2? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/ -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

16 24

Oberon for a C++ user.
by Andreas Pirklbauer 16 Nov '16

16 Nov '16

Chris, Joerg:that is exactly the problem: assigning a procedure of a *client* module to a procedure variable of an *imported* module, and then unloading the client module - leaving the procedure variable in the imported module dangling.Assigning a procedure of a client module to a variable of an imported "base" module is in fact the standard way the Oberon system itself employs procedure variables to implement the viewer system in an object-oriented style.For example, module TextFrames (the client) installs a handler (procedure TextFrames.Handle) in the field F.handle of text frame F (see TextFrames.NewText and TextFrames.Open for the details), where the record field F.handle is declared as a procedure variable in the "base" module Viewers (see Viewers.ViewerDesc), which also manages the viewer data structure (see procedure Viewers.Open). Except that of course in the case of the Oberon system, the "client" module TextFrames *never* gets unloaded, so this is not a problem there. Thus, the burden is on the user to make sure that such modules never get unloaded.It is of course possible to implement a "procedure variable" counter - in analogy to the "module counter" employed in Oberon: each time an assignment to a procedure variable is made, the counter gets increased. But that would require changing the code generator compiler for assignments, and the module loader (Modules.Load) and unloader (Modules.Free). But I would refrain from introducing such complexity to the compiler and runtime system.Andreas Chris Burrows chris at cfbsoftware.com > Joerg, > > OK - you may well be onto something here but it is incomplete as it is. Something has to> import Square so that the module body is executed, or you need an exported procedure in> Square that is called from the OS. > > Note: there are a couple of semicolons missing and Init must be exported.> > Chris. > -----Original Message----- > From: Jörg Straube [mailto:joerg.straube at iaeth.ch] > Sent: Saturday, 1 October 2016 2:22 PM > To: chris at cfbsoftware.com; ETH Oberon and related systems > Subject: Re: [Oberon] Oberon for a C++ user. > > Chris > > Here a possble example that might cause issues: > > MODULE Figure; > TYPE > DrawProc = PROCEDURE; > Figure = POINTER TO FigureDesc; > FigureDesc = RECORD > next: Figure; > draw: DrawProc > END; > VAR list: Figure; > PROCEDURE Init(d: DrawProc) > VAR f: Figure; > BEGIN > NEW(f); f.next := list; list := f; > f.draw := d > END Init; > BEGIN list:= NIL END Figure. > > MODULE Square; > IMPORT Figure; > PROCEDURE DrawSquare; > BEGIN (* do what ever you > need to do to draw a square *) > END DrawSquare > BEGIN > Figure.Init(DrawSquare) > END Square. > > Now you could run Square and unload Square. The list in Figure has a > reference to unloaded code. > > J rg >

16 54

Re: [Oberon] Availability of OberonStation
by Chris Burrows 14 Nov '16

14 Nov '16

> > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Ken Boak > Sent: Monday, 18 January 2016 7:29 PM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Availability of OberonStation > > Have any of the list had experience of the Oberon system on the > Xilinx Artix-7 - specifically on the $99 Arty board - is this a > preferred platform? > It is likely that I have had the most experience on the Xilinx Artix-7 seeing as I ported our 'embedded' subset of ProjectOberon to the Arty board ;-) I agree with Walter. Oberon-07 is an ideal language for developing embedded applications. I'm not sure what you mean by 'preferred platform'. The Arty (Artix-7) and the Pippistrello (Spartan-6 LX45) development boards are the only two I have found so far that have sufficient BRAM to run embedded ProjectOberon without external SRAM. Saanlima's Pippistrello is about $50 more than the Arty. However, the Pippistrello does have a built-in SD Card socket and can also be used as an ProjectOberon Workstation development system with Saanlima's optional Oberon SRAM 'Wing'. There are many simpler FPGA boards available but all the ones I have found use less-capable FPGA devices with insufficient BRAM. The Arty and the Pippistrello have more features than are needed for embedded Oberon applications like those on the ARM Cortex-M3/M4 boards that we support. However, I guess that doesn't matter for those who are designing their own boards and just want an off-the-shelf reference system to use for prototyping / proof of concept. If on the other hand you want to run the complete Project Oberon 'workstation' system with VGA / HDMI, keyboard and mouse. You will need a board with external SRAM like the OberonStation. An Arty would not be suitable for this purpose. > Finally, and perhaps best addressed to Chris Burrows - I see that > you have produced packages for the ARM M3 and M4 Cortex - mainly NXP. > Do you have any aspirations to port to Cortex M7 - such as the $50 > STM32F7 Discovery Platform - which has a great selection of useful > hardware on-board? > There used to be an clear distinction between the simple 8-bit microcontroller at one end of the spectrum and the 64-bit PC at the other. In recent years the two have started to converge. The embedded systems are becoming more powerful; the PCs are becoming smaller and less power-hungry - the distinction is blurring. The STM32F7 Discovery Platform seems to me to be more a miniature PC than a high-power embedded system. While we remain focused on supporting embedded systems we are unlikely to be targeting it, Regards, Chris Chris Burrows CFB Software http://www.astrobe.com/RISC5

34 147

Parameterized and parameterless versions of a procedure.
by peter＠easthope.ca 26 Oct '16

26 Oct '16

The Oberon syntax in A2 allows parameterized and parameterless (command) versions of a procedure to be in one definition. Correct? Is this possible in Native Oberon? Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Safe module unloading
by Andreas Pirklbauer 24 Oct '16

24 Oct '16

The case of inheritance (type extension in Oberon) is now fully covered in the latest version of safe module unloading in Experimental Oberon. See Kernel.Check, Modules.Free and Oberon.GC. It also covers the case where a structure rooted in a variable of base type T declared in a module M contains elements of an extension T' defined in module M’. Andreas ----------------------------------------------------------------------------------- Lars noreply at z505.com <mailto:oberon%40lists.inf.ethz.ch?Subject=Re:%20Re%3A%20%5BOberon%5D%20Safe%20module%20unloading&In-Reply-To=%3C44c2905716ce81a33bb4b7ce00da692b.squirrel%40gator3286.hostgator.com%3E> Mon Oct 24 02:24:50 CEST 2016 > The only remaining problem is the case where a structure rooted in a > variable of base type T declared in a module M contains elements of an > extension T' defined in module M'. I was going to say, what about inheritance? I'm not too familiar with oberon inheritance but if another module inherits from another module, then all modules would have to be unloaded that connect to each other? Actually, this makes me want to read up on oberon inheritance, as I'm more familiar with delphi inheritance. But even that is a complex nightmare

1 0

Safe module unloading
by Andreas Pirklbauer 24 Oct '16

24 Oct '16

Wojtek, The “safe module unloading” solution is now almost fully implemented in the (inner) core of Experimental Oberon. After unloading, references to the unloaded module are set to NIL (global pointer references are set to NIL explicitly in procedure Modules.Free, references from dynamic heap objects are collected by the garbage collector which is invoked when a module is unloaded, see Modules.Free and System.Free). This means that the system will no longer crash when a module is (force-)unloaded and another module tries to execute a procedure variable that previously pointed to the now unloaded module. Now, it will merely produce a TRAP 5 message (“illegal procedure call”) in the system log viewer. The only remaining problem is the case where a structure rooted in a variable of base type T declared in a module M contains elements of an extension T' defined in module M'. In Oberon 2013, the system can crash after module M' is unloaded (namely when the space previously occupied by module M' - containing its type descriptors - is overwritten by another module N that is small enough to fill the hole left behind after the unloading of M’). In Ceres-Oberon this problem was circumvented by persisting type descriptors in main memory which was achieved by allocating them in the heap rather than placing them as constants (which is what they are) in the module block space. In Experimental Oberon, module M’ normally simply cannot be unloaded, eliminating the problem altogether. But it becomes a problem if a user forces the unloading of module M' via the /f option. This can be addressed in various ways, I just haven’t done it yet. Total implementation cost (inner core and compiler): - Kernel: + 18 lines - Modules: + 25 lines - ORG: + 7 lines (needed to produce an extended object file format) Total: 50 lines Andreas —————————————————————— Skulski, Wojciech skulski at pas.rochester.edu <mailto:oberon%40lists.inf.ethz.ch?Subject=Re:%20Re%3A%20%5BOberon%5D%20Safe%20module%20unloading%20%28was%3A%20Re%3A%20Oberon%20for%20a%20C%2B%2B%20user.%29&In-Reply-To=%3CCY1PR07MB22136B7AE4F42CE9F473B5C6FFDA0%40CY1PR07MB2213.namprd07.prod.outlook.com%3E> Tue Oct 11 15:47:58 CEST 2016 Andreas: it looks like a great development to me. Given the simplicity of your solutions, I wonder if they should not just become a standard part of the "official" 2013 Oberon System. Should they not get backpropagated to Professor NW, with a note that it shows the strength and vitality of the Oberon community which he started? Wojtek ________________________________________ From: Oberon [oberon-bounces at lists.inf.ethz.ch <https://lists.inf.ethz.ch/mailman/listinfo/oberon>] on behalf of Andreas Pirklbauer [andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>] Sent: Monday, October 10, 2016 1:21 PM To: Oberon List Subject: [Oberon] Safe module unloading (was: Re: Oberon for a C++ user.) 1. I have uploaded a new version of System.SecureFree that now performs *all* checks (including the check whether there are any global procedure variables in other modules that reference procedures of the module to be unloaded). 2. Writing NIL to all references (and type tags!) when unloading is forced via a /f option is in fact included, but only in the version that is integrated with the garbage collector. The reason is that if it were done outside the existing garbage collector (as is the case in the proof-of-concept version that is currently published), it would immediately break the garbage collector (because it references tags without checking whether they are NIL - see procedure Kernel.Scan for example). If I decide to include “safe module unloading” in the Oberon core, there would also be a /f option and, if selected, all references and tags to unloaded modules would be set to NIL. That’s the holy grail. It is fully implemented. Meanwhile, you can just use System.Free (which does not perform the checks). Andreas ——————————————————————— On Mon, 10 Oct 2016 12:51:39 +CEAR, Chris wrote: > On Sat, 8 Oct 2016 19:28:55 +0200, Andreas Pirklbauer wrote: > > I’d welcome more input on this topic.. all I wanted to show is that > > it is *doable* (proof of concept) and that the effort is very small. > > > >Whether it *should* be done is another question. It remains open. > Thanks for this great write-up. I think the effort is so small that it > should be included in the system. This would close the biggest hole in > the Oberon system. > I would prefer to improve the forced unload function by writing NIL to > all references that would close the last hole (I hope) in the system > for the occurrence of dangling pointers. > Greetings, chris

2 1

Safe module unloading
by Andreas Pirklbauer 23 Oct '16

23 Oct '16

Just a final remark that “completely safe module unloading" is now fully implemented in Experimental Oberon. - System.Free M … does not unload a module if references to M exist (pointer refs, procedure refs, type refs) - System.Free M/f … forces module unload in spite of references, but in such a way as to never crash the system The experiment showed that it can be done with less than 50 lines of code (without the /f option) and less than 100 lines (with the /f option), but I would not recommend implementing the /f option (persisting type descriptors used by other modules is a bit cumbersome indeed). Andreas ———————————————————————————— Wojtek, The “safe module unloading” solution is now almost fully implemented in the (inner) core of Experimental Oberon. After unloading, references to the unloaded module are set to NIL (global pointer references are set to NIL explicitly in procedure Modules.Free, references from dynamic heap objects are collected by the garbage collector which is invoked when a module is unloaded, see Modules.Free and System.Free). This means that the system will no longer crash when a module is (force-)unloaded and another module tries to execute a procedure variable that previously pointed to the now unloaded module. Now, it will merely produce a TRAP 5 message (“illegal procedure call”) in the system log viewer. The only remaining problem is the case where a structure rooted in a variable of base type T declared in a module M contains elements of an extension T' defined in module M'. In Oberon 2013, the system can crash after module M' is unloaded (namely when the space previously occupied by module M' - containing its type descriptors - is overwritten by another module N that is small enough to fill the hole left behind after the unloading of M’). In Ceres-Oberon this problem was circumvented by persisting type descriptors in main memory which was achieved by allocating them in the heap rather than placing them as constants (which is what they are) in the module block space. In Experimental Oberon, module M’ normally simply cannot be unloaded, eliminating the problem altogether. But it becomes a problem if a user forces the unloading of module M' via the /f option. This can be addressed in various ways, I just haven’t done it yet. Total implementation cost (inner core and compiler): - Kernel: + 18 lines - Modules: + 25 lines - ORG: + 7 lines (needed to produce an extended object file format) Total: 50 lines Andreas —————————————————————— Skulski, Wojciech skulski at pas.rochester.edu <mailto:oberon%40lists.inf.ethz.ch?Subject=Re:%20Re%3A%20%5BOberon%5D%20Safe%20module%20unloading%20%28was%3A%20Re%3A%20Oberon%20for%20a%20C%2B%2B%20user.%29&In-Reply-To=%3CCY1PR07MB22136B7AE4F42CE9F473B5C6FFDA0%40CY1PR07MB2213.namprd07.prod.outlook.com%3E> Tue Oct 11 15:47:58 CEST 2016 Andreas: it looks like a great development to me. Given the simplicity of your solutions, I wonder if they should not just become a standard part of the "official" 2013 Oberon System. Should they not get backpropagated to Professor NW, with a note that it shows the strength and vitality of the Oberon community which he started? Wojtek ________________________________________ From: Oberon [oberon-bounces at lists.inf.ethz.ch <https://lists.inf.ethz.ch/mailman/listinfo/oberon <https://lists.inf.ethz.ch/mailman/listinfo/oberon>>] on behalf of Andreas Pirklbauer [andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon <https://lists.inf.ethz.ch/mailman/listinfo/oberon>>] Sent: Monday, October 10, 2016 1:21 PM To: Oberon List Subject: [Oberon] Safe module unloading (was: Re: Oberon for a C++ user.) 1. I have uploaded a new version of System.SecureFree that now performs *all* checks (including the check whether there are any global procedure variables in other modules that reference procedures of the module to be unloaded). 2. Writing NIL to all references (and type tags!) when unloading is forced via a /f option is in fact included, but only in the version that is integrated with the garbage collector. The reason is that if it were done outside the existing garbage collector (as is the case in the proof-of-concept version that is currently published), it would immediately break the garbage collector (because it references tags without checking whether they are NIL - see procedure Kernel.Scan for example). If I decide to include “safe module unloading” in the Oberon core, there would also be a /f option and, if selected, all references and tags to unloaded modules would be set to NIL. That’s the holy grail. It is fully implemented. Meanwhile, you can just use System.Free (which does not perform the checks). Andreas ——————————————————————— On Mon, 10 Oct 2016 12:51:39 +CEAR, Chris wrote: > On Sat, 8 Oct 2016 19:28:55 +0200, Andreas Pirklbauer wrote: > > I’d welcome more input on this topic.. all I wanted to show is that > > it is *doable* (proof of concept) and that the effort is very small. > > > >Whether it *should* be done is another question. It remains open. > Thanks for this great write-up. I think the effort is so small that it > should be included in the system. This would close the biggest hole in > the Oberon system. > I would prefer to improve the forced unload function by writing NIL to > all references that would close the last hole (I hope) in the system > for the occurrence of dangling pointers. > Greetings, chris

1 0

Re: [Oberon] Numerical CASE Statements in Project Oberon
by Chris Burrows 23 Oct '16

23 Oct '16

> -----Original Message----- > From: Chris Burrows [mailto:chris@cfbsoftware.com] > Sent: Saturday, 7 November 2015 11:33 PM > To: ETH Oberon and related systems (oberon(a)lists.inf.ethz.ch) > Subject: Numerical CASE Statements in Project Oberon (was: [Oberon] > RISC.img) > > > > > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > > Jan de Kruyf > > Sent: Friday, 6 November 2015 8:37 PM > > To: Paul Reed; ETH Oberon and related systems > > Subject: Re: [Oberon] RISC.img > > > > 2. Question: > > I see that the 'numerical' CASE implementation is missing in > ORP.Mod, > > although it is in the language spec and although we might > reasonably > > expect people to port programs from O2 to O7. > > > > Would it be in the interest of the community for me to try and > > implement that part, at least for constant labels? > > > > Don't even think about implementing it unless you are planning to do > it properly - a half-baked solution would be worse than none. e.g. I > would expect a complete solution to include the implementation of a > RISC6 (or RISC5.1 maybe?) processor which has indexed-branch > statements. > I have now implemented a numerical CASE statement in Astrobe for Embedded Project Oberon for compatibility with the Oberon compiler used in Astrobe for the ARM-Cortex targets. I was wrong about the RISC5 processor instruction set. It does not need any additional instructions in order to be able to implement an efficient branch table-driven numerical CASE statement. It already has a branch instruction that sets the address of the next instruction to be the value of a register. The index into the jump table can be computed and stored in that register. Apologies for any confusion, Regards, Chris Chris Burrows CFB Software http://www.astrobe.com/RISC5

2 1

Fwd: A little weakness of operators syntax and COPY() removing
by Stéphane Aulery 17 Oct '16

17 Oct '16

Hello, A little weakness of Oberon syntax is that logical operators for conjunction and negation are "&" and "~" but disjunction is "OR". Maybe it's because the CASE syntax encroaching on its domain. OR could be | CASE p OF P0: p.b := 10 | P1: p.b := 2.5 | P2: p.b := {0, 2} END could be CASE p OF P0: p.b := 10 OR P1: p.b := 2.5 OR P2: p.b := {0, 2} END There also SELECT p OF P0: p.b := 10 CASE P1: p.b := 2.5 CASE P2: p.b := {0, 2} END but it's unusual. It's just a little idea. ------ I find also a possible minor error in https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf page 15. But COPY have been removed according to https://www.inf.ethz.ch/personal/wirth/Oberon/OberonAtAGlance.pdf for the whole language or only outside SYSTEM module? Regards, -- Stéphane Aulery

2 2