[31509] in Perl-Users-Digest
Perl-Users Digest, Issue: 2768 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 15 00:09:42 2010
Date: Thu, 14 Jan 2010 21:09:08 -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 Thu, 14 Jan 2010 Volume: 11 Number: 2768
Today's topics:
Re: a defense of ad hoc software development <kentilton@gmail.com>
Re: a defense of ad hoc software development <barmar@alum.mit.edu>
Re: converting from 'use' to 'require' <ben@morrow.me.uk>
How to subclass Log::Log4perl::Appender and Log::Dispat <glex_no-spam@qwest-spam-no.invalid>
Re: Perl module to display MIME email in browser? <OJZGSRPBZVCX@spammotel.com>
Re: Perl module to display MIME email in browser? <ben@morrow.me.uk>
Programs with Inline::C suddenly fail to compile <jl_post@hotmail.com>
Re: Programs with Inline::C suddenly fail to compile <ben@morrow.me.uk>
Re: Programs with Inline::C suddenly fail to compile <jl_post@hotmail.com>
Re: Programs with Inline::C suddenly fail to compile <ben@morrow.me.uk>
Re: some perl programs I wrote <jurgenex@hotmail.com>
Re: some perl programs I wrote (Jens Thoms Toerring)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 14 Jan 2010 20:25:33 -0500
From: Kenneth Tilton <kentilton@gmail.com>
Subject: Re: a defense of ad hoc software development
Message-Id: <4b4fc408$0$31257$607ed4bc@cv.net>
Richard McBeef wrote:
> ccc31807 wrote:
> [snip]
>> Comments?
> Yeah, Paul Graham is a total b.s. artist.
> Besides a prolific author of internet screeds
> he wrote some successful software a long time ago.
> Oh, and I do not deny he is a lisp expert.
> But, yeah, PG is full of shit and his bazillion
> bullshit essays all have the same annoying
> common theme "I'm the best! Be like me!".
No, he's pretty good and a very nice guy, too. No b.s., unless by b.s.
you mean anything you disagree with. That is my definition, too!
kt
--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
------------------------------
Date: Thu, 14 Jan 2010 21:44:15 -0500
From: Barry Margolin <barmar@alum.mit.edu>
Subject: Re: a defense of ad hoc software development
Message-Id: <barmar-29EDDA.21441514012010@news.eternal-september.org>
In article <hinusa$bt$1@speranza.aioe.org>,
Richard McBeef <cho.seung-hui@vt.edu> wrote:
> ccc31807 wrote:
> [snip]
> > Comments?
> Yeah, Paul Graham is a total b.s. artist.
> Besides a prolific author of internet screeds
> he wrote some successful software a long time ago.
> Oh, and I do not deny he is a lisp expert.
> But, yeah, PG is full of shit and his bazillion
> bullshit essays all have the same annoying
> common theme "I'm the best! Be like me!".
That may be true, but what he says in this particular article is
correct. Read the book "Coders at Work", and you'll learn that most of
the great programmers think similarly. Programming simply cannot be
mechanized. Writing specifications precise enough to be validated
mechanically *is* programming.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
------------------------------
Date: Fri, 15 Jan 2010 00:24:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: converting from 'use' to 'require'
Message-Id: <k6p427-kqr.ln1@osiris.mauzo.dyndns.org>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <op.u6jephrjmk9oye@frodo>, on 01/14/2010
> at 08:21 PM, "Jochen Lehmeier" <OJZGSRPBZVCX@spammotel.com> said:
>
> >You do not need an eval with require to make it conditional. require is
> >not executed at compile time.
>
> Thanks; I was looking at some code in bwWhois and misread the intent; the
> eval is actually there to trap errors, not to avoid compile-time
> processing.
The idiom
eval "require $module"
does two things: it catches exceptions thrown by the module (which could
just as well have been done with eval BLOCK) and it allows you to pass a
module name like "Foo::Bar" without having to transform it into
"Foo/Bar.pm". (There is some confusion in the docs for require about
that transformation: it always occurs like that, with slashes,
regardless of platform; and require at least always understands paths
with slashes in.)
Ben
------------------------------
Date: Thu, 14 Jan 2010 17:29:16 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: How to subclass Log::Log4perl::Appender and Log::Dispatch::DBI
Message-Id: <4b4f9e50$0$1335$815e3792@news.qwest.net>
I'm trying the following, to test if I can log to Oracle,
and am getting an error of:
Use of uninitialized value in numeric gt (>) at
/usr/lib/perl5/site_perl/5.8.5/Log/Log4perl/Appender.pm line 160.
Can't use string ("level") as a HASH ref while "strict refs" in use at
/usr/lib/perl5/site_perl/5.8.5/Log/Log4perl/Appender.pm line 187.
Log::Log4perl::Appender::log(/usr/lib/perl5/site_perl/5.8.5/Log/Log4perl/Appender.pm:156):
156: my ($self, $p, $category, $level) = @_;
DB<1> n
Log::Log4perl::Appender::log(/usr/lib/perl5/site_perl/5.8.5/Log/Log4perl/Appender.pm:160):
160: if($self->{level} > $
161: Log::Log4perl::Level::PRIORITY{$level}) {
DB<1> print $level
message
and $Log::Log4perl::Level::PRIORITY{'debug'} is undefined,
so I must be doing something wrong.
use Logger;
my $log = Logger->new();
# eventually want to use config file too..
# $log->init( 'dbi.conf' ); or Log::Log4perl::init( 'dbi.conf' );
for my $mth ( qw( debug info warn error fatal ) )
{
$log->log( level => $mth, message => "Testing $mth" );
}
#-----
package Logger;
use base qw( Log::Log4perl );
sub new
{
my $class = shift;
my $dbh = getmyownconnection(); #from DBI->connect
my $self = Log::Log4perl::Appender->new(
'Log::Dispatch::DBI',
name => 'dbi',
dbh => $dbh,
table => 'my_log'
);
return $self;
}
1;
Essentially I want a class that will connect to the correct database
and write to the correct table, in Oracle. Connecting to the DB is
Ok, but subclassing this isn't working the way I thought.
I also need to over-ride create_statement and log_message, but
that looks pretty simple.
I have found examples of other Log::Dispatch classes, but haven't
found anything that shows how to do it with ::DBI.
------------------------------
Date: Fri, 15 Jan 2010 01:34:20 +0100
From: "Jochen Lehmeier" <OJZGSRPBZVCX@spammotel.com>
Subject: Re: Perl module to display MIME email in browser?
Message-Id: <op.u6js7i0dmk9oye@frodo>
On Thu, 14 Jan 2010 23:08:29 +0100, Henry Law <news@lawshouse.org> wrote:
> Anyone done this, or something similar, who could point me in the right
> direction?
I have used the MIME-tools package to parse MIME mails, get at the
attachments, traverse the "MIME part" trees etc.; also to create new MIME
messages, but that doesn't matter for your requirements.
Nothing except the standard MIME package was needed, together with its
documentation. It's pretty well fleshed out.
> Otherwise it's more heroic coding at dead of night ...
I'd say so. I've not rendered a mail in HTML yet, but I don't think it
should be that hard. MIME parts can be recursive, and so is HTML. Just go
from part to part, recursing as necessary, and output it in HTML (e.g., a
text/html part is output as is; a raw text part is output with "<pre>"
etc., and for an attachment, just output the link or whatever you see fit).
The immediate goal should be to read the mail from the DB, parse it into a
MIME::Entity, and go on from there.
To get you started,
http://search.cpan.org/~doneill/MIME-tools-5.427/lib/MIME/Tools.pm should
be more than sufficient.
------------------------------
Date: Fri, 15 Jan 2010 01:49:41 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl module to display MIME email in browser?
Message-Id: <l6u427-fcs.ln1@osiris.mauzo.dyndns.org>
Quoth "Jochen Lehmeier" <OJZGSRPBZVCX@spammotel.com>:
>
> I'd say so. I've not rendered a mail in HTML yet, but I don't think it
> should be that hard. MIME parts can be recursive, and so is HTML. Just go
> from part to part, recursing as necessary, and output it in HTML (e.g., a
> text/html part is output as is; a raw text part is output with "<pre>"
> etc., and for an attachment, just output the link or whatever you see fit).
Be very careful. The HTML in an email is untrusted, and needs to be
sanitised before serving it from your webserver. Otherwise there is a
good chance the HTML might contain some JavaScript that does something
nasty.
The OP is right to be looking for a premade solution to this problem;
unfortunately I don't know of one in Perl.
Ben
------------------------------
Date: Thu, 14 Jan 2010 15:14:30 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Programs with Inline::C suddenly fail to compile
Message-Id: <be855cde-a7c4-4867-a81d-ef9366cc5e68@c3g2000yqd.googlegroups.com>
Hi,
Last month I was tinkering around with the Inline::C module. I
even posted a small program to comp.lang.perl.misc with the subject
"Curious benchmark results with Inline::C". (If you want to see it,
you can find it at:
http://groups.google.com/group/comp.lang.perl.misc/msg/920c641d68dd4910?dmode=source
)
Today I've gone back to that script and modified it a little. The
problem is, any change I make to the C code makes the code no longer
compile. If I leave the code untouched, then the script runs just
fine, but as soon as I make a small change (such as insert a space
somewhere), or even copy the script to a separate directory and run it
there, I get compiler errors.
For example, if I copy the "extra_function_c.pl" (found in the post
I referenced above) to my D:\tmp directory, cd to that directory, and
type:
perl extra_function_c.pl
I see the following output:
=== BEGIN OUTPUT ===
C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils
\xsubpp -typemap C:\strawberry\perl\lib\ExtUtils\typemap
extra_function_c_pl_850b.xs > extra_function_c_pl_850b.xsc && C:
\strawberry\perl\bin\perl.exe -MExtUtils::Command -e mv
extra_function_c_pl_850b.xsc extra_function_c_pl_850b.c
gcc -c -ID:/tmp -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -
DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -
DPERL_MSVCRT_READFIX -s -O2 -DVERSION=\"0.00\" -DXS_VERSION=
\"0.00\" "-IC:\strawberry\perl\lib\CORE" extra_function_c_pl_850b.c
Running Mkbootstrap for extra_function_c_pl_850b ()
C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e chmod 644
extra_function_c_pl_850b.bs
C:\strawberry\perl\bin\perl.exe -MExtUtils::Mksymlists \
-e "Mksymlists('NAME'=>\"extra_function_c_pl_850b\", 'DLBASE' =>
'extra_function_c_pl_850b', 'DL_FUNCS' => { }, 'FUNCLIST' => [],
'IMPORTS' => { }, 'DL_VARS' => []);"
dlltool --def extra_function_c_pl_850b.def --output-exp dll.exp
'dlltool' is not recognized as an internal or external command,
operable program or batch file.
dmake: Error code 129, while making 'blib\arch\auto
\extra_function_c_pl_850b\extra_function_c_pl_850b.dll'
A problem was encountered while attempting to compile and install your
Inline
C code. The command that failed was:
dmake > out.make 2>&1
The build directory was:
D:\tmp\_Inline\build\extra_function_c_pl_850b
To debug the problem, cd to the build directory, and inspect the
output files.
at extra_function_c.pl line 4
BEGIN failed--compilation aborted at extra_function_c.pl line 74.
=== END OUTPUT ===
It seems as though the problem starts around this line:
'dlltool' is not recognized as an internal or external command,
operable program or batch file.
I checked the C:\strawberry directory tree and no file named
dlltool.* appears to exist. Just in case it mysteriously disappeared
from my platform, I checked someone else's Strawberry Perl
installation, and he doesn't have it either.
Incidentally, I cd'ed to D:\tmp\_Inline\build
\extra_function_c_pl_850b and ran "dmake", and this is what I saw:
dlltool --def extra_function_c_pl_850b.def --output-exp dll.exp
'dlltool' is not recognized as an internal or external command,
operable program or batch file.
dmake: Error code 129, while making 'blib\arch\auto
\extra_function_c_pl_850b\extra_function_c_pl_850b.dll'
So it does seem likely that it's failing because "dlltool" can't be
found.
I'm puzzled here. Why did this program work just fine last month,
and today it's trying to run "dlltool", a program that seems to have
never existed in my Strawberry Perl installation in the first place?
Does anyone know how to get Inline::C working for me again? (I
reinstalled it with "cpan -fi Inline::C" but it didn't make any
difference.)
Thanks.
-- Jean-Luc
------------------------------
Date: Fri, 15 Jan 2010 00:41:53 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Programs with Inline::C suddenly fail to compile
Message-Id: <h7q427-h5s.ln1@osiris.mauzo.dyndns.org>
Quoth "jl_post@hotmail.com" <jl_post@hotmail.com>:
>
[Inline::C]
>
> Today I've gone back to that script and modified it a little. The
> problem is, any change I make to the C code makes the code no longer
> compile. If I leave the code untouched, then the script runs just
> fine, but as soon as I make a small change (such as insert a space
> somewhere), or even copy the script to a separate directory and run it
> there, I get compiler errors.
This is a red herring. Inline::C checksums your source and skips the
recompile if it's unchanged, so your old script isn't getting recompiled
at all. If you clear out D:\tmp\_Inline you'll find the old script stops
working too (which is actually a step forward, even though it may not
seem like it).
> For example, if I copy the "extra_function_c.pl" (found in the post
> I referenced above) to my D:\tmp directory, cd to that directory, and
> type:
>
> perl extra_function_c.pl
>
> I see the following output:
>
> === BEGIN OUTPUT ===
<snip>
> dlltool --def extra_function_c_pl_850b.def --output-exp dll.exp
> 'dlltool' is not recognized as an internal or external command,
> operable program or batch file.
> dmake: Error code 129, while making 'blib\arch\auto
> \extra_function_c_pl_850b\extra_function_c_pl_850b.dll'
>
> A problem was encountered while attempting to compile and install your
> Inline
> C code. The command that failed was:
> dmake > out.make 2>&1
>
> The build directory was:
> D:\tmp\_Inline\build\extra_function_c_pl_850b
<snip>
>
> I checked the C:\strawberry directory tree and no file named
> dlltool.* appears to exist. Just in case it mysteriously disappeared
> from my platform, I checked someone else's Strawberry Perl
> installation, and he doesn't have it either.
>
> Incidentally, I cd'ed to D:\tmp\_Inline\build
> \extra_function_c_pl_850b and ran "dmake", and this is what I saw:
>
> dlltool --def extra_function_c_pl_850b.def --output-exp dll.exp
> 'dlltool' is not recognized as an internal or external command,
> operable program or batch file.
> dmake: Error code 129, while making 'blib\arch\auto
> \extra_function_c_pl_850b\extra_function_c_pl_850b.dll'
>
> So it does seem likely that it's failing because "dlltool" can't be
> found.
>
> I'm puzzled here. Why did this program work just fine last month,
> and today it's trying to run "dlltool", a program that seems to have
> never existed in my Strawberry Perl installation in the first place?
Have you upgraded ExtUtils::MakeMaker in the meanwhile, or any other
toolchain modules? AFAICT from the version of EU::MM_Win32 I have here
(6.55_02) it always invokes dlltool if you are using gcc, and AFAICT
from gitPAN this was present in 5.47, so I don't know what was happening
before.
> Does anyone know how to get Inline::C working for me again? (I
> reinstalled it with "cpan -fi Inline::C" but it didn't make any
> difference.)
Well, you could always find a copy of dlltool (I presume it's part of
GNU binutils for Win32) and put it in strawberry\c\bin.
Ben
------------------------------
Date: Thu, 14 Jan 2010 18:00:38 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Programs with Inline::C suddenly fail to compile
Message-Id: <e6306003-523c-4e66-b891-7f45f34a03d5@j14g2000yqm.googlegroups.com>
On Jan 14, 5:41 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Have you upgraded ExtUtils::MakeMaker in the meanwhile,
> or any other toolchain modules?
No, I haven't, although since you mentioned it, I tried re-
installing it with:
cpan -fi ExtUtils::MakeMaker
but that didn't seem to change anything. I finally got it working,
though, with your next suggestion:
> Well, you could always find a copy of dlltool
> (I presume it's part of GNU binutils for Win32)
> and put it in strawberry\c\bin.
I checked, and dlltool.exe was not in my GNU unix utilities for
Win32 (I'm not sure... is that the same as GNU binutils?). However, I
did a "find2perl" search on C:\ and eventually found dlltool.exe in C:
\Program Files\GCL-2.6.7-ANSI\mingw\mingw32\bin , so I copied it to C:
\strawberry\c\bin (the directory where gcc.exe resides).
This solved the problem! My Inline::C programs now compile.
Of course, I'm still puzzled as to why I could compile with no
problems last month and today I got errors relating to not finding
dlltool.exe . I don't recall ever installing mingw (perhaps
installing Strawberry Perl or Inline::C did it for me), but maybe the
mingw bin directory was in my path and somehow got removed recently.
> Inline::C checksums your source
> and skips the recompile if it's unchanged, so your old
> script isn't getting recompiled at all. If you clear out
> D:\tmp\_Inline you'll find the old script stops working
> too (which is actually a step forward, even though it may
> not seem like it).
Makes sense, as it would explain why there's multiple copies of
programs in the _Inline\lib\auto directory. This brings up the
question: If I modify the C code 20 times and run it after each
modification, will I have 20 cached programs in the _Inline
directory? Do the old cached programs ever go away, or do they
essentially stay around forever?
Anyway, thanks a million for your help, Ben.
-- Jean-Luc
------------------------------
Date: Fri, 15 Jan 2010 02:52:21 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Programs with Inline::C suddenly fail to compile
Message-Id: <5s1527-9js.ln1@osiris.mauzo.dyndns.org>
Quoth "jl_post@hotmail.com" <jl_post@hotmail.com>:
> On Jan 14, 5:41 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > Well, you could always find a copy of dlltool
> > (I presume it's part of GNU binutils for Win32)
> > and put it in strawberry\c\bin.
>
> I checked, and dlltool.exe was not in my GNU unix utilities for
> Win32 (I'm not sure... is that the same as GNU binutils?).
I don't know... there are several packages floating around calling
themselves 'Unix utilities for Win32'. binutils is the GNU package that
contains ar, ld, gas etc., including (on Win32) dlltool.
> However, I
> did a "find2perl" search on C:\ and eventually found dlltool.exe in C:
> \Program Files\GCL-2.6.7-ANSI\mingw\mingw32\bin , so I copied it to C:
> \strawberry\c\bin (the directory where gcc.exe resides).
>
> This solved the problem! My Inline::C programs now compile.
>
> Of course, I'm still puzzled as to why I could compile with no
> problems last month and today I got errors relating to not finding
> dlltool.exe . I don't recall ever installing mingw (perhaps
> installing Strawberry Perl or Inline::C did it for me), but maybe the
> mingw bin directory was in my path and somehow got removed recently.
Strawberry includes a copy of mingw gcc and binutils in strawberry\c
(that's the whole point). What I don't understand is why dlltool wasn't
there: I wonder if it was originally, and it got deleted somehow? If you
have time you might want to move aside your current Strawberry
installation and reinstall, to see if that includes dlltool.
> > Inline::C checksums your source
> > and skips the recompile if it's unchanged, so your old
> > script isn't getting recompiled at all. If you clear out
> > D:\tmp\_Inline you'll find the old script stops working
> > too (which is actually a step forward, even though it may
> > not seem like it).
>
> Makes sense, as it would explain why there's multiple copies of
> programs in the _Inline\lib\auto directory. This brings up the
> question: If I modify the C code 20 times and run it after each
> modification, will I have 20 cached programs in the _Inline
> directory? Do the old cached programs ever go away, or do they
> essentially stay around forever?
I don't know (perldoc Inline doesn't mention the issue) but I rather
suspect they stay around for ever. I just checked ~/.Inline on this
machine, and I still have build directories hanging around from 2003
that I haven't touched since. All this is part of the reason I don't
really like Inline.
Ben
------------------------------
Date: Thu, 14 Jan 2010 15:33:31 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: some perl programs I wrote
Message-Id: <i2avk5d38e3nn5fui5ld901e4k4u86ddv6@4ax.com>
Ralph Malph <ralph.malph@altavista.com> wrote:
>Uri Guttman wrote:
>Oh, and if you were bothered by Uri's comments
>then please do not worry. He is a morbidly obese
>shut in. One of the aforementioned jaded losers.
>Nobody has seen him in months...his
>doorways are now far to narrow to allow him out.
>Even if he turns sideways.
>I must hand it to him though, it is quite a novel
>way to fight foreclosure!
Considering that your posting history in this NG is very short, none of
your postings had any Perl-related content whatsoever, and almost all
are attacks on Uri, who on the otherhand is a long-standing well
respected member of CLPM I in your place would be very careful with such
libel and defamation. It not only puts you in a very poor light, it also
exposes you to legal actions.
jue
------------------------------
Date: 15 Jan 2010 01:03:36 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: some perl programs I wrote
Message-Id: <7r9t78Fe0nU1@mid.uni-berlin.de>
Robin <robin1@cnsp.com> wrote:
> check out some of my perl programs,
> http://offlame.memebot.com
> let me know if you like them.... :-)
I unfortunately have to agree with others here that didn't
like your code - but I only looked at the program for gene-
rating prime numbers and the "text editor" yet. And both are
not winners... Here's the one for generating prime numbers:
1 #!/usr/bin/perl
2 use strict;
3 my $npflag = 0;
4 my $n;
5 my @z;
6 print "Prime number generator starting at 3 and going up....\n";
7
8 foreach my $q (4 .. 10000) {
9 $npflag = 0;
10 foreach my $m (1 .. $q) {
11 next if $m == 1;
12 next if $m == $q;
13 $_ = "$q" / "$m";
14 if ($_ !~ /\./) {
15 $npflag = 1;
16 }
17 }
18
19 if (! $npflag) {
20 print "We have found prime : $q\n";
21 sleep 1;
22 }
23 }
Lets forget about the unused variables and that kind of stuff.
a) What you print out in line 6 isn't correct, you start with 4,
and not with 3 as you claim.
b) Including even numbers in checks for primes is a strange idea,
they are simple to avoid and are never prime (except 2;-)
c) Starting with $m set to 1 in line 10 and then checking in
line 11 that $m is not 1 is very strange, to say the least.
d) The same holds for going up to $q and then checking that $m
isn't $q.
e) Going up to $q instead of it's square root shows that you
should do a bit more research on prime numbers before you
atart writing programs to find primes.
f) The double quotes in line 13 indicate that you don't well
understand really what they are used for in Perl.
g) Using '$_' as a variable looks to me as bad as you can get.
h) Using a regex to check if a number can be divided by another
one is, to say the least, strange ("inefficent" doesn't cover
it appropriately).
And then, even if you remove the call to sleep(), it's slow as
molasses. Take the following program, that does logically more
or less the same as yours (using the same rather uneducated al-
gorithm):
#!/usr/bin/perl
use strict;
use warnings;
print "Prime number generator starting at 3 and going up....\n";
NOT_A_PRIME:
for ( my $q = 3; $q <= 10000; $q += 2 ) {
for ( my $m = 3; $m <= sqrt( $q ); $m += 2 ) {
next NOT_A_PRIME unless $q % $m;
}
print "We have found prime : $q\n";
}
It's about a factor of 2000 faster (sorry, that's only a very
rough guess - the updated version seems to spent most CPU time
on getting Perl to run and interpret it instead of doing any
real computations), and that with just a very few changes, using
a tiny bit of knowledge about prime numbers. What you may take
from this is: Look for a good algorithm (the one in my somewhat
faster version is definitely not a good one, already the ancient
Greeks, more than 2000 years ago, had a better one, look up the
"Sieve of Eratosthenes")... But even with a bad algorithm you
often can get much better performance if you think about it just
a tiny bit.
Concerning your "text editor": You didn't write a text editor.
You just use Perl TK widgets for all the hard work, so you're
using code that others have written that allows to input text,
select files etc. and there's nothing original you have done
there. Saying "I wrote a text editor" is, in this case, like
claiming "I build a car" because you just managed to start the
engine of a car someone gave you the keys to. And then it's not
even done very well, you could easily cut it down to nearly half
the code size (and thus make it easier to maintain) by not repea-
ting the nearly identical code in the functions savetop() and
savebottom(). Perhaps you should try to figure out how to pass
arguments to Perl Tk callback functions - it's actually not
that complicated...
I guess that you're rather young (from your code I would assume
that, while you're clever, you're not much more than about 14
year old) and, if that's the case, don't despair just because of
a bit of criticism. It simply takes time to learn things. Others
have already spent 10 or 20 years longer on it and you would have
to be an absolute genius to be better at such a very youg age.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
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 2768
***************************************
