Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

On 01/30/2013 06:47 AM, Zeev Suraski wrote: This is the kind of info the RFC (and then user doc) should have. I updated the RFC with two extra sections - 'what's an opcode cache', This section extremely general and doesn't explain what the expected feature set might look like. I'm not aski

Re: [PHP-DEV] rfc:foreach-non-scalar-keys

> I'm not sure how I came to that conclusion - did the description change > since I looked at it? Maybe a little bit but not very much, if at all. > I guess the title "foreach-non-scalar-keys" may have thrown me off - so > this isn't about arrays, or really even about foreach, but about the > Ite

Re: [PHP-DEV] rfc:foreach-non-scalar-keys

On Fri, Feb 1, 2013 at 1:05 AM, Rasmus Schultz wrote: > I'm not sure how I came to that conclusion - did the description change > since I looked at it? > > I guess the title "foreach-non-scalar-keys" may have thrown me off - so > this isn't about arrays, or really even about foreach, but about th

Re: [PHP-DEV] rfc:foreach-non-scalar-keys

I'm not sure how I came to that conclusion - did the description change since I looked at it? I guess the title "foreach-non-scalar-keys" may have thrown me off - so this isn't about arrays, or really even about foreach, but about the Iterator interface. I'm not against that at all. I would sugge

RE: [PHP-DEV] [Reflection] Improve logic of ReflectionMethod->invokeArgs() for static methods

Maybe I can help explain a good example on were this is useful as I also suggested this improvement and created the patch for it: (http://bugs.php.net/bug.php?id=62113) This is actually something I am using in one of my primary projects as a framework (this example shows the concept not the act

[PHP-DEV] Re: VCS Account Request: alejosimon

VCS Account Rejected: alejosimon rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

On 01/31/2013 01:22 AM, Terry Ellison wrote: > On 30/01/13 00:54, Rasmus Lerdorf wrote: >> On 01/29/2013 04:47 PM, Stas Malyshev wrote: >>> Hi! >>> which shows the dreaded zend_optimizerplus.inherited_hack which mimics APC's autofilter hack. I'd love to get rid of this particular bit of >

[PHP-DEV] PHP 5.3.22RC1 and 5.4.12RC1 Released for Testing!

Hi! We've released PHP 5.3.22RC1 and 5.4.12RC1 which can be found here: 5.3.20RC1: http://downloads.php.net/johannes/php-5.3.22RC1.tar.bz2 http://downloads.php.net/johannes/php-5.3.22RC1.tar.gz 5.4.10RC1: http://downloads.php.net/stas/php-5.4.12RC1.tar.bz2 http://downloads.php.

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

On 31/01/13 15:35, Gustavo Lopes wrote: On Thu, 31 Jan 2013 14:55:26 +0100, Ivan Enderlin @ Hoa wrote: I'm not sure what you mean here. Each time you open a php://memory stream, you're working on a new "bucket", right? Yes exact. My bad. But my proposal still persist. Identifying php://memo

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

On Thu, 31 Jan 2013 14:55:26 +0100, Ivan Enderlin @ Hoa wrote: I'm not sure what you mean here. Each time you open a php://memory stream, you're working on a new "bucket", right? Yes exact. My bad. But my proposal still persist. Identifying php://memory buckets would be nice to retrieve th

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

On 31/01/13 12:18, Gustavo Lopes wrote: On Thu, 31 Jan 2013 10:37:53 +0100, Ivan Enderlin @ Hoa wrote: The php://memory, and its respectful sibling php://temp, appear very useful when we need to compute streams on-the-fly. They offer a lot of services, like avoiding HDD accesses, increasing s

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)

> > The fact that this use of PHP is documented in the manual as a feature > www.php.net/manual/en/**language.oop5.basic.php > > And mentions that it will elicit a E_STRICT error - does not indicate that > it would be DEPRECATED, I'm assuming th

RE: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

>On 31/01/13 12:00, Sebastian Krebs wrote: >> 2013/1/31 Chris Wright >> I propose the following syntax: php://memory/ php://temp//maxmemory: >>> I would very much like to see this as well. >>> >>> Would this also allow you to open multiple pointers to the same bucket?

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

On Thu, 31 Jan 2013 10:37:53 +0100, Ivan Enderlin @ Hoa wrote: The php://memory, and its respectful sibling php://temp, appear very useful when we need to compute streams on-the-fly. They offer a lot of services, like avoiding HDD accesses, increasing speed... and through a straightforward AP

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

2013/1/31 Ivan Enderlin @ Hoa > > On 31/01/13 12:00, Sebastian Krebs wrote: > >> 2013/1/31 Chris Wright >> >> I propose the following syntax: php://memory/ php://temp//maxmemory:<**size> >>> I would very much like to see this as well. >>> >>> Would this also allow

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

On 31/01/13 12:00, Sebastian Krebs wrote: 2013/1/31 Chris Wright I propose the following syntax: php://memory/ php://temp//maxmemory: I would very much like to see this as well. Would this also allow you to open multiple pointers to the same bucket? For example would this work?

Re: [PHP-DEV] Re: [lists.php] [PHP-DEV] Proposal: php://memory/ (& ://temp/)

On 31/01/13 11:12, ALeX wrote: Hi Ivan, php://memory/ php://temp//maxmemory: It's not that hard to write such an function in php. (http://www.php.net/manual/en/function.stream-wrapper-register.php). Did I say it was hard? This is quite obvious to write such a wrapper, but PHP has ph

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

2013/1/31 Chris Wright > > I propose the following syntax: > > > > php://memory/ > > php://temp//maxmemory: > > I would very much like to see this as well. > > Would this also allow you to open multiple pointers to the same bucket? > > For example would this work? > > > $fp = fopen('ph

RE: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

> I propose the following syntax: > > php://memory/ > php://temp//maxmemory: I would very much like to see this as well. Would this also allow you to open multiple pointers to the same bucket? For example would this work? http://www.php.net/unsub.php

[PHP-DEV] Re: [lists.php] [PHP-DEV] Proposal: php://memory/ (& ://temp/)

Hi Ivan, > php://memory/ > php://temp//maxmemory: It's not that hard to write such an function in php. (http://www.php.net/manual/en/function.stream-wrapper-register.php). I even once wrote an handler like "string://data-right-here" which allows to read (only) the "data-right-here" as a

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

On 31/01/13 11:00, Attila Bukor wrote: Hi Ivan, Hi Attila, I've never actually worked with them, but it seems nice. However, we should make redirect php://memory and php://temp to php://memory/default and php://temp/default respectively to avoid break stuff imho. Obviously yes! Sorry, I miss

Re: [PHP-DEV] Proposal: php://memory/ (& ://temp/)

Hi Ivan, I've never actually worked with them, but it seems nice. However, we should make redirect php://memory and php://temp to php://memory/default and php://temp/default respectively to avoid break stuff imho. Cheers, r1pp3rj4ck On Thu, Jan 31, 2013 at 10:37 AM, Ivan Enderlin @ Hoa < ivan.e

[PHP-DEV] Proposal: php://memory/ (& ://temp/)

Hi internals, The php://memory, and its respectful sibling php://temp, appear very useful when we need to compute streams on-the-fly. They offer a lot of services, like avoiding HDD accesses, increasing speed... and through a straightforward API /à la/ PHP, e.g. fopen('php://memory', 'r+'). H

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

On 30/01/13 00:54, Rasmus Lerdorf wrote: On 01/29/2013 04:47 PM, Stas Malyshev wrote: Hi! which shows the dreaded zend_optimizerplus.inherited_hack which mimics APC's autofilter hack. I'd love to get rid of this particular bit of confusion/code complexity on the integration. Ohh, this one. II

Re: [PHP-DEV] Re: Deprecate and remove calls from incompatible context

Todd Ruth wrote: Could there be a compromise that would allow us evildoers to continue in our evil ways without identifying and changing every use? Perhaps "implements allowStaticCallsFromIncompatibleContexts" or somesuch? I can imagine replacing every "class ..." with "class ... implements ...