Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

[Scott Arciszewski]

On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez  wrote:
> Ah, I didn't realize this thread existed. I had just commented on the old
> one, but the point still stands:
>
> PHP 7.0 RC1 was just tagged.
> Shouldn't this be a relatively high priority to fix/decide so we don't end
> up with behavior that can't be fixed until PHP 8.0?
>
> On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller  wrote:
>>
>> >
>> > Okay, great, we have people on both sides on this discussion. I hope
>> > nobody minds if I sit this part out.
>> >
>> > What specifics need to be discussed? Should somebody set up a poll? (I
>> > don't know how to do that.)
>>
>>
>> You can find information on how to setup a poll in step 6 here:
>> https://wiki.php.net/rfc/howto
>>
>> Regards, Niklas

I agree that this should be a relatively high priority. I'm not sure
what the next steps would be. (Aside: I still have a PR I need to
write that I've been holding off on until the fate of PHP 7's CSPRNG
feature is determined.)

Can we reach some sort of consensus on throw new Exception vs throw new Error?

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

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

[PHP-DEV] FYI: Linux Foundation CII Draft

[Yasuo Ohgaki]

Hi all,

Some of us may know already. Linux Foundation CII project
https://www.coreinfrastructure.org/
released draft badge program.

https://github.com/linuxfoundation/cii-best-practices-badge

We may consider badge program compliance in the future.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Adding phpdbg_webhelper to .gitignore

[Christopher Jones]

On 19/08/2015 9:17 pm, Bob Weinand wrote:

Am 19.08.2015 um 01:46 schrieb Christopher Jones :
On 12/08/2015 11:31 pm, Ferenc Kovacs wrote:


On Wed, Aug 12, 2015 at 1:55 PM, Christopher Jones mailto:christopher.jo...@oracle.com>> wrote:


Bob,

Is the ext/phpdbg_webhelper sym link really needed ?  If so, can you add it 
to .gitignore.

Thank you,

Chris

--
http://twitter.com/ghrd

Bob had a suggested change which would make the *nix build process more 
flexible and would allow us to get rid of the symlinking:
http://www.serverphorums.com/read.php?7,1061039
not sure why was this never pushed though.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu



Bob: ping.

Chris

--
http://twitter.com/ghrd


As Ferenc wrote, 
https://github.com/php/php-src/compare/master...bwoebi:soft_ext_dir patch 
should solve these issues. Seems I have forgotten it...

I'll look again at it today and then eventually finally push it.

Bob



Thank you.

I saw the patch.

Chris

--
http://twitter.com/ghrd

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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: bump versions: configure.in main/php_version.h

[Stanislav Malyshev]

Hi!

> Hm... But isn't then the safe route to revert set_exception_handler to
> old behaviour
> and take the rest in 7.1? I mean depending on size of problems it takes

It's not that safe if set_exception_handler is used as "handler of last
resort". Because then we have a whole class of exceptions (not
Exceptions but still exceptions) that are not caught by it.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] C++ Extensions

[Kalle Sommer Nielsen]

(sorry for top posting)

Hi Sara,

I think such will be just fine for RC2, unless Anatol got any object, go
ahead.

-K
On Aug 20, 2015 6:49 PM, "Sara Golemon"  wrote:

> On Wed, Aug 19, 2015 at 1:10 PM, Stanislav Malyshev 
> wrote:
> >> A) Adding those defines prior to including stdint.h
> >> B) Expecting C++ ext devs to define those before including php.h
> >> C) Modifying zend_long.h to use things like
> >> std::numeric_limits() when __cplusplus is defined
> >>
> >> A may (potentially) have unexpected side-effects
> >> B has precedent (see ext/intl/config.m4)
> >> C makes the ifdef block that's already there notably more complex
> >
> > I'd rather have everything solved by php.h than having magic
> > incantations that one has to do prior to it. I would prefer A unless
> > there's really something wrong with it that. Given that these macros are
> > on their way out anyway:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=15366
> > I'm not sure it's that dangerous to define them in the meantime.
> >
> I agree! :)  Though I didn't realize they were deprecated anyway.
>
> Second question, is it too late to put it in 7.0.0?
> Happy enough to put it behind #ifdef __cplusplus to limit the exposed
> surface area.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] C++ Extensions

[Stanislav Malyshev]

Hi!

> Second question, is it too late to put it in 7.0.0?
> Happy enough to put it behind #ifdef __cplusplus to limit the exposed
> surface area.

That doesn't look like a radical change, so unless RM (or somebody
else?) disapproves my opinion is it can be in 7.0.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] C++ Extensions

[Sara Golemon]

On Wed, Aug 19, 2015 at 1:10 PM, Stanislav Malyshev  wrote:
>> A) Adding those defines prior to including stdint.h
>> B) Expecting C++ ext devs to define those before including php.h
>> C) Modifying zend_long.h to use things like
>> std::numeric_limits() when __cplusplus is defined
>>
>> A may (potentially) have unexpected side-effects
>> B has precedent (see ext/intl/config.m4)
>> C makes the ifdef block that's already there notably more complex
>
> I'd rather have everything solved by php.h than having magic
> incantations that one has to do prior to it. I would prefer A unless
> there's really something wrong with it that. Given that these macros are
> on their way out anyway:
> https://sourceware.org/bugzilla/show_bug.cgi?id=15366
> I'm not sure it's that dangerous to define them in the meantime.
>
I agree! :)  Though I didn't realize they were deprecated anyway.

Second question, is it too late to put it in 7.0.0?
Happy enough to put it behind #ifdef __cplusplus to limit the exposed
surface area.

-Sara

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

Re: [PHP-DEV] Benchmark Results for PHP Master 2015-07-30

[Pasindu De Silva]

Hi Andone
Is there a way to better send the results maybe csv attachment or dump some
where.
I can build a small integration.

+1
Pasindu

On Fri, Jul 31, 2015 at 10:01 PM, Andone, Bogdan 
wrote:

> > -Original Message-
> > From: Christopher Jones [mailto:christopher.jo...@oracle.com]
> > Sent: Friday, July 31, 2015 1:12 AM
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Benchmark Results for PHP Master 2015-07-30
> >
> >
> >
> > On 30/07/2015 11:12 pm, Niklas Keller wrote:
> > > 2015-07-30 14:42 GMT+02:00 Andone, Bogdan :
> > >
> > >>> -Original Message-
> > >>> From: Niklas Keller [mailto:m...@kelunik.com]
> > >>> Sent: Thursday, July 30, 2015 1:47 PM
> > >>> To: Pierre Joye
> > >>> Cc: lp_benchmark_robot; PHP internals; l...@lists.01.org
> > >>> Subject: Re: [PHP-DEV] Benchmark Results for PHP Master 2015-07-30
> > >>>
> > >>> 2015-07-30 11:57 GMT+02:00 Pierre Joye :
> > >>>
> >  Hi,
> > 
> >  Does someone has a contact there?
> > 
> >  It would be nicer to have these results combined with what we
> > pushed
> >  on qa.php.net as well.
> > 
> >  Cheers,
> >  Pierre
> > >>>
> > >>>
> > >>> Thought about that as well, results per mail aren't that useful,
> > >>> especially as they're badly formatted for me in GMail (no fixed
> > font).
> > >>> A graph visualizing those numbers would be nice.
> > >>>
> > >>> Regards, Niklas
> > >>
> > >> Hi Guys,
> > >>
> > >> We are glad that our small ticking spam start to be observed :) !
> > >>
> > >> We would like to offer valuable information to the community related
> > to
> > >> performance trends of the PHP project on Intel platforms based on
> > daily
> > >> builds
> > >> and we are open for suggestions for making these results relevant.
> > >>
> > >> We chose to share our numbers as plain text mails for easily seeing
> > the
> > >> summary
> > >> snapshots on discussion lists without the need of other clicks.
> > >> Everybody agrees that plain text is ugly and, yes, you need to have
> > fixed
> > >> font in
> > >> place for having the table formatted correctly. Let’s discuss a
> > better way
> > >> of doing;
> > >> integration with qa.php.net is possible if we find the right
> > interface
> > >> for sharing
> > >> data in an automated way.
> > >>
> > >> Normally  should be the official entry for feedbacks
> > and
> > >> requests but,
> > >> unfortunately, it is not yet operational, so I will be your direct
> > contact
> > >> as I am part
> > >> of the team which deploys this project.
> > >>
> > >>
> > >> Kind regards,
> > >> Bogdan
> > >>
> > >>
> > > Hi Bogdan,
> > >
> > > I think absolute numbers (instead of a %-change) would be better
> > suited for
> > > visualizing performance over time.
> > >
> > > Regards, Niklas
> > >
> >
> > I agree on using absolute numbers.  With percentages it is not
> > immediately obvious whether the change was good or bad.
> >
> > Including the build options would be good.
> >
> > Chris
> >
> > --
> > http://twitter.com/ghrd
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> We can work on build option documentation. Most probably we will offer a
> link on the 01.org containing details on the environment configuration.
> Concerning absolute numbers I am afraid it will be difficult to publish
> them in this way. Our intention is to allow you to see progresses trend in
> the context of Zend PHP project only. We would like to avoid the temptation
> to use the absolute numbers for comparisons with other projects; they might
> be misleading and could drive to wrong conclusions if they are removed from
> the context.
>
> If the PHP baseline is relevant, the fact you see absolute numbers or
> percents should not make a real difference. We chose php-7.0.0beta1 in a
> somehow subjective way as they are no official PHP7 releases yet but we can
> take a PHP5.x release baseline if it looks more relevant.
>
> Kind Regards,
> Bogdan
>



-- 

*Pasindu De Silva**ppasin...@gmail.com *

[PHP-DEV] Benchmark Results for PHP Master 2015-08-20

[lp_benchmark_robot]

Results for project php-src-nightly, build date 2015-08-20 05:00:00+03:00

commit:   7373da78fea6130bffad75bfeff3d2cdce0ddba3

revision_date:2015-08-19 22:27:39+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



Note: Baseline results were generated using release php-7.0.0beta1, with hash

ad8a73dd55c087de465ad80e8715611693bb1460 from 2015-07-07 16:02:13+00:00



---

 benchmark executable unit   relative   change 
since   change since

 std_dev*  
yesterday php-7.0.0beta1

---

   Wordpress 4.2.2 cgi -T1 php opc=on  fps  0.39%  
0.14%  0.70%

   Drupal 7.36 cgi -T1 php opc=on  fps  0.26% 
-0.06%  1.65%

   MediaWiki 1.23.9 cgi -T5000 php opc=on  fps  0.13% 
-0.07% -0.31%

 bench.php cgi -T1 php opc=on  sec  0.02% 
-0.73% -4.41%

   micro_bench.php cgi -T1 php opc=on  sec  0.03%  
0.33% -0.86%

mandelbrot.php cgi -T1 php opc=on  sec  0.01%  
0.35% -2.09%

* Relative Standard Deviation computed from 5 runs



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.  No license (express or implied, by 
estoppel or otherwise) to any intellectual property rights is granted by this 
document.

Intel disclaims all express and implied warranties, including without 
limitation, the implied warranties of merchantability, fitness for a particular 
purpose, and non-infringement, as well as any warranty arising from course of 
performance, course of dealing, or usage in trade.  This document may contain 
information on products, services and/or processes in development. Contact your 
Intel representative to obtain the latest forecast, schedule, specifications 
and roadmaps.  The products and services described may contain defects or 
errors known as errata which may cause deviations from published specifications.

Current characterized errata are available on request.



(C) 2015 Intel Corporation.

Re: [PHP-DEV] Re: Syntactical inconsistency with new group use syntax

[Marcio Almada]

Hi,

2015-08-18 19:18 GMT-03:00 Christoph Becker :
> On 18.08.2015 at 22:47, Arne Blankerts wrote:
>
>> while playing around with the new group use syntax, I stumbled upon an
>> inconsistency of which I'm not sure whether or not it is expected.
>> For the "classic" syntax, while technically pointless, a leading \ for
>> the name is considered valid and works identical to a line without it:
>>
>> >
>> namespace foo;
>>
>> use \some\bar;
>> use some\baz;
>>
>>
>> With the new group syntax, the version with a leading \ is considered
>> invalid - a lint will PHP Parse error: syntax error, unexpected '{',
>> expecting identifier (T_STRING):
>>
>> >
>> namespace foo;
>> use some\{ bar, baz };
>> use \some\{ bar, baz };
>>
>>
>>
>>
>> Is this a bug or feature?
>
> It seems to me that is an oversight.  The resolution would be rather
> simple, cf.
> .
>

This one was fixed via PR ^

> However, while looking at the grammar, I've noticed that the entities
> inside the braces may start with a backslash, what I consider rather
> strange (particularly as there has to be a backslash immediately before
> the opening brace).
>

Someone beat me to it, all fixed now. Thank you!

> --
> Christoph M. Becker
>

Marcio

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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: bump versions: configure.in main/php_version.h

[Björn Larsson]

Den 2015-08-19 kl. 19:15, skrev Anatol Belski:

Hi,


-Original Message-
From: Sebastian Bergmann [mailto:sebast...@php.net]
Sent: Wednesday, August 19, 2015 4:21 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [PHP-CVS] com php-src: bump versions: configure.in
main/php_version.h

Am 19.08.2015 um 16:09 schrieb Niklas Keller:

TBH, I'd rather take the time and have a delayed release without a
hurry than shipping a final version with unresolved problems. Having a
schedule to follow is nice, but you should rethink the schedule when
problems arise instead of following it no matter what.

  +1


Actually I would mind that. As much as I personally would see all the issues 
resolved, as much as an RM I understand that it would mean just crashing PHP7. 
The most of user space code works either without change or with some additional 
effort. People already

- port PHP code
- port C code
- document the features
- read the docs :)
- etc.

Actually, if someone is in the mood to go for an RFC to change the 7.0 timeline 
and it is accepted - so be, let's go for an alpha again and move the final to 
spring :) Otherwise - we're really in the freeze.

With the particular set_exception_handler thread - it would be not bad to see 
first

- some affected places in the real apps
- some implementation
- some tests

That can help to understand the magnitude/impacts to the current code base. 
Many of the topics are just too heavy to be handled within the current timeline 
which is still valid.

Regards

Anatol

Totally agree, we shouldn't jeopardize PHP 7 timeline and 
set_exception_handler
is a bit of a separate topic. Since the behaviour is changed vs PHP 5, 
now catching
exceptions and errors versus just exceptions earlier, it would be good 
to see the

impact as you propose above.

Regards //Björn


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