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" in
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
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 t
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
Mar
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
S
Derick Rethans wrote:
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
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 directo
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 (htt
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: http://www.php.
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 say
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,
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
T
Andi Gutmans wrote:
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
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 man
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,
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,
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 want to contribute to the development of PHP.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
SF>>How is it going to be dependent in any way on a module that was loaded
SF>>after 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 th
SF>>Because we need to work through one resource at a time from the top,
SF>>and because dl'd modules are the last things with a resource id to be
SF>>loaded, because they have to be.
As you see belowe, this is not correct.
SF>>You got me there. OK, I didn't know that happens until just now. The
SF>>How is it going to be dependent in any way on a module that was loaded
SF>>after 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
SF>>Because we need to work through one resource at a time from the top,
SF>>and because dl'd modules are the last things with a resource id to be
SF>>loaded, because they have to be.
As you see belowe, this is not correct.
SF>>You got me there. OK, I didn't know that happens until just now. Th
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
SF>>crash might well appear random.) The best way to deal with an
extension
SF>>declaring 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
SF>>The number of the final TSRM resource id that was loaded will be the
SF>>size of the table they're stored in, plus one (to keep life simple).
SF>>So we pick up that figure and call it 'table_size'. Then we subtract
SF>>the number of modules registered in the dl_module_count.
I'm not sure wh
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 wrote
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 Alshanets
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 parame
SF>>crash might well appear random.) The best way to deal with an extension
SF>>declaring 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.
SF>>being
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 Reflect
SF>>The number of the final TSRM resource id that was loaded will be the
SF>>size of the table they're stored in, plus one (to keep life simple).
SF>>So we pick up that figure and call it 'table_size'. Then we subtract
SF>>the number of modules registered in the dl_module_count.
I'm not sure wh
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
ts_free_
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 w
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 th
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 dis
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:1
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
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] (
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
- Ori
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 ReflectionFunction::invoke
reading
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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:
Sent: Friday, June 09, 2006 11:42 AM
Subject: RE: [PHP-DEV] Re: [PATCH] Automatic module glob
Hi Stas,
SF>>Attached are patches for fixing the win32/ZTS thing only when needed -
SF>>this will _only_ work if you apply Dmitry's patch to 5_2 as well. The
SF>>idea 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_c
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
SF>>Attached are patches for fixing the win32/ZTS thing only when needed -
SF>>this will _only_ work if you apply Dmitry's patch to 5_2 as well. The
SF>>idea 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());
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
http:/
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
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 recen
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
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 glo
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
51 matches
Mail list logo
