[13662] in Perl-Users-Digest
Perl-Users Digest, Issue: 1072 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Oct 15 15:27:22 1999
Date: Fri, 15 Oct 1999 12:27:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <940015624-v9-i1072@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 15 Oct 1999 Volume: 9 Number: 1072
Today's topics:
Perl ISAPI not seeming to work quickly. zeushao@my-deja.com
Re: Perl ISAPI not seeming to work quickly. <gellyfish@gellyfish.com>
Re: Perl ISAPI not seeming to work quickly. <ehpoole@ingress.com>
Re: Perl lite (Martien Verbruggen)
Re: Perl lite (Ilya Zakharevich)
Re: Perl lite (Bart Lateur)
Re: Perl lite (Abigail)
Re: Perl lite (Martien Verbruggen)
Re: Perl lite (Bart Lateur)
Re: Perl lite <dan@tuatha.sidhe.org>
Re: Perl lite (Abigail)
Re: Perl lite <rra@stanford.edu>
Re: Perl lite (Bart Lateur)
Re: Perl lite <carlj@peak.org>
Re: Perl lite (David Wall)
Re: Perl lite (Bart Lateur)
Perl Modules in AIX <veratude@us.ibm.com>
Re: Perl Modules in AIX <rra@stanford.edu>
Re: Perl Modules in AIX <bveratudela@austin.rr.com>
perl mysql problems <jdibiase@sminter.com.ar>
Re: perl mysql problems <amonotod@netscape.net>
Re: perl mysql problems <gellyfish@gellyfish.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 14 Oct 1999 17:07:06 GMT
From: zeushao@my-deja.com
Subject: Perl ISAPI not seeming to work quickly.
Message-Id: <7u52je$t8k$1@nnrp1.deja.com>
Hi! I'm using the latest version of Perl ISAPI from ActiveState. The
platform is NT 4/SP3 IIS4. Working locally, a very simple script takes
about 5-6 seconds to load. I have another machine which runs RedHat 6.0
and apache. On that machine, the same script takes less than a half
second to load.
The file association in this dratted configuration tool that comes with
IIS is '.plx' mapped to 'c:\perl\bin\perlis.dll'. The scripts run, just
very very slowly. If I change their names to .pl and associate that
with 'c:\perl\bin\perl.exe %s %s' (the default), they run equally
slowly. Any idea why ISAPI doesn't seem to be speeding things up at
all? And why ActiveState's perl interpreter is so slow?
--Johnny Wales
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: 14 Oct 1999 21:21:41 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Perl ISAPI not seeming to work quickly.
Message-Id: <7u5hh5$1f8$1@gellyfish.btinternet.com>
On Thu, 14 Oct 1999 17:07:06 GMT zeushao@my-deja.com wrote:
> Hi! I'm using the latest version of Perl ISAPI from ActiveState. The
> platform is NT 4/SP3 IIS4. Working locally, a very simple script takes
> about 5-6 seconds to load. I have another machine which runs RedHat 6.0
> and apache. On that machine, the same script takes less than a half
> second to load.
>
> The file association in this dratted configuration tool that comes with
> IIS is '.plx' mapped to 'c:\perl\bin\perlis.dll'. The scripts run, just
> very very slowly. If I change their names to .pl and associate that
> with 'c:\perl\bin\perl.exe %s %s' (the default), they run equally
> slowly. Any idea why ISAPI doesn't seem to be speeding things up at
> all? And why ActiveState's perl interpreter is so slow?
>
Of course it might just be the server itself ... I would suggest that you
ask in comp.infosystems.www.servers.ms-windows - even with the crap PWS
running on my desktop machine at work I dont get that kind of difference.
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Fri, 15 Oct 1999 02:41:50 -0400
From: "Ethan H. Poole" <ehpoole@ingress.com>
Subject: Re: Perl ISAPI not seeming to work quickly.
Message-Id: <3806CCAE.981531E6@ingress.com>
zeushao@my-deja.com wrote:
>
> Hi! I'm using the latest version of Perl ISAPI from ActiveState. The
> platform is NT 4/SP3 IIS4. Working locally, a very simple script takes
> about 5-6 seconds to load. I have another machine which runs RedHat 6.0
> and apache. On that machine, the same script takes less than a half
> second to load.
I, too, have noticed that the Win32 Perl port still needs a fair amount of
optimization.
> The file association in this dratted configuration tool that comes with
> IIS is '.plx' mapped to 'c:\perl\bin\perlis.dll'. The scripts run, just
> very very slowly. If I change their names to .pl and associate that
> with 'c:\perl\bin\perl.exe %s %s' (the default), they run equally
> slowly. Any idea why ISAPI doesn't seem to be speeding things up at
> all? And why ActiveState's perl interpreter is so slow?
My suspicion would be that the Win32 Perl port may not yet be particularly
optimized for the Win32 platform(s). I have not had the time to
investigate the source for Perl, but it would not be very difficult to
imagine that there may still be a lot of code in Perl that was written
with UNIX platforms in mind and which has not been rewritten (and
optimized) for the Win32 port. A unified port which supports Win32 in the
same source distribution as UNIX was a very recent development in the
Win32 world.
I do know that if I write similar code in C and compile it on both Windows
NT and Linux, I will get substantially similar performance between the two
systems, which *suggests* (like I said, I have not had time to investigate
the code to see if there is some other reason for the present penalty)
that it should be possible to improve the performance on Win32
significantly. I have noticed that file I/O is one area that tends to
score poorly on the Win32 Perl port and that could easily be a significant
contributor to the performance penalty, particularly if similar code is
also handling the reading of the source to compile a given script.
As for not observing any significant performance improvement with the
ISAPI Perl DLL, have you disabled caching of Extensions (it should be
Enabled)? I have not seen many instances where there was more-or-less
zero improvement when the DLL is cached.
It is worth noting that each of us who use the Win32 Perl ports are now
empowered with the source code to make performance improvements if we wish
and they may well find their way into future distributions if people share
them with the current developers. I know I have been planning to take a
look at the code when I can find some time between projects. It is in
every Perl developer's best interest to help improve Perl wherever
possible.
--
Ethan H. Poole **** BUSINESS ****
ehpoole@ingress.com ==Interact2Day, Inc.==
(personal) http://www.interact2day.com/
------------------------------
Date: Tue, 12 Oct 1999 23:19:39 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: Perl lite
Message-Id: <fmPM3.89$jg4.2574@nsw.nnrp.telstra.net>
On 12 Oct 1999 14:49:29 -0500,
Abigail <abigail@delanet.com> wrote:
> Dan Sugalski (dan@tuatha.sidhe.org) wrote on MMCCXXXIII September
> MCMXCIII in <URL:news:wCMM3.481$IZ5.14254@news.rdc1.ct.home.com>:
> !! The Glauber <theglauber@my-deja.com> wrote:
> !! Hmmm. Configure definitely warns about slowdowns. On the other hand, I
> !! know AIX resolves its symbols at link time instead of runtime (like
> !! VMS does) so it may be that you pay the price when perl's built rather
> !! than when perl's invoked.
>
> Well, just saying "it's slower on this OS, and there's no penalty on
> this OS" is only half of the story.
>
> The other half is at least as important, and is "how are you using perl?".
>
> At my previous job, we noticed a definitive improvement when going from
> a static to a dynamic perl, when the main use of Perl was for a badly
> written Perl/Tk application on an E3000, with 50+ instances running
> simultaneously.
And this is one of the keys. If you know that you will have many
instances of perl running at once (where many varies per architecture,
OS, and hardware specs), binaries linked against shared libraries more
often than not outperform the same binaries statically linked.
Especially if those many instances are going to be shortlived
processes (think CGI). When you only run one or two perls, now and
again, the static version will most likely be faster.
It has to do with caching, memory mapping and sharing and that sort of
stuff. But there is no way to be sure unless you test it, in a 'real
life' situation, mimicking the load you expect.
I'd be surprised to see enormous differences though. Most modern,
decent, OSes are quite good at link-time or run-time work.
Martien
--
Martien Verbruggen |
Interactive Media Division | That's not a lie, it's a terminological
Commercial Dynamics Pty. Ltd. | inexactitude.
NSW, Australia |
------------------------------
Date: 12 Oct 1999 23:26:51 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Perl lite
Message-Id: <7u0g3r$qos$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Martien Verbruggen
<mgjv@comdyn.com.au>],
who wrote in article <fmPM3.89$jg4.2574@nsw.nnrp.telstra.net>:
> And this is one of the keys. If you know that you will have many
> instances of perl running at once (where many varies per architecture,
> OS, and hardware specs), binaries linked against shared libraries more
> often than not outperform the same binaries statically linked.
Of course, this may happen on the systems which were badly designed only.
There is no reason why pages of executable modules should not be
handled identically to instances of loaded shared modules.
> I'd be surprised to see enormous differences though. Most modern,
> decent, OSes are quite good at link-time or run-time work.
I would say that modern OSes will have static version outperform
dynamic one - except on the systems with compile-time name resolution,
when the only additional overhead of dynaloading may be opening an
extra file.
Ilya
------------------------------
Date: Wed, 13 Oct 1999 06:40:51 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Perl lite
Message-Id: <38052822.1940170@news.skynet.be>
Ilya Zakharevich wrote:
>>binaries linked against shared libraries more
>> often than not outperform the same binaries statically linked.
>
>Of course, this may happen on the systems which were badly designed only.
>
>There is no reason why pages of executable modules should not be
>handled identically to instances of loaded shared modules.
Heh? I don't get it.
If you have, say, 10 copies of Perl statically linked, running, then
there's 10 *different* copies of Perl loaded. If it's linked
dynamically, there's *one* copy of the common library loaded. There's no
need to load 9 additional copies, and that's why I expect it to be
faster on shortlived scripts, as Martien said, *and* gentler on the
memory load of the computer, as Abigail confirmed.
Think swapping. If there's a task switch from one PErl to another,
there's no need to remove the Perl library from memory and loading the
other copy. So, on heavily loaded machines, I expect the difference to
be bigger, in favour of dynamically linked executables.
--
Bart.
------------------------------
Date: 13 Oct 1999 06:08:18 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Perl lite
Message-Id: <slrn808q0j.nk2.abigail@alexandra.delanet.com>
Bart Lateur (bart.lateur@skynet.be) wrote on MMCCXXXIV September MCMXCIII
in <URL:news:38052822.1940170@news.skynet.be>:
() Ilya Zakharevich wrote:
()
() >>binaries linked against shared libraries more
() >> often than not outperform the same binaries statically linked.
() >
() >Of course, this may happen on the systems which were badly designed only.
() >
() >There is no reason why pages of executable modules should not be
() >handled identically to instances of loaded shared modules.
()
() Heh? I don't get it.
()
() If you have, say, 10 copies of Perl statically linked, running, then
() there's 10 *different* copies of Perl loaded. If it's linked
() dynamically, there's *one* copy of the common library loaded. There's no
() need to load 9 additional copies, and that's why I expect it to be
() faster on shortlived scripts, as Martien said, *and* gentler on the
() memory load of the computer, as Abigail confirmed.
There's a difference between how it's done on certain OSses, and
how it _could_ be done.
() Think swapping. If there's a task switch from one PErl to another,
() there's no need to remove the Perl library from memory and loading the
() other copy. So, on heavily loaded machines, I expect the difference to
() be bigger, in favour of dynamically linked executables.
Tell me.... is there really a need to keep identical copies in memory?
Abigail
--
perl -weprint\<\<EOT\; -eJust -eanother -ePerl -eHacker -eEOT
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 13 Oct 1999 11:20:05 GMT
From: mgjv@wobbie.heliotrope.home (Martien Verbruggen)
Subject: Re: Perl lite
Message-Id: <slrn808qoi.a18.mgjv@wobbie.heliotrope.home>
On Wed, 13 Oct 1999 06:40:51 GMT,
Bart Lateur <bart.lateur@skynet.be> wrote:
> Ilya Zakharevich wrote:
>
> >>binaries linked against shared libraries more
> >> often than not outperform the same binaries statically linked.
> >
> >Of course, this may happen on the systems which were badly designed only.
> >
> >There is no reason why pages of executable modules should not be
> >handled identically to instances of loaded shared modules.
>
> Heh? I don't get it.
>
> If you have, say, 10 copies of Perl statically linked, running, then
> there's 10 *different* copies of Perl loaded. If it's linked
> dynamically, there's *one* copy of the common library loaded. There's no
> need to load 9 additional copies, and that's why I expect it to be
> faster on shortlived scripts, as Martien said, *and* gentler on the
> memory load of the computer, as Abigail confirmed.
Nono.. I think Ilya might be right, for some modern OSes. I wanted to
go off and have a look at the sources for Linux and OpenBSD to see
what they do (I expect Linux doesn't, and OpenBSD does have awareness
of this), but I don't have the time, so I'll take Ilya's word for it
:).
Since the OS _can_ know whether a binary is the same, it _can_ share
memory pages between the processes. In the past that sort of behaviour
you would only see on forks, and of course on shared libraries. And
you'd use some sort of copy-on-write scheme.
> Think swapping. If there's a task switch from one PErl to another,
> there's no need to remove the Perl library from memory and loading the
> other copy. So, on heavily loaded machines, I expect the difference to
> be bigger, in favour of dynamically linked executables.
Yes, for dynamically loaded modules that's a clear one. But there is
really nothing to stop the OS of figuring out how much can be shared
between a number of related processes. The hard part would be to
identify which ones are related in the first place. Once you know
that, you just copy memory pages on demand.
I wouldn't want to write that sort of memory management though. A
shared library makes it a lot easier :)
Martien
--
Martien Verbruggen |
Interactive Media Division | Make it idiot proof and someone will make a
Commercial Dynamics Pty. Ltd. | better idiot.
NSW, Australia |
------------------------------
Date: Wed, 13 Oct 1999 10:58:05 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Perl lite
Message-Id: <3804656c.191853@news.skynet.be>
Abigail wrote:
>Tell me.... is there really a need to keep identical copies in memory?
Well... YOU know these are identical copies. The OS doesn't know.
--
Bart.
------------------------------
Date: Wed, 13 Oct 1999 14:25:39 GMT
From: Dan Sugalski <dan@tuatha.sidhe.org>
Subject: Re: Perl lite
Message-Id: <DD0N3.605$IZ5.15157@news.rdc1.ct.home.com>
Bart Lateur <bart.lateur@skynet.be> wrote:
> Abigail wrote:
>>Tell me.... is there really a need to keep identical copies in memory?
> Well... YOU know these are identical copies. The OS doesn't know.
Sure it does. It's the one that loaded up the executable in the first
place, after all. And every file in the filesystem has a short,
unique identifier (FID, or inode/device, or whatever windows uses) so
it's certainly in a position to check. And scanning through an in-mem
list of open executables is a darned sight cheaper than hitting disk.
I was under the impression that Unix has done this for years. Isn't
that what the sticky bit's for?
Dan
------------------------------
Date: 13 Oct 1999 14:18:32 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Perl lite
Message-Id: <slrn809mno.nk2.abigail@alexandra.delanet.com>
Bart Lateur (bart.lateur@skynet.be) wrote on MMCCXXXIV September MCMXCIII
in <URL:news:3804656c.191853@news.skynet.be>:
** Abigail wrote:
**
** >Tell me.... is there really a need to keep identical copies in memory?
**
** Well... YOU know these are identical copies. The OS doesn't know.
*Blink*
Both executables and dynamic libraries are files. Are you suggesting
there's some black magic that prevents the OS from knowing that when the
same executable is run twice they are indentical, but if said executable
loads a dynamic library, the OS does know they are identical?
Abigail
--
sub camel (^#87=i@J&&&#]u'^^s]#'#={123{#}7890t[0.9]9@+*`"'***}A&&&}n2o}00}t324i;
h[{e **###{r{+P={**{e^^^#'#i@{r'^=^{l+{#}H***i[0.9]&@a5`"':&^;&^,*&^$43##@@####;
c}^^^&&&k}&&&}#=e*****[]}'r####'`=437*{#};::'1[0.9]2@43`"'*#==[[.{{],,,1278@#@);
print+((($llama=prototype'camel')=~y|+{#}$=^*&[0-9]i@:;`"',.| |d)&&$llama."\n");
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 13 Oct 1999 13:18:43 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl lite
Message-Id: <yl7lkrf1zw.fsf@windlord.stanford.edu>
Bart Lateur <bart.lateur@skynet.be> writes:
> If you have, say, 10 copies of Perl statically linked, running, then
> there's 10 *different* copies of Perl loaded.
This hasn't really been true for years; modern Unixes will all only load
one copy of the text segment of executables that multiple users are
running. It used to be that you had to set the sticky bit on the file to
get that behavior, but that's generally gone the same way as the
"register" declaration in C.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Wed, 13 Oct 1999 20:22:53 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Perl lite
Message-Id: <3804e98d.7128605@news.skynet.be>
Bart Lateur wrote:
>>Tell me.... is there really a need to keep identical copies in memory?
>
>Well... YOU know these are identical copies. The OS doesn't know.
Silly me. These are *scripts*, so the executable (the interpreter) is
the same.
The difference that I'm talking about should only matter with regards to
different executables, with the same library linked in.
So the difference in behaviour of the OS, in this case, is rather
puzzling.
--
Bart.
------------------------------
Date: 13 Oct 1999 09:35:50 -0700
From: Carl Johnson <carlj@peak.org>
Subject: Re: Perl lite
Message-Id: <87u2nv8bh5.fsf@cjlinux.localnet>
bart.lateur@skynet.be (Bart Lateur) writes:
> Ilya Zakharevich wrote:
>
> >>binaries linked against shared libraries more
> >> often than not outperform the same binaries statically linked.
> >
> >Of course, this may happen on the systems which were badly designed only.
> >
> >There is no reason why pages of executable modules should not be
> >handled identically to instances of loaded shared modules.
>
> Heh? I don't get it.
>
> If you have, say, 10 copies of Perl statically linked, running, then
> there's 10 *different* copies of Perl loaded. If it's linked
> dynamically, there's *one* copy of the common library loaded. There's no
> need to load 9 additional copies, and that's why I expect it to be
> faster on shortlived scripts, as Martien said, *and* gentler on the
> memory load of the computer, as Abigail confirmed.
I think that you are either confused, or that is a "feature" of MS
operating systems. Unix operating systems have shared executables for
many years now. It is true that if you have multiple copies of a perl
script, then each will have its own data area, including the script
itself, but there will only be one perl executable in memory.
--
Carl Johnson carlj@peak.org
------------------------------
Date: Thu, 14 Oct 1999 02:22:43 GMT
From: darkon@one.net (David Wall)
Subject: Re: Perl lite
Message-Id: <38053eb5_1@news2.one.net>
In article <x7d7ulkv0a.fsf@home.sysarch.com>, Uri Guttman <uri@sysarch.com> wrote:
>actually i found a place where i needed to do this. my new web/mail host
>has a low price deal with only 5MB for $9.95/Month (with virtual
>hosting). but they have a crappy old perl (5.004_01 would you believe!)
>and no decent modules. so i installed the latest and my needed modules
>into my home dir and everything is dandy. but they now take up 6.5MB so
>i have to pay an additional $2.95/MB/month. the next level is $24.95 for
>50MB so i am saving a whole $9.10/month.
Something like this is why I put up with my ISP being paranoid about
browsers. I pay the standard $20/month for all the regular things, and
get 100MB of space at no extra charge. (used to be 60MB) No virtual
hosting though, and Perl is v 5.005_02. Horrors! :-) I haven't looked
at the modules.
--
David Wall
darkon@one.net
------------------------------
Date: Thu, 14 Oct 1999 10:48:36 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Perl lite
Message-Id: <3805b236.15701959@news.skynet.be>
Bart Lateur wrote:
>Silly me. These are *scripts*, so the executable (the interpreter) is
>the same.
>
>The difference that I'm talking about should only matter with regards to
>different executables, with the same library linked in.
>
>So the difference in behaviour of the OS, in this case, is rather
>puzzling.
I have an idea. I don't know how valid it is, since I'm not familiar
with Perl's internals (me and C...), but I'll launch it anyway.
Perl scripts are old to be *not* interpreted, but compiled at startup. I
think I once read a remark in the docs (perldoc -f dump) saying that
that compiled executable could be quite big.
Maybe this compiled script also incorporates large parts of the original
executable. That way, the compiled stuff might just be quite a bit
bigger using the statically linked executable, than when using the
dynamically linked executable.
--
Bart.
------------------------------
Date: Tue, 12 Oct 1999 17:27:46 -0500
From: "Benjamin S. Vera-Tudela" <veratude@us.ibm.com>
Subject: Perl Modules in AIX
Message-Id: <3803B5E1.79F514BF@us.ibm.com>
Hi.
Does anybody have expertise on Perl in AIX? I have a problem. When
writing a Perl Module that does dynamic loading, I get an error message
from a function within the Perl DynaLoader module called "readExports".
This function fails when TYPE(ldp) != U802TOCMAGIC (where ldp is an
LDFILE* initialized by ldopen), thus returning an error message that
says "readExports: bad magic". This happens at DynaLoader.pm's bootstrap
subroutine doing "my $libref = dl_load_file($file,
$module->dl_load_flags) or croak ......". Now, the interesting thing is
that if I write a perl script that uses my module, everything works. The
problem I have is when I actually try to run the script from a C program
that creates its own PerlInterpreter. After doing:
perl_parse (myperl, xs_init, 3, argv_, NULL)
the script gets parsed, finds a "use MyModule;" so parses "MyModule.pm"
which "uses DynaLoader", calling the DynaLoader::bootstrap, failing at
the line I indicated above.
Any clues, hints, help?
thanks
Benjamin S. Vera-Tudela
------------------------------
Date: 12 Oct 1999 16:29:21 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl Modules in AIX
Message-Id: <ylaepoqhta.fsf@windlord.stanford.edu>
Benjamin S Vera-Tudela <veratude@us.ibm.com> writes:
> Now, the interesting thing is that if I write a perl script that uses my
> module, everything works. The problem I have is when I actually try to
> run the script from a C program that creates its own PerlInterpreter.
What version of Perl are you using? Loading dynamic modules from inside
an embedded Perl interpretor didn't really work right until 5.004.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Thu, 14 Oct 1999 11:43:06 GMT
From: "Benjamin S. Vera-Tudela" <bveratudela@austin.rr.com>
Subject: Re: Perl Modules in AIX
Message-Id: <3805C24C.682A47C1@austin.rr.com>
Hi Russ ... first thanks for replying. Well, I happen to be using 5.00502. I
have kind of hacked around the problem but still will be very interested in
knowing why I was getting the "readExports: bad magic" error message since the
hack may cost me some.
I happen to have another question though:
i'm trying to embed perl into a C++ application, and this app happens to be
a multithreaded one with several instances of an object that need to embed
perl scripts. i NEED to have several interpreters (one will do but I need a
lot of tricks and may be VERY expensive at runtime). i am trying to compile
a sample code from the perlembed man page that shows a 2-interpreter C
program, but it does not work as expected. I AM COMPILING
WITH -DMULTIPLICITY but no luck. anybody knows what the problem is?
basically, the script that gets parsed last with perl_parse (...) is the one
that produces the output for all instances. here is kind of what i have:
class MyClass
{
PerlInterpreter *myPerl;
public:
MyClass (char *script);
~MyClass ();
};
MyClass::MyClass (char *name)
{
char *argv[] = {NULL, name, NULL};
myPerl = perl_alloc ();
perl_construct (myPerl);
perl_parse (myPerl, xs_init, 3, argv, NULL);
perl_run (myPerl);
}
MyClass::~MyClass ()
{
perl_destruct (myPerl);
perl_free (myPerl);
}
int main ()
{
MyClass o1 ("my_perl_script_1");
MyClass o2 ("my_perl_script_2");
}
where my_perl_script_1 is:
#!/usr/bin/perl
print "HELLO FROM 1";
and my_perl_script_2 is:
#!/usr/bin/perl
print "HELLO FROM 2";
After compiling with -DMULTIPLICTY, the output is:
HELLO FROM 2
HELLO FROM 2
as instead of
HELLO FROM 1
HELLO FROM 2
Now, if I reverse the perl_parse routines, I get
HELLO FROM 1
HELLO FROM 1
anybody knows what I am doing wrong?
Russ Allbery wrote:
> Benjamin S Vera-Tudela <veratude@us.ibm.com> writes:
>
> > Now, the interesting thing is that if I write a perl script that uses my
> > module, everything works. The problem I have is when I actually try to
> > run the script from a C program that creates its own PerlInterpreter.
>
> What version of Perl are you using? Loading dynamic modules from inside
> an embedded Perl interpretor didn't really work right until 5.004.
>
> --
> #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
> $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
> 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
> rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Wed, 13 Oct 1999 16:03:33 +0000
From: Jose Luis Di Biase <jdibiase@sminter.com.ar>
Subject: perl mysql problems
Message-Id: <3804AD55.3B358CFA@sminter.com.ar>
i wanna configure my linux like communitech have, to test my scripts at
home..
the problem is that....i have installed mysql ( works very well, with
php3 )...., but when i tried to execute perl script prints me:
Can't locate object method "connect" via package "Mysql" at file line x.
i had installed mysql-perl-bin-3.21.23-1 and mysql-3.21.30-1
help me!! please.....
------------------------------
Date: Wed, 13 Oct 1999 21:20:29 GMT
From: amonotod <amonotod@netscape.net>
Subject: Re: perl mysql problems
Message-Id: <7u2t2e$bpt$1@nnrp1.deja.com>
Jose Luis Di Biase <jdibiase@sminter.com.ar> wrote:
> the problem is that....i have installed mysql ( works very well, with
> php3 )...., but when i tried to execute perl script prints me:
> Can't locate object method "connect" via package "Mysql" at file line
> x.
Sounds like whatever module you installed was not installed properly.
> i had installed mysql-perl-bin-3.21.23-1 and mysql-3.21.30-1
> help me!! please.....
Check to make sure that the .pm or .pl is in your lib or sitelib path.
Good luck,
amonotod
--
`\|||/ amonotod@
(@@) netscape.net
ooO_(_)_Ooo________________________________
_____|_____|_____|_____|_____|_____|_____|_____|
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: 13 Oct 1999 20:54:51 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: perl mysql problems
Message-Id: <7u2rir$ce$1@gellyfish.btinternet.com>
On Wed, 13 Oct 1999 16:03:33 +0000 Jose Luis Di Biase wrote:
> i wanna configure my linux like communitech have, to test my scripts at
> home..
> the problem is that....i have installed mysql ( works very well, with
> php3 )...., but when i tried to execute perl script prints me:
>
> Can't locate object method "connect" via package "Mysql" at file line x.
>
> i had installed mysql-perl-bin-3.21.23-1 and mysql-3.21.30-1
>
But you havent installed the Mysql Perl module ...
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 1072
**************************************
