[23113] in Perl-Users-Digest
Perl-Users Digest, Issue: 5334 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 8 14:05:57 2003
Date: Fri, 8 Aug 2003 11:05:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 8 Aug 2003 Volume: 10 Number: 5334
Today's topics:
A simple doubt :-/ (Vijoy Varghese)
Re: A simple doubt :-/ <nobull@mail.com>
Re: Any way to stop a kill? (Carlton Brown)
App distribution method? <bret@bretwortman.com>
Re: App distribution method? <jwillmore@cyberia.com>
Re: bluescreens with perl for NT (Bohne)
Re: hash <tassilo.parseval@rwth-aachen.de>
Re: hash <sonet.all@msa.hinet.net>
Re: help with regular expression <spamblock@junkmail.com>
Re: How do I modify version number in XML doc - path to (Sherman Willden)
Re: How do you simulate "." or "source" in a perl scrip <jwillmore@cyberia.com>
Re: How do you simulate "." or "source" in a perl scrip <abigail@abigail.nl>
Re: nested HTML parsing <usenet@dwall.fastmail.fm>
PATHS Problem <jrendant@comcast.net>
Perfect perl IDE! <member32241@dbforums.com>
Re: Perfect perl IDE! <usenet@dwall.fastmail.fm>
Re: Perfect perl IDE! <mpapec@yahoo.com>
Re: Perl and C APIs <tassilo.parseval@rwth-aachen.de>
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi (Chas Friedman)
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi <nobull@mail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 8 Aug 2003 09:58:50 -0700
From: viijv@thedifferenZ.com (Vijoy Varghese)
Subject: A simple doubt :-/
Message-Id: <4c08aaff.0308080858.470666b2@posting.google.com>
Hello Group
I have a doubt.
The programs written in 'C' language *.c is compiled to *.obj and then
linked to *.exe which is the 'machine language' substitute for our *.c
program, right? Now for a processor to execute any program, the
program should be coded in a language which the processor can
understand, and here in our case the *.exe is such a language (or may
be one level above the 'language processor can understand', and our
Operating System does the translation work for the processor). So what
ever it be, the *.exe is close to the language which the processor can
understand.
Now, a CGI program written in Perl, *.cgi there is no compilation or
linking. That is each time we try to activate this program the Perl
interpreter have to convert it to the *.exe format(or directly to hard
core machine language of 0's and 1's?) and this process is repeated
during all activation of the *.cgi script, right?
So this is a kind of overhead when a same script is activated some
1000 time in a minute, right? But still people are using Perl for CGI
scripting, why? Yes, Perl is fun, its always fun to program using a
language which remind us more of a 'natural language' rather than a
'programming language'. But still, why don’t some one make a
'Compiled Perl' with all features of current Perl, but which can be
compiled to machine language, so that there is no need to 'translate'
it each time its activated.
Or is there is already one available? I have heard a lot about
'mod_perl' and that it increases the speed of CGI scripts by some 100
times. Is that have something to do with the 'compiled' version :-/
I am expecting a lot of '@#$#$%$@' replies, because I know this is not
the way to ask questions in a group. But friends, this doubt... its
hunting me for a long time, and i cant find a convincing answer
anywhere. :-(
Waiting for your replies or some pointers where I can find answer to
my doubt.
Thanking you all
Regards
Vijoy Varghese
------------------------------
Date: 08 Aug 2003 18:25:18 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: A simple doubt :-/
Message-Id: <u91xvwt62p.fsf@wcl-l.bham.ac.uk>
viijv@thedifferenZ.com (Vijoy Varghese) writes:
> The programs written in 'C' language *.c is compiled...
[snip how compiled lanuages work ]
> Now, a CGI program written in Perl, *.cgi there is no compilation or
> linking. That is each time we try to activate this program the Perl
> interpreter have to convert it to the *.exe format(or directly to hard
> core machine language of 0's and 1's?) and this process is repeated
> during all activation of the *.cgi script, right?
Actually in converts it into an intermediate form - Perl byte code.
The Perl by code is then interpreted by a virtual machine.
> So this is a kind of overhead when a same script is activated some
> 1000 time in a minute, right? But still people are using Perl for CGI
> scripting, why?
Be aware that a lot of the overhead is also in the process creation
overhead. Even if you use native executable CGIs you still have to
pay.
If you want speed one way is to load your web server apps into the
web server itself. For example, in Apache you do this with Apache
loadable modules.
> Yes, Perl is fun, its always fun to program using a
> language which remind us more of a 'natural language' rather than a
> 'programming language'. But still, why don’t some one make a
> 'Compiled Perl' with all features of current Perl, but which can be
> compiled to machine language, so that there is no need to 'translate'
> it each time its activated.
Attempts have been made but they've not managed to produce significant
speed improvements.
> Or is there is already one available?
There are, AFAIK, no production-ready Perl compilers or byte-code loaders.
> I have heard a lot about 'mod_perl' and that it increases the speed
> of CGI scripts by some 100 times. Is that have something to do with
> the 'compiled' version :-/
Yes. In Apache mod_perl the Perl interpreter is kept running and not
restarted for each web transaction so once any module (or pseudo CGI
script) has been loaded and compiled once it need not be again until
the web server is restarted. Actually there's a pool of several Perl
interpreters servicing requests so each module is compiled once for
each interpreter. Also because Perl programs sometime leak memory
each interpreter is killed off and replaced periodically.
If you know in advance what modules are going to be used the you can
preload them at server startup and then they don't need to be loaded
during the first transaction that needs them.
Be aware that mod_perl is not CGI. It is possible to write Perl
source code that can run both as CGI scripts and as mod_perl handler
modules using the 'Registry' mechanisms provided by mod_perl. This is
the mode in which most people (including myself) use mod_perl most of
the time. Such programs need to obey a few simple rules above and
beyond those which real CGI scripts would.
However you can do a lot more in mod_perl than you can in CGI.
Also running mod_perl in the mode where in can use these dual-role
programs will slow it down.
For information about Apache+mod_perl go see the Apache+mod_perl
websites. (Like, D'uh!).
There's some real exciting stuff in Apache2+mod_perl2.
Note: there are other alternatives to CGI that also eleminiate the
process creation-per-transation overhead, e.g. FastCGI.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 8 Aug 2003 08:23:32 -0700
From: carltonbrown@hotmail.com (Carlton Brown)
Subject: Re: Any way to stop a kill?
Message-Id: <aa611a32.0308080723.2be1d628@posting.google.com>
Marshall Dudley <mdudley@execonn.com> wrote in message news:<3F32BE2C.48694D68@execonn.com>...
> After a customer orders something, emails get sent to me and the
> customer by a perl script. Lately the server has been loaded more
> heavily than normal, and the sendmail is taking a while to complete and
> for control to return back to perl.
I have no answer for this, but for the record I'll affirm that I have
also recently seen similar behavior with sendmail - around June I
noticed that it started taking exactly 60 seconds to return control to
the script. It's as though sendmail forgot how to flush its input
buffers and resorts to a default timeout. And it isn't just PERL, the
behavior can be reproduced on the command line. I'm looking into
Solaris patches applied at that time which may have had an effect.
Are you by chance on Solaris too, and can you reproduce the behavior
on the command line?
In the meantime I am looking at a similar solution of forking a child
process as a workaround.
-Carlton
------------------------------
Date: Fri, 08 Aug 2003 12:03:05 GMT
From: "Bret Wortman" <bret@bretwortman.com>
Subject: App distribution method?
Message-Id: <3f339178@news.comindico.com.au>
I've got a Perl application I recently developed which relies on a number of
modules, including a variety of XML and SAX flavors. I really need a
minimum of Perl 5.6.1. The application polls each target system for system
information and gathers version information for installed software products.
It also does some hardware investigation and the like. It runs from an
automounted (or NFS-mounted) directory and, outside of Perl and the module
dependencies, is self-contained.
We want to deploy this application across a very large number of systems and
the problem is that we have Perl versions ranging back to 5.005 and up to
5.8.0. Some have never been configured for CPAN and others have obsolete
configurations. The application will be deployed to a variety of Unixes
(Tru64, Solaris) and Linux.
I've written some scripts which are capable of installing all the
prerequisites (including building Perl 5.8.0, installing CPAN-1.70 and
setting up a basic MyConfig.pm file) then building some key modules before
using CPAN to install from an autobundle-created bundle file. After that,
my app is good to go on the target system.
My question is this: is there a way to install the necessary libraries and
modules under a common directory and not directly on the target systems?
Could I create a series of subdirectories of the main NFS-mounted dir which
could contain enough modules and libraries to avoid having to do the full-up
CPAN installation on each target system? The process of rolling this out is
becoming daunting and I'm looking for shortcuts which might reduce the
requirements on the target systems.
If this is possible, would I need directories organized both by target OS
*and* by Perl version?
Thanks!
Bret Wortman
------------------------------
Date: Fri, 08 Aug 2003 14:56:46 GMT
From: James Willmore <jwillmore@cyberia.com>
Subject: Re: App distribution method?
Message-Id: <20030808105600.5b0758da.jwillmore@cyberia.com>
> My question is this: is there a way to install the necessary
> libraries and modules under a common directory and not directly on
> the target systems? Could I create a series of subdirectories of the
> main NFS-mounted dir which could contain enough modules and
> libraries to avoid having to do the full-up CPAN installation on
> each target system? The process of rolling this out is becoming
> daunting and I'm looking for shortcuts which might reduce the
> requirements on the target systems.
>
> If this is possible, would I need directories organized both by
> target OS*and* by Perl version?
Two thoughts:
1) Install the Perl version you want, modules and all, on an NFS mount
common to all machines.
2) Install the modules on an NFS mount using the
following:
perl Makefile.PL PREFIX=<NFS mount here>
make
make test
make install
Each method has various issues associated with them. The second,
depending on what modules you use, may need you to update core Perl
modules - which will cause tons of headaches. The first, although
it's attractive, may cause headaches when the modules you're building
depend on libraries that not all the machines have (such as expat and
libxml). Not to mention that, again, core Perl modules may need to be
updated.
These are just two thoughts. Someone else may have better solutions
for you. These are the two I have right off the top of my head, both
are pretty messy.
HTH
Jim
------------------------------
Date: 8 Aug 2003 04:55:50 -0700
From: simjesse@aol.com (Bohne)
Subject: Re: bluescreens with perl for NT
Message-Id: <bfedec4.0308080355.42aadb18@posting.google.com>
> > I am having problems with bluescreens.
> > Mainly when I am using the perl debugger.
> >
> > I am using Perl v5.6.1
> > NT 4.00.1381
> > Norton Antivirus 7.61.934
> >
>
> What does "mainly" mean?
--> Mainly means usually while I am actually using the perl debugger
(about 90%)
sometimes I only open the debugger and it's gone
sometimes I work with it for quite a while and then it jumps out on
me.
however, sometimes I have finished with the debugger and do something
totally different and WHHOPS, there it is.
>Do bsods occur all the time, regardless of whether you're running
Perl scripts or not?
>Do they only occur when you run your Perl scripts?
--> I can run perl scripts without problem, it's just when I try to
debug them.
>Do they occur regardless of what Perl script you're running?
--> it seems this way
> Do they only occur when you run a specific script?
--> no
> I once had a problem with perl (okay, me...) causing bsods on an NT box, but
> all I can remember of that unfortunate incident is that it had something to
> do with a system call gone awry. I would look for something suspcious like
> that if it is just one script that is causing your problems...
>
> Matt
------------------------------
Date: 8 Aug 2003 10:06:21 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: hash
Message-Id: <bgvsmt$1ot$1@nets3.rz.RWTH-Aachen.DE>
[CCed to poster]
Also sprach <sonet.all@msa.hinet.net>:
> how to do $ADHash{@userArray}=1;
>
>
> Known
> @usrArray = [a,b,c]
>
> Let:
> $ADHach{'a'}=1
> $ADHach{'b'}=1
> $ADHach{'c'}=1
By using a hash-slice:
@ADHash{ @userArray } = (1) x @userArray;
Slices are described in perldata.pod.
> please mail to : sonet.all@msa.hinet.net
You may ask for a CC but asking for a mail reply is rude. A newsgroup
also acts as archive for other people to look things up. If all replies
were by mail, a newsgroup would only contain the questions but no
answers.
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: Fri, 8 Aug 2003 18:20:21 +0800
From: <sonet.all@msa.hinet.net>
Subject: Re: hash
Message-Id: <bgvtlf$bmi@netnews.hinet.net>
sorry !! my english is so poor! our first language is not english
in other words , i cant distinguish what different from mailto and cc .
sorry again!!
thanks for your reply
"Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> ¦b¶l¥ó
news:bgvsmt$1ot$1@nets3.rz.RWTH-Aachen.DE ¤¤¼¶¼g...
> [CCed to poster]
>
> Also sprach <sonet.all@msa.hinet.net>:
>
> > how to do $ADHash{@userArray}=1;
> >
> >
> > Known
> > @usrArray = [a,b,c]
> >
> > Let:
> > $ADHach{'a'}=1
> > $ADHach{'b'}=1
> > $ADHach{'c'}=1
>
> By using a hash-slice:
>
> @ADHash{ @userArray } = (1) x @userArray;
>
> Slices are described in perldata.pod.
>
> > please mail to : sonet.all@msa.hinet.net
>
> You may ask for a CC but asking for a mail reply is rude. A newsgroup
> also acts as archive for other people to look things up. If all replies
> were by mail, a newsgroup would only contain the questions but no
> answers.
>
> 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: Fri, 8 Aug 2003 10:06:33 -0700
From: "David Oswald" <spamblock@junkmail.com>
Subject: Re: help with regular expression
Message-Id: <vj7mgpb181sg5a@corp.supernews.com>
Never heard back as to whether "the dude" got the answer he was looking for
from this discussion. I suspect he either took the first (wrong) one, or
gave up on the project, or forgot where to find the post. ;) We may never
know.
------------------------------
Date: 8 Aug 2003 08:54:03 -0700
From: sherman.willden@hp.com (Sherman Willden)
Subject: Re: How do I modify version number in XML doc - path to pass to Twig?
Message-Id: <3a80d8d6.0308080754.ddebbb6@posting.google.com>
Thanks, Michael, for your response earlier and the code works, the
values are modified, and the text stream is output to the screen.
My question is how do I get a well-formed XML document from the
results? I tried printing to a file handle ( C:\temp\twig_tmp.xml )
but that didn't work. Below is the code that outputs the results to
the screen.
To further explain, I have file xyz.xml. I want to modify one value in
the xyz.xml file and have a working xyz.xml file after the
modification.
I am sure that I missed the answer when reading Michael's site, Perl
and XML, and the twig documentation. Can someone provide a reference
to the paragraph(s) that explains what I missed?
Thanks;
Sherman
#!/usr/bin/perl -w
use strict;
use XML::XPath;
use XML::XPath::XMLParser;
use XML::Twig;
my $field= 'string';
my $old_value = '2.20.0.0';
my $new_value = '2.20.0.12';
if ( -f "C:/temp/twig_tmp.xml" ) {
chmod(0777, "C:/temp/twig_tmp.xml");
unlink("C:/temp/twig_tmp.xml");
}
#open(TMPFLE, ">>c:/temp/twig_tmp.xml");
my $t = new XML::Twig( twig_handlers =>
{ qq{$field\[string() = "$old_value"] } => \&update, # process
__default__ => sub { $_[0]->flush; }, # flush anything
else
},
pretty_print => 'record_c',);
$t->parsefile( 'BC_HA.iap_xml' );
#$t->print( \*TMPFLE );
$t->flush;
#close(TMPFLE);
sub update
{
my( $t, $field_elt)= @_;
# if you want the version number to be in a CDATA section
# then set_content is not enough
if( my $cdata= $field_elt->first_child_is( '#CDATA'))
{ $cdata->set_cdata( $new_value); }
else
{ $field_elt->set_text( $new_value); }
}
------------------------------
Date: Fri, 08 Aug 2003 15:16:22 GMT
From: James Willmore <jwillmore@cyberia.com>
Subject: Re: How do you simulate "." or "source" in a perl script ?
Message-Id: <20030808111536.71614720.jwillmore@cyberia.com>
> Specifically I would like to set environment variables inside a perl
> script which are stored inside a separate config file (used by many
> other programs)
If you want to set environmental variables from within Perl, %ENV is
the place to set such items. perldoc perlvar for more information.
>
> At the moment I have a separate ksh script wrapper around my perl
> script which simply does something like
>
> #!/bin/ksh
>
> . /dir/config.sh
>
> /dir/perlscript.pl
No offense, but what's the issue with this? It seems like it does
what you wnat it to do. If you want ALL scripts to have the SAME
environmental variables, why not set them from within .profile or
.bashrc or.cshrc or some variation of the three based upon your shell?
>
> but there's got to be a better way than that.
>
> Unfortunately neither "." nor "source" are particularly easy things
> to search for and I've not spotted anything in either perldoc nor
> googling this newsgroup.
Because it's not portable. Perl is designed with portablity in mind.
WIN32 systems don't use '.' or 'source' without some help (ie
Cygwin). Might I suggest you read some more of the Perl
documentation. Perl is not your average scripting language (like
C-Shell, BASH, KSH, etc).
>
> I guess I could have the perl script read the config file explicitly
> and act upon what it finds there - but someone must have tackled
> this already.
This is a workable solution if you can't keep the environmental
variables set in the parent shell. It's also more portable. If you
decide, one day, to run the scripts on a WIN32 machine, then you don't
have to re-invent the wheel to do so. There are several modules to
aid in this task -or- you could roll your own.
HTH
Jim
------------------------------
Date: 08 Aug 2003 15:29:59 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: How do you simulate "." or "source" in a perl script ?
Message-Id: <slrnbj7gfm.39l.abigail@alexandra.abigail.nl>
Chris Marshall (c_j_marshall@hotmail.com) wrote on MMMDCXXVIII September
MCMXCIII in <URL:news:cb9c7b76.0308070721.2f4cd3f5@posting.google.com>:
&& Is there a good way of simulating the bourne shell's "." command - or
&& csh's "source" command inside a perl script ?
&&
&& Specifically I would like to set environment variables inside a perl
&& script which are stored inside a separate config file (used by many
&& other programs)
&&
&& At the moment I have a separate ksh script wrapper around my perl
&& script which simply does something like
&&
&& #!/bin/ksh
&&
&& . /dir/config.sh
&&
&& /dir/perlscript.pl
&&
&& but there's got to be a better way than that.
&&
&& Unfortunately neither "." nor "source" are particularly easy things to
&& search for and I've not spotted anything in either perldoc nor
&& googling this newsgroup.
&&
&& I guess I could have the perl script read the config file explicitly
&& and act upon what it finds there - but someone must have tackled this
&& already.
An often asked question is 'how to "source" a file', like you do in the
shell, to set one or more environment variables. The easy answer is:
first source the file, then start the program. But what if the file
to source isn't known in advance? Or it's impossible to write a wrapper
script? Put the code below at or near the beginning of your program.
The code below runs in combination with the Korn shell, and probably any
other Bourne shell decendent, including the POSIX shell. I don't know
whether this works in the standard Windows shell - probably not due to
quoting issues, but getting it to run under Cygwin/bash should not be
a problem.
Abigail
my $ENVIRONMENT = "/some/file/with/environment/variables/";
if (@ARGV && $ARGV [0] eq '--sourced_environment') {
shift;
}
else {
if (-f $ENVIRONMENT) {
#
# Now we perform a double exec. The first exec gives us a shell,
# allowing us the source the file with the environment variables.
# Then, from within the shell we re-exec ourself - but with an
# argument that will prevent us from going into infinite recursion.
#
# We cannot do a 'system "source $ENVIRONMENT"', because
# environment variables are not propagated to the parent.
#
# Note the required trickery to do the appropriate shell quoting
# when passing @ARGV back to ourselves.
#
# Also note that the program shouldn't normally be called with
# '--sourced_environment' - if so, pick something else.
#
@ARGV = map {s/'/'"'"'/g; "'$_'"} @ARGV;
exec << " --";
source '$ENVIRONMENT'
exec $0 --sourced_environment @ARGV;
--
die "This should never happen.";
}
}
--
$_ = "\112\165\163\1648\141\156\157\164\150\145\1628\120\145"
. "\162\1548\110\141\143\153\145\162\0128\177" and &japh;
sub japh {print "@_" and return if pop; split /\d/ and &japh}
------------------------------
Date: Fri, 08 Aug 2003 15:27:18 -0000
From: "David K. Wall" <usenet@dwall.fastmail.fm>
Subject: Re: nested HTML parsing
Message-Id: <Xns93D17486D742Fdkwwashere@216.168.3.30>
Chris Mattern <syscjm@gwu.edu> wrote:
> Tad McClellan wrote:
>>
>> If it is invalid, then it is not HTML at all, just some
>> angle-brackety text.
>>
>>
> I suppose it's a question of intent. "Invalid HTML" == "It was
> supposed to be HTML, but it ain't"
Argument "It was supposed to be HTML, but it ain't" isn't numeric in
numeric eq (==) at ...
Argument "Invalid HTML" isn't numeric in numeric eq (==) at ...
:-)
------------------------------
Date: 8 Aug 2003 17:55:07 GMT
From: "Jim Rendant" <jrendant@comcast.net>
Subject: PATHS Problem
Message-Id: <EtGdnZi7KvPSfq6iXTWJkQ@comcast.com>
I have created a perl script that lives in the cgi-bin directory. It builds
web pages on the fly but it doesn't find the CSS style sheet located in the
.../html/ directory. I have used the http://ipaddress/html/ path name and it
works. When I transfer this to another server I will have to reconfigure all
the absolute path names for that server.
I AM SURE I AM MISSING SOMETHING HERE!
There has to be a eaiser way for a script located in the cgi-bin directory
to use a CSS files of other files in other directories.
Please help me.
Thanks
Jim Rendant
--
PLEASE NOTE: comp.infosystems.www.authoring.cgi is a
SELF-MODERATED newsgroup. aa.net and boutell.com are
NOT the originators of the articles and are NOT responsible
for their content.
HOW TO POST to comp.infosystems.www.authoring.cgi:
http://www.thinkspot.net/ciwac/howtopost.html
------------------------------
Date: Fri, 08 Aug 2003 17:33:35 +0000
From: dominant <member32241@dbforums.com>
Subject: Perfect perl IDE!
Message-Id: <3218389.1060364015@dbforums.com>
I want to start learning perl with a really good IDE.
Any suggestions?
(free IDE)
--
Posted via http://dbforums.com
------------------------------
Date: Fri, 08 Aug 2003 17:48:53 -0000
From: "David K. Wall" <usenet@dwall.fastmail.fm>
Subject: Re: Perfect perl IDE!
Message-Id: <Xns93D18C88311B0dkwwashere@216.168.3.30>
dominant <member32241@dbforums.com> wrote:
> I want to start learning perl with a really good IDE.
>
> Any suggestions?
>
> (free IDE)
perldoc -q editor
"Is there an IDE or Windows Perl Editor?"
You might try Google groups, too -- this gets asked at least once or
twice a month.
------------------------------
Date: Fri, 08 Aug 2003 19:47:22 +0200
From: Matija Papec <mpapec@yahoo.com>
Subject: Re: Perfect perl IDE!
Message-Id: <iun7jvo2v7e99egsajth5okq1kttlkce85@4ax.com>
X-Ftn-To: dominant
dominant <member32241@dbforums.com> wrote:
>
>I want to start learning perl with a really good IDE.
>
>Any suggestions?
For windows there are Komodo and Perl builder but they aren't free.
>(free IDE)
http://www.crimsoneditor.com/
It is very solid editor with "saving via ftp" feature.
--
Matija
------------------------------
Date: 8 Aug 2003 10:36:49 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Perl and C APIs
Message-Id: <bgvug1$3cf$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Gregski:
> I have an API which I wish to make accessible via Perl and I'm looking
> for some advice:
> Under C, I would normally set up sessions, register callbacks and then
> run a control-loop API call which holds my program until the session
> is broken; all processing of events is done solely through callbacks.
That would be the same approach in Perl. I assume you are talking about
XS here?
> I'm having difficulty in getting to grips with how best to approach
> this problem: if I purely tried to write a similar flow, I would never
> be able to return a session handle to Perl, control would only return
> once the API returned - useless because by then the session is broken.
> On the other hand, if I register Perl functions for the callbacks from
> C, I'm left with an un-Perl like program flow (yes, I know...),
> because what *I think* I'd really like to do is use Perl to read data
> in at polled intervals from the C-side called-back routines acting
> effectively as data collectors. But do I?
Sorry, I didn't understand any of these last words. But why would it be
'un-Perl' if you had your C core trigger Perl functions at the right
time? If I understand the scenario correctly, you have a C library. You
register a few callbacks via function pointers and then call the
function of this library that starts the mainloop. This function never
returns but instead triggers the callbacks. In Perl a lot of modules
work the very same way. It roughly looks like this:
$obj = Some::Class->new (
'callback1' => sub { my ($arg1, $arg2) = @_; ...; return $i },
'callback2' => sub { ... },
...
);
$obj->run;
From an XS point of view, new() will store the codereferences (those are
simply SV*'s) somewhere. Then it registers ordinary C callbacks. Since
you want to call Perl functions, these C callbacks have to retrieve the
respective code-reference, set up the argument stack and then call the
Perl functions. One implementation of the C callback that calls the Perl
code would be this:
int callback1 (int arg1, int arg2) {
SV *callback = function_that_retrieves_perl_callback(CALLBACK1);
/* set up the call stack */
dSP;
ENTER;
SAVETMPS;
PUSHMARK(SP);
/* callback1 expects two arguments */
XPUSHs(sv_2mortal(newSViv((IV)arg1)));
XPUSHs(sv_2mortal(newSViv((IV)arg2)));
PUTBACK;
/* run the callback */
count = call_sv(callback, G_SCALAR);
SPAGAIN;
/* check number of returned values */
if (count == 1)
/* our callback returned an int ($i in the above) */
ret = POPi;
else
croak("callback must return one value");
PUTBACK;
FREETMPS;
LEAVE;
/* return the value from the Perl callback to the C caller */
return ret;
}
This can get arbitrarily complex: any argument that the callbacks should
receive are pushed onto the stack. If you push the Perl object (provided
you have it accessible from C somewhere) onto it, the callbacks can even
be used as methods.
> One way round this would be to create a separate thread which enters
> the control-loop, leaving another thread to do its stuff.
Yeah, thread-safeness is extreme fun with extern C libraries.
> Additionally, since I want platform independence, I can't use fork.
>
> 1) What are my options?
>
> 2) Has anyone published a cookbook that deals with issues like these?
There appears to be no widely accepted way of doing that. It can get
nasty when the arguments the C callbacks receive shall differ from those
of the Perl callbacks. Then you start needing global variables to store
them etc (which again will turn thread-safeness issues into a nightmare).
Perhaps you should subscribe to perl-xs@perl.org. You are likely to find
more people with such problems there.
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: Fri, 8 Aug 2003 17:19:41 +0000 (UTC)
From: friedman@math.utexas.edu (Chas Friedman)
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.4 $)
Message-Id: <bh0m3d$9s8$1@geraldo.cc.utexas.edu>
tadmc@augustmail.com wrote:
>..................................
> Sending a "stealth" Cc copy
> A "stealth Cc" is when you both email and post a reply without
> indicating *in the body* that you are doing so.
>..................................
I've never done this, and I can't imagine why I would, but I've wondered
for some time why this is considered such a faux pas. Is it just that it
is annoying to go to the trouble of posting a response and then getting an
email that expects the same response, or is there some more subtle reason?
(My apologies if I shouldn't have posted this due to it's not being strictly
a perl question.)
Thanks for any comments!
chas
------------------------------
Date: 08 Aug 2003 18:31:51 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.4 $)
Message-Id: <u9wudorr7c.fsf@wcl-l.bham.ac.uk>
friedman@math.utexas.edu (Chas Friedman) writes:
> tadmc@augustmail.com wrote:
> >..................................
> > Sending a "stealth" Cc copy
> > A "stealth Cc" is when you both email and post a reply without
> > indicating *in the body* that you are doing so.
> >..................................
>
> I've never done this, and I can't imagine why I would, but I've wondered
> for some time why this is considered such a faux pas. Is it just that it
> is annoying to go to the trouble of posting a response and then getting an
> email that expects the same response,
Actually the cronology is reversed because mail get through faster
then news.
It annoying to go to the trouble of writing a personal response to an
email and then seeing the same posting and haviong to cut/paste the
response out of your "copies-to-self" and maybe re-phrase it a bit for
a public forum.
> (My apologies if I shouldn't have posted this due to it's not being strictly
> a perl question.)
No problem - you posted it in the "Posting Guidelines for
comp.lang.perl.misc" thread. Anyone who want's to avoid reading
meta-discussion arrising out of the guidelines will have killfiled
the subject line already.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
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.
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 5334
***************************************
