Skip Menu |
 

This queue is for tickets about the Math-BigInt CPAN distribution.

Report information
The Basics
Id: 29303
Status: resolved
Worked: 10 min
Priority: 0/
Queue: Math-BigInt

People
Owner: TELS [...] cpan.org
Requestors: alexander.danel [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.87
Fixed in: (no value)



Subject: BigInt-1.87 fails "test" on cygwin
Date: Tue, 11 Sep 2007 14:45:49 -0500
To: bug-Math-BigInt [...] rt.cpan.org
From: "Alexander Danel" <alexander.danel [...] gmail.com>
The Math::BigInt-1.87 has lots and lots of error under "make test" for Cygwin on Windows-2000.
Subject: Re: [rt.cpan.org #29303] BigInt-1.87 fails "test" on cygwin
Date: Tue, 11 Sep 2007 17:33:18 -0500
To: bug-Math-BigInt [...] rt.cpan.org
From: "Alexander Danel" <alexander.danel [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
The errors seem to be due to incorrect interpretation of new-lines at the ends of strings. Here is an example: Expected: "1\r" The backslash 'r' seems to be the difference. # - - - - - - - - - - - - - - On 9/11/07, Bugs in Math-BigInt via RT <bug-Math-BigInt@rt.cpan.org> wrote: Show quoted text
> > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "BigInt-1.87 fails "test" on cygwin", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [rt.cpan.org #29303]. Your ticket is accessible > on the web at: > > http://rt.cpan.org/Ticket/Display.html?id=29303 > > Please include the string: > > [rt.cpan.org #29303] > > in the subject line of all future correspondence about this issue. To do > so, > you may reply to this message. > > Thank you, > bug-Math-BigInt@rt.cpan.org > > ------------------------------------------------------------------------- > The Math::BigInt-1.87 has lots and lots of error under "make test" for > Cygwin on Windows-2000. > >
Download (untitled) / with headers
text/plain 397b
On Tue Sep 11 18:44:57 2007, alexander.danel@gmail.com wrote: Show quoted text
> The errors seem to be due to incorrect interpretation of new-lines at the > ends of strings. Here is an example:
This happens because the .t files became somehow converted to \r\n line endings and the chomp() in the .t files fails to remove the \r (0x0d) character. Will be fixed in the v1.88 release. Thanx for your report! Tels
Subject: RE: [rt.cpan.org #29303] BigInt-1.87 fails "test" on cygwin
Date: Sun, 16 Sep 2007 22:26:31 -0500
To: <bug-Math-BigInt [...] rt.cpan.org>
From: "Alexander Danel" <alexander.danel [...] gmail.com>
Download (untitled) / with headers
text/plain 1.2k
This is actually I bigger problem, because it happens with many modules under the following context: * Download the module to a MicroSoft PC from CPAN web site (CR-LF). * Install the module in a Cygwin system (LF only). It might also occur when using the "cpan" automated facility; it certainly happened when I did a web download and manual build. Any module that has a self referential test is at risk. I've also seen it happen for a module that has a self-referential method of extracting constants from the POD documentation. So really, this problem needs to be escalated to the CPAN gurus, in my opinion. Can you do that? Alexander Show quoted text
-----Original Message----- From: via RT [mailto:bug-Math-BigInt@rt.cpan.org] Sent: Sunday, September 16, 2007 6:37 AM To: alexander.danel@gmail.com Subject: [rt.cpan.org #29303] BigInt-1.87 fails "test" on cygwin <URL: http://rt.cpan.org/Ticket/Display.html?id=29303 > On Tue Sep 11 18:44:57 2007, alexander.danel@gmail.com wrote:
> The errors seem to be due to incorrect interpretation of new-lines at the > ends of strings. Here is an example:
This happens because the .t files became somehow converted to \r\n line endings and the chomp() in the .t files fails to remove the \r (0x0d) character. Will be fixed in the v1.88 release. Thanx for your report! Tels
Subject: Re: [rt.cpan.org #29303] BigInt-1.87 fails "test" on cygwin
Date: Mon, 17 Sep 2007 18:23:11 +0200
To: bug-Math-BigInt [...] rt.cpan.org
From: Tels <nospam-abuse [...] bloodgate.com>
Download (untitled) / with headers
text/plain 2.7k
Moin, On Monday 17 September 2007 05:23:14 Alexander Danel via RT wrote: Show quoted text
> Queue: Math-BigInt > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=29303 > > > This is actually I bigger problem, because it happens with many modules > under the following context: > > * Download the module to a MicroSoft PC from CPAN web site (CR-LF). > * Install the module in a Cygwin system (LF only).
No, modules on CPAN are LF, well, at least modules that are created on Linux systems - as are mine. What likely is that you unzipped the module under Windows with WinZIP, and this (or something similiar) converted the line endings. If you run: cpansign --verify inside Cygwin, I expect the signature check to fail. In this case one could argue that the module got altered, and is thus broken per se, but I think making it robust against that line ending change is much easier. However, any other changes are also likely to break the module. You cannot simple take the module or .t files, alter them, and then expect anything still to work. For instance, re-encoding them in something else than UTF-8 would f.i. break any module that has Unicode UTF-8 characters in its source. Show quoted text
> It might also occur when using the "cpan" automated facility; it > certainly happened when I did a web download and manual build. Any > module that has a self referential test is at risk.
Well, any module that is altered after download is at risk :) Show quoted text
> I've also seen it > happen for a module that has a self-referential method of extracting > constants from the POD documentation. > > So really, this problem needs to be escalated to the CPAN gurus, in my > opinion. Can you do that?
I don't think so, as the problem is a windows problem, not a CPAN problem. However, you are right, modules that read their own data (or whatever data) must expect line endings of either CR-LF, LF or CR (mac) format and many many don't do. I fear that the only remedy is to bug report each module where this happens. What would really help is if someone could setup a cpan-tester machine that purposefull converts .t files or .pm files to CR-LF and then runs the testsuite - this would catch most of these problems. (However, you will get people arguing that their module works only in unaltered form as downloaded from CPAN :) It might also be a good idea to amend the documentation about chomp(). I sent an email to perl5-porters asking about this topic. All the best, Tels -- Signed on Mon Sep 17 18:13:00 2007 with key 0x93B84C15. View my photo gallery: http://bloodgate.com/photos PGP key on http://bloodgate.com/tels.asc or per email. "COMPASS [for the CDC-6000 series] is the sort of assembler one expects from a corporation whose president codes in octal." -- J.N. Gray
Download (untitled)
application/pgp-signature 481b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 143b
This bug should be resolved with the release of v1.88 - if it isn't, please reply to this email to re-open the bug. Thank you for your report!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.