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

Procedure variables and local procedures
by Andreas Pirklbauer 29 Sep '17

29 Sep '17

> On 2017-09-28 21:15, August Karlstrom wrote > > On 2017-09-28 18:57, Andreas Pirklbauer wrote: > > Addendum: Another way to read the sentence “P must not be declared local to ANOTHER > > procedure” is that in fact “P may be declared local to the SAME procedure”. > > Your interpretation seemed far fetched at first, but you are most likely right. I get it now. > > -- August In fact, with the latest revision of Oberon-07 one could rewrite the above language rule as “If a procedure P is assigned to a procedure variable v, both v and P must be visible in the scope where the assignment is made and when it is made”. Thus, Oberon-07 now no longer *require*s the enclosing scope of a local procedure P to be active when P is executed. P only needs to be “reachable somehow”, and this could be via a global variable, as shown below. However I would not recommend adopting such a programming pattern (the example is just meant to show what is now “legally possible”). This may be why this new “feature" is advertised anywhere. It can be seen a byproduct of the decision to restrict access to variables on the global or the strictly local level. This eliminated the need for a static link in implementations. And this in turn means that the enclosing scope doesn’t have to be around anymore when a procedure P is executed. -Andreas MODULE M; TYPE Proc = PROCEDURE; VAR GlobalVar: Proc; PROCEDURE GlobalProc1; VAR LocalVar1: Proc; PROCEDURE LocalProc1; BEGIN END LocalProc1; BEGIN (*GlobalProc1*) END GlobalProc1; PROCEDURE GlobalProc2; VAR LocalVar2: Proc; PROCEDURE LocalProc2; BEGIN END LocalProc2; BEGIN (*GlobalProc2*) GlobalVar := GlobalProc1; (*allowed*) GlobalVar := GlobalProc2; (*allowed*) GlobalVar := LocalProc2; (*allowed (LocalProc2 visible in current scope)*) LocalVar2 := GlobalProc1; (*allowed*) LocalVar2 := GlobalProc2; (*allowed*) LocalVar2 := LocalProc2; (*allowed (LocalProc2 visible in current scope)*) (* GlobalVar := LocalProc1; (*not allowed (LocalProc1 undefined)*) LocalVar1 := GlobalProc1; (*not allowed (LocalVar1 undefined)*) LocalVar1 := GlobalProc2; (*not allowed (LocalVar1 undefined)*) LocalVar1 := LocalProc1; (*not allowed (LocalVar1 and LocalProc1 undefined)*) LocalVar1 := LocalProc2; (*not allowed (LocalVar1 undefined)*) *) END GlobalProc2; BEGIN (*M*) GlobalVar := GlobalProc1; (*allowed*) GlobalVar := GlobalProc2; (*allowed*) GlobalVar; (*allowed*) GlobalProc2; (*allowed (assigns LocalProc2 to GlobalVar)*) GlobalVar; (*allowed (effectively executes LocalProc2) !!!*) (* GlobalVar := LocalProc1; (*not allowed (LocalProc1 undefined)*) GlobalVar := LocalProc2; (*not allowed (LocalProc2 undefined)*) LocalVar1 := GlobalProc1; (*not allowed (LocalVar1 undefined)*) LocalVar1 := GlobalProc2; (*not allowed (LocalVar1 undefined*) LocalVar1 := LocalProc1; (*not allowed (LocalVar1 and LocalProc1 undefined)*) LocalVar1 := LocalProc2; (*not allowed (LocalVar1 and LocalProc2 undefined)*) LocalVar2 := GlobalProc1; (*not allowed (LocalVar2 undefined)*) LocalVar2 := GlobalProc2; (*not allowed (LocalVar2 undefined*) LocalVar2 := LocalProc1; (*not allowed (LocalVar2 and LocalProc1 undefined)*) LocalVar2 := LocalProc2; (*not allowed (LocalVar2 and LocalProc2 undefined)*) *) END M.

2 1

Procedure variables and local procedures
by Andreas Pirklbauer 28 Sep '17

28 Sep '17

Note that even though the Oberon language report of Oberon-07 still states that “If a procedure P is assigned to a procedure variable of type T [...]. P must not be declared local to another procedure”, in the current implementation of Oberon-07, this restriction is not actually checked - at least not in the case when the procedure variable to which a local procedure is assigned is itself declared locally in the same scope, as in the following example: MODULE M; PROCEDURE P; VAR p: PROCEDURE; PROCEDURE Q; BEGIN END Q; BEGIN p := Q END P; END M. which compiles correctly under Oberon 2013 without an error message. AP -------------------------------------------------------------------------- August Karlstrom fusionfile(a)gmail.com <mailto:fusionfile@gmail.com> Thu Sep 18 12:14:29 CEST 2017 In the latest revision of the Oberon language, access to identifiers in intermediate scopes is denied. Doesn't this imply that the restriction that only globally defined procedures can be assigned to procedure variables, is the unnecessary? -- August

3 4

Procedure variables and local procedures
by Andreas Pirklbauer 28 Sep '17

28 Sep '17

Wojtek, sure, this is possible - below is a slightly modified version. Compile M and N, then activate N.Run. MODULE M; IMPORT Texts, Oberon; TYPE PROC* = PROCEDURE; VAR proc*: PROC; W: Texts.Writer; PROCEDURE P () : PROC; VAR p: PROCEDURE; PROCEDURE Q; BEGIN Texts.WriteString(W, "Q executing"); Texts.Append(Oberon.Log, W.buf) END Q; BEGIN p := Q; RETURN p END P; BEGIN Texts.OpenWriter(W); proc := P() END M. MODULE N; IMPORT M; PROCEDURE Run*; BEGIN M.proc() END Run; END N. Local procedures are in fact almost identical to global procedures - they are compiled just like any (global) procedure, they have a fixed static starting address within the module block (where they are stored, just like global procedures). Therefore, they can of course also be assigned to variables and/or returned as the result of a function procedure, as shown in the above example. The only difference to global procedures is that it can only be *accessed by name* (i.e. in the source code) from the enclosing scope. For example, the local procedure Q can only *accessed by name* from the enclosing procedure P - i.e. only P can reference Q by name: it might of course call Q directly, but it can also assign Q to a local or global variable. Such an assignment is perfectly legitimate (recall that internally simply the address of Q is copied). So the fact that a local procedure Q can only be *accessed by name* from the enclosing scope does NOT mean that it somehow “disappears” once the enclosing procedure P has been executed. In other words, local procedures do NOT behave like local variables, which are allocated on the stack and indeed disappear once the procedure declaring them has been executed. By contrast, “local" procedures don’t go away, once the enclosing procedure has been executed. They are still there, it’s just that they can be accessed by their name only when the enclosing procedure executes. Andreas --------------------------- Thu Sep 28 19:06:44 CEST 2017 Skulski, Wojciech skulski at pas.rochester.edu <http://pas.rochester.edu/> wrote: Andreas: is the following code correct? If so, can another module import M and call M.proc()? What is the intent, if it is possible? MODULE M; TYPE PROC* = PROCEDURE; VAR proc*: PROC; PROCEDURE P () : PROC; VAR p: PROCEDURE; PROCEDURE Q; BEGIN END Q; BEGIN p := Q RETURN p END P; END M. ________________________________________ From: Oberon [oberon-bounces at lists.inf.ethz.ch <https://lists.inf.ethz.ch/mailman/listinfo/oberon>] on behalf of Andreas Pirklbauer [andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>] Sent: Thursday, September 28, 2017 12:57 PM To: ETH Oberon and related systems Subject: [Oberon] Procedure variables and local procedures Addendum: Another way to read the sentence “P must not be declared local to ANOTHER procedure” is that in fact “P may be declared local to the SAME procedure”. This is the case in the example below. Either way, the assignment to procedure variables is not restricted to globally defined procedures. AP On 28 Sep 2017, at 18:11, Andreas Pirklbauer <andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon><mailto:andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>>> wrote: Note that even though the Oberon language report of Oberon-07 still states that “If a procedure P is assigned to a procedure variable of type T [...]. P must not be declared local to another procedure”, in the current implementation of Oberon-07, this restriction is not actually checked - at least not in the case when the procedure variable to which a local procedure is assigned is itself declared locally in the same scope, as in the following example: MODULE M; PROCEDURE P; VAR p: PROCEDURE; PROCEDURE Q; BEGIN END Q; BEGIN p := Q END P; END M. which compiles correctly under Oberon 2013 without an error message. AP -------------------------------------------------------------------------- August Karlstrom fusionfile at gmail.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon><mailto:fusionfile at gmail.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>> Thu Sep 18 12:14:29 CEST 2017 In the latest revision of the Oberon language, access to identifiers in intermediate scopes is denied. Doesn't this imply that the restriction that only globally defined procedures can be assigned to procedure variables, is the unnecessary? -- August

1 1

Procedure variables and local procedures
by August Karlstrom 28 Sep '17

28 Sep '17

In the latest revision of the Oberon language, access to identifiers in intermediate scopes is denied. Doesn't this imply that the restriction that only globally defined procedures can be assigned to procedure variables, is the unnecessary? -- August

1 0

General - Academic vs Commercial applications
by Tomas Kral 28 Sep '17

28 Sep '17

Hi, I have come across a few interesting links on Oberon, applied in practice, traditionally of academic or even commercial use. This is an interesting one, http://www.oberon.ch/ Would anyone have some experience, can kindly explain here in brief? Also I miss a central link to AOS as a continuation of Oberon systems at ETH University faculty of informatics. I found these, but do not appear tied ... http://www.ethoberon.ethz.ch/ - possibly slightly outdated http://www.cs.inf.ethz.ch/ - Last updated: 22-12-2014 / RM to ETH department of informatics? https://www.inf.ethz.ch/department/faculty.html -- Tomas Kral <thomas.kral(a)email.cz>

5 5

NativeOberon's FileName limitations - HOW2 extend?
by eas lab 27 Sep '17

27 Sep '17

Linux : X11 is a monster, but LNO [121104] runs in a FrameBuffer nicely; also under 64bit. Why would you NEED LNO ? 1. to have multiple files visible together on the same screen; 2. with powerfull mouse-chording ability; PublicDomain wily [needs X11], copied from ETHO, is even better, except lacks 3. ETHO's coloring capability: to give an extra dimension to complex relationships between texts, possibly in multiple files. Mildly complex tasks, soon need 4, 5, 6 ...TextFrames viewable-together. Since screen-area is the limiting factor, M$'s wastefull <staggered frames>, copied by Aos, is NOT acceptable. The paper-book, where each of hundreds of pages "automatically line-up", is a magical concept! The big problem/weakness of LNO: not being able to immediately read/write to files anywhere in the file-tree, can be reduced by: 1. use a convenient file-navigator, like mc, which allows to 2. <push a button> at the reqired-file, which stores its /PATH/Name to a fixed location, which 3. is accessed by LNO to mount the file-to-be-accessed by LNO. Right now, while composing this text, via USBstik:Linux:TinyCore46:LNO I want to access some Oberon:V4 files on the M$-partition. I failed: apparently LNO can't mount FATFS, like LEO can. It shouldn't be difficult to extend the capability? But read/write to V4 files in LinuxFS, is OK via: FileSystem.Mount V4 LinuxFS /mnt/sdb2/CRG/ETHO/V4dirTree/usr/local/oberon/Text/~ The 4-string command/M.P had the last/long string stored in the known location; so "V4" is my chosen name and string1, string3 are in the <Tools Text>; and the user need only add his chosen name to make the 4-string command. Then System.Directory ^ V4:* lists the directory contents; giving immediate access to the 96 files:----------- V4:. V4:.. V4:Analyzer.Tool V4:AsciiCoder.Tool V4:Backup.Tool V4:Balloon.Text V4:BalloonIdx.hlp ... V4:Find.Tool V4:Welcome.Text V4:Xref.Tool 96 files ---------------- LNO can access all: Aos, *nix, FATFS and presumably V4 formats. The PROBLEM remains, to access eg. "tmp:mc-root", where "mc-root" is not a valid <FileName>. AFAIR <Linux ETH Oberon> was able to access such filenames by quoting? Can we extend LNO, perhaps based on LEO? == Chris Glur. PS. The fact that ETHO's System.Directory output is not available: ordered by recentcy, is a serious deficiency: not acknowledging that <the stack and tree> are central to cognition & thus computing ?

1 0

Re (2): General - Academic vs Commercial applications
by peter＠easthope.ca 27 Sep '17

27 Sep '17

Felix, Thanks for your overview. From: Felix Friedrich <felix.friedrich(a)inf.ethz.ch> Date: Wed, 27 Sep 2017 12:17:23 +0200 > Apart from that I am the "last man standing" for Oberon at ETH. One is better than zero. Thanks for your dedication! This circumstance is a good argument for incuding the language report for Active Oberon as HTML in the wikibook. Being a wiki, anyone can work on it. Subject to your permission of course. Incidentally, accesses to the front page has settled to 400-500/month. https://en.wikibooks.org/w/index.php?title=Oberon&action=info Certain to climb as the content increases and improves. 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

General - Xerox PARC 1970
by Tomas Kral 27 Sep '17

27 Sep '17

Hi, A bit of history, this is where it all started. http://www.computerhistory.org/revolution/input-output/14/348 In the Lab picture from left to right, Jim Mitchell, Ed Fiala, Terry Roberts, an unknown girl with a cigar(?), Wesley Clark, and Ed Taft. NOTE: Ed Fiala, a fellow contryman, (Eduard Fiala), I wonder what these people are today up to? When reading `Alto' specs, not seeing the size, price, etc. Still sounds like today's computing :-) -- Tomas Kral <thomas.kral(a)email.cz>

3 7

FPGA - Pictures.Mod composition
by Tomas Kral 27 Sep '17

27 Sep '17

Hi, Looking at these two structures, I am scratching my head, is a picture `kind of' bitmap, or `makes use of' bitmap, as we repeat fields: width, height, depth, and base, while only adding colour table? TYPE Bitmap* = POINTER TO BitmapDesc; BitmapDesc* = RECORD width*, height*, depth*: INTEGER; base*: INTEGER; size*: INTEGER END; TYPE Picture* = POINTER TO PictureDesc; PictureDesc* = RECORD width*, height*, depth*: INTEGER; bitmap: Bitmaps.Bitmap; base: INTEGER; ct: ColorTable END; Should we not just extend it? TYPE PictureDesc* = RECORD (Bitmaps) ct: ColorTable END; -- Tomas Kral <thomas.kral(a)email.cz>

5 7

FW: BMP; was "FPGA - Screen.Mod"
by Skulski, Wojciech 26 Sep '17

26 Sep '17

Hello: I attached two figures. One is PNG. I opened it in Irfanview, and then saved as BMP. They are essentially the same, are they not? Now look at the size of both files. PNG was 9 kB, the BMP is 203 kB Edit: on the moderator's request I had to remove the BMP because the message size is limited to 60 kB on this mailing list. You can use Irfanview at your end to recreate the BMP and to compare the sizes. Regards, W. ________________________________________ From: Oberon [oberon-bounces(a)lists.inf.ethz.ch] on behalf of Tomas Kral [thomas.kral(a)email.cz] Sent: Wednesday, September 20, 2017 12:56 PM To: paulreed(a)paddedcell.com; ETH Oberon and related systems Subject: Re: [Oberon] BMP; was "FPGA - Screen.Mod" Hi, Interesting discussion. I have started looking into `Picture.Mod' ETH Oberon code. In its simplest form Oberon pictures seem RLE encoded bitmaps with color tables. I am still learning it so perhaps not complete observation. EDIT I wonder if Oberon pictures are close in nature to those pictures found on early Apple Macintoshes? -- Tomas Kral <thomas.kral(a)email.cz> -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mail…

4 6