Just a question ad "RC" (return code): would the RC value in Rexx upon return
from the command be
the value from the executed command itself in all of these scenarios (rather
than from "rxqueue")?
---rony
On 13.04.2018 13:12, Rick McGuire wrote:
> I hate it when code compiles and runs on the first attempt :-) Just moved the
> pipe reading code to
> before wait for process termination and the big data test case started
> working. Erich, What I did
> for Windows with the separate thread should be easily adapted for Linux.
>
> Rick
>
> On Fri, Apr 13, 2018 at 6:58 AM, Rick McGuire <object.r...@gmail.com
> <mailto:object.r...@gmail.com>> wrote:
>
> Ok, I have things working with a separate thread filling the input pipe,
> but I'm able to get a
> hang with a simple example (see below). As I suspected, the problem is
> caused by waiting for
> the process to complete before reading from the output pipe. The command
> process stalls when
> the pipe gets filled and waits until data is read from the pipe. So, the
> process never
> terminates because it is waiting for the pipe to be cleared out. The
> attached programs work
> fine with much smaller amounts of data.
>
> test.rex
>
> a1=.array~new(100000)
> a1~fill('This is a test')
>
> addresscommand'rexx flipit.rex'withinputusing(a1) outputstema.
> saya.0
>
> flipit.rex
>
> signalonnotready
>
> loopforever
> sayreverse(linein())
> end
>
> notready:
>
> Rick
>
> On Thu, Apr 12, 2018 at 7:59 PM, Gil Barmwater <gbarmwa...@alum.rpi.edu
> <mailto:gbarmwa...@alum.rpi.edu>> wrote:
>
> 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
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
