[32832] in Perl-Users-Digest
Perl-Users Digest, Issue: 4097 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Dec 20 21:09:30 2013
Date: Fri, 20 Dec 2013 18:09:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 20 Dec 2013 Volume: 11 Number: 4097
Today's topics:
Re: Can't locate object method "new" via package <news@lawshouse.org>
Re: Can't locate object method "new" via package <news@lawshouse.org>
Re: Can't locate object method "new" via package <rweikusat@mobileactivedefense.com>
Re: Extra commas ignored? <rweikusat@mobileactivedefense.com>
Re: Extra commas ignored? <ben@morrow.me.uk>
Re: Syntax understanding problem (Tony Mountifield)
Re: Syntax understanding problem <ben@morrow.me.uk>
Re: Syntax understanding problem <jurgenex@hotmail.com>
Re: Syntax understanding problem <rweikusat@mobileactivedefense.com>
Re: Syntax understanding problem <jurgenex@hotmail.com>
Re: Syntax understanding problem <ben@morrow.me.uk>
Re: Syntax understanding problem <ben@morrow.me.uk>
Re: Syntax understanding problem <jurgenex@hotmail.com>
Re: Syntax understanding problem (Tim McDaniel)
Re: Syntax understanding problem <ben@morrow.me.uk>
Warnings when using Graphics::ColorObject <sbryce@scottbryce.com>
Re: Warnings when using Graphics::ColorObject <ben@morrow.me.uk>
Re: Warnings when using Graphics::ColorObject <sbryce@scottbryce.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 20 Dec 2013 11:14:12 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Can't locate object method "new" via package
Message-Id: <SLqdnWagZ5gYuynPnZ2dnUVZ8j-dnZ2d@giganews.com>
On 20/12/13 10:33, smilesonisamal@gmail.com wrote:
> Can't locate object method "new" via package
This helpful error message is telling you that the package you're using
doesn't have a "new" method.
Well, should it? Only you can tell, since we don't know which package,
or who wrote it, or how you ended up calling it. It might even be a
coding error on your part.
So, as Jürgen Exner suggests, why not post something which actually
tells us what's going on? It's completely futile trying to help until
you do, can you not see?
--
Henry Law Manchester, England
------------------------------
Date: Fri, 20 Dec 2013 11:16:59 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Can't locate object method "new" via package
Message-Id: <SLqdnWGgZ5i2uinPnZ2dnUVZ8j-dnZ2d@giganews.com>
On 20/12/13 10:52, George Mpouras wrote:
> # try
George, Jürgen ... small virtual coffee bet that this is one of the
threads where the OP never shows up again. Like nraju531@gmail.com in
the "Perl Modules and Packages" thread started December 14th.
--
Henry Law Manchester, England
------------------------------
Date: Fri, 20 Dec 2013 14:09:00 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can't locate object method "new" via package
Message-Id: <87txe3ty0z.fsf@sable.mobileactivedefense.com>
smilesonisamal@gmail.com writes:
> Hi all,
> I am finding an issue in perl v5.10.1. I am getting the following issue.
> I have added the path in @INC in my script.
>
> Error : Can't locate object method "new" via package
>
> Can anybody help me in this regard?
This statement is a little cryptic. Let's assume that the package name
is Arthur. In this case, the error message
Error : Can't locate object method "new" via package Arthur
(perhaps you forgot to load Arthur)
means there's a call to a method named new (usually a constructor)
using Arthur as invocant, eg
my $dent = Arthur->new();
but the symbol table of the package Arthur didn't contain an entry for a
subroutine named new. Usually, the cause is just what the error message
suggests: It wasn't loaded, a statement a la
use Arthur;
is missing. You should provide some more information about your problem
if that wasn't the cause.
------------------------------
Date: Fri, 20 Dec 2013 16:32:30 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Extra commas ignored?
Message-Id: <87wqizv5y9.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>>
>> The key is the "it's just the list argument separator" here which
>> implies that a comma in list context is not 'the comma operator' (which
>> takes two arguments, evaluates both left-to-right and returns the
>> result of the right one[*]) but a separator.
>
> There is only one comma operator. It always parses the same, and it
> always compiles down to the same opcode (it has to, because context
> isn't always known at compile time).
Judging from the 5.10.1 perly.y, there's actually no such thing as 'a
comma operator' which would need to be a 'binary operator between
terms'. The lexer treats it as such but in the parser, it's only (slight
simplification)
/* Expressions are a list of terms joined by commas */
argexpr : argexpr ','
{
#ifdef MAD
OP* op = newNULLLIST();
token_getmad($2,op,',');
$$ = append_elem(OP_LIST, $1, op);
#else
$$ = $1;
#endif
}
| argexpr ',' term
{
OP* term = $3;
DO_MAD(
term = newUNOP(OP_NULL, 0, term);
token_getmad($2,term,',');
)
$$ = append_elem(OP_LIST, $1, term);
}
| term %prec PREC_LOW
;
ie, there is something like a list operator and the , is used as purely
syntactical element for separating terms in a list.
[...]
>> [*] Technically, the scalar-context comma operator is also not an operator
>> in the sense that + is, it's rather a compiler directive.
>
> Nonsense. The lexer, parser and optree handle it exactly the same way as
> they handle +, except for the fact that OP_LIST takes multiple arguments.
At least in certain cases, the list is expanded inline, with no 'list
operator' anywhere in sight, eg
[rw@sable]~#perl -MO=Concise,-exec,a -e 'sub a { return ($_[0], $_[3], $_[2]); }'
main::a:
1 <;> nextstate(main 1 -e:1) v
2 <0> pushmark s
3 <#> aelemfast[*_] s
4 <#> aelemfast[*_] s/3
5 <#> aelemfast[*_] s/2
6 <@> return KP
7 <1> leavesub[1 ref] K/REFC,1
In constrast to this, an addition compiles to
[rw@sable]~#perl -MO=Concise,-exec,a -e 'sub a { return ($_[0] + $_[3] + $_[2]); }'
main::a:
1 <;> nextstate(main 1 -e:1) v
2 <0> pushmark s
3 <#> aelemfast[*_] s
4 <#> aelemfast[*_] s/3
5 <2> add[t3] sK/2
6 <#> aelemfast[*_] s/2
7 <2> add[t5] sKP/2
8 <@> return K
9 <1> leavesub[1 ref] K/REFC,1
And in any case,
[rw@sable]~#perl -e 'LIST =~ /,|comma/i or print "something else\n"'
something else
It would be interesting to know if 'the comma operator' in C is actually
treated as an operator or if the historical misnomer actually came from
there.
NB: I'm very much obliged to you for posting this because it has greatly
helped my understanding of perl, even though this reply may not sound
like this. I don't have an affirmtative mind ...
------------------------------
Date: Fri, 20 Dec 2013 18:28:12 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Extra commas ignored?
Message-Id: <sqeeoa-e7s2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> >>
> >> The key is the "it's just the list argument separator" here which
> >> implies that a comma in list context is not 'the comma operator' (which
> >> takes two arguments, evaluates both left-to-right and returns the
> >> result of the right one[*]) but a separator.
> >
> > There is only one comma operator. It always parses the same, and it
> > always compiles down to the same opcode (it has to, because context
> > isn't always known at compile time).
>
> Judging from the 5.10.1 perly.y, there's actually no such thing as 'a
> comma operator' which would need to be a 'binary operator between
> terms'. The lexer treats it as such but in the parser, it's only (slight
> simplification)
>
> /* Expressions are a list of terms joined by commas */
> argexpr : argexpr ','
[Sometime between 5.10.1 and the blead source I posted an extract from
before, this production was renamed to 'listexpr'...]
> | argexpr ',' term
> | term %prec PREC_LOW
> ;
>
> ie, there is something like a list operator and the , is used as purely
> syntactical element for separating terms in a list.
OK, you can call it that if you like; it's not really any different from
the ?: operator, which uses '?' and ':' to separate its three arguments.
My point was that 'the scalar comma operator' and 'the list context list
construction operator' are actually the same operator, whose behaviour
is context-dependant.
> >> [*] Technically, the scalar-context comma operator is also not an operator
> >> in the sense that + is, it's rather a compiler directive.
> >
> > Nonsense. The lexer, parser and optree handle it exactly the same way as
> > they handle +, except for the fact that OP_LIST takes multiple arguments.
>
> At least in certain cases, the list is expanded inline, with no 'list
> operator' anywhere in sight, eg
>
> [rw@sable]~#perl -MO=Concise,-exec,a -e 'sub a { return ($_[0], $_[3],
> $_[2]); }'
> main::a:
> 1 <;> nextstate(main 1 -e:1) v
> 2 <0> pushmark s
> 3 <#> aelemfast[*_] s
> 4 <#> aelemfast[*_] s/3
> 5 <#> aelemfast[*_] s/2
> 6 <@> return KP
> 7 <1> leavesub[1 ref] K/REFC,1
That's a slight hack: this is the 'listop' production, which does
actually build an OP_LIST, but then, rather than adding an extra op, it
converts the OP_LIST into an OP_RETURN. It's easier to see what's
happening without -exec:
~/src/perl/perl% perl -MO=Concise,a -e'sub a { $x, $y, $z }'
main::a:
7 <1> leavesub[1 ref] K/REFC,1 ->(end)
- <@> lineseq KP ->7
1 <;> nextstate(main 1 -e:1) v ->2
6 <@> list K ->7
2 <0> pushmark s ->3
- <1> ex-rv2sv sK/1 ->4
3 <$> gvsv(*x) s ->4
- <1> ex-rv2sv sK/1 ->5
4 <$> gvsv(*y) s ->5
- <1> ex-rv2sv sK/1 ->6
5 <$> gvsv(*z) s ->6
-e syntax OK
~/src/perl/perl% perl -MO=Concise,a -e'sub a { return $x, $y, $z }'
main::a:
7 <1> leavesub[1 ref] K/REFC,1 ->(end)
- <@> lineseq KP ->7
1 <;> nextstate(main 1 -e:1) v ->2
6 <@> return K ->7
2 <0> pushmark s ->3
- <1> ex-rv2sv sK/1 ->4
3 <$> gvsv(*x) s ->4
- <1> ex-rv2sv sK/1 ->5
4 <$> gvsv(*y) s ->5
- <1> ex-rv2sv sK/1 ->6
5 <$> gvsv(*z) s ->6
-e syntax OK
The only different between these two is that perl has turned the 'list'
into a 'return'.
> And in any case,
>
> [rw@sable]~#perl -e 'LIST =~ /,|comma/i or print "something else\n"'
> something else
I don't understand this.
> It would be interesting to know if 'the comma operator' in C is actually
> treated as an operator or if the historical misnomer actually came from
> there.
In C the comma really does have two entirely different meanings: the
'comma operator' which behaves like Perl's comma in scalar context, and
the comma-as-an-argument-separator in the argument list of a function
call, which is not really an operator at all.
Ben
------------------------------
Date: Fri, 20 Dec 2013 13:22:22 +0000 (UTC)
From: tony@mountifield.org (Tony Mountifield)
Subject: Re: Syntax understanding problem
Message-Id: <l91gae$bmc$1@softins.softins.co.uk>
In article <gefdoa-a5o.ln1@zem.masonsmusic.co.uk>,
Justin C <justin.1303@purestblue.com> wrote:
> I've just found something in code I wrote, but I don't
> understand it and don't know where I found it. I wrote it a long
> time ago. I have this line:
>
> ($discard = 0, next) if /^Relayed messages/;
This is just a cryptic perlish way of saying this:
if (/^Relayed messages/) {
$discard = 0;
next;
}
It was just a way of dispensing with {} and making it a one-liner,
which some people consider cool. (I'm not commenting on that opinion).
> I was tweaking the program for a issue I had (that turns out to
> have been elsewhere), and changed the above to:
>
> $discard = 0 if /^Relayed messages/;
>
> At a later stage I had to revert to the original behaviour and
> put this:
>
> ($discard = 0 && next) if /^Relayed messages/;
>
> Which didn't do what I wanted!
>
> Where can I read about this behaviour of the comma? And what is
> that && doing in the last version, am I really saying ($discard
> = 0) and ($discard = next)?
$ perldoc perlop
Cheers
Tony
--
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org
------------------------------
Date: Fri, 20 Dec 2013 13:31:02 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <mdtdoa-dgo2.ln1@anubis.morrow.me.uk>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Justin C <justin.1303@purestblue.com> wrote:
> >I've just found something in code I wrote, but I don't
> >understand it
>
> That's not surpising. You are (mis?)-using data structures as control
> flow elements. That is at the very least a rather questionable habit.
>
> >and don't know where I found it. I wrote it a long
> >time ago. I have this line:
> >
> >($discard = 0, next) if /^Relayed messages/;
>
> If the condition is true, then you are creating a temporary list that is
> never used. This list has 2 elements, first the value 0, and second the
> return value of next. As a side effect while calculating the first value
> it also sets $discard to 0. And of course 'next' never returns, so it
> does not really have a valid return value.
No, the bracketed expression is in void context, so no list is created;
instead this is 'the scalar comma operator', which is considered
reasonable to use to sequence side-effects.
> >($discard = 0 && next) if /^Relayed messages/;
> >
> >Which didn't do what I wanted!
>
> Not surprising that's something completely different. Here you got a
> list with only one element. And this element is calculated as the result
> of the assignment of the expression (0 && next) to $discard because &&
> has a higher precedence than the assignment.
> 0 is logical 'false', therefore the && short-circuits and never
> evaluates the right side 'next' but instead returns 'false' immediately
> and that's what gets assigned to $discard.
More specifically, it returns the 0 from the LHS. In particular,
$discard will now stringify as "0", rather than the "" you would get
from a generic false value.
Ben
------------------------------
Date: Fri, 20 Dec 2013 07:51:12 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Syntax understanding problem
Message-Id: <emp8b9p6mbhdnefsifmkv7m6f5obfici93@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>instead this is 'the scalar comma operator', which is considered
>reasonable to use to sequence side-effects.
This I dare say is highly debatable. Just because it is possible to use
data structures to control execution flow doesn't mean it is a good idea
to do so. The OPs confusion is actually a good example why it is a
pretty darn stupid idea.
jue
------------------------------
Date: Fri, 20 Dec 2013 17:22:22 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Syntax understanding problem
Message-Id: <87sitnv3n5.fsf@sable.mobileactivedefense.com>
tony@mountifield.org (Tony Mountifield) writes:
> In article <gefdoa-a5o.ln1@zem.masonsmusic.co.uk>,
> Justin C <justin.1303@purestblue.com> wrote:
>> I've just found something in code I wrote, but I don't
>> understand it and don't know where I found it. I wrote it a long
>> time ago. I have this line:
>>
>> ($discard = 0, next) if /^Relayed messages/;
>
> This is just a cryptic perlish way of saying this:
>
> if (/^Relayed messages/) {
> $discard = 0;
> next;
> }
>
> It was just a way of dispensing with {} and making it a one-liner,
> which some people consider cool. (I'm not commenting on that opinion).
It should be noted that this is your opinion about people who use
certain syntactic constructs (they're irrational and do bad things
because of that), camouflaged as asessement of the "deep, inner
motivations of someone who 'does something you'd never do yourself'" and
- completely unsurprisingly - you came to the conclusion that "they're
probably mad" (since 'drunk' won't suffice here).
$discard = 0, next if /^Relayed messages/;
is another way of writing
/^Related messages/ and $discard = 0, next;
That's an expression using the short-ciruiting behaviour of the boolean
operators for flow control, a possibility which has existed at least
since C, except that Perl provides an alternate set of these operators
whose precedence makes them more suitable for this use and an alternate
syntax someone presumably considered to be clearer than using the
operators. AFAIK, statement modifiers are indeed unique to Perl but
different programming languages actually differ and decrying them as
'cryptic' because they do make little sense ("You're all full of shit
and everything someone who has learnt Math doesn't understand ought to be
banned!" is an old Xah-Lee chestnut, pax hibiscus ...)
------------------------------
Date: Fri, 20 Dec 2013 10:03:58 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Syntax understanding problem
Message-Id: <5g19b99etnqr9tmkfano6ft9dcgc0c10ps@4ax.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>is another way of writing
>
>/^Related messages/ and $discard = 0, next;
>
>That's an expression using the short-ciruiting behaviour of the boolean
>operators for flow control, [...]
And exactly for this reason it is just as insane.
Just do not mix code (control flow) and data (expressions).
jue
------------------------------
Date: Fri, 20 Dec 2013 18:05:25 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <5gdeoa-8pr2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> AFAIK, statement modifiers are indeed unique to Perl but
Nope. Larry stole them from BASIC-PLUS (from whence also came the term
'ppcode', and possibly the whole idea of half-compiling).
Ben
------------------------------
Date: Fri, 20 Dec 2013 20:20:12 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <scleoa-f5t2.ln1@anubis.morrow.me.uk>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Ben Morrow <ben@morrow.me.uk> wrote:
> >instead this is 'the scalar comma operator', which is considered
> >reasonable to use to sequence side-effects.
>
> This I dare say is highly debatable. Just because it is possible to use
> data structures to control execution flow doesn't mean it is a good idea
> to do so. The OPs confusion is actually a good example why it is a
> pretty darn stupid idea.
The code in question was not a 'data structure', it was the comma
operator in scalar (or, actually, void) context. The sole purpose of the
behaviour of this operator is to allow this sort of sequencing of
side-effects within a statement, just like the equivalent operator in C.
Justin's confusion is more an example of why it is a bad idea to copy
code you don't entirely understand (sorry Justin) than of anything wrong
with the construction itself.
Ben
------------------------------
Date: Fri, 20 Dec 2013 13:40:45 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Syntax understanding problem
Message-Id: <65e9b9tt9gnb5afk84jjhbtob1envnbfk4@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth J?Exner <jurgenex@hotmail.com>:
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> >instead this is 'the scalar comma operator', which is considered
>> >reasonable to use to sequence side-effects.
>>
>> This I dare say is highly debatable. Just because it is possible to use
>> data structures to control execution flow doesn't mean it is a good idea
>> to do so. The OPs confusion is actually a good example why it is a
>> pretty darn stupid idea.
>
>The code in question was not a 'data structure', it was the comma
>operator in scalar (or, actually, void) context. The sole purpose of the
The code in question is an expression. The purpose of an expression is
to manipulate date, not to control execution flow.
>behaviour of this operator is to allow this sort of sequencing of
>side-effects within a statement, just like the equivalent operator in C.
I never said that side-effects in statements that are used for control
flow were a good idea in C, either.
>Justin's confusion is more an example of why it is a bad idea to copy
>code you don't entirely understand (sorry Justin) [...]
Well, that's a given, isn't it?
jue
------------------------------
Date: Fri, 20 Dec 2013 22:13:52 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Syntax understanding problem
Message-Id: <l92ff0$r45$1@reader1.panix.com>
In article <65e9b9tt9gnb5afk84jjhbtob1envnbfk4@4ax.com>,
J_rgen Exner <jurgenex@hotmail.com> wrote:
>The purpose of an expression is
>to manipulate data, not to control execution flow.
assert($args->{FLEX}, "Must say how to flex!");
$count = $args->{COUNT} || 1;
$source = $args->{ISUSER} ? $local : $global;
open my $log, '>>', '/home/fred/debug' or die;
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sat, 21 Dec 2013 00:57:36 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <0l5foa-te03.ln1@anubis.morrow.me.uk>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >Quoth J?Exner <jurgenex@hotmail.com>:
> >> Ben Morrow <ben@morrow.me.uk> wrote:
> >> >instead this is 'the scalar comma operator', which is considered
> >> >reasonable to use to sequence side-effects.
> >>
> >> This I dare say is highly debatable. Just because it is possible to use
> >> data structures to control execution flow doesn't mean it is a good idea
> >> to do so. The OPs confusion is actually a good example why it is a
> >> pretty darn stupid idea.
> >
> >The code in question was not a 'data structure', it was the comma
> >operator in scalar (or, actually, void) context. The sole purpose of the
>
> The code in question is an expression. The purpose of an expression is
> to manipulate date, not to control execution flow.
The code in question (approximately
($foo = $bar, next) if $whatever;
) is a statement under a postfix conditional, insofar as the distinction
between 'expression' and 'statement' exists in Perl. The brackets are,
perhaps, confusing (not to mention unnecessary), making it look like a
list when in fact it's nothing of the sort; I would have omitted them.
Apart from that, the scalar comma operator is explicitly intended for
control flow, just like 'and' and 'if' (and unlike '&&' and '?:').
This is not at all the same as, say,
my @x = ($foo = $bar, next);
which I would entirely agree is grossly confusing.
> >behaviour of this operator is to allow this sort of sequencing of
> >side-effects within a statement, just like the equivalent operator in C.
>
> I never said that side-effects in statements that are used for control
> flow were a good idea in C, either.
While I don't agree with that as a general principle[0], in this case
the expression used for control flow ($whatever) has no side-effects.
The expressions with side-effects are controlled by the 'if', and joined
by an operator intended for sequencing. The whole thing could equally
well have been written
do { $foo = $bar; next } if $whatever;
at some expense in clarity, or as
if ($whatever) {
$foo = $bar;
next;
}
with a substantial loss of concision.
[0] In particular, the constructions
if (my $x = ...) { ... }
$x = foo() and $y = $x->bar() and $y->baz();
not to mention
open ... or die;
are too useful to lose.
Ben
------------------------------
Date: Fri, 20 Dec 2013 10:58:38 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Warnings when using Graphics::ColorObject
Message-Id: <l920go$cvs$1@dont-email.me>
This script
--------------
#!/usr/bin/perl
use strict;
use warnings;
use Graphics::ColorObject;
my $hue = 0;
my $saturation = 0.7;
my $brightness = 1;
my $color = Graphics::ColorObject->new_HSV([$hue, $saturation,
$brightness]);
my ($cyan, $magenta, $yellow, $black) = @{$color->as_CMYK()};
print "$cyan, $magenta, $yellow, $black";
-----------------
throws a warning.
Use of uninitialized value within @_ in lc at
C:/Perl/site/lib/Graphics/ColorObject.pm line 1905.
Am I doing something wrong? Is there another module I should be using to
convert from HSV to CMYK?
What I want to do is select colors that are evenly distributed by hue
(thus HSV), but the output is a PDF file (thus the CMYK). I am drawing
pie charts, so I want contrast between successive colors.
Perl 5.16.3
Windows 8.
------------------------------
Date: Fri, 20 Dec 2013 21:32:32 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Warnings when using Graphics::ColorObject
Message-Id: <gkpeoa-sut2.ln1@anubis.morrow.me.uk>
Quoth Scott Bryce <sbryce@scottbryce.com>:
> This script
[...]
>
> throws a warning.
>
> Use of uninitialized value within @_ in lc at
> C:/Perl/site/lib/Graphics/ColorObject.pm line 1905.
This looks like a bug in Graphics::ColorObject, but it's hard to be
sure. Try adding
use Carp;
$SIG{__WARN__} = \&Carp::cluck;
to the top of your script, and see if the extra information helps.
> Am I doing something wrong? Is there another module I should be using to
> convert from HSV to CMYK?
I don't know, I'm afraid. I assume you've seen the note in the BUGS
section of that module about CMYK support not being very accurate?
> What I want to do is select colors that are evenly distributed by hue
> (thus HSV), but the output is a PDF file (thus the CMYK). I am drawing
> pie charts, so I want contrast between successive colors.
PDF supports RGB, and the conversion from HSV to RGB is simple and exact
(depending on exactly which definition of HSV you want), so you might
want to consider using RGB colours instead.
Ben
------------------------------
Date: Fri, 20 Dec 2013 18:18:58 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Warnings when using Graphics::ColorObject
Message-Id: <l92qae$99a$1@dont-email.me>
On 12/20/2013 2:32 PM, Ben Morrow wrote:
> This looks like a bug in Graphics::ColorObject, but it's hard to be
> sure.
I was thinking the same thing.
> Try adding
>
> use Carp;
> $SIG{__WARN__} = \&Carp::cluck;
>
> to the top of your script, and see if the extra information helps.
Use of uninitialized value within @_ in lc at
C:/Perl/site/lib/Graphics/ColorObject.pm line 1905.
at C:/Perl/site/lib/Graphics/ColorObject.pm line 1905.
Graphics::ColorObject::namecolor(undef) called at
C:/Perl/site/lib/Graphics/ColorObject.pm line 150
Graphics::ColorObject::new('Graphics::ColorObject') called at
C:/Perl/site/lib/Graphics/ColorObject.pm line 197
Graphics::ColorObject::new_RGB('Graphics::ColorObject',
'ARRAY(0x1e83e2c)') called at C:/Perl/site/lib/Graphics/ColorObject.pm
line 279
Graphics::ColorObject::new_HSV('Graphics::ColorObject',
'ARRAY(0x72a71c)') called at G:\Scratch\killme.pl line 12
> PDF supports RGB, and the conversion from HSV to RGB is simple and
> exact (depending on exactly which definition of HSV you want), so you
> might want to consider using RGB colours instead.
I get the same warnings when I convert to RGB. I don't need an exact
conversion. I like to use CMYK when the output is intended to be
printed. But if I don't need an exact conversion, RGB would probably be
just as good a CMYK.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4097
***************************************
