January 2017 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Re (2): Parts & paths.
by eas lab 15 Jan '17

15 Jan '17

Re. Aos under Linux: Aos' ability to increase font size for all Frames, is also good for Oberon systems which have too small font. But: as for all older ETHO versions: Oberon.Text file has a <default font size field>. When I changed that and re-launched Oberon from inside Aos, there was no corresponding font change in the new-Oberon launch. Perhaps the Documentation only applies to pre-Aos: Oberon? Is Oberon.Text in Aos' Oberon effective? Does Inet connect via the Linux underlying system; ie. connect via Linux, and use Aos' inet facilities? == TIA. PS. it's confusing when Linux and M$:Win have similar *LOOKING* apps, with slightly different input reactions. You think you are talking to Jack, but John reacts differently.

1 0

Re: [Oberon] Incremental evolution of piping system?
by Lars 14 Jan '17

14 Jan '17

On Tue, January 10, 2017 8:24 pm, eas lab wrote: > *Importantly* FP/piping gives extreme modularity Piping also gives danger... make one little mistake and your entire pipe could be very dangerous.. This is what has always scared me about unix commands, one little error and you can eff up your system.. even a typo... There is no "recycle bin" to back up and get out of what you just did, unless, you made a backup of your system before running a command. That would mean every single command you ever run, you have to make a backup first, which no one does.. Now on the other hand if your pipe isn't doing that much which is dangerous, i.e. just getting a read only output of something....

3 2

Re (2): Parts & paths.
by peter＠easthope.ca 11 Jan '17

11 Jan '17

From: eas lab <lab.eas at gmail.com> Date: Thu, 13 Oct 2016 07:03:31 +0200 > ... LNO & ALO are restricted to files in their own-single directory? In UnixAos, including LinuxAos as a particular case, any directory can be addressed relative to the working directory. If your working directory is /home/chris/work , the root of the file system is /../../ . Try some examples. System.Directory /../../home/chris/* ~ System.Directory /../../tmp/* ~ Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 2

Incremental evolution of piping system?
by eas lab 11 Jan '17

11 Jan '17

Where is Oberon's "DoIt" facility? ----------------------- The idea is that if you "ask the time", you don't want to have to get married to the respondent, like with gmail that gives you only the minimum info, at each query, in order to keep you "engaged" and waste your time, to be able to manipulate you, to earn money. So, to find out the time, you don't want to have to start and run a further live-program. ----------------------------- Ie. I use: `g1277 L WiFi` <-3 tokens: 1 verb + 2 args to: use a textOnlyHttpFetcher to fetch the contents of all URLs listed in file:L, appending them to File:WiFi [the evolving book on WiFi], and heading each fetch by the URL, and terminating eah appended fetch by "<><><><><>"; which allows stepping through the evolving WiFi<book>, from the <contents list at the top>, and where <find next "<><><>" > is equivalent to stepping to the next chapter. This one-artillery-shot/DoIt as opposed to the live-TV show paradigm, could be an incremental step towards giving ETHO piping ability. ------------------------ The simplest approach to achieve concatenation of functions, may be to just use 2 files A & B, to alternate the function-chain through? So using V4, which is all I've got now, as an example task: Show first 8 most recently modified fileNames of <Directory>: [this stack-concept function is ESSENTIAL for when working in a directory, which has already MANY files, swamping the new relevant ones.] ----------------------- System.Directory /C:/Users/Public/CRG/LynxW32/*\d > A CutOffTopLines (2, A) > B SwapWiteCharDelimitedFields(1,2,B) > A ReOrderStupidDateFields(A) > B ReverseOrderLines(B) > A ShowFirstLines(8,A) It seems that a refinement of the 6 stages above, is that A, B can be global constants and are redundant args to the listed functions. A function is a procedure with input parameter/S and preferably ONE output. So it seems to be simplifying to: System.Directory /C:/Users/Public/CRG/LynxW32/*\d | CutOffTopLines(2) | SwapWiteCharDelimitedFields(1,2) | ReOrderStupidDateFields | ReverseOrderLines | ShowFirstLines(8) As I recall, S3 has already got several of these functions. One perceived value of such an extension to ETHO is the ability to write in our nice syntax; building a set of usefull functions which can easily be concatenated to do common jobs, without starting an extra live program. Of course the aspect of stand-alone utilities, and piping capability within the existing OS, are separate considerations. NB. no extra temporary variables are introduced, and any extra filter/function can be introduced at any stage in the chain. Eg. in the above example: "skip all files named *.Obj". == Chris Glur. PS. How would I, with this lame M$ system: mark, with 3 or less key-strokes, the ID of a <worked on file> in any directory, so that V4 [or other program] can immediately access such file ? Under *nix, you can call a universally accessible script eg. `Lz` to: write the directory & most recently changed file/S to a file <known by V4>; wherby V4, will just look into the pre-agreed file to get the needed info.

2 3

OLR
by peter＠easthope.ca 08 Jan '17

08 Jan '17

Hello Peter M., I've left two messages about OLR in wikidot. https://www.wikidot.com/account/messages This is the only way I know, to notify you. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Class Methods Vs. Procedure variables in Records
by Andreas Pirklbauer 06 Jan '17

06 Jan '17

This topic has been the subject of intense debate at the Institute of Computer Science at ETH Zurich around 1988-early 1990s. It's hard to convey the full spirit of these discussions so many years later, but I'll try to summarize some of the key aspects that were discussed back then, at least as far as object-oriented programming is concerned. One key topic was of course whether the language should be "instance-centered" vs. "class-centered". First, a language called Object Oberon was devised and implemented at ETH Zurich. It was essentially a class-centered derivative of the original Oberon language (adding a keyword CLASS and class methods, etc). I have used it extensively. Among other things, that project demonstrated that adding a class mechanism to an existing language can be achieved with relatively little extra effort. And indeed, the compiler's complexity increased only moderately (10-20%). Then Oberon-2 was devised, which essentially removed the CLASS keyword and added type-bound procedures instead, i.e. classes where now again also called what they really are - namely records. It too was not significantly more complex than the original Oberon language and compiler. Of course much simpler than the OOP languages that emerged during that period (we were still in a pre-Java world back then and had to put up with C++ or the like). But even though it was demonstrated that the additional complexity of the compilers for Object Oberon and Oberon-2 remained within tolerable bounds, the debate was not about that, but rather whether the notational conveniences justify the conceptual complications. The "defendants" of the original Oberon language (instance-centered with procedure variables) argued that while it is true that class-centered languages (with class methods, a.k.a. type-bound procedures) offer a somewhat more convenient notation, increased security, and also more efficient upcalls, this was considered a marginal advantage. It was believed the object-oriented programming style should be confined to a few select cases only, i.e. one should use it only where it is justified and deemed appropriate - whatever that means (seen from today's point of view, where Java has achieved such a dominant position, and where it seems that almost everything has to be a class, this may sound strange, but back then the OOP style has not yet gained widespread adoption and many ideas were still in flux). The "case study" cited as proof was of course the Oberon System itself: It showed that the entire Oberon system could be programmed in conventional programming style, except for one area: the viewer system, as everyone knows who contributed to or extended the viewer system. It was a lively debate, to say the least.. But in the end, the question remained open. This is, I believe, one of the reasons why we now have two main version of the Oberon language: Oberon and Oberon-2. Personally, I believe Oberon7 is enough for many purposes, and that certainly includes system design. And that is why I decided to stick to the original Oberon language in Experimental Oberon. But that is entirely my personal bias. From an educational point of view, I would consider using Oberon-2 instead, as it very nicely and cleanly demonstrated the various OOP concepts. But in any case, more important than the choice of the language is, I believe, to teach the debate. Srinivas Nayak sinu.nayak2001 at gmail.com Tue Jan 3 05:17:06 CET 2017 All,In Oberon we have Procedure variables in Records.In Oberon2 we added/appreciated Class Methods.But Oberon7 we only retained Procedure variables in Records.In the evolution of Wirthian languages, when Oberon allowsobject oriented paradigm, why still we thought,Procedure variables in Records is the way to go with Oberon7?In other words, why we decided and retained Procedure variables in Records,but didn't go for Class Methods? Any disadvantage of Class methods?Why we think, Procedure variables in Records is more elegant than Class Methods?Where can we find discussions/decisions on these two constructs by masters?Kindly note that, in this query,my focus is on Language design, rather than Language use.With thanks and best regards,Yours sincerely,Srinivas NayakHome: http://www.mathmeth.com/sn/Blog: http://srinivas-nayak.blogspot.in/

4 3

The list might find this post interesting
by Liam Proven 06 Jan '17

06 Jan '17

It's not mine, I should point out. I just found this fascinating blog by the notice that it was closing down. Shame but it's been a fascinating afternoon's reading. A bit like the great Jamie Zawinski's blog, you can just jump in, start opening links in tabs, and get lost for hours while learning a lot. Disclaimer: I'm not saying that what you're going to learn is /useful/ but I certainly find it very interesting. Here's where he got to Oberon: http://prog21.dadgum.com/136.html I suggest starting with the links at the bottom... -- Liam Proven • Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk • Google Mail/Talk/Plus: lproven(a)gmail.com Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053

1 0

Re: [Oberon] Class Methods Vs. Procedure variables in Records
by Josef Templ 04 Jan '17

04 Jan '17

Excellent summary by Andreas. In addition I would like to point out that the motivation of moving from Object Oberon's class syntax to the Oberon-2 syntax was to avoid many forward references. The other motivation was of course to make the syntactical differences smaller by removing additional keywords. The overall compiler changes for Oberon-2 were smaller than for Object Oberon, if I remember correctly. In later Oberon extensions such as BlueBottle and A2 the problem with forward references has been solved by substantially rewriting the parser but I don't know the details of the approach chosen. Having methods nested within a RECORD scope was thereby less of a burden in practice and very natural with respect to scoping. In general, the message records and explicit message dispatching as used in the Oberon system proved to be successful and have also been used in BlackBox for the visible objects (Views), although BlackBox does not use handler procedure variables per object but type bound handlers. Class based OOP with method tables instead of message records is more efficient because it replaces the message dispatching consisting of cascades of nested IFs by a tiny constant time operation. It gives up the full flexibility and extensibility, though. This OOP style has been used in the "Draw" editor for abstracting from the different classes of graphical objects (Rectangles, Curves, etc.). The Draw editor was used for drawing board layouts with hundreds or thousands of graphical elements and at least at that time the performance gain was important. - Josef

1 0

Class Methods Vs. Procedure variables in Records
by Srinivas Nayak 03 Jan '17

03 Jan '17

Dear All, In Oberon we have Procedure variables in Records. In Oberon2 we added/appreciated Class Methods. But Oberon7 we only retained Procedure variables in Records. In the evolution of Wirthian languages, when Oberon allows object oriented paradigm, why still we thought, Procedure variables in Records is the way to go with Oberon7? In other words, why we decided and retained Procedure variables in Records, but didn't go for Class Methods? Any disadvantage of Class methods? Why we think, Procedure variables in Records is more elegant than Class Methods? Where can we find discussions/decisions on these two constructs by masters? Kindly note that, in this query, my focus is on Language design, rather than Language use. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

2 2

Announcement: ofront 1.4 final Release for Raspbian and Linux 386
by Josef Templ 01 Jan '17

01 Jan '17

Hi everybody, I would like to announce the final release of ofront 1.4 for (1) the Raspberry Pi running under Raspbian and (2) i386 based Linux. ofront 1.4 comes with command line tools as well as a complete Oberon V4 system that also includes many extensions from Linz Oberon V4 (Dialogs, Elems, EditKeys, etc.). Version 1.4 of ofront adds a command named 'ocl' (Compiler.Compile in Oberon V4) that hides the complexities of the underlying C-compiler and linker and generates a shared object (.so) file per module. Compiling, loading and unloading of modules works as usual under Oberon V4. For the Raspberry Pi there is an interface module WiringPi.Mod for the wiringPi library and low-level modules RPI.Mod and GPIO.Mod for full access to all hardware registers. ofront 1.4 can be downloaded from http://www.software-templ.com/shareware.html. Best wishes for the year 2017. - Josef Templ

2 1