On 09/13/2016 02:07 AM, Larry Garfield wrote:
> On 09/12/2016 06:47 PM, Stephen Reay wrote:
>>> Ah, I did see that one, but there was a lot of discussion after it
>>> so I thought the idea evolved. Response below based on skimming the
>>> responses after that as well...
>>>
>>> It sounds like th
Hi,
I was skeptical about this idea, but the PoC looks interesting and quite simple.
This might be too big change for 7.*, if we won't completely hide
implementation details for extensions using existing macros...
I'm not sure if this will lead to performance improvement.
On one hand, we wo
Hi Ben!
Benjamin Coutu wrote:
I was wondering if it would make sense to store small strings (length <= 7)
directly inside the zval struct, thereby avoiding the need to extra allocate a
zend_string, which would also not entail any costly indirection and refcounting
for such strings.
The idea
Results for project PHP master, build date 2016-09-13 06:24:51+03:00
commit: 409ff32
previous commit:ca5cfac
revision date: 2016-09-12 17:36:33-04:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hello everyone,
I was wondering if it would make sense to store small strings (length <= 7)
directly inside the zval struct, thereby avoiding the need to extra allocate a
zend_string, which would also not entail any costly indirection and refcounting
for such strings.
The idea would be to add
>
> > I noticed that there's a stale version of a supported package on pecl:
> > https://pecl.php.net/package/pdo_dblib
> >
> > Should this be removed to avoid confusion?
>
> Alternatively a note might be added, as it has been done for
> PECL/domxml, for instance.
>
> Either way, that should also b
On 13/09/2016 14:07, Christoph M. Becker wrote:
On 13.09.2016 at 14:53, Adam Baratz wrote:
I noticed that there's a stale version of a supported package on pecl:
https://pecl.php.net/package/pdo_dblib
Should this be removed to avoid confusion?
Alternatively a note might be added, as it has b
On 13.09.2016 at 14:53, Adam Baratz wrote:
> I noticed that there's a stale version of a supported package on pecl:
> https://pecl.php.net/package/pdo_dblib
>
> Should this be removed to avoid confusion?
Alternatively a note might be added, as it has been done for
PECL/domxml, for instance.
Eit
Hi,
I noticed that there's a stale version of a supported package on pecl:
https://pecl.php.net/package/pdo_dblib
Should this be removed to avoid confusion?
Thanks,
Adam
I don't think anyone is arguing that literally no one is using PEAR
packages, but looking at the ~6 months old archive.org mirror of
http://pear.php.net/package-stats.php (available at
https://web.archive.org/web/20160315083551/http://pear.php.net/package-stats.php),
the largest package, PEAR itsel
Hi Rowan,
On Tue, Sep 13, 2016 at 6:47 PM, Rowan Collins wrote:
> To me, uniqid() is useful because it is a quick way of getting a short
> string that's likely to be fairly unique. If that is its purpose, then
> making it slower, and its output longer, are not helping anybody.
>
> If it's purpose
On Mon, 12 Sep 2016, Niklas Keller wrote:
> 2016-09-12 10:21 GMT+02:00 Derick Rethans :
>
> > On Mon, 12 Sep 2016, Pierre Joye wrote:
> >
> > > This RFC is about stop bundling it with the php releases and propose
> > > composer/pickle instead. Everything else has nothing to do with this
> > > RFC
On 13/09/16 00:47, Stephen Reay wrote:
> Regarding identity, I’m going to refer back to the DateTimeImmutable class. I
> know its not the same implementation, but honestly I don’t think that
> matters. Developers use PHP because they generally *don’t* have to worry
> about the internal details o
On 13/09/2016 02:07, Yasuo Ohgaki wrote:
I pasted simple benchmark to the PR.
New code uses about 2x cpu time on my Fedora 24. CSPRNG uses more complex
code than php_combined_lcg(), so this is expected.
To me, this is at least as important as changing the length and
character range of the outp
On 13/09/16 01:44, Pierre Joye wrote:
> On Tue, Sep 13, 2016 at 3:06 AM, Lester Caine wrote:
>> On 12/09/16 20:31, Christoph M. Becker wrote:
>>> On 11.09.2016 at 12:35, Lester Caine wrote:
>>>
On 11/09/16 11:05, Christoph M. Becker wrote:
>>>
I have already debugged the problems and wil
Sent: Monday, September 12, 2016 12:34 PM
>To: Tony Marston
>Cc: Sherif Ramadan ; Stanislav Malyshev ; internals@lists.php.net
>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
>
>On Mon, Sep 12, 2016 at 9:32 AM, Tony Marston wrote:
>
>Sent: Sunday, September 11, 201
Proposed operator overloading and magic methods to compare with other
objects
is very good idea, I like it a lot, there even may be additional
restriction provided
with my other RFC https://wiki.php.net/rfc/object-typehint
But I think this goal should be provided in separate RFC as it is very
usef
Hi Kauzo,
On Tue, Sep 13, 2016 at 3:23 PM, Kazuo Oishi wrote:
>> Current implementation is good enough for most cases, but it can be better.
>
> I agree this legacy design API works good enough for most cases.
>
> So, I think it should not be changed in BC break way.
I updated the RFC.
2nd param
18 matches
Mail list logo
