Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

B::Deparse::maybe_qualify(): uninitialized value warning #12152

Closed
p5pRT opened this issue Jun 1, 2012 · 16 comments
Closed

B::Deparse::maybe_qualify(): uninitialized value warning #12152

p5pRT opened this issue Jun 1, 2012 · 16 comments

Comments

@p5pRT
Copy link

p5pRT commented Jun 1, 2012

Migrated from rt.perl.org#113464 (status was 'resolved')

Searchable as RT113464$

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2012

From @jkeenan

Created by @jkeenan

From time-to-time I run coverage analysis on the Parrot virtual
machine's configuration and build tools. Today I ran that
program for the first time after upgrading to Perl 5.16.0 and
v0.87 of Devel​::Cover. Monitoring the output, I saw this, which
I had not previously observed​:

t/configure/033-step.t ...................... 1/34 Use of uninitialized
value $prefix in string eq at /usr/local/lib/perl5/5.16.0/B/Deparse.pm
line 1335.
Use of uninitialized value $prefix in concatenation (.) or string at
/usr/local/lib/perl5/5.16.0/B/Deparse.pm line 1335.
Use of uninitialized value $prefix in string eq at
/usr/local/lib/perl5/5.16.0/B/Deparse.pm line 1335.
Use of uninitialized value $prefix in concatenation (.) or string at
/usr/local/lib/perl5/5.16.0/B/Deparse.pm line 1335.
Use of uninitialized value $prefix in string eq at
/usr/local/lib/perl5/5.16.0/B/Deparse.pm line 1335.
Use of uninitialized value $prefix in concatenation (.) or string at
/usr/local/lib/perl5/5.16.0/B/Deparse.pm line 1335.

Here is the relevant section of B​::Deparse​:

1333 sub maybe_qualify {
1334 my ($self,$prefix,$name) = @​_;
1335 my $v = ($prefix eq '$#' ? '@​' : $prefix) . $name;

If $prefix comes into the subroutine undefined, it will still be
undefined at line 1335, thereby generating the warning.
maybe_qualify() is invoked at two points within B​::Deparse​:

1292 sub stash_variable {
1293 my ($self, $prefix, $name, $cx) = @​_;
...
1314 return $prefix . $self->maybe_qualify($prefix, $name);
1315 }

and​:

1319 sub stash_variable_name {
1320 my($self, $prefix, $gv) = @​_;
1321 my $name = $self->gv_name($gv, 1);
1322 $name = $self->maybe_qualify($prefix,$name);
...
1331 }

Either stash_variable() or stash_variable_name() is invoked
approximately nine times within B​::Deparse. While I can't be
certain which usage Devel​::Cover is picking up on, I lean toward
this instance of stash_variable_name() where we are deliberately
passing an undefined value to that method​:

2499 sub rv2gv_or_string {
2500 my($self,$op) = @​_;
2501 if ($op->name eq "gv") { # could be open("open") or open("###")
2502 my($name,$quoted) =
2503 $self->stash_variable_name(undef,$self->gv_or_padgv($op));

This suggests at least two possible approaches to a fix​:

(1) Change the first argument to stash_variable_name() at line
2503 to an empty string.

(2) After line 1320 in stash_variable_name(), say something
like​:

  $prefix //= '';

(Hey, that's the first time I've ever had the opportunity to use
'//='!)

How should we proceed?

Thank you very much.
Jim Keenan

Perl Info

Flags:
     category=library
     severity=low
     module=B::Deparse

Site configuration information for perl 5.16.0:

Configured by jimk at Sun May 20 20:01:26 EDT 2012.

Summary of my perl5 (revision 5 version 16 subversion 0) configuration:

   Platform:
     osname=darwin, osvers=8.11.0, archname=darwin-2level
     uname='darwin macintosh-8.local 8.11.0 darwin kernel version 
8.11.0: wed oct 10 18:26:00 pdt 2007; root:xnu-792.24.17~1release_ppc 
power macintosh powerpc '
     config_args='-des'
     hint=recommended, useposix=true, d_sigaction=define
     useithreads=undef, usemultiplicity=undef
     useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
     use64bitint=undef, use64bitall=undef, uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing 
-pipe -I/usr/local/include -I/opt/local/include',
     optimize='-O3',
     cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe 
-I/usr/local/include -I/opt/local/include'
     ccversion='', gccversion='4.0.1 (Apple Computer, Inc. build 5250)', 
gccosandvers=''
     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
     alignbytes=8, prototype=define
   Linker and Libraries:
     ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' 
-L/usr/local/lib -L/opt/local/lib'
     libpth=/usr/local/lib /opt/local/lib /usr/lib
     libs=-ldbm -ldl -lm -lc
     perllibs=-ldl -lm -lc
     libc=, so=dylib, useshrplib=false, libperl=libperl.a
     gnulibc_version=''
   Dynamic Linking:
     dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
     cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup 
-L/usr/local/lib -L/opt/local/lib'

Locally applied patches:



@INC for perl 5.16.0:
     /usr/local/lib/perl5/site_perl/5.16.0/darwin-2level
     /usr/local/lib/perl5/site_perl/5.16.0
     /usr/local/lib/perl5/5.16.0/darwin-2level
     /usr/local/lib/perl5/5.16.0
     /usr/local/lib/perl5/site_perl/5.14.2
     /usr/local/lib/perl5/site_perl/5.14.0
     /usr/local/lib/perl5/site_perl/5.12.0
     /usr/local/lib/perl5/site_perl/5.10.1
     /usr/local/lib/perl5/site_perl/5.10.0
     /usr/local/lib/perl5/site_perl
     .


Environment for perl 5.16.0:
 
DYLD_LIBRARY_PATH=/Users/jimk/work/pseudoinstall/lib:/Users/jimk/gitwork/parrot/blib/lib
     HOME=/Users/jimk
     LANG (unset)
     LANGUAGE (unset)
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
 
PATH=/usr/local/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/Users/jimk/bin:/Users/jimk/bin/perl:/Users/jimk/bin/c:/Users/jimk/bin/shell:/sw/lib:/sw/bin:/Users/jimk/bin:/Users/jimk/bin/perl:/Users/jimk/bin/c:/Users/jimk/bin/shell:/sw/lib:/sw/bin
     PERL_BADLANG (unset)
     SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2012

From chromatic@wgz.org

On Friday, June 01, 2012 04​:00​:31 PM James E Keenan wrote​:

From time-to-time I run coverage analysis on the Parrot virtual
machine's configuration and build tools. Today I ran that
program for the first time after upgrading to Perl 5.16.0 and
v0.87 of Devel​::Cover

Monitoring the output, I saw this, which
I had not previously observed​:

t/configure/033-step.t ...................... 1/34 Use of uninitialized
value $prefix in string eq at /usr/local/lib/perl5/5.16.0/B/Deparse.pm
line 1335.

Is this running under 'make test'?

How should we proceed?

Given that B​::Deparse has on line 26 in my 5.16 installation​:

  use warnings ();

... perhaps this is really a bug in Test​::Harness, which somewhere in its guts
unilaterally enables warnings throughout all subprograms it launches.

(Some might argue there's a bug in warnings.pm that this empty import list
doesn't do quite the same thing as "no warnings 'unitialized';".)

-- c

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2012

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2012

From @jkeenan

On Fri Jun 01 16​:19​:23 2012, chromatic@​wgz.org wrote​:

On Friday, June 01, 2012 04​:00​:31 PM James E Keenan wrote​:

Is this running under 'make test'?

How should we proceed?

Given that B​::Deparse has on line 26 in my 5.16 installation​:

use warnings \(\);

... perhaps this is really a bug in Test​::Harness, which somewhere in
its guts
unilaterally enables warnings throughout all subprograms it launches.

(Some might argue there's a bug in warnings.pm that this empty import
list
doesn't do quite the same thing as "no warnings 'unitialized';".)

Here's the guts of the program I'm using​:

PERL5OPT=-MDevel​::Cover=-db,$COVERAGEDIR/ \
  perl Configure.pl --test --configure_trace

It's the same program I've used for years. I usually run it in a screen
session, so I don't often observe the error output. This B​::Deparse
output is something I haven't observed before.

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2012

From chromatic@wgz.org

On Friday, June 01, 2012 04​:40​:30 PM James E Keenan via RT wrote​:

... perhaps this is really a bug in Test​::Harness, which somewhere in
its guts unilaterally enables warnings throughout all subprograms it
launches.

Here's the guts of the program I'm using​:

PERL5OPT=-MDevel​::Cover=-db,$COVERAGEDIR/ \
perl Configure.pl --test --configure_trace

It's the same program I've used for years. I usually run it in a screen
session, so I don't often observe the error output. This B​::Deparse
output is something I haven't observed before.

Parrot's Configure.pl eventually calls something which uses Test​::Harness.

-- c

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2012

From @jkeenan

On 6/1/12 10​:15 PM, chromatic wrote​:

On Friday, June 01, 2012 04​:40​:30 PM James E Keenan via RT wrote​:

... perhaps this is really a bug in Test​::Harness, which somewhere in
its guts unilaterally enables warnings throughout all subprograms it
launches.

Here's the guts of the program I'm using​:

PERL5OPT=-MDevel​::Cover=-db,$COVERAGEDIR/ \
perl Configure.pl --test --configure_trace

It's the same program I've used for years. I usually run it in a screen
session, so I don't often observe the error output. This B​::Deparse
output is something I haven't observed before.

Parrot's Configure.pl eventually calls something which uses Test​::Harness.

But it doesn't bother me that running my program throws warnings. For
example, running Devel​::Cover throws a *lot* of "subroutine redefined"
warnings. What I'm calling attention to is that there's a specific
place in B​::Deparse that is particularly prone to an "uninitialized
value" warning and that this is fixable.

jimk

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2012

From @nwc10

On Fri, Jun 01, 2012 at 04​:18​:46PM -0700, chromatic wrote​:

On Friday, June 01, 2012 04​:00​:31 PM James E Keenan wrote​:

From time-to-time I run coverage analysis on the Parrot virtual
machine's configuration and build tools. Today I ran that
program for the first time after upgrading to Perl 5.16.0 and
v0.87 of Devel​::Cover

Monitoring the output, I saw this, which
I had not previously observed​:

t/configure/033-step.t ...................... 1/34 Use of uninitialized
value $prefix in string eq at /usr/local/lib/perl5/5.16.0/B/Deparse.pm
line 1335.

Is this running under 'make test'?

How should we proceed?

Given that B​::Deparse has on line 26 in my 5.16 installation​:

use warnings \(\);

What is that code intending by this?

BEGIN {
  require warnings;
}

Surely that's a no-op within the scope of Deparse.pm, as all it does is load
warnings.pm if it's not already loaded. So, likely, not what the author
intended.

... perhaps this is really a bug in Test​::Harness, which somewhere in its guts
unilaterally enables warnings throughout all subprograms it launches.

(Some might argue there's a bug in warnings.pm that this empty import list
doesn't do quite the same thing as "no warnings 'unitialized';".)

That's going to be tricky, isn't it? Because C<use foo ();> doesn't even call
foo->import(), whereas use foo; does (with an empty list). Couple this with
how require only loads the code once, and I think that there's no reliable
way of detecting that something did C<use warnings ();> because
C<BEGIN { require warnings; }> may not even run any Perl code.

Nicholas Clark

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2012

From @pjcj

On Fri, Jun 01, 2012 at 10​:43​:06PM -0400, James E Keenan wrote​:

On 6/1/12 10​:15 PM, chromatic wrote​:

On Friday, June 01, 2012 04​:40​:30 PM James E Keenan via RT wrote​:

... perhaps this is really a bug in Test​::Harness, which somewhere in
its guts unilaterally enables warnings throughout all subprograms it
launches.

Here's the guts of the program I'm using​:

PERL5OPT=-MDevel​::Cover=-db,$COVERAGEDIR/ \
perl Configure.pl --test --configure_trace

It's the same program I've used for years. I usually run it in a screen
session, so I don't often observe the error output. This B​::Deparse
output is something I haven't observed before.

Parrot's Configure.pl eventually calls something which uses Test​::Harness.

But it doesn't bother me that running my program throws warnings.
For example, running Devel​::Cover throws a *lot* of "subroutine
redefined" warnings. What I'm calling attention to is that there's
a specific place in B​::Deparse that is particularly prone to an
"uninitialized value" warning and that this is fixable.

It is the enabling of warnings which is the specific reason that these
messages are being seen, as chromatic suggests. Compare​:

$ perl -MDevel​::Cover -e 'open "open"'

with

$ perl -w -MDevel​::Cover -e 'open "open"'

But I haven't looked into exactly what is turning on the warnings in
this case.

The warning is indeed new in 5.16.0. It came into being with be6cf5c
from Father C, which was on top of b89b725, which was a fix for #91416.

There are at least two things which can be done here. First, changing
the explicit undef to "" doesn't cause any tests to fail. (The only
test exercising that code is the one added by Father C as a part of the
patch.) I have attached a patch to do that, but perhaps Father C has a
comment about this?

Secondly, I can insulate Devel​::Cover against this by explicitly turning
off warnings before calling B​::Deparse. I have done this as
pjcj/Devel--Cover@0cc09d9
which will be in the next release of Devel​::Cover.

There is another uninitialized warning shown by
$ ./perl -w -Ilib dist/B-Deparse/t/deparse.t
  Use of uninitialized value in string ne at lib/B/Deparse.pm line 1606

There are probably others not shown by the tests. I have provided
patches to quieten B​::Deparse warnings in the past. Do we want to make
B​::Deparse warning safe?

For many years I've wanted to split B​::Deparse into its two logical
parts​: one to generate an AST and the other to generate Perl from the
AST. Then you could have other front or back ends targetting the same
AST. I don't suppose I'll ever find time to do it though.

--
Paul Johnson - paul@​pjcj.net
http​://www.pjcj.net

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2012

From @pjcj

perl113464.patch
commit a52451d8c9cd8ffae49eb56535d6ac6dba04f18b
Author: Paul Johnson <paul@pjcj.net>
Date:   Sat Jun 2 14:44:47 2012 +0200

    Quieten B::Deparse warnings (fixes #113464).

diff --git a/dist/B-Deparse/Deparse.pm b/dist/B-Deparse/Deparse.pm
index 46af5e4..debbf6a 100644
--- a/dist/B-Deparse/Deparse.pm
+++ b/dist/B-Deparse/Deparse.pm
@@ -2500,7 +2500,7 @@ sub rv2gv_or_string {
     my($self,$op) = @_;
     if ($op->name eq "gv") { # could be open("open") or open("###")
 	my($name,$quoted) =
-	    $self->stash_variable_name(undef,$self->gv_or_padgv($op));
+	    $self->stash_variable_name("", $self->gv_or_padgv($op));
 	$quoted ? $name : "*$name";
     }
     else {

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2012

From @doy

On Sat, Jun 02, 2012 at 03​:07​:24PM +0200, Paul Johnson wrote​:

On Fri, Jun 01, 2012 at 10​:43​:06PM -0400, James E Keenan wrote​:

On 6/1/12 10​:15 PM, chromatic wrote​:

On Friday, June 01, 2012 04​:40​:30 PM James E Keenan via RT wrote​:

... perhaps this is really a bug in Test​::Harness, which somewhere in
its guts unilaterally enables warnings throughout all subprograms it
launches.

Here's the guts of the program I'm using​:

PERL5OPT=-MDevel​::Cover=-db,$COVERAGEDIR/ \
perl Configure.pl --test --configure_trace

It's the same program I've used for years. I usually run it in a screen
session, so I don't often observe the error output. This B​::Deparse
output is something I haven't observed before.

Parrot's Configure.pl eventually calls something which uses Test​::Harness.

But it doesn't bother me that running my program throws warnings.
For example, running Devel​::Cover throws a *lot* of "subroutine
redefined" warnings. What I'm calling attention to is that there's
a specific place in B​::Deparse that is particularly prone to an
"uninitialized value" warning and that this is fixable.

It is the enabling of warnings which is the specific reason that these
messages are being seen, as chromatic suggests. Compare​:

$ perl -MDevel​::Cover -e 'open "open"'

with

$ perl -w -MDevel​::Cover -e 'open "open"'

But I haven't looked into exactly what is turning on the warnings in
this case.

Test​::Harness forcibly runs everything with -w​:
https://metacpan.org/source/ANDYA/Test-Harness-3.23/lib/Test/Harness.pm#L76

I believe people have been talking with andya to get this fixed, because
it really is kind of broken.

-doy

@p5pRT
Copy link
Author

p5pRT commented Jun 3, 2012

From @rjbs

* Jesse Luehrs <doy@​tozt.net> [2012-06-02T12​:35​:59]

https://metacpan.org/source/ANDYA/Test-Harness-3.23/lib/Test/Harness.pm#L76

I believe people have been talking with andya to get this fixed, because
it really is kind of broken.

A few of us demonstrated this behavior to Andy about a month ago and he agreed
that it was not desirable and easy to restore if desired on a per-whatever
basis, and has made the required commit to fix it​:

  Perl-Toolchain-Gang/Test-Harness@18794a8

...it just hasn't been released yet.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented Jun 3, 2012

From @jkeenan

On Sun Jun 03 06​:32​:05 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Jesse Luehrs <doy@​tozt.net> [2012-06-02T12​:35​:59]

https://metacpan.org/source/ANDYA/Test-Harness-
3.23/lib/Test/Harness.pm#L76

I believe people have been talking with andya to get this fixed,
because
it really is kind of broken.

A few of us demonstrated this behavior to Andy about a month ago and
he agreed
that it was not desirable and easy to restore if desired on a per-
whatever
basis, and has made the required commit to fix it​:

https://github.com/Perl-Toolchain-Gang/Test-
Harness/commit/18794a8565633ae08f048b9cf6c25b03be6e1020

...it just hasn't been released yet.

Okay, that should permit us to re-focus the discussion in this RT back
to its original topic​: uninitialized value warnings in B​::Deparse
revealed by usage of Devel​::Cover.

rjbs​: Do you have thoughts about how we should approach this?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Jun 8, 2012

From @jkeenan

On Sat Jun 02 06​:08​:02 2012, paul@​pjcj.net wrote​:

There are at least two things which can be done here. First, changing
the explicit undef to "" doesn't cause any tests to fail. (The only
test exercising that code is the one added by Father C as a part of
the
patch.) I have attached a patch to do that, but perhaps Father C has
a
comment about this?

I have tested this patch against blead and can confirm that all tests
continue to pass.

Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Jun 9, 2012

From @cpansprout

On Sat Jun 02 03​:33​:13 2012, nicholas wrote​:

On Fri, Jun 01, 2012 at 04​:18​:46PM -0700, chromatic wrote​:

On Friday, June 01, 2012 04​:00​:31 PM James E Keenan wrote​:

From time-to-time I run coverage analysis on the Parrot virtual
machine's configuration and build tools. Today I ran that
program for the first time after upgrading to Perl 5.16.0 and
v0.87 of Devel​::Cover

Monitoring the output, I saw this, which
I had not previously observed​:

t/configure/033-step.t ...................... 1/34 Use of
uninitialized
value $prefix in string eq at
/usr/local/lib/perl5/5.16.0/B/Deparse.pm
line 1335.

Is this running under 'make test'?

How should we proceed?

Given that B​::Deparse has on line 26 in my 5.16 installation​:

use warnings \(\);

What is that code intending by this?

BEGIN {
require warnings;
}

Surely that's a no-op within the scope of Deparse.pm, as all it does
is load
warnings.pm if it's not already loaded. So, likely, not what the
author
intended.

I’m pretty certain that is *exactly* what the author intended. Later on
we see this​:

{
  # Mask out the bits that L<warnings​::register> uses
  my $WARN_MASK;
  BEGIN {
  $WARN_MASK = $warnings​::Bits{all} | $warnings​::DeadBits{all};
  }
  sub WARN_MASK () {
  return $WARN_MASK;
  }
}

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Jun 9, 2012

From @cpansprout

On Sat Jun 02 06​:08​:02 2012, paul@​pjcj.net wrote​:

On Fri, Jun 01, 2012 at 10​:43​:06PM -0400, James E Keenan wrote​:

On 6/1/12 10​:15 PM, chromatic wrote​:

On Friday, June 01, 2012 04​:40​:30 PM James E Keenan via RT wrote​:

... perhaps this is really a bug in Test​::Harness, which
somewhere in
its guts unilaterally enables warnings throughout all subprograms
it
launches.

Here's the guts of the program I'm using​:

PERL5OPT=-MDevel​::Cover=-db,$COVERAGEDIR/ \
perl Configure.pl --test --configure_trace

It's the same program I've used for years. I usually run it in a
screen
session, so I don't often observe the error output. This
B​::Deparse
output is something I haven't observed before.

Parrot's Configure.pl eventually calls something which uses
Test​::Harness.

But it doesn't bother me that running my program throws warnings.
For example, running Devel​::Cover throws a *lot* of "subroutine
redefined" warnings. What I'm calling attention to is that there's
a specific place in B​::Deparse that is particularly prone to an
"uninitialized value" warning and that this is fixable.

It is the enabling of warnings which is the specific reason that these
messages are being seen, as chromatic suggests. Compare​:

$ perl -MDevel​::Cover -e 'open "open"'

with

$ perl -w -MDevel​::Cover -e 'open "open"'

But I haven't looked into exactly what is turning on the warnings in
this case.

The warning is indeed new in 5.16.0. It came into being with be6cf5c
from Father C, which was on top of b89b725, which was a fix for
#91416.

There are at least two things which can be done here. First, changing
the explicit undef to "" doesn't cause any tests to fail. (The only
test exercising that code is the one added by Father C as a part of
the
patch.) I have attached a patch to do that, but perhaps Father C has
a
comment about this?

That patch looks good. I have applied it as 1db94ee. Thank you.

Secondly, I can insulate Devel​::Cover against this by explicitly
turning
off warnings before calling B​::Deparse. I have done this as
https://github.com/pjcj/Devel--
Cover/commit/0cc09d91d9107838845c9572cffb9cbb4c385723
which will be in the next release of Devel​::Cover.

There is another uninitialized warning shown by
$ ./perl -w -Ilib dist/B-Deparse/t/deparse.t
Use of uninitialized value in string ne at lib/B/Deparse.pm line
1606

There are probably others not shown by the tests. I have provided
patches to quieten B​::Deparse warnings in the past. Do we want to
make
B​::Deparse warning safe?

It wouldn’t hurt to make it warning-safe, but, for me, it’s really not
high-priority.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Jun 9, 2012

@cpansprout - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant