hi,
On Tue, Feb 17, 2009 at 02:02:35AM -0500, Eric Stewart wrote:
> 14. A few other directives have been question but I don't have enough
> experience with these particular settings so please weight in on them.
>
> extension_dir = "./"
> enable_dl = On
i'd be incredibly weary of this setting, ev
Hello Greg,
Wednesday, February 11, 2009, 6:07:27 AM, you wrote:
> Hi,
> While tracking down a problem in one of phar's tests, I found what might
> be a problem in RecursiveDirectoryIterator's handling of flags. Here is
> a crude patch demonstrating the issue, and wondering if this is
> some
On Tue, Feb 17, 2009 at 10:12, sean finney wrote:
> hi,
>
> On Tue, Feb 17, 2009 at 02:02:35AM -0500, Eric Stewart wrote:
>> 14. A few other directives have been question but I don't have enough
>> experience with these particular settings so please weight in on them.
>>
>> extension_dir = "./"
>>
Anyone's thoughts on this?
I'm thinking of re-reverting in 48 hours without further objections.
Moriyoshi
On Sun, Feb 15, 2009 at 11:48 PM, Moriyoshi Koizumi wrote:
> Ilia Alshanetsky wrote:
>> I've discussed this issue with Andrei at least a month ago (if not
>> longer) when the patch was orig
On Tue, 2009-02-17 at 10:12 +0100, sean finney wrote:
> hi,
>
> On Tue, Feb 17, 2009 at 02:02:35AM -0500, Eric Stewart wrote:
> > 14. A few other directives have been question but I don't have enough
> > experience with these particular settings so please weight in on them.
> >
> > extension_dir
14. A few other directives have been question but I don't have enough
experience with these particular settings so please weight in on them.
extension_dir = "./"
enable_dl = On
I think enable_dl should be off by default in both production and test
environments. Aside from being a somewhat a
Moriyoshi Koizumi wrote:
Ilia Alshanetsky wrote:
I've discussed this issue with Andrei at least a month ago (if not
longer) when the patch was originally added, and I believe that the
introduced behavior is the correct one.
IMO correct or not depends on the context where the function is used.
Eric,
Should uncommented parameters that seem to have the default value be
commented out? For example "asp_tags" and "precision". If the
parameters don't always have the same default value everywhere, should
they be documented in Quick Reference section as having a different
value to the defau
Hello all, I've cooked up a short patch for Bug 42362, and would
appreciate comments. The patch turns off zlib compression if there is no
output, to make zlib_compression play more nicely with 304s.
Cheers,
Edward
Index: ext/zlib/zlib.c
Hi,
while implementing a small toy extension (see [1]) I found out that
ZEND_USER_OPCODE_CONTINUE seems to misbehave as it doesn't go to the
next opcode so I ended up in an endless loop executing the same opcode
again and again.
I'm not sure whether we should change the behavior, using a trivial
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Johannes,
> while implementing a small toy extension (see [1]) I found out that
> ZEND_USER_OPCODE_CONTINUE seems to misbehave as it doesn't go to the
> next opcode so I ended up in an endless loop executing the same opcode
> again and again.
I gu
Hi Johannes,
> while implementing a small toy extension (see [1]) I found out that
> ZEND_USER_OPCODE_CONTINUE seems to misbehave as it doesn't go to the
> next opcode so I ended up in an endless loop executing the same opcode
> again and again.
Isn't that expected behaviour? If a normal opcode h
Stefan,
On Tue, 2009-02-17 at 22:05 +0100, Stefan Esser wrote:
> > while implementing a small toy extension (see [1]) I found out that
> > ZEND_USER_OPCODE_CONTINUE seems to misbehave as it doesn't go to the
> > next opcode so I ended up in an endless loop executing the same opcode
> > again and
Edward Z. Yang wrote:
> Hello all, I've cooked up a short paonetch for Bug 42362, and would
> appreciate comments. The patch turns off zlib compression if there is no
> output, to make zlib_compression play more nicely with 304s.
The previous patch is wrong (it doesn't handle the flush();flush();
On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski wrote:
> SORT_STRING can only reliably deal with strings - its behavior on non-string
> type is basically broken. Unless we agree that PHP is Tcl (strings are the
> only type), then SORT_REGULAR makes much more sense to me, and evidently
> others.
In addition, we should look at similar comparison-involved array
functions such as array_intersect, array_diff and so on, otherwise
it's gonna be a mess.
Moriyoshi
On Wed, Feb 18, 2009 at 11:43 AM, Moriyoshi Koizumi wrote:
> On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski
> wrote:
>
>> SORT_S
hi,
recently, working on an extension, i wanted to call a method w/ 3 params,
and as you know, zend_call_method only supports 2 parameters at most. i
came across this thread in the archives,
http://marc.info/?l=php-internals&m=120179690310419&w=2
so i tossed together a quick patch w/ no emalloc
17 matches
Mail list logo
