[32833] in Perl-Users-Digest
Perl-Users Digest, Issue: 4098 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Dec 22 06:09:31 2013
Date: Sun, 22 Dec 2013 03:09:05 -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 Sun, 22 Dec 2013 Volume: 11 Number: 4098
Today's topics:
Re: "Use of assignment to $[ is deprecated" means I wil jidanni@jidanni.org
DBI: CREATE USER statement fails <kai@mvps.org.invalid>
Re: DBI: CREATE USER statement fails <rlwinm@sdf.org>
Re: DBI: CREATE USER statement fails <gamo@telecable.es>
Re: DBI: CREATE USER statement fails <kai@mvps.org.invalid>
Re: DBI: CREATE USER statement fails <ben@morrow.me.uk>
PDL Questions - Dec. 21, 2013 <edgrsprj@ix.netcom.com>
Re: PDL Questions - Dec. 21, 2013 <gravitalsun@hotmail.foo>
Re: PDL Questions - Dec. 21, 2013 <edgrsprj@ix.netcom.com>
Re: PDL Questions - Dec. 21, 2013 <edgrsprj@ix.netcom.com>
Re: PDL Questions - Dec. 21, 2013 <gravitalsun@hotmail.foo>
Re: PDL Questions - Dec. 21, 2013 <edgrsprj@ix.netcom.com>
Proposed Modules: Tk::MDTextBook (renamed: Tk::MIMEApp, jimiwills@gmail.com
Re: Syntax understanding problem (Tim McDaniel)
Re: Syntax understanding problem <ben@morrow.me.uk>
Re: 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: Sun, 22 Dec 2013 13:59:26 +0800
From: jidanni@jidanni.org
Subject: Re: "Use of assignment to $[ is deprecated" means I will need to spend all night to update my program
Message-Id: <874n61a0jl.fsf@jidanni.org>
>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
KT> You updated the code at the above URL after posting; it no longer
KT> refers to $[.
KT> The updated code is probably better that it was, but it's not useful
KT> to future readers who are curious about the original problem you
KT> were asking about.
OK sorry. I did not plan ahead. The original version is at
http://web.archive.org/web/20130620210922/http://jidanni.org/astro/programs/jupmoons
The current version at http://jidanni.org/astro/programs/jupmoons
produces about the same results, so I assume my updates didn't break anything.
------------------------------
Date: Sat, 21 Dec 2013 13:37:53 +0100
From: Kai Schaetzl <kai@mvps.org.invalid>
Subject: DBI: CREATE USER statement fails
Message-Id: <VA.000068e4.2e1f85d4@news.conactive.com>
I want to add new users to MySQL with DBI. I've been using DBI and DBD::mysql for years and
adding the user directly to mysql.user and mysql.db. I want to change this method now to
the "official" CREATE USER query syntax.
e.g. CREATE USER '$user'@'localhost' IDENTIFIED BY '$password'
Works fine via mysql in the shell, but fails when using perl.
/testmysqluser.pl testuser4 "testuser4-test"
DBD::mysql::db do failed: String 'testuser4' IDENTIFIED BY ' is too long for user name
(should be no longer than 16) at ./testmysqluser.pl line 19.
This makes no sense as 'testuser4' isn't longer than 16 characters. It looks like DBI tries
to create a user "'testuser4' IDENTIFIED BY '" which would indeed be longer than 16
characters.
This happens on CentOS 5 with MySQL and DBI/DBD provided by the base installation. I tried
several other MySQL versions on other CentOS installations, and a newer DBI version. Same
problem. Also tried with and without the single quotes around the strings, error message
changes only slightly. I was wondering whether the error message was misleading and
actually talks about the password hash length (16->41), but I also get it on systems with
old MySQL passwords.
Am I doing something wrong or is this a DBI or DBD driver problem?
simplified code without variable/parameter fetching:
use DBI;
use DBD::mysql;
$dsn = "dbi:mysql:$mysqldb:localhost:3306";
$dbh = DBI->connect($dsn, $mysqluser, $mysqlpw) or die "Unable to connect: $DBI::errstr\n";
$sql = "CREATE USER '$user'@'localhost' IDENTIFIED BY '$password'";
$sth = $dbh->do($sql);
$dbh->disconnect();
(As I understand I don't have to open the mysql database for "CREATE USER", but I have to
specify a database for the dsn.)
Thanks for hints!
------------------------------
Date: Sat, 21 Dec 2013 14:19:47 +0000 (UTC)
From: Alan Curry <rlwinm@sdf.org>
Subject: Re: DBI: CREATE USER statement fails
Message-Id: <l94822$8iu$1@speranza.aioe.org>
In article <VA.000068e4.2e1f85d4@news.conactive.com>,
Kai Schaetzl <kai@mvps.org.invalid> wrote:
>
>/testmysqluser.pl testuser4 "testuser4-test"
>DBD::mysql::db do failed: String 'testuser4' IDENTIFIED BY ' is too long for user name
>(should be no longer than 16) at ./testmysqluser.pl line 19.
[...]
>
>$sql = "CREATE USER '$user'@'localhost' IDENTIFIED BY '$password'";
>
Notice how the localhost part didn't show up in the error message? That's a
clue. A bigger clue can be seen if you'd just enable warnings:
Possible unintended interpolation of @::localhost in string at - line 4.
Name "main::localhost" used only once: possible typo at - line 4.
To put an @ character in a qq string you need to use \@ or you'll be
interpolating an array.
@'localhost is equivalent to @::localhost because of compatibility with an
ancient perl version that wasn't trying to look like C++.
--
Alan Curry
------------------------------
Date: Sat, 21 Dec 2013 15:28:14 +0100
From: gamo <gamo@telecable.es>
Subject: Re: DBI: CREATE USER statement fails
Message-Id: <l948i7$9r9$1@speranza.aioe.org>
El 21/12/13 13:37, Kai Schaetzl escribi:
> $sql = "CREATE USER '$user'@'localhost' IDENTIFIED BY '$password'";
>
> $sth = $dbh->do($sql);
Are you sure that command is as you think it is?
try inserting a
print "$sql\n";
------------------------------
Date: Sat, 21 Dec 2013 15:57:09 +0100
From: Kai Schaetzl <kai@mvps.org.invalid>
Subject: Re: DBI: CREATE USER statement fails
Message-Id: <VA.000068e5.2e9f0451@news.conactive.com>
Alan Curry schrieb am Sat, 21 Dec 2013 14:19:47 +0000 (UTC):
> To put an @ character in a qq string you need to use \@ or you'll be
> interpolating an array.
Should have known that, thanks for spotting. That happens if you program
just once a year a bit with perl by adjusting your year's old perl scripts
;-) I've also put a "-w" now in my shebang line. Used to do that year's
ago, but not for these scripts.
Have nice holidays!
Kai
------------------------------
Date: Sat, 21 Dec 2013 21:49:05 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: DBI: CREATE USER statement fails
Message-Id: <hvehoa-qhd.ln1@anubis.morrow.me.uk>
Quoth Alan Curry <rlwinm@sdf.org>:
> In article <VA.000068e4.2e1f85d4@news.conactive.com>,
> Kai Schaetzl <kai@mvps.org.invalid> wrote:
> >
> >/testmysqluser.pl testuser4 "testuser4-test"
> >DBD::mysql::db do failed: String 'testuser4' IDENTIFIED BY ' is too
> long for user name
> >(should be no longer than 16) at ./testmysqluser.pl line 19.
> [...]
> >
> >$sql = "CREATE USER '$user'@'localhost' IDENTIFIED BY '$password'";
> >
>
> Notice how the localhost part didn't show up in the error message? That's a
> clue. A bigger clue can be seen if you'd just enable warnings:
>
> Possible unintended interpolation of @::localhost in string at - line 4.
> Name "main::localhost" used only once: possible typo at - line 4.
>
> To put an @ character in a qq string you need to use \@ or you'll be
> interpolating an array.
If the OP had used placeholders and a single-quoted string this problem
would have never existed:
my $sql = 'CREATE USER ?@? IDENTIFIED BY ?';
$dbh->do($sql, undef, $user, "localhost", $password);
This will also avoid potential SQL-injection problems if $password
contains a single-quote character.
> @'localhost is equivalent to @::localhost because of compatibility with an
> ancient perl version that wasn't trying to look like C++.
More specifically, it was trying to look like Ada. It was a bad plan,
most importantly because syntax-highlighters hated it.
Ben
------------------------------
Date: Sat, 21 Dec 2013 10:42:44 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: PDL Questions - Dec. 21, 2013
Message-Id: <MKGdnZku9IpnWSjPnZ2dnUVZ_oqdnZ2d@earthlink.com>
PDL Questions - Dec. 21, 2013
Several of us including a retired computer programmer and I are
gradually developing various science related computer programs. And present
efforts involve selecting the best computer languages for these efforts.
PERL
One of the main Perl language limitations is calculation speed. And
I would be interested in any information that people have on what type of
calculation speed improvements can be made if the PDL module is used with
Perl.
Also, how good is it for graphics?
My current ActiveState Perl based programs will need to be translated
to a newer version so that PDL will run. And some of the presently used
commands will not work with the newest version. But that translation can be
managed if it appears to be worth the effort.
The latest ActiveState version was downloaded and run on a different
computer. And the PDL module was linked with it. But although the PPM
program automatically loaded some support modules that PDL needed it would
apparently not run without some additional types of modifications. So I
could not do any calculation speed or graphics tests using it myself. And I
have not yet had time to try to determine what additional modifications need
to be made to get the PDL module to work.
JULIA
This is another language that is being considered. It appears that
it might be something like a supercharged version of Fortran.
http://julialang.org
Several of us downloaded the program and tried to get it running
without success. And unfortunately there does not appear to be a Julia
language Newsgroup where questions can be asked. So that evaluation effort
is still ongoing.
FORTRAN
One of my programming colleagues has apparently already made the move
from TrueBasic to Fortran. The calculation speed differences between Perl
and TrueBasic and Fortran that he is finding are pretty amazing to me. I
was also surprised to see that there can be considerable differences in
calculation speed with Fortran programs depending on which compiler or IDE
is used. My retired programming colleague tested two called Plato and
Simply Fortran.
For the calculations we are presently running, the Plato generated
code was 4 times faster than the Simply Fortran code and about 35 times
faster than the TrueBasic code. Perl was not checked. But I would
eventually like to compare the Fortran times with PDL module code
calculation times.
People that I have talked with so far don't know too much about the
following. So, these comments are not based on any expert input. And one
or more might be incorrect.
One of standard Fortran's limitations appear to be the fact that it
doesn't have a "sleep" command that will tell it to stop using processor
time and go into a temporary idle mode.
Perl in contrast does have at least two types of sleep commands. And
watching the computer processor work being done in a Windows environment I
can see that Perl does actually stop using all of the processor time when it
goes into a "sleep" type of temporary idle mode.
Also without using special modules Fortran does not have commands
that allow it to easily interact with Windows and active Windows programs.
And special libraries need to be used to get it to do graphics.
It will be interesting to see how the Julia language compares with
Fortran and Perl PDL regarding those topics.
------------------------------
Date: Sat, 21 Dec 2013 19:17:38 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <l94ifl$1g9$1@news.ntua.gr>
Perl is great, but for row calculation power there is only C.
So I think youy core function must me coded in C and use them through
the module Inline::C
------------------------------
Date: Sat, 21 Dec 2013 11:28:03 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <QeydnRQ9h74GUijPnZ2dnUVZ_gKdnZ2d@earthlink.com>
"George Mpouras" <gravitalsun@hotmail.foo> wrote in message
news:l94ifl$1g9$1@news.ntua.gr...
> Perl is great, but for row calculation power there is only C.
http://pdl.perl.org
So far I haven't seen a good explanation of exactly how the PDL
module works. But I am guessing that when Perl is told to run, that module
converts some specially written Perl code to something like C language code.
And then that C (or whatever) code runs instead of having Perl run all of
the Perl code one statement at a time.
------------------------------
Date: Sat, 21 Dec 2013 12:55:28 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <2OOdnVpBVdeBeSjPnZ2dnUVZ_qadnZ2d@earthlink.com>
> "George Mpouras" <gravitalsun@hotmail.foo> wrote in message
> news:l94ifl$1g9$1@news.ntua.gr...
>> Perl is great, but for row calculation power there is only C.
http://julialang.org
Additionally, if you look at the Julia language Web page, there is a
computation benchmark speed chart. And it shows that Julia calculations are
pretty fast. They are roughly good matches with both C and Fortran language
calculation speeds.
Perl PDL calculation speed is not included with that benchmark chart.
Assuming that PDL calculations are much faster than regular Perl language
calculations I personally feel that the Julia people should probably also
run speed tests on the PDL module and add that information to the chart.
And if I had been able to find a contact E-mail address at the Julia Web
site or a Julia Newsgroup I would have already contacted them about that.
------------------------------
Date: Sat, 21 Dec 2013 22:40:30 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <l94ubu$v7n$1@news.ntua.gr>
Στις 21/12/2013 19:28, ο/η E.D.G. έγραψε:
> "George Mpouras" <gravitalsun@hotmail.foo> wrote in message
> news:l94ifl$1g9$1@news.ntua.gr...
>> Perl is great, but for row calculation power there is only C.
>
> http://pdl.perl.org
>
> So far I haven't seen a good explanation of exactly how the PDL
> module works. But I am guessing that when Perl is told to run, that
> module converts some specially written Perl code to something like C
> language code. And then that C (or whatever) code runs instead of having
> Perl run all of the Perl code one statement at a time.
>
are you involved at pdl.perl.org ?
if so, and you want any specific help to translate something to newer
Perl version I could help
------------------------------
Date: Sat, 21 Dec 2013 15:02:04 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <ppmdnQdsWthYnCvPnZ2dnUVZ_jednZ2d@earthlink.com>
"George Mpouras" <gravitalsun@hotmail.foo> wrote in message
news:l94ubu$v7n$1@news.ntua.gr...
> are you involved at pdl.perl.org ?
> if so, and you want any specific help to translate something to newer Perl
> version I could help
Hi George,
Thanks for the offer.
No, I am not involved with Perl PDL development efforts. And I am
somewhat surprised that ActiveState Perl PPM by itself was not able to get
the PDL module to run without some other types of modifications. Usually
PPM works fairly well.
At the moment I don't have time to try to convert my ActiveState Perl
programs to newer versions. And also before attempting that I want to
determine if PDL would make it possible to do calculations and graphic work
faster and easier. If not then efforts will probably shift to translating
all of my Perl programs to some other language such as Fortran or Julia.
Moving to Python does not appear to be a worthwhile effort as Python is also
by itself fairly slow with calculations.
------------------------------
Date: Sun, 22 Dec 2013 02:26:47 -0800 (PST)
From: jimiwills@gmail.com
Subject: Proposed Modules: Tk::MDTextBook (renamed: Tk::MIMEApp, Tk::Markdown, Tk::MarkdownTk)
Message-Id: <298c6274-1ae0-454d-b009-074ba9d1055d@googlegroups.com>
A set of modules that allow easy mixing of code types to be interpretted as
a Tk application...
The input is in MIME-multipart/mixed format, and easy entity can be markdown
(displayed formatted
in a Text with options to add Tk windows and behaviours), perl (eval()ed),
yaml (structure made available
to app) or menu in yaml (posted on main mindow).
The purpose of this is to contribute to a compiled program (for
Windows/Mac/Linux) that can run appended scripts in this format. The reason
for having this format is that resources can be included in the one file.
The Markdown stuff
is to allow easy inclusion of controls in the context of a document.
Tk::MDText - a Tk::Text that displays Markdown with Tk "tags" to include
widgets inline.
Tk::MDTextBook - a Tk::NoteBook that reads multipart document and contructs
an app (using MDTexts)
Tk::MDTextBook::Data2Tk - quick sub to make a window and give <DATA> to
Tk::MDTextBook
Does that make sense to anybody?? Here's an example:
E.g.:
use strict;
use Tk::MDTextBook::Data2Tk; # exports one sub:
data2tk;
__DATA__
MIME Version: 1.0
Content-Type: multipart/mixed; boundary=##--##--##--##--##
Title: Window Title
Here is a prologue
--##--##--##--##--##
Content-Type: application/x-ptk.markdown
Title: _Basic MarkDown
ID: Page1
# MarkDown Tk Text Thingy.
## Here is a sub-header
And a paragraph here
because I wanted to
check that it handles stuff
right over several lines.
--##--##--##--##--##
Content-Type: application/x-ptk.markdown
Title: _Tk and Scripting
ID: Page2
##### Tk windows and scripts
Here is my markdown. Here is some stuff in a preformatted block:
field label <Tk::Entry> <-- put stuff here!
another label <Tk::Entry> ... and more
and so on <Tk::Button -text="Here is some text!">
--##--##--##--##--##
Content-Type: application/x-yaml.menu
---
- _File:
- _Exit: exit
- '---' : '---'
- _Help:
- _About: MyPackage::ShowPreamble
- _Help : MyPackage::ShowEpilog
--##--##--##--##--##
Content-Type: application/x-perl
package MyPackage;
## the most useful of the following will get included in the module
itself...
sub myScriptSub {
print "Hello from script sub!\n";
}
sub getObjectList {
my @shelf = @Tk::MDTextBook::Shelf;
my $object = $shelf[$#shelf]; # get the last one!
return $object->{Objects};
}
sub getMW {
return $Tk::MDTextBook::Data2Tk::MW;
}
sub getPreamble {
return getObjectList()->{Main}->{Preamble};
}
sub getEpilog {
return getObjectList()->{Main}->{Epilog};
}
sub ShowPreamble {
getMW()->messageBox(-message=>getPreamble());
}
sub ShowEpilog {
getMW()->messageBox(-message=>getEpilog());
}
--##--##--##--##--##--
Here is the epilogue
---
[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]
In article <20131220121453.11844.qmail@lists-nntp.develooper.com>,
"Jimi Wills" <???> wrote:
> Tk::MDText - a Tk::Text that displays Markdown with Tk "tags" to include
> widgets inline.
> Does that make sense to anybody?? Here's an example:
The idea sounds interesting and makes sense, but I wonder if there's a
better name for it.
I didn't immediately think of Markdown with MD in this context, but
maybe that doesn't have to be part of the name. The main feature is
including parts in a MIME format, right?
If you still settle on the name you have now, that's fine.
Good luck, :)
--
brian d foy (one of many PAUSE admins), http://pause.perl.org
PAUSE instructions: http://pause.perl.org/pause/query?ACTION=pause_04about
Archives: http://www.xray.mpe.mpg.de/mailing-lists/modules
Please send all messages back to modules@perl.org with no CC to me.
---
> The idea sounds interesting and makes sense, but I wonder if there's a
> better name for it.
Thanks, Brian.
I agree about the names...
> I didn't immediately think of Markdown with MD in this context, but
> maybe that doesn't have to be part of the name. The main feature is
> including parts in a MIME format, right?
how about...
- instead of Tk::MDText...
Tk::Markdown - to display markdown (subset: I'm not going to try to support
inline html!)
Tk::MarkdownTk - a Tk::Markdown that also has the Tk tags functionality...
eg <Tk::Button -text="whatever">
- and instead of MDTextBook...
Tk::MIMEApp - uses MIME multipart to construct an app.
Jimi
---
------------------------------
Date: Sat, 21 Dec 2013 03:20:18 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Syntax understanding problem
Message-Id: <l931di$rdm$1@reader1.panix.com>
In article <0l5foa-te03.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>Apart from that, the scalar comma operator is explicitly intended for
>control flow, just like 'and' and 'if' (and unlike '&&' and '?:').
I see "and", "&&", and "?:" to be entirely equal: one thing is
evaluated, and depending on the result, some other thing(s) may be
evaluated, whatever the precedence (I consider requiting parentheses
or no to be an inessential feature).
As to whether you call it "control flow", it depend on your
definition. I can think of several possible definitions:
- the locus of execution moves outside the statement: next, last,
return, ...
- the locus of execution may skip or repeat the same statement, which
is those plus the postfix statement modifiers
- the flow of execution causes code to be skipped, but may remain in
the same expression, being those plus: and or && || ?:
I suppose one definition might be more useful than another depending
on the discussion, so I'd define the term or avoid it.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sat, 21 Dec 2013 21:41:08 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <kgehoa-qhd.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <0l5foa-te03.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >Apart from that, the scalar comma operator is explicitly intended for
> >control flow, just like 'and' and 'if' (and unlike '&&' and '?:').
>
> I see "and", "&&", and "?:" to be entirely equal: one thing is
> evaluated, and depending on the result, some other thing(s) may be
> evaluated, whatever the precedence (I consider requiting parentheses
> or no to be an inessential feature).
>
> As to whether you call it "control flow", it depend on your
> definition. I can think of several possible definitions:
> - the locus of execution moves outside the statement: next, last,
> return, ...
> - the locus of execution may skip or repeat the same statement, which
> is those plus the postfix statement modifiers
> - the flow of execution causes code to be skipped, but may remain in
> the same expression, being those plus: and or && || ?:
> I suppose one definition might be more useful than another depending
> on the discussion, so I'd define the term or avoid it.
I consider it bad form to use && or ?: to control the execution of code
with side-effects, and very bad form to use them to control those
operators in your first list. In general && and ?: should be evaluated
for their return value, whereas 'and' and 'or' are evaluated for their
side-effects (in causing a piece of code to be executed or not).
Ben
------------------------------
Date: Sat, 21 Dec 2013 11:49:02 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Warnings when using Graphics::ColorObject
Message-Id: <l94nr9$eet$1@dont-email.me>
On 12/20/2013 2:32 PM, Ben Morrow wrote:
> 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.
That is the route I have decided to go.
I found an HSV to RGB conversion algorithm on line, re-wrote it in Perl,
and I am using the resulting RGB values in the PDF file. I will let
Acrobat Reader and/or the system decide how it should be printed.
I appreciate the help you were able to offer.
------------------------------
Date: Sat, 21 Dec 2013 21:06:47 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Warnings when using Graphics::ColorObject
Message-Id: <7gchoa-k6d.ln1@anubis.morrow.me.uk>
Quoth Scott Bryce <sbryce@scottbryce.com>:
> 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
Yep, definitely a bug in Graphics::ColorObject. In fact it's already
been reported nearly three years ago
(https://rt.cpan.org/Public/Bug/Display.html?id=65700), and since the
last entry in the changelog is from 2005 I rather doubt it will be fixed
now. (Unless you feel like volunteering to take over maintainance...)
> > 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.
Since you said 'pie charts' I'm assuming you're targeting a desktop
printer rather than (say) an imagesetter. In that case IME you usually
get better results with RGB, especially in the absence of proper colour
management. Mostly this is because RGB has a larger gamut than CMYK,
which gives whatever does the final conversion down to ink levels
(sometimes this happens in the print driver, sometimes the printer is
sent RGB and does the conversion itself) a better chance of finding a
decent match.
You could try using the functional interface, which doesn't involve the
constructor (which is where the bug is). Alternatively, you could just
copy out the algorithm you want (or, indeed, just get it off Wikipedia).
HSV->RGB is slightly involved but not in any way complicated; the
algorithms used by GCO for RGB->CMY and CMY->CMYK are simple to the
point of being naive. In particular, I would expect that if your print
chain ends up using those CMYK values directly (rather than converting
to RGB and back) that blues would come out much too dark.
Ben
------------------------------
Date: Sun, 22 Dec 2013 01:07:28 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Warnings when using Graphics::ColorObject
Message-Id: <l966kd$di6$1@dont-email.me>
On 12/21/2013 2:06 PM, Ben Morrow wrote:
> Since you said 'pie charts' I'm assuming you're targeting a desktop
> printer rather than (say) an imagesetter.
Yes. I create PDF files that are intended for classroom use. Most of
them are grayscale, but I like to have the option of color sometimes.
> In that case IME you usually get better results with RGB, especially
> in the absence of proper colour management.
This is something I was not aware of.
> Mostly this is because RGB has a larger gamut than CMYK,
That I suspected.
> Alternatively, you could just copy out the algorithm you want (or,
> indeed, just get it off Wikipedia).
I found a Javascript version of an HSV to RBG script on line, which I
re-wrote in Perl. Given your advice, I will use RBG in the PDF file.
It looks like the problem is solved, or, at least, an alternative
without the problem has been found. Thank you for your help!
------------------------------
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 4098
***************************************
