On 25 October 2012 13:46, JJ ja...@php.net wrote:
On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
theanomaly...@gmail.com wrote:
I understand there are people out there that don't read the
documentation and aren't aware of the difference between
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
On Thu, Oct 25, 2012 at 1:46 AM, JJ ja...@php.net wrote:
On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
theanomaly...@gmail.com wrote:
I understand there are people out there that don't read the
documentation and aren't aware of the difference between
curl_setopt($ch,
On Wed, Oct 24, 2012 at 11:21 PM, Sherif Ramadan theanomaly...@gmail.comwrote:
On Thu, Oct 25, 2012 at 1:46 AM, JJ ja...@php.net wrote:
On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
theanomaly...@gmail.com wrote:
I understand there are people out there that don't read the
CURLOPT_SSL_VERIFYHOST - this option just sounds like should I verify
host?, when it must sound like what verifying strategy should I use?
On Thu, 25 Oct 2012 10:19:24 +0400, Adam Harvey ahar...@php.net wrote:
On 25 October 2012 13:46, JJ ja...@php.net wrote:
On Wed, Oct 24, 2012 at 10:34
hi!
On Wed, Oct 24, 2012 at 10:47 PM, Eric Stenson erics...@microsoft.com wrote:
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
[Pierre said:]
It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any
On Thu, Oct 25, 2012 at 8:36 AM, Kris Craig kris.cr...@gmail.com wrote:
What if, instead of changing the behavior, we have it throw a notice or
warning if a boolean value is passed here? Because this is such a common
error, I think it could be really beneficial in helping developers catch
On 10/24/2012 11:34 PM, Sherif Ramadan wrote:
On Thu, Oct 25, 2012 at 1:03 AM, JJ ja...@php.net wrote:
Hey all - I'd like start a discussion around pull request 221
(https://github.com/php/php-src/pull/221).
In short, there's a high volume of [incorrect] code out there which looks like:
On 10/25/2012 12:36 AM, Kris Craig wrote:
On Wed, Oct 24, 2012 at 11:21 PM, Sherif Ramadan theanomaly...@gmail.comwrote:
On Thu, Oct 25, 2012 at 1:46 AM, JJ ja...@php.net wrote:
On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
theanomaly...@gmail.com wrote:
I understand there are people out
2012/10/25 crankypuss fullm...@newsguy.com
On 10/24/2012 11:34 PM, Sherif Ramadan wrote:
On Thu, Oct 25, 2012 at 1:03 AM, JJ ja...@php.net wrote:
Hey all - I'd like start a discussion around pull request 221
(https://github.com/php/php-**src/pull/221https://github.com/php/php-src/pull/221
On 25 October 2012 18:38, Sebastian Krebs krebs@gmail.com wrote:
2012/10/25 crankypuss fullm...@newsguy.com
Booleans ought to be 1 and 0. Casting a boolean to 2 is just wrong, a way
to fix badly written code a few people have written and in so doing risk
the breakage of far more code that
So you propose to implement strict type checking of parameters because a
few bozos don't read the documentation? That doesn't make much sense to me.
What makes more sense is that the extension perform its own type checking
where that is appropriate. I have plenty of subroutine code that
On 10/25/2012 04:54 AM, Kris Craig wrote:
So you propose to implement strict type checking of parameters because a
few bozos don't read the documentation? That doesn't make much sense to me.
What makes more sense is that the extension perform its own type checking
where that is appropriate. I
I completely agree with Adam and others, we should not change the
behaviour to add any magic.
The ext/curl api was made to stay as close as possible from the
original libcurl api and it should stay the same (even if it's not
always implicit). A lot of people are often referring to the libcurl C
All,
On Thu, Oct 25, 2012 at 3:14 AM, Guillaume Rossolini
g.rossol...@gmail.comwrote:
On Thu, Oct 25, 2012 at 8:36 AM, Kris Craig kris.cr...@gmail.com wrote:
What if, instead of changing the behavior, we have it throw a notice or
warning if a boolean value is passed here? Because this is
Hi,
Am 25.10.2012 um 07:03 schrieb JJ ja...@php.net:
[...]
My solution was to check the type for CURLOPT_SSL_VERIFYHOST: if it is
boolean and true, the opt value for libcurl is set to 2L.
I understand that engineers should have the proper option value to
begin with but weighing the impact
On Thu, Oct 25, 2012 at 7:26 AM, Anthony Ferrara ircmax...@gmail.comwrote:
All,
On Thu, Oct 25, 2012 at 3:14 AM, Guillaume Rossolini
g.rossol...@gmail.com wrote:
On Thu, Oct 25, 2012 at 8:36 AM, Kris Craig kris.cr...@gmail.com wrote:
What if, instead of changing the behavior, we have
If there are no objections, I'll go ahead and draft an RFC for the
notice/docs idea later today. If anyone would like to co-author it with
me, please drop me an email and I'll send you the wiki link once I've
created the page.
Do we even need an RFC for this? I would personally just open a
On 10/25/2012 08:53 AM, Anthony Ferrara wrote:
If there are no objections, I'll go ahead and draft an RFC for the
notice/docs idea later today. If anyone would like to co-author it with
me, please drop me an email and I'll send you the wiki link once I've
created the page.
Do we even
Do we even need an RFC for this? I would personally just open a bug and
commit the change.
But if people want an RFC, that's fine... It just seems like a huge
undertaking for such a minor change...
I see no need for an RFC just to add a helpful notice here. Just do it.
Thanks
FYI: the bug is: 63363
https://bugs.php.net/bug.php?id=63363
On Thu, Oct 25, 2012 at 12:06 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Do we even need an RFC for this? I would personally just open a bug and
commit the change.
But if people want an RFC, that's fine... It just seems
Rasmus et al,
I see no need for an RFC just to add a helpful notice here. Just do it.
-Rasmus
Should this target master only (5.5)? Or 5.3/5.4 as well?
My tendancy would be to target 5.5 only, but I can see the argument made
that it should target 5.3/5.4 as well... Thoughts?
Anthony
Hi!
My tendancy would be to target 5.5 only, but I can see the argument made
that it should target 5.3/5.4 as well... Thoughts?
I think it'd be fine for 5.4. Please do a pull req first though to be sure.
Thanks,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Agreed.
https://github.com/johnj/php-src/commit/905f7121fa664380c97f71ff9cbc4b6c04396374
- JJ
On Thu, Oct 25, 2012 at 8:54 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
I see no need for an RFC just to add a helpful notice here. Just do it.
-Rasmus
--
PHP Internals - PHP Runtime
Stas suggested this should throw a notice instead of a warning, I've
amended. Thx all.
https://github.com/php/php-src/pull/221
- JJ
On Thu, Oct 25, 2012 at 11:39 AM, JJ ja...@php.net wrote:
Agreed.
https://github.com/johnj/php-src/commit/905f7121fa664380c97f71ff9cbc4b6c04396374
- JJ
On
Just use logrotate for that.
On 2012-10-25 23:16, Raymond Irving wrote:
Hello,
How about adding an option to recycle the PHP log when it gets too big?
For example:
[php ini]
max_error_log_size = 512k
When the log file is larger than 512k rename the file by adding the current
date or
On Thu, Oct 25, 2012 at 2:48 PM, JJ ja...@php.net wrote:
Stas suggested this should throw a notice instead of a warning, I've
amended. Thx all.
https://github.com/php/php-src/pull/221
The PR has been merged in and closed. It has been merged into 5.4 and
master.
Thanks for the contribution!
26 matches
Mail list logo
