On 13.04.2018 17:11, Rick McGuire wrote:
> The RC value is handled exactly the same as a command without redirection
> since we're doing the
> piping rather than the command shell.
super, this is really great!
---rony
>
>
> On Fri, Apr 13, 2018 at 11:05 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at
> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> 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
