Re: [Oorexx-devel] Address With progress

On 25.04.2018 18:40, Erich Steinböck wrote: > > Erich will have to speak for the other platforms > > > Unix should be fine.  I just noticed that somehow the latest commit, fixing > the environment for > spawn, didn't come through - did the commit now. > > For Windows there may still be work

Re: [Oorexx-devel] Address With progress

It is in the InputRedirectory.cpp file. Rick On Wed, Apr 25, 2018 at 2:27 PM, Gil Barmwater wrote: > OK, thanks. I'm actually doing a redirect of input from a stream object > but I assume the argument is the same. And where do I look for the code > that reads that

Re: [Oorexx-devel] Address With progress

OK, thanks.  I'm actually doing a redirect of input from a stream object but I assume the argument is the same.  And where do I look for the code that reads that stream object? Gil On 4/25/2018 2:20 PM, Rick McGuire wrote: That is the correct behavior. If you are doing the output to a stream

Re: [Oorexx-devel] Address With progress

That is the correct behavior. If you are doing the output to a stream object directly rather than using the STREAM resource (or USING with a .File object), the stream is neither opened nor closed during the processing. In fact, an OutputStream object need not support a close method, so it would be

Re: [Oorexx-devel] Address With progress

All of the builds I have attempted were Windows REL32 but I've never experienced a hang at CreateProcess().  FWIW. I do have a question about a problem I'm seeing, however.  The scenario is as follows: I've modified the test bed I wrote for the package I presented at the Symposium so it would

Re: [Oorexx-devel] Address With progress

> > Erich will have to speak for the other platforms > Unix should be fine. I just noticed that somehow the latest commit, fixing the environment for spawn, didn't come through - did the commit now. For Windows there may still be work ahead. For me the new ADDRESS.testGroup doesn't run. But

Re: [Oorexx-devel] Address With progress

The docs are not written yet, but there are lots of examples of usage in the two test group files in the root of the source tree. In a nutshell, address env command with input resourcei output (REPLACE|APPEND) resourceo error (REPLACE|APPEND) resourseo resourcei can be STEM stemvarname STREAM

Re: [Oorexx-devel] Address With progress

Great! Where can one learn the available syntax? Currently, "https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0beta/rexxref.pdf; is from 2018-03-28 and does not have the new syntax documented. ---rony On 25.04.2018 13:59, Rick McGuire wrote: > Test away. I don't know of any

Re: [Oorexx-devel] Address With progress

Test away. I don't know of any pending work on Windows at least. Erich will have to speak for the other platforms. Rick On Wed, Apr 25, 2018 at 7:55 AM, Rony G. Flatscher wrote: > A question ad implementation status: is the functionality in trunk already > regarded to

Re: [Oorexx-devel] Address With progress

A question ad implementation status: is the functionality in trunk already regarded to be fully implemented and functional such that one can start to test it under Windows, Linux and MacOSX? ---rony On 21.04.2018 20:43, Gil Barmwater wrote: > > Yep! Got a clean build after I got ALL the

Re: [Oorexx-devel] Address With progress

Yep! Got a clean build after I got ALL the updates. Thanks. Gil On 4/21/2018 2:09 PM, Rick McGuire wrote: I’m guessing you ran the sun up from the wrong directory. You’re missing a lot of updates. On Sat, Apr 21, 2018 at 2:06 PM Gil Barmwater

Re: [Oorexx-devel] Address With progress

I’m guessing you ran the sun up from the wrong directory. You’re missing a lot of updates. On Sat, Apr 21, 2018 at 2:06 PM Gil Barmwater wrote: > Just finished updating to the latest sandbox revision - 11426 - and > attempted a 32-bit Windows build. The following

Re: [Oorexx-devel] Address With progress

Just finished updating to the latest sandbox revision - 11426 - and attempted a 32-bit Windows build.  The following errors were posted when compiling SystemCommands.cpp: E:\Sandbox\interpreter\platform\windows\SystemCommands.cpp(179): error C2065:

Re: [Oorexx-devel] Address With progress

> > Does that mean that in theory it also should work on Android? > No, not at this time. I found one source mentioning that the posix_spawn* family of calls would become available with Android P -- Check out the vibrant

Re: [Oorexx-devel] Address With progress

> > Unable to reproduce this on windows > CreateInterpreter() runs into a segmentation fault if there is no environment. Seems to be when for primitiveSearchName(BASEIMAGE,..) getenv("PATH") returns NULL. We had no environment in spawned commands because I thought if the appropriate arg was set

Re: [Oorexx-devel] Address With progress

Right now, monitor objects would not work (an oversight on my part). I'll look into adding them. Output should be easy. Input is sort of implicitly supported because the last step is to send a makeArray to the object. The reads from the pipes are done a buffer at a time and the error output that

Re: [Oorexx-devel] Address With progress

On 19.04.2018 19:21, Erich Steinböck wrote: > I just committed the Unix implementation of a redirecting system command > handler, that passes all > tests in (an updated) ADDRESS.testGroup. > > It handles OUTPUT in the main thread, and INPUT and ERROR in additional > threads when required. >

Re: [Oorexx-devel] Address With progress

On 19.04.2018 19:21, Erich Steinböck wrote: > I just committed the Unix implementation of a redirecting system command > handler, that passes all > tests in (an updated) ADDRESS.testGroup. > > It handles OUTPUT in the main thread, and INPUT and ERROR in additional > threads when required. >

Re: [Oorexx-devel] Address With progress

On Thu, Apr 19, 2018 at 1:21 PM, Erich Steinböck wrote: > I just committed the Unix implementation of a redirecting system command > handler, that passes all tests in (an updated) ADDRESS.testGroup. > > It handles OUTPUT in the main thread, and INPUT and ERROR in

Re: [Oorexx-devel] Address With progress

I just committed the Unix implementation of a redirecting system command handler, that passes all tests in (an updated) ADDRESS.testGroup. It handles OUTPUT in the main thread, and INPUT and ERROR in additional threads when required. (Handling OUTPUT in the main thread will allow Rexx code to get

Re: [Oorexx-devel] Address With progress

Yep, it probably should. I'll take a look at it. Rick On Mon, Apr 16, 2018 at 10:04 AM, Erich Steinböck < erich.steinbo...@gmail.com> wrote: > Should this print "line" twice? It currently prints two null strings. > > ~~~ > stem. = "line" > stem.0 = 2 > address "" "cat" with input using ( stem.

Re: [Oorexx-devel] Address With progress

I added a waitForTermination() method to SysThread...pretty trivial to do. The unix version hasn't even been compiled yet. Rick On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck wrote: > I have a working redirecting context on Ubuntu (no tests run yet). > But I guess

Re: [Oorexx-devel] Address With progress

We haven't needed it yet anywhere, but it looks fairly trivial to add a waitForTermination() method to the SysThread class. Unfortunately, I'm in the middle of migrating to a new PC, and neither my old PC or the new one is really functional at this time. Rick On Fri, Apr 13, 2018 at 6:40 PM,

Re: [Oorexx-devel] Address With progress

On Fri, Apr 13, 2018 at 6:40 PM, Erich Steinböck wrote: > >>- How do I wait for SysThreads to terminate? Or check if they're >>still running? >> >> For the Windows version, I called terminate on the thread object that >> will clean things up. >> > > When

Re: [Oorexx-devel] Address With progress

> > >- How do I wait for SysThreads to terminate? Or check if they're still >running? > > For the Windows version, I called terminate on the thread object that will > clean things up. > When terminate() returns, I know that dispatch() has finished? I believe I need to wait for dispatch()

Re: [Oorexx-devel] Address With progress

On Fri, Apr 13, 2018 at 6:00 PM, Erich Steinböck wrote: > What I did for Windows with the separate thread should be easily adapted >> for Linux > > I've rewritten the Linux handler with separate threads for INPUT and ERROR > (if requested), while handling OUTPUT in

Re: [Oorexx-devel] Address With progress

> > What I did for Windows with the separate thread should be easily adapted > for Linux I've rewritten the Linux handler with separate threads for INPUT and ERROR (if requested), while handling OUTPUT in the main thread. I'm just starting the first tests, and I've got a few questions. - How

Re: [Oorexx-devel] Address With progress

If you haven't already done so, the code I added has somecontext->RaiseCondition() method calls that should be reviewed for their appropriateness. Gil On 4/13/2018 11:57 AM, Rick McGuire wrote: ERROR and FAILURE conditions are related to the execution of the command itself. Other sorts of

Re: [Oorexx-devel] Address With progress

ERROR and FAILURE conditions are related to the execution of the command itself. Other sorts of failures in the redirection should probably be SYNTAX condition, probably in the Error_Execution category. Rick On Fri, Apr 13, 2018 at 11:37 AM, Erich Steinböck < erich.steinbo...@gmail.com> wrote:

Re: [Oorexx-devel] Address With progress

> > would the RC .. be the value from the executed command itself .. (rather > than from "rxqueue")? > Yes, the rc from the command. With this implementation rxqueue isn't involved at all, the redirection is done through Windows/Unix pipes. Q: With redirection we will have (potentially many, but

Re: [Oorexx-devel] Address With progress

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

Re: [Oorexx-devel] Address With progress

The RC value is handled exactly the same as a command without redirection since we're doing the piping rather than the command shell. Rick On Fri, Apr 13, 2018 at 11:05 AM, Rony G. Flatscher wrote: > Just a question ad "RC" (return code): would the RC value in Rexx

Re: [Oorexx-devel] Address With progress

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

Re: [Oorexx-devel] Address With progress

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

Re: [Oorexx-devel] Address With progress

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

Re: [Oorexx-devel] Address With progress

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

Re: [Oorexx-devel] Address With progress

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

Re: [Oorexx-devel] Address With progress

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

Re: [Oorexx-devel] Address With progress

On Thu, Apr 12, 2018 at 2:56 PM, Gil Barmwater 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

Re: [Oorexx-devel] Address With progress

Grrr, hit the wrong key again... On Thu, Apr 12, 2018 at 2:56 PM, Gil Barmwater 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. > >

Re: [Oorexx-devel] Address With progress

On Thu, Apr 12, 2018 at 2:56 PM, Gil Barmwater 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

Re: [Oorexx-devel] Address With progress

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"

Re: [Oorexx-devel] Address With progress

These sound like good questions to ask on StackOverflow. Rick On Thu, Apr 12, 2018 at 2:37 AM, Erich Steinböck wrote: > checking the code in as it is is also an option...it gets more eyeballs on >> the problem >> > I checked in the code for a Unix redirecting

Re: [Oorexx-devel] Address With progress

> > checking the code in as it is is also an option...it gets more eyeballs on > the problem > I checked in the code for a Unix redirecting command handler. It's still work-in-progress, not only because of some minor issues (e. g. Ctrl+C handling), but because some severe restrictions, that I know

Re: [Oorexx-devel] Address With progress

On Wed, Apr 11, 2018 at 2:26 PM Gil Barmwater 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

Re: [Oorexx-devel] Address With progress

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. -- -- Gil

Re: [Oorexx-devel] Address With progress

Yes, but Windows uses crlf makers for file i/o. Just \n is a *ix thing. However, if just a new line is expected in this situation on windows, I can simplify my code. In any event, I just committed the ReadInputBuffer change...currently returning crlf linends on Windows. Rick On Fri, Apr 6, 2018

Re: [Oorexx-devel] Address With progress

Thanks for the quick reply.  I may wait for the ReadInputBuffer() as it may make it more like my package code which takes an array, converts it to a string with embedded linends, and writes it in chunks to the pipe. On the subject of the "proper" linends, I would think that since this is

Re: [Oorexx-devel] Address With progress

Gil, ReadInput returns just the data for the next line, with no line terminator. You can include the line terminator by doing a second write for just the terminator. I am also working on a ReadInputBuffer() function that will allow you to obtain the entire redirected output as a single buffer.

Re: [Oorexx-devel] Address With progress

Rick, Thanks for that info.  I agree that we should see how it plays out with the default pipe buffer sizes and address it later if we encounter problems in practice. I'm working on the code to write the data to the input pipe. I've looked at the testCommandHandler() and found the

Re: [Oorexx-devel] Address With progress

Gil, Been doing a little reading on the Windows Pipe and I/O functions. and it appears you could also encounter a problem, though in a slightly different way. If you are still writing data to the pipe and the buffer is full, WriteFile() will block until the other end of the pipe reads enough data

Re: [Oorexx-devel] Address With progress

I also found this: https://linux.die.net/man/2/pipe2 which allows you to create the pipe as non blocking. Rick On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck wrote: > I have a working redirecting context on Ubuntu (no tests run yet). > But I guess I need to think

Re: [Oorexx-devel] Address With progress

On Thu, Apr 5, 2018 at 8:29 PM, Gil Barmwater wrote: > Let me start by saying that I know next to nothing about *ix but perhaps > the sequence in Windows may shed some light here. The example I used for > my package, and which is the basis of what I'm doing for

Re: [Oorexx-devel] Address With progress

Let me start by saying that I know next to nothing about *ix but perhaps the sequence in Windows may shed some light here.  The example I used for my package, and which is the basis of what I'm doing for ADDRESS...WITH on Windows, does the following: 1) create the pipes and pass the handles to

Re: [Oorexx-devel] Address With progress

This article seems to describe the exact situation you are dealing with: https://www.geeksforgeeks.org/non-blocking-io-with-pipes-in-c/ Rick On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck wrote: > I have a working redirecting context on Ubuntu (no tests run yet).

Re: [Oorexx-devel] Address With progress

On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck wrote: > I have a working redirecting context on Ubuntu (no tests run yet). > But I guess I need to think a little more about the blocking issue. > What we're doing here is, fork a child (which runs the command) and >

Re: [Oorexx-devel] Address With progress

On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck wrote: > I have a working redirecting context on Ubuntu (no tests run yet). > But I guess I need to think a little more about the blocking issue. > What we're doing here is, fork a child (which runs the command) and >

Re: [Oorexx-devel] Address With progress

I have a working redirecting context on Ubuntu (no tests run yet). But I guess I need to think a little more about the blocking issue. What we're doing here is, fork a child (which runs the command) and connect us to the child through at most three pipes. A stdin pipe, a stdout pipe, and an error

Re: [Oorexx-devel] Address With progress

>From the description in https://blog.uxul.de/e?e=mt-160 (very bottom) it seems "trivial" to do. Not a Linux guru at all, but I'd give it a try if no one else volunteers. The blog also contains a discussion of an interesting quirk with fork(), which is why the sample code uses POSIX spawn to

[Oorexx-devel] Address With progress

I still have to write a bunch of unit tests for the global Address With setup and overrides, but all of the base redirection mechanisms are now passing the unit tests. The missing piece right now is the redirection in the system handlers. Any Linux gurus out there willing to take a look at how to