Re: [Oorexx-users] Need help reading,writing to a "com" port

[Moritz Hoffmann]

On Thu, Feb 4, 2016 at 4:33 AM, Les Koehler  wrote:

> Where is the advertisement after your signature coming from?


It's Sourceforge adding the advertisements. That's another reason why I'm
advocating switching to a different host.
Moritz
-- 
Moritz Hoffmann;
http://antiguru.de/
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Re: [Oorexx-users] Need help reading,writing to a "com" port

[CVBruce]

Test Reply w/o advert
> On Feb 4, 2016, at 6:45 AM, Les Koehler  wrote:
> 
> Thanks, Moritz! Yes, that would be a good reason to switch hosts. That's
> anti-social behavior by SF :-(
> 
> It's hard to imagine the totality of the additional network load for
> every list and every subscriber that they have!
> 
> Now we all have to remember to *remove* the advertisement when we Reply.
> 
> Les



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Re: [Oorexx-users] Need help reading,writing to a "com" port

[Chip Davis]

Didn't seem to work, unless you meant "... w/o Les' appended advert". 
  It certainly didn't prevent SF from appending one to your note... :-(

-Chip-

On 2/4/2016 7:06 PM, CVBruce wrote:
> Test Reply w/o advert
>> On Feb 4, 2016, at 6:45 AM, Les Koehler  wrote:
>>
>> Thanks, Moritz! Yes, that would be a good reason to switch hosts. That's
>> anti-social behavior by SF :-(
>>
>> It's hard to imagine the totality of the additional network load for
>> every list and every subscriber that they have!
>>
>> Now we all have to remember to *remove* the advertisement when we Reply.
>>
>> Les
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>
>
>
> ___
> Oorexx-users mailing list
> Oorexx-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-users
>

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Re: [Oorexx-users] (no subject)

[Les Koehler]

Chip,

The trouble with this suggestion is that a simple typo could *create* a 
new directory, which must then be manually deleted.
Of course one could make the same mistrake with "mkdir" itself, but 
there the irror would be more obvious :-)

Les

On 2/4/2016 1:26 PM, Chip Davis wrote:
> IMHO this is a software blivet (Def: "50 kg of manure in a 40 kg bag").
>
> The DIRECTORY() function is trying to do three things with the ability
> to return only one string:
> 1. Return the current directory
> 2. Create a new directory
> 3. Change to a new directory
>
> This is at least one operation too many, because the returned string
> that makes sense for one operation does not make sense for others.
>
> I argue that is should _always_ return the current directory, because
> that is its default behavior, and to make it easy to revert to that
> directory after (potentially) changing it.
>
> That does not eliminate the possibility of indicating whether or not
> the creation of a new directory was successful.
>
> So if I had designed that routine, here is the set of behaviors:
>
> DIRECTORY() returns current directory
>
> DIRECTORY('existing-dir') returns current directory, then makes
> 'existing-dir' the current directory
>
> DIRECTORY('new_dir') returns current directory, then creates
> 'new-dir', then makes 'new-dir' the current directory IFF creation
> successful
>
> Because of the aggregation of the three operations, when changing
> directories a prudent programmer should always compare the response
> from DIRECTORY() to see if it matches the argument passed.  If so, the
> operation was successful.
>
> If not, either something happened to 'existing-dir', or the creation
> of 'new-dir' was not successful.  Regardless, further operations to
> that directory should not be attempted.
>
> This is no more effort that testing for a null string returned value
> and far more consistent.
>
> -Chip-
>
> On 2/4/2016 10:42 AM, Les Koehler wrote:
>> I find the Regina OS/2 Help just as  confusing! First, it starts with a
>> simple declarative and non-contradictory sentence:
>>
>> - clip -
>> Returns the current directory for the running process, and optionally
>> changes directory to the specified new directory.
>> - eclip -
>>
>> I've seen this technique in ooRexx before and it's quite logical. It
>> provides, in one operation, the name of the directory to restore *and*
>> switches to the new (presumably valid) directory. Neat!
>>
>> However, the sentences that follow *modify* the previous declarative
>> sentence, thus creating confusion:
>>
>> - clip -
>> If the new directory
>> exists, and the change to new directory succeeds, the new directory is
>> returned. If the new directory does not exist or an error occurred changing
>> to that new directory, the empty string is returned.
>> - eclip -
>>
>> The original Object Rexx Beta Draft was much clearer:
>>
>> - clip -
>> returns the current directory, first changing it to NewDirectory if an
>> argument is supplied and the named directory exists. If NewDirectory is
>> not specified, the name of the current directory is returned. Otherwise,
>> an attempt is made to change to the specified NewDirectory. If
>> successful, the name of the NewDirectory is returned; if an error
>> occurred, null is returned.
>> - eclip -
>>
>> Maybe its just me, but this is a prime example of non-professional
>> writers trying to *improve* what an expert writer wrote to begin with!
>> Generally speaking, we should guard against such changes.
>>
>> Les
>>
>>
>>
>> On 2/4/2016 2:59 AM, Jon Wolfers wrote:
>>> Hi Bert,
>>>
>>> this thread has suddenly become quite complex and sensitive.  I hope that
>>> the nuances in my reply come through.
>>>
>>> Firstly, I did see your response about your experience on VM.  I would not
>>> expect VM to behave in the same way as Windows.  The filesystem is
>>> different.  It is nearly a quarter century since I had my hands on a VM
>>> system, but I don't remember there being a directory structure at all just
>>> filename filetype and Disk[mode] - perhaps I'm remembering wrong.
>>>
>>> Secondly, the code as you posted it doesn't demonstrate how the directory
>>> function actually behaved at that  time, in fact, reading your post I can't
>>> even be certain of how you expected it to behave.  I read several
>>> possibilities into this scenario, including one where the documentation was
>>> just as ambiguous then, and the interpreter writers intention was the same
>>> then as the observed behaviour today.
>>>
>>> You say "all implementations of the language should match" and you go on to
>>> establish a principle of prior precedent.  Now I don't know what you mean
>>> by 'should', I would agree that *gratuitous* change should be avoided.  I
>>> think that the reason that this is desirable is not because the language
>>> needs to be fixed in stone, but because changes cause programs out there to
>>> 

Re: [Oorexx-users] Need help reading,writing to a "com" port

[Les Koehler]

Thanks, Moritz! Yes, that would be a good reason to switch hosts. That's 
anti-social behavior by SF :-(

It's hard to imagine the totality of the additional network load for 
every list and every subscriber that they have!

Now we all have to remember to *remove* the advertisement when we Reply.

Les

On 2/4/2016 4:42 AM, Moritz Hoffmann wrote:
> On Thu, Feb 4, 2016 at 4:33 AM, Les Koehler  wrote:
>
>> Where is the advertisement after your signature coming from?
>
>
> It's Sourceforge adding the advertisements. That's another reason why I'm
> advocating switching to a different host.
> Moritz

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Re: [Oorexx-users] (no subject)

[Les Koehler]

I find the Regina OS/2 Help just as  confusing! First, it starts with a 
simple declarative and non-contradictory sentence:

- clip -
Returns the current directory for the running process, and optionally
changes directory to the specified new directory.
- eclip -

I've seen this technique in ooRexx before and it's quite logical. It 
provides, in one operation, the name of the directory to restore *and* 
switches to the new (presumably valid) directory. Neat!

However, the sentences that follow *modify* the previous declarative 
sentence, thus creating confusion:

- clip -
If the new directory
exists, and the change to new directory succeeds, the new directory is
returned. If the new directory does not exist or an error occurred changing
to that new directory, the empty string is returned.
- eclip -

The original Object Rexx Beta Draft was much clearer:

- clip -
returns the current directory, first changing it to NewDirectory if an 
argument is supplied and the named directory exists. If NewDirectory is 
not specified, the name of the current directory is returned. Otherwise, 
an attempt is made to change to the specified NewDirectory. If 
successful, the name of the NewDirectory is returned; if an error 
occurred, null is returned.
- eclip -

Maybe its just me, but this is a prime example of non-professional 
writers trying to *improve* what an expert writer wrote to begin with! 
Generally speaking, we should guard against such changes.

Les



On 2/4/2016 2:59 AM, Jon Wolfers wrote:
> Hi Bert,
>
> this thread has suddenly become quite complex and sensitive.  I hope that
> the nuances in my reply come through.
>
> Firstly, I did see your response about your experience on VM.  I would not
> expect VM to behave in the same way as Windows.  The filesystem is
> different.  It is nearly a quarter century since I had my hands on a VM
> system, but I don't remember there being a directory structure at all just
> filename filetype and Disk[mode] - perhaps I'm remembering wrong.
>
> Secondly, the code as you posted it doesn't demonstrate how the directory
> function actually behaved at that  time, in fact, reading your post I can't
> even be certain of how you expected it to behave.  I read several
> possibilities into this scenario, including one where the documentation was
> just as ambiguous then, and the interpreter writers intention was the same
> then as the observed behaviour today.
>
> You say "all implementations of the language should match" and you go on to
> establish a principle of prior precedent.  Now I don't know what you mean
> by 'should', I would agree that *gratuitous* change should be avoided.  I
> think that the reason that this is desirable is not because the language
> needs to be fixed in stone, but because changes cause programs out there to
> break.
>
> I don't know how the directory BIF worked on Object Rexx for OS/2 or the
> system interpeter on VM, but I have verified to my satisfaction by looking
> at the code in the ooRexx repository that the current behaviour has been
> present on ooRexx for Windows and Linux for at least the last eight years,
> and possibly more.
>
> I don't know how other interpreters work - although looking at the manuals
> I have for Personal Rexx & Kexx I see that they each handle this very
> differently.  Regina appears to have a directory BIF for OS/2 only and the
> helpfile seems to indicate that the behaviour in Regina for OS/2 is exactly
> the same as what happens in ooRexx currently.  I hope Mark doesn't mind,
> but I quote the Regina OS/2 help below.
>
> Now, given that it isn't possible to have all rexx interpreters working
> exactly the same, because we see such a spread of behaviour, and that the
> current behaviour in ooRexx for Windows and Linux has been in place for a
> long time, I would say that changing this behaviour to match some behaviour
> that might have existed on some interpreter on some platform in the past
> would break more currently active code than recognising that this change
> may have occurred in the past and that the helpfile is ambiguous and
> correcting the helpfile suitably.
>
> I hope that that makes my position on this clear.  Sorry if it opens a can
> of worms.
>
> Jon
>
>
> Regina's Directory BIF for OS/2 helpfile:
>
>> DIRECTORY([new directory]) - (OS/2)
>> Returns the current directory for the running process, and optionally
>> changes directory to the specified new directory. If the new directory
>> exists, and the change to new directory succeeds, the new directory is
>> returned. If the new directory does not exist or an error occurred changing
>> to that new directory, the empty string is returned.
>
>
>
> On 4 February 2016 at 02:03, Bertram Moshier 
> wrote:
>
>> Hi Jon,
>>
>> .
>>> I would say that this is a documentation bug as the documentation lists
>>> two different behaviours which can't both be right, and the code only
>>> displays 

Re: [Oorexx-users] (no subject)

[Walter Pachl]

Reasonable (but wishful) thinking...
This reminds me of the value bif
(returns current value and optionally sets the new value)
Greetings
Walter


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Re: [Oorexx-users] (no subject)

[Jon Wolfers]

- clip -
returns the current directory, first changing it to NewDirectory if an
argument is supplied and the named directory exists. If NewDirectory is not
specified, the name of the current directory is returned. Otherwise, an
attempt is made to change to the specified NewDirectory. If successful, the
name of the NewDirectory is returned; if an error occurred, null is
returned.
- eclip -

Yes, I agree the text you found is clearer.

Jon

On 4 February 2016 at 15:42, Les Koehler  wrote:

> I find the Regina OS/2 Help just as  confusing! First, it starts with a
> simple declarative and non-contradictory sentence:
>
> - clip -
> Returns the current directory for the running process, and optionally
> changes directory to the specified new directory.
> - eclip -
>
> I've seen this technique in ooRexx before and it's quite logical. It
> provides, in one operation, the name of the directory to restore *and*
> switches to the new (presumably valid) directory. Neat!
>
> However, the sentences that follow *modify* the previous declarative
> sentence, thus creating confusion:
>
> - clip -
> If the new directory
> exists, and the change to new directory succeeds, the new directory is
> returned. If the new directory does not exist or an error occurred changing
> to that new directory, the empty string is returned.
> - eclip -
>
> The original Object Rexx Beta Draft was much clearer:
>
> - clip -
> returns the current directory, first changing it to NewDirectory if an
> argument is supplied and the named directory exists. If NewDirectory is not
> specified, the name of the current directory is returned. Otherwise, an
> attempt is made to change to the specified NewDirectory. If successful, the
> name of the NewDirectory is returned; if an error occurred, null is
> returned.
> - eclip -
>
> Maybe its just me, but this is a prime example of non-professional writers
> trying to *improve* what an expert writer wrote to begin with! Generally
> speaking, we should guard against such changes.
>
> Les
>
>
>
> On 2/4/2016 2:59 AM, Jon Wolfers wrote:
>
>> Hi Bert,
>>
>> this thread has suddenly become quite complex and sensitive.  I hope that
>> the nuances in my reply come through.
>>
>> Firstly, I did see your response about your experience on VM.  I would not
>> expect VM to behave in the same way as Windows.  The filesystem is
>> different.  It is nearly a quarter century since I had my hands on a VM
>> system, but I don't remember there being a directory structure at all just
>> filename filetype and Disk[mode] - perhaps I'm remembering wrong.
>>
>> Secondly, the code as you posted it doesn't demonstrate how the directory
>> function actually behaved at that  time, in fact, reading your post I
>> can't
>> even be certain of how you expected it to behave.  I read several
>> possibilities into this scenario, including one where the documentation
>> was
>> just as ambiguous then, and the interpreter writers intention was the same
>> then as the observed behaviour today.
>>
>> You say "all implementations of the language should match" and you go on
>> to
>> establish a principle of prior precedent.  Now I don't know what you mean
>> by 'should', I would agree that *gratuitous* change should be avoided.  I
>>
>> think that the reason that this is desirable is not because the language
>> needs to be fixed in stone, but because changes cause programs out there
>> to
>> break.
>>
>> I don't know how the directory BIF worked on Object Rexx for OS/2 or the
>> system interpeter on VM, but I have verified to my satisfaction by looking
>> at the code in the ooRexx repository that the current behaviour has been
>> present on ooRexx for Windows and Linux for at least the last eight years,
>> and possibly more.
>>
>> I don't know how other interpreters work - although looking at the manuals
>> I have for Personal Rexx & Kexx I see that they each handle this very
>> differently.  Regina appears to have a directory BIF for OS/2 only and the
>> helpfile seems to indicate that the behaviour in Regina for OS/2 is
>> exactly
>> the same as what happens in ooRexx currently.  I hope Mark doesn't mind,
>> but I quote the Regina OS/2 help below.
>>
>> Now, given that it isn't possible to have all rexx interpreters working
>> exactly the same, because we see such a spread of behaviour, and that the
>> current behaviour in ooRexx for Windows and Linux has been in place for a
>> long time, I would say that changing this behaviour to match some
>> behaviour
>> that might have existed on some interpreter on some platform in the past
>> would break more currently active code than recognising that this change
>> may have occurred in the past and that the helpfile is ambiguous and
>> correcting the helpfile suitably.
>>
>> I hope that that makes my position on this clear.  Sorry if it opens a can
>> of worms.
>>
>> Jon
>>
>>
>> Regina's Directory BIF for OS/2 helpfile:

Re: [Oorexx-users] (no subject)

[Jon Wolfers]

Hi Bert,

this thread has suddenly become quite complex and sensitive.  I hope that
the nuances in my reply come through.

Firstly, I did see your response about your experience on VM.  I would not
expect VM to behave in the same way as Windows.  The filesystem is
different.  It is nearly a quarter century since I had my hands on a VM
system, but I don't remember there being a directory structure at all just
filename filetype and Disk[mode] - perhaps I'm remembering wrong.

Secondly, the code as you posted it doesn't demonstrate how the directory
function actually behaved at that  time, in fact, reading your post I can't
even be certain of how you expected it to behave.  I read several
possibilities into this scenario, including one where the documentation was
just as ambiguous then, and the interpreter writers intention was the same
then as the observed behaviour today.

You say "all implementations of the language should match" and you go on to
establish a principle of prior precedent.  Now I don't know what you mean
by 'should', I would agree that *gratuitous* change should be avoided.  I
think that the reason that this is desirable is not because the language
needs to be fixed in stone, but because changes cause programs out there to
break.

I don't know how the directory BIF worked on Object Rexx for OS/2 or the
system interpeter on VM, but I have verified to my satisfaction by looking
at the code in the ooRexx repository that the current behaviour has been
present on ooRexx for Windows and Linux for at least the last eight years,
and possibly more.

I don't know how other interpreters work - although looking at the manuals
I have for Personal Rexx & Kexx I see that they each handle this very
differently.  Regina appears to have a directory BIF for OS/2 only and the
helpfile seems to indicate that the behaviour in Regina for OS/2 is exactly
the same as what happens in ooRexx currently.  I hope Mark doesn't mind,
but I quote the Regina OS/2 help below.

Now, given that it isn't possible to have all rexx interpreters working
exactly the same, because we see such a spread of behaviour, and that the
current behaviour in ooRexx for Windows and Linux has been in place for a
long time, I would say that changing this behaviour to match some behaviour
that might have existed on some interpreter on some platform in the past
would break more currently active code than recognising that this change
may have occurred in the past and that the helpfile is ambiguous and
correcting the helpfile suitably.

I hope that that makes my position on this clear.  Sorry if it opens a can
of worms.

Jon


Regina's Directory BIF for OS/2 helpfile:

> DIRECTORY([new directory]) - (OS/2)
> Returns the current directory for the running process, and optionally
> changes directory to the specified new directory. If the new directory
> exists, and the change to new directory succeeds, the new directory is
> returned. If the new directory does not exist or an error occurred changing
> to that new directory, the empty string is returned.



On 4 February 2016 at 02:03, Bertram Moshier 
wrote:

> Hi Jon,
>
> .
>> I would say that this is a documentation bug as the documentation lists
>> two different behaviours which can't both be right, and the code only
>> displays one of these behaviors.
>
>
> I think my earlier email about find a VM/CMS example went though, but in
> case it didn't (I sent it from a tablet).  I found an example in my old
> notes, while at Cray Research, Inc, of using it as:
>
> Current_Dir = directory(New_Dir)  where New_Dir was a valid location.
>
> I also think I successfully used this coding using classic Rexx under OS/2
> Warp, but have yet to find my old OS/2 Warp drives.
>
> As all implementations of the language should match and VM/CMS, OS/2 Warp,
> MVS, etc all came earlier, I'd say the documentation and code both are off
> in their own ways.  The documentation needs to be clear, obviously.  Also
> the implementation should allow functions, such as the directory, to
> function the same regardless.
>
> Would this be two bug reports or one for two areas?
>
> Bert.
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Oorexx-users mailing list
> Oorexx-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-users
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor 

Re: [Oorexx-users] (no subject)

[Moritz Hoffmann]

On Thu, Feb 4, 2016 at 8:59 AM, Jon Wolfers  wrote:

>
> Now, given that it isn't possible to have all rexx interpreters working
> exactly the same, because we see such a spread of behaviour, and that the
> current behaviour in ooRexx for Windows and Linux has been in place for a
> long time, I would say that changing this behaviour to match some behaviour
> that might have existed on some interpreter on some platform in the past
> would break more currently active code than recognising that this change
> may have occurred in the past and that the helpfile is ambiguous and
> correcting the helpfile suitably.
>

I fully agree. We should be more concerned about not breaking ooRexx
instead of making it compatible to some other version of Rexx. I'd vote for
adjusting the documentation and leave it as that. We could even add a note
saying that ooRexx's directory bif might be different from old versions of
Rexx.

Moritz
-- 
Moritz Hoffmann;
http://antiguru.de/
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users