On Sat, Jan 10, 2015 at 11:07 PM, François Laupretre
wrote:
> De : Pierre Joye [mailto:pierre@gmail.com]
>
>> Say we do support builtin scripts, an opcache will simply load them on minit
>> or on the first request and flag them as
>> permanent. Yes, it means we need to change opcache but coul
On Sat, Jan 10, 2015 at 8:08 PM, Sara Golemon wrote:
> On Sat, Jan 10, 2015 at 2:39 PM, Stanislav Malyshev
> wrote:
>> So I think it would be useful to define what exactly would be covered
>> and what not, i.e. which APIs are supported, which can be supported,
>> which can not. Right now we don'
De : Pierre Joye [mailto:pierre@gmail.com]
> Say we do support builtin scripts, an opcache will simply load them on minit
> or on the first request and flag them as
> permanent. Yes, it means we need to change opcache but could be way easier
> than trying to hack the engine to support
> p
Hi all,
On Sun, Jan 11, 2015 at 3:36 PM, Pierre Joye wrote:
> > Well, the feature list for PHP7 is not closed yet. I hope new attractive
> features will be added soon because, otherwise, it will be very hard to
> sell. And we need attractive features in the first release, not 7.1 or 7.2,
> which
Am 25.08.2014 um 19:39 schrieb Nikita Popov:
> I don't know if I will be implementing that ext myself. In any case, before
> that can happen I will have to create another RFC for converting parse
> errors into exceptions and making sure we don't leak memory on failed parse
> - I think thats a prere
On Jan 11, 2015 1:34 PM, "François Laupretre" wrote:
> Well, the feature list for PHP7 is not closed yet. I hope new attractive
features will be added soon because, otherwise, it will be very hard to
sell. And we need attractive features in the first release, not 7.1 or 7.2,
which will never have
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> I thought there will be 5.7 and didn't pay much attention on this. Slow
> transition is better than too fast.
Slow transition is good, but, sometimes, it is too slow; I don't know if you
remember how much time was
On Jan 11, 2015 11:38 AM, "François Laupretre" wrote:
>
> > De : Pierre Joye [mailto:pierre@gmail.com]
> >
> > > Sorry, I am not sure I understand how the opcode cache, as it exists
now,
> > can understand this. Do you mean that opcode cache code would need to be
> > modified ?
> >
> > Yes and
> De : Stanislav Malyshev [mailto:smalys...@gmail.com]
>
> TLDR: this RFC would make a call to parent::__construct() succeed (as in
> "not produce a fatal error") even if the parent class does not define a
> ctor. Same for __destruct and __clone. The motivation for it is in the
> RFC and here: http
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> > Sorry, I am not sure I understand how the opcode cache, as it exists now,
> can understand this. Do you mean that opcode cache code would need to be
> modified ?
>
> Yes and no. Yes if we want them to do not even try to update files
> that are
On Sat, Jan 10, 2015 at 2:39 PM, Stanislav Malyshev wrote:
> So I think it would be useful to define what exactly would be covered
> and what not, i.e. which APIs are supported, which can be supported,
> which can not. Right now we don't even have the API as such for the
> engine itself (i.e., you
Hey:
On Sun, Jan 11, 2015 at 6:37 AM, Andrea Faulds wrote:
> Hey internals,
>
> A longstanding PHP bug is that invalid octal digits simply terminate the
> literal and are ignored, rather than generating a compile error. Thus, this
> is valid:
>
> $x = 0109; // same as 010, or 8
>
> I see no
On Mon, Jan 5, 2015 at 10:12 AM, David Zuelke wrote:
> This sounds reasonable, because given how the sort is *not* stable, there
> will be other cases (totally made up, but let's say ["a", "o", "O"]) where
> the swap does *not* happen. Consistency, and thus a stable sort, is better.
>
> But you'
On Sat, Jan 10, 2015 at 9:12 AM, François Laupretre
wrote:
> De : Pierre Joye [mailto:pierre@gmail.com]
>
>> Opcache is why I think we should have a list registered names. A simple hash
>> exists and the cache will know what to do.
>
> Sorry, I am not sure I understand how the opcode cache, a
I'd like to initiate a vote on this RFC:
https://wiki.php.net/rfc/json_preserve_fractional_part
TLDR: this RFC would add a new json_encode option to preserve fractional
part of float numbers when they are 0. Ie, encoding (float)10 to json will
be 10.0.
PS: This is not enabled by default.
The code
Hi all,
On Wed, Jan 7, 2015 at 12:14 AM, David Zuelke wrote:
> > I am not sure about that. Introducing a not easy to catch BC break for
> > 0.1% gain on function (or even for the whole app) is not very
> > appealing.
> >
> > However, there is nothing in the documentation actually describing how
> On 11 Jan 2015, at 02:26, Juan Basso wrote:
>
> I renamed the constant name on the RFC. Can I open the voting?
Hey Juan,
It’s been long enough, and the constant name is a minor issue. Go for it.
:)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
I renamed the constant name on the RFC. Can I open the voting?
On Wed, Jan 7, 2015 at 7:14 PM, Juan Basso wrote:
> I really like the new name and the consistence with the rest of php. If no
> one else has a complain about it I will update the RFC and open for voting,
> right?
>
> Juan Basso
> On
Hi Stas,
On Sun, Jan 11, 2015 at 9:34 AM, Stanislav Malyshev
wrote:
> I'd like to initiate a vote on this RFC:
> https://wiki.php.net/rfc/default_ctor
>
> TLDR: this RFC would make a call to parent::__construct() succeed (as in
> "not produce a fatal error") even if the parent class does not def
Hi all,
Nice fix, Andrea!
On Sun, Jan 11, 2015 at 8:55 AM, Stanislav Malyshev
wrote:
> > A longstanding PHP bug is that invalid octal digits simply terminate
> > the literal and are
> ignored, rather than generating a compile error. Thus, this is valid:
> >
> > $x = 0109; // same as 010, or 8
>
Hi!
I'd like to initiate a vote on this RFC:
https://wiki.php.net/rfc/default_ctor
TLDR: this RFC would make a call to parent::__construct() succeed (as in
"not produce a fatal error") even if the parent class does not define a
ctor. Same for __destruct and __clone. The motivation for it is in th
Hi!
> A longstanding PHP bug is that invalid octal digits simply terminate
> the literal and are
ignored, rather than generating a compile error. Thus, this is valid:
>
> $x = 0109; // same as 010, or 8
>
> I see no particular reason why this behaviour should be preserved.
> I’ve written a patch
On 10/01/2015 23:45, Stanislav Malyshev wrote:
of forthcoming RFCs. If some "evil" BC breaks get to PHP7, then having
5.7 might have been handy, but we've just ruled out this possibility.
We didn't actually - we could resurrect that RFC and have another vote
when the circumstances change.
It'
Hi Andrea,
On Fri, Jan 9, 2015 at 5:28 AM, Andrea Faulds wrote:
> I’m actually closing this vote a little late, it should’ve closed a bit
> before 3pm GMT, but I assumed the vote had been opened in the evening. No
> harm done.
>
> The vote on the PHP 5.7 RFC has closed. By 19 votes to 14, the RF
Hi!
> The current PHP7 doesn't have huge BC breaks as far as I can tell, and
> that's why I (and possibly others) have voted "no".
For the record, it's exactly why I voted no too. If we end up having
ones (e.g. a huge BC break looming in the strict types RFC) that may change.
> of forthcoming RF
Hi!
> Funny to see you mention this. I literally just pulled together a
> meeting today to discuss HHVM's admittedly unstable extension API.
> One idea to emerge from this was to design a new extension API
> agnostic of underlying implementation. An API which, if done right,
What extensions do
Hey internals,
A longstanding PHP bug is that invalid octal digits simply terminate the
literal and are ignored, rather than generating a compile error. Thus, this is
valid:
$x = 0109; // same as 010, or 8
I see no particular reason why this behaviour should be preserved. I’ve written
a p
> De : Dan Ackroyd [mailto:dan...@basereality.com]
>
> The RFC is missing one thing if nothing else; a reason for why this
> functionality would be so much better implemented in the core than in
> userland code.
I thought it was trivial : first, performance and then, ease of use, but I can
elabo
> De : christopher jones [mailto:christopher.jo...@oracle.com]
>
>> To summarize, I started with a rather simple feature request and was
>> then pushed by external wishes.
>
> See #13 at
> https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
> "Take advice on board but make sure your
> De : François Laupretre [mailto:franc...@tekwire.net]
> > De : Andrey Andreev [mailto:n...@devilix.net]
> > I have to agree here. Nested arrays are too much ... it should be
> > limited to single-dimension arrays.
>
> It makes the C code simpler to understand. But I am OK not to document the
> f
On 1/10/15 9:03 AM, François Laupretre wrote:
To summarize, I started with a rather simple feature request and was
then pushed by external wishes.
See #13 at
https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
"Take advice on board but make sure your feature doesn't end up bei
Hi François,
The RFC is missing one thing if nothing else; a reason for why this
functionality would be so much better implemented in the core than in
userland code.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Andrey,
> De : Andrey Andreev [mailto:n...@devilix.net]
>
> I have to agree here. Nested arrays are too much ... it should be
> limited to single-dimension arrays.
It makes the C code simpler to understand. But I am OK not to document the
feature for search and replace. I'd like to keep it fo
Hi,
The RFC about the 'cyclic replacements' addition to str_[i]replace() :
https://wiki.php.net/rfc/cyclic-replace
The pull request, including a complete implementation of the RFC and the
corresponding tests :
https://github.com/php/php-src/pull/980
Please prefer PR comments.
Regards,
Franço
De : Pierre Joye [mailto:pierre@gmail.com]
> Opcache is why I think we should have a list registered names. A simple hash
> exists and the cache will know what to do.
Sorry, I am not sure I understand how the opcode cache, as it exists now, can
understand this. Do you mean that opcode cach
De : Nikita Popov [mailto:nikita@gmail.com]
>
> str_replace is a simple function for string replacement. It has some (imho
> also unnecessary)
> extra gimmicks to implicitly do a foreach() loop during the replacement. This
> is still relatively
> simple API-wise. But if I see this (taken fro
Hi,
On Sat, Jan 10, 2015 at 1:53 PM, Nikita Popov wrote:
> But if I see this (taken from the tests) as the search & replacement values...
>
> $search=array('[?]',array('(?)','d','e'),'a','R');
> $repl=array(
> array('ap(?)z[?]',"b[?](?)v",null,37,"[?]n[?]"),
> array('a',array('b',null)),
Hi Sara,
Obviously a great idea that would make a lot of people's life easier all
around.
One question though? How would api extensions be handled on both sides and
would it be at all possible to keep the APIs consistent across hvvm / php
versions?
I imagine that there would need to be consensus
On Jan 10, 2015 6:55 PM, "François Laupretre" wrote:
>
> > De : Pierre Joye [mailto:pierre@gmail.com]
> >
> > A proof of concept, IRC log, I am lazy :)
> >
> > benjamin, Derick
> > https://gist.github.com/pierrejoye/ce4867a5eaabffa71df4
> > https://gist.github.com/pierrejoye/0859e3702ceb3bb65
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> A proof of concept, IRC log, I am lazy :)
>
> benjamin, Derick
> https://gist.github.com/pierrejoye/ce4867a5eaabffa71df4
> https://gist.github.com/pierrejoye/0859e3702ceb3bb652b6
> https://gist.github.com/pierrejoye/544e60d8994094c55583
> too
On Fri, Jan 9, 2015 at 1:08 AM, François Laupretre
wrote:
> Hi,
>
> I just created the RFC :
>
> https://wiki.php.net/rfc/cyclic-replace
>
> I tried to include everything we agreed upon. Tell me if I missed
> something.
>
> Please note that the current PR does not implement the whole RFC. You may
On Sat, Jan 10, 2015 at 12:16 AM, Pierre Joye wrote:
> On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei wrote:
>> Hey everyone,
>>
>> I want to open discussion on my RFC to strengthen the ability of extensions
>> to provide functionality to developers in both C **and** PHP code.
>>
>> For this ex
On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei wrote:
> Hey everyone,
>
> I want to open discussion on my RFC to strengthen the ability of extensions
> to provide functionality to developers in both C **and** PHP code.
>
> For this extensions can add PHP files to a list of "prepend files" that a
43 matches
Mail list logo
