Re: munge-texi.pl

[Rik]

On 01/05/2013 01:57 PM, Rik wrote:
> On 01/05/2013 10:00 AM, address@hidden wrote:
>> Message: 6
>> Date: Sat, 5 Jan 2013 12:47:06 -0500
>> From: Michael Goffioul <address@hidden>
>> To: "John W. Eaton" <address@hidden>
>> Cc: octave maintainers mailing list <address@hidden>
>> Subject: Re: Octave 3.6.4-rc1 release candidate available for ftp
>> Message-ID:
>>      <address@hidden>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> On Thu, Jan 3, 2013 at 4:04 PM, John W. Eaton <address@hidden> wrote:
>>
>>>> The second release candidate of Octave 3.6.4 is now available from
>>>> alpha.gnu.org in the directory /gnu/octave:
>>>>
>>>>   a8261dbeb3fa23c575c5c905c6770cc0  octave-3.6.4-rc1.tar.gz  (md5sum)
>>>>
>>>>   -rw-r--r-- 1 3003 3002 18352066 Jan 03 20:36 octave-3.6.4-rc1.tar.gz
>>>>
>>>> Please help make the 3.6.4 release a success by building from this
>>>> release candidate and reporting any problems.  We could especially use
>>>> reports for Windows and OS X systems.
>>>>
>> Code compiles fine, but I've a problem rebuilding the doc (because of the
>> patch I apply, some files are regenerated). I think it's due to the move of
>> munge-texi from C++ to Perl. The file src/DOCSTRINGS is still generated by
>> C++ and it uses the CRLF newline convention. However, munge-texi.pl does
>> not chomp the CR character, so when reading src/DOCSTRINGS, it records
>> symbols as "bitand<CR>" instead of "bitand" and then fails to match them
>> when referenced in .texi files.
>>
>> I can find a local workaround for that, but I thought it's was worth
>> mentioning.
>>
>> The problem does not occur in default branch, most probably because
>> DOCSTRINGS generation has also been moved to Perl.
> 1/5/12
>
> There are a number of problems here.  First, I made the change that
> introduced munge-texi.pl and I have no memory of making it on the stable
> branch.  Touching the build process in this way seems mildly risky and it
> surprises me that I would have done this.  Is it possible that some
> Mercurial shenanigans accidentally transplanted the patches from one branch
> to another?
>
> One possibility, therefore, might be to transplant these changesets to the
> default branch and use C++ generation of documentation for the 3.6.X
> branch.  Incidentally, the changes came in after the 3.6.1 release.  Is
> there any reason you haven't seen this trouble for the 3.6.2 and 3.6.3
> releases?  Or maybe you didn't bother to try compiling those with MSVC?
>
> Finally, I specifically used chomp() in Perl to handle EOL issues.  On an
> old Windows XP system, a text file is generated with "\r\n" as the line
> ending but when I read that same file with Perl it auto-converts the line
> to end in "\n".  Maybe you can check what Perl does for you with the
> attached tst_eol.txt file.
>
> Try
>
> perl -ne "print length ($_),\"\n\"; print ord (substr ($_,3))" tst_eol.txt
>
> I get
> 4
> 10
>
> We could always use regular expressions in munge.texi to strip all space
> characters from the end of line.
>
> --Rik
>
Michael,

Sorry, tst_eol.txt is getting stripped by the mailer so it won't work as a
test bed.  For reference, I just created a file with vi with the characters
"abc".  When I save that file on a Windows system the length of it is 5
bytes as expected.

--Rik