Hi Andi,
We already discussed most of semantic changes introduced in AST patch.
Most of them came from another approved RFC
https://wiki.php.net/rfc/uniform_variable_syntax
Thanks. Dmitry.
On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans wrote:
> Hi Nikita,
>
> I reviewed the AST RFC on my way t
The patch looks good and seems to contain the necessary opcache changes.
I'm not sure if you really need zend_return_hint.used and
zend_return_hint.class_name_type (may be I just didn't analyze the patch
deep enough).
You may support "self" by setting zend_return_hint.class_name =
GC(actrive_cla
On Mon, Aug 18, 2014 at 1:43 PM, Dmitry Stogov wrote:
> Hi Levi,
>
> The implementation is really not a problem. It must be quite simple and I
> may take care about it.
> The problem that we can't come to agreement on scalar type hinting for years
> :(
>
> Thanks. Dmitry.
>
>
> On Mon, Aug 18, 201
On 08/17/2014 03:55 PM, Chris Wright wrote:
On 17 August 2014 11:49, David Zuelke wrote:
That does not make any sense; applications could accept XML, CSV or whatever
else just as well.
The original proposal is not very useful. $_GET contains parsed query string
info, $_POST contains parsed H
Hey:
thanks very much for testing this.
then seems I should not commit this for now.
thanks
On Mon, Aug 18, 2014 at 5:33 PM, Remi Collet wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 18/08/2014 11:21, Stas Malyshev a écrit :
>> BTW, it'd be nice to figure out why we h
On Mon, Aug 18, 2014 at 11:30 PM, Johannes Schlüter
wrote:
> On Mon, 2014-08-18 at 23:09 +0800, Tjerk Meesters wrote:
> > > On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter <
> johan...@schlueters.de> wrote:
> > >
> > >> On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
> > >> The question
Hi Nikita,
I reviewed the AST RFC on my way to vote but there was something that wasn’t
clear to me.
This patch introduces some semantic/behavioral changes in addition to the AST.
Are these as a side-effect of how AST was implemented? Or are they unrelated to
the AST patch?
I think some of them
I will +1 this as I have had to deal with some of these struggles, as a
suggestion though:
"Like the bind(To) methods, a static class cannot be bound (using →call
will fail)"
I would like to see this function work like
Closure::bind()/Closure::bindTo() and give the option for the $newScope
option
Hi Derick,
> On Mon, 18 Aug 2014, Wei Dai wrote:
>
> > > I'm trying to call a function inside a module, a PHP_FUNCTION.
> > >
> > > Other than zend_eval_stringl, what's the direct way to do it?
> >
> > Please refer to call_user_function and call_user_function_ex.
>
> Actually, you need to
On 18 Aug 2014, at 00:40, Levi Morrison wrote:
> On Sun, Aug 17, 2014 at 5:13 PM, Stas Malyshev wrote:
>> Hi!
>>
>>> It does, but maybe you missed it. Under the Proposal section:
>>>
To solve this, we relax the current invariant of scoped closures
having to be bound, and add a new p
Hi!
Moving this out of other topics into its own: according to the release
RFC, we should have 5.4 have 2 years of bugfixes & one year of security
fixes. Since 5.4 was released in March 2012, we're already past 2 year
mark. However, we're still have some bugfixes in 5.4, so I'd like to do
this:
-
Am 19.8.2014 um 00:09 schrieb Stas Malyshev :
> Hi!
>
> Since we've had phpng branch merged to master the build on Travis CI is
> broken for master (as in, doesn't even build). Could it be fixed? It's
> not a good thing that we have master branch that CI can not even run on.
> I suspect it has to
Hi!
> I opted for master-only on the grounds that while it's an improvement,
> it's not really a bugfix, and released versions (or versions as near
> to release as 5.6 is) should be bug-fix only. I know there's an
> argument for this *being* a bug-fix, but...
>
> If a consensus feels it should b
Hi!
Since we've had phpng branch merged to master the build on Travis CI is
broken for master (as in, doesn't even build). Could it be fixed? It's
not a good thing that we have master branch that CI can not even run on.
I suspect it has to do with phpdbg but didn't look into it in depth.
--
Stani
Hi Levi,
The implementation is really not a problem. It must be quite simple and I
may take care about it.
The problem that we can't come to agreement on scalar type hinting for
years :(
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 9:57 PM, Levi Morrison
wrote:
> On Mon, Aug 18, 2014 at 8:21 AM, D
On Mon, Aug 18, 2014 at 12:04 PM, Nikita Popov wrote:
> On Mon, Aug 18, 2014 at 7:59 PM, Levi Morrison wrote:
>>
>> On Mon, Aug 18, 2014 at 6:04 AM, Dmitry Stogov wrote:
>> > Hi,
>> >
>> > Please take a look into the proposed new Memory Manager for PHP:
>> >
>> > https://github.com/php/php-src/p
On Mon, Aug 18, 2014 at 7:59 PM, Levi Morrison wrote:
> On Mon, Aug 18, 2014 at 6:04 AM, Dmitry Stogov wrote:
> > Hi,
> >
> > Please take a look into the proposed new Memory Manager for PHP:
> >
> > https://github.com/php/php-src/pull/777
>
> It looks like the gains are mostly earned by passing
On Mon, Aug 18, 2014 at 6:04 AM, Dmitry Stogov wrote:
> Hi,
>
> Please take a look into the proposed new Memory Manager for PHP:
>
> https://github.com/php/php-src/pull/777
It looks like the gains are mostly earned by passing size information;
is that correct?
--
PHP Internals - PHP Runtime Dev
On Mon, Aug 18, 2014 at 8:21 AM, Dmitry Stogov wrote:
> I see your point. For me they just don't have a lot of sense without each
> other.
I am the author of two of those RFCs. I've worked with several members
of the HHVM team so that any inconsistencies are planned and recorded
(or will be; I kn
Hi internals!
I've opened the vote on the Abstract Syntax Tree RFC:
https://wiki.php.net/rfc/abstract_syntax_tree#vote
Thanks,
Nikita
On Mon, Aug 18, 2014 at 3:30 PM, Dmitry Stogov wrote:
> Some more problems I found:
>
> - few tests started fail with the patch
>
> Zend Multibyte and ShiftJIS
> [Zend/tests/multibyte/multibyte_encoding_001.phpt]
> zend multibyte (8) [ext/mbstring/tests/zend_multibyte-08.phpt]
>
Thanks, those ar
Am 18.08.2014 um 16:21 schrieb Dmitry Stogov:
> For me they just don't have a lot of sense without each other.
https://wiki.php.net/rfc/returntypehinting makes sense without
https://wiki.php.net/rfc/scalar_type_hinting_with_cast and
https://wiki.php.net/rfc/nullable_typehints IMHO.
--
PHP Int
On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
>foreach ($db->query("SELECT id, title FROM entries") as $row) {
>echo "if ($row[0] == $_GET['highlight_id']) {
>echo " background='#ff'";
>}
>echo ">".htmlentities($row[1])."";
>}
>
On Mon, 2014-08-18 at 23:09 +0800, Tjerk Meesters wrote:
> > On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter
> > wrote:
> >
> >> On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
> >> The question isn't "What's wrong with ===, strcmp()?" but "What's wrong
> >> with ==, <, >?".
> >>
> >>
> On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter
> wrote:
>
>> On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
>> The question isn't "What's wrong with ===, strcmp()?" but "What's wrong
>> with ==, <, >?".
>>
>> We have a standard way to compare two operands but currently we do some
On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
> The question isn't "What's wrong with ===, strcmp()?" but "What's wrong
> with ==, <, >?".
>
> We have a standard way to compare two operands but currently we do some
> magic things to solve something that don't need to be solved.
Still
On Sun, Aug 17, 2014 at 11:25 AM, Ferenc Kovacs wrote:
> Hi,
>
> I'm planning to release 5.6.0 from RC4 if nothing serious comes up, so
> this is just a heads-up: if you think that there is some fix, which should
> make into the 5.6.0 final (which isn't in RC4) or if you think that there
> is som
I see your point. For me they just don't have a lot of sense without each
other.
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 6:14 PM, Andrea Faulds wrote:
>
> On 18 Aug 2014, at 15:11, Dmitry Stogov wrote:
>
> > What do you think about merging the following proposals into a single
> and consist
On 18 Aug 2014, at 15:11, Dmitry Stogov wrote:
> What do you think about merging the following proposals into a single and
> consistent one:
>
> https://wiki.php.net/rfc/scalar_type_hinting_with_cast
> https://wiki.php.net/rfc/returntypehinting
> https://wiki.php.net/rfc/nullable_typehints
No
Hi,
What do you think about merging the following proposals into a single and
consistent one:
https://wiki.php.net/rfc/scalar_type_hinting_with_cast
https://wiki.php.net/rfc/returntypehinting
https://wiki.php.net/rfc/nullable_typehints
I think it makes sense to keep syntax consistent with subset
On Mon, Aug 18, 2014 at 3:39 PM, Nikita Popov wrote:
> On Mon, Aug 18, 2014 at 1:19 PM, Dmitry Stogov wrote:
>
>> On Mon, Aug 18, 2014 at 2:26 PM, Nikita Popov
>> wrote:
>>
>>> On Mon, Aug 18, 2014 at 9:32 AM, Dmitry Stogov wrote:
>>>
Hi Nikita,
I think RFC misses few important
On Mon, Aug 18, 2014 at 02:44:36PM +0200, Marc Bennewitz wrote:
> >What exactly is wrong with ===, strcmp(), etc..?
>
> The question isn't "What's wrong with ===, strcmp()?" but "What's
> wrong with ==, <, >?".
>
> We have a standard way to compare two operands but currently we do
> some magic t
hi,
On Mon, Aug 18, 2014 at 2:44 PM, Marc Bennewitz wrote:
>
>
> On 17.08.2014 22:18, Sara Golemon wrote:
>>
>> On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz wrote:
>>>
>>> I've created a draft RFC and patch to change the behavior of non-strict
>>> string to string comparison to be binary saf
On 17.08.2014 22:18, Sara Golemon wrote:
On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz wrote:
I've created a draft RFC and patch to change the behavior of non-strict
string to string comparison to be binary safe (as the strict comparison
operator does):
https://wiki.php.net/rfc/bina
Hi,
Please take a look into the proposed new Memory Manager for PHP:
https://github.com/php/php-src/pull/777
The patch provides visible performance improvement on real life apps
(tested on Linux 32 and 64 bit). It's based on ideas mainly borrowed from
jemalloc and tcmalloc.
I hope, the patch mu
On Mon, Aug 18, 2014 at 1:19 PM, Dmitry Stogov wrote:
> On Mon, Aug 18, 2014 at 2:26 PM, Nikita Popov
> wrote:
>
>> On Mon, Aug 18, 2014 at 9:32 AM, Dmitry Stogov wrote:
>>
>>> Hi Nikita,
>>>
>>> I think RFC misses few important notes about behavior changes:
>>>
>>> 1) The behavior of $a->$b[$c
one more problem
sapi/cli/php -r ' $a = [1,2]; list($b, $a) = $a; var_dump($a,$b);'
Segmentation fault
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 3:19 PM, Dmitry Stogov wrote:
>
>
>
> On Mon, Aug 18, 2014 at 2:26 PM, Nikita Popov
> wrote:
>
>> On Mon, Aug 18, 2014 at 9:32 AM, Dmitry Stogov wro
On Mon, Aug 18, 2014 at 2:26 PM, Nikita Popov wrote:
> On Mon, Aug 18, 2014 at 9:32 AM, Dmitry Stogov wrote:
>
>> Hi Nikita,
>>
>> I think RFC misses few important notes about behavior changes:
>>
>> 1) The behavior of $a->$b[$c] is changed. PHP apps that used such syntax
>> have to be changed i
On Mon, Aug 18, 2014 at 9:32 AM, Dmitry Stogov wrote:
> Hi Nikita,
>
> I think RFC misses few important notes about behavior changes:
>
> 1) The behavior of $a->$b[$c] is changed. PHP apps that used such syntax
> have to be changed into $a->{$b[$c]}.
>
This is a change from the uniform variable
On Mon, 18 Aug 2014, Wei Dai wrote:
> > I'm trying to call a function inside a module, a PHP_FUNCTION.
> >
> > Other than zend_eval_stringl, what's the direct way to do it?
>
> Please refer to call_user_function and call_user_function_ex.
Actually, you need to be careful with this. If you are ca
On Mon, 18 Aug 2014, Remi Collet wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 18/08/2014 11:21, Stas Malyshev a écrit :
> > BTW, it'd be nice to figure out why we have 6 fails there :)
>
> I already spent a lot of time fixing various non-intel failed tests...
>
> 3 related to
On 17 Aug 2014, at 22:55, Chris Wright wrote:
> On 17 August 2014 11:49, David Zuelke wrote:
>> That does not make any sense; applications could accept XML, CSV or whatever
>> else just as well.
>>
>> The original proposal is not very useful. $_GET contains parsed query string
>> info, $_POST
On Mon, 2014-08-18 at 10:37 +0800, Wei Dai wrote:
> Hi,
> > Hi,
> >
> > I'm trying to call a function inside a module, a PHP_FUNCTION.
> >
> > Other than zend_eval_stringl, what's the direct way to do it?
> Please refer to call_user_function and call_user_function_ex.
See also the set of zend_c
Magento doesn't work with AST patch.
500 response on home page, no crash.
Other applications I tested seem to work.
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 11:32 AM, Dmitry Stogov wrote:
> Hi Nikita,
>
> I think RFC misses few important notes about behavior changes:
>
> 1) The behavior of $a
On Sun, Aug 17, 2014 at 9:58 PM, Marc Bennewitz wrote:
> Hi internals!
>
> I've created a draft RFC and patch to change the behavior of non-strict
> string to string comparison to be binary safe (as the strict comparison
> operator does):
>
> https://wiki.php.net/rfc/binary_string_comparison
On 18 August 2014 03:37, Wei Dai wrote:
> Hi,
>> Hi,
>>
>> I'm trying to call a function inside a module, a PHP_FUNCTION.
>>
>> Other than zend_eval_stringl, what's the direct way to do it?
> Please refer to call_user_function and call_user_function_ex.
...and along these lines, when you need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 18/08/2014 11:21, Stas Malyshev a écrit :
> BTW, it'd be nice to figure out why we have 6 fails there :)
I already spent a lot of time fixing various non-intel failed tests...
3 related to date can be ignored (because of fedora / red hat
system-tz
Hi!
> Quick test build (using fedora 5.6.0RC4 package on RHEL-7...)
> (notice, report will be clean in a few days)
Thanks a lot, Remi! Looks like something is not right with these patches
>
> Without the patches
>
> https://kojipkgs.fedoraproject.org//work/tasks/9765/7399765/build.log
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 18/08/2014 08:10, Laruence a écrit :
> Hey:
>
> There are some PRs for supports of PowerPC64
>
> https://github.com/php/php-src/pull/734
> https://github.com/php/php-src/pull/735
> https://github.com/php/php-src/pull/736
> https://github.com/ph
Hi!
> There are some PRs for supports of PowerPC64
>
> https://github.com/php/php-src/pull/734
> https://github.com/php/php-src/pull/735
> https://github.com/php/php-src/pull/736
> https://github.com/php/php-src/pull/737
>
> Anyone can review them?
>
> or, I will com
constant expressions for properties, etc.
class Foo {
public $x = 5 + SOME_CONST;
}
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 11:52 AM, Sebastian Bergmann
wrote:
> Am 18.08.2014 um 09:32 schrieb Dmitry Stogov:
> > Can OPcahce always keep AST in shared memory and don't copy it into
> > process
Am 18.08.2014 um 10:01 schrieb Pierre Joye:
> I can imagine optimizations happening during the cache lifetime and
> not only right on the 1st request/compilation. Having the AST at hand
> can be handy.
That makes sense.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vis
On Mon, Aug 18, 2014 at 9:52 AM, Sebastian Bergmann wrote:
> Am 18.08.2014 um 09:32 schrieb Dmitry Stogov:
>> Can OPcahce always keep AST in shared memory and don't copy it into
>> process memory on each request? (ext/opcache/zend_accelerator_util_funcs.c)
>
> Why would the AST need to be cached?
Am 18.08.2014 um 09:32 schrieb Dmitry Stogov:
> Can OPcahce always keep AST in shared memory and don't copy it into
> process memory on each request? (ext/opcache/zend_accelerator_util_funcs.c)
Why would the AST need to be cached?
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
Hi Nikita,
I think RFC misses few important notes about behavior changes:
1) The behavior of $a->$b[$c] is changed. PHP apps that used such syntax
have to be changed into $a->{$b[$c]}.
2) The evaluation order of left and right parts of assignment is changed.
$a[$i++] = $a[$i++]; It wasn't guaran
55 matches
Mail list logo
