On 12/14/2009 10:16 PM, Jérôme Loyet wrote:
Hi tony,
There is several things in this patch:
1- makes log message about pool concistent. I set it to [pool %s]
message. Before there where different variants:
pool %s,
foo (pool %s) bar
[pool %s]
[%s]
2- corrects some log messages which were not
On 15.12.2009 12:04, Jani Taskinen wrote:
3- Some log level have been switched from NOTICE to DEBUG, so that the
log_file in normal operation would not be a nightmare to read (with a
lot of anoying and useless messages for end users)
Wouldn't it make more sense to make this configurable?
On 12/15/2009 11:14 AM, Antony Dovgal wrote:
On 15.12.2009 12:04, Jani Taskinen wrote:
3- Some log level have been switched from NOTICE to DEBUG, so that the
log_file in normal operation would not be a nightmare to read (with a
lot of anoying and useless messages for end users)
Wouldn't it
On 15.12.2009 12:30, Jani Taskinen wrote:
Surely log_level is configurable.
Jerome just changed error level of some error messages to reduce the amount
of notices in the log.
I replied badly, I meant ALL the points in the mail. Configurable log
entries, levels, etc. Not some static
The only two things that would come up after reading Jani's email is:
1) Make the log string configurable, such as CustomLog in apache
2) Configure the log level threshold, though I think that should
already be there in the first place.
On 12/15/09, Antony Dovgal t...@daylessday.org wrote:
On
2009/12/15 Tjerk Anne Meesters datib...@php.net:
The only two things that would come up after reading Jani's email is:
so am I
1) Make the log string configurable, such as CustomLog in apache
Yes but CustomLog is for access log, this feature is not present in
php-fpm (should it be ?)
All the
On 15.12.2009 15:19, Tjerk Anne Meesters wrote:
The only two things that would come up after reading Jani's email is:
1) Make the log string configurable, such as CustomLog in apache
CustomLog is needed in Apache because there are so much variables available.
Here we have time, pid, function
Hi
I just figured out a bug with epoll on the last php-fpm version from svn.
It seems that with epoll only (no problem with poll or select -- don't
have a freebsd ready to check kqueue), the catch_worker_output is
buggy.
With catch_workers_output set to no, all output to stdout or stderr
from
Hello again,
Discuss away!
I'm a little disappointed by the non-outcome of this debate. Very few
people have responded and most of them seem to agree proposal (A) should
be implemented, perhaps with the additional bind/bindTo as in my
proposal and perhaps not.
The problem here is: (A) was
On 15.12.2009, at 20:01, Christian Seiler wrote:
Hello again,
Discuss away!
I'm a little disappointed by the non-outcome of this debate. Very few
people have responded and most of them seem to agree proposal (A) should
be implemented, perhaps with the additional bind/bindTo as in my
Le 15 décembre 2009 17:08, Jérôme Loyet jer...@loyet.net a écrit :
Hi
I just figured out a bug with epoll on the last php-fpm version from svn.
It seems that with epoll only (no problem with poll or select -- don't
have a freebsd ready to check kqueue), the catch_worker_output is
buggy.
I
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there is
more time for this to mature if needed inside svn.
Ok, so then I call for
I found a solution:
Just after the fork() call to create a child, the first thing to do is
to call event_init() to create a fresh libevent environment for the
new child. In fact epoll shares the same fd between process and having
not libevent reinit make things not working as excepted. It's not
On Tue, Dec 15, 2009 at 20:46, Christian Seiler chris...@gmx.net wrote:
(A): Original closures implementation:
$this is always the object context at
closure creation. No possibility to do
$someObject-closureProperty(...) and thus
no possibility to extend
Hi!
Ok, so then I call for a vote. Again, here are the options:
A+, no direct method calling (get/call problem would be messy)
one additional thing:
$a = static function () {}
should leave $this not bound (in case for some reason you don't want it
to be bound, e.g. to avoid keeping reference
Hi,
Ok, so then I call for a vote. Again, here are the options:
A+, no direct method calling (get/call problem would be messy)
I don't quite follow: Why A+ if no direct method calling? What would be
the point of allowing bindTo() if $obj-closureProp() doesn't work
anyway? If you don't want
On 15.12.2009, at 22:46, Christian Seiler wrote:
Ok, so then I call for a vote. Again, here are the options:
(0): No $this in closures, keep it that way. (keep PHP 5.3 behavior)
I vote for (0)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, Dec 15, 2009 at 4:25 AM, Antony Dovgal t...@daylessday.org wrote:
Here we have time, pid, function and line.
With log_level=debug all of them are printed, in other cases only time gets
into the log,
which makes perfect sense to me.
+1 to Antony and Jérôme.
Having a log format
A+, but I'm not an internal dev.
On 12/15/2009 21:46, Christian Seiler wrote:
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there
Hi,
Maybe I don't exactly understand the need for closureProperty(); also,
I haven't read the rfc ;-)
My understanding would be that you can treat it as a callable object, like so:
$a = function($msg) { echo $this-id, : , $msg, [ calls: ,
++$this-calls, ];
}
$a-id = 123;
$a(hello world);
If
2009/12/15 Ionut G. Stan ionut.g.s...@gmail.com:
A+, but I'm not an internal dev.
On 12/15/2009 21:46, Christian Seiler wrote:
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the
Christian Seiler wrote
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there
is
more time for this to mature if needed
On Tuesday 15 December 2009 1:46:44 pm Christian Seiler wrote:
Hi Lukas,
Call for a vote. This time around people cannot claim to not have had
time to review the issue. Also back then we tried to play it safe
because of the short time before we were to release. This time there is
more
On Tue, Dec 15, 2009 at 02:27:30PM -0800, Michael Shadle wrote:
However if people have ideas on how this will help or be useful (i.e.
you -are- planning on running logfiles or logwatch or something) then
it might be smart to bring it back to the table again. Jérôme and I
were talking about
On Tue, Dec 15, 2009 at 9:59 PM, Joey Smith j...@joeysmith.com wrote:
On Tue, Dec 15, 2009 at 02:27:30PM -0800, Michael Shadle wrote:
However if people have ideas on how this will help or be useful (i.e.
you -are- planning on running logfiles or logwatch or something) then
it might be smart to
25 matches
Mail list logo
