Re: [boost] Re: 1.31.0 Release candidate 2 available - some nitpicks
Joel de Guzman wrote:
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:
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
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.
At 02:39 AM 1/29/2004, Baptiste Lepilleur wrote:
Yep, I check the CVS files and that's the problem.
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:
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:
Martin Wille 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, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
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:
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:
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:
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:
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:
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:
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:
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