[31447] in Perl-Users-Digest
Perl-Users Digest, Issue: 2699 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Nov 30 00:58:36 2009
Date: Sun, 29 Nov 2009 13:12:48 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 29 Nov 2009 Volume: 11 Number: 2699
Today's topics:
Re: DLL unload question for embedded Perl on Windows <nospam-abuse@ilyaz.org>
Re: DLL unload question for embedded Perl on Windows <ben@morrow.me.uk>
Re: FAQ 4.18 Does Perl have a Year 2000 problem? Is Per <ben@morrow.me.uk>
Re: FAQ 4.18 Does Perl have a Year 2000 problem? Is Per <justin.0911@purestblue.com>
Re: FAQ 4.18 Does Perl have a Year 2000 problem? Is Per (David Canzi)
Faster way to get PHP script than LWP::Simple <jwcarlton@gmail.com>
Modules in a required file <jwcarlton@gmail.com>
Re: Modules in a required file <ben@morrow.me.uk>
Re: perlio vs. sysread speed (was: Quick CGI question ( <nospam-abuse@ilyaz.org>
Re: perlio vs. sysread speed (was: Quick CGI question ( <ben@morrow.me.uk>
Using CGI::Cookie <jwcarlton@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 29 Nov 2009 01:10:42 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: DLL unload question for embedded Perl on Windows
Message-Id: <slrnhh3igi.elt.nospam-abuse@powdermilk.math.berkeley.edu>
On 2009-11-28, Ben Morrow <ben@morrow.me.uk> wrote:
> I don't know. Have you checked to see whether perl_free unloads the dlls
> or not? If it does then that's what you want.
AFAIK, the design of Perl DLLs was always that they are not unloadable.
Hope this helps,
Ilya
------------------------------
Date: Sun, 29 Nov 2009 01:42:35 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: DLL unload question for embedded Perl on Windows
Message-Id: <b509u6-ebl1.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2009-11-28, Ben Morrow <ben@morrow.me.uk> wrote:
> > I don't know. Have you checked to see whether perl_free unloads the dlls
> > or not? If it does then that's what you want.
>
> AFAIK, the design of Perl DLLs was always that they are not unloadable.
That's more-or-less what I thought, but perldoc DynaLoader says
| dl_unload_file()
| Syntax:
|
| $status = dl_unload_file($libref)
|
| Dynamically unload $libref, which must be an opaque ’library
| reference’ as returned from dl_load_file. Returns one on success
| and zero on failure.
|
| This function is optional and may not necessarily be provided on
| all platforms. If it is defined, it is called automatically when
| the interpreter exits for every shared object or library loaded by
| DynaLoader::bootstrap. All such library references are stored in
| @dl_librefs by DynaLoader::Bootstrap as it loads the libraries.
| The files are unloaded in last‐in, first‐out order.
|
| This unloading is usually necessary when embedding a shared‐object
| perl (e.g. one configured with −Duseshrplib) within a larger
| application, and the perl interpreter is created and destroyed
| several times within the lifetime of the application. In this case
<details of why this is necessary>
and checking dl_win32.xs shows that it does define dl_unload_file.
Therefore, I would expect all perl extension dlls to be unloaded as part
of perl_destruct, but not before.
Ben
------------------------------
Date: Sat, 28 Nov 2009 23:34:41 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: FAQ 4.18 Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
Message-Id: <hlo8u6-uok1.ln1@osiris.mauzo.dyndns.org>
Quoth Justin C <justin.0911@purestblue.com>:
> In article <slrnhh2gg8.323.hjp-usenet2@hrunkner.hjp.at>, Peter J. Holzer wrote:
> > On 2009-11-28 13:46, Justin C <justin.0911@purestblue.com> wrote:
> >> In article <jSYPm.59723$rE5.9343@newsfe08.iad>, PerlFAQ Server wrote:
> >>> 4.18: Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> I don't believe that this is still a FAQ. What sort of person would be
> >> asking it ten years after the event?
> >
> > I predict that it won't take very long until programs start breaking
> > when they have to deal with dates before 2000.
> >
> > Also, the year 2038 is approaching. Is perl Y2038-compliant yet? ;-).
>
> See FAQ 4.18 Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
I believe Peter's point was that the FAQ answer doesn't address that
question.
Ben
------------------------------
Date: Sun, 29 Nov 2009 01:08:16 +0000
From: Justin C <justin.0911@purestblue.com>
Subject: Re: FAQ 4.18 Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
Message-Id: <05u8u6-8c6.ln1@purestblue.com>
In article <hlo8u6-uok1.ln1@osiris.mauzo.dyndns.org>, Ben Morrow wrote:
>
> Quoth Justin C <justin.0911@purestblue.com>:
>> See FAQ 4.18 Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
>
> I believe Peter's point was that the FAQ answer doesn't address that
> question.
Hardly surprising when it isn't the subject of the FAQ! I'm not saying
that that FAQ should be scrapped, but maybe it needs re-naming and
updating.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Sat, 28 Nov 2009 23:12:36 +0000 (UTC)
From: dmcanzi@remulak.uwaterloo.ca (David Canzi)
Subject: Re: FAQ 4.18 Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
Message-Id: <hesap4$a9q$1@rumours.uwaterloo.ca>
In article <slrnhh2gg8.323.hjp-usenet2@hrunkner.hjp.at>,
Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>On 2009-11-28 13:46, Justin C <justin.0911@purestblue.com> wrote:
>> In article <jSYPm.59723$rE5.9343@newsfe08.iad>, PerlFAQ Server wrote:
>>> 4.18: Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
>>
>> I don't believe that this is still a FAQ. What sort of person would be
>> asking it ten years after the event?
>
>I predict that it won't take very long until programs start breaking
>when they have to deal with dates before 2000.
>
>Also, the year 2038 is approaching. Is perl Y2038-compliant yet? ;-).
Nope.
dmcanzi@tribulation $ cat ~/bin/ctime
#!/usr/bin/perl
printf "%s\n", scalar localtime eval shift;
dmcanzi@tribulation $
dmcanzi@tribulation $ ctime 0x7fffffff
Mon Jan 18 22:14:07 2038
dmcanzi@tribulation $ ctime 0x80000000
Fri Dec 13 15:45:52 1901
dmcanzi@tribulation $
Around Y2K, many programs that had used a "%02d" format for the
year were changed to use "%04d" or "%4d". This will cause trouble
in the future -- only "%d" is Y10K compliant.
--
David Canzi
------------------------------
Date: Sat, 28 Nov 2009 18:50:24 -0800 (PST)
From: Jason Carlton <jwcarlton@gmail.com>
Subject: Faster way to get PHP script than LWP::Simple
Message-Id: <c4321335-c811-4aa8-b9a9-c170e66d9c90@g26g2000yqe.googlegroups.com>
I'm using a PHP script as a heading for the site, and it has several
functions in it. If I want to include this header in a Perl script, is
there a better / faster way than using LWP::Simple?
I ask because I've noticed that my Perl-based pages load a little
slower than other pages on the site (even a plain "Hello World" script
that includes this header), so I'm pretty sure that this is the
bottleneck.
------------------------------
Date: Sat, 28 Nov 2009 17:57:32 -0800 (PST)
From: Jason Carlton <jwcarlton@gmail.com>
Subject: Modules in a required file
Message-Id: <67bfddf8-e433-409d-b201-e7484457d6d1@j4g2000yqe.googlegroups.com>
I'm have several scripts that share the same function, so I'm moving
that function to a separate script and using require in the parent
scripts.
This function uses the CGI::Cookie module. Do I need to "use" this
module in each of the parent scripts, or can I only call it once in
the required script?
------------------------------
Date: Sun, 29 Nov 2009 02:49:46 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Modules in a required file
Message-Id: <a349u6-sml1.ln1@osiris.mauzo.dyndns.org>
Quoth Jason Carlton <jwcarlton@gmail.com>:
> I'm have several scripts that share the same function, so I'm moving
> that function to a separate script and using require in the parent
> scripts.
Consider making a proper module instead. It has several advantages.
> This function uses the CGI::Cookie module. Do I need to "use" this
> module in each of the parent scripts, or can I only call it once in
> the required script?
CGI::Cookie appears to be an OO module, so you need only 'require' or
'use' it once before you attempt to create your first object. For
modules that export functions, you need to 'use' them once per package,
so if your required file uses the same package as the file requiring it
a single 'use' will suffice. Modules that have lexical effect, like
'strict' and 'warnings', need to be used separately in every scope they
need to apply to, so don't forget the 'use warnings; use strict;' in the
required file.
Ben
------------------------------
Date: Sun, 29 Nov 2009 01:13:25 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: perlio vs. sysread speed (was: Quick CGI question (specific to the CGI package))
Message-Id: <slrnhh3ill.elt.nospam-abuse@powdermilk.math.berkeley.edu>
On 2009-11-28, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> * Reading line by line is significantly slower than reading by blocks.
Remember that when reading line-by-line (with 80char line), you
actually read 80 times char-by-char.
Yours,
Ilya
------------------------------
Date: Sun, 29 Nov 2009 02:42:46 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perlio vs. sysread speed (was: Quick CGI question (specific to the CGI package))
Message-Id: <6m39u6-sml1.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2009-11-28, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> > * Reading line by line is significantly slower than reading by blocks.
>
> Remember that when reading line-by-line (with 80char line), you
> actually read 80 times char-by-char.
Not under normal circumstances. When perl is using buffered IO, it reads
a bufferful and then goes grovelling through it for line endings.
This is true, however, when reading line-by-line with the :unix PerlIO
layer, which is why that should be avoided unless strictly necessary.
Ben
------------------------------
Date: Sat, 28 Nov 2009 17:55:17 -0800 (PST)
From: Jason Carlton <jwcarlton@gmail.com>
Subject: Using CGI::Cookie
Message-Id: <39441fca-3dab-4f11-a049-d263b04f1274@w19g2000yqk.googlegroups.com>
For CGI::Cookie, Cpan states:
The simplest way to send a cookie to the browser is by calling the bake
() method:
$c->bake;
If you want to set the cookie yourself, Within a CGI script you can
send a cookie to the browser by creating one or more Set-Cookie:
fields in the HTTP header. Here is a typical sequence:
my $c = new CGI::Cookie(-name => 'foo',
-value => ['bar','baz'],
-expires => '+3M');
print "Set-Cookie: $c\n";
print "Content-Type: text/html\n\n";
When should I use "bake", and when should I simply use "Set-Cookie"?
Is there an advantage or disadvantage either way?
The script I'm building doesn't actually print anything to the screen,
but just redirects to a success page. Since there's no content-type
being printed, does this mean that I need to use bake?
TIA,
Jason
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 2699
***************************************
