Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

Ahhh okay that explains where this change is coming from. Thanks a lot, Dan! I wonder if this side effect ("all dependencies are iterated also during "make install") is intentional. Maybe Niki can chime in on GitHub; I'll ping him there, as well as the original author. Thanks a lot! David

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

directory that, in its entirety, can be compressed into an archive for distribution of only that extension's files. Does that make sense? On Thu, Dec 9, 2021 at 8:28 PM Dan Ackroyd wrote: > > On Wed, 8 Dec 2021 at 15:25, David Zuelke via internals > wrote: > > > > That does

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

lash Gnome wrote: > > Right. > > configure && make && make install > works. > > For my personal information : Now which command should I use to get the error > ? > > > Le jeu. 9 déc. 2021 à 17:34, David Zuelke a écrit : >> >> Of cour

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

error with my build procedure. > But, if I use "make -d install' insteadof "make && make install' I get errors. > > Can you confirm it ? > > > > > > Le jeu. 9 déc. 2021 à 03:19, David Zuelke a écrit : >> >> Yes, of course; it happens with any e

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

this problem with this extension > (PHP8 / 7/5>): > https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0 > > At the moment I need to check some dependency to try your extension. > I'll keep you informed. > > Best Regards > > Le jeu. 9 déc. 2021 à 01:20, Da

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

at 12:33 AM Glash Gnome wrote: > > Hello, > > Can you tell me what the program is in step 7) > > > package up > > Thanks you, > > > Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals > a écrit : >> >> Hi all, >> >> When

[PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

Hi all, When building shared extensions for PHP for the purpose of packaging and distributing the builds, the build environment obviously needs PHP installed in the destination directory structure (for headers, phpize, and so forth). But the resulting archive of the built extension should only

Re: [PHP-DEV] PHP 7.4.7 Released!

The 7.4.7 release post on php.net links to http://www.php.net/ChangeLog-7.php#7.4.6 for the changelog. On Thu, Jun 11, 2020 at 4:16 PM Derick Rethans wrote: > > The PHP development team announces the immediate availability of PHP > 7.4.7. This is a security bug fix release. > > All PHP 7.4 users

Re: [PHP-DEV] [RFC] Provide argon2 support for password_hash() from ext/sodium

You're listing libsodium versions 0.15 and 0.13 there, but it should be 1.0.15 and 1.0.13. Maybe for everyone's reference: Ubuntu 16.04 LTS comes with no libargon2, and with libsodium 1.0.8; 18.04 LTS comes with libargon2 and with libsodium 1.0.16. Debian Stretch has 1.0.11, and 1.0.17 in

[PHP-DEV] PHP_VERSION_SERIES_EOL_DATE or similar constants?

Hi all, Would it not be lovely to have, say, two new constants, that contain the date (ISO, UTC, I guess) of when the running PHP series will be end-of-maintenance and end-of-life? Of course PHP_VERSION_SERIES_EOM_DATE and PHP_VERSION_SERIES_EOL_DATE are a little verbose, but... It would be

Re: [PHP-DEV] On fixing DOMNameSpaceNode and DOM NS API Inconsistency Problems

I agree this should be fixed. It's pretty hilarious how this exact case (fiddling with the xmlns prefix) is the only comment for DOMElement::setAttributeNS: http://php.net/manual/en/domelement.setattributens.php (although unnecessary, as you don't have to "add namespaces" to a document, that

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

On Tue, Jun 26, 2018 at 6:32 PM Kalle Sommer Nielsen wrote: > > Hi > > Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov : > > If you have a minor deprecation in mind, but were too lazy to write an RFC > > for it, please write me a mail until tomorrow, so that it might be included > > as part

Re: [PHP-DEV] FPM maintainership?

Yeah I was going to say: work with Jakub, he has some good stuff in flight! :) On Wed, Feb 21, 2018 at 11:52 AM, Jakub Zelenka wrote: > Hey > > On Wed, Feb 21, 2018 at 12:42 AM, Stanislav Malyshev > wrote: > >> Hi! >> >> I'd like to raise the question of FPM

[PHP-DEV] Trivial 7.2 opcache segfault

I'm trying to understand this one: https://bugs.php.net/bug.php?id=75837 Is that related to the optimizations in 7.2 around unused local variables? Can that somehow be triggered by the @ operator? It's such a trivial reproduce case, it seems almost silly that this hasn't come up during testing...

Re: [PHP-DEV] PHP 7.2.0 RC6 Released

Is it really going to be Nov 30, or Nov 23? On Thu, Nov 9, 2017 at 2:36 PM, Sara Golemon wrote: > The sixth (and likely final) release candidate for 7.2.0 was just > released and can be > downloaded from: > https://downloads.php.net/~pollita/ > Or using the git tag: php-7.2.0RC6

[PHP-DEV] libsodium version target for 7.2

Hi all, The standalone sodium extension has been changed a few days ago to require libsodium 1.0.9: https://github.com/jedisct1/libsodium-php/commit/e4d6d281cf197deb0086b592a72f282905ba7ead Will this version requirement also be ported to the PHP-7.2 branch? The reason I'm asking is because

Re: [PHP-DEV] PHP 7.1.4 is available

The changelog is incomplete; stops at iconv. https://github.com/php/php-src/commit/330a7b62c3558aa987ee80e12f1914347d3a9eee is also missing from NEWS for 7.1.3 > On 13. Apr 2017, at 18:43, Joe Watkins wrote: > > Evening, > > The PHP development team announces the

Re: [PHP-DEV] OPcache compilation performance regression in PHP 5.6/7 with huge classes

n, Mar 27, 2017 at 10:58 PM, David Zuelke <d...@heroku.com> wrote: > Just another poke to surface it, in case this should be merged into the 7.0 > branch as well :) > > https://bugs.php.net/bug.php?id=74250 > > I've applied > https://github.com/php/php-src/commi

Re: [PHP-DEV] OPcache compilation performance regression in PHP 5.6/7 with huge classes

Just another poke to surface it, in case this should be merged into the 7.0 branch as well :) https://bugs.php.net/bug.php?id=74250 > On 19. Mar 2017, at 23:39, David Zuelke <d...@heroku.com> wrote: > > Thanks for the fixes, Nikita! > > Will they be merged to the P

Re: [PHP-DEV] OPcache compilation performance regression in PHP 5.6/7 with huge classes

On 14 Mar 2017, at 16:39, Nikita Popov <nikita@gmail.com> wrote: > > On Tue, Mar 14, 2017 at 11:29 AM, David Zuelke <d...@heroku.com> wrote: >> Hi all, >> >> There appears to be a performance regression in the CFG and DFA based >> optimization passe

[PHP-DEV] OPcache compilation performance regression in PHP 5.6/7 with huge classes

Hi all, There appears to be a performance regression in the CFG and DFA based optimization passes of OPcache in PHP 5.6+ when loading huge classes (such as those generated by Symfony's routing component) for the first time. The issue does not occur on PHP 5.5. Tests below are with 5.6.30,

Re: [PHP-DEV] [RFC][Vote] Libsodium vote closes; accepted (37-0)

Will there be a renaming of the "libsodium" extension on PECL to "sodium" as well, and will the two codebases be kept in sync? Otherwise, libraries cannot, using Composer, express a dependency on "ext-sodium". > On 10.02.2017, at 22:04, Scott Arciszewski wrote: > > The

Re: [PHP-DEV] Fixing Apache mod_proxy_fcgi SCRIPT_FILENAME et al for good

> On 17.01.2017, at 15:58, Remi Collet <r...@fedoraproject.org> wrote: > > Le 17/01/2017 à 15:44, David Zuelke a écrit : >> Hi all, >> >> https://github.com/php/php-src/pull/694 and >> https://github.com/php/php-src/pull/765 brought support for Apache'

[PHP-DEV] Fixing Apache mod_proxy_fcgi SCRIPT_FILENAME et al for good

Hi all, https://github.com/php/php-src/pull/694 and https://github.com/php/php-src/pull/765 brought support for Apache's "SetHandler" based mod_proxy_fcgi-to-FPM interface. Recently, a change in Apache (https://github.com/apache/httpd/commit/cab0bfbb2645bb8f689535e5e2834e2dbc23f5a5) broke

[PHP-DEV] Schedule for next releases?

Happy new year everyone! I haven't seen this mentioned here on the list, and figured I'd ask, as it makes some people's lives a bit easier to know this... :) What's the schedule/plan for the next point releases for PHP? The last ones were four weeks ago, but there haven't been the usual RC

Re: [PHP-DEV] PHP 5.6 end of active support

On 14.12.2016, at 16:15, Dennis Clarke wrote: > > On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote: >> Hi >> >> On Dec 14, 2016 12:23, "Christoph M. Becker" wrote: >>> >>> Hi! >>> >>> The end of active support for PHP 5.6 is documented to be on

Re: [PHP-DEV] Bumping minimal OpenSSL version to 1.0.1 in master for PHP 7.1

On 13.12.2016, at 11:31, Niklas Keller wrote: > > OpenSSL support for 1.0.1 will end this year. > > Support for version 1.0.1 will cease on 2016-12-31. No further releases of >> 1.0.1 will be made after that date. Security fixes only will be applied to >> 1.0.1 until then. >>

Re: [PHP-DEV] PHP 7.1.0 GA

On 22.11.2016, at 19:36, Joe Watkins wrote: > Evening internals, > > I'm excited to announce that PHP 7.1.0 will be GA on December 1st. > > It has taken a lot of hard work from a lot of people, so stop whatever you > are doing and give those people a round of applause. >

Re: [PHP-DEV] Do You think PHP's SOAP client should have an option to virtuallyAdd (for XSD imports!) missing end-slash in the URI to WSDL? I do!

I think it should not. Your pull request fixes a problem in that WSDL. The WSDL is located at the URL `https://pg.eet.cz/eet/services/EETServiceSOAP/v3?wsdl`. It references an XML Schema file at `EETXMLSchema.xsd`, which is a relative location, so it's looked for relative to the containing

Re: [PHP-DEV] Enabling opcache causes libraries to build as static

On 20.03.2016, at 22:10, David Zuelke <d...@heroku.com> wrote: > > On 10.03.2016, at 16:56, David Zuelke <d...@heroku.com> wrote: >> >>> On 08.03.2016, at 16:18, Andrea Faulds <a...@ajf.me> wrote: >>> >>> Hi, >>> >>> D

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

I think this solution is merely a band-aid for a more profound architectural weakness of current PHP setups, where a web server call out to the engine (via embedding or FastCGI) to execute a script, which causes this recurring initialization overhead in the first place. The future is (or

Re: [PHP-DEV] PCRE JIT stack size limit

On 21.03.2016, at 23:44, Anatol Belski wrote: > > What I'm suggesting to do is using a bit finer comb checking with the real > life situations. Fe what would be the win for the user, either having to > enable JIT by hand, or to disable it in a rare case. Currently, as for

Re: [PHP-DEV] PCRE JIT stack size limit

On 21.03.2016, at 19:41, Anatol Belski wrote: > I've just pushed a fix for this issue, could you please check? A global > stack space > Is used in a thread safe manner. I was first setting max to 256K, then > decreased it > To 64K for now. My tests on Linux and Windows show

Re: [PHP-DEV] PCRE JIT stack size limit

On 21.03.2016, at 19:54, Nikita Popov wrote: > > On Mon, Mar 21, 2016 at 7:41 PM, Anatol Belski wrote: >> The issue I have with more increasing the stack is that - while as we see >> till today >> the default stack size of 32K is enough in the common

Re: [PHP-DEV] PCRE JIT stack size limit

> On 20.03.2016, at 22:41, Anatol Belski <anatol@belski.net> wrote: > > Hi, > >> -Original Message----- >> From: David Zuelke [mailto:d...@heroku.com] >> Sent: Sunday, March 20, 2016 10:10 PM >> To: Anatol Belski <anatol@belski.ne

Re: [PHP-DEV] Enabling opcache causes libraries to build as static

On 10.03.2016, at 16:56, David Zuelke <d...@heroku.com> wrote: > >> On 08.03.2016, at 16:18, Andrea Faulds <a...@ajf.me> wrote: >> >> Hi, >> >> David Zuelke wrote: >>> Is this intentional? Related to opcache's "can only be built sh

Re: [PHP-DEV] PCRE JIT stack size limit

> On 17.03.2016, at 05:22, David Zuelke <d...@heroku.com> wrote: > >> On 16.03.2016, at 21:38, Anatol Belski <anatol@belski.net> wrote: >> >> Hi, >> >>> -Original Message- >>> From: David Zuelke [mailto:d...@heroku.co

Re: [PHP-DEV] OpenSSL ext status including port to OpenSSL 1.1

On 20.03.2016, at 20:50, Jakub Zelenka wrote: > > Hi, > > I just wanted to send a quick update about my recent work on openssl ext in > case someone else wanted to start something similar so we don't have a > wasted effort on that. :) > > 1. Error queueing > > I'm more or less

Re: [PHP-DEV] PCRE JIT stack size limit

> On 16.03.2016, at 21:38, Anatol Belski <anatol@belski.net> wrote: > > Hi, > >> -Original Message----- >> From: David Zuelke [mailto:d...@heroku.com] >> Sent: Tuesday, March 15, 2016 11:58 PM >> To: Anatol Belski <anatol@belski.ne

Re: [PHP-DEV] [RFC] Libsodium (bump)

I think I've said this before; please call it ext-sodium, not ext-libsodium. David > On 15.03.2016, at 18:40, Scott Arciszewski wrote: > > Link to RFC: https://wiki.php.net/rfc/libsodium > > I'd like to bump the RFC to make Libsodium a core extension, as per > Ferenc's

Re: [PHP-DEV] PCRE JIT stack size limit

On 15.03.2016, at 21:18, Anatol Belski <anatol@belski.net> wrote: > > Hi, > >> -Original Message- >> From: David Zuelke [mailto:d...@heroku.com] >> Sent: Sunday, March 13, 2016 6:09 AM >> To: Anatol Belski <anatol@belski.net> >&g

Re: [PHP-DEV] PCRE JIT stack size limit

Just wanted to resurrect this thread... I just got a JIT stack size limit error (which Composer reports as "unknown error" because it has no logic for the new constant) while running "composer require somepackage" with PHP 7 and JIT enabled. IMO, a pattern modifier would be good so that

Re: [PHP-DEV] Enabling opcache causes libraries to build as static

> On 08.03.2016, at 16:18, Andrea Faulds <a...@ajf.me> wrote: > > Hi, > > David Zuelke wrote: >> Is this intentional? Related to opcache's "can only be built shared" status? >> But why would that trigger static builds? Or is it a bug? > > While

[PHP-DEV] Enabling opcache causes libraries to build as static

Hi all, I've been trying to get to the bottom of why even a minimal PHP build (any 5.x or 7 release, or a fresh e.g. 7.0 branch checkout after buildconf) creates .a versions of all shared extensions in addition to .so modules. I've narrowed it down to opcache: $ ./configure --disable-all ...

Re: [PHP-DEV] NEWS entries

On 28.02.2016, at 13:24, Tom Sommer wrote: > > I'm reading the 7.0.4 NEWS file[1] and I get the policy of just writing the > bug number and headline, but in a lot of cases the bug report headline says > nothing about the actual problem, or the actual fix. > > For instance:

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

Thanks for the work, Derick. Looks good! (aaand I just top-replied :p) > On 09.02.2016, at 13:33, Derick Rethans wrote: > > Hello! > > Things have quieted down around the Code of Conduct and Contributor > Guidelines process, but I have not been sitting still. In the last

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

On 09.02.2016, at 15:33, Derick Rethans wrote: > > On Tue, 9 Feb 2016, Zeev Suraski wrote: > >> 1. "Debate the technical issues, and never attack a person's opinion. >> People will disagree, so be it." >> >> I think this sentence is problematic. Not that I'm pro-attacks, but

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

On 22.01.2016, at 17:43, Florian Anderiasch wrote: > > On 22.01.2016 15:29, Pierre Joye wrote: >> >> Freshly adopted: >> >> http://rubyonrails.org/conduct/ >> https://golang.org/conduct >> > > Ruby (the language) is discussing the adoption of a Code of Conduct > right

Re: [PHP-DEV] Bug #68276 Reproducible memory corruption: pgsql conflicts with openssl extension

> On 18.01.2016, at 03:03, Yasuo Ohgaki wrote: > > Hi openssl module maintainers, > > This bug https://bugs.php.net/bug.php?id=68276 is categorized > as pgsql bug, but it would be more appropriate if categorized as > openssl bug. > > This bug report includes PR

Re: [PHP-DEV] Bug #68276 Reproducible memory corruption: pgsql conflicts with openssl extension

On 19.01.2016, at 02:36, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > > Hi David, > > On Tue, Jan 19, 2016 at 2:31 AM, David Zuelke <d...@heroku.com> wrote: >> >> I have customers running into this too. I have not yet had time to pick up >> that pat

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

On 14.01.2016, at 13:18, Zeev Suraski wrote: > The way I see it, we don't need to acknowledge having a problem in order to > want to improve. I'm sure that resonates with most developers on this list - > wanting to continuously improve does not mean you're saying that things

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 11.01.2016, at 12:31, Anthony Ferrara wrote: > Actually, asking for proof and denying are the same thing. If they > weren't, then why would you be asking for proof unless you believed it > didn't happen? They are not the same thing. If you make a claim, then the onus of

Re: [PHP-DEV] [RFC] Libsodium

Can we call that extension "sodium" please without the "lib" prefix? David > On 07.01.2016, at 08:26, Scott Arciszewski wrote: > > Hi everyone, > > I've updated the RFC to make libsodium a core PHP extension in 7.1, to > include references to the online documentation. >

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 08.01.2016, at 07:09, Anthony Ferrara wrote: > > I think if the current RFC went to vote, it would come very close to > passing as-is. But as I've said before, I don't think it's anywhere > near ready to vote on. Larry has started a discussion with the people > behind

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 09.01.2016, at 19:48, Anthony Ferrara wrote: > > All, > >> I was not hesitant (or, let's maybe call it "intentionally procrastinating") >> to post on this topic because I felt unsafe on this list or in the general >> realm of the PHP community; I simply was in no mood

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 06.01.2016, at 12:31, Rowan Collins wrote: > > On 6 January 2016 19:42:29 GMT, Stanislav Malyshev > wrote: >> I love it how The Law spends so much text and yet leaves so much >> unspecified and open to interpretation. > > Welcome to Common Law.

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 08.01.2016, at 07:47, Anthony Ferrara wrote: > > I don't think anything in this thread warrants the term "attack" or > "harassment". While I strongly don't agree with the tone being used > nor the tactics being used, I don't think they warrant any sort of CoC > violation.

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 06.01.2016, at 07:21, Anthony Ferrara wrote: > > Stas, > > I wanted to avoid citing personal examples for personal reasons. But > since you refuse to read between the lines, here it goes: > > I have received no less than 4 direct threats of violence that were > directly

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

+1 to all the points below; pretty much my concerns and thoughts exactly. > On 08.01.2016, at 08:30, Zeev Suraski wrote: > >> We've seen time and time again that the court of public opinion is a >> horrific >> judge for these style issues. > > This sentence has me worried in

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 06.01.2016, at 03:58, Kevin Smith wrote: > >> You state this like some kind of self-evident truth. Understand that not >> everybody agrees with you, and scorn is not generally something that wins >> people round to your argument. > > If a code of conduct so broad and

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

(Thank you for this write-up, Brandon. It's good to hear an opinion from someone who's a bit closer to that "field". I'll ignore netiquette and top-post because it feels like a good point to pick up from and share my general thoughts on this) Personally, I don't disagree with the idea of

Re: [PHP-DEV] Practical comparisons on PHP7

Lester, we are software developers. not fortune tellers. Stop speculating. Gather data. Profile your stuff and look where the bottlenecks are. > On 10.12.2015, at 12:16, Lester Caine wrote: > > On 10/12/15 11:02, Björn Larsson wrote: >> Just noticed that Smarty team is

Re: [PHP-DEV] Practical comparisons on PHP7

Then do a trace with xhprof/xdebug/blackfire and see where the time is spent. How should we magically know the answers? > On 09.12.2015, at 20:02, Lester Caine wrote: > > On 09/12/15 16:24, Rowan Collins wrote: >>> So as somebody already said, maybe your code or setup is

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

riods for PHP 5.6: > > > > https://wiki.php.net/rfc/php56timeline > > > > Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring > omissions. > > > > Let the discussion continue… > > > > Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Practical comparisons on PHP7

On 08.12.2015, at 13:32, Lester Caine wrote: > Bottom line is that given the real world loading on my sites, the > differences are probably in the noise of network transit times so not > impressive at all :( ... or you have a bunch of very slow queries in there that are

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

he support periods for PHP 5.6: >> >> https://wiki.php.net/rfc/php56timeline >> >> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring >> omissions. >> >> Let the discussion continue… > > I think you're making the voting too

Re: [PHP-DEV] PHP 5.6 life cycle

On 06.12.2015, at 20:38, Anatol Belski wrote: > From today's perspective, I'd suggest to extend the security only period of > 5.6. That would be my suggestion too. End "full" support in, say, December 2016 (a year after 7.0.0), but then give it two years of security

Re: [PHP-DEV] 7.0.0 release

On 24.11.2015, at 12:57, Leigh wrote: > I prefer a over c. > > As you said, we can deliver a stable and high quality 7.0.0 today. An RC > period where you expect no bugs does not sound productive to me. That is exactly the point of an RC. No show-stoppers means you then roll

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

On 23.11.2015, at 04:02, Rasmus Lerdorf wrote: > > On Nov 23, 2015, at 00:48, Adam Harvey wrote: >> >> Here's an alternative suggestion: we've previously switched to one >> week RC cycles late in the piece when trying to get major releases >> stabilised and

Re: [PHP-DEV] 7.0.0 release

On 23.11.2015, at 22:10, Anatol Belski wrote: > So in the end, a solution is wanted. I don't think any opinion is allowed to > be ignored for such a topic. So options > > a) release on 26th including all known bug fixes > b) do RC8, assume there are no bugs, so target 10th

Re: [PHP-DEV] PHP7 / foreach / references / ugly code / discrepancy to PHP 5.6

Should this be in the UPGRADING notes? > On 10.11.2015, at 20:45, Nikita Popov wrote: > > On Tue, Nov 10, 2015 at 5:48 PM, Philip Hofstetter < > phofstet...@sensational.ch> wrote: > >> Hi, >> >> I'm having a cause of slightly ugly code that runs differently from PHP 5.6

Re: [PHP-DEV] PHP 7 RTM date

On 10.11.2015, at 10:26, Lester Caine wrote: > > On 10/11/15 00:49, Rasmus Lerdorf wrote: >>> November 30 is Cyber Monday, where people are either a) focused on maxing out their credit cards on every possible e-commerce site, or b) unable to roll out PHP

Re: [PHP-DEV] PHP 7 RTM date

November 30 is Cyber Monday, where people are either a) focused on maxing out their credit cards on every possible e-commerce site, or b) unable to roll out PHP 7 because their customers are busy with a) At least at Heroku we have a blackout policy around Thanksgiving and Christmas for

Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

On 06.10.2015, at 19:28, Pierre Joye wrote: > The license cannot be changed without approvals of every contributor > to date. I very much doubt they will. And to make that point clear for > me, if they do and come with anything but the PHP license, I can > already say that

Re: [PHP-DEV] PCRE JIT stack size limit

On 24.07.2015, at 09:33, Adam Harvey ahar...@php.net wrote: On 23 July 2015 at 11:47, Christoph Becker cmbecke...@gmx.de wrote: snip great explanation, thanks Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit). That would mean, however, to add yet another ini setting, of

Re: [PHP-DEV] Fixing bundled extension version mess

Since I'm working on something related... what's the verdict here? :) On 20.04.2015, at 20:00, Jakub Zelenka bu...@php.net wrote: Hi, On Thu, Apr 16, 2015 at 1:21 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Apr 16, 2015 at 6:27 PM, François Laupretre franc...@php.net wrote:

Re: [PHP-DEV] Branching off PHP7 and electing RMs

But an alpha timeline sounds good ;) On 13.05.2015, at 16:32, Pierre Joye pierre@gmail.com wrote: On May 13, 2015 7:57 PM, Julien Pauli jpa...@php.net wrote: Hello people. Time is going, and summer is coming. I think we must have branched 7.0 until end of May, and have our 2 RMs

Re: [PHP-DEV] [VOTE] Exceptions in the engine

I feel like this one is different though, because there already was consensus that the current naming isn't the best, and there was support for Throwable, while voting on the original RFC was still open. To adhere to the RFC process, the open RFC wasn't changed accordingly, because voting was

Re: [PHP-DEV] [VOTE] Exceptions in the engine

Why not wait with the merge until a consensus emerges regarding Throwable? On 09.03.2015, at 05:26, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! Voting on the engine exceptions RFC, which proposes to

Re: [PHP-DEV] [VOTE] Exceptions in the engine

+1000 on this; so much better than the BaseException stuff! On 27.02.2015, at 15:31, Sebastian Bergmann sebast...@php.net wrote: Am 23.02.2015 um 19:15 schrieb Nikita Popov: Voting on the engine exceptions RFC, which proposes to convert existing fatal and recoverable fatal errors into

[PHP-DEV] Allow tightening of PHP_INI_SYSTEM directives in PHP_INI_PERDIR+ contexts?

Hi, Currently, some directives such as expose_php or allow_url_fopen can only be changed on the PHP_INI_SYSTEM level, which in some cases apparently even means through php.ini only. Wouldn't it make sense to allow tightening of these values in, say, a PERDIR contexts? So expose_php can be

Re: [PHP-DEV] Faster zend sorting implementation

On 06.01.2015, at 05:42, Pierre Joye pierre@gmail.com wrote: I am not sure about that. Introducing a not easy to catch BC break for 0.1% gain on function (or even for the whole app) is not very appealing. However, there is nothing in the documentation actually describing how it works

Re: [PHP-DEV] Faster zend sorting implementation

This sounds reasonable, because given how the sort is *not* stable, there will be other cases (totally made up, but let's say [a, o, O]) where the swap does *not* happen. Consistency, and thus a stable sort, is better. But you're saying your patch is kind of a stable sorting algo, so is it

Re: [PHP-DEV] PHP-FPM state

Well, there are two changes there (not sure why move zlog_set_level() again shows up twice in the log?) One changes the pm.start_servers calculated default message to a notice (makes total sense IMO). The other moves zlog_set_level() so it's called earlier, or else the log level isn't set yet

Re: [PHP-DEV] PHP 5.4.33 RC1 = mod_proxy_fcgi still broken

The fix is not broken. He's describing a different/additional issue. Things have always been shaky with ProxyPass (that's https://bugs.php.net/bug.php?id=65641) because it's a bag of hurt. That's the whole reason Apache now has SetHandler for proxies! On 08.09.2014, at 22:54, Stas Malyshev

Re: [PHP-DEV] PHP 5.4.33 RC1 = mod_proxy_fcgi still broken

On 05.09.2014, at 10:54, Remi Collet r...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 05/09/2014 15:52, David Zuelke a écrit : People should simply use the SetHandler approach instead. I agree, see https://bugzilla.redhat.com/1136290 But some people may

Re: [PHP-DEV] PHP 5.4.33 RC1 = mod_proxy_fcgi still broken

The fixes in that ticket were pretty risky as they very late in the game fiddled with strings. That was brittle should have been fixed earlier during request processing. The new patch

Re: [PHP-DEV] 5.4 security only

I'd like to see https://github.com/php/php-src/pull/694 / https://github.com/php/php-src/pull/765 in so FPM in 5.4 will work properly with Apache 2.4.10+'s mod_proxy_fcgi. David On 19 Aug 2014, at 01:59, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Moving this out of other topics into

Re: [PHP-DEV] Native support - PUT request, multipart form data

On 17 Aug 2014, at 22:55, Chris Wright c...@daverandom.com wrote: On 17 August 2014 11:49, David Zuelke d...@heroku.com wrote: That does not make any sense; applications could accept XML, CSV or whatever else just as well. The original proposal is not very useful. $_GET contains parsed

Re: [PHP-DEV] Native support - PUT request, multipart form data

That does not make any sense; applications could accept XML, CSV or whatever else just as well. The original proposal is not very useful. $_GET contains parsed query string info, $_POST contains parsed HTTP request body information if the media type is application/x-www-urlencoded or

[PHP-DEV] Re: 5.3 final release

On 22 Jul 2014, at 21:10, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! not sure, have you seen https://bugs.php.net/bug.php?id=67606 ? This is worrying. Looks like the patch is not as safe as we've hoped, and causes BC issues for mod_fastcgi, so maybe we should not get it into 5.3.