You are correct on the placement of the APPEND|REPLACE keywords. I
somehow misread the BNF :-( . As for the required parenthesis around
the variable name, this will be a difference, I suspect, between ooRexx
and Regina that we need to clearly document, probably by including an
example showing that usage. And I have no problem with the required dot
after stem objects (as in using (foo.)) but 'output stem s' seems to me
unambiguous as the keyword 'stem' indicates the name 's' is the name of
a stem. Just my opinion.
I access the pipes the same way the sample code I found did, with the
ReadFile() and WriteFile() functions. As I said earlier, I hadn't
tested large amounts of redirected output data so the problem didn't
arise during my development and testing. The sample code didn't
actually do a wait so that was something I added without thinking about
the full pipe scenario. I believe a loop with a timed wait and pipe
reads (and buffered output writes) might address this but I haven't had
time to experiment with it yet. However, even that approach won't cover
the case where the code blocks writing to the input pipe since we
wouldn't get to the wait loop until the input data is all written.
Sounds like the thread approach might be the most straightforward way to
go.
Gil
On 4/12/2018 5:39 PM, Rick McGuire wrote:
It looks like spinning off a thread to do this is pretty easy using
the classes we already have. Gil, what commands have you been using to
test both ends of the pipe?
Also, I notice that the code waits for the process to complete before
reading the output pipes. Shouldn't it be reading before the process
completes? Otherwise, a command that creates a large amount of output
will fill the pipe up.
Rick
On Thu, Apr 12, 2018 at 5:03 PM, Rick McGuire <object.r...@gmail.com
<mailto:object.r...@gmail.com>> wrote:
I decided to post a question to StackOverflow to see if anybody
has an suggestions. I'm sort of thinking the solution might be to
spin off a thread to handle the writes to the buffer so that the
main thread can immediately start emptying the output pipes. I
think I'll try taking a stab at this for the Windows version.
Rick
On Thu, Apr 12, 2018 at 2:56 PM, Gil Barmwater
<gbarmwa...@alum.rpi.edu <mailto:gbarmwa...@alum.rpi.edu>> wrote:
Found and fixed the problem and have been through all my tests
that I developed for my proof of concept package. In the
process, I found several things I wasn't expecting.
1) The parser seems to have reversed the expected positions of
the target type - STEM, STREAM, or USING - and the "mode" -
APPEND or REPLACE. I believe the syntax per the ANSI standard
should be e.g. WITH OUTPUT STEM APPEND someStem. and not WITH
OUTPUT APPEND STEM someStem.
2) There seems to be a requirement for the stream/stem name to
be either a literal - "abc.txt" - or if it is a variable,
enclosed in parenthesis - (someFile). I expected the () for
USING but not for STEM or STREAM.
3) My package allowed for stem "names" to be specified with or
without the trailing . but my testing shows the trailing . is
required or an error message is generated. I'm OK with that
as long as it is documented.
4) I get an error (unable to open ... for output) when I specify
output stream "abc2.txt" error replace stream "abc2.txt"
which was testing the redirection of both output and error to
the same stream.
5) Using a non-existent file for redirected input generates an
error (unable to open ... for reading) while my package
treated this as a null file. Probably not a problem as the
error message would flag a file name typo :-)
As for checking in the code, I am not a committer so I plan to
generate a patch file and attach it to RFE 4.
One other item that I discovered is that I can get a deadlock
in Windows as well. I had not tested sending a lot of data to
redirected output but when I did, my package locked up,
presumably due to the output pipe being full. I plan to
experiment with ways around this but will generate the patch
file with the code as it stands now.
Gil
On 4/11/2018 2:32 PM, Rick McGuire wrote:
On Wed, Apr 11, 2018 at 2:26 PM Gil Barmwater
<gbarmwa...@alum.rpi.edu <mailto:gbarmwa...@alum.rpi.edu>> wrote:
Just a quick update on my progress so far. I've gotten
all the code in
(hopefully) the right places and I have a clean build.
My initial tests
are working but I've just hit my first problem which I
need to debug.
Hopefully, it will not be too much longer before I'm done.
checking the code in as it is is also an option...it gets
more eyeballs on the problem
Rick
--
--
Gil Barmwater
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the
world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
<mailto:Oorexx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
<https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
<mailto:Oorexx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
<https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
--
Gil Barmwater
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
<mailto:Oorexx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
<https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Gil Barmwater
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
