[Oberon] Can LinuxAos support LEO like it DOES Oberon ?
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
== C. Glur.
More information about the Oberon