[Oberon] Re (2): Streams.

[Skulski, Wojciech]

Joerg:

 thank you for the heads up.  From my perspective it is important to use the SD card to record the data files and then painlessly transfer them to the PC for processing. Like a digital camera. Ideally the card will open under Windows or Mac and the PC will be able to pull the files. 

I just read about FAT32 versus exFAT versus NTFS. I do not see large differences for the camera-like applications, based on a popular article on the web. Data logging  can live with the 4 GB file limit. I would like to see modern SD capacities served in full, plus perspective that TB cards will be served as well when available. Concerning reliability, possible data corruption is always a problem, but let's be realistic. The camera-like reliability is OK. If a given file system works for photographers then it can work for data logging as well.

I designed the RiskOne data logger with two card slots. One will be a System Disk for the Oberon System. The other SD is a Data Disk. I want to avoid the situation that the instrument stops working after pulling the card. Having two separate disks will help avoid this situation. The System Disk can use the original Oberon file format. Only the Data Disk needs to be readable under PC. 

On the other hand, it will be really nice if Oberon System Disk can be formatted, updated, and backed up on a PC. From this perspective it would be smart to use a PC file system also under Oberon. 

I have two questions.

1) How does your plan relate to HCFiler by Chris?

2) Why is the file system a part of the “HW enumerator”? I thought that enumerator is like a Linux Device Tree. The file system seems to be outside the scope of the device tree.

Thank you,
Wojtek
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Joerg [joerg.straube at iaeth.ch]
Sent: Friday, April 23, 2021 4:41 AM
To: ETH Oberon and related systems
Subject: [EXT] Re: [Oberon] Re (2): Streams.

BTW just as a heads up. What I described below is something I intend to change in my long term project of a “HW enumerator”.
These hooks in Files are helpful for emulator writers as well 😊
Jörg

Von: Joerg <joerg.straube at iaeth.ch>
Datum: Freitag, 23. April 2021 um 05:26
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] Re (2): Streams.


The main drawback of the ProjectOberon system as of today is that Files.Mod is directly bound to the implementation of the Oberon file system and is not only a dispatcher with PROCEDURE variables.

Although you could write a module that reads e.g. DOS formated volumes, or ext3 formatted volumes so your application can read and write to those volumes, the Oberon system itself is strictly bound to the Oberon filesystem as implemented in Files.

If Files.Mod only provided hooks (a kind of standard API aka interface how to read/write to files, and the real implementation of the file system is in another module, you could „easily“ bind another file system to the Files interface and all modules using Files can benefit of this new implementation, even the Oberon system itself.

With such a mechanism, the Streams idea could be implemented more elegantly, as Streams could temporarily modify the implementation of the Files. So all modules using the Files API do not know that they are not reading from real Oberon files but temporary / virtual files provided by Streams.

Obviously you can write/port streams to ProjectOberon and use it in your application but the ProjectOberon commands itself like System.CopyFiles will not use Streams.

BTW: Texts uses Files. So if we allowed Files to redirect, Texts are redirected as well😊

BTW2: The Oberon Log can be redirected already today if needed, as Oberon.Mod offers the procedure OpenLog.

br
Jörg


Am 23.04.2021 um 00:32 schrieb Charles Perkins <chuck at kuracali.com>:

Hi Peter,

I would like to be able to chain commands, where the output of one command is treated as the input to another command. Something like:

Stream.Do List.File AFile.txt | Lines.Uppercase | Lines.Sort | Lines.Uniq | Lines.Count

The three above modules (Stream, List, and Lines) would co-operate to list the number of unique case-insensitive lines in a file. This should be possible without multitasking or process scheduling -- the Stream.Do command would merely set the output of each command (a PROCEDURE variable) to the input of the next with the final output being retained by 'Do' and written to the system log.

That is what I envision in a Stream module suitable for Project Oberon. Others may have a different opinion!
Best Regards,
Chuck



On Thu, Apr 22, 2021 at 1:21 PM <peter at easthope.ca<mailto:peter at easthope.ca>> wrote:
From:   Charles Perkins <chuck at kuracali.com<mailto:chuck at kuracali.com>>
Date:   Thu, 22 Apr 2021 12:34:35 -0700
> I was just wishing for streams in Project Oberon so this is timely for me.

Charles, can you elaborate on the motivation for Streams please.
Why not just use Files directly?
Can your requirements help to illustrate?

Thx,                             ... P.

--
VoIP: +1 604 670 0140            Bcc: peter at easthope. ca

--
Oberon at lists.inf.ethz.ch<mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwMFaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=7n8g4uoeil21c9RYnjY7RRCAhlq-XxYHQHkUyZso6wA&s=UQb1fbJmN4490e1hk0984IcGjYqqnE92ougI2J3Cq7c&e=>
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwQFaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=7n8g4uoeil21c9RYnjY7RRCAhlq-XxYHQHkUyZso6wA&s=UQb1fbJmN4490e1hk0984IcGjYqqnE92ougI2J3Cq7c&e=>