I'm trying to work through some of the more subtle changes in phpng and
one that sticks out is the loss of IS_BOOL. I think the explanation is
that it removes a read, but while I'm only seeing a few uses of is_bool
across the codebase, every one of them is used simply to convert the
bool value into
Hey:
On Wed, Jul 23, 2014 at 4:02 PM, Lester Caine wrote:
> I'm trying to work through some of the more subtle changes in phpng and
> one that sticks out is the loss of IS_BOOL. I think the explanation is
> that it removes a read, but while I'm only seeing a few uses of is_bool
> across the codeb
Hey, thank you for looking into it :-)
Am 23.7.2014 um 00:23 schrieb Dmitry Stogov :
> hi Bob,
>
> I still think that current array usage in constant expressions is not
> consistent and dangerous. It "smells" to me, and I think it may bring
> troubles in the future even if the existing known bugs
Notice,
All Internal classes, implementing Countable still doesn't accept this
optional parameter.
Ex:
Method [ public method count ] {
- Parameters [0] {
}
Indeed, all Spl classes still use zend_parse_parameters_none().
This work, because count($a) doesn't use th
Notice,
All Internal classes, implementing Countable still doesn't accept this
optional parameter.
Ex:
Method [ public method count ] {
- Parameters [0] {
}
Indeed, all Spl classes still use zend_parse_parameters_none().
This work, because count($a) doesn't use th
Hi!
>> > class Foo {
>>const BAR = [0];
>>static $a = Foo::BAR; // constant array usage
>> }
>> var_dump(Foo::$a); // prints array
>> var_dump(Foo::BAR); // emits fatal error
>> ?>
>
> They can only be used in static scalar contexts.
>
> I wanted to introduce constants to be used an
Stas Malyshev wrote (on 22/07/2014):
Alternatively, we could do a wiki maybe but the problem there is that it
is hard to export (unless anybody knows wiki setups that can be easily
exported into single document).
Something like Wikipedia's "Create a Book" feature perhaps? [1] That can
be set u
On Wed, Jul 23, 2014 at 12:16 PM, Bob Weinand wrote:
> Hey, thank you for looking into it :-)
>
> Am 23.7.2014 um 00:23 schrieb Dmitry Stogov :
> > hi Bob,
> >
> > I still think that current array usage in constant expressions is not
> > consistent and dangerous. It "smells" to me, and I think it
On 23/07/14 09:12, Laruence wrote:
> On Wed, Jul 23, 2014 at 4:02 PM, Lester Caine wrote:
>> > I'm trying to work through some of the more subtle changes in phpng and
>> > one that sticks out is the loss of IS_BOOL. I think the explanation is
>> > that it removes a read, but while I'm only seeing
On Tue, Jul 22, 2014 at 9:50 PM, Sara Golemon wrote:
> Just announced something at OSCON that's probably going to get a lot
> of folks talking and making assumptions, so before things get out of
> hand, I want to provide some context.
>
> We (As in PHP) have been talking about making a spec for th
Le 23/07/2014 10:26, Remi Collet a écrit :
> Both solution "should" fix this:
> - adding the count_elements handler
> - accepting the optional mode
Both works.
> But, Reflection still not correct, and count($a) still raise the
IT is ok (sorry for the noise, tested with a bad path...)
> I think
On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs wrote:
>
>
>
> On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli wrote:
>>
>> On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs wrote:
>> >
>> >
>> >
>> > On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov
>> > wrote:
>> >>
>> >> On Tue, Jul 22, 2014 at 12:27
Rowan Collins wrote:
> Stas Malyshev wrote (on 22/07/2014):
>> Alternatively, we could do a wiki maybe but the problem there is that it
>> is hard to export (unless anybody knows wiki setups that can be easily
>> exported into single document).
>
> Something like Wikipedia's "Create a Book" feature
On 23/07/2014 10:57, Remi Collet wrote:
>> I think this is not consistent (internal vs userland)
>
> Inconsistency is :
>
> $a->count() call the method (with the optional arg),
> count($a) call the handler
quite a while ago I've attached a patch that fixes such incostistency:
https://bugs.p
On Wed, Jul 23, 2014 at 10:57 AM, Julien Pauli wrote:
> On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs wrote:
> >
> >
> >
> > On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli wrote:
> >>
> >> On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs
> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Jul 22, 2014
On Wed, Jul 23, 2014 at 11:09 AM, Ferenc Kovacs wrote:
>
>
>
> On Wed, Jul 23, 2014 at 10:57 AM, Julien Pauli wrote:
>>
>> On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs wrote:
>> >
>> >
>> >
>> > On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli wrote:
>> >>
>> >> On Tue, Jul 22, 2014 at 2:04 PM,
On 22/07/14 23:28, Stas Malyshev wrote:
> I would propose choosing some collaborative platform for managing it,
> something like Google Docs (suggestions about best platform ever for
> that are welcome :) so that people could comment on specific parts and
> keep track of what is the current state a
Yes. Did you see my thoughts before?
> I'm just wondering if we can't somehow deeply copy the asts for opcache
> between compile time and run time in pass_two() (If I'm not wrong pass_two()
> has some hook for zend extensions?)
>
> Then we can fix the ast and don't have to take care of opcache
Hi!
> Another idea would be a Git repository with the specification as
> markdown files. This would allow creating Pull Requests via GitHub.
I think facilitating discussion and feedback is more important than
change tracking for now, but given github also has issues facility it
may actually work.
Hi,
> On 23.07.2014, at 11:22, Stas Malyshev wrote:
>
> Hi!
>
>> Another idea would be a Git repository with the specification as
>> markdown files. This would allow creating Pull Requests via GitHub.
>
> I think facilitating discussion and feedback is more important than
> change tracking for
On Wed, Jul 23, 2014 at 1:20 PM, Bob Weinand wrote:
> Yes. Did you see my thoughts before?
>
> I'm just wondering if we can't somehow deeply copy the asts for opcache
>> between compile time and run time in pass_two() (If I'm not wrong
>> pass_two() has some hook for zend extensions?)
>>
>> Then
I have a thought about the spec.
I work on Yii framework and the team building it has a great policy - if
your changes to the code require changes to the documentation - you are
required to update the docs. No docs changes - no merge.
The most up to date documentation I have ever seen.
Maybe for
Am 23.7.2014 um 11:34 schrieb Dmitry Stogov :
> On Wed, Jul 23, 2014 at 1:20 PM, Bob Weinand wrote:
>
>> Yes. Did you see my thoughts before?
>>
>> I'm just wondering if we can't somehow deeply copy the asts for opcache
>>> between compile time and run time in pass_two() (If I'm not wrong
>>> pa
On Wed, 23 Jul 2014, Aaron Lewis wrote:
> Hi,
>
> How can I know the line no in eval()'d code?
>
> e.g eval()'d code on line 1 (I couldn't find the definition of that
> output, so I had to ask it here)
>
> zend_get_executed_lineno(TSRMLS_C) doesn't seem to be the right value
AFAIK, it's all on
On 07/23/2014 12:48 AM, Sara Golemon wrote:
I dunno, with syntax changes being 2/3rd majority and our formal RFC
process in place, I think we (PHP) can reasonably learn to make
updating the spec a formal part of our process.
Requiring an RFC that changes syntax (or core semantics) to provide a
On 07/23/2014 12:25 AM, Andrea Faulds wrote:
Myself I think it’d be best if the PHP Group runs it.
And who exactly is the PHP Group? Most of the people listed in the
credits as "The PHP Group" have not contributed in years.
I agree, though, that the PHP project should own the language
spec
Hi Remi,
Thanks for the PR. I'll merge it as soon as I've been able to test it,
as the class should respect the definition of the method in the
interface.
Regarding the change in behaviour, I think the patch
https://bugs.php.net/patch-display.php?bug=67064&patch=bug67064-BC&revision=1402667581
sh
Le 23/07/2014 12:54, Sebastian Bergmann a écrit :
On 07/23/2014 12:25 AM, Andrea Faulds wrote:
Myself I think it’d be best if the PHP Group runs it.
And who exactly is the PHP Group? Most of the people listed in the
credits as "The PHP Group" have not contributed in years.
I agree, thou
On 22 ביול 2014, at 15:39, Lester Caine wrote:
> It does sound very much as if
> phpng is already a done deal and it just need to be rubber stamped into
> the main development stream?
It's not a rubber stamp. If you don't feel it should make it in and enough
people will think like you, then it
On 22/07/14 20:50, Sara Golemon wrote:
> http://dl.hhvm.com/resources/PHPSpec-SneakPeak.pdf
I know this is a peak at the new documentation, but it flagged up
something when I was scanning through.
switch Statement ...
I have always put the 'default:' as the last item in the list since it's
what
> -Original Message-
> From: Pascal Chevrel [mailto:pascal.chev...@free.fr]
> Sent: Wednesday, July 23, 2014 2:58 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] PHP Group, what is it? (was Re:PHP Language
> Specification)
>
> Could somebody that was in the project 15 years ago ex
On 23/07/14 13:05, Zeev Suraski wrote:
>> It does sound very much as if
>> > phpng is already a done deal and it just need to be rubber stamped into
>> > the main development stream?
> It's not a rubber stamp. If you don't feel it should make it in and enough
> people will think like you, then it
On Mon, 2014-07-21 at 18:17 +0400, Dmitry Saprykin wrote:
> changed "write_history" at the end to "append_history" after
> each cli_is_valid_code.
> Now it is -1 line, +1 line commit and completely looks like bug fix. )
Have you tested with libedit? - A quick grep on my system shows no
append_hist
On 23 Jul, 2014, at 8:38 pm, Johannes Schlüter wrote:
> On Mon, 2014-07-21 at 18:17 +0400, Dmitry Saprykin wrote:
>> changed "write_history" at the end to "append_history" after
>> each cli_is_valid_code.
>> Now it is -1 line, +1 line commit and completely looks like bug fix. )
>
> Have you tes
Hello Sara,
First, thank you for the hard work. I have started to work on it few
days ago as suggested in [1]. You have been faster than me ;-). Good job!
On 23/07/2014 00:22, Sara Golemon wrote:
On Tue, Jul 22, 2014 at 12:50 PM, Sara Golemon wrote:
This document is meant for PHP, and PHP
Yes, you are right. append_history is not suitable for libedit. I left
write_history call for libedit.
On 23 July 2014 16:38, Johannes Schlüter wrote:
> On Mon, 2014-07-21 at 18:17 +0400, Dmitry Saprykin wrote:
> > changed "write_history" at the end to "append_history" after
> > each cli_is_val
On 23 Jul 2014, at 09:49, Lester Caine wrote:
> I'm looking for the explanation as to why it HAS to change rather than
> anything else. I can see that using the 64bit value field is overkill,
> but there is still plenty of spare space in the TYPE element to not have
> to create an extra object t
Good afternoon,
My sincerest apologies about all the mess earlier and the delay. Both me and
Zeev are happy enough with the RFC, so the voting for this RFC has started
(again). It shall end on 2014-07-30 (next Wednesday, a week’s time) and it
won’t be cancelled this time.
https://wiki.php.net/
Somewhat unrelated to this vote in particular, but someone mentioned on
IRC that it would be cool to see votes chronologically so I wrote a
short JS snippet that does just that. In case anyone is interested for
archeological purposes:
https://gist.github.com/Seldaek/bc0ae0e2bf1617d71ed7
--
PH
On Wed, Jul 23, 2014 at 3:38 PM, Andrea Faulds wrote:
> Good afternoon,
>
> My sincerest apologies about all the mess earlier and the delay. Both me
> and Zeev are happy enough with the RFC, so the voting for this RFC has
> started (again). It shall end on 2014-07-30 (next Wednesday, a week’s tim
> did you consider resetting the vote as the text was changed multiple times
> after the voting begun?
It was reset.
S
On 23 Jul 2014, at 15:21, Ferenc Kovacs wrote:
> I also think that it would be reasonable to have two weeks for the votes to
> come in, as https://wiki.php.net/rfc/voting states that "There'd be a
> minimum of 2 weeks between when an RFC that touches the language is brought
> up on this list and
On Wed, Jul 23, 2014 at 4:32 PM, Andrea Faulds wrote:
>
> On 23 Jul 2014, at 15:21, Ferenc Kovacs wrote:
>
> > I also think that it would be reasonable to have two weeks for the votes
> to
> > come in, as https://wiki.php.net/rfc/voting states that "There'd be a
> > minimum of 2 weeks between wh
On Wed, Jul 23, 2014 at 4:31 PM, Sean Coates wrote:
> did you consider resetting the vote as the text was changed multiple times
> after the voting begun?
>
>
> It was reset.
>
> S
>
>
whoops, sorry.
then I'm really surprised the number of votes already in.
--
Ferenc Kovács
@Tyr43l - http://tyr
On Wed, Jul 23, 2014 at 11:12 AM, Julien Pauli wrote:
> On Wed, Jul 23, 2014 at 11:09 AM, Ferenc Kovacs wrote:
>>
>>
>>
>> On Wed, Jul 23, 2014 at 10:57 AM, Julien Pauli wrote:
>>>
>>> On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Jul 22, 2014 at 6:20 PM,
On Tue, Jul 22, 2014 at 7:23 PM, Aaron Lewis wrote:
>
> How can I know the line no in eval()'d code?
>
Are you asking how to determine where the eval'd code was called from?
There's a way, but it's a bit messy:
Walk up EG(current_execute_data) until you get to the opline pointing
at ZEND_EVAL (t
PHP-5.6 is frozen for new features for a long time.
Adding new features after RC is not a good idea.
And we will need some kind of RFC and voting.
I help you technically, but you know my opinion about this feature..
anyway, lets fix bugs first, I got an idea that may work...
Thanks. Dmitry.
On
On Jul 14, 2014, at 10:13, Andrea Faulds wrote:
> We are using hack’s syntax (int, float, bool, string, no
> integer/double/boolean aliases).
On 20 Jul 2014, at 14:11, Andrea Faulds wrote:
> The patch actually warns you if you try to do this now:
>
>function foo(double $foo) {}
>foo(1.
On Wed, Jul 23, 2014 at 7:39 AM, Ferenc Kovacs wrote:
> On Wed, Jul 23, 2014 at 4:32 PM, Andrea Faulds wrote:
>
> >
> > On 23 Jul 2014, at 15:21, Ferenc Kovacs wrote:
> >
> > > I also think that it would be reasonable to have two weeks for the
> votes
> > to
> > > come in, as https://wiki.php.n
On 23 Jul 2014, at 19:21, Robert Williams wrote:
> It seems odd to me to not support the aliases. Since I can do this:
>
> $foo = (integer)$bar;
>
> I would expect to be able to do this:
>
> function foo(integer $param) {}
Aliases mean inconsistency. We shouldn’t unnecessarily have multi
Ivan Enderlin @ Hoa wrote (on 23/07/2014):
My idea was to constitute a **PHP Consortium** (yes, the name is
classy but it reflects the reality), responsible to maintain and edit
the PHP Specification. With what members? Members from the PHP Group
(maintainers of php-src), from Facebook (maintai
On 23 Jul 2014, at 19:59, Rowan Collins wrote:
> On the flip side, there is definitely value in representatives from other
> implementations having a voice in changes that affect them, but that could
> just mean ensuring that members of those projects are involved within the
> current framewo
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Wednesday, July 23, 2014 8:00 AM
> To: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] RFC: Move phpng to master
>
> I think before we do that we need to do much better documentation around
> the changes
Hi!
> It was a restriction to not support arrays in constant context. It seems
> like nobody can remember why it was introduced.
My vague recollection is that it had some troubles with keeping
refcounts consistent, esp. withing bytecode caching context, but it may
be a false memory :)
> However,
Am 23.7.2014 um 22:33 schrieb Stas Malyshev :
> Hi!
>
>> It was a restriction to not support arrays in constant context. It seems
>> like nobody can remember why it was introduced.
>
> My vague recollection is that it had some troubles with keeping
> refcounts consistent, esp. withing bytecode ca
On Jul 23, 2014, at 1:59 PM, Rowan Collins wrote:
> On the flip side, there is definitely value in representatives from other
> implementations having a voice in changes that affect them, but that could
> just mean ensuring that members of those projects are involved within the
> current framew
On Jul 23, 2014, at 11:37, Andrea Faulds wrote:
> Aliases mean inconsistency. We shouldn’t unnecessarily have multiple names
> for the same thing, just one. Also, for every alias we support, another
> reserved word is added. Hence we only allow one set of names. This is also
> Facebook’s appro
On 23/07/14 19:23, Kris Craig wrote:
> Wow, looks like the PHP 7 votes are dominating so far. If you want to
> avoid the confusion and ridicule that will result from skipping a version
> increment, I suggest you remember to cast your vote.
Since PHP6 existed then sorry but using it again is just
On 23 Jul 2014, at 21:59, Ben Ramsey wrote:
> This got me thinking about the whole version number debate. With a language
> specification, to what does the version number refer? The state of the
> language specification, or the state of a given implementation of the
> specification? Right now
On 23 Jul 2014, at 22:17, Robert Williams wrote:
> Although I don’t have voting rights, I would completely support a separate
> RFC to remove the aliases in PHP 6/7. But in the mean time, as long as
> they’re still in the language, I think they need to be fully supported
> anywhere their “rea
> On Jul 23, 2014, at 11:23 AM, Kris Craig wrote:
>
>> On Wed, Jul 23, 2014 at 7:39 AM, Ferenc Kovacs wrote:
>>
>>> On Wed, Jul 23, 2014 at 4:32 PM, Andrea Faulds wrote:
>>>
>>>
On 23 Jul 2014, at 15:21, Ferenc Kovacs wrote:
I also think that it would be reasonable to have
On 23/07/2014 22:27, Andrea Faulds wrote:
For majors and minors things are quite clear-cut. Zend PHP 5.6 implements PHP
5.6 as specified, and I imagine that HHVM foo.bar is going to say it’s
“5.6-compliant” or something of the sort. The problem is micro versions. 5.6.1
is probably going to be
Hi,
I have a request to include our latest sapi/litespeed V6.6 to the EOL
PHP 5.3 release. I thought it was EOL already.
We had some difficult to commit our LiteSpeed SAPI code into PHP source
repository before, so it is lagging behind our office release.
The sapi/litespeed code in 5.3.28 is
On 23/07/2014 13:06, Lester Caine wrote:
I have always put the 'default:' as the last item in the list since it's
what is left after processing all the other options and one may or may
not have fallen out.
This is intuitive, and arguably good coding style, but not necessary as
switch statemen
Hi,
Two quick points on the PHP6/7 discussion:
1. There is an existing alternative PHP-compatible implementation called
PH7 available from http://ph7.symisc.net/. This may be very confusing if
mainline PHP is called PHP 7.
2. People may see the latest version of PHP 7, think that there have been
On 24 Jul 2014, at 01:47, m appu wrote:
> Two quick points on the PHP6/7 discussion:
Why aren’t you responding to the existing RFC discussion?
> 1. There is an existing alternative PHP-compatible implementation called
> PH7 available from http://ph7.symisc.net/. This may be very confusing if
>
hi,
On Wed, Jul 23, 2014 at 10:45 PM, Bob Weinand wrote:
> Well, we still could fix it now, AFAIK, we will still have another RC now and
> when we fix it only for 5.6.1, there also will only be one RC in between.
> That's no gain in testing time etc..
Also please keep in mind that we are alrea
Hi!
On Wed, Jul 23, 2014 at 4:26 PM, Remi Collet wrote:
> Notice,
>
> All Internal classes, implementing Countable still doesn't accept this
> optional parameter.
>
> Ex:
>
> Method [ public method count ]
> {
>
> - Parameters [0] {
> }
>
> Indeed, all Spl classes s
On Wed, Jul 23, 2014 at 8:20 PM, Pierre Joye wrote:
> hi,
>
> On Wed, Jul 23, 2014 at 10:45 PM, Bob Weinand wrote:
>
> > Well, we still could fix it now, AFAIK, we will still have another RC
> now and when we fix it only for 5.6.1, there also will only be one RC in
> between.
> > That's no gain
Hi Lonny,
On Wed, Jul 23, 2014 at 3:01 AM, Lonny Kapelushnik
wrote:
> Morning,
>
> I propose deprecating two GD functions: imagettftext and imagettfbbox.
>
> The reasons I would like to deprecate them are:
> 1. Their functionality is a subset of imagefttext and imageftbbox
> 2. The imagettf* fu
70 matches
Mail list logo
