Re: [perl #44457] [TODO] make sure files match test files for DYNPMCs and DYNOPs etc
--- El vie 12-sep-08, Rafael Sanchez <[EMAIL PROTECTED]> escribió:
De:: Rafael Sanchez <[EMAIL PROTECTED]>
Asunto: Re: [perl #44457] [TODO] make sure files match test files for DYNPMCs
and DYNOPs etc
A: "Christoph Otto" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Fecha: viernes, 12 septiembre, 2008, 2:49 pm
--- El vie 12-sep-08, Christoph Otto <[EMAIL PROTECTED]> escribió:
De:: Christoph Otto <[EMAIL PROTECTED]>
Asunto: Re: [perl #44457] [TODO] make sure files match test files for DYNPMCs
and DYNOPs etc
A: [EMAIL PROTECTED], [EMAIL PROTECTED]
Fecha: viernes, 12 septiembre, 2008, 6:56 am
[EMAIL PROTECTED] via RT wrote:
>
> --- El mié 10-sep-08, Rafael Sanchez <[EMAIL PROTECTED]>
escribió:
> De:: Rafael Sanchez <[EMAIL PROTECTED]>
> Asunto: Re: [perl #44457] [TODO] make sure files match test files for
DYNPMCs and DYNOPs etc
> A: "Christoph Otto via RT"
<[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Fecha: miércoles, 10 septiembre, 2008, 6:26 pm
> On Mon Aug 06 06:08:54 2007, pcoch wrote:
>> In the file t/distro/test_file_coverage.t there is the todo item:
>>
>> # TODO: DYNPMC, DYNOPS, etc
>>
>> This is in the context of making sure that the files match the test
>> files. This needs to be implemented.
>
> Is this as simple as writing a test to make sure every src/dynpmc/*.pmc
> and src/dynoplibs/*.ops has a matching
> t/dynpmc/*.t and t/dynoplibs/*.t ? If so, this would be an ideal task
> for one of our recent volunteers, since the code would be pure Perl.
>
>> Also, the test will fail without an exception for
src/dynpmc/rotest.pmc.
>> I don't know if a test should be written for this PMC or not.
>
>> I'm working in the script.
>
>> Igor
>
> I have a working script(with testing variables only).
>
> I have to filter de input (there are other types of files), and improbe
the reporting part.
>
> I don't know if I forgeting something.
>
> Igor
>
> The script is:
>
> #!/usr/bin/perl -w
>
> # Copyright (C) 2007-2008, The Perl Foundation.
> # $Id: Match.pl 2008-09-10 igor $
>
> =head1 NAME
>
> Match.pl
>
> =head1 DESCRIPTION
>
> Reports if doesn't mach a pmc file with a test file, there is not test
file
>
> =cut
>
> sub find_files {
> my ($base_dir,$dirpmc,$dirtest) = @_;
> opendir(DIRPMC, $base_dir.$dirpmc);
> opendir(DIRTEST,$base_dir.$dirtest);
>
> my @filespmc = grep { $_ ne '.' and $_ ne '..' }
readdir DIRPMC;
> my @filest = grep { $_ ne '.' and $_ ne '..' }
readdir DIRTEST;
>
> my @pmc_values = @{strip_ext([EMAIL PROTECTED])};
> my @t_values = @{strip_ext([EMAIL PROTECTED])};
>
> my %hash_t = map { $_ => $_ } @t_values;
>
> for (0 .. $#pmc_values) {
> if ( exists $hash_t{ $pmc_values[$_] } ) {
> print "element exist
".$pmc_values[$_]."\n";
> } else {
> print "element do not exist
".$pmc_values[$_]."\n";
> }
> }
>
> }
>
> sub strip_ext {
> my @ref_t = @{$_[0]};
> my @arr_stripped = ();
> for (my $i=0;$i<$#ref_t+1; $i++) {
> if ($ref_t[$i] =~ m/(\w+)[.]\w+/) { #Obtain names of
files without extension
> $arr_stripped[$i] = $1;
> } else {
> print "error";
> }
> }
> return [EMAIL PROTECTED];
> }
>
> my $base_dir = "/home/raf/parrot/";
> my $dirpmc = "src/dynpmc/";
> my $dirtest = "t/dynpmc/";
>
> #find_files($base_dir,$dirpmc,$dirtest);
>
>Hi Igor,
>First, thank you for taking the time to write this script.
>Unfortunately, the test needs to be added to t/distro/test_file_coverage.t
in
>Parrot. This ensures that it is run every time Parrot's test suite is
run
>via
>make test. It should be fairly easy to copy and modify the existing code
in
>t/distro/test_file_coverage.t to make it match dynpmc and dynops source
code
>to test files, but I'll be glad to help if you run into any issues.
>While you're working on the test, you can run it directly as a Perl
script
>or
>with prove. Note that you have to run perl Configure.pl before this test
will
>work.
>To learn how to contribute, I highly recommend the documentation in
>docs/project, especially cage_cleaners_guide.pod and committer_guide.pod.
>When modifying existing tests, it's best to work against svn trunk and
>update
>often. This avoids conflicts and makes it easy to generate patches.
>Once you have t/distro/test_file_coverage.t updated and working, create a
diff:
>svn diff >dynpmc_dynops_test_coverage.patch
>and attach that to a reply to this thread. You should also generally run
make
>codingstd_tests before submitting a patch, but I'll remember if you
>don't. ;)
>Again, thank you for contributing. I hope at least some of this
information
>is new to you.
>Christoph
>Hi Christoph,
>Actually all information you gave me is new to me,
>here in Mexico programmers(in companiies I've worked),
>don't use any testing software, In my last job we couldn't
>install subversion in a linux server(don't ask me why
Re: [perl #59398] [PATCH] Moving methods from Str.pir toany-str.pir
On Mon, Sep 29, 2008 at 01:53:44AM +1000, Vasily Chekalkin wrote: > Patrick R. Michaud wrote: >> This section of code would be much simpler (and more efficient) >> by using the C and C instead of >> individually examining each character one-at-a-time. >> >>> +.sub 'chop' :method >>> +len = length tmps >>> +if len == 0 goto done >>> +dec len >>> +substr tmps,tmps, 0, len >>> ... >> >> PIR has a C opcode, perhaps we should use it? > > Definitely. But I just moved code around. Should I add TODO ticket for > cleaning up this code? Yes, please. And these are cleanups that someone should be able to do with only a modest knowledge of PIR (and perhaps a good chance to learn PIR :-). Pm
Re: [perl #59410] [PATCH] CONTROL_LOOP_NEXT support for pct. Rakudo won't build, though.
> Cardinal's works fine, but with this patch, rakudo hangs while building. > Specifically, on parrot -o perl6.pbc perl6.pir. Oddly, if I comment out the builtins (line 25): .include 'src/gen_builtins.pir' then perl6.pbc compiles just fine. It doesn't run, of course, because the builtins are missing, but it does get things past the compile stage. This makes me think it's definitely an imcc bug of some sort. I have trouble conceiving what in src/gen_builtins.pir could be causing imcc to (later) hang when compiling the actions. Pm
Re: [perl #59398] [PATCH] Moving methods from Str.pir toany-str.pir
Patrick R. Michaud wrote: ... This section of code would be much simpler (and more efficient) by using the C and C instead of individually examining each character one-at-a-time. +.sub 'chop' :method +len = length tmps +if len == 0 goto done +dec len +substr tmps,tmps, 0, len ... PIR has a C opcode, perhaps we should use it? Definitely. But I just moved code around. Should I add TODO ticket for cleaning up this code? -- Bacek
Re: Problem building parrot
On Sunday 28 September 2008 05:47:14 Nikolay Ananiev wrote: > I'm trying to build parrot r31477 with visual studio 2008 on vista home and > i get the following error > > src\pmc\exceptionhandler.c > .\src\pmc\exceptionhandler.pmc(34) : error C2275: > 'Parrot_ExceptionHandler_attri > butes' : illegal use of this type as an expression > d:\dev\projects_out\parrot\src\pmc\pmc_exceptionhandler.h(109) : > see dec > laration of 'Parrot_ExceptionHandler_attributes' MSVC error messages aren't very useful. The problem is that C90 forbids an expression before a variable declaration, which GCC helpfully warns about. Anyhow, I fixed this and some METHOD return problems in r31482 (the culprit was r31451). Thanks for reporting! -- c
Re: Split with negative limits, and other weirdnesses
On Sun, Sep 28, 2008 at 11:40 AM, Chris Davaz <[EMAIL PROTECTED]> wrote: > Ok, so 0 returns the empty list and -1 violates the signature? In PIR > can we have such signatures that put a constraint on the range of > values for a given parameter? Maybe this has already been proposed and rejected, but why not simply define the limit parameter such that split($pat, $src, $limit) is equivalent, result-wise, to split($pat, $src)[0 .. $limit - 1] ? Of course, the limit-parameter case might be able to avoid some work compared to the second, which might not always be able to do its job lazily, but the return value would be the same. Then you don't have to come up with separate edge case rules for two different constructs... the one follows logically from the other. $limit is 0? @foo[0..-1] is the empty list. Check. @foo[0..-2] is also the empty list. So negative parameters don't need to Fail.. -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Split with negative limits, and other weirdnesses
Ok, so 0 returns the empty list and -1 violates the signature? In PIR can we have such signatures that put a constraint on the range of values for a given parameter? On Sun, Sep 28, 2008 at 7:25 PM, Carl Mäsak <[EMAIL PROTECTED]> wrote: > Jason (>): >> It makes sense to me to go with option 1; you get what you ask for. It also >> makes sense to make to not use magical implied numbers, such as negatives, >> to accomplish things that either ranges or whatever star can accomplish. > > Aye, agreement. There's a whole lot of consensus already... reading > through the discussion once more, I don't find anyone saying anything > contradicting the above summary. > > Chris, I'm not in a position to provide a final word, but it seems > very possible already to use what has already been said here as a > basis for an implementation. > > // Carl >
Re: [perl #59394] [PATCH] Implementation of Pair.pairs.
On Sun, Sep 28, 2008 at 04:00:47AM +1000, Vasily Chekalkin wrote:
> Patrick R. Michaud via RT wrote:
>>> +$P0 = get_hll_namespace ['Perl6Pair']
>>> +'!EXPORT'('pairs', $P0)
>>
>> It's probably wrong to export 'pairs' here -- the exported pairs
>> function should be the one that is on 'Any'. Either that or it needs
>> to be a :multi so that we can distinguish between them.
>
> It's not clear for me, should it be part of Any. Probably it shouldn't
> be exported at all.
S29 shows List.pairs as being exported; presumably that's to be
able to support
my @x = pairs @list;
Pm
Re: [perl #59398] [PATCH] Moving methods from Str.pir to any-str.pir
On Sat, Sep 27, 2008 at 05:44:43AM -0700, Vasily Chekalkin wrote: > --- a/languages/perl6/src/builtins/any-str.pir > +++ b/languages/perl6/src/builtins/any-str.pir > + > +=item capitalize > + [...] > +=cut > + > +.local int pos, is_ws, is_lc > +pos = 0 > +goto first_char > + next_grapheme: > +if pos == len goto done > +is_ws = is_cclass .CCLASS_WHITESPACE, tmps, pos > +if is_ws goto ws > + advance: > +pos += 1 > +goto next_grapheme > + ws: > +pos += 1 > + first_char: > +is_lc = is_cclass .CCLASS_LOWERCASE, tmps, pos > +unless is_lc goto advance > ... This section of code would be much simpler (and more efficient) by using the C and C instead of individually examining each character one-at-a-time. > +.sub 'chop' :method > +len = length tmps > +if len == 0 goto done > +dec len > +substr tmps,tmps, 0, len > ... PIR has a C opcode, perhaps we should use it? Pm
Problem building parrot
I'm trying to build parrot r31477 with visual studio 2008 on vista home and
i get the following error
src\pmc\exceptionhandler.c
.\src\pmc\exceptionhandler.pmc(34) : error C2275:
'Parrot_ExceptionHandler_attri
butes' : illegal use of this type as an expression
d:\dev\projects_out\parrot\src\pmc\pmc_exceptionhandler.h(109) : see
dec
laration of 'Parrot_ExceptionHandler_attributes'
.\src\pmc\exceptionhandler.pmc(34) : error C2059: syntax error : 'const'
.\src\pmc\exceptionhandler.pmc(40) : error C2065: 'core_struct' : undeclared
ide
ntifier
.\src\pmc\exceptionhandler.pmc(40) : warning C4047: '=' : 'DPOINTER *'
differs i
n levels of indirection from 'int'
.\src\pmc\exceptionhandler.pmc(41) : error C2065: 'core_struct' : undeclared
ide
ntifier
.\src\pmc\exceptionhandler.pmc(41) : error C2223: left of '->min_severity'
must
point to struct/union
.\src\pmc\exceptionhandler.pmc(42) : error C2065: 'core_struct' : undeclared
ide
ntifier
.\src\pmc\exceptionhandler.pmc(42) : error C2223: left of '->max_severity'
must
point to struct/union
.\src\pmc\exceptionhandler.pmc(43) : error C2065: 'core_struct' : undeclared
ide
ntifier
.\src\pmc\exceptionhandler.pmc(43) : error C2223: left of '->handled_types'
must
point to struct/union
.\src\pmc\exceptionhandler.c(106) : error C2143: syntax error : missing '{'
befo
re '*'
.\src\pmc\exceptionhandler.c(108) : warning C4431: missing type specifier -
int
assumed. Note: C no longer supports default-int
.\src\pmc\exceptionhandler.c(108) : warning C4142: benign redefinition of
type
.\src\pmc\exceptionhandler.pmc(147) : warning C4057: 'return' : 'int *'
differs
in indirection to slightly different base types from 'opcode_t *'
.\src\pmc\exceptionhandler.pmc(232) : warning C4098:
'Parrot_ExceptionHandler_nc
i_min_severity' : 'void' function returning a value
.\src\pmc\exceptionhandler.pmc(251) : warning C4098:
'Parrot_ExceptionHandler_nc
i_max_severity' : 'void' function returning a value
.\src\pmc\exceptionhandler.c(1215) : warning C4057: 'initializing' :
'invoke_met
hod_t' differs in indirection to slightly different base types from 'int
*(__cde
cl *)(Parrot_Interp,PMC *,void *)'
.\src\pmc\exceptionhandler.c(1376) : warning C4057: 'initializing' :
'invoke_met
hod_t' differs in indirection to slightly different base types from 'int
*(__cde
cl *)(Parrot_Interp,PMC *,void *)'
NMAKE : fatal error U1077: 'D:\dev\vms\perl5.10\bin\perl.exe' : return code
'0x2
'
Stop.
Re: Split with negative limits, and other weirdnesses
Jason (>): > It makes sense to me to go with option 1; you get what you ask for. It also > makes sense to make to not use magical implied numbers, such as negatives, > to accomplish things that either ranges or whatever star can accomplish. Aye, agreement. There's a whole lot of consensus already... reading through the discussion once more, I don't find anyone saying anything contradicting the above summary. Chris, I'm not in a position to provide a final word, but it seems very possible already to use what has already been said here as a basis for an implementation. // Carl
