- Oberon - mailman3.inf.ethz.ch

Re (2): Servers for old ETH Oberon ports.
by peter＠easthope.ca 21 Sep '23

21 Sep '23

P.s. > ... hardware to run it on) :-) At least one. https://www.computerhistory.org/collections/catalog/102711028 Some of the machines there are demonstrated working. They might be interested in the software you have. ... P. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Re (2): Servers for old ETH Oberon ports.
by peter＠easthope.ca 21 Sep '23

21 Sep '23

From: Andreas Signer <asigner(a)gmail.com> Date: Thu, 21 Sep 2023 18:37:58 +0200 > I guess this would be good time now to upload it to github, ... Good! Please feel free to edit the wiki page or send the link. > ... still has the hardware to run it on Might be one at https://www.computerhistory.org . Thx, ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Re: [Oberon] Servers for old ETH Oberon ports.
by Andreas Signer 21 Sep '23

21 Sep '23

On Thu, Sep 21, 2023 at 5:31 PM <peter(a)easthope.ca> wrote: > Hi, > > In https://en.wikibooks.org/wiki/Oberon/ETH_Oberon/download > many of the links were dead. > > Under heading "Oberon ports no longer updated" Native now refers to > Sourceforge and Github. > > Windows [95NT] now refers to Github. > > What about the other ports? The thesis of Bernard Egger is at > > https://csap.snu.ac.kr/sites/default/files/papers/2001.Egger.Development%20… > Is an installation archive available? > <shameless plug> I don't know about Berhard's Aos implementation for DNARD, but the "original" SharkOberon (a port of System 3 for DNARD) still sits on my hard disk :-) I guess this would be good time now to upload it to github, just in case anybody is still interested (and still has the hardware to run it on) :-) </shameless plug> > Windows 3.x? > > MacOS? > > HP-UX? > > Thanks, ... P.L. > > - > mobile: +1 778 951 5147 > VoIP: +1 604 670 0140 > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon >

1 0

Servers for old ETH Oberon ports.
by peter＠easthope.ca 21 Sep '23

21 Sep '23

Hi, In https://en.wikibooks.org/wiki/Oberon/ETH_Oberon/download many of the links were dead. Under heading "Oberon ports no longer updated" Native now refers to Sourceforge and Github. Windows [95NT] now refers to Github. What about the other ports? The thesis of Bernard Egger is at https://csap.snu.ac.kr/sites/default/files/papers/2001.Egger.Development%20… Is an installation archive available? Windows 3.x? MacOS? HP-UX? Thanks, ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Activate Midle Mouse button for Oberon on Windows 10
by Dieter 09 Sep '23

09 Sep '23

Hi there, I am one of the few fossils still working with *ETH PlugIn Oberon for WindowsTM / Win32 2.5 (18.12.2010) ** ** on Windows 2008 Version 6.1.7600 Glötzel@GLÖTZEL-PC * *Logitech Mouse MS560* I can no longer use the middle mouse key. I did have it running properly some time ago, but meanwhile I forgot the clue. Thanks, Dieter

2 3

Re: [Oberon] Names in Unix.Oberon.NetSystem.Mod
by peter＠easthope.ca 02 Sep '23

02 Sep '23

From: Joerg <joerg.straube(a)iaeth.ch> Date: Sat, 26 Aug 2023 18:46:04 +0200 > As you store the host and the service as well, I would call the > bundle of these 4 strings „ServiceLogin“ or „ServiceAccess“ > or something along these lines. From: peter(a)easthope.ca Date: 28 Aug 2023 07:52:52 -0700 > English has no specific name for the four-tuple. I found this. https://en.wiktionary.org/wiki/Thesaurus:quartet and think of "accessQuartet" and "accessTetrad". Also, https://de.wiktionary.org/wiki/Tetrade accessTetrad? accessTetrade? Any further comments? Thanks, ... P. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Non-matching expressions in case statements
by Andreas Pirklbauer 31 Aug '23

31 Aug '23

> My interpretation is that the presence of the phrase *case label list* indicates > that the remainder of the sentence only applies to numeric case statements. > > The syntax for type case statements is a substantially reduced form of the > syntax for numeric case statements: > > TypeCaseStatement = CASE qualident OF case {"|" case} END. > case = [qualident ":" StatementSequence]. > > NumericCaseStatement = CASE expression OF case {"|" case} END. > case = [CaseLabelList ":" StatementSequence]. > CaseLabelList = LabelRange {"," LabelRange}. > LabelRange = label [".." label]. > label = integer | string | qualident. I agree. And this is not the only difference between the two forms of the case statement. For example: Although the semantics of what happens at run time, when the value (or type) of the case expression (or case variable) does not correspond to any case label (or case label type) in the source text is NOT defined in the Oberon language, an actual compiler implementation may choose two different approaches, e.g., a. For the numeric case statement: the program is aborted b. For the type case statement: no action is taken (e.g., to enable the "fall-through” mechanism in OO settings)

1 0

Non-matching expressions in case statements
by August Karlstrom 31 Aug '23

31 Aug '23

1) For case statements with integer labels, which often represent an enumerated type, it's *desirable* to trap non-matching case expressions as it may indicate a forgotten case label. 2) When using case statements with type labels, the programmer typically relies on non-matching case expressions being ignored; for message records the message "fall through", as described in "Programming in Oberon", p. 61. Here it's *essential* that the implementation does not halt the program with a trap, otherwise this technique will not work. The language report says: "First the case expression is evaluated, then the statement sequence is executed whose case label list contains the obtained value." As I interpret the sentence above, the expression is supposed to match exactly one label, however that is not the case with "fall through" messages. I think it needs to be clarified in the language report that "fall through" is well-defined for case statements with type labels. Any comments? https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf https://miasap.se/obnc/oberon-report.html#sec6.3 Regards, August

2 1

Case statements containing base type labels
by August Karlstrom 30 Aug '23

30 Aug '23

Given the declarations Shape = RECORD x, y: REAL END Rectangle = RECORD (Shape) w, h: REAL END Circle = RECORD (Shape) r: REAL END does a case statement containing labels for all three types have well defined behavior? CASE s OF Rectangle: ... | Circle: ... | Shape: ... END In this case a rectangle and a circle respectively is also a shape so it's not clear what label is selected and the order of the labels should not matter. Regards, August

6 12

Re: [Oberon] Oberon Digest, Vol 231, Issue 7
by dirk muysers 29 Aug '23

29 Aug '23

I prefer the very clear solution to this problem in Modula-3: CASE is for ordinal types TYPECASE for REF types WITH to open inner scopes I really miss them in OBERON (What I miss in M3 is selectively hiding RECORD fields 😊) Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: oberon-request(a)lists.inf.ethz.ch<mailto:oberon-request@lists.inf.ethz.ch> Sent: mardi 29 août 2023 12:00 To: oberon(a)lists.inf.ethz.ch<mailto:oberon@lists.inf.ethz.ch> Subject: Oberon Digest, Vol 231, Issue 7 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. Re: Case statements containing base type labels (August Karlstrom) 2. Re: Case statements containing base type labels (chris) 3. Re: Case statements containing base type labels (Joerg) 4. Re: Case statements containing base type labels (joerg.straube(a)iaeth.ch) 5. Case statements containing base type labels (Andreas Pirklbauer) ---------------------------------------------------------------------- Message: 1 Date: Mon, 28 Aug 2023 19:27:44 +0200 From: August Karlstrom <fusionfile(a)gmail.com> To: oberon(a)lists.inf.ethz.ch Subject: Re: [Oberon] Case statements containing base type labels Message-ID: <4df8fce8-2156-e403-21e5-b0a4a58a4c07(a)gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 2023-08-28 15:20, Chris Burrows wrote: > Refer to the pair of examples on P 61 of Programming in Oberon, 2014: > > https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf > <https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf> The examples you refer to in "Programming in Oberon" are in the context of message records and all labels are (proper) direct extensions of the base type Message so there is no ambiguity in this case; the labels can be arranged in any order without affecting the behavior of the case statement (as it should be). My current conclusion is that a case statement where one type label is an extension of another is not well-defined. I think an ambitious compiler could even reject such a statement, similar to how repeated case labels can be handled. /August ------------------------------ Message: 2 Date: Mon, 28 Aug 2023 20:51:20 +0200 From: chris <chris(a)gcjd.org> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Case statements containing base type labels Message-ID: <20230828205120917858.5a21830c(a)gcjd.org> Content-Type: text/plain; charset=iso-8859-1 On Mon, 28 Aug 2023 19:27:44 +0200, August Karlstrom wrote: > My current conclusion is that a case statement where one type label > is an extension of another is not well-defined. I agree. IMHO it was a bad idea to mix the WITH statement and the CASE statement at all. The WITH statement was defined by IF/ELSIF so no problem here: For example in "Object-Oriented Programming in Oberon-2" (M?ssenb?ck 1993) Appendix A: "WITH v: T1 DO S1 | v: T2 DO S2 ELSE S3 END has the following meaning: if the dynamic type of v is T1, then the statement sequence S1 is executed, where v is regarded as if it had the static type T1; else if the dynamic type of v is T2, then S2 is executed, where v is regarded as if it had the static type T2; else S3 is executed. T1 and T2 must be extensions of T0." As explained by Wirth in "Differences between Revised Oberon and Oberon" (Wirth 2011) "The case statement performs the same function as the if statement. However, it is intended to use a different technique of implementation, namely a single, indexed branch instead of a cascade of conditional branches." The 2011 version of Oberon-07 only allows INTEGER and CHAR for CASE statements. Mixing with type tests makes no sense as they will most likely be implemented as several IF - ELSIF statements. > I think an ambitious > compiler could even reject such a statement, similar to how repeated > case labels can be handled. I think it should reject such code as the case labels are not distinct from each other. Otherwise the semantics of the CASE statement would change for this case from the original intention and the other variant with INTEGER/CHAR labels which must be distinct. Greetings, chris ------------------------------ Message: 3 Date: Mon, 28 Aug 2023 23:09:21 +0200 From: Joerg <joerg.straube(a)iaeth.ch> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Case statements containing base type labels Message-ID: <D085B260-A1DE-4947-A9D5-A34F625B5937(a)iaeth.ch> Content-Type: text/plain; charset=utf-8 ?August When I saw your code, this was basically my first reaction why I said the CASE label ?Shape? is not allowed as it is no extension. Then came Diego and said ?Shape? is an extension of itself. He is right as the report explicitely states it. Because I never thought of types with different extension levels, I thought: the missing ELSE could be handled elegantly with this ?trick? Personally, I find the CASE construct seen as a combination of IF-ELSE with implicit WITHs a nice ?syntactic sugar?. But I have to agree with Chris, that it?s not obvious that then the order of CASE labels is important! To define the clear semantic I propse 4 options: 1) state that all extension have to be on the same level aka must have the same ?depth? ?> Shape generates an error. 2) state that the ?CASE with types? is a syntactic sugar for an IF-ELSE cascade with implicit WITHs. Basically, leaving the order to the programmer. ?Shape? as last CASE label is an elegant way for an ELSE. But having ?Shape? as first label, makes the labels ?Circle? and ?Rectangle? void. 3) as type extensions build a hierarchy state that in the ?CASE with types? the labes have to be sorted from specific to broader. If a label is a more specific than a previous one, generate an error. 4) state that the compiler sorts the labels from specific to broader. The hierarchy/order is guarateed by the compiler Looking at these 4 options, I would go for 1) or 3) br J?rg > Am 28.08.2023 um 19:28 schrieb August Karlstrom <fusionfile(a)gmail.com>: > ?On 2023-08-28 15:20, Chris Burrows wrote: >> Refer to the pair of examples on P 61 of Programming in Oberon, 2014: >> https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf <https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf> > > The examples you refer to in "Programming in Oberon" are in the context of message records and all labels are (proper) direct extensions of the base type Message so there is no ambiguity in this case; the labels can be arranged in any order without affecting the behavior of the case statement (as it should be). > > My current conclusion is that a case statement where one type label is an extension of another is not well-defined. I think an ambitious compiler could even reject such a statement, similar to how repeated case labels can be handled. > > > /August > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon ------------------------------ Message: 4 Date: Tue, 29 Aug 2023 07:11:59 +0000 From: "joerg.straube(a)iaeth.ch" <joerg.straube(a)iaeth.ch> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Case statements containing base type labels Message-ID: <PAWP194MB210299BFCD1EDA11B5CE9EE2AEE7A(a)PAWP194MB2102.EURP194.PROD.OUTLOOK.COM> Content-Type: text/plain; charset="utf-8" Hi In the meantime, I implemented 3) The type extensions in a CASE are only allowed to get broader and broader. In other words: the extension depth is only allowed to get smaller. I made the following changes to ORP.Mod. Parameter ?depth? added to PROCEDURE IsExtension(t0, t1: ORB.Type; VAR depth: INTEGER): BOOLEAN; BEGIN (* t1 is an extension of t0 *) INC(depth); RETURN (t0 = t1) OR (t1 = NIL) & IsExtension(t0, t1.base, depth) END IsExtension; Parameter ?depth? added to PROCEDURE TypeTest(VAR x: ORG.Item; T: ORB.Type; guard: BOOLEAN; VAR depth: INTEGER); Hierarchy logic added to PROCEDURE TypeCase(obj: ORB.Object; VAR x: ORG.Item; VAR prvDepth: INTEGER); VAR depth: INTEGER; BEGIN ? depth := 0; TypeTest(x, typobj.type, FALSE, depth); obj.type := typobj.type; IF depth > prvDepth THEN ORS.Mark(?type more specific than previous?) END; prvDepth := depth ? END TypeCase; and finally in StatSequence: start with an ?infinite? depth (I took 9999) and propagate depth from label to label ELSIF sym = ORS.case ?. IF (orgtype.form = ORB.Pointer) OR (orgtype.form = ORB.Record) & (obj.class = ORB.Par) THEN Check(ORS.of); depth := 9999; TypeCase(obj, x, depth); L0 := 0 WHILE sym = ORS.bar DO ORS.Get(sym); ORG.FJump(L0); ORG.Fixup(x); obj.type := orgtype; TypeCase(obj, x, depth) END ? END J?rg Von: Oberon <oberon-bounces(a)lists.inf.ethz.ch> im Auftrag von Joerg <joerg.straube(a)iaeth.ch> Datum: Montag, 28. August 2023 um 23:10 An: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Betreff: Re: [Oberon] Case statements containing base type labels August When I saw your code, this was basically my first reaction why I said the CASE label ?Shape? is not allowed as it is no extension. Then came Diego and said ?Shape? is an extension of itself. He is right as the report explicitely states it. Because I never thought of types with different extension levels, I thought: the missing ELSE could be handled elegantly with this ?trick? Personally, I find the CASE construct seen as a combination of IF-ELSE with implicit WITHs a nice ?syntactic sugar?. But I have to agree with Chris, that it?s not obvious that then the order of CASE labels is important! To define the clear semantic I propse 4 options: 1) state that all extension have to be on the same level aka must have the same ?depth? ?> Shape generates an error. 2) state that the ?CASE with types? is a syntactic sugar for an IF-ELSE cascade with implicit WITHs. Basically, leaving the order to the programmer. ?Shape? as last CASE label is an elegant way for an ELSE. But having ?Shape? as first label, makes the labels ?Circle? and ?Rectangle? void. 3) as type extensions build a hierarchy state that in the ?CASE with types? the labes have to be sorted from specific to broader. If a label is a more specific than a previous one, generate an error. 4) state that the compiler sorts the labels from specific to broader. The hierarchy/order is guarateed by the compiler Looking at these 4 options, I would go for 1) or 3) br J?rg > Am 28.08.2023 um 19:28 schrieb August Karlstrom <fusionfile(a)gmail.com>: > ?On 2023-08-28 15:20, Chris Burrows wrote: >> Refer to the pair of examples on P 61 of Programming in Oberon, 2014: >> https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf <https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf> > > The examples you refer to in "Programming in Oberon" are in the context of message records and all labels are (proper) direct extensions of the base type Message so there is no ambiguity in this case; the labels can be arranged in any order without affecting the behavior of the case statement (as it should be). > > My current conclusion is that a case statement where one type label is an extension of another is not well-defined. I think an ambitious compiler could even reject such a statement, similar to how repeated case labels can be handled. > > > /August > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20230829/f49ad4cd/att…> ------------------------------ Message: 5 Date: Tue, 29 Aug 2023 09:43:03 +0200 From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> To: Oberon List <oberon(a)lists.inf.ethz.ch> Cc: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> Subject: [Oberon] Case statements containing base type labels Message-ID: <B619D6F9-161E-4A2D-852F-275A75F603AF(a)yahoo.com> Content-Type: text/plain; charset=utf-8 Isn?t the problem that the evaluation order of the Oberon ?type" case statement (CASE p OF basetype .. | extendedtype.. | .. END) is not well defined. This inevitably means that different compilers will (necessarily) end up implementing different semantics.. which is bad. In my view: a) The type case statement should never have been merged with the ?numerical? case statement - not because it makes the parser a little bit easier, but mainly because they are in fact separate statements. b) The evaluation order of labels should be defined in the language - the order doesn?t necessarily have to be declaration order, it could for example also be defined by the type hierarchy itself (e.g. highest extension level first). ------------------------------ 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 231, Issue 7 **************************************

1 0