Re: [Oorexx-devel] Discussion of missing SourceForge links...
Mark Miesfeld wrote: The new SourceForge interface we are using has some problems loading the summary page and as a result the correct menu doesn't get loaded. Mark, I clicked on one of the projects you are a developer for, and that project had more links... so evidently the number of links displayed is different from project to project. Thank you for providing your link as well. I will add that to my ooRexx bookmark collection. Sincerely, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] On the topic of enchaining SysFileTree...
Chip Davis wrote: SysFileTree() otoh, was never intended for interactive use and is more accurately regarded as a application interface to the file system. snip IMHO, of course. So was that a +1 for my RFE? -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ...
Just realized (from habits of the past) that I forgot to explicitly ask for voting (up or down or abstain)! So please, if interested in any of these RFEs below, then consider to vote up or down or abstain by clicking on the link and then press the + button or the - button. If you want to abstain after having clicked any of these buttons, just re-click them, such that they pop back to neutral (abstain). ---rony On 25.08.2012 13:09, Rony G. Flatscher wrote: Hi there, thank you very much for all of your feedback which encouraged me to create the following two RFEs: * feature-requests:479 Add a condense method to the Array class: https://sourceforge.net/p/oorexx/feature-requests/479/ and * feature-requests:480 Allow the sort/sortWith methods to sort sparse arrays as well: https://sourceforge.net/p/oorexx/feature-requests/480/ ---rony On 24.08.2012 12:01, Rony G. Flatscher wrote: Yesterday I stumbled over a surprising behaviour of Array's sort, which led me to open a bug report https://sourceforge.net/p/oorexx/bugs/1107/. Obviously the sorting is working as designed, hence the reported behaviour was not accepted as a bug. Having slept a night over this and thinking about my utmost surprise that sort would raise an error condition if it hits an empty array element (one without an entry) in between, I try to summarize my thoughts about the current behaviour, requesting a change of the design and implementation to get rid of the surprising factor and to remove undeterminable fragility from the Array sort. First, the current design and implementation: The single dimiensioned array that gets sorted must not have empty entries in between. If the sort tries to refer to an empty slot it raises Error 98.975: Missing array element at position xyz and the program is ended, if the condition does not get trapped. Thoughts about this: 1. Having worked for many years sorting arrays, I was *totally surprised* about this unexpected (because never experienced) behaviour! The surprise factor for me was at the maximum. 2. There is no documentation going with sorting arrays that would communicate that the arrays to be sorted must have no empty elements in between that I am aware of. Therefore one cannot expect this behaviour at all. 3. If one uses single dimensioned arrays that get changed in routines and methods (written by others) such that elements get removed in between, then sorting such an array all of a sudden (and totally unforseeable) raises the above mentioned error condition, which makes sort quite fragile for programmers IMHO. 1. To overcome this situation, one must advice every ooRexx programmer to do *always* a (potentially time-consuming) makearray before sorting an array just to make sure that the aforementioned error condition does not get raised. 4. Finally, I would have expected that an array with empty elements should be sortable without a problem, therefore my utmost surprise! :) 1. My expectations would be simply as follows: if a single dimensioned array contained empty elements, then sorting would work and all the empty elements are sorted to the end of the array, no matter what the comparison method returns. This way, after a sort, all empty elements are always at the end of the array. (The items and size messages would remain the same.) The questions I would have, before contemplating about filing a RFE: * am I the only one who is surprised about a failing sort on a single dimensioned array if in between there are empty elements? * Independent of this, would it be acceptable to change the current design and implementation of the sort such that empty elements are tolerated and put to the end of the array (what would be arguments, thoughts that speak against such a change)? ---rony -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Publican Status
On Tue, Aug 28, 2012 at 6:08 AM, David Ashley w.david.ash...@gmail.com wrote: I will commit what I have done so far later this morning. Here is what is left for finishing. 2. All the edits are done except finishing the conversion of link tage to xref tags. About 1/3 of the files are converted. Take a look at how I am doing the conversion and you will see that ir requires a LOT of hand editing. I tried to write a program to do it but I could not get it to work without it creating more problems than it solved. Okay good. I think I may be able to do a global search and replace with Slick Edit to do a lot of them. Stress the word 'think.' We'll see. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ...
Rony, I just tried to vote, but there was no response when clicking the button. What else must I do to register a vote? From: Rony G. Flatscher [mailto:rony.flatsc...@wu-wien.ac.at] Sent: Tuesday, August 28, 2012 06:49 To: oorexx-devel@lists.sourceforge.net Subject: Re: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ... Just realized (from habits of the past) that I forgot to explicitly ask for voting (up or down or abstain)! So please, if interested in any of these RFEs below, then consider to vote up or down or abstain by clicking on the link and then press the + button or the - button. If you want to abstain after having clicked any of these buttons, just re-click them, such that they pop back to neutral (abstain). ---rony On 25.08.2012 13:09, Rony G. Flatscher wrote: Hi there, thank you very much for all of your feedback which encouraged me to create the following two RFEs: * feature-requests:479 Add a condense method to the Array class: https://sourceforge.net/p/oorexx/feature-requests/479/ and * feature-requests:480 Allow the sort/sortWith methods to sort sparse arrays as well: https://sourceforge.net/p/oorexx/feature-requests/480/ ---rony On 24.08.2012 12:01, Rony G. Flatscher wrote: Yesterday I stumbled over a surprising behaviour of Array's sort, which led me to open a bug report https://sourceforge.net/p/oorexx/bugs/1107/ https://sourceforge.net/p/oorexx/bugs/1107/. Obviously the sorting is working as designed, hence the reported behaviour was not accepted as a bug. Having slept a night over this and thinking about my utmost surprise that sort would raise an error condition if it hits an empty array element (one without an entry) in between, I try to summarize my thoughts about the current behaviour, requesting a change of the design and implementation to get rid of the surprising factor and to remove undeterminable fragility from the Array sort. First, the current design and implementation: The single dimiensioned array that gets sorted must not have empty entries in between. If the sort tries to refer to an empty slot it raises Error 98.975: Missing array element at position xyz and the program is ended, if the condition does not get trapped. Thoughts about this: 1. Having worked for many years sorting arrays, I was *totally surprised* about this unexpected (because never experienced) behaviour! The surprise factor for me was at the maximum. 2. There is no documentation going with sorting arrays that would communicate that the arrays to be sorted must have no empty elements in between that I am aware of. Therefore one cannot expect this behaviour at all. 3. If one uses single dimensioned arrays that get changed in routines and methods (written by others) such that elements get removed in between, then sorting such an array all of a sudden (and totally unforseeable) raises the above mentioned error condition, which makes sort quite fragile for programmers IMHO. 1. To overcome this situation, one must advice every ooRexx programmer to do *always* a (potentially time-consuming) makearray before sorting an array just to make sure that the aforementioned error condition does not get raised. 4. Finally, I would have expected that an array with empty elements should be sortable without a problem, therefore my utmost surprise! :) 1. My expectations would be simply as follows: if a single dimensioned array contained empty elements, then sorting would work and all the empty elements are sorted to the end of the array, no matter what the comparison method returns. This way, after a sort, all empty elements are always at the end of the array. (The items and size messages would remain the same.) The questions I would have, before contemplating about filing a RFE: * am I the only one who is surprised about a failing sort on a single dimensioned array if in between there are empty elements? * Independent of this, would it be acceptable to change the current design and implementation of the sort such that empty elements are tolerated and put to the end of the array (what would be arguments, thoughts that speak against such a change)? ---rony -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ...
Dan: On 28.08.2012 15:22, Mark Miesfeld wrote: On Tue, Aug 28, 2012 at 5:59 AM, Dan Carter gwcar...@ezlink.com wrote: Rony, I just tried to vote, but there was no response when clicking the button. What else must I do to register a vote? It worked okay for me. I voted up and then back to abstain with no problem. It's possible that you need to be logged in to SourceForge for your vote to count. Mark is probably right, you would need to login to Sourceforge with your Sourceforge account. It also seems that the site remembers who voted, such that one is able to remove a vote or change it later. ---rony -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] On the topic of enchaining SysFileTree...
On 8/28/2012 08:46 Rony G. Flatscher said: On 28.08.2012 13:02, Michael Lueck wrote: Chip Davis wrote: SysFileTree() otoh, was never intended for interactive use and is more accurately regarded as a application interface to the file system. snip IMHO, of course. So was that a +1 for my RFE? Hmm, only after reading this did I conclude that I could do a +1 on your RFE right there at: https://sourceforge.net/p/oorexx/feature-requests/482/. Just did that and saw that you yourself had not done that vote up. I had not bumped the RFE because I wanted to initiate a discussion about the implementation of it, first. Specifically, Michael suggested a flag to indicate that every file should be returned. My point was that return every file should be the default behavior, and that the interface could use flags, RE's, wildcards, arguments, or whatever, to indicate something less than every file was desired. I know the backwards compatibility argument will be raised, but the current behavior is not consistent across all filesystems now. The only reasonable default behavior is for SysFileTree() to return all the files it can see on whatever filesystem it is scanning. I have now bumped this RFE, primarily to encourage someone to look at the issue. I would prefer that the solution suggested by the RFE not be the way it is implemented. -Chip- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ...
On 8/28/2012 09:38 Rony G. Flatscher said: On 28.08.2012 15:22, Mark Miesfeld wrote: On Tue, Aug 28, 2012 at 5:59 AM, Dan Carter gwcar...@ezlink.com wrote: Rony, I just tried to vote, but there was no response when clicking the button. What else must I do to register a vote? It worked okay for me. I voted up and then back to abstain with no problem. It's possible that you need to be logged in to SourceForge for your vote to count. Mark is probably right, you would need to login to Sourceforge with your Sourceforge account. It also seems that the site remembers who voted, such that one is able to remove a vote or change it later. Indeed, I went to the RFE link and the voting buttons did not work, so I logged in and returned to the RFE page where they still did not work. Refreshing the page after logging in to Sourceforge did the trick. -Chip- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] On the topic of enchaining SysFileTree...
On Tue, Aug 28, 2012 at 10:19 AM, Chip Davis c...@aviatrexx.com wrote: On 8/28/2012 08:46 Rony G. Flatscher said: Just did that and saw that you yourself had not done that vote up. I had not bumped the RFE because I wanted to initiate a discussion Actually I think Rony meant Michael had not bumped up his own RFE, but that's not that relevant. about the implementation of it, first. Specifically, Michael suggested a flag to indicate that every file should be returned. My point was that return every file should be the default behavior, and that the interface could use flags, RE's, wildcards, arguments, or whatever, to indicate something less than every file was desired. I know the backwards compatibility argument will be raised, but the But what about backwards compatibility? I agree with you that the reasonable default for the S flags would have been all files. But it wasn't implemented that way on Unix-like systems. It's been that way for a long time, probably forever. If we suddenly changed the behavior, programs like the ones Michael has already written and has been using would no longer produce the same results. Is that okay to do just because the original default wasn't reasonable? That's the question I'm interested in. I have now bumped this RFE, primarily to encourage someone to look at the issue. I would prefer that the solution suggested by the RFE not be the way it is implemented. Did you add a comment stating that also? -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] svnnotify now available on Sourceforge (Fwd: Re: Questions ad Allura ...
This was just posted a few minutes ago on the allura-dev list. If I understand correctly, than one can use the svnnotify hook to send a commit message to a configured mailing list, which might solve the problem. ---rony Original Message Subject:Re: Questions ad Allura ... Date: Tue, 28 Aug 2012 13:30:59 -0400 From: Dave Brondsema d...@brondsema.net Reply-To: allura-...@incubator.apache.org To: allura-...@incubator.apache.org On 8/23/12 5:58 PM, Dave Brondsema wrote: Hi again Rony. Thanks for the feedback. On 8/23/12 5:09 AM, Rony G. Flatscher (Apache) wrote: Hi Dave, On 22.08.2012 20:00, Dave Brondsema wrote: Commit diffs in emails: I see there are a lot of votes and comments on https://sourceforge.net/p/allura/tickets/2922/ I assume many are from ooRexx developers. It certainly is on our radar due to that, and something we'd like to add. When subscribed (btw, admins are automatically subscribed to all tools including SVN) emails will be sent with each commit, including a link to view the diff. Maybe making this feature available for regular users (maybe as an option to activate) would already solve this requeust? Yeah, I agree. In the mean time, you could consider using the RSS feed at https://sourceforge.net/p/oorexx/code-0/feed I know that's not as good as an email. We also want to get svn-notify available as a post-commit hook, but it isn't available yet. Great, thank you, looking forward to it! svnnotify is now available on SourceForge: https://sourceforge.net/p/forge/community-docs/Subversion/#adding-an-svnnotify-hook Setting up a commits mailing list may work well for you. Since this is specific to the SourceForge deployment of Allura, it'd probably be best to direct any questions/issues with svnnotify to SF Support: https://sourceforge.net/support -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] On the topic of enchaining SysFileTree...
On 28.08.2012 19:32, Mark Miesfeld wrote: On Tue, Aug 28, 2012 at 10:19 AM, Chip Davis c...@aviatrexx.com wrote: On 8/28/2012 08:46 Rony G. Flatscher said: Just did that and saw that you yourself had not done that vote up. I had not bumped the RFE because I wanted to initiate a discussion Actually I think Rony meant Michael had not bumped up his own RFE, but that's not that relevant. about the implementation of it, first. Specifically, Michael suggested a flag to indicate that every file should be returned. My point was that return every file should be the default behavior, and that the interface could use flags, RE's, wildcards, arguments, or whatever, to indicate something less than every file was desired. I know the backwards compatibility argument will be raised, but the But what about backwards compatibility? I agree with you that the reasonable default for the S flags would have been all files. But it wasn't implemented that way on Unix-like systems. It's been that way for a long time, probably forever. If we suddenly changed the behavior, programs like the ones Michael has already written and has been using would no longer produce the same results. Is that okay to do just because the original default wasn't reasonable? That's the question I'm interested in. This is an interesting question! What, if one just regards the current behaviour on Unix systems to be a (long standing) bug, rather than a RFE? :) ---rony -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] On the topic of enchaining SysFileTree...
On 8/28/2012 14:08 Rony G. Flatscher said:
On 28.08.2012 19:32, Mark Miesfeld wrote:
On Tue, Aug 28, 2012 at 10:19 AM, Chip Davis c...@aviatrexx.com wrote:
On 8/28/2012 08:46 Rony G. Flatscher said:
Just did that and saw that you yourself had not done that vote up.
I had not bumped the RFE because I wanted to initiate a discussion
Actually I think Rony meant Michael had not bumped up his own RFE, but
that's not that relevant.
about the implementation of it, first. Specifically, Michael
suggested a flag to indicate that every file should be returned.
My point was that return every file should be the default behavior,
and that the interface could use flags, RE's, wildcards, arguments, or
whatever, to indicate something less than every file was desired.
I know the backwards compatibility argument will be raised, but the
But what about backwards compatibility?
I agree with you that the reasonable default for the S flags would
have been all files. But it wasn't implemented that way on Unix-like
systems. It's been that way for a long time, probably forever. If we
suddenly changed the behavior, programs like the ones Michael has
already written and has been using would no longer produce the same
results.
Is that okay to do just because the original default wasn't reasonable?
That's the question I'm interested in.
This is an interesting question!
What, if one just regards the current behaviour on Unix systems to be a (long
standing) bug, rather
than a RFE?
:)
As one who frequently raises the backward-compatibility issue, I fully
recognize the issue with changing SysFileTree. That's why I was
reticent to vote for this RFE. But it is broken now; fixing it will
probably require more effort than writing a new routine.
Which means the best solution is a new routine. Call it SysFileList
if you will. I'm with Rony in that all of the various implementations
of SysFileTree that mimicked the behavior of a particular platform's
interactive list files command ('ls', 'listfile', 'dir', et al.)
were doomed to cross-platform failure from the start.
It's time we implemented a truly cross-platform file list utility,
where the default is to return all files.
IMHO, of course.
-Chip-
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] On the topic of enchaining SysFileTree...
Rony G. Flatscher wrote: Hmm, only after reading this did I conclude that I could do a +1 on your RFE right there at: I had no idea that the SF site had a voting system. I was interested in tabulating peer support that I am not a lunatic for requesting. ;-) Sincerely, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] On the topic of enchaining SysFileTree...
Mark Miesfeld wrote: I agree with you that the reasonable default for the S flags would have been all files. But it wasn't implemented that way on Unix-like systems. It's been that way for a long time, probably forever. If we suddenly changed the behavior, programs like the ones Michael has already written and has been using would no longer produce the same results. Is that okay to do just because the original default wasn't reasonable? That's the question I'm interested in. I vote in favor of leaving the API alone for legacy support and band-aid it with an additional switch. I do not want another big-bang upgrade pain like was felt with the ooRexx FTP class early on. I recall something in that API changed and programs were not portable across the hump. I had to decide to run the new ooRexx, hurry to change my code, and never to go back to older versions. Until I get around to upgrading all places I need to double SysFileTree I would like that legacy code not to suddenly really find A files with '*' search pattern. That would cause duplication of the result set, slow down the program execution, etc... Implement it the same way the L option was added to SysFileTree long long ago. Oh, I can receive four digit years from SysFileTree. How nice, I will use that. Sincerely, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] ooRexx 4.1.2 code moved to release
Hi All I moved main 4.1.2 from branches to releases and docs 4.1.2 from branches to releases Things are set on on SourceForge: https://sourceforge.net/projects/oorexx/files/oorexx/4.1.2/ and https://sourceforge.net/projects/oorexx/files/oorexx-docs/4.1.2/ The 4.1.2 docs are built and uploaded to SourceForge. For ooRexx 4.1.2, the Windows installers are built and uploaded, the source tar and zip files are uploaded, and several Linux installers are uploaded. I'll add some more Linuxes tomorrow, and send out the release announcement Thursday night. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
