Hi Pierre,
I'm glad, you agree to rename IS_INT back to IS_LONG.
zend_long and size_t usage looks fine.
I see no problems changing zend_string related API and related macros
introduced in NG. They are new for everyone.
I hope, the changes won't make API less clear or useful (so it would be
great
Hi Matt,
Can you provide instruction how to install and run Joomla and Symfony unit
tests.
Thanks. Dmitry.
On Thu, Aug 21, 2014 at 10:27 PM, Matt Ficken
wrote:
> Master (with PHPNG) builds on Windows (our snapshot build servers were
> never interrupted BTW), though extensions including PDO,
Hi Lior,
On Mon, August 25, 2014 11:09, Lior Kaplan wrote:
> Hi Anatol,
>
>
> It seems you've done some changes to the date extension recently, could
> you take a look at these two failures.
>
> Dmitry - FYI in case it's phpng related.
>
>
> Bug #67118 crashes in DateTime when this used after fail
Hi Derick,
Could you please take a look into these tests failures.
I actually, think that the new behavior is right.
Calls to parent::__constructor() shouldn't change value of already
constructed $this.
The expectation of ext/data/tests/bug67118_2.phpt looks completely wrong.
The actual output o
I'll have to check tomorrow whether its incorrect. I know it shouldn't change
this, but if I recall correctly, changing this now broke some code.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
On 25 Aug, 2014, at 5:43 pm, Dmitry Stogov wrote:
> Hi Derick,
>
> Could you please take a look into these tests failures.
> I actually, think that the new behavior is right.
> Calls to parent::__constructor() shouldn't change value of already
> constructed $this.
I think the following com
Now we have just 5 failed tests related to 2 unsolved incompatibilities
introduced by phpng.
I'll take care about them. Don't fix them by changing expectation yet.
Thanks. Dmitry.
On Mon, Aug 25, 2014 at 2:01 PM, Tjerk Meesters
wrote:
> Hi!
>
> On 25 Aug, 2014, at 5:43 pm, Dmitry Stogov wrote
On Aug 25, 2014 9:22 AM, "Dmitry Stogov" wrote:
>
> Hi Pierre,
>
> I'm glad, you agree to rename IS_INT back to IS_LONG.
>
> zend_long and size_t usage looks fine.
>
> I see no problems changing zend_string related API and related macros
introduced in NG. They are new for everyone.
> I hope, the c
On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye wrote:
>
> On Aug 25, 2014 9:22 AM, "Dmitry Stogov" wrote:
> >
> > Hi Pierre,
> >
> > I'm glad, you agree to rename IS_INT back to IS_LONG.
> >
> > zend_long and size_t usage looks fine.
> >
> > I see no problems changing zend_string related API and r
On Aug 25, 2014 12:56 PM, "Dmitry Stogov" wrote:
>
>
>
>
> On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye wrote:
>>
>>
>> On Aug 25, 2014 9:22 AM, "Dmitry Stogov" wrote:
>> >
>> > Hi Pierre,
>> >
>> > I'm glad, you agree to rename IS_INT back to IS_LONG.
>> >
>> > zend_long and size_t usage looks
On Mon, Aug 25, 2014 at 2:59 PM, Pierre Joye wrote:
>
> On Aug 25, 2014 12:56 PM, "Dmitry Stogov" wrote:
> >
> >
> >
> >
> > On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye
> wrote:
> >>
> >>
> >> On Aug 25, 2014 9:22 AM, "Dmitry Stogov" wrote:
> >> >
> >> > Hi Pierre,
> >> >
> >> > I'm glad, you
On Aug 25, 2014 1:14 PM, "Dmitry Stogov" wrote:
>
>
>
>
> On Mon, Aug 25, 2014 at 2:59 PM, Pierre Joye wrote:
>>
>>
>> On Aug 25, 2014 12:56 PM, "Dmitry Stogov" wrote:
>> >
>> >
>> >
>> >
>> > On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye
wrote:
>> >>
>> >>
>> >> On Aug 25, 2014 9:22 AM, "Dmitry
On Sat, Aug 23, 2014 at 1:58 AM, Ferenc Kovacs wrote:
>
>
>
> 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 th
Le 17/08/2014 11:25, Ferenc Kovacs a écrit :
> 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 some blocker i
On Mon, Aug 25, 2014 at 2:38 PM, Remi Collet wrote:
> Le 17/08/2014 11:25, Ferenc Kovacs a écrit :
> > 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 (w
On Mon, Aug 25, 2014 at 1:22 PM, Ferenc Kovacs wrote:
>
>
>
> On Sat, Aug 23, 2014 at 1:58 AM, Ferenc Kovacs wrote:
>>
>>
>>
>>
>> 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
On Mon, Aug 18, 2014 at 6:41 PM, Nikita Popov wrote:
> Hi internals!
>
> I've opened the vote on the Abstract Syntax Tree RFC:
>
> https://wiki.php.net/rfc/abstract_syntax_tree#vote
>
The Abstract Syntax Tree RFC has been accepted unanimously, with 47 votes
in favor and 0 against.
I'll merg
Am 25.08.2014 um 19:01 schrieb Nikita Popov:
> The Abstract Syntax Tree RFC has been accepted unanimously, with 47
> votes in favor and 0 against.
Yay! :-) Thank you for your work, Nikita.
> I'll merge the patch as soon as the int64 naming issues are resolved.
Do you when you'll get around to i
On Mon, Aug 25, 2014 at 7:07 PM, Sebastian Bergmann
wrote:
> Am 25.08.2014 um 19:01 schrieb Nikita Popov:
> > The Abstract Syntax Tree RFC has been accepted unanimously, with 47
> > votes in favor and 0 against.
>
> Yay! :-) Thank you for your work, Nikita.
>
> > I'll merge the patch as soon as t
Hi!
> 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
If we're talking the plunge of putting exceptions into the core
>
> If we're talking the plunge of putting exceptions into the core engine,
> wouldn't it make sense to convert most of the fatal errors (especially
> the "catchable" ones) to exceptions too? Most of them (except for out of
> memory, timeouts and such) don't really require the engine to shut down,
On Mon, Aug 25, 2014 at 11:39 PM, Stas Malyshev
wrote:
> Hi!
>
> > 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
> p
Hi!
> This is something that Nikita had originally proposed in an RFC
> (https://wiki.php.net/rfc/engine_exceptions) but postponed until after 5.6.
>
> I have a feeling we'll be hearing about its resurrection soon enough.
5.6 was not a good place for it, but PHP 7 very well may be. Some
cleanup
On Tue, Aug 26, 2014 at 1:12 AM, Stas Malyshev
wrote:
> Hi!
>
> > This is something that Nikita had originally proposed in an RFC
> > (https://wiki.php.net/rfc/engine_exceptions) but postponed until after
> 5.6.
> >
> > I have a feeling we'll be hearing about its resurrection soon enough.
>
> 5.6
On 26 Aug 2014, at 00:53, Benjamin Eberlei wrote:
> Depends, registering for shutdown handlers and catching fatals is a pretty
> common thing. If EngineException does not get caught, it should produce an
> E_FATAL again with the correct error code.
Exceptions already do this, do they not? I don
25 matches
Mail list logo