[Oberon] Oberon-2 cross compiler source for INMOS T800 Transputer available now (OP2/V4)

eas lab lab.eas at gmail.com
Sat Dec 7 06:51:40 CET 2013


It's taken me a while to digest this 'header'
"Oberon-2 cross compiler source for INMOS T800 Transputer available
now (OP2/V4)".

* Why *NOW* ? Wasn't Transputer squashed-out by big-business decades ago?
* Is V4 easier to port than S3? I was using linux-based-V4 extensively
 previously; some times, in preference to LEO, for the simple but important
 reason that kluxing a FileName would automatically open it in <oberonText>
 or <ASCII>, depending on the file. It's tedious/annoying after kluxing a
 FileName, to then need 2 more mouse-kluxes to select the proper mode.

BTW, don't think that you'll use <Linux Aos> just to process Aos files.
<Linux Aos> is no good, unless like LEO, it allows you to process your
*nix files, and even you M$-files.

After the most recent <theft of my hardware> I didn't get V4 re-set-up YET.

That's how Micro$loth and now google operate:
  they first make you dependent,
  then they change the system requirements, [needs new set up]
  so that you continually MUST buy their updates [new flavor].

Which is OK, provided users realise the narcotic-pedlar-tactics.

== Chris Glur.

PS. the proper END-goal should be, to be able to port the
<ETHO HCI> as in S3 & V4 to any hardware.
Apparently there are now more ARM devices than X86 in the world.
And LNO also achives the <ETHO HCI>.
---
Who knows about `wily`, which is based on Plan9:acme, copied from
<ETHO HCI> ?
Nobody here has acknowledge the <ETHO HCI> deficiency that stacking
textFrames, eventually leads to having the one-you-need hidden.
Then you fetch a 'duplicate'. Then you have 2 un-synced copied.
Then you have chaos/errors.

If you instruct wily: show me all lines in <Dir> with <files>
   containing <TextString>
 and it gives you the file-list;
not only the files are listed, but also the file-position of the match.
IMPORTANTLY when you klux, THAT file pops-up *also if it was covered/hidden*,
at the match position. Which removes the ETHO deficiency.
And it shouldn't be difficult to implement.

Don't worry `wily` is NOT more powerful that ETHO.



More information about the Oberon mailing list