Hi Dmitry,
I was doing some code review of ext/standard/array.c and have recognized some
potential for a few performance improvements:
=== ARRAY_SLICE(..., preserve_keys=false) ===
array_slice() can always construct a packed array if preserve_keys is false,
restricting it to inputs with
Hey:
On Tue, Jan 20, 2015 at 4:30 PM, Benjamin Coutu ben.co...@zeyos.com wrote:
Hi Dmitry,
I was doing some code review of ext/standard/array.c and have recognized some
potential for a few performance improvements:
=== ARRAY_SLICE(..., preserve_keys=false) ===
array_slice() can always
Hey:
On Tue, Jan 20, 2015 at 5:06 PM, Benjamin Coutu ben.co...@zeyos.com wrote:
Hi,
Regarding ARRAY_SLICE(..., preserve_keys=false) my whole point was that the
check for non-numeric key inputs is not necessary if preserve_keys is false.
It should basically be analogue to array_values(), but
Sorry, your right of course as not preserving keys only applies to numeric
indices.
== Original ==
From: Xinchen Hui xinche...@zend.com
To: Benjamin Coutu ben.co...@zeyos.com
Date: Tue, 20 Jan 2015 10:13:04 +0100
Subject: Re: [PHP-DEV] Re: Improvements to array.c code base
Hi Dmitry,
On Tue, January 20, 2015 06:08, Dmitry Stogov wrote:
Hi Anatol,
Despite of this, we also have few extensions not converted to PHP7 yet -
https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet
3 of them related to MSSQL, 2 to Oracle and one to Interbase. the last
2015-01-20 6:35 GMT+01:00 Pierre Joye pierre@gmail.com:
On Tue, Jan 20, 2015 at 6:15 AM, Andrea Faulds a...@ajf.me wrote:
Hi Mike,
On 20 Jan 2015, at 03:30, Mike Willbanks pen...@gmail.com wrote:
I am very familiar with the in operator. However, the implementation
would be incomplete
Hi,
Regarding ARRAY_SLICE(..., preserve_keys=false) my whole point was that the
check for non-numeric key inputs is not necessary if preserve_keys is false.
It should basically be analogue to array_values(), but of course respecting the
offset and length boundaries.
One question regarding
Hey:
On Tue, Jan 20, 2015 at 5:21 PM, Benjamin Coutu ben.co...@zeyos.com wrote:
Sorry, your right of course as not preserving keys only applies to numeric
indices.
np, advise and questions on performance are always welcome :)
thanks
== Original ==
From: Xinchen Hui
On Tue, Jan 20, 2015 at 6:55 AM, Andrea Faulds a...@ajf.me wrote:
Hi again,
On 19 Jan 2015, at 10:28, Andrea Faulds a...@ajf.me wrote:
On 19 Jan 2015, at 10:24, Dmitry Stogov dmi...@zend.com wrote:
There are also a number of tests started to fail since last Friday
testing integer
Hi,
On Tue, January 20, 2015 06:26, Pierre Joye wrote:
On Tue, Jan 20, 2015 at 6:08 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Anatol,
Despite of this, we also have few extensions not converted to PHP7 yet
-
https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet
3 of them
Hello Pierre, Andrea and Niklas,
On Mon, Jan 19, 2015 at 11:35 PM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jan 20, 2015 at 6:15 AM, Andrea Faulds a...@ajf.me wrote:
On 20 Jan 2015, at 03:30, Mike Willbanks pen...@gmail.com wrote:
I am very familiar with the in operator. However,
Hi,
Mike, the use of in as `for ($var in $object) {};` could be the
subject for another distinct RFC since it's doing something different
from the original proposal:
var_dump(PHP in [PHP, C, Java]); // true
2015-01-20 10:41 GMT-03:00 Mike Willbanks pen...@gmail.com:
Hello Pierre, Andrea and
Hello,
On Tue, Jan 20, 2015 at 7:47 AM, Marcio Almada marcio.w...@gmail.com
wrote:
Hi,
Mike, the use of in as `for ($var in $object) {};` could be the
subject for another distinct RFC since it's doing something different
from the original proposal:
var_dump(PHP in [PHP, C, Java]); // true
Hey:
On Tue, Jan 20, 2015 at 9:43 PM, Julien Pauli jpa...@php.net wrote:
Hi !
Here is a PR removing our old PHP4 zend_module_entry structure
compatibility.
I'm about to merge it against master, if no-one objects.
https://github.com/php/php-src/pull/988
I see no problem at all
thanks
Mike,
Also FYI - in the future please try not to top post and instead post under
where you are commenting as it makes it more difficult for
people coming later to the thread to see the scope of the conversation.
Thanks for the tip! I read to do not top post on the guidelines but
had no clue
Hi !
Here is a PR removing our old PHP4 zend_module_entry structure
compatibility.
I'm about to merge it against master, if no-one objects.
https://github.com/php/php-src/pull/988
Julien.P
Rowan Collins wrote in message news:54bd4d98.80...@gmail.com...
Tony Marston wrote on 19/01/2015 16:24:
Rowan Collins wrote in message news:54bd240a.7050...@gmail.com...
Tony Marston wrote on 19/01/2015 15:01:
The aim should be to eliminate customer grievances as much as possible
and not
Mike,
Back to the subject,:
It is indeed different but ever so slightly, a for loop in this case cannot
handle a single argument of true and would cause a parse error.
Therefore for (PHP in [PHP, C, Java]) could be handled differently.
Again, my main point is that due to other languages
Mike Willbanks wrote on 20/01/2015 03:30:
I am very familiar with the in operator. However, the implementation
would be incomplete without handling loops via the in operator. Many
people when seeing an in operator also think of JavaScript. In that case
the in operator iterates over
On Tue, Jan 20, 2015 at 8:26 AM, Tony Marston tonymars...@hotmail.com
wrote:
@tony: What's really interesting is that all this time you've spent arguing
could have been used to update your code and make this no longer an issue
for you.
@everyone: Would an RFC be necessary to update the PHP
Am 20.01.2015 um 16:42 schrieb Rowan Collins:
Given the ability to write foreach ( $foo as $key = $value ), I'm not
sure adding a variant syntax of for ( $key in $foo ) has that much value
for PHP.
I totally agree with you here.
The only real reason why Javascript has a for-in operation that
On 20 Jan 2015, at 21:00, Joshua Rogers g...@internot.info wrote:
Respective variables are unsigned and cannot be 0.
Did you mean to use “==“ in comparisons?
---
sapi/litespeed/lsapilib.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
On 21/01/15 05:32, Alexey Zakhlestin wrote:
On 20 Jan 2015, at 21:00, Joshua Rogers g...@internot.info wrote:
Respective variables are unsigned and cannot be 0.
Did you mean to use “==“ in comparisons?
Yes.
Fixed it in the pull request:
On 20 January 2015 at 07:09, Kristopher kristopherwil...@gmail.com wrote:
@everyone: Would an RFC be necessary to update the PHP manual to actually
recommend the PHP 5 constructors and recommend against using the PHP 4
style constructors, using very explicit language? If not, should this
Internals,
Last year I fixed the behavior of closures in a few regards, which
were included in PHP 5.5.14 and 5.6 (unsure on exact version):
- Static closures properly use late-static binding on `static::`
calls from inside static methods.
- Non-static closures in static methods are
Respective variables are unsigned and cannot be 0.
---
sapi/litespeed/lsapilib.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sapi/litespeed/lsapilib.c b/sapi/litespeed/lsapilib.c
index 2e60701..20279d1 100644
--- a/sapi/litespeed/lsapilib.c
+++
Here are the issues with master (008 is rounding issue so you can ignore
for the moment)
FAILED TEST SUMMARY
-
InterBase: BLOB test [ext/interbase/tests/004.phpt]
InterBase: transactions [ext/interbase/tests/005.phpt]
InterBase:
Am 20.01.2015 um 18:58 schrieb Levi Morrison:
Internals,
Last year I fixed the behavior of closures in a few regards, which
were included in PHP 5.5.14 and 5.6 (unsure on exact version):
- Static closures properly use late-static binding on `static::`
calls from inside static methods.
-
Ok, in that case I'll take back some of my words. Would you please
remove my name from the maintainers if it is still there? I don't expect
to be able to contribute or fix anything anymore.
-- Jouni Ahto
On 01/20/2015 09:33 PM, marius adrian popa wrote:
interbase extension is maintained and
Am 19.01.2015 um 19:48 schrieb Adam Harvey:
On 17 January 2015 at 18:04, Andrea Faulds a...@ajf.me wrote:
For consistency with list(), we could also just put nothing:
foo($bar, , $baz);
Which is like:
list($bar, , $baz) = $arr;
Thoughts?
That was Stas's original, original
Hi!
@Stas: Any news on using default on inheritance ?
Not yet, probably will look into this towards next weekend.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 2015-01-19 at 18:07 +0100, Anatol Belski wrote:
Hi,
I think the research on
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far enough
to be discussed.
So far I only could not test sapi/nsapi because it needs a SunOs/IPlanet.
But independent from that, it'd make
De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part
I'm happy to update the manual, but I think I'd want more of a
consensus (not necessarily a formal RFC, but at least a straw poll)
for soft deprecation (to reuse the term we used for mysql_* before
it started generating
On Tue, Jan 20, 2015 at 1:59 PM, Adam Harvey ahar...@php.net wrote:
On 20 January 2015 at 12:54, Marc Bennewitz dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid for for
direct variable calls:
- string MyClass::staticFunc
- string self::staticFunc
-
On 20/01/2015 20:09, Marc Bennewitz wrote:
Am 19.01.2015 um 19:48 schrieb Adam Harvey:
On 17 January 2015 at 18:04, Andrea Faulds a...@ajf.me wrote:
For consistency with list(), we could also just put nothing:
foo($bar, , $baz);
Which is like:
list($bar, , $baz) = $arr;
In testing PHP7 beyond just the default extensions, I am noticing that
ext/imap is segfaulting on almost every test. I tracked it down to this
code in ext/imap/php_imap.c:
/* {{{ imap_do_open
*/
static void php_imap_do_open(INTERNAL_FUNCTION_PARAMETERS, int persistent)
{
char *mailbox,
Hi All!
Occasionally, in various discussions, waiting for the next major release
is described as maybe another 10 years, but I think that's a very
pessimistic prediction. It's more reasonable to expect it in half that
time, around 2020, and that is what we should base our decisions on.
The
On 01/20/2015 01:54 PM, Rasmus Lerdorf wrote:
Things I have tried. changed it from p to s and also from p to S
and using a zend_string * instead. In both cases I got the same bogus
address back from zpp. Right now I am trying to make sense of the
generated assembly differences, but it is slow
Hi!
So, I guess the lesson is that we need to be careful when we migrate
extensions to PHP 7. Passing ints instead of size_t string length params
to zpp can cause extreme weirdness and we should go through all our
bundled extensions and make sure things that are still using s have
all been
On 20 January 2015 at 20:09, Marc Bennewitz dev@mabe.berlin wrote:
Pros Cons
_Named Parameters:_
pro:
- readability (If caller is not required to call as assoc array)
- not an option for inheritance
con:
- paramter skipping is a side product with possible edge cases
-
Hey Marc,
On 20 Jan 2015, at 20:54, Marc Bennewitz dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid for for
direct variable calls:
- string MyClass::staticFunc
- string self::staticFunc
- string static::staticFunc
- string parent::func
- string
On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string MyClass::staticFunc
- string self::staticFunc
- string static::staticFunc
- string parent::func
- string
Hi,
On Tue, 2015-01-20 at 06:36 +0100, Kevin Ingwersen (Ingwie Phoenix)
wrote:
Today I have started to concept a new SAPI which I have wanted to do
in quite a while now. To learn more, here is a README:
https://github.com/IngwiePhoenix/php-jrp/blob/master/README.md
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
Given the ability to write foreach ( $foo as $key = $value ), I'm not
sure adding a variant syntax of for ( $key in $foo ) has that much value
for PHP.
+1. Useless and ambiguous.
--
PHP Internals - PHP Runtime Development Mailing List
Hey Adam,
On 20 Jan 2015, at 20:59, Adam Harvey ahar...@php.net wrote:
On 20 January 2015 at 12:54, Marc Bennewitz dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid for for
direct variable calls:
- string MyClass::staticFunc
- string
On 01/20/2015 02:46 PM, Stanislav Malyshev wrote:
Hi!
So, I guess the lesson is that we need to be careful when we migrate
extensions to PHP 7. Passing ints instead of size_t string length params
to zpp can cause extreme weirdness and we should go through all our
bundled extensions and make
Hi Rowan,
On Mon, Jan 19, 2015 at 12:05 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 18 January 2015 at 01:01, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Sat, Jan 17, 2015 at 8:43 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
My concern is, at what cost? Given how
In userland it is sometimes necessary to extend PHP's notices/warnings with
additional information (e.g. username from session, stack trace, etc.)
I'm proposing to enable error_handler callback parameters to be passed by
reference to be able to append additional data to error messages.
Example:
Occasionally, in various discussions, waiting for the next major release is
described as maybe another 10 years, but I think that's a very pessimistic
prediction. It's more reasonable to expect it in half that time, around
2020, and that is what we should base our decisions on.
I am fairly
On Tue, Jan 20, 2015 at 8:33 PM, marius adrian popa map...@gmail.com wrote:
interbase extension is maintained and at least i will rename to firebird
after php7 api conversion is over (a few blob/events tests don't pass after
the big api changes )
There are two questions, maintained or dead
On 20 January 2015 at 12:54, Marc Bennewitz dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid for for
direct variable calls:
- string MyClass::staticFunc
- string self::staticFunc
- string static::staticFunc
- string parent::func
- string
On 20.01.2015 22:46, Nikita Popov wrote:
On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid
for for direct variable calls:
- string MyClass::staticFunc
- string
On Tue, 2015-01-20 at 14:13 -0800, Rasmus Lerdorf wrote:
So, I guess the lesson is that we need to be careful when we migrate
extensions to PHP 7. Passing ints instead of size_t string length params
to zpp can cause extreme weirdness and we should go through all our
bundled extensions and make
---
ext/mbstring/mbstring.c | 8
ext/reflection/php_reflection.c | 1 +
main/main.c | 1 +
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/ext/mbstring/mbstring.c b/ext/mbstring/mbstring.c
index 7f2209f..504a5e6 100644
---
On 20/01/15 19:33, marius adrian popa wrote:
pdo_firebird is ok but doesn't cover the firebird api so we still need them
both
And I would add to that - PDO does not allow cross database transactions
which is another area interbase/firebird can utilise. It's particularly
useful archiving
On 21/01/15 07:28, Joshua Rogers wrote:
---
ext/mbstring/mbstring.c | 8
ext/reflection/php_reflection.c | 1 +
main/main.c | 1 +
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/ext/mbstring/mbstring.c b/ext/mbstring/mbstring.c
index
valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string MyClass::staticFunc
- string self::staticFunc
- string static::staticFunc
- string parent::func
- string parent::staticFunc
see http://3v4l.org/1oSO3
Thoughts ?
--
PHP Internals - PHP
Hi!
Agree, but maybe a RFC for in operator and a follow up RFC to allow
in on for context could be a win/win here as long as one feature
doesn't block each other?
The problem is in is not just for. The problem is this: when you say
$foo in $bar, is $foo a value or a key? In many languages,
interbase extension is maintained and at least i will rename to firebird
after php7 api conversion is over (a few blob/events tests don't pass after
the big api changes )
Dmitry Stogov https://plus.google.com/u/0/114466583226539257267?prsrc=4 added
some patches but we need to fix the zend engine
#1 and #2 may be considered to be genuine improvements by the user
community, but #3 most certainly will not. It does not matter how you
try to dress it up, forcing your end users to jump through hoops before
they can upgrade is a customer relations disaster.
PHP and other scripting
At least one mail didn't bounce.
The situation with Interbase extension, in my opinion: it's dead meat
and should most probably be just removed. Nobody is currently, to my
knowledge, maintaining it. Even the birth of said extension was a bit
troublesome, when I had just for the fun of it
61 matches
Mail list logo
