Re: [boost] Re: 1.31.0 Release candidate 2 available - some nitpicks
Joel de Guzman wrote:
Pavel Vozenilek wrote:
2. Spirit 1.8 docs: each line in code snippets is appended by empty line. Seems as CSS problem (unless its feature).
Hmmm... which code snippets? I can't find them.
I have had a look at the docs. For example, libs/spirit/doc/scanner.html has the following code snippet: template< typename IteratorT = char const*, typename PoliciesT = scanner_policies<> > class scanner; The problem is in the html sources where every line is folloowed by a blank line, e.g.: <html> <head> <title>The Scanner and Parsing</title> ... -- this seems to be a problem with the HTML code generator. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger
Reece Dunn wrote:
Joel de Guzman wrote:
Pavel Vozenilek wrote:
2. Spirit 1.8 docs: each line in code snippets is appended by empty line. Seems as CSS problem (unless its feature).
Hmmm... which code snippets? I can't find them.
I have had a look at the docs. For example, libs/spirit/doc/scanner.html has the following code snippet:
template<
typename IteratorT = char const*,
typename PoliciesT = scanner_policies<> >
class scanner;
The problem is in the html sources where every line is folloowed by a blank line, e.g.:
<html>
<head>
<title>The Scanner and Parsing</title>
...
-- this seems to be a problem with the HTML code generator.
I don't see it. Here's what I have: <html> <head> <title>The Scanner and Parsing</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <link rel="stylesheet" href="theme/style.css" type="text/css"> </head> I see no empty blank lines. Could someone else please confirm this? -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
----- Original Message ----- From: "Joel de Guzman" <joel@boost-consulting.com> Newsgroups: gmane.comp.lib.boost.devel Sent: Thursday, January 29, 2004 2:17 AM Subject: Re: Re: 1.31.0 Release candidate 2 available - some nitpicks
Reece Dunn wrote:
Joel de Guzman wrote:
Pavel Vozenilek wrote:
[...] I see no empty blank lines. Could someone else please confirm this?
Line ending of all HTML files of spirit are of the form '\r\r\n' (just look at them with a binary editor). It's likely the result of a checking in unix file format from a windows platform (or something like that). You need to run some tools to fix line endings. Baptiste.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At 02:39 AM 1/29/2004, Baptiste Lepilleur wrote:
Line ending of all HTML files of spirit are of the form '\r\r\n' (just look at them with a binary editor).
Yep, I check the CVS files and that's the problem.
It's likely the result of a checking in unix file format from a windows platform (or something like that). You need to run some tools to fix line endings.
I think Dave Abrahams had that problem once. IIRC, the problem occurs when you check out a file on one platform, copy it to a machine running the other platform, and then check the file back in. I see this sometimes with patched files people send me. I have to strip out the extra "\r" before committing the file. We really should have a filter on CVS that doesn't allow certain line endings to be committed. Thanks, --Beman
Beman Dawes wrote:
At 02:39 AM 1/29/2004, Baptiste Lepilleur wrote:
Line ending of all HTML files of spirit are of the form '\r\r\n' (just look at them with a binary editor).
Yep, I check the CVS files and that's the problem.
Huh? Martin Wille, Hartmut Kaiser and I checked the CVS (both Spirit's and Boost's and all relevant branches) and didn't find any '\r\r\n'. See [ http://tinyurl.com/2tokp ]. There are no '\r\r\n' in there. What we found out however, is that the candidate 2 zip file that's the problem. Here are some quotes from Hartmut and Martin: Hartmut Kaiser wrote:
My CVS version is clean. But in the zip file the error is reproducible. There are simply additional newlines inside the <pre></pre> tags of the html files (these are renderend verbatim)!
Don't know, what to do with this.
Martin Wille wrote:
I'm unable to reproduce the problem with any of the four relevant CVS branches.
The contents of the ZIP file very much look like another flavour of a CR/LF vs LF problem. My text editor displays ^M and the end of most lines but didn't switch do DOS mode. This is usually an indication for inconsistent newline styles within a file.
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right? still-clueless-ly-y'rs, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right?
still-clueless-ly-y'rs,
I may be the case though, that the CVS is in a consistent but wrong state, i.e. CR/LF used consistently. If that gets checked out to a Windows box then I would expect the LF to be replaced by CR/LF resulting in CR/CR/LF. That would explain why the browsers didn't show any problem with the CVS (they can cope with both styles) while the browsers find problems in the ZIP file. (I haven't got access to the CVS right at the moment so I can't verify. However, in the light of other recent CR/LF problems, I'm quite sure CR/LF in the CVS is the problem) Don't we have an inspection tool that already checks the line endings of source files? I think it should also work on .html files (in addition to making the CVS change the line endings). Regards, m
At 08:21 AM 1/29/2004, Joel de Guzman wrote:
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right?
Yes, but I've got four different CVS checkouts, on two machines, some done with WinCVS and some with command line CVS, and all show "0d0d0a" line endings for Spirit html files but not other library's html files. Could someone else on a Windows machine please check the line endings in a CVS checkout of libs/spirit/doc/scanner.html? --Beman scanner.html: Addr 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E -------- ---- ---- ---- ---- ---- ---- ---- ---- ---------------- 00000000 3c68 746d 6c3e 0d0d 0a3c 6865 6164 3e0d <html>...<head>. 00000010 0d0a 3c74 6974 6c65 3e54 6865 2053 6361 ..<title>The Sca 00000020 6e6e 6572 2061 6e64 2050 6172 7369 6e67 nner and Parsing ...
Beman Dawes wrote:
At 08:21 AM 1/29/2004, Joel de Guzman wrote:
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right?
Could someone else on a Windows machine please check the line endings in a CVS checkout of libs/spirit/doc/scanner.html?
I see [CR][CR][LF] endings. -- I only use WinCVS, only one checkout of the tree (on this machine), and absolutely no cross platform checkouts. -- -- 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 Dawes wrote:
At 08:21 AM 1/29/2004, Joel de Guzman wrote:
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right?
Could someone else on a Windows machine please check the line endings in a CVS checkout of libs/spirit/doc/scanner.html?
I see [CR][CR][LF] endings. -- I only use WinCVS, only one checkout of the tree (on this machine), and absolutely no cross platform checkouts.
These things occur when someone checks in CR/LF file from a Unix CVS client. It sees [CR] (logical end of line) so when you check out on Windows, you get [CR] [CR/LF] (which is the physical end of line there.)
Hi, I am reading by chance this email, so I don't know if I can give you a useful hint, which you might already know. So please ignore this if it is out of point. I don't use WinCvs but cvs under CygWin for a project in SourceForge Under Cygwin "CVS will add DOS style line endings when files are CheckedOut onto a text mounted drive. It will use UNIX style line endings on binary mounted drives." So, this is what I do: # --------- only once - begin # from the home directory mkdir /mntdos mkdir dos ( subdirectory of home ) # this mount /mntdos as text mounted drive ( the correct sintax is: ) mount -t C:/GShell/Unix/Cygwin/home/dos /mntdos # --------- only once - end cd /mntdos cvs co myproject at this point I get the VCF files with CRLF instead than just with LF as it is in bynary mounted drives. Notice that after the first time I just need to : cd /mntdos even if I reboot the computer When I commit a change, the cvs server takes care of all the CRLF characters, so I don't need to worry about. Cheers, Marcello Peter Dimov wrote:
Rene Rivera wrote:
Beman Dawes wrote:
At 08:21 AM 1/29/2004, Joel de Guzman wrote:
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right?
Could someone else on a Windows machine please check the line endings in a CVS checkout of libs/spirit/doc/scanner.html?
I see [CR][CR][LF] endings. -- I only use WinCVS, only one checkout of the tree (on this machine), and absolutely no cross platform checkouts.
These things occur when someone checks in CR/LF file from a Unix CVS client. It sees [CR] (logical end of line) so when you check out on Windows, you get [CR] [CR/LF] (which is the physical end of line there.)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Rene Rivera wrote:
Beman Dawes wrote:
At 08:21 AM 1/29/2004, Joel de Guzman wrote:
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right?
Could someone else on a Windows machine please check the line endings in a CVS checkout of libs/spirit/doc/scanner.html?
I see [CR][CR][LF] endings. -- I only use WinCVS, only one checkout of the tree (on this machine), and absolutely no cross platform checkouts.
Ok, there's definitely something wrong here. Yet, I can't reporduce the problem. I did a grep for "\r\r\n" on all the files on all relevant CVSes and all relevant branches and find nothing. I do not know how to fix it. Nor do I know what really caused it. I was the only one (AFAIK) that was working on the docs and I worked only on Windows. Any help will be highly appreciated. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Rene Rivera wrote:
Beman Dawes wrote:
At 08:21 AM 1/29/2004, Joel de Guzman wrote:
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right?
Could someone else on a Windows machine please check the line endings in a CVS checkout of libs/spirit/doc/scanner.html?
I see [CR][CR][LF] endings. -- I only use WinCVS, only one checkout of the tree (on this machine), and absolutely no cross platform checkouts.
Ok, there's definitely something wrong here. Yet, I can't reporduce the problem. I did a grep for "\r\r\n" on all the files on all relevant CVSes and all relevant branches and find nothing. I do not know how to fix it. Nor do I know what really caused it. I was the only one (AFAIK) that was working on the docs and I worked only on Windows. Any help will be highly appreciated.
Ok, I did a full grep for "\r\r\n" on all the files in the candidate 2 zip file. I was shocked to see a lot all over the place, including but **not limited to** Spirit. This problem is boost-wide! Yet, again, doing a grep for "\r\r\n" on the CVS checkouts reveals nothing. One thing definite is that we must find a practical solution to this problem. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
At 11:56 AM 1/29/2004, Joel de Guzman wrote:
Rene Rivera wrote:
Beman Dawes wrote:
At 08:21 AM 1/29/2004, Joel de Guzman wrote:
Beman, might it be that your CVS chekout that's in an inconsistent state? After all, it was you who packaged the zip file, right?
Could someone else on a Windows machine please check the line endings in a CVS checkout of libs/spirit/doc/scanner.html?
I see [CR][CR][LF] endings. -- I only use WinCVS, only one checkout of the tree (on this machine), and absolutely no cross platform checkouts.
Ok, there's definitely something wrong here. Yet, I can't reporduce the problem. I did a grep for "\r\r\n" on all the files on all relevant CVSes and all relevant branches and find nothing. I do not know how to fix it. Nor do I know what really caused it. I was the only one (AFAIK) that was working on the docs and I worked only on Windows. Any help will be highly appreciated.
Have you deleted a file from you working directory and then updated from CVS? Perhaps you aren't really seeing what is in CVS because cvs thinks your files are up-to-date when in fact they differ in line endings. --Beman
(Rene Rivera <grafik.list@redshift-software.com>) wrote:
I see [CR][CR][LF] endings. -- I only use WinCVS, only one checkout of the tree (on this machine), and absolutely no cross platform checkouts.
Same is for me. Altough using TortoiseCVS. Roland
Beman Dawes <bdawes@acm.org> wrote:
Yes, but I've got four different CVS checkouts, on two machines, some done with WinCVS and some with command line CVS, and all show "0d0d0a" line endings for Spirit html files but not other library's html files.
Could someone else on a Windows machine please check the line endings in a CVS checkout of libs/spirit/doc/scanner.html?
CVS copy: Directory of C:\[cut]\home\Bronislaw\boost\boost\libs\spirit\doc 004-01-17 03:25 24 158 scanner.html binary content of the above file: 0: 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 61 64 3e 0d 0a 10: 3c 74 69 74 6c 65 3e 54 68 65 20 53 63 61 6e 6e 20: 65 72 20 61 6e 64 20 50 61 72 73 69 6e 67 3c 2f 30: 74 69 74 6c 65 3e 0d 0a 3c 6d 65 74 61 20 68 74 (CVS tool I use is from MINGW, last CVS checkout yesterday) File extracted from boost_1_31_0_rc2.zip: Directory of C:\[cut]\boost_1_31_0_rc2\libs\spirit\doc 004-01-14 09:53 24 446 scanner.html binary content of the above file: 0: 3c 68 74 6d 6c 3e 0d 0d 0a 3c 68 65 61 64 3e 0d 10: 0d 0a 3c 74 69 74 6c 65 3e 54 68 65 20 53 63 61 20: 6e 6e 65 72 20 61 6e 64 20 50 61 72 73 69 6e 67 30: 3c 2f 74 69 74 6c 65 3e 0d 0d 0a 3c 6d 65 74 61 B.
participants (10)
-
Baptiste Lepilleur -
Beman Dawes -
Bronek Kozicki -
Joel de Guzman -
Martin Wille -
Peter Dimov -
Pietrobon Marcello -
Reece Dunn -
Rene Rivera -
Roland