[PHP-DEV] Using XMLWriter after a SoapFault-Exception

Hi list, I've just updated bug report https://bugs.php.net/bug.php?id=78150 and added a simplified version of the reproduction code. As it appears, XMLWriter refuses to write xml files after a SoapFault-Exception. I'd be very glad if someone could have a look at this. Thanks! Greetings Nico

[PHP-DEV] State of libmysql?

Hi internals, Building PHP 7.4 against libmysql rather than mysqlnd has been broken for quite a while and only recently noticed in https://github.com/php/php-src/pull/4316. Clearly none of us are using libmysql and none of our CI jobs test it. Now that it compiles again, there are many build warni

Re: [PHP-DEV] State of libmysql?

Le 28/06/2019 à 14:59, Nikita Popov a écrit : > Hi internals, > > Building PHP 7.4 against libmysql rather than mysqlnd has been broken for > quite a while and only recently noticed in > https://github.com/php/php-src/pull/4316. Clearly none of us are using > libmysql and none of our CI jobs test

[PHP-DEV] [RFC][VOTE] Unbundle ext/recode

Hi, since there has been no further discussion on this RFC, I have opened the voting on unbundling ext/recode: Voting ends in two weeks, i.e. on 2019-07-12. Thanks for everybody participating in the vote in advance! Joe, while I agree with your

Re: [PHP-DEV] State of libmysql?

On Fri, 2019-06-28 at 15:04 +0200, Remi Collet wrote: > Le 28/06/2019 à 14:59, Nikita Popov a écrit : > > Hi internals, > > > > Building PHP 7.4 against libmysql rather than mysqlnd has been > > broken for > > quite a while and only recently noticed in > > https://github.com/php/php-src/pull/4316.

Re: [PHP-DEV] What to do with ext/xmlrpc?

On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev wrote: > > Hi! > > > ext/imap should follow the same road. > > > > BTW, if we want to keep this extension, we need to consider the bundled > > library as a fork, maintained by US (and drop support to build using the > > system library, if present) >

Re: [PHP-DEV] What to do with ext/xmlrpc?

On 28.06.2019 at 17:49, Peter Kokot wrote: > On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev wrote: >> >>> ext/imap should follow the same road. >>> >>> BTW, if we want to keep this extension, we need to consider the bundled >>> library as a fork, maintained by US (and drop support to build usin

Re: [PHP-DEV] Memory leak in eval()'d code

On Fri, 2019-06-28 at 02:41 +0200, Benjamin Morel wrote: > Hi internals, > > I've tracked down a memory leak to an anonymous class created within > eval(): > > ``` > for ($i = 0; $i < 100; $i++) { > $object = eval('return new class {};'); > > if ($i % 1000 == 0) { >

Re: [PHP-DEV] Memory leak in eval()'d code

> Theoretical it is thinkable we could either detect equal classes (but > unlikely to happen ... if it's the same why do it in eval, zthus cost > likely is higher than benefit in most cases?) Thanks for your reply. I do it in eval() because schema.org has many types (more than 600 at the moment),

Re: [PHP-DEV] Memory leak in eval()'d code

On June 28, 2019 6:49:49 PM GMT+02:00, Benjamin Morel wrote: > >> or unload the class once >> it's not needed anymore (which is hard to detect with reflection and >> other mechanisms which aren't bound to an instance's zval and also >not >> cheap) > >AFAIK, unloading a class is not possible fr

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

These are good points. Originally my RFC called for less functions but based on feedback I added the others. My proposal: take the RFC as-is to a vote. If it fails, I will raise another RFC for a vote that will just contain the two basic functions: str_begins and str_ends. Thanks, Will On 20

[PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

Hello PHP, I just started the vote on https://wiki.php.net/rfc/normalize-array-auto-increment-on-copy-on-write and I will close it in one week from now >From the discussion (https://externals.io/message/105992) it emerged the intention to make the proposed change even stricter. But, given that's

Re: [PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

On Fri, 28 Jun 2019 at 23:01, Wes wrote: > Hello PHP, > > I just started the vote on > https://wiki.php.net/rfc/normalize-array-auto-increment-on-copy-on-write > and I will close it in one week from now > All votes must be at least 2 weeks long after the "No short votes" RFC passed. Best regard

Re: [PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

Den lør. 29. jun. 2019 kl. 00.02 skrev Wes : > > Hello PHP, > > I just started the vote on > https://wiki.php.net/rfc/normalize-array-auto-increment-on-copy-on-write > and I will close it in one week from now The RFC was posted 8 days ago and you need to wait another 6 days before putting this to

Re: [PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

Ugh. I incorrectly remembered it was one week. Sorry for the confusion.

Re: [PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

Totally missed that. Thank you for linking. >

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

On Fri, Jun 28, 2019 at 10:54 PM wrote: > These are good points. Originally my RFC called for less functions but > based on feedback I added the others. My proposal: take the RFC as-is to > a vote. If it fails, I will raise another RFC for a vote that will just > contain the two basic functions:

Re: [PHP-DEV] Memory leak in eval()'d code

Hi! > I case this is non-trivial to fix. Each invocation recompile a new > piece of code, which creates a new class. That's not a "leak". You create new objects (in this case, classes), they take memory. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing L

Re: [PHP-DEV] Memory leak in eval()'d code

> > That's not a "leak". You create new objects (in this case, classes), > they take memory. Why do they not "leak" memory without eval() then? Replace with `$object = new class {};` and memory usage stays flat. There has do be some kind of garbage collection for these anonymous classes. Ben

Re: [PHP-DEV] Memory leak in eval()'d code

On 6/28/19 3:37 PM, Benjamin Morel wrote: > That's not a "leak". You create new objects (in this case, classes), > they take memory. > > > Why do they not "leak" memory without eval() then? Replace with `$object > = new class {};` and memory usage stays flat. > There has do be some kin