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

Oberon for a C++ user.
by Andreas Pirklbauer 21 Nov '16

21 Nov '16

Felix, below is the output (under Experimental Oberon) of a modified set of your modules A, B, and C (source code appended below). It nicely shows that C.Delete selects the "right" module B, i.e. either the "old B" (here called B*), or the "new B" (here called B). The type descriptors and the code of module B* (removed from module list) is still available in memory. All type tests automatically select the "right" type descriptor and the "old B" is only removed from memory when no more references from the remaining modules exist. Andreas COMMAND SEQUENCE (see below for source code of A, B, and C): B.Insert 1 ... insert elemt from old BSystem.ShowModules ... B is the old BSystem.Free B/f ... remove old B from module list, don't release memorzSystem.ShowModules ... B* is the old BB.Insert 2 ... new BSystem.ShowModules ... B* is the old B, B is the new BC.Delete 1 ... deletes the element created by the old BC.Delete 2 ... deletes the element created by the old BC.Init ... clears the data structure rooted in A.rootModules.Collect ... collects B* (no longer referenced)System.ShowModules ... module B* no longer in memory GENERATED OUTPUT: 1) B.Insert 1insert element from module B module descriptor at 000212C0 2) System.ShowModulesB 000212C0 000213D0 0A 00020F60 00020FDC 1System 0001CB80 0001D320 0... 3) System.Free B/fB unloading: removing from module list (references exist) 4) System.ShowModules*B 000212C0 000213D0 0 (removed from module list)A 00020F60 00020FDC 1System 0001CB80 0001D320 0... 5) B.Insert 2insert element from module B module descriptor at 00021800 6) System.ShowModulesB 00021800 00021910 0*B 000212C0 000213D0 0 (removed from module list)A 00020F60 00020FDC 2System 0001CB80 0001D320 0... 7) C.Delete 1type of t is T from module B* module descriptor at 000212C0 8) C.Delete 2type of t is T from module B module descriptor at 00021800 9) C.Init + Modules.Collect + System.ShowModulesB 00021800 00021910 0A 00020F60 00020FDC 2System 0001CB80 0001D320 0... ---------------------------------------------------------------------------------------------------- MODULE A; (*base module managing data structure of base type T*) TYPE T* = POINTER TO R; P* = PROCEDURE (t: T); R* = RECORD i*: INTEGER; close*: P; next: T END ; VAR root*: T; PROCEDURE Find*(i: INTEGER): T; VAR t: T; BEGIN t := root; WHILE (t # NIL) & (t.i # i) DO t := t.next END ; RETURN t END Find; PROCEDURE Insert*(t: T); VAR s: T; BEGIN s := Find(t.i); IF s = NIL THEN t.next := root; root := t END END Insert; PROCEDURE Delete*(i: INTEGER); VAR s, t: T; BEGIN t := root; s := t; WHILE (t # NIL) & (t.i # i) DO s := t; t := t.next END ; IF t # NIL THEN t.close(t); IF t = root THEN root := NIL ELSE s.next := t.next END END END Delete; PROCEDURE Init*; BEGIN root := NIL END Init; BEGIN InitEND A. -------------------------------------- MODULE B; (*client of A, defining extensions of A.T*) IMPORT A, Modules, Texts, Oberon; TYPE T* = POINTER TO R; R* = RECORD (A.R) j: INTEGER END; VAR M: Modules.Module; W: Texts.Writer; PROCEDURE Close*(t: A.T); VAR S: Texts.Scanner; BEGIN IF (t IS T) & (M # NIL) THEN Texts.WriteString(W, "type of t is T from module "); Texts.WriteString(W, M.name); Texts.WriteString(W, " module descriptor at "); Texts.WriteHex(W, ORD(M)); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END END Close; PROCEDURE Insert*; VAR S: Texts.Scanner; t: T; BEGIN Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(S); IF S.class = Texts.Int THEN NEW(t); t.i := S.i; t.close := Close; A.Insert(t); Texts.WriteString(W, "insert element from module "); Texts.WriteString(W, M.name); Texts.WriteString(W, " module descriptor at "); Texts.WriteHex(W, ORD(M)); Texts.WriteLn(W); Texts.Append(Oberon.Log, W.buf) END END Insert; PROCEDURE Init*; BEGIN END Init; BEGIN Texts.OpenWriter(W); M := Modules.root; WHILE (M # NIL) & (M.name # "B") DO M := M.next ENDEND B. -------------------------------------- ODULE C; (*tool module*) IMPORT A, Texts, Oberon; VAR W: Texts.Writer; PROCEDURE Delete*; VAR S: Texts.Scanner; BEGIN Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(S); IF S.class = Texts.Int THEN A.Delete(S.i) END END Delete; PROCEDURE Init*; BEGIN END Init; BEGIN Texts.OpenWriter(W)END C. ----------------

2 1

Oberon for a C++ user.
by Andreas Pirklbauer 18 Nov '16

18 Nov '16

Felix, that appears to be a solvable problem though. Two comments: (i) In order to keep "old" types and methods around, it suffices to keep older versions of a module block (containing both its type descriptors and its procedures) around in main memory, as long as there are references to them from the remaining part of the system. (ii) Even if an "old" version of a module passes a pointer around and that pointer suddenly ends up in a newer version (of potentially the same module), it is not really a problem (I think, but happy to be proven wrong) - so long as the "old" type descriptors and methods are still available in memory. Note that "old" methods will of course also access the "old" record and the "old" type descriptor for that record type, so there doesn't seem to be problem in principle. That of course needs to be taken with a grain of salt, just like one needs to take module interfaces with a grain of salt. If the newer version of a module doesn't actually change the module *interface* (i.e. meaning that clients do not need to be recompiled), but significantly changes the semantics of its implementation, there may be issues. All that is really guaranteed is that the module *interface* doesn't change - so even with modules, it is the programmer's responsibility that the *semantics* between multiple versions are "consistent". I'd say it's the same with records and methods. PS: I have implemented (i), but have not tested an example for (ii) yet. So if someone supplied a short test program for that in this forum, I'd be happy to test and then report on it. Andreas -------------------------------------------------------------------------------------------From: Felix Friedrich felix.friedrich at inf.ethz.ch Tue Sep 27 19:11:59 CEST 2016 > But this does not solve other problems coming from the possible > coexistence of an old and new version of a module. If the old module > survives, pointers could be passed around to new modules compromising > the type system. > I think that any kind of upcall, be it via procedure variables or via > object methods does not go well with module unloading. > Felix

3 3

Re (2): Tidyness of iteration.
by peter＠easthope.ca 17 Nov '16

17 Nov '16

From: =?utf-8?Q?J=C3=B6rg_Straube?= <joerg.straube(a)iaeth.ch> Date: Thu, 17 Nov 2016 18:51:16 +0100 > ... Oberon system has no "shutdown" command. Native O. has System.Quit. On most PCs it succeeds to power off. 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

2 1

Re (2): Tidyness of iteration.
by peter＠easthope.ca 17 Nov '16

17 Nov '16

From: Bob Walkden <bob(a)web-options.com> Date: Mon, 14 Nov 2016 19:35:14 +0000 > The read-ahead technique is very valuable in structurin= > g the software to match the structure of the input stream. Relying your authority. > If any of those are to be discarded, let it be LOOP, which encourages badly= > -structured code. The benefit or need for one entrance and one exit to a loop is understandable. I'm not convinced of the benefit from requiring the entrance and exit to be adjacent. Nevertheless, for forward compatibility I'm excluding LOOP. Thanks, ... 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

Tidyness of iteration.
by peter＠easthope.ca 17 Nov '16

17 Nov '16

(* Pre-2013. *) PROCEDURE LOOPiteration(); BEGIN Texts.OpenReader(R, t, 0); LOOP Texts.Read(R, ch); IF R.eot THEN EXIT ELSE (* Process ch *) END END END LOOPinteration. Project Oberon 2013, Page 5. "2. The LOOP and EXIT statements (repetitions with multiple exit points) have been discarded." (* Using REPEAT, R.eot must be checked twice in each iteration. *) PROCEDURE REPEATiteration(); BEGIN Texts.OpenReader(R, t, 0); REPEAT IF ~R.eot THEN Texts.Read(R, ch); (* Process ch *) END UNTIL R.eot END REPEATinteration. (* Using WHILE, Texts.Read is duplicated. *) PROCEDURE WHILEiteration(); BEGIN Texts.OpenReader(R, t, 0); Texts.Read(R, ch); WHILE ~R.eot (* Process ch *); Texts.Read(R, ch) END END WHILEinteration. Can the REPEAT example or the WHILE example be simplified further? (One must wonder about discarding REPEAT and WHILE and retaining LOOP with strictly one EXIT.) Thanks, ... 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

8 9

Oberon for a C++ user.
by Andreas Pirklbauer 16 Nov '16

16 Nov '16

Chris, Joerg:that is exactly the problem: assigning a procedure of a *client* module to a procedure variable of an *imported* module, and then unloading the client module - leaving the procedure variable in the imported module dangling.Assigning a procedure of a client module to a variable of an imported "base" module is in fact the standard way the Oberon system itself employs procedure variables to implement the viewer system in an object-oriented style.For example, module TextFrames (the client) installs a handler (procedure TextFrames.Handle) in the field F.handle of text frame F (see TextFrames.NewText and TextFrames.Open for the details), where the record field F.handle is declared as a procedure variable in the "base" module Viewers (see Viewers.ViewerDesc), which also manages the viewer data structure (see procedure Viewers.Open). Except that of course in the case of the Oberon system, the "client" module TextFrames *never* gets unloaded, so this is not a problem there. Thus, the burden is on the user to make sure that such modules never get unloaded.It is of course possible to implement a "procedure variable" counter - in analogy to the "module counter" employed in Oberon: each time an assignment to a procedure variable is made, the counter gets increased. But that would require changing the code generator compiler for assignments, and the module loader (Modules.Load) and unloader (Modules.Free). But I would refrain from introducing such complexity to the compiler and runtime system.Andreas Chris Burrows chris at cfbsoftware.com > Joerg, > > OK - you may well be onto something here but it is incomplete as it is. Something has to> import Square so that the module body is executed, or you need an exported procedure in> Square that is called from the OS. > > Note: there are a couple of semicolons missing and Init must be exported.> > Chris. > -----Original Message----- > From: Jörg Straube [mailto:joerg.straube at iaeth.ch] > Sent: Saturday, 1 October 2016 2:22 PM > To: chris at cfbsoftware.com; ETH Oberon and related systems > Subject: Re: [Oberon] Oberon for a C++ user. > > Chris > > Here a possble example that might cause issues: > > MODULE Figure; > TYPE > DrawProc = PROCEDURE; > Figure = POINTER TO FigureDesc; > FigureDesc = RECORD > next: Figure; > draw: DrawProc > END; > VAR list: Figure; > PROCEDURE Init(d: DrawProc) > VAR f: Figure; > BEGIN > NEW(f); f.next := list; list := f; > f.draw := d > END Init; > BEGIN list:= NIL END Figure. > > MODULE Square; > IMPORT Figure; > PROCEDURE DrawSquare; > BEGIN (* do what ever you > need to do to draw a square *) > END DrawSquare > BEGIN > Figure.Init(DrawSquare) > END Square. > > Now you could run Square and unload Square. The list in Figure has a > reference to unloaded code. > > J rg >

16 54

git
by Aubrey McIntosh 14 Nov '16

14 Nov '16

I have made small changes to HostFiles and wish to share them. I tried to post an encoded file to this list yesterday, but don't see any evidence that they were distributed. I thought I might try git and see how my luck ran. I have an account named a-mcintosh on github.com. Working on Linux, I have created and uploaded a RSA ssh key, and when I execute >ssh -T git(a)github.com I receive the response Hi a-mcintosh! You've successfully authenticated, but GitHub does not provide shell access. If I try >ssh -T a-mcintosh(a)github.com It asks me for the passphrases id_dsa (not id_rsa) and ultimately fails. If I try >git clone git@github.com:BlackBoxCenter/bbcb.git it tells me it cannot read from the remote repository. While I am posting, I also attached the encoded version of the patch and a test file. -- Aubrey McIntosh, Ph.D. 1502 Devon Circle Austin TX 78723 (512) 348-7401 ---- StdCoder.Decode ..,1 ..k.....dONb9RT7FTvMfv9VOMdvMFvLFuPb9RBPONPNbf9T9N5HeK qtMHT9NT7I19RFf9T9N51w1,... 1Ak....g....58FTuPE,5TWyqlKrqKKrGrtumdGLmGorCquU2hgnRAXDFTvMUn7FTvMf1G2sET fPdPMHfP9fQbf9hOO9vR7ONbvMoedhgrRiioedFWUkTeoxhmhgnpZHZijJC7ONbvM0.,.S.qL3 U.QklbcjRAktgdjZgZZh2hgnlsDor.kay4.qorGqmQiig76FUHZijJCbnWmqmqKWKqtcw7.,.L S0A,Qs7E.0E.cUGpmWLuOpoKqvCbHZiYpedhA704TeKKw.bHfEWUmL.6..D.PP0E.CcIhgsNHT 9N9ntQ8qorG4704D.CbB,708T1U.ktS.T.Lv,2U.2.Id,U00.bnUGLu8ro8quGrmCLWKqtE0E. kHU.EBU.U,U.I3tfj1.0E65.wMAU0KyB.,UgU.UO.,UzX.2Ue.E.07M7k44.3cUZT1E.sCE.c4 E.k.0.e0.,6j3.O.g1AUgU0o.sqs.3gwP.,6..EBU.U,2.I3,DX1.0E6,1.CE.M.7,,Mec.USU ,Q32U02.8E1E.a14kSE.mn.c.B.u.yz20JdyoVKIWKJdKIEWGmeHEGoo8rmCKuyatBZUwdgZgU 2ZgxhXJbUocdZhZRiiYdjRgVZijJiv2YiBghhgu2Y4BBcH1PPiHECLo8LmeHE8obyIaKoUuoIe HEO2cFH9P9vCPM0HcJ1eI,dQ9vQN76H99,dOp76HeHdOFDOFZuC,dNp76BOO66ZPNBfC,tJHfP 18QHf9FOER8FNOFr76BfP1PP9fCgigZhCBghtCGrw0rmeHEOoosQGpw0bv2YnJbUIcNZe3RbBA ,HsQFPM7vPj96p76BOR.2ZeAgghhUIakAaqgZlAahAanIZdgV7Ic3xc7pdBAV7AcHRe3JeI3Zg xB,t6,dHH8HN76Z7AHtC,NEbuI90RPMPHECGE8GFmGE8nMamRqk2IiZRiUIbx2YjRhv2Ya3Yug bUod7ZdvgV7AVLBdI3dUYhjRgu6HTvM11,7FTO1HM0HMEV9Q9fP798NvPuGs4KuWKK0Gr4qqYZ UIYWY3NvPghV3jAhgiZZUogiBAamRq.OKEenSYecBhnpcdZhZ3ZaphV,kYOIEOKECGEu2,7JFO FRO1Hk2akYcTb9OZ9N,tHZ86FdNRtQdPMdPN,ND,NNlvMNPRbPOhPNH76d8G9GEmqrCamhgn32 gcmJijJicQicBgmBhixg3JimBZv2YGhcIheGpdUod7ZdBAV7AV7gcARe33YgxhX,krEqyql2C2 YugbUogiYhjRgi.7tC,78J,..0GdKIeUahV7A,HMFR8FPM0H.in4a.HWn3hmFeW2CLEenSQicB A99N,NFNuI9mt0GRMNl1EEKIbGoRUD3iZph4BhgltmGEOKrEKIiZpgg2YmhgnBZvgV7kY68FdQ 9vQ,ND,dNmaCxhopcjhiiZg3JimBZUwdG32ZPNEs4KuWKbyKuO2.H76B76F7PTXmxhjZiAhgi3 Yy2YkAZUYe6l4k2SomGrdWqkG47OOZ98NvP599,dNkI.HsQUUMDOKr447tC,78..UBM0HM01Gs EIOKr44NFr44I2UigBEK.a0M0B1G3UcoA.M0HWa,22.aU7Fz.T0B1..M8UUYBIiZFRMFwBUd,Q 5.u2P.HkWm2m4.wB.V1,,Bf9.Y2...iHE.oAM0KIbg,AV3lRU7w7.C5UgcQO4Qid.akYcQ9HEq XjRhUYe6h6.66sQYAGGEKIbGIEIZV,.UBU3,MG..M1M0ROFj88BP8r76Bf9NXUIbx6PTnRqk2a U7ogiQirBgk3CZ96pNDqmMiHEaKEenS0GMin4a.HsFYet3iZ3ZiBghVoBjkN8rN1M0BnYuqoGL ea5F7Rn9Qa0M01uIUmhga3YX2YdphqBggBhYZZUAakwadQbBU7oAZPNB96pVmhgaRbUogiohVh B,dCvFnu4G0Bf9b1IbxsQr76Bf9d96pNDiom8LrKKquGeaqqKKIamRqk2M0BHqKKr0GRqXLBhi ,DONdfFH9PCpoermWGtKKnmWeBZBA,K2PU3lREqyqluGtERMFUmhgnB3cI98Jf0MFRGEyIqGqR gV0CyIhACoruKu8rrmKqKKtCLLCJuQcoJigZcZRiX3Ul1.UiQcjpho,YcZRiX3.5011.85...C LL.U2V.IS6.636.M00.,E06.,.1cUXDJcIf9P9fQbf9bWGhigFWE.4Te.sQRdIf9P9HWE.8z,U .kJl1kFF.0U10.bf9bWHZitZhZZcZRC,Mw.ELMSN12Umz.0U..2,I92U.E,,.RNEd1U2V.6,6. .UYU.AU.6.0..sFnQ.ytrM.M.6.,U0KyB.,..u,2.A.MEZPO19PmLT5.2UECU.U..61lbAUIJa FNZhhL8ssH2.Cor..626..U6U..HE.6wlgR0Oxad.az86Utj00LCjaUojC0gU.... 1Ak...OY....58FTuPE,5TWyqlKrqKKrGrtumdGLmGorCquU2hgnRAXDFTvMUn7FTvMf1G2sET fPdPMHfP9fQbf9hOO9vR7ONbvMoedhgrRiioedFWUkTeoxhmhgnpZHZijJC7ONbvM0.,.S.SN2 E.QklbcjRAktgdjZgZZh2hgnlsDor.kay4.qorGqmQiig76FUHZijJCbnWmqmqKWKqtcw7.,.9 z,A,gv5E.0E.cUGpmWLuOpoKqvCbHZiYpedhA704TeKKw.bHfEWUmL.6..D.Dw,6.,sUGpmWbB xhYhAbndMHT9NY6Mw.sQq2Y6cwB.0.XQ,w,Al3E.0E.ENV00.bnUGLu8ro8quGrmCLWKqtE0E. kNE.0.p.0.4.I3l6w1.0E65.wr2U.U6qq06Ibe.8ssHomOrVyqqqqkuKmKKtCLLCJuo8.,Mw7O Nh1.uGf.2UmT.6..E1U.M3M1szFd8Z7AXdBPNAXN9XtA,NMNPPPM0H86jPMR9R99N,7RT96NPN 1fQR96j9O19R,7RFPN,tQ9fQhPNZ96T76b9O19NTvR,7NHfQ9vMdvPaLE0rkGLo0mv4qtuGE0m Y0GuWqrKrnWKu0GuWqkGLEaKrOqr8rq4KuaqruKEqqoSKoGbWhgUIiZZipJiihgY3YWBjU2djR iopcdZhZRiiwdgZgi2YUAdo3Yohimphn3Yjhio3Yo3BYC9nvyKtiqouqn0Gma4.V1aqt0mkwiV Bjn3YmhgoVZd9,760Gs8rr0rrCrm0GuWqk.4qlGru4Kq0Gs4KusPB96d9O9HnaKqKKECLoyqum Km0GlKaVpiVBhgBgWZhZ3YdphUYicFqyql0Gv4Ktaqk8KqKaVpgohgm3YmhgoVUogmxhh3Yo3h ZtM19PNf9PM0PM0d8OHvQ,7QZvPDfQ1PP,7R9vQdvQ,7RFPMIgZ3hVpidxhmpZU2Y7ZC7vP9vQ ,NOd96dvRHvM9963PN5PMfvQ996dXmhgUAhn3YVphUggshgXhioBhjFs4Ku6RFPMAhnNRRPOXP R996BvPZ96196b9O1fQ99N,7QZPNhPOTPRb9Pn9699SHvQdPORvN,dNH9Pum4emIqkayIWKJaK IEGpmCLu0pkGLoin4akYqIcyIdGp4ak2OoomqmCLK0GYyqtEqUHZiYZdjxgvgV7AVBAV1xdCRe IhV7AVAxhX3aUgbUIYHZiYxZBxhYJYv2YCBghhgk2Yx2218QHf9T9N5f6rN1HM0NWl2Yx2YWYe ZRCTNH.MA,ND,Fc4KuoZjZgXVBAVEJeDRc3ZcJJe33Y2xheQbBA,hOEZO1HM0H6PTvM,dC,dFH 9PoZAxhXBgoxhmRbBA,HcNX79,dNZ76p76B0ocdZBrN1HcE9uFHeHPM0H6PkS0GXaKqQC7POZf 9d8OHvQF76NuP59AamRqk2aEn2YugbU..T8P798,7PTvMN76ROMPHMmGEGJdKpW0mIin4MGB86 BPAvdHH8H,7JFOFR86b8R71RtIdfQHfPD98,d6BPO2Yixho3Yj3iZphZZgu2YW2Yd2Y3ZdHhcU QeoZA..Uj3iZ,AZUgcCZcvgV7AVHZiYZ7.Eqyac2djRCktY744aGL0rkGbY2Yf2YWwZW2Yf2YC BA2YdQ5.6HRvCPM0qU7YB.UYVI,.UaJaUIbx22.sH.m0EK..HeFIaxod7Z7..b0EFUUoB.UU.. ...T1Ud.kd..6P23.CbAlk....00.EagV7gcCZcUYcjRbBAVBgcCZ6dONbHcELqk48EEGZn,Yc jhV0CyIhACoruKu8rrmKqKKtCLLCZYRcoJigZcZRiX3Ulb8..umVyKrG5EWKqtCK.Q6AA.cQ.. .sQR,.G20EtH.0.G,0.aU.2U.2..AU0CyIVGhighgmRiiQ88pum470,Mwd0UnpZGhighA70,cw 5.,6.QJw.QI2U.sU.ktumdsIdPSNPN7ONbvM,Mw.ELMSN12Umz.,6.0.E2Eh2.0.32.oZ,ZC.G 259.G.0..670U.AU.U.UkAqO,,63Fc.8rrM.M.6.,U0KyB.,..e,2.A.c8.2UECU.U..61lbAU wApPt0lLU8ssHorMP91Cor..c2E..U6U.k.A,6EruQAnW8Utj00My7kx8O0MCT7Uw,... --- end of encoding ---

1 0

Re (2): Tidyness of iteration.
by peter＠easthope.ca 14 Nov '16

14 Nov '16

From: Alexander Ilin <ajsoft(a)yandex.ru> Date: Mon, 14 Nov 2016 21:58:19 +0300 > The REPEATiteration should be as follows: > ... > To simplify the code, ... Thanks Alexander. I'm terribly rusty, ... 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

Re: [Oberon] Availability of OberonStation
by Chris Burrows 14 Nov '16

14 Nov '16

> > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Ken Boak > Sent: Monday, 18 January 2016 7:29 PM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] Availability of OberonStation > > 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? > It is likely that I have had the most experience on the Xilinx Artix-7 seeing as I ported our 'embedded' subset of ProjectOberon to the Arty board ;-) I agree with Walter. Oberon-07 is an ideal language for developing embedded applications. I'm not sure what you mean by 'preferred platform'. The Arty (Artix-7) and the Pippistrello (Spartan-6 LX45) development boards are the only two I have found so far that have sufficient BRAM to run embedded ProjectOberon without external SRAM. Saanlima's Pippistrello is about $50 more than the Arty. However, the Pippistrello does have a built-in SD Card socket and can also be used as an ProjectOberon Workstation development system with Saanlima's optional Oberon SRAM 'Wing'. There are many simpler FPGA boards available but all the ones I have found use less-capable FPGA devices with insufficient BRAM. The Arty and the Pippistrello have more features than are needed for embedded Oberon applications like those on the ARM Cortex-M3/M4 boards that we support. However, I guess that doesn't matter for those who are designing their own boards and just want an off-the-shelf reference system to use for prototyping / proof of concept. If on the other hand you want to run the complete Project Oberon 'workstation' system with VGA / HDMI, keyboard and mouse. You will need a board with external SRAM like the OberonStation. An Arty would not be suitable for this purpose. > 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? > There used to be an clear distinction between the simple 8-bit microcontroller at one end of the spectrum and the 64-bit PC at the other. In recent years the two have started to converge. The embedded systems are becoming more powerful; the PCs are becoming smaller and less power-hungry - the distinction is blurring. The STM32F7 Discovery Platform seems to me to be more a miniature PC than a high-power embedded system. While we remain focused on supporting embedded systems we are unlikely to be targeting it, Regards, Chris Chris Burrows CFB Software http://www.astrobe.com/RISC5

34 147

Oberon for a C++ user.
by Andreas Pirklbauer 13 Nov '16

13 Nov '16

Sorry, typo in the links. Here are the correct links: https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Docume… https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Source… https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Source… https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Source… --------------------------------------Srinivas, The way the problem was mitigated is by checking references from other modules before unloading, and simply keeping the module in memory, as long as there are references to the unloaded module in the remaining part of the system. It is described in section 5 of this document (forget the rest, just skip to section 5): https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Docume… Or, if you want, you can just check out the source code that implements all this here: https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Source… (adds procedure CheckRef) https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Source… (adds procedure CheckRef) https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Source… (adds procedure variable offsets to descriptors) Note that, as outlined in the PDF document cited above, in order for this to work, the type descriptor (and therefore also the Oberon object file format) and the descriptor for global data (e.g. global procedure variables) had to be extended with a list of *procedure variable offsets* - an idea that was originally implemented in MacOberon around 1990 and which I (essentially) adopted but also extended with a mechanism to *automatically* collect no longer referenced modules. But the changes needed to implement all that were absolutely minimal: just a few minor adaptations and only 2 (!) additional lines in the compiler (see procedures ORG.FindFlds, ORG.BuildTD, ORG.Nofrefs, ORG.FindRefs and ORG.Close) and only 3 (!) additional lines to module loader (see procedure Modules.Load). That's it! In total, the implementation cost for all of the above was about 50-70 lines (depending on how one counts). It completely does away with the need for finalization - which I always viewed with great suspicion (too complex, too many issues, seems like tinkering with the symptoms rather than with the root cause). Andreas ------------------------------------------------------------------------> Srinivas Nayak sinu.nayak2001 at gmail.com > Sat Nov 12 08:39:10 CET 2016 > Yes, Andreas wrote... > "The case of inheritance (type extension in Oberon) is now fully covered in the latest version of safe module unloading in Experimental Oberon. ..." > Can anybody please summarize how he mitigated the problem?> I was thinking, Finalization can help us here.> But, interested to know the approach taken by Andreas to barring such deviousness. > With thanks and best regards, > Yours sincerely,> Srinivas Nayak

1 0