[perl #40589] [PATCH] Adding (some) coding standards tests to the default tests

[Paul Cochrane]

# New Ticket Created by  "Paul Cochrane" 
# Please include the string:  [perl #40589]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40589 >


Hi,

This patch adds the C, C and C
tests to the default list of tests run when one performs C
on the Parrot distro.  It also appends the perl emacs/vim coda to the
file as this is a perl script.

Comments welcome!

Paul


files affected:

t/harness
Index: t/harness
===
--- t/harness	(revision 15005)
+++ t/harness	(working copy)
@@ -159,8 +159,17 @@
   stm );
 # manifest.t was moved from t/perl to t/distro
 # codingstd.t was moved from t/perl to t/codingstd
-push @default_tests, 't/distro/manifest.t', 't/codingstd/cppcomments.t';
+push @default_tests, 't/distro/manifest.t';
 
+# collect the coding standard tests (that we want to run) together and
+# append them to the list of default tests
+my @coding_std_tests = map { "t/codingstd/$_" } qw( c_code_coda.t 
+cppcomments.t 
+cuddled_else.t 
+tabs.t 
+);
+push @default_tests, @coding_std_tests;
+
 my @tests = @ARGV ? map { glob( $_ ) } @ARGV : @default_tests;
 
 unless ($html) {
@@ -251,3 +260,11 @@
 Bernhard Schmalhofer merged F back into F.
 
 =cut
+
+
+# Local Variables:
+#   mode: cperl
+#   cperl-indent-level: 4
+#   fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:

[perl #40590] [PATCH] Reduce verbosity in t/codingstd/tabs.t

[Paul Cochrane]

# New Ticket Created by  "Paul Cochrane" 
# Please include the string:  [perl #40590]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40590 >


Hi,

This patch reduces the amount of output generated by the
t/codingstd/tabs.t test, and makes the output like that of the other
coding standards tests.

Comments welcome!

Regards,

Paul


files affected:

t/codingstd/tabs.t
Index: t/codingstd/tabs.t
===
--- t/codingstd/tabs.t	(revision 15005)
+++ t/codingstd/tabs.t	(working copy)
@@ -35,15 +35,26 @@
 my @tabs;
 
 foreach my $file (@files) {
-open my $fh, '<', $file
-or die "Cannot open '$file' for reading: $!\n";
+my $path;
 
-my $tabcount;
+## get the full path of the file
+# if we have the files on the command line, the file is the full path
+if (@ARGV) {
+$path = $file;
+}
+
+# otherwise, use the Parrot::Doc::File::path method
+else {
+$path = $file->path;
+}
+
+open my $fh, '<', $path
+or die "Cannot open '$path' for reading: $!\n";
+
+# search each line for leading tabs
 while (<$fh>) {
-next unless /^ *\t/;
-push @tabs, "tab in leading whitespace, file '$file', line $.\n";
-if ( ++$tabcount >= 5 ) {
-push @tabs, "skipping remaining lines (you get the idea)\n";
+if ($_ =~ m/^ *\t/) {
+push @tabs => "$path\n";
 last;
 }
 }
@@ -51,12 +62,13 @@
 }
 
 ok( !scalar(@tabs), "tabs in leading whitespace" )
-or diag(@tabs);
+or diag("Found tab in leading whitespace in " . scalar(@tabs) 
+. " files.  Files affected:[EMAIL PROTECTED]");
 
 exit;
 
 sub source_files {
-return map { $_->path } (
+return (
 map( $_->files_of_type('C code'),   $DIST->c_source_file_directories ),
 map( $_->files_of_type('C header'), $DIST->c_header_file_directories ),
 map( $_->files_of_type('PMC code'), $DIST->pmc_source_file_directories ),

Re: Parrot::Coroutine

[Bob Rogers]

   From: François PERRAD <[EMAIL PROTECTED]>
   Date: Mon, 23 Oct 2006 18:51:03 +0200


   In languages/lua/lib/thread.pir, I create a Lua thread type by extension of 
   Parrot::Coroutine.
   So I add a lot of methods for Lua type, but I think that 2 of these methods 
   could be integrated in Parrot::Coroutine :
   - __clone
   - __get_pointer (equivalent of get_pointer() in src/pmc/sub.pmc)

   François.

The thread.pir methods you mention are stubs, so I'm not certain what
they should do.

   * Should __clone copy the whole object state, or just the initial
sub, effectively resetting the coroutine to the start?  Methinks the
latter, but I have little practical experience with coroutines.

   * What should __get_pointer return?  The address of the PMC?  If so,
would that be better to implement on default.pmc?

   In any case, I have had to limit my Parrot hacking lately to keep my
hands from hurting [1], so feel free to enhance Parrot::Coroutine as you
see fit.  AFAIK, you're the only one using it at this point, so you
shouldn't need to worry about breaking anything else.

-- Bob

[1]  FWIW, it's not a big deal, and I'm trying hard to keep it that way.

[perl #40592] [PATCH] Update of t/codingstd/linelength.t

[Paul Cochrane]

# New Ticket Created by  "Paul Cochrane" 
# Please include the string:  [perl #40592]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40592 >


Hi,

This patch: replaces the pattern match operators used so that vim can
syntax highlight the file properly; adds more languages to the
language list so that the script can find more files to check; and
fixes a minor typo in one comment.

Comments welcome,

Regards,

Paul


files affected:

t/codingstd/linelength.t
Index: t/codingstd/linelength.t
===
--- t/codingstd/linelength.t	(revision 15007)
+++ t/codingstd/linelength.t	(working copy)
@@ -21,20 +21,27 @@
 
 our $columns = 100;
 
-use lib qw! . lib ../lib ../../lib !;
+use lib qw( . lib ../lib ../../lib );
 
 use Test::More;
 use Parrot::Config;
-use ExtUtils::Manifest qw!maniread!;
+use ExtUtils::Manifest qw( maniread );
 
-use vars [EMAIL PROTECTED];
+use vars qw( @files );
 
 diag "finding source files, this may take a while.";
 
 our %check_language = map { $_ => 1; } qw{
+APL
+WMLScript
+amber
+cardinal
+dotnet
 lua
+perl6
+pugs
+python
 tcl
-WMLScript
 };
 
 # XXX this should really be using src_dir instead of build_dir but it
@@ -45,8 +52,8 @@
 
 # Read some extra exceptions
 while () {
-next if m!^#!;
-next if m!^\s*$!;
+next if m{^#};
+next if m{^\s*$};
 chomp;
 $manifest_gen->{$_}++;
 }
@@ -62,15 +69,15 @@
 next if exists( $manifest_gen->{$file} );
 
 # I could make this other way, but this way is more flexible
-next if ( $ffile =~ m!^$build_dir/languages/([^/]+)/!
+next if ( $ffile =~ m{^$build_dir/languages/([^/]+)/}
 && !$check_language{$1} );
 
-push @files, $ffile if $file =~ m!\.c$!;
-push @files, $ffile if $file =~ m!\.pmc$!;
-push @files, $ffile if $file =~ m!\.ops$!;
-push @files, $ffile if $file =~ m!\.pod$!;
+push @files, $ffile if $file =~ m{\.c$};
+push @files, $ffile if $file =~ m{\.pmc$};
+push @files, $ffile if $file =~ m{\.ops$};
+push @files, $ffile if $file =~ m{\.pod$};
 
-# push @files, $ffile if $file =~ m!\.pl$!;
+# push @files, $ffile if $file =~ m{\.pl$};
 }
 
 plan tests => scalar @files;
@@ -81,7 +88,7 @@
 my $l;# will hold the first line to be corrected
 
 my $g = $f;# will hold the file to be corrected with relative path;
-$g =~ s!^$build_dir/!!;
+$g =~ s{^$build_dir/}{};
 
 my $ok = 1;
 
@@ -122,7 +129,7 @@
 tools/build/nativecall.pl
 tools/dev/lib_deps.pl
 tools/dev/parrot_coverage.pl
-# these ones includes a big URL
+# these ones include a big URL
 cage/todo.pod
 docs/gettingstarted.pod
 docs/glossary.pod

Re: signature subtyping and role merging

[TSa]

HaloO,

Jonathan Lang wrote:

If you're not using "multi", then the signature is superfluous for
type-checking purposes.


I think that signatures do matter for type-checking! It is
an error to provide too few or to many positional args or
args with an incompatible type.


Regards, TSa.
--

Re: signature subtyping and role merging

[TSa]

HaloO,

TSa wrote:

When names have to be available as well, then we get an undefined
method that has to have two positionals and two named parameters such
that all four names appear to satisfy all conceivable call sites for
the two roles.


To get four names for two positional Parameters an 'is alias' parameter
trait is needed that can be given several times to produce an alias
that can be used as key in the named argument binding. Such a trait is
also very useful for backwards compatibility when parameter names are
changed. The signature merger would set alias traits as needed.

I don't know how the routine that is put behind the signature determines
in which context it was called to correctly swap the arguments for the
backend doit routine. Ideas?


Regards, TSa.
--

[perl #40593] [CAGE] make t/codingstd/linelength.t output look like other coding standard tests

[via RT]

# New Ticket Created by  Jerry Gay 
# Please include the string:  [perl #40593]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40593 >


this test differs from other coding standard test in output format:
~ should display filenames for failing files
~ should execute as one test, not many
there may be other differences that a more proper code review will
uncover. this is your ticket to provide that code review :)

~jerry

Re: [perl #40593] [CAGE] make t/codingstd/linelength.t output look like other coding standard tests

[Will Coleda]

Not all tests follow the "one test reporting on many files" paradigm:  
see t/codingstd/perlcritic.t


FWIW,in general, I prefer the perlcritic method.

On Oct 24, 2006, at 5:32 PM, Jerry Gay (via RT) wrote:


# New Ticket Created by  Jerry Gay
# Please include the string:  [perl #40593]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40593 >


this test differs from other coding standard test in output format:
~ should display filenames for failing files
~ should execute as one test, not many
there may be other differences that a more proper code review will
uncover. this is your ticket to provide that code review :)

~jerry



--
Will "Coke" Coleda
[EMAIL PROTECTED]

Re: [HOWTO] add a C file to get archived in libparrot.a

[Karl Forner]

On 10/23/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:


Karl Forner wrote:
> I've added one C src file, say src/foo.c, and include/parrot/foo.h, and
a
> test in t/src/foo.t.
> I've changed the MANIFEST file accordingly, but I can not manage to
> have my
> foo.o file to be added in libparrot.a (after a make clean;perl
> Configure.pl
> ;make)
>
> What did I miss ?
Not sure if you've solved this yet, but just a guess: did you try a
"make realclean"?



Yes, but that does not change anything. My file does not appear in the
Makefile (except for foo.h).
I have absolutely no clue of the process used to generate the list of C
files to be linked into the parrot interpreter.

Re: signature subtyping and role merging

[Jonathan Lang]

TSa wrote:

Jonathan Lang wrote:
> If you're not using "multi", then the signature is superfluous for
> type-checking purposes.

I think that signatures do matter for type-checking! It is
an error to provide too few or to many positional args or
args with an incompatible type.


Mea culpa.  I thought you were still talking about using an object's
methods as part of the process of deciding whether or not that object
satisfies the role requirements of some other routine's signature.  Of
course signatures matter when it comes to deciding which arguments
that method will accept.

--
Jonathan "Dataweaver" Lang

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

[Paul Cochrane]

Amos and Chris,

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

Further to my question:

so do C and C 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.

Regards,

Paul
Index: MANIFEST
===
--- MANIFEST	(revision 14998)
+++ MANIFEST	(working copy)
@@ -2450,6 +2450,7 @@
 t/codingstd/cppcomments.t   []
 t/codingstd/cuddled_else.t  []
 t/codingstd/fixme.t []
+t/codingstd/line_endings.t  []
 t/codingstd/linelength.t[]
 t/codingstd/perlcritic.t[]
 t/codingstd/tabs.t  []
Index: t/codingstd/line_endings.t
===
--- t/codingstd/line_endings.t	(revision 0)
+++ t/codingstd/line_endings.t	(revision 0)
@@ -0,0 +1,102 @@
+#! perl
+# Copyright (C) 2006, The Perl Foundation.
+# $Id$
+
+use strict;
+use warnings;
+
+use lib qw( . lib ../lib ../../lib );
+use Test::More;
+use ExtUtils::Manifest qw(maniread);
+
+# skip the tests if SVN::Client isn't installed
+BEGIN {
+eval { require SVN::Client; };
+if ($@) {
+plan skip_all => 'SVN::Client not installed';
+}
+}
+
+# set up how many tests to run
+plan tests => 1;
+
+=head1 NAME
+
+t/codingstd/line_endings.t - checks for DOS line endings in text files
+
+=head1 SYNOPSIS
+
+# test all files
+% prove t/codingstd/line_endings.t
+
+# test specific files
+% perl t/codingstd/line_endings.t src/foo.c include/parrot/bar.h
+
+=head1 DESCRIPTION
+
+Checks that text files do not have DOS (CRLF) line endings.  Instead, they
+should have Unix (CR) line endings.
+
+=head1 SEE ALSO
+
+L
+
+=cut
+
+my @files = @ARGV ? @ARGV : source_files();
+my @dos_files;
+
+foreach my $file (@files) {
+my $buf;
+
+# slurp in the file
+open( my $fh, '<', $file )
+or die "Cannot open '$file' for reading: $!\n";
+{
+local $/;
+$buf = <$fh>;
+}
+
+# append to the dos_files array if the code matches
+push @dos_files => "$file\n"
+if $buf =~ m{\r$}m;
+}
+
+ok( !scalar(@dos_files), 'Line endings correct' )
+or diag( "DOS line ending found in " . scalar @dos_files . " files:[EMAIL PROTECTED]" );
+
+sub source_files
+{
+my $client = SVN::Client->new();
+my $manifest = maniread('MANIFEST');
+my @test_files;
+# grab names of files to test (except binary files)
+foreach my $filename ( sort keys %$manifest ) {
+# try to read the svn:mime-type property of the file
+my $prop_ref = $client->propget("svn:mime-type", $filename, "WORKING", 0);
+
+# if we have no mime-type property set or the mime-type is text/*
+# then the file is text (this is the assumption used by subversion)
+my $prop = $prop_ref->{$filename};
+# of the mime-type property is undefined, append to the file list
+if (!defined $prop) {
+push @test_files, $filename;
+}
+else {
+# if we know we have a text file, append it
+push @test_files, $filename
+if ($prop =~ m{text});
+}
+}
+
+return @test_files;
+}
+
+exit;
+
+# Local Variables:
+#   mode: cperl
+#   cperl-indent-level: 4
+#   fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:

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

[Bob Rogers]

   From: "Paul Cochrane" <[EMAIL PROTECTED]>
   Date: Tue, 24 Oct 2006 11:49:23 +0200

   Amos and Chris,

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

   Further to my question:

   so do C and C 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/

Re: OO Requirements [was Re: classnames and HLL namespaces -- help!]

[Allison Randal]

chromatic wrote:

On Monday 23 October 2006 09:49, Jonathan Worthington wrote:


Would it be a good idea to start collecting requirements together from
different language implementors so that when the time comes to work on
the OO PDD, there is already a good description of what it needs to do?


Please do.  The docs/pdds/clip/ directory exists for this.


More specifically: If you have any questions related to a PDD in clip, 
please add them to a QUESTIONS section at the end of the PDD. For 
requirements, use REQUIREMENTS. Neither of these sections will live in 
the final version of the PDD, so it's a flag for me to process the 
discussion. (And it's enormously easier to roll the discussion into the 
PDD when it's collected together like that than scattered across several 
months of email. Especially considering how terrible Thunderbird's 
full-text searching is.)


Allison

Re: classnames and HLL namespaces

[Allison Randal]

To wrap up (or restart) the thread, here are some thoughts from a 
high-level view:


HLL classnames should live in the symbol table (i.e. namespace), not in 
Parrot's internal class registry. Yes, this means PIR/POST will need 
different syntax for instantiating objects from HLL classes. But the 
syntax to create lexical and global variables is different than the 
syntax to create Parrot's internal named temporary variables. They're 
fundamentally different things, so different syntax is sensible.


The syntax for instantiating an object from an HLL class (that only 
lives in a namespace) should be quick and easy.


All of Parrot's internal classes will be accessible via the 'parrot' HLL 
namespace (though at times only virtually), so we don't necessarily have 
to have syntax that deals directly with the registry. But there's enough 
code that instantiates from type numbers to make it worth keeping that 
as an option.


--

Okay, so that's what I want. Discussion: What does it break and are the 
trade-offs worth it? How deeply ingrained is the Parrot class registry? 
('interpreter->class_hash' is pretty thoroughly sprinkled through the 
code when looking up types (curiously, the 'class_hash' is a 
'enum_type_NameSpace', but a different instance of it than 
'interpreter->root_namespace').)


How costly would it be to have lookups performed on the root_namespace 
instead of the class_hash? If it's too costly, name-mangling the HLL 
namespace name into the class_hash is a possibility, but an ugly one.


Allison

Re: Embedded perl5 modules

[Richard Hainsworth]

Tried
use perl5:Wx::SimpleApp;
but the compiler complained it could not find SimpleApp.pm

GUI packages, which are wrappers around C classes, seem to use all the 
techniques of perl5. I dont understand them to find out what is going 
on, or to isolate what the error so as to put it into a test.


In general, it seems to me that for there to be "full" use of perl5 
modules in perl6, the useage in perl6 should be the same as in perl5 
(bar the minor changes in syntax). Thus if

use Wx;
is sufficient in perl5 for Wx::SimpleApp to be a recognised namespace in 
the program and for the compiler to know where to go to get 
Wx::SimpleApp->new, then in perl6 the same should be true, viz.,

use perl5:Wx;
Wx::SimpleApp.new

Regards,

Richard

Steffen Schwigon wrote:

Richard Hainsworth <[EMAIL PROTECTED]> writes:
  

use perl5:Wx;
my $app = Wx::SimpleApp.new;
my $frame=Wx::Frame.new(undef, -1, 'Hello world!');
$frame.Show;
$app.MainLoop;

The following is the result:
$pugs wxtest.p6
*** No compatible subroutine found: "&Wx::SimpleApp"
   at wxtest.p6 line 2, column 1-28

Is the perl6 wrong?

I have also tested
use perl5:Wx ;



Maybe an additional

 use perl5:Wx::SimpleApp;

? I'm just guessing...

Steffen
  

Re: Embedded perl5 modules

[Steffen Schwigon]

Richard Hainsworth <[EMAIL PROTECTED]> writes:
> Tried
> use perl5:Wx::SimpleApp;
> but the compiler complained it could not find SimpleApp.pm

Did you see my other suggestion with an intermediate "WxHelper"
(http://www.nntp.perl.org/group/perl.perl6.users/546)?

It also doesn't really work but at least it gets you a step
further. Try it and maybe you have the next idea as you maybe 
know Wx better than I do. 

Steffen
-- 
Steffen Schwigon <[EMAIL PROTECTED]>
Dresden Perl Mongers 
Deutscher Perl-Workshop