Just read your answer about "RAISE notready", which makes a lot of sense in the
context of this
functionality! Causing any other conditions should then be reported.
---rony
On 28.04.2018 15:53, Rony G. Flatscher wrote:
> Trying to make the question clearer: while developing the code for the
> monitor's LINEIN method by
> accident I noticed that any error in this method will cause the input monitor
> to be regarded to be
> closed: in one version I was using a sysSleep() for a "randome(0,999)/1000"
> (note the trailing "e"
> in "randome(...)") which caused the program to end without any input and
> without any error message
> indicating that there was a coding error in the LINEIN method.
>
> ---rony
>
>
> On 28.04.2018 15:45, Rony G. Flatscher wrote:
>> Another question ad using a monitor for input: is it o.k. to cause an error
>> in the LINEIN method
>> by not returning a value, if the input monitor supplied all of its items as
>> input?
>>
>> Currently the following code works without raising a condition and causes
>> the end of input to be
>> noticed:
>>
>> ::method linein
>> expose log thisClzName rxq
>> val=rxq~pull
>> if val=.nil then return
>>
>> str=.dateTime~new thisClzName", received="pp(val,"{","}")
>> call lineout "stderr:", "--->" str "<---"
>> log~append(str)
>> return str
>>
>> "log" is an array, "rxq" a RexxQueue containing the data to be returned as
>> input for the
>> executing program/command one by one.
>>
>> ---rony
>>
>> P.S.: On a side-note: it is great that using monitors one can act in
>> "real-time" i.e. acting upon
>> output or error output.
>>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
