[PHP-DEV] "finally" implementation improvement (behaviour must be the same)

Hi Laruence, Please take a look into the "finally" improvement patch. It resolves most the jump addresses at compile time and makes executor cleaner and faster. Attached the patch for PHP 5.5 (it requires zend_vm_execute.h regeneration). Thanks. Dmitry. diff --git a/Zend/zend_compile.c b/Zend/ze

Re: [PHP-DEV] RFC: ext/mysql deprecation

On Wed, Nov 21, 2012 at 10:56 AM, Kris Craig wrote: > On Wed, Nov 21, 2012 at 7:43 AM, Thomas Hruska wrote: >> On 11/12/2012 9:22 AM, Derick Rethans wrote: >> Why deprecate? Just because you like PDO doesn't mean everyone else will >> like it. Just because mysql_query() tends to create security

Re: [PHP-DEV] RFC: ext/mysql deprecation

On Wed, Nov 21, 2012 at 7:43 AM, Thomas Hruska wrote: > On 11/12/2012 9:22 AM, Derick Rethans wrote: > >> On Mon, 12 Nov 2012, Adam Harvey wrote: >> >> I've written an RFC to cover deprecating ext/mysql in PHP 5.5: >>> https://wiki.php.net/rfc/**mysql_deprecation

Re: [PHP-DEV] RFC: ext/mysql deprecation

> Users are lazy - binding each field separately is going to drive some to > resort to string concatenation, which will result in a situation nearly > identical to what you have already. You don't have to bind each field separately. I don't think I have ever done that with PDO . . . -- PHP Inter

Re: [PHP-DEV] RFC: ext/mysql deprecation

On 11/12/2012 9:22 AM, Derick Rethans wrote: On Mon, 12 Nov 2012, Adam Harvey wrote: I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I pres

[PHP-DEV] Eliminating stat() calls in opcode caches for include_once

Hi Pierre, To avoid stat() syscalls the opcode cache has to override zend_resolve_path() and zend_open_stream() callbacks with something like the following functions. static char* my_resolve_path(const char *filename, int filename_len TSRMLS_DC) { if ((EG(opline_ptr) && *EG(o

Re: [PHP-DEV] RFC: ext/mysql deprecation

On Wed, Nov 21, 2012 at 6:08 AM, Adam Harvey wrote: > We can't really unbundle and move to PECL without > deprecating first anyway > For the record, we did this with other extensions in the past. Technically mysql isn't any different, we only make a more careful approach because ext/mysql "just

Re: [PHP-DEV] RFC: ext/mysql deprecation

David Muir wrote: No other extension was deprecated before moving to PECL, so why the extra hurt for ext/mysql? As I've said before, it doesn't makes sense to have it throw notices while it's in core, then no longer throw notices once moved to PECL. If the plan is to drop it completely, and not m

Re: [PHP-DEV] Where did the _logo_ functions go?

On Wed, 2012-11-21 at 00:45 -0800, Stas Malyshev wrote: > Hi! > > > Actually, I'm going to retract my statement, and here's why: > > http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.php > > I think breaking this code is an advantage :) That's definitely not

Re: [PHP-DEV] RFC: ext/mysql deprecation

On Wed, 2012-11-21 at 16:02 +0800, Laruence wrote: > Hey: > sorry for top reply. > > but how about, move mysql to PECL instead of a E_DEPRECATED? Once ext/mysql is dropped from php-src we will add it to PECL and make a release there. Still it will be gone for many users. johannes -- PHP

Re: [PHP-DEV] Re: Expose zend_message_dispatcher_p

Hi Pierre, Sorry, but I'm really busy to support APC. I may explain the working solution once again, but according to coding I would prefer to spend my "free" time looking into php-5.5 problems and possible new performance improvements. Thanks. Dmitry. On Wed, Nov 21, 2012 at 12:25 PM, Pierre J

Re: [PHP-DEV] Where did the _logo_ functions go?

Hi! > Actually, I'm going to retract my statement, and here's why: > http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.php I think breaking this code is an advantage :) That's definitely not how php_logo_guid should be used and using it as a secure salt make

Re: [PHP-DEV] Where did the _logo_ functions go?

Hi! > It's the inconsistency that bothers me. I think a rule like "Never remove > a ~function without it first emitting E_DEPRECATED" can be followed 100% > of the time, and don't see this as a bureaucratic rule but instead think > this consistency would make PHP better. I guess that's where we

Re: [PHP-DEV] Re: Expose zend_message_dispatcher_p

hi Dmitry, On Wed, Nov 21, 2012 at 9:14 AM, Dmitry Stogov wrote: > Great! I always glad to help. And I would avoid "tricky" solutions as much > as possible. :) > > Even 2 minutes TTL is going to save few thousands syscalls, in case your > site is really > high loaded, and it make no sense to care

[PHP-DEV] Re: Expose zend_message_dispatcher_p

Great! I always glad to help. And I would avoid "tricky" solutions as much as possible. :) Even 2 minutes TTL is going to save few thousands syscalls, in case your site is really high loaded, and it make no sense to care about "last syscall optimization" if you system is mostly idle. BTW: I'm not

Re: [PHP-DEV] RFC: ext/mysql deprecation

Hey: sorry for top reply. but how about, move mysql to PECL instead of a E_DEPRECATED? thanks On Fri, Nov 16, 2012 at 2:30 PM, Johannes Schlüter wrote: > On Nov 16, 2012, at 3:16, David Muir wrote: > >> The point is, an extension should never be throwing deprecation warnings >> for a plann