Bug in Indexed String handling (Part 2)?
Locked
Bug in Indexed String handling (Part 2)?
 
|
Bill, I've abandoned the original thread since it seems to be misbehaving.Class Example /*( Class 'Example' illustrates an {interesting fact | feature | bug} of Indexed String handling. The two methods 'Good' and 'Bad' differ only in the way they assign a default value to their locally defined variables 'IndexedRexxBad' and 'IndexedRexxGood'. The issue is their behavior on the second entry to each. Since the two variables are local, it is expected that on any entry the Indexed String will be "empty" (have no indices defined). But Method Bad retains a value set on the first entry on its second entry. java -version Java(TM) SE Runtime Environment (build 1.7.0_10-b18) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode) NetRexxC version NetRexx 3.02, build 172-20130625-1742 )*/ Properties Private Constant Rc_Default = "*NotDefined*" Method Good( a_EntryNum ) Private Static IndexedRexxGood = "*NotDefined*" --/ default is a literal string Say "Method Good: Entry #"a_EntryNum". IndexedRexxGood[1]="IndexedRexxGood[1] IndexedRexxGood[1] = "'Index [1] defined'" Method Bad( a_EntryNum ) Private Static IndexedRexxBad = Rc_Default --/ default is a Private Constant Property Say "Method Bad: Entry #"a_EntryNum". IndexedRexxBad[1] ="IndexedRexxBad[1] IndexedRexxBad[1] = "'Index [1] defined'" Method main( a_Args_1s = String[] ) Public Static Good( 1 ) Good( 2 ) Bad( 1 ) Bad( 2 ) /*( The program says: Method Good: Entry #1. IndexedRexxGood[1]=*NotDefined* Method Good: Entry #2. IndexedRexxGood[1]=*NotDefined* Method Bad: Entry #1. IndexedRexxBad[1] =*NotDefined* Method Bad: Entry #2. IndexedRexxBad[1] ='Index [1] defined' )*/ -- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Bug in Indexed String handling (Part 2)?
|
|
It looks like this is working correctly to me. The issue is not the variable, but the object being assigned to the variable. The assignment to the literal string creates a new Rexx string value each time, so the indexing is empty. The assignment to the Rc_Default value reuses the same object on each call, so prior alterations are still visible. Rick On Sun, Nov 17, 2013 at 9:38 AM, George Hovey <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Bug in Indexed String handling (Part 2)?
|
|
You may be right. But if so this seems to me to beg for some exposition in the NRL. On Sun, Nov 17, 2013 at 9:46 AM, Rick McGuire <[hidden email]> wrote:
-- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by George Hovey-2
I'm reposing my earlier response since it contains the reference to the
language reference manual. I don't know what the problem with the list computer is - normally the replies are posted with no problems. Bill ------------------------------------- George, The problem may be that in "Files_IRx = Rc_FilesNoDef", Files_IRx is not a new copy of Rc_FilesNoDef, it renames it. The note on page 78 of the language reference says: "Note: A variable is just a name, or handle for a value. It is possible for more than one variable to refer to the same value, as in the program: first=A string second=first Here, both variables refer to the same value. If that value is changeable then a change to the value referred to by one of the variable names would also be seen if the value is referred to by the other." I find this a bit confusing myself since some other languages do not work this way. Consider this example and its output: /* netrexx */ x = ''; x[1] = '1' z = x say 'x[1] is' x[1] 'and z[1] is' z[1] x[1] = '2' -- Change x but not z? say 'x[1] is' x[1] 'and z[1] is' z[1] /*===== Exec: temp ===== x[1] is 1 and z[1] is 1 x[1] is 2 and z[1] is 2 Processing of 'temp.nrx' complete */ Try omitting the use of Rc_FilesNoDef by replacing it with whatever was assigned to it. Original email: ----------------- From: George Hovey [hidden email] Date: Sat, 16 Nov 2013 20:28:30 -0500 To: [hidden email], [hidden email] Subject: Re: [Ibm-netrexx] Bug in Indexed String handling? Bill, See below. On Sat, Nov 16, 2013 at 6:12 PM, [hidden email] <[hidden email]>wrote: > Does the program work if you initialize the variables yourself? See Note > below. > > Are the variables arrays or are they Rexx strings? Rexx Strings Are the > variables being > initially defined within an if block? No > > Perhaps if you show us the method declaration and the first few > instructions which define or reference the two variables it would be > helpful. Method ParseFiles( ) Private Static Say ">>Enter ParseFiles( )" Files_IRx = Rc_FilesNoDef -- _IRx means 'being used as Indexed String' TypesUC_IRx = Rc_TypesUCNoDef (Rc_FilesNoDef and Rc_TypesUCNoDef are constants.) > How big is the ParseFiles method? 160K zip implies that the > class is several thousand lines - a bit much. The class source is about > 300 lines (less comments). The ParseFiles method is about 100 lines. A > PDF (157K) of jEdit-formatted source is included. > Note: If I follow the two defs above with code nulling all elements of the two Indexed Strings, the program works as hoped for. The ZIP includes correct and incorrect output files. > > > Original email: > ----------------- > From: George Hovey [hidden email] > Date: Sat, 16 Nov 2013 14:42:57 -0500 > To: [hidden email] > Subject: [Ibm-netrexx] Bug in Indexed String handling? > > > I have encountered an apparent bug in the handling of Indexed Strings by > NetRexxC under Windows 7. The NetRexxC version is: > > "NetRexx portable processor, version NetRexx 3.02, build > 172-20130625-1742" > > It appears that a local Rexx Indexed String variable is not iniialized > correctly upon entry to a method. Specifically, the local variable > its values from the previous entry to the method. > > I have attempted to reproduce this behavior in a skeletonized version of my > program without success. So I can only demonstrate it with my original > program. > Furtunately, this is a single class. > > Briefly, the class, 'TreeX' processes the output from the DOS 'Tree' > commmand, which is a graphical representation of a directory tree. Method > 'ParseFiles' handles the processing of the files in a single directory, and > is called for each directory encountered. > > ParseFiles defines two (local) Indexed Strings, TypesUC_IRx and Files_IRx. > The intent is that after ParseFiles has processed all files in the > directory, TypesUC_IRx contains a list of the (uppercase) file types > encountered; and Files_IRx contains a list of all file names encountered. > > The problem is that on subsequent entry to ParseFiles, the results from the > previous entry are retained in the two Indexed Strings. > > If anyone would care to take a look at this I'll send a ZIP (160K). > > -- George Hovey > > -- > "One can live magnificently in this world if one knows how to work and how > to love." -- Leo Tolstoy > > > -------------------------------------------------------------------- > mail2web.com - Microsoft® Exchange solutions from a leading provider - > http://link.mail2web.com/Business/Exchange > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy Original email: ----------------- From: George Hovey [hidden email] Date: Sat, 16 Nov 2013 20:28:30 -0500 To: [hidden email], [hidden email] Subject: Re: [Ibm-netrexx] Bug in Indexed String handling? Bill, See below. On Sat, Nov 16, 2013 at 6:12 PM, [hidden email] <[hidden email]>wrote: > Does the program work if you initialize the variables yourself? See Note > below. > > Are the variables arrays or are they Rexx strings? Rexx Strings Are the > variables being > initially defined within an if block? No > > Perhaps if you show us the method declaration and the first few > instructions which define or reference the two variables it would be > helpful. Method ParseFiles( ) Private Static Say ">>Enter ParseFiles( )" Files_IRx = Rc_FilesNoDef -- _IRx means 'being used as Indexed String' TypesUC_IRx = Rc_TypesUCNoDef (Rc_FilesNoDef and Rc_TypesUCNoDef are constants.) > How big is the ParseFiles method? 160K zip implies that the > class is several thousand lines - a bit much. The class source is about > 300 lines (less comments). The ParseFiles method is about 100 lines. A > PDF (157K) of jEdit-formatted source is included. > Note: If I follow the two defs above with code nulling all elements of the two Indexed Strings, the program works as hoped for. The ZIP includes correct and incorrect output files. > > > Original email: > ----------------- > From: George Hovey [hidden email] > Date: Sat, 16 Nov 2013 14:42:57 -0500 > To: [hidden email] > Subject: [Ibm-netrexx] Bug in Indexed String handling? > > > I have encountered an apparent bug in the handling of Indexed Strings by > NetRexxC under Windows 7. The NetRexxC version is: > > "NetRexx portable processor, version NetRexx 3.02, build > 172-20130625-1742" > > It appears that a local Rexx Indexed String variable is not iniialized > correctly upon entry to a method. Specifically, the local variable > its values from the previous entry to the method. > > I have attempted to reproduce this behavior in a skeletonized version of my > program without success. So I can only demonstrate it with my original > program. > Furtunately, this is a single class. > > Briefly, the class, 'TreeX' processes the output from the DOS 'Tree' > commmand, which is a graphical representation of a directory tree. Method > 'ParseFiles' handles the processing of the files in a single directory, and > is called for each directory encountered. > > ParseFiles defines two (local) Indexed Strings, TypesUC_IRx and Files_IRx. > The intent is that after ParseFiles has processed all files in the > directory, TypesUC_IRx contains a list of the (uppercase) file types > encountered; and Files_IRx contains a list of all file names encountered. > > The problem is that on subsequent entry to ParseFiles, the results from the > previous entry are retained in the two Indexed Strings. > > If anyone would care to take a look at this I'll send a ZIP (160K). > > -- George Hovey > > -- > "One can live magnificently in this world if one knows how to work and how > to love." -- Leo Tolstoy > > > -------------------------------------------------------------------- > mail2web.com - Microsoft® Exchange solutions from a leading provider - > http://link.mail2web.com/Business/Exchange > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy -------------------------------------------------------------------- mail2web LIVE Free email based on Microsoft® Exchange technology - http://link.mail2web.com/LIVE _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: Bug in Indexed String handling (Part 2)?
|
|
Bill, I have no quarrel with your explanation, which may be right.On Sun, Nov 17, 2013 at 10:44 AM, [hidden email] <[hidden email]> wrote: I'm reposing my earlier response since it contains the reference to the -- "One can live magnificently in this world if one knows how to work and how to love." -- Leo Tolstoy _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by George Hovey-2
George,
As I said earlier, I find it a bit confusing too. An alternative is to force the local variable to be a copy. So instead of : Files_IRx = Rc_FilesNoDef use: Files_IRx = Rexx(Rc_FilesNoDef) That forces the local variable object to be a copy instead of a reference. /* netrexx - updated */ x = 'Original X' x[1] = 'x1' y = x -- make reference z = Rexx(x) -- make copy, not reference say 'x[1] is' x[1]', y[1] is' y[1]', and z[1] is' z[1] z[1] = 'z1' say 'x[1] is' x[1]', y[1] is' y[1]', and z[1] is' z[1] x[1] = 'xx1' say 'x[1] is' x[1]', y[1] is' y[1]', and z[1] is' z[1] /* ===== Exec: temp ===== x[1] is x1, y[1] is x1, and z[1] is Original X x[1] is x1, y[1] is x1, and z[1] is z1 x[1] is xx1, y[1] is xx1, and z[1] is z1 Processing of 'temp.nrx' complete */ Original email: ----------------- From: George Hovey [hidden email] Date: Sun, 17 Nov 2013 11:07:02 -0500 To: [hidden email], [hidden email] Subject: Re: [Ibm-netrexx] Bug in Indexed String handling (Part 2)? Bill, I have no quarrel with your explanation, which may be right. To me the issue is the "astonishment factor." To the naive user (say, me) my assignment of a default value represented by a Private Static property meets the NLR's requirements. Note 1 on page 78 says "A variable of type Rexx must have been assigned a value before indexing is used on it." And the value I used seems, on the face of it, to satisfy that requirement. If the actual behavior depends on a more subtle understanding of objects, or whatever, fine; but we naive users would appreciate some words of wisdom on the subject from those who understand the innards of NetRexx. -------------------------------------------------------------------- mail2web.com Enhanced email for the mobile individual based on Microsoft® Exchange - http://link.mail2web.com/Personal/EnhancedEmail _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |