On Tue, Dec 15, 2009 at 9:59 PM, Joey Smith 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 bring it ba
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 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
>
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
2009/12/15 Ionut G. Stan :
> 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 shor
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 wor
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
On Tue, Dec 15, 2009 at 4:25 AM, Antony Dovgal 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 parameter seems a bit
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: http://www.php.
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 wa
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
On Tue, Dec 15, 2009 at 20:46, Christian Seiler 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 objects!
+1
Pre
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 th
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 f
Le 15 décembre 2009 17:08, Jérôme Loyet 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 just teste
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
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 exac
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
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
2009/12/15 Tjerk Anne Meesters :
> 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 log message (my
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 wrote:
> On 15.12.2009 12:30, Jan
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 stati
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 ma
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 configu
Contributing to a proof-of-concept branch for the PHP website.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
26 matches
Mail list logo
