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] 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] 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] Ad sorting arrays: request for discussion/thoughts ...
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] Ad sorting arrays: request for discussion/thoughts ...
I reported this already (item #3151709, was opened at 2011-01-05 09:52), and I was also surprised. There is a note in REXXREF about sorting arrays and non-sparse arrays (page 285). I found out after reporting. I think it's not consistent with Do s over array say s end This will show all existing items in the array. Skippning removed items I prefer to think of, in this case, that removed items is nonexisting items and should not be included in a sort operation, which means array will shrink. but it has already done that more or less, array~items will only count indexes with values (like the do over clause), but array~sort statment will fail if item is removed from array, if not last item in array is removed. As for current status shouldn't array~items return a count including removed entries. Some inconsistency here I think /hex - Ursprungligt Meddelande - Från: Rony G. Flatscher rony.flatsc...@wu-wien.ac.at Till: Open Object Rexx Developer Mailing List oorexx-devel@lists.sourceforge.net Kopia: Datum: fredag, 24 augusti 2012 12:02 Ämne: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ... 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:Missingarrayelementatposition xyz and the program is ended, if the condition does not get trapped. Thoughts about this: 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. 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. 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. 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. Finally, I would have expected that an array with empty elements should be sortable without a problem, therefore my utmost surprise! :) 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-- 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.
Re: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ...
On Fri, Aug 24, 2012 at 7:15 AM, hakan hexi...@users.sourceforge.netwrote: ** I reported this already (item #3151709, was opened at 2011-01-05 09:52), and I was also surprised. There is a note in REXXREF about sorting arrays and non-sparse arrays (page 285). I found out after reporting. I think it's not consistent with Do s over array say s end These are fundamentally different constructs. Do Over actually requests a new version from the collection which is defined as being non-sparse. The sort is an in-place modification of the array itself. This will show all existing items in the array. Skippning removed items I prefer to think of, in this case, that removed items is nonexisting items and should not be included in a sort operation, which means array will shrink. but it has already done that more or less, array~items will only count indexes with values (like the do over clause), but array~sort statment will fail if item is removed from array, if not last item in array is removed. As for current status shouldn't array~items return a count including removed entries. Not allowing empty slots at the end would make the sort essentially unusable. Consider the following: a = .array~new(1000) -- create an array with a best guess on the size do while iterator~haveMoreitems a~append(iterator~nextItem) end a~sort Raising an error if a~items a~size would mean the above scenario would only work if there were exactly 1000 items added to the array. The dichotomy between items and size and the meaning of sparse is intentional. This change is not going to be made. Rick Some inconsistency here I think /hex - Ursprungligt Meddelande - *Från:* Rony G. Flatscher rony.flatsc...@wu-wien.ac.atrony.flatsc...@wu-wien.ac.at *Till:* Open Object Rexx Developer Mailing List oorexx-devel@lists.sourceforge.net oorexx-devel@lists.sourceforge.net *Kopia:* *Datum:* fredag, 24 augusti 2012 12:02 *Ämne:* [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ... 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 Error98 .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
Re: [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts ...
Rick McGuire object.r...@gmail.com wrote: These are fundamentally different constructs. Do Over actually requests a new version from the collection which is defined as being non-sparse. The sort is an in-place modification of the array itself. REXX used to have a principle of least astonishment. You're saying that to be un-astonished a user has to know the inner workings of the implementation which seems, well, astonishing. [snip] Raising an error if a~items a~size would mean the above scenario would only work if there were exactly 1000 items added to the array. The dichotomy between items and size and the meaning of sparse is intentional. This change is not going to be made. Is it possible then that a decent explanation that ordinary users can understand can be put into the relevant doc? -- Jeremy Nicoll - my opinions are my own -- 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 G. Flatscher rony.flatsc...@wu-wien.ac.at 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. I've read this and the bug report and think one could argue it from both points of view... I've also looked at the Ref manual section on arrays. I'm very much not an expert on any of the oo stuff. Arrays are descibed though as: An array is a possibly sparse collection with indexes that are positive whole numbers. which says to me that sparseness (which might be the issue) are an expected attribute of an array. I looked at the definition of remove. It does not say that an array which has had an item removed ceases to be an array, and it does not say that such an array (if not already sparse) becomes sparse. That would say to me, naively(?) that a sortable array which then has an element removed, is still a sortable array. On the other hand the sort method says right at the start Sorts an array of Comparable items... which makes me wonder if there might be an element of the if a == .nil issue involved in this? Also the link to sorting arrays takes one to text that says: Any non-sparse Array instance can have its elements placed into sorted order using the sort method of the Array class. which without going into useful details does suggest sparseness is an issue. Maybe it would be useful if arrays had an attribute that said whether or not they were sparse? On the whole I think I'd go with Rony's view that removed items should all sort together to one or other extreme of an array, if they're still part of the array. Otherwise, remove might as well be renamed ruin. -- Jeremy Nicoll - my opinions are my own -- 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 ...
Rick McGuire object.r...@gmail.com wrote: On Fri, Aug 24, 2012 at 7:15 AM, hakan hexi...@users.sourceforge.netwrote: I think it's not consistent with Do s over array say s end These are fundamentally different constructs. Do Over actually requests a new version from the collection which is defined as being non-sparse. That sounds to me like a colossally inefficient thing to do - are you really saying that for do/over there's a second copy of the array created (and then destroyed?)? -- Jeremy Nicoll - my opinions are my own -- 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 Fri, Aug 24, 2012 at 8:21 PM, Jeremy Nicoll - ml sourceforge jn.ml.sfrg...@letterboxes.org wrote: Rick McGuire object.r...@gmail.com wrote: On Fri, Aug 24, 2012 at 7:15 AM, hakan hexi...@users.sourceforge.netwrote: I think it's not consistent with Do s over array say s end These are fundamentally different constructs. Do Over actually requests a new version from the collection which is defined as being non-sparse. That sounds to me like a colossally inefficient thing to do - are you really saying that for do/over there's a second copy of the array created (and then destroyed?)? Do Over is defined as operating on a snapshot of the collection, so this is a requirement for the instruction. Rick -- Jeremy Nicoll - my opinions are my own -- 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 -- 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 Fri, Aug 24, 2012 at 8:43 PM, Jeremy Nicoll - ml sourceforge jn.ml.sfrg...@letterboxes.org wrote: Rick McGuire object.r...@gmail.com wrote: Do Over is defined as operating on a snapshot of the collection, so this is a requirement for the instruction. Do you mean because the code inside the do loop could change the collection so it needs the separate copy made at the start to control the loop? Yes, that's what I mean. I can understand that, but it still seems very inefficient. Nonetheless, that is how it is defined. -- Jeremy Nicoll - my opinions are my own -- 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 -- 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
