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

Re (2): Keyboard substituting for mouse.
by peter＠easthope.ca 18 Jan '16

18 Jan '16

> How easy is it to disable the damned <capslock> or move it to > a 'remote' key: eg. Pause/Break ? In NO, Break already has a use. Don't break Break. In Input.Mod, Search for CapsLock. Disabling shouldn't be difficult. Comment out the actions you don't want and recompile. Eg. < ELSIF c = 03AX THEN (* Caps make *) < LedKey(flags, CapsLock, c, k) > ELSIF c = 03AX THEN (* Caps make *) > (* LedKey(flags, CapsLock, c, k) *) If you want another key to function as CapsLock, put those commented actions in the preferred locations. In any case, CONST ... CapsLock = 2; shouldn't need a change. A disabled <Caps Lock> in a public release for general use probably will confuse more than help. The keyboard has been inherited from the mechanical typewriter with the convolutions of <Shift>, <Caps Lock>, <Cntrl>, <Alt> and etc. to extend functionality. Better to focus on the display and pointing devices and keep the elaborations in software. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 2

Availability of OberonStation
by Ken Boak 18 Jan '16

18 Jan '16

Hi, I am new to this list - attracted by the low resource requirement of the Oberon System. A few quick questions: Could someone advise me please of the availability of the OberonStation kit - currently showing a "Sold Out" status. Is there a new batch expected in the near future? Have any of the list had experience of the Oberon system on the Xilinx Artix-7 - specifically on the $99 Arty board - is this a preferred platform? Finally, and perhaps best addressed to Chris Burrows - I see that you have produced packages for the ARM M3 and M4 Cortex - mainly NXP. Do you have any aspirations to port to Cortex M7 - such as the $50 STM32F7 Discovery Platform - which has a great selection of useful hardware on-board? regards Ken London

3 2

Re: [Oberon] Availability of OberonStation
by Ken Boak 18 Jan '16

18 Jan '16

Walter, & List Thank you for your rapid response. Forgive me - but it is met with more beginner's questions. Could you point me to details of how you have handled keyboard/mouse and video on the Arty. For another project, I have developed a small VGA shield that fits the Arduino-style headers, that also includes PS/2 keyboard & mouse. It can also produce a RGB 3:3:2 colour video output using an appropriate resistor network. I presume that your uSD is effectively taken care of with the on-board QuadSPI 16MB Nand Flash? Has anyone on the mailing list devised any simple way of benchmarking the performance of Oberon against other known systems? Thanks again Ken >

1 0

Re: [Oberon] Syntax-directed program editing
by Chris Burrows 18 Jan '16

18 Jan '16

> -----Original Message----- > From: eas lab [mailto:lab.eas@gmail.com] > Sent: Sunday, 17 January 2016 4:58 PM > To: chris(a)cfbsoftware.com; ETH Oberon and related systems > Subject: Re: [Oberon] CapsLock > > What about a syntax-directed editor/system, where you initially see:- > Module #ModID; ConstDecls; .... > ProcDecls; > BEGIN > Stmts > END. > I have occasionally tried the sorts of systems that use shortcut keys to insert code templates / snippets for different constructs e.g. using Visual Studio's 'IntelliSense > Insert Snippet' feature you can type CTRL-KXF<Enter> and you will get for (int i = 0; i < length; i++) { } You then edit the variables and fill in the blanks. However, I haven't got into the habit of using that. I find it awkward if my flow of typing does not follow my train of thought. Also, the slower I type the more time I spend thinking about what I am typing which is usually not such a bad thing :) My best experience with smart typing was in the 1980s when I was developing Pascal software for a couple of years on an HP64000 Microprocessor Development System. They had a neat system where each function key was mapped to a label just above the key at the bottom of the screen. The labels changed according to the context. However, I can't remember exactly, but I think it was probably used when entering command-lines rather than program text. In the HP64000 documentation (which can be downloaded from bitsavers.org) it is described as follows: "Directed syntax, softkey operation makes the Development Stations friendly. Syntax errors are virtually eliminated as the software-driven softkeys present selections of appropriate commands at each decision point. Commands are entered by a keystroke rather than by typing cryptic code words, letter by letter. New users of the 64000 Logic Development System become proficient quickly, and experienced users work more effectively." Regards, Chris Chris Burrows CFB Software http://www.cfbsoftware.com

4 4

Re: [Oberon] CapsLock
by Chris Burrows 17 Jan '16

17 Jan '16

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Steven Hirsch > Sent: Sunday, 17 January 2016 6:51 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Re (2): Keyboard substituting for mouse. > > On Sat, 16 Jan 2016, peter(a)easthope.ca wrote: > > > A disabled <Caps Lock> in a public release for general use probably > > will confuse more than help. > > That's odd. The system that shipped with my OberonStation does not > have a functional caps-lock. > > I would go further than the other Chris (Chris Glur) and would rename it the "DAMNED <cAPSlOCK>". I don't know why he doesn't like it but the problem I have always had with it is that I set it on and then forget and start using the shift key as well so I end up with something like this: PROCEDURE rEADiNT Yes - I know, it's my fault as I have never learnt how to touchtype properly so I only look at the screen after typing every few words. My preferred behaviour would be that the Shift key is ignored whenever CapsLock is on instead of acting as 'toggle case' but I guess that would confuse everybody else. Consequently I never use the <CapsLock> key. Believe it or not it was this irritation that led to the creation of first CPIde and then Astrobe. I designed the editor so that you could type everything in lowercase (using the shift key for isolated capital letters). The editor recognises Oberon reserved words and keywords and automatically capitalises them. For example, if I type: procedure ReadInt(r: Rider; i: integer); begin The Astrobe editor's auto-capitalisation feature converts this on the fly to: PROCEDURE ReadInt(r: Rider; i: INTEGER); BEGIN Of course, the feature can be switched off for those who are happy with CapsLock. For those who need to have CapsLock on RISC5 Oberon I have proposed a modification to Input.Mod on the OberonStation forum: http://oberonstation.x10.mx/smf/index.php?topic=22.0 Regards, Chris (Burrows) CFB Software http://www.astrobe.com

4 3

Re: Keyboard substituting for mouse.
by peter＠easthope.ca 17 Jan '16

17 Jan '16

From: joerg.straube at iaeth.ch (Joerg), Tue, 12 Jan 2016 11:31:53 +0100 > ... unfortunate that Project Oberon has no standardized definitions of the > key codes for the up, left, right and down keys. As I like to move around the caret > with my keyboard instead of the mouse ... A general solution which simplifies Mouse* and facilitates support for other input hardware. MODULE Input; ... < ELSIF c = 046X THEN (* Scroll make *) < LedKey(flags, ScrollLock, c, k); < state := DisableInterrupts(); < IF ScrollLock IN flags THEN < IF Kernel.timer = NIL THEN Kernel.timer := timerproc END < ELSE < IF Kernel.timer = timerproc THEN Kernel.timer := NIL END < END; < RestoreInterrupts(state) > ELSIF c = 046X THEN (* Scroll make *) > LedKey(flags, ScrollLock, c, k); > state := DisableInterrupts(); > IF ScrollLock IN flags THEN (* Keypad input extant. *) > RemoveMouse(GetKeypadEvent); > AddMouse(GetMouseEvent); > IF Kernel.timer = NIL THEN Kernel.timer := timerproc END > ELSE (* Mouse input extant. *) > RemoveMouse(GetMouseEvent); > AddMouse(GetKeypadEvent); > IF Kernel.timer = timerproc THEN Kernel.timer := NIL END > END; > RestoreInterrupts(state) < PROCEDURE Mouse*(ind: SHORTINT; VAR keys: SET; VAR x, y: INTEGER); < ... < IF ScrollLock IN flags THEN < keys := {}; < IF 11 IN kpmap THEN INCL(keys, 2) END; < IF 5 IN kpmap THEN INCL(keys, 1) END; < IF 12 IN kpmap THEN INCL(keys, 0) END; < state := DisableInterrupts(); < INC(m.mouseX, LONG(kdx)); < INC(m.mouseY, LONG(kdy)); < kdx := 0; kdy := 0; < RestoreInterrupts(state) < ELSE > PROCEDURE GetKeypadEvent(VAR keys: SET; VAR dx, dy, dz: INTEGER): BOOLEAN; > ... > keys := {}; > IF 11 IN kpmap THEN INCL(keys, 2) END; > IF 5 IN kpmap THEN INCL(keys, 1) END; > IF 12 IN kpmap THEN INCL(keys, 0) END; > state := DisableInterrupts(); > INC(m.mouseX, LONG(kdx)); > INC(m.mouseY, LONG(kdy)); > kdx := 0; kdy := 0; > RestoreInterrupts(state) > ... A week or more until I can test it. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 2

Re: [Oberon] Numerical CASE Statements in Project Oberon
by John Stout 17 Jan '16

17 Jan '16

Jan I wasn't suggesting that we NOT implement it, just that compiling it (implementing it) to a series of compiled IF THEN statements may be more in keeping with NW's view. Suppose we have (taken from the Oberon-07 report): CASE k OF 0: x := x + y | 1: x := x − y | 2: x := x * y | 3: x := x / y END This would compile, using IF THEN equivalents, to code like this (I've assumed that R14 is a base register): LDR0, R14, k_offset SUBR1, R0, 0 BNECase_1 code for x := x + y BEnd_Case Case_1: SUBR1, R0, 1 BNECase_2 Code for x := x - y BEnd_Case Case_2: SUBR1, R0, 2 BNECase_3 Code for x := x * y BEnd_Case Case_3: SUBR1, R0, 3 BNEEnd_Case Code for x := x / y End_Case: This is simple and clear. There is a clear maximum execution path length. Adding label ranges is a bit longer, but still (I think) simple and clear, e.g., CASE k OF 0 .. 10: x := x − y | 11 .. 1000: x := x * y | 1001 .. 2047 : x := x / y END could compile to something like this: LDR0, R14, k_offset SUBR1, R0, 0 BLTCase_1 SUBR1, R0, 10 BGTCase_1 code for x := x - y BEnd_Case Case_1: SUBR1, R0, 11 BLTCase_1 SUBR1, R0, 1000 BGTCase_2 Code for x := x * y BEnd_Case Case_2: SUBR1, R0, 1001 BLTCase_1 SUBR1, R0, 2047 BNEEnd_Case Code for x := x / y End_Case: This will work even for very large ranges. The size of the generated code (no data needed) depends on the number of cases, not the range of the constants in the case label list or case label range. Adding label lists: CASE k OF 0, 10: x := x − y | 11, 1000: x := x * y | 1001, 2047, 19 : x := x / y END could compile to something like this: LDR0, R14, k_offset SUBR1, R0, 0 BEQC_1 SUBR1, R0, 10 BNECase_1 C_0:code for x := x - y BEnd_Case Case_1: SUBR1, R0, 11 BEQC_1 SUBR1, R0, 1000 BNECase_2 C_1:Code for x := x * y BEnd_Case Case_2: SUBR1, R0, 1001 BEQC_3 SUBR1, R0, 2047 BEQC_3 SUBR1, R0, 19 BNEEnd_Case C_3:Code for x := x / y End_Case: John >> Am 16.11.2015 um 09:31 schrieb Jan de Kruyf <jan.de.kruyf(a)gmail.com>: >> >> Yes, >> The old man has been right most of the time, I agree. And I will have >> a royal battle to reduce the compiler construction back down to >> Wirthian elegance, that I also realize. But at the same time the code >> I produce is very elegant and sweet. On the basis of that I would say >> you are wrong in your statement that IF THEN can be made as efficient >> as a good case construct. Besides, a Case statement allows ranges >> like A..Z, a..z and so on, this has never been part of IF THEN, while >> in a properly constructed bin-tree it resolves itself. >> >> So since Wirth was first and foremost a teacher all his life, we >> could say that there are 2 learning opportunities here 1. to produce >> fast code. >> 2. to construct an elegant way of doing so. >> >> I think that the master himself also realized the issues you and I >> are bringing up, and did not see his way out of the predicament yet. >> And since he is about 80 now and since he still got a few irons in >> the fire this was left for a bit. >> >> Lastly Dijkstra taught that you should never limit yourself because >> of inefficient machines. But you should strive to generalize any >> language design solution to as many cases as possible, even if that >> slows your program execution down a bit. There were big arguments in >> the Algol design meetings about that. Some people then felt that you >> had to live with the equipment given and use it as efficiently as >> possible. Wirth no doubt knows that whole history even better than I >> do. In the mean time of course, the machine limitations of those days >> (it was the time of the vacuum tubes) have been solved a hundred >> times over, but we still are trying to live with the language limitations of some of the older languages. >> Ergo the numerical case statement is in the O-7 language report, but >> is has not been implemented yet. >> >> So I feel fully justified implementing it. The way how to, we can >> talk about. If the Oberon community is alive and well ten I am sure >> that the last word has not been spoken yet. >> >> >> Enjoy your day >> >> j. >> [King George V Logo] John Stout Management Information Systems Coordinator Tel: 01704 530601 E-Mail: JSS(a)kgv.ac.uk Web: www.kgv.ac.uk Information contained in this e-mail is intended for the use of the addressee only and is confidential. Any dissemination, distribution, copying or use of this communication without prior permission of the addresseeis strictly prohibited. Every effort has been made to ensure that any attachment to this mail does not contain virus. King George V College has taken every reasonable precaution to minimise this risk, neither it nor the sender can accept liability for any damage which you sustain as a result of software viruses. You should carry outyour own virus checks before opening any attachments. [Think Before You Print]

11 17

Old versions: MultiScreen Select?
by Andreas Pirklbauer 17 Jan '16

17 Jan '16

An implementation of multiscreen select (together with continuous line scroll) in Oberon can be found here:https://github.com/andreaspirklbauer/Oberon-3-continuous-fractional-li… ------------------------------------------------------------------ On 06/07/14 07:19, eas lab wrote: > I vaguely remember that old versions of ETHO couldn't select text-stretches > which exceeded the ViewerSize, which the mouse could sweep. But you could always split the viewer and select arbitrary long text by starting the selection in the first viewer and ending it in a different part of the document in the second viewer. Richard ============== As Peter Easthope pointed out, the finer details are that: Old method needed sweep TopViewer till bottom, and sweep lower Viewer from from top. Which works with ALO now. Since I've got rPi:ALO connected via HDMI to the same display as X86:LEO via VGA, and they both have the same look and feel, I can easily forget who I'm talking to, when I come back after a few hours absence. Thanks, == Chris Glur. PS. the following belongs to the <functional composition> thread;-- I've been thinking how to show the marvels of *nix piping to some non-*nix users, via this exercise: Why is this LEO [aka Linux-based ETH Oberon] hanging? Show me the pid/s of all LEO = pgrep beron Show me the latest one started = pgrep beron | tail -1 Show me which files it has open = lsof | grep `pgrep beron |tail -1` !!Wow!! There a big problem. Right now, by test/pasteing that cmd, it shows: .. IPv4 391647 TCP 10.208.223.203:41160->78.46.70.116:nntp (ESTABLISHED) But I've been off-line for 10 hours. On 6/7/14, Richard Hable <informujo at aon.at> wrote: > On 06/07/14 07:19, eas lab wrote: >> I vaguely remember that old versions of ETHO couldn't select >> text-stretches >> which exceeded the ViewerSize, which the mouse could sweep. > > But you could always split the viewer and select arbitrary long text > by starting the selection in the first viewer and ending it in a > different part of the document in the second viewer. > > Richard > > > -- > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon >

1 0

Re (3): Keyboard substituting for mouse.
by peter＠easthope.ca 16 Jan '16

16 Jan '16

From: Steven Hirsch <snhirsch(a)gmail.com>, Sat, 16 Jan 2016 15:21:05 -0500 > That's odd. The system that shipped with my OberonStation does > not have a functional caps-lock. Sorry, I should have mentioned Native Oberon. Might apply to Unix Oberon also. I'd guess that Chris has one of those. No idea for Oberon FPGA or OberonStation. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Functional programming style for Oberon?
by eas lab 14 Jan '16

14 Jan '16

Some years ago when the OO-paradigm was at it's peek, ETHO was extended to handle procedure types, which could be passed as arguments. There's great advantages in avoiding temporary-fads, so I never exercised OOP. Now [using LEO] that it's less easy to access my old NativeOberon files, I failed to find the documentation, and example uses of the <passing PROCs as arguments>. Where should I look? Can Oberon procedure types facilitate the <functional/compositional> style of programming? Which is NOT a passing fad. *nix's <piping of functions/data-transformers> is staggeringly economical in user's effort, but has a terrible syntax. The benefit of removing the need to learn ad-hoc syntaxS is my motivation for syntax-directed-editors & menu-driven-usage: which ETHO already used successfully. An example of *nix's ability to easily get results by piping a sequence of existing/proven/well-tested functions together [but using understand-able syntax] is:-- CheckTheFileDataBaseForFilesNamed *roc*ointer* | ButSkipAllFiles *.pdf *.zip *.ps *.gz | AndListThoseContainingString "beron" The big advantage of this functioal/compositional style is the maintainablity. Which is the whole idea of NW's "MODUL"a and "COMPONENT" pascal. Some years ago, when my then ISP introduced Sender-must-ID for email, it was quite a job to modify the ETHO <emailer>. Now there's a new-fad which messes my TextToSpeech facility: instead of 'saying' "can't", it says "Sea Aye Enn Tea"; because many feature/fad-following clowns are replacing the one-byte single-quote [ASCII] by 3 bytes. Since the substantial processing-stages of fetching [unfortunately these days http-formatted] text, visually scanning it to wipe-out <bad sections> by an ETHO-like editor, and getting the TestToSpeech to a device, as a suitably-named file, needs only a few mouse-chords and typing the chosen name, you don't need to understand the details of each stage. So you can just plug-a-function-into-the-pipe-line to: <translate the 3-byte-quote-fad to ASCII(SingleQuote)>. Which just needs pasting from your library of examples, a 10 char line, and editing/modifying it; into the suitable pipe-line position. That's why I call it MickeyMouse programming. A most convincing argument, for me, for the functional style, is:-- Let's create a list of all even numbers up to 100, and another list omitting the first five of them. The program written in Java. final int LIMIT=50;int[] a = new int[LIMIT]; int[] b = new int[LIMIT - 5]; for (int i=0;i < LIMIT;i++) { a[i] = (i+1)*2; if (i >=5) b[i - 5] = a[i]; } The program written in ### let a = [2,4..100] let b = drop 5 a It is immediately clear that with ###, you can understand what's going on; whereas in Java, or any imperative language, you can barely tell what the code is supposed to do because you are overwhelmed with the low-level minutia. This effect increases as programs grow more complex. From this simplicity and abstraction flow most of ###'s advantages. ----------------------------- end of extract. -------------------- ### <- let's not get stuck on NAMES. Let's rather first understand the CONCEPTS. Of course, the above is an extreme example, but ETHO's already existing facilities could perhaps do: MapFunctionOverElements(DigitToText:PROC, DigitSequence: TextString):TextString; MapFunctionOverElements(TestForPrime:PROC, Ints1toN: IntegerList):IntegerList; There's nothing new about this. Extracting from McCarthy [designed lisp in 60s?]:- These three procedures clearly share a common underlying pattern. They are for the most part identical, differing only in the name of the procedure, the function/job of a used to compute the term to be added, and the function that provides the next value of a. We could generate each of the procedures by filling in slots in the same template: ------ snip lisp code --- The presence of such a common pattern is strong evidence that there is a useful abstraction waiting to be brought to the surface. Indeed, mathematicians long ago identified the abstraction of summation of a series and invented ``sigma notation,'' to express this concept. The power of sigma notation is that it allows mathematicians to deal with the concept of summation itself rather than only with particular sums -- for example, to formulate general results about sums that are independent of the particular series being summed ... What are unforeseen problems in using ETHO to do this too? == Chris Glur. PS. it's very problematic pasting the pre-written text into the web-browser for gmail [designed for F/B-twitter kiddies=modern] compare to the 90's N-O emailer. Can Linux:Aos handle gmail?

6 12