- Oberon - mailman3.inf.ethz.ch

Case statements containing base type labels
by Andreas Pirklbauer 29 Aug '23

29 Aug '23

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).

1 0

Re: [Oberon] Case statements containing base type labels
by Joerg 29 Aug '23

29 Aug '23

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

2 1

Re (2): Names in Unix.Oberon.NetSystem.Mod
by peter＠easthope.ca 28 Aug '23

28 Aug '23

From: Joerg <joerg.straube(a)iaeth.ch> Date: Sat, 26 Aug 2023 18:46:04 +0200 > Principally, as neither Password nor PasswordDesc is exported, it‘s > a pure implementation decision how you want to call this > module-internal type. Acknowledged. I don't claim to be a professional programmer but things I write tend to be understandable, to me at least, within a year of writing. As years pass, understanding the reasoning behind code withers. =8~/ For code written by another, I don't have the original reasoning except where it was documented. The "understanding problem" is magnified. The difficulty is mitigated by correct use of natural language. The situation is illustrated by the parallel discussion of the CASE statement. The expert can assert, "I named the variable 'mammal' because it refers to a mammal." For the compiler, the variable might equally well be "whale" or "mammal" or "animal". For the human reader, the choice can be significant but subtle. > Personally, I would only call the set („user“, „password“) „ > Credential“. 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. Thanks. English has no specific name for the four-tuple. I can imagine "authenticationFourTuple" but you might find that laughable. With contemporary hardware, the length of the name is probably not objectionable. > But feel free to call it „Credential“, if you like. I'll refrain. You caught a semantic error. Not sure about "authenticationFourTuple". Thanks for the helpful reply, ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

Re: [Oberon] Names in Unix.Oberon.NetSystem.Mod
by Joerg 26 Aug '23

26 Aug '23

Peter Principally, as neither Password nor PasswordDesc is exported, it‘s a pure implementation decision how you want to call this module-internal type. Personally, I would only call the set („user“, „password“) „Credential“. 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. But feel free to call it „Credential“, if you like. br Jörg > Am 26.08.2023 um 16:32 schrieb peter(a)easthope.ca: > > Hi, > > Unix.Oberon.NetSystem.Mod, > Password = POINTER TO PasswordDesc; > PasswordDesc = RECORD > service, user, host, passwd: ARRAY 64 OF CHAR; > next: Password > END; > > Reference, > https://en.wiktionary.org/wiki/credential#Noun 1. > https://en.wiktionary.org/wiki/password#Noun 2. > > My assertion: a password is one component of a credential. Therefore > this declaration represents the concepts better. > > Unix.Oberon.NetSystem.Mod, > Credential = POINTER TO CredentialDesc; > CredentialDesc = RECORD > service, user, host, passwd: ARRAY 64 OF CHAR; > next: Credential > END; > > Comments? Does anyone object to me making this change? > > 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

Names in Unix.Oberon.NetSystem.Mod
by peter＠easthope.ca 26 Aug '23

26 Aug '23

Hi, Unix.Oberon.NetSystem.Mod, Password = POINTER TO PasswordDesc; PasswordDesc = RECORD service, user, host, passwd: ARRAY 64 OF CHAR; next: Password END; Reference, https://en.wiktionary.org/wiki/credential#Noun 1. https://en.wiktionary.org/wiki/password#Noun 2. My assertion: a password is one component of a credential. Therefore this declaration represents the concepts better. Unix.Oberon.NetSystem.Mod, Credential = POINTER TO CredentialDesc; CredentialDesc = RECORD service, user, host, passwd: ARRAY 64 OF CHAR; next: Credential END; Comments? Does anyone object to me making this change? Thanks, ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

How to activate Middle Mouse CLick on Windows 10
by Dieter 15 Aug '23

15 Aug '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 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 -- ____________________________________ Dr. Dieter Glötzel Im Rosengarten 27 64367 Mühltal Tel.: 06151 / 360 82 72

1 0

Re: [Oberon] Re (2): A2 multi-desktop switching vs. Oberon subsystem.
by Michael Schierl 07 Aug '23

07 Aug '23

Hello, Am 07.08.2023 um 17:09 schrieb peter(a)easthope.ca: > Michael & all, > > From: Michael Schierl <schierlm(a)gmx.de> > Date: Mon, 31 Jul 2023 22:19:02 +0200 >> In latest gitlab version, you can either disable global hotkeys >> completely by pressing the F12 key, ... > > F12 left no * marker from Oberon F1 and Hotkeys.Show reported 0 hotkeys. Just in case it was unclear, first disable hotkeys by pressing F12 and then press F1 to add a * marker... >> ... or you can edit Hotkeys.xml ... > > Specifying the Oberon function key behaviour in Hotkeys.xml might be > appropriate. I haven't found how it is done. My Hotkeys.XML contains this:  <HotKey name="Desktop 1" keys="F1" command="WMOSD.Close;WMNavigate.SetViewportRange -d -1 -1 1 1;WMOSD.Open 'Desktop 1'"/> <HotKey name="Desktop 1 (WinAos)" keys="META+F1" command="WMOSD.Close;WMNavigate.SetViewportRange -d -1 -1 1 1;WMOSD.Open 'Desktop 1'"/> <HotKey name="Desktop 2" keys="F2" command="WMOSD.Close;WMNavigate.SetViewportRange -d 0 -1 1 1;WMOSD.Open 'Desktop 2'"/> <HotKey name="Desktop 3" keys="F3" command="WMOSD.Close;WMNavigate.SetViewportRange -d -1 0 1 1;WMOSD.Open 'Desktop 3'"/> <HotKey name="Desktop 4" keys="F4" command="WMOSD.Close;WMNavigate.SetViewportRange -d 0 0 1 1;WMOSD.Open 'Desktop 4'"/> <HotKey name="Desktops Overview" keys="F5" command="WMOSD.Close;WMNavigate.SetViewportRange -d -1 -1 2 2;WMOSD.Open 'Desktops Overview'"/> Commenting or removing the first HotKey makes F1 no longer switch to the first desktop. Meta+F1 still switches to the first desktop. > In Configuration.XML, commenting out "Hotkey support" gave Oberon > functionality. >  That's the sledgehammer method and works too, of course :) > Appears that Oberon function key behaviour is the initial default and > Hotkeys with empty Hotkeys.xml obliterates that. So my simple > solution is to disable Hotkeys and a more elaborate solution is to > define Oberon hotkeys. Hotkeys behave like this: If a pressed key is defined as a hotkey, the hotkey command is executed. If it is not (is it a coldkey then?), it is passed to the focused window (which is the Oberon window in your case) to be handled. So, not having F1 being defined as a hotkey is what you actually want for Oberon being able to create a * marker for you. Regards, Michael

1 0

Re (2): A2 multi-desktop switching vs. Oberon subsystem.
by peter＠easthope.ca 07 Aug '23

07 Aug '23

Michael & all, From: Michael Schierl <schierlm(a)gmx.de> Date: Mon, 31 Jul 2023 22:19:02 +0200 > In latest gitlab version, you can either disable global hotkeys > completely by pressing the F12 key, ... F12 left no * marker from Oberon F1 and Hotkeys.Show reported 0 hotkeys. > ... or you can edit Hotkeys.xml ... Specifying the Oberon function key behaviour in Hotkeys.xml might be appropriate. I haven't found how it is done. In Configuration.XML, commenting out "Hotkey support" gave Oberon functionality.  Appears that Oberon function key behaviour is the initial default and Hotkeys with empty Hotkeys.xml obliterates that. So my simple solution is to disable Hotkeys and a more elaborate solution is to define Oberon hotkeys. Thanks for the help, ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0

A2 multi-desktop switching vs. Oberon subsystem.
by peter＠easthope.ca 31 Jul '23

31 Jul '23

Hi, Jan de Kruyf jan.de.kruyf at gmail.com Mon Jul 17 19:29:29 CEST 2023 > The latest LinuxAos version from uni-Bremen runs fine on Debian Trixie > (testing) 64 bit. > DEll Latitude E7470. Thanks Jan. Here reinstalled Debian 11, AMD64 in a Lenovo ThinkCentre and installed LinuxA2-64bit, rev.9799. A2 and Oberon displays appear. Photo here shows A2, Desktop 2. http://easthope.ca/A2Gen.64rev.9799.jpg Was desktop switching added recently? Oberon function key usage has been supplanted. For example, F1 sets A2, Desktop 1 and the * marker can not be set in Oberon. Is Oberon function key usage available in rev.9799 or later? Otherwise the Oberon subsystem is effectively disabled. Thx, ... P.L.

2 1

Re: [Oberon] Re (2): New to Oberon
by Stuff Received 20 Jul '23

20 Jul '23

Greetings, Peter. On 2023-07-20 11:23, peter(a)easthope.ca wrote: > Hi, > >> S. > > Apology for not recognizing your identity. > >> In the interim, the ETHZ distribution does contain the loader code. > > Currently available from ETH? Yes, part of their Unix distribution (here https://ftp.gwdg.de/pub/languages/oberon/ftp.inf.ethz.ch/ETHOberon/Unix/spa… and other places). > If so, please send a link for the wikibook. Here: https://ftp.gwdg.de/pub/languages/oberon/ftp.inf.ethz.ch/ETHOberon/Unix/spa… (and probably other places). > > Thx, ... P.L. Sincerely, S > > - > mobile: +1 778 951 5147 > VoIP: +1 604 670 0140 >

1 0