Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h
On 09/11/2007, Joshua Isom <[EMAIL PROTECTED]> wrote: > Did you test the exec runcore? I don't think any of that code is used > outside of the exec runcore so you aren't actually testing that code. I'll have a go at testing against the exec runcore and see what turns up. This is likely something we should be testing more often right? Paul
[TODO] Why two configuration steps where one would suffice?
Currently, Parrot configuration step #32 is gen::cpu, while step #50 is auto:cpu. Let's do a diff between their respective packages (at r22775): [parrot] 504 $ diff -w config/gen/cpu.pm config/auto/cpu.pm > ~/learn/ parrot/diff.gen.auto.cpu.txt 1c1 < # Copyright (C) 2001-2006, The Perl Foundation. --- > # Copyright (C) 2001-2007, The Perl Foundation. 6c6 < config/gen/cpu.pm - CPU specific Files --- > config/auto/cpu.pm - CPU specific Files 10c10 < Runs C<&run_cpu()> in F if it exists. --- > Runs C<&run_cpu()> in F if it exists. 14c14 < package gen::cpu; --- > package auto::cpu; 18a19 > 21c22 < use Parrot::Configure::Step qw(copy_if_diff); --- > use Parrot::Configure::Step; 24d24 < 28c28 < $data{description} = q{Generating CPU specific stuff}; --- > $data{description} = q{Running CPU specific stuff}; 44c44,46 < my $hints = "gen::cpu::" . $conf->data->get('cpuarch') . "::auto"; --- > $conf->data->add( ' ', TEMP_atomic_o => '' );# assure a default > > my $hints = "auto::cpu::" . $conf->data->get('cpuarch') . "::auto"; Not very much, if you think about it. Both classes exist primarily to run a subroutine in an OS/platform-specific .pm hints file one level down in the hierarchy. config/gen/cpu.pm has hints files for i386 and x86_64. In neither case are any Makefiles, header files or any other kind of files generated, so the name 'gen::cpu' for this config step is a misnomer. config/auto/cpu.pm has hints files for i386, ppc, sun4 and x86_64. They run C probes of the platform much like any other 'auto' configuration step. I haven't yet run Parrot::Configure::Trace to see how the values in the Parrot::Configure object set by gen::cpu affect the steps between #32 and #50. Nor have I experimented yet with combining the two packages into one and running it at step #32. But does anyone know any reason why that kind of experimentation should be rejected *a priori*? Does anyone recall anything about these packages that in the past mandated that their functionality be split between the two widely separated configuration steps? Thank you very much. kid51
Getting Feedback from Smoke Testers
One of the test files I wrote for configuration step class auto::alignptrs, t/configure/124-auto_alignptrs-05.t, has been getting failure reports on one particular test -- but not on all platforms, and not on a platform I have access to. I would like to follow up with the folks running these smoke services, but the smoke report pages do not provide email addresses for the testers. Can anyone tell me how I would follow up with these two smokers -- or with our smokers more generally? 1. TAP Matrix - Fri Nov 9 13:09:31 2007 GMT duration: 1361 branch: unknown harness_args: -D40 --gc-debug DEVEL: -devel VERSION: 0.4.17 archname: x86_64-linux-gnu-thread-multi build_dir: /home/rick/build/parrot cc: cc cpuarch: amd64 optimize: osname: linux revision: 22778 2. TAP Matrix - Fri Nov 9 12:03:20 2007 GMT duration: 836 branch: unknown harness_args: -D40 --gc-debug DEVEL: -devel VERSION: 0.4.17 archname: i386-linux-thread-multi build_dir: /home/jurosz/PaP6-testing/parrot-temp cc: gcc cpuarch: i386 optimize: osname: linux revision: 22778 Thank you very much. kid51
[perl #47313] [BUG] config/auto/va_ptr.pm delivering surprising result
# New Ticket Created by James Keenan # Please include the string: [perl #47313] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=47313 > The description for Parrot configuration step class auto::va_ptr states that its purpose is: "Tests which kind of PARROT_VA_TO_VAPTR to use." Assuming that the test does not die, there are only two possible results: 'ppc' and 'x86'. Whichever result is achieved is assigned both to the step's result and to Parrot::Configure object key 'va_ptr_type'. When I run this on Linux, I get 'x86', as I would expect. But when I configure on my iBook, I *also* get 'x86': Test the type of va_ptr (this test is likely to segfault)..x86. But I'm clearly running on the powerpc version of Darwin: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=darwin, osvers=8.7.0, archname=darwin-2level uname='darwin macintosh.local 8.7.0 darwin kernel version 8.7.0: fri may 26 15:20:53 pdt 2006; root:xnu-792.6.76.obj~1release_ppc power macintosh powerpc ' Even though I have no idea what a va_ptr is, I would still expect the result of this step on my iBook to be 'ppc'. Why isn't it? Thank you very much. kid51
[perl #43348] [TODO] config/auto/cgoto.pm: Write unit tests
Patches applied to trunk in r22786. Resolving ticket.
[perl #43332] [TODO] config/auto/env.pm: Write unit tests
Please review attached patch, which refactors Parrot configuration step auto::env slightly and provides 3 test files. Index: MANIFEST === --- MANIFEST(revision 22786) +++ MANIFEST(working copy) @@ -1,7 +1,7 @@ # ex: set ro: # $Id$ # -# generated by tools/dev/mk_manifest_and_skip.pl Sat Nov 10 01:52:43 2007 UT +# generated by tools/dev/mk_manifest_and_skip.pl Sat Nov 10 03:36:54 2007 UT # # See tools/dev/install_files.pl for documentation on the # format of this file. @@ -3096,7 +3096,9 @@ t/configure/139-auto_signal-01.t[] t/configure/140-auto_socklen_t-01.t [] t/configure/140-auto_socklen_t-02.t [] -t/configure/141-auto_env.t [] +t/configure/141-auto_env-01.t [] +t/configure/141-auto_env-02.t [] +t/configure/141-auto_env-03.t [] t/configure/142-auto_aio.t [] t/configure/143-auto_gmp.t [] t/configure/144-auto_readline.t [] Index: t/configure/141-auto_env-01.t === --- t/configure/141-auto_env-01.t (revision 0) +++ t/configure/141-auto_env-01.t (revision 0) @@ -0,0 +1,77 @@ +#! perl +# Copyright (C) 2007, The Perl Foundation. +# $Id$ +# 141-auto_env-01.t + +use strict; +use warnings; +use Test::More tests => 12; +use Carp; +use lib qw( lib t/configure/testlib ); +use_ok('config::init::defaults'); +use_ok('config::auto::env'); +use Parrot::Configure; +use Parrot::Configure::Options qw( process_options ); +use Parrot::Configure::Test qw( test_step_thru_runstep); + +my $args = process_options( { +argv=> [], +mode=> q{configure}, +} ); + +my $conf = Parrot::Configure->new(); + +test_step_thru_runstep($conf, q{init::defaults}, $args); + +my ($task, $step_name, @step_params, $step, $ret); +my $pkg = q{auto::env}; + +$conf->add_steps($pkg); +$conf->options->set(%{$args}); +$task = $conf->steps->[1]; +$step_name = $task->step; [EMAIL PROTECTED] = @{ $task->params }; + +$step = $step_name->new(); +ok(defined $step, "$step_name constructor returned defined value"); +isa_ok($step, $step_name); +ok($step->description(), "$step_name has description"); + +ok($step->runstep($conf), "runstep() returned true value"); + +pass("Keep Devel::Cover happy"); +pass("Completed all tests in $0"); + +### DOCUMENTATION ### + +=head1 NAME + +141-auto_env-01.t - test config::auto::env + +=head1 SYNOPSIS + +% prove t/configure/141-auto_env-01.t + +=head1 DESCRIPTION + +The files in this directory test functionality used by F. + +The tests in this file test subroutines found in config::auto::env in +its most ordinary usage. + +=head1 AUTHOR + +James E Keenan + +=head1 SEE ALSO + +config::auto::env, F. + +=cut + +# Local Variables: +# mode: cperl +# cperl-indent-level: 4 +# fill-column: 100 +# End: +# vim: expandtab shiftwidth=4: Property changes on: t/configure/141-auto_env-01.t ___ Name: svn:mime-type + text/plain Name: svn:keywords + Author Date Id Revision Name: svn:eol-style + native Index: t/configure/141-auto_env.t === --- t/configure/141-auto_env.t (revision 22786) +++ t/configure/141-auto_env.t (working copy) @@ -1,54 +0,0 @@ -#! perl -# Copyright (C) 2007, The Perl Foundation. -# $Id$ -# 141-auto_env.t - -use strict; -use warnings; -use Test::More tests => 2; -use Carp; -use lib qw( lib ); -use_ok('config::auto::env'); - -=for hints_for_testing The documentation for this package is skimpy; -please try to improve it, e.g., by explaining what 'setenv' and -'unsetenv' are. Try to cover all branches and conditions. Check latest -reports of Parrot configuration tools testing coverage to see where your -time available for writing tests is spent. - -=cut - -pass("Completed all tests in $0"); - -### DOCUMENTATION ### - -=head1 NAME - -141-auto_env.t - test config::auto::env - -=head1 SYNOPSIS - -% prove t/configure/141-auto_env.t - -=head1 DESCRIPTION - -The files in this directory test functionality used by F. - -The tests in this file test subroutines exported by config::auto::env. - -=head1 AUTHOR - -James E Keenan - -=head1 SEE ALSO - -config::auto::env, F. - -=cut - -# Local Variables: -# mode: cperl -# cperl-indent-level: 4 -# fill-column: 100 -# End: -# vim: expandtab shiftwidth=4: Index: t/configure/141-auto_env-02.t === --- t/configure/141-auto_env-02.t (revision 0) +++ t/configure/141-auto_env-02.t (revision 0) @@ -0,0 +1,98 @@ +#! perl +# Copyright (C)
Re: [svn:parrot] r22780 - in trunk/src: . pmc
On Friday 09 November 2007 09:00:00 [EMAIL PROTECTED] wrote: > Author: paultcochrane > Date: Fri Nov 9 08:59:59 2007 > New Revision: 22780 > > Modified: >trunk/src/objects.c >trunk/src/pmc/namespace.pmc >trunk/src/pmc_freeze.c > > Log: > [core,pmc] Removed unreachable code compiler warnings > > Modified: trunk/src/objects.c > === >=== --- trunk/src/objects.c(original) > +++ trunk/src/objects.c Fri Nov 9 08:59:59 2007 > @@ -1918,10 +1918,8 @@ > > /* RT#45989 escape NUL char */ > if (VTABLE_exists_keyed_str(interp, attr_hash, full_attr_name)) { > -char * const c_error = string_to_cstring(interp, full_attr_name); > -real_exception(interp, NULL, 1, "Attribute '%s' already exists", > c_error); -/* RT#45991 leak! */ > -string_cstring_free(c_error); > +real_exception(interp, NULL, 1, "Attribute '%s' already exists", > +string_to_cstring(interp, full_attr_name)); > } I'm not a huge fan of this, especially when removing the RT #45591 link, but a better solution is to use the format %Ss, which tells Parrot's sprintf engine that it's getting a STRING. This avoids the memory leak of string_to_cstring(). -- c
Re: [perl #47313] [BUG] config/auto/va_ptr.pm delivering surprising result
On Nov 9, 2007, at 8:08 PM, James Keenan (via RT) wrote: # New Ticket Created by James Keenan # Please include the string: [perl #47313] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=47313 > The description for Parrot configuration step class auto::va_ptr states that its purpose is: "Tests which kind of PARROT_VA_TO_VAPTR to use." Assuming that the test does not die, there are only two possible results: 'ppc' and 'x86'. Whichever result is achieved is assigned both to the step's result and to Parrot::Configure object key 'va_ptr_type'. When I run this on Linux, I get 'x86', as I would expect. But when I configure on my iBook, I *also* get 'x86': Test the type of va_ptr (this test is likely to segfault)..x86. But I'm clearly running on the powerpc version of Darwin: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=darwin, osvers=8.7.0, archname=darwin-2level uname='darwin macintosh.local 8.7.0 darwin kernel version 8.7.0: fri may 26 15:20:53 pdt 2006; root:xnu-792.6.76.obj~1release_ppc power macintosh powerpc ' Even though I have no idea what a va_ptr is, I would still expect the result of this step on my iBook to be 'ppc'. Why isn't it? Thank you very much. kid51 It in no way refers to architecture actually. It refers to the calling convention on an architecture(dependent upon implementation). The x86 method is by pushing arguments onto the stack, and the ppc method is in registers. On amd64, parrot reports ppc, which is essentially correct. Calling it x86 and ppc is probably just because those are the two dominant architectures. They could be labeled differently.
Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h
On Nov 9, 2007, at 2:24 AM, Paul Cochrane wrote: On 09/11/2007, Joshua Isom <[EMAIL PROTECTED]> wrote: Did you test the exec runcore? I don't think any of that code is used outside of the exec runcore so you aren't actually testing that code. I'll have a go at testing against the exec runcore and see what turns up. This is likely something we should be testing more often right? Paul Most of the runcores are greatly undertested. The switched runcore for instance is small in executable size, and faster than the standard runcore(great for embedded systems on both parts), but there isn't even a smoke target for it. If you look at the smoke report page, how many smokes do you see using the jit runcore on any platform? Further still, how many language smokes using jit?