[Oberon] Re (2): Streams.

Joerg joerg.straube at iaeth.ch
Fri Apr 23 10:41:49 CEST 2021


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> wrote:

From:   Charles Perkins <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 mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon

--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20210423/d13fe5ec/attachment.html>


More information about the Oberon mailing list