[23887] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 6090 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 6 18:10:41 2004

Date: Fri, 6 Feb 2004 15:10:10 -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           Fri, 6 Feb 2004     Volume: 10 Number: 6090

Today's topics:
    Re: Need help passing arrays by reference pls. (G Klinedinst)
    Re: Need help passing arrays by reference pls. (Walter Roberson)
    Re: Need help passing arrays by reference pls. (G Klinedinst)
    Re: Need help passing arrays by reference pls. (Walter Roberson)
    Re: NNTP Subject Parsing (Peter Scott)
    Re: Optimization request <ebohlman@earthlink.net>
        Perl and WMI (seldn)
    Re: Perl data types (Aaron Sherman)
    Re: Perl For Amateur Computer Programmers <bik.mido@tiscalinet.it>
    Re: perl identifier limits <troc@pobox.com>
    Re: perl identifier limits <uri@stemsystems.com>
        Perl script into a Windows Service (Cosmic Cruizer)
    Re: Perl's read() vs. sysread() (Walter Roberson)
        Req.for Advice: Learning Perl <none@hotmail.com>
    Re: Req.for Advice: Learning Perl <ebohlman@earthlink.net>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: 6 Feb 2004 13:17:54 -0800
From: g_klinedinst@hotmail.com (G Klinedinst)
Subject: Re: Need help passing arrays by reference pls.
Message-Id: <168f035a.0402061317.7b9ad23f@posting.google.com>

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in message news:

> Looks like you have a precidence problem. @$_[0] is {@{$_}}[0]
> Your code will work if you use
> 
>      my @subArr1 = @{$_[0]};
>      my @subArr2 = @{$_[1]};

Thanks, that worked perfectly. I see what I was doing now. 

> I would, though, recommend using prototypes and declaring sub test
> before it is used:
> 
>   sub test( \@\@ ) {
>        my @subArr1 = @{$_[0]};
>        my @subArr2 = @{$_[1]};
>        # ...
>   }
> 
>   test @arr1, @arr2;
>
> Notice there that you do NOT explicitly \ the arrays as you pass them in.

Yep, I am just not sure why. I will need to study the docs this
weekend and figure out what you are doing here.

 
> Personally, I wouldn't take a copy of the array in the sub unless
> I had a reason to. I would use something akin to
> 
>    sub test( \@\@ ) {
>       my ($subArr1_ref, $subArr2_ref) = @_;
>       print $subArr1_ref->[0] . ':' . scalar( @$subArr1_ref ) . "\n"; 
>       print $subArr2_ref->[0] . ':' . scalar( @$subArr2_ref ) . "\n"; 
>    }

Makes sense. The reason I am making a local copy is that I am going to
be iterating through them(using a for loop). With your syntax I'm not
sure how I would go about that. For example I will be doing something
like this:

for my $a ( @subArr1 ) {
    print $a;
}

If I can figure out how to do that using the references, like you are
using I will do that otherwise I will have to make a local copy.
Thanks again.


-Greg


------------------------------

Date: 6 Feb 2004 21:34:14 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: Need help passing arrays by reference pls.
Message-Id: <c0118m$61g$1@canopus.cc.umanitoba.ca>

In article <168f035a.0402061317.7b9ad23f@posting.google.com>,
G Klinedinst <g_klinedinst@hotmail.com> wrote:
:Makes sense. The reason I am making a local copy is that I am going to
:be iterating through them(using a for loop). With your syntax I'm not
:sure how I would go about that. For example I will be doing something
:like this:

:for my $a ( @subArr1 ) {
:    print $a;
:}

:If I can figure out how to do that using the references, like you are
:using I will do that otherwise I will have to make a local copy.

print $_ foreach @$subArr1_ref

Similarily,

print "$_: $hash_ref->{$_}\n" foreach (keys %$hash_ref);

print $$scalar_ref, "\n"
-- 
Warning: potentially contains traces of nuts.


------------------------------

Date: 6 Feb 2004 13:49:19 -0800
From: g_klinedinst@hotmail.com (G Klinedinst)
Subject: Re: Need help passing arrays by reference pls.
Message-Id: <168f035a.0402061349.79d8b12b@posting.google.com>

> Life would be much easier if you did:
> 
> #! perl
> 
> use strict;
> use warnings;
> 
> my @arr1 = (1, 2, 3);
> my @arr2 = (4, 5, 6);
> 
> $arr1[0] = 1;
> 
> print $arr1[0], ':', scalar @arr1, "\n" ;
> print $arr2[0], ':', scalar @arr2, "\n" ;
> 

Unfortunately the arrays hold an index to another array, which
basically tells which input fields were filled out, so some of the
arrays are going to be empty(due to the user not entering any data at
that position).


> # You should avoid the unnecessary concatenations you had in your code.
> 
> print "\n\n" ;
> 
> test(\@arr1, \@arr2);
> 
> sub test {
>     my ($subArr1, $subArr2) = @_;
> 
>     print $subArr1->[0], ':', scalar @{$subArr1}, "\n" ;
>     print $subArr2->[0], ':', scalar @{$subArr2}, "\n" ;
> }

Why is that? Are the commas implemented faster, or just for
readability? Just curious. It's a habit I picked up from Java so now
even my Perl code looks like that. It's hard to break coding habits
once you get into them. Thanks for your help, and I hope things are
starting to warm up there in Ithaca for you.

-Greg


------------------------------

Date: 6 Feb 2004 22:00:22 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: Need help passing arrays by reference pls.
Message-Id: <c012pm$6op$1@canopus.cc.umanitoba.ca>

In article <168f035a.0402061349.79d8b12b@posting.google.com>,
G Klinedinst <g_klinedinst@hotmail.com> wrote:
:> # You should avoid the unnecessary concatenations you had in your code.

:Why is that? Are the commas implemented faster, or just for
:readability?

Commas in print's are converted into concatenation internally, so both
have the same execution speed.

Sometimes, though, if you use concatenation, you can end up
with unexpected results because of precidence issues. Just a couple
of days ago, I had something of the form

  print Operation Argument . Somestring

and Operation was being applied to  Argument . Somestring
instead of Operation Argument being computed and Somestring being
concatenated on the end. My fault for not thinking about precidences.
Changing to , instead of . fixed the code.
-- 
   Will you ask your master if he wants to join my court at Camelot?!


------------------------------

Date: Fri, 06 Feb 2004 16:05:21 GMT
From: peter@PSDT.com (Peter Scott)
Subject: Re: NNTP Subject Parsing
Message-Id: <5XOUb.419400$ts4.210346@pd7tw3no>

In article <IBwUb.13166$IF1.3217@nwrdny03.gnilink.net>,
 $_@_.%_ writes:
>Does anyone know where i could find some information
>about parsing NNTP subject fields?
>
>Psuedo Code and/or RegExp advise would be ideal.
>
>Im looking to parse out multipart messages.
>ie: Test Subject (1/1) - file.bin [01/10]
>     Another test.bin (1/2)
>
>Then store them untill all the parts have been gathered.

Are you trying to duplicate the functionality of this:

	http://linux.maruhn.com/sec/aub.html
	http://yukidoke.org/~mako/projects/aub/

Written in Perl to boot.

-- 
Peter Scott
http://www.perldebugged.com/
*** NEW *** http//www.perlmedic.com/


------------------------------

Date: 6 Feb 2004 22:17:27 GMT
From: Eric Bohlman <ebohlman@earthlink.net>
Subject: Re: Optimization request
Message-Id: <Xns9487A6203889Aebohlmanomsdevcom@130.133.1.17>

Tore Aursand <tore@aursand.no> wrote in
news:pan.2004.02.05.15.29.03.543225@aursand.no: 

> On Thu, 05 Feb 2004 13:58:34 +0000, Guru03 wrote:
>> For you, it's faster this:
>> 
>> s/>/&gt;/g;
>> 
>> or this:
>> 
>> s/>/&gt;/g if index ($_, '>');
>> 
>> and why?
> 
> Isn't it obvious that the first one is faster?  Your last line of code
> requires Perl to do _two_ things, while the first one only do one
> thing; 

It's actually not all that obvious, since both methods only require perl to 
do *one* thing for inputs that don't contain any &gt;s.  Plainly if each 
input processed contains one or more &gt;s then your observation will be 
correct (assuming there's no possible interaction between the index() and 
the substitution).  If not, it will depend on whether or not a non-matching 
substitution that searches for a simple literal is faster or slower than a 
call to index(), and whether or not this difference scales up or down with 
the length of the string to be searched.

It's often the case that one method is more efficient in most circumstances 
but less efficient in others.  For example, the general runtime behavior of 
an insertion sort is O(N^2) whereas the general runtime behavior of a 
quicksort is O(N log N), but an insertion sort can actually run faster in 
the case (which used to be quite common in the days of tapes and cards) 
where the data to be sorted consists of a large amount of in-order data 
followed by a much smaller amount of unsorted data.


------------------------------

Date: 6 Feb 2004 08:19:00 -0800
From: seldn@hotmail.com (seldn)
Subject: Perl and WMI
Message-Id: <5dd9b03b.0402060819.407264d8@posting.google.com>

Hello all.

I use Perl for intranet applications and Unix systems administration
on an HP-UX platform.  I have recently been tasked with collecting
system information from Windows servers.  I'd really like to keep
using Perl for this if possible.  Visual Basic is just not my cup of
tea.

I know how to query the WMI in VBScript to get system information,
however, can this also be done in Perl?  I've downloaded and installed
ActiveState Perl; I guess what I'm looking for now is the best modules
that can be used for this task.

I'm surfing CPAN right now; opinions and advice would be helpful.

Thanks,
Tom


------------------------------

Date: 6 Feb 2004 10:43:13 -0800
From: ajs@ajs.com (Aaron Sherman)
Subject: Re: Perl data types
Message-Id: <eaa2c627.0402061043.5366d653@posting.google.com>

"Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote in message news:<bvu525$1hl$1@nets3.rz.RWTH-Aachen.DE>...
> Also sprach Malcolm Dew-Jones:

> >: > object.method()
> >: > 
> >: > instead, and let inheritance take care of what gets done, no?
>  
> >: No, not in Java. Due to broken-by-design method dispatch, you will
> >: constantly be checking the type and then do a typecast. If you have a
> >: class "Foo" with a method "bar" and you stuff 10 Foo objects into 
>  
> >:     Object array[10];
> > 
> > If they are Foo objects, then why pretend they are just generic Objects?  
> > Why not stuff them into

> Too bad that you sometimes have no choice. Just look at some of the
> classes in the Java API (like 'Collection' or so). They all cast their
> objects down to the most generic class 'Object'.

I think you are misunderstanding Java.

The entire reason that your have to lug around vtables is so that
polymorphism will work as you expect. Otherwise, polymorphism is only
one-way any your life is most unpleasant.

Example:

 class AJSClass1 {
    public static void main(String[] args) {
        AJSClass3 foo = new AJSClass3();
        AJSClass2 bar = foo;
        System.out.println(bar.hello());
    }
 }

 class AJSClass2 {
        public String hello() {
                return "Hello";
        }
 }

 class AJSClass3 extends AJSClass2 {
        public String hello() {
                return "World";
        }
 }

If that didn't print "World", we'd be in pretty sad shape (well, those
who use Java would be, I'm not one of those -- I had to go search
language references just to remember how to declare main ;-)

> Java simply is lacking things like C++ templates. Note that C++ would
> become pretty unprogrammable if you didn't have them for the sake of
> genericity and polymorphism.

C++ does not use templates for what you describe above. C++ uses the
same vtable management (in general, though specifics of implementation
differ) as Java. Templates allow CODE to be polymorphic right along
with the objects that the code works on.

> Yes, occasionally. But this happens at runtime. In Java the thing wont
> even compile. Also, please count the occurances of can() and isa() in
> Perl code and compare the number to 'instanceof' and typecasts in Java
> programs.

The reason you use can() or isa() in Perl is (I would assume) much the
same reason that you would use the equivalents in Java: to know if an
object that you have been handed is capable of performing some task.

Now, in Java you have the option of using type-checking to tell you
that up-front if you have designed your class structure correctly. In
Perl, you have to do it manually, because Perl's types are too dynamic
to impose such restrictions (I think Perl 6 aims to allow such
restrictions, though).

> Often enough I had to program in Java and each time I got sick of these
> (deliberate, I may add) limitations of this language.

I think you got stuck with some bad documentation or poorly written
libraries.


------------------------------

Date: Sat, 07 Feb 2004 21:33:49 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl For Amateur Computer Programmers
Message-Id: <351a20lj7pojbb6turutj5l4h9ljhpb2fv@4ax.com>

On Thu, 5 Feb 2004 18:00:03 -0500, "Matt Garrish"
<matthew.garrish@sympatico.ca> wrote:

>And to avoid the inevitable "well stop whining about it and do something"
>responses, I may just work on a script to build a more user-friendly html
>interface to the existing docs.

Taking into account that I rarely use the HTML form of the docs, but
as far as they are concerned, I find them next to as terse and nice as
possible, I really wish you succeed in you purpose: the result should
be impressive!


Michele
-- 
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
  "perl bug File::Basename and Perl's nature"


------------------------------

Date: Fri, 06 Feb 2004 16:42:52 GMT
From: Rocco Caputo <troc@pobox.com>
Subject: Re: perl identifier limits
Message-Id: <slrnc27h3p.eu.troc@eyrie.homenet>

On Fri, 06 Feb 2004 18:50:28 +0900, Alex Shinn wrote:
> At Fri, 06 Feb 2004 09:36:23 GMT, Uri Guttman wrote:
>> 
>> >>>>> "AS" == Alex Shinn <foof@synthcode.com> writes:
>> 
>>   AS> Not that I'd write such a long identifier, but I've got auto-generated
>>   AS> code that reaches twice that length.  Any ideas apart from applying
>>   AS> compression algorithms to the id names?  Any plans on fixing this?
>> 
>> fix your code. i can't see any possible reason to generate names that
>> long. you would have to come up with some amazing reasons to support
>> your claim that you need it.
>
> You obviously don't write Perl with a Lisp mindset.  If you
> auto-generate code on the fly it is not always easy to design it such
> that names won't conflict.  In my case I'm working with an application
> server which can have a *huge* base of dynamically generated code.  A
> potential workaround is to use only hashtables and store anonymous
> subroutines in them, but this is far from an insignificant rewrite and
> looses some flexibility.  After googling I find I'm not the only one who
> has had this problem:
>
>   http://www.gossamer-threads.com/archive/mod_perl_C1/asp_F3/Identifier_Too_Long_Error_with_Long_Pathnames_P480/
>
> It's also a very silly & trivial bug in Perl, which is acknowledged as a
> known bug.  And Python does it right!

But it's a very rare problem to run into.  As such, it's not a pressing
issue for [wild guess] 99% of the people who use Perl.  As you feel
strongly about it, you may want to address the problem yourself and
submit a patch.

Or you can do the damsel in distress routine ("OH! HELP! SOMEONE PLEASE
HELP ME!") until some shining knight patches it for you.  For your sake,
I hope you're cute.  :)

While you're holding your breath, consider rolling your own symbol
table:  A hash of long identifiers mapped to computed short ones.  As
your program writes Perl source, it can translate the too-long symbols
into the short ones.

Sure, nobody will understand the generated source code.  You probably
don't want people editing it directly anyway, so the obfuscation acts as
a deterrent.

-- 
Rocco Caputo - rcaputo@pobox.com - http://poe..perlorg/


------------------------------

Date: Fri, 06 Feb 2004 18:23:35 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: perl identifier limits
Message-Id: <x73c9ot6c9.fsf@mail.sysarch.com>

>>>>> "AS" == Alex Shinn <foof@synthcode.com> writes:

  AS> At Fri, 06 Feb 2004 09:36:23 GMT, Uri Guttman wrote:
  >> 
  >> >>>>> "AS" == Alex Shinn <foof@synthcode.com> writes:
  >> 
  AS> Not that I'd write such a long identifier, but I've got auto-generated
  AS> code that reaches twice that length.  Any ideas apart from applying
  AS> compression algorithms to the id names?  Any plans on fixing this?
  >> 
  >> fix your code. i can't see any possible reason to generate names that
  >> long. you would have to come up with some amazing reasons to support
  >> your claim that you need it.

  AS> You obviously don't write Perl with a Lisp mindset.  If you

hell, i wouldn't do anything with a lisp mindset. i would rather toggle
in code by binary switches (done it) than have a lisp mindset.

  AS> auto-generate code on the fly it is not always easy to design it such
  AS> that names won't conflict.  In my case I'm working with an application
  AS> server which can have a *huge* base of dynamically generated code.  A
  AS> potential workaround is to use only hashtables and store anonymous
  AS> subroutines in them, but this is far from an insignificant rewrite and
  AS> looses some flexibility.  After googling I find I'm not the only one who
  AS> has had this problem:

  AS>   http://www.gossamer-threads.com/archive/mod_perl_C1/asp_F3/Identifier_Too_Long_Error_with_Long_Pathnames_P480/

that seems to be an asp problem as much as a perl one. why a path name
gets converted to a sub or identifier name is the question.

but the fact that is it tells me something.

the symbol table is not meant to be a general purpose hash structure. so
using it as such (via symrefs) is very dumb. you say you lose
flexibility by using hashes vs identifiers and that makes even less
sense than lisp mind. i would have done it with dispatch tables and
trees of them and had no issues with the names as i stay out of the
symtable unless i have to. you didn't have to do it but you chose
(wrongly) to use symbols for that. symbols are usually human written and
read so a limit of 255 chars is fine. hash keys have no length limit so
that is better for any auto generated stuff.

uri

-- 
Uri Guttman  ------  uri@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org


------------------------------

Date: Fri, 06 Feb 2004 21:52:52 GMT
From: XXjbhuntxx@white-star.com (Cosmic Cruizer)
Subject: Perl script into a Windows Service
Message-Id: <Xns94878D34DB897ccruizermydejacom@64.164.98.51>

For the last several months, I have been trying to turn a simple Perl script 
into a Windows 2000 service. I keep finding a lot of question about doing 
this in newsgroups, but I have yet to find an easy to follow solution. Can 
anybody recommend either a book, web page, article, or something that will 
help me out? It almost sounds like setting up a Perl script to run as a 
service is an urban legend. 

Thanks,


------------------------------

Date: 6 Feb 2004 19:32:30 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: Perl's read() vs. sysread()
Message-Id: <c00q4e$30a$1@canopus.cc.umanitoba.ca>

In article <c00do4$f46$1@wisteria.csv.warwick.ac.uk>,
Ben Morrow  <usenet@morrow.me.uk> wrote:

:jl_post@hotmail.com (J. Romano) wrote:
:>    I was wondering if anyone could tell me the differences between
:> Perl's read() function and its sysread() function. 

:The difference between the two sets is that read, print, etc. all
:buffer their IO.

That's certainly an important difference. There are sometimes other
differences as well.


:The only time to use sys* is when using select.

That's not the *only* time. Sometimes, some of the functionality
available via a systems fcntl() call are only available when you
use the sys* calls.


:Buffered IO is always more efficient when you can use it.

Not completely correct. In fact, not at all correct if you are
into low-level I/O wizardry. Buffered I/O -always- copies the data,
and there are situations where that data copy just isn't fast enough
(e.g., for streaming video.) If you want top efficiency, you have
to use the sysread() functions... or more likely, you have to drop
into XS and do some magic down there for proper buffer alignment.

If you want efficiency, you want *unbuffered* reads, and lots of
good reference manuals on hand... and you probably want DMA, and
direct I/O, and scatter-gather, and you want filesystems that
support real-time I/O and guaranteed bandwidth (e.g., xfs) and
you want ....
-- 
   IMT made the sky
   Fall.


------------------------------

Date: Fri, 06 Feb 2004 22:34:25 +0000
From: darren_uk <none@hotmail.com>
Subject: Req.for Advice: Learning Perl
Message-Id: <MDUUb.518$cb7.3935@newsfep4-glfd.server.ntli.net>

Request for Advice on Learning Perl.

I need to come up to speed with Perl quickly.

I own "Learning Perl" but find that I personally am better at looking at
simple (and not so simple) examples, and probably moving onto more complex
examples.

For example, browsing some of the "How2" postings in this newsgroup and
trying to understand the answers seems to steepen the learning curve for me
- possibly this is because I'm a problem solver by nature and have 15 years
of support experience so running through someone else's code and figuring
out what it does is just the way I work best.


Based on the above, can anyone offer any suggestions on the best way I can
learn Perl, I'm due to begin a project in about a week's time and I'm
encouraged to gain as much Perl insight as I can, with a view to not only
understanding existing Perl script on site, but also to eventually develop
my own.


Of course, I will also continue with Programming Perl throughout the
projects, getting better and better with each passing week, but I need
enough to give me the tools to be able to tackle the Perl scripts from day
one.

Many thanks for your help.


------------------------------

Date: 6 Feb 2004 23:00:19 GMT
From: Eric Bohlman <ebohlman@earthlink.net>
Subject: Re: Req.for Advice: Learning Perl
Message-Id: <Xns9487AD64A9427ebohlmanomsdevcom@130.133.1.17>

darren_uk <none@hotmail.com> wrote in
news:MDUUb.518$cb7.3935@newsfep4-glfd.server.ntli.net: 

> I need to come up to speed with Perl quickly.
> 
> I own "Learning Perl" but find that I personally am better at looking
> at simple (and not so simple) examples, and probably moving onto more
> complex examples.
> 
> For example, browsing some of the "How2" postings in this newsgroup
> and trying to understand the answers seems to steepen the learning
> curve for me - possibly this is because I'm a problem solver by nature
> and have 15 years of support experience so running through someone
> else's code and figuring out what it does is just the way I work best.

Sounds like _The Perl Cookbook_ is just the thing for you.


------------------------------

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 6090
***************************************


home help back first fref pref prev next nref lref last post