[24116] in Perl-Users-Digest
Perl-Users Digest, Issue: 6310 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 27 11:05:39 2004
Date: Sat, 27 Mar 2004 08:05:06 -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 Sat, 27 Mar 2004 Volume: 10 Number: 6310
Today's topics:
ANNOUNCE: HTML::Tmojo v0.300 (Will Conant)
Re: Choosing Perl/Python for my particular niche <tassilo.parseval@rwth-aachen.de>
Re: Choosing Perl/Python for my particular niche (Cameron Laird)
Re: Choosing Perl/Python for my particular niche <fma@doe.carleton.ca>
Re: Choosing Perl/Python for my particular niche <ptmcg@austin.stopthespam_rr.com>
Re: Choosing Perl/Python for my particular niche <roy@panix.com>
Re: Choosing Perl/Python for my particular niche (Jim Keenan)
Re: Choosing Perl/Python for my particular niche (Cameron Laird)
Re: Choosing Perl/Python for my particular niche (Cameron Laird)
Does anyone know what this switch does? <vunderink@t-online.de>
Re: Filehandles Referenced with a Variable (Myron Turner)
Re: Filehandles Referenced with a Variable (Peter Scott)
hashes , use strict readParse <pdconetwofour_numbers_@yahoo.co.uk>
Re: hashes , use strict readParse <pdconetwofour_numbers_@yahoo.co.uk>
Re: hashes , use strict readParse <noreply@gunnar.cc>
Loss of privledges in a perl app lvirden@yahoo.com
Re: Loss of privledges in a perl app <spamtrap@dot-app.org>
Tangent on embeddability (was: Choosing Perl/Python for (Cameron Laird)
Re: The "value" of a block in 'map' <spamhole@klaas.ca>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 27 Mar 2004 01:49:14 GMT
From: will@willconant.com (Will Conant)
Subject: ANNOUNCE: HTML::Tmojo v0.300
Message-Id: <Hv8rG1.H69@zorch.sf-bay.org>
HTML::Tmojo is a flexible, template-based content
generation engine. While it is particularly well suited
for generating HTML and XML documents, it can be used
effectively to produce any text output.
Key Features of Tmojo include:
- powerful yet clear template syntax
- 100% object-oriented templates
- excellent control over white-space in output text
- file and memory caching of compiled templates for
terrific performance
- customizable template loading
- very flexible template processing model
- "lite" templates which can be safely provided by
un-trusted 3rd parties
- works very well with mod_perl and CGI but is not at
all bound to them
HTML::Tmojo v0.300 is available now through CPAN and
from the Tmojo web site located at:
http://lab-01.com/tmojo
A deeper explanation of Tmojo, comprehensive
documentation, and information about the Tmojo E-Mail
List are also available at the above site.
------------------------------
Date: 27 Mar 2004 08:28:36 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <c43dvk$adq$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Fred Ma:
> This is not a troll posting, and I've refrained from
> asking because I've seen similar threads get all
> nitter-nattery. But I really want to make a decision
> on how best to invest my time. I'm not interested on
> which language is better in *general*, just for my
> purpose. My area of research is in CAD algorithms,
> and I'm sensing the need to resort to something more
> expedient than C++, bash scripting, or sed scripting.
> What I hope to do is a bit multifaceted. What I don't
> do dabble in is web apps (though I'm not sure of the
> similarities). No XML processing or database
> interaction in what I do.
Who knows, though. The desire to do certain things grows with the skills
one acquired.
> One thing I expect to have to do is to modify design
> files. For example, there is a tool which takes ASCII
> hardware desscription language (HDL) and converts it
> to a C++ (augmented by hardware simulation library).
> The translator is freeware, so has limitations which I
> have to make up for by tweaking the HDL code. In the
> past, I've eeked out sed scripts for such tasks, but
> would appreciate a more traditional language. Since
> Perl is used alot in digital IC design, I took a stab
> at that, motivated by the simple need to convert my
> mail aliases from one mail reader to the other. It
> took a while to do, and I'm concerned at the difficulty
> level. If I did this kind of thing constantly, I
> would probably get proficient and use the power behind
> it, but it's not my main area.
That sounds like a text-processing task. Perl's strengths in this area
are well-known, so there's no need to go into that deeper. Most
scripting languages (and that includes Python) can be used here.
> The alternative is Python, which is easier to read
> from what I've read. My concern there is that I cut
> myself off from large availability of stuff that's
> out there. For example, I use a PC-to-solaris
> viewer called VNC, and I've banged my head against the
> startup script to change it a bit for my situation.
> Likewise, the above translator uses Perl extensively
> in its operation, as well as it's building and
> installation. If I wasn't passingly familiar with
> Perl, I would have had a much harder time installing
> it. Being in the approximate area digit circuits,
> I'm concerned about being on the band wagon, if only
> to avoid reinventing things, or impediments to sharing
> things.
This is a strong reason to use Perl. While it may not always be
desirable to toe the line, here it is. The availability of tools that
can easily be integrated into one's own work will save you a lot of
work on the long run. I didn't know that Perl was particularly strong
in the field of IC design. If so, good then.
Apart from this particular case, it's generally a good thing when
pre-written code exists that can be used. The amount of such code for
Perl is immense (several thousand libraries) and gathered all in one
place (the CPAN) with a unified interface to access and install them and
a vast infrastructure built around it.
I don't know how much or whether at all the situation for Python has
significantly improved over the recent past. A while ago at least there
was no such thing.
> An additional usage scenario is to (if reasonable)
> replace my shell scripting e.g. I just converted to
> bash from tcsh to write scripts that push a document
> through a series of filters, or simply as a wrapper
> around a tough-to-use utility e.g. pstops. A final
> example is to take a file of design information and
> do more than tweak it e.g. extract all the information
> about interconnections between circuit building blocks,
> including which is the source block, and which are the
> destination blocks. Typically, this information will
> be read by matlab scripts and passed to my C++ code
> (I've managed to avoid writing code to parse the
> input file from C++).
As with text processing, both Python and Perl offer all the essential
things needed for that. On a cursory glance, the score of them is tied.
> Whichever way I go, I would like to avoid the overhead
> of learning both Perl and Python. I will sculpt out some
> time in a miserly fashion to slowly get to know one. Since
> I spend most of my time exploring the algorithm in Matlab or
> C++/STL, there's only so much time to pick up higher level
> languages (it took years before I shelled out the time
> to switch from tcsh to bash). One of the things that
> makes the decision not clear is that despite Python's
> claim to a gentler learning curve and clearer code, I
> often like the expedience of sed e.g. a terse one-liner
> that can be pipelined with other shell commands. I
> also note that Perl's unweldiness only comes for big
> projects, and I don't expect to using Perl quite that
> way.
Perl wins when it comes to one-liners and maybe replacing shell scripts.
As I tend to forget the syntax of bash's scripting language easily, I've
replaced it entirely with Perl.
Perl's bad reputation for big projects is probably due to the variance
of those people using Perl. One large group is sys-admins who use Perl
in an entirely different way as compared to someone building larger
systems. However, there are enough very large Perl projects that show
that it can be used for that just as easily (at least as long as one
keeps the sys-admins away from the source;-).
> I've seen mention of parrot and perl6, which is quite a
> ways off. I'm not sure how much that should weigh into
> my decision, since it isn't real yet.
It shouldn't. Perl6 is mostly yet another leap towards fitness for large
projects. I don't think it will gain much for those more hackish tasks.
Also, no one quite knows when Perl6 will be due.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Sat, 27 Mar 2004 10:19:59 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <106alaf403jgs54@corp.supernews.com>
In article <c43dvk$adq$1@nets3.rz.RWTH-Aachen.DE>,
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote:
>Also sprach Fred Ma:
.
.
.
>> purpose. My area of research is in CAD algorithms,
>> and I'm sensing the need to resort to something more
>> expedient than C++, bash scripting, or sed scripting.
.
.
.
>> One thing I expect to have to do is to modify design
>> files. For example, there is a tool which takes ASCII
>> hardware desscription language (HDL) and converts it
>> to a C++ (augmented by hardware simulation library).
>> The translator is freeware, so has limitations which I
>> have to make up for by tweaking the HDL code. In the
>> past, I've eeked out sed scripts for such tasks, but
>> would appreciate a more traditional language. Since
>> Perl is used alot in digital IC design, I took a stab
>> at that, motivated by the simple need to convert my
>> mail aliases from one mail reader to the other. It
.
.
.
>> The alternative is Python, which is easier to read
>> from what I've read. My concern there is that I cut
>> myself off from large availability of stuff that's
>> out there. For example, I use a PC-to-solaris
>> viewer called VNC, and I've banged my head against the
>> startup script to change it a bit for my situation.
.
.
.
>work on the long run. I didn't know that Perl was particularly strong
>in the field of IC design. If so, good then.
>
>Apart from this particular case, it's generally a good thing when
>pre-written code exists that can be used. The amount of such code for
>Perl is immense (several thousand libraries) and gathered all in one
>place (the CPAN) with a unified interface to access and install them and
>a vast infrastructure built around it.
.
.
.
>> An additional usage scenario is to (if reasonable)
>> replace my shell scripting e.g. I just converted to
>> bash from tcsh to write scripts that push a document
>> through a series of filters, or simply as a wrapper
>> around a tough-to-use utility e.g. pstops. A final
.
.
.
>> destination blocks. Typically, this information will
>> be read by matlab scripts and passed to my C++ code
>> (I've managed to avoid writing code to parse the
>> input file from C++).
.
.
.
>> Whichever way I go, I would like to avoid the overhead
>> of learning both Perl and Python. I will sculpt out some
>> time in a miserly fashion to slowly get to know one. Since
>> I spend most of my time exploring the algorithm in Matlab or
>> C++/STL, there's only so much time to pick up higher level
>> languages (it took years before I shelled out the time
>> to switch from tcsh to bash). One of the things that
>> makes the decision not clear is that despite Python's
>> claim to a gentler learning curve and clearer code, I
>> often like the expedience of sed e.g. a terse one-liner
>> that can be pipelined with other shell commands. I
.
.
.
Where to begin? I'm seriously surprised that you haven't
mentioned Tcl, originally created to serve CAD needs, and
still more prevalent than either Perl or Python in CAD,
from all I know. Perl is indeed present, too, although,
in some ways, PythonCAD <URL: http://www.pythoncad.org/ >
is the most interesting action in this domain. All three
languages have enough to recommend them, and are close
enough in their capabilities, that I feel comfortable ad-
vising you to choose the one that suits *you* best. If
you like thinking in Perl, choose that; you'll miss out
on a few Python capabilities, but you'll be as productive
as with any other choice.
Either Perl or Python is going to satisfy you for algorithmic
experiments much, MUCH more than Matlab or C++. Make the
switch, *now*.
Either Perl or Python can adequately substitute for shell
in the uses you describe. They pipeline fine themselves;
'fact, I'm working on an essay on how they're *better* at
pipelining.
"The translater is freeware, so has limitations ...": I
don't understand how to read this. Has it been your
experience that commercial CAD packages are perfect, and
without limitations?
I work with VNC a lot, too. You seem to believe that
there's a special relation between VNC and Perl; do I
have that right? That surprises me. If anything, I'd
say Tcl leads in that domain <URL:
http://www-106.ibm.com/developerworks/linux/library/l-vnc/ >.
I generally favor Python over Perl; in the absence of
more details, I think there's mild evidence that those
who don't specialize in programming are happier over the
long term with the readability of the former. They're
very close, though. The one most certain advantage
Python boasts is a dimension that I'd think important
to you, although you haven't mentioned it: Python's
interfaces to C++ are MUCH easier to manage than Perl's.
Perl6 will change this. For now, though, it's FAR
easier to practice "dual-level programming" with Python
and C++. If you have a large existing library of C++
work, I think that tips the balance toward Python.
Understand, SWIG and other alternatives make Perl-to-C++
links possible; with Python's facilities, though,
including Pyrex, they're *fun*.
There's more to say; I'll be back later.
--
Cameron Laird <claird@phaseit.net>
Business: http://www.Phaseit.net
------------------------------
Date: 27 Mar 2004 13:09:46 GMT
From: Fred Ma <fma@doe.carleton.ca>
To: claird@phaseit.net
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <40657D14.3FBE7E82@doe.carleton.ca>
Cameron Laird wrote:
>
> Where to begin? I'm seriously surprised that you haven't
> mentioned Tcl, originally created to serve CAD needs, and
> still more prevalent than either Perl or Python in CAD,
I was under the impression (rightly or wrongly) that Tcl
was good at interfacing to, and controlling, CAD tools.
I was more motivated by the need to massage data, though
they probably overlap greatly. My experience with Tcl is
limited to using Synopsys DC shell to do unconventional
things, like traverse my design hierarchy (originally
in verilog) flattening and stripping out things. At the
time, the documentation for their dcshell was more
complete than for their Tcl version of the same. But
it's good to know that Tcl is an option to Perl and Python,
at least for some things.
> from all I know. Perl is indeed present, too, although,
> in some ways, PythonCAD <URL: http://www.pythoncad.org/ >
> is the most interesting action in this domain. All three
> languages have enough to recommend them, and are close
> enough in their capabilities, that I feel comfortable ad-
> vising you to choose the one that suits *you* best. If
> you like thinking in Perl, choose that; you'll miss out
> on a few Python capabilities, but you'll be as productive
> as with any other choice.
Good to know that at a personal level, I can run faster with
whichever one I feel more comfortable with (though I have
yet to explore Python for personal comfort). I was also
trying to take into consideration the prevalence of Perl
in digital design.
Along this line, I should clarify that by CAD, I don't mean
general purpose computer aided drawing. I mean software
that helps designers in digital design, much of which is not
graphical. In fact, my area is more combinatoric
optimization and graph theory-ish than drawing. Sometimes,
I forget that CAD has a much more general meaning than this.
> Either Perl or Python is going to satisfy you for algorithmic
> experiments much, MUCH more than Matlab or C++. Make the
> switch, *now*.
I'm surprised to hear that. Perhaps it's related to the
confusion above (due to the initial generality of my
description). My thesis research deals with evolutionary
algorithms (EAs) for programming coarse grain reconfigurable
logic platforms. They tend to be heavy on computation, and
I migrated to C++ for the speedup compared to matlab.
Matlab has been made fast for highly vectorizable
computation, but the restrictive conditions for such speedup
was, too restrictive. I saw some examples of genetic
algorithms in Perl (or perhaps it was Python), but assumed
(maybe prematurely) that it was much slower than C++. Other
factors also contributed to this impression, including the
fact that I augment the evolutionary search with local searh
heuristics, giving rise to complicated control flow in the
code. So I've used C++ for the computation engine code, and
shell/data-massaging scripts for "glue" activity. Matlab
I'm using because I've got alot of familiarity invested in
its graphing capabilities (to assess data rather than
drawing). I'm also pretty familiar with its compact
vectorized operations, which helps for data massaging in the
post-processing phase.
> Either Perl or Python can adequately substitute for shell
> in the uses you describe. They pipeline fine themselves;
> 'fact, I'm working on an essay on how they're *better* at
> pipelining.
Actually, I was thinking more along the lines of pipelining
Perl commands in a bash command pipeline, along with other
commands. But it's good to know that they pipeline within
their own scripts (if I understand you correctly), and for
general shell scripting.
> "The translater is freeware, so has limitations ...": I
> don't understand how to read this. Has it been your
> experience that commercial CAD packages are perfect, and
> without limitations?
The man page for "verilator" says this: "many limitations and
lack of features compared to a commercial simulator". One
of the things that prompted me to ask about Perl/Python is
because I'm looking at making many changes throughout a
number of files in order to accommodate the limitations.
Regardless of limitations carried by commercial tools, these
are the ones that I have to deal with.
> I work with VNC a lot, too. You seem to believe that
> there's a special relation between VNC and Perl; do I
> have that right? That surprises me. If anything, I'd
> say Tcl leads in that domain <URL:
> http://www-106.ibm.com/developerworks/linux/library/l-vnc/ >.
I described my experience with VNC just as an example of the
various situation in which I had to make sense of Perl
scripts. The vncserver script is written in Perl, at least
for TightVNC, and for older versions of RealVNC I seem to
recall. That's the extent to which I delved into VNC, since
my area of study (and thus the area where I spend most of my
time) is in "CAD" algorithms, as described above. I was
driven more by a need to expediently get a certain
kind/level of functionality from VNC rather than the
intention of developing it.
> I generally favor Python over Perl; in the absence of
> more details, I think there's mild evidence that those
> who don't specialize in programming are happier over the
> long term with the readability of the former. They're
> very close, though. The one most certain advantage
> Python boasts is a dimension that I'd think important
> to you, although you haven't mentioned it: Python's
> interfaces to C++ are MUCH easier to manage than Perl's.
> Perl6 will change this. For now, though, it's FAR
> easier to practice "dual-level programming" with Python
> and C++. If you have a large existing library of C++
> work, I think that tips the balance toward Python.
> Understand, SWIG and other alternatives make Perl-to-C++
> links possible; with Python's facilities, though,
> including Pyrex, they're *fun*.
That's good news, from my standpoint. I don't know what
level of programming qualifies a person to be "specializing
in programming", thus leading to more satisfaction with
Python. I've tried to read my own C++ code after half a
year, and have gained a new appreciation for the importance
of readability. So I'm still fine-tuning my idea of
adequate commenting. Since I'm working on my thesis rather
than commercial code, I don't have large amounts of generic
C++ library code. Just a big-ish heap of routines/functions
for the problem that I'm investigating, as the algorithms
that I choose to try morph.
My impression is that you think Python would be more
appropriate for my situation. Just wondering if you can
comment on the merit of having lots of Perl code around. It
seems to be prevelant in a digital design tool environment.
It may not matter all that much to me right now, but it
would be nice to be on the same wavelength as others if I
find myself in a team situation. As I mentioned, there have
already been situations where a nodding familiarity with
Perl has helped in making use of other people's tools.
> There's more to say; I'll be back later.
Thanks for your comments, and looking forward to hear any
further comments.
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
------------------------------
Date: Sat, 27 Mar 2004 13:26:45 GMT
From: "Paul McGuire" <ptmcg@austin.stopthespam_rr.com>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <pif9c.10786$TY1.9017@fe1.texas.rr.com>
"Fred Ma" <fma@doe.carleton.ca> wrote in message
news:40652B0D.7C313F77@doe.carleton.ca...
<snip>
> One thing I expect to have to do is to modify design
> files. For example, there is a tool which takes ASCII
> hardware desscription language (HDL) and converts it
> to a C++ (augmented by hardware simulation library).
> The translator is freeware, so has limitations which I
> have to make up for by tweaking the HDL code.
If you eventually find yourself in the Python realm, please look into the
pyparsing text parsing module, more information at
http://pyparsing.sourceforge.net/. I have implemented an easily-extended
99% Verilog parser using this module, and it may provide some shortcuts for
you in dealing with your HDL files.
-- Paul McGuire
------------------------------
Date: Sat, 27 Mar 2004 08:46:53 -0500
From: Roy Smith <roy@panix.com>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <roy-3EDA29.08465327032004@reader1.panix.com>
Fred Ma <fma@doe.carleton.ca> wrote:
> I was under the impression (rightly or wrongly) that Tcl
> was good at interfacing to, and controlling, CAD tools.
Tcl is an interesting language, and well worth learning, although it
certainly has its share of quirks.
The product I work on has close to 20,000 lines of Tcl code doing
network discovery via SNMP. The low-level SNMP protocol is accessed via
hooks done in C. It's not very fast, but it's as fast as it has to be,
and I shudder to think how many lines of C or C++ the whole system would
have been.
The real strengths are twofold:
1) It's easy to learn. Even easier than Python. We take guys who are
networking types with no programming experience and get them doing
useful development in Tcl in just a few days.
2) It's dead simple to embed in a C/C++ application. This is one place
where it really outshines Python. It's literally two lines of C to get
a Tcl interpreter up and running. It's equally trivial to extend Tcl by
providing functions in C. Compare this to the native Python/C
interface, boost.python, or swig, and you really appreciate the
difference!
For most general purpose tasks, I reach for Python first. But if I
needed to provide a quick scripting interface to an existing C library,
or wanted to embed some easy scriptability into a large C/C++ app, Tcl
is what I would be looking at.
------------------------------
Date: 27 Mar 2004 06:06:51 -0800
From: jkeen_via_google@yahoo.com (Jim Keenan)
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <196cb7af.0403270606.520c617@posting.google.com>
Fred Ma <fma@doe.carleton.ca> wrote in message news:<40652B0D.7C313F77@doe.carleton.ca>...
> Hello,
>
[snip 4 paragraphs]
>
> Whichever way I go, I would like to avoid the overhead
> of learning both Perl and Python. I will sculpt out some
> time in a miserly fashion to slowly get to know one.
Okay. You are at Carleton University, which was the site of Yet
Another Perl Conference::Canada in May 2003. So you have an excellent
pool of local Perl experts to draw upon -- and there are many more not
far away in Montreal, Toronto and Kitchener/Waterloo. Look them up
via http://www.pm.org/groups/north_america.html .
Jim Keenan
Brooklyn NY
------------------------------
Date: Sat, 27 Mar 2004 15:32:18 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <106b7k2s8af5c3c@corp.supernews.com>
In article <40657D14.3FBE7E82@doe.carleton.ca>,
Fred Ma <fma@doe.carleton.ca> wrote:
.
.
.
>I was under the impression (rightly or wrongly) that Tcl
>was good at interfacing to, and controlling, CAD tools.
>I was more motivated by the need to massage data, though
>they probably overlap greatly. My experience with Tcl is
>limited to using Synopsys DC shell to do unconventional
>things, like traverse my design hierarchy (originally
>in verilog) flattening and stripping out things. At the
>time, the documentation for their dcshell was more
>complete than for their Tcl version of the same. But
>it's good to know that Tcl is an option to Perl and Python,
>at least for some things.
.
.
.
>Along this line, I should clarify that by CAD, I don't mean
>general purpose computer aided drawing. I mean software
>that helps designers in digital design, much of which is not
>graphical. In fact, my area is more combinatoric
>optimization and graph theory-ish than drawing. Sometimes,
>I forget that CAD has a much more general meaning than this.
>
>> Either Perl or Python is going to satisfy you for algorithmic
>> experiments much, MUCH more than Matlab or C++. Make the
>> switch, *now*.
>
>I'm surprised to hear that. Perhaps it's related to the
>confusion above (due to the initial generality of my
>description). My thesis research deals with evolutionary
>algorithms (EAs) for programming coarse grain reconfigurable
>logic platforms. They tend to be heavy on computation, and
>I migrated to C++ for the speedup compared to matlab.
>Matlab has been made fast for highly vectorizable
>computation, but the restrictive conditions for such speedup
>was, too restrictive. I saw some examples of genetic
>algorithms in Perl (or perhaps it was Python), but assumed
>(maybe prematurely) that it was much slower than C++. Other
>factors also contributed to this impression, including the
>fact that I augment the evolutionary search with local searh
>heuristics, giving rise to complicated control flow in the
>code. So I've used C++ for the computation engine code, and
>shell/data-massaging scripts for "glue" activity. Matlab
>I'm using because I've got alot of familiarity invested in
>its graphing capabilities (to assess data rather than
>drawing). I'm also pretty familiar with its compact
>vectorized operations, which helps for data massaging in the
>post-processing phase.
.
.
.
Several people have posted good advice already.
Thanks for the clarification; NOW I understand considerably
better your focus on graph-theoretic and related work.
When I characterize you as not primarily a software person,
I'm just trying to say that your aim is engineering or
mathematical understanding. You have a life beyond pro-
gramming (good thing!).
My current instinct is that you'll be happiest with Perl--
but it's a close choice, all around. I'm most accomplished
in Tcl, and would happily use it, or Perl, or Python. It
seems to me, though, that it's crucial that you be able
to exploit libraries that pertain to your domain, and, in
particular, optimized engines for linear algebra, graph
theory, and linear and mathematical programming. Tcl
lacks the weight that Perl and, to an increasing extent,
Python can boast in their libraries.
The most important thing I can do is to continue to push
you in the direction of exploring at least one of Perl
and Python. YES genetic algorithms and other adaptive
methods are available. Some C++ is more mature--but some-
times Perl, or Python, have taken the lead. I understand
your concern with performance. Switch to one of Perl or
Python now, and I think you'll look back on the decision
as a correct one.
That's much more to say on precisely this issue. It
likely will take weeks to get it all out. I'm quite
certain of my conclusion, though, even without making the
time to explain it in detail: you'll be happier basing
your experiments in combinatoric and graph-theoretic
algorithms on Perl or Python than if you focused on C++.
--
Cameron Laird <claird@phaseit.net>
Business: http://www.Phaseit.net
------------------------------
Date: Sat, 27 Mar 2004 15:52:29 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <106b8ptboh4ig4a@corp.supernews.com>
In article <406532F7.D56DC671@doe.carleton.ca>,
Fred Ma <fma@doe.carleton.ca> wrote:
>Just wanted to add another example of stuff that
>I encounter alot of. As in many computer languages,
>various kinds of scopes are delineated by things
>like braces or begin/end statements. I often find
>it valuable to find an occurance of certain things
>(e.g. certain data declaration) within certain
>scope structures. Sed is convenient for that:
>
> /SomeStartPattern/,/SomeEndPattern/{
> Do some stuff,
> including conditional branching
> }
>
>To avoid the hassle of writing a script file and
>filtering the input source file to an output source
>file, I often use gvim's awesome pattern matching
>and macro recording abilities. A sed script file
>can look pretty cryptic, especially when I want
>to search across physical lines (lots of conditional
>flow to append things to the hold buffer, etc..).
>For that reason, I tend to stay with quick/dirty
>practices in gvim. Crypticness (though not of the
>same variety) is one of the things that I found
>hard about ramping up on Perl, to the degree that
>I did. As I hinted earlier, a fair comparison would
>account for the fact that its power would be more
>apparent if I became adequately guru-like, but
>realistically, I will not spend enough time with
>it on a regular basis to expect that. Here again
>is a dichotomy; I appreciate the sed terseness because
>I can make a command line pipe stage out of it, but
>the same brevity in a scripting language can make for
>rough going. Maybe it's wishful thinking to expect
>one language to cover all the bases that I initially
>mentioned.
.
.
.
I *really* don't know how to respond to this; a
sentence with "sed", "conditional" and "convenient"
leaves me at a loss.
Both Perl and Python are good fits for large popu-
lations. I have a lot of confidence that, in the
near future, you'll find the one you've choosen
handier than either sed or Matlab, *even for most
of the tasks at which sed and Matlab are good*.
Perl and Python are that strong.
Python's population has a greater propensity to
regard its readability as an advantage, while
Perlites often revel in concise power. Try 'em
both briefly, choose one that makes a good impres-
sion, and get back to your engineering work.
You'll be glad you upgraded to a 'P' language.
--
Cameron Laird <claird@phaseit.net>
Business: http://www.Phaseit.net
------------------------------
Date: Sat, 27 Mar 2004 16:31:15 +0100
From: Rob Vunderink <vunderink@t-online.de>
Subject: Does anyone know what this switch does?
Message-Id: <c446o7$uqi$01$1@news.t-online.com>
Hi,
I have a question. It is related to the following situation.
Check out this url:
http://www.opstartpagina.nl/cgi-bin/ipadres.cgi
It works.
Now check out this url:
http://angel.regioportals.nl/gelderlander/cgi-bin/ipadres.cgi
It does not work, although the scripts are the same in both cases:
= - = - = - = - = - = - = - = -
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Uw IP-adres is: $ENV{REMOTE_ADDR}";
= - = - = - = - = - = - = - = -
Now check out this url:
http://angel.regioportals.nl/gelderlander/cgi-bin/ipadres2.cgi
It works. The script is:
= - = - = - = - = - = - = - = -
#!/usr/bin/perl --
print "Content-type: text/html\n\n";
print "Uw IP-adres is: $ENV{REMOTE_ADDR}";
= - = - = - = - = - = - = - = -
Her comes the question.
The difference is the " --" on the shebang line. What does this switch
do? Why does it make a difference?
Thanks if anybody knows the answer.
Rob Vunderink
------------------------------
Date: Sat, 27 Mar 2004 14:25:44 GMT
From: mturner@ms.umanitoba.ca (Myron Turner)
Subject: Re: Filehandles Referenced with a Variable
Message-Id: <4065843b.2024782923@news.wp.shawcable.net>
On Fri, 26 Mar 2004 20:51:25 GMT, Mike Flannigan
<mikeflan@earthlink.net> wrote:
>#use strict;
>use warnings;
>
>my $infile = 'USAshorter.txt';
>
>my $fileout = 'states.txt';
>my ($line, $stm, $state, $st, @sttemp, %count, $k, $v);
>my $num=0;
>my $tot=0;
>my @states = ('AK', 'AL', 'AR', 'AS', 'AZ', 'CA', 'CO', 'CT', 'DC',
>'DE', 'FL', 'FM', 'GA', 'GU', 'HI', 'IA', 'ID', 'IL', 'IN', 'KS', 'KY',
>'LA', 'MA', 'MD', 'ME', 'MH', 'MI', 'MN', 'MO', 'MP', 'MS', 'MT', 'NC',
>'ND', 'NE', 'NH', 'NJ', 'NM', 'NV', 'NY', 'OH', 'OK', 'OR', 'PA', 'PR',
>'PW', 'RI', 'SC', 'SD', 'TN', 'TX', 'UM', 'UT', 'VA', 'VI', 'VT', 'WA',
>'WI', 'WV', 'WY');
>
I know this topic has been gone over, but this is based on
"Programming Perl", page 249, which I've known about but have never
used:
my %handles;
for my $file(@names) {
my $fh;
$handles{$file} = $fh;
}
for my $file(@names) {
print "$file\n";
my $fh = $handles{$file};
open($fh, $file) || die "$!: $file\n";
print <$fh>;
close $fh;
}
I'm not sure why, but in the second loop, you have to first assign the
hash to a variable:
my $fh = $handles{$file};
You can open and close the file with using the hash directly but you
can't simply say;
print < $handles{$file}>;
If you do it prints the value of the GLOB.
Myron Turner
www.room535.org
------------------------------
Date: Sat, 27 Mar 2004 14:33:58 GMT
From: peter@PSDT.com (Peter Scott)
Subject: Re: Filehandles Referenced with a Variable
Message-Id: <qhg9c.22760$li5.10984@pd7tw3no>
In article <406497E7.D78B8566@earthlink.net>,
Mike Flannigan <mikeflan@earthlink.net> writes:
>my @states = ('AK', 'AL', 'AR', 'AS', 'AZ', 'CA', 'CO', 'CT', 'DC',
>'DE', 'FL', 'FM', 'GA', 'GU', 'HI', 'IA', 'ID', 'IL', 'IN', 'KS', 'KY',
>'LA', 'MA', 'MD', 'ME', 'MH', 'MI', 'MN', 'MO', 'MP', 'MS', 'MT', 'NC',
>'ND', 'NE', 'NH', 'NJ', 'NM', 'NV', 'NY', 'OH', 'OK', 'OR', 'PA', 'PR',
>'PW', 'RI', 'SC', 'SD', 'TN', 'TX', 'UM', 'UT', 'VA', 'VI', 'VT', 'WA',
>'WI', 'WV', 'WY');
>
>my %type = (
> "DC" => "*DC",
> "AL" => "*AL"
> );
>
>chdir 'C:\Copy2';
>
>open OUT, ">", $fileout or die "Cannot open $fileout: $!";
>open DC, ">DC.txt" or die "Cannot open DC.txt: $!";
This should do the trick:
for my $st (@states)
{
open(my $fh, ">", "$st.txt") or die "Cannot open $st.txt: $!";
$type{$st} = $fh;
}
As others pointed out, %type is not a good name.
--
Peter Scott
http://www.perldebugged.com/
*** NEW *** http://www.perlmedic.com/
------------------------------
Date: Sat, 27 Mar 2004 10:29:54 GMT
From: p cooper <pdconetwofour_numbers_@yahoo.co.uk>
Subject: hashes , use strict readParse
Message-Id: <CIc9c.4100$kT7.37619890@news-text.cableinet.net>
I seem to be in a muddle over the above.
my scripts seem to fall over using
&ReadParse(*input)
with use strict;
#!/usr/bin/perl
use CGI;
use strict;
my % input;
ReadParse(*input)
and i get a blank page when trying to do anything wih the hash key/values.
I cant find how use strict fits together with ReadParse(*input) and then
using the hash.
------------------------------
Date: Sat, 27 Mar 2004 11:04:03 GMT
From: p cooper <pdconetwofour_numbers_@yahoo.co.uk>
Subject: Re: hashes , use strict readParse
Message-Id: <Dcd9c.4117$Ek.38001929@news-text.cableinet.net>
the preoblem seems to be when im trygin to produce different pages with the
same script
eg
if $ENV{HTTP_REFERER} =~/page1.htm/
{ do page two stuff }
elsif $ENV{HTTP_REFERER} =~/page2.htm/
{ do page 3 stuff}
use strict appears to break things doesnt work going round for the second
time.
Dont know if this something with use strict ans hashes that i dont know or
its a probem somewhere else.
------------------------------
Date: Sat, 27 Mar 2004 14:05:52 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: hashes , use strict readParse
Message-Id: <c43u6l$2dqb2p$1@ID-184292.news.uni-berlin.de>
p cooper wrote:
> I seem to be in a muddle over the above.
> my scripts seem to fall over using
>
> &ReadParse(*input)
>
> with use strict;
>
> #!/usr/bin/perl
> use CGI;
> use strict;
> my % input;
> ReadParse(*input)
>
> and i get a blank page when trying to do anything wih the hash
> key/values.
Try making %input a package global:
our %input;
You also need to either import 'ReadParse' or call the function with
the fully qualified name, even if that has nothing to do with
strictures. But by enabling warnings, Perl would have told you about
that mistake.
use warnings;
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 27 Mar 2004 08:31:00 GMT
From: lvirden@yahoo.com
Subject: Loss of privledges in a perl app
Message-Id: <c43e44$3s2$3@srv38.cas.org>
I inherited a perl app that runs setuid. The app was running okay, but
recently, I discovered that when I tried to run it, I was getting a failure
message about an inability to perform a specialized directory creation.
When I added the line
print system("id");
the results indicated that there was no effective userid being set.
Could merely adding this line have caused perl to give up the effective
userid state? If so, then is there a method by which I could determine
whether the effective userid is set correctly? It doesn't seem like it
could be, given the error I am getting. But debugging this app is a
tough job.
If indeed the app is throwing away the effective userid, how can I determine
why? I am using the -w switch, and am not seeing any warnings about
a problem.
--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
------------------------------
Date: Sat, 27 Mar 2004 05:07:43 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Loss of privledges in a perl app
Message-Id: <0rCdnegTmr3wz_jd4p2dnA@adelphia.com>
lvirden@yahoo.com wrote:
> Could merely adding this line have caused perl to give up the effective
> userid state?
Yes - although not for the reason you might be imagining. Many systems clear
the suid bit on a file whenever that file is written to, as a security
precaution. So simply editing the file and changing it, regardless of what
was added or changed, can cause the script to give up its suid state.
BTW, there's no need to call an external program like "id" to get the
currently euid - there are Perl variables that already hold that info. $<
and $> hold the real and effective user id, and $( and $) the real and
effective group id. The English.pm equivalents are $REAL_USER_ID, $UID,
$EFFECTIVE_USER_ID, $EUID, $REAL_GROUP_ID, $GID, $EFFECTIVE_GROUP_ID, and
$EGID.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Sat, 27 Mar 2004 15:43:31 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Tangent on embeddability (was: Choosing Perl/Python for my particular niche)
Message-Id: <106b893s0sfut11@corp.supernews.com>
In article <roy-3EDA29.08465327032004@reader1.panix.com>,
Roy Smith <roy@panix.com> wrote:
.
.
.
>2) It's dead simple to embed in a C/C++ application. This is one place
>where it really outshines Python. It's literally two lines of C to get
>a Tcl interpreter up and running. It's equally trivial to extend Tcl by
>providing functions in C. Compare this to the native Python/C
>interface, boost.python, or swig, and you really appreciate the
>difference!
>
>For most general purpose tasks, I reach for Python first. But if I
>needed to provide a quick scripting interface to an existing C library,
>or wanted to embed some easy scriptability into a large C/C++ app, Tcl
>is what I would be looking at.
Me, too, to a large extent. I think you overstate Tcl's
advantage, though, Roy, in a couple of ways. First, I
agree that Tcl is objectively easier and more reliable
in embedding; Python still has blemishes in ease-of-use
and portability in this role. It can be hard getting
all of Python embedded correctly, especially, in my ex-
perience, when working on multiple platforms.
However, Tcl has historically been so easy that it hasn't
bothered documenting the process. Python has a definitive
(if aging) embedding manual that I regard as more inviting
than what Tcl offers.
Also, ctypes, Boost and Pyrex *are* successful, and appear
to me progressing faster than any of their Tcl cousins.
Yet another way to look at the comparison is that a sig-
nificant number of people rely on SWIG, and, to them,
Tcl and Python are indistinguishable.
Follow-ups narrowed. Most of Perl's response to all of
this is, "Wait 'til 6!"
--
Cameron Laird <claird@phaseit.net>
Business: http://www.Phaseit.net
------------------------------
Date: 27 Mar 2004 08:54:00 GMT
From: Klaas <spamhole@klaas.ca>
Subject: Re: The "value" of a block in 'map'
Message-Id: <Xns94B99A92FCC6nothing@209.98.50.131>
After careful consideration, Anno Siegel muttered:
> Bernie Cosell <bernie@fantasyfarm.com> wrote in comp.lang.perl.misc:
>> Yes, in fact I do: but as it turns out, of all of the languages [and
>> there are several] that have this ternary operator, *ONLY*PERL*
>> short-circuits it.
>
> Not true.
>
> Afaik, "?:" appeared first in C, which *does* short-circuit.
>
> 1 ? printf( "hi\n") : printf( "ho\n");
>
> prints only "hi".
java does likewise. Anyone know a language with ?: that doesn't short-
circuit?
-Mike
------------------------------
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 6310
***************************************
