[Oberon] Can LinuxAos support LEO like it DOES Oberon ?

eas lab lab.eas at gmail.com
Wed Nov 29 06:33:39 CET 2017


I've wasted a lot of time failing to get LinuxEthOberon to render the
good font-size, which it does only when running from Debian7's
installing DVD. But my notes tell that LinuxAos [now lost] shows the
font-size of its Oberon/N-O perfectly sized.
Before I lost the IDE with the LinuxAos [due to absurd Chinese quality
of the USB to IDE/SATA adaptor - who remembers "Jap crap" in the
60's?], I was amazed how Aos' Oberon adjusted the font size,
continuously, as the Oberon frame was manually adjusted in size.

Many would ask: why don't I just use LinuxAos which has good font-size?
No! The most valuable resource is screen area; so I want the "Frames to
automatically line-up, like a book's pages". Not M$ style.
  So before I waste more time failing to solve my problem:
is it difficult to have LinuxEthOberon "ride on top of AOS", like or
instead of how Oberon already does ?

Why must you have LEO? Because nothing else gives you the ability
to do <literate programming - per Knuth>. eg. where you'd solve
ETHO's absurdity of not having <list directory, ordered by recentcy>.
When you've got a 2 year old directory [please don't use M$-baby-talk
and call it a folder], which had 55 files and which you're using for a
new task, which is accumulating a further dozen files, you don't want
the files of the new/current task to be buried/lost in the 55 old files.
They must "float on top"! The stack concept.

So you use your linux script/s to see only the N most recent files.
Which LEO executes directly: via eg. System.Execute ^ ls -t <dir> |head

And using this problem as an example of LEO's literate-programing
capability: starting with ETHO's badly formatted System.Directory ?\d

   OldDir:Alibi  20.03.2017 17:13:00    4096
   OldDir:AngloLaw  26.07.2017 09:05:18    4096
   OldDir:BatousTTS  27.07.2017 03:46:49    1405
   OldDir:CIPC  16.04.2017 22:09:54      66
   OldDir:CWilksnMail  19.12.2016 16:32:00     188
   OldDir:CanLegal  27.06.2017 19:29:46    4096
   OldDir:Champerty  07.06.2017 18:31:35    4096
... [this is pasted from LNO, which gives GOOD font-size on this
TC64 installation, but lacks other essential capabilities.]

A possible/guess 4-stage sequence of transformations [that's why
functional programming capability is essential] might be:
1: reOrder each-line's fields to 2 3 1 4,  gives:
     20.03.2017 17:13:00 OldDir:Alibi 4096 <-*nix awk does this
2: transform "20.03.2017" to "2017.03.20" <-our EBNF is better than *nix
3: Sort lines, now formatted to: 2017.03.20 17:13:00 OldDir:Alibi 4096
4: Possibly ? output only the FileID and size, which shows the recentcy.

AFAIK computing which started with <punch cards and cloth-pattern
machines> had no concept of THE STACK. Nor did Turing's-machine.
Wasn't it Burroughs that brought in the stack?
The most essential part of any task that is composed of sub-tasks.
And ETHO failed to provide the capability in directory-listings ?!

How do other users manage without <recentcy ordered dir-listing>?
What am I missing? Or are they like students, who have no HISTORY,
and are only working on the new/present project, which has its own
clean/new directories? Then also they don't appreciate <literate
programming> which allows them to build on easily documented previous
work.

== C. Glur.


More information about the Oberon mailing list