[Oberon] native A2/Oberon on Raspberry Pi - was: Oberon-2 on FPGA

[eas lab]

>So ALO is Oberon for ARM compiled as a Linux app? LEO is the same but for x86?

No, Peter. M of ALO 'has' made several "the same" ie. for different CPUs.

As also LEO has a <Darwin> etc. versions AFAIR.

>I am not sure I understand. This means there are no subdirectories &
> all files live in a single flat directory?

That's how the original Native-Oberon was.

Being stressed by having lost my good system/s and forced to use Micro$hit:
I can't remember the detail, but I believe that LEO could:--
 <FetchDOSformatFile>  /mnt/cdrom/..../File1
 <Fetch*nixFormatFile> /home/dog/File2
 <FetchFile>  /usr/local/sbin/ScriptName
Then you'd have 3 TextFrames seen *TOGETHER*,
 and you can search & CutNpaste between then and or other Files,
 in aos,Fat,*nix formats.

When I investigate a topic, I build a <topic>book, which looks like:-
==CONTENTS==
<1st part's name>
<2nd part's name>
.....
<><><><> <- section separator
<1st part's name>
<Text browser fetched contents & links>
<><><><> <- section separator
<2nd part's name>
.....contents...
<><><><>
....
<><><><>

When I go on-line, I run a Linux command:
 G L Win64ETHO
which fetched the contents  of the list of URLs in file:L
 and appends each to the <Book>File named Win64ETHO in sequence:
1. the URL
2. the contents plus links [in lynx -dump format].
3. the section terminator: "<><><><>"

If I've got 5 sections in the Win64ETHO<book> and L has 4 lines of URLs,
I get the extra 4 sections appened to the <book>.
When I read these new sections, I allocate suitable names to them, and
MUST paste the same names to the context section.

Ie. it's essential to have visual access to multiple part of any text-file.

You can also paste graphical images to your books.
The problem that I have so far failed to solve is rendering
LaTex Math formul<aer>

LEO can also execute Linux scripts, so you can do complex acrobatics.

== Chris Glur.





On 11/5/16, Liam Proven <lproven at gmail.com> wrote:
> On 5 November 2016 at 03:02, eas lab <lab.eas at gmail.com> wrote:
>> ALO <ARM linux Oberon> runs nicely on the RPi,
>> but I prefer to *USE* wily [not experiment/teach] unless I need
>> oberons coloring facility to give extra dimentions of comprehension,
>> for the most difficult tasks.
>>
>> IMO ALO's weakness is the need to <bring all the files to ALO's dir>.
>
> So ALO is Oberon for ARM compiled as a Linux app? LEO is the same but for
> x86?
>
>> Any non-trivial task needs multiple files [and parts of file] to be
>> worked on together. Seeing the files/parts together is what ETHO Tiling
>> is about.
>
> I am not sure I understand. This means there are no subdirectories &
> all files live in a single flat directory?
>
>> LEO [x86 UnixOberon; not for RPi], in contrast, can reach-out and work
>> on files [Aos,FAT,*nix] anywhere in the file tree.
>
> Does that mean it can handle the underlying Windows/Linux filesystem
> when running under it, or that a native Oberon system can access these
> filesystems? Or are you talking about across a network connection?
>
>
> --
> Liam Proven • Profile: http://lproven.livejournal.com/profile
> Email: lproven at cix.co.uk • GMail/Twitter/Facebook/Flickr: lproven
> Skype/MSN: lproven at hotmail.com • LinkedIn/AIM/Yahoo: liamproven
> Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>