Re: [PHP-DEV] Issues with exceptions and overloading opcodes

[Derick Rethans]

On Tue, 20 Oct 2015, Bob Weinand wrote:

> > Am 20.10.2015 um 18:08 schrieb Derick Rethans :
> > 
> > On Tue, 20 Oct 2015, Bob Weinand wrote:
> > 
> >>> Am 20.10.2015 um 17:11 schrieb Xinchen Hui :
> >>> 
> >>> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans  >>> > wrote:
> >>> 
>  When hacking on Xdebug for PHP 7, I ran into some issues where 
>  PHP would just spin around. This happens when there is an 
>  exception, and I use overloaded opcodes. I wrote a small example 
>  extension at 
>  https://github.com/derickr/php-minimal-opcode-overloading-example 
>  with a test case ( 
>  https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
>   
>  ) that shows that something is looping in executing opcodes, as 
>  the HANDLE_EXCEPTION iirc doesn't advance to the next opline. I 
>  believe this is a recent enough change, as it only started 
>  happening after I upgraded from about RC1 to latest master.
>  
>  Would you care to have a look?
>  
> >>> This is introduced by a fix made by Bob, 
> >>> https://github.com/php/php-src/commit/808f62bb 
> >>> 
> >>> 
> >>> Bob, I am going to revert this for now, since you didn't include a 
> >>> test script to show where the problem was, I am not sure why you 
> >>> made this?
> >> 
> >> I didn't add any test case as we don't have any APIs in php-src 
> >> using that user_opcode handler. I discussed the change back then 
> >> with Dmitry and committed with his review.
> >> 
> >> It concretely broke uopz which might throw an exception itself. And 
> >> in turn we realized that for integrity we need to ensure that 
> >> opline == EX(opline) else we'll end up with different behavior in 
> >> global register builds and normal builds.
> >> 
> >> In general, you should not overload ZEND_HANDLE_EXCEPTION (if you 
> >> need to, have a special handling for it, but never directly 
> >> dispatch to it). It is quite special being the only opcode actually 
> >> allowing EG(exception) to be non-NULL at the start of it.
> >> 
> >> You are doing an #ifdef ZTS to exempt it… why don't you always 
> >> exempt it?
> > 
> > Even if I do (like I've just pushed into the extension), the test 
> > still fails because the code loops. So you did break something.
> 
> Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
> 
> … maybe I should write
> 
> if (EG(exception)
>  && opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode != ZEND_CATCH
>  && ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN && ret 
> != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
> HANDLE_EXCEPTION();
> }
> 
> to allow dispatching for these two opcodes too?

I don't know. Dmitry, Xinchen? I'd like to get this resolved soon..

cheers,
Derick
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Dan Ackroyd]

Hi Sean, internals,

While I support this RFC, it seems that the actual implementation is
still under discussion.

In particular, whether the RFC is going to allow protected constants
in an interface is not clear.

In the text of the RFC, on one line it says: "This RFC propose PHP
support class constant visibility that mirror the behaviour of method
and property visibility." This would imply that protected constants
are not allowed, as protected methods are not allowed in interfaces.

Just below it says: "//Interfaces only support protected/public const,
and a compile time error will be throw for privates" Which says
clearly that protected constants _would_ be allowed.

Please can you update the text of the RFC?

Unfortunately, that may need a restart of the voting :-\ However that
should just be a formality as it seems to be a popular RFC.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Benchmark Results for PHP Master 2015-10-21

[lp_benchmark_robot]

Results for project PHP master, build date 2015-10-21 05:12:39+03:00
commit: 387b7c7905490cc66c0f4e1e19727a03ac768801
revision date:  2015-10-20 21:56:20+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 
2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0beta3, with hash
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+00:00

--
benchmark   relative   change since   change since
std_dev*   last run   baseline
--
:-)   Wordpress 4.2.2 cgi -T1  0.25% -0.06%  2.16%
:-)   Drupal 7.36 cgi -T1  0.75%  0.06%  1.08%
:-)   MediaWiki 1.23.9 cgi -T5000  0.37%  0.23%  2.80%
:-) bench.php cgi -T1  0.04% -0.03%  2.98%
:-)   micro_bench.php cgi -T1  0.04% -0.01%  1.08%
:-)mandelbrot.php cgi -T1  0.13% -0.02%  5.03%
--
Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
* Relative Standard Deviation (Standard Deviation/Average)

Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Levi Morrison]

> Who decides if/when we should restart voting?

I don't believe we've ever formalized that aspect. I know in the past
sometimes RFC authors will notice something wrong and fix it, then
restart voting themselves.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] LXR targets

[Julien Pauli]

Hi,


Our LXR is actually wrong.

It indexes "php-src" and "PHP_TRUNK", but both point to the same codebase.

It also indexes "phpng", which nowadays is useless.

Finally , it does NOT index the new PHP-7.0 branch, which to me seems
like the biggest problem.


Could someone from system@ have a look at it when possible ?

Thank you very much.


Julien

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Sean DuBois]

On Wed, Oct 21, 2015 at 03:54:48PM +, Dan Ackroyd wrote:
> Hi Sean, internals,
>
> While I support this RFC, it seems that the actual implementation is
> still under discussion.
>
> In particular, whether the RFC is going to allow protected constants
> in an interface is not clear.
>
> In the text of the RFC, on one line it says: "This RFC propose PHP
> support class constant visibility that mirror the behaviour of method
> and property visibility." This would imply that protected constants
> are not allowed, as protected methods are not allowed in interfaces.
>
> Just below it says: "//Interfaces only support protected/public const,
> and a compile time error will be throw for privates" Which says
> clearly that protected constants _would_ be allowed.
>
> Please can you update the text of the RFC?
>
> Unfortunately, that may need a restart of the voting :-\ However that
> should just be a formality as it seems to be a popular RFC.
>
> cheers
> Dan
>
> --
Hi!

That is an unfortunate mistake on my part. The *proper* way to adjust
visibility of a trait from a class constant is the following.

trait myTrait {
public const FOO = 'bar'
}

class myClass {
use myTrait { FOO as protected; }
}

class myClass {
use myTrait { FOO as private; }
}

We should not allow anything besides public in trait, this mirrors the design 
of methods.

If this is right (mind just sending an ACK to make sure I got it right this 
time) I
will update the RFC. Who decides if/when we should restart voting?

thanks

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Dan Ackroyd]

On 21 October 2015 at 16:17, Sean DuBois  wrote:
>
>  I will update the RFC. Who decides if/when we should restart voting?


"The PHP RFC rules is more what you'd call "guidelines" than actual
rules" as there are no set decision makers or rules enforcers.

The rules set down for this scenario are, in theory, pretty clear:

> Based on the result of the votes and the discussion there are three possible 
> outcomes:
>
> A serious issue with your RFC needs to be addressed: update the status of 
> your RFC
> page and its section on https://wiki.php.net/RFC to “Under Discussion” and 
> continue
> again from step 5.

But in practice what is a 'serious issue' is not defined.

I think it is almost always right to restart a vote for anything other
than the most minor change as:

i) It avoids setting a precedent where an RFC is changed substantially
while under vote.

ii) It avoids anyone being able to complain that either what was
implemented was not what they voted for, or for people to be able to
ask that the 'missing' behaviour be implemented as a bug-fix.

And yes, in this case the RFC restarting the vote could be considered overkill.

I can't see anyone actually changing their mind due to the text being
clarified, and so the result of the vote will be overwhelming support,
again. But following the rules scrupulously when the outcome is clear,
makes it harder for people to bend the rules when the outcome isn't as
clear.

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Sean DuBois]

On Wed, Oct 21, 2015 at 12:31:58PM -0500, Aaron Piotrowski wrote:
> Hi Sean,
>
> > On Oct 21, 2015, at 11:17 AM, Sean DuBois  wrote:
> >
> > On Wed, Oct 21, 2015 at 03:54:48PM +, Dan Ackroyd wrote:
> >> Hi Sean, internals,
> >>
> >> While I support this RFC, it seems that the actual implementation is
> >> still under discussion.
> >>
> >> In particular, whether the RFC is going to allow protected constants
> >> in an interface is not clear.
> >>
> >> In the text of the RFC, on one line it says: "This RFC propose PHP
> >> support class constant visibility that mirror the behaviour of method
> >> and property visibility." This would imply that protected constants
> >> are not allowed, as protected methods are not allowed in interfaces.
> >>
> >> Just below it says: "//Interfaces only support protected/public const,
> >> and a compile time error will be throw for privates" Which says
> >> clearly that protected constants _would_ be allowed.
> >>
> >> Please can you update the text of the RFC?
> >>
> >> Unfortunately, that may need a restart of the voting :-\ However that
> >> should just be a formality as it seems to be a popular RFC.
> >>
> >> cheers
> >> Dan
> >>
> >> --
> > Hi!
> >
> > That is an unfortunate mistake on my part. The *proper* way to adjust
> > visibility of a trait from a class constant is the following.
> >
> >trait myTrait {
> >public const FOO = 'bar'
> >}
> >
> >class myClass {
> >use myTrait { FOO as protected; }
> >}
> >
> >class myClass {
> >use myTrait { FOO as private; }
> >}
> >
> > We should not allow anything besides public in trait, this mirrors the 
> > design of methods.
> >
> > If this is right (mind just sending an ACK to make sure I got it right this 
> > time) I
> > will update the RFC. Who decides if/when we should restart voting?
> >
> > thanks
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> I think you may have misunderstood. Traits should be able to have protected 
> and private constants. The issue that Dan pointed out is with an interface 
> having a protected constant in the example code, contradicting what was 
> written prior in the RFC about mirroring the current behavior of method and 
> property visibility.
>
> Interfaces should only be allowed to have public constants. Protected 
> constants would infer that the interface knows something about 
> implementation, which doesn’t make sense for an interface. I think the RFC 
> should be updated to remove this ambiguity.
>
> I’m not sure if this would require the vote to be restarted, as I doubt 
> anyone who voted yes would now vote no with this change.
>
> Regards,
> Aaron Piotrowski
>
>
Argh I am rushing, again my mistake.

I just updated the RFC to reflect this, sorry about the confusion
everyone! The intent of the RFC is to just copy existing patterns from
methods/properties so as non-controversial as possible.

For now I am not going to restart the vote, if anyone feels
this decision is wrong I am more than happy to restart the vote.
However, don't want to inconvenience the people who have already taken
time to vote.

thanks!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] SQLite 3.9.X in PHP 7.0.0RC6?

[Kalle Sommer Nielsen]

Hi Mark

2015-10-21 12:29 GMT+02:00 Mark Tomlin :
> Thanks for the reply, I use the SQLite built into PHP pretty much
> exclusively for my projects that that's handy to know when I target for PHP
> 7.

I think from an RM's point of view, it is a little too soon, plus we
are in RC stage now to merge it. I don't see a reason for why we can't
however merge it into a 7.0.x release once we know it is a little more
stable (which also goes for 7.0).


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Aaron Piotrowski]

Hi Sean,

> On Oct 21, 2015, at 11:17 AM, Sean DuBois  wrote:
> 
> On Wed, Oct 21, 2015 at 03:54:48PM +, Dan Ackroyd wrote:
>> Hi Sean, internals,
>> 
>> While I support this RFC, it seems that the actual implementation is
>> still under discussion.
>> 
>> In particular, whether the RFC is going to allow protected constants
>> in an interface is not clear.
>> 
>> In the text of the RFC, on one line it says: "This RFC propose PHP
>> support class constant visibility that mirror the behaviour of method
>> and property visibility." This would imply that protected constants
>> are not allowed, as protected methods are not allowed in interfaces.
>> 
>> Just below it says: "//Interfaces only support protected/public const,
>> and a compile time error will be throw for privates" Which says
>> clearly that protected constants _would_ be allowed.
>> 
>> Please can you update the text of the RFC?
>> 
>> Unfortunately, that may need a restart of the voting :-\ However that
>> should just be a formality as it seems to be a popular RFC.
>> 
>> cheers
>> Dan
>> 
>> --
> Hi!
> 
> That is an unfortunate mistake on my part. The *proper* way to adjust
> visibility of a trait from a class constant is the following.
> 
>trait myTrait {
>public const FOO = 'bar'
>}
> 
>class myClass {
>use myTrait { FOO as protected; }
>}
> 
>class myClass {
>use myTrait { FOO as private; }
>}
> 
> We should not allow anything besides public in trait, this mirrors the design 
> of methods.
> 
> If this is right (mind just sending an ACK to make sure I got it right this 
> time) I
> will update the RFC. Who decides if/when we should restart voting?
> 
> thanks
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

I think you may have misunderstood. Traits should be able to have protected and 
private constants. The issue that Dan pointed out is with an interface having a 
protected constant in the example code, contradicting what was written prior in 
the RFC about mirroring the current behavior of method and property visibility.

Interfaces should only be allowed to have public constants. Protected constants 
would infer that the interface knows something about implementation, which 
doesn’t make sense for an interface. I think the RFC should be updated to 
remove this ambiguity.

I’m not sure if this would require the vote to be restarted, as I doubt anyone 
who voted yes would now vote no with this change.

Regards,
Aaron Piotrowski


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] LXR targets

[Anatol Belski]

Hi Julien,

> -Original Message-
> From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of
> Julien Pauli
> Sent: Wednesday, October 21, 2015 7:05 PM
> To: PHP Systems ; PHP Internals 
> Subject: [PHP-DEV] LXR targets
> 
> Hi,
> 
> 
> Our LXR is actually wrong.
> 
> It indexes "php-src" and "PHP_TRUNK", but both point to the same codebase.
> 
> It also indexes "phpng", which nowadays is useless.
> 
> Finally , it does NOT index the new PHP-7.0 branch, which to me seems like the
> biggest problem.
> 
> 
> Could someone from system@ have a look at it when possible ?
> 
Yeah, thanks for bringing this up again. I was pinging systems@ several times 
yet, but seems all the people with the access to the box are busy. Maybe one 
could find a moment for that now.

Regards

Anatol 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[Julien Pauli]

On Wed, Sep 30, 2015 at 12:08 AM, Johannes Schlüter
 wrote:
> On Tue, 2015-09-29 at 21:04 +0300, S.A.N wrote:
>>
>> When Node.js appear async/await, many developers and projects will
>> migrate to a Node.js, if PHP is not implement async APIs.
>>
>> Hopefully, Dmitry Stogov and others, will make another surprise:
>> PHP-Next-Async? :)
>
> My claim is that if you're doing something CPU-intensive which can be
> parallelized in PHP you're most likely doing something wrong but you
> should send this to a processing service. PHP imo needs a stronger
> async-IO story.
>
> Node.js is a completely different thing and people don't switch because
> it has a async feature, but people pick it (aside from hype) since it
> solves different issues.
>
> Anyways. This is irrelevant for *this* thread. This thread was about
> reserving async/await keywords. The discussion has proven that there is
> no clear plan. Therefore we should not reserve any keywords.

Yep I also agree with that, we should reserve when we are sure (voted RFC)
keywords will be used.


Julien.P

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

[Julien Pauli]

On Tue, Sep 29, 2015 at 8:24 PM, Rowan Collins  wrote:
> On 29 September 2015 16:22:30 BST, Thomas Hruska  
> wrote:
>>On 9/29/2015 6:52 AM, Joe Watkins wrote:
>>> We shouldn't reserve words on a whim ...
>>>
>>> async/await doesn't solve any problems for multithreaded programming,
>>at
>>> all ... it solves problems for asynchronous programming, a different
>>> concept ... let's not confuse the two ...
>>
>>Actually, it does.  Asynchronous and multithreaded programming are
>>attempts at solving the exact same problem:  Simultaneously handling
>>multiple data streams in whatever form that takes whether that be
>>network, hard drive, random device XYZ, RAM, or even CPU.  The former
>>says, "Let's wait until we can read or write and continue when we have
>>data."  The latter says, "Let's read and write but let the OS handle
>>context switching to give the appearance of simultaneously handling
>>multiple data streams."
>
> That description may have held a few years ago, when processes and threads 
> were nearly always time-slices on a single CPU core, but surely on a modern 
> system there can be real simultaneity, because even the cheapest  laptop has 
> multiple CPU cores. An asynchronous approach is useful for cases of "do 
> something else while I wait for this background task to complete", but seems 
> less so for "do both of these things actively, using whatever resource is 
> available".
>
> It may be that the first class of problem is more common, but that doesn't 
> make the two equivalent.

Remember that discussion we had some years ago ? ;-)

Async IOs etc...  some parts can still be found on the wiki
(https://wiki.php.net/ideas/php6/engine).

I hope we'll be able to collaborate about this subject for a PHP-Next,
like PHP 8.


Julien.P

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Issues with exceptions and overloading opcodes

[Xinchen Hui]

Hey:



On Wed, Oct 21, 2015 at 10:38 PM, Derick Rethans  wrote:

> On Tue, 20 Oct 2015, Bob Weinand wrote:
>
> > > Am 20.10.2015 um 18:08 schrieb Derick Rethans :
> > >
> > > On Tue, 20 Oct 2015, Bob Weinand wrote:
> > >
> > >>> Am 20.10.2015 um 17:11 schrieb Xinchen Hui :
> > >>>
> > >>> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans  > wrote:
> > >>>
> >  When hacking on Xdebug for PHP 7, I ran into some issues where
> >  PHP would just spin around. This happens when there is an
> >  exception, and I use overloaded opcodes. I wrote a small example
> >  extension at
> >  https://github.com/derickr/php-minimal-opcode-overloading-example
> >  with a test case (
> > 
> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
> >  ) that shows that something is looping in executing opcodes, as
> >  the HANDLE_EXCEPTION iirc doesn't advance to the next opline. I
> >  believe this is a recent enough change, as it only started
> >  happening after I upgraded from about RC1 to latest master.
> > 
> >  Would you care to have a look?
> > 
> > >>> This is introduced by a fix made by Bob,
> > >>> https://github.com/php/php-src/commit/808f62bb
> > >>> 
> > >>>
> > >>> Bob, I am going to revert this for now, since you didn't include a
> > >>> test script to show where the problem was, I am not sure why you
> > >>> made this?
> > >>
> > >> I didn't add any test case as we don't have any APIs in php-src
> > >> using that user_opcode handler. I discussed the change back then
> > >> with Dmitry and committed with his review.
> > >>
> > >> It concretely broke uopz which might throw an exception itself. And
> > >> in turn we realized that for integrity we need to ensure that
> > >> opline == EX(opline) else we'll end up with different behavior in
> > >> global register builds and normal builds.
> > >>
> > >> In general, you should not overload ZEND_HANDLE_EXCEPTION (if you
> > >> need to, have a special handling for it, but never directly
> > >> dispatch to it). It is quite special being the only opcode actually
> > >> allowing EG(exception) to be non-NULL at the start of it.
> > >>
> > >> You are doing an #ifdef ZTS to exempt it… why don't you always
> > >> exempt it?
> > >
> > > Even if I do (like I've just pushed into the extension), the test
> > > still fails because the code loops. So you did break something.
> >
> > Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
> >
> > … maybe I should write
> >
> > if (EG(exception)
> >  && opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode !=
> ZEND_CATCH
> >  && ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN
> && ret != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
> > HANDLE_EXCEPTION();
> > }
> >
> > to allow dispatching for these two opcodes too?
>
> I don't know. Dmitry, Xinchen? I'd like to get this resolved soon..
>
> The commit which cause this problem has been reverted,  so this is
resolved , and regarding the problem which is commit tried to fixed, we
will find a better way to re-fix that.

thanks

> cheers,
> Derick




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] SQLite 3.9.X in PHP 7.0.0RC6?

[Mark Tomlin]

Will we see the bundled SQLite updated to the 3.9.x released in PHP
7.0.0RC6?

-- 
Thank you for your time,
Mark 'Dygear' Tomlin;

Re: [PHP-DEV] SQLite 3.9.X in PHP 7.0.0RC6?

[Lior Kaplan]

I think it's too soon to update to the 3.9 branch (let it get a little more
stable).

But if the RM ask for this change I'll be happy to do that.

Kaplan



On Wed, Oct 21, 2015 at 12:13 PM, Mark Tomlin  wrote:

> Will we see the bundled SQLite updated to the 3.9.x released in PHP
> 7.0.0RC6?
>
> --
> Thank you for your time,
> Mark 'Dygear' Tomlin;
>

Re: [PHP-DEV] SQLite 3.9.X in PHP 7.0.0RC6?

[Mark Tomlin]

Thanks for the reply, I use the SQLite built into PHP pretty much
exclusively for my projects that that's handy to know when I target for PHP
7.

On Wed, Oct 21, 2015 at 5:56 AM, Lior Kaplan  wrote:

> I think it's too soon to update to the 3.9 branch (let it get a little
> more stable).
>
> But if the RM ask for this change I'll be happy to do that.
>
> Kaplan
>
>
>
> On Wed, Oct 21, 2015 at 12:13 PM, Mark Tomlin  wrote:
>
>> Will we see the bundled SQLite updated to the 3.9.x released in PHP
>> 7.0.0RC6?
>>
>> --
>> Thank you for your time,
>> Mark 'Dygear' Tomlin;
>>
>
>


-- 
Thank you for your time,
Mark 'Dygear' Tomlin;