Re: [svn:parrot] r23307 - trunk/examples/sdl
On 01/12/2007, Will Coleda [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Author: paultcochrane Date: Sat Dec 1 06:08:08 2007 New Revision: 23307 Modified: trunk/examples/sdl/blue_rect.pl Log: [examples] - corrected editor coda - added no critic flags to switch off Perl::Critic warnings for the use strict and use warnings pragmas as they aren't part of NQP Modified: trunk/examples/sdl/blue_rect.pl NQP and Perl6 aren't Perl5; Should we really be running the perl5 coding standard tests against them? Probably not, but having the correct coda is a good thing, and I only needed to switch off the warnings about a lack of Cuse strict/warnings. At present, this isn't a maintanence burden, but as soon as we get lots of nqp/perl6 files we will need to rethink how we handle them. I don't think it's worth worrying about just yet. Paul
Re: [perl #48010] [RFC] [DEPRECATED] print_newline opcode
Will Coleda (via RT) wrote: print_newline I vote we kill it. +1 Allison
Re: [svn:parrot] r23307 - trunk/examples/sdl
On Sun, Dec 02, 2007 at 10:44:08AM +0100, Paul Cochrane wrote: NQP and Perl6 aren't Perl5; Should we really be running the perl5 coding standard tests against them? Probably not, but having the correct coda is a good thing, ... Agreed. ... and I only needed to switch off the warnings about a lack of Cuse strict/warnings. At present, this isn't a maintanence burden, but as soon as we get lots of nqp/perl6 files we will need to rethink how we handle them. I don't think it's worth worrying about just yet. I disagree. I think we'll quickly be accumulating a lot of Perl 6/NQP files, and putting the nocritic lines in all of them is a bit of a pain, as well as adjusting them all later. If it helps, we can start marking all such files with 'use v6;', and then the critic (or its driver) can use that to decide if the file should be checked. Or, if that's not good enough, then I'd at least want to put the nocritic lines with the coda instead of at the head of the file (if that's even possible). Pm
[perl #44171] [TODO] config/auto/attributes.pm: Write unit tests
I had some off-list conversations with ptc about a month ago about these issues. Running the step with --verbose-step indicated that attributes that the compiler does not recognize do not get added to the 'ccflags' attribute. Cf. patch applied to trunk: http://perlcabal.org/svn/parrot/revision/?rev=23364.
[svn:parrot-pdd] r23382 - in trunk: compilers/pct/src/PAST docs/pdds
Author: pmichaud Date: Sun Dec 2 14:51:22 2007 New Revision: 23382 Modified: trunk/docs/pdds/pdd26_ast.pod Changes in other areas also in this revision: Modified: trunk/compilers/pct/src/PAST/Compiler.pir Log: [pct]: * Add 'copy' pasttype. * Update pdd26, since we've changed the assign pasttype to be 'copy'. Modified: trunk/docs/pdds/pdd26_ast.pod == --- trunk/docs/pdds/pdd26_ast.pod (original) +++ trunk/docs/pdds/pdd26_ast.pod Sun Dec 2 14:51:22 2007 @@ -251,7 +251,7 @@ =over 4 -=item assign +=item copy Copy the value of the node's second child into the variable expression given by its first child. @@ -381,7 +381,7 @@ opcode, any destination is typically generated automatically and should not be explicitly given as a child operand to the node. The table of PIR opcodes that PAST knows about is given in -Fcompilers/pct/src/POST/Node.pir . +Fcompilers/pct/src/PAST/Compiler.pir . =item lvalue([flag])
[perl #47313] [BUG] config/auto/va_ptr.pm delivering surprising result
Patch was committed to trunk 01 Dec in r23331.
[perl #48070] [TODO] Replace Parrot::IO::Capture::Mini with IO::CaptureOutput
# New Ticket Created by James Keenan # Please include the string: [perl #48070] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48070 Several months ago I adapted CPAN module IO::Capture for use inside Parrot by creating Parrot::IO::Capture::Mini. Its main use is to capture verbose output during testing so as to reduce terminal clutter and to see if correct output is generated. I've run into a number of difficulties with P::IO::C::Mini and tonight began to explore the possibility of replacing it with CPAN module IO::CaptureOutput, maintainership of which has recently been assumed by David Golden. I have created a 'capture' branch in the Parrot repository to make and test this replacement in each of 80+ test files that currently use Mini. If CaptureOutput proves superior to Mini, I will advocate that it be used in trunk. If anyone wishes to help me out with this search-and-replace work, please check out the 'capture' branch and let me know. Thank you very much. kid51
[PATCH] fix for pcre test if libpcre installed in non-standard location
The attached patch will address a parrot test failure in the PCRE module (t/library/pcre.t) in the case where the libpcre library is installed in a nonstandard location. In my case, it occurs on OS X that Fink installed libpcre into /sw/lib, and so the test believes that PCRE is installed because the pcre-config utility returned zero, but it cannot find the library. The change runs pcre-config to get the location of the library, and then updates the PARROT_LIB_PATH_DYNEXT to contain the additional entry. -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller pcre.t.patch Description: Binary data
Re: [PATCH] fix for pcre test if libpcre installed in non-standard location
On Sunday 02 December 2007 21:04:28 Devin Heitmueller wrote: The attached patch will address a parrot test failure in the PCRE module (t/library/pcre.t) in the case where the libpcre library is installed in a nonstandard location. In my case, it occurs on OS X that Fink installed libpcre into /sw/lib, and so the test believes that PCRE is installed because the pcre-config utility returned zero, but it cannot find the library. The change runs pcre-config to get the location of the library, and then updates the PARROT_LIB_PATH_DYNEXT to contain the additional entry. Everything looks reasonable except the double-escaped newline; is this an artifact of the patch? -- c
Re: [PATCH] fix for pcre test if libpcre installed in non-standard location
In order to insert the $pcre_libpath into the content of the PIR, I had to change the interpolation mode in pir_output_is(). This therefore required me to escape the backslashes in the heredoc. If there's a more preferred approach to this sort of problem, let me know and I will happy resubmit the patch with said approach. Devin On Dec 3, 2007 12:17 AM, chromatic [EMAIL PROTECTED] wrote: On Sunday 02 December 2007 21:04:28 Devin Heitmueller wrote: The attached patch will address a parrot test failure in the PCRE module (t/library/pcre.t) in the case where the libpcre library is installed in a nonstandard location. In my case, it occurs on OS X that Fink installed libpcre into /sw/lib, and so the test believes that PCRE is installed because the pcre-config utility returned zero, but it cannot find the library. The change runs pcre-config to get the location of the library, and then updates the PARROT_LIB_PATH_DYNEXT to contain the additional entry. Everything looks reasonable except the double-escaped newline; is this an artifact of the patch? -- c -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller
Re: [PATCH] fix for pcre test if libpcre installed in non-standard location
On Sunday 02 December 2007 21:21:49 Devin Heitmueller wrote: In order to insert the $pcre_libpath into the content of the PIR, I had to change the interpolation mode in pir_output_is(). This therefore required me to escape the backslashes in the heredoc. Oh. I missed that, but it makes sense. If there's a more preferred approach to this sort of problem, let me know and I will happy resubmit the patch with said approach. If it were me, I'd switch those lines from Cprint to Csay and avoid the question altogether. -- c
