On Mon, Sep 1, 2014 at 6:01 AM, Andrea Faulds wrote:
> Good evening,
>
> Here’s a suggestion: Why don’t we make zend_parse_parameters emit
""Why not" is usually not a very good reason for a change in the language
syntax. " -- Stas
> E_RECOVERABLE_ERROR on failure, rather than just emitting E_WAR
Good evening,
Here’s a suggestion: Why don’t we make zend_parse_parameters emit
E_RECOVERABLE_ERROR on failure, rather than just emitting E_WARNING and
returning FAILURE (causing the caller to typically bail out and return NULL)?
This would bring it into line with userland type hints, which also c
Hi Pierre,
On Sun, August 31, 2014 14:12, Pierre Joye wrote:
> Hi Anatol,
>
>
> Thanks!
>
>
> For what I see it should have no impact, either mem usage or perf but
> when such offset is used, in 64bit.
>
> However some numbers are better, could you provide some using exclusively
> this syntax and
On Sun, Aug 31, 2014 at 2:08 PM, Tjerk Meesters
wrote:
> Hi Ferenc,
>
> On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs wrote:
>
>
>
>
> On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters
> wrote:
>
>> Hi internals (again),
>>
>> Recently I’ve done a small assessment on how feasible it is to remove
>>
Hi,
Another possible behaviour would be to trigger a fatal when trying to
access a partially destroyed object in ob_start.
It took me a while to actually figure out why the memory was corrupted
when doing stuff in ob_start() (even before playing with the AMQP lib).
Having a fatal would allow me
Hi!
> Instead of iterating through all objects and setting a flag, can't we
> set a global flag that object dtors are not called after this point?
We could, but that would probably break some code that expects dtors to
be actually called. E.g. in the bug, the library there seems to do a lot
from
On 31 Aug 2014, at 20:34, Chris Wright wrote:
> I have on occasion come across code that uses split(), more often than not
> as if it were explode() with a literal delimiter.
>
> If ereg is to be removed (for which I am +1) does anyone have any
> objections to making split() into an alias of ex
I have on occasion come across code that uses split(), more often than not
as if it were explode() with a literal delimiter.
If ereg is to be removed (for which I am +1) does anyone have any
objections to making split() into an alias of explode()? This would also be
consistent with the join() -> i
Fine for OCI8 and PDO_OCI. I'll let you know when to re-enable.
On Aug 31, 2014 7:43 AM, Nuno Lopes wrote:
>
> Hi,
>
> I've disabled the following extensions from the build of PHP_HEAD at the
> gcov.php.net server:
> - oci8
> - pdo_oci
> - sybase_ct
> - litespeed SAPI
>
> These extensions
On Sun, Aug 31, 2014 at 8:32 AM, Pierre Joye wrote:
> Heck... No :)
>
> Or we mark it as dead right away, single release for the sake of it and let
> it die.
I think a single, unmaintained release of ext/ereg in PECL would be
acceptable, but I don't really see the point of that either. If you
sti
Hi,
> Sara Golemon hat am 16. August 2014 um 19:39 geschrieben:
> > On Aug 16, 2014, at 9:09, Timm Friebe wrote:
> > two weeks ago, the RFC `Catchable "Call to a member function bar() on a
> > non-object"` was accepted by a vote. I don't have commit access to
> > php-src/Zend,
>
> If it's not so
Hi,
> I've disabled the following extensions from the build of PHP_HEAD at the
> gcov.php.net server:
[...]
> - sybase_ct
You're right, this is unmaintained.
Timm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I've disabled the following extensions from the build of PHP_HEAD at the
gcov.php.net server:
- oci8
- pdo_oci
- sybase_ct
- litespeed SAPI
These extensions don't seem to have been upgraded to the new APIs.
Therefore I've disabled them so that we can test the other (majority)
extensions.
Heck... No :)
Or we mark it as dead right away, single release for the sake of it and let
it die.
On Aug 31, 2014 2:08 PM, "Tjerk Meesters" wrote:
> Hi Ferenc,
>
> On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs wrote:
>
> >
> >
> >
> > On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters <
> tjerk.meest
+1
Kill it with fire and throw more gasoline ontop of the fire.
On Sun, Aug 31, 2014 at 8:08 AM, Tjerk Meesters
wrote:
> Hi Ferenc,
>
> On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs wrote:
>
> >
> >
> >
> > On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters <
> tjerk.meest...@gmail.com> wrote:
> >
Hi Anatol,
Thanks!
For what I see it should have no impact, either mem usage or perf but when
such offset is used, in 64bit.
However some numbers are better, could you provide some using exclusively
this syntax and using common apps pls? Only to be sure.
Cheers,
Pierre
On Aug 31, 2014 1:57 PM,
Hi Ferenc,
On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs wrote:
>
>
>
> On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters
> wrote:
> Hi internals (again),
>
> Recently I’ve done a small assessment on how feasible it is to remove
> ext/ereg from the project for the next major version. This is t
On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
> On Fri, Aug 29, 2014 at 11:49 PM, Anatol Belski
> wrote:
>
>> Hi,
>>
>>
>> while refining the big string support, it turned out that we've an
>> issue. The syntax like $s[42] = 'x'; is currently inconsistend, because
>> we have uint32 for string
On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters
wrote:
> Hi internals (again),
>
> Recently I’ve done a small assessment on how feasible it is to remove
> ext/ereg from the project for the next major version. This is the result
> (so far):
>
> https://github.com/datibbaw/php-src/compare/kill-ereg
Hi,
I've submitted a PR to make the hash_equals function leak less information
about compared strings' lengths (benchmark and use cases available in
comments): https://github.com/php/php-src/pull/792
Trying to hide length is needed to replace Symfony and Joomla PHP
implementations by hash_equals
On Sun, Aug 31, 2014 at 3:33 AM, Stas Malyshev
wrote:
> Hi!
>
> I was looking at bug https://bugs.php.net/bug.php?id=67644 and it looks
> like we have a bit of a problem with output buffering and dtors on
> shutdown. Basically, right now our code looks like this:
>
> /* 2. Call all possib
On 30.08.2014 23:26, Robert Williams wrote:
> If the syntax of heredocs/nowdocs is to be loosened, the biggest aspect I’d
> like to see addressed is indentation. I can certainly see how it would be
> nice to loosen the restrictions around the post-closing-token newline to
> allow easier use in p
22 matches
Mail list logo
