On Thu, 8 Jun 2006, Andi Gutmans wrote:
Any chance we can get the SPL docs integrated into the PHP manual? I
get questions about it here and there and think that as it's in the
default PHP distro it makes sense to have that as part of the official
PHP manual.
There is no way we can do
Derick Rethans mailto:[EMAIL PROTECTED] wrote on Friday, June 09, 2006
8:25 AM:
On Thu, 8 Jun 2006, Andi Gutmans wrote:
Any chance we can get the SPL docs integrated into the PHP manual? I
get questions about it here and there and think that as it's in the
default PHP distro it makes sense
Hello Andi,
the problem is the non existing OO support in docbook. I had the idea
of eventually using doxygen's xml output and putting that somehow in the
manual. But that's is probably something for livedocs. So lets have
livedocs first. Apart from that nobody hinders the doc team from copying
Steph,
You patch is still need:
MSHUTDOWM(mod_name)
{
#ifndef ZTS
module_globals_dtor();
#endif
This is logical inconsistency.
My patch manages globals for both ZTS and non-ZTS builds and doesn't require
any tricks from extension writers.
The should just declare callbacks for module
Hi,
I will rework patch with new names (GINIT/GSHUTDOWN as Sara suggested) and
commit it into HEAD today or at Thursday.
According to PHP_5_2 we probably will need voting.
Thanks. Dmitry.
-Original Message-
From: Pierre [mailto:[EMAIL PROTECTED]
Sent: Friday, June 09, 2006 4:09 AM
Dmitry, hi,
Sure - the difference is that that call's ALWAYS been needed in MSHUTDOWN
for non-ZTS dtor calls, whereas the thing of needing a ZTS call in MSHUTDOWN
is brand-new. The one's a 'feature', the other I think it's reasonable to
call a bug given that it's always worked until very
Hey Dmitry we both need to learn to read to the end before we reply :)
Attached are patches for fixing the win32/ZTS thing only when
needed - this
will _only_ work if you apply Dmitry's patch to 5_2 as well.
The idea being that this way everybody's covered.
- Steph
- Original Message
On Fri, 9 Jun 2006, Dmitry Stogov wrote:
I will rework patch with new names (GINIT/GSHUTDOWN as Sara suggested) and
commit it into HEAD today or at Thursday.
According to PHP_5_2 we probably will need voting.
I'm -1 on integrating it into 5.2 then.
regards,
Derick
--
Derick Rethans
SFAttached are patches for fixing the win32/ZTS thing only when needed -
SFthis will _only_ work if you apply Dmitry's patch to 5_2 as well. The
SFidea being that this way everybody's covered.
I'm not sure I understand what this line does:
ts_free_id(table_size - zend_dl_module_count());
Can
I also think that Steph's patch is to magic. :)
Dmitry.
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Friday, June 09, 2006 12:28 PM
To: Steph Fox
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [PATCH] Automatic module globals management
Hi Stas,
SFAttached are patches for fixing the win32/ZTS thing only when needed -
SFthis will _only_ work if you apply Dmitry's patch to 5_2 as well. The
SFidea being that this way everybody's covered.
I'm not sure I understand what this line does:
ts_free_id(table_size -
What's 'magic' about going 1, 2, 3, 4?
- Original Message -
From: Dmitry Stogov [EMAIL PROTECTED]
To: 'Stanislav Malyshev' [EMAIL PROTECTED]; 'Steph Fox' [EMAIL
PROTECTED]
Cc: internals@lists.php.net
Sent: Friday, June 09, 2006 11:42 AM
Subject: RE: [PHP-DEV] Re: [PATCH] Automatic
reading
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Sebastian
On 6/8/06, Sebastian Bergmann [EMAIL PROTECTED] wrote:
http://phpfi.com/122573
Looks like the arginfo patch broke it.., well, actually it uncovered a
bug in ext/reflection.
The messages are correct, ReflectionMethod::invokeArgs takes two
arguments but
Yep, it not clear how to document such OO beast in docbook. Also we have few
active persons working in the documentation, that aren't enough to catch up
all the new features, BC breaks, etc.. We probably would need someone to
exclusively work on SPL, which we can't afford ATM.
Nuno
-
Forwarding here.
Maybe it got lost inbetween the spam attacks, maybe its just not
interesting but lets open up the topic to a larger audience :)
Original Message
Subject: fetch() returning false for empty datasets
Date: Mon, 05 Jun 2006 11:41:12 +0200
From: [EMAIL PROTECTED]
On 6/9/06, Lukas Smith [EMAIL PROTECTED] wrote:
Forwarding here.
Maybe it got lost inbetween the spam attacks, maybe its just not
interesting but lets open up the topic to a larger audience :)
Original Message
Subject: fetch() returning false for empty datasets
Date: Mon, 05
Who said that 1,2,3,... should work?
What will your patch do if some extension will register several tsrm ids?
What will it do if some extension will not register globals?
Thanks. Dmitry.
-Original Message-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, June 09, 2006 2:17
Maybe we can get a volunteer to improve the docbook?
At 11:25 PM 6/8/2006, Derick Rethans wrote:
On Thu, 8 Jun 2006, Andi Gutmans wrote:
Any chance we can get the SPL docs integrated into the PHP manual? I
get questions about it here and there and think that as it's in the
default PHP
This is a docbook limitation? Couldn't we still find some standard
way to write it? most of it is manual stuff ala
http://framework.zend.com/manual/en/zend.html?
No?
Andi
At 12:24 AM 6/9/2006, Marcus Boerger wrote:
Hello Andi,
the problem is the non existing OO support in docbook. I had
On 6/9/06, Andi Gutmans [EMAIL PROTECTED] wrote:
Maybe we can get a volunteer to improve the docbook?
We have, http://code.google.com/soc/php/appinfo.html?csaid=1D6D429391DFBA6F
-Hannes
At 11:25 PM 6/8/2006, Derick Rethans wrote:
On Thu, 8 Jun 2006, Andi Gutmans wrote:
Any chance we can
Hi :)
Who said that 1,2,3,... should work?
Erm, it does...
What will your patch do if some extension will register several tsrm ids?
If an extension has several tsrm ids and it's loaded as a shared module, it
will probably crash on shutdown unless the author adds the appropriate
SFThe number of the final TSRM resource id that was loaded will be the
SFsize of the table they're stored in, plus one (to keep life simple).
SFSo we pick up that figure and call it 'table_size'. Then we subtract
SFthe number of modules registered in the dl_module_count.
I'm not sure why is
Hi Marcus,
Could you please fix PHP6 build.
You broke it day or two ago :(
After your modifications of ext/reflection PHP always emits error messages
about method incompatibilities.
I am not sure if static methods must be checked for compatibility (I mean
ReflectionMethod::export()), but
SFcrash might well appear random.) The best way to deal with an extension
SFdeclaring more than one thread resource would be to build it as static. But
That's a good advice but not practical at all. :) Static extensions can
not be distributed as a product or a package, for example.
SFbeing in
On 6/9/06, Dmitry Stogov [EMAIL PROTECTED] wrote:
Hi Marcus,
Could you please fix PHP6 build.
You broke it day or two ago :(
Yeah, sorry about that, was my fault (it broke 5_2 to).
Actually, this bug has been there for a while, but the engine didn't
catch it since it had no idea which
You're right, Steph's comments threw me off a bit there, but after
reconsidering the patch in detail I think it should be fine for 5.2,
so go ahead and commit it.
On 8-Jun-06, at 7:44 PM, Andi Gutmans wrote:
Why so? It doesn't affect any compatibility.
At 02:31 PM 6/8/2006, Ilia
PHP-GTK has been using modified docbook for its stuff...
http://gtk.php.net/manual/en/classtree.php
-Andrei
On Jun 9, 2006, at 6:55 AM, Andi Gutmans wrote:
Maybe we can get a volunteer to improve the docbook?
At 11:25 PM 6/8/2006, Derick Rethans wrote:
On Thu, 8 Jun 2006, Andi Gutmans
SFThe number of the final TSRM resource id that was loaded will be the
SFsize of the table they're stored in, plus one (to keep life simple).
SFSo we pick up that figure and call it 'table_size'. Then we subtract
SFthe number of modules registered in the dl_module_count.
I'm not sure why is
SFcrash might well appear random.) The best way to deal with an
extension
SFdeclaring more than one thread resource would be to build it as
static. But
That's a good advice but not practical at all. :) Static extensions can
not be distributed as a product or a package, for example.
And as I
My comments went something along the lines of 'well if it's going in can we
please apply a fix for the problem this was supposed to fix in the first
place, because it isn't an answer to that problem'. I'd still personally
rather it didn't, but I'm happy so long as we get an actual fix in there
SFBecause we need to work through one resource at a time from the top,
SFand because dl'd modules are the last things with a resource id to be
SFloaded, because they have to be.
As you see belowe, this is not correct.
SFYou got me there. OK, I didn't know that happens until just now. The rest
SFHow is it going to be dependent in any way on a module that was loaded
SFafter it was?!
As far as understand the code, table_size - zend_dl_module_count() formula
starts with last allocated ID and deallocates one ID per module unloaded,
starting from the latest loaded module. However, if
SFBecause we need to work through one resource at a time from the top,
SFand because dl'd modules are the last things with a resource id to be
SFloaded, because they have to be.
As you see belowe, this is not correct.
SFYou got me there. OK, I didn't know that happens until just now. The
rest
SFHow is it going to be dependent in any way on a module that was loaded
SFafter it was?!
As far as understand the code, table_size - zend_dl_module_count() formula
starts with last allocated ID and deallocates one ID per module unloaded,
starting from the latest loaded module. However, if there
I want to contribute to the development of PHP.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The problem is always maintenance.. I've have some knowledge about DSSSL but
none about XSL. In phpdoc we use both, that need to be kept in sync, so
that's always complicated to make changes.
The best option would be to create a work-group to study with docbook
creators the best approaches to
I think that doesn't look too bad. It might not be the Doxygen
output, etc.. but for the PHP manual I think it's quite adequate.
At 09:43 AM 6/9/2006, Andrei Zmievski wrote:
PHP-GTK has been using modified docbook for its stuff...
http://gtk.php.net/manual/en/classtree.php
-Andrei
On Jun 9,
Hi Nuno,
Christian Weiske and myself have both done quite a lot with docbook - mostly
extending the PHP-GTK dtd and forcing the (fairly elderly but much-altered)
stylesheets to do all sorts of horrible things they weren't designed to do
:). The same goes for James Moore if he's around at all,
Hey,
I'm obviously not an expert on this stuff so I don't have much added
value to add. However, I think from a high-level I think it's
important that we have one PHP manual and that the manual covers both
functional and oo extensions. I think the last thing we want is to
have several PHP
Is /etc/php.d a standard part of *every* php4 installation? Can I rely
on it's existance? Is it's location a configuable option?
Thanks,
Mike
--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
--
PHP Internals - PHP Runtime Development Mailing List
Yeah API docs is useful, but still we should have the end-user docs
in the PHP manual. I don't think once comes instead of the other. The
end-user docs is especially useful as people in the community can
give comments, etc...
At 02:52 PM 6/9/2006, Lukas Smith wrote:
Andi Gutmans wrote:
Hey,
Andi Gutmans wrote:
Yeah API docs is useful, but still we should have the end-user docs in
the PHP manual. I don't think once comes instead of the other. The
end-user docs is especially useful as people in the community can give
comments, etc...
Err, you misunderstood what I was trying to
Michael B Allen wrote:
Is /etc/php.d a standard part of *every* php4 installation? Can I rely
on it's existance? Is it's location a configuable option?
No, you can't rely on it.
What's in there?
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Fri, 9 Jun 2006 18:15:31 -0400
[EMAIL PROTECTED] (Michael B Allen) wrote:
Is /etc/php.d a standard part of *every* php4 installation? Can I rely
on it's existance? Is it's location a configuable option?
It is a distribution specific directory. Some uses it other not.
The PHP releases
On Sat, 10 Jun 2006, Pierre wrote:
On Fri, 9 Jun 2006 18:15:31 -0400
[EMAIL PROTECTED] (Michael B Allen) wrote:
Is /etc/php.d a standard part of *every* php4 installation? Can I rely
on it's existance? Is it's location a configuable option?
It is a distribution specific directory. Some
Hello Andi,
that's nothing more than our manual besides a different layout. I'd
like to document how studd is being integrated, how stuff works together
and how inheritance trees look like. You saw the gtk tree, wow, cool if
there is only one real tree like inheritance graph. But unfortunatley
I find the Doxygen-generated SPL docs maze-like and pretty much
impossible to navigate. There is nothing stopping you from maintaining
that separate document, but I'd love to see the useful bits integrated
into the PHP docs. Losing the inheritance graphs doesn't bother me a bit.
-Rasmus
Hello,
On 6/10/06, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Something I'd like to see more distros make use of. I am not sure how
to get the ball rolling on that though, but it makes packaging up
extensions so much easier when all you need is to drop a foo.ini file in
a directory instead of
Hello Hannes,
the patch looks good and solves the issues as far as i can tell. We
might want to make the abstract part an interface but we'll see. Just
commit for now.
best regards
marcus
Friday, June 9, 2006, 5:06:02 PM, you wrote:
On 6/9/06, Dmitry Stogov [EMAIL PROTECTED] wrote:
Hi
I agree with Rasmus here, there should be at least some level of the docs in
the PHP manual. Its always been considered the one stop shop for reference
for all the beginning coders that I've seen, and is one of the draws for the
language.
Having a seperate set of docs for the more advanced
51 matches
Mail list logo
