On Tue, 28 Feb 2012, Vincent Veyron wrote:
> Le mardi 28 février 2012 à 13:46 -0500, Perrin Harkins a écrit :
>
> > Even if mod_perl someday stops being developed for new versions of
> > perl and apache, there will be no immediate need to move off it and
> > plenty of alternatives available.
>
> Do
On Sat, 09 Feb 2008, William A. Rowe, Jr. wrote:
> Randy Kobes wrote:
> We might see what compiling the ppm with .pdb files (not sure if you
> do that already) - simply /Zi args to CL.exe and /debug /opt:ref to
> the linker (rather than /release). Of course you can unpack the httpd
> symbols from
On Fri, 28 Dec 2007, Randy Kobes wrote:
> On Fri, 28 Dec 2007, Jan Dubois wrote:
> > Therefore I'm genuinely interested to learn where the problems are
> > if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl
> > with VC7. I would expect this to work
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
> Jan Dubois wrote:
>> I still haven't seen a compelling argument why someone wants to move
>> away from using MSVCRT.dll (and then continue switching CRTs then
>> every other year).
>
> The obvious question is; wha
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
> Studio 2008, true to form, proves that MS is incapable of keeping
> around a stdc library any longer than one product cycle. Yes, our long
> awaited (not) MSVCR90 is here.
You can expect a new runtime library version for each compiler release
from
PerlIO_teardown() calls PerlIO_debug(), which doesn't take an aTHX
argument, but assumes the TLS still points to a valid interpreter (it
contains a dTHX macro call). This seems like a bad assumption to me;
calling PERL_SYS_TERM before all interpreters have been destroyed is
a bug. Therefore I think
is safe to use Win32::OLE.
Cheers,
-Jan
>
> Jan Dubois wrote:
>> On Fri, 08 Jun 2007, Foo JH wrote:
>>
>>> I wonder if I am alone in experiencing this. Simply put: putting
>>> 'use Win32::OLE' in my modperl package will cause the Apache to
>>
On Fri, 08 Jun 2007, Foo JH wrote:
> I wonder if I am alone in experiencing this. Simply put: putting 'use
> Win32::OLE' in my modperl package will cause the Apache to fault. It
> basically can't start at all. A window will pop up complaining about
> 'Apache HTTP Server has encountered a problem an
On Tue, 30 Nov 2004, Stas Bekman wrote:
> What about the solution of ithreads? Originally ithreads were storing
> their context in ThreadLocalStorage, and this didn't work under mp2,
> so it was rewritten to store the context in a perl PL_ interpreter
> global, now ithreads can be run inside the sa
On Mon, 29 Nov 2004, Stas Bekman wrote:
> If you just call perl_clone it runs in the new perl context, but
> inside the same thread. At least on Unix. Under ithreads.pm it
> probably starts a new thread first (but I'm not sure). Under
> modperl 2, there is no 1:1 relationship between interpreters a
On Mon, 29 Nov 2004, Stas Bekman wrote:
> Jan, do you have any idea why the CLONE trick doesn't work? CLONE is
> running inside the newly-clonned perl, so thread-safety shouldn't get
> on the way, no?
Is CLONE running inside the new *thread* ? It is not good enough to run
it in the correct Perl in
On Thu, 25 Nov 2004, Randy Kobes wrote:
> I see the same problem when trying to use Win32::OLE in a startup
> script (with no error messages recorded - just a popup box saying that
> Apache encountered a problem when trying to start). This will require
> some debugging, but just to confirm - if you
On Tue, 21 Sep 2004, Steve Hay wrote:
> I'm a little wary of this fix because MSDN docs say "An apartment must
> call CoUninitialize once for each successful call it has made to
> CoInitialize" and "CoUninitialize should be called on application
> shutdown", but it certainly seems to work and is le
On Tue, 21 Sep 2004, Jan Dubois wrote:
> There is also a race condition when 2 modules try to call CoUninitialize(),
> e.g. Win32::Shortcut and Win32::OLE. If Win32::Shortcut has been loaded last,
> then its END block will be executed first, and the DESTROY methods of all
> still ex
On Tue, 21 Sep 2004, Steve Hay wrote:
> (Non-Win32 users: The real issue here is not Win32-specific.)
As to Win32::Shortcut: you should just delete the END block from the module.
I see that Sarathy already did this over a year for the version that ships
with ActivePerl. He also gave me his mailb
On Mon, 08 Dec 2003 11:27:36 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
>Jan Dubois wrote:
>> We observe the following mod_perl test failures on HP-UX 11.00 on PA-RISC,
>> with both HP C and GCC in both 32 bit and 64 bit mode. They are not
>> present on
On Mon, 08 Dec 2003 17:24:37 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
>> Feel free to cut-n-paste or mangle as you see fit. Here is an alternative
>> way of putting it:
>>
>> When building mod_perl 1.99 on HP-UX for PA-RISC architecture 11.00/11.11,using
>> the HP ANSI C compiler, pleas
On Mon, 08 Dec 2003 11:07:59 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
>Jan Dubois wrote:
>> On HP-UX for PA-RISC, version 11.00/11.11 you need to install patch
>> PHSS_29484/PHSS_29485 if you use HP C to compile mod_perl 1.99_11.
>>
>> Interestingly en
still get those errors.
Cheers,
-Jan
>Thanks,
>Rita
>
>-Original Message-
>From: Stas Bekman [mailto:[EMAIL PROTECTED]
>Sent: Monday, December 08, 2003 11:16 AM
>To: Jan Dubois
>Cc: [EMAIL PROTECTED]
>Subject: Re: mod_perl 1.99_11 test failures on 64 bit HP-UX syst
We observe the following mod_perl test failures on HP-UX 11.00 on PA-RISC,
with both HP C and GCC in both 32 bit and 64 bit mode. They are not
present on IPF systems in any of these combinations.
Failed Test Total Fail Failed List of Failed
We are observing the attached test failures on 64 bit HP-UX systems. They
happen on both PA-RISC and IPF systems. I compiled Apache 2.0.48, Perl
5.8.2 and mod_perl 1.99_11 both with the HP ANSI C compiler and with GCC.
The errors are always the same. They don't appear in 32 bit mode at all.
TJ
On Tue, 02 Dec 2003 16:22:05 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
>p.s. I didn't know you had to use ActivePerl for HP-UX. Doesn't the plain
>build work there?
Note that the default Perl in /opt/perl and /opt/perl_64 on HP-UX *is*
ActivePerl, at least on machines shipped in the last yea
On Thu, 04 Dec 2003 12:03:34 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
>THELLA,RITA (HP-Cupertino,ex3) wrote:
>> After installing HP-c patches, make test is working fine.
>
>Great. What're HP-c patches?
On HP-UX for PA-RISC, version 11.00/11.11 you need to install patch
PHSS_29484/PHSS_29485
23 matches
Mail list logo
