Stanislav Malyshev a écrit :
Hi!
I am wondering what the opcode EXT_FCALL_BEGIN and EXT_FCALL_END is
used for?
When php is in "extended opcode" mode (usually used by debuggers) these
opcodes are generated by the compiler before entering and after exiting
function calls (so that the debugger
Hi!
By extending the new internal class SessionHandler, users can wrap or
override methods of whatever session handler is in use, or implement a
complete custom handler.
Couple of notes:
1. I'd call mod_active something more clean - like session_active?
2. What happens if session module is se
Hi!
I think stream_resolve_include_path() should be changed to work through
zend_resolve_path, in any case. Also, what is the reason it can't be in
5.3 too?
I'd like to both fix stream_resolve_include_path() and get it into 5.3,
any objections to that?
If that was done, only problem with usi
Just out of curiosity, is there any open source bug tracker out there
that would lend itself well to these needs? Currently the bug tracker
is highly customized so when thinking about adding those new features,
it may also be a good time to look around ;-)
On 12/8/09, Lukas Kahwe Smith wrote:
>
>
On Tue, Dec 8, 2009 at 10:57 AM, Stanislav Malyshev wrote:
> How real would be the case of 2 hosts in the same pool having same configs,
> but the same hosts in different pool having different configs?
I never though about that but I can tell you I use all my websites
under the same pool. I part
Hi!
Unless there is a "Pool" identifier added:
Host can be different for the same pool
Path can be different for the same pool
.user.ini's don't work for *every* ini option.
How real would be the case of 2 hosts in the same pool having same
configs, but the same hosts in different pool havin
I'm +1 on the release branching, but i'm only a test committer so my
opinioin miht not weight that much here. I am however using this exact
model in my own team and it has proven to do very well when tied in to
Trac for tracking merges and all that.
How hard would this be to add to the bug tracke
> On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye wrote:
>> Why would you need that given that we have host, path or .user.ini
>> support? Which has to be backported to FPM as far as I know.
> you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
> things the user can't or shouldn't
you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
things the user can't or shouldn't change themselves in .user.ini type
files or with things like htscanner (pre 5.3)
On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye wrote:
> hi,
>
> On Mon, Dec 7, 2009 at 12:35 PM, Michael Shadle
hi,
On Mon, Dec 7, 2009 at 12:35 PM, Michael Shadle wrote:
> - Per-pool php.ini file (should be easy)
Why would you need that given that we have host, path or .user.ini
support? Which has to be backported to FPM as far as I know.
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.or
> pecl/parse_tree (if it (still) works) provides access to the parse
> tree of PHP code in the form of XML. The XML can be manipulated and
> then transformed back into PHP code.
PECL::Parse_Tree is still in alpha state and has not been updated since
January 2007, so I don't have too much confiden
11 matches
Mail list logo
