- Oberon - mailman3.inf.ethz.ch

EE, CE, CS buildings on the ETH campus.
by peter＠easthope.ca 22 May '21

22 May '21

Oberoners, Dozens of photos are here. https://commons.wikimedia.org/wiki/Category:ETH_Zurich I've never visited the campus. Can anyone suggest a photo pertinent to early Oberon development? Is an appropriate EE or CE or CS building prominent in one of the photos? Otherwise this? https://en.wikipedia.org/wiki/ETH_Zurich#/media/File:Sta_zentrum_hauptgebae… My objective is to include a photo on the title page of the wikibook. Thanks! ... P. L. -- tel: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

Michael Franz receives 2020 ACM Chuck Thacker Breakthrough Award
by Andreas Pirklbauer 17 May '21

17 May '21

Hi Chris, > Thank you for the info - that is a great achievement for him. His CV > is also quite impressive :) http://michaelfranz.com/cv.pdf Indeed, in particular the work around just-in-time-compilation e.g. for Mozilla that his team did in the 1990s and which was incorporated into Firefox etc, was excellent. Without that, browsers would not be so fast. From a technical point of view, I learned a lot from him - especially the many (very) clever techniques that he has used in MacOberon (some of which I have later adopted). Very bright fellow. However, from a "tech strategy" point of view, I believe it would have been good to just have gone to Sun Microsystems around 1992/93 - when work on Java was already underway - and propose his slim binary instead of the byte code that was later adopted. But that did not happen. When Sun released Java (with its byte code format) in 1995, I knew it was all over. And the jewel was gone. In all fairness though, one has to add that - unlike today - ETH was more detached from the rest of the world in those days. It went its own way, with a certain level of pride. Today, with modern communication means, it would be different (although I’m not sure Sun would have done anything different). Andreas

1 0

Re: [Oberon] Michael Franz receives 2020 ACM Chuck Thacker Breakthrough Award
by Chris Burrows 16 May '21

16 May '21

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Andreas Pirklbauer > Sent: Tuesday, 11 May 2021 1:09 AM > To: Oberon List > Subject: [Oberon] Michael Franz receives 2020 ACM Chuck Thacker > Breakthrough Award > > Just FYI: > https://www.acm.org/media-center/2021/april/thacker-award-2020 > > PS: Michael was my assistant in the course Informatik 3/4 given by > Niklaus Wirth in the late 80s. He also showed me many tricks in compiler > design.. > Thank you for the info - that is a great achievement for him. His CV is also quite impressive :) http://michaelfranz.com/cv.pdf The article he wrote "Oberon - the Overlooked Jewel" is a good read. It can be downloaded as a PDF file from several sources. Regards, Chris

1 0

INC(i) vs i := i + 1
by Jeff Maggio 16 May '21

16 May '21

Yeah, for our application I want to write very explicit code that's fairly self-explanatory as part of a tutorial so I chose i := i + 1. Even if they end up using INC(i) down the road, INC(i) isn't necessarily self-explanatory for a novice user without assembly experience *(like me for example)*. It's a small consideration though - I was mostly curious if they are compiled differently best, Jeff > My understanding is that if an experienced Python programmer just wanted to increment an integer variable they wouldn't write i = i + 1, instead they would write: > > i += 1 > > Similarly C++ programmers would write > > i++ > > INC(i) is the best match in Oberon for either of these statements. > > I suspect they would be unhappy if you told them to rewrite this in Python / C++ as > > i = i + 1 > > so they would see this as a disadvantage if they were told that they had to write it this way in Oberon. > > Regards, > Chris Burrows > CFB Softwarehttps://www.astrobe.com > >

6 10

Re (2): Re (n): Streams.
by peter＠easthope.ca 16 May '21

16 May '21

From: eas lab <lab.eas(a)gmail.com> Date: Sun, 16 May 2021 01:32:59 -0400 > <System.Execute ls -ta /mnt/OtherDevice/AnyDir | head -22> There was a similar command in A2. Did you check the current repository? https://en.wikibooks.org/wiki/Oberon/A2#The_A2_Repository > ... web-based-gmail ... Why not use the mail facilities in A2? https://en.wikibooks.org/wiki/Oberon/A2#Email Regards, ... P.L. -- tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0

Should hidden re-imports be able to coexist with identifiers
by Andreas Pirklbauer 16 May '21

16 May '21

Hi Luca, You are about half way through in convincing me.. ;-) .. and now that there is an easy way (i.e. 5 lines of code) to get rid of the “invalid import order” restriction also in the PO 2013 compiler (i.e. without having to make more elaborate changes as in oberonc/Griesemer’s approach), it’s tempting indeed. > 2. It breaks encapsulation. If I (module B) import a module, > A, I should only care about its public interface, not how it > is implemented. So if the module A re-imports types and > indirectly could mess with the import order of my module B, > we have implementation details leaking through. So when > the implementation changes the import order of the client > modules could break. That is a strong argument indeed! In essence, what you’re saying is that the very postulate of “modular programming” itself is violated here (namely that changes in the implementation of A should not necessitate the recompilation - or in this case even the re-editing (!) of the import list - of a client module B) . Although one can also view the re-exported types of A as *part* of its interface, in the sense that if A is modified such that it now also re-exports types from another module (that it previously didn’t re-export), the “interface” of A *does* actually change - surely the symbol file of A does. Thus, a client B must - at the minimum - be recompiled anyway. It just happens not to be the “public” part of A's interface that changes, but only the “hidden” part (=list of re-exported types). So.in principle, this should not be great cause for great concern, weren’t it for the fact that (the import list of) module B may now also have to be edited (!) before it can be re-compiled. * * * The crux is: It’s the fact that the re-import mechanism is a *hidden* mechanism (i.e. not in the spirit of Oberon) that causes much of the issue. PS: I have experimented with - and even implemented - a few possible ways to try to solve the root cause of the issue instead of tinkering with its symptoms, i.e. to get rid of the re-import mechanism altogether.. e.g. by explicitly marking re-exported types in the source file or something.. ..but I just couldn’t do it (at least not in a satisfactory manner). -ap

1 0

Re (n): Streams.
by peter＠easthope.ca 16 May '21

16 May '21

>From eas lab lab.eas at gmail.com Tue May 4 06:18:55 CEST 2021 > Can aos do: > list the 22 most recentcy-ordered > including <dotted files> in /tmp ? > eg.*nix: ls -ta /tmp | head -22 From: Joerg <joerg.straube(a)iaeth.ch> Date: Thu, 13 May 2021 09:33:24 +0200 > When you run linux virtualized on top of a windows machine, why > would you want linux to have a windows console? Windows wasn't mentioned. Chris has UnixAos on a Unix-like system running directly on a PC. Correct? If Chris has A2 on the native machine, Tools > Secure Shell can provide a console on a remote or external *nix system. Either way a command such as ls -ta /tmp | head -22 can execute with the result available in the console for another calculation. Regards, ... P. -- tel: +1 604 670 0140 Bcc: peter at easthope. ca

3 2

Should hidden re-imports be able to coexist with identifiers
by Andreas Pirklbauer 16 May '21

16 May '21

Ok, so before I respond to more emails on this topic off-forum, I have now uploaded the various variants (some have been suggested by others) to implement the compiler’s import handler to: https://github.com/andreaspirklbauer/Oberon-module-imports Variant1 (ORB1.Mod): - "conflict with re-import" if a module M is first re-imported, and then M is used as an alias - "conflict with alias" if M is first used as an alias name, and then module M is re-imported - "invalid import order" if a module M is first re-imported and then explicitly imported Variant 2 (ORB2.Mod): - hidden re-imports can peacefully coexist with aliases - "invalid import order" if a module M is first re-imported and then explicitly imported Variant (ORB3.Mod): - no more restrictions at all, i.e. can import modules in *any* order. * * * All of these variants differ only by a few lines of code (i.e. zero cost, and there is no need for module anchors or GModtab's, etc as in Griesermer’s approach). It’s now a matter of taste which variant to pick. Personally I’m currently (but that may change) leaning towards variant ORB2, i.e. I intentionally leave the “invalid import order” restriction in the compiler. Why? Because I view it is a desirable property if the compiler, if it encourages the programmer to write the import list of a module in the “right” order, i.e. reflecting the module hierarchy.. fully knowing that enforcing the rule that explicit imports must always become before re-imports may in some (rare?) cases force the programmer of a client module to change the import order, if the programmer of an imported module changes *its* import list. I understand that some people feel more strongly about this restriction and absolutely want to be able to write the module list in the IMPORT statement in *any* order -> well, they can now just pick variant ORB3.Mod if they want. -ap

3 2

PO 2013 allows one to "override" predefined procedures and functions
by Andreas Pirklbauer 15 May '21

15 May '21

Thanks, Josef, I can now see how such a “feature” might actually be useful (although I’ve never used it nor did I know it has apparently existed all along since Pascal days). So I resist the temptation.. -Andreas > Standard procedures in Oberon live in the outmost (global) scope on purpose > and the reason is extensibility. It makes it possible to add new procedures > later without invalidating any existing programs. This is so in all Pascal > style languages and their successors. It is very cheap to implement in the > compiler and fits well with the nesting of scopes. Overriding such > procedures locally is thereby possible but used mainly when a new procedure> > happens to be added in a new language version or dialect and an object with > the same name already exists in a program. The locally defined name then > shadows the same name in the global scope and the program compiles and runs > as before. > > I would not recommend to remove this feature. > > - Josef

1 0

PO 2013 allows one to "override" predefined procedures and functions
by Josef Templ 15 May '21

15 May '21

Standard procedures in Oberon live in the outmost (global) scope on purpose and the reason is extensibility. It makes it possible to add new procedures later without invalidating any existing programs. This is so in all Pascal style languages and their successors. It is very cheap to implement in the compiler and fits well with the nesting of scopes. Overriding such procedures locally is thereby possible but used mainly when a new procedure happens to be added in a new language version or dialect and an object with the same name already exists in a program. The locally defined name then shadows the same name in the global scope and the program compiles and runs as before. I would not recommend to remove this feature. - Josef <oberon-request(a)lists.inf.ethz.ch> schrieb am Sa., 15. Mai 2021, 12:00: > Send Oberon mailing list submissions to > oberon(a)lists.inf.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.inf.ethz.ch/mailman/listinfo/oberon > or, via email, send a message with subject or body 'help' to > oberon-request(a)lists.inf.ethz.ch > > You can reach the person managing the list at > oberon-owner(a)lists.inf.ethz.ch > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Oberon digest..." > > > Today's Topics: > > 1. PO 2013 allows one to "override" predefined procedures and > functions (Andreas Pirklbauer) > 2. Re: [EXT] PO 2013 allows one to "override" predefined > procedures and functions (Skulski, Wojciech) > 3. PO 2013 allows one to "override" predefined procedures and > functions (Andreas Pirklbauer) > 4. Re: PO 2013 allows one to "override" predefined procedures > and functions (Diego Sardina) > 5. Re: PO 2013 allows one to "override" predefined procedures > and functions (J?rg) > 6. RiskOne ordered (Skulski, Wojciech) > 7. Re: RiskOne ordered (peter(a)easthope.ca) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 May 2021 15:29:21 +0200 > From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> > To: Oberon List <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > Message-ID: <7012460B-DB79-4945-BA61-8FD9CF5603E3(a)yahoo.com> > Content-Type: text/plain; charset=utf-8 > > Has anyone noticed that the PO 2013 allows the programmer > to ?overrride? predefined procedures and functions, e.g., > > MODULE M; > VAR > INC: CHAR; > i: INTEGER; > BEGIN > INC := "a?; > INC(i) (*not a procedure*) > END M. > > This should not be allowed.. > > > > > ------------------------------ > > Message: 2 > Date: Fri, 14 May 2021 14:00:35 +0000 > From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] [EXT] PO 2013 allows one to "override" > predefined procedures and functions > Message-ID: > < > SN6PR07MB41575CDB194A6063310CA849FF509(a)SN6PR07MB4157.namprd07.prod.outlook.com > > > > Content-Type: text/plain; charset="Windows-1252" > > Andreas: > > what a great feature. It could be really useful in the hands of a creative > programmer. I am wondering, what would be the run time behavior of this > feature. A crash? > > How did you find this feature? Would be good to get rid of it. > > Wojtek > ________________________________________ > From: Oberon [oberon-bounces(a)lists.inf.ethz.ch] on behalf of Andreas > Pirklbauer [andreas_pirklbauer(a)yahoo.com] > Sent: Friday, May 14, 2021 9:29 AM > To: Oberon List > Subject: [EXT] [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > > Has anyone noticed that the PO 2013 allows the programmer > to ?overrride? predefined procedures and functions, e.g., > > MODULE M; > VAR > INC: CHAR; > i: INTEGER; > BEGIN > INC := "a?; > INC(i) (*not a procedure*) > END M. > > This should not be allowed.. > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mail… > > > ------------------------------ > > Message: 3 > Date: Fri, 14 May 2021 16:19:46 +0200 > From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> > To: Oberon List <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > Message-ID: <B0FC842A-6CDA-40F8-A607-3A529EFFC203(a)yahoo.com> > Content-Type: text/plain; charset=utf-8 > > Wojtek, > > The run time behaviour of this ?feature? is to simply override the > predefined identifier, which then is > no longer available in the current scope. So no crash. One can even > override things like INTEGER, etc. > > Actually, the compiler itself does some overriding in this way, namely > with the three procedures > ORG.ADC, ORG.SBC, ORB.UML. Inside these three procedures the corresponding > predefined > identifier (ADC, SBC or UML) is of course not available. > > To disallow this kind of ?overrriding? in the compiler, one could for > example: > > 1. Rename ORG.ADC, ORG.SBC, ORB.UML to ORG.Adc, ORG.Sbc, ORB.Uml > > 2. Adapt ORP.StandFunc accordingly to use the new procedure names > > 3. Adapt ORB.NewObj such that it now also checks the predefined > identifiers as follows: > > x := universe; > WHILE (x # NIL) & (x.name # id) DO x := x.next END ; > IF x = NIL THEN (*...ok...*) ELSE ORS.Mark("predefined identifier?) END > > to arrive at something along the lines of: > > PROCEDURE NewObj*(VAR obj: Object; id: ORS.Ident; class: INTEGER); > (*insert new Object with name id*) > VAR new, x: Object; > BEGIN x := universe.next; > WHILE (x # NIL) & (x.name # id) DO x := x.next END ; > IF x = NIL THEN x := topScope; > WHILE (x.next # NIL) & (x.next.name # id) DO x := x.next END ; > IF x.next = NIL THEN > NEW(new); new.name := id; new.class := class; new.next := NIL; > new.rdo := FALSE; new.dsc := NIL; > x.next := new; obj := new > ELSE obj := x.next; ORS.Mark("mult def") > END > ELSE ORS.Mark("predefined identifier") > END > END NewObj; > > PS: When doing this, the impact on the compiler?s performance is about > 5-10%. > > -ap > > > > Andreas: > > > > what a great feature. It could be really useful in the hands of a > creative programmer. I am wondering, what would be the run time behavior of > this feature. A crash? > > > > How did you find this feature? Would be good to get rid of it. > > > > Wojtek > ________________________________________ > From: Oberon [ > oberon-bounces at lists.inf.ethz.ch] on behalf of Andreas Pirklbauer > [andreas_pirklbauer at yahoo.com > ] > Sent: Friday, May 14, 2021 9:29 AM > To: Oberon List > Subject: [EXT] [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > > Has anyone noticed that the PO 2013 allows the programmer > to ?overrride? predefined procedures and functions, e.g., > > MODULE M; > VAR > INC: CHAR; > i: INTEGER; > BEGIN > INC := "a?; > INC(i) (*not a procedure*) > END M. > > This should not be allowed.. > > ------------------------------ > > Message: 4 > Date: Fri, 14 May 2021 16:14:16 +0200 > From: "Diego Sardina" <dsar(a)eml.cc> > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > Message-ID: <abd70680-9ba8-4a38-9e4e-ba426b8757e3(a)www.fastmail.com> > Content-Type: text/plain;charset=utf-8 > > On Fri, May 14, 2021, at 3:29 PM, Andreas Pirklbauer wrote: > > Has anyone noticed that the PO 2013 allows the programmer > > to ?overrride? predefined procedures and functions, e.g., > > > > MODULE M; > > VAR > > INC: CHAR; > > i: INTEGER; > > BEGIN > > INC := "a?; > > INC(i) (*not a procedure*) > > END M. > > > > This should not be allowed.. > > > > For what I remember in Oberon every predefined identifier can be > overridden since always. > > This is the reason TRUE and FALSE were promoted to keyword in Oberon-07, > to avoid CONST TRUE = FALSE. > > But I agree that this shouldn't be allowed (and that promotion to keyword > is debatable). > > -- > Diego Sardina > > > ------------------------------ > > Message: 5 > Date: Fri, 14 May 2021 16:25:11 +0200 > From: J?rg <joerg.straube(a)iaeth.ch> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > Message-ID: <175B9254-7AF3-48FE-AE31-BB0C41459FB6(a)iaeth.ch> > Content-Type: text/plain; charset=utf-8 > > > > Gruss, J?rg > > > Am 14.05.2021 um 16:23 schrieb Diego Sardina <dsar(a)eml.cc>: > > > > ?On Fri, May 14, 2021, at 3:29 PM, Andreas Pirklbauer wrote: > >> Has anyone noticed that the PO 2013 allows the programmer > >> to ?overrride? predefined procedures and functions, e.g., > >> > >> MODULE M; > >> VAR > >> INC: CHAR; > >> i: INTEGER; > >> BEGIN > >> INC := "a?; > >> INC(i) (*not a procedure*) > >> END M. > >> > >> This should not be allowed.. > >> > > > > For what I remember in Oberon every predefined identifier can be > overridden since always. > > > > This is the reason TRUE and FALSE were promoted to keyword in Oberon-07, > to avoid CONST TRUE = FALSE. > > > > But I agree that this shouldn't be allowed (and that promotion to > keyword is debatable). > > > > -- > > Diego Sardina > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > ------------------------------ > > Message: 6 > Date: Fri, 14 May 2021 15:28:14 +0000 > From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] RiskOne ordered > Message-ID: > < > SN6PR07MB4157574B3A984FAADF19B383FF509(a)SN6PR07MB4157.namprd07.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > All: > > I ordered production of two prototype RiskOne motherboards. If anyone > want to have those, it is the last minute to tell me so I can possibly add > more boards to the order. You need to do it today. The cost will be $500 > per board. > > The features: > Spartan-6 LX25, > 4 MB of ZBT RAM, > 16 MB HyperRAM (so it is 20 MB total). I intend to use HyperRAM for video, > but it can be used for anything else. > HDMI connector to output video > PS2 mouse and keyboard > W5500 chip for Ethernet with the RJ-45 socket. > Three serial ports. One of these can be optionally operated as "optical > interface" at 50 MHz. > Connector for the Nordic NRF24L01 radio, same as PO 2013. > Connector for Wi-Fi Sparkfun WRL-13678. > Two SD cards. One micro, one full. This is to adopt Chris file system > HCFiler with one of these. > Three PMOD connectors. > One set of expansion connectors for the daughter card "shield". > -- I already designed the ADC shield, which is my primary interest. > -- The shield can be anything: ADC, DAC, industrial PID control, > anything. > > I would have attached the full spec sheet, but this will hold off the > posting for approval. > > > > ------------------------------ > > Message: 7 > Date: Fri, 14 May 2021 10:17:11 -0700 > From: peter(a)easthope.ca > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] RiskOne ordered > Message-ID: <E1lhbR1-0001Dh-8B(a)joule.invalid> > > Hi Wojciech, > > > I ordered production of two prototype RiskOne motherboards. If > > anyone want to have those, it is the last minute to tell me so I can > > possibly add more boards to the order. You need to do it today. The > > cost will be $500 per board. > > Good news. I thought of asking about progress but better to refrain > from bothering you. > > Please order one at my expense. No rush to receive it. As described > earlier, it's an investment. Can convert 500 US to Canadian dollars > and mail a paper cheque to your campus address. Is Interac used > there? Might be Canada only. World Remit is international and I use > it routinely. If you prefer another means of payment, just let me > know. > > Thanks! ... P. > > -- > tel: +1 604 670 0140 Bcc: peter at easthope. ca > > > > ------------------------------ > > Subject: Digest Footer > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > ------------------------------ > > End of Oberon Digest, Vol 204, Issue 11 > *************************************** >

2 1