Re: applying patterns
On Wed, Oct 09, 2002 at 05:50:35PM -0400, darren chamberlain said:
I use the one from lib.pm:
nodups = grep { ++$h{$_} == 1 } dups;
using grep is the other idiom/technique/method/pattern/whatever that
I've seen I just have a sort of irrational fear of grep stemming from
when I was first learning Perl and someone more experienced than I told
me that you very rarely ever need to use it and 99% of the time people
use it incorrectly.
It's just one of those habits I've got into.
Anybody else want to criticise my code? ;)
Simon
surprisingly cheery for a cold addled thursday morning
Re: applying patterns
On Wed, Oct 09, 2002 at 09:27:14AM -0700, Randal L. Schwartz said:
Simon == Simon Wistow [EMAIL PROTECTED] writes:
Simpler:
package Singleton;
my $singleton;
sub new { return __PACKAGE__ }
sub ...
A class itself is always a singleton.
Or even
-- code --
package Singleton;
my $a = 1;
sub foo {
return $a++;
}
package main;
my $a = Singleton;
my $b = Singleton;
print $a-foo(),\n;
print $b-foo(),\n;
-- end code --
which prints ...
1
2
Hey! Wait! We could give Perl a slogan! Something about there being
multiple methods to achieve a given task or something :)
Re: applying patterns
On Thu, Oct 10, 2002 at 09:04:34AM +0100, Simon Wistow wrote:
On Wed, Oct 09, 2002 at 05:50:35PM -0400, darren chamberlain said:
I use the one from lib.pm:
nodups = grep { ++$h{$_} == 1 } dups;
using grep is the other idiom/technique/method/pattern/whatever that
I've seen I just have a sort of irrational fear of grep stemming from
when I was first learning Perl and someone more experienced than I told
me that you very rarely ever need to use it and 99% of the time people
use it incorrectly.
I don't understand how anyone can say that any construct is used
incorrectly if the result is the desired one. It may be that they
is a better/different way to solve the problem, but thats what perl
is all about TMTOWTDI.
Graham.
Re: Privacy Laws
On Wed, Oct 09, 2002 at 06:23:20PM +0100, Roger Horne wrote: But neither of you as yet, so far as I am aware, has *amended* versions of the Acts. ie they are stored as originally enacted. This has been... mentioned. Some ideas have been bandied about, though nothing as sophisticated as: The Statute Law Database - http://www.lcd.gov.uk/lawdatfr.htm - will, it is claimed, do this: it will be possible to see what an Act said on any particular day from 1991 onwards. (Sometime. I first saw a demo many years ago when it was said that it would be finished in two years from then. I think that the estimate is still two years.) It's a government IT project. It's a _large_ government IT project. When did one of those _ever_ work? Tasmania seems to have got it right (see http://www.thelaw.tas.gov.au/), but that's a much smaller jurisdiction. Amending up a database of English legislation automatically, rather than manually, would be extremely difficult given our method of legislation. eg a simple transitional provision: Yet another of those problems easily solved with handwaving and strong AI. Roger
Re: Reuse; was: applying patterns
On Wed, Oct 09, 2002 at 07:55:37PM +0100, Marty Pauley wrote: I prefer: use File::Basename; ... my $name = basename $0; since it handles :foo:bar:baz and foo:[bar]baz as full paths. Prewritten modules are better than patterns. The difficulty and the objection as always is what I'm rapidly coming to think of as the mozilla effect. In essence, this is that mozilla has used so many different libraries that each do their one thing well, that what you end up with is having to install some large number of dependencies in the form of various GNOME, and other libraries (that you may well not have installed for anything else), all of which are themselves complex. If I were going to attempt to do a security audit on Mozilla (and I'm not planning to anytime soon), I suspect it would be an even more unpleasant task than unpicking the 600-odd C files in OpenSSL. WRT to CPAN, as a system administrator, you do basically want to maintain the smallest number of independent bits of software on the machines you run, but when a CPAN module depends on several others, each of which depends on several others etc, you can have a potential nightmare on your hands.[1] [1] In this case, I'm counting stuff in the core as part of the core, and not as an independent software package. I'm curious to know what people's solutions are to this problem, as it seems to go against code-reuse. I can only imagine that the right answer is some sort of compromise. -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: applying patterns
On Thu, 10 Oct 2002, Graham Barr wrote: using grep is the other idiom/technique/method/pattern/whatever that I've seen I just have a sort of irrational fear of grep stemming from when I was first learning Perl and someone more experienced than I told me that you very rarely ever need to use it and 99% of the time people use it incorrectly. I don't understand how anyone can say that any construct is used incorrectly if the result is the desired one. It may be that they is a better/different way to solve the problem, but thats what perl is all about TMTOWTDI. I suspect the usage is more about using complicated functions, when there are similar, much more efficient, less fuzzy ways of implementing it. I've seen goto's used in perl, in place of if constructs (so rather than negating the term, if goto's past some code, unless the condition is true) for someone else to understand the code, it might be a little bit more difficult, but in real processor time, I've a feeling that there's not a lot of difference in efficiency[1]. Similarly, foreach, map and grep can do similar jobs, in similar numbers of keystrokes, but with different levels of programming efficiency. And similarly, I can drive a tank, the wrong way up a motorway, even though I've not even got a driving license, and still get to my intended destination. If you're not worried about the rest of the world, then indeed all of these are valid solutions to problems. But when other people are going to interact with your code (either as end users, paying for inefficiencies in terms of performance, or other coders, having to figure out if you're doing something dead clever, or just making it look more complicated than it is) then most of these others will consider them incorrect. the hatter [1] I don't care if you prove me wrong - it's not like I'd ever write it that way. And anyway, this is just an illustration.
Re: Reuse; was: applying patterns
On Thu, Oct 10, 2002 at 10:08:16AM +0100, Lusercop wrote: I'm curious to know what people's solutions are to this problem, as it seems to go against code-reuse. I can only imagine that the right answer is some sort of compromise. A decent packaging system solves the sysadmin side of it. As for the security audit, look at it as auditing the whole system rather than just one application... Roger
Re: Reuse; was: applying patterns
WRT to CPAN, as a system administrator, you do basically want to maintain the smallest number of independent bits of software on the machines you run, but when a CPAN module depends on several others, each of which depends on several others etc, you can have a potential nightmare on your hands.[1] [1] In this case, I'm counting stuff in the core as part of the core, and not as an independent software package. I'm curious to know what people's solutions are to this problem, as it seems to go against code-reuse. I can only imagine that the right answer is some sort of compromise. Generally, when big chunks of code are coming together the name/variable space needs to guarantee uniqueness ... in this way code won't glob over the top of previous code (e.g., Java's packaging system helps to police this due to the assumption about namespaces - in reverse dns order: com.companyname.modulename) Because the namespace resolves to directories and files ... loading and pre-requisite checking can be automated ... in the case of Perl the namespace can't be guaranteed in the same way as Java ... Nige -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: better way to split text into a hash ?
On Wed, 9 Oct 2002, Dave Cross wrote: On Wed, Oct 09, 2002 at 04:23:17PM +0100, Mark Fowler ([EMAIL PROTECTED]) wrote: http://web.archive.org/web/20010512143145/http://www.cookwood.com/cgi-bin/lcastro/perlbbs.pl?read=4700 Lovely. Thanks for that. /me gets all nostalgic I know a song about that. http://www.snurfer.org/text/cookwood_filk.txt -- matt You want evil, I'll give you evil, because nothing is more evil than the truth. - Doc Ellis
Re: Reuse; was: applying patterns
* at 10/10 10:08 +0100 Lusercop said: WRT to CPAN, as a system administrator, you do basically want to maintain the smallest number of independent bits of software on the machines you run, but when a CPAN module depends on several others, each of which depends on several others etc, you can have a potential nightmare on your hands.[1] [1] In this case, I'm counting stuff in the core as part of the core, and not as an independent software package. I'm curious to know what people's solutions are to this problem, as it seems to go against code-reuse. I can only imagine that the right answer is some sort of compromise. I think it's a trade off. Yes there might well be a lot of CPAN modules but surely this is better than having 6 bits of code that all do what $module does that you have to audit individually rather than going, oh yes, that uses $module to do that, that's fine. You then only (!) have to audit the application specific code. Assuming you've audited all the CPAN modules on your system already that is. s
Re: Reuse; was: applying patterns
On Thu, Oct 10, 2002 at 09:15:53AM +, the hatter wrote: This puts me in mind of the extreme programming you're never going to use that essay. A 20 character idiom that works on all the platforms you're planning on it running on can either be used directly, or you can call the Perhaps an indirect side-effect of this approach is that people will see that 20-character idiom and then copy it. Which would be a shame, since it's wrong. (The one posted misses colons as separators, and there are plenty of Macs about that use that, not to mention DOS J: drive prefixes etc.) If people are going to learn by copy/paste then it's preferable surely they copy use Module;... This is probably more relevant, the less the function is used in a project. In the grand scheme of things, if you only process soemthing once, then there's a lot of overhead, and making the change later, should it become necessary, is quick. This makes the big assumption you can find it, and that you know what you're looking for when something mysteriously doesn't work. For example, couple of months back I spent an unholy amount of time debugging some damn tool that hardwired assumptions about its filesystems (hfs,ufs,ext2, etc) so that when a couple of machines were installed with ext3 it failed, but in an unbelievably oblique way. It's time like those you come away frothing just use a frickin' module... Paul -- Paul Makepeace ... http://paulm.com/ If this was any good, then why does he look at me with those shoe-tying eyes. -- http://paulm.com/toys/surrealism/
Re: Reuse; was: applying patterns
On Thu, 10 Oct 2002, Struan Donald wrote:
I think it's a trade off. Yes there might well be a lot of CPAN
modules but surely this is better than having 6 bits of code that all
do what $module does that you have to audit individually rather than
going, oh yes, that uses $module to do that, that's fine.
To my mind, CPAN adds a major advantage in that quote printable $a is
much more readable than the regular expression which is behind that
function (see String::Escape) even though it's moderately trivial.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print$x\n;eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;{$x}(\$x);};};}
foreach my $i (3..65535) { {'2'}($i); }
Re: applying patterns
On Wed, 9 Oct 2002, Marty Pauley wrote:
Hashes in Perl have iterators ('each') but they also provide array-based
You're quite right, TIEHASH is a better example than TIEARRAY for
iterators in Perl.
interfaces using 'keys', 'value', or just list context.
keys is NOT an array-based interface to the hash. It does not even let you
access the hash. It merely executes the iterator and gives you an array
interface to a copy of the data returned by the iterator.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print$x\n;eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;{$x}(\$x);};};}
foreach my $i (3..65535) { {'2'}($i); }
Re: Reuse; was: applying patterns
On Thu, Oct 10, 2002 at 10:26:41AM -0500, Nigel Hamilton wrote: Because the namespace resolves to directories and files ... loading and pre-requisite checking can be automated ... in the case of Perl the namespace can't be guaranteed in the same way as Java ... This is an interesting issue, but not quite what I was getting at. If I have a machine with only an intermittent network connection, for example, or that has no direct net access, then downloading multiple packages can be a hassle. I want to get all the distribution tarballs, and then in each case install that one separately. Now, I know that often it would be insane not to install a lot of this stuff onto a non-net-connected PC, but I can see very good reasons why I might want a PC that is never connected to anything, and having a full CPAN archive is unlikely to be the right answer. Also, a comment raised by a co-worker (also on this list) is that there is also the problem of version incompatibility as code gets changed. This is far more of an issue. I don't know the answers, I don't claim to, but I look at a lot of things and go how many modules do I need to download to get that to work?, though the corollary of they've implemented this and got it wrong is also an obvious problem. I don't think the answer is as easy as use a module and I don't think it's as easy as rewrite it every time. What the answer *is*, however, is the question I'm mainly posing to this list. I don't claim to have it, or even claim that there is an answer, but I'm interested in the insight that this can generate. -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: applying patterns
On Wed, Oct 09, 2002 at 10:44:02PM +, Nicholas Clark wrote:
On Tue, Oct 08, 2002 at 05:49:33PM +0100, Simon Wistow wrote:
Some examples. You want to remove the duplicates from a list. I always
use :
nodups = keys %{{ map { $_ = 1 } dups }};
I didn't always but once I worked it out by myself (or was shown it or
however I learnt it) it was useful to have in my head.
The one I always use (modulo bugs) is something close to
my %hash;
nodups = grep { !$hash{$_}++ } dups
admittedly this uses a temporary hash, so it's not as elegant as yours.
However, thinking about how OPS ARE BAD, I believe the optimal answer is
my %hash;
hash{@dups} = dups;
nopdups = values %hash;
And the 3 laws of optimising are Benchmark, Benchmark, Benchmark
[and we all know what comes after lies and damn lies, so I think that gives
an idea of how reliable this whole game is]
I believe I understand what I'm about to do, and that my analysis is correct:
With more tea, I now disagree with myself. (I thought last night I should
have benchmarked this but still hit send)
Woohoo! No stinking loops.
But, given data that is highly repetitive (all the words in the 5.8
changes file - 546016 works, 33748 unique)
Benchmark: timing 10 iterations of Cookbook, Nick, Simon...
Cookbook: 12 wallclock secs (12.37 usr + 0.01 sys = 12.38 CPU) 0.81/s (n=10)
Nick: 24 wallclock secs (23.65 usr + 0.01 sys = 23.66 CPU) 0.42/s (n=10)
Simon: 31 wallclock secs (31.37 usr + 0.03 sys = 31.40 CPU) 0.32/s (n=10)
s/iterSimon Nick Cookbook
Simon 3.14 -- -25% -61%
Nick 2.37 33% -- -48%
Cookbook 1.24 154% 91% --
Cookbook wins.
OK, so it's probably using less RAM than mine. Lets try something with less
repeated words - all the lines in the current AUTHORS file:
Benchmark: timing 1000 iterations of Cookbook, Nick, Simon...
Cookbook: 5 wallclock secs ( 4.69 usr + 0.00 sys = 4.69 CPU) 213.22/s (n=1000)
Nick: 5 wallclock secs ( 5.35 usr + 0.00 sys = 5.35 CPU) 186.92/s (n=1000)
Simon: 8 wallclock secs ( 7.61 usr + 0.01 sys = 7.62 CPU) 131.23/s (n=1000)
RateSimon Nick Cookbook
Simon131/s -- -30% -38%
Nick 187/s 42% -- -12%
Cookbook 213/s 62% 14% --
Oh. Cookbook still wins.
I'll buy the cookbook.
Wait - I already have
Nicholas Clark
PS I wonder why - possibly time to investigate what the hash slice ops are
actually doing.
PPS I'm sure Dave will argue that there's nothing wrong with having two or
more copies of the same book (preferably his http://www.manning.com/cross/
1 for home, 1 for work, 1 for the reading on the toilet... Makes the
perfect gift for all your friends, family, hamsters...)
Re: applying patterns
On Thursday 10 October 2002 11:05am, Shevek wrote:
On Wed, 9 Oct 2002, Marty Pauley wrote:
Hashes in Perl have iterators ('each') but they also provide array-based
You're quite right, TIEHASH is a better example than TIEARRAY for
iterators in Perl.
Something that overloads is an even better example :-)
--
\|/GET| Dave Hinton
-/SOME| Battersea, London, England
/SLEEP| http://thereaction.co.uk/dah
Re: Testing whether 'use'ing a module throws warnings
On Sunday, October 6, 2002, at 07:06 pm, Kate L Pugh wrote:
[snip]
I wanted a test that's like use_ok, but which fails if any warnings (such
as that below in [0]) come up during the 'use'. But I only wanted it
to fail once, however many warnings I got, and I wanted it to pass (as
opposed to not be run) if I got no warnings. This is what I did:
[snip]
If you can live with two tests (one for the successful use, one for
whether it caused warnings or not) you can use Test::Warn to produce
something quite readable. For example:
use strict;
use Test::More tests = 2;
use Test::Warn;
BEGIN {
warnings_are { use_ok('My::Module') } [], My::Module raised no
warnings;
};
Cheers,
Adrian
Re: Plea: A funky deparse?
On Thu, 10 Oct 2002, Rafiq Ismail wrote:
Does anyone know of a a way to isolate code fragments/methods of only
those fragments of codes which get invoked by a script.
Isn't this traditionally the job of the code profiler?
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print$x\n;eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;{$x}(\$x);};};}
foreach my $i (3..65535) { {'2'}($i); }
Re: Plea: A funky deparse?
On Thu, 10 Oct 2002, Shevek wrote: On Thu, 10 Oct 2002, Rafiq Ismail wrote: Does anyone know of a a way to isolate code fragments/methods of only those fragments of codes which get invoked by a script. Isn't this traditionally the job of the code profiler? I'm working on a convoluted site with lots of do's and require's and the big problem with -MO=Deparse is that it will neatly do what is expected with used libs, however when it comes to the do's on scripts it will import every method in the script. I don't want 'every' method in my readable version, thus I'd like a way for the output to be filtered by only those subroutines which actually get invoked. Any ideas? Cheers, Rafiq -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: Plea: A funky deparse?
Shevek said: On Thu, 10 Oct 2002, Rafiq Ismail wrote: Does anyone know of a a way to isolate code fragments/methods of only those fragments of codes which get invoked by a script. Isn't this traditionally the job of the code profiler? Or more specifically, a code coverage tool. And I just happen to have one of those sitting in my CPAN directory :-) Actually, Devel::Cover is probably not only overkill for this, but you'll also have to work fairly hard to get what you want. I have considered adding subroutine coverage a number of times, as the new weakest form of coverage available. Maybe I should actually do that. In any case, hacking Devel::Coverage to bits will get you what you want. Actually, what is it you want? To automatically create a program/module with only the bits you need? To manually do the same? Something else? I had assumed the former, but in that case, why? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Plea: A funky deparse?
On Thu, 10 Oct 2002, Paul Johnson wrote: Shevek said: On Thu, 10 Oct 2002, Rafiq Ismail wrote: Does anyone know of a a way to isolate code fragments/methods of only those fragments of codes which get invoked by a script. Isn't this traditionally the job of the code profiler? Or more specifically, a code coverage tool. And I just happen to have one of those sitting in my CPAN directory :-) Super! I just looked at the output of Devel::DProf and am thinking of using the methods highlighted by that that to filter the the output of the Deparse. In any case, hacking Devel::Coverage to bits will get you what you want. Ok, I'll look at that. Actually, what is it you want? To automatically create a program/module with only the bits you need? To manually do the same? Something else? I had assumed the former, but in that case, why? The former, since I have to rewrite code which uses lots of do's, with global variables, importing all methods into main:: and willynilly calling methods in other scripts which were also do'ed. It's proving a nightmare to find what's what and where. There are long chains of calls going all over the place from one script to another and back, all in the same package space. I need to isolate these so that I can rewrite the scripts, modularise and .. etc, etc. Pitty me. -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
[JOB] Senior OO Perl Developer
Vacancy: Senior OO Perl Developer Senior OO Perl Developer required with the following key skills and experience: 1.)4 years + OO Perl developement experience. 2.)Unix skills. 3.)An excellent understanding of Internet protocols. web services, and core back-end technology development. 4.)RDBMS, Perl DBI and HTML skills. 5.)Experience within a very high-volume website environment. 6.)Knowledge of Template Toolkit, MySQL, Oracle and UML advantageous. Job Type: Permanent Location: London, South East Start Date Asap Duration 2 years Salary 40,000 Ref No 14246-VP2-21272-GCS Date Advertised 10 Oct 2002 Cliveden Recruitment Plc (S-oton) 023 8022 9094 (T) 023 8022 0326 (F) IT Department -- S. Joel Bernstein :: joel at fysh dot org :: t: 020 8458 2323 Nobody is going to claim that Perl 6's OO is bolted on. Well, except maybe for certain Slashdotters who don't know the difference between rational discussion and cheerleading... -- Larry Wall
