Am Mo., 4. März 2019 um 18:00 Uhr schrieb Nikita Popov :
>
> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski wrote:
>
> >
> >
> > On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov wrote:
> >
> >> Hi internals,
> >>
> >> I think it is well known that == in PHP is a pretty big footgun. It
> >> doesn't
> >
On Wed, Mar 6, 2019 at 1:49 PM Peter Kokot wrote:
>
> First of all, thank you for the nomination and suggestion. Yes, of
> course, I'd be honoured to do that part. Overall, it's no secret I
> still have a lot of catching up to do as far as PHP core is concerned,
> but for the PHP 7.4 timeframe I
Hello,
On Wed, 6 Mar 2019 at 15:31, Joe Watkins wrote:
>
> Hi all,
>
> It would be nice to hear from Peter , do you want to take on this role ?
>
> You would have my vote, obviously, but we like people to volunteer, it's
> not a small or short commitment.
>
> Cheers
> Joe
>
> On Wed, 6 Mar 2019 at
I voted no for similar reason. I understand the problem we have, but I really
don't like the idea that just introduce a new method, well actually a pair of
new methods, to solve this problem, without any plan to stop userland developer
from the wrong use case. The deprecating plan also sounds to
On Mon, Mar 4, 2019 at 11:25 AM Johannes Schlüter
wrote:
> On Mo, 2019-03-04 at 07:30 -0800, Steven Penny wrote:
> > On Mon, 04 Mar 2019 02:23:46, Peter Kokot wrote:
> > >
> > > Now, interesting is that in bash and some langs (where the main
> > > environment is CLI), there is by default newline
Hi all,
It would be nice to hear from Peter , do you want to take on this role ?
You would have my vote, obviously, but we like people to volunteer, it's
not a small or short commitment.
Cheers
Joe
On Wed, 6 Mar 2019 at 10:39, Kalle Sommer Nielsen wrote:
> Den ons. 6. mar. 2019 kl. 11.03 skre
> How do people feel about deprecating Serializable in 7.4 and
> removing in 8.0 (not as part of this RFC but a separate one)? The
> deprecation warning would only be thrown if Serializable is implemented but
> the class has no __serialize/__unserialize. The timeline would be a bit
> aggressive in
On 25.02.2019 at 13:44, Peter Cowburn wrote:
> On Mon, 25 Feb 2019 at 11:29, Joe Watkins wrote:
>
>> Whoever creates the pecl package would be listed as maintainer, which may
>> explain silence :)
>>
>> I'm not sure who has karma for creating repos on git.php.net either, I
>> may ?
>
> FYI: dsp
Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov :
>
> On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann wrote:
>
> > Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:
> > > I'd like to suggest Peter Kokot for this role.
> >
> > Seconded.
> >
>
> Thirded.
Fourthed.
--
regards,
Kalle Sommer Ni
On Mon, Mar 4, 2019 at 9:18 PM Marc wrote:
>
> On 04.03.19 10:08, Nikita Popov wrote:
> > On Mon, Mar 4, 2019 at 6:31 AM Marc wrote:
> >
> >> (sorry for top posting)
> >>
> >> Hi Nikita,
> >>
> >> as for the question about magic methods vs. interface.
> >>
> >> I have the feeling that it could b
On Wed, Mar 6, 2019 at 9:47 AM Stanislav Malyshev
wrote:
> Hi!
>
> > This is intended x86 specific optimization. The behavior of SHR is
> > documented.
> >
> > See https://c9x.me/x86/html/file_module_x86_id_285.html
> >
> > "The count is masked to 5 bits, which limits the count range to 0 to 31"
On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann wrote:
> Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:
> > I'd like to suggest Peter Kokot for this role.
>
> Seconded.
>
Thirded.
On Wed, Mar 6, 2019 at 7:41 AM Markus Fischer wrote:
> Hello,
>
> On 06.03.19 01:16, Andrea Faulds wrote:
> > https://wiki.php.net/rfc/trailing_whitespace_numerics
> >
> > I expect this should be an uncontroversial proposal, but maybe I'm
> > jinxing it there. I hope you all like it. :)
> >
> > T
Hi!
> This is intended x86 specific optimization. The behavior of SHR is
> documented.
>
> See https://c9x.me/x86/html/file_module_x86_id_285.html
>
> "The count is masked to 5 bits, which limits the count range to 0 to 31"
> on 32-bit systems.
I see. But I wonder whether the compiler will always
Hi!
> But I'm not sure how it's supposed to work. Is it correct that on GCC
> (and clang, presumably, since it defines __GNUC__) accept long bitshifts
> and do the right thing with argument like 138? Is it documented
> anywhere? Or is there a bug here?
>
>
> This is a bug, yes. O
On Wed, Mar 6, 2019 at 1:28 AM Stanislav Malyshev
wrote:
> Hi!
>
> I've been working on running PHP with undefined behavior sanitizer
> (http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) and I've
> encountered a weird error while running PHP:
>
> /src/php-src/Zend/zend_alloc.c:585:9: ru
16 matches
Mail list logo