- Oberon - mailman3.inf.ethz.ch

Attribution of graphics.
by peter＠easthope.ca 18 Jul '22

18 Jul '22

The arrow used in the Tutorial is here. https://commons.wikimedia.org/wiki/File:OberonMouse1.jpg Any suggestions to correct or improve attribution? Deutsch: Ubersetzung ins Deutsche? Thx, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0

Re (2): Re(2): RFC 5322 and ETH Oberon SMTP.
by peter＠easthope.ca 18 Jul '22

18 Jul '22

From: Paul Reed <paulreed(a)paddedcell.com> Date: Mon, 18 Jul 2022 11:02:05 +0100 > I can't see any validation of email addresses at all - maybe a > validation routine would be worth putting in and called for each email > address processed? You could put separate logging/debugging in that. > Sometimes text copied from various sources has hidden blank characters > - or might be UTF-8, for example... Noted, thanks. In a few weeks, when the tutorial images are finished, I can focus effort on Mail. > Looks like https://en.wikibooks.org/wiki/Oberon/A2/Oberon.Mail.Mod has a > trace BOOLEAN which if set will output to the system log. It's set by > > trace := NetTools.QueryBool("TraceMail"); > > in Mail.Send. But the tracing code is separate from the network write > statements, so it's not strictly a validation of the data sent (e.g., > line-endings). Wireshark might be better/easier. Will review that also. Thanks again, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0

Re(2): RFC 5322 and ETH Oberon SMTP.
by peter＠easthope.ca 18 Jul '22

18 Jul '22

From: Michael Schierl <schierlm(a)gmx.de> Date: Fri, 15 Jul 2022 19:22:23 +0200 > SMTP is RFC 5321. RFC 5322 is about the message format, which does not > depend on whether it is sent via SMTP, POP3, IMAP, etc. Missed that. Thanks. > I hope that Oberon's Mail implementation provides a feature to view > the headers and raw body of a sent email (Thunderbird does :D). Not in release 2.3.7 but output to a file can be added. For a received message the document has a source button. Send a test message to myself and "source" shows the header and body. > I will assume first that the emails do not have attachments, i.e. they > consist of one single text/plain or text/html body part. Consistent with the cases I noticed. To investigate the details you listed I need to add output recording. Thanks, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

2 1

Should hidden re-imports be able to coexist with identifiers
by Andreas Pirklbauer 17 Jul '22

17 Jul '22

Hi Luca, See my inline answers below: > Luca Boasso luke.boasso at gmail.com Sat Jul 16 20:22:54 CEST 2022 > > Hi Andreas, > > Thanks for giving that a try! > > Is this approach over all simpler than the one I am using in oberonc? It is hard for me to say since your solution evolved over time, but you should be able to give your take since you knew about the Griesemer's approach. Yes, my approach is considerably (!) simpler than oberonc and Griesemer’s approach.. in the sense that I found a way to do away with module anchors and global module tables completely. If on http://github.com/andreaspirklbauer/Oberon-module-imports you scroll down to section 6., the approach is briefly explained (I essentially propagate the reference number of each re-exported type through the module hierarchy and then use that number to detect whether a type has already been re-imported or not). > Do you have a comprehensive test suite I could try with oberonc to see if both compilers agree on the result? I have now added (essentially your) test suite here: https://github.com/andreaspirklbauer/Oberon-module-imports/tree/master/Sour… There is a file called TESTIMPORT.Tool which contains a single ORP.Compile command that compiles the test suite. All module compile correctly except for 3 cases, which I intentionally disallow (I don’t allow creating more than one alias per imported module or importing the same module twice, finally PO 2013 doesn’t allow external pointer base types - I restriction which I just inherited and didn’t want to touch). I could easily allow those cases as well, but then I would need to change the symbol table data structure in topScope. This seemed unnecessary. For further reading on the rationale used and a proof that indeed all possible cases are covered by it, see: https://github.com/andreaspirklbauer/Oberon-module-imports/blob/master/Docu… as well as the test file https://github.com/andreaspirklbauer/Oberon-module-imports/blob/master/Sour… You can just click through the various modules contained in this file. They really cover all possible cases. This is comforting to know. > Cheers, Luca Cheers, Andreas > > On Sat, Jul 16, 2022, 09:52 Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote: > > Luca Boasso luke.boasso at gmail.com Sun May 16 03:13:24 CEST 2021 > > > > I have two problems in forcing the programmer to think about import > ordering: > > > > 1. It does not scale. If you have big systems it is hard to hold in your > > head all the import relationships. It is better to have the compiler > figure > > it out for you and do the proper checks. > > > > 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. > > Luca, > > I now couldn’t resist and have actually implemented a variant > of ORB that removes the “invalid import order” restriction and > allows hidden re-imports to peacefully coexist with identifiers. > > It was surprisingly straight-forward to implement, only about > 15-20 lines of code. Details are here (variant 2): > > https://github.com/andreaspirklbauer/Oberon-module-imports > > The key idea is to simply propagate reference numbers of > re-exported types from the original module throughout the > module hierarchy (I just add to the information that is > already output for re-exported types). When later a > type T is imported explicitly, one only needs to check > that particular reference number had previously been > re-imported. And if so, the type is discarded after > having read it from the symbol file. > > PS: This would make a nice exercise for a compiler course. > Not much to code, but some thinking is required for sure. > > Andreas

2 1

Re (2): RFC 5322 and ETH Oberon SMTP.
by peter＠easthope.ca 16 Jul '22

16 Jul '22

From: Paul Reed <paulreed(a)paddedcell.com> Date: Fri, 15 Jul 2022 16:23:52 +0100 > Can you highlight the specific SMTP sending code you're running? https://en.wikibooks.org/wiki/Oberon/A2/Oberon.Mail.Mod The module in the SVN archive for A2 is in the left column. https://en.wikibooks.org/wiki/Oberon/A2#Module_Sources,_Tools_and_Configura… > Further to Joerg's comments, are you sure the From header is > *exactly* RFC5322 compliant in all cases? The ability to record message output, as suggested by Michael, is probably my next step. Will tackle it after all images are restored to the Fischer Tutorial. SIDENOTE Procedure ReadText has RETURN approximately in the middle. I made an unsuccessful attempt to move RETURN according to Oberon-07 syntax. I admire the functionality coupled with inscrutability. =8~) Eventually might have another go at the revision. Thanks, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0

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

16 Jul '22

> Luca Boasso luke.boasso at gmail.com Sun May 16 03:13:24 CEST 2021 > > I have two problems in forcing the programmer to think about import ordering: > > 1. It does not scale. If you have big systems it is hard to hold in your > head all the import relationships. It is better to have the compiler figure > it out for you and do the proper checks. > > 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. Luca, I now couldn’t resist and have actually implemented a variant of ORB that removes the “invalid import order” restriction and allows hidden re-imports to peacefully coexist with identifiers. It was surprisingly straight-forward to implement, only about 15-20 lines of code. Details are here (variant 2): https://github.com/andreaspirklbauer/Oberon-module-imports The key idea is to simply propagate reference numbers of re-exported types from the original module throughout the module hierarchy (I just add to the information that is already output for re-exported types). When later a type T is imported explicitly, one only needs to check that particular reference number had previously been re-imported. And if so, the type is discarded after having read it from the symbol file. PS: This would make a nice exercise for a compiler course. Not much to code, but some thinking is required for sure. Andreas

2 1

What happened to Zonnon
by Darek Maksimiuk 15 Jul '22

15 Jul '22

Hi All, I hope that is a good place to ask some questions which are not strictly Oberon related. I am trying to find if there are any activities around Zonnon programming language and its compiler. There is a web page : https://zonnon.org with some embedded (and dead) links to : http://zonnon.ethz.ch Is anyone in the community aware about the status of the Zonnon project (anybody is using the existing compiler or working on something new) ? Any info is highly appreciated! Regards, Darek P.S. The is a snapshot of the project here: https://web.archive.org/web/20140809032925/http://www.zonnon.ethz.ch/projec…

2 2

RFC 5322 and ETH Oberon SMTP.
by peter＠easthope.ca 15 Jul '22

15 Jul '22

Hi, Some of my messages sent by SMTP in the Oberon subsystem of A2 bounce with a report such as this. <aabbcc(a)gmail.com>: host gmail-smtp-in.l.google.com[142.250.102.26] said: 550-5.7.1 [192.185.50.161] Our system has detected that this message is not RFC 550-5.7.1 5322 compliant. To reduce the amount of spam sent to Gmail, this 550-5.7.1 message has been blocked. Please review 550 5.7.1 RFC 5322 specifications for more information. gs16-20020a1709072d1000b00718c7b4cbeasi2856260ejc.991 - gsmtp (in reply to end of DATA command) The reference to RFC 5322 is non-specific. Most incidents are for Gmail addresses but some other addresses have produced bounces. Ideas? Thx, ... P. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

3 2

Re (2): Re (2): RFC 5322 and ETH Oberon SMTP.
by peter＠easthope.ca 15 Jul '22

15 Jul '22

From: Paul Reed <paulreed(a)paddedcell.com> Date: Fri, 15 Jul 2022 16:23:52 +0100 > Can you highlight the specific SMTP sending code you're running? Two links to Oberon.Mail.Mod here. https://en.wikibooks.org/wiki/Oberon/A2#Module_Sources,_Tools_and_Configura… The source compiled on my computer is almost identical to the "Wikibook copy". During the weekend, will check for a difference. Revisions of the ETH version are described in the discussion page of the Wikibook copy. https://en.wikibooks.org/wiki/Talk:Oberon/A2/Oberon.Mail.Mod Will check the other points in your email also. Incidental note: "Wikibook version" is probably better terminology than "Wikibook copy". =8~/ Thanks for replying, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

1 0

Re (2): RFC 5322 and ETH Oberon SMTP.
by peter＠easthope.ca 15 Jul '22

15 Jul '22

From: Joerg <joerg.straube(a)iaeth.ch> Date: Fri, 15 Jul 2022 08:17:33 +0200 > ... not ALL emails are bounced? In other words: is it a sporadic effect? Correct. Definitely sporadic. > Did you investigate what is special with the bounced emails? No systematic investigation yet. A simple observation is that my smarthost mail server is blacklisted occasionally. I receive a bounce message mentioning blacklisting. It must affect thousands of others along with me and clears automatically after a day or two. The bounces from the gmail recipients don't mention blacklisting. Appears that blacklisting can be a third party service whereas Gmail might operate blacklisting internally. > - are they longer than others? Recently only short messages. Few of my messages are longer than the height of the screen. > - do they have one or more recipients? A recent message had 5 or 6 recpients. Two with gmail addresses gave the report described. > - do they have long attachments? Not the recent ones. The alternative I prefer is a file or files on a http server. > - when you close and reopen A2 does the same email bounce again? Haven't checked that. Will blunder along as usual and keep your questions in mind. Thanks, ... P.L. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W

2 1