[31131] in Perl-Users-Digest
Perl-Users Digest, Issue: 2376 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 29 16:22:50 2009
Date: Wed, 29 Apr 2009 13:09:13 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 29 Apr 2009 Volume: 11 Number: 2376
Today's topics:
Can't locate object method "dslip_status" <mala@web.de>
Re: Is there a better way to convert foreign characters <hjp-usenet2@hjp.at>
Re: Is there a better way to convert foreign characters <nospam-abuse@ilyaz.org>
Re: Is there a better way to convert foreign characters <noreply@gunnar.cc>
Re: Perl is too slow - A statement <uri@stemsystems.com>
Re: Perl is too slow - A statement <uri@stemsystems.com>
Re: Perl is too slow - A statement <hjp-usenet2@hjp.at>
Re: perl tk - pass function inside button sln@netherlands.com
Re: Posting to perl.beginners via google groups <spamtrap@dot-app.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 29 Apr 2009 21:57:57 +0200
From: Mala Dibbs <mala@web.de>
Subject: Can't locate object method "dslip_status"
Message-Id: <gtabg3$rq7$1@hoshi.visyn.net>
Hi,
i'm trying to install a plugin for Twiki which has an installer script written in perl.
It gives me "Can't locate object method "dslip_status" via package "CPAN::Module" at
tools/extender.pl line 256, <STDIN> chunk 1." before dying.
Is there something wrong with my perl installation?
Greets, mala
------------------------------
Date: Wed, 29 Apr 2009 17:48:08 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrngvgtlo.e01.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-29 10:01, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2009-04-28 16:12, Tim McDaniel <tmcd@panix.com> wrote:
>> What sort of nonsense is that?
>
> The sort of nonsense you when when you don't read postings carefully
> enough.
And this sentence is the sort of nonsense you get when you press the
send button before proof-reading :-(. s/when/get/
hp
------------------------------
Date: Wed, 29 Apr 2009 17:43:40 GMT
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrngvh4r4.j6g.nospam-abuse@chorin.math.berkeley.edu>
On 2009-04-29, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2009-04-28 20:53, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>> On 2009-04-28, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>>> If $value is a byte string and no locale is in effect, lc on a non-ASCII
>>> string is poorly defined.
>>
>> ??? In absense of `use locale', lc should convert to lower-case using
>> Unicode case-conversion tables.
>
> For a byte-string? No, it doesn't, and I think it shouldn't
I'd like to hear the logic behind this...
> You don't know whether an octet is a character.
If lc is applied to a string, it consists of characters.
> For example, IIRC the ISO-2022-JP encoding uses octets in the range
> 0x20-0x7F in multi-byte encodings. If you apply lc (without locale
> information)
So do not... You do not apply lc() to gzipped strings, right? 1/3 ;-)
Yours,
Ilya
------------------------------
Date: Wed, 29 Apr 2009 20:28:23 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <75rkiaF19mtfkU1@mid.individual.net>
Peter J. Holzer wrote:
> On 2009-04-28 16:31, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>> Peter J. Holzer wrote:
>>> (of course I really think you should use character strings if you do
>>> operations on characters, and not muck around with byte strings)
>>
>> So far, I haven't bothered with encoding/decoding when I have been
>> working with Latin-1. Are you saying that encoding/decoding is advisable
>> even if you are not dealing with UTF-8 or some other encoding with wide
>> characters?
>
> Yes.
>
> * Perl knows that a character string is a character string. So matching
> against character classes, lc, uc, etc. works automatically.
> * You don't have to care about the encoding within your program.
> Only for I/O you have to decode/encode, and that can usually be done
> with an I/O-layer. So all the encoding-specific stuff is centralized
> in one place: Where the file is opened.
>
> For me the rule of thumb is
>
> * When you read character data from an external source, decode it
> immediately. If there is an automatic way to do that (I/O layer,
> option for the DBD, etc.) use that.
> * When you write character data to an external source, encode it as
> late as possible. Again, use an automatic way if there is one.
>
> Then, within my program, I know that all character data is in character
> strings and everything "just works" whether the data came from a latin-1
> file or a utf-8 file or database in big-5. And all the byte data (e.g.,
> blobs, images, etc.) is in byte strings, and that also just works.
Thanks for those useful comments, Peter. You gave me something to think
about.
I suppose, though, that your rule of thumb is only applicable as long as
you don't want backwards compatibility with pre 5.8 perl versions.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Wed, 29 Apr 2009 11:23:15 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl is too slow - A statement
Message-Id: <87my9zscv0.fsf@quad.sysarch.com>
>>>>> "MV" == Michael Vilain <vilain@NOspamcop.net> writes:
MV> Yes, companies can just "buy bigger computers" but at some point, that's
MV> a waste. Guess you haven't gotten the memo that companies aren't buying
MV> new systems right now. They want to extend the use of their systems
MV> another couple years. You're don't seem to be bothering enough or care
MV> enough about making something better, which is one of my criteria for
MV> being in programming. It's good know where you stand on the mediocracy
MV> scale. A recent slashdot article on programmers talked about a manager
MV> trying to figure out how to balance out his team. He had a couple
MV> really good code monkeys, about 6 hard working, get-it-done people, and
MV> two wastes of airspace. He wanted to know what to do with those last
MV> two. If he has an opening, maybe you should give him a call.
you don't know where i stand on anything from a stupid usenet
thread. sure you can program better and get more from a cpu. i do that
all the time (as i noted about my cpan modules). it is just that some
people don't know how to do that well or don't get the
cost/effectiveness tradeoffs. and my main point (regardless of budgets)
is that development time is way more expensive than cpu time these
days. and that isn't disputed. that doesn't mean i or someone else can't
or won't write faster code. it just means that you have to look at many
ways get a faster system. i have to have strengths in scaling systems
which is not even programming but more architecture and not a common
skill. but it means i have to think in multiple dimensions including how
many cpus to buy vs how long it would take to code something up. cloud
computing is the latest way to balance this. you can rent cpus by the
minute (history repeating itself) but you need to have a distributed
architecture to take advantage of that.
so stop assuming i only push for more cpu vs better coding. i do both as
needed. but assuming that better development is the only solution for
more speed is just as dumb as the other way around. knowing their true
costs and balancing is the issue.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 29 Apr 2009 11:24:04 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl is too slow - A statement
Message-Id: <87iqknsctn.fsf@quad.sysarch.com>
>>>>> "R" == Ruud <rvtol+usenet@xs4all.nl> writes:
R> Uri Guttman wrote:
>> you don't get it. study some history as i said. computer power is dirt
>> cheap today. cheaper than you realize. developer cost is way more
>> expensive. so buying more/faster computers is usually more economical
>> than hiring more and better developers. of course this isn't always
>> possible but it is a very strong rule of thumb. and note, i am a speed
>> freak coder. most of my cpan modules (id: uri) are about doing things as
>> fast as possible. and they usually succeed. :)
>>
>> for a starter, read the mythical man month.
R> Uri, please stop wasting your precious developer's time on these
R> types, because they will never get it.
R> We could also discuss algorithms that run processes in parallel that
R> wastefully produce overlapping results which are then merged and
R> deduped in order to get the final result much much earlier then when
R> we would let a speed addict touch it. But we can't discuss them if we
R> are too busy implementing them. :)
agreed. 'nuff said.
but my point about reading MMM is still very valid! :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 29 Apr 2009 18:20:59 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl is too slow - A statement
Message-Id: <slrngvgvjd.e01.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-28 16:31, Charlton Wilbur <cwilbur@chromatico.net> wrote:
>>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>
> PJH> If you have a bad SQL join it is completely irrelevant whether
> PJH> you call it from PHP or Perl or C, and whether your PHP/Perl/C
> PJH> code is in turn invoked by a request from Firefox or Opera or
> PJH> IE. All your PHP/Perl/C code will do is wait while the RDBMS is
> PJH> slogging through gigabytes of data, and all your browser will
> PJH> do is wait for your PHP/Perl/C code.
>
> Which touches off another argument: even if you have a *good* SQL join,
> and your database is perfectly tuned, the I/O will still probably take
> an order of magnitude more time than any computation you do with the
> data.
Most of the time, yes. But I've seen cases where a perl process consumed
nearly 100 % CPU time in a loop like this:
while ($r = $sth->fetchrow_arrayref) {
set_bit($r->[0]);
}
Here the database was able to deliver rows a lot faster than perl was
able to process them, even though the processing was rather simple.
hp
------------------------------
Date: Wed, 29 Apr 2009 13:04:42 -0700
From: sln@netherlands.com
Subject: Re: perl tk - pass function inside button
Message-Id: <6o9hv4luc9h8rqm186300b062qo5lajvrb@4ax.com>
On Wed, 29 Apr 2009 01:00:11 GMT, "A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote:
>Slickuser <slick.users@gmail.com> wrote in
>news:a485e5cd-33e4-442d-b2fe-86528369cfea@q33g2000pra.googlegroups.com:
>
>[ don't top post. don't quote sigs. read and follow the posting
>guidelines already ]
>
>> On Apr 28, 2:51 pm, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
>>> Slickuser <slick.us...@gmail.com> wrote in
>>> news:8703c486-548f-44e0-a181-
>>> 95943a5d7...@u39g2000pru.googlegroups.com:
>>>
>>> > I have this generic function to add a button to the main Tk window.
>>> > How do I pass this correction function in when a button is press
>>> > for this Button?
>>>
>>> I can't make sense of this paragraph no matter how many times I read
>>> it.
>>>
>>> > add_button('test a',1,0,\&test_a);
>>> > add_button('test b',1,1,\&test_b);
>>>
>>> > sub add_button ( $$$$)
>>>
>>> Why are you using a prototype?
>>>
>>> > {
>>> > my ($text,$row,$col,$cmd) = @_;
>>> > $main->Button
>>> > (
>>> > -text => $text,
>>> > -command =>\&function_pass
>>> > ## pass in user command?
>>> > ##\&test_a
>>> > ### \&test_b
>>> > )
>>>
>>> Shouldn't you be referring to the fourth argument passed to
>>> add_button (which is in $cmd)? What the heck is function_pass?
>>>
>> I have a lot of buttons and each button have different function call
>> (once clicked).
>>
>> I created a generic sub routine to create the button and grab inputs
>> from method call.
>> Now I want to pass in a "sub routine" so this button will execute the
>> right method call once a button is click.
>
>You still haven't explained what exactly is giving you a problem and why
>you are using prototypes.
>
>I was assuming you understood what function arguments are etc in my
>original response but it looks like that's where the problem lies.
>
>So, is this (not tested) really what you are asking for?
>
>sub add_button {
> my ($text, $row, $col, $cmd) = @_;
>
> $main->Button(
> -text => $text,
> -command => $cmd,
> )->grid(
> -row => $row,
> -column => $col,
> );
>}
What??? I'm not sure you understood his pigeon Engrish. His example code clearly
portray's his intended question. He's looking for a single *pass-through* function
handler for all the buttons he creates in a particular group of buttons.
That is the \&function_pass handler. In the add_button function he is instantiating
a new button. Each call is assigning the same button handler for every new button.
In the add_button function, he is trying to add a parameter to be passed to a common
handler. In this case its a reference to a function. But it could have been anything,
like a pseudo button ID.
When instantiating a Button, the -command parameter expects either a code ref or an
array ref. The latter must have a code ref as the first parameter, then any number of
user, pre-defined arguments that are passed to that function. This emulate's
a sophisticated event driven OS, gui or otherwise, and is just an emulation.
Sometimes develpers want to 'pre-filter' events instead of asigning unique handlers
to each events. Sometimes there is a range of events that need action en-mass like
disabling or enabling or other factored out chores.
This is quite common in event driven OS applications.
-command => $code_ref or [$code_ref, $arg1, $arg2, ...],
And it is quite common to have a single handler for many buttons, needing only the
button ID (pseudo in this case).
I think you are looking at the trees instead of the forest.
There are numerous uses for a common handler in event driven app's.
Even primitive Tk apps.
------------------------
sub function_pass
{
my ($func, $id) = @_;
# do common activities
# ...
# call this specific handler
my $result = $func->();
# do specific activities
# if ($id == 2 && !$result)
# { .. disable a group of controls .. }
}
sub add_button
{
my ($text, $row, $col, $handler, $control_id) = @_;
# instatiate button, set grid
$main->Button (
-text => $text,
-command => [\&function_pass, $handler, $control_id]
)->grid(
-row => $row,
-column => $col,
);
}
sub test_a
{
}
sub test_b
{
}
add_button('test a', 1,0, \&test_a, 1);
add_button('test b', 1,1, \&test_b, 2);
-----------------------
-sln
------------------------------
Date: Wed, 29 Apr 2009 14:20:34 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Posting to perl.beginners via google groups
Message-Id: <m1zldziaod.fsf@dot-app.org>
Nathan Keel <nat.k@gm.ml> writes:
> Good grief, you people will argue about anything
You must be new here! Welcome to usenet. :-)
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 2376
***************************************
