Bug in Indexed String handling (Part 2)?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in Indexed String handling (Part 2)?

George Hovey-2
Bill,
I've abandoned the original thread since it seems to be misbehaving.

I tried your suggestion and it worked.  So armed, I was able to write a program that eliminates extraneous issues.

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'
)*/

George Hovey


--
"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/

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Indexed String handling (Part 2)?

rickmcguire
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:
Bill,
I've abandoned the original thread since it seems to be misbehaving.

I tried your suggestion and it worked.  So armed, I was able to write a program that eliminates extraneous issues.

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'
)*/

George Hovey


--
"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/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Indexed String handling (Part 2)?

George Hovey-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:
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:
Bill,
I've abandoned the original thread since it seems to be misbehaving.

I tried your suggestion and it worked.  So armed, I was able to write a program that eliminates extraneous issues.

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'
)*/

George Hovey


--
"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/




_______________________________________________
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

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Indexed String handling (Part 2)?

Bill Fenlason
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
retains
> 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
retains
> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Indexed String handling (Part 2)?

George Hovey-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.


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
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
retains
> 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
retains
> 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/




--
"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/

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Indexed String handling (Part 2)?

Bill Fenlason
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/