February 2013 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] WITH removal in Oberon-07
by Paul Reed 13 Mar '14

13 Mar '14

> Date: Thu, 21 Feb 2013 22:52:05 +0100 > From: "Frans-Pieter Vonck" <fp(a)vonck.nl> > Subject: Re: [Oberon] WITH removal in Oberon-07 Hi Frans-Pieter, > i watched your presentation at MEDIA OberonDay2011. > Am I right that you made an ARM emulator first. No. The virtual machine is RISC, as in Prof. Wirth's Compiler Construction book (published in English in 1996 and updated on his home page http://www.inf.ethz.ch/personal/wirth/) > And did you use this emulator to ran Oberon System07 on top of it? It's not called System07, but it's basically the original system in the Project Oberon book, modified to compile under Oberon-07, run inside a RISC virtual machine executing on a bare-metal PC. > You showed a Spartan FPGA. I scanned through the Verilog ARM code. But > that seems a to big leap to me. I don't know what Verilog code you are referring to here. The Spartan-3 board only has 500K gates and 1MB of external static RAM, so it's much smaller and simpler than a typical ARM system. But ideal for Oberon. > Do you think it is possible to run [The Oberon System, compiled in Oberon-07] on an of the shelf > board with a Cortex M3 processor? I don't see why not, but most small ARM boards don't have a video framebuffer. The Raspberry Pi does, but it's a complicated board, as I've said before. The Oberon inner core (Kernel, FileDir, Files, Modules) and even the text system do not actually require a framebuffer display, so you could build a hybrid system. Using a simple FPGA board allows us to avoid the vast and irrelevant complexity inherent with most ARM System-on-Chip (SoC) systems; but since field-programmable gate arrays are so flexible, they will never be as cheap or as fast as a dedicated ARM. That's life. :) HTH Paul

4 5

Can ETHO be ported to ARM?
by eas lab 13 Jan '14

13 Jan '14

No, not the <language>, but the unique interface of S3/V4. What matters is the human-interface. That's what determines your productivety [maximum gain for minimum pain]. Not needing to switch between awkward F-keys and the screen, and having easy access to multiple text-files together, and each text-view having <what the bottle does, written on the bottle, instead of in the filing cabinet>. Porting ETHO to linux [both S3 & V4] was a killer app:. you get the Inet capability of *nix together with the superior human-interface of ETHO, plus you can view *pdf, LaTex..etc. on the same screen. For tricky problems, needing simultaneous views of: email/s, USEnet/s, your test-logs EHO is unbeaten, especially with the text colouring facilities, which help extract the meaning of difficult explanations. Because opeing/closing a new ETHO-for-linux takes a second, it's viable to have several copies running in the various dirs, which are handling current problems. Real life doesn't allow fixing one problem at a time. Can those of us who want to escape the WinTel monopoly, hope to use ARM based CPUs with an ETHO-like interface, by a porting of the existing/proven code? == Chris Glur. PS. LNO's inability to easily navigate the dir-tree, limits its utility.

3 7

Locate/identify Char at cursor ?
by eas lab 28 Feb '13

28 Feb '13

Sorry that I've lost the mail-subject-thread. In this failed-state-location, my ISP has forced me to use gmail, which can only fetch ONE mail per expensive login session. Paul Reed wrote: > ] TextFrames.Edit is in turn called from the TextFrames message handler > ] TextFrames.Handle(). > ---- > > OK, but I still can't see how to get the char at the CURSOR. > > Is this correct:-- >> Oberon.GetSelection(text, beg, end, time); > > char := <Scan 'text' from 'beg'> >> would get the char of mouse: RM. > > > > But the RECORD in Oberon.Mod which holds 'text' and 'beg' > > has been Set by a process, which runs in the background, > > which is not published. > > It is! :) AFAIK Display.Mod sets the RECORD which Oberon.Mod reads. Are you saying that the code of Display.Mod IS published? AFAIK Display.Mod does the difficult job of finding the index in the text-stream of 'beg' and 'end', for possible later GetSelection. > The current (latest) selection is a conceptually-global > property of the system, which is obtained by Oberon.Mod using a > SelectionMsg broadcast in GetSelection(). Each viewer (e.g. a TextViewer) > with a selection will respond to this message in its handler and update > the selection in the message (as long as the selection time is later than > any selection already there). See TextFrames.GetSelection(). Yes, but TextFrames.GetSelection() like Oberon.GetSelection wouldn't *set* the RECORD. > > I want the CURSOR-chars, to be returned, for various keys, like they > > can be, for mouse: RM, via < Scan(GetSelected(args)) >. > > There's a convention for many Oberon commands that in fact, only the > beginning of the text need be selected. A simple example to look at would > be Edit.Locate, at the end of Chapter 5 of Project Oberon, page 174 (or > page 139 of the PDF), which: I'm not yet fluent in Chapter*.Text so I don't want to take other medicine. > 1. finds the marked (starred) viewer, typically a source file being compiled > 2. gets the current selection (usually in another viewer, the log viewer, > a pos of a compile error) > 3. opens a scanner S at the start of the current selection (after this, > what text is *actually* selected is ignored) > 4. scans until it finds an integer (a position), returned in S.i <--*? > 5. shows that position in the marked viewer, by repositioning the Text > frame (found in 1.) to 200 characters beforehand > 6. puts the focus and the caret in the marked viewer at position S.i Without looking at the code [yet], I'll confidentially say this is the reverse of my problem. So it's also interesting. The compiler KNOWS the index of the char/token and needs to position the cursor/caret there. In a non-ETHO system it could merely step the cursor to char N. The concept of X,Y coordinates are not even needed. > > The difficult part, is that the <text stream viewed on the screen/display> > > consists of different sized rectangles. > > Yes, and each viewer has the choice to lay out text however it wants > (there's text in the graphics editor too, for example). > > > It seems to me that there can be no 'mapping' from X,Y to the > > correspondingly > > displayed-char. Because eg. if you change the font-size of charN, then the > > X,Y of char (n + i) changes. > > Quite. Hence the message broadcast, so that each viewer can interpret its > own contents. I've found the code to trace the *gadget* at coordinated x,y. But, are you saying that each char is an object/gadget ?! > > I'm not getting near a solution. > > Hopefully the above helps a bit. If you really want the text at the > *mouse* cursor, you could add a new message type and add a handler for > that message type to each type of window which displays text. Or perhaps > at least add a new message id to ControlMsg. In later systems YMMV. No need to add a new message type. I only want a subset of what's already done, in the 2 cases: 1. on the systems without a MidMouse, <Ctrl> can be used. This reads the char at the cursor [plus those before and after, up to white-char] 2. RM selects a char. I.e. beg=end are set in the RECORD. So if RM can set the RECORD, then my privileged-key events can too. Eg. <Ctrl> is promoted to a priveleged-key -- as in A2 too. > But you'd be changing the convention on how the system is used, since the > selection is the established way to get things like this done. And in any > case I'm not sure what you actually want to do! :) Well yes, I'm drastically extending the usage: you just roam around with a keyless mouse, and pick off various keys when the mouse is over various chars/tokens. OK, I've realised that since you can edit any ascii-char to become a 'multiply-sized bitmap-image' eg. a bird, so perhps each char IS a gadget. Then I could try the published code which <finds the gadget at cursor position: x,y>. But now I remember, that I had a brain-dump after I though I was getting there while testing modified Hex.Mod [V4 has similar code]. Don't bother to study this, but just note that it's a function, with display-coordinates IN and CharIndexInFrame OUT. ------ I remember that my tests showed the x-coordinate of where the cursor was when invoking <Do.Test>. The problem was that I didn't know how to get from <MarkedDisplay> to the corresponding Frame, which PROC LocateChar needs. When I asked on this forum, I was told to 'buy the book'. WDYS ? Thanks, == Chris Glur. ==> NO/Hex.Mod HOW2 <LocateChar in Frame @ x,y=cursor> Location* = RECORD org*, pos*: LONGINT; <-- output: position of char in text-stream. x*, y*, dx*, dy*: INTEGER; <-- input args: cursor coordinates line: TextLine END ; -------- PROCEDURE LocateChar* (F: Frame; x, y: INTEGER; VAR loc: Location); VAR t: TextLine; pat: Display.Pattern; i: LONGINT; n, w, lm, pw, tw, ddx, cn, dx, xc, yc, wc, hc: INTEGER; nextCh: C P: Parc; pbeg: LONGINT; BEGIN LocateLine(F, y, loc); t := loc.line; w := x - F.X; AdjustMetrics(F, t, pw, tw, ddx, cn, P, pbeg); lm := F.left + SHORT(P.left DIV Unit); IF (t # F.trailer) & (w > pw) THEN Texts.OpenReader(R, F.text, t.org); i := 0; n := 0; dx := 0; nextCh := 0X; WHILE (i < t.len) & (pw + dx < w) DO (* i = pos after nextCh; dx = width of nextCh; pw = line width without nextCh *) Texts.Read(R, nextCh); INC(i); INC(pw, dx); IF nextCh <= " " THEN GetSpecial(R, nextCh, P, F, n, cn, ddx, pw - lm, dx, xc, yc, wc, hc) ELSE Display.GetChar(R.fnt.raster, nextCh, dx, xc, yc, wc, hc, pat) END END ; IF pw + dx < w THEN INC(i); INC(pw, dx); R.elem := NIL END ; INC(loc.pos, i - 1); loc.x := F.X + pw; IF i < t.len THEN loc.dx := dx; loc.dy := R.fnt.height * R.voff DIV 64 ELSE loc.dx := 4 END ELSE loc.dx := 4; R.elem := NIL END END LocateChar; ----------------------- !! Oh !! It's interesting, that it does LocateLine(F, y, loc) FIRST, since we know that chars of different height on the same line, align on a common base, which is related to 'y'. Then it just needs to step 'x', once the y-coordinate has given the line. ---- BTW: Chapter5.Text => "Locating a gadget in the display space....There are essentially three ways of locating gadgets: by position, by state (the current gadget selection), or by name. Given a certain X, Y position on the display, we can ask exactly what gadget is located at that position. " OK, but the chars in a Document are normally NOT gadgets.

1 0

Massive power increase, from ETHO riding on *unix
by eas lab 27 Feb '13

27 Feb '13

Here's another simple little example: where/what's that file you were working on yesterday? So you need the files of the relevant directory to be listed in recentcy-order. ETHO doesn't do that. Years ago I investigated transforming the output of System.Directory *\d but the unfortunate choice of ETHO's time-format: InitLog 07.08.2012 12:07:07 610 InitLog.Bak 07.08.2012 12:06:23 546 means you'd have to re-format: '07.08.2012' to '2012.08.07' to be able to use ETHO's `sort` facility, and that's after using RX to re-order the 4 fields to: 2012.08.07 12:07:07 InitLog 610 Don't worry, of course *nix gives you <show the most recent 10 [say] files-names, ordered in recentcy>. Just say: System.Execute <doIt>. The actual *nix syntax is: `System.Execute ls -t | head` but the syntax is not important. You just have the instruction in your tool-box. And if you need to see the sizes too, or any of the other zillion options, *nix has got them all. Just add them to your tool-box as you evolve and test them. With ETHO on top of *nix, you've got the superior HCI of ETHO with the FREE underlying support of *nix. Not to mention the full range of device drivers [How's ETHO/A2 for USBstik] and inet. I can't get gmail [non-http] with ETHO yet. Can A2 do it? It needs TLS. == Chris Glur. PS. did I forget to mention, again, this applies to ETH Oberon (2.4.3) for Linux x86 -------- IMO the BAD format of Day.Month.Year should be fixed; but NOT to US format. We need to be prepared to fix errors, like the "_" in the default font, and not work-around them, contunually. OK! I See the "_" IS fixed here in LEO. And here's a little diversion related to the topic: I want to see the *.Scn.Fnt of this text that I'm writing now. Hex.Open ETHObjcts shows it, but won't allow me to copy-paste it here. So let's see: System.Execute head ETHObjcts OK, `head` give the 1st 10 lines. But ETHO's EOL does NOT qualify as a *nix EOL. So it writes the whole ETHObjcts in a text frame, all as ONE-line -- wrapped. And I CAN cut: ...OB2ULiNE.Scn.Fnt3Oberon10.Scn.Fnt,UOberon14b.Scn.Fnt which tells about the fonts used in this frame. Let's try another little trick: System.Execute cat ETHObjcts | strings | fold `strings` means show only ascii chars -- I think `fold` means break the line at word-boundry @ linelen < X Which shows me the file of THIS text that I'm now writing, and would allow the infinite trick-set that *nix can do to it.

1 0

Re: [Oberon] Arduino (was: objects and jewels)
by Chris Burrows 25 Feb '13

25 Feb '13

> -----Original Message----- > From: Jörg Straube [mailto:joerg.straube@iaeth.ch] > Sent: Monday, 25 February 2013 9:15 PM > To: <fp(a)vonck.nl>; ETH Oberon and related systems > Cc: ETH Oberon and related systems > Subject: Re: [Oberon] [Fwd: RE: objects and jewels] > > If you want to use Oberon as programming environment for Arduino, you > either need an Oberon cross-compiler to AVR RISC code (so the Oberon > program runs natively on the Arduino) or you could use the Firmata > protocol to control the Arduino. There is a third possible option for Arduino and Oberon programming. If the prime reason for choosing the Arduino is the ready availability of 'shields' (i.e. hardware add-ons) you can use an Arduino pin-compatible development board that has an ARM7 or Cortex-M3 microcontroller. E.g. the boards from Coridium: "Designed on the 32-bit ARM, the companys three families provide full IEEE 754 floating-point support and offer the largest available selection of Arduino Shield-compatible microcontrollers." We provide source code examples and technical support for the use of Astrobe for writing software in Oberon to target the Coridium boards that are listed here: http://www.astrobe.com/boards.htm Regards, Chris -- Chris Burrows CFB Software http://www.astrobe.com

1 0

[Fwd: RE: objects and jewels]
by Frans-Pieter Vonck 25 Feb '13

25 Feb '13

thanks Jörg for your hint to the instantiation init aLed.init := Init; I missed that. > Remark: I would only pass a Led pointer to the procedure Init (either by > declaring Led as POINTER or declaring led as VAR parameter) but this has > nothing to do with the asked topic "procedure variables". Yes yo'ure right, I try out how it works out when I create a driver MODULE LED that is imported by BlinkaLed. Greets, Frans-Pieter > Hi FP > > Your example code could look like this: > > MODULE ExampleProcType; > > TYPE > Led = RECORD > pin, port: INTEGER; > init: PROCEDURE(led: Led; Pin, Port: INTEGER) > END; > VAR > aLed: Led; > > PROCEDURE Init(led: Led; Pin, Port: INTEGER); > BEGIN > (*some code *) > END Init; > > BEGIN > aLed.init := Init; > aLed.init(aLed, 1, 5); > END ExampleProcType. > > > Remark: I would only pass a Led pointer to the procedure Init (either by > declaring Led as POINTER or declaring led as VAR parameter) but this has > nothing to do with the asked topic "procedure variables". > > Jörg > > -----Original Message----- > From: Frans-Pieter Vonck [mailto:fp@vonck.nl] > Sent: Dienstag, 19. Februar 2013 16:47 > To: Jörg > Subject: RE: [Oberon] objects and jewels > > Thanks Jorg, > this was the interview I remembered. However the interview mentions > extention of record types, but not the introduction of procedure types. > > I could not find simple examples of using procedure types, probably > because of the introduction of type bound procedures with Oberon-2. > > The original oberon system uses procedure types a lot as part of the > message concept. I wonder if the concept of message handling together with > the task loop can be transfered to microcontrollers. > Procedure Types are supported in Oberon07. > > To start simple, I was thinking of something like this > MODULE ExampleProcType; > > TYPE > Led = RECORD > pin, port : INTEGER; > init : PROCEDURE(led : Led; Pin,Port:INTEGER) > END; > VAR aLed : Led; > > PROCEDURE init (led: Led; Pin,Port: INTEGER); > (*some code *) > END init; > > BEGIN > aLed.init(aLed,1,5) > END ExampleProcType. > > This compiles in Astrobe. But i do not know what is happening here. > For instance, if I change the name of the PROCEDURE init to PROCEDURE onit > the module still compiles. So it seems that the procedure type init not > binds with the procedure init. > > Could someone explain me a little more about procedure types? > > Greets, > > Frans-Pieter > >> Frans-Pieter >> >>> I remember reading an argument of Wirth against object orientation. >> However >>> the object way, "myservo.atttach(9)" seems more elegant than the >>> modular >>> way. Did I overlook something? >> >> You might consider this syntax as more elegant, but basically >> object-oriented programming (OOP) does not add one single new concept to >> traditional procedural programming (PP). Read Wirth's argumentation >> below. >> >> Whether you write in OOP "myservo.attach(9)" or write in PP >> "SERVO.Attach(myservo, 9)" is the same. >> >> br >> Jörg >> >> Wirth: >> Many people tend to look at programming styles and languages like >> religions: if you belong to one, you cannot belong to others. But this >> analogy is another fallacy. It is maintained for commercial reasons >> only. >> Object-oriented programming (OOP) solidly rests on the principles and >> concepts of traditional procedural programming (PP). OOP has not added a >> single novel concept, but it emphasizes two concepts much more strongly >> that >> was done with procedural programming. The fist such concept is that of >> the >> procedure bound to a composite variable called object. (The binding of >> the >> procedure is the justification for it being called a method). The means >> for >> this binding is the procedure variable (or record field), available in >> languages since the mid 1970s. The second concept is that of >> constructing >> a >> new data type (called subclass) by extending a given type (the >> superclass). >> >> It is worthwhile to note that along with the OOP paradigm came an >> entirely new terminology with the purpose of mystifying the roots of >> OOP. >> Thus, whereas you used to be able to activate a procedure by calling it, >> one >> now sends a message to the method. A new type is no longer built by >> extending a given type, but by defining a subclass which inherits its >> superclass. An interesting phenomenon is that many people learned for >> the >> first time about the important notions of data type, of encapsulation, >> and >> (perhaps) of information hiding when introduced to OOP. This alone would >> have made the introduction to OOP worthwhile, even if one didnt >> actually >> make use of its essence later on. >> >> Nevertheless, I consider OOP as an aspect of programming in the >> large; >> that is, as an aspect that logically follows programming in the small >> and >> requires sound knowledge of procedural programming. Static >> modularization >> is >> the first step towards OOP. It is much easier to understand and master >> than >> full OOP, its sufficient in most cases for writing good software, and >> is >> sadly neglected in most common languages (with the exception of Ada). >> >> In a way, OOP falls short of its promises. Our ultimate goal is >> extensible programming (EP). By this, we mean the construction of >> hierarchies of modules, each module adding new functionality to the >> system. >> EP implies that the addition of a module is possible without any change >> in >> the existing modules. They need not even be recompiled. New modules not >> only >> add new procedures, but more importantly also new (extended) data >> types. >> We have demonstrated the practicality and economy of this approach with >> the >> design of the Oberon System. >> >> > > >

7 13

Re: [Oberon] Oberon Digest, Vol 106, Issue 21
by Søren Renner 25 Feb '13

25 Feb '13

> > *This is also true for the so much laureated Lego Next. Java on top of C++ > libraries. A very expensive dialectical nightmare. One rarely encounters two consecutive sentences so stylistically perfect. I wish I had written that.

1 0

Re: [Oberon] objects and jewels
by Chris Burrows 25 Feb '13

25 Feb '13

> -----Original Message----- > From: Frans-Pieter Vonck [mailto:fp@vonck.nl] > Sent: Monday, 25 February 2013 7:11 AM > To: ETH Oberon and related systems > Subject: Re: [Oberon] [Fwd: RE: objects and jewels] > > The information about the led object can be recorded in it's attributes, > however, it seems to me that in the microcontroller world this creates a > lot of redundant information. The state of the pins are all registered in > the microcontroller registers. Set and get methods can be directed > directly to the registers and not to the objects. This is my argument why > an object orientation with dynamic types is not necessary for micro- > controllers. > Maybe you have a better explanation and yes I've read Steps Beyond, > Chapter 14 Oberon-2. > I agree with you. The real usefulness of object-oriented programming techniques is when you need to make complex tasks simple - not to make simple tasks complex. For a better explanation read Hanspeter Mössenböck's book "Object-Oriented Programming in Oberon-2". The foreword sums it up nicely: "For, not all programs are automatically improved by merely recasting them in an object-oriented style. On the contrary, the new method can only be applied sensibly where complex data structures are present. It would be unwise to prematurely discard the conventional view." You can download a copy from: ftp.ssw.uni-linz.ac.at/Research/Books/Oberon2.pdf or purchase a new real paperback copy from: http://www.amazon.com/gp/offer-listing/3540600620/ref=dp_olp_new?ie=UTF8&con dition=new Regards, Chris -- Chris Burrows CFB Software Astrobe: Program ARM7 and Cortex-M3 microcontrollers in Oberon http://www.astrobe.com

1 0

Oberon.Call
by Paul Reed 24 Feb '13

24 Feb '13

Hi Chris, > Date: Mon, 28 Jan 2013 10:44:46 +0200 > From: eas lab <lab.eas(a)gmail.com> > Subject: [Oberon] HOW2 get Token at cursor? > Getting the tokens at the cursor is exactly what must happen with: > Oberon.Call(S.s, Oberon.Par, FALSE, res); ... > But the <TextScanner> does NOT read the cursor co-ordinates; Have a look at TextFrames.Call(), which calls Oberon.Call() after setting up the parameters to the command. TextFrames.Call() is called from TextFrames.Edit() when tracking the mouse. TextFrames.Edit is in turn called from the TextFrames message handler TextFrames.Handle(). HTH Paul

2 2

Re: [Oberon] WITH removal in Oberon-07
by Paul Reed 21 Feb '13

21 Feb '13

> Date: Tue, 19 Feb 2013 22:13:01 +0100 > From: "Frans-Pieter Vonck" <fp(a)vonck.nl> > Subject: Re: [Oberon] [Fwd: RE: objects and jewels] Hi Frans-Pieter, > - WITH is not part of the Oberon07 language so that limits the use of > procedure types. This implies that the message model of the Oberon System > is not possible in Oberon07. [extracted from screeds of irrelevant repetitions of emails in the list digest!] Respectfully, that's not true. Although the regional type-guard (WITH) has been abolished in Oberon-07, normal type-guards are certainly still provided. I have implemented the Oberon System in Oberon-07 (e.g. for Oberon Day 2011) and the number of changes to cope with the absence of WITH were small. I feel the code is actually more readable without WITH. Looking at the examples either side of the section 11.2.3 heading on page 197 of Programming in Oberon (Reiser & Wirth 1992): IF p1 IS P2 THEN y2 := p1(P2)^; d2 := p1(P2).b END I find more concise than IF p1 IS P2 THEN WITH p1: P2 DO y2 := p1^; d2 := p1.b END END and I also don't like the latter because it changes p1 from the type of its declaration. It's always possible to declare a new variable with the guarded type if the number of guards appears to be getting excessive, but ceteris paribus I like the code to say what it's actually doing. Cheers, Paul

2 2