- Oberon - mailman3.inf.ethz.ch

Re (2): Re (2): The Radiar A2 Swiss industrial controller.
by peter＠easthope.ca 11 Nov '21

11 Nov '21

Hello Josef, In Details_en.pdf "1 MB battery-buffered RAM". "battery-buffered" =? "battery-backed" Booting begins from the 1 MB? > It is a good idea to include it in the Oberon#Computers. https://en.wikibooks.org/wiki/Oberon#Computers 3rd row. Complaints, corrections, editing welcome. Thanks, ... P. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0

Re (2): The Radiar A2 Swiss industrial controller.
by peter＠easthope.ca 11 Nov '21

11 Nov '21

Josef, From: Josef Sedlacek <sedlacek(a)swissonline.ch> Date: Tue, 2 Nov 2021 10:55:57 +0100 > We are still delivering A2 swiss industry controllers to Asia, > Wnamely Singapore. They are used for gravimetric feeding and blending > in Taiwan and also in main China. Thanks. A turnkey system; correct? Appears the controller might also serve as a workstation running A2. Is the controller sold alone? Include here? https://en.wikibooks.org/wiki/Oberon#Computers Better not? Thanks again, ... P. L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

2 1

Identities of releases and References.Text from ETH Oberon.
by peter＠easthope.ca 10 Nov '21

10 Nov '21

Michael Schierl schierlm at gmx.de Thu Sep 9 21:20:09 CEST 2021 > Codenames are a different story, but I would not use "alpha" or "beta" > as a codename for a release, just because it can be confused with the > software release phases. "Alpha" removed from the headings of the tables. (Less is more.) https://en.wikibooks.org/wiki/Oberon/ETH_Oberon#Module_Sources_in_ETH_Obero… For completeness, the old References.Text is now included here. https://en.wikibooks.org/wiki/Oberon/ETH_Oberon#Texts_in_ETH_Oberon I've made an effort to preserve the original appearance. To compensate for dead links, I've added two footnotes; one with a link to Sourceforge; the 2nd with a link to the Bibliography page. Criticisms and suggestions welcome. Thx, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0

The Radiar A2 Swiss industrial controller.
by peter＠easthope.ca 02 Nov '21

02 Nov '21

Jörg joerg.straube at iaeth.ch, Sun Oct 10 21:03:44 CEST 2021: > ... company Radiar http://www.radiar.ch/page_en.html still uses Oberon. Mention of a variety of applications in the Details PDF suggests the "controller" is a general purpose computer. Has anyone made ETH Oberon, A2 or V5 work on ite? Thanks, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

3 2

Modules in C++20
by Hans Klaver 25 Oct '21

25 Oct '21

Recently in a local bookstore I was browsing through (the Dutch translation of) a book by Bjarne Stroustrup, 'A Tour of C++'. Somewhat surprised I read that C++20 has (or will have) modules à la Wirth (complete with import and export) as a better alternative for header files and #include. Stroustrup writes that using #include in a wrong order is the biggest and most expensive source of bugs since 1972, when this mechanism was introduced in C. Well, I guess that after nearly 40 years Stroustrup & al. saw the light... Ofcourse they make modules much more convoluted than Wirth, with multiple 'module units', one of them being the 'module interface unit', and with 'module partitions'. And for the time being C++ will be using these modules next to #include; and then there are also namespaces in C++. Must give Niklaus Wirth some joy and satisfaction that he did these things the right way from the start (when designing Modula around 1976, Modula-2 around 1979, and Oberon around 1986). Regards, Hans Klaver The Netherlands

1 0

Array Index Out Of Range in ORG.FindPtrFlds
by Andreas Pirklbauer 24 Oct '21

24 Oct '21

> Ich bin mir nicht ganz sicher, aber sollte es nicht so heissen? > > > ELSIF typ.form = ORB.Array THEN FindPtrFlds(typ.base, off, dcw) END Nope. You need *all* pointer locations across *all* array elements .. otherwise the garbage collector will not find find all pointer locations. So for an array of N=3 records with pointer offsets 3, 37, 62 within each record, and a record size of S = 100 bytes, one needs the offsets 3, 37, 62, 103, 137, 162, 203, 237, 262. Obviously, for large arrays the number of pointer locations can quickly exceed the value of ORG.maxTD. One way to avoid storing the *same* offsets *N times* would be to store them in compact form, for example as [N = 3, S = 100, 3, 37, 62]. But then one also needs to adapt Kernel.Mark so it can interpret this format. Due to the possibility of recursive data structures, this is complex. Been there. Doable. But not recommendable.. PS: An alternative is to extend the intrinsic procedure NEW to allow NEW(p), where p is an array of pointers. That’s what I use in Extended Oberon. In the PO 2013 2013 version I have found no better solution than to (temporarily) increase ORG.maxTD :-(

3 2

Array Index Out Of Range in ORG.FindPtrFlds
by Andreas Pirklbauer 23 Oct '21

23 Oct '21

The following program compilers correctly in FPGA Oberon MODULE M1; TYPE P = POINTER TO R; R = RECORD a: ARRAY 160 OF INTEGER END ; (*compiles correctly*) END M1. but the following program leads to a trap 1 = array index out of range error in ORG.FindPtrFlds MODULE M2; TYPE P = POINTER TO R; R = RECORD a: ARRAY 160 OF P END ; (*trap 1 = array index out of range*) END M2. The reason is, of course, that ORG.data is an ARRAY maxTD (=160) OF INTEGER and ORG.FindPtrFlds traverses each array element individually to compute the offsets ELSIF typ.form = ORB.Array THEN s := typ.base.size; FOR i := 0 TO typ.len-1 DO FindPtrFlds(typ.base, i*s + off, dcw) END (*<--------*) Any suggestions how to address that in program M2 (or in the compiler, other than increasing maxTD)?

3 2

Array Index Out Of Range in ORG.FindPtrFlds
by Andreas Pirklbauer 18 Oct '21

18 Oct '21

> > MODULE M2; > > TYPE P = POINTER TO R; > > R = RECORD a: ARRAY 160 OF P END ; (*trap 1*) > > END M2. > > > > Any suggestions how to address that in program M2? > > > > What practical problem are you trying to solve with example M2? > > If I just wanted a list of pointers I would use a static array e.g. > > MODULE M3; > TYPE P = POINTER TO R; > R = RECORD a: ARRAY 160 OF INTEGER END ; > A = ARRAY 200 OF P; > END M3. > > — > Regards, > Chris Burrows > I have adapted the inner core to allow for *arbitrary* file sizes, using a Unix-like inode structure both on disk and in-memory. On disk, it’s easy as all reference are simply (integer) disk addresses. But in-memory, I want to dynamically allocate *intermediate* nodes (nodes containing “just” 256 pointers to other index nodes which then contain actual disk addresses of data sectors) *only when needed*. In Extended Oberon, the modification in Files.Mod is straightforward, as one can just allocate a dynamic array of pointers whenever needed: MODULE Files; TYPE IndexTable = ARRAY FileDir.IndexSize OF Index; (*<---*) FileDesc* = RECORD … sec: FileDir.SectorTable; (*direct data blocks*) ext: ARRAY FileDir.ExTabSize OF Index; (*single indirect blocks*) ind: POINTER TO IndexTable; (*<--- double indirect blocks*) ... END PROCEDURE Old*(name: ARRAY OF CHAR): File; … IF k > FileDir.ExTabSize THEN NEW(f.ind); (*<--- allocate an array of pointers on the heap*) Disk.GetSector(F.ind, f.ind^) END but in the FPGA Oberon version, I currently need to resort to either a) or b): a) allocate a record containing an array of INTEGER using NEW, but do plus some type casting back to pointers (=> ugly) b) just increase the constant ORG.maxTD to e.g. 300 (which actually works and which is what I currently use). PS: I have played with a “compressed” representation of the pointer locations in records containing arrays of pointers (noting that the offsets simply repeat themselves N times in an array) in ORG, but the result is just too cumbersome, as such data structures can be defined recursively => not pursued. In any case, I’ll use b) for now. Regards, Andreas

1 0

Re: [Oberon] Array Index Out Of Range in ORG.FindPtrFlds
by Chris Burrows 18 Oct '21

18 Oct '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Andreas > Pirklbauer > Sent: Monday, 18 October 2021 5:09 PM > To: Oberon List > Subject: [Oberon] Array Index Out Of Range in ORG.FindPtrFlds > > The following program compilers correctly in FPGA Oberon > > MODULE M1; > TYPE P = POINTER TO R; > R = RECORD a: ARRAY 160 OF INTEGER END ; (*compiles correctly*) > END M1. > > but the following program leads to a trap 1 = array index out of range error > in ORG.FindPtrFlds > > MODULE M2; > TYPE P = POINTER TO R; > R = RECORD a: ARRAY 160 OF P END ; (*trap 1 = array index out of > range*) > END M2. ... ... > Any suggestions how to address that in program M2 (or in the compiler, other > than increasing maxTD)? > What practical problem are you trying to solve with example M2? If I just wanted a list of pointers I would use a static array e.g. MODULE M3; TYPE P = POINTER TO R; R = RECORD a: ARRAY 160 OF INTEGER END ; A = ARRAY 200 OF P; END M3. -- Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5

1 0

Re (2): Andre's Watson.html.
by peter＠easthope.ca 11 Oct '21

11 Oct '21

From: Liam Proven <lproven(a)gmail.com> Date: Mon, 11 Oct 2021 13:14:36 +0200 > Small correction: > "below" -- located underneath; opposite of "above" > "bellow" -- to speak at maximum volume, to shout Acknowledged. Unfortunately I can't correct the mail archive. > This also looks strange: http://easthope.ca/Watson2.gif Gadgets implementation of V4 fold? Used to store multiple revisions in one file. https://en.wikibooks.org/wiki/Oberon#Glossary Never used it and don't know the correct terminology. > You mean this? http://easthope.ca/Watson3.gif Yes. Meant to have the appearance of an eye? I don't understand the purpose. > You might ask him directly, via Jörg's suggestion? ?? Joerg referred to OMEGA or Omega. To my understanding, not related to the Watson{2,3}.gif active entities. Thanks, ... P. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0