Ok, looks like noone can help me out here, but perhaps
someone can point me in the right direction as to how
to do this myself? I have scoured the php.net site,
googled the web, and can't find a howto or anything on
how to contribute to the PHP project, let alone how to
update the Win32 build.
Is
It can be significant. There are a couple of issues:
1. The included_files list gets updated each time you include a file. In
order to make sure that the same file included by different paths or
symlinks don't conflict we do a realpath() on the file to be included.
That means stats on e
PEAR is considering stipulating 1 class per file, for the packages. -
one of the concerns raised is performance. While this is true for a
non-cache compiled situation (where performance is less of an issue) -
would anyone care to comment on the implications when using the Zend
Optimizer or APC,
Hi,
I applied for CVS access a number of weeks ago, but have had no reply. I'm
anxious to get my PEAR Package up.
(username: aidan)
Has my request been declined, or has no one had a chance to action it. If
the latter, when can this be expected to happen?
Thank you,
Aidan
--
PHP Internals - PHP
> Right, sorry, more precisely, by setting them to pemalloc/pefree they
> result in calling malloc/free anyway. Not a direct mapping of course.
> But I think we have beaten this one to death. Since PHP just calls
> malloc/free anyway and the wrapper layer is causing problems, simply
> removi
On Fri, 23 Apr 2004, Andrei Zmievski wrote:
> On Fri, 23 Apr 2004, Rasmus Lerdorf wrote:
> > You mean they are not generic memory alloc functions? I know that. But
> > they map to malloc/free which is the important point here.
>
> The global variables pcre_malloc and pcre_free initial
On Fri, 23 Apr 2004, Rasmus Lerdorf wrote:
> You mean they are not generic memory alloc functions? I know that. But
> they map to malloc/free which is the important point here.
The global variables pcre_malloc and pcre_free initially
contain the entry points of the standard malloc
On Fri, 23 Apr 2004, Andrei Zmievski wrote:
> On Fri, 23 Apr 2004, Rasmus Lerdorf wrote:
> > I guess I have no idea what you are talking about. The bug we are
> > discussing is that the PCRE extension registers pemalloc/pefree as the
> > cache malloc/free functions. On a restart these PHP wrapper
On Apr 23, 2004, at 9:24 AM, Wez Furlong wrote:
While solving http://bugs.php.net/bug.php?id=27974,
we've discovered that count() on an overloaded object
(in this case, a variant object representing an OLE
SafeArray) doesn't return a truthful value.
What, if anything, are we going to do about that
On Fri, 23 Apr 2004, Rasmus Lerdorf wrote:
> I guess I have no idea what you are talking about. The bug we are
> discussing is that the PCRE extension registers pemalloc/pefree as the
> cache malloc/free functions. On a restart these PHP wrappers go away and
> we crash when another module hits PC
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> Never mind. I don't feel like explaining myself a thousand times :) If
> you'd have read what I wrote you would have seen that I wasn't saying that
> we're using emalloc/efree (and thus the memory manager) today.
> I was talking about the PCRE library an
i'm pretty sure it does, it has a compiled regex cache that uses it, i
think.
-sterling
On Apr 23, 2004, at 7:11 AM, Andi Gutmans wrote:
At 10:05 AM 4/23/2004 -0400, Ilia Alshanetsky wrote:
On April 23, 2004 10:01 am, Andi Gutmans wrote:
> I think changing back to malloc/free on RSHUTDOWN is a
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> At 03:01 PM 4/23/2004 +0100, Joe Orton wrote:
> >On Fri, Apr 23, 2004 at 04:59:27PM +0300, Andi Gutmans wrote:
> > > If at all, I think this should be fixed in PHP so that it affects all
> > SAPIs
> > > (i.e. first time we set umask() save the old one and
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> I know what you were talking about. I was contemplating of making the PCRE
> library use emalloc/efree (a completely different issue), but arrived at
> the conclusion that it wouldn't work because of the compiled regex caching
> we do.
> *A completely diff
I know what you were talking about. I was contemplating of making the PCRE
library use emalloc/efree (a completely different issue), but arrived at
the conclusion that it wouldn't work because of the compiled regex caching
we do.
*A completely different issue*!!!
Andi
At 08:09 AM 4/23/2004 -07
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> At 07:49 AM 4/23/2004 -0700, Rasmus Lerdorf wrote:
>
> > > You didn't understand what I'm saying. If we were to use emalloc/efree
> > > (which we don't but we should if possible) and if we wouldn't replace them
> > > with malloc/free on RSHUTDOWN, then so
At 07:49 AM 4/23/2004 -0700, Rasmus Lerdorf wrote:
> You didn't understand what I'm saying. If we were to use emalloc/efree
> (which we don't but we should if possible) and if we wouldn't replace them
> with malloc/free on RSHUTDOWN, then some other Apache module which handles
> the next request (
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> At 07:43 AM 4/23/2004 -0700, Rasmus Lerdorf wrote:
> >On Fri, 23 Apr 2004, Andi Gutmans wrote:
> > > If we were to use emalloc/efree and PHP would leave these at the end of the
> > > request, then some other Apache module which uses PCRE would be using PH
At 07:43 AM 4/23/2004 -0700, Rasmus Lerdorf wrote:
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> If we were to use emalloc/efree and PHP would leave these at the end of the
> request, then some other Apache module which uses PCRE would be using PHP's
> emalloc/efree. I don't think it has anything to d
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> If we were to use emalloc/efree and PHP would leave these at the end of the
> request, then some other Apache module which uses PCRE would be using PHP's
> emalloc/efree. I don't think it has anything to do with Apache restart.
Which should be fine since
If we were to use emalloc/efree and PHP would leave these at the end of the
request, then some other Apache module which uses PCRE would be using PHP's
emalloc/efree. I don't think it has anything to do with Apache restart.
Andi
At 07:37 AM 4/23/2004 -0700, Rasmus Lerdorf wrote:
I don't underst
I don't understand why this would have to be in RSHUTDOWN. We are talking
about an Apache restart here so MSHUTDOWN should be sufficient.
-Rasmus
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> I think changing back to malloc/free on RSHUTDOWN is a better solution.
> After all, we use our memory man
Okay. I'll release RC2 without it. There have been too many important
fixes, and this seems to be an old bug.
Keep me posted when you manage to nail things down. I'll talk to Zeev about
count() and see what he thinks.
Andi
At 03:32 PM 4/23/2004 +0100, Wez Furlong wrote:
> >We could add a hook
> >We could add a hook to the C iterator API for count();
> >it shouldn't have a huge impact on the rest of the engine.
>
> I'm not sure if the Iterators API is the right place (it's an API for
> foreach()). I guess it could be in either the Iterators API or the Object
> API. What would you expect
At 10:05 AM 4/23/2004 -0400, Ilia Alshanetsky wrote:
On April 23, 2004 10:01 am, Andi Gutmans wrote:
> I think changing back to malloc/free on RSHUTDOWN is a better solution.
> After all, we use our memory manager to prevent memory leaks and I think
> this is one of PHP's most important features. I
At 03:01 PM 4/23/2004 +0100, Joe Orton wrote:
On Fri, Apr 23, 2004 at 04:59:27PM +0300, Andi Gutmans wrote:
> If at all, I think this should be fixed in PHP so that it affects all
SAPIs
> (i.e. first time we set umask() save the old one and a flag that let's
> RSHUTDOWN know it should change it ba
At 02:24 PM 4/23/2004 +0100, Wez Furlong wrote:
While solving http://bugs.php.net/bug.php?id=27974,
we've discovered that count() on an overloaded object
(in this case, a variant object representing an OLE
SafeArray) doesn't return a truthful value.
What, if anything, are we going to do about that?
On April 23, 2004 10:01 am, Andi Gutmans wrote:
> I think changing back to malloc/free on RSHUTDOWN is a better solution.
> After all, we use our memory manager to prevent memory leaks and I think
> this is one of PHP's most important features. I don't trust third party
> extensions :)
The php_pcr
On Fri, Apr 23, 2004 at 04:59:27PM +0300, Andi Gutmans wrote:
> If at all, I think this should be fixed in PHP so that it affects all SAPIs
> (i.e. first time we set umask() save the old one and a flag that let's
> RSHUTDOWN know it should change it back).
(In case it wasn't clear, all my patch
I think changing back to malloc/free on RSHUTDOWN is a better solution.
After all, we use our memory manager to prevent memory leaks and I think
this is one of PHP's most important features. I don't trust third party
extensions :)
Andi
At 11:02 AM 4/22/2004 +0100, Joe Orton wrote:
This fixes #
If at all, I think this should be fixed in PHP so that it affects all SAPIs
(i.e. first time we set umask() save the old one and a flag that let's
RSHUTDOWN know it should change it back).
Andi
At 10:51 AM 4/22/2004 +0100, Joe Orton wrote:
Patch is below; the apache2filter SAPI needs the same f
At 02:23 PM 4/22/2004 -0400, Rob Richards wrote:
From: Sterling Hughes
> I think you are off base in removing them. We need them to hook into
> PHP's error handling system. I think setting/resetting in RINIT
> instead of MINIT is a good place to start and see if that fixes the
> problem. I per
On Fri, 23 Apr 2004, Sebastian Bergmann wrote:
> phpinfo() shows "220040412ÌÌÌxrr" for the Zend Extension
> number here.
Fixed in CVS.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
While solving http://bugs.php.net/bug.php?id=27974,
we've discovered that count() on an overloaded object
(in this case, a variant object representing an OLE
SafeArray) doesn't return a truthful value.
What, if anything, are we going to do about that?
We could add a hook to the C iterator API for
phpinfo() shows "220040412ÌÌÌxrr" for the Zend Extension
number here.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Maili
Hi folks:
There's a problem that I've been trying to figure out since
PHP 4.3.5. My last try was with yesterday PHP's snapshot (200404221230).
Using domxml extension compiled as a module, PHP exits with
"Illegal Instruction". Apache breaks out and even remove it's pid
file. When I don't load this
36 matches
Mail list logo
