Need V4 Code for trivial task.
2 apparently independant Windows bases TextToSpeech translator, both absurdly pause at the text's <newlines>, making the speech sound bad. Linux fixes that with:-- # remove all EOL : \n = new line; \r = return #tr -d \n | tr -d \r \NNN :Octal 10+2=> 012; 13=8+5=>015; 32=\040 cat $1 | tr -d "\012" | tr -d "\015" | \ sed 's/\./\.\r\n/g' | sed 's/ / /g' >> $2 # CrLf after each period & double-space to single-space <-irrelevant But I currently can't get inet except via M$, and I can't afford to switch to *nix for trivial tasks which I can't do with M$!! Since Oberon V4 is running in M$, I thought of: OpenInfile; OpenOutfile; FOR Char:=NextByte(Infile) IF (Ord(Char) = 10) OR (Ord(Char) = 13) THEN Write(Outfile, Ord(32) ELSE Write(Outfile, Char END; CloseInfile; CloseOutfile. You can see that I'm no longer fluent/familiar with <Algol> ?! My ETHO documentation is lost/destroyed, and it's pointless to collect replacements it [since I need to stay dependent on a M$ laptop, to easily flee as the 'revolution' progresses]; but I remember that per S3 documentation: opening & closing files involved <riders>. Can someone please sketch some V4 syntax to solve this problem, since I've really only installed V4 for the <ability to access multiple text files together on the same screen>; which apparently is beyond the imagination of the M$ designers. Thanks, == Chris Glur. PS. I looked at M$'s good idea to follow *nix's shell idea, but you can see that M$'s founder has lawer ancestors: who have the lawer's moto "if ten thousand words will do, why use ten".
Chris, This V4 code seems to work! Needing to cast a BYTE using ORD threw me for a while. You don't need to do that with Component Pascal. MODULE Foo; IMPORT Files, SYSTEM; VAR rd: Files.Rider; wr: Files.Rider; inFile: Files.File; outFile: Files.File; PROCEDURE Open* (out, in: ARRAY OF CHAR): BOOLEAN; VAR flag: BOOLEAN; BEGIN inFile := Files.Old(in); flag := (inFile # NIL); IF flag THEN Files.Set(rd, inFile, 0); outFile := Files.New(out); flag := (outFile # NIL); IF flag THEN Files.Set(wr, outFile, 0) END END; RETURN flag END Open; PROCEDURE Strip* ; VAR b: SYSTEM.BYTE; BEGIN Files.Read(rd, b); WHILE ~rd.eof DO IF (ORD(b) = 13) OR (ORD(b) = 10) THEN b := 32 END; Files.Write(wr, b); Files.Read(rd, b); END; Files.Register(outFile); Files.Close(inFile) END Strip; PROCEDURE Test*; BEGIN IF Open("TestOut.Mod", "TestIn.Mod") THEN Strip END; END Test; END Foo.Test << middle mouse click there to run the program TestIn.Mod looks like This is a sentence with lots of line breaks. Hope this works! TestOut.Mod looks like This is a sentence with lots of line breaks. Hope this works! -Doug On 11/27/2016 10:40 PM, eas lab wrote:
2 apparently independant Windows bases TextToSpeech translator, both absurdly pause at the text's <newlines>, making the speech sound bad.
Linux fixes that with:-- # remove all EOL : \n = new line; \r = return #tr -d \n | tr -d \r \NNN :Octal 10+2=> 012; 13=8+5=>015; 32=\040
cat $1 | tr -d "\012" | tr -d "\015" | \ sed 's/\./\.\r\n/g' | sed 's/ / /g' >> $2 # CrLf after each period & double-space to single-space <-irrelevant
But I currently can't get inet except via M$, and I can't afford to switch to *nix for trivial tasks which I can't do with M$!!
Since Oberon V4 is running in M$, I thought of:
OpenInfile; OpenOutfile; FOR Char:=NextByte(Infile) IF (Ord(Char) = 10) OR (Ord(Char) = 13) THEN Write(Outfile, Ord(32) ELSE Write(Outfile, Char END; CloseInfile; CloseOutfile.
You can see that I'm no longer fluent/familiar with <Algol> ?!
My ETHO documentation is lost/destroyed, and it's pointless to collect replacements it [since I need to stay dependent on a M$ laptop, to easily flee as the 'revolution' progresses]; but I remember that per S3 documentation: opening & closing files involved <riders>.
Can someone please sketch some V4 syntax to solve this problem, since I've really only installed V4 for the <ability to access multiple text files together on the same screen>; which apparently is beyond the imagination of the M$ designers.
Thanks,
== Chris Glur.
PS. I looked at M$'s good idea to follow *nix's shell idea, but you can see that M$'s founder has lawer ancestors: who have the lawer's moto "if ten thousand words will do, why use ten". -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-- Danforth of the Greenwood
Hi Doug, You don't need to use any SYSTEM facilities or casts in Oberon for this task. Replace: VAR b: SYSTEM.BYTE; with: VAR ch: CHAR; Then you can say: IF (ch = 0AX) OR (ch = 0DX) THEN ch := " " END; Regards, Chris Chris Burrows CFB Software http://www.astrobe.com From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Douglas G Danforth Sent: Monday, 28 November 2016 7:29 PM To: ETH Oberon and related systems Subject: Re: [Oberon] Need V4 Code for trivial task. Chris, This V4 code seems to work! Needing to cast a BYTE using ORD threw me for a while. You don't need to do that with Component Pascal. MODULE Foo; IMPORT Files, SYSTEM; VAR rd: Files.Rider; wr: Files.Rider; inFile: Files.File; outFile: Files.File; PROCEDURE Open* (out, in: ARRAY OF CHAR): BOOLEAN; VAR flag: BOOLEAN; BEGIN inFile := Files.Old(in); flag := (inFile # NIL); IF flag THEN Files.Set(rd, inFile, 0); outFile := Files.New(out); flag := (outFile # NIL); IF flag THEN Files.Set(wr, outFile, 0) END END; RETURN flag END Open; PROCEDURE Strip* ; VAR b: SYSTEM.BYTE; BEGIN Files.Read(rd, b); WHILE ~rd.eof DO IF (ORD(b) = 13) OR (ORD(b) = 10) THEN b := 32 END; Files.Write(wr, b); Files.Read(rd, b); END; Files.Register(outFile); Files.Close(inFile) END Strip; PROCEDURE Test*; BEGIN IF Open("TestOut.Mod", "TestIn.Mod") THEN Strip END; END Test; END Foo.Test << middle mouse click there to run the program TestIn.Mod looks like This is a sentence with lots of line breaks. Hope this works! TestOut.Mod looks like This is a sentence with lots of line breaks. Hope this works! -Doug On 11/27/2016 10:40 PM, eas lab wrote: 2 apparently independant Windows bases TextToSpeech translator, both absurdly pause at the text's <newlines>, making the speech sound bad. Linux fixes that with:-- # remove all EOL : \n = new line; \r = return #tr -d \n | tr -d \r \NNN :Octal 10+2=> 012; 13=8+5=>015; 32=\040 cat $1 | tr -d "\012" | tr -d "\015" | \ sed 's/\./\.\r\n/g' | sed 's/ / /g' >> $2 # CrLf after each period & double-space to single-space <-irrelevant But I currently can't get inet except via M$, and I can't afford to switch to *nix for trivial tasks which I can't do with M$!! Since Oberon V4 is running in M$, I thought of: OpenInfile; OpenOutfile; FOR Char:=NextByte(Infile) IF (Ord(Char) = 10) OR (Ord(Char) = 13) THEN Write(Outfile, Ord(32) ELSE Write(Outfile, Char END; CloseInfile; CloseOutfile. You can see that I'm no longer fluent/familiar with <Algol> ?! My ETHO documentation is lost/destroyed, and it's pointless to collect replacements it [since I need to stay dependent on a M$ laptop, to easily flee as the 'revolution' progresses]; but I remember that per S3 documentation: opening & closing files involved <riders>. Can someone please sketch some V4 syntax to solve this problem, since I've really only installed V4 for the <ability to access multiple text files together on the same screen>; which apparently is beyond the imagination of the M$ designers. Thanks, == Chris Glur. PS. I looked at M$'s good idea to follow *nix's shell idea, but you can see that M$'s founder has lawer ancestors: who have the lawer's moto "if ten thousand words will do, why use ten". -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Danforth of the Greenwood
Yeh, but the browser for Files shows PROCEDURE Read (VAR r: Rider; VAR x: SYSTEM.BYTE); On 11/28/2016 2:33 AM, Chris Burrows wrote:
Hi Doug,
You don't need to use any SYSTEM facilities or casts in Oberon for this task.
Replace:
VAR b: SYSTEM.BYTE;
with:
VAR ch: CHAR;
Then you can say:
IF (ch = 0AX) OR (ch = 0DX) THEN ch := " " END;
Regards, Chris
Chris Burrows CFB Software http://www.astrobe.com
From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Douglas G Danforth Sent: Monday, 28 November 2016 7:29 PM To: ETH Oberon and related systems Subject: Re: [Oberon] Need V4 Code for trivial task.
Chris, This V4 code seems to work! Needing to cast a BYTE using ORD threw me for a while. You don't need to do that with Component Pascal.
MODULE Foo;
IMPORT Files, SYSTEM;
VAR rd: Files.Rider; wr: Files.Rider; inFile: Files.File; outFile: Files.File;
PROCEDURE Open* (out, in: ARRAY OF CHAR): BOOLEAN; VAR flag: BOOLEAN; BEGIN inFile := Files.Old(in); flag := (inFile # NIL); IF flag THEN Files.Set(rd, inFile, 0); outFile := Files.New(out); flag := (outFile # NIL); IF flag THEN Files.Set(wr, outFile, 0) END END; RETURN flag END Open;
PROCEDURE Strip* ; VAR b: SYSTEM.BYTE; BEGIN Files.Read(rd, b); WHILE ~rd.eof DO IF (ORD(b) = 13) OR (ORD(b) = 10) THEN b := 32 END; Files.Write(wr, b); Files.Read(rd, b); END; Files.Register(outFile); Files.Close(inFile) END Strip;
PROCEDURE Test*; BEGIN IF Open("TestOut.Mod", "TestIn.Mod") THEN Strip END; END Test;
END Foo.Test << middle mouse click there to run the program
TestIn.Mod looks like This is a sentence with lots of line breaks. Hope this works!
TestOut.Mod looks like This is a sentence with lots of line breaks. Hope this works!
-Doug On 11/27/2016 10:40 PM, eas lab wrote: 2 apparently independant Windows bases TextToSpeech translator, both absurdly pause at the text's <newlines>, making the speech sound bad.
Linux fixes that with:-- # remove all EOL : \n = new line; \r = return #tr -d \n | tr -d \r \NNN :Octal 10+2=> 012; 13=8+5=>015; 32=\040
cat $1 | tr -d "\012" | tr -d "\015" | \ sed 's/\./\.\r\n/g' | sed 's/ / /g' >> $2 # CrLf after each period & double-space to single-space <-irrelevant
But I currently can't get inet except via M$, and I can't afford to switch to *nix for trivial tasks which I can't do with M$!!
Since Oberon V4 is running in M$, I thought of:
OpenInfile; OpenOutfile; FOR Char:=NextByte(Infile) IF (Ord(Char) = 10) OR (Ord(Char) = 13) THEN Write(Outfile, Ord(32) ELSE Write(Outfile, Char END; CloseInfile; CloseOutfile.
You can see that I'm no longer fluent/familiar with <Algol> ?!
My ETHO documentation is lost/destroyed, and it's pointless to collect replacements it [since I need to stay dependent on a M$ laptop, to easily flee as the 'revolution' progresses]; but I remember that per S3 documentation: opening & closing files involved <riders>.
Can someone please sketch some V4 syntax to solve this problem, since I've really only installed V4 for the <ability to access multiple text files together on the same screen>; which apparently is beyond the imagination of the M$ designers.
Thanks,
== Chris Glur.
PS. I looked at M$'s good idea to follow *nix's shell idea, but you can see that M$'s founder has lawer ancestors: who have the lawer's moto "if ten thousand words will do, why use ten". -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-- Danforth of the Greenwood
Chris, I did as you said and that works. My confusion stems from a difference between V4 and Component Pascal. A Component Pascal CHAR is 2 bytes. One must say SHORTCHAR to get 1 byte. Also I didn't think the compiler would accept (if I had thought of it) a CHAR where it specifies a SYSTEM.BYTE. Why in heavens name does V4 Files even mention SYSTEM.BYTE? -Doug On 11/28/2016 2:33 AM, Chris Burrows wrote:
Hi Doug,
You don't need to use any SYSTEM facilities or casts in Oberon for this task.
Replace:
VAR b: SYSTEM.BYTE;
with:
VAR ch: CHAR;
Then you can say:
IF (ch = 0AX) OR (ch = 0DX) THEN ch := " " END;
Regards, Chris
Chris Burrows CFB Software http://www.astrobe.com
-- Danforth of the Greenwood
Oberon-07 defines BYTE as a keyword: BYTE the integers between 0 and 255 So now we have a sort of a variety between CHAR, SHORTCHAR, BYTE, and SYSTEM.BYTE defined in different places by different people at different time. Perhaps it would not be a bad idea to just adopt one set of definitions across the spectrum? Committees appear not that bad after all... Wojtek ________________________________________ From: Oberon [oberon-bounces@lists.inf.ethz.ch] on behalf of Alexander Ilin [ajsoft@yandex.ru] Sent: Monday, November 28, 2016 9:41 AM To: ETH Oberon and related systems; chris@cfbsoftware.com Subject: Re: [Oberon] Need V4 Code for trivial task. A SYSTEM.BYTE formal parameter is compatible with any byte-sized actual parameter. An ARRAY OF SYSTEM.BYTE is compatible with anything. 28.11.2016, 15:49, "Douglas G Danforth" <danforth@greenwoodfarm.com>: Chris, I did as you said and that works. My confusion stems from a difference between V4 and Component Pascal. A Component Pascal CHAR is 2 bytes. One must say SHORTCHAR to get 1 byte. Also I didn't think the compiler would accept (if I had thought of it) a CHAR where it specifies a SYSTEM.BYTE. Why in heavens name does V4 Files even mention SYSTEM.BYTE? -Doug ---=====--- Александр
It's all in the Oakwood Guidelines. 28.11.2016, 22:46, "Skulski, Wojciech" <skulski@pas.rochester.edu>:
Oberon-07 defines BYTE as a keyword: BYTE the integers between 0 and 255
So now we have a sort of a variety between CHAR, SHORTCHAR, BYTE, and SYSTEM.BYTE defined in different places by different people at different time. Perhaps it would not be a bad idea to just adopt one set of definitions across the spectrum?
Committees appear not that bad after all...
---=====--- Александр
It's all in the Oakwood Guidelines
Were they followed? W. ________________________________________ From: Alexander Ilin [ajsoft@yandex.ru] Sent: Monday, November 28, 2016 2:58 PM To: Skulski, Wojciech; ETH Oberon and related systems; chris@cfbsoftware.com Subject: Re: [Oberon] Need V4 Code for trivial task. It's all in the Oakwood Guidelines. 28.11.2016, 22:46, "Skulski, Wojciech" <skulski@pas.rochester.edu>:
Oberon-07 defines BYTE as a keyword: BYTE the integers between 0 and 255
So now we have a sort of a variety between CHAR, SHORTCHAR, BYTE, and SYSTEM.BYTE defined in different places by different people at different time. Perhaps it would not be a bad idea to just adopt one set of definitions across the spectrum?
Committees appear not that bad after all...
---=====--- Александр
Yes, by the XDS compiler, for example.
Not by the ETH crowd, though. That's why we have all these different BYTE's meaning whatever. W. ________________________________________ From: Alexander Ilin [ajsoft@yandex.ru] Sent: Monday, November 28, 2016 3:42 PM To: Skulski, Wojciech; ETH Oberon and related systems; chris@cfbsoftware.com Subject: Re: [Oberon] Need V4 Code for trivial task. 28.11.2016, 23:32, "Skulski, Wojciech" <skulski@pas.rochester.edu>:
It's all in the Oakwood Guidelines
Were they followed?
Yes, by the XDS compiler, for example. ---=====--- Александр
Douglas G Danforth wrote:-
This V4 code seems to work! Needing to cast a BYTE using ORD threw me for a while. You don't need to do that with Component Pascal.
Yes thank, I'm using your code. And I'd like to refine it to syntax:- ELO.Fix <InFile> <OutFile> ~ Because it's a production tool for me; so I want minimal handling; but I've also lost the *.Text with the nice tutorial examples of S3 which I believe would also work with V4. Ie. to scan ahead to fetch "<InFile> <OutFile> ~" . Yes, I'm lazy and resisiting relearning old stuff. It's more fruitfull to discuss extensions to Oberon. That's also why I included the terse examples of *nix script. .... With hold till later discussion re. massive power/economy-of-effort from functional/piping programming style, as demonstrated in this tread's linux snippet. == Chris Glur.
Chris, I am just as lazy as you are, but I stuck with it and have a command line version that works. Command line in that within the V4 system one can middle mouse on the line Eol.Fix inFileName outFileName and the conversion will happen. Here is the code --- MODULE Eol; IMPORT Files, Oberon, Out, Texts; VAR rd: Files.Rider; wr: Files.Rider; inFile: Files.File; outFile: Files.File; PROCEDURE Open* (out, in: ARRAY OF CHAR): BOOLEAN; VAR flag: BOOLEAN; BEGIN inFile := Files.Old(in); flag := (inFile # NIL); IF flag THEN Files.Set(rd, inFile, 0); outFile := Files.New(out); flag := (outFile # NIL); IF flag THEN Files.Set(wr, outFile, 0) ELSE Out.String("Could not open output <"); Out.String(out); Out.String(">"); Out.Ln END ELSE Out.String("Could not open input <"); Out.String(in); Out.String(">"); Out.Ln END; RETURN flag END Open; PROCEDURE Strip* ; VAR c: CHAR; BEGIN Files.Read(rd, c); WHILE ~rd.eof DO IF (c = 0DX) OR (c = 0AX) THEN c := " " END; Files.Write(wr, c); Files.Read(rd, c); END; Files.Register(outFile); Files.Close(inFile) END Strip; PROCEDURE Fix*; VAR s: Texts.Scanner; inName, outName: ARRAY 256 OF CHAR; BEGIN Out.Open; Texts.OpenScanner(s, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(s); IF s.class # Texts.Name THEN Out.String("input name not found"); Out.Ln ; Out.Int(s.class,3); Out.String(" = s.class"); Out.Ln ELSE COPY(s.s, inName) ; Texts.Scan(s); IF s.class # Texts.Name THEN Out .String("output name not found"); Out.Ln ; Out.Int(s.class,3); Out.String(" = s.class"); Out.Ln ELSE COPY(s.s, outName); IF Open(outName, inName) THEN Strip; Out.String("File converted"); Out.Ln END END END END Fix; END Eol. --- On 12/3/2016 10:32 PM, eas lab wrote:
Douglas G Danforth wrote:-
This V4 code seems to work! Needing to cast a BYTE using ORD threw me for a while. You don't need to do that with Component Pascal. Yes thank, I'm using your code. And I'd like to refine it to syntax:- ELO.Fix <InFile> <OutFile> ~ Because it's a production tool for me; so I want minimal handling; but I've also lost the *.Text with the nice tutorial examples of S3 which I believe would also work with V4. Ie. to scan ahead to fetch "<InFile> <OutFile> ~" .
Yes, I'm lazy and resisiting relearning old stuff. It's more fruitfull to discuss extensions to Oberon. That's also why I included the terse examples of *nix script.
.... With hold till later discussion re. massive power/economy-of-effort from functional/piping programming style, as demonstrated in this tread's linux snippet.
== Chris Glur. -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-- Danforth of the Greenwood
Very nice, thanks. Plus I can easily extend: as I've done,eg. by: translating "%" and """ to " " and translating "." to "`"; where V4's Hex.Open gave me the values. which V4's Hex.Open gave me the ORD values of.. And interestingly that's achieved also by "just popping an extra-line into the code". But it's not as modular/simple/safe as the canonical piping syntax: InputFile |Filter1 |Filter2....|FilterN > OutputFile ======================================= WHILE ~rd.eof DO IF (c = 0DX) OR (c = 0AX) OR (c = 25X) OR (c = 22X) THEN c := " " END; IF (c = 2EX)THEN c := 60X END; (* delete Cr, Lf, %=25 "=22 ; .=2E => `=60 *) Files.Write(wr, c); Files.Read(rd, c); END; == Chris Glur.
But it's not as modular/simple/safe as the canonical piping syntax: InputFile |Filter1 |Filter2....|FilterN > OutputFile
Unix pipes are based on a certain programming paradigm which is different from the Oberon System and from GUI-based systems in general. The piping paradigm is based on the notion of a program transforming input into output, which was inspired by the chain "card reader --> computer --> card punch". You may recall: PROGRAM CALC (INPUT, OUTPUT) In Unix input is named stdin, output is named stdout, but the idea is the same. Piping means that the output of one program becomes the input to another one. It can be achieved with punched card decks, files on disk, or FIFO in memory. The technical details are secondary. The key to understanding is the word "sequential". Unix pipes can give you an illusion of concurrent execution, but the data is in in fact transformed sequentially. The GUI paradigm is a different one. GUI systems do not have one input and one output. GUI can take its input from anywhere and it can put the output anywhere. The GUI is manifestly parallel, even though under the hood all the processing is performed sequentially. But here the sequential processing becomes a secondary implementation detail. The paradigm itself is parallel. After saying all this I would declare that you are advocating a paradigm which Oberon System (and any other GUI system) has explicitly disposed of. Your piping can be implemented in Oberon with an executable program whose interface would explicitly say PROGRAM (input, output) or "function main (stdin, stdout)", or something compatible. There are Oberon compilers which will produce this kind on an executable. Oberon System is not one of of them. W.
W, Thank you for saying that! I was paid $3,000 in 1979 by Three Rivers Computer to implement a Unix shell with pipes. I did that on a Terak <https://en.wikipedia.org/wiki/Terak_8510/a> machine written in Pascal. I never want to go back to that form of "linear thinking". I greatly prefer the GUI Oberon approach. -Doug Danforth On 12/6/2016 7:44 PM, Skulski, Wojciech wrote:
But it's not as modular/simple/safe as the canonical piping syntax: InputFile |Filter1 |Filter2....|FilterN > OutputFile Unix pipes are based on a certain programming paradigm which is different from the Oberon System and from GUI-based systems in general. The piping paradigm is based on the notion of a program transforming input into output, which was inspired by the chain "card reader --> computer --> card punch". You may recall:
PROGRAM CALC (INPUT, OUTPUT)
In Unix input is named stdin, output is named stdout, but the idea is the same. Piping means that the output of one program becomes the input to another one. It can be achieved with punched card decks, files on disk, or FIFO in memory. The technical details are secondary. The key to understanding is the word "sequential". Unix pipes can give you an illusion of concurrent execution, but the data is in in fact transformed sequentially.
The GUI paradigm is a different one. GUI systems do not have one input and one output. GUI can take its input from anywhere and it can put the output anywhere. The GUI is manifestly parallel, even though under the hood all the processing is performed sequentially. But here the sequential processing becomes a secondary implementation detail. The paradigm itself is parallel.
After saying all this I would declare that you are advocating a paradigm which Oberon System (and any other GUI system) has explicitly disposed of. Your piping can be implemented in Oberon with an executable program whose interface would explicitly say PROGRAM (input, output) or "function main (stdin, stdout)", or something compatible. There are Oberon compilers which will produce this kind on an executable. Oberon System is not one of of them.
W. -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-- Danforth of the Greenwood
The pipe'n'filter style arises from the batch processing habits of yore whereas Oberon was written for an interactive workstation. They each have their uses, and I wouldn't dismiss either of them out-of-hand, or consider either of them to be the final grand answer to everything. They're not the only options either. Clements, Bass et al. have written a lot about software architectural styles, their strengths and weaknesses. Worth being familiar with them. http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=30264 B On 7 Dec 2016, at 09:21, Douglas G Danforth <danforth@greenwoodfarm.com<mailto:danforth@greenwoodfarm.com>> wrote: W, Thank you for saying that! I was paid $3,000 in 1979 by Three Rivers Computer to implement a Unix shell with pipes. I did that on a Terak<https://en.wikipedia.org/wiki/Terak_8510/a> machine written in Pascal. I never want to go back to that form of "linear thinking". I greatly prefer the GUI Oberon approach. -Doug Danforth On 12/6/2016 7:44 PM, Skulski, Wojciech wrote: But it's not as modular/simple/safe as the canonical piping syntax: InputFile |Filter1 |Filter2....|FilterN > OutputFile Unix pipes are based on a certain programming paradigm which is different from the Oberon System and from GUI-based systems in general. The piping paradigm is based on the notion of a program transforming input into output, which was inspired by the chain "card reader --> computer --> card punch". You may recall: PROGRAM CALC (INPUT, OUTPUT) In Unix input is named stdin, output is named stdout, but the idea is the same. Piping means that the output of one program becomes the input to another one. It can be achieved with punched card decks, files on disk, or FIFO in memory. The technical details are secondary. The key to understanding is the word "sequential". Unix pipes can give you an illusion of concurrent execution, but the data is in in fact transformed sequentially. The GUI paradigm is a different one. GUI systems do not have one input and one output. GUI can take its input from anywhere and it can put the output anywhere. The GUI is manifestly parallel, even though under the hood all the processing is performed sequentially. But here the sequential processing becomes a secondary implementation detail. The paradigm itself is parallel. After saying all this I would declare that you are advocating a paradigm which Oberon System (and any other GUI system) has explicitly disposed of. Your piping can be implemented in Oberon with an executable program whose interface would explicitly say PROGRAM (input, output) or "function main (stdin, stdout)", or something compatible. There are Oberon compilers which will produce this kind on an executable. Oberon System is not one of of them. W. -- Oberon@lists.inf.ethz.ch<mailto:Oberon@lists.inf.ethz.ch> mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Danforth of the Greenwood -- Oberon@lists.inf.ethz.ch<mailto:Oberon@lists.inf.ethz.ch> mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
In an effort to understand the background of that book I googled Len Bass and as far as I can tell he has never actually programmed for the environments of which he writes. Its important to know the experience of the authors so as to understand their perspectives. He has a lot of acclimations but they all seem to be academic. -Doug On 12/7/2016 11:55 AM, Bob Walkden wrote:
The pipe'n'filter style arises from the batch processing habits of yore whereas Oberon was written for an interactive workstation. They each have their uses, and I wouldn't dismiss either of them out-of-hand, or consider either of them to be the final grand answer to everything.
They're not the only options either. Clements, Bass et al. have written a lot about software architectural styles, their strengths and weaknesses. Worth being familiar with them.
http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=30264
B
-- Danforth of the Greenwood
On Tue, December 6, 2016 9:50 pm, Douglas G Danforth wrote:
W, Thank you for saying that! I was paid $3,000 in 1979 by Three Rivers Computer to implement a Unix shell with pipes. I did that on a Terak <https://en.wikipedia.org/wiki/Terak_8510/a> machine written in Pascal. I never want to go back to that form of "linear thinking". I greatly prefer the GUI Oberon approach. -Doug Danforth
I like both the gui approach and the console approach... A web program that runs on a server is actually a gui, that runs via a console like program... Sometimes the simplicity of a console program over the extreme complexity of a GUI is very refreshing, and nostalgic. On the other hand, console programs are extremely boring. The old turbo pascal programs were utter boredom compared to today's wiz bang GUI candy. But every time, for example, ComponentPascal Blackbox logs a message or a line of text to the log window, you are essentially emulating a sort of linear console mode program in a limited gui window that acts very much like a console. Any time you LogLn or Write to a window it's very much like a limited console. In other words, both the console approach and the gui approach are useful IMO. I don't think we should be Gui Nazis and get rid of all console mode thinking entirely, or command line zealots (linux nerds) who only enjoy and prefer console mode programming... Console mode programming, is still useful for telnet/ssh into a web server. I'd like to see how one manages a web server over telnet without using console mode... i.e. one of the oberon projects has a web server (bluebottle?). So how pray tell does one administer his server, from a hotel, if you are on the road, with a web connection, without resorting to a ssh/telnet console to take control of the server? you could theoretically manage the server via a remote GUI but that complicates matters: sometimes it is much simpler to log in to a server remotely using telnet/ssh and type in a command, rather than opening up an entire GUI protocol over an I internet connection. The bandwidth wasted to for example run an X11 gui over an internet connection, compared to a simple telnet/ssh session... is absurd bandwidth. I'm sure running a remote oberon GUI would be more efficient, but even a ssh/telnet connection to a bluebottle/oberongui that uses simple console programs would IMO be much simpler and less complex than a remote GUI session similar to the heavy and hefty X11 system. As I am unfamiliar with some of the Oberon projects that have a web server (bluebottle?), I don't even know if one can remotely administer a web server over an internet connection. You could always use html itself, and build a web based remote control system, but that still is not as simple and powerful as a telnet/ssh console mode remote control ability that unix has had for decades, and even ms windows has had for decades... Sometimes forcing everything to be GUI, complicates matters... On the other hand, I totally agree that console mode programs such as Midnight Commander or pretty much any other console mode program, are absolutely pathetic compared to their GUI counterparts such as Total Commander.
Just to clarify: "The shell syntax for pipelines forces them to be linear, although the operating system permits processes to be connected by pipes in a general graph." My understanding is that, in general, processes further down the pipeline do not have to wait for the previous processes to finish before they can start. The process is described further in the following document written by Dennis Ritchie in 1978: "The UNIX Timesharing System - A Retrospective" https://www.bell-labs.com/usr/dmr/www/retro.pdf @Chris Glur: MS-DOS from version 2.0 onwards also has a limited piping system. You can still use this in a Windows 10 system via the "command prompt" e.g. try the following command sequence to get a directory listing sorted by descending date and then paged to the screen: cmd dir /O-D | more Regards, Chris Burrows CFB Software http://www.cfbsoftware.com
-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Skulski, Wojciech Sent: Wednesday, 7 December 2016 2:15 PM To: ETH Oberon and related systems Subject: Re: [Oberon] Need V4 Code for trivial task.
But it's not as modular/simple/safe as the canonical piping syntax: InputFile |Filter1 |Filter2....|FilterN > OutputFile
Unix pipes are based on a certain programming paradigm which is different from the Oberon System and from GUI-based systems in general. The piping paradigm is based on the notion of a program transforming input into output, which was inspired by the chain "card reader --> computer --> card punch". You may recall:
PROGRAM CALC (INPUT, OUTPUT)
In Unix input is named stdin, output is named stdout, but the idea is the same. Piping means that the output of one program becomes the input to another one. It can be achieved with punched card decks, files on disk, or FIFO in memory. The technical details are secondary. The key to understanding is the word "sequential". Unix pipes can give you an illusion of concurrent execution, but the data is in in fact transformed sequentially.
The GUI paradigm is a different one. GUI systems do not have one input and one output. GUI can take its input from anywhere and it can put the output anywhere. The GUI is manifestly parallel, even though under the hood all the processing is performed sequentially. But here the sequential processing becomes a secondary implementation detail. The paradigm itself is parallel.
After saying all this I would declare that you are advocating a paradigm which Oberon System (and any other GUI system) has explicitly disposed of. Your piping can be implemented in Oberon with an executable program whose interface would explicitly say PROGRAM (input, output) or "function main (stdin, stdout)", or something compatible. There are Oberon compilers which will produce this kind on an executable. Oberon System is not one of of them.
W. -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
On Tue, December 6, 2016 8:44 pm, Skulski, Wojciech wrote:
The GUI paradigm is a different one. GUI systems do not have one input and one output. GUI can take its input from anywhere and it can put the output anywhere. The GUI is manifestly parallel, even though under the hood all the processing is performed sequentially. But here the sequential processing becomes a secondary implementation detail. The paradigm itself is parallel.
But a GUI often still has a console window that you can open. Gui's still need to run batch tasks, IMO. i.e. a pure GUI environment, without any console ability, is less powerful.
After saying all this I would declare that you are advocating a paradigm which Oberon System (and any other GUI system) has explicitly disposed of.
Then what does one do for batch tasks on this pure GUI? IMO console programs are still useful, especially for teaching simple programming concepts where a GUI would get in the way and complicate matters beyond simplicity. A linux/bsd or even windows system, still has access to a console, IMO extremely useful, and should not be entirely disposed of. You end up with something like a console.. similar to ComponentPascal blackbox IDE where you have log windows, which is essentially a special console window without it having all the power of a unix console. Any log window where you are writing text line by line one at a time, is like a console... and then you will end up reinventing the console if you start to expand it further. Pipes can be useful for interprocess communication too, transferring data between programs, without ever anyone seeing a "Console"... the pipe could be hidden and used as a message system to pass data between two processes. One could completely hide away the inner details of a pipe so that the end user never saw a console window or a command line, and that pipe could be used in a GUI to pass data between two processes: once again the end user never sees a console window or knows a pipe is being used. And this pipe, could be very useful in a gui to pass data... but end user knows nothing of a console.
-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Lars Sent: Tuesday, 13 December 2016 8:44 PM To: ETH Oberon and related systems Subject: Re: [Oberon] Need V4 Code for trivial task.
But a GUI often still has a console window that you can open. Gui's still need to run batch tasks, IMO.
Quote from a message from J.M Drake in comp.lang.oberon (30 Nov 1999) "However, the best feature of Oberon's TUI as opposed to a GUI is that a TUI seems, to me anyway, to be a natural bridge between a CLI and a GUI. When prototyping a project, commands can be typed on and clicked in a manner which isn't that far removed from a CLI. But these same commands can be rapidly incorporated into an ETH Oberon "gadget", a BlackBox "form", or a V4 "Dialog". In ETH Oberon, these command can be tied to variables on the gadget by use of macros. (Yes, Oberon does support macros. Had to throw that in there.)" For his complete post see: http://www.ethoberon.ethz.ch/cli.html Regards, Chris Burrows CFB Software http://www.astrobe.com/RISC5
On Tue, December 13, 2016 4:48 am, Chris Burrows wrote:
Quote from a message from J.M Drake in comp.lang.oberon (30 Nov 1999)
...
In ETH Oberon, these command can be tied to variables on the gadget by use of macros. (Yes, Oberon does support macros. Had to throw that in there.)"
What exactly is an oberon macro? The term macro is overloaded to mean many things... is it like in a text editor where you record a macro (or MS Excel) and can playback events?
[...]
After saying all this I would declare that you are advocating a paradigm which Oberon System (and any other GUI system) has explicitly disposed of.
Then what does one do for batch tasks on this pure GUI?
Since you can execute commands in any window (or viewer in Oberon terminology, any viewer is also a kind of a shell. There is a kind of a meta command executing commands written in a viewer. In A2/WinAos this meta command is: SystemTools.DoCommands and It reads all commands until it encounters two ~ (possibly separated by white space). Normal commands terminate their parameters usually by a single ~. I do not recall, how it was called in System 3 or System 4 and I was not able to dig it out quickly enough. BTW: A surprisingly similar interface to execute commands was the worksheet user interface of the Macintosh Programmers Workshop on the classic Mac (see: https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop) . It is not so surprising if you know that the Oberon System and the classic Mac both can be traced back to the heritage of the Xerox Alto at developed at PARC https://en.wikipedia.org/wiki/Xerox_Alto).
IMO console programs are still useful, especially for teaching simple programming concepts where a GUI would get in the way and complicate matters beyond simplicity.
Programming for the Oberon GUI is very different to programming for Windows/Mac/*ix GUIs. Regards -- Bernhard
Skulski wrote:- ] The GUI paradigm is a different one. ]GUI systems do not have one input and one output. ]GUI can take its input from anywhere and it can put the output anywhere. No: GraphicalUserInterface is orthoginal to "number of inputs/outputs. It's just that the CommandLineInput [ie. instead of selecting from a menu] is more tolerable with the economy of concepts and corresponding economy of tokens in a command. ----------------- ]..you are advocating a paradigm which Oberon System (and any other ] GUI system) has explicitly disposed of. No, and that's also why lisp and Forth are not being replaced. Haskell seems to be taking the lead, but lacks a NW who can analyse and explain the subtle aspects, instead of lapsing into "it feels nice". We have a reader here who built an <Oberon Functional system> and who presumably should have plently to tell, but his system uses the absurd MocroSoft convention of haveing multi-word-tokens, which kills the UserInterface aspect, which you have rightly emphasised is vitally important. For me the User-Interface, which is quite independant of imperative, declarative, functional/piping style, is of great importace and a big plus for ETHO. Apparently python & Haskel, also use format/indentation as part of the syntax; and case-of-1st-letter-of-tokens. Similarly syntax hi-lighting/colouring has value. -------------------------- ]Your piping can be implemented in Oberon with an executable program ]whose interface would explicitly say PROGRAM (input, output) or ] "function main (stdin, stdout)", or something compatible. What happened to nested functions which TurboPascal & my P-code interpreter used? Like: count the sentences in dirTree:D in Files:F which contain "blue" & "red" ListAllFilesIn D | Filter F| extract sentences |\ grep "blue" | grep "red" | IncrCounter NameMatches [ListFiles (Dir),NameF] ... it's too difficult. That's why the piping-notation is good. ------------------------------------ Chris Burrows wrote:- ] the following command sequence to get a directory listing ] sorted by descending date and then paged to the screen: ] ] dir /O-D | more That's a perfect example of a vital command/tool, implemented by merely 4 tokens. ----------------- Douglas G Danforth wrote:-
Thank you for saying that! I was paid $3,000 in 1979 by Three Rivers Computer to implement a Unix shell with pipes. I did that on a Terak machine written in Pascal. I never want to go back to that form of "linear thinking".
You conflate the BUILDING of the item with the USE of the item. Perhaps it's not as much fun PRODUCING choclate as EATING it? Yes LINEAR thinking is ONE dimensional. I like to reduce the thinking to the MINIMAL <dimensionality>. It's the MULTI-dimensionality that most tasks seem to entail that pains me. That's where ETHO proves superior to even `wily` by handleing an extra dimension by MULTIPLE colorS.
I greatly prefer the GUI Oberon approach.
One of the few substantial projects I did was via TurboPascal-3, and I've been wondering how the DOS-based system made the menues and different source-files so effortlessly available, whereas gmail & M$: via a generation later [MODERN giant corporationS] are so lame! Gmail cut off 2 of my 3 accounts, when my system was stolen and I was forced to use my RPi with a TV-set and slow Inet, because they "detected strange activity". So they used their multidimensional game of sending you passwords to one account to confirm/unlock another account, and then cut-off the game/cycle once you had used the confirming phone-number N-times, because they had simplistically designed <limitation of N accounts per single phone-number>. If the above had been linear, it would be easier to understand?
On Tue, December 13, 2016 7:51 am, eas lab wrote:
Skulski wrote:- ] The GUI paradigm is a different one. ]GUI systems do not have one input and one output. ]GUI can take its input from anywhere and it can put the output anywhere.
No: GraphicalUserInterface is orthoginal to "number of inputs/outputs. It's just that the CommandLineInput [ie. instead of selecting from a menu] is more tolerable with the economy of concepts and corresponding economy of tokens in a command. ----------------- ]..you are advocating a paradigm which Oberon System (and any other ] GUI system) has explicitly disposed of.
No, and that's also why lisp and Forth are not being replaced. Haskell seems to be taking the lead, but lacks a NW who can analyse and explain the subtle aspects, instead of lapsing into "it feels nice".
Lisp and forth probably already have been replaced, or superseded, by unfortunately C++. C++ with all its templating tricks is basically "plain C with lisp like extensibility but still not as powerful as lisp" When Paul Graham wrote his Lisp shopping cart (the first one to exist on the internet apparently, Yahoo Stores, way way back in the day) Guess what happened? His startup got bought, and they converted the code from lisp to another language that modern developers could actually use and understand... Since lisp is so bloody extensible and powerful, that's it's double edged sword: you can modify the living hell out of a lisp program, to the extent that no one actually understands what the lisp program is doing any more. With all its "macros" and changing the language at run time, rather than a fixed simpler language like C (assuming you don't use preprocessor macros or compiler tricks), basically no one uses lisp, because it's too much of a nightmare to understand all the "lisp tricks" that clever (clever is not necessarily the same as smart) programmers put into the lisp code... Also Lisp keeps getting replaced (or refined?) with new forks of itself. You've got Scheme, and then you've got Paul Graham's version of lisp... all these seem to be disciplined "rewrites" of lisp to try to put some sense in it so that it is more, disciplined... To be fair, the same thing (but different) happened with plain C. People forked it and created objective C and c++, and php, and other c variants, like Java... Java was an attempt to make C code more disciplined (or C++ Rather). As for Forth, I guess I don't know enough about it to comment, but pray tell, who in the hell even uses forth? There's like, what a total of.. how many Forth programmers... Not to knock it or bash it, as again I don't know enough about it, but it just seems like... a niche language that very few use. Be interesting to find out how many people use it and for what purposes.. You had that crazy version of forth called Color Forth which is alien... and weird, which I've been meaning to try, but can't figure out what I would actually do with it, let alone why.. Generally programming languages are not "Replaced". They don't die. They just get refinements. Everyone said Delphi was dead when Borland left it to die.. but Delphi didn't die. Programming languages just don't die..
We have a reader here who built an <Oberon Functional system> and who presumably should have plently to tell, but his system uses the absurd MocroSoft convention of haveing multi-word-tokens, which kills the UserInterface aspect, which you have rightly emphasised is vitally important.
Can you explain what a Microsoft multi word token is in their GUI? AFIACT microsoft uses gui widgets... where are these tokens you speak of? do you mean the windows api? What's a multi word token in a gui?
What happened to nested functions which TurboPascal & my P-code interpreter used? Like: count the sentences in dirTree:D in Files:F which contain "blue" & "red"
By nested functions do you mean code? like procedure test; procedure inner; begin end; begin inner; // local function, nested end; or do you mean something else... AFAIK some oberon have nested functions? But maybe you mean something else.. like nested commands, at a unix terminal. But then you mentioned turbo pascal so I wonder what you mean... BTW freepascal may interest you if you are a turbopascal fan... Then there are those higher order functions, or golfing functions inside functions. IMO nested functions are a double edged sword as people end up abusing them to have functions inside functions inside functions, on and on and on, until their program looks like a steaming pile of nested tree crap.. http://i1.trekearth.com/photos/89575/tree_complex_1.jpg One nest deep and you aren't too bad... but once you start nesting the crap out of everything, you end up with some bizarre program that no one can understand that wiggles all over the screen, which makes you beg for a plain C non nested program that reads from top to bottom... Functional languages and their deep nests of functions inside functions is also one of the things that I'm a biggest critic of with regards to functional programming... Human brains are not equipped to understand such deep nests, IMO, which is why languages like C and C++ and Java are winning, likely.. because they read from top to bottom, not inside each others insides and all over each others internal functions inside functions... Now displayed use of nests is a good thing... but deep nests IMO are bad, and is likely one of the biggest issues with LISP and maybe even other languages like, Javascript, but I don't know enough about javascript to comment much. But the nests you talk about could be something else, I don't know. It's just that you mentioned turbo pascal..
You conflate the BUILDING of the item with the USE of the item. Perhaps it's not as much fun PRODUCING choclate as EATING it?
It's much more fun to produce chocolate if you are making money selling it, as consuming it does not produce a large income. The chocolate industry is basically a monopoly right now, with the only sensible tasting 99 percent chocolate, coming from a company called Lindt, who apparently has virtually no competitors. So when Lindt has a monopoly on 90 percent and 99 percent rated chocolate, they make a killing in profits. I'd much rather produce (make income from) chocolate than consume it, but even better I'd rather produce it and sample it at the factory too, sticking my finger into someone's bar. In other words, writing a compiler, and using it, or writing a parser, or any program, and "eating your own dog food" is the ideal.
One of the few substantial projects I did was via TurboPascal-3, and I've been wondering how the DOS-based system made the menues and different source-files so effortlessly available, whereas gmail & M$: via a generation later [MODERN giant corporationS] are so lame! Gmail cut off 2 of my 3 accounts, when my system was stolen and I was forced to use my RPi with a TV-set and slow Inet, because they "detected strange activity". So they used their multidimensional game of sending you passwords to one account to confirm/unlock another account, and then cut-off the game/cycle once you had used the confirming phone-number N-times, because they had simplistically designed <limitation of N accounts per single phone-number>. If the above had been linear, it
Security is difficult, no one really gets it right... Even PayPal locks out your credit card if you add it too many times (the same card number). So if you remove the credit card and then decide a few months later that you will in fact use that card again even though you previously chose to remove it, just be careful.. Same with bank accounts being confirmed. Security is difficult to get right. Ultimately there should be a bypass system, like you can call up google and say "hey this account got locked out, is there any way I can get you to reset this for me so it works..". All small companies generally have this feature "call us". Big companies suffer from the issue of lack of personal customer service because they have grown too big. Except for banks, which have figured out a way to grow in massive size, but still provide Local Branches you can visit for one on one customer service. That is something to be said about banks...
On 14 December 2016 at 07:39, Lars <noreply@z505.com> wrote:
Lisp and forth probably already have been replaced, or superseded,
Hardly. Sadly many quite poor languages -- over-complex, or unsafe, or both -- have become very popular, but that doesn't mean that the older ones have gone away. They are still around, still updated, still in use.
When Paul Graham wrote his Lisp shopping cart (the first one to exist on the internet apparently, Yahoo Stores, way way back in the day)
Yahoo Stores is what it was called after it was acquired and rewritten -- just checking for clarity here.
His startup got bought,
Yes, by Yahoo.
and they converted the code from lisp to another language that modern developers could actually use and understand...
Yes. C. But see Greenblatt's Law.
Since lisp is so bloody extensible and powerful, that's it's double edged sword: you can modify the living hell out of a lisp program, to the extent that no one actually understands what the lisp program is doing any more.
While this is true, it's also true of C. Any language can be hard to read and obscure if not written in a clear style; and almost any can be clear and readable if done well. Perhaps not Intercal or Befunge. ;-)
Also Lisp keeps getting replaced (or refined?) with new forks of itself. You've got Scheme, and then you've got Paul Graham's version of lisp... all these seem to be disciplined "rewrites" of lisp to try to put some sense in it so that it is more, disciplined...
There are dozens or hundreds: Racket, Arc, CGOL, PLOT, Qi, Shen, etc. But actually, I suspect that there are only a few in serious widespread use: * Clojure * Common Lisp * Emacs Lisp So you can, sadly, ignore a lot of the noise.
To be fair, the same thing (but different) happened with plain C. People forked it and created objective C and c++, and php, and other c variants, like Java... Java was an attempt to make C code more disciplined (or C++ Rather).
In part. Java has different goals -- it's deepy object-oriented, type-safe, runs in a managed VM, and so on. More direct comparisons to C/C++ are Objective C and D. To Java, C#.
As for Forth, I guess I don't know enough about it to comment, but pray tell, who in the hell even uses forth? There's like, what a total of.. how many Forth programmers... Not to knock it or bash it, as again I don't know enough about it, but it just seems like... a niche language that very few use. Be interesting to find out how many people use it and for what purposes..
Millions, but they mostly don't know it. It's part of OpenFirmware. https://en.wikipedia.org/wiki/Open_Firmware All computers with SPARC and PowerPC processors, including millions of Power Macs, and quite a few other RISC systems. Sadly not common on x86 (where we got UEFI) or ARM (where there's no standard firmware). Forth is distantly related to Postscript, and that's in millions of printers and imaging devices -- and forms the basis of the display model of Mac OS X, in hundreds of millions of Apple computers. http://wiki.c2.com/?ForthPostscriptRelationship -- Liam Proven • Profile: https://about.me/liamproven Email: lproven@cix.co.uk • Google Mail/Talk/Plus: lproven@gmail.com Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053
How does Win8.1 work re. internet access for Oberon-V4? Trying to access some http gave a <can/t access> error message, so I tested the V4's telnet facility on my NNTP-server, using their IP number instead of their name. And I was able to dialogue. Under linux, that would normally indicate DNS, resolver problems. How would I further debug this under Windows: Oberon-V4? ------------------------- ]> What happened to nested functions which TurboPascal & my P-code ]> interpreter used? Like: count the sentences in dirTree:D in Files:F which ]> contain "blue" & "red" ]> Lars wrote:- ] By nested functions do you mean code? ] ] like ] ] procedure test; ] procedure inner; ] begin ] end; ] begin ] inner; // local function, nested ] end; No. X := Max(Smallest(Afiles), Bigest(Bfiles)); where Max returns the larger of 2 Ints; and Smallest, Bigest return the Int-size of a set of files. Much of ETHO's code has a naive/annoying style of:- REPEAT Collect all needed temp variables launch the function using the tempVars collect any return values for next stage UNTIL Done; Contrast this with: Stage1 | Stage2 | ..... StageN With the laguage ML, you don't need/want variables. You just have "it". == Chris Glur.
On 14 December 2016 at 19:06, eas lab <lab.eas@gmail.com> wrote:
How does Win8.1 work re. internet access for Oberon-V4?
Don't hijack other's threads. Start a new one with a new mail to the list and a new subject line. -- Liam Proven • Profile: https://about.me/liamproven Email: lproven@cix.co.uk • Google Mail/Talk/Plus: lproven@gmail.com Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053
Yes that's right. I didn't anticipate that it would develop into a thread. I have the same problem, when an expected temporary tree-leaf develops into a sub-tree. That's why we need ETHO/wily interface: to be able to see multiple viewers, for multiple files that are related to the root-topic. == Chris Glur. On 12/15/16, Liam Proven <lproven@gmail.com> wrote:
On 14 December 2016 at 19:06, eas lab <lab.eas@gmail.com> wrote:
How does Win8.1 work re. internet access for Oberon-V4?
Don't hijack other's threads. Start a new one with a new mail to the list and a new subject line.
-- Liam Proven • Profile: https://about.me/liamproven Email: lproven@cix.co.uk • Google Mail/Talk/Plus: lproven@gmail.com Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053 -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
BTW: A surprisingly similar interface to execute commands was the worksheet user interface of the Macintosh Programmers Workshop on the classic Mac (see: https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop) . It is not so surprising if you know that the Oberon System and the classic Mac both can be traced back to the heritage of the Xerox Alto at developed at PARC https://en.wikipedia.org/wiki/Xerox_Alto).
Would be interesting to see what approach Plan9 operating system took, since it was inspired by oberon but also inspired by unix. I have a hunch that somehow they managed to make the command line still available in plan9 but I haven't used it to know. I'm still curious how one would manage an oberon web server from afar, such as if you were in a different country, and had to log in to your computer remotely from 2500 miles away... do you do something like X11 and have a remote GUI session, or I guess maybe oberon operating systems haven't hit this speed bump yet... or no one has come across that problem yet.. You either have to remotely log in to a gui and send all the gui details over tcp/ip, or you just send commands/text over tcp/ip which is much more bandwidth efficient. i.e. ssh/telnet
On 13 December 2016 at 18:07, Lars <noreply@z505.com> wrote:
Would be interesting to see what approach Plan9 operating system took, since it was inspired by oberon but also inspired by unix.
So download it and run it in a VM. It's trivial to do so. Plan 9 is small and both it and VirtualBox are FOSS. I've done it myself. https://9p.io/plan9/download.html https://www.virtualbox.org/
I have a hunch that somehow they managed to make the command line still available in plan9 but I haven't used it to know.
It's a descendant of Unix. It has a Unix-like shell, just as Unix does.
I'm still curious how one would manage an oberon web server from afar, such as if you were in a different country, and had to log in to your computer remotely from 2500 miles away... do you do something like X11 and have a remote GUI session, or I guess maybe oberon operating systems haven't hit this speed bump yet... or no one has come across that problem yet..
Why would Oberon not be able to support protocols such as Telnet or SSH? Over that, a TUI could be shown and interacted with without particular difficulty -- but mouse support would be a problem. If some kind of keyboard-based control of a mouse pointer were enabled, such as is used by many disabled people to interact with GUIs, then it would not be a problem at all. For mouse support, VNC is simple, FOSS, and works with many widely different OSes. It's also a built-in feature of several hypervisors. It is as you say a lot less efficient, though, as much more data needs to be transferred. A specific protocol could be implemented, of course, sending text info but with mouse control -- but that presents a lot of issues of its own in terms of client support. -- Liam Proven • Profile: https://about.me/liamproven Email: lproven@cix.co.uk • Google Mail/Talk/Plus: lproven@gmail.com Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053
On Tue, Dec 13, 2016, 11:57 PM Liam Proven <lproven@gmail.com> wrote:
Why would Oberon not be able to support protocols such as Telnet or SSH? Over that, a TUI could be shown and interacted with without particular difficulty -- but mouse support would be a problem. If some kind of keyboard-based control of a mouse pointer were enabled, such as is used by many disabled people to interact with GUIs, then it would not be a problem at all.
It seems like there's at least three different concepts in this thread: 1) Chaining together simple commands to perform complex tasks, as exemplified by UNIX pipes. 2) Performing interactive or iterative tasks in Oberon without coding a formal solution. 3) Interacting with Oberon via some sort of shell. If you research #1, you'll find a book called Software Tools where the UNIX concept of "do one thing and do it well" was born, and they code in RATFOR in a handful of lines many of the tools we use today, before the concept of pipes. Pipes only augmented those tools, as discussed earlier. But, if you've ever done any Visual Basic scripting, you'll see some parallels with Oberon in that there's an initial pain point. My CV whine was always, "I don't want to have to create and destroy a dozen objects just to append text to a file." So I ended up writing functions to do the things I wanted that could be called in a sane fashion that hid all the mess. No different than what really happens when someone implements grep, and something I believe is still in the spirit of Oberon, seen in every Tool file. Thinking about #2, some people use Python as their interactive shell. When you look at the way they approach traditional UNIX workflows and problems, it's very different than the bash mindset. I think someone could write an interactive Oberon shell, but I don't think it would be as efficient as the TUI for the structure of the resulting code. Better would be to port or write a new shell. UNIX isn't born with a shell, it's just another program, often interchanged. A good place to start would be Inferno's rc shell, as Limbo and Oberon have some very strong similarities. But, like Inferno, a shell is just a shell, and familiar tools need to be reimplemented using the native language. You'll find their code for grep, cat, etc., but not sed, it was likely not worth the payoff to the implementation. Last, connectivity out is much different than connectivity in. Out is old hat, telnet was there in V2, I wrote a VT100 emulator back in the day, and can't imagine trying to tackle SSH in Oberon but it could be done. Connectivity in, for the whole experience it would be easier to construct by doing VNC via A2 or UNIX, but for an alternate experience I like the idea of exposing content or services via HTTP. I'm surprised no one has implemented a wiki in Oberon yet. -Jack
Treutwein Bernhard wrote:------------------ ]Since you can execute commands in any window (or viewer in ] Oberon terminology, any viewer is also a kind of a shell. There is ] a kind of a meta command executing commands written in a viewer. ] In A2/WinAos this meta command is: SystemTools.DoCommands and <--- *! ] It reads all commands until it encounters two ~ (possibly separated by ] white space). Normal commands terminate their parameters usually ] by a single ~. I tried to explain this before. ETHO often 'pipes' via a sequence of viewers, with some manual input to move on to the next stage. And I've done some experiments using <ET.Do> as a script, as described above: MarkPositionForViewer A Generate F1's output [to position A's viewer] MarkPositionForViewer A to be used as input for F2 Generate F2's output, to the next Viewer ....... I can't remember details now: the mark & delete Viewer enabled removing <pipe sections> that had finished their job, to make space for further stages. The important fact is that ETHO already uses the paradigm: Function1 | Function2 |.....FunctionN == Chris Glur.
participants (10)
-
Alexander Ilin -
Bob Walkden -
Chris Burrows -
Douglas G Danforth -
eas lab -
Jack Johnson -
Lars -
Liam Proven -
Skulski, Wojciech -
Treutwein Bernhard