I don't understand what are you going to demonstrate with this example.
Did you try to run it?
It produces error as expected.
DOMDocument() in your example is a user-space class that is not related
to internal ext/dom class. If you like to use internal class that is
overriden in namespace you
In general this patch will use more memory.
(4 bytes more for each heap allocated zval).
The only advantage is automatic cycle collection, but most web
applications doesn't make cycles.
Dmitry.
Guilherme Blanco wrote:
I want to put my 2 cents, but before make any comment, I'm interested
to
Derick Rethans wrote:
On Tue, 4 Dec 2007, Andi Gutmans wrote:
To clarify I meant there's a tri-state (not compiled in, compiled in
but collection turned off, compiled in but collection turned on). My
recommendation was to always compile it in but to keep collection
turned off by default.
The GC patch passes the whole php test-suite with the same bugs.
The fact that it crashes on some script doesn't mean that the patch
doesn't actually work.
Thanks. Dmitry.
Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably
wrote:
On Thu, 6 Dec 2007, Dmitry Stogov wrote:
Derick Rethans wrote:
That doesn't mean it works better for me than the old one either, where I
couldn't get it to crash at all ;-) Anyway, did you try to reproduce it with
the instructions that I provided?
Yes I did. I'm looking into the crash
Jessie Hernandez wrote:
I thought global names were considered in the patch, but now that I
re-read Dmitry's post, only symbols in the namespace and internal
symbols are considered.
I read through most of the posts regarding namespaces, but could not
find a reason why global names are not
Hi Derick,
Now, you cannot override existing classes with use statement.
However inside a namespace you don't have internal classes and use
works just fine.
?php
namespace Foo;
use myNamespace::Bar as stdClass;
?
I think it is clear decision.
If you like to override internal classes just
GC fixes three tests. (I can send you logs if you like)
Thanks. Dmitry.
Derick Rethans wrote:
On Fri, 7 Dec 2007, Dmitry Stogov wrote:
all your tests passed for me yesterday with memory_limit=1G.
May be it's some fresh non GC related bug :)
Try the same test with -dzend.enable_gc=0
BTW the interesting fact that during Derick's test GC cycle collector
was automatically run 124 times and it collected 2,388,399 zvals.
So it really works! :)
Dmitry.
Dmitry Stogov wrote:
Hi Derick,
You test are enormous, but than you anyway. :)
I've found and fixed the problem.
Now your
Hi Jessie,
The namespace may include several files and it may be extended with
additional files in any moment. So having single
__get_namespace_classes() function will require to update it every time
you extend namespace.
Also such function will significantly slowdown access to internal
Probably I've changed ZE after the patch was done :(
I'll rebuild it, but not today.
Dmitry.
Derick Rethans wrote:
On Mon, 17 Dec 2007, Dmitry Stogov wrote:
Didn't I send it to you?
Maybe, maybe not :) I couldn't find it atleast.
I just tried to apply this to PHP 5.3, but it gives lots
to `gc_globals'
php5.3-200712250730/Zend/zend_gc.h:183: undefined reference to `gc_globals'
php5.3-200712250730/Zend/zend_gc.h:184: undefined reference to `gc_globals'
collect2: ld returned 1 exit status
right now ...
- - Markus
Dmitry Stogov wrote:
updated patch.
Dmitry.
Derick Rethans wrote
Thanks for catching this.
Committed.
Dmitry.
phpxcache wrote:
http://bugs.php.net/bug.php?id=43696
Description:
as you can see in zend_compile.c
opline-opcode = ZEND_INIT_NS_FCALL_BY_NAME;
ZEND_INIT_NS_FCALL_BY_NAME's op1 is initialized, so is op2
.
Hi,
The attached patch (for PHP_5_3) implements the segmented argument_stack
that has the following advantages:
1) It fixes #43426 and other crashes which occur because of stack
reallocation.
2) The whole stack is never reallocated. So we don't have penalties
because of the while stack
to optimize it.
Thanks. Dmitry.
Thanks,
Nuno
- Original Message - From: Dmitry Stogov [EMAIL PROTECTED]
To: PHP Internals List internals@lists.php.net
Sent: Monday, January 21, 2008 7:47 PM
Subject: [PHP-DEV] Segmented argument_stack
Hi,
The attached patch (for PHP_5_3) implements
The final nowdoc patches are attached.
I'm going to commit them on Thursday in case of no objections.
Thanks. Dmitry.
Stanislav Malyshev wrote:
Hi all!
I remember the topic of 'nowdocs' (if you don't remember what it is,
read on) was already discussed, but nothing really happened about it.
The feature is very useful, however, I agree, the syntax would be better. :)
The current syntax:
$var = 'TEXT'
text
TEXT;
Thanks. Dmitry.
Antony Dovgal wrote:
On 30.01.2008 16:41, Dmitry Stogov wrote:
The final nowdoc patches are attached.
I'm going to commit them on Thursday in case
Hi,
We are going to include your md5() implementation into php-5.3.0.
I confirm at least 25% md5() speedup on my Core2 3GHz, however license
issues are not clear.
We are going to distribute files under standard PHP license including
your original copyright notes.
The files which are going to
Hi Scott,
I'm fine with your patch.
Please commit it, or let me know if you like me to commit it.
Thanks. Dmitry.
Scott MacVicar wrote:
Hi,
While doing some threaded work I noticed that tsrm_mutex_lock and
tsrm_mutex_unlock return different values for Windows and Linux (using
pthread).
is officially
recognized as being compatible with GNU GPL by the FSF -
http://www.fsf.org/licensing/licenses/ - and is apparently recognized by
the OSI - http://opensource.org/node/239
On Tue, Feb 05, 2008 at 02:34:40PM +0300, Dmitry Stogov wrote:
We are going to include your md5() implementation
Thank you for fix.
I assume now the patch is ready to commit.
I'll commit it tomorrow in case of no objections.
Thanks. Dmitry.
Solar Designer wrote:
I wrote:
OK, I think I found it. ext/hash/php_hash_md.h has this:
#define PHP_MD4Init PHP_MD5Init
which breaks when the
Hi,
Solar Designer wrote:
On Thu, Feb 07, 2008 at 04:21:15PM +0300, Dmitry Stogov wrote:
I assume now the patch is ready to commit.
I'll commit it tomorrow in case of no objections.
Yes, it is. No objections from me.
Just two minor points:
1. You have not yet fixed the size_t vs
I'm wondered, how did I change the comment style, because I didn't do it
by hand. :)
Dmitry.
Dmitry Stogov wrote:
Hi,
Solar Designer wrote:
On Thu, Feb 07, 2008 at 04:21:15PM +0300, Dmitry Stogov wrote:
I assume now the patch is ready to commit.
I'll commit it tomorrow in case
Hi Marcus,
I think that the idea of ini preprocessing is great, however I would
like little bit different syntax.
a) I think we don't need (1) ternary support at all, as (2)
if-elif=else-endif may do the same.
b) I think usage of square brackets is not a good idea, because they are
Jani Taskinen wrote:
On Fri, 2008-02-15 at 11:36 +0300, Dmitry Stogov wrote:
a) I think we don't need (1) ternary support at all, as (2)
if-elif=else-endif may do the same.
That was already dropped. :)
b) I think usage of square brackets is not a good idea, because they are
commonly used
the semantic of NOWDOC with double quotes should be the same as HEREDOC.
Dmitry.
Lars Strojny wrote:
Hi,
I know, I might be a bit late but I've played around with NOWDOCS and
one issue popped up instantly: it seems not really logical to me, why
only single quotes are allowed and I have the
#if defined(PHP_MAJOR_VERSION) PHP_MAJOR_VERSION = 6
extension=unicode.so
#endif
Here PHP_MAJOR_VERSION is a PHP constant that is not defined in php-5.3
but might be defined in the future version.
Dmitry.
Jani Taskinen wrote:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani
version.
Dmitry.
Jani Taskinen wrote:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
c) We can use just value insted of ${value} in conditions.
Yup. ${foobar} is actually not any variable per se, but just a
reference to existing ini entry in the file. And I
without changing anything..
--Jani
Dmitry Stogov kirjoitti:
I think it will work.
#ifdef UNDEFINED 5 (false)
#ifdef UNDEFINED = 5 (true)
(but anyway I think it is possible to find out an unclear condition)
Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
shouldn't this be like in C/C++ where a non
: Wednesday, March 05, 2008 11:25 PM
To: Dmitry Stogov; internals Mailing List
Subject: Re: cvs: ZendEngine2(PHP_5_3) / zend.c zend.h
zend_vm_def.h zend_vm_execute.h php-src NEWS php-src/main
fopen_wrappers.c fopen_wrappers.h main.c
Dmitry Stogov wrote:
dmitry Wed Mar 5 13:34
Hi,
The attached patch for PHP_5_3 is going to provide general solution to
control some aspects of PHP compilation. It is absolutely necessary for
all opcode caches to make cached scripts work exactly in the same way as
non-cached.
The problem occurs because early binding of inherited classes is
The patch for this issue is sent to @internals.
It will be probably commited on next week.
Please try to play with it.
Thanks. Dmitry,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
phpxcache
Sent: Friday, March 07, 2008 12:27 PM
To: Johannes
Hi Marcus,
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 09, 2008 3:00 PM
To: Dmitry Stogov
Cc: Derick Rethans; internals Mailing List; Andi Gutmans; Stas
Malyshev; phpxcache
Subject: Re: [PHP-DEV] Patch for opcode caches
Hello
)
Thanks. Dmitry.
-Original Message-
From: Dmitry Stogov
Sent: Monday, March 10, 2008 3:48 PM
To: 'Marcus Boerger'
Cc: Andi Gutmans; Stas Malyshev; 'phpxcache';
'internals@lists.php.net'
Subject: RE: [PHP-DEV] Patch for opcode caches
Hi Marcus,
-Original Message
Sorry for dealy.
It must be fixed now.
Thanks. Dmitry.
-Original Message-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2008 7:26 PM
To: Dmitry Stogov
Cc: internals
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) /
zend_API.c zend_builtin_functions.c
Hi,
I have separated fixes and optimizations from the delayed early binding itself
and added comments about options. Now the patch must be more clear.
The order of actual class declaration in PHP scripts doesn't follow to syntax
order. Some classes might be declared at compile-time (early
, 2008 8:06 AM
To: Dmitry Stogov; internals Mailing List
Subject: [PATCH] adding stream wrappers to include_path
Hi,
I found some time to whip up a quick patch against 5.3.
This patch allows adding stream wrappers to include_path on
both windows and unix. This means one can set
-
From: Pierre Joye [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 2:12 PM
To: Dmitry Stogov
Cc: Gregory Beaver; internals Mailing List
Subject: Re: [PHP-DEV] RE: [PATCH] adding stream wrappers to
include_path
On Thu, Mar 13, 2008 at 11:55 AM, Dmitry Stogov
[EMAIL
I've attached two tests.
BTW it mighr be hard to run them because opcode caches usually don't
work in CLI mode.
Thanks. Dmitry.
-Original Message-
From: Robin Fernandes [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 1:05 PM
To: Dmitry Stogov
Cc: internals
Subject: Re
Hi Marcus,
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 9:27 PM
To: Dmitry Stogov
Cc: Andi Gutmans; Stas Malyshev; phpxcache; internals@lists.php.net
Subject: Re: [PHP-DEV] Patch for opcode caches
Hello Dmitry,
Monday
I do not want to remove early binding. In fact I always
wanted to have early binding as much as possible. Because
that is faster and makes compiler caches easier. So why slow
down stuff? A Compiler cache wants everythign as static as
possible which means a compiler cache wants early
-Original Message-
From: Xuefer [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 15, 2008 11:21 AM
To: Rasmus Lerdorf
Cc: Marcus Boerger; Stas Malyshev; Dmitry Stogov; Andi
Gutmans; internals@lists.php.net
Subject: Re: [PHP-DEV] Patch for opcode caches
I don't actually see
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 10:11 PM
To: Rasmus Lerdorf
Cc: Marcus Boerger; Dmitry Stogov; Andi Gutmans;
internals@lists.php.net
Subject: Re: [PHP-DEV] Patch for opcode caches
I don't actually see early
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 9:28 PM
To: Stas Malyshev
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch for opcode caches
Hello Stanislav,
Friday, March 14, 2008, 6:48:52 PM, you wrote:
Hi!
The patch has been just committed.
You should use something like the following code to make it work.
function cache_compile_file($filename) {
if (!is_cached($filename)) {
...
orig_compiler_options = CG(compiler_optins);
Drop it.
Dmitry.
Felipe Pena wrote:
Hallo developers,
Have we a decision?
2008/3/11, Cristian Rodriguez [EMAIL PROTECTED]:
2008/3/10, Felipe Pena [EMAIL PROTECTED]:
Hello!
I've backported the Dmitry's patch (HEAD) for to drop
zend.ze1_compatibility_mode in PHP_5_3 branch. Would
Hi Greg,
At least your patch is incomplete.
Even it handles stream wrappers in include(), include_once() it doesn't
handle them in fopen() and some other functions.
In general I like the idea, so I'll look how to extend the support.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
I found some
Hi Greg,
I've fixed your patch to work with all functions (fopen, file_get_contente).
Please verify it with ext/phar and then I'll commit it.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
Please look at the stream wrappers in include_path patch I posted last week.
Thanks,
Greg
Index:
Gregory Beaver wrote:
Dmitry Stogov wrote:
Hi Greg,
I've fixed your patch to work with all functions (fopen,
file_get_contente).
Please verify it with ext/phar and then I'll commit it.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
Please look at the stream wrappers in include_path patch I
:
Dmitry Stogov wrote:
Hi Greg,
I've fixed your patch to work with all functions (fopen,
file_get_contente).
Please verify it with ext/phar and then I'll commit it.
Thanks. Dmitry.
Gregory Beaver wrote:
Hi,
Please look at the stream wrappers in include_path patch I posted
last week.
Thanks
The direct comparison must be faster than memcmp().
memcmp() might be optimized into the same code but probably won't be.
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Gregory,
Monday, March 24, 2008, 2:47:25 PM, you wrote:
Marcus Boerger wrote:
Hello Gregory,
Monday, March 24, 2008,
that we cannot open the file. (On
some systems getcwd() may fail on some reasons).
I didn't test the patch with pecl/phar.
Could you explain why php goes into the endless loop?
Thanks. Dmitry.
Gregory Beaver wrote:
Dmitry Stogov wrote:
Hi Greg,
In your second patch you forgot break, so
Gregory Beaver wrote:
Dmitry Stogov wrote:
REALPATH_FAILED looks like a hack :(
PHP itself doesn't need it at all, according to your patch
php_stream_open() may just return NULL immediately instead of setting
of this flag.
However I am not sure that it will work for all cases. The fact
I hope it's the last iteration, but check me anyway.
The patch is based on latest Gregory's patch.
- optimized out strncpy() calls
- zend_resolve_path() replaced with php_resolve_path()
- improved php_resolve_path() to resolve file://...
- fixed possible double-free issue in
Hi Marcus,
The ext/tokenizer/tests/token_get_all_variation17.phpt is probably the
last broken test. It has a memleak. I am not trying to fix it because
you should know it much better, also re2c scanner is not ported to HEAD
yet and you may keep changes that must be ported.
BTW PHP_5_3
Sorry, but I didn't store benchmarks before re2c patch so I can just
compare PHP_5_3 and PHP_5_2.
Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster
Not all the speedup caused by re2c scanner, but it makes significant
part of it.
Thanks. Dmitry.
Of course.
Dmitry.
Christian Schneider wrote:
Dmitry Stogov wrote:
Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster
Out of curiosity: I assume this is without an opcode cache?
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
I'm going to commit it tomorrow.
Thanks. Dmitry.
Gregory Beaver wrote:
Dmitry Stogov wrote:
I hope it's the last iteration, but check me anyway.
The patch is based on latest Gregory's patch.
- optimized out strncpy() calls
- zend_resolve_path() replaced with php_resolve_path()
- improved
:(
Any ideas how to support this?
Dmitry.
Stefan Walk wrote:
On Monday 24 March 2008 20:28:49 Stanislav Malyshev wrote:
Beats me, I'm sure posix-based systems don't, but it is called Uniform
Naming Convention so it's possible somebody might implement it
The fact that it's called uniform
Hi Greg,
in php_resolve_path()
- you removed (p - filename 1) check but it means that c://tmp will be
used as stream wrapper
- you added check for !wrapper, but we don't need to do any filesystem
search for filename with wrong wrapper
I've removed this modifications.
I also added proper
Hi Marcus,
Sorry, if I broke something in latest patch, I just didn't see any
comments from others about it. And from my point of view the patch did
unnecessary things. I still think the same, becaus I mainly changed code
that checks for wrapper in given argument, but not in include_path.
BTW:
Hi Greg,
I just don't see if my changes broke something.
So could you please prove that committed patch has an issue (with test
case), and restore part of your patch that was going to fix the issue.
Sorry for double work.
Thanks. Dmitry.
Greg Beaver wrote:
Dmitry Stogov wrote:
Hi Marcus
(return_value_ptr_ptr)==NULL) before
write it. Will it work for you?
Thanks. Dmitry.
Derick Rethans wrote:
On Fri, 11 Apr 2008, Dmitry Stogov wrote:
dmitry Fri Apr 11 09:43:31 2008 UTC
Modified files: (Branch: PHP_5_3)
/php-src NEWS
/ZendEngine2 zend.c
Rethans wrote:
On Fri, 11 Apr 2008, Dmitry Stogov wrote:
Sorry, but I think mainly about PHP performance, and of course I didn't know
that you trace return_values it in xdebug.
After the patch, in case if return value is not used we set
EG(return_value_ptr_ptr) to NULL before call to nested execute
Hi Scott,
Could you provide a script to reproduce the crash?
Thanks. Dmitry.
Scott MacVicar wrote:
Jeremy Privett wrote:
Another week later and still no response. I would hope /someone/
thinks this a critical issue and needs to be resolved. Is /anyone/
looking at this at all?
Thanks.
Hi,
The proposed patch delays EG(active_symbol_table) initialization till it
's really needed. Most functions don't need EG(active_symbol_table) at
all, as they use IS_CV variables and HashTable initialization and
updating just waste of time.
The patch doesn't break any PHPT tests, it gives
Hi Matt,
I like the idea (especially ZEND_INIT_ARRAY optimization) and from the
first look patch seems proper. I'll need to look into it more careful
before commit (probably on next week).
Thanks. Dmitry.
Matt Wilmas wrote:
Hi all,
Expanding on the idea of passing a size other than 0 to
Hi Matt,
I've made a review of your patch.
At first it has a bug at least in array_psplice() that makes several
tests to fail. So I removed the whole ext/standard part and tested only
Zend Engine changes.
Although the idea is interesting and implementation is perfect, the
patch doesn't
context:
array_splice(...); // Not used in assignment or function call
And the calling code wouldn't be affected? Maybe I don't get it, and that
check should be removed. :-)
Thanks for your feedback,
Matt
- Original Message -
From: Dmitry Stogov
Sent: Wednesday, April 30, 2008
Hi
: Dmitry Stogov
Sent: Wednesday, April 30, 2008
For some reason make test with the patch reported several broken
array_splice() tests. Looking in gdb I saw that init_array() got -1 as a
size of new array.
I don't think checks for return_value_used for array_splice() have a lot
of sense.
Thanks
As we didn't drop this support yet, and it didn't work in namespaces by
mistake I've fixed it to work in the same way as without namespaces.
Removing this support won't give any speedup (except of compilation
speed), but might break a lot of code.
Thanks. Dmitry.
Antony Dovgal wrote:
On
, 5 May 2008, Dmitry Stogov wrote:
As we didn't drop this support yet, and it didn't work in namespaces by
mistake I've fixed it to work in the same way as without namespaces.
Removing this support won't give any speedup (except of compilation speed),
but might break a lot of code.
How can
Hi,
The attached patch allows to declare internal classes, functions and
constants in namesaces and create aliases for classes and functions.
I'm going to commit it on next week in case of no objections.
The second patch (for ext/soap) is just a prove of concept and I'm not
going to commit
Hi,
The proposed patch for PHP improves the executor.
At first it eliminates direct execute() recursion so the following
script won't produce SIGSEGV anymore (It'll produce memory overflow
error instead).
?php
function foo() {
foo();
}
foo();
?
Note that in case some extension (e.q.
to crash!
Nuno
- Original Message - From: Dmitry Stogov [EMAIL PROTECTED]
To: PHP Internals List internals@lists.php.net
Cc: Andi Gutmans [EMAIL PROTECTED]; Stanislav Malyshev [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 12:11 PM
Subject: [PHP-DEV] [PATCH] Executor improvements
Hi
The recursion elimination itself doesn't show any significant speed
difference.
Thanks. Dmitry.
Nuno Lopes wrote:
Nuno Lopes wrote:
Out of curiosity, what's the slowdown without fastcall?
fastcall calling convention assumes passing parameters in registers
instead of pushing them on stack.
Exactly. The fastcall attribute wasn't supported before.
Thanks. Dmitry.
Sebastian Bergmann wrote:
Dmitry Stogov wrote:
The proposed patch for PHP improves the executor.
ZEND_GCC_VERSION = 3400 means = GCC 3.4.0, right?
--
PHP Internals - PHP Runtime Development Mailing List
I will do it before commit. Didn't have time to check Windows version yet.
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
Tuesday, June 10, 2008, 1:11:57 PM, you wrote:
Index: Zend/zend.h
===
RCS file:
Hi Christian,
I took a look into your patch and found it too difficult.
So I implemented another patch (attached) which is based on your ideas.
From user's level of view it does exactly the same except for lexical
variables definition. I don't use any new reserver word because every
new reserved
seem so bad, though.
- Federico Lebron
Dmitry Stogov wrote:
Hi Christian,
I took a look into your patch and found it too difficult.
So I implemented another patch (attached) which is based on your ideas.
From user's level of view it does exactly the same except for lexical
variables
Hi Christian,
I'm fine with your suggestion for lexical variables syntax, but I don't
know if we really need brackets around them. For now I changed syntax in
the following way.
$func = function ($x, $y) use $a, $b, $c {
}
According to segfault, I added a check that emits fatal error.
I don't
No it won't.
Dmitry.
Lars Strojny wrote:
Hi Dmitry, hi Christian,
Am Freitag, den 20.06.2008, 15:12 +0400 schrieb Dmitry Stogov:
$func = function ($x, $y) use $a, $b, $c {
}
Will lexical scoping work with normal (named) functions too?
function foo($x, $y) use $a, $b, $c {
}
cu
,
Am Freitag, den 20.06.2008, 16:19 +0400 schrieb Dmitry Stogov:
No it won't.
While I don't want to use it, it might be really confusing to our users
that it works different to closures (because the declaration of
functions and closures looks similar). Are there any internal
limitations why
I thought about use($this) too. :)
I'll try to implement it in the next version of the patch.
Thanks. Dmitry.
Alexander Wagner wrote:
On Friday 27 June 2008, Andi Gutmans wrote:
I lean towards the use(...) syntax.
Me too.
* I provided a patch variant that only stores $this if $this is
Thanks for static function () idea, it's much better and consistent
than function () use ($this). I think we should go this way.
Do you see any other issues with the patch?
Thanks. Dmitry.
Alexander Wagner wrote:
On Friday 27 June 2008, Andi Gutmans wrote:
I am not sure I like the idea of
Hi Lukas,
From my point of view the proposed closures concept is very consistent
and implementation doesn't complicate the engine at all. The code
without closures will work without any changes, but code with closures
(instead of eval() and create_function()) will work significant faster
as
Etienne Kneuss wrote:
2) late static binding
Etienne had some questions recently [5], which were met by criticism by Stas
[6]. However all others agreed with the change. So I guess we are solid here
too?
Yes, the only thing remaining is a tad of love from somebody with ZE
karma to commit
Lukas Kahwe Smith wrote:
2) phar extension
I guess we are pretty solid here?
We'll need to review the phar before release. It definitely must be in
5.3, but it should be improved, and this improvements may require some
changes in ZE.
For now packed phpMyAdmin is 4 times slower than unpacked
Absolutely agree.
I don't see any reason for 5.4. We don't plan any significant new features.
Thanks. Dmitry.
Derick Rethans wrote:
On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote:
On 02.07.2008, at 13:41, Christian Seiler wrote:
So as things look atm, closures will have to wait until then.
is not to postpone a feature freeze nor a final
release so it's really up to the release managers to decide on (1) and
(2).
Andi
-Original Message-
From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 03, 2008 12:27 AM
To: Lukas Kahwe Smith
Cc: Christian Seiler; php-dev List
I like the idea, and I think we don't need --enable-signals options.
BTW I'm not sure about committing it into 5.3. It's a question to RM(s).
Thanks. Dmitry.
Lucas Nealan wrote:
Hi Internals,
I am proposing the following RFC to improve signal handling in the Zend
Engine:
Hi Etienne,
I took a look into the patch and I don't like it all.
At first, I don't see any consistency there.
Why parent:: does forwarding but self::, static:: and class names don't?
At second, it's too complicated.
I would propose more consistent (from my point of view) and simpler patch.
5.2 didn't have static:: so it cannot be a BC break.
Thanks. Dmitry.
Derick Rethans wrote:
On Tue, 8 Jul 2008, Dmitry Stogov wrote:
I took a look into the patch and I don't like it all.
At first, I don't see any consistency there.
Why parent:: does forwarding but self::, static
. Dmitry.
Alexey Zakhlestin wrote:
On Tue, Jul 8, 2008 at 3:39 PM, Dmitry Stogov [EMAIL PROTECTED] wrote:
I took a look into the patch and I don't like it all.
At first, I don't see any consistency there.
Why parent:: does forwarding but self::, static:: and class names don't?
class names
method (with the same behavior).
Thanks. Dmitry.
Mike Lively wrote:
-- Forwarded message --
From: Mike Lively [EMAIL PROTECTED]
Date: Tue, Jul 8, 2008 at 6:23 AM
Subject: Re: [PHP-DEV] Re: parent:: forwarding
To: Dmitry Stogov [EMAIL PROTECTED]
On Tue, Jul 8, 2008
Hi Stas,
Note that called_scope is passed only to static methods of __parent__
class. I cannot imagine the use-case with intersecting LSBs in the same
class hierarchy. Could you please write the example.
Thanks. Dmitry.
Stanislav Malyshev wrote:
Hi!
Each call to static method of parent
Here, I'm half-agree with you. I would prefer full forwarding or not
forwarding at all.
Thanks. Dmitry.
Stanislav Malyshev wrote:
Hi!
With current proposal we can call the same static method from the same
context with different behavior parent::foo(), self::foo(), A::foo().
That's
I have Fatal error: Class 'Foo' not found which is expected.
Thanks. Dmitry.
Gergely Hodicska wrote:
Hi!
I think I found a bug but before posing it to bugs.php.net I would like
to ask your opinion. I think the it is not a planed behavior that some
errors doesn't bubble up from autoload,
Yes. I use instanceof_function() in the patch.
Thanks. Dmitry.
Stanislav Malyshev wrote:
Hi!
Note that called_scope is passed only to static methods of __parent__
class. I cannot imagine the use-case with intersecting LSBs in the same
class hierarchy. Could you please write the example.
The use can be used only as top-level statement.
Thanks. Dmitry.
Stefan Priebsch wrote:
Hi list,
I was playing around with namespaces and stumbled across this:
#!/home/steve/php5.3-200807070430/sapi/cli/php
?php
namespace Foo;
use Foo::Bar as Something;
class Bar { }
?
works fine,
1 - 100 of 1669 matches
Mail list logo
