On Tue, 2014-12-30 at 12:57 +, Craig Duncan (PHP) wrote:
I'd be willing to spend some time on this. Presumably I'd need some
authorised access to the bug tracker?
You can simply add comments without special account, people with account
will follow up and close/assign accordingly. For them
De : Nikita Popov [mailto:nikita@gmail.com]
str_replace is a simple function for string replacement. It has some (imho
also unnecessary)
extra gimmicks to implicitly do a foreach() loop during the replacement. This
is still relatively
simple API-wise. But if I see this (taken from the
On Fri, Jan 9, 2015 at 1:08 AM, François Laupretre franc...@tekwire.net
wrote:
Hi,
I just created the RFC :
https://wiki.php.net/rfc/cyclic-replace
I tried to include everything we agreed upon. Tell me if I missed
something.
Please note that the current PR does not implement the whole
Hi,
On Sat, Jan 10, 2015 at 1:53 PM, Nikita Popov nikita@gmail.com wrote:
But if I see this (taken from the tests) as the search replacement values...
$search=array('[?]',array('(?)','d','e'),'a','R');
$repl=array(
array('ap(?)z[?]',b[?](?)v,null,37,[?]n[?]),
Hi Andrey,
De : Andrey Andreev [mailto:n...@devilix.net]
I have to agree here. Nested arrays are too much ... it should be
limited to single-dimension arrays.
It makes the C code simpler to understand. But I am OK not to document the
feature for search and replace. I'd like to keep it for
On 1/10/15 9:03 AM, François Laupretre wrote:
To summarize, I started with a rather simple feature request and was
then pushed by external wishes.
See #13 at
https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
Take advice on board but make sure your feature doesn't end up
De : christopher jones [mailto:christopher.jo...@oracle.com]
To summarize, I started with a rather simple feature request and was
then pushed by external wishes.
See #13 at
https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
Take advice on board but make sure your feature
De : François Laupretre [mailto:franc...@tekwire.net]
De : Andrey Andreev [mailto:n...@devilix.net]
I have to agree here. Nested arrays are too much ... it should be
limited to single-dimension arrays.
It makes the C code simpler to understand. But I am OK not to document the
feature
De : François Laupretre [mailto:franc...@tekwire.net]
I just created the RFC :
https://wiki.php.net/rfc/cyclic-replace
Just added full array multi-level recursion support to the RFC.
Final (?) patch pushed to PR. In sync with RFC.
Please also give me your opinion about implementing
On Jan 10, 2015 8:35 AM, François Laupretre franc...@tekwire.net wrote:
De : François Laupretre [mailto:franc...@tekwire.net]
I just created the RFC :
https://wiki.php.net/rfc/cyclic-replace
Just added full array multi-level recursion support to the RFC.
Final (?) patch pushed
Hi,
Just wanted to say: +1 on this and thank you for proposing a patch.
I myself created a feature request for it on bugs.php.net some time
ago, now closed as duplicate: https://bugs.php.net/bug.php?id=62315
Cheers,
Andrey.
On Fri, Jan 9, 2015 at 2:08 AM, François Laupretre
De : François Laupretre [mailto:franc...@tekwire.net]
I just created the RFC :
https://wiki.php.net/rfc/cyclic-replace
Just added full array multi-level recursion support to the RFC.
Still debugging the code and adding new tests.
Please also give me your opinion about implementing a
Hi,
I just created the RFC :
https://wiki.php.net/rfc/cyclic-replace
I tried to include everything we agreed upon. Tell me if I missed something.
Please note that the current PR does not implement the whole RFC. You may
review the RFC while I update the code.
Please also give me your opinion
Hi,
I just created a PR for a feature request lying around since 2006 :
https://github.com/php/php-src/pull/980
It adds support in str_replace() and str_ireplace() for the combination of
(string needle, array replace). In this case, each occurrence of the needle
is replaced with an element f
Hey François,
On 5 Jan 2015, at 17:15, F N Laupretre nf.laupre...@yahoo.fr wrote:
I just created a PR for a feature request lying around since 2006 :
https://github.com/php/php-src/pull/980
It adds support in str_replace() and str_ireplace() for the combination of
(string needle,
On Mon, Jan 5, 2015 at 9:30 PM, Andrea Faulds a...@ajf.me wrote:
On 5 Jan 2015, at 20:28, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
usually each BC break would warrant an RFC and a vote, but I'm not sure
many people would use str_replace(foo, array(bar), $subject); and
On Mon, Jan 5, 2015 at 9:28 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
usually each BC break would warrant an RFC and a vote, but I'm not sure
many people would use str_replace(foo, array(bar), $subject); and
expect the implicit array to string conversion of array(bar) = Array
On Mon, Jan 5, 2015 at 6:20 PM, Andrea Faulds a...@ajf.me wrote:
Hey François,
On 5 Jan 2015, at 17:15, F N Laupretre nf.laupre...@yahoo.fr wrote:
I just created a PR for a feature request lying around since 2006 :
https://github.com/php/php-src/pull/980
It adds support in
Hi!
usually each BC break would warrant an RFC and a vote, but I'm not sure
many people would use str_replace(foo, array(bar), $subject); and
expect the implicit array to string conversion of array(bar) = Array
which also emits a notice.
let's see what others think.
I wouldn't consider this
On 5 Jan 2015, at 20:28, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
usually each BC break would warrant an RFC and a vote, but I'm not sure
many people would use str_replace(foo, array(bar), $subject); and
expect the implicit array to string conversion of array(bar) = Array
which
Levi wrote:
...and what to do with feature requests?
Stanislav Malyshev smalys...@gmail.com wrote:
if it's clear what is being asked than just leave them alone,
Would it be appropriate to close issues that are clear, but can easily
be done in userland e.g. https://bugs.php.net/bug.php?id=64639
On Sun, Jan 4, 2015 at 8:50 PM, Dan Ackroyd dan...@basereality.com wrote:
Levi wrote:
...and what to do with feature requests?
Stanislav Malyshev smalys...@gmail.com wrote:
if it's clear what is being asked than just leave them alone,
Would it be appropriate to close issues that are
Hi!
Would it be appropriate to close issues that are clear, but can easily
be done in userland e.g. https://bugs.php.net/bug.php?id=64639
Leaving an issue like that open seems to pretty pointless, even though
it is clear what is being asked.
Yes, this one is pretty clearly not going to
On 29 December 2014 at 07:59, Stanislav Malyshev smalys...@gmail.com
wrote:
We definitely need somebody triaging old bugs. The problem is it
requires a real lot of time, and is mind-numbingly boring, so not many
people do it. Many bugs are low quality - missing data, not having good
Hi!
For a while I have been just stalking the bugs database[1], and I
would love if we could some more focus on closing bugs. I'm not saying
the job we do (my self included) is not being done well enough, but
currently we have over 4.1k and a lot of those are old feature
requests, or bugs
For a while I have been just stalking the bugs database[1], and I
would love if we could some more focus on closing bugs. I'm not saying
the job we do (my self included) is not being done well enough, but
currently we have over 4.1k and a lot of those are old feature
requests, or bugs going
Hi!
...and what to do with feature requests?
I would say - if it looks big (i.e. BC-breaking change, language change,
completely new functionality that may influence other parts of the
language, etc.), recommend submitting the RFC, otherwise if it's clear
what is being asked than just leave
I will have some time the next few days, I have little C knowledge and never
committed something to PHP core, but I could take a look and do some cleanup.
Sent from my iPhone 7 Beta [Confidential use only]
On 29 dec. 2014, at 19:02, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
Any chance to people without Karma helping here? Maybe trying to reproduce
the bug in 5.4+ and asking for feedback? Any workflow suggested?
On Dec 29, 2014 4:03 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
...and what to do with feature requests?
I would say - if it looks big (i.e.
I'm pretty sure that just trying to reproduce a problem and posting
results in the comment, would be *very* helpful.
W dniu 2014-12-29 o 19:19, Rafael Kassner pisze:
Any chance to people without Karma helping here? Maybe trying to reproduce
the bug in 5.4+ and asking for feedback? Any workflow
My previous suggestion was to have a contributors page and it will rank
people based on bug fixes.
There appears to be a trend emerging where frameworks are making this more
of a feature on their sites and there's nothing people enjoy more than
getting recognition for their effort - even if
On Sun, Dec 28, 2014 at 7:45 AM, Remi Collet r...@fedoraproject.org wrote:
Le 27/12/2014 16:06, Sebastian Bergmann a écrit :
Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
bugs going as far back as to PHP4.
Bug reports for PHP version that are not supported anymore [1]
should
I have committed a fix for one bug and closed another bug report
because of this thread. I will continue to look at bugs but I wanted
to spread some encouragement.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Come up with a way to incentivise people to fix bugs.
My previous suggestion was to have a contributors page and it will rank
people based on bug fixes.
I'd be happy to work on this with someone.
On 28 Dec 2014 19:16, Levi Morrison le...@php.net wrote:
I have committed a fix for one bug and
Hi Pasindu
2014-12-28 23:43 GMT+01:00 Pasindu De Silva ppasin...@gmail.com:
Hi
I would like join and fix some I have been trying to fix some bugs in
DateTIme thought it was a good place to start, is there maybe a way to add a
label called
novice or starter bugs for people with little
Hi Kelle Thanks will dig in
On Mon, Dec 29, 2014 at 4:28 AM, Kalle Sommer Nielsen ka...@php.net wrote:
Hi Pasindu
2014-12-28 23:43 GMT+01:00 Pasindu De Silva ppasin...@gmail.com:
Hi
I would like join and fix some I have been trying to fix some bugs in
DateTIme thought it was a good
Howdy dear Internals
For a while I have been just stalking the bugs database[1], and I
would love if we could some more focus on closing bugs. I'm not saying
the job we do (my self included) is not being done well enough, but
currently we have over 4.1k and a lot of those are old feature
Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
bugs going as far back as to PHP4.
Bug reports for PHP version that are not supported anymore [1]
should IMHO be bulk-closed. The message should ask to reopen if
the bug is reproducible with a supported version of PHP. IMHO :)
--
[1]
On 27 December 2014 15:06:42 GMT, Sebastian Bergmann sebast...@php.net wrote:
Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
bugs going as far back as to PHP4.
Bug reports for PHP version that are not supported anymore [1]
should IMHO be bulk-closed. The message should ask to reopen if
Hey all,
On 27 Dec 2014, at 18:34, Rowan Collins rowan.coll...@gmail.com wrote:
On 27 December 2014 15:06:42 GMT, Sebastian Bergmann sebast...@php.net
wrote:
Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
bugs going as far back as to PHP4.
Bug reports for PHP version that are
Hi Andrea
2014-12-27 20:08 GMT+01:00 Andrea Faulds a...@ajf.me:
As Rowan says, this would be a problem. Rather than just closing all bugs
that are of a certain age, we should just go through all the open bugs one by
one. 4000 open bugs is a lot, sure, but with a few people working at it I
I for one are against just closing old bugs without at least a review
too. If we can have 5-10 developers (from any part of the community
with a @php.net account) to look over a few bugs a day, then we can
quickly bring that number down.
I'll gladly enlist here. I've gone through bugs in the
One of the biggest issues I have found with the PHP bug tracker is the
inability to filter on tickets and find the low hanging fruit based on a
label or a priority. I realise the advanced search allows you to find
based on package however this still is not enough. I am quite new to the
Hey Jacob,
On 28 Dec 2014, at 01:48, Jacob Bednarz jacob.bedn...@gmail.com wrote:
One of the biggest issues I have found with the PHP bug tracker is the
inability to filter on tickets and find the low hanging fruit based on a
label or a priority.
What do you mean by this? What’s a
What do you mean by this? What’s a priority? You can sort by votes, you
can filter by status, I’m not sure what you mean with “on a label”.
Could you please elaborate? Thanks.
Sure - A label can be anything that is used to allow finer searching of
issues. For example, I don't have a specific
Hey Jacob,
On 28 Dec 2014, at 03:09, Jacob Bednarz jacob.bedn...@gmail.com wrote:
What do you mean by this? What’s a priority? You can sort by votes, you can
filter by status, I’m not sure what you mean with “on a label”.
Could you please elaborate? Thanks.
Sure - A label can be
Well, there isn’t such a label because labels have to be created by
people going through and adding that label to bugs. So someone has to look
through 4000 bugs.
This definitely could be an issue for existing bugs but if it's available
when someone creates a bug they could fill it out at
Hi again,
On 28 Dec 2014, at 03:11, Andrea Faulds a...@ajf.me wrote:
On 28 Dec 2014, at 03:09, Jacob Bednarz jacob.bedn...@gmail.com wrote:
What do you mean by this? What’s a priority? You can sort by votes, you can
filter by status, I’m not sure what you mean with “on a label”.
Could
Le 27/12/2014 16:06, Sebastian Bergmann a écrit :
Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
bugs going as far back as to PHP4.
Bug reports for PHP version that are not supported anymore [1]
should IMHO be bulk-closed. The message should ask to reopen if
the bug is reproducible
49 matches
Mail list logo
