On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui xinche...@zend.com wrote:
Hey:
On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I'm working on call/return sequence optimization. As part of this work
I'm
minimizing the size of call frame (zend_execute_data) and
On 28 November 2014 06:51:56 GMT, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
We already have the single-byte versions: chr() and ord(). It's been
on
Not really. chr(0xA1) is a byte with value 0xA1. The function I propose
would instead produce \xC2\xA1.
Ah, yes, so it would. According
I see no problems with these patches.
If all tests on PPC are passed, then they should be accepted.
The patches won't affect other architectures.
Anybody tested?
Thanks. Dmitry.
On Thu, Nov 27, 2014 at 3:39 PM, Gustavo Frederico Temple Pedrosa
gustavo.pedr...@eldorado.org.br wrote:
Hi,
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
This solution may be implemented efficiently and consistently.
It also must be enough for 99% use cases.
On 28 Nov 2014, at 09:31, Dmitry Stogov dmi...@zend.com wrote:
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
No, it shouldn't match
Andrea Faulds wrote on 28/11/2014 10:57:
On 28 Nov 2014, at 09:31, Dmitry Stogov dmi...@zend.com wrote:
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 28/11/2014 08:50, Remi Collet a écrit :
5.6.4RC1 already built in Fedora rawhide, which means Koschei [1]
will run (slowly, in the next days) a scratch rebuild of all the
PHP stack, with the test suites (various libraries, phpunit,
symfony,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 28/11/2014 10:10, Dmitry Stogov a écrit :
I see no problems with these patches. If all tests on PPC are
passed, then they should be accepted. The patches won't affect
other architectures.
Anybody tested?
I should be able to run some scratch
I didn't get what you mean.
parameters are invariant, invariance, which is safe for both and it
shouldn't match parameters are contradictory.
Thanks. Dmitry.
On Fri, Nov 28, 2014 at 1:57 PM, Andrea Faulds a...@ajf.me wrote:
On 28 Nov 2014, at 09:31, Dmitry Stogov dmi...@zend.com wrote:
On 28 Nov 2014, at 12:27, Dmitry Stogov dmi...@zend.com wrote:
I didn't get what you mean.
parameters are invariant, invariance, which is safe for both and it
shouldn't match parameters are contradictory.
Well, that’s why I said “the exception is invariance”.
--
Andrea Faulds
Hello,
PHP 5.5.20RC1 is available for testing.
You can download it from
http://downloads.php.net/jpauli/
The Windows binaries are available at http://windows.php.net/qa/
This release contains a number of bugfixes, many of them about the PHP-FPM
IPV6 support feature.
We'd like to point you to
2014-11-28 2:13 GMT+01:00 Bostjan Skufca bost...@a2o.si:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a function
that would return an object ID. A function called
On Fri, Nov 28, 2014 at 2:14 PM, Sebastian Krebs krebs@gmail.com
wrote:
2014-11-28 2:13 GMT+01:00 Bostjan Skufca bost...@a2o.si:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger
On Friday 28 November 2014 14:51:55 Ferenc Kovacs wrote:
I also used spl_object_hash() in the past when traversing/custom
serializing object structures which can have infinite recursions
between
objects, but even that could be simply solved by storing the already
traversed objects in an
Ferenc Kovacs wrote on 28/11/2014 13:51:
On Fri, Nov 28, 2014 at 2:14 PM, Sebastian Krebs krebs@gmail.com
wrote:
2014-11-28 2:13 GMT+01:00 Bostjan Skufca bost...@a2o.si:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I
On Fri, Nov 28, 2014 at 3:02 PM, Patrick Schaaf p...@bof.de wrote:
On Friday 28 November 2014 14:51:55 Ferenc Kovacs wrote:
I also used spl_object_hash() in the past when traversing/custom
serializing object structures which can have infinite recursions between
objects, but even
The vote is now closed; The RFC was accepted 34 to 2.
Zeev
*From:* Zeev Suraski [mailto:z...@zend.com]
*Sent:* Thursday, November 27, 2014 12:09 PM
*To:* PHP internals (internals@lists.php.net)
*Subject:* RE: [VOTE] [RFC] PHP 7.0 timeline
All,
The vote will end tomorrow at noon GMT –
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
Realistically there isn't much code to share, especially since the two
structures are incompatible.
On Fri, Nov 28, 2014 at 5:39 PM, Patrick Schaaf p...@bof.de wrote:
Am 28.11.2014 15:46 schrieb Ferenc Kovacs tyr...@gmail.com:
from a quick test using spl_object_hash seems to be the slower with big
number of elements in haystack.
Your test only does the is-it-known test once. For an
On Tue, Nov 18, 2014 at 9:34 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
The vote for https://wiki.php.net/rfc/secure_unserialize has been
completed (actually, should be last week but I was busy, sorry for the
delay) and the RFC is accepted 17 votes for to 6 votes against.
Now,
Hi Levi,
if you remember, in my patch return_type was actually stored in
arg_info[-1].
it was mainly done for unification and to allow return type hinting for
internal functions (they already use arg_info[-1])
So the strictures may be compatible.
See
On Mon, Nov 10, 2014 at 12:02 PM, Johannes Schlüter
johan...@schlueters.de wrote:
On Thu, 2014-11-06 at 19:52 -0500, Peter Wolanin wrote:
Suggested solution: add a PDO attribute that could be set on a
connection or a driver option for PDO::prepare to enforce the limit
of
a
On 28 November 2014 at 04:10, reeze re...@php.net wrote:
Won't `$obj1 === $obj2` work for you ?
This works if you have two objects which are easily accessible in the same
scope.
Not that it can not be done this way, but it may require jumping through
hoops to get two object references into
On 28 November 2014 at 07:04, Joe Watkins pthre...@pthreads.org wrote:
I don't think so, there is talk of removing object handles in 7.
Could you point me to a discussion about this? Tnx.
Even if we intended to keep object handles, this leaks implementation
details that we
PHP has evolved a lot in recent years but we still can't have a static and
a nonstatic function with the same name:
class A {
function bla() { echo 'normal'; }
static function bla() { echo 'static'; }
}
A::bla();
## ERROR: Cannot redeclare A::bla()
And also PHP supports calling
Am 28.11.2014 20:23 schrieb Bostjan Skufca bost...@a2o.si:
On 28 November 2014 at 04:10, reeze re...@php.net wrote:
Won't `$obj1 === $obj2` work for you ?
Think of it like this:
- in file bootstrap.php I see this object initialized and passed somewhere
- in file view.phtml I receive the
Please review the patch https://gist.github.com/dstogov/47a39aff37f0a6441ea0
Instead of duplicating logic in two places I'd rather grab the
relevant data first, then do the logic once:
zend_string *class_name;
if (fe-type == ZEND_INTERNAL_FUNCTION) {
class_name = zend_string_init(
Won't `$obj1 === $obj2` work for you ?
This works if you have two objects which are easily accessible in the same
scope.
Not that it can not be done this way, but it may require jumping through
hoops to get two object references into the common scope where you can
compare them.
If you
Over 20 days since the last comment and seems there is a consensus about
accept it to the next 5.6 patch version, right? Can it be merged?
Juan Basso
On Wed, Nov 5, 2014 at 9:37 PM, Juan Basso jrba...@gmail.com wrote:
After the comments I see about deprecating the constant. Makes completely
Please read :
http://grokbase.com/t/php/php-internals/14acs23cpe/disallow-non-static-method-calls-with-self-static-in-php-7#20141026ct1np9k82bte2m9k9rtmq1c2jr
Am 28.11.2014 um 20:29 schrieb Carlos Rodrigues:
PHP has evolved a lot in recent years but we still can't have a static and
a
2014.11.28. 9:24 ezt írta (Dmitry Stogov dmi...@zend.com):
On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui xinche...@zend.com wrote:
Hey:
On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I'm working on call/return sequence optimization. As part of this work
Am 28.11.2014 um 21:21 schrieb Levi Morrison:
Won't `$obj1 === $obj2` work for you ?
This works if you have two objects which are easily accessible in the same
scope.
Not that it can not be done this way, but it may require jumping through
hoops to get two object references into the common
Hi!
It confuses programmers that came from other languages, prevent APIs from
having meaningful names on static methods and have no other benefit than
supporting PHP 4 code.
I think this notion of confuses programmers sometimes goes too far,
and this is one of the examples. PHP prides itself
Hi!
Sorry, I missed this thread back when you posted.
Personally I'm a bit hesitant about this change.
Do we already have something additional/upcoming features which could be
a good fit to lump together with allowed_classes?
There was talk about limiting depth or breadth to prevent hash DoS
Hi!
I should be able to run some scratch build next week
That'd be great. I thought about merging them but since I don't have any
ppc64 hardware around I was not sure, but if you have some it'd be great.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing
Hi!
this is a long spoken topic which is now embodied in
https://wiki.php.net/rfc/native-tls . A preliminary implementation is
there as well, thus we can discuss it.
This sounds great! \o/
I understand there's no practical performance impact? If so, code
simplification looks like a real win.
On 28/11/2014 21:06, Marc Bennewitz wrote:
But to have a unique ID for objects sound like a very good idea and
would solve the object as array key issue.
I'm sure it's not as simple as the function prototype explained in
this thread previously.
Indeed. Fortunately, we already have one: it's
On 28/11/2014 01:13, Bostjan Skufca wrote:
A function called spl_object_hash() exists,
but it returns identical hashes for equal objects.
In case it's been lost in the noise, no it doesn't.
From http://php.net/spl_object_hash
Return Values
A string that is unique for each currently
On 22 Sep 2014, at 23:42, Andrea Faulds a...@ajf.me wrote:
Good evening again,
Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow
Thoughts appreciated, as is help with the patch, though I can probably manage
on my own.
Thanks!
At long last, we are at the point where I
On Fri, Nov 28, 2014 at 1:21 PM, Juan Basso jrba...@gmail.com wrote:
Over 20 days since the last comment and seems there is a consensus about
accept it to the next 5.6 patch version, right? Can it be merged?
After reading over the thread, there doesn't seem to be a consensus; I
am not sure how
Levi,
From what I understood it is a consensus to apply the change to PHP 5.6 as
it is (new flag and disabled by default). There is no consensus about how
should be in PHP 7, but was agreed to discuss that later.
On Fri, Nov 28, 2014 at 11:39 PM, Levi Morrison le...@php.net wrote:
On Fri, Nov
41 matches
Mail list logo
