Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Rony G. Flatscher 
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 ahead. For me the new ADDRESS.testGroup 
> doesn't run.
> But then I do have a very strange issue with addressWith Debug builds: each 
> time a new rexx.exe is
> built, it will hang for a full minute (60 seconds exactly) at CreateProcess() 
> in the command
> handler (for any arbitrary command) before continuing.  This may repeat two 
> or three times, until
> it starts behaving normally again (no delay by CreateProcess).  The issue 
> will reappear as soon as
> I build a new version.
> This issue doesn't happen for Debug builds of trunk, and I've never witnessed 
> it before.
> I treid swapping back the old command handler (all other Rick's changes still 
> in place), but even
> then the issue is still there.
Your commit  also removed the 
test command handler
from Windows 
(sandbox/rick/addresswith/interpreter/platform/windows/SystemCommands.cpp), 
which
ADDRESS.testGroup seems to depend on.

---rony

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

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Rick McGuire 
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 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
> 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 wrong to attempt it.
>
> Rick
>
> On Wed, Apr 25, 2018 at 2:15 PM, Gil Barmwater 
> wrote:
>
>> 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 run ADDRESS ... WITH commands
>> instead.  All of my tests run except when I run two particular tests
>> consecutively.  Each test runs fine standalone.  Both tests use a file
>> called 'abc1.txt' which contains 4 lines of rexx instructions, the last
>> being 'exit'.  The first test issues > using (smallFile)>, having first done > .stream~new('abc1.txt')>.  In other words, redirecting Input to a stream
>> object.  That works as expected.  The second test issues > abc1.txt with ...> .  When run alone, it too, works as expected but if run
>> immediately after the first test, it gets > initialization: File "C:\Rexx\projects\addresswith\abc1.txt" is
>> unreadable.>  Suspecting the file may not have been closed by the first
>> test, I added a  immediately after the address ... with in
>> that test and that fixed the problem.  I attempted to find where the input
>> stream object was processed in the C++ code but got lost .  Any
>> suggestions would be appreciated.
>>
>> BTW, I saw all the work that has gone into the address.testgroup and was
>> very impressed! Nice work!
>> Gil
>>
>> On 4/25/2018 12:40 PM, 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 ahead. For me the new
>> ADDRESS.testGroup doesn't run.
>> But then I do have a very strange issue with addressWith Debug builds:
>> each time a new rexx.exe is built, it will hang for a full minute (60
>> seconds exactly) at CreateProcess() in the command handler (for any
>> arbitrary command) before continuing.  This may repeat two or three times,
>> until it starts behaving normally again (no delay by CreateProcess).  The
>> issue will reappear as soon as I build a new version.
>> This issue doesn't happen for Debug builds of trunk, and I've never
>> witnessed it before.
>> I treid swapping back the old command handler (all other Rick's changes
>> still in place), but even then the issue is still there.
>>
>>
>> --
>> 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 
>> listOorexx-devel@lists.sourceforge.nethttps://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
>>
>>
>
>
> --
> 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 
> listOorexx-devel@lists.sourceforge.nethttps://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
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Gil Barmwater 
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 
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 wrong to attempt it.


Rick

On Wed, Apr 25, 2018 at 2:15 PM, Gil Barmwater 
mailto:gbarmwa...@alum.rpi.edu>> wrote:


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 run ADDRESS ...
WITH commands instead.  All of my tests run except when I run two
particular tests consecutively.  Each test runs fine standalone. 
Both tests use a file called 'abc1.txt' which contains 4 lines of
rexx instructions, the last being 'exit'.  The first test issues
, having
first done . In other words,
redirecting Input to a stream object. That works as expected.  The
second test issues  .  When
run alone, it too, works as expected but if run immediately after
the first test, it gets   Suspecting the file may not have been closed by the
first test, I added a  immediately after the
address ... with in that test and that fixed the problem.  I
attempted to find where the input stream object was processed in
the C++ code but got lost . Any suggestions would be
appreciated.

BTW, I saw all the work that has gone into the address.testgroup
and was very impressed! Nice work!

Gil

On 4/25/2018 12:40 PM, 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 ahead. For me the new
ADDRESS.testGroup doesn't run.
But then I do have a very strange issue with addressWith Debug
builds: each time a new rexx.exe is built, it will hang for a
full minute (60 seconds exactly) at CreateProcess() in the
command handler (for any arbitrary command) before continuing. 
This may repeat two or three times, until it starts behaving
normally again (no delay by CreateProcess). The issue will
reappear as soon as I build a new version.
This issue doesn't happen for Debug builds of trunk, and I've
never witnessed it before.
I treid swapping back the old command handler (all other Rick's
changes still in place), but even then the issue is still there.



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





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

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Rick McGuire 
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 wrong to attempt it.

Rick

On Wed, Apr 25, 2018 at 2:15 PM, Gil Barmwater 
wrote:

> 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 run ADDRESS ... WITH commands instead.  All of
> my tests run except when I run two particular tests consecutively.  Each
> test runs fine standalone.  Both tests use a file called 'abc1.txt' which
> contains 4 lines of rexx instructions, the last being 'exit'.  The first
> test issues , having
> first done .  In other words,
> redirecting Input to a stream object.  That works as expected.  The second
> test issues  .  When run alone, it too,
> works as expected but if run immediately after the first test, it gets
>  "C:\Rexx\projects\addresswith\abc1.txt" is unreadable.>  Suspecting the
> file may not have been closed by the first test, I added a
>  immediately after the address ... with in that test and
> that fixed the problem.  I attempted to find where the input stream object
> was processed in the C++ code but got lost .  Any suggestions would
> be appreciated.
>
> BTW, I saw all the work that has gone into the address.testgroup and was
> very impressed! Nice work!
> Gil
>
> On 4/25/2018 12:40 PM, 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 ahead. For me the new
> ADDRESS.testGroup doesn't run.
> But then I do have a very strange issue with addressWith Debug builds:
> each time a new rexx.exe is built, it will hang for a full minute (60
> seconds exactly) at CreateProcess() in the command handler (for any
> arbitrary command) before continuing.  This may repeat two or three times,
> until it starts behaving normally again (no delay by CreateProcess).  The
> issue will reappear as soon as I build a new version.
> This issue doesn't happen for Debug builds of trunk, and I've never
> witnessed it before.
> I treid swapping back the old command handler (all other Rick's changes
> still in place), but even then the issue is still there.
>
>
> --
> 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 
> listOorexx-devel@lists.sourceforge.nethttps://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
>
>
--
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

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Gil Barmwater 
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 run ADDRESS ... WITH commands 
instead.  All of my tests run except when I run two particular tests 
consecutively.  Each test runs fine standalone. Both tests use a file 
called 'abc1.txt' which contains 4 lines of rexx instructions, the last 
being 'exit'.  The first test issues input using (smallFile)>, having first done .stream~new('abc1.txt')>.  In other words, redirecting Input to a stream 
object.  That works as expected.  The second test issues rexx abc1.txt with ...> .  When run alone, it too, works as expected but 
if run immediately after the first test, it gets during initialization: File "C:\Rexx\projects\addresswith\abc1.txt" is 
unreadable.> Suspecting the file may not have been closed by the first 
test, I added a  immediately after the address ... with 
in that test and that fixed the problem.  I attempted to find where the 
input stream object was processed in the C++ code but got lost .  
Any suggestions would be appreciated.


BTW, I saw all the work that has gone into the address.testgroup and was 
very impressed! Nice work!


Gil
On 4/25/2018 12:40 PM, 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 ahead. For me the new 
ADDRESS.testGroup doesn't run.
But then I do have a very strange issue with addressWith Debug builds: 
each time a new rexx.exe is built, it will hang for a full minute (60 
seconds exactly) at CreateProcess() in the command handler (for any 
arbitrary command) before continuing.  This may repeat two or three 
times, until it starts behaving normally again (no delay by 
CreateProcess).  The issue will reappear as soon as I build a new version.
This issue doesn't happen for Debug builds of trunk, and I've never 
witnessed it before.
I treid swapping back the old command handler (all other Rick's 
changes still in place), but even then the issue is still there.



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

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Erich Steinböck 
>
> 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 then I do have a very strange issue with addressWith Debug builds: each
time a new rexx.exe is built, it will hang for a full minute (60 seconds
exactly) at CreateProcess() in the command handler (for any arbitrary
command) before continuing.  This may repeat two or three times, until it
starts behaving normally again (no delay by CreateProcess).  The issue will
reappear as soon as I build a new version.
This issue doesn't happen for Debug builds of trunk, and I've never
witnessed it before.
I treid swapping back the old command handler (all other Rick's changes
still in place), but even then the issue is still there.
--
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

[Oorexx-devel] Fwd: Address With progress

2018-04-25 Thread Rony G. Flatscher 
Forwarding to the list as mistakingly the follow-ups were not directed at the 
ooRexx developer list.

Many thanks again.

---rony



 Forwarded Message 
Subject:Re: [Oorexx-devel] Address With progress
Date:   Wed, 25 Apr 2018 09:12:11 -0400
From:   Rick McGuire 
To: Rony G. Flatscher 



Oops, RexxQueue objects can also be used with USING for both input and output. 

Rick

On Wed, Apr 25, 2018 at 9:10 AM, Rony G. Flatscher mailto:rony.flatsc...@wu.ac.at>> wrote:

Great, thank you *very* much!

---rony


On 25.04.2018 14:57, Rick McGuire wrote:
> 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 cexpr
> USING cexpr
>
> cexpr is the same sort of expression used with USE ARG default values or 
> the subkeyword
> expressions on RAISE and FORWARD.
>
> With USING, the expression is evaluated and the source determined by the 
> type of the result:
>
> 1) a string. Just the string value it written to the input pipe. Useful 
> if you only need to
> send one line. 
> 2) a stem object. Same as using the STEM option
> 3) a File object. Same as the STREAM option
> 4) an object that implements InputStream or a Monitor object. data is 
> obtained via LINEIN methods.
> 5) the object is requested as an array, and if successfully converted, 
> the array lines are used. 
>
> resourceo can be
>
> STEM stemvarname
> STREAM cexpr
> USING cexpr
>
> USING options are 
>
> 1) a stem object
> 2) a File object 
> 3) an object that implements OutputStream or a Monitor. Lineout is used 
> 4) an object that is an OrderedCollection. lines are added using APPEND.
>
> Special note: if the same object is used for both input and output, the 
> output is buffered to
> avoid conflicts. 
>
> Rick
>
> On Wed, Apr 25, 2018 at 8:33 AM, Rony G. Flatscher 
>  > wrote:
>
> 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 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 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 updates. Thanks.
>> >
>> > Gil
>>


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

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Rick McGuire 
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 cexpr
USING cexpr

cexpr is the same sort of expression used with USE ARG default values or
the subkeyword expressions on RAISE and FORWARD.

With USING, the expression is evaluated and the source determined by the
type of the result:

1) a string. Just the string value it written to the input pipe. Useful if
you only need to send one line.
2) a stem object. Same as using the STEM option
3) a File object. Same as the STREAM option
4) an object that implements InputStream or a Monitor object. data is
obtained via LINEIN methods.
5) the object is requested as an array, and if successfully converted, the
array lines are used.

resourceo can be

STEM stemvarname
STREAM cexpr
USING cexpr

USING options are

1) a stem object
2) a File object
3) an object that implements OutputStream or a Monitor. Lineout is used
4) an object that is an OrderedCollection. lines are added using APPEND.

Special note: if the same object is used for both input and output, the
output is buffered to avoid conflicts.

Rick

On Wed, Apr 25, 2018 at 8:33 AM, Rony G. Flatscher 
wrote:

> 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 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 <
> rony.flatsc...@wu.ac.at> wrote:
>
>> 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 updates. Thanks.
>> >
>> > Gil
>>
>
>
> 
> --
> 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
>
>
--
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

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Rony G. Flatscher 
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 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 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 updates. Thanks.
> >
> > Gil
>

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

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Rick McGuire 
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 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 updates. Thanks.
> >
> > Gil
>
>
> 
> --
> 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
>
--
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

Re: [Oorexx-devel] Address With progress

2018-04-25 Thread Rony G. Flatscher 
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 updates. Thanks.
>
> Gil


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

Re: [Oorexx-devel] USE ARG default values with references.

2018-04-25 Thread Rony G. Flatscher 
Just to make sure that no other misunderstanding occurs: the default value in 
USE ARG has been
used/applied by ooRexx only, if an argument value was left out when invoking 
the routine.

In the current implementation of a variable reference argument must be always 
supplied or otherwise
a runtime error occurs. Hence running:

call test

::routine test
  use arg >a
  a="value from test"
  return

will yield the error:

Error 88 running E:\sandbox_ooRexx\test_a.rex line 4:  Invalid argument.
Error 88.931:  The 1 was omitted. A VariableReference argument is required.

The current implementation will therefore enforce that a variable reference 
value gets always supplied.

---

If a variable reference is supplied, then the argument exists and no defined 
default value should be
applied. Whether the supplied variable reference argument is an alias to an 
uninitialized variable
in the caller or not should not matter, even if that context can be determined.

Hence the current error message for a program like:

say "1. a="a   -- uninitialized variable
call test >a   -- call by VariableReference
say "2. a="a   -- value from assignment in test()

::routine test
  use arg >test="some default value" -- alias the variable reference
  return

yielding the error message:

Error 99 running E:\sandbox_ooRexx\test_b.rex line 6:  Translation error.
Error 99.950:  A USE ARG default value is not allowed for variable 
references.

is therefore the behavior that I would expect.

---

As mentioned, whether the supplied variable reference argument is an alias to 
an uninitialized
variable in the caller or not should not matter. Hence the following program:

say "1. a="a   -- uninitialized variable
call test >a   -- call by VariableReference
say "2. a="a   -- value from assignment in test()

::routine test
  use arg >test-- alias the variable reference
  test="value from test()" -- assign alias variable a new value
  return

yields the expected output:

1. a=A
2. a=value from test()

---

This feature IMHO is very well thought out and extremely helpful e.g. in 
situations where one
creates Rexx packages with closely related/coupled functionality, where in the 
implementations
variable references can help a lot in different use cases, including cases 
where multiple variables
from the caller should be referenced/aliased such that they get directly 
updated in the called routines!

---rony



On 18.04.2018 16:34, Rony G. Flatscher wrote:
> On 17.04.2018 18:53, Rick McGuire wrote:
>> No, you are not understanding the question. If you use 
>>
>> USE ARG >someVar
>>
>> Then the argument is always required.
> If that is the case then I would be surprised that although an argument was 
> supplied
> (unexpectedly) a default value gets applied instead (as you write in your 
> last sentence).
>
> My take, misunderstanding was linked to the expectation that the default 
> value gets applied only,
> if the argument is left out, and then it is just would be a local variable 
> and not a variable
> alias to the caller supplied variable reference. (Expecting that if an 
> argument is supplied, then
> it must be a VariableReference, be it to an initialized or uninitialized one 
> would not matter.)
>
> ---rony
>
>
>> An error will be raised if one is not provided and the reference is not to a 
>> matching type. Right
>> now, if you use ">", the default value expression is not allowed. However, I 
>> was thinking of the
>> situation where the variable being referenced does not have an assigned 
>> value, so it might make
>> sense to initialize that variable to some default value. However, as I was 
>> typing this
>> explanation, I realized that because of the way stem variables are handled, 
>> there would never be
>> a case where a referenced stem variable would not have a backing value, so 
>> it definitely would
>> not apply. 
>>
>> On the other hand, since we know at parsing time what type of variable this 
>> is going to be, it
>> would still be possible to support this for simple variables. My biggest 
>> reservation is that this
>> somewhat redefines the meaning of the default value. 
>>
>> Rick 
>>
>> On Tue, Apr 17, 2018 at 12:33 PM, Rony G. Flatscher > > wrote:
>>
>>
>> On 17.04.2018 16:18, Rick McGuire wrote:
>>> Now that the spelling of the character has been sorted out, does 
>>> anybody have an opinion on
>>> the actual question of this thread?
>>>
>>> Rick
>>>
>>> On Sun, Apr 15, 2018 at 7:45 AM, Rick McGuire >> > wrote:
>>>
>>> I have one additional open issue with my variable references 
>>> prototype, and that's
>>> whether to support a default value or not on USE ARG if aliasing is 
>>> requested.  Right
>>> now I don't support it at all.  
>>>
>>> There is a case for supporting a default value that would b