[24994] in Perl-Users-Digest
Perl-Users Digest, Issue: 7244 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Oct 14 06:06:50 2004
Date: Thu, 14 Oct 2004 03:05:07 -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 Thu, 14 Oct 2004 Volume: 10 Number: 7244
Today's topics:
Re: [newbie] shtml question <nospam@bigpond.com>
Re: [newbie] shtml question <noreply@gunnar.cc>
Re: hard references/arrays <tintin@invalid.invalid>
Re: HTML::Parser and <p> behaviour? <geoff.cox@removethisplease.freeuk.com>
Re: HTML::Parser and <p> behaviour? <bigal187@removethis.rx.eastcoasttfc.com>
Re: HTML::Parser and <p> behaviour? <geoff.cox@removethisplease.freeuk.com>
Re: HTML::Parser and <p> behaviour? <spambiat@yahoo.com>
Re: HTML::Parser and <p> behaviour? <spambiat@yahoo.com>
Re: HTML::Parser and <p> behaviour? <geoff.cox@removethisplease.freeuk.com>
Re: HTML::Parser and <p> behaviour? (Anno Siegel)
Re: localizing %SIG handlers (Anno Siegel)
Re: odd problem with open() <Joe.Smith@inwap.com>
Re: odd problem with open() <bigal187@removethis.rx.eastcoasttfc.com>
Re: Sorting Array of String Backward (Randal L. Schwartz)
Re: Top 10 list algorithm <someone@example.com>
Top posting (was Re: Concatenating an array into one st <spikeywan@bigfoot.com>
Re: Trying to force 32-bit in pack() <Joe.Smith@inwap.com>
Re: undef takes forever (Anno Siegel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 14 Oct 2004 17:12:33 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: [newbie] shtml question
Message-Id: <2t6n72F1t6ehdU1@uni-berlin.de>
Larry wrote:
> In article <5aj042-rj5.ln1@osiris.mauzo.dyndns.org>,
> Ben Morrow <usenet@morrow.me.uk> wrote:
>
>> Idiot.
>
>
> Mr. Ben Morrow , the idiot one is you.
Hardly, he's well respected in the Perl community, and you are unlikely to
get meaningful replies to your questions in the future.
gtoomey
------------------------------
Date: Thu, 14 Oct 2004 11:47:09 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: [newbie] shtml question
Message-Id: <2t70iqF1q13kqU1@uni-berlin.de>
Gregory Toomey wrote:
> Larry wrote:
>> Ben Morrow wrote:
>>>
>>> Idiot.
>>
>> Mr. Ben Morrow , the idiot one is you.
>
> Hardly, he's well respected in the Perl community,
Which tells us that even well respected persons say idiotic things at
times.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Thu, 14 Oct 2004 20:09:16 +1300
From: "Tintin" <tintin@invalid.invalid>
Subject: Re: hard references/arrays
Message-Id: <2t6muvF1pvq0pU1@uni-berlin.de>
"Paul Lalli" <mritty@gmail.com> wrote in message
news:Bm9bd.5421$275.4070@trndny01...
> "Tintin" <tintin@invalid.invalid> wrote in message
> news:2t495mF1s5ereU1@uni-berlin.de...
>> I'm wanting to set up a loop of array names like:
>
> No you don't. First read
> perldoc -q "variable name"
> and then search Google for the absurdly large number of posts dealing
> with "variable as a variable name" and "symrefs", including more than a
> few in the last week.
Yes, I am painfully aware of the gazillion questions along those lines.
Notice I said "like", meaning, what is the correct way of doing this.
>
>> #!/usr/bin/perl
>> use strict;
>> use diagnostics;
>>
>> my (@name1, @name2, @name3);
>>
>> foreach my $array qw(name1 name2 name3) {
>
> Why would you want to loop through the *names* of the arrays instead of
> the arrays themselves?
Because I wanted to use the array name along with its data.
> Because you've ill-defined your problem. This is basically an XY issue.
> You have issue X, which is that you want to access each array one at a
> time. You've decided the solution to that is Y, to loop through the
> names of the arrays. Your method for Y doesn't work, so you're trying
> to figure out a different way of doing Y, instead of figuring out the
> proper way of doing X.
Quite likely true (see below).
> In the general case, loop through the arrays themselves instead of the
> array names:
> foreach my $arr (\@array1, \@array2, \@array3) {
> foreach my $row (@$arr) {
> print "$row\n";
> }
> }
OK, that shows me how to use hard references correctly. Thank you.
>
> HOWEVER, in this case all you're doing is printing each element of each
> array, followed by a newline. Why even bother looping?
>
> {
> local $, = "\n";
> print @array1, @array2, @array3;
> }
> print "\n";
Now that's a useful piece of code, however let me wind the clock right back
and explain what I'm trying to do, ie: X.
I'm reading in a fields from a text file to be loaded into a database.
There are various sets of data that can have 1-6 lines of information. For
example
Address1=1 fred st
Address2=suburb
Address3=city
In the database, there are 6 columns defined for the Address, so what I need
to do is read in the addresses (and ensure that I account for records with
less than 6 lines). Now there are at least 6 other data types like this.
What I'm currently doing is
foreach my $i (0..5) {
push @insert_record,$addresses[$i];
}
foreach my $i (0..5) {
push @insert_record,$elements[$i];
}
and so on, to build up an array used to insert a record into the database.
Using repeated code like that is a red warning sign saying that it can be
compacted, however I wasn't (still aren't) sure of the best way of handling
it.
Note that the loop is needed to pad out the insert_record array with undef
values if the array being referenced is less than 6 elements. This ensures
that the fields match those defined in the database.
Hopefully that explains things a little better.
------------------------------
Date: Thu, 14 Oct 2004 07:31:44 GMT
From: Geoff Cox <geoff.cox@removethisplease.freeuk.com>
Subject: Re: HTML::Parser and <p> behaviour?
Message-Id: <mdasm0lhpv0ijfd9s6lcroniaqipptid4h@4ax.com>
On 14 Oct 2004 00:07:44 GMT, "A. Sinan Unur"
<usa1@llenroc.ude.invalid> wrote:
>I think you probably want to emit the start and end tags only when the
>start and end callbacks are invoked. I tried to shorten your script to deal
>only with the p case:
Many thanks for the code below - it woks fine and I will try to get to
grips with how it achieves this. You can no doubt see that I do not
have a very good understanding of HTML::Parser !
Do you have any suggestions re possible HTML::Parser tutorial type
places on the net? I have looked but not found anything that starts
far enough back ...
I have now bought the Perl & LWP book by Sean Burke - any others
spring to mind?
Thanks again for your help.
Cheers
Geoff
>use strict;
>use warnings;
>
>package MyParser;
>use base qw(HTML::Parser);
>
>my ($in_p, $fh);
>
>sub register_fh { $fh = $_[1]; }
>
>sub start {
> my ($p, $t, $a, undef, $txt ) = @_;
>
> if ($t eq 'p') {
> $in_p = 1;
> print $fh '<p>';
> return;
> }
>}
>
>sub end {
> my ($p, $t, $txt) = @_;
>
> if ($t eq 'p') {
> $in_p = 0;
> print $fh "</p>\n";
> return;
> }
>}
>
>sub text {
> my ($p, $txt) = @_;
> print $fh $txt if ($in_p);
>}
>
>package main;
>
>my $p = MyParser->new;
>$p->register_fh(\*STDOUT);
>
>print <<HEADER;
><html>
><head>
><title>Test Output</title>
></head>
><body>
>HEADER
>
>$p->parse_file(\*DATA);
>
>print <<FOOTER;
></body>
></html>
>FOOTER
>
>__DATA__
><html>
><head>
><title>test</title>
></head>
>
><body>
>
><h2>test file</h2>
>
><p>The is some text which I am using to test whether para.pl using
>HTML::Parser will output all of the text in this paragraph in one
>paragraph, or, in two smaller paragraphs.</p>
>
>
></body>
></html>
------------------------------
Date: Thu, 14 Oct 2004 00:37:42 -0700
From: "187" <bigal187@removethis.rx.eastcoasttfc.com>
Subject: Re: HTML::Parser and <p> behaviour?
Message-Id: <2t6oieF1sinaeU1@uni-berlin.de>
A. Sinan Unur wrote:
> "187" <bigal187@removethis.rx.eastcoasttfc.com> wrote in
> news:2t6e85F1rvlp5U1@uni-berlin.de:
>
>> Tad McClellan wrote:
>>
>>> You are speaking from ignorance. Mighty embarrassing in such
>>> a public forum! Perhaps you should have waited until you could
>>> followup on something that you actually know something about.
>>>
>>> Geoff has proven a rather persistent disregard for the time
>>> of other people. We are here only to serve his needs, so it
>>> is no big deal if we have to work a little harder or ignore
>>> his threads.
>>
>> I am sorry I did nto know this at first.
>
> ...
>
>> I'm not a bad person, I am in fact a tech as well. I love Perl
>
> Well, clearly. Why else would you read this group?
Good point.
> OTOH, I would think that someone who wishes to appear friendly might
> want to avoid the nickname '187'.
Why is that? This is how I uniquely identify myself. If "187" means
something else that I am not awre of please let me know. Other wise I
can go back ot posting under my name "Al" (which also appears in my
email address.)
> As for my reaction to the OP, I find it particularly unproductive and
> annoying to blame the package rather than look for an error in one's
> own code. This was especially so since the OP provided no code of his
> own which we could have looked at to test his assertion that the
> package was somehow at fault.
True. I do admit I was quick to judge and I'm sorry for snapping at you.
> Referring to the original post:
>
> Geoff Cox <geoff.cox@removethisplease.freeuk.com> wrote in
> news:irtqm0lj618tedv6hsr8od6db5821b2h6b@4ax.com:
That has got to be the longest message ID I've ever laid eyes on
(between 'news:' amd '@ax.com'.)
>> I cannot seem to work out how HTML::Parser deals with <p> text </p>
>> from an html file ...
>>
>> It breaks up a paragraph by placing a </p> <p> inside a paragraph of
>> text in what seems to me to be a random fashion...
>
> The "It" in the second paragraph surely refers to HTML::Parser.
>
> I stand by my belief that this is a "stupid" way to approach
> programming problems. One should ask
>
> + Here is what I am doing
> + Here is what I would like to have happen
> + Instead, here is what is happening
> + What am I doing wrong?
>
> Repeatedly ignoring this advice brings to mind the extremely apropos
> maxim (I am probably misquoting this):
Agreed. No arguements here.
> once is happenstance, twice coincidence, thrice is enemy action
>
> and deserves a somewhat harsher than the usual mild reminder that the
> OP read the posting guidelines.
All understood. I am once again sorry, and hope there are no hard
feelings.
------------------------------
Date: Thu, 14 Oct 2004 07:38:51 GMT
From: Geoff Cox <geoff.cox@removethisplease.freeuk.com>
Subject: Re: HTML::Parser and <p> behaviour?
Message-Id: <gnasm0th5knbf6kh6e7pv3jmaj18ahl082@4ax.com>
On Wed, 13 Oct 2004 21:56:38 -0500, Tad McClellan
<tadmc@augustmail.com> wrote:
>If you show us your code, we might be able to help fix it.
>
>Make a short and complete program *that we can run* that shows
>this phantom "</p> <p>" thing, and we will explain to you
>how it got there.
Tad,
Fascinating to have my character analysed by you all as if I no longer
existed!
I am sure you are correct in saying that I have previously failed to
provide useable code for testing. My fault, my apologies.
If you look will see that I have corrected that in another posting in
this thread which has allowed a very helpful answer.
In my first posting here my assumption was that there would be
something so obvious that people better versed in HTML::Parser would
have no problem seeing what was wrong.
I do accept that a small bit of code would have been better.
Cheers
Geoff
>
>
>Why not follow the suggestions given in the Posting Guidelines?
>
>If you had, the question would have been answered already instead
>of another of your round-and-round threads where there is not
>enough information given to be able to solve the problem.
>
>Post a small program. We will fix it.
------------------------------
Date: Thu, 14 Oct 2004 00:46:43 -0700
From: "Fred Canis" <spambiat@yahoo.com>
Subject: Re: HTML::Parser and <p> behaviour?
Message-Id: <cklao2$hir$1@news.astound.net>
David H. Adler wrote:
> On 2004-10-14, Fred Canis <spambiat@yahoo.com> wrote:
> / Tad McClellan wrote:
> /
> / | There is a significant history here that I appear to be ignorant
> / | of.
> /
> / If you mean the history of the OP, well I think it's hardly fair to
> / exact everyone who posts or read here to keep track of the posting
> / histroy of every poster. It doesn't mean it couldn't be checked, of
> / course it could, but I do not think it right at all to give someone
> / such a thorough beating for missing one. I hardly think this is been
> / such a heinous offense.
>
> I think tad's point is that if one is going to lambaste people for
> their response to a toaster, one might check whether there is some
> reason for that response, rather than that one should check the
> posting history relevant to any given thread.
I think the overall problem is the initial responses in this thread came
out very harsh, and it should come as no suprise that some if not many
people will see that as needly negativity. Though in this case one
should of checked up on this one.
------------------------------
Date: Thu, 14 Oct 2004 00:54:38 -0700
From: "Fred Canis" <spambiat@yahoo.com>
Subject: Re: HTML::Parser and <p> behaviour?
Message-Id: <cklb6t$hmm$1@news.astound.net>
Geoff Cox wrote:
> On Wed, 13 Oct 2004 21:56:38 -0500, Tad McClellan
> <tadmc@augustmail.com> wrote:
>
>
>> If you show us your code, we might be able to help fix it.
>>
>> Make a short and complete program *that we can run* that shows
>> this phantom "</p> <p>" thing, and we will explain to me
>> how it got there.
>
> Tad,
>
> Fascinating to have my character analysed by you all as if I no longer
> existed!
>
> I am sure you are correct in saying that I have previously failed to
> provide useable code for testing. My fault, my apologies.
>
> If you look will see that I have corrected that in another posting in
> this thread which has allowed a very helpful answer.
Keep in mind that the order the psots come down a given news feed isn't
guarenteed; in all probability, he may not to have seen it yet.
> In my first posting here my assumption was that there would be
> something so obvious that people better versed in HTML::Parser would
> have no problem seeing what was wrong.
In all probability, that might of been so, but heres a question: did you
look at the perdoc for that module? Maybe there answer is there.
> I do accept that a small bit of code would have been better.
Just strip it down to the smallest bit of code that demonstrates your
problem.
> Cheers
>
> Geoff
>
>
>
>>
>>
>> Why follow the suggestions given in the Posting Guidelines?
>>
>> If you had, the question would not have been answered already instead
>> of another of your round-and-round threads where there is enough
>> information given to be able to solve the problem.
>>
>> Post a small program. We will fix it.
------------------------------
Date: Thu, 14 Oct 2004 08:35:48 GMT
From: Geoff Cox <geoff.cox@removethisplease.freeuk.com>
Subject: Re: HTML::Parser and <p> behaviour?
Message-Id: <jgesm0ta73kn930pugkdn108esgmguq3hn@4ax.com>
On Thu, 14 Oct 2004 00:54:38 -0700, "Fred Canis" <spambiat@yahoo.com>
wrote:
>In all probability, that might of been so, but heres a question: did you
>look at the perdoc for that module? Maybe there answer is there.
Fred
I did look but sometimes a doc starts just too far ahead to be useful
..!
Cheers
Geoff
>
>> I do accept that a small bit of code would have been better.
>
>Just strip it down to the smallest bit of code that demonstrates your
>problem.
>
>> Cheers
>>
>> Geoff
>>
>>
>>
>>>
>>>
>>> Why follow the suggestions given in the Posting Guidelines?
>>>
>>> If you had, the question would not have been answered already instead
>>> of another of your round-and-round threads where there is enough
>>> information given to be able to solve the problem.
>>>
>>> Post a small program. We will fix it.
>
------------------------------
Date: 14 Oct 2004 10:00:05 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: HTML::Parser and <p> behaviour?
Message-Id: <cklin5$juo$2@mamenchi.zrz.TU-Berlin.DE>
187 <bigal187@remove.rx.eastcoasttfc.com> wrote in comp.lang.perl.misc:
> Tom wrote:
> > 187 wrote:
>
> [ snip unwarrented and non-sequitor drivel ]
>
> FYI I've programming, working networks, IT, and help desks since the
> 80's. You know nothing of me.
No, we don't, and claims to expertise impress no-one on Usenet.
Gain some credibility, then we might be inclined to consider
your opinions. Otherwise, opinions are like... well you know
what they are like.
Anno
------------------------------
Date: 14 Oct 2004 08:29:43 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: localizing %SIG handlers
Message-Id: <cklddn$juo$1@mamenchi.zrz.TU-Berlin.DE>
Ben Morrow <usenet@morrow.me.uk> wrote in comp.lang.perl.misc:
>
> Quoth anno4000@lublin.zrz.tu-berlin.de (Anno Siegel):
> > Ben Morrow <usenet@morrow.me.uk> wrote in comp.lang.perl.misc:
> > >
> > > There are two possible ways out, AFAICT. The first is that assigning
> > > undef to a member of %SIG currently has undefined effects. In fact, what
> > > happens is that any assigned value that 1. isn't a glob or a reference
> > > and 2. stringifies to the empty string causes the signal handler to be
> > > set to SIG_DFL. At the potential risk of breaking programs that rely on
> > > the (undocumented) consequence that $SIG{FOO} = undef; is equivalent to
> > > $SIG{FOO} = 'DEFAULT'; it would be relatively trivial to change
> > > mg.c:Perl_magic_setsig to cause undef to leave the signal handler
> > > unchanged, instead of setting it to the default.
> >
> > Ah, but that would mean that a pristine $SIG{FOO} wouldn't be restored
> > after { local $SIG{ FOO} = \&something }. \&something would stick,
> > which is certainly unexpected.
>
> OK, so initialise all of %SIG to 'DEFAULT' rather than to undef
> (especially as that's what it's implicitly initialised to anyway). Then
> when Perl restores the 'DEFAULT' at the end of the block it will restore
> SIG_DFL.
But that would break... Oh, never mind. This discussion really
should be on p5p.
[...]
> > In the particular case, the solution was to scratch local(). It
> > was only there out of orderliness in the first place :)
>
> Yes. However, it *ought* to work: the reason local is useful is because
> it's so hard to catch all the exits from a dynamic scope.
Yes. "{ ...; next; ... } continue { $SIG{ FOO} = ... }" is ersatz
at best.
Anno
------------------------------
Date: Thu, 14 Oct 2004 08:40:18 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: odd problem with open()
Message-Id: <SXqbd.254499$3l3.94379@attbi_s03>
Colin Howarth wrote:
> sub do_dir {
> while ($file = readdir(DIR)) {
> if (-d "$dir/$file") {
> do_dir("$dir/$file");
It is not a good idea to call readdir() in scalar context when doing
recursion. An older version of perl would lose its place in the
parent readir() when the subdirectory readdir() started.
If you're going to re-invent the wheel that has already been solved
via File::Find, be sure to use lexical file handles and dir handles,
not global ones.
-Joe
------------------------------
Date: Thu, 14 Oct 2004 01:49:47 -0700
From: "187" <bigal187@removethis.rx.eastcoasttfc.com>
Subject: Re: odd problem with open()
Message-Id: <2t6spiF1ra4krU1@uni-berlin.de>
Joe Smith wrote:
> Colin Howarth wrote:
>
>> sub do_dir {
>> while ($file = readdir(DIR)) {
>> if (-d "$dir/$file") {
>> do_dir("$dir/$file");
>
> It is not a good idea to call readdir() in scalar context when doing
> recursion. An older version of perl would lose its place in the
> parent readir() when the subdirectory readdir() started.
This is a work arond I once imployed in a some what similar situation
(as far as using a file handle of the same name multiple time from the
result of recursion) :
sub do_dir {
# makes sure DIR from resursive calls to do_dir() don't clash.
local *DIR; # localize file handle.
#-------------------------------------------------------------
while ($file = readdir(DIR)) {
if (-d "$dir/$file") {
do_dir("$dir/$file");
[...]
> If you're going to re-invent the wheel that has already been solved
> via File::Find, be sure to use lexical file handles and dir handles,
> not global ones.
Good mudule. Just FYI, for the last part of the sentance, my addition to
the OP's code applies as well :-)
------------------------------
Date: 14 Oct 2004 01:23:24 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Sorting Array of String Backward
Message-Id: <1097742805.7oOayfy4JEmjQwJHXwy46A@teranews>
>>>>> "nntp" == nntp <nntp@rogers.com> writes:
nntp> I have an array of strings I need to sort from backward, such as in this
nntp> order.
nntp> cba
nntp> dba
nntp> eba
nntp> I perldoc -f sort, but I can not see it has this feature. Basically, if I
nntp> can reverse the string, sort them, then rever them back will do the trick.
nntp> The reverse function in perl only do on arrays not on strings.
@sorted = map scalar reverse, sort map scalar reverse, @input;
Whee. :)
--
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: Thu, 14 Oct 2004 07:55:01 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: Top 10 list algorithm
Message-Id: <phqbd.1961$cr4.861@edtnps84>
Shawn Corey wrote:
>
> The reason why your routine is so much faster is that it does not do
> heap operations for each item. heap_each() does (that's what each
> means), and is therefore very slow. However your routine has inspired a
> change in my simple routine that blows the socks off everything else.
>
> Also I corrected a bug in it that is not a bug. At least it did what I
> wanted and didn't complain about it. I leave it as an exercise to the
> reader to find the change.
>
>
> use constant SIZE => 10;
> my $seed = time;
>
> sub simple {
> my @top = ( 0 ) x SIZE;
>
> srand( $seed );
> for my $i ( 1 .. 10_000 ){
> my $num = rand();
> next if $num < $top[-1];
> my $j = $#top;
> for( $j = $#top; $j >= 0; $j -- ){
> if( $top[$j] > $num ){
> @top = ( @top[ 0 .. $j ], $num, @top[ $j + 1 .. $#top ] );
Why not use splice? :-)
splice @top, $j + 1, 0, $num;
> pop @top;
> last;
> }
> }
> if( $j < 0 ){
> unshift @top, $num;
> pop @top;
> }
> }
>
> # print "@top\n";
> }
John
--
use Perl;
program
fulfillment
------------------------------
Date: Thu, 14 Oct 2004 10:00:23 +0100
From: "Richard S Beckett" <spikeywan@bigfoot.com>
Subject: Top posting (was Re: Concatenating an array into one string?)
Message-Id: <cklfc8$3ms$1@newshost.mot.com>
> One of the prime sins to avoid is top-posting and fully quoting someone
> else's post without actually referring to any part of it.
>
> Have fun learning.
>
> Sinan.
One small question about this...
In some news groups, they get upset if you top post, because they like the
entire thread to be visible in each post from the top down. This means that
you can pick any individual post, read from the top, and get the gist of the
entire thread.
In other newsgroups they much prefer people to top post. This means that if
you've been reading the thread from the beginning, you don't have to trawl
through everything that you've already read to find the latest comment, as
it's there right at the top. If you do need to read back, then the
information is still there.
Both systems have their merits, and I can understand why the people in some
groups opt for one style, and the people in other groups opt for the other
style.
However, if a person reads many newsgroups, it's a very difficult thing for
them to know whether they're supposed to top post or bottom post in a
particular newsgroup.
As long as the pertinent information is there, who is to say which style is
correct?
Can someone please get a ruling from God or something as to which system we
should use across ALL newsgroups, so we can put this to bed once and for
all, 'cause I'm getting really pissed off by the anal twats who insist that
people must post at the bottom in one newsgroup, and then a different bunch
of anal twats who insist that you must post at the top in another group!
Thanks.
R.
------------------------------
Date: Thu, 14 Oct 2004 08:53:01 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: Trying to force 32-bit in pack()
Message-Id: <N7rbd.388821$Fg5.190540@attbi_s53>
Brad Walton wrote:
> I got it to work. After some research (emails), I found out it needed
> little-endian 32 bit 'V'. Thanks again for your help. It is appreciated!
In the case of a protocol that you've invented yourself, it does not make
much difference when using V instead of N, as long as both ends agree
and are the same endian-ness. But if you intend to talk to another
machine that is not based the the x86 architecture, you need to use
the network-byte-order (n and N).
-Joe
------------------------------
Date: 14 Oct 2004 08:10:17 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: undef takes forever
Message-Id: <cklc99$ii1$1@mamenchi.zrz.TU-Berlin.DE>
Ben Morrow <usenet@morrow.me.uk> wrote in comp.lang.perl.misc:
>
> Quoth anno4000@lublin.zrz.tu-berlin.de (Anno Siegel):
> > Bart Lateur <bart.lateur@pandora.be> wrote in comp.lang.perl.misc:
> > > KKramsch wrote:
[...]
> > > I think the extra slowness is due to your memory being full,causing
> > > extensive swapping.
> > >
> > > I'd try to move the check to an external script, which needn't be so
> > > careful about carefully releasing all memory. If necessary, you can
> > > shortcircuit the garbage collection for that external script using a
> > > carefully chosen exec().
> >
> > How so? Did you mean exit()?
>
> A common trick for programs which leak, at least on Unix, is to re-exec
> yourself every so often (having arranged things so you can get back into
> the state you were in, of course), which will 'deal' with the leaks.
Oh, right.
> I'm not sure if this applies here though: will perl go through a full GC
> run if you exec, even though it doesn't need to free the memory? I guess
> it may, in order to call DESTROY handlers...
Apparently not. From the Camel:
It [END and DESTROY] isn't run if, instead of exiting, the current
process just morphs itself from one program to another via exec.
I can't find the equivalent passage in perldoc.
Anno
------------------------------
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 V10 Issue 7244
***************************************
