Hi,
Recently we've found a huge problem in PHP traits implementation.
It performs copying of each op_array (with all opcodes!) for each method
used from trait. This not only makes traits extremely slow and reduce
effect of opcode caches, but also prohibits extensions from modifying
op_array
Hi Stefan,
On 01/13/2012 02:13 PM, Stefan Marr wrote:
Hi Dmitry:
On 13 Jan 2012, at 10:36, Dmitry Stogov wrote:
Recently we've found a huge problem in PHP traits implementation.
Thanks for taking care of it, but just to be explicit here: I pointed out the
implementation details
Hi Alex,
Right now it's possible to use SOAP with proxy using special options in
SoapClient constructor
(http://www.php.net/manual/en/soapclient.soapclient.php)
new SoapClient($wsdl, array('proxy_host' = 'my.proxy.com',
'proxy_port' = '8080',
Hi Yasuo,
how did you see that Zend Multibyte Support weren't enabled?
$ sapi/cli/php -d zend.multibyte=1 -i | grep -i multibyte
Zend Multibyte Support = provided by mbstring
zend.multibyte = On = On **
Multibyte Support = enabled
Multibyte string engine = libmbfl
Multibyte (japanese)
I suppose PHP can't autodetect SJIS encoding and needs a hint
for 5.4
$ php -d zend.multibyte=1 -d zend.script_encoding=SJIS sjis.php
5.3 must be compiled with --enable-zend-multibyte, then
$ php -d mbstring.script_encoding=SJIS for 5.3
(I've just tested 5.4 but not 5.3. Just don't have 5.3
$ sapi/cli/php -d zend.multibyte=1 -d zend.script_encodinSJIS -d
mbstring.internal_encoding=UTF8 -d mbstring.output_encoding=UTF8 sjis.php
表
Too many different encodings :)
Thanks. Dmitry.
On 11/03/2011 01:38 PM, Yasuo Ohgaki wrote:
Oops, I thought ? was due to terminal encoding, but I
Hi Gustavo,
First of all, thank you for catching this.
For now, I've tried to extend GC to support closures.
You can find the proposed patch at https://bugs.php.net/bug.php?id=60139
However it won't work for other classes, anyway.
Probably it would be better to extend object handlers in 5.4
I've also wrote another patch (gc-closure2.diff at
https://bugs.php.net/bug.php?id=60139) that introduce new get_gc()
object handler in 5.4.
Thanks. Dmitry.
On 10/31/2011 12:51 PM, Dmitry Stogov wrote:
Hi Gustavo,
First of all, thank you for catching this.
For now, I've tried to extend GC
Hi,
As I already said, I don't see any technical issues with the patch.
I don't like it very mach, but it looks robust, and I don't object about it.
Thanks. Dmitry.
On 10/14/2011 10:08 PM, Arnaud Le Blanc wrote:
Hi,
I've already posted this patch and it has since been reviewed and improved.
Hi Flavius,
Unfortunately, the proposed fix is wrong.
It changes the operators precedence and it's definitely wrong.
I suppose the crash caused by side effect of some other bug.
Try to run the same script with valgrind.
Thanks. Dmitry.
On 09/11/2011 02:27 PM, Flavius Aspra wrote:
Hi
I
in final RC phase of 5.3.7. I don't think
it is critical for 5.3.7 and I wonder whether we need it for 5.3 at
all.
johannes
On Mon, 2011-07-04 at 14:55 +, Dmitry Stogov wrote:
dmitry Mon, 04 Jul 2011 14:55:39 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=312904
Log:
Fixed
Hi Arnaud,
Is the main advantage of the patch - elimination of zval copy
constructor for IS_VAR and IS_CV operands?
Does it improve speed only for VAR/CV array operands?
Will the following script require an extra zval ealloc/efree with the patch?
?php
function foo($x, $y) {
$x ? $y
Hi Stas,
On 07/11/2011 11:25 AM, Stas Malyshev wrote:
Hi!
On 7/11/11 12:18 AM, Dmitry Stogov wrote:
Hi Ralph,
I don't have strong opinion about your suggestion.
In some cases this warning might help to find a typo, in others it may
be useless, but anyway, I think that usage of undefined
For now the patch still looks a bit messing to me. Also, I would
probably prefer to use new opcodes ZEND_QM_ASSIGN_VAR and ZEND_JMP_SET_VAR.
Ok, I'll change the patch to use new opcodes instead
It's not necessary yet.
Please, let me think a bit more.
Thanks. Dmitry.
--
PHP Internals -
assign it to yourself?
Thanks,
Ralph
On 6/30/11 2:39 AM, Dmitry Stogov wrote:
Hi Ralph,
I agree with expected behavior, but didn't understand the patch and
which side effects it may have as well as the original implementation of
is_a_impl(). It looks for me like one huge bug :)
Please reassign
it to yourself?
Thanks,
Ralph
On 6/30/11 2:39 AM, Dmitry Stogov wrote:
Hi Ralph,
I agree with expected behavior, but didn't understand the patch and
which side effects it may have as well as the original implementation of
is_a_impl(). It looks for me like one huge bug :)
Please reassign the bug
Hi Ralph,
I agree with expected behavior, but didn't understand the patch and
which side effects it may have as well as the original implementation of
is_a_impl(). It looks for me like one huge bug :)
Please reassign the bug to me, if you like me to take a deeper look.
I can do it only on
Hi Felipe,
I like the idea. It makes indirect method calls less expensive.
I would add a hint to specializer, to eliminate small overhead for
regular function calls.
} else if (OP1_TYPE != IS_CONST
EXPECTED(Z_TYPE_P(function_name) == IS_ARRAY)
Hi,
In my opinion a restriction API compatibility must be kept (internals
and userland) for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.
I would suggest to change API compatibility must be kept to API
backward compatibility must be kept as much as possible.
slightly to allow for changes that
break undocumented behaviors, but leaves it basically stable and measurable.
This also leaves the door open for internal changes if they're really needed,
but basically suggests against it.
John Crenshaw
Priacta, Inc.
-Original Message-
From: Dmitry
Hi,
The attached patch improves speed of numeric operations by inlining the
most probable paths directy into executor. It also optimizes some
operations for x86 CPU using assembler.
The bench.php gets more than 10% speedup (2.5 sec instead of 2.9 sec)
Real-life applications are not affected.
Hi Pierre,
On 05/20/2011 01:49 PM, Pierre Joye wrote:
hi Dmitry,
Nice improvements, thanks :)
Any reason not to have done the changes for windows as well?
Sorry, I'm not an expert in MS VC inline assembler.
As I remember in VC6 it was poor and didn't allow complicated things.
In case
On 05/20/2011 02:05 PM, Pierre Joye wrote:
On Fri, May 20, 2011 at 12:01 PM, Dmitry Stogovdmi...@zend.com wrote:
Hi Pierre,
On 05/20/2011 01:49 PM, Pierre Joye wrote:
hi Dmitry,
Nice improvements, thanks :)
Any reason not to have done the changes for windows as well?
Sorry, I'm not an
Hi Moriyoshi,
OK, I thought the email was lost, so ignore the email I just resent.
In general I like your patch and I would glad to see it fixed.
I already tried to make some fixes.
See the attached patch.
Thanks. Dmitry.
On 03/02/2011 11:51 PM, Moriyoshi Koizumi wrote:
Hey,
I think I can
Hi Moriyoshi,
Some ext/exif and Zend/tests/multibyte tests are still broken after your
mbstring related changes on December. ext/exif just can't work because
you changed the prototypes of zend_multibyte functions but not the
function invocations.
Are you going to fix it?
Thanks. Dmitry.
Hi,
The proposed patch completely removes ext/mbstring compile-time
dependencies. As result the same php binaries may be used for Asian and
European languages without performance degradation. ext/mbstring now may
be compiled as a DSO. I'm going to commit the patch on Wednesday.
Any comments
Thanks. Already removed it.
Dmitry.
On 12/06/2010 01:21 PM, Hannes Magnússon wrote:
On Mon, Dec 6, 2010 at 09:31, Dmitry Stogovdmi...@zend.com wrote:
Hi,
The proposed patch completely removes ext/mbstring compile-time
dependencies. As result the same php binaries may be used for Asian and
Hi Moriyoshi,
On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
Hi,
How about using the value of mbstring.script_encoding to determine
whether to enable the encoding conversion feature? If the value is
the same as that of mbstring.internal_encoding, then no conversion
should be needed in the
On 12/06/2010 08:38 PM, Moriyoshi Koizumi wrote:
Hi,
The patch almost looks good to me, but we should be more careful about
introducing a set of hook points into the API. I think it'd be great
if the multipart parser portion was rewritten so that it would only
call the Zend multibyte API's
On 12/06/2010 08:25 PM, Moriyoshi Koizumi wrote:
On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogovdmi...@zend.com wrote:
Hi Moriyoshi,
On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote:
Hi,
How about using the value of mbstring.script_encoding to determine
whether to enable the encoding
On 12/07/2010 03:32 AM, Moriyoshi Koizumi wrote:
On Tue, Dec 7, 2010 at 5:57 AM, Dmitry Stogovdmi...@zend.com wrote:
On 12/06/2010 08:25 PM, Moriyoshi Koizumi wrote:
On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogovdmi...@zend.comwrote:
Hi Moriyoshi,
On 12/06/2010 01:31 PM, Moriyoshi
Hi Felipe,
I'm wondered it works out of the box with so small patches :)
However, both patches introduce new parser conflicts and it would be
grate to avoid them.
Also the patches need to be checked for memory leaks in case of
exceptions thrown from constructor and chained function(s).
It
the proposed patch (backport from php6) is attached.
I think this feature is completely useless and it was agreed to remove
it about 5 years ago.
Derick, can I commit the patch today?
Thanks. Dmitry.
Dmitry Stogov wrote:
Hi,
Previously we decided to remove break/continue $var syntax.
I
in a BC
break sections.
done.
Thanks. Dmitry.
[1] http://google.com/codesearch?hl=ensa=Nq=lang:php+break\s{1,}%28\%24\w%29
Cheers,
On Wed, Nov 24, 2010 at 1:11 PM, Dmitry Stogov dmi...@zend.com wrote:
the proposed patch (backport from php6) is attached.
I think this feature is completely
hi,
I've prepared the patch which completely removes compile-time
--enable-zend-multibyte configuration directive.
The configuration can be changed at run-tume using zend.multibyte=0/1.
The patch also fixes Unicode detection for phar archives.
I would like to commit it on Thursday.
Thanks.
Derick Rethans wrote:
On Tue, 23 Nov 2010, Dmitry Stogov wrote:
I've prepared the patch which completely removes compile-time
--enable-zend-multibyte configuration directive.
The configuration can be changed at run-tume using zend.multibyte=0/1.
The patch also fixes Unicode detection
Gustavo Lopes wrote:
On Tue, 23 Nov 2010 09:34:49 -, Dmitry Stogov dmi...@zend.com wrote:
hi,
I've prepared the patch which completely removes compile-time
--enable-zend-multibyte configuration directive.
The configuration can be changed at run-tume using zend.multibyte=0/1.
The patch
Hi Chris,
I've added a note into UPGRADING, but I didn't change php.ini-*
Thanks. Dmitry.
Christopher Jones wrote:
On 11/23/2010 01:34 AM, Dmitry Stogov wrote:
hi,
I've prepared the patch which completely removes compile-time
--enable-zend-multibyte configuration directive
wrote:
On 11/19/2010 06:16 AM, Dmitry Stogov wrote:
Derick Rethans wrote:
On Thu, 18 Nov 2010, Christopher Jones wrote:
On 11/18/2010 06:26 AM, Dmitry Stogov wrote:
The proposed patch allows compiling PHP with --enable-zend-multibyte
and then enable or disable multibyte support at run-time
, Dmitry Stogov wrote:
Previously we decided to remove break/continue $var syntax.
I even implemented it in PHP6 brunch, however it wasn't backported into
trunk. Could I do it?
Is there a really good reason to remove it?
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
CG(multibyte) is defined only inside #ifdef ZEND_MULTIBYTE.
Thanks. Dmitry.
Patrick ALLAERT wrote:
2010/11/18 Dmitry Stogov dmi...@zend.com:
Index: ext/mbstring/mbstring.c
===
--- ext/mbstring/mbstring.c (revision 305494
Derick Rethans wrote:
On Thu, 18 Nov 2010, Christopher Jones wrote:
On 11/18/2010 06:26 AM, Dmitry Stogov wrote:
The proposed patch allows compiling PHP with --enable-zend-multibyte
and then enable or disable multibyte support at run-time using
zend.multibyte=0/1 in php.ini. As result
Hi,
The proposed patch allows compiling PHP with --enable-zend-multibyte and
then enable or disable multibyte support at run-time using
zend.multibyte=0/1 in php.ini. As result the single binary will be able
to support multibyte encodings and run without zend-multibyte overhead
dependent on
Hi,
Previously we decided to remove break/continue $var syntax.
I even implemented it in PHP6 brunch, however it wasn't backported into
trunk. Could I do it?
Thanks. Dmitry.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hi,
don't we have ext/filter that should check all the dangerous input
strings? It would be useless to perform additional checks for constant
stings known at compile time (e.g. on include foo.php)
Thanks. Dmitry.
Rasmus Lerdorf wrote:
On 11/15/10 10:12 PM, Stas Malyshev wrote:
Hi!
Well,
Hi,
The attached patch modifies internal ZE data structures.
It gives 4% less heap memory usage on waiting PHP process (2210KB
instead of 2304KB) and up to 7% improvement on applications with many
classes (ZendFramework benchmark uses 17.7M instead of 19M). It also
makes small speedup on some
Hi Guilherme,
Guilherme Blanco wrote:
Hi Dmitry,
Comments goes inline.
On Wed, Sep 8, 2010 at 10:56 AM, Dmitry Stogov dmi...@zend.com wrote:
Pierrick Charron wrote:
Hi Dmitry,
First thanks for having a look at the patch and taking some time to
give your feedback ! It's much appreciated
Hi Pierrick,
I've taken just a quick look into concept and patch. It looks
interesting and might be useful in some areas, but I see several
significant problems:
1) Have you thought about compatibility with opcode caches? In case I
understood properly, you store annotation as a HashTable of
Hi Derick,
We had a long discussion on RFC and hear you can see the summary of my
opinion:
I think removing the strict type hinting (reverting semantic back to
5.3), but keeping the new syntax and reflection API is a good decision.
However I definitely against of delegation of type-hinting
Pierrick Charron wrote:
Hi Dmitry,
First thanks for having a look at the patch and taking some time to
give your feedback ! It's much appreciated
2010/9/8 Dmitry Stogov dmi...@zend.com:
Hi Pierrick,
I've taken just a quick look into concept and patch. It looks interesting
and might
Hi,
Recently I noticed that reading of string offset is performed in two
steps. At first special string_offset variant of temporary_variable is
created in zend_fetch_dimension_address_read() and then the real string
value is created in _get_zval_ptr_var_string_offset().
I think we can
Hi,
s...@geleia.net wrote:
On Tue, May 18, 2010 8:22 am, Dmitry Stogov wrote:
I'm proposing another optimisation technique implementation for PHP
which makes up to 20% speed up on synthetic tests and up to 8% speed up on
real-life applications.
The technique is similar to inline caches which
Stas Malyshev wrote:
Hi!
I see three key options going forward:
1. Implement the table along the lines of what it looks like now,
perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in
PHP; That effectively turns type hinting into scalar casting
Hi Chris,
I've added notes for extension maintainers.
I hope they will answer all your questions.
Thanks. Dmitry.
Christopher Jones wrote:
Dmitry Stogov wrote:
http://wiki.php.net/rfc/runtimecache
The patch breaks binary and source compatibility but it's not
hard to
adopt
Hi Jones,
Christopher Jones wrote:
Dmitry Stogov wrote:
Hi,
I'm proposing another optimisation technique implementation for PHP
which makes up to 20% speed up on synthetic tests and up to 8% speed up
on real-life applications.
The technique is similar to inline caches which
Hi,
I'm proposing another optimisation technique implementation for PHP
which makes up to 20% speed up on synthetic tests and up to 8% speed up
on real-life applications.
The technique is similar to inline caches which is very popular in JIT
compilers for object oriented languages.
Hi Moriyoshi,
I took just a quick look through the patch, but for me it looks like a
bad idea. Introducing new magic function may bring a lot of troubles and
open a new door for exploit writer (we already have problems with
__toString() method). Also I afraid, this magic method will make php
Hi Rob,
May be I missed the discussion...
I'm not sure if it's a good idea to have all this scarp in SVN.
Personally, I won't support these DSP files just because I don't use
Visual Studio 6.0 to build php. This method was deprecated for ages. I'm
also not sure if next php version is going to
Hi Rob,
The problem is not to have them. The problem is to keep them in
consistency in case someone adds/removes a file. I like the idea of
automatic generation much more.
Thanks. Dmitry.
Rob Richards wrote:
Hi Dmitry,
The discussion was a while ago (Steph was working on a way to
Hi Christopher,
Christopher Jones wrote:
Dmitry Stogov wrote:
Hi,
I've added the corresponding patch for APC, so anyone is able to verify
the performance difference.
http://wiki.php.net/rfc/performanceimprovements
Dmitry,
What do you think caused the fw difference in absolute
Hi Derick,
Thank you for review.
Derick Rethans wrote:
On Tue, 13 Apr 2010, Dmitry Stogov wrote:
I've published all the patches, their description and performance evaluation
at http://wiki.php.net/rfc/performanceimprovements
I've a few questions and comments:
http://wiki.php.net/rfc
Hi Alexey,
I'll try to take care of it.
It's definitely a bug, however I'm not sure how to fix it yet.
(I've updated the bug report).
Thanks. Dmitry.
Alexey Zakhlestin wrote:
I was doing some tests with long-running scripts recently and noticed that 5.3
is leaking memory in cases where 5.2
Hi,
I've added the corresponding patch for APC, so anyone is able to verify
the performance difference.
http://wiki.php.net/rfc/performanceimprovements
Thanks. Dmitry.
Dmitry Stogov wrote:
Hi,
I've published all the patches, their description and performance
evaluation at http
Kalle Sommer Nielsen wrote:
Hi Dmitry
2010/4/19 Dmitry Stogov dmi...@zend.com:
Hi,
I've added the corresponding patch for APC, so anyone is able to verify the
performance difference.
http://wiki.php.net/rfc/performanceimprovements
Thanks. Dmitry.
Dmitry Stogov wrote:
In the patched
Hi,
I've published all the patches, their description and performance
evaluation at http://wiki.php.net/rfc/performanceimprovements
In two words the patches give 0-20% improvement even on real-life
applications.
I'm going to commit them into trunk in a week in case of no objections.
Of
Hi Richard,
Richard Quadling wrote:
On 13 April 2010 14:53, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I've published all the patches, their description and performance evaluation
at http://wiki.php.net/rfc/performanceimprovements
In two words the patches give 0-20% improvement even on real
and deserialization could benefit.
Though I guess igbinary could be patched to take advantage of
string interning?
Probably it can. However, I've never looked into it, so I can't be sure.
Thanks. Dmitry.
-Jared
-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent
Hi Kalle,
Kalle Sommer Nielsen wrote:
Hi
2010/4/13 Dmitry Stogov dmi...@zend.com:
Hi,
I've published all the patches, their description and performance evaluation
at http://wiki.php.net/rfc/performanceimprovements
The only thing I notice while browsing the patches was that you need
to add
Hi Moriyoshi,
Moriyoshi Koizumi wrote:
Hi,
Wouldn't it suffice to add a field for the hash value and a flag that
indicates its validity to zval instead of appending zend_literal
everywhere?
We used the approach you suggest on the early stages of development, but
then realized that passing
Moriyoshi Koizumi wrote:
Hi,
On Thu, Mar 25, 2010 at 8:41 AM, Stanislav Malyshev s...@zend.com wrote:
Hi!
Wouldn't it suffice to add a field for the hash value and a flag that
indicates its validity to zval instead of appending zend_literal
everywhere?
Enlarging zval would be costly (the
Hi Rasmus,
Rasmus Lerdorf wrote:
On 03/24/2010 07:12 AM, Zeev Suraski wrote:
Hi,
Over the last few weeks we've been working on several ideas we had for
performance enhancements. We've managed to make some good progress. Our
initial tests show roughly 10% speed improvement on real world apps.
Hi Rasmus,
Let me know how to reproduce them and I'll try to look into them.
Thanks. Dmitry.
Rasmus Lerdorf wrote:
I'm seeing some GC-related segfaults in current PHP_5_3. I haven't had
time to dive into it very far. All I have is a couple of bts and the
request that triggers it, but it is
Jani Taskinen wrote:
On 09/07/2009 09:25 AM, Dmitry Stogov wrote:
Hi,
I'm wondered why the shebang line support was removed from scanner.
Because it didn't make any sense for other SAPIs. You could ask Ilia
more about
branches, but
it's the second priority.
Thanks. Dmitry.
David Zülke wrote:
On 28.07.2009, at 19:14, Jani Taskinen wrote:
Dmitry Stogov wrote:
David Zülke wrote:
On 28.07.2009, at 13:32, Dmitry Stogov wrote:
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break
Hi Derick,
Derick Rethans wrote:
On Tue, 11 Aug 2009, Dmitry Stogov wrote:
The patch can't be used as it breaks ext/soap build as shared extension.
timelib function are compiled into php and aren't exported :(
May be you will be able to change the patch using ext/date public API.
We can
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final decision.
The only thing I didn't understood - why win32/php_stdint.h is needed.
Thanks. Dmitry.
David Zülke wrote:
On 28.07.2009, at 13:32, Dmitry Stogov wrote:
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final decision.
The only thing I
Hi David,
Please report a bug on bugs.php.net (assign it to dmitry).
I'll look into it later.
Thanks. Dmitry.
David Zülke wrote:
This sounds like a serious issue, but I'm not sure if it's in libxml or
in ext/soap. Will have a look later; but maybe Dmitry or someone else
knows off the top of
it's not the only reason. ext/soap also supports digital authentication
which is still unsupported by streams. (may be something else).
Thanks. Dmitry.
David Zülke wrote:
On 10.07.2009, at 17:00, Hannes Magnusson wrote:
On Fri, Jul 10, 2009 at 16:58, Uwe Schindlertheta...@php.net wrote:
As
1) The patch introduce several new reserved words (resource, numeric,
scalar, object). This may break existing applications which use these
names as function or class names.
2) The patch should define something like ZEND_ARG_TYPE_INFO()
3) do we really need IS_CLASS constant?
4)
more
than a million method calls on a framework does not worth?
None gave a final word on this subject.
I could not see this commited in 5.3 neither in HEAD.
So...can someone notify me about the status of this???
Cheers,
On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov dmi...@zend.com wrote
Hi Paul,
Paul Biggar wrote:
On Mon, May 11, 2009 at 7:47 PM, Guilherme Blanco
guilhermebla...@gmail.com wrote:
What's the status on this one?!
I think it died from neglect. But it was a really good idea.
One question that was raised was:
On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov
method resolution more efficient than
name-function, i.e. hashtable. These lookups can be cached (i.e. CV style)
but I don't see how they can be altogether prevented.
On Tue, May 12, 2009 at 7:25 AM, Dmitry Stogov dmi...@zend.com wrote:
The real things is even worse as during compilation
Paul Biggar wrote:
On Tue, May 12, 2009 at 9:43 AM, Dmitry Stogov dmi...@zend.com wrote:
Apologies, I'm not familiar with run-time inheritence in PHP. My
understanding was that when a classes source code is compiled, its
parent classes must be known. When is this not the case?
The parent
Hi Matt,
I wasn't able to look into all details of the patch, but in general I
like it, as it fixes bugs and makes scanner smaller. I think you can
commit it.
Although this patch doesn't fix the EOF handling related to mmap().
Thanks. Dmitry.
Matt Wilmas wrote:
Hi guys,
- Original
Hi Matt,
Does this patch fix EOF handling issues related to mmap()? (e.g. parsing
of files with size 4096, 8192, ...). Now we have two dirty fixes to
handle them correctly.
The patch is quite big to understand it quickly. I'll probably take a
look on weekend.
-ANY_CHAR [^\x00]
+ANY_CHAR
I looked into it some time ago.
Really, I don't understand what it's going to fix (the need of
preserving low bits looks strange for me).
Also it breaks ~30 tests.
Thanks. Dmitry.
Johannes Schlüter wrote:
On Fri, 2009-04-10 at 14:45 -0500, Matt Wilmas wrote:
Hi Dmitry,
I finally updated
Hi,
Thanks for comments.
The updated patch fixes RFC incompatibilities. It just ignores
extensions and trailer.
The patch also exports chunked filter into user space so now it can be
used with any streams (see test in the patch).
In case user opens http stream and server responds with
I sent a new version of patch with these features a minute ago :)
Thanks. Dmitry.
Arnaud Le Blanc wrote:
Hi,
On Tue, 2009-04-14 at 18:59 +0400, Dmitry Stogov wrote:
Some PHP applications which check for Transfer-Encoding HTTP header and
perform manual decoding might be broken.
What about
Christopher Jones wrote:
Stanislav Malyshev wrote:
Hi!
I'm looking forward to reading at least a mail note describing what
extension
maintainers can/can't do with this.
Basically you can make your Zend extension load with any API number
and any build ID (or let it decide with which ID
Hi Matt,
I don't really see why we should preserve the least significant bits
and I don't think we should support bitwise operations with doubles.
Stas, could you please look into this too.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent
Hi Matt,
I tried to look into this issue once again, but I completely
misunderstand why do we need all this magic. Why do we need conversion
of positive double into negative long?
I would stay with single DVAL_TO_LVAL() definition and use it in places
instead of (long)Z_DVAL().
#define
Hi Basant,
I've updated you patch for 5.3 (attached, don't forget to regenerate
zend_vm_execute.h). 5.2 is closed for such changes anyway and I don't
think the patch should be applied into 5.3 too, because it is in RC stage.
I got ~10% speed-up on very synthetic benchmarks (b.php attached).
Lukas Kahwe Smith wrote:
On 16.03.2009, at 16:49, Pierre Joye wrote:
2009/3/16 Johannes Schlüter johan...@php.net:
Hi,
On Mon, 2009-03-16 at 09:52 +, Dmitry Stogov wrote:
Log:
Fixed bug #47664 (get_class returns NULL instead of FALSE)
[...]
@@ -716,7 +716,7 @@
int dup
Hi Matt,
I ran you version but it looked little bit slower (I checked it with
callgrind). So I kept the current CVS version. Anyway, it is not a big
problem to change it after RC.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday
later (around the usual time) to let you know
either way. :-)
I'm waiting for your changes.
Thanks. Dmitry.
- Matt
- Original Message -
From: Dmitry Stogov
Sent: Wednesday, March 18, 2009
Hi Matt,
I suppose I fixed the patch.
Could you please check which patch is better yours
Hi Matt,
I have no objections against proposed behaviour, but can't we use just a
check for (errno == ERANGE) after strtol()?
Thanks. Dmitry.
Matt Wilmas wrote:
Hi all,
Assuming there are no objections, I'll commit this fix in a few hours...
Besides the bug report(s), I had also found
Hi Matt,
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Wednesday, March 18, 2009
BTW may be we should eliminate strtol() at all.
There's no need to scan the string twice.
Your change to remove strtol() [1] is not checking for overflow
correctly
$a[2147483648] 0.168 0.142
$a[0]0.116 0.082
$a[214748364x] 0.136 0.141
$a[0] 0.0800.080
Also, do you have other patches which I could look into before RC?
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Wednesday, March 18, 2009
Hi Matt,
I suppose I fixed the patch.
Could you please check which patch is better yours or the attached one?
According to attached benchmark my one is faster for most usual
1101 - 1200 of 1669 matches
Mail list logo
