While these lines give proper output from e.g. \utilities\rexx\platform\windows\rexx.cpp
they give no output when used in \extensions\rexxutil\platform\windows\rexxutil.cpp.
Am I forgetting something?
Do you have better suggestions to quickly show debugging output?
Thanks, Andre
PS1: building platform is Windows and Visual Studio 2015
PS2: more specifically, I want to investigate bug report 1318 SysFileTree wrong for files > 4096 MB (https://sourceforge.net/p/oorexx/bugs/1318)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know any reason why that would not also work from rexxutil. Are
you certain the lines in question are actually getting executed? Another
possibility might be that an older version of RexxUtil is getting picked
up.
As to the bug report, note that the simple straight forward fix for this
problem is likely to break a lot of programs. Expanding the size field
would change the relative position of the returned information, breaking
any programs that used parse with absolute positions. This is the primary
reason why this has not been fixed before.
Rick
PS: The developers list is probably a better location for this sort of
discussion.
But how can I add my debugging lines to the C sources?
In some places in the C source I see fprintf(stdout,...) used to write to
screen.
Therefore I use the following debug lines.
~~~~
long long mydummy = 4300210176;
fprintf(stdout, "My debug output: %llu\n", mydummy);
~~~~
While these lines give proper output from e.g.
\utilities\rexx\platform\windows\rexx.cpp
they give no output when used in
\extensions\rexxutil\platform\windows\rexxutil.cpp.
Am I forgetting something?
Do you have better suggestions to quickly show debugging output?
Thanks, Andre
PS1: building platform is Windows and Visual Studio 2015
PS2: more specifically, I want to investigate bug report 1318 SysFileTree
wrong for files > 4096 MB (https://sourceforge.net/p/oorexx/bugs/1318)
Thanks for your help. Indeed I was picking up an old version of rexxutil.dll. Inactivating that one gave me the expected trace output lines.
For bug #1318 I have found a fix and I will document that soon in the bug report.
You say the fix will break programs that use absolute positioning for parsing the sysfiletree result.
That is true, but that would be wrong programming because the documentation states space delimited file descriptions.
From the ooRexx Reference:
SysFileTree returns the file descriptions (date, time, size, attributes, and file specification) space delimited in a Rexx stem variable collection.
Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To be more exact:
For file sizes < 4096MB this fix will not change layout, so no code breaking there.
Only for files > 4096MB sysfiletree output will shift one or more positions.
This could break some programs, but these specific programs are even now not working correctly because sysfiletree currently feeds them wrong sizes.
And the developer may not be aware of that.
At the same time, the number of programmers affected by breaking code is probably minimal, because the bug has been around for a long time (just tested with v4.2.0 Windows and is also in there), yet noone else had noticed and taken the trouble to report it.
The ones that raise the stink are the ones that made the programming mistakes.
Let's hope they are thankful for getting the opportunity to improve their code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To be more exact:
For file sizes < 4096MB this fix will not change layout, so no code
breaking there.
Only for files > 4096MB sysfiletree output will shift one or more
positions.
This could break some programs, but these specific programs are even now
not working correctly because sysfiletree currently feeds them wrong sizes.
And the developer may not be aware of that.
At the same time, the number of programmers affected by breaking code is
probably minimal, because the bug has been around for a long time (just
tested with v4.2.0 Windows and is also in there), yet noone else had
noticed and taken the trouble to report it.
The ones that raise the stink are the ones that made the programming
mistakes.
Let's hope they are thankful for getting the opportunity to improve their
code.
Rick is absolutely correct here. Parsing the output from sysfiletree has
been problematic, probably since filenames went beyond 8.3 format and it
was permitted to have spaces in filenames.
Whatever the manual says, this will break programs, and lots of them and is
to be avoided.
To be more exact:
For file sizes < 4096MB this fix will not change layout, so no code
breaking there.
Only for files > 4096MB sysfiletree output will shift one or more
positions.
This could break some programs, but these specific programs are even now
not working correctly because sysfiletree currently feeds them wrong sizes.
And the developer may not be aware of that.
At the same time, the number of programmers affected by breaking code is
probably minimal, because the bug has been around for a long time (just
tested with v4.2.0 Windows and is also in there), yet noone else had
noticed and taken the trouble to report it.
The ones that raise the stink are the ones that made the programming
mistakes.
Let's hope they are thankful for getting the opportunity to improve their
code.
I agree with Rick and Jon, there are loads of programs out there that depend on a specific, possibly incorrect behaviour. In my workplace we have some 900 Rexx programs still being used for database uploads and other stuff, most of the programmers are long gone and a change in behaviour would be a catastrohpy.
This is probably for the developers to discuss but how difficult would it be to make another method/function SysFileTree2 with the correct behaviour? Not very beautiful but effective.
P.O.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This thread has been discussed elsewhere, and the suggestion (Rony's I think) was that an extra option should be added to SysFileTree correctly returning the size for larger files.
This has been done on Regina and I imagine we will follow them with letter ('H') and the format output there.
It should be noted that for programmers happy to use the object oriented features, the File class has always returned the correct size. Sysfiletree is however very important to classic rexx users.
I think an RFE will be constructed shortly.
Jon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wish to do some debugging of the C source code.
But how can I add my debugging lines to the C sources?
In some places in the C source I see fprintf(stdout,...) used to write to screen.
Therefore I use the following debug lines.
While these lines give proper output from e.g. \utilities\rexx\platform\windows\rexx.cpp
they give no output when used in \extensions\rexxutil\platform\windows\rexxutil.cpp.
Am I forgetting something?
Do you have better suggestions to quickly show debugging output?
Thanks, Andre
PS1: building platform is Windows and Visual Studio 2015
PS2: more specifically, I want to investigate bug report 1318 SysFileTree wrong for files > 4096 MB (https://sourceforge.net/p/oorexx/bugs/1318)
I don't know any reason why that would not also work from rexxutil. Are
you certain the lines in question are actually getting executed? Another
possibility might be that an older version of RexxUtil is getting picked
up.
As to the bug report, note that the simple straight forward fix for this
problem is likely to break a lot of programs. Expanding the size field
would change the relative position of the returned information, breaking
any programs that used parse with absolute positions. This is the primary
reason why this has not been fixed before.
Rick
PS: The developers list is probably a better location for this sort of
discussion.
On Fri, Aug 14, 2015 at 8:42 AM, AvdP avanderputten@users.sf.net wrote:
Rick,
Thanks for your help. Indeed I was picking up an old version of rexxutil.dll. Inactivating that one gave me the expected trace output lines.
For bug #1318 I have found a fix and I will document that soon in the bug report.
You say the fix will break programs that use absolute positioning for parsing the sysfiletree result.
That is true, but that would be wrong programming because the documentation states space delimited file descriptions.
From the ooRexx Reference:
SysFileTree returns the file descriptions (date, time, size, attributes, and file specification) space delimited in a Rexx stem variable collection.
Andre
None the less, programs will still break...and the ones with the broken programs will raise the biggest stink. Voice of experience speaking here.
To be more exact:
For file sizes < 4096MB this fix will not change layout, so no code breaking there.
Only for files > 4096MB sysfiletree output will shift one or more positions.
This could break some programs, but these specific programs are even now not working correctly because sysfiletree currently feeds them wrong sizes.
And the developer may not be aware of that.
At the same time, the number of programmers affected by breaking code is probably minimal, because the bug has been around for a long time (just tested with v4.2.0 Windows and is also in there), yet noone else had noticed and taken the trouble to report it.
The ones that raise the stink are the ones that made the programming mistakes.
Let's hope they are thankful for getting the opportunity to improve their code.
That is never the case. I've said my piece, others will need to deal with
the fallout.
On Fri, Aug 14, 2015 at 6:56 PM, AvdP avanderputten@users.sf.net wrote:
Rick is absolutely correct here. Parsing the output from sysfiletree has
been problematic, probably since filenames went beyond 8.3 format and it
was permitted to have spaces in filenames.
Whatever the manual says, this will break programs, and lots of them and is
to be avoided.
Jon
On Aug 14, 2015 11:58 PM, "Rick McGuire" bigrixx@users.sf.net wrote:
I agree with Rick and Jon, there are loads of programs out there that depend on a specific, possibly incorrect behaviour. In my workplace we have some 900 Rexx programs still being used for database uploads and other stuff, most of the programmers are long gone and a change in behaviour would be a catastrohpy.
This is probably for the developers to discuss but how difficult would it be to make another method/function SysFileTree2 with the correct behaviour? Not very beautiful but effective.
P.O.
Hi Per,
This thread has been discussed elsewhere, and the suggestion (Rony's I think) was that an extra option should be added to SysFileTree correctly returning the size for larger files.
This has been done on Regina and I imagine we will follow them with letter ('H') and the format output there.
It should be noted that for programmers happy to use the object oriented features, the File class has always returned the correct size. Sysfiletree is however very important to classic rexx users.
I think an RFE will be constructed shortly.
Jon