[threads] Compilation problems on CW and others...
Michael, I believe one of the last remaining problems with the compilation of threads in Win32 platforms, maybe others, is that the line-endings on the files are totally incorrect. When I look at the files I see double spaced lines with line-endings of the CR-CR-LF variety. This causes all kinds of problems when the CW preprocessor tries to parse multi-line macros as it only parses the first line and error on the rest, for example: ### mwcc Compiler: # File: ..\src\exceptions.cpp # ------------------------------ # 49: || defined(__CYGWIN__) # Error: ^^ # declaration syntax error Which is the second line of: # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) \ || defined(__CYGWIN__) It will likely be easier for me to fix this directly than have you try and get the line endings just right, as the editor I use has functionality to fix those problems. Would it be OK for me to fix those at this time? I don't want to collide with anything you might be changing. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Michael,
I believe one of the last remaining problems with the compilation of threads in Win32 platforms, maybe others, is that the line-endings on the files are totally incorrect. When I look at the files I see double spaced lines with line-endings of the CR-CR-LF variety. This causes all kinds of problems when the CW preprocessor tries to parse multi-line macros as it only parses the first line and error on the rest, for example:
### mwcc Compiler: # File: ..\src\exceptions.cpp # ------------------------------ # 49: || defined(__CYGWIN__) # Error: ^^ # declaration syntax error
Which is the second line of:
# if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) \ || defined(__CYGWIN__)
I fixed this particular error by moving the 2nd line onto the end of the first, not realizing that the linebreaks were the problem. Feel free to move it back if you want.
It will likely be easier for me to fix this directly than have you try and get the line endings just right, as the editor I use has functionality to fix those problems.
Would it be OK for me to fix those at this time? I don't want to collide with anything you might be changing.
I've just checked in some changes, and don't plan to do anything else for some time, probably not for a couple of days. Please do. I wish I knew why they are wrong in the first place. Mike
Michael Glassford wrote:
Rene Rivera wrote:
# if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) \ || defined(__CYGWIN__)
I fixed this particular error by moving the 2nd line onto the end of the first, not realizing that the linebreaks were the problem. Feel free to move it back if you want.
I just left it as you last changed it :-)
I've just checked in some changes, and don't plan to do anything else for some time, probably not for a couple of days. Please do.
OK. All done. With much better results.
I wish I knew why they are wrong in the first place.
Usually it happens when you tell CVS to use different line endings than your platform uses. The most common case I've seen is when people cross-mount a repository on Linux and Windows. PS. The only error on CW is now: ### mwcc Compiler: # File: ..\src\read_write_mutex.cpp # ------------------------------------ # 44: EXT("Assertion failed (func=%s, file=%s, line=%d): %s"), func, file, line, expr); # Error: ^ # undefined identifier 'snprintf' Which happens because for CW this is supposed to be std::snprintf (the _sntprintf resolves to snprintf). Adding a "using namespace std;" in the function solves that problem. Now the tests run, and some happen to fail :-( More things that are suspicious... ### mwcc Compiler: # File: ..\src\read_write_mutex.cpp # ------------------------------------ # 412: } # Warning: ^ # return value expected ### mwcc Compiler: # 526: } # Warning: ^ # return value expected ### mwcc Compiler: # 584: } # Warning: ^ # return value expected ### mwcc Compiler: # 613: } # Warning: ^ # return value expected I don't know what the intent on those are, so I leave you to fix that. Another possible problem, although not on VC and CW, is the use of the auto-link support in the tests. For CW it causes warnings: ### mwld Linker Warning: # Cannot locate library "boost_thread-cw8-mt-1_31" specified in #pragma comment(lib,...) But others will causes errors. Adding "<define>BOOST_ALL_NO_LIB=1" to the test target requirements disables the auto-link code. OK to commit those two changes? (the using.., and define..) That leaves the one and only runtime failure: execute-test C:\Boost\bin\boost\libs\thread\test\test_read_write_mutex.test\cw\release\threading-multi\test_read_write_mutex.run ====== BEGIN OUTPUT ====== Running 1 test case... plain test, sp=0 try test, sp=0 timed test, sp=0 plain test, sp=1 try test, sp=1 timed test, sp=1 plain test, sp=2 try test, sp=2 timed test, sp=2 test_read_write_mutex.cpp(206): error in "test_read_write_mutex": test r2.m_value == 10 failed plain test, sp=3 try test, sp=3 timed test, sp=3 *** 1 failure detected in test suite "Boost.Threads: read_write_mutex test suite" EXIT STATUS: 201 ====== END OUTPUT ====== -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
OK to commit those two changes? (the using.., and define..)
No reply, so I'm assuming it's OK ;-) Both of those changes are now in CVS. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Michael Glassford wrote:
Rene Rivera wrote:
# if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) \ || defined(__CYGWIN__)
I fixed this particular error by moving the 2nd line onto the end of the first, not realizing that the linebreaks were the problem. Feel free to move it back if you want.
I just left it as you last changed it :-)
OK.
I've just checked in some changes, and don't plan to do anything else for some time, probably not for a couple of days. Please do.
OK. All done. With much better results.
I wish I knew why they are wrong in the first place.
Usually it happens when you tell CVS to use different line endings than your platform uses. The most common case I've seen is when people cross-mount a repository on Linux and Windows.
Yes, but I'm not doing this.
PS. The only error on CW is now:
### mwcc Compiler: # File: ..\src\read_write_mutex.cpp # ------------------------------------ # 44: EXT("Assertion failed (func=%s, file=%s, line=%d): %s"), func, file, line, expr); # Error: ^ # undefined identifier 'snprintf'
Which happens because for CW this is supposed to be std::snprintf (the _sntprintf resolves to snprintf). Adding a "using namespace std;" in the function solves that problem.
OK.
Now the tests run, and some happen to fail :-(
I'll look.
More things that are suspicious...
### mwcc Compiler: # File: ..\src\read_write_mutex.cpp # ------------------------------------ # 412: } # Warning: ^ # return value expected ### mwcc Compiler: # 526: } # Warning: ^ # return value expected ### mwcc Compiler: # 584: } # Warning: ^ # return value expected ### mwcc Compiler: # 613: } # Warning: ^ # return value expected
I think I've fixed these.
I don't know what the intent on those are, so I leave you to fix that.
Another possible problem, although not on VC and CW, is the use of the auto-link support in the tests. For CW it causes warnings:
### mwld Linker Warning: # Cannot locate library "boost_thread-cw8-mt-1_31" specified in #pragma comment(lib,...)
But others will causes errors. Adding "<define>BOOST_ALL_NO_LIB=1" to the test target requirements disables the auto-link code.
OK to commit those two changes? (the using.., and define..)
Yes.
That leaves the one and only runtime failure:
execute-test C:\Boost\bin\boost\libs\thread\test\test_read_write_mutex.test\cw\release\threading-multi\test_read_write_mutex.run
====== BEGIN OUTPUT ====== Running 1 test case... plain test, sp=0 try test, sp=0 timed test, sp=0 plain test, sp=1 try test, sp=1 timed test, sp=1 plain test, sp=2 try test, sp=2 timed test, sp=2 test_read_write_mutex.cpp(206): error in "test_read_write_mutex": test r2.m_value == 10 failed plain test, sp=3 try test, sp=3 timed test, sp=3
*** 1 failure detected in test suite "Boost.Threads: read_write_mutex test suite"
EXIT STATUS: 201 ====== END OUTPUT ======
Thanks, I'll look into this. Mike
Michael Glassford <glassfordm@hotmail.com> writes:
I wish I knew why they are wrong in the first place. Usually it happens when you tell CVS to use different line endings than your platform uses. The most common case I've seen is when people cross-mount a repository on Linux and Windows.
Yes, but I'm not doing this.
Are the files in question checked in as binary? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Michael Glassford <glassfordm@hotmail.com> writes:
I wish I knew why they are wrong in the first place.
Usually it happens when you tell CVS to use different line endings than your platform uses. The most common case I've seen is when people cross-mount a repository on Linux and Windows.
Yes, but I'm not doing this.
Are the files in question checked in as binary?
They don't seem to be in CVS. Another possibility is a mismatch between what the end-lines in the CVS client are set to vs. what the editor you use produces. For example if CVS is set to CR-LF and your editor is producing LF only. Many IDEs handle any endline variety, but at the same time they tend to produce mixed end-line files. In this case I think the change happened 3 weeks ago. If you look at the history of libs/thread/src/condition.cpp you'll see that there is a check in of version 1.19 which seems to have no differences: http://tinyurl.com/653xz - That is what an end-of-line only change looks like to the diff, and what the change I did last night also looks like. Beman has a program which runs checks for this kind of stuff when he was running the regressions tests: tools/inspect. Perhaps we can have someone run those tests again? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Beman has a program which runs checks for this kind of stuff when he was running the regressions tests: tools/inspect. Perhaps we can have someone run those tests again?
OK, just made myself a script to run this program. I replaced the old report, see the numerous errors at: http://www.boost.org/regression-logs/inspection_report.html Boost Inspection Report The summary is as follows: 8022 files scanned 674 directories scanned 5647 problems reported problem counts: 3934 files missing Boost license info 1234 files missing copyrights 114 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 91 broken links 45 unlinked files 53 file names too long 175 files with tabs So if people can look at this and help out in fixing the problems that would be a wonderful way to contribute ;-) PS. I can't run this as a automated job, but I'll be glad to run it frequently, and on demand if asked. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera <grafik.list@redshift-software.com> writes:
problem counts: 3934 files missing Boost license info
Are we making that a formal release requirement now? Otherwise I think there ought to be a view that filters that problem out. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
problem counts: 3934 files missing Boost license info
Are we making that a formal release requirement now? Otherwise I think there ought to be a view that filters that problem out.
Don't know... I just ran the default for the inspect tool which does all the checks. You tell me; Should I filter that out? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
problem counts: 3934 files missing Boost license info
Are we making that a formal release requirement now? Otherwise I think there ought to be a view that filters that problem out.
Don't know... I just ran the default for the inspect tool which does all the checks. You tell me; Should I filter that out?
OK, taking to myself ;-) I ran it again without that check. I guess that since we are unlikely to go change >3900 files in a few days it's pointless even if it was a requirement. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
On Sat, 17 Jul 2004 16:47:57 -0500, Rene Rivera wrote
Don't know... I just ran the default for the inspect tool which does all the checks. You tell me; Should I filter that out?
OK, taking to myself ;-) I ran it again without that check. I guess that since we are unlikely to go change >3900 files in a few days it's pointless even if it was a requirement.
We've never enforced that every last file contain licensing information -- particularly the documentation and Jamfiles. By my eye this is the majority of the problems. I'm much more worried about the tabs and file lengths. I believe 31 chars is the maximum allowed on CD-ROMs and MAC platforms. And, of course, tabs are evil... So if we wanted to filter down the report I suggest we throw out all the licensing issues... Jeff BTW: I've already checked in fixes for the date_time long filenames and files with tabs...
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sat, 17 Jul 2004 16:47:57 -0500, Rene Rivera wrote
Don't know... I just ran the default for the inspect tool which does all the checks. You tell me; Should I filter that out?
OK, taking to myself ;-) I ran it again without that check. I guess that since we are unlikely to go change >3900 files in a few days it's pointless even if it was a requirement.
We've never enforced that every last file contain licensing information -- particularly the documentation and Jamfiles. By my eye this is the majority of the problems.
I'm much more worried about the tabs and file lengths. I believe 31 chars is the maximum allowed on CD-ROMs and MAC platforms. And, of course, tabs are evil...
So if we wanted to filter down the report I suggest we throw out all the licensing issues...
I respectfully disagree. Improving our licensing consistency is an important goal for Boost, and leaving off licenses/copyrights is a real barrier to adoption. Let's not allow it to get worse, at least. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sat, 17 Jul 2004 20:51:05 -0400, David Abrahams wrote
So if we wanted to filter down the report I suggest we throw out all the licensing issues...
I respectfully disagree. Improving our licensing consistency is an important goal for Boost, and leaving off licenses/copyrights is a real barrier to adoption. Let's not allow it to get worse, at least.
I don't disagree with improving things, but we need an organized effort to modify that many files that isn't right before the release. For example, Date-time has be bunch of documentation files that don't have license info directly embedded. However, I don't think there can be any confusion since the license is linked from the first page of the docs and is in every source file. I don't feel that adding a license reference in every doc file is a valueable use of my time right now. So, let me clarify that I was thinking of these auxilary files like Jamfiles and documentation files that I consider less important. I think that all source files need a copyright and license reference. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sat, 17 Jul 2004 20:51:05 -0400, David Abrahams wrote
So if we wanted to filter down the report I suggest we throw out all the licensing issues...
I respectfully disagree. Improving our licensing consistency is an important goal for Boost, and leaving off licenses/copyrights is a real barrier to adoption. Let's not allow it to get worse, at least.
I don't disagree with improving things, but we need an organized effort to modify that many files that isn't right before the release. For example, Date-time has be bunch of documentation files that don't have license info directly embedded. However, I don't think there can be any confusion since the license is linked from the first page of the docs and is in every source file. I don't feel that adding a license reference in every doc file is a valueable use of my time right now.
So, let me clarify that I was thinking of these auxilary files like Jamfiles and documentation files that I consider less important. I think that all source files need a copyright and license reference.
What I would like to ensure is that the number of files without license or copyright is no greater than it was at the last release. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sun, 18 Jul 2004 12:02:21 -0400, David Abrahams wrote
What I would like to ensure is that the number of files without license or copyright is no greater than it was at the last release.
That's reasonable :-) Jeff
David Abrahams wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
So if we wanted to filter down the report I suggest we throw out all the licensing issues...
I respectfully disagree. Improving our licensing consistency is an important goal for Boost, and leaving off licenses/copyrights is a real barrier to adoption. Let's not allow it to get worse, at least.
With that in mind I just changed the tests I run, again ;-) Now in addition to the "regular" syntax, and copyright checks page: http://www.boost.org/regression-logs/inspection_report.html I added a different page for the license check: http://www.boost.org/regression-logs/license_report.html That way at least we know what's missing if anyone wants to work on improving the situation. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
On Mon, 19 Jul 2004 15:08:01 -0500, Rene Rivera wrote
David Abrahams wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
So if we wanted to filter down the report I suggest we throw out all the licensing issues...
I respectfully disagree. Improving our licensing consistency is an important goal for Boost, and leaving off licenses/copyrights is a real barrier to adoption. Let's not allow it to get worse, at least.
With that in mind I just changed the tests I run, again ;-) Now in addition to the "regular" syntax, and copyright checks page:
http://www.boost.org/regression-logs/inspection_report.html
I added a different page for the license check:
http://www.boost.org/regression-logs/license_report.html
That way at least we know what's missing if anyone wants to work on improving the situation.
Thanks that's nice. I've been thinking about this more. You will notice all the 'issues' in date-time amount to code in the examples subtree and documentation. I've been resisting cluttering example code with copyright and licensing stuff. But now I'm thinking that this can just be tagged onto the bottom. I suppose docs are pretty much the same. BTW, not to open the proverbial can of worms, but I'm betting inspect isn't looking at .xml files. And now that we have a fair number of xml files I'm certain there are problems in there... Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Mon, 19 Jul 2004 15:08:01 -0500, Rene Rivera wrote
David Abrahams wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
So if we wanted to filter down the report I suggest we throw out all the licensing issues...
I respectfully disagree. Improving our licensing consistency is an important goal for Boost, and leaving off licenses/copyrights is a real barrier to adoption. Let's not allow it to get worse, at least.
With that in mind I just changed the tests I run, again ;-) Now in addition to the "regular" syntax, and copyright checks page:
http://www.boost.org/regression-logs/inspection_report.html
I added a different page for the license check:
http://www.boost.org/regression-logs/license_report.html
That way at least we know what's missing if anyone wants to work on improving the situation.
Thanks that's nice. I've been thinking about this more. You will notice all the 'issues' in date-time amount to code in the examples subtree and documentation. I've been resisting cluttering example code with copyright and licensing stuff. But now I'm thinking that this can just be tagged onto the bottom. I suppose docs are pretty much the same.
Ah, no, I don't think so. I'm pretty sure license/copyright info needs to go near the top of files. Uniformity is the name of the game where making lawyers comfortable is concerned. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Mon, 19 Jul 2004 18:36:29 -0400, David Abrahams wrote
Thanks that's nice. I've been thinking about this more. You will notice all the 'issues' in date-time amount to code in the examples subtree and documentation. I've been resisting cluttering example code with copyright and licensing stuff. But now I'm thinking that this can just be tagged onto the bottom. I suppose docs are pretty much the same.
Ah, no, I don't think so. I'm pretty sure license/copyright info needs to go near the top of files. Uniformity is the name of the game where making lawyers comfortable is concerned.
Well, I hate to get ornery, but we aren't here to serve the lawyers. I'm certain that legally it can go anywhere in the file. When the license/copyright is at the top it just interferes with the documentation. Remember I'm not talking about source files in the library -- I'm talking about stuff in the example subtree that winds up in the documentation. And if the lawyers can't figure out how to use grep then too bad -- maybe they could hire one of us poor programmers to write a program to help them sort it out... Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Mon, 19 Jul 2004 18:36:29 -0400, David Abrahams wrote
Thanks that's nice. I've been thinking about this more. You will notice all the 'issues' in date-time amount to code in the examples subtree and documentation. I've been resisting cluttering example code with copyright and licensing stuff. But now I'm thinking that this can just be tagged onto the bottom. I suppose docs are pretty much the same.
Ah, no, I don't think so. I'm pretty sure license/copyright info needs to go near the top of files. Uniformity is the name of the game where making lawyers comfortable is concerned.
Well, I hate to get ornery, but we aren't here to serve the lawyers.
No, we're here to serve the C++ community. Inasmuch as corporate lawyers are uncomfortable with the format, it will inhibit programmers from using Boost.
I'm certain that legally it can go anywhere in the file.
Me too.
When the license/copyright is at the top it just interferes with the documentation. Remember I'm not talking about source files in the library -- I'm talking about stuff in the example subtree that winds up in the documentation.
Is there some reason the documentation needs to show the license/copyright portion of the example files??
And if the lawyers can't figure out how to use grep then too bad -- maybe they could hire one of us poor programmers to write a program to help them sort it out...
Actually, that's what they're doing at several large companies. Evaluating all of Boost is still an enormous task. I think we should make it as painless as possible. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Mon, 19 Jul 2004 20:30:54 -0400, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
When the license/copyright is at the top it just interferes with the documentation. Remember I'm not talking about source files in the library -- I'm talking about stuff in the example subtree that winds up in the documentation.
Is there some reason the documentation needs to show the license/copyright portion of the example files??
The files from the examples directory get automatically processed into the documentation -- so unless we add another step to automatically strip the license / copyright it shows up in the docs. Sure, it can be added, but it's more time spent off-task...
And if the lawyers can't figure out how to use grep then too bad -- maybe they could hire one of us poor programmers to write a program to help them sort it out...
Actually, that's what they're doing at several large companies.
Sure -- I've worked with plenty of them and promoted Boost everywhere. Of course, licensing has to be approved. Some companies have an efficient evaluation process and some don't. If they have an inefficient process then they spend lots of money figuring out that it is ok to use Boost -- some can't ever decide that it's ok. From what I've seen this is mostly a problem with the companies themselves and not a problem with the structure of Boost...
Evaluating all of Boost is still an enormous task. I think we should make it as painless as possible.
Don't disagree, but there needs to be limits on the amount of time we spend on it. To me, if some big company really insists on getting every single file in boost 100% consistent then they should pay someone to get it consistent -- perhaps you ;-) Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Mon, 19 Jul 2004 20:30:54 -0400, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
When the license/copyright is at the top it just interferes with the documentation. Remember I'm not talking about source files in the library -- I'm talking about stuff in the example subtree that winds up in the documentation.
Is there some reason the documentation needs to show the license/copyright portion of the example files??
The files from the examples directory get automatically processed into the documentation -- so unless we add another step to automatically strip the license / copyright it shows up in the docs. Sure, it can be added, but it's more time spent off-task...
It shouldn't show up in the docs at the top *or* the bottom, so IMO it's on-task if we care about good documentation.
And if the lawyers can't figure out how to use grep then too bad -- maybe they could hire one of us poor programmers to write a program to help them sort it out...
Actually, that's what they're doing at several large companies.
Sure -- I've worked with plenty of them and promoted Boost everywhere. Of course, licensing has to be approved. Some companies have an efficient evaluation process and some don't. If they have an inefficient process then they spend lots of money figuring out that it is ok to use Boost -- some can't ever decide that it's ok. From what I've seen this is mostly a problem with the companies themselves and not a problem with the structure of Boost...
Evaluating all of Boost is still an enormous task. I think we should make it as painless as possible.
Don't disagree, but there needs to be limits on the amount of time we spend on it. To me, if some big company really insists on getting every single file in boost 100% consistent then they should pay someone to get it consistent -- perhaps you ;-)
I don't see how putting those 4-5 lines at the bottom of example files is going to save us any time. In my case it's going to cost me time because my editor automatically generates them at the top and puts my cursor below them ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Mon, 19 Jul 2004 22:14:55 -0400, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
Don't disagree, but there needs to be limits on the amount of time we spend on it. To me, if some big company really insists on getting every single file in boost 100% consistent then they should pay someone to get it consistent -- perhaps you ;-)
I don't see how putting those 4-5 lines at the bottom of example files is going to save us any time. In my case it's going to cost me time because my editor automatically generates them at the top and puts my cursor below them ;-)
So, truth be told, I wrote a script, made the change, and checked it in before we started this discussion -- so that's part of why I'm being difficult. I'm not dealing with any new code in this case. And I think cntl-home will put you at the top so you can insert above the generated text -- 1/4 of a second maybe ;-) Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Mon, 19 Jul 2004 22:14:55 -0400, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
Don't disagree, but there needs to be limits on the amount of time we spend on it. To me, if some big company really insists on getting every single file in boost 100% consistent then they should pay someone to get it consistent -- perhaps you ;-)
I don't see how putting those 4-5 lines at the bottom of example files is going to save us any time. In my case it's going to cost me time because my editor automatically generates them at the top and puts my cursor below them ;-)
So, truth be told, I wrote a script, made the change, and checked it in before we started this discussion -- so that's part of why I'm being difficult. I'm not dealing with any new code in this case. And I think cntl-home will put you at the top so you can insert above the generated text -- 1/4 of a second maybe ;-)
I think you should undo it and spend the time instead to make the doc generator strip out copyrights (which needs to be done anyway). Every new way that people decide to "get creative" with licensing, including placement, weakens the whole project of trying to establish a uniform license. Other projects have no problems using a strictly uniform licensing convention; this doesn't seem like a place we have to express our "cussed individualism". -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Jeff Garland wrote:
BTW, not to open the proverbial can of worms, but I'm betting inspect isn't looking at .xml files. And now that we have a fair number of xml files I'm certain there are problems in there...
I see worms ;-) -- With some minor changes and movement of code inspect now checks xml files, and many other text/source files. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Rene Rivera wrote:
Beman has a program which runs checks for this kind of stuff when he was running the regressions tests: tools/inspect. Perhaps we can have someone run those tests again?
OK, just made myself a script to run this program. I replaced the old report, see the numerous errors at:
http://www.boost.org/regression-logs/inspection_report.html Boost Inspection Report
The summary is as follows:
8022 files scanned 674 directories scanned 5647 problems reported
problem counts: 3934 files missing Boost license info 1234 files missing copyrights 114 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 91 broken links 45 unlinked files 53 file names too long 175 files with tabs
So if people can look at this and help out in fixing the problems that would be a wonderful way to contribute ;-)
PS. I can't run this as a automated job, but I'll be glad to run it frequently, and on demand if asked.
Boost.Threads: * libs/thread/index.html: broken link: doc/index.html, missing copyright Not sure where this should point to, since Boost.Threads now uses BoostBook. * libs/thread/src/mutex.cpp: invalid (cr only) line-ending Fixed. * libs/thread/src/recursive_mutex.cpp: invalid (cr only) line-ending Fixed. * libs/thread/test/test_read_write_mutex.cpp: tabs in file Fixed. Mike
Michael Glassford wrote:
Rene Rivera wrote:
114 files with invalid line endings
I just fixed all the rest of the line-ending errors. Excepting the 1 for the test case for the inspection program itself.
* libs/thread/index.html: broken link: doc/index.html, missing copyright
Not sure where this should point to, since Boost.Threads now uses BoostBook.
If I remember correctly links to the Boost.Book docs get filled in shortly before the actual release when those docs get checked into CVS. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
* libs/thread/index.html: broken link: doc/index.html, missing copyright
Not sure where this should point to, since Boost.Threads now uses BoostBook.
If I remember correctly links to the Boost.Book docs get filled in shortly before the actual release when those docs get checked into CVS.
So: should this file exist in CVS or should it be added before release? If it should exist in CVS, then we'll get spirous warnings from it, right? - Volodya
http://www.boost.org/regression-logs/inspection_report.html Boost Inspection Report
Thanks, regex: fixed. type_traits: one spurious error from a forwarding html index file. config: lots of spurious errors from machine generated files (they have a licence declaration but no owner as such - can/should a machine generated file have one?). John.
John Maddock wrote:
http://www.boost.org/regression-logs/inspection_report.html Boost Inspection Report
Thanks,
Welcome.
regex: fixed. type_traits: one spurious error from a forwarding html index file.
Thanks :-) Just updated the report to reflect your changes.
config: lots of spurious errors from machine generated files (they have a licence declaration but no owner as such - can/should a machine generated file have one?).
They could, and they probably should. After all even if they are machine generated they are based on some original source that someone wrote. So even if it is machine generated, the text within it is someones substantive work. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
David Abrahams wrote:
Michael Glassford <glassfordm@hotmail.com> writes:
I wish I knew why they are wrong in the first place.
Usually it happens when you tell CVS to use different line endings than your platform uses. The most common case I've seen is when people cross-mount a repository on Linux and Windows.
Yes, but I'm not doing this.
Are the files in question checked in as binary?
They don't seem to be in CVS.
Another possibility is a mismatch between what the end-lines in the CVS client are set to vs. what the editor you use produces. For example if CVS is set to CR-LF and your editor is producing LF only. Many IDEs handle any endline variety, but at the same time they tend to produce mixed end-line files.
I'm using the VC++ 7.1 editor. Can you suggest an editor or tool on Windows that will detect and/or fix invalid line endings?
In this case I think the change happened 3 weeks ago. If you look at the history of libs/thread/src/condition.cpp you'll see that there is a check in of version 1.19 which seems to have no differences: http://tinyurl.com/653xz - That is what an end-of-line only change looks like to the diff, and what the change I did last night also looks like.
Beman has a program which runs checks for this kind of stuff when he was running the regressions tests: tools/inspect. Perhaps we can have someone run those tests again?
I did try this, but haven't got it building yet. Judging from the report you made available, it doesn't tell where they are, anyway. Mike
Michael Glassford wrote:
I'm using the VC++ 7.1 editor. Can you suggest an editor or tool on Windows that will detect and/or fix invalid line endings?
I use SciTE; http://scintilla.sourceforge.net/SciTE.html It has an option for showing the line endings as [CR][LF] symbols. And you can set which line endings to use. The way I fix the problem is to show the line endings, and to set line endings to [CR][LF], load a file, do a global search+replace for [CR][LF] to erase all empty double lines, tell SciTE to convert all endings to my selected one. It's really only a load, replace, convert, save sequence, after some practice it only takes about 2 seconds per file :-) My other editor, the CodeWarrior IDE does the conversion automatically. That is just load and it notices the problem and converts, then save. But it doesn't get rid of the extra empty lines.
Beman has a program which runs checks for this kind of stuff when he was running the regressions tests: tools/inspect. Perhaps we can have someone run those tests again?
I did try this, but haven't got it building yet. Judging from the report you made available, it doesn't tell where they are, anyway.
It tells you the file. Is that not enough? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Michael Glassford wrote:
I'm using the VC++ 7.1 editor. Can you suggest an editor or tool on Windows that will detect and/or fix invalid line endings?
I use SciTE; http://scintilla.sourceforge.net/SciTE.html
It has an option for showing the line endings as [CR][LF] symbols. And you can set which line endings to use.
The way I fix the problem is to show the line endings, and to set line endings to [CR][LF], load a file, do a global search+replace for [CR][LF] to erase all empty double lines, tell SciTE to convert all endings to my selected one. It's really only a load, replace, convert, save sequence, after some practice it only takes about 2 seconds per file :-)
Thanks! It seems to be just what I was looking for.
My other editor, the CodeWarrior IDE does the conversion automatically. That is just load and it notices the problem and converts, then save. But it doesn't get rid of the extra empty lines.
I used to use CodeWarrior on a Mac and liked it a lot, but don't have access to it now.
Beman has a program which runs checks for this kind of stuff when he was running the regressions tests: tools/inspect. Perhaps we can have someone run those tests again?
I did try this, but haven't got it building yet. Judging from the report you made available, it doesn't tell where they are, anyway.
It tells you the file. Is that not enough?
It is if you have an editor that will show them or search and replace them; unless I'm missing something, mine didn't. Now that I have SciTE, I see a problem: for some reason all my files are being checked out with only LF line endings. I'm using the latest version of TortoiseCVS, which was supposed to handle line endings properly. I wonder what's up? On the theory that it seemed to be working for the most part, I removed the stray CR that was in the two files indicated by Beman's checking program and checked them in. Let me know if this doesn't do the right thing. Mike
Michael Glassford wrote:
Now that I have SciTE, I see a problem: for some reason all my files are being checked out with only LF line endings. I'm using the latest version of TortoiseCVS, which was supposed to handle line endings properly. I wonder what's up?
It will only be a problem if you use an editor which doesn't respect the existing line endings in the file -- And very few are that nice. Ideally you want to make sure that the line endings CVS gives you match those of your platform to reduce chances of misbehavior. But as long as you feed CVS consistent EOLs no problems should arise.
On the theory that it seemed to be working for the most part, I removed the stray CR that was in the two files indicated by Beman's checking program and checked them in. Let me know if this doesn't do the right thing.
Seems to have worked. You might want to investigate which editor on your machine messes up the EOLs. Now that you have SciTE you should be able to see which editor is to blame. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera <grafik.list@redshift-software.com> writes:
Michael Glassford wrote:
Now that I have SciTE, I see a problem: for some reason all my files are being checked out with only LF line endings. I'm using the latest version of TortoiseCVS, which was supposed to handle line endings properly. I wonder what's up?
It will only be a problem if you use an editor which doesn't respect the existing line endings in the file -- And very few are that nice.
Emacs does that very well. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (6)
-
David Abrahams -
Jeff Garland -
John Maddock -
Michael Glassford -
Rene Rivera -
Vladimir Prus