[perl #40544] [NEW] Test for DOS line endings in Parrot text files

2 views
Skip to first unread message

Paul Cochrane

unread,
Oct 16, 2006, 5:13:13 AM10/16/06
to bugs-bi...@rt.perl.org
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40544]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40544 >


Hi,

This patch adds a test for DOS line endings in text files in the
Parrot distribution.

Comments welcome,

Paul

files affected:
MANIFEST
t/codingstd/line_endings.t

line_endings_t.patch

Chris Dolan

unread,
Oct 24, 2006, 12:54:01 AM10/24/06
to Paul Cochrane, parrotbug...@parrotcode.org
On Oct 23, 2006, at 7:39 AM, Paul Cochrane wrote:

> BEGIN {
> eval { use SVN::Client; };
> if ($@) {
> plan skip_all => 'SVN::Client not installed';
> }
> }
>

Paul,

This should be
eval {require SVN::Client; };

use() is a compile-time directive, not runtime.

Chris

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)


Amos Robinson

unread,
Oct 24, 2006, 12:42:40 AM10/24/06
to Paul Cochrane, parrotbug...@parrotcode.org
I suppose the reason it's more efficient is that it compiles it at actual
compile time. The only use I know of eval{} is catching dies...

On 10/23/06, Paul Cochrane <paultc...@gmail.com> wrote:
>
> > > This patch adds a test for DOS line endings in text files in the
> > > Parrot distribution.
> > >
> > > Comments welcome,
> >

> > Hi Paul,
> >
> > could you add a check for SVN::Client and skip the test when there is no
>
> > SVN::Client?
>
> Bernhard,
>
> No worries :-) Please see attached patch.
>
> I noticed something odd when I was testing this patch. When I used
> the following code (adapted directly from perlcritic.t )


>
> BEGIN {
> eval { use SVN::Client; };
> if ($@) {
> plan skip_all => 'SVN::Client not installed';
> }
> }
>

> and tested that the test couldn't find SVN::Client and hence would
> skip the tests, I got a compile-time error that the module wasn't in
> @INC, yet when I change the eval statement to:
>
> eval "use SVN::Client";
>
> it works (by printing just the message: "SVN::Client not installed"),
> and yet Programming Perl says that the latter C<eval> is just a less
> efficient form of the former. Any ideas what's going on here? I then
> tested perlcritic.t and found that it gives an @INC compile time error
> too when it can't find Test::Perl::Critic, and I can supply a patch
> for that if you want. The reason I ask is that even though I have a
> solution, I don't know *why* it works, and I'd like to, but can't seem
> to find any reason for the difference between the C<eval> forms.
>
> Many thanks in advance!

Bob Rogers

unread,
Oct 24, 2006, 8:30:46 PM10/24/06
to Paul Cochrane, parrotbug...@parrotcode.org
From: "Paul Cochrane" <paultc...@gmail.com>
Date: Tue, 24 Oct 2006 11:49:23 +0200

Amos and Chris,

Thanks for the feedback! I've updated the patch to use C<require>
instead of C<use>, and it is attached to this email.

Further to my question:

so do C<eval { use My::Class; };> and C<eval "use My::Class;";> get
evaluated at different times? I'm trying to understand why one
generates a compile-time error, whereas the other generates the
expected output (i.e. skips the tests and supplies the reason) but
that the docs say they are (almost) the same thing.

Here is the difference:

eval "use My::Class;"; does the following:

1. Sets up the run-time error-catching mechanism.

2. Compiles the expression (which tries to load My::Class).

3. Executes the rest of the expression (which does nothing).

4. Tears down the run-time error-catching mechanism.

eval { use My::Class; }; tries to do the following:

1. Compiles the expression (while compiling the containing block).

2. Sets up the run-time error-catching mechanism.

3. Executes the rest of the expression (which does nothing).

4. Tears down the run-time error-catching mechanism.

Since 'use' happens entirely at compile time, the eval-block case can't
catch any errors from 'use', and it fails in step 1.

-- Bob Rogers
http://rgrjr.dyndns.org/

Paul Cochrane

unread,
Oct 25, 2006, 4:58:14 AM10/25/06
to Bob Rogers, parrotbug...@parrotcode.org
Bob,

Many thanks for your reply! That's exactly the subtlety I was
interested in knowing.

Regards,

Paul

Will Coleda via RT

unread,
Feb 19, 2007, 9:00:33 PM2/19/07
to perl6-i...@perl.org
After the application of this test, we have 1265 files that don't pass muster as of 19FEB2007.

Paul Cochrane

unread,
Feb 20, 2007, 2:08:49 AM2/20/07
to parrotbug...@parrotcode.org, perl6-i...@perl.org
On 20/02/07, Will Coleda via RT <parrotbug...@parrotcode.org> wrote:
> After the application of this test, we have 1265 files that don't pass muster as of 19FEB2007.

This is related to the new test in t/distro/file_metadata.t right[1]?
In which case this is related to RT#41485. I've set the property
appropriately in my working copy, and the test is now passing. Is it
ok to do a single commit back to the repository, or is doing a single
commit ok?

Paul

[1] t/codingstd/line_endings.t passes for me as of r17073

Paul Cochrane

unread,
Feb 20, 2007, 11:03:35 AM2/20/07
to parrotbug...@parrotcode.org, perl6-i...@perl.org
On 20/02/07, Paul Cochrane <paultc...@gmail.com> wrote:
> On 20/02/07, Will Coleda via RT <parrotbug...@parrotcode.org> wrote:
> > After the application of this test, we have 1265 files that don't pass muster as of 19FEB2007.
>
> This is related to the new test in t/distro/file_metadata.t right[1]?
> In which case this is related to RT#41485. I've set the property
> appropriately in my working copy, and the test is now passing. Is it
> ok to do a single commit back to the repository, or is doing a single
> commit ok?

After a discussion on #parrot, it was decided to do a small number of
commits (it'll be about 16) updating the svn:eol-style property
(changing metadata only). This will affect a *large* number of files,
so I'm trying to prepare people before I actually do it. I will begin
the update in about 3-4 hours (by approx 19:00-20:00 GMT) and it won't
take that long to do (I hope!).

Regards,

Paul

Paul Cochrane

unread,
Feb 20, 2007, 2:45:32 PM2/20/07
to parrotbug...@parrotcode.org, perl6-i...@perl.org

The tests in t/distro/file_metadata.t should now pass as of r17102

Paul

Will Coleda via RT

unread,
Mar 15, 2007, 1:42:18 AM3/15/07
to perl6-i...@perl.org
Again, more failures.

Paul, can you coordinate with Jerry Gay (particle) to insure the test doesn't encourage updates of
files that would break the windows build? Once we can trust the output of the test, we can
update the remaining files and close the ticket.

Regards.

On Fri Mar 02 19:55:37 2007, coke wrote:
> More failures with the line endings.


Paul Cochrane

unread,
Mar 15, 2007, 5:52:36 AM3/15/07
to parrotbug...@parrotcode.org, perl6-i...@perl.org
On 15/03/07, Will Coleda via RT <parrotbug...@parrotcode.org> wrote:
> Again, more failures.
>
> Paul, can you coordinate with Jerry Gay (particle) to insure the test doesn't encourage updates of
> files that would break the windows build? Once we can trust the output of the test, we can
> update the remaining files and close the ticket.

Jerry and I have already been discussing this, and he let me know
about the problems with windows (my main problem has been lack of time
due to $work to fix the issue). He also mentioned that the test
itself is broken, and he is unable to run the relevant test due to
SVN::Client being nonexistent on CPAN. I am about to try and fix the
test so that the files which require LF keep the setting, and the rest
get 'native'. Perhaps we should skip the test for the time being to
reduce noise until the test itself is fixed.

Paul

Reply all
Reply to author
Forward
0 new messages