Loading ...
Sorry, an error occurred while loading the content.

different versions of Perl

Expand Messages
  • Todd White
    i fear this has been asked many times, but i could not find a definitive answer. i am using a system on which mod_perl is available, but the Perl version it s
    Message 1 of 15 , Nov 3, 2003
    • 0 Attachment
      i fear this has been asked many times, but i could not find a definitive
      answer.

      i am using a system on which mod_perl is available, but the Perl version
      it's using is 5.6.1

      this system also has Perl version 5.8.1 installed. is there any way to
      use the 5.8.1 interpreter without rebuilding mod_perl?

      the only thing i found related to this was here:
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      http://perl.apache.org/docs/1.0/guide/install.html#Should_I_Rebuild_mod_perl_if_I_have_Upgraded_Perl_
      Should I Rebuild mod_perl if I have Upgraded Perl?

      Yes, you should. You have to rebuild the mod_perl enabled server since it
      has a hard-coded @INC variable. This points to the old Perl and it is
      probably linked to an old libperl library. If for some reason you need to
      keep the old Perl version around you can modify @INC in the startup
      script, but it is better to build afresh to save you getting into a mess.
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      i do not have the option of rebuilding mod_perl and i found that this
      answer only seemed to address the @INC variable.




      --
      Reporting bugs: http://perl.apache.org/bugs/
      Mail list info: http://perl.apache.org/maillist/modperl.html
    • Perrin Harkins
      ... No, there isn t. Frankly, unless you really need something that is in 5.8.1 you should stick with what you have. 5.6.1 is considerably faster. - Perrin
      Message 2 of 15 , Nov 3, 2003
      • 0 Attachment
        On Mon, 2003-11-03 at 12:12, Todd White wrote:
        > this system also has Perl version 5.8.1 installed. is there any way to
        > use the 5.8.1 interpreter without rebuilding mod_perl?

        No, there isn't. Frankly, unless you really need something that is in
        5.8.1 you should stick with what you have. 5.6.1 is considerably
        faster.

        - Perrin

        --
        Reporting bugs: http://perl.apache.org/bugs/
        Mail list info: http://perl.apache.org/maillist/modperl.html
      • Rafael Garcia-Suarez
        ... Have you some benchmarks to back up this affirmation or is it only an opinion ? If you have benchmarks, I know quite a lot of people that would be
        Message 3 of 15 , Nov 3, 2003
        • 0 Attachment
          Perrin Harkins wrote:
          >
          > On Mon, 2003-11-03 at 12:12, Todd White wrote:
          > > this system also has Perl version 5.8.1 installed. is there any way to
          > > use the 5.8.1 interpreter without rebuilding mod_perl?
          >
          > No, there isn't. Frankly, unless you really need something that is in
          > 5.8.1 you should stick with what you have. 5.6.1 is considerably
          > faster.

          Have you some benchmarks to back up this affirmation or is it only
          an opinion ? If you have benchmarks, I know quite a lot of people
          that would be interested.

          --
          Reporting bugs: http://perl.apache.org/bugs/
          Mail list info: http://perl.apache.org/maillist/modperl.html
        • Perrin Harkins
          ... I ve been running benchmarks of various IPC modules, like MLDBM::Sync, DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them about 50%
          Message 4 of 15 , Nov 3, 2003
          • 0 Attachment
            On Mon, 2003-11-03 at 12:21, Rafael Garcia-Suarez wrote:
            > Have you some benchmarks to back up this affirmation or is it only
            > an opinion ? If you have benchmarks, I know quite a lot of people
            > that would be interested.

            I've been running benchmarks of various IPC modules, like MLDBM::Sync,
            DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
            about 50% faster than the version of 5.8 that shipped with Red Hat 9.
            Granted, I heard that 5.8.1 made some gains in dealing with the overhead
            of unicode and Red Hat's Perl may be compiled with thread support (known
            to slow things down a lot), but I'd be surprised if 5.8.1 was as fast as
            5.6.1.

            - Perrin

            --
            Reporting bugs: http://perl.apache.org/bugs/
            Mail list info: http://perl.apache.org/maillist/modperl.html
          • Todd White
            as mentioned in my side message to you, Perrin, i m looking to 5.8.1 for its unicode support. specifically, to make it easy to output XML in UTF-8 as an OAI
            Message 5 of 15 , Nov 3, 2003
            • 0 Attachment
              as mentioned in my side message to you, Perrin, i'm looking to 5.8.1 for
              its unicode support. specifically, to make it easy to output XML in UTF-8
              as an OAI (Open Archives Initiative) repository.



              On 3 Nov 2003, Perrin Harkins wrote:

              > On Mon, 2003-11-03 at 12:21, Rafael Garcia-Suarez wrote:
              > > Have you some benchmarks to back up this affirmation or is it only
              > > an opinion ? If you have benchmarks, I know quite a lot of people
              > > that would be interested.
              >
              > I've been running benchmarks of various IPC modules, like MLDBM::Sync,
              > DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
              > about 50% faster than the version of 5.8 that shipped with Red Hat 9.
              > Granted, I heard that 5.8.1 made some gains in dealing with the overhead
              > of unicode and Red Hat's Perl may be compiled with thread support (known
              > to slow things down a lot), but I'd be surprised if 5.8.1 was as fast as
              > 5.6.1.
              >
              > - Perrin
              >
              > --
              > Reporting bugs: http://perl.apache.org/bugs/
              > Mail list info: http://perl.apache.org/maillist/modperl.html
              >
              >


              --
              Reporting bugs: http://perl.apache.org/bugs/
              Mail list info: http://perl.apache.org/maillist/modperl.html
            • Rafael Garcia-Suarez
              ... The perl shipped with RH 9 (actually a 5.8.0 + lots of patches) is compiled with threads and with a shared libperl.so, two factors that are known to slow
              Message 6 of 15 , Nov 3, 2003
              • 0 Attachment
                Perrin Harkins wrote:
                > I've been running benchmarks of various IPC modules, like MLDBM::Sync,
                > DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
                > about 50% faster than the version of 5.8 that shipped with Red Hat 9.
                > Granted, I heard that 5.8.1 made some gains in dealing with the overhead
                > of unicode and Red Hat's Perl may be compiled with thread support (known
                > to slow things down a lot), but I'd be surprised if 5.8.1 was as fast as
                > 5.6.1.

                The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
                is compiled with threads and with a shared libperl.so, two factors that
                are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
                but not considerably. However I have no definitive numbers either.

                --
                Reporting bugs: http://perl.apache.org/bugs/
                Mail list info: http://perl.apache.org/maillist/modperl.html
              • Perrin Harkins
                ... Now that the dust has settled on 5.8.1, I will probably install it and run some of these same benchmarks soon. When I get some numbers, I ll post them. -
                Message 7 of 15 , Nov 3, 2003
                • 0 Attachment
                  On Mon, 2003-11-03 at 12:45, Rafael Garcia-Suarez wrote:
                  > The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
                  > is compiled with threads and with a shared libperl.so, two factors that
                  > are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
                  > but not considerably. However I have no definitive numbers either.

                  Now that the dust has settled on 5.8.1, I will probably install it and
                  run some of these same benchmarks soon. When I get some numbers, I'll
                  post them.

                  - Perrin

                  --
                  Reporting bugs: http://perl.apache.org/bugs/
                  Mail list info: http://perl.apache.org/maillist/modperl.html
                • Perrin Harkins
                  ... You really do need to recompile mod_perl, just as you would with any CPAN module that isn t pure Perl. What s the difficulty with recompiling? Is it just
                  Message 8 of 15 , Nov 3, 2003
                  • 0 Attachment
                    On Mon, 2003-11-03 at 12:39, Todd White wrote:
                    > as mentioned in my side message to you, Perrin, i'm looking to 5.8.1 for
                    > its unicode support. specifically, to make it easy to output XML in UTF-8
                    > as an OAI (Open Archives Initiative) repository.

                    You really do need to recompile mod_perl, just as you would with any
                    CPAN module that isn't pure Perl. What's the difficulty with
                    recompiling? Is it just a political issue?

                    - Perrin

                    --
                    Reporting bugs: http://perl.apache.org/bugs/
                    Mail list info: http://perl.apache.org/maillist/modperl.html
                  • Stas Bekman
                    ... I know about the threads issue. But it s a first time I hear about a shared libperl.so. Is it relevant to mod_perl? It gets loaded at the server startup
                    Message 9 of 15 , Nov 3, 2003
                    • 0 Attachment
                      Rafael Garcia-Suarez wrote:
                      > Perrin Harkins wrote:
                      >
                      >>I've been running benchmarks of various IPC modules, like MLDBM::Sync,
                      >>DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
                      >>about 50% faster than the version of 5.8 that shipped with Red Hat 9.
                      >>Granted, I heard that 5.8.1 made some gains in dealing with the overhead
                      >>of unicode and Red Hat's Perl may be compiled with thread support (known
                      >>to slow things down a lot), but I'd be surprised if 5.8.1 was as fast as
                      >>5.6.1.
                      >
                      >
                      > The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
                      > is compiled with threads and with a shared libperl.so, two factors that
                      > are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
                      > but not considerably. However I have no definitive numbers either.

                      I know about the threads issue. But it's a first time I hear about a shared
                      libperl.so. Is it relevant to mod_perl? It gets loaded at the server startup
                      and I think produces no overhead at run-time. Or does it? Is it about
                      resolving symbols at run-time vs. PERL_DL_NONLAZY=1, which doesn't happen in
                      the static library?


                      __________________________________________________________________
                      Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                      http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                      mailto:stas@... http://use.perl.org http://apacheweek.com
                      http://modperlbook.org http://apache.org http://ticketmaster.com


                      --
                      Reporting bugs: http://perl.apache.org/bugs/
                      Mail list info: http://perl.apache.org/maillist/modperl.html
                    • Rafael Garcia-Suarez
                      ... For discussion about this, see the INSTALL file, section Building a shared Perl library . You re right, maybe this doesn t impact mod_perl.
                      Message 10 of 15 , Nov 3, 2003
                      • 0 Attachment
                        Stas Bekman wrote:
                        > > The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
                        > > is compiled with threads and with a shared libperl.so, two factors that
                        > > are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
                        > > but not considerably. However I have no definitive numbers either.
                        >
                        > I know about the threads issue. But it's a first time I hear about a shared
                        > libperl.so. Is it relevant to mod_perl? It gets loaded at the server startup
                        > and I think produces no overhead at run-time. Or does it? Is it about
                        > resolving symbols at run-time vs. PERL_DL_NONLAZY=1, which doesn't happen in
                        > the static library?

                        For discussion about this, see the INSTALL file, section "Building a shared
                        Perl library". You're right, maybe this doesn't impact mod_perl.

                        PERL_DL_NONLAZY is only for XS modules (AFAIK).

                        --
                        Reporting bugs: http://perl.apache.org/bugs/
                        Mail list info: http://perl.apache.org/maillist/modperl.html
                      • Stas Bekman
                        ... In terms of performance, on my test system (Solaris 2.5_x86) the perl test suite took roughly 15% longer to run with the shared libperl.so. Your system and
                        Message 11 of 15 , Nov 4, 2003
                        • 0 Attachment
                          Rafael Garcia-Suarez wrote:
                          > Stas Bekman wrote:
                          >
                          >>>The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
                          >>>is compiled with threads and with a shared libperl.so, two factors that
                          >>>are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
                          >>>but not considerably. However I have no definitive numbers either.
                          >>
                          >>I know about the threads issue. But it's a first time I hear about a shared
                          >>libperl.so. Is it relevant to mod_perl? It gets loaded at the server startup
                          >>and I think produces no overhead at run-time. Or does it? Is it about
                          >>resolving symbols at run-time vs. PERL_DL_NONLAZY=1, which doesn't happen in
                          >>the static library?
                          >
                          >
                          > For discussion about this, see the INSTALL file, section "Building a shared
                          > Perl library". You're right, maybe this doesn't impact mod_perl.

                          Hmm, I wonder about this para from that file:

                          ---
                          In terms of performance, on my test system (Solaris 2.5_x86) the perl
                          test suite took roughly 15% longer to run with the shared libperl.so.
                          Your system and typical applications may well give quite different
                          results.
                          ---

                          The whole point of using shared libs is that if there are more than one app
                          using the same library it gets loaded only once. I don't know who wrote the
                          claim above, but have you tried doing perl -le 'sleep 1000 while 1' in another
                          window (of course using the same perl) and then start the test suite? This way
                          libperl.so will be constantly loaded and won't cause the loading overhead. I
                          suppose that depending on the OS the loader may even remember the symbols it
                          has resolved at run-time. The perl test suite spawns a lot of fresh perls
                          which causes most of the overhead.

                          > PERL_DL_NONLAZY is only for XS modules (AFAIK).

                          Could be. But I what I meant is whatever the dlopen flag for resolving symbols
                          right away is, and not doing the lazy loading. This is of course of other perl
                          programs can benefit from this resolving. If not it will just slow things down.

                          Actually on several OSs you have no choice but to resolve all the symbols when
                          the shared library is loaded (OS X?), which in case of libperl.so makes a huge
                          overhead if you just need a few dozen of symbols out of 4K+ symbols.

                          __________________________________________________________________
                          Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                          http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                          mailto:stas@... http://use.perl.org http://apacheweek.com
                          http://modperlbook.org http://apache.org http://ticketmaster.com


                          --
                          Reporting bugs: http://perl.apache.org/bugs/
                          Mail list info: http://perl.apache.org/maillist/modperl.html
                        • Gisle Aas
                          ... I also found 15% slowdown with perlbench on Linux. ... The slowdown is not in the loading. The core perl code runs slower because it is compiled with
                          Message 12 of 15 , Nov 5, 2003
                          • 0 Attachment
                            Stas Bekman <stas@...> writes:

                            > Hmm, I wonder about this para from that file:
                            >
                            > ---
                            > In terms of performance, on my test system (Solaris 2.5_x86) the perl
                            > test suite took roughly 15% longer to run with the shared libperl.so.
                            > Your system and typical applications may well give quite different
                            > results.

                            I also found 15% slowdown with perlbench on Linux.

                            > The whole point of using shared libs is that if there are more than
                            > one app using the same library it gets loaded only once. I don't know
                            > who wrote the claim above, but have you tried doing perl -le 'sleep
                            > 1000 while 1' in another window (of course using the same perl) and
                            > then start the test suite? This way libperl.so will be constantly
                            > loaded and won't cause the loading overhead.

                            The slowdown is not in the loading. The core perl code runs slower
                            because it is compiled with -fpic to make it position independent when
                            you enable 'useshrplib'.

                            Regards,
                            Gisle

                            --
                            Reporting bugs: http://perl.apache.org/bugs/
                            Mail list info: http://perl.apache.org/maillist/modperl.html
                          • Stas Bekman
                            ... I should give it a try and see if my ideas make any difference. ... If I understand correctly the following description from the gcc manpage: -fpic
                            Message 13 of 15 , Nov 5, 2003
                            • 0 Attachment
                              Gisle Aas wrote:
                              > Stas Bekman <stas@...> writes:
                              >
                              >
                              >>Hmm, I wonder about this para from that file:
                              >>
                              >>---
                              >>In terms of performance, on my test system (Solaris 2.5_x86) the perl
                              >>test suite took roughly 15% longer to run with the shared libperl.so.
                              >>Your system and typical applications may well give quite different
                              >>results.
                              >
                              >
                              > I also found 15% slowdown with perlbench on Linux.

                              I should give it a try and see if my ideas make any difference.

                              >>The whole point of using shared libs is that if there are more than
                              >>one app using the same library it gets loaded only once. I don't know
                              >>who wrote the claim above, but have you tried doing perl -le 'sleep
                              >>1000 while 1' in another window (of course using the same perl) and
                              >>then start the test suite? This way libperl.so will be constantly
                              >>loaded and won't cause the loading overhead.
                              >
                              >
                              > The slowdown is not in the loading. The core perl code runs slower
                              > because it is compiled with -fpic to make it position independent when
                              > you enable 'useshrplib'.

                              If I understand correctly the following description from the gcc manpage:

                              -fpic
                              Generate position-independent code (PIC) suitable for use in a
                              shared library, if supported for the target machine. Such code
                              accesses all constant addresses through a global offset table
                              (GOT). The dynamic loader resolves the GOT entries when the pro-
                              gram starts (the dynamic loader is not part of GCC; it is part of
                              the operating system). If the GOT size for the linked executable
                              exceeds a machine-specific maximum size, you get an error message
                              from the linker indicating that -fpic does not work; in that case,
                              recompile with -fPIC instead. (These maximums are 16k on the m88k,
                              8k on the SPARC, and 32k on the m68k and RS/6000. The 386 has no
                              such limit.)

                              Position-independent code requires special support, and therefore
                              works only on certain machines. For the 386, GCC supports PIC for
                              System V but not for the Sun 386i. Code generated for the IBM
                              RS/6000 is always position-independent.

                              it affects only the loading time:

                              The dynamic loader resolves the GOT entries when the program starts

                              Doesn't it imply that once resolved, there is no more run-time overhead incurred?

                              __________________________________________________________________
                              Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                              http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                              mailto:stas@... http://use.perl.org http://apacheweek.com
                              http://modperlbook.org http://apache.org http://ticketmaster.com


                              --
                              Reporting bugs: http://perl.apache.org/bugs/
                              Mail list info: http://perl.apache.org/maillist/modperl.html
                            • Wilt, Paul
                              Stas: Actually there is continued overhead due to the fact that different instructions (that require a larger number of cycles to decode / dispatch) are used
                              Message 14 of 15 , Nov 5, 2003
                              • 0 Attachment
                                Stas:

                                Actually there is continued overhead due to the fact that different
                                instructions (that require a larger number of cycles to decode / dispatch)
                                are used when calling subroutines and / or accessing memory in a shared
                                environment.

                                Paul E Wilt
                                Senior Principal Software Engineer
                                ProQuest Information and Learning
                                ---------------------------------------------------------
                                http://www.proquest.com mailto:paul.wilt@...
                                300 North Zeeb Rd Phone: (734) 302-6777
                                Ann Arbor, MI 48106 Fax: (734) 302-6779
                                ---------------------------------------------------------



                                -----Original Message-----
                                From: Stas Bekman [mailto:stas@...]
                                Sent: Wednesday, November 05, 2003 4:17 AM
                                To: Gisle Aas
                                Cc: Rafael Garcia-Suarez; perrin@...; modperl@...
                                Subject: Re: different versions of Perl


                                Gisle Aas wrote:
                                > Stas Bekman <stas@...> writes:
                                >
                                >
                                >>Hmm, I wonder about this para from that file:
                                >>
                                >>---
                                >>In terms of performance, on my test system (Solaris 2.5_x86) the perl
                                >>test suite took roughly 15% longer to run with the shared libperl.so.
                                >>Your system and typical applications may well give quite different
                                >>results.
                                >
                                >
                                > I also found 15% slowdown with perlbench on Linux.

                                I should give it a try and see if my ideas make any difference.

                                >>The whole point of using shared libs is that if there are more than
                                >>one app using the same library it gets loaded only once. I don't know
                                >>who wrote the claim above, but have you tried doing perl -le 'sleep
                                >>1000 while 1' in another window (of course using the same perl) and
                                >>then start the test suite? This way libperl.so will be constantly
                                >>loaded and won't cause the loading overhead.
                                >
                                >
                                > The slowdown is not in the loading. The core perl code runs slower
                                > because it is compiled with -fpic to make it position independent when
                                > you enable 'useshrplib'.

                                If I understand correctly the following description from the gcc manpage:

                                -fpic
                                Generate position-independent code (PIC) suitable for use in a
                                shared library, if supported for the target machine. Such code
                                accesses all constant addresses through a global offset table
                                (GOT). The dynamic loader resolves the GOT entries when the
                                pro-
                                gram starts (the dynamic loader is not part of GCC; it is part
                                of
                                the operating system). If the GOT size for the linked
                                executable
                                exceeds a machine-specific maximum size, you get an error
                                message
                                from the linker indicating that -fpic does not work; in that
                                case,
                                recompile with -fPIC instead. (These maximums are 16k on the
                                m88k,
                                8k on the SPARC, and 32k on the m68k and RS/6000. The 386 has
                                no
                                such limit.)

                                Position-independent code requires special support, and
                                therefore
                                works only on certain machines. For the 386, GCC supports PIC
                                for
                                System V but not for the Sun 386i. Code generated for the IBM
                                RS/6000 is always position-independent.

                                it affects only the loading time:

                                The dynamic loader resolves the GOT entries when the program
                                starts

                                Doesn't it imply that once resolved, there is no more run-time overhead
                                incurred?

                                __________________________________________________________________
                                Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                                http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                                mailto:stas@... http://use.perl.org http://apacheweek.com
                                http://modperlbook.org http://apache.org http://ticketmaster.com


                                --
                                Reporting bugs: http://perl.apache.org/bugs/
                                Mail list info: http://perl.apache.org/maillist/modperl.html

                                --
                                Reporting bugs: http://perl.apache.org/bugs/
                                Mail list info: http://perl.apache.org/maillist/modperl.html
                              • Stas Bekman
                                ... That would be a very badly designed shared lib support. Those instructions are supposed to be cached, aren t they? From what I understand the shared
                                Message 15 of 15 , Nov 5, 2003
                                • 0 Attachment
                                  Wilt, Paul wrote:
                                  > Stas:
                                  >
                                  > Actually there is continued overhead due to the fact that different
                                  > instructions (that require a larger number of cycles to decode / dispatch)
                                  > are used when calling subroutines and / or accessing memory in a shared
                                  > environment.

                                  That would be a very badly designed shared lib support. Those instructions are
                                  supposed to be cached, aren't they? From what I understand the shared
                                  libraries concept was designed to make upgrades easy, save memory and provide
                                  other benefits, without losing the speed benefits of the static libs. Reading
                                  some papers from Ulrich Drepper (http://people.redhat.com/drepper/) suggests
                                  that the latest glibc libs 2.3.x is suppose to be much better at giving you a
                                  good performance with shared libs. It also suggest that -fpic is about 3 times
                                  faster than -fPIC. This is all discussed in details at:
                                  http://people.redhat.com/drepper/dsohowto.pdf

                                  In any case, perlbench indeed shows a signifact performance difference, so I'd
                                  rather believe numbers than promises, untill someone proves it wrong ;) So we
                                  need to add one more tip to the bag-of-performance tricks: Use less shared
                                  libs if you can, especially avoid libperl.so.

                                  p.s. According to the paper I've quoted above (See section 2), it takes one
                                  extra instruction for -fpic and 3 for -fPIC to do the dispatch and not a large
                                  number of cycles as you have suggested above, Paul ;) Unless we are talking
                                  about different things (and may be different architectures).

                                  __________________________________________________________________
                                  Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                                  http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                                  mailto:stas@... http://use.perl.org http://apacheweek.com
                                  http://modperlbook.org http://apache.org http://ticketmaster.com


                                  --
                                  Reporting bugs: http://perl.apache.org/bugs/
                                  Mail list info: http://perl.apache.org/maillist/modperl.html
                                Your message has been successfully submitted and would be delivered to recipients shortly.