Re: FAILs with undefined symbol: setup_constants
On Mon, 27 Oct 2008 11:03:00 +, Paul LeoNerd Evans [EMAIL
PROTECTED] said:
I'm finding that one of my XS-based dists, Devel-Refcount, is failing
lately on most platforms ({Open,Free,Net}BSD, Darwin, Linux), on a symbol
lookup error:
t/01refs.../home/cpan/pit/rel/perl-5.10.0/bin/perl: symbol lookup
error:
/home/cpan/pit/rel/conf/perl-5.10.0/.cpanplus/5.10.0/build/Devel-Refcount-0.03/blib/arch/auto/Devel/Refcount/Refcount.so:
undefined symbol: setup_constants
I don't have such a symbol in my code; the XS is absolutely tiny. It
seems like it may be related to perl itself then?
For reference, some FAILs:
http://nntp.x.perl.org/group/perl.cpan.testers/2470288 (5.10 / linux)
http://nntp.x.perl.org/group/perl.cpan.testers/2449662 (5.10 / netbsd)
http://nntp.x.perl.org/group/perl.cpan.testers/2447543 (5.10 / darwin)
All your fail reports are written by bingos with CPANPLUS, version
0.84. This is not only true for the three above but for all reports.
CPANPLUS 0.84 *never* wrote a PASS for Devel-Refcount up to now.
Some PASSes on the same perl version / platform:
http://nntp.x.perl.org/group/perl.cpan.testers/2069693 (5.10 / linux)
http://nntp.x.perl.org/group/perl.cpan.testers/2028293 (5.10 / netbsd)
http://nntp.x.perl.org/group/perl.cpan.testers/2149637 (5.10 / darwin)
These are written by CPANPLUS::Dist::YACSmoke 0.02 and 0.04 by the
same tester, this time known as chris.
Before I go looking too deeply into it; is anyone aware of the reason
behind this? Anything I can do about it?
Maybe chris knows something?
--
andreas
Re: FAILs with undefined symbol: setup_constants
On Wed, 29 Oct 2008 05:16:57 +0100 [EMAIL PROTECTED] (Andreas J. Koenig) wrote: All your fail reports are written by bingos with CPANPLUS, version 0.84. This is not only true for the three above but for all reports. CPANPLUS 0.84 *never* wrote a PASS for Devel-Refcount up to now. ... These are written by CPANPLUS::Dist::YACSmoke 0.02 and 0.04 by the same tester, this time known as chris. Like a cheetah who's just won Best Coat Award in the annual Serengeti Miss Africa contest; well spotted. Maybe chris knows something? Righto. I'll ask him. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Arrays in Config::General without resorting to copy/paste OR yaml
I'm trying to set a configuration file with Config::General and apparently to set an Array, I need to the following example: example lamp = linux lamp = apache lamp = mysql lamp = perl /example When using keys that are long, it's simply a copy paste issue. Isn't the a more comfortable way? These don't work either: lamp linux, apache, mysql, perl /lamp -- lamp linux apache mysql perl /lamp Anyone?
Re: Arrays in Config::General without resorting to copy/paste OR yaml
* On Wed, Oct 29 2008, Sawyer X wrote: I'm trying to set a configuration file with Config::General and apparently to set an Array, I need to the following example: example lamp = linux lamp = apache lamp = mysql lamp = perl /example When using keys that are long, it's simply a copy paste issue. Isn't the a more comfortable way? These don't work either: lamp linux, apache, mysql, perl /lamp What is stopping you from post-processing this into the data you want? You are but a simple split away from having this syntax work. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Arrays in Config::General without resorting to copy/paste OR yaml
I'm using Moose with MooseX::SimpleConfig
I guess it'd be nicer if the configuration module (Config::Any) or
even MooseX::SimpleConfig role would do this instead of having to do
sub BUILD {
my $self = shift;
$self-method( [ split /,/, $self-method ] );
}
On Wed, Oct 29, 2008 at 8:15 PM, Jonathan Rockway [EMAIL PROTECTED] wrote:
* On Wed, Oct 29 2008, Sawyer X wrote:
I'm trying to set a configuration file with Config::General and
apparently to set an Array, I need to the following example:
example
lamp = linux
lamp = apache
lamp = mysql
lamp = perl
/example
When using keys that are long, it's simply a copy paste issue. Isn't
the a more comfortable way?
These don't work either:
lamp
linux, apache, mysql, perl
/lamp
What is stopping you from post-processing this into the data you want?
You are but a simple split away from having this syntax work.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Arrays in Config::General without resorting to copy/paste OR yaml
* On Wed, Oct 29 2008, sawyer x wrote:
I'm using Moose with MooseX::SimpleConfig
I guess it'd be nicer if the configuration module (Config::Any) or
even MooseX::SimpleConfig role would do this instead of having to do
sub BUILD {
my $self = shift;
$self-method( [ split /,/, $self-method ] );
}
In this case, I think you can write a custom Config::Any plugin:
package Config::Any::Foo;
sub extensions { 'foo' }
sub load {
my ($class, $filename, $args) = @_;
...
if( whatever ) { split /, /, ... }
return ...
}
Then if you have a .foo file, this code will run to load it. Totally
untested, but something like this should work.
BTW, I would just use YAML (or JSON) here. Config::General is one of
the ugliest file formats I've ever seen, and it maps poorly to Perl.
YAML is nice looking and maps perfectly to Perl.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
Re: Integrating license related things of CPAN
On Mon, Oct 27, 2008 at 11:17 AM, David Cantrell [EMAIL PROTECTED] wrote: So, in summary, here's my objections to the current 'license' field in META.yml: * poorly documented; * limited range of options for licences; * only one licence per distribution The first is fixable so I'm not too bothered by it. The second and third are fundamental design flaws which make it unfit for purpose. Your proposal doesn't seem to address the second point in any way. I'm also not thrilled with how it addresses the third, since it seems to me that any distribution with such complex licensing terms probably can't be covered by such a mechanism anyway. For instance, if I have A.pm under GPL and B.pm under BSD, what happens when they call each other? Does that constitute encapsulation and/or usage as a library? Such matters generally have to be spelled out explicitly. I agree that the second point is a problem. I'd like to solve it by delegating to Software::License. Anything it knows about should be a valid choice. -Ken
Re: Integrating license related things of CPAN
On Wed, Oct 29, 2008 at 9:13 PM, Ken Williams [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 11:17 AM, David Cantrell [EMAIL PROTECTED] wrote: So, in summary, here's my objections to the current 'license' field in META.yml: * poorly documented; * limited range of options for licences; * only one licence per distribution The first is fixable so I'm not too bothered by it. The second and third are fundamental design flaws which make it unfit for purpose. Your proposal doesn't seem to address the second point in any way. I'm also not thrilled with how it addresses the third, since it seems to me that any distribution with such complex licensing terms probably can't be covered by such a mechanism anyway. For instance, if I have A.pm under GPL and B.pm under BSD, what happens when they call each other? Does that constitute encapsulation and/or usage as a library? Such matters generally have to be spelled out explicitly. I agree that the second point is a problem. I'd like to solve it by delegating to Software::License. Anything it knows about should be a valid choice. I think supporting options like other or mixed should resolve most of these cases. Sure, automatic tools that use this field will be out of luck, but that should be a fairly small minority.
