[30393] in Perl-Users-Digest
Perl-Users Digest, Issue: 1636 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 13 00:09:49 2008
Date: Thu, 12 Jun 2008 21:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 12 Jun 2008 Volume: 11 Number: 1636
Today's topics:
Re: DirectoryIndex not working with AuthDBI <jcharth@gmail.com>
Re: FAQ 7.14 What is variable suicide and how can I pre <bill@ts1000.us>
Re: How to unpack long long ? <ben@morrow.me.uk>
Re: How to unpack long long ? <uri@stemsystems.com>
Re: How to unpack long long ? <ben@morrow.me.uk>
Re: How to unpack long long ? <uri@stemsystems.com>
Re: Learning Perl <tadmc@seesig.invalid>
Re: Learning Perl <allergic-to-spam@no-spam-allowed.org>
LWP::UserAgent proxy issues <silentlox@gmail.com>
More questions about "perldoc perlembed" <jl_post@hotmail.com>
Re: More questions about "perldoc perlembed" <ben@morrow.me.uk>
Re: Reading a line from a CVS file into an array. <chad@chadhanna.co.uk>
Re: Reading a line from a CVS file into an array. xhoster@gmail.com
Simplest way (or module) to tweak query in CGI server-s <dearjerry@mindspring.com>
Re: Simplest way (or module) to tweak query in CGI serv <noreply@gunnar.cc>
Re: sorting a hash / 2008-06-01 <whynot@pozharski.name>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 12 Jun 2008 13:32:50 -0700 (PDT)
From: joe <jcharth@gmail.com>
Subject: Re: DirectoryIndex not working with AuthDBI
Message-Id: <ac5d2c9e-6df3-49a2-ad1d-afe049606f7f@f63g2000hsf.googlegroups.com>
On Jun 12, 3:21 pm, smallpond <smallp...@juno.com> wrote:
> joe wrote:
> > Hello I manage to get AuthDBI to work but now the directory does not
> > recognize index.php or index.htm when typingwww.domain.com i get
> > 403 and I get a list of files if I add Options Indexes. I believe it
> > could be related to not having perlhander but if I add apache::asp as
> > the perlhandler it does not work. Any suggestions? Thanks
>
> 403 Access Forbidden - not a perl problem. Look at the web server error logs.
Thanks for the reply. I dont see any related error in the logs. But if
I type something like www.domain.com/index.htm
it works. If I type www.domain.com/ or www.domain.com it does not
display the DirectoryIndex index.php or index.htm or index.html
files by defaul. The directoryindex directive works everywhere but not
in the authDBI protected folder. Ill try to disable other modules may
be it is just a conflict or a priority issue.
>
> ** Posted fromhttp://www.teranews.com**
------------------------------
Date: Thu, 12 Jun 2008 18:04:01 -0700 (PDT)
From: Bill H <bill@ts1000.us>
Subject: Re: FAQ 7.14 What is variable suicide and how can I prevent it?
Message-Id: <9bb88369-16f4-4e91-b51d-de7e70da207c@f63g2000hsf.googlegroups.com>
On Jun 12, 10:27=A0am, brian d foy <brian.d....@gmail.com> wrote:
> In article
> <a72f0e8e-7e89-4655-a129-56f5e42af...@t54g2000hsg.googlegroups.com>,
>
> Bill H <b...@ts1000.us> wrote:
> > On Jun 11, 9:03=A0am, PerlFAQ Server <br...@stonehenge.com> wrote:
>
> > > 7.14: What is variable suicide and how can I prevent it?
>
> > > =A0 =A0 This problem was fixed in perl 5.004_05, so preventing it mean=
s
> > > =A0 =A0 upgrading your version of perl. ;)
> > Two things:
>
> > 1) this just explains the behaviour - it doesn't say what to do
> > (unless I am blind)
>
> You mean what to do to prevent vaiable suicide? It's the first sentence
> of the answer: upgrade Perl.
I totally didnt see that. Maybe that should be at the end of the
explanation of what the problem is (also?).
Bill H
------------------------------
Date: Thu, 12 Jun 2008 21:35:39 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to unpack long long ?
Message-Id: <rtd8i5-77k.ln1@osiris.mauzo.dyndns.org>
Quoth Ted Zlatanov <tzz@lifelogs.com>:
> On Thu, 12 Jun 2008 18:20:55 +0100 Ben Morrow <ben@morrow.me.uk> wrote:
>
> BM> Quoth Golan <ghadad@gmail.com>:
> >> How do i unpack "long long" int type ( 8 bytes ) ?
>
> BM> 'q'. Note that your perl needs to be built with 64bit integers.
>
> That seems like an unnecessary restriction. Is it really impossible for
> a 32-bit Perl to decode 64-bit numbers? We know the endianness, is
> there anything else needed?
Err... a type to hold the value in? While you can hold numbers greater
than 2**32 in a NV, NVs only have 53 bits of precision (or, at least,
they do here) so they can't hold values up to 2**64 with integer
precision.
If you know the endianness and know the value will be small, or if you
use bigint, you can easily unpack as two longs and combine them.
Ben
--
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks] ben@morrow.me.uk
------------------------------
Date: Thu, 12 Jun 2008 21:44:32 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: How to unpack long long ?
Message-Id: <x77icumips.fsf@mail.sysarch.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Quoth Ted Zlatanov <tzz@lifelogs.com>:
>> On Thu, 12 Jun 2008 18:20:55 +0100 Ben Morrow <ben@morrow.me.uk> wrote:
>>
>> That seems like an unnecessary restriction. Is it really impossible for
>> a 32-bit Perl to decode 64-bit numbers? We know the endianness, is
>> there anything else needed?
BM> Err... a type to hold the value in? While you can hold numbers greater
BM> than 2**32 in a NV, NVs only have 53 bits of precision (or, at least,
BM> they do here) so they can't hold values up to 2**64 with integer
BM> precision.
good point.
BM> If you know the endianness and know the value will be small, or if you
BM> use bigint, you can easily unpack as two longs and combine them.
but that isn't really unpacking them. it is reordering bytes and it
still is a byte string. 32 bit perl has no direct way to interact with
64 bit numbers (some modules do xs trickery to hold 64 bit values like
Time::HiRes). so unpacking 8 bytes to 64 bits makes no sense in 32 bit
perl.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 13 Jun 2008 00:03:04 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to unpack long long ?
Message-Id: <8im8i5-rk21.ln1@osiris.mauzo.dyndns.org>
Quoth Uri Guttman <uri@stemsystems.com>:
> >>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
>
[unpack 'q' in 32bit perl]
>
> BM> If you know the endianness and know the value will be small, or if you
> BM> use bigint, you can easily unpack as two longs and combine them.
>
> but that isn't really unpacking them. it is reordering bytes and it
> still is a byte string. 32 bit perl has no direct way to interact with
> 64 bit numbers (some modules do xs trickery to hold 64 bit values like
> Time::HiRes). so unpacking 8 bytes to 64 bits makes no sense in 32 bit
> perl.
I meant something along the lines of
use bigint;
my ($l1, $l2) = unpack 'll', $quad;
my $num = ($l2<<32) + $l1;
(assuming LE quads). If you know the values will be below 2**53 and
replace '<<32' with '* 2**32' this will work without 'bigint'.
Ben
--
"Faith has you at a disadvantage, Buffy."
"'Cause I'm not crazy, or 'cause I don't kill people?"
"Both, actually."
[ben@morrow.me.uk]
------------------------------
Date: Fri, 13 Jun 2008 02:02:44 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: How to unpack long long ?
Message-Id: <x7fxrif5x8.fsf@mail.sysarch.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Quoth Uri Guttman <uri@stemsystems.com>:
>> >>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
>>
BM> [unpack 'q' in 32bit perl]
>>
BM> If you know the endianness and know the value will be small, or if you
BM> use bigint, you can easily unpack as two longs and combine them.
>>
>> but that isn't really unpacking them. it is reordering bytes and it
>> still is a byte string. 32 bit perl has no direct way to interact with
>> 64 bit numbers (some modules do xs trickery to hold 64 bit values like
>> Time::HiRes). so unpacking 8 bytes to 64 bits makes no sense in 32 bit
>> perl.
BM> I meant something along the lines of
BM> use bigint;
BM> my ($l1, $l2) = unpack 'll', $quad;
BM> my $num = ($l2<<32) + $l1;
BM> (assuming LE quads). If you know the values will be below 2**53 and
BM> replace '<<32' with '* 2**32' this will work without 'bigint'.
i understood your intent but your original comment overrides that. 32
bit perl can't handle 64 bit numbers. putting them into a double isn't
the same thing.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 12 Jun 2008 19:33:39 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Learning Perl
Message-Id: <slrng53g33.q9r.tadmc@tadmc30.sbcglobal.net>
Elizabeth Barnwell <elizabethbarnwell@gmail.com> wrote:
> Here is a set of flashcards our developers have been using to learn
> Perl with very good results:
Good results include thinking you have warnings turned on when you don't?
"What character is at the end of every Perl statement?"
^^^^^
while ( <> ) {
print
}
Look Ma! No semicolon!
> Add the subject to your study materials,
I'm going to have to take a pass.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Fri, 13 Jun 2008 05:16:57 +0200 (CEST)
From: Jim Cochrane <allergic-to-spam@no-spam-allowed.org>
Subject: Re: Learning Perl
Message-Id: <slrng53pk9.gvt.allergic-to-spam@no-spam-allowed.org>
On 2008-06-13, Tad J McClellan <tadmc@seesig.invalid> wrote:
> Elizabeth Barnwell <elizabethbarnwell@gmail.com> wrote:
>
>> Here is a set of flashcards our developers have been using to learn
>> Perl with very good results:
>
>
> Good results include thinking you have warnings turned on when you don't?
>
> "What character is at the end of every Perl statement?"
> ^^^^^
>
> while ( <> ) {
> print
> }
>
> Look Ma! No semicolon!
>
>
>> Add the subject to your study materials,
>
>
> I'm going to have to take a pass.
IOW, in Perl, a semicolon is a statement separator, not a statement
terminator.
--
------------------------------
Date: Thu, 12 Jun 2008 16:20:43 -0700 (PDT)
From: thesussman <silentlox@gmail.com>
Subject: LWP::UserAgent proxy issues
Message-Id: <c053664c-ad35-4ce3-bff8-6d4f56a17426@56g2000hsm.googlegroups.com>
Hello, I have a number of questions regarding the proxy function of
LWP::UserAgent.
What is the syntax of inputting proxies? In the official info page, it
is written ('http', 'http://proxy.sn.no:8001/'), so is the http prefix
for the proxy address necessary, or I can just specify vanilla IP
addresses suffixed with ports without the prefix?
The method demonstration in the documentation makes me curious once
again regarding the format of the proxy addresses: Is a plain IP
address - 127.0.0.1:80 for example alright, or I have to seek a proxy
with a dns (for example: los.micros.com:80)? Or maybe the CGI proxies
you can find for bypassing filters on the web (The ones where you
input your destination site address at) are enough? I didn't really
get it.
How can I confirm that the proxifying process succeeded? Is $proxy-
>proxy('http', '127.0.0.1:80') || if ($proxy->is_success) enough and
does the ->is_success method works on the proxy() function?
Best regards and thanks for reading,
Matt James
------------------------------
Date: Thu, 12 Jun 2008 17:00:22 -0700 (PDT)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: More questions about "perldoc perlembed"
Message-Id: <d11c0581-9827-4928-a8b7-5a5d7b3310f8@e39g2000hsf.googlegroups.com>
Hi,
I recently posted several questions on embedding Perl from a C++
program, and Ben Morrow and Rob (sisyphus) provided me with some great
help. Now I have a few more questions about it.
Before I ask the questions, let me say that I am trying to run Perl
scripts from a C++ executable compiled on Microsoft Visual Studio 2005
and running on Windows XP. The Perl code I am using is Perl 5.10 from
ActiveState. Ideally I want this to also work on Linux (and Windows
Vista), but right now I am focusing on getting it to work on Windows
XP.
What's more, I want these Perl scripts to call C++ code (or rather,
XS functions that call C++ code). So basically I am trying to modify
a C++ program to run Perl code that calls C++ code.
The package that I am defining is called "SCRIPTSPACE". When in
this package, a Perl script (run by my program) should be able to
access any function/method defined in the "SCRIPTSPACE.xs" file.
(And for the record, I've been reading through the perldocs for
"perlapi", "perlcall", "perlembed", "perlguts", "perlxs", and
"perlxstut".)
So anyway, here are my issues and questions:
Issue 1: At first, the code I used to invoke a PerlInterpreter was:
void runPerlScript(char * script_filename)
{
PerlInterpreter *my_perl = perl_alloc();
perl_construct(my_perl);
char* scriptArguments[] = { "PROGRAM",
"-w",
"-ID:/perl/lib",
script_filename };
const int numArguments = sizeof(scriptArguments) / sizeof(char*);
const int parseResult = perl_parse(my_perl, xs_init, numArguments,
scriptArguments, (char**) NULL);
if (parseResult == 0)
perl_run(my_perl);
perl_destruct(my_perl);
perl_free(my_perl);
}
with xs_init() defined as:
// This next section was taken straight out of "perldoc perlembed":
EXTERN_C void boot_DynaLoader(pTHX_ CV* cv);
EXTERN_C void boot_SCRIPTSPACE(pTHX_ CV* cv);
EXTERN_C static void xs_init(pTHX)
{
char *file = __FILE__;
// DynaLoader is a special case:
newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, file);
newXS("SCRIPTSPACE::bootstrap", boot_SCRIPTSPACE, file);
}
Now, when I try to run the following simple little Perl script:
#!/usr/bin/perl
SCRIPTSPACE::setPreferences( {} ); # takes a hash reference
__END__
the following error message gets printed:
Undefined subroutine &SCRIPTSPACE::setPreferences called at D:\scripts
\test_script.pl line 2.
Wondering why the setPreferences() function couldn't be seen, I
asked a co-worker about it. He suggested that maybe SCRIPTSPACE's
"BOOT" section was not being executed, and to put a breakpoint there
to see if it ever executes. So I put a breakpoint at the first line
of the "BOOT:" code block, and sure enough, the breakpoint is never
hit.
Now, I remember reading in one of the perldocs (can't remember
which one) that ordinarily the BOOT section gets executed when "use
Module;" is encountered in the Perl script. However, that won't work
in my case because there is no "SCRIPTSPACE.pm" file -- just *.xs
code.
(I previously thought that putting the:
newXS("SCRIPTSPACE::bootstrap", boot_SCRIPTSPACE, file);
line inside the xs_init() function would be enough to call the BOOT
code, but apparently I was wrong.)
So I tried to figure out how to invoke this BOOT code from inside
my runPerlScript() C++ function. I saw from another person's previous
code attempts that:
{
dSP;
PUSHMARK(SP);
call_pv("SCRIPTSPACE::bootstrap", G_DISCARD|G_NOARGS) ;
}
had been tried. However, I never got that to work (the call_pv() line
would always crash my program), not even without the "dSP;" and
"PUSHMARK(SP);" lines.
Eventually I found that the following line of code:
eval_pv("SCRIPTSPACE::bootstrap", TRUE);
successfully invoked the BOOT section. However, it only worked AFTER
I called perl_parse() with the xs_init argument, and since my Perl
script wouldn't run correctly until the BOOT section executed, I had
to do it BEFORE I ran my script. So essentially I was calling the
perl_parse() function without a scriptname, like this:
char* scriptArguments[] = { "PROGRAM",
"-w",
"-ID:/perl/lib",
script_filename };
const int numArguments = sizeof(scriptArguments) / sizeof(char*);
perl_parse(my_perl, xs_init, numArguments-1, scriptArguments,
(char**) NULL);
eval_pv("SCRIPTSPACE::bootstrap", TRUE); // invokes "BOOT:"
So question 1 is: Is it correct for me to call
'eval_pv("SCRIPTSPACE::bootstrap", TRUE);' to "BOOT" SCRIPTSPACE, or
should I use call_pv() instead (or perhaps something else altogether)?
Issue 2: Now that I have the SCRIPTSPACE package "BOOT"ing up, I want
to execute my test perl script. I figure I can call perl_parse()
again right after the call to eval_pv("SCRIPTSPACE::bootstrap",
TRUE). So now my runPerlScript() function looks like:
void runPerlScript(char * script_filename)
{
PerlInterpreter *my_perl = perl_alloc();
perl_construct(my_perl);
char* scriptArguments[] = { "PROGRAM",
"-w",
"-ID:/perl/lib",
script_filename };
const int numArguments = sizeof(scriptArguments) / sizeof(char*);
perl_parse(my_perl, xs_init, numArguments-1, scriptArguments,
(char**) NULL);
eval_pv("SCRIPTSPACE::bootstrap", TRUE); // invokes the "BOOT:"
code
const int parseResult = perl_parse(my_perl, NULL, numArguments,
scriptArguments, (char**) NULL);
if (parseResult == 0)
perl_run(my_perl);
perl_destruct(my_perl);
perl_free(my_perl);
}
But now when the call to perl_run() executes, I still get this same
error:
Undefined subroutine &SCRIPTSPACE::setPreferences called at D:\scripts
\test_script.pl line 2.
So I thought about this for a while... Could my_perl not have access
to the SCRIPTSPACE functions? To test whether it did or not, I
inserted the following line right beneath the
'eval_pv("SCRIPTSPACE::bootstrap", TRUE)' line:
eval_pv("SCRIPTSPACE::setPreferences( {} )", TRUE);
and placed a breakpoint on the first line of SCRIPTSPACE's
setPreferences XS function. When I tried re-running the Perl script,
the breakpoint was hit as the program executed that line (and that
error message wasn't displayed).
So apparently eval_pv() can see the SCRIPTSPACE::setPreferences()
function, but perl_run() cannot.
So question 2 is: Why can eval_pv() "see" the SCRIPTSPACE functions
but perl_run() cannot?
Issue 3: After a little more thought, I figured that if eval_pv() can
"see" SCRIPTSPACE, why not just read the script into a variable and
execute that through eval_pv()? So then my runPerlScript() function
looked like:
void runPerlScript(char * script_filename)
{
PerlInterpreter *my_perl = perl_alloc();
perl_construct(my_perl);
char* scriptArguments[] = { "PROGRAM",
"-w",
"-ID:/perl/lib",
script_filename };
const int numArguments = sizeof(scriptArguments) / sizeof(char*);
perl_parse(my_perl, xs_init, numArguments-1, scriptArguments,
(char**) NULL);
eval_pv("SCRIPTSPACE::bootstrap", TRUE); // invokes the "BOOT:"
code
std::ifstream inFile(script_filename);
if (inFile.is_open())
{
// Read the entire file contents
// into the fileContents variable
// and execute it with eval_pv():
const std::string fileContents =
std::string( std::istreambuf_iterator<char>( inFile ),
std::istreambuf_iterator<char>( ) );
inFile.close();
eval_pv(fileContents.c_str(), FALSE);
}
perl_destruct(my_perl);
perl_free(my_perl);
}
Then when my program ran the test script, it worked! (I also
tested it on larger scripts, and they worked, too.) However, even
though this approach with eval_pv() worked, I would prefer to use
perl_parse() and perl_run(), since they give me more control over
seeing if parsing and running succeeded (so I can report an error if
one fails).
So question 3 is: Is there any way I can run my Perl scripts with
calls to perl_parse() and perl_run(), or am I pretty much limited to
using eval_pv()?
That's it for now. I have a few more issues other than the ones I
posted, but I'll think I'll try working them out on my own first.
Thank you in advance for any advice.
-- Jean-Luc
------------------------------
Date: Fri, 13 Jun 2008 04:33:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: More questions about "perldoc perlembed"
Message-Id: <oc69i5-unb1.ln1@osiris.mauzo.dyndns.org>
Quoth "jl_post@hotmail.com" <jl_post@hotmail.com>:
<snip background>
>
> Issue 1: At first, the code I used to invoke a PerlInterpreter was:
>
> void runPerlScript(char * script_filename)
> {
> PerlInterpreter *my_perl = perl_alloc();
> perl_construct(my_perl);
>
> char* scriptArguments[] = { "PROGRAM",
> "-w",
> "-ID:/perl/lib",
> script_filename };
> const int numArguments = sizeof(scriptArguments) / sizeof(char*);
>
> const int parseResult = perl_parse(my_perl, xs_init, numArguments,
> scriptArguments, (char**) NULL);
> if (parseResult == 0)
> perl_run(my_perl);
>
> perl_destruct(my_perl);
> perl_free(my_perl);
> }
>
> with xs_init() defined as:
>
> // This next section was taken straight out of "perldoc perlembed":
> EXTERN_C void boot_DynaLoader(pTHX_ CV* cv);
> EXTERN_C void boot_SCRIPTSPACE(pTHX_ CV* cv);
> EXTERN_C static void xs_init(pTHX)
> {
> char *file = __FILE__;
> // DynaLoader is a special case:
> newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, file);
> newXS("SCRIPTSPACE::bootstrap", boot_SCRIPTSPACE, file);
> }
>
> Now, when I try to run the following simple little Perl script:
>
> #!/usr/bin/perl
> SCRIPTSPACE::setPreferences( {} ); # takes a hash reference
> __END__
>
> the following error message gets printed:
>
> Undefined subroutine &SCRIPTSPACE::setPreferences called at D:\scripts
> \test_script.pl line 2.
How are you compiling SCRIPTSPACE.xs? Do you have some particular need
for it to not be an ordinary XS module? I would have thought the easiest
thing to do would be to build and install SCRIPTSPACE as an ordinary XS
module, including a .pm that probably just calls XSLoader::load, and
then 'use' that module from your Perl program. That way you can omit
boot_SCRIPTSPACE from xs_init altogether, and let DynaLoader handle it.
If you want to call functions in your main program from XS, this
shouldn't be a problem. You need to make sure they're exported (I don't
remember how this works under Win32; under Unix it's easy, everything's
available without asking, but under Win32 you have to mark functions
specially if you want a dll to be able to call them) but then you should
be able to just call them from SCRIPTSPACE.xs. Of course, that
SCRIPTSPACE module will now not work if loaded into an ordinary perl,
but I doubt that's a problem.
> Wondering why the setPreferences() function couldn't be seen, I
> asked a co-worker about it. He suggested that maybe SCRIPTSPACE's
> "BOOT" section was not being executed, and to put a breakpoint there
> to see if it ever executes. So I put a breakpoint at the first line
> of the "BOOT:" code block, and sure enough, the breakpoint is never
> hit.
Is SCRIPTSPACE.dll even being loaded? If you don't call DynaLoader, I
can't see why it would be.
<snip>
> Eventually I found that the following line of code:
>
> eval_pv("SCRIPTSPACE::bootstrap", TRUE);
>
> successfully invoked the BOOT section. However, it only worked AFTER
> I called perl_parse() with the xs_init argument, and since my Perl
> script wouldn't run correctly until the BOOT section executed, I had
> to do it BEFORE I ran my script.
Well, you can't call SCRIPTSPACE::bootstrap before xs_init has installed
it. You could, perhaps, call it *from* xs_init, after the newXS calls?
> So essentially I was calling the
> perl_parse() function without a scriptname, like this:
>
> char* scriptArguments[] = { "PROGRAM",
> "-w",
> "-ID:/perl/lib",
> script_filename };
> const int numArguments = sizeof(scriptArguments) / sizeof(char*);
> perl_parse(my_perl, xs_init, numArguments-1, scriptArguments,
> (char**) NULL);
> eval_pv("SCRIPTSPACE::bootstrap", TRUE); // invokes "BOOT:"
>
> So question 1 is: Is it correct for me to call
> 'eval_pv("SCRIPTSPACE::bootstrap", TRUE);' to "BOOT" SCRIPTSPACE, or
> should I use call_pv() instead (or perhaps something else altogether)?
Well, I would say you should be letting DynaLoader handle that for you.
If you don't want to do that for some reason, read DynaLoader.pm or
XSLoader.pm and the appropriate .xs for your platform to see what the
right thing to do is.
> Issue 2: Now that I have the SCRIPTSPACE package "BOOT"ing up, I want
> to execute my test perl script. I figure I can call perl_parse()
> again right after the call to eval_pv("SCRIPTSPACE::bootstrap",
> TRUE).
I don't think calling perl_parse twice on the same interpreter is valid.
If you *must* follow this approach, better would be something like
eval_pv("do q!scriptname!", TRUE);
> So now my runPerlScript() function looks like:
>
<snip>
> perl_parse(my_perl, xs_init, numArguments-1, scriptArguments,
> (char**) NULL);
>
> eval_pv("SCRIPTSPACE::bootstrap", TRUE); // invokes the "BOOT:"
> code
>
> const int parseResult = perl_parse(my_perl, NULL, numArguments,
> scriptArguments, (char**) NULL);
<snip>
>
> But now when the call to perl_run() executes, I still get this same
> error:
>
> Undefined subroutine &SCRIPTSPACE::setPreferences called at D:\scripts
> \test_script.pl line 2.
>
> So I thought about this for a while... Could my_perl not have access
> to the SCRIPTSPACE functions? To test whether it did or not, I
> inserted the following line right beneath the
> 'eval_pv("SCRIPTSPACE::bootstrap", TRUE)' line:
>
> eval_pv("SCRIPTSPACE::setPreferences( {} )", TRUE);
>
> and placed a breakpoint on the first line of SCRIPTSPACE's
> setPreferences XS function. When I tried re-running the Perl script,
> the breakpoint was hit as the program executed that line (and that
> error message wasn't displayed).
>
> So apparently eval_pv() can see the SCRIPTSPACE::setPreferences()
> function, but perl_run() cannot.
>
> So question 2 is: Why can eval_pv() "see" the SCRIPTSPACE functions
> but perl_run() cannot?
I suspect that repeating perl_parse has clobbered things that shouldn't
have been clobbered, and that essentially you have started again with a
fresh perl interpreter that hasn't called SCRIPTSPACE::bootstrap yet. I
also suspect that, since you didn't call perl_destruct, this interpreter
is now in a mess, and things will go wrong :).
> Issue 3: After a little more thought, I figured that if eval_pv() can
> "see" SCRIPTSPACE, why not just read the script into a variable and
> execute that through eval_pv()? So then my runPerlScript() function
> looked like:
<snip>
>
> Then when my program ran the test script, it worked! (I also
> tested it on larger scripts, and they worked, too.) However, even
> though this approach with eval_pv() worked, I would prefer to use
> perl_parse() and perl_run(), since they give me more control over
> seeing if parsing and running succeeded (so I can report an error if
> one fails).
>
> So question 3 is: Is there any way I can run my Perl scripts with
> calls to perl_parse() and perl_run(), or am I pretty much limited to
> using eval_pv()?
If you want to have multiple passes through perl_parse/perl_run, I think
you need to clean up in between with perl_destruct, and this will unload
all your extensions. Note that eval_pv("do...") will substitute for
reading the file yourself. I don't think there's any easy way to
separate the 'compile' and 'run' phases of an eval. If you're willing to
poke through pp_ctl.c it may be possible to call pp_entereval directly,
and then run the returned optree yourself, but it probably requires
fairly detailed knowledge of the perl runloop to get right.
Ben
--
All persons, living or dead, are entirely coincidental.
ben@morrow.me.uk Kurt Vonnegut
------------------------------
Date: Thu, 12 Jun 2008 22:11:41 +0100
From: Chad Hanna <chad@chadhanna.co.uk>
Subject: Re: Reading a line from a CVS file into an array.
Message-Id: <g2s3ed$1fm$1$8302bc10@news.demon.co.uk>
coffeevictim wrote:
> Hi,
>
> I have the fairly simply task of manipulating a CSV file containing
> marketing data (name, address, business description etc.) so it can be
> imported into a CRM system.
>
> The problem is that some of the text fields also contain commas so I
> am a bit stumped as to how to construct a command that will accurately
> split the line at the actual separators. The text containing commas
> that are not separators is quoted so Excel does not have a problem
> understanding it but I can not think how to get my script to ignore
> the ones in quotes.
>
> coffeevictim
If you can't use Text::CSV_XS (or Text::CSV) look at perlfaq4 for "How
can I split a [character] delimited string except when inside [character]?"
Chad
--
Chad Hanna
Systems Developer FamilyHistoryOnline www.familyhistoryonline.net
FreeBSD Apache MySQL Perl mod_perl PHP
------------------------------
Date: 12 Jun 2008 21:40:36 GMT
From: xhoster@gmail.com
Subject: Re: Reading a line from a CVS file into an array.
Message-Id: <20080612174039.322$8A@newsreader.com>
coffeevictim <colin@yoursupport.biz> wrote:
> On 12 Jun, 19:52, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> > coffeevictim <co...@yoursupport.biz> wrote:
> > >The problem is that some of the text fields also contain commas so I
> > >am a bit stumped as to how to construct a command that will accurately
> > >split the line at the actual separators.
> >
> > I don't know the file format CVS, but if you are talking about CSV then
> > is there anything wrong with Text::CSV?
> >
> > jue
>
> CSV. My mistake.
>
> Since I wish to execute the script at the Windows command line and
> make it as portable as possible, I was hoping to to use just perl.exe.
You could use Text::Balanced, which I think is a core module and so should
be available wherever Perl is. If you insist on doing it without modules,
and are using Excel style (comma are protected by wrapping in double quotes
and literal double quotes are escaped by doubling them) then maybe this:
my @x = split /,(?=[^\"]*(?:\"[^\"]*\"[^\"]*)*$)/ ;
It just does the splitting, it doesn't deprotect or deescape. And embedded
newlines are not tolerated.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 12 Jun 2008 18:10:38 -0700 (PDT)
From: Jerry Krinock <dearjerry@mindspring.com>
Subject: Simplest way (or module) to tweak query in CGI server-side validation
Message-Id: <18347ab8-ebbc-4409-a3d6-b4b240e031e2@25g2000hsx.googlegroups.com>
I've been working on my first perl cgi script for server-side form
validation today. I was amazed to find out that, after validating,
all I have to do is
print "Location: $redirect\n\n";
and my form gets redirected to another script. One line? No
modules? Great!
However, it looks like this simply passes through the received query
string, and now I realize I need to change a value or two in the query
after validation, for example, multiplying price by a coupon discount.
Is there any similar simple way to edit the query before sending the
redirect? Or do I need a module? Looks like
use CGI ;
has the functions I need. But I see there are other modules
available. If I need a module, what is a good one that my web host is
likely to have already installed?
Thank you,
Jerry Krinock
------------------------------
Date: Fri, 13 Jun 2008 04:37:48 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Simplest way (or module) to tweak query in CGI server-side validation
Message-Id: <6be4udF3a4mejU1@mid.individual.net>
Jerry Krinock wrote:
> I've been working on my first perl cgi script for server-side form
> validation today. I was amazed to find out that, after validating,
> all I have to do is
>
> print "Location: $redirect\n\n";
>
> and my form gets redirected to another script. One line? No
> modules? Great!
>
> However, it looks like this simply passes through the received query
> string, and now I realize I need to change a value or two in the query
> after validation, for example, multiplying price by a coupon discount.
Sounds like you don't want to just redirect, after all, but rather
submit a new query. The libwww-perl family of modules can do that; see
for instance LWP::UserAgent.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Thu, 12 Jun 2008 22:44:54 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: sorting a hash / 2008-06-01
Message-Id: <mua8i5x53o.ln2@carpet.zombinet>
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "EP" == Eric Pozharski <whynot@pozharski.name> writes:
*SKIP*
> EP> print "$site $_ $urls{$site}{$_}[0] $urls{$site}{$_}[1]\n"
> EP> foreach(
> EP> sort { $urls{$site}{$a}[0] <=> $urls{$site}{$b}[0]; }
> EP> sort { $urls{$site}{$a}[1] <=> $urls{$site}{$b}[1]; }
> EP> keys %{$urls{$site}});
> are you (or the OP) trying to do a multilevel sort?
Me. That was my guess.
> it looks like yours will work but it is unusual to do two sort passes.
I have unusual habbit of chaining C<map>s and C<grep>s. That was plain
inertia.
> and it relies on the sort to be stable (meaning equal keys stay in the
> same ordering post sort). perl now uses a stable sort but earlier
> versions didn't. it is not something you should depend upon.
I rarely C<sort> (honestly, I don't at all). However I've definetely
seen notes on stability of C<sort>. I was ignorant. Mea culpa.
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1636
***************************************
