[29475] in Perl-Users-Digest
Perl-Users Digest, Issue: 719 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 4 09:09:46 2007
Date: Sat, 4 Aug 2007 06:09:10 -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 Sat, 4 Aug 2007 Volume: 11 Number: 719
Today's topics:
Re: A perl issue when execute system call <Joseph.Trapasso@gmail.com>
new CPAN modules on Sat Aug 4 2007 (Randal Schwartz)
Re: Perl and Sockets <joe@inwap.com>
Re: Prototypes/Parameters to a Function/Sub-Routine anno4000@radom.zrz.tu-berlin.de
Re: Q on localizing *STDOUT and fork <nobull67@gmail.com>
Re: Q on localizing *STDOUT and fork <nobull67@gmail.com>
Re: Using DBI, better option than importing into @array <hjp-usenet2@hjp.at>
Re: Using DBI, better option than importing into @array <hjp-usenet2@hjp.at>
Re: Using DBI, better option than importing into @array <hjp-usenet2@hjp.at>
Re: Using DBI, better option than importing into @array <hjp-usenet2@hjp.at>
Re: Windows based perl editor? <bill@ts1000.us>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 04 Aug 2007 08:57:22 -0000
From: "Joseph.Trapasso@gmail.com" <Joseph.Trapasso@gmail.com>
Subject: Re: A perl issue when execute system call
Message-Id: <1186217842.130509.29670@g12g2000prg.googlegroups.com>
On Jul 23, 6:10 am, jeanwelly <jeanwe...@gmail.com> wrote:
> On Jul 20, 11:51 pm, jeanwelly <jeanwe...@gmail.com> wrote:
>
>
>
> > Hi Glenn,
> > Actually I was using `which upd` to got the full datapath of clearcase
> > bin/upd command, when I debug, I found similar hang issue of `which
> > whois`, due to different server setup, I can't rely on the PATH to
> > tell where is the bin/upd.
>
> > The interesting thing is in SUN server1 I have the issue, but no in
> > SUN server2, and the two with same kernel version and perl verison.
>
> > On 7 20 , 10 27 , Glenn Jackman <gle...@ncf.ca> wrote:
>
> > > At 2007-07-20 07:05AM, "jeanwelly" wrote:
>
> > > > > >> jeanwelly wrote:
> > > > > >>> my $result = `which command`;
> > > > > >>> print "Stop...\n"; # can not call to here.
> > > > > >>> chomp($result);
>
> > > > Sorry for not presented my problem clearly, here is clarification.
> > > > `which whois`; # it will hang.
>
> > > > It is executed in SUN UNIX OS, and some seems fine, some no; if key
> > > > the command in shell directly, it tell me "shell built in command" in
> > > > the issued SUN server; while in another SUN server that without this
> > > > hang issue, the shell tells me the correct directory.
>
> > > What shell do you use that has whois as a builtin command?
>
> > > Doesn't 'which' read your .cshrc to learn about aliases? Do you have
> > > anything in .cshrc that might be interfering?
>
> > > Anyway, you shouldn't be relying on the PATH in a Perl program -- it's a
> > > security issue. Either specify the full path /usr/bin/whois where you
> > > need it, or set $ENV{PATH} yourself to something like '/usr/bin:/bin'.
>
> > > --
> > > Glenn Jackman
> > > "You can only be young once. But you can always be immature." -- Dave Barry
>
> Anyone has any suggestions to check? I'm still in the trouble. :(
> One of my workmate can use his account in the server (I encountered
> with hang issue) with NO the hang issue. I sourced his .cshrc, but
> still does not work.
Rewrite your own version of which within perl:
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';
unless(@ARGV){
print "Too few arguments\n";
exit;
}
foreach my $file(@ARGV){
my $path = (grep {-e "$_/$file"} split(/:+/, $ENV{PATH}))[0];
if($path){
print "$path/$file\n";
}else{
print "$file: Command not found.\n";
}
}
Running it gives me:
l-xterm-7:~/sandbox/scratch> ./perlWhich.pl perl doggy fish gdb whois
/home/utils/perl-5.8.8/bin//perl
doggy: Command not found.
fish: Command not found.
/usr/bin/gdb
/usr/bin/whois
l-xterm-7:~/sandbox/scratch>
------------------------------
Date: Sat, 4 Aug 2007 04:42:13 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Sat Aug 4 2007
Message-Id: <JM8FqD.1JML@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Apache-Session-1.83_01
http://search.cpan.org/~chorny/Apache-Session-1.83_01/
A persistence framework for session data
----
Archive-Builder-1.12
http://search.cpan.org/~adamk/Archive-Builder-1.12/
File generation and archiving framework
----
Bio-Grep-v0.8.4
http://search.cpan.org/~limaone/Bio-Grep-v0.8.4/
Perl extension for searching in Fasta files
----
CSS-Minifier-0.01
http://search.cpan.org/~pmichaux/CSS-Minifier-0.01/
Perl extension for minifying CSS
----
Catalyst-View-JSON-0.19
http://search.cpan.org/~miyagawa/Catalyst-View-JSON-0.19/
JSON view for your data
----
ClearCase-Wrapper-1.14
http://search.cpan.org/~dsb/ClearCase-Wrapper-1.14/
General-purpose wrapper for cleartool
----
DJabberd-EntityTime-0.01
http://search.cpan.org/~urkle/DJabberd-EntityTime-0.01/
----
DJabberd-EntityTime-0.02
http://search.cpan.org/~urkle/DJabberd-EntityTime-0.02/
----
Devel-Hide-0.0006_01
http://search.cpan.org/~ferreira/Devel-Hide-0.0006_01/
Forces the unavailability of specified Perl modules (for testing)
----
HTML-Menu-TreeView-0.7.1
http://search.cpan.org/~lze/HTML-Menu-TreeView-0.7.1/
----
JavaScript-Minifier-1.04
http://search.cpan.org/~pmichaux/JavaScript-Minifier-1.04/
Perl extension for minifying JavaScript code
----
Mail-SpamAssassin-Plugin-GoogleSafeBrowsing-1.02
http://search.cpan.org/~danborn/Mail-SpamAssassin-Plugin-GoogleSafeBrowsing-1.02/
SpamAssassin plugin to score mail based on Google blocklists.
----
Math-Prime-TiedArray-0.03
http://search.cpan.org/~zigdon/Math-Prime-TiedArray-0.03/
Simulate an infinite array of prime numbers
----
Math-Prime-TiedArray-0.04
http://search.cpan.org/~zigdon/Math-Prime-TiedArray-0.04/
Simulate an infinite array of prime numbers
----
Module-PluginFinder-0.01
http://search.cpan.org/~pevans/Module-PluginFinder-0.01/
automatically choose the most appropriate plugin module.
----
Net-Google-SafeBrowsing-Blocklist-1.03
http://search.cpan.org/~danborn/Net-Google-SafeBrowsing-Blocklist-1.03/
Query a Google SafeBrowsing table
----
Net-Google-SafeBrowsing-UpdateRequest-1.03
http://search.cpan.org/~danborn/Net-Google-SafeBrowsing-UpdateRequest-1.03/
Update a Google SafeBrowsing table
----
Net-OpenID-Consumer-0.14
http://search.cpan.org/~bradfitz/Net-OpenID-Consumer-0.14/
library for consumers of OpenID identities
----
Net-SSH-Expect-1.01
http://search.cpan.org/~bnegrao/Net-SSH-Expect-1.01/
SSH wrapper to execute remote commands
----
Net-SSH-Expect-1.02
http://search.cpan.org/~bnegrao/Net-SSH-Expect-1.02/
SSH wrapper to execute remote commands
----
Params-Clean-0.9.2
http://search.cpan.org/~plato/Params-Clean-0.9.2/
(Parse A Routine Allowing Modest Syntax--Casually List Explicit Arg Names): Process @_ as positional/named/flag/list/typed arguments
----
String-FixedLen-0.02
http://search.cpan.org/~dland/String-FixedLen-0.02/
Create strings that will never exceed a specific length
----
Text-XLogfile-0.01
http://search.cpan.org/~sartak/Text-XLogfile-0.01/
reading and writing xlogfiles
----
Thread-Queue-Any-0.08
http://search.cpan.org/~elizabeth/Thread-Queue-Any-0.08/
thread-safe queues for any data-structure
----
WWW-Mechanize-Timed-0.43
http://search.cpan.org/~lbrocard/WWW-Mechanize-Timed-0.43/
Time Mechanize requests
----
WWW-Sitebase-0.5
http://search.cpan.org/~grantg/WWW-Sitebase-0.5/
Base class for Perl modules
----
YAML-Syck-0.95
http://search.cpan.org/~audreyt/YAML-Syck-0.95/
Fast, lightweight YAML loader and dumper
----
mocked-0.07
http://search.cpan.org/~lukec/mocked-0.07/
use mocked libraries in unit tests
----
pod2book-0.0.1
http://search.cpan.org/~lutetius/pod2book-0.0.1/
Convert a number of POD pages into a LaTeX book
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Fri, 03 Aug 2007 23:15:11 -0700
From: Joe Smith <joe@inwap.com>
Subject: Re: Perl and Sockets
Message-Id: <ocmdnT6M4Y_ohCnbnZ2dnUVZ_sejnZ2d@comcast.com>
Zev G. wrote:
> I am working on a new project and the need to code in Sockets came up.
> I have also been told that the nature of sockets entails multi-
> threading. In other words, if my program is listening for a call, I
> need to make sure the user can use the computer for other stuff.
That's not a problem. All modern OS implementations (and many of the
old ones) allow other things to happen while a waiting for a connection.
Your program may be blocked, but others on the same computer won't be.
That being said, there is often a problem in a single program where you
want to be listening on a socket (for data to send to the screen) and
want to be waiting for a keypress (to send to the socket). In that
case, it makes sense to use fork() to create a second process; one do
deal with input from the socket and the other to deal with output to
the socket.
> ... it has a wrapper for sockets. Does this wrapper also
> handle the threads?
Some versions of Perl for Windows implement fork() as OS threads,
so it's taken care of.
Check out http://www.inwap.com/mybin/miscunix/tcp-proxy - it is a program
designed to run on both SunOS-4.1 UNIX and Windows-95, and it uses three
processes to deal with two sockets.
1) Master process listens at port 119 on the IP address on the secondary
ethernet, the one connected to the LAN at home.
2) When a request comes in, a second socket is created on the IP address
on the primary ethernet, the one connected to the cable modem. That
socket is used to connect to news.athome.net port 119.
3) The master forks twice. One child accepts NNTP packets from the
LAN and sends it to the remote news server. The other child accepts
responses from the remote news server and delivers them to the NNTP
client on the LAN.
4) The master goes back to the accept() call, and awaits new connections.
5) Multiple simultaneous connections are allowed, each one having its
own pair of forked processes.
This was back before "internet connection sharing" was available. It allowed
one or more NNTP clients on the LAN to access the ISP's news server.
It served me well - I pulled many hundreds of megabytes of newsgroup postings
through that little Win95 box.
-Joe
------------------------------
Date: 4 Aug 2007 08:52:18 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Prototypes/Parameters to a Function/Sub-Routine
Message-Id: <5hit22F3jktuuU1@mid.dfncis.de>
O. Olson <olson_ord@yahoo.it> wrote in comp.lang.perl.misc:
> On Aug 3, 2:03 pm, anno4...@radom.zrz.tu-berlin.de wrote:
> > Not necessarily. A user could present $obj2 coming from a subclass,
> > in which case the test may fail, depending how it it done.
> >
> > In a purely OO design, the diff method would use accessor methods of
> > the common class to compare values, not rely on a particular structure
> > of the objects.
> >
> > Anno
>
> Dear Anno,
>
> Thanks for taking interest - But I'm still not entirely clear what
> you mean. ( Let's not consider inheritance for a while, because it may
> complicate matters - and I'm not using it right now).
>
> Consider for example the following class
There are ready-made time classes on CPAN that do time calculations.
In a real application I would urge you to use one of those. I'll
assume your implementation of MyTime is an exercise.
> -----------------------------------------------------
> package MyTime;
>
> sub new {
> my $inv = shift;
> my $class = ref( $inv ) || $inv;
> die "Too many arguments\n" unless @_ <=3;
You mean ">=".
> my $self;
>
> if ( @_ == 0 ) {
>
> my @time = localtime( );
> $self = { HOUR => $time[ 2 ],
> MINUTE => $time[ 1 ],
> SECOND => $time[ 0 ] };
> } else {
> $self = { HOUR => $_[ 0 ],
> MINUTE => $_[ 1 ] || 0,
> SECOND => $_[ 2 ] || 0 };
> }
>
> return bless $self, $class;
> }
>
> sub timeDiff {
>
> my $start_time = shift; # Start Time - First argument
> my $stop_time = shift; # Stop Time - Second argument
>
>
> print "Calculating the Time Difference between: " . $start_time-
> >as_text . " to " . $stop_time->as_text; #print "\n";
>
> my $start_seconds = $start_time->{HOUR}*3600 + $start_time-
> >{MINUTE}*60 + $start_time->{SECOND};
> my $stop_seconds = $stop_time->{HOUR}*3600 + $stop_time-
> >{MINUTE}*60 + $stop_time->{SECOND};
>
> my $diff_seconds = $stop_seconds - $start_seconds;
>
> print " = $diff_seconds \n";
>
> return $diff_seconds;
>
> }
>
> -----------------------------------------------------
>
> Assuming timeDiff() is called as:
>
> $time_start-> timeDiff($time_stop)
>
> -----------------------------------------------------
>
>
> My question is how can I ensure that the second argument passed to
> timeDiff() is of The same class MyTime.
You could say
die "..." unless $time_stop->isa( 'MyTime);
but I simply wouldn't bother.
If someone calls ->timeDiff with an inappropriate argument, access to
->{ HOUR} will fail and you'll see warnings about using an undefined
value. (Your *are* running with warnings and strict, aren't you?)
That should be enough to detect and correct the error.
On the other hand, you are duplicating the code to transform a
time value to seconds in your timeDiff method. Instead, define
a method (code untested)
sub inSecs {
my $time =shift;
($time->{ HOUR}*60 + $time->{ MINUTE})*60 + $time->{ SECOND};
}
and base timeDiff on that:
sub timeDiff {
my ( $start, $stop) = @_;
$stop->inSecs - $start->inSecs;
}
Besides the better code re-use, this makes sure that a call with a
non-time will fail because the ->inSecs method won't be defined.
Anno
------------------------------
Date: Sat, 04 Aug 2007 02:44:32 -0700
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: Q on localizing *STDOUT and fork
Message-Id: <1186220672.407031.107620@g4g2000hsf.googlegroups.com>
On Aug 3, 4:55 pm, kj <so...@987jk.com.invalid> wrote:
> In <1186036012.070979.170...@19g2000hsx.googlegroups.com> Brian McCauley <nobul...@gmail.com> writes:
>
> >On Aug 2, 12:41 am, kj <so...@987jk.com.invalid> wrote:
> >I wrote a quite detailed explanation of this here...
> >http://groups.google.com/group/comp.lang.perl.misc/browse_frm/thread/...
>
> That was certainly illuminating. Thank you!
>
> In that post you wrote:
>
> > But if you do local(*STDOUT) you stash away the current contents of
> > *STDOUT{IO} and make it empty. Now when you open(STDOUT,...) you get a
> > new IO-thingy associated with *STDOUT{IO} but this IO-thingy is not
> > associated with FD 1. As far as the current Perl process is concerned
> > this is now the "standard output" but any child process that's created
> > will still think of FD 1 as standard out.
>
> Inspired by this I replaced
>
> local *STDOUT;
>
> with
>
> local *STDOUT = *STDOUT;
>
> The subsequent redirection of STDOUT now worked as desired, but
> the original STDOUT was not restored after the end of the enclosing
> block. My guess is that the "stashing away" that happens when one
> uses local does not include the association of the file descriptor
> with the file control block, which just gets lost after the
> duplication with "open STDOUT, '>&', ...".
With local *STDOUT = *STDOUT all you are doing is manipulating the
very top layers of the stuff described in my other post.
You are not creating a new IO-thingy nor are you changing anything in
the IO-thingy, filedescriptor, FCB chain. There's still only one
filedescriptor (1) associated with the original FCB and as soon as you
reopen STDOUT your process looses all connection with that FCB.
------------------------------
Date: Sat, 04 Aug 2007 03:25:34 -0700
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: Q on localizing *STDOUT and fork
Message-Id: <1186223134.723592.105510@d55g2000hsg.googlegroups.com>
On Aug 3, 8:02 pm, Brian McCauley <nobul...@gmail.com> wrote:
> On Aug 3, 4:55 pm, kj <so...@987jk.com.invalid> wrote:
>
> > In <1186036012.070979.170...@19g2000hsx.googlegroups.com> Brian McCauley
> > >I'm fairly sure I've seen modules on CPAN to wrap it up a bit...
>
> > If anyone happens to know the CPAN module that Brian is referring
> > to here please let me know. I looked for it without any luck. I
> > searched for terms like "redirect" and "redirection". (FWIW, I
> > did my search with Google restricted to site:search.cpan.org.)
>
> I think I was miss-remembering either Hook::Output::File or
> SelectSaver - neither of which does what you want. Hook::Output::File
> could be rewritten to do the right thing.
On the other hand simply abstracting the code from my previous post
into a subroutine is not too hard:
use AtExit;
sub save_fd {
my $std = shift;
open ( my $saved,'>&', $std) or die $!;
my $mode = shift;
open $std, $mode, @_ and new AtExit sub {
# Actually the or die is of dubious utility here
open ($std,'>&', $saved) or die $!;
};
}
print "To terminal\n";
{
my $save_STDOUT = save_fd \*STDOUT, '>', 'x.log' or die $!;
print "To log\n";
}
print "To terminal\n";
------------------------------
Date: Sat, 4 Aug 2007 13:39:45 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Using DBI, better option than importing into @array
Message-Id: <slrnfb8pc1.2tf.hjp-usenet2@zeno.hjp.at>
On 2007-07-30 21:30, Jason <jwcarlton@gmail.com> wrote:
> I've posted a few times now that I'm rebuilding a message board
> program to use MySQL instead of flat text files. I'm relatively new to
> MySQL, though, so I'm having fun with the challenges along the way.
>
> The database has 2 tables: one to hold subjects, and one to hold all
> of the posts. The subjects table has around 17000 rows, while the
> posts table has around 600,000.
>
> The most current problem is SPEED! From sheer lack of knowledge, I'm
> importing the subjects table into an array in the beginning of the
> script, then using a for loop throughout the program to access that
> array. But the program is running pretty slow, and I'm sure that the
> bottleneck is with this array.
This first thing you have to do when you try to make your program faster
is to profile it. If you don't know WHAT exactly is slow, you can only
guess, and you'll probably guess wrong and spend a lot of time improving
the performance by one percent.
There are tools for profiling, like Devel::DProf or Apache::DProf, but
for starters, you can just use time (possibly with Time::HiRes to get
sub-second resolution) and print, like this:
> Here is the code that I'm using:
use Time::HiRes qw(time);
my $t0 = time;
> # Push subjects into Perl array
> my $filelist = $dbh->selectall_arrayref("SELECT `id`, `lastmodified`,
> `subject` FROM $forum_subjects ORDER BY lastmodified DESC");
>
> my @filenames;
> for my $row (@$filelist) {
> my ($id, $lastmodified, $subject) = @$row;
> push(@filenames, $id . "|:|" . $lastmodified . "|:|" . $subject);
> }
my $t1 = time();
print STDERR "retrieved subject list in ", $t1 - $t0, " seconds\n";
$t0 = time();
>
> # In the "view subject" section, loop through last 20 indexes of
> @filenames
> # 0 and 20 are dynamic in the real script
> for ($count=0; $count < 20; $count++) {
> ($id, $lastmodified, $subject) = split(/\|:\|/, $filenames[$count]);
>
> my $topiclist = $dbh->selectall_arrayref("SELECT `id`, `subject`,
> `postdate`, `username`, `email`, `comment` FROM $forum_posts WHERE
> id=" . $dbh->quote($id) . " ORDER BY postdate ASC");
>
> print ...
> }
$t1 = time();
print STDERR "displayed 20 postings in ", $t1 - $t0, " seconds\n";
This will tell you whether you spend most time in the first or the
second part of your program. Naturally, you start improving the part
where it spends most time ...
It also gives you numbers to compare so you don't have to rely on
subjective feeling of speed. "I think it is now faster than last week"
is not a good measurement. If you see in your log files that last week
it took between 8 and 11 seconds, and now you're down to 5 to 6 seconds,
you know that you've made progress.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 4 Aug 2007 13:55:27 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Using DBI, better option than importing into @array
Message-Id: <slrnfb8q9f.2tf.hjp-usenet2@zeno.hjp.at>
On 2007-07-30 22:26, usenet@DavidFilmer.com <usenet@DavidFilmer.com> wrote:
> On Jul 30, 2:30 pm, Jason <jwcarl...@gmail.com> wrote:
>
>> The most current problem is SPEED!
>
> Yeah, I imagine so. The killer is that you are submitting a full
> selectall inside a loop.
The loop is executed only 20 times, and prepare time is usually rather
short (in fact, MySQL didn't have server side prepares until recently,
and it's still disabled by default in DBD::mysql), so I doubt this is
"the killer". If that makes any difference at all, it is probably not
noticable to the user.
But as always in performance-tuning: Don't guess - measure!
> You should generally NEVER do that. By constructing a different SQL
> statement each time (because you hard- code the id in the SQL) it
> means the statement will never be found in your database server's
> cache, so the server must compute an execution plan over and over
> again. Instead, you should always use the prepare method (outside of
> the loop) and then an execute (inside the loop).
I agree with that, but mostly because it forces you to use placeholders.
> Oh, and, also:
>
>> $dbh->quote($id)
>
> If you are sure your $id cannot be tainted (such as it has an integer
> type imposed by the database) then you don't need to quote it (and
> doing so further slows you down).
This is very bad advice. The OP should use placeholders instead. quote()
encourages just that kind of dangerous micro-optimizations (Oh, I guess
$id is probably ok, so I'll save 13 keystrokes and a few microseconds
... and then you'll find out that it wasn't ok when your machine is
0wned).
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 4 Aug 2007 14:12:57 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Using DBI, better option than importing into @array
Message-Id: <slrnfb8ra9.2tf.hjp-usenet2@zeno.hjp.at>
On 2007-07-31 18:38, usenet@DavidFilmer.com <usenet@DavidFilmer.com> wrote:
> On Jul 30, 4:34 pm, Jason <jwcarl...@gmail.com> wrote:
>> the subjects table is
>>
>> Categories: id - lastmodified - subject
>> Actual row: 17090 - 20070730192222 - This is a test
>>
>> The posts table would be like:
>>
>> Categories: id - subject - postdate - username - email - comment
Please call the columns of the table "columns" or "fields". Nobody will
understand you if you call them "categories".
>> Actual row: 17090 - This is a test - 20070730192222 - Jason -
>> jwcarl...@gmail.com - This is a test comment.
>
> OK, try something like this (untested - I don't have a sample
> database):
>
> my $sth = $dbh->prepare(<<SQL);
> select $forum_posts.id,
> $forum_posts.subject,
> $forum_posts.postdate,
> $forum_posts.username,
> $forum_posts.email,
> $forum_posts.comment
> from $forum_posts
> left join id on ($forum_subjects.id = $forum_posts.id)
> order by $forum_subjects.postdate ASC
> limit 20
> SQL
I haven't tested it either, but it doesn't look equivalent to what the
OP had. It gets the oldest 20 postings instead of the newest 20 threads.
>> In retrospect, I can't quite remember why I'm duplicating the
>> information into the subjects table; I think it was at the suggestion
>> of someone in another NG.
>
> The person who made such a suggestion is a complete idiot.
Maybe, maybe not. There are two possibilities:
1) The subject cannot change within a thread. In this case it belongs
*only* into the subjects (threads) table. Duplicating it in the
postings table breaks normalization and is probably useless.
2) The subject can change within a thread. In this case duplicating the
subject of the first (or last) message into the subjects (threads)
table may still be worthwhile to avoid a join if you just want to
display an overview of the threads.
>> Would it be better to get rid of the "subjects" table altogether, and
>> just create an index with the ID field?
>
> Absolutely.
Probably not. But it's hard to tell without knowing how the tables are
used.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 4 Aug 2007 14:20:39 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Using DBI, better option than importing into @array
Message-Id: <slrnfb8ron.2tf.hjp-usenet2@zeno.hjp.at>
On 2007-07-30 22:33, J. Gleixner <glex_no-spam@qwest-spam-no.invalid> wrote:
> Jason wrote:
>> my $topiclist = $dbh->selectall_arrayref("SELECT `id`, `subject`,
>> `postdate`, `username`, `email`, `comment` FROM $forum_posts WHERE
>> id=" . $dbh->quote($id) . " ORDER BY postdate ASC");
>
> Look into placeholders and bind_columns
I second that advice.
> and you don't need any of those '`'.
Nope. The backticks are to delimit identifiers. You cannot substitute
identifiers with placeholders. The backticks are only necessary if you
want to use column names which are keywords or contain "non-identifier"
characters (like spaces). As a matter of style, I think they should
generally be omitted. Tools which generate SQL often use backticks so
that the user doesn't have to know about SQL naming rules.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 04 Aug 2007 04:55:11 -0700
From: Bill H <bill@ts1000.us>
Subject: Re: Windows based perl editor?
Message-Id: <1186228511.108296.212200@l70g2000hse.googlegroups.com>
On Aug 3, 11:29 pm, skywriter14 <sumonsmail...@gmail.com> wrote:
> So a lot of Perl programmer use Windows for developement!? And many
> people still thinks Perl doesn't even run on Windows. In my country at
> least.
I do all my development on windows and then transfer it over to linux
for actual testing. I have looked at all the editors mentioned on here
and am looking at the ones listed in the wikipedia site (thanks for
that link). Most of them seem to do too much (is that bad?) for me at
this time, but may be of use in the future. The biggest thing I really
want is the incremental backup so that I can walk back through
previous versions of a program if I discover that changes I made
"broke" something else. The syntax hiliting and the other "wish list"
stuff I can get along without. I may just have to use the MS C++ to
write what I want. It already comes with a sample of SuperPad (notepad
on steriods) that I could make do the incremental backups.
Bill H
------------------------------
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 719
**************************************
