<div dir="ltr">Hi Jörg,<div>Those are my thoughts too. Unifying the files api and the streams api would provide the user with a more flexible and powerful system and also avoid duplication in functionality since files and streams are almost identical in behavior.</div><div>Best Regards,</div><div>Chuck</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 23, 2021 at 1:42 AM Joerg <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="DE-CH" style="overflow-wrap: break-word;"><div class="gmail-m_3552460887122102563WordSection1"><p class="MsoNormal"><span lang="EN-US">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”.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">These hooks in Files are helpful for emulator writers as well </span><span lang="EN-US" style="font-family:"Apple Color Emoji"">😊</span><span lang="EN-US"><u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Jörg<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0cm 0cm"><p class="MsoNormal"><b><span style="font-size:12pt;color:black">Von: </span></b><span style="font-size:12pt;color:black">Joerg <<a href="mailto:joerg.straube@iaeth.ch" target="_blank">joerg.straube@iaeth.ch</a>><br><b>Datum: </b>Freitag, 23. April 2021 um 05:26<br><b>An: </b>ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>><br><b>Betreff: </b>Re: [Oberon] Re (2): Streams.<u></u><u></u></span></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">BTW: Texts uses Files. So if we allowed Files to redirect, Texts are redirected as well<span style="font-family:"Apple Color Emoji"">😊</span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">BTW2: The Oberon Log can be redirected already today if needed, as Oberon.Mod offers the procedure OpenLog.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">br<u></u><u></u></p><div><p class="MsoNormal">Jörg<u></u><u></u></p></div></div><div><p class="MsoNormal"><br><br><u></u><u></u></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><p class="MsoNormal" style="margin-bottom:12pt">Am 23.04.2021 um 00:32 schrieb Charles Perkins <<a href="mailto:chuck@kuracali.com" target="_blank">chuck@kuracali.com</a>>:<u></u><u></u></p></blockquote></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal"><u></u><u></u></p><div><p class="MsoNormal">Hi Peter,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Stream.Do List.File AFile.txt | Lines.Uppercase | Lines.Sort | Lines.Uniq | Lines.Count<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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. <u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">That is what I envision in a Stream module suitable for Project Oberon. Others may have a different opinion!<u></u><u></u></p></div><div><p class="MsoNormal">Best Regards,<u></u><u></u></p></div><div><p class="MsoNormal">Chuck<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Apr 22, 2021 at 1:21 PM <<a href="mailto:peter@easthope.ca" target="_blank">peter@easthope.ca</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">From:   Charles Perkins <<a href="mailto:chuck@kuracali.com" target="_blank">chuck@kuracali.com</a>><br>Date:   Thu, 22 Apr 2021 12:34:35 -0700<br>> I was just wishing for streams in Project Oberon so this is timely for me.<br><br>Charles, can you elaborate on the motivation for Streams please.  <br>Why not just use Files directly?<br>Can your requirements help to illustrate?<br><br>Thx,                             ... P.<br><br>-- <br>VoIP: +1 604 670 0140            Bcc: peter at easthope. ca<br><br>--<br><a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><u></u><u></u></p></blockquote></div><p class="MsoNormal">--<br><a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><u></u><u></u></p></div></blockquote></div></div></div>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>