Re: Thank you so much Josh Hoblitt for the backtracing

[Jeff Horwitz]

very nice -- i could have used that THIS AFTEROON!  :)

On Thu, 26 Jul 2007, Andy Lester wrote:

Josh putting in the new backtrace behind my new assertions makes debugging 
assertions SO MUCH EASIER.


I'm gonna go s/assert/PARROT_ASSERT/ everywhere.

xoxo,
Andy

P.S. sample

# Received:
# 1..1
# Backtrace - Obtained 16 stack frames (max trace depth is 32).
#   (unknown)
# Parrot_confess
#   Parrot_make_COW_reference
# Parrot_String_get_string
#   Parrot_set_s_p
# (unknown)
#   (unknown)
# (unknown)
#   (unknown)
# Parrot_runops_fromc_args
#   Parrot_runcode
# (unknown)
#   imcc_run
# (unknown)
#   __libc_start_main
# (unknown)
# src/string.c:129: failed assertion 's'
#
# Expected:
# 1..1
# ok 1
#
# Looks like you failed 6 tests of 12.
t/pmc/exporterdubious
   Test returned status 6 (wstat 1536, 0x600)

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

[perl #44187] [RFC] Configure.pl: --configure_trace option too verbose

[James Keenan via RT]

On Thu Jul 26 19:22:57 2007, particle wrote:
> while typing
>   perl Configure.pl --nomanicheck ---verbose-step=init::gcc
> --configure_trace
> 
> earlier today in order to debug a configure-related problem i was
> having, i felt --configure_trace was too much to type.
> 
> i'd like to see --trace instead, if it makes sense and doesn't overlap
> with an existing option. 

I considered that when developing Parrot::Configure::Trace.  But I felt
that if someone dreamed up other options in the future which did (in
some sense) tracing, it would be better to have a more specifically
self-documenting option name.

In a situation like this, we have to strike a balance between
identifiers which are:

(a) self-documenting but possibly verbose;
(b) succinct but opaque.

(a) maximizes the utility of all those studying/working on Parrot who
are encountering the identifier for the first time.

(b) maximizes the utility of the relative handful of Parrot hackers who
are actually using the identifier in their daily work.

My own inclination is that when I'm repeatedly using a command with
multiple/lengthy-to-spell options, I put all of that into a shell alias
or into a symlink.

But I wouldn't rule out a change to this option name in the context of
other improvements to the module.

kid51

Re: [perl #44181] for (1,2,3) does not work

[Patrick R. Michaud]

On Thu, Jul 26, 2007 at 05:51:23PM -0700, Colin Kuskie wrote:
> for (0,1,2) { say $_; }
> 
> that construct dies with:
> 
> Null PMC access in get_bool()

Now fixed in 20269.

> I checked in an updated 01-sanity/07-for.t into the pugs repository,
> so if t/fetchspec is run you would be setup to run and debug.

Excellent, thanks!

Pm

[perl #44207] t/tools/pmc2cutils/06-print_tree.t: Test failures related to deep recursion

[via RT]

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


---
osname= linux
osvers= 2.6.18.3
arch=   i486-linux-gnu-thread-multi
cc= cc
---
Flags:
category=core
severity=high
ack=no
---
A new test failure has emerged in t/tools/pmc2cutils/.  The following is
the output of 'prove -v t/tools/pmc2cutils/06-print_tree.t'.  I should
note that my system hung bigtime before failing test 12 -- the first
time I've ever observed that in these tests.


t/tools/pmc2cutils/06-print_tree
OK:  Parrot top directory located
1..55
ok 1 - use Parrot::Pmc2c::Pmc2cMain;
ok 2 - use Cwd;
ok 3 - use File::Temp;
ok 4 - changed to temp directory for testing
ok 5 - created src/ under tempdir
ok 6 - created src/pmc/ under tempdir
ok 7 - all src/pmc/*.pmc files copied to tempdir
ok 8 - The object isa Parrot::Pmc2c::Pmc2cMain
ok 9 - dump_vtable created vtable.dump
ok 10 - dump_pmc succeeded
ok 11 - default.dump created as expected
Deep recursion on subroutine "Parrot::Pmc2c::Pmc2cMain::print_tree" at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212.
 at /home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 27
Parrot::Pmc2c::Pmc2cMain::__ANON__('Deep recursion on subroutine 
"Parrot::Pmc2c::Pmc2cMain::print...') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xbcbcf7c)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xbc313d4)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xbba3560)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xbb15764)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xba88980)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb9f8780)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb96a540)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb8dfeb8)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb8530ac)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb7c4118)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb73524c)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb6a6e8c)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb618b04)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb58ce54)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb5000f0)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb472274)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb3e3320)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb353db0)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Parrot::Pmc2c::Pmc2cMain=HASH(0x8322508)',
 'HASH(0xb2c5950)') called at 
/home/jimk/work/parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm line 212

Parrot::Pmc2c::Pmc2cMain::print_tree('Pa

One Data Point on the Static Analysis Tests

[chromatic]

Let me preface this by saying that I know that our static analysis tests 
represent a tremendous amount of work by several people (especially Paul, 
with an enormous amount of respect to everyone who's contributed also to 
Perl::Critic and PPI), and that they have helped us reach and do help us 
maintain an important level of quality in our code.  Maintainability my the 
second most important goal for our code after correctness.

With that in mind, I wonder if it's time to reconsider our strategy for using 
these tests effectively.

I ran make test.  It took almost six minutes:

Files=307, Tests=7413, 345 wallclock secs (187.91 cusr + 34.26 csys = 222.17 
CPU

I renamed DEVELOPING to DEV and ran make test again.  It took under four 
minutes:
Files=296, Tests=7392, 220 wallclock secs (121.98 cusr + 26.64 csys = 148.62 
CPU)

The first run failed several coding standards tests, which suggests to me that 
people don't run them before every commit.  We can't prevent accidental 
forgetting, but I wonder if making the coding standards tests faster would 
make them less painful and make it more likely that people would run them 
more often.

Most of our commits touch fewer than a dozen files.  Are we getting enough 
benefit from performing static (non-functional) analysis of all several 
thousand files in our tree for every make test run that it's worth adding 
another 50% to our test run times?  (Not all assertions are equal in value, 
but cutting out 21 from 7400 drops the amount of time in a test run by a 
third.)

Again, our code has improved in no small part due to the tests and the 
diligence of all committers in running them and correcting minor accidents as 
they occur.  I only mention this to bring up the possibility of brainstorming 
alternate ways to use the tests to their full advantage.  If we're using them 
to their full potential now, that's fine.

-- c