August 2022 - Oberon - mailman3.inf.ethz.ch

Re (2): Licensing of images in the wikibook.
by peter＠easthope.ca 24 Aug '22

24 Aug '22

Florian & all, Thanks for the discussion. For me, this copyright business has subtle concepts and I stray into faulty thinking too easily. From: Florian Negele <negelef(a)openbrace.org> Date: Wed, 24 Aug 2022 19:39:44 +0200 > Regarding your configuration strings example, I am wondering why the > ETH Oberon license is relevant at all here. IMHO since you made the > screenshot, you are the sole copyright holder. The text is from source developed at ETH. So ETH copyright is on the text. Being only 23 lines, maybe acknowledgement without quoting the license is enough in most contexts. But Wikimedia requires stating a license for each image. Seems unfair to state only the CCbySA license and not the ETH license. Therefore I put both. > Otherwise you would have to include the license of Qemu just as > well. Only the tiny QEMU icon in the upper left corner and the "QEMU" title are specific to QEMU. Use of the name QEMU probably isn't a copyright violation here. I might have to acknowledge display of the icon. Can investigate that. Thx, ... P.L. mobile: +1 778 951 5147 VoIP: +1 604 670 0140 https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Licensing of images in the wikibook.
by peter＠easthope.ca 24 Aug '22

24 Aug '22

Hi, A gallery of images used in the wikibook is here. https://commons.wikimedia.org/wiki/Category:Oberon_(operating_system) Each image has an accompanying licensing section. A partial list of license tags allowed by Wikimedia is here. https://commons.wikimedia.org/wiki/Commons:Copyright_tags/Free_Creative_Com… This is the page for one image. https://commons.wikimedia.org/wiki/File:OberonBootLoaderConfigStrings.png In my thinking, three components in the page are critical to licensing. (1) The ETH license on the green background. (2) The Wikimedia license. In this case "Creative Commons Attribution-Share Alike 4.0 International". (3) The evaluation by Seraphimblade of compatibility of (1) to (2). "evaluation" is a link. In my current thinking the page addresses ETH requirements and Wikimedia requirements. Comments? Complaints? If the page is OK, I'll revise some of the other image pages similarly. Thanks! ... P.L. mobile: +1 778 951 5147 VoIP: +1 604 670 0140 https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Re (4): Duplicate headers in SMTP.
by peter＠easthope.ca 10 Aug '22

10 Aug '22

From: Michael Schierl <schierlm(a)gmx.de> Date: Fri, 22 Jul 2022 23:54:41 +0200 > "To:" may only appear once. Ug! Used email for more than three decades without recognizing that https://datatracker.ietf.org/doc/html/rfc5322#section-3.6 allows no more than one of each of to, cc and bcc fields. =8~/ From: Paul Reed <paulreed(a)paddedcell.com> Date: Fri, 22 Jul 2022 22:57:20 +0100 > "Oh, it's worse than that, Jim!" :) Star Trek? Yes, definitely worse. =8~( Certainly Oberon mail output should respect IETF. From: Michael Schierl <schierlm(a)gmx.de> > Try: > > To: <......(a)gmail.com>, <s....(a)shaw.ca> Here Mail is compiled with simpler = TRUE. <> are omitted. For input, I'd rather Oberon accept To: a@m To: b@n and Bcc: c@p Bcc: d@q than require To: a@m, b@n and Bcc: c@p, d@q . The former is better to read. In the Oberon interface, better to assemble. Also the IETF limits and recommends line lengths. https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1 In fact Bcc: c@p Bcc: d@q Bcc: e@r ... rarely fails. I've used lists of forty or more addresses without a failure. It's To: a@m To: b@n which snags. From: Paul Reed <paulreed(a)paddedcell.com> > The code ... will need a good coat of looking at, to reduce the > number of "TO:" headers to one. :( Another project ... but admire the progress of ETH Oberon over a decade ago. Regards, ... P.L.

7 17

Constant folding, Re: Bit-fiddling: SETs and type c
by Andreas Pirklbauer 09 Aug '22

09 Aug '22

CORRECTION: And of course, one also needs to reverse the sign inside the new brackets ( “-" instead of “+" ) PROCEDURE P; VAR ch: CHAR; BEGIN ch := CHR(ORD(ch) - (ORD("a") - ORD("A”))) END P; 2 90E00004 LDR R0 SP 4 3 40090020 SUB R0 R0 32 # ORD(“a) - ORD(“A”) = 97 - 65 = 32 --> constants folded 4 B0E00004 STR R0 SP 4

1 0

Constant folding, Re: Bit-fiddling: SETs and type casts in Oberon-07
by Andreas Pirklbauer 09 Aug '22

09 Aug '22

If you put extra brackets around the last two calls to ORD, as in: PROCEDURE P; VAR ch: CHAR; BEGIN ch := CHR(ORD(ch) - (ORD("a") + ORD("A”))) END P; then the official Oberon-07 compiler does actually fold the constants: 2 90E00004 LDR R0 SP 4 3 40090020 SUB R0 R0 32 # ORD(“a) - ORD(“A”) = 97 - 65 = 32 --> constants folded 4 B0E00004 STR R0 SP 4

1 0