[31018] in Perl-Users-Digest
Perl-Users Digest, Issue: 2263 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 9 16:09:47 2009
Date: Mon, 9 Mar 2009 13:09:12 -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 Mon, 9 Mar 2009 Volume: 11 Number: 2263
Today's topics:
Re: Ban Xah Lee <dirk.bruere@gmail.com>
Re: calculate an average with every data in an array <edwards@nouce.trurl.bsd.uchicago.edu>
Re: Forcing list context on <$fh> (Tim McDaniel)
Re: Forcing list context on <$fh> <noreply@gunnar.cc>
Re: good editor for perl <justin.0903@purestblue.com>
Re: good editor for perl <cartercc@gmail.com>
How to convert a floating point number to a 64 bit inte <slsamliu@gmail.com>
Re: How to convert a floating point number to a 64 bit <ben@morrow.me.uk>
listing files in sub directories <Stephen.Schoenberger@gmail.com>
Re: listing files in sub directories <ben@morrow.me.uk>
Matches wuth CIDR range? <liarafan@xs4all.nl>
Re: Matches wuth CIDR range? <ben@morrow.me.uk>
Re: Matches wuth CIDR range? <liarafan@xs4all.nl>
Re: perl as email client <1usa@llenroc.ude.invalid>
software design question <cartercc@gmail.com>
Re: software design question <glennj@ncf.ca>
Re: software design question <tadmc@seesig.invalid>
Re: software design question <hjp-usenet2@hjp.at>
Re: software design question <cartercc@gmail.com>
Re: software design question <uri@stemsystems.com>
Re: software design question <brian.d.foy@gmail.com>
Re: software design question <uri@stemsystems.com>
Re: Which Lisp to Learn? <maustin@firstdbasource.com>
Re: wxperl <mikaelb@df.lth.se>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 09 Mar 2009 18:27:56 +0000
From: Dirk Bruere at NeoPax <dirk.bruere@gmail.com>
Subject: Re: Ban Xah Lee
Message-Id: <71l5ctFlkc5fU4@mid.individual.net>
Larry Gates wrote:
> On Sun, 08 Mar 2009 04:09:52 +0000, Dirk Bruere at NeoPax wrote:
>
>> Dirk Bruere at NeoPax wrote:
>
>>> Well, don't worry - nobody is going to ban you from Usenet (except
>>> possibly the Chinese govt).
>>> OTOH, nobody here much cares.
>>> So, rant on - it's what Usenet is for. ☄ <--- what is that char?????
>
> http://lomas-assault.net/usenet/z12.jpg
>
> I don't know how to answer the question. Is the zeroeth character also
> null?
Almost had me cleaning the screen.
--
Dirk
http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff
------------------------------
Date: Mon, 09 Mar 2009 19:02:00 GMT
From: Edwards <edwards@nouce.trurl.bsd.uchicago.edu>
Subject: Re: calculate an average with every data in an array
Message-Id: <slrngrapsj.teb.edwards@trurl.bsd.uchicago.edu>
Not sure if this was directed at me; if not, sorry, please ignore.
On 2009-03-09, Erol Akman <jogsalot75@yahoo.de> wrote:
> Thank you very much for your thoughts and efforts. It made me realize
> how nuts this task really is ;-)
>
> Taken into account that I could make a few educated guesses as Rasmus
> Villemoes suggested, I would not have "hundreds of values" but 20 or
> even less.
>
> You've said, that you already ran a calculation on your computer with
> 10 values (?), how did you do that? Could you provide me your code?
Well, I was a bit afraid to do that because it's so ugly; keep in mind
this was just a quick hack that I threw together based only on your
initial description of the problem. The output isn't really formatted
the way you requested, but it should be pretty self-explanatory (the
number in parentheses after a given average is how many lists of
values had that average). I've reformatted it a bit (it was originally
one long line at the command line) and added some comments...
trurl:~>perl -e 'my @data = qw(4 6 2 7 1 8 3 5 9 10);
my %avg_list;
for my $iter (1..2**@data-1) {
# There must be a better way to get the bit flags from each number,
# but I couldn't figure out how to get unpack to do what I wanted...
my @chosen = split "", sprintf("%0" . @data . "b", $iter);
my @indices = grep($chosen[$_], (0..@data-1));
# The eval was just a silly way to do the average in one line; you're
# probably better off doing it the straightforward way (as you posted)
my $this_avg = (eval join("+", @data[@indices]))/@indices;
push @{$avg_list{$this_avg}}, [@data[@indices]];
}
for my $this_avg (sort {$a <=> $b} keys (%avg_list)) {
print "$this_avg (", scalar(@{$avg_list{$this_avg}}), "):\n";
for my $list (@{$avg_list{$this_avg}}) {
print "\t@{$list}\n";
}
}' | more
Please consider this code "not really tested in any serious way".
--
Darrin
------------------------------
Date: Mon, 9 Mar 2009 15:56:49 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Forcing list context on <$fh>
Message-Id: <gp3e81$jjh$1@reader1.panix.com>
In article <270220091436308861%jimsgibson@gmail.com>,
Jim Gibson <jimsgibson@gmail.com> wrote:
>In article <go9ieb$jsq$1@reader1.panix.com>, Tim McDaniel
><tmcd@panix.com> wrote:
>
>> As a practical matter, I run enough scripts on Windows (whether
>> under bash or cmd) and have hit the problem enough that I do
>> chomp;
>> s/\r+$//;
>> as a matter of rote, or instead use \s if I want to strip all trailing
>> whitespace whatsoever.
>
>Why not just
>
> s/[\r\n]+$//;
>
>in one operation and skip the chomp?
That would assume that $/ contains only carriage returns and ASCII
newlines (that is, not considering the "\n" special casing that gets
done when doing I/O on non-binary files). However, in practice for
me, $/ DOES contain only CR and NL.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 09 Mar 2009 18:05:53 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Forcing list context on <$fh>
Message-Id: <71l0jiFlop25U1@mid.individual.net>
Tim McDaniel wrote:
> In article <270220091436308861%jimsgibson@gmail.com>,
> Jim Gibson <jimsgibson@gmail.com> wrote:
>> In article <go9ieb$jsq$1@reader1.panix.com>, Tim McDaniel
>> <tmcd@panix.com> wrote:
>>
>>> As a practical matter, I run enough scripts on Windows (whether
>>> under bash or cmd) and have hit the problem enough that I do
>>> chomp;
>>> s/\r+$//;
>>> as a matter of rote, or instead use \s if I want to strip all trailing
>>> whitespace whatsoever.
>> Why not just
>>
>> s/[\r\n]+$//;
>>
>> in one operation and skip the chomp?
>
> That would assume that $/ contains only carriage returns and ASCII
> newlines (that is, not considering the "\n" special casing that gets
> done when doing I/O on non-binary files).
What "\n" special casing?
http://groups.google.com/group/comp.lang.perl.misc/msg/932b35d8434e2f11
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 09 Mar 2009 14:25:38 -0000
From: Justin C <justin.0903@purestblue.com>
Subject: Re: good editor for perl
Message-Id: <5d80.49b526e2.2cdc6@zem>
On 2009-03-05, abcd <aa@aa.com> wrote:
> I'am looking for good editor which show parameters of functions....
If you're on OS X I recommend TextMate, an excellent all-round text
editor.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Mon, 9 Mar 2009 10:12:55 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: good editor for perl
Message-Id: <8b8a7aca-58ad-46d3-875b-06849050bc8d@q11g2000vbn.googlegroups.com>
On Mar 5, 5:03=A0pm, "abcd" <a...@aa.com> wrote:
> I'am looking for good editor which show parameters of functions....
I promiscuously try many different editors, I probably have two dozen
installed on my machine at work, but I always come back to vi, or
Winvi or gVim on Windows.
vi is old, ugly, and cranky, like Perl, but however flashy and
'modern' other text editors are, there's always something they can't
do that vi can when you are writing Perl. I have a fair amount of time
in both Visual Studio and Eclipse, and while the tools they offer are
great, especially if you are writing Java or one of the .NET
languages, I find that they don't match what you need when writing the
kinds of Perl apps that I write. If I were a full time programmer in
one of these other languages, I almost certainly wouldn't use vi, but
for me it's ideal for writing Perl.
CC
------------------------------
Date: Mon, 9 Mar 2009 11:17:56 -0700 (PDT)
From: SamL <slsamliu@gmail.com>
Subject: How to convert a floating point number to a 64 bit integer?
Message-Id: <ece2db8c-3b2d-4504-a791-dd6783ad41e3@j12g2000vbl.googlegroups.com>
I need to convert a floating point number to a 64 bit integer (long
long). How to do that in perl? Thanks.
------------------------------
Date: Mon, 9 Mar 2009 19:04:34 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to convert a floating point number to a 64 bit integer?
Message-Id: <2r5g86-ilc1.ln1@osiris.mauzo.dyndns.org>
Quoth SamL <slsamliu@gmail.com>:
> I need to convert a floating point number to a 64 bit integer (long
> long). How to do that in perl? Thanks.
You will need to specify a little more about where these numbers are
coming from. Probably you want perldoc -f pack.
Ben
------------------------------
Date: Mon, 9 Mar 2009 10:32:00 -0700 (PDT)
From: steve <Stephen.Schoenberger@gmail.com>
Subject: listing files in sub directories
Message-Id: <4832b2cc-2d36-49ad-990c-a7e833e6936b@o11g2000yql.googlegroups.com>
I am trying to list all files in all sub-directories and have the code
below but this is listing the . directories as well as the directories
themselves. I just want the full path filenames and not the individual
directories out. Here is what I have
#!c:/Perl/bin/Perl.exe
@ARGV = qw(.) unless @ARGV;
use File::Find;
find sub { print $File::Find::name, -d && "/", "\n"}, @ARGV
for example if structure is
c:\file.txt
c:\file2.txt
c:\one\teo.txt
c:\two\text.bmp
the output of the script when run from c:\ would be
./
./script.pl
./file.txt
./file2.txt
./one/
./one/teo.txt
./two/
./two/text.bmp
all I want is
./script.pl
./file.txt
./file2.txt
./one/teo.txt
./two/text.bmp
Thanks!
------------------------------
Date: Mon, 9 Mar 2009 17:56:52 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: listing files in sub directories
Message-Id: <4s1g86-3bc1.ln1@osiris.mauzo.dyndns.org>
Quoth steve <Stephen.Schoenberger@gmail.com>:
> I am trying to list all files in all sub-directories and have the code
> below but this is listing the . directories as well as the directories
> themselves. I just want the full path filenames and not the individual
> directories out. Here is what I have
>
> #!c:/Perl/bin/Perl.exe
>
> @ARGV = qw(.) unless @ARGV;
>
> use File::Find;
>
> find sub { print $File::Find::name, -d && "/", "\n"}, @ARGV
Err... you already seem to know the answer to that...
find sub { -d or print "$File::Find::name\n" }, @ARGV;
Ben
------------------------------
Date: Mon, 9 Mar 2009 17:43:56 +0100
From: "Mark" <liarafan@xs4all.nl>
Subject: Matches wuth CIDR range?
Message-Id: <H9edndKC36rR2ijUnZ2dnUVZ8vednZ2d@giganews.com>
Hello,
Using Net::CIDR, I was unable to get a subset of how many IP adresses fall
into a certain range. For instance, I'd like to know how many IP addresses
fall into this (fake) range:
1.2.3.0/24
When I have addreses stored in @iplist, where @iplist is a list of IP
addresses to which client IP addresses are added (by a mail server
milter). Net::CIDR can only look up 1 IP address at the time (to see
whether it's within the specified range). Yet I'd like to know many
currently in @iplist are within range. Something like:
$count = within ('1.2.3.0/24', @iplist);
Surprisingly, I couldn't find any module on CPAN that has such
functionality. Am I overlooking an easy method? Or does anyone perhaps
know of a module to accomplish this?
Thanks.
------------------------------
Date: Mon, 9 Mar 2009 17:18:01 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Matches wuth CIDR range?
Message-Id: <9jvf86-r2c1.ln1@osiris.mauzo.dyndns.org>
Quoth "Mark" <liarafan@xs4all.nl>:
> Hello,
>
> Using Net::CIDR, I was unable to get a subset of how many IP adresses fall
> into a certain range. For instance, I'd like to know how many IP addresses
> fall into this (fake) range:
>
> 1.2.3.0/24
>
> When I have addreses stored in @iplist, where @iplist is a list of IP
> addresses to which client IP addresses are added (by a mail server
> milter). Net::CIDR can only look up 1 IP address at the time (to see
> whether it's within the specified range). Yet I'd like to know many
> currently in @iplist are within range. Something like:
>
> $count = within ('1.2.3.0/24', @iplist);
my $count = grep cidrlookup($_, "1.2.3.0/24"), @iplist;
Ben
------------------------------
Date: Mon, 9 Mar 2009 18:45:53 +0100
From: "Mark" <liarafan@xs4all.nl>
Subject: Re: Matches wuth CIDR range?
Message-Id: <ZPidnWW0hpNHyCjUnZ2dnUVZ8v6dnZ2d@giganews.com>
> my $count = grep cidrlookup($_, "1.2.3.0/24"), @iplist;
Thanks! That's exactly what I needed! :)
------------------------------
Date: Mon, 09 Mar 2009 18:14:11 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: perl as email client
Message-Id: <Xns9BC990D1C1E84asu1cornelledu@127.0.0.1>
Larry Gates <larry@example.invalid> wrote in
news:163kvha2yybb6$.3zk61x3canv4$.dlg@40tude.net:
> On Sat, 07 Mar 2009 15:51:25 GMT, A. Sinan Unur wrote:
>
>> Larry Gates <larry@example.invalid> wrote in
>> news:q98xh61wmkc$.1k26eqqyvwvc0$.dlg@40tude.net:
>>
>>> Gosh, I would have thought that writing an e-mail client in perl
>>> would be as commonplace as ways to calculate pi with fortran.
>>
>> http://www.unur.com/comp/ppp/delallspam.html
>>
>> might help you get started.
>>
> C:\MinGW\source>perl eml3.pl
> Can't locate Lingua/EN/Inflect.pm in @INC (@INC contains:
> C:/Perl/site/lib C:/Pe
> rl/lib .) at eml3.pl line 52.
> BEGIN failed--compilation aborted at eml3.pl line 52.
>
...
> use Lingua::EN::Inflect qw( PL );
>
> if( $to_delete ) {
> printf "%d %s will be deleted. Commit: [Y/N]?\n",
> $to_delete, PL('message', $to_delete);
> $pop->Reset unless yes();
> }
...
> use Lingua::EN::Inflect qw( PL );
>
> What does this module do to filter out spam?
Note that the only place the module is used is where I choose between
message/messages on the basis of the number of messages to delete.
It is unnecessary to pull in a whole module to do this just once
(obviously) but this code was meant as a demonstration.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Mon, 9 Mar 2009 06:23:52 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: software design question
Message-Id: <bb8a9f1b-c1af-4c72-baa1-8b1502544534@q18g2000vbn.googlegroups.com>
I have an application (the same one that my last few posts have
concerned) that is growing rather large. It's not OO mostly for the
reason that I've never done OO in Perl and didn't want to learn on
this one.
I have a couple of modules that are responsible for collecting user
data, a couple of modules that are responsible for the control logic,
a couple of modules that are responsible for calculating and preparing
the content, and an SQL module that handles the database stuff. I seem
to have a choice in the way the content is passed as the output as the
program: (1) either return the values to a main function that prints
the output, or (2) printing the output directly in the function that
calculates and prepares the output. IOW, I can do something like the
following:
FIRST OPTION:
my $content = calculate_content( \@vars);
print $content;
...
sub calculate_content
{
my $varref = shift;
my $output;
# do stuff like
$output .= output_from_other_functions();
return $output;
}
SECOND OPTION:
calculate_content( \@vars);
...
sub calculate_content
{
my $varref = shift;
my $output;
# do stuff like
$output .= output_from_other_functions();
print $output;
}
In out-putting the data, I can do it in the main function or do it in
helper functions. Which option is better? Why?
My preference is for (1) because I like to assign my variables in the
main function rather than hide the assignments in subroutines, but it
seems rather verbose and unnecessary here, so I'm tending toward (2),
but I'm not comfortable with it.
Thanks, CC.
------------------------------
Date: 9 Mar 2009 13:59:17 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: software design question
Message-Id: <slrngra85m.ijf.glennj@smeagol.ncf.ca>
At 2009-03-09 09:23AM, "ccc31807" wrote:
[...]
> FIRST OPTION:
> my $content = calculate_content( \@vars);
> print $content;
> ...
> sub calculate_content
> {
> my $varref = shift;
> my $output;
> # do stuff like
> $output .= output_from_other_functions();
> return $output;
> }
>
> SECOND OPTION:
> calculate_content( \@vars);
> ...
> sub calculate_content
> {
> my $varref = shift;
> my $output;
> # do stuff like
> $output .= output_from_other_functions();
> print $output;
> }
Name your subroutines to describe what they're doing:
FIRST OPTION: print generate_content( \@vars );
SECOND: emit_results( \@vars );
Personally, I'd favour the second. It would also lend itself to acting
as a dispatcher should you choose to output results in different
formats (html, csv, etc)
--
Glenn Jackman
Write a wise saying and your name will live forever. -- Anonymous
------------------------------
Date: Mon, 9 Mar 2009 09:02:02 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: software design question
Message-Id: <slrngra8aq.dbs.tadmc@tadmc30.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
> I seem
> to have a choice in the way the content is passed as the output as the
> program: (1) either return the values to a main function that prints
> the output, or (2) printing the output directly in the function that
> calculates and prepares the output.
> In out-putting the data, I can do it in the main function or do it in
> helper functions. Which option is better? Why?
I recommend following Uri's rule:
print rarely, print late
http://groups.google.com/group/comp.lang.perl.misc/msg/10f151df27e050b2
> My preference is for (1) because I like to assign my variables in the
> main function rather than hide the assignments in subroutines, but it
> seems rather verbose and unnecessary here, so I'm tending toward (2),
> but I'm not comfortable with it.
Good. You should be uncomfortable with (2). It is less flexible.
What if you later need to print somewhere other than STDOUT?
Easy with (1), less easy with (2).
What if you later need to further process the output? (eg. wrap it in HTML).
Easy with (1), less easy with (2).
Coding for ease of maintenance is a Really Good Idea, therefore
returning strings (rather than printing strings) is also a Good Idea.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 9 Mar 2009 16:51:02 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: software design question
Message-Id: <slrngraen7.vr4.hjp-usenet2@hrunkner.hjp.at>
On 2009-03-09 14:02, Tad J McClellan <tadmc@seesig.invalid> wrote:
> ccc31807 <cartercc@gmail.com> wrote:
>> I seem to have a choice in the way the content is passed as the
>> output as the program: (1) either return the values to a main
>> function that prints the output, or (2) printing the output directly
>> in the function that calculates and prepares the output.
>
>> In out-putting the data, I can do it in the main function or do it in
>> helper functions. Which option is better? Why?
>
>
> I recommend following Uri's rule:
>
> print rarely, print late
>
> http://groups.google.com/group/comp.lang.perl.misc/msg/10f151df27e050b2
In general, I agree with that.
>> My preference is for (1) because I like to assign my variables in the
>> main function rather than hide the assignments in subroutines, but it
>> seems rather verbose and unnecessary here, so I'm tending toward (2),
>> but I'm not comfortable with it.
>
>
> Good. You should be uncomfortable with (2). It is less flexible.
It is also harder to test.
> What if you later need to print somewhere other than STDOUT?
perldoc -f select
Or you could redirect STDOUT to a string (this is what I usually do if I
need to test a function which prints to STDOUT).
So it is possible, but it may be awkward.
> returning strings (rather than printing strings) is also a Good Idea.
Except when your strings are really huge. I have an application where
results in the tens of megabytes are normal and gigabytes possible.
I didn't really expect that (lack of foresight on my part), so I
construct the whole result (an XML file, usually) as a string in memory
before printing it. This needs a lot of memory and it is slower than
necessary (printing only starts when the computation is finished), so
I'd like to change that but the structure of the application doesn't
make that easy.
So while "print rarely, print late" is fine most of the time, you should
still think whether it is appropriate for your specific situation.
hp
------------------------------
Date: Mon, 9 Mar 2009 09:54:22 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: software design question
Message-Id: <760aa2eb-3fd4-4ed2-9b95-7a8c2740374f@n30g2000vba.googlegroups.com>
On Mar 9, 11:51=A0am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> Except when your strings are really huge. I have an application where
> results in the tens of megabytes are normal and gigabytes possible.
I don't expect my strings to be really huge, but they possible can be
on the large size. If it comes to it, I'll return a reference to a
scalar to the main function.
> I didn't really expect that (lack of foresight on my part), so I
> construct the whole result (an XML file, usually) as a string in memory
> before printing it. This needs a lot of memory and it is slower than
> necessary (printing only starts when the computation is finished), so
> I'd like to change that but the structure of the application doesn't
> make that easy.
I sometimes have to output a lot of data. I can't think of a single
time I've not written to a text file first, and then sent the file to
a printer, usually non-programmatically but on occasion in the script.
My users expect a file in some particular format, like Word or Excel
or PDF, so it's easier for me to do it this way.
> So while "print rarely, print late" is fine most of the time, you should
> still think whether it is appropriate for your specific situation.
I wasn't familiar with this rule in this context, but it's a good
codification of a best practice. An exception might be where your app
is computationally expensive and your IO is not, maybe where you are
picking a few values out of a large database. In general, my scripts
don't print until the very last.
CC
------------------------------
Date: Mon, 09 Mar 2009 12:31:59 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: software design question
Message-Id: <x7mybuiovk.fsf@mail.sysarch.com>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>> returning strings (rather than printing strings) is also a Good Idea.
PJH> Except when your strings are really huge. I have an application where
PJH> results in the tens of megabytes are normal and gigabytes possible.
so return scalar refs to those strings. that is what i do in many cases
anyway to save on copying.
PJH> I didn't really expect that (lack of foresight on my part), so I
PJH> construct the whole result (an XML file, usually) as a string in
PJH> memory before printing it. This needs a lot of memory and it is
PJH> slower than necessary (printing only starts when the computation
PJH> is finished), so I'd like to change that but the structure of the
PJH> application doesn't make that easy.
and there are modules which ONLY print for you or to a single handle and
cause many problems if you want flexibility. hence my rule. :)
PJH> So while "print rarely, print late" is fine most of the time, you should
PJH> still think whether it is appropriate for your specific situation.
always think about whether something is appropriate! :) but scalar refs
solves the passing around big strings. you still need at least one large
buffer for it though.
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: Mon, 09 Mar 2009 14:02:01 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: software design question
Message-Id: <090320091402015644%brian.d.foy@gmail.com>
In article <slrngra85m.ijf.glennj@smeagol.ncf.ca>, Glenn Jackman
<glennj@ncf.ca> wrote:
> Name your subroutines to describe what they're doing:
>
> FIRST OPTION: print generate_content( \@vars );
> SECOND: emit_results( \@vars );
>
> Personally, I'd favour the second. It would also lend itself to acting
> as a dispatcher should you choose to output results in different
> formats (html, csv, etc)
I like to have both of those. One always returns the content as a
string, and one prints to a filehandle:
emit_results( $fh, \@vars ); # $fh is any sort of handle
sub generate_results { ... }
sub emit_results {
my( $fh, $vars ) = @_;
print $fh generate_results( $vars );
}
------------------------------
Date: Mon, 09 Mar 2009 14:53:23 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: software design question
Message-Id: <x7mybuh3rg.fsf@mail.sysarch.com>
>>>>> "bdf" == brian d foy <brian.d.foy@gmail.com> writes:
bdf> In article <slrngra85m.ijf.glennj@smeagol.ncf.ca>, Glenn Jackman
bdf> <glennj@ncf.ca> wrote:
>> Name your subroutines to describe what they're doing:
>>
>> FIRST OPTION: print generate_content( \@vars );
>> SECOND: emit_results( \@vars );
>>
>> Personally, I'd favour the second. It would also lend itself to acting
>> as a dispatcher should you choose to output results in different
>> formats (html, csv, etc)
bdf> I like to have both of those. One always returns the content as a
bdf> string, and one prints to a filehandle:
bdf> emit_results( $fh, \@vars ); # $fh is any sort of handle
bdf> sub generate_results { ... }
bdf> sub emit_results {
bdf> my( $fh, $vars ) = @_;
bdf> print $fh generate_results( $vars );
bdf> }
i don't see the major win having a separate emit routine. it is just the
one line print statement so you have more code for little benefit. if
you needed to print it in many places it could be a minor savings.
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: Mon, 09 Mar 2009 14:55:25 -0500
From: Michael Austin <maustin@firstdbasource.com>
Subject: Re: Which Lisp to Learn?
Message-Id: <Wsetl.15335$as4.2169@nlpi069.nbdc.sbc.com>
Arne Vajhøj wrote:
> Xah Lee wrote:
>> For those of you imperative programers who kept on hearing about lisp
>> and is tempted to learn, then, ...
>
> You:
> * consider yourself unfairly treated by various communities
> * post a long drivel about various Lisp flavors to newsgroups
> that are not in any way Lisp related
> ?
>
> There seems to be a disconnect somewhere.
>
> Arne
Hey Arne - like he even knows what LISP is... ;)
------------------------------
Date: Mon, 09 Mar 2009 16:16:04 +0100
From: "M.O.B. i L." <mikaelb@df.lth.se>
Subject: Re: wxperl
Message-Id: <gp3brl$m5i$1@news.lth.se>
abcd wrote:
> suport wxperl all function which include in wx for c++?
"For the most part the wxPerl API closely mirrors the C++ API. When the
C++ and Perl API differ, a wxPerl-specific note in the manual explains
how the function calls translate to Perl."
<http://wxperl.sourceforge.net/documentation.html>.
I don't know more than this.
BTW I installed Wx (with OpenGL support) using cpan. It was very
difficult to do on Kubuntu 8.04 Hardy Heron because one has to install a
lot of development libraries. But in the end it worked.
------------------------------
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 2263
***************************************
