On Tue, Mar 23, 2010 at 11:18:09PM +, Michael Maclean wrote:
> >just to throw something out there, shouldn't the various inputLen
> >parameters be of type size_t instead of unsigned int?
>
> The function signature in php_hash.g says unsigned int, so that's
> what I used (though I note some of
Hi!
I'm sure you understand that nesting makes things much more easier to read.
fpm.workers..pm.dynamic.start_servers is
not my preferred syntax.
This is actually highly debatable. Nesting does not allow you an easy
way to know where each value belongs to - you'd have to climb up the
tree a
Hi!
I want PHP core to do it. Not only for FPM but for many other reasons. :)
MySQL does a !includedir thing...
Oh, well, that's another thing. Do an RFC then :)
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Inte
2010/3/23 Stanislav Malyshev :
> Actually, if you have extension parsing the .ini, nobody prevents you from
> having:
>
> include[]=another.ini
>
> and have your extension interpret it as it wishes (i.e parse another file).
> Only problem you have is if you want PHP to do it automatically for you.
Hi!
That's not true. You configure the fastcgi SAPI for lighttpd in the
lighttpd config, in LUA. Sure, it's the web-server side of it, but it's
no different from sapi/fpm which is its own little wrapper instead of
the one that comes with lighttpd.
Actually, it is different. lighty is not a par
Hi!
That was something I brought up to internals a while back, was adding
in the ability for includes in the php.ini file. I can see many usage
models for this, from distributions to web hosting managers.
Actually, if you have extension parsing the .ini, nobody prevents you
from having:
inc
PDO DBLIB fetch on demand patch revised and posted at:
http://bugs.php.net/bug.php?id=50755&edit=2
Comments are eagerly awaited. I'm excited about this one... I can feel
the warm patch acceptance. ;)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.n
On 03/23/2010 04:02 PM, Lukas Kahwe Smith wrote:
> In conclusion:
> There should of course be fun in just hacking out cool stuff, but I think for
> most developers a big part of the fun is actually seeing your ideas in a
> stable release.
Exactly. But that means we need to wait and see which de
Michael Maclean wrote:
The function signature in php_hash.g says unsigned int, so that's what I
used (though I note some of the other algorithms appear not to). We
don't support files > 2^32 on 64-bit, so as I understand it, it's not
going to cause issues right now, but if a large file support
sean finney wrote:
On Tue, Mar 23, 2010 at 10:01:20PM +, Michael Maclean wrote:
The patch:
http://mgdm.net/~michael/patches/php-fnv.txt
just to throw something out there, shouldn't the various inputLen
parameters be of type size_t instead of unsigned int?
The function signature in php_h
At 00:33 24/03/2010, Derick Rethans wrote:
On Wed, 24 Mar 2010, Zeev Suraski wrote:
> At 00:01 24/03/2010, Derick Rethans wrote:
> > I don't see how this actually matters. None of the other SAPIs are
> > configured with a php.ini syntax.
>
> None of the other SAPIs are configured, period.
That
On 23.03.2010, at 18:15, Rasmus Lerdorf wrote:
> My point is that your eventual list should come from things that have
> been committed to trunk and survived review and tests.
Sure, its only that many patches and todo items have been lingering (hello
frustration?) because of the trunk situatio
On Tue, Mar 23, 2010 at 11:33 PM, Derick Rethans wrote:
> That's not true. You configure the fastcgi SAPI for lighttpd in the
> lighttpd config, in LUA. Sure, it's the web-server side of it, but it's
> no different from sapi/fpm which is its own little wrapper instead of
> the one that comes with
On Tue, Mar 23, 2010 at 10:01:20PM +, Michael Maclean wrote:
> The patch:
> http://mgdm.net/~michael/patches/php-fnv.txt
just to throw something out there, shouldn't the various inputLen
parameters be of type size_t instead of unsigned int?
sean
signature.asc
Description: Digital
At 00:25 24/03/2010, Antony Dovgal wrote:
On 24.03.2010 01:08, Zeev Suraski wrote:
> At 23:58 23/03/2010, Antony Dovgal wrote:
>>Okay, here is XML based config quickly converted to php.ini-style syntax:
>
> Here's mine - a bit more representative of how .ini files look
> instead of trying to con
On Tue, Mar 23, 2010 at 10:16 PM, Zeev Suraski wrote:
> At 00:01 24/03/2010, Derick Rethans wrote:
>>
>> I don't see how this actually matters. None of the other SAPIs are
>> configured with a php.ini syntax.
>
> None of the other SAPIs are configured, period; The little configuration
> they do h
On Wed, 24 Mar 2010, Zeev Suraski wrote:
> At 00:01 24/03/2010, Derick Rethans wrote:
> > I don't see how this actually matters. None of the other SAPIs are
> > configured with a php.ini syntax.
>
> None of the other SAPIs are configured, period.
That's not true. You configure the fastcgi SAPI f
On 24.03.2010 01:08, Zeev Suraski wrote:
> At 23:58 23/03/2010, Antony Dovgal wrote:
>>Okay, here is XML based config quickly converted to php.ini-style syntax:
>
> Here's mine - a bit more representative of how .ini files look
> instead of trying to convert a nested XML file:
I'm sure you under
At 00:01 24/03/2010, Derick Rethans wrote:
I don't see how this actually matters. None of the other SAPIs are
configured with a php.ini syntax.
None of the other SAPIs are configured, period; The little
configuration they do have is done using php.ini.
This SAPI requires much more configurati
At 23:58 23/03/2010, Antony Dovgal wrote:
Okay, here is XML based config quickly converted to php.ini-style syntax:
Here's mine - a bit more representative of how .ini files look
instead of trying to convert a nested XML file:
[globals]
pid_file = /usr/local/var/run/php-fpm.pid
error_log = /
On Tue, 23 Mar 2010, Michael Maclean wrote:
> A while back I wrote a patch for ext/hash to add support for the 32- and
> 64-bit variants of the FNV-1 hash algorithm. Since we now have a new trunk, I
> thought I'd clean it up a bit, and thanks to some suggestions from Pierre and
> Johannes on IRC i
On Tue, Mar 23, 2010 at 8:55 PM, Antony Dovgal wrote:
> Now I was never an XML fan myself, but I think THIS particular XML config file
> is even easier to read and understand than php.ini.
Actually, I agree with Antony on this point. The existing XML config
file is pretty easy to read. I didn't i
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Tuesday, March 23, 2010 9:05 AM
> To: PHP Developers Mailing List
> Subject: [PHP-DEV] trunk is alive and open
>
> Hello,
>
> I've just created trunk for 5.3 again. I've set the version to
5.3.99-dev as to
> expli
On Tue, Mar 23, 2010 at 2:58 PM, Antony Dovgal wrote:
> Okay, here is XML based config quickly converted to php.ini-style syntax:
> ==
> [fpm.flobals]
> pid_file = /usr/local/var/run/php-fpm.pid
> error_log = /usr/local/var/l
On Tue, 23 Mar 2010, Zeev Suraski wrote:
> At 22:58 23/03/2010, Antony Dovgal wrote:
>
> > On 03/23/2010 11:54 PM, Zeev Suraski wrote:
> > > At 22:44 23/03/2010, Jérôme Loyet wrote:
> > >>In fact with INI syntax, there is a serious missing cause there is no
> > >>include system shiped with. And w
Hi,
A while back I wrote a patch for ext/hash to add support for the 32- and
64-bit variants of the FNV-1 hash algorithm. Since we now have a new
trunk, I thought I'd clean it up a bit, and thanks to some suggestions
from Pierre and Johannes on IRC it's a bit better now. Would anyone
object to
On 24.03.2010 00:05, Zeev Suraski wrote:
>>How do you propose to describe the same set of options using php.ini syntax?
>>Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine
>>into php.ini.
>>But how would decribe a set of pools each with its own set of options?
>>(taking into acco
Hi:
On 23 Mar 2010, at 18:15, Rasmus Lerdorf wrote:
>>> On 03/23/2010 09:36 AM, Lukas Kahwe Smith wrote:
Yeah, but I still think it would be a good idea to figure out lets say 3-5
big time features that we focus on for the next release and a rough
timeline for the next release.
>
At 22:55 23/03/2010, Antony Dovgal wrote:
On 03/23/2010 11:31 PM, Zeev Suraski wrote:
> It's not clear at all. In fact I think it was very clear that using
> php.ini syntax (together with sections if necessary) is very much an
> option, and I think mostly everyone here leaned towards it.
Just
At 22:58 23/03/2010, Antony Dovgal wrote:
On 03/23/2010 11:54 PM, Zeev Suraski wrote:
> At 22:44 23/03/2010, Jérôme Loyet wrote:
>>In fact with INI syntax, there is a serious missing cause there is no
>>include system shiped with. And with FPM as there is potentialy many
>>"vhosts", it's necessa
On Tue, Mar 23, 2010 at 1:55 PM, Antony Dovgal wrote:
> Now I was never an XML fan myself, but I think THIS particular XML config file
> is even easier to read and understand than php.ini.
There was one other suggestion / something Andrei wanted to do (at
least he mentioned to me) and that was c
On 03/23/2010 11:54 PM, Zeev Suraski wrote:
> At 22:44 23/03/2010, Jérôme Loyet wrote:
>>In fact with INI syntax, there is a serious missing cause there is no
>>include system shiped with. And with FPM as there is potentialy many
>>"vhosts", it's necessary to have an include system to feet all syst
On 03/23/2010 11:31 PM, Zeev Suraski wrote:
> It's not clear at all. In fact I think it was very clear that using
> php.ini syntax (together with sections if necessary) is very much an
> option, and I think mostly everyone here leaned towards it.
Just take a look at it:
http://svn.php.net/viewv
At 22:44 23/03/2010, Jérôme Loyet wrote:
In fact with INI syntax, there is a serious missing cause there is no
include system shiped with. And with FPM as there is potentialy many
"vhosts", it's necessary to have an include system to feet all system
administrator needs.
We were talking about th
2010/3/23 Jérôme Loyet :
> In fact with INI syntax, there is a serious missing cause there is no
> include system shiped with. And with FPM as there is potentialy many
> "vhosts", it's necessary to have an include system to feet all system
> administrator needs.
That was something I brought up to
2010/3/23 Zeev Suraski :
> At 21:43 23/03/2010, Antony Dovgal wrote:
>>
>> > - The config file change, moving from the XML-based php-fpm.conf to
>> > using php.ini (I think some work had started on this, but syntax was
>> > under debate?)
>>
>> We've discussed this many times and I thought it's pre
At 21:43 23/03/2010, Antony Dovgal wrote:
> - The config file change, moving from the XML-based php-fpm.conf to
> using php.ini (I think some work had started on this, but syntax was
> under debate?)
We've discussed this many times and I thought it's pretty clear that php.ini
syntax won't fit in
On Tue, Mar 23, 2010 at 4:09 PM, Michael Shadle wrote:
> On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal
> wrote:
>
> > I mentioned it, albeit briefly:
> > * basic SAPI status info (similar to Apache mod_status)
>
> Missed it (oops)
>
> > We've discussed this many times and I thought it's pretty
On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal wrote:
> I mentioned it, albeit briefly:
> * basic SAPI status info (similar to Apache mod_status)
Missed it (oops)
> We've discussed this many times and I thought it's pretty clear that php.ini
> syntax won't fit in this situation - the requireme
Antony Dovgal wrote:
On 03/23/2010 10:26 PM, Michael Shadle wrote:
- Jerome's put in some statistics functionality, which could be useful
in monitoring, etc. - might be nice to mention in the "features" [I
would include only the JSON output though]
I mentioned it, albeit briefly:
* basic SAP
On 03/23/2010 10:37 PM, Pierre Joye wrote:
> hi Tony,
>
> On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal wrote:
>
>>> Does it really need to be separate SAPI? I mean, just replace the old
>>> sapi/cgi
>>> with it? Keep the name 'cgi' though. :)
>>
>> I don't see any need to touch sapi/cgi at al
2010/3/23 Pierre Joye :
> hi Tony,
>
> On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal wrote:
>
>>> Does it really need to be separate SAPI? I mean, just replace the old
>>> sapi/cgi
>>> with it? Keep the name 'cgi' though. :)
>>
>> I don't see any need to touch sapi/cgi at all.
>> Keeping both CG
On 03/23/2010 10:26 PM, Michael Shadle wrote:
> - Jerome's put in some statistics functionality, which could be useful
> in monitoring, etc. - might be nice to mention in the "features" [I
> would include only the JSON output though]
I mentioned it, albeit briefly:
* basic SAPI status info (simila
hi Tony,
On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal wrote:
>> Does it really need to be separate SAPI? I mean, just replace the old
>> sapi/cgi
>> with it? Keep the name 'cgi' though. :)
>
> I don't see any need to touch sapi/cgi at all.
> Keeping both CGI and FastCGI in one SAPI leads to a
2010/3/23 Michael Shadle :
> On Tue, Mar 23, 2010 at 10:25 AM, Antony Dovgal wrote:
>
>> sapi/fpm and sapi/cgi now have quite different codebase as we've dropped
>> some stuff
>> not pertinent to FastCGI (there might be some leftovers, I'll deal with them
>> later).
>
> Not sure if it's best to
On Tue, Mar 23, 2010 at 10:25 AM, Antony Dovgal wrote:
> sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some
> stuff
> not pertinent to FastCGI (there might be some leftovers, I'll deal with them
> later).
Not sure if it's best to say it here or just post to the wiki
On Tue, 2010-03-23 at 16:04 +, Derick Rethans wrote:
> Hello,
>
> I've just created trunk for 5.3 again. I've set the version to
> 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or
> 6.0 next.
As I mentioned on IRC and in previous threads: I'd prefer to call it 5.4
- w
Hi,
On Tue, 2010-03-23 at 18:44 +0100, Kalle Sommer Nielsen wrote:
> Im assuming that we are still removing the stuff that we deprecated in
> 5.3 and removed in the old trunk? If thats the case then I will work
> on merging those removed features like safe_mode and so on out.
I think that's, like
>> New features should go to trunk; but anything other then trivial
>> additions should require an RFC and discussion. I think Antony has the
>> FPM RFC ready to show what sort of stuff would be useful to have. I'll
>> let Antony start a thread to discuss it (although I doubt there needs to
>> be a
On 23.03.2010, at 18:44, Kalle Sommer Nielsen wrote:
> Hi Derick
>
> 2010/3/23 Derick Rethans :
>> New features should go to trunk; but anything other then trivial
>> additions should require an RFC and discussion. I think Antony has the
>> FPM RFC ready to show what sort of stuff would be usefu
Hi Derick
2010/3/23 Derick Rethans :
> Hello,
>
> I've just created trunk for 5.3 again. I've set the version to
> 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or
> 6.0 next.
Great!
>
> New features should go to trunk; but anything other then trivial
> additions should req
On 03/23/2010 08:15 PM, Jani Taskinen wrote:
> 23.3.2010 18:42, Antony Dovgal wrote:
>> Hello all.
>>
>> Derick (and other people) asked me to create an RFC for FPM describing what
>> it is and why do we need it.
>> Quite.. ahem.. laconic version of such RFC can be found here:
>> http://wiki.php
On 03/23/2010 10:05 AM, Lukas Kahwe Smith wrote:
>
> On 23.03.2010, at 17:59, Rasmus Lerdorf wrote:
>
>> On 03/23/2010 09:36 AM, Lukas Kahwe Smith wrote:
>>>
>>> On 23.03.2010, at 17:21, Rasmus Lerdorf wrote:
>>>
On 03/23/2010 09:11 AM, Pierre Joye wrote:
> hi,
>
> I would rather
23.3.2010 18:42, Antony Dovgal wrote:
> Hello all.
>
> Derick (and other people) asked me to create an RFC for FPM describing what
> it is and why do we need it.
> Quite.. ahem.. laconic version of such RFC can be found here:
> http://wiki.php.net/rfc/fpm
>
> I'm open for your questions.
Does
On 23.03.2010, at 17:59, Rasmus Lerdorf wrote:
> On 03/23/2010 09:36 AM, Lukas Kahwe Smith wrote:
>>
>> On 23.03.2010, at 17:21, Rasmus Lerdorf wrote:
>>
>>> On 03/23/2010 09:11 AM, Pierre Joye wrote:
hi,
I would rather have some kind of rules defined before opening trunk
a
On 03/23/2010 09:36 AM, Lukas Kahwe Smith wrote:
>
> On 23.03.2010, at 17:21, Rasmus Lerdorf wrote:
>
>> On 03/23/2010 09:11 AM, Pierre Joye wrote:
>>> hi,
>>>
>>> I would rather have some kind of rules defined before opening trunk
>>> again (or the pandora box). That's what we are discussing rig
yes
On Tue, Mar 23, 2010 at 5:47 PM, Richard Quadling
wrote:
> On 23 March 2010 16:38, Derick Rethans wrote:
>> On Tue, 23 Mar 2010, Derick Rethans wrote:
>>
>>> I've just created trunk for 5.3 again. I've set the version to
>>> 5.3.99-dev as to explicitly not decide on whether there will be 5.4
On 23 March 2010 16:38, Derick Rethans wrote:
> On Tue, 23 Mar 2010, Derick Rethans wrote:
>
>> I've just created trunk for 5.3 again. I've set the version to
>> 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or
>> 6.0 next.
>
> I've also enabled snapshots for trunk, they are
Hello all.
Derick (and other people) asked me to create an RFC for FPM describing what it
is and why do we need it.
Quite.. ahem.. laconic version of such RFC can be found here:
http://wiki.php.net/rfc/fpm
I'm open for your questions.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime stat
On Tue, 23 Mar 2010, Derick Rethans wrote:
> I've just created trunk for 5.3 again. I've set the version to
> 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or
> 6.0 next.
I've also enabled snapshots for trunk, they are called
php-trunk-.*. See them at http://snaps.php.ne
On 03/23/2010 09:32 AM, Pierre Joye wrote:
> On Tue, Mar 23, 2010 at 5:21 PM, Rasmus Lerdorf wrote:
>> On 03/23/2010 09:11 AM, Pierre Joye wrote:
>>> hi,
>>>
>>> I would rather have some kind of rules defined before opening trunk
>>> again (or the pandora box). That's what we are discussing right
On 23.03.2010, at 17:21, Rasmus Lerdorf wrote:
> On 03/23/2010 09:11 AM, Pierre Joye wrote:
>> hi,
>>
>> I would rather have some kind of rules defined before opening trunk
>> again (or the pandora box). That's what we are discussing right now.
>> May I know why you choosed that now is the right
On Tue, Mar 23, 2010 at 5:21 PM, Rasmus Lerdorf wrote:
> On 03/23/2010 09:11 AM, Pierre Joye wrote:
>> hi,
>>
>> I would rather have some kind of rules defined before opening trunk
>> again (or the pandora box). That's what we are discussing right now.
>> May I know why you choosed that now is the
On 03/23/2010 09:11 AM, Pierre Joye wrote:
> hi,
>
> I would rather have some kind of rules defined before opening trunk
> again (or the pandora box). That's what we are discussing right now.
> May I know why you choosed that now is the right time to do it and
> declare it open?
We have rules. L
hi,
I would rather have some kind of rules defined before opening trunk
again (or the pandora box). That's what we are discussing right now.
May I know why you choosed that now is the right time to do it and
declare it open?
Cheers,
On Tue, Mar 23, 2010 at 5:04 PM, Derick Rethans wrote:
> Hello
Hello,
I've just created trunk for 5.3 again. I've set the version to
5.3.99-dev as to explicitly not decide on whether there will be 5.4 or
6.0 next.
New features should go to trunk; but anything other then trivial
additions should require an RFC and discussion. I think Antony has the
FPM R
sorry, my bad.
Tyrael
On Tue, Mar 23, 2010 at 2:18 PM, Derick Rethans wrote:
> On Tue, 23 Mar 2010, Ferenc Kovacs wrote:
>
> > It seems that the
> > "Implement David's Circular Garbage collection patch" was not merged into
> > 5.3, I think it should be a good feature for 5.4
>
> Uh, yes it was.
On Tue, 23 Mar 2010, Ferenc Kovacs wrote:
> It seems that the
> "Implement David's Circular Garbage collection patch" was not merged into
> 5.3, I think it should be a good feature for 5.4
Uh, yes it was. It's most definitely in 5.3.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like X
On Sat, Mar 20, 2010 at 4:58 AM, Pas wrote:
> On 2010.03.19. 19:50, la...@garfieldtech.com wrote:
>
>> On 3/19/10 1:31 PM, Nate Abele wrote:
>>
>>> The point is that, for instance, PHP 5.3 was not a trivial upgrade
for coders or hosters. Sure it's mostly compatible, and you certainly
ca
Hi Stan.
On Tue, Mar 23, 2010 at 8:47 AM, Stan Vassilev wrote:
> Thanks for your patch, but you're going to affect a whole group of users who
> do advanced logging and recovery in the shutdown phase. This is why these
> things have to be considered when they're first added.
How would they be aff
With the help of Scotts last suggestion, I made some changes. It seems
to work, but then I don't really know how to test it properly. I can
verify that A) it allows userland code the grace period of 1 second
for shutting down and B) shuts down regardless of the userland error
handler returning or
71 matches
Mail list logo
