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

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

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 (2): Amiga OS and Oberon
by peasthope＠shaw.ca 03 Feb '13

03 Feb '13

From: eas lab <lab.eas(a)gmail.com> Date: Thu, 31 Jan 2013 11:01:46 +0200 > ... where the ISP's can no longer handle ETHO-based email and I'm forced > to use inefficient gmail. A Linux router can connect with almost any protocol an ISP will use. The router will also connect to Oberon. Problem solved. Really the solution is more general. It offers many services in addition to email connectivity. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

4 6

RaspberryPi port?
by Douglas G. Danforth 02 Feb '13

02 Feb '13

Folks, Recently someone mentioned they were porting a version of Oberon to the RasberryPi. I don't remember who and would be interested in finding out the status of that port. -Doug Danforth

4 4

Re: [Oberon] Amiga OS and Oberon
by Treutwein Bernhard 31 Jan '13

31 Jan '13

> >This book describes V4: (HCI/GUI, garbage collection, version checking >while >loading modules...) >http://www.amazon.com/The-Oberon-System-Programmers-Manual/dp/0201544229 > Are you sure? I thought it describes V1 and/or V2. Then there came the "Spirit of Oberon" later renamed to S3, which introduced objects and libraries and an answer was V4 showing that there is no need to change the kernel (see also Appendix "Ten Years After" to the online edition of Project Oberon (p. 434 of http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf) But please correct me, I was never member of the group ... -- Bernhard

2 1

HOW2 get Token at cursor?
by eas lab 31 Jan '13

31 Jan '13

Please follow and correct my exposed reasoning: Getting the tokens at the cursor is exactly what must happen with: Oberon.Call(S.s, Oberon.Par, FALSE, res); which is repeated often in severa; *.Mod Let's morph this to Oberon.CaT(TokenAtCursor, ParList, New, Res); Using 3 colours, which you can't see in the mail, shows, eg : Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(S); COPY(S.s, cmd); Oberon.Call(cmd, Oberon.Par, FALSE, res) Which shows the <signalFlow> as: cmd <- S.s <- ?? Texts.* But the <TextScanner> does NOT read the cursor co-ordinates; which are exported from Oberon.* via TYPE Cursor* = RECORD marker*: Marker; (** Cursor marker. *) on*: BOOLEAN; (** Is cursor shown? *) X*, Y*: INTEGER (** Absolute cursor position. *) END; So is Cursor.X continually updated, if the mouse moves? But <Variable:Text> is a list of chars and <Cursor Position> is an OrderedPair. So, TextScanner only sees a list of chars. And It's not clear where the pixelGeometry/OrderedPair maps to the corresponding char, except at the very low-level of the display-driver. Actually I don't want the token at the cursor, which I've tried to trace above. I want the more primitive CharAtCursor. NB. distinguish between cursor and caret. I'd like to see: WHILE CharAtCursorChanges(Ch) DO Out.Char(Ch);Out.Ln() END; or better: REPEAT Ch:=CharAtCursorChanges; Out.Char(Ch);Out.Ln() UNTIL Ch="Q" So the ChangingCharAtTheCursor would scroll in the System.Log Please advise. == Chris Glur. PS. Since Texts does not IMPORT Oberon, it can't know Oberon.Cursor.X PSS. Perhaps more is seem from:- Arrow*, Star*: Marker; (** Normal Oberon arrow, and the star marker. *) No, because the star-marker is not concerned with displayedChars.

8 9

Addendum: Amiga OS
by Treutwein Bernhard 30 Jan '13

30 Jan '13

AmigaOS was based on TripOS, which was developed at Cambridge, UK (see: http://www.amigahistory.co.uk/tripos.html and http://en.wikipedia.org/wiki/TRIPOS) Regards -- Bernhard

1 0

#oberon on irc.freenode.net
by Michal Wallace 17 Jan '13

17 Jan '13

Hey all, A few of us have started hanging out in the #oberon channel on irc.freenode.net , and we wanted to invite you guys to come join us. irc://irc.freenode.org/oberon -Michal ( tangentstorm )

1 0

ETHO work flow tools.
by eas lab 14 Jan '13

14 Jan '13

It's quiet likely that others have discovered this little quirk, without mentioning it: a serious flaw in the work-flow model of ETHO. Analysing why A2 doesn't work for me, led to recognising a similar flaw in ETHO. My ancestors wrote on the cave walls. Later in Babylon they wrote on slate & clay-tables. And then they had the mess of a zillion papers and chaos. Like me. Until a saviour arrived and suggested that: make all papers the same size [compatible]; number/ID and pysically order them meaningfully; bind them together [with a hinge]; add a table-of-contents, to a unique, heuristically chosen location; and we'll call it a "BOOK". Novels have a linear structure, and could be contained in a scroll, because they don't need RAM. "Knowledge" OTOH, is heirarchically/tree-like structured, and needs RAM; which a "book" achieves. =========== ETHO S3 largely achieves the superior discipline/constraints of a book; whereas A2 is the same mess as Microsoft Windows. Although I did some substantial software projects in the Turbo Pascal [and before that] days, I can't cope with ETHO. But now I've found out why. As the complexity of the project expands:. the number of textFrames opened increases and it's inevitable that a critical one will be Grown to cover others. Once that is done, choas will set in, since inconsistent copies of 'papers under the pile' will be created.. IIRC TurboPascal [for DOS] showed only one textFrame at a time, but there was a stack-menu of recent textFrames, which prevented the described problem. Interestingly, `wily` [the public domain version of Plan9's acme] which acknowledges being based on ETHO, seems to have anticipated and handled the described problem. Eg. if you've got testFrames A,B,C & you <Grow> A to cover B & C, and then later <reload> B, then the previous <Grow> of A is reversed so that the already loaded B is visible. I.e. the *existing* B pops out. == Apparently ETHO has anticipated the problem too, and gives the solution of a <popupmenu>: but IIRC it caters for only *.Mod, *.Tool files, which restiction seems bad. Perhaps a 'separate-class' can be created for other file-name extensions. BTW, a serious problem with LEO is the hiding of the filename, due to the field length overflow by long path-names. `mc` handles this well by showing the rightmost/most-relevant text. How does A2 for Win & Linux handle this problem of showing long pathnames in a restricted width field? == Rather than the technical details being the limiting factor, it's the human work-flow aspects that are important in computing. Apparently one can be working away for years, without seeing the bigger picture. "Just get on with the job" is a disasterous short-term attitude. == Doutlessly the BIGGEST picture is keep-it-simple, ie. limit the number of chunks that the user has to keep in mind at one time.. A menu condenses N items into one. A book disciplines N pages into one. .. == Chris Glur. .. PS. I've just been looking at a LEO file <TextPopups.Tool> which may have come from ETHO, or been partially created by me, which seems to handle many of the problems raised above. Apparently this fix was introduced late in the evolution of ETHO. How did the Turbo Pascal designer manage to solve the problem 20 years earlier?

5 5

Code generation and the Lilith architecture
by Luca Boasso 12 Jan '13

12 Jan '13

Hello, I would like to have a copy of this doctoral thesis: "Code generation and the Lilith architecture" written by Jacobi Christian. I could find only the abstract at http://e-collection.library.ethz.ch/view/eth:36058 Could somebody please share it with me? I was looking for a good example of a stack based machine that could be potentially a good target for a simple Oberon compiler. Thank you very much Luca

1 0