On 07/30/2012 01:02 AM, Lester Caine wrote:
Having just been helping another unsophisticated user, the growing
problem of incompatibility between versions is starting to hit harder.
So can developers please start taking a little more care with the
support of existing users!
Lester, we get it.
On 07/26/2012 11:36 PM, Alex Aulbach wrote:
1) The bigger the language grows, the more we need to think about how
to implement new features.
I think it's a bad argument to say we made this and that not so
ideal, so we can make this also. Don't be so idealistic. :)
I think it's a duty to make
On 07/27/2012 11:59 PM, Lester Caine wrote:
Rasmus Lerdorf wrote:
I don't think this generator question is any different. We need to
explain generators in the simplest way possible. The simplest way to
explain generators is to not even worry about them being generators at
all. Simply say
On 07/28/2012 12:37 AM, Lester Caine wrote:
Rasmus Lerdorf wrote:
I don't think this generator question is any different. We need to
explain generators in the simplest way possible. The simplest way to
explain generators is to not even worry about them being
generators at
all. Simply say
On 07/28/2012 07:09 AM, Johannes Schlüter wrote:
On Fri, 2012-07-27 at 22:07 +0200, Anatoliy Belsky wrote:
after working for some time with the PHP test suite I've realized - it
needs an improvement of a special kind. What I'm talking about is the
server based testing. Very urgent cases have
On 07/28/2012 11:24 AM, Johannes Schlüter wrote:
On Sat, 2012-07-28 at 10:08 -0700, Rasmus Lerdorf wrote:
For that I once created a special SAPI, which can also do
multi-threading:
https://github.com/johannes/pconn-sapi
http://schlueters.de/blog/archives/166-Testing-persistent
On 07/25/2012 04:25 PM, Alex Aulbach wrote:
In 50 lines of code yield will be just overseen.
But I meant something different: I thought of documentation. Maybe
someone reads the docs. Really! In the docs he will find functions.
And in the function this yield. He dosn't want to know that. It
On 07/24/2012 06:35 AM, Nikita Popov wrote:
On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@php.net wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
The finally clause comes with a
On 07/24/2012 10:01 AM, Nikita Popov wrote:
Another, separate point against finally is that in PHP (unlike many
other languages) most (all?) built-in resources clean up after
themselves. So if you open a file you don't have to worry about
closing it again. It'll do that all by itself as soon
On 07/20/2012 05:16 PM, Rick Bird wrote:
Hi,
My name is Rick.. I done some light work on documentation side of things,
but I had a question because I've been working a lot with the Symfony
framework lately. Some in the Symfony irc room seem to be under the
impression that short_open_tags
Your commit reminded me that we should probably look into providing
access to the low-level monotonic clock.
eg. CLOCK_MONOTONIC_RAW described here:
http://www.kernel.org/doc/man-pages/online/pages/man2/clock_getres.2.html
There is a monotonic clock library here that should help with
On 07/19/2012 12:25 AM, Pierre Joye wrote:
hi Rasmus,
On Wed, Jul 18, 2012 at 8:49 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:
$a = -5;
$b = -5;
echo $a-abs(); // Outputs 5
The goal of this message is to encourage and motivate a few people to
give me a hand with tracking down APC bugs. There are still a few
outstanding bugs that is slowing PHP 5.4 adoption and it would be really
nice to plow through these instead of wasting cycles on some of the
other discussions
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
- to have clean APIs,
On 07/18/2012 05:10 PM, David Muir wrote:
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
smalys...@sugarcrm.com wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness
On 07/17/2012 03:07 AM, Pierre Joye wrote:
hi,
On Tue, Jul 17, 2012 at 2:12 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
Let's ignore empty arguments like make[s] PHP feel modern. That aside, the
main argument advanced in this message makes no sense.
This idea has been proposed many
On 07/17/2012 08:06 AM, Andrew Faulds wrote:
Whilst weak typing has its benefits, I think typing is a little too weak
in places. IMO should not be equal to 0 or coercable to 0. But of
course 0 should equal 0.
Which has nothing to do with this thread.
On Jul 17, 2012 3:04 PM, Rasmus
On 07/15/2012 06:03 PM, Anthony Ferrara wrote:
Additionally, DateTime is a class in core. Do any functions throw
exceptions?
Nope, and note that if you call those same DateTime functions
procedurally they don't use exceptions. So yes, changing PHP to start
throwing exceptions from
On 07/14/2012 10:13 AM, Anthony Ferrara wrote:
Gustavo,
Why is the last key special? Why not a function to get the first or the
penultimate key?
How would such a function look?
I think the function would look just like the function we have for doing
this.
key(array_slice($arr,-2));
And
On 07/14/2012 10:29 AM, Rasmus Lerdorf wrote:
On 07/14/2012 10:13 AM, Anthony Ferrara wrote:
Gustavo,
Why is the last key special? Why not a function to get the first or the
penultimate key?
How would such a function look?
I think the function would look just like the function we have
On 07/14/2012 01:49 PM, Andrew Faulds wrote:
Hi there,
This is a patch that replaces PHP's infamous logo GUIDs with data URIs
instead, and also embed PHP credits in the phpinfo() page, hidden
using JavaScript (but gracefully degrading), to eliminate these GUIDs
altogether.
:)
On 07/12/2012 09:30 AM, Stas Malyshev wrote:
Hi!
Would it be worth while adding a new type hint that checks for this
condition? I'd propose Iterable:
I see more and more multiplication of weird ad-hoc type checks. First we
had callable, now traversable, then we invent more and more weird
On 07/12/2012 09:46 AM, Stas Malyshev wrote:
Hi!
For non-interchangeable types it is already strict by definition. I
don't see a problem with type hints that make life easier on both the
caller (by generating better error messages) and the callee (by having
to write less boilerplate type
On 07/12/2012 10:19 AM, Stas Malyshev wrote:
Hi!
This gives quite a bit more info since we now know that it was an
argument and specifically which argument it was, what its type was and
what it should have been vs. having a fatal from somewhere deep in the
function itself. So I disagree
I spent a bit of time looking at a mismatch between pdo_mysql and
MYSQL_OPT_RECONNECT. There is some rather odd code in
pdo_mysql/mysql_driver.c:
http://lxr.php.net/xref/PHP_5_4/ext/pdo_mysql/mysql_driver.c#640
There are two main problems here
1. This code is inside an if(driver_options)
On 07/04/2012 07:37 AM, Tom Boutell wrote:
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be significantly slower in production for those who
know what they're doing, yes?
Depends on your code. For people who write code that needs to include
hundreds, or
On 07/03/2012 07:13 AM, Tom Boutell wrote:
This one:
*** glibc detected *** /usr/local/bin/php-cgi: double free or
corruption (out): 0x7f9d6ce2c080 ***
=== Backtrace: =
/lib/libc.so.6(+0x77806)[0x7f9d679be806]
/lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3]
On 07/03/2012 08:17 AM, Pierre Joye wrote:
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.
Other developers may disagree but it makes very hard to maintain APC.
There are really just two big features in APC.
On 07/03/2012 09:49 AM, Arvids Godjuks wrote:
One one side it's good to know i'm not wrong, on the other hand it's sad
in this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone
On 06/29/2012 05:56 AM, Anthony Ferrara wrote:
Additionally, it appears that SHA256/512 are way overallocating the buffer.
For SHA512:
int needed = (sizeof(sha512_salt_prefix) - 1
+ sizeof(sha512_rounds_prefix) + 9 + 1
+ salt_in_len + 1 + 86
On 06/27/2012 08:45 PM, Yasuo Ohgaki wrote:
Hi,
I forgot to mention MySQL's query cache.
This change may have negative performance impact, since prepared
query is not cached and native prepared query may not be used by
other requests.
That's not really true anymore. There are some
On 06/24/2012 05:12 AM, Nikita Popov wrote:
The main problem with not throwing a warning is that it makes
debugging the error quite hard. json_last_error() only gives you an
error code. So you have to use some script like the one used as an
example in php.net/json_last_error to figure out what
On 06/23/2012 04:06 PM, Stas Malyshev wrote:
Hi!
Maybe it is simply time to rethink the error handling.
This is true, current error handling has many deficiencies and is also
very expensive even when the errors are muted (we still produce the
whole error string, etc. even if we never
On 06/21/2012 07:25 AM, Nikita Popov wrote:
On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Nikita:
PHP = 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
string is encountered:
* A warning is thrown, but only if
On 06/08/2012 11:38 PM, Robert Eisele wrote:
Hi,
I have a kind of stupid question. I run PHP inside a fpm chroot jail for a
lot of vhosts, each vhost with it's own pool. Unfortunatley, I can't
connect to remote domains neither via the native file api (assumed
allow_url_fopen is on) nor via
On 06/06/2012 04:42 AM, Laruence wrote:
On Wed, Jun 6, 2012 at 10:27 AM, Laruence larue...@php.net wrote:
On Wed, Jun 6, 2012 at 10:15 AM, Laruence larue...@php.net wrote:
Hi Nikita:
the most important part to me is how did you implemented `yield`
keyword, is there a whole patch file I
On 05/24/2012 08:23 AM, Tom Boutell wrote:
I've seen this statement before about the impact of caching the actual
compilation (or mere tokenization?) to bytecode being very small
compared to the impact of avoiding disk access. I am curious if there
are any measurements breaking this down.
On 05/06/2012 07:28 AM, Dmitri Dmitrison wrote:
So that just makes me wonder.
Is anyone even checking the bug system for requests anymore?
If the team feels strongly not to implement certain features, could you
just reply to those tickets and close them?
Would it be better to create RFCs
On 05/06/2012 08:23 AM, Dmitri Dmitrison wrote:
That is actually a promising statistic.
However, is there a predictable process for picking some requests over others?
If it's based on whether it resonated with the PHP dev who happened to
look at it, why even have a voting feature (and
On 05/01/2012 06:39 AM, Paul Reinheimer wrote:
Hi Larry,
Fascinating. I even verified the md5sum of the file I got on the other end
just to be sure. I'll hold off on the blog post then. :-) I look forward
to your test setup.
The server in question is still on PHP 5.2.13
Script:
On 05/01/2012 07:27 AM, Rasmus Lerdorf wrote:
On 05/01/2012 06:39 AM, Paul Reinheimer wrote:
Hi Larry,
Fascinating. I even verified the md5sum of the file I got on the other end
just to be sure. I'll hold off on the blog post then. :-) I look forward
to your test setup.
The server
Number of posts to internals since Jan.1,2012 (top 15):
[kris.cr...@gmail.com]= 249
[smalys...@sugarcrm.com] = 193
[pierre@gmail.com]= 146
[yohg...@ohgaki.net] = 105
[t...@punkave.com] = 98
[tyr...@gmail.com]= 96
[ircmax...@gmail.com]
On 04/17/2012 11:41 AM, Kris Craig wrote:
On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com
mailto:ras...@lerdorf.com wrote:
Number of posts to internals since Jan.1,2012 (top 15):
[kris.cr...@gmail.com mailto:kris.cr...@gmail.com]= 249
Wooot
On 04/13/2012 09:09 AM, Stas Malyshev wrote:
However I think it would make sense not to use this conversion in string
comparisons when we know it's lossy - it seems to be outside of the use
case for such comparisons and it seems apparent by now that it is hard
for people to understand why it
On 04/11/2012 02:10 PM, Yasuo Ohgaki wrote:
It's also very easy to write backward compatible code also.
The 3 lines of changes to adopt this RFC do not bother
old PHP.
No compatibility issue for existing code
Just 3 lines of change to adopt
Full backward compatibility for OLD systems
He's done.
On 04/07/2012 08:27 AM, Kiall Mac Innes wrote:
On Sat, Apr 7, 2012 at 4:22 PM, Derick Rethans der...@php.net wrote:
You repeatly call people stupid, or like a child or what terrible
happened in your life and that is *not* allowed behaviour here. If you
(or anyone else for that
On 04/07/2012 10:23 AM, Ángel González wrote:
And I like the idea of providing a function for auto escaping ?= echos.
Turn on your default input filter and all data that comes from the user
will automatically be escaped.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To
On 04/07/2012 01:07 PM, Ángel González wrote:
On 07/04/12 19:29, Rasmus Lerdorf wrote:
On 04/07/2012 10:23 AM, Ángel González wrote:
And I like the idea of providing a function for auto escaping ?= echos.
Turn on your default input filter and all data that comes from the user
On 04/05/2012 07:55 PM, Sébatien Durand wrote:
IMHO, PHP is a great template language. This is what makes it so simple
and powerful, compared to other web languages.
So far, we have ?php, ?= and various legacy syntaxes like ?.
A suggestion : deprecate these old tags and replace them with
On 04/04/2012 02:42 AM, Alan Knowles wrote:
Rather than this hap-hazard approach to ensuring code is correctly
handling error conditions would it not be far better for the engine to
be advising of situations where this may be occurring before they
occur.. in the same way undefined variables
On 04/03/2012 07:02 PM, Alan Knowles wrote:
I just saw Daniel changing some of the PEAR classes to use Exceptions,
and it's pretty clear that this could cause havoc with the end users.
The problem being that there is no 'soft' landing for the migration
process.
Users switching code from
On 04/02/2012 06:35 PM, Charlie Somerville wrote:
Hi internals,
I've created a pull request (https://github.com/php/php-src/pull/33) that
changes json_encode to fall back to ASCII for strings that are not valid
UTF-8.
I ran into an issue in a production application involving PayPal IPN
On 04/01/2012 12:47 AM, Helmut Tessarek wrote:
Hello,
The removal of sqlite in PHP 5.4 has not been thoroughly thought through.
In the documentation it says it has been moved to PECL.
Then you go to PECL and the only thing you find is the version from 2004,
which states that this package
On 03/30/2012 11:25 PM, Alexey Shein wrote:
Hmm, that's different. You get a notification if there's some change
on that bug (new comment/state changed/patch etc.). If bug didn't
change for years, you won't get any notifications - it's more likely
you forget about it.
That's not true. There
On 03/31/2012 01:21 AM, Alexey Shein wrote:
31 марта 2012 г. 12:50 пользователь Stas Malyshev
smalys...@sugarcrm.com написал:
Hi!
2) Keep devs' attention on known failures - XFAIL doesn't solve that.
You remember about them when you run tests and if you want make
attention at them.
Which
On 03/31/2012 01:52 AM, David Soria Parra wrote:
On 2012-03-31, David Soria Parra d...@php.net wrote:
Commit:3bf53aa911e1e2128a11aee45c126000635de006
Author:David Soria Parra d...@php.net Sat, 31 Mar 2012
09:34:25 +0200
Parents: aa774a51d5c45b98103e0f67914d4c0b152e80ae
On Mar 31, 2012, at 6:59 PM, Moriyoshi Koizumi m...@mozo.jp wrote:
Hi,
I wrote a RFC that proposes removal of PHP tags. There is actually
strong public demand for it, and I also think it is necessary to
leverage PHP to a genuine, modern scripting language.
On Mar 31, 2012, at 7:45 PM, Moriyoshi Koizumi m...@mozo.jp wrote:
Ok, I'll try to fix that part. Thanks for the correction.
No problem. Keeping the April 1st RFCs factually accurate is a top priority
around here.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To
On 03/14/2012 02:40 PM, Ryan McCue wrote:
Rasmus Lerdorf wrote:
The other way to solve this would be to make max_input_vars PHP_INI_ALL
and then just let people ini_set() their way around the limit.
That's probably going to confuse people if it doesn't change the HTTP
request parsing limit
On 03/14/2012 10:09 AM, Ferenc Kovacs wrote:
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.comwrote:
Maybe, and this is right of the top of my head, if PHP is installed
for a production environment with no INI file, or if an ini file
doesn't alter any of the core settings
It is somewhat unintuitive that parse_str() is subject to the
max_input_vars limitation and there are sites that use parse_str() to
parse things that aren't directly coming from user query args.
There arr two ways to solve this. We could add an optional max_vars arg
something along these lines:
On 03/14/2012 01:32 PM, Pierre Joye wrote:
hi Rasmus,
As the ini_all option sounds appealing, I can imagine ISPs willing to
do not allow their users to change this value, and that's something I
would not allow random users either.
I'd to go with the optional argument, adding a clear in
On 03/14/2012 02:46 PM, Anthony Ferrara wrote:
But Pierre, you understand that by the time you ini_set() it in the code
it can only ever affect parse_str() calls.
Well, wouldn't INI_ALL would allow .htaccess files to override that
statement, and hence open the vulnerability?
No because it
On 03/14/2012 03:11 PM, Stas Malyshev wrote:
Hi!
The other way to solve this would be to make max_input_vars PHP_INI_ALL
and then just let people ini_set() their way around the limit.
I think making it PHP_INI_ALL is OK. If you have access to a way to
change INI_ALL vars, that means you
On 03/14/2012 04:27 PM, Ilia Alshanetsky wrote:
Sounds like a least dangerous way of solving the problem to me. The
only issue I can see with this fix is what would happen is if after
the PG(max_input_vars) = max_vars;
call the request got interrupted in persistent environment such as
On 03/14/2012 07:34 PM, Tjerk Anne Meesters wrote:
On Thu, Mar 15, 2012 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
Yes, it would need a zend_alter_ini_entry_ex() call there. The patch
wasn't complete, just a quick hack. But it would still have an
out-of-context error message when
I caused this situation myself by not explicitly differentiating between
the default charset for the internal htmlspecialchars() and
htmlentities() functions and the output charset directive ini directive
default_charset.
The idea behind the default_charset ini directive was to act as the
charset
On 03/12/2012 12:10 AM, Stas Malyshev wrote:
Hi!
What we really need is what we added in PHP 6. A runtime encoding ini
setting that is distinct from the output charset which we can use here.
That would allow people to fix all their legacy code to a specific
runtime encoding with a single
On 03/12/2012 12:41 AM, Rasmus Lerdorf wrote:
$string = $string = prep$gb2312/p/pre;
Sorry typo there obviously. Just one $string
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 03/12/2012 12:52 AM, Stas Malyshev wrote:
Hi!
Ignoring 5.4 for a second, if you in 5.3 do this:
echo htmlspecialchars($string);
echo htmlspecialchars($string, NULL, ISO-8859-1);
echo htmlspecialchars($string, NULL, UTF-8);
You will see that the first two output the escaped string with
On 03/12/2012 03:05 AM, Yasuo Ohgaki wrote:
Hi
I think following PHP 5.4.0 NEWS entry is misleading.
. Changed default value of default_charset php.ini option from ISO-8859-1
to
UTF-8. (Rasmus)
Yes, I have fixed that now.
I thought default_charset became UTF-8, so I was
On 03/12/2012 12:40 PM, Stas Malyshev wrote:
Hi!
And yes, it may very well be dangerous to use the wrong charset and now
that we have better support for GB2312 and other asian charsets in the
entities functions in 5.4 it is even more prudent to choose the right
one so we should provide some
On 03/12/2012 12:51 PM, Stas Malyshev wrote:
Hi!
But you can't necessarily hardcode the encoding if you are writing
portable code. That's a bit like hardcoding a timezone. In order to
write portable code you need to give people the ability to localize it.
No, it's not like timezone at
On 03/12/2012 05:52 PM, Yasuo Ohgaki wrote:
I always set all parameters for htmlentities/htmlspecialchars, therefore
I haven't noticed this was changed from 5.3. They may be migrating from
5.2 or older. (RHEL5 uses 5.1)
No, like I showed, moving from 5.3 to 5.4 breaks because the new default
On 03/06/2012 06:03 AM, John Crenshaw wrote:
I've seen a simple safe code evaluator put together using token_get_all.
I'm certain that you could create an include_restricted() function in
userland using a similar system: walk through the tokens looking for anything
forbidden (this will be
On 02/28/2012 01:25 PM, Christian Ferrari wrote:
Dear all,
I'm asking your help because I'm not able to solve an issue probably related
to some foolish mistake I have not yet discovered.
I'm trying to develop an experimental extension to interface LIXA library
(http:/lixa.sourceforge.net/).
On 02/26/2012 08:03 AM, Stas Malyshev wrote:
Hi!
Just discovered that our stock php 4 support discontinued message in
bugs looks like:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste
On 02/26/2012 07:19 PM, Tom Boutell wrote:
Bump - this is still a live issue on Ubuntu 11.10, for instance.
I just hacked my Ubuntu PHP-from-source installer to touch up the
Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job.
Which I knew more about autoconf, I'd like to help
On 02/26/2012 07:43 PM, Tom Boutell wrote:
If what I did is basically already in 5.4 and won't be finding its
way back to 5.3, I guess I'm good with my hack for now.
Interesting, I never noticed it, but I tried your exact configure
switches and I was able to reproduce it. Here is what I use on
On 02/21/2012 06:54 AM, Bostjan Skufca wrote:
Hi all,
we've bumped into a possible bug where file_get_contents() returns empty
string if we try to get contents from HTTPS source. This error only occurs
if PHP is compiled with --with-curlwrappers.
Funny thing is this only happens on
On 02/21/2012 10:16 PM, John Crenshaw wrote:
-Original Message-
From: Deepak Balani [mailto:wgpdeepak1...@gmail.com]
Sent: Wednesday, February 22, 2012 1:07 AM
To: flav...@php.net
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP Script Compile System
No I mean persistent
On Feb 18, 2012, at 2:33 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Fri, 17 Feb 2012 22:59:20 +0100, Rasmus Lerdorf ras...@lerdorf.com wrote:
The main reason is that our default for max_file_uploads is rather low
and since we count empty uploads against this limit it is easy
IBM created a bit of a mess here. We can't grant new accounts on these
extensions without the approval of one of the existing members. They
have some sort of internal process they need to go through to be allowed
to commit to this code.
The existing members are:
On 02/17/2012 10:55 AM, Ambrish Bhargava1 wrote:
Hi Rasmus,
I am one of the developer for IBM_DB2, PDO_IBM and PDO_INFORMIX
extensions. Rahul is working with me on these extension. To contribute
to these extensions on the community he needs SVN access to his account.
Ok, done.
--
PHP
I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also
in the next 5.3 release. This setting is very similar in scope to
max_input_vars and other POST-related limiters like upload_max_filesize,
and post_max_size all of which are PHP_INI_SYSTEM|PHP_INI_PERDIR.
The main reason is
On 02/17/2012 02:41 PM, Stas Malyshev wrote:
Hi!
I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also
in the next 5.3 release. This setting is very similar in scope to
I think the change is good, I just want to understand - why before
5.4.0? I understand the change
On 02/15/2012 11:24 PM, J David wrote:
On Tue, Feb 14, 2012 at 8:35 AM, Ferenc Kovacs tyr...@gmail.com wrote:
as far as I can see the referenced fix (
http://svn.php.net/viewvc?view=revisionrevision=323016) never made to the
5.3.10 release (
On 02/14/2012 06:42 AM, Dmitry Stogov wrote:
I've opened the bug report #61083.
The bugs you mentioned are probably not related to zend_signals.
They were introduced only in 5.4.
Right, but zend_signals actually fixes these deadlocks, so they are
related that way.
-Rasmus
--
PHP Internals -
On 02/14/2012 08:48 AM, jpauli wrote:
On Tue, Feb 14, 2012 at 5:35 PM, Rasmus Lerdorf ras...@php.net
mailto:ras...@php.net wrote:
On 02/14/2012 06:42 AM, Dmitry Stogov wrote:
I've opened the bug report #61083.
The bugs you mentioned are probably not related to zend_signals
On 02/14/2012 09:22 AM, Adi Mutu wrote:
Thanks Julien
I don't know french, but i'll read it using google translate:)
If you just want to see some of the function calls, most calls that are
visible in userspace are prefixed with zif_ internally.
eg.
% gdb sapi/cli/php
GNU gdb
Heads up RMs. We need to apply the patch attached to this bug:
https://bugs.php.net/bug.php?id=60986edit=1
to 5.3/5.4/trunk. We switched to pcre_fullinfo() in most places already,
but there is that one spot left. It is essentially a one-liner and it
doesn't change any functionality since
Hey Dmitry, could you take a look at this one. I think this is mostly
your code and I am a bit lost in the path manipulation that is going on
here. This is bug https://bugs.php.net/51860 and it can be reproduced
from cli like this:
% cd /
% ln -s / phptest
% echo OK /phpfile
% echo '?php include
Ok, by popular demand I have changed Bogus to Not a bug in the bugs
tracker. The sub-status stuff we have been discussing can just be added
in the comment when you mark something as Not a bug. eg.
Status: Not a bug
Reason: 583 CNR
So, having done this, for the folks too skittish to mark stuff
On 01/27/2012 05:49 PM, Clint M Priest wrote:
I'm trying to upload the latest getters/setters patch to:
https://bugs.php.net/bug.php?id=49526
I get Uploaded file is empty or nothing was uploaded.
Is there a problem or a file size limit? The patch file is 205k now.
Really, a 200k patch?
On Jan 24, 2012, at 3:47 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Wed, Jan 25, 2012 at 12:11 AM, Justin Martin frozenf...@php.net wrote:
Hello,
With some frequency, I find bugs which are not bogus, so much as they
are reported based on a misunderstanding. Usually this happens for
On 01/19/2012 08:20 PM, Clint M Priest wrote:
Just updated and tried to compile, getting this:
make: *** No rule to make target
`/opt/php-core/trunk-accessor/ext/hash/hash_salsa.c', needed by
`ext/hash/hash_salsa.lo'. Stop.
I see that commit 322421 removed the hash_salsa.c but perhaps
On 01/13/2012 05:13 AM, Hannes Landeholm wrote:
I'm flooded with this warning when my system is under a high load and uses
a lot of sockets/file descriptors. I get it in stream_select:
E_WARNING: E_WARNING caught: stream_select(): You MUST recompile PHP with
a larger value of FD_SETSIZE.
It
On 01/13/2012 02:42 PM, Reindl Harald wrote:
Am 13.01.2012 17:36, schrieb Rasmus Lerdorf:
FD_SETSIZE is a system limit on the number of open files a
single process can have. From a bash shell type: ulimit -n and
you will probably see this magical 1024 number pop up. This
means
On 01/10/2012 11:33 AM, Philip Olson wrote:
Any objections? Regardless of deprecation status, this option
should be available. Or if not, why?
The main reason is that we are not done removing all the dependencies.
This is a large deprecation that is going to require the process to span
multiple
On 01/09/2012 08:50 AM, Xinchen Hui wrote:
Hi:
I am not sure whether you have understood my point.
If an array have more than 1024 buckets in an same bucket
list(same index), there must already be an performance issue.
The problem is you really need to consider the source. There are
401 - 500 of 1709 matches
Mail list logo
