Re: [PHP-DEV] Surveying interest regarding CMake

On Thu, 2021-12-16 at 20:15 +0100, Nikita Popov wrote: > My main question would be how this will affect 3rd party extensions, > which are currently using autoconf. Will they need to migrate to > cmake, or will we have to effectively maintain both build systems? We would have to keep our autoconf

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

On February 27, 2021 7:29:43 PM GMT+01:00, Kamil Tekiela wrote: >> The code shown here >https://www.w3schools.com/php/func_mysqli_connect.asp is >relatively correct at the moment. Maybe not nice, but it handles the >error. >That is the second hit on google (after php.net manual) when

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

On February 27, 2021 5:23:47 PM GMT+01:00, Kamil Tekiela wrote: >> >> The issue is, as said, that this only happens in an error situation. >> Thus if users only test "does my site still work after update?" (what >> many do ...) won't notice this, till something fails, which would >have >>

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

On Wed, 2021-01-27 at 15:17 +0100, Sebastian Bergmann wrote: > Am 25.01.2021 um 11:03 schrieb Nikita Popov: > > Fully support this proposal. Throwing exceptions is the right > > default, it > > matches what PDO does, and restoring the old behavior is one line > > of code. > > I second that

Re: [PHP-DEV] [VOTE]: Change Default mysqli Error Mode

Hi, On Wed, 2021-02-10 at 23:35 +, Kamil Tekiela wrote: > I have started voting on > https://wiki.php.net/rfc/mysqli_default_errmode > The voting period is 2020-02-11 -- 2020-02-28 Sorry, I didn't see this before. I agree that Exceptions are the way to go and it were good if that had been

Re: [PHP-DEV] Replies on lists.php.net

On Mon, 2021-02-15 at 16:43 -0600, Larry Garfield wrote: > This is a long standing fight. Who is in the wrong, mail clients > that stupidly send double messages, or mail clients that stupidly > can't detect and omit double messages? Probably both, but the one > that is really wrong is whatever

Re: [PHP-DEV] Thank you to JetBrains (PHP 8 Announcement page)

On Fri, 2020-11-27 at 09:40 -0600, Sara Golemon wrote: > I've been receiving fantastic feedback on the PHP 8.0 Announcement > landing page ( https://www.php.net/releases/8.0 ), and I just wanted > to extend a big Thank You to all the folks at JetBrains for making > this suggestion and putting

Re: [PHP-DEV] Make `always true` SPL methods return void

On Thu, 2020-06-18 at 23:17 -0400, Jesse Rushlow wrote: > * Disclaimer - I have not thoroughly reviewed the bug report or PR > mentioned. > > From a PHP developers perspective, if I was calling a method that > returned true. I would automatically assume that the method is > capable of returning

Re: [PHP-DEV] New functions `hash_serialize` and `hash_unserialize`?

On Mon, 2020-06-08 at 09:01 -0400, Eddie Kohler wrote: > I'm writing to gauge interest in two new functions to the PHP `hash` > extension, `hash_serialize` and `hash_unserialize`. These functions > would serialize and unserialize the internals of a HashContext > objectallowing a partially-computed

Re: [PHP-DEV] SPL development interest

On Sat, 2020-05-16 at 16:37 +0200, Jakob Givoni wrote: > The reason I was wondering about it was mostly for understanding > where > one would put Classes, Interfaces and Traits that should be essential > parts of the language. > F.ex. it seems the Countable interface should have been in the core >

Re: [PHP-DEV] SPL development interest

On Fri, 2020-05-15 at 12:53 +0100, Dan Ackroyd wrote: > Obviously, all of the following is my own personal opinion, and other > people may have different opinions. > > There are two main lessons learnt from the SPL experience. > > i) Some APIs need to evolve separately from the PHP release >

Re: [PHP-DEV] Graceful timeout

On Sat, 2020-05-16 at 19:15 +0100, Derick Rethans wrote: > sleep(2) should not trigger a 1 second timeout. Currently the time > counted for max_execution_time timeouts is CPU time, not wall time. I might remember wrongly, but I think on Windows it uses wall time. One thing to consider when

Re: [PHP-DEV] [VOTE] Userspace operator overloading

On March 28, 2020 5:44:28 PM GMT+01:00, Nikita Popov wrote: >On Sat, Mar 28, 2020 at 5:28 PM Johannes Schlüter > >wrote: > >> On Sat, 2020-03-28 at 17:05 +0100, Christoph M. Becker wrote: >> > On 28.03.2020 at 15:57, Johannes Schlüter wrote: >> > >>

Re: [PHP-DEV] [VOTE] Userspace operator overloading

On Sat, 2020-03-28 at 17:05 +0100, Christoph M. Becker wrote: > On 28.03.2020 at 15:57, Johannes Schlüter wrote: > > > On March 28, 2020 1:25:11 PM GMT+01:00, "Christoph M. Becker" < > > cmbecke...@gmx.de> wrote: > > > > > This "try

Re: [PHP-DEV] [VOTE] Userspace operator overloading

On March 28, 2020 1:25:11 PM GMT+01:00, "Christoph M. Becker" wrote: >On 28.03.2020 at 10:22, Arnold Daniels wrote: > >> This issues become even more apparent when sequencing operations like >`$a + >> $b + $c - $d`. Trying left, then trying right, will make it very >difficult >> to determine

Re: [PHP-DEV] [VOTE] Userspace operator overloading

On Mon, 2020-03-23 at 18:58 +0100, jan.h.boeh...@gmx.de wrote: > Hi internals, > > I have opened voting on > https://wiki.php.net/rfc/userspace_operator_overloading, which allows > users to overload operators in their own classes. > I consider operator overlaoding in general a good feature

Re: [PHP-DEV] Are PECL modules preferable?

On Mon, 2020-03-23 at 11:01 -0400, Mike Schinkel wrote: > > On Mar 23, 2020, at 6:36 AM, Remi Collet wrote: > > > > Le 21/03/2020 à 23:52, Mike Schinkel a écrit : > > > > On Mar 21, 2020, at 5:59 PM, tyson andre < > > > > tysonandre...@hotmail.com> wrote: > > > > FROM: Re: [PHP-DEV] [RFC]

Re: [PHP-DEV] Re: OSI approval for PHP 3.01 license

On Wed, 2020-03-04 at 10:33 +0100, Andreas Heigl wrote: > Does anyone here remember why the changes to the license where done > in > the first place? The commit was done on the 1st of Jan. 2006 (at > least > according to >

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Wed, 2020-02-12 at 10:54 -0600, Paul M. Jones wrote: > Hi Johannes, > > > > What indication is there that this will be more successfull than > > the > > filter API? > > Fair question. While I can't say how successful (or not) ext/filter > has been, I *can* say that the proposal does not

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi, On Mon, 2020-02-10 at 10:18 -0600, Paul M. Jones wrote: > After a couple of years of incubation, I am happy to offer a second > version of this RFC: > > https://wiki.php.net/rfc/request_response What indication is there that this will be more successfull than the filter API? The filter

Re: [PHP-DEV] Operator overloading for userspace objects

On Wed, 2020-01-29 at 00:14 +0100, jan.h.boeh...@gmx.de wrote: > the last days I have experimented a bit with operator overloading in > userspace classes (redefing the meaning of arithmetic operations like Some historic context: I am probably the one who did operator overloading in PHP first.

Re: [PHP-DEV] Support for Async / Await

On Mon, 2019-12-23 at 10:55 -0800, Stanislav Malyshev wrote: > Hi! > > > Does this actually fit in with php's execution model of each > > request > > being a separate thread / process? As far as I understand this kind > > of > > async programming is only useful within an event-loop architecture >

Re: [PHP-DEV] GitHub RFC workflow

On November 4, 2019 8:35:16 AM GMT+01:00, Joe Watkins wrote: >I'm in Spain, and unaware of any access problems ... In Spain there recently was a court case against an app used to organize protests for an independence of Catalonia. In consequence Github was required to block access from

Re: [PHP-DEV] GitHub RFC workflow

On Sat, 2019-11-02 at 19:40 +0100, Joe Watkins wrote: > I would like to question the reasoning behind wanting to "own" the > RFC content: We don't require any such thing for any other kind of PR > although we say we require a patch on bugsnet, we actually don't > require it. So, I have a hard time

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

On Fri, 2019-10-04 at 16:45 +0100, Mark Randall wrote: > Hi Internals, > > I put forward the following RFC "Deprecate Backtick Operator (V2)" > for > discussion. > I use them from time to time when using PHP as a better shell scripting language. Quite useful in that context. Deprecating them

Re: [PHP-DEV] Changing PECL signup flow.

On Thu, 2019-09-19 at 13:06 +0100, Dan Ackroyd wrote: > Johannes wrote: > > I think we should clarify what PECL actually is. > > Without such a tool the need for a central distribution > > site goes away > > I think there is still a large amount of value in PECL being 'merely' > a distribution

Re: [PHP-DEV] Changing PECL signup flow.

On September 18, 2019 3:32:38 PM GMT+02:00, "Christoph M. Becker" wrote: >On 18.09.2019 at 15:22, Johannes Schlüter wrote: > >> The Windows builds are also a relevant factor in the discussions >> regarding the PECL site. Afaik (Anatoliy and others know better t

Re: [PHP-DEV] Changing PECL signup flow.

On Mon, 2019-09-16 at 11:13 +0200, Christoph M. Becker wrote: > > For the record, there is already > , but that project looks like > it has fallen asleep. > Right and contrary to the old PECL/PEAR tool this can also fetch the precompiled Windows

Re: [PHP-DEV] Changing PECL signup flow.

On Sun, 2019-09-15 at 18:11 +0100, Dan Ackroyd wrote: > HI internals, > > Currently, it is quite difficult to signup to get a PECL account. > > We have a somewhat deliberately obtuse form to signup through, which > then needs to be manually approved by someone with the appropriate > karma. I

Re: [PHP-DEV] Merging fuzzing SAPI into core

On Tue, 2019-07-30 at 13:28 -0400, Bishop Bettini wrote: > On the other, I've found it refreshing working in a > slender repo that doesn't have all the history and process rules. > This is good for external (non-core and non-extension) collaborators, > particularly allowing write access to those

Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations

On Tue, 2019-07-16 at 08:00 -0700, Zeev Suraski wrote: > > Now unanimity implies consensus however not having a unanimous vote > does > > not mean there is no consensus. > > Moreover, even though "consensus" does come from the Latin > *cōnsēnsus* (“agreement, > > accordance, unanimity”) [3] it

Re: [PHP-DEV] Bugsnet: Quick fix descriptions

On Thu, 2019-07-18 at 12:24 +0100, Peter Cowburn wrote: > I'm not sure if anyone other than us is still using this source code > (looking at the MySQL guys). If not, can we just include the reasons > in > the source directly, and forget about the database or a special file > containing the

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

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] 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 > >

Re: [PHP-DEV] Feedback on state of some PHP extensions, functions, etc.

Hi, On Wed, 2019-06-12 at 17:32 +0200, G. P. B. wrote: >- the enable_dl directive, it is said that "This deprecated > feature*will* certainly be *removed* in the future." [x] is this > the case already? addressed in the Deprecation for 7.4 draft RFC [2] I missed that debate, but I think

Re: [PHP-DEV] [VOTE] Allow throwing exceptions from __toString()

On Mi, 2019-05-22 at 15:44 +0200, Nikita Popov wrote: > Hi internals, > > I've opened voting on the __toString() exceptions RFC: > https://wiki.php.net/rfc/tostring_exceptions I raised some concerns as this can lead to subtle bugs. I however want to publicly applaud you for the effort and

Re: [PHP-DEV] Removing mysqlnd stats from phpinfo

On Fr, 2019-05-17 at 09:20 +0100, Peter Cowburn wrote: > On Fri, 17 May 2019 at 09:15, Claude Pache > wrote: > > > > > > > > > > > > > Le 17 mai 2019 à 09:35, Peter Bowyer > > > a > > écrit : > > > > > > > > > This could be a good time to make all blocks on the page > > > collapsible, > >

Re: [PHP-DEV] Removing mysqlnd stats from phpinfo

On Mi, 2019-05-15 at 19:01 +0200, Pieter Hordijk wrote: > Hey internals, > > when there is support for mysqlnd the `phpinfo()` page hows the > entire list of available mysqlnd stats. > > Do we really need to show the stats here? It makes the page > unnecessary long and somewhat annoying to

Re: [PHP-DEV] PHP header files, restrict to declaring code only

On Fr, 2019-05-10 at 15:14 +0200, Lynn wrote: > Hi Nikita, > > By limiting a header file to declaring code only, a couple of issues > could > be tackled: > > 1. No side effects when loading files. You can assume the global > state > remains the same, no >    code is executed by this file, and no

Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance

On Di, 2019-04-16 at 23:49 +0100, Dan Ackroyd wrote: > I'm pretty sure one of the big goals that the PHP project should try > to accomplish over the next year or two is to allow extensions to be > distributed through channels similar to Composer. In reality 90% of users use Linux (or *BSD or Mac

Re: [PHP-DEV] Required Make version

On Di, 2019-04-16 at 09:46 -0600, Levi Morrison wrote: >  > I'd be happy to work help with the CMake port, as I know it a decent > bit, but I don't have enough time to champion the whole thing. > That has been done ages ago: http://svn.php.net/viewvc/php/cmake/ Back then it didn't have any

Re: [PHP-DEV][DISCUSSION] Multilingual PHP

Hi, On Do, 2019-04-11 at 15:32 -0500, Michael Morris wrote: > Submitted to the floor is a Wired article from 2 days ago I came > across > > https://www.wired.com/story/coding-is-for-everyoneas-long-as-you-spea > k-english/ > Oh, memories. Microsoft Office has (or had) localised macros. This

Re: [PHP-DEV] Status of pickle?

On Fr, 2019-03-29 at 11:29 +0700, Pierre Joye wrote: > On a side note, pickle is not related to php.net. :) > Considering that we're kicking the pecl (pear) installer out we should provide an alternative. pickle might be one alternative, teaching people to do wget+phpize+configure+make install

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote: > > As we stand now, code using short open tags works when those tags are > enabled.  As we'd stand in the future, that code would not work.  > That > level of BC break requires a strong justification. The code would not simply "not work" but

Re: [PHP-DEV] PHP_VERSION_SERIES_EOL_DATE or similar constants?

On Mo, 2019-03-18 at 23:30 +0100, David Zuelke wrote: >  > It would be really useful for e.g. code check systems, tools like > Composer, hosting platforms, to inform the user of an upcoming or > past > EOM/EOL date, without having to maintain a list of these dates > separately (by copying from, or

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

On Di, 2019-03-12 at 23:50 +0100, Peter Kokot wrote: >  > > Which would be good - as all those things make writing portable > > code > > harder. > > > >    $ echo '' | php > > > > Is a valid program, which will behave vastly different based on the > > ini > > setting. > > In reality if

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

On Di, 2019-03-12 at 15:53 +, Rowan Collins wrote: > On Tue, 12 Mar 2019 at 13:28, G. P. B. > wrote: > > > > > I was more going along the lines of removing short tags altogether > > with the > > ini setting as they are not available out of the box except if you > > use a > > special compile

Re: [PHP-DEV] print with newline

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 echoed. In PHP and > > other languages there isn't. Changing

Re: [PHP-DEV] print with newline

On So, 2019-03-03 at 05:53 -0800, Steven Penny wrote: > On Sun, 03 Mar 2019 06:49:25, Joe Watkins wrote: > > > > Jokes aside, this is so trivially achievable in userland that there > > is no > > justification whatever for an internal function or functions, or > > constructs, or opcodes. > if

Re: [PHP-DEV] print with newline

On So, 2019-03-03 at 14:33 +, Rowan Collins wrote: > On 02/03/2019 23:15, Steven Penny wrote: > > > > > > > > > > > > > 4. introduce a new variable, perhaps > > > > "$OUTPUT_RECORD_SEPARATOR",  > > > > "$ORS", "$\" > > > > or similar, that controls output record separator > > > Such magic

Re: [PHP-DEV] print with newline

On Sa, 2019-03-02 at 11:59 -0800, Steven Penny wrote: > 1. Modify one or more of "print", "print_r", "var_export" such that > they produce >    a newline by default This is a break of backwards compatibility in a bad way. This breaks people doing specific output. > 2. Modify one or more of

Re: [PHP-DEV] Allow throwing from __toString()

On March 1, 2019 10:52:02 PM GMT+01:00, "Christoph M. Becker" wrote: >On 01.03.2019 at 21:31, Johannes Schlüter wrote: > >> On Fr, 2019-03-01 at 18:28 +0100, Nikita Popov wrote: >>> made the same mistake there. So there's one more point to add to the >>

Re: [PHP-DEV] Allow throwing from __toString()

On Fr, 2019-03-01 at 18:28 +0100, Nikita Popov wrote: > made the same mistake there. So there's one more point to add to the > extension guidelines: Do we have a persistent space to keep those? The internals manual is limited ... :-) > I'm happy to find and fix these bugs, rather than leave the

Re: [PHP-DEV] Allow throwing from __toString()

On Fr, 2019-03-01 at 12:25 +0100, Nikita Popov wrote: > For extension authors, the guideline is: Will zend_parse_paramters and related detect if an exception is thrown and fail? I believe things like database (or other network) extensions have to be really carefully checked, not that we store

Re: [PHP-DEV] Re: phpenmod/phpdismod

On Mo, 2019-02-18 at 23:39 +0100, Legale.legale wrote: > I have made super simple OS independent phpenmod.  >   > Https://github.com/legale/phpenmod This won't replace Ubuntu's version since on Ubuntu different SAPIs use different ini dirs. Functionality-wise it is also no replacement as

Re: [PHP-DEV] Drop support for libreadline

Hi, On Mi, 2019-02-13 at 11:56 +0100, Remi Collet wrote: > Hi, > > > Terribly old and known issue. > > libreadline license (GPL) is incompatible with PHP > > We support build with libedit (BSD) for years > > Most Linux distribution use libedit > Windows also use libedit > > > So, this PR

Re: [PHP-DEV] Convert ext/xml to use an object instead of resource

On Di, 2019-02-12 at 10:29 -0500, Bishop Bettini wrote: > Would it make sense to update is_resource > (and friends) to be aware that "resources" returned from xml_parser_* > are not resources proper, but rather resources nominal? > > If userland needed to strictly determine what was a resource

Re: [PHP-DEV] phpenmod/phpdismod

On Mo, 2019-02-04 at 07:24 +0100, Remi Collet wrote: >  > P.S. I have never understand the need of such tools... > did it made sense in previous century, where download have a cost ? > > BTW, on package linux distro, when I install a webapp which depends > on > some extensions, I obviously expect

Re: [PHP-DEV] New website for the PHP project

On Mo, 2019-02-04 at 15:32 +0200, Andrey Andreev wrote: > Hi, > > I could nitpick on most of the proposed plan, but I really only > wanted > to reply to this: > > > > > > > > > * A new home page, not a "news" page, but a page simply showing > > > the PHP Logo, a code example maybe and > > >

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Sa, 2019-02-02 at 01:20 -0500, Bishop Bettini wrote: > So, how do we identify those who are currently the most contributory? > Commits mostly, though we can't ignore other qualities. In a 2003 > paper[1], Scacchi (UC Irvine) defined a F/OSS meritocracy pyramid in > which those at the top had

Re: [PHP-DEV] phpenmod/phpdismod

On Sa, 2019-02-02 at 21:52 +0100, Legale.legale wrote: > For example: > phpenmod mysqli > will try to find an extension and if it exists, script will create > related ini file in the conf.d directory. > phpdismod mysqli > will remove ini file from the conf.d dir. > > It makes a world a bit more

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Do, 2019-01-31 at 14:28 -0500, Bishop Bettini wrote: > >    2. Core developers are defined as the top 13 committers within the >    period of two years since voting began. A core developer is a de > facto >    community member, but caucuses as a core developer. How do you define "top 13

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Do, 2019-01-31 at 15:44 +0200, Zeev Suraski wrote: > Without further ado, an RFC that’s attempting to comprehensively > solve many of the issues that have plagued our RFC process since it > was hastily introduced in 2011: > > https://wiki.php.net/rfc/voting2019 > Being mostly outside I

Re: [PHP-DEV] Unbundle libsqlite3?

On Mo, 2018-09-17 at 15:16 +0200, Christoph M. Becker wrote: > So is there any particular reason why we still bundle libsqlite3? An issue is that users often  don't control the version being used and SQLite adds features to it's SQL dialect from time to time. At the moment, with the bundled

Re: [PHP-DEV] bugs.php.net usability, migration to a different tool

Popov wrote: > On Thu, Aug 9, 2018 at 1:54 AM, Hoffman, Zachary Robert .edu> > wrote: > > > > > > > > > On Wed, 2018-08-08 at 18:16 +0200, Johannes Schlüter wrote: > > > > > > > > > On August 8, 2018 6:06:00 PM GMT+0

Re: [PHP-DEV] bugs.php.net usability, migration to a different tool

On August 8, 2018 6:06:00 PM GMT+02:00, "Johannes Schlüter" wrote: > > >On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary Robert" > wrote: >>On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote: >>> On Di, 2018-08-07 at 15:10 -05

Re: [PHP-DEV] bugs.php.net usability, migration to a different tool

On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary Robert" wrote: >On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote: >> On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote: >> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski >> wrot

Re: [PHP-DEV] bugs.php.net usability, migration to a different tool

On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote: > On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski > wrote: > >  > > 3. As stated on twitter > > (https://twitter.com/official_php/status/1024658601770668033 ) > > there > > are some specific needs which make the move to different tool > >

Re: [PHP-DEV] PHP 2^3

On Mo, 2018-06-25 at 16:14 -0700, Alice Wonder wrote: > As a packager github is a fracking nightmare. > > Frequently what we do is include a hash of the release tarball in our > build and require that it matches so that people rebuilding our > package (e.g. to add a patch they need) don't have to

Re: [PHP-DEV] PHP 2^3

On Mo, 2018-06-25 at 09:58 -0500, Ralph Schindler wrote: > On 6/25/18 9:13 AM, Johannes Schlüter wrote: > > > > On Mo, 2018-06-25 at 12:30 +, Zeev Suraski wrote: > > > > > > 3. Foreign Function Interface support. > > Related to this on a non-PHP

Re: [PHP-DEV] PHP 2^3

On Mo, 2018-06-25 at 12:30 +, Zeev Suraski wrote: > 3. Foreign Function Interface support.  Related to this on a non-PHP-code and strategic matter I would like to rethink PECL. Currently maintenance and installing extensions using it is a pita. This should be doable in a nicer way.  (i.e.

Re: [PHP-DEV] [RFC][Discussion] iterable_to_array() and iterable_count()

On Mi, 2018-06-20 at 03:55 +0200, Michael Moravec wrote: > Hello internals, > > I'd like to propose two new functions for PHP 7.3: > iterable_to_array() and > iterable_count() > > These functions are supposed to work with iterables (7.1 pseudotype) > - both arrays and iterators, unlike

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

Hi, On Di, 2018-06-12 at 13:54 +0200, Christoph M. Becker wrote: > > https://wiki.php.net/rfc/umaintained_extensions > > I think it is *very* important to finally tackle this topic.  Since > it It's a good subject to think about, but we should be careful not to end with a process and then

Re: [PHP-DEV] what's the official position on apache threaded environments

On Mi, 2018-03-21 at 22:52 -0700, Alice Wonder wrote: > Is there a list somewhere of what the specific issues with using zts > in multi-threaded apache are? What modules have known issues? > > I haven't found it. PHP itself should be thread-safe, if there are bugs inside PHP itself we try to

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

On Mo, 2018-02-12 at 14:36 -0600, Michael Morris wrote: > Any particular reason why "`unicode string `" wouldn't work? Because this would be a BC break which is really hard to detect. People might do this (i.e. while generating Markdown output or something about shell scripting or ...) and this

Re: [PHP-DEV] Potential adoption of run-tests.php replacement

On So, 2018-02-04 at 01:53 -0800, Stanislav Malyshev wrote: > - Section support - I think besides TEST, the following will be > needed: > * XFAIL: unfortunately, those are still needed > * ENV: there are a lot of environment-dependent tests as it seems > * FILE_EXTERNAL: is pretty widely used > *

Re: [PHP-DEV] threadsafe php crashes too easily

On Fr, 2018-01-26 at 12:43 +0100, Hajo Locke wrote: > Hello List, > > i hope this is the right place to get helped. I have a promising > setup  > for testing purposes, but unfortunately i ran quick into problems. > >   I compiled a minimal libphp7.so (7.2.1)  using this line: > ./configure

Re: [PHP-DEV] [RFC] is_countable

Hi, On So, 2018-01-21 at 18:01 +, Gabriel Caruso wrote: > After that, I like to propose and discuss a new function for PHP 7.x > (current 7.3): is_countable. > > *RFC*: https://wiki.php.net/rfc/is-countable. The primary place for this imo should be reflection. If there is high demand we

Re: [PHP-DEV] Security mailing list

On Mi, 2018-01-10 at 19:38 +0100, Christoph M. Becker wrote: > On 10.01.2018 at 19:31, Kalle Sommer Nielsen wrote: > > > > > 2018-01-10 17:58 GMT+01:00 Christoph M. Becker : > > > > > > > > Can someone please point out, how I can subscribe to the security > > > mailing list? 

Re: [PHP-DEV] Mailing list moderation

On Di, 2018-01-02 at 11:49 +0100, Nikita Popov wrote: > li...@rhsoft.net, who have recently been > aggressively derailing  He was blocked in 2012 already: https://externals.io/message/59395#59421 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Outstanding php.net account requests

On Di, 2017-12-19 at 21:17 +, Anatol Belski wrote: > IMO it is a strategical question and we should keep up with the real > world. It was one of the reasons for Pickle to come to life, which > however didn't come to the optimal end implementation meanwhile. > There's github, bitbucket, etc.

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

On December 12, 2017 8:51:42 AM GMT+01:00, Stanislav Malyshev wrote: >Hi! > >> The issue, as you well know, is that references disable >copy-on-write. Thus assume you have code like this: >> >> function with_ref(&$a) { >>count ($a); >> } >> >> function no_ref($a) {

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

On December 12, 2017 7:38:54 AM GMT+01:00, Stanislav Malyshev wrote: >Hi! > >> I would rather discourage usage of references. Since PHP 7 the cost >of >> breaking cow isn't as expensive anymore, but receiving values by >value >> and returning by value is more idiomatic

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi, On Mi, 2017-12-06 at 20:49 +0100, Nikita Popov wrote: > Hi internals, > > I'd like propose optional support for explicitly marking by-reference > argument passing at the call-site, in addition to the declaration- > site: > > https://wiki.php.net/rfc/explicit_send_by_ref > I would

Re: [PHP-DEV] Outstanding php.net account requests

On Di, 2017-12-05 at 14:57 +0100, Christoph M. Becker wrote: > On 05.12.2017 at 14:34, Pedro Magalhães wrote: > > > > > On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter <johannes@schlue > > ters.de> > > wrote: > > > > > > > > we c

[PHP-DEV] Outstanding php.net account requests

Hi, we currently have 118 outstanding php.net account requests going back to October 2016. If you recently tried to onboard somebody could you verify whether they are still unapproved? If somebody creates a mass- edit interface this would also be great, as the CSRF protection makes deleting

Re: [PHP-DEV] Re: Public Tags of Releases

On Mi, 2017-11-29 at 15:43 +0100, li...@rhsoft.net wrote: > Am 29.11.2017 um 15:37 schrieb Johannes Schlüter: > > > > On Mi, 2017-11-29 at 12:09 +0100, Jan Ehrhardt wrote: > > > > > > FWIW: I am using the zip's at github, like > > > https://gi

Re: [PHP-DEV] Re: Public Tags of Releases

On Mi, 2017-11-29 at 12:09 +0100, Jan Ehrhardt wrote: > FWIW: I am using the zip's at github, like > https://github.com/php/php-src/archive/php-7.2.0.zip Contrary to "official" release tarballs those don't contain generated parsers etc. thus behavior might be different i.e. due to different

Re: [PHP-DEV] Proposal: Rename image functions

On So, 2017-11-05 at 20:18 -0500, Michael Morris wrote: > Then, for backward compatibility, add a php.ini setting that runs > "import PHP\Legacy" at the start of each script. We did that mistake with magic_quotes and the ze1 compatibility mode in PHP 5.0. We should learn from that and reduce

Re: [PHP-DEV] Proposal: Rename image functions

On So, 2017-11-05 at 14:51 +0100, Peter Kokot wrote: > Hello all, > > correct me if I'm wrong, but wouldn't be a good practice to follow > the > currently set coding standards? > https://github.com/php/php-src/blob/master/CODING_STANDARDS That is good for new code. But breaking 20 years of

Re: [PHP-DEV] Idea: PDO - Single-round-trip prepared statements

On Sa, 2017-11-04 at 08:28 +0100, Matteo Beccati wrote: > Hi, > > On 03/11/2017 21:25, Scott Arciszewski wrote: > > > > MySQL calls it an X Protocol, apparently. > > > > https://dev.mysql.com/doc/internals/en/x-protocol-use-cases-use-cas > >

Re: [PHP-DEV] Mysql result data types

On Do, 2017-10-12 at 14:55 +0300, Reinis Rozitis wrote: > Hello, > is there a reason (technical or historical) why the data coming from > MySQL is always strings? > I've found only one case where the data type is "honored" - > PDO+mysqlnd+emulation off [1] The reason for this is that this is the

Re: [PHP-DEV] Parallelised run-tests.php (patch)

On Di, 2017-10-10 at 13:35 +0100, Andrea Faulds wrote: > > This is cool! I also see (from very very very) short look on the > > github diff that you have a parallelization protection for some > > tests, which  might share resources. Very good! > I'm glad you like it! Although I discover now that

Re: [PHP-DEV] Parallelised run-tests.php (patch)

On So, 2017-10-08 at 04:47 +0100, Andrea Faulds wrote: > Have you long since ABANDONED every test directory besides > Zend/tests? ... or ran only eext/foo/tests ;) > …*ahem*. Okay, enough terrible salesmanship. I felt like > parallelising  > run-tests.php, so I did it. If you give it the flag

Re: [PHP-DEV] Re: GitHub and Extensions

On Fr, 2017-10-06 at 20:11 +0200, Christoph M. Becker wrote: > Not sure about issues, though.  Probably these shouldn't even be > available. > Correct, usually we disable issues and point users to bugs.php.net to have a central bug database instead of having to track multiple trackers. Usually

Re: [PHP-DEV] RFC proposal: Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1

On Mi, 2017-10-04 at 11:23 -0700, Walter Parker wrote: > Sorry, my mistake. I didn't notice when PHP changed from GPL style to > BSD style. > Hard to remember, since that happened already during the last century (with PHP 3 in 1997) ;-) And yes, LGPL modules are tolerable, but not liked. GPL is

Re: [PHP-DEV] Expose gmp_ce and friends

On Mo, 2017-10-02 at 17:33 -0400, Sara Golemon wrote: > Stas specifically, but also others: > > Any objections if I apply > https://github.com/php/php-src/compare/master...sgolemon:gmp.export > to > make consuming GMP objects from third-party extensions easier? > > -Sara I would prefer not

Re: [PHP-DEV] PHP extension - Saxon/C

On Fr, 2017-09-22 at 12:01 +0100, O'Neil Delpratt wrote: >  > [Fri Sep 22 08:56:42 2017]  Script:  '/home/ond1/work/svn/latest9.8- > saxonc/hec/samples/php/xqueryExamples.php' > /home/ond1/work/svn/latest9.8- > saxonc/hec/Saxon.C.API/php7_saxon.cpp(3250) :  Freeing  [...] > See full code of PHP

Re: [PHP-DEV] array_filter vs for/foreach usage cost

Hi, On Do, 2017-09-07 at 15:13 -0300, David Rodrigues wrote: > I understand that array_filter() should costs more than for/foreach > because > it is a function call that call another function for each item, while > the > for/foreach is a language constructor that works on a way totally >

  1   2   3   4   5   6   7   8   9   10   >