Hi Dan,
Because the guide is in the manual. The manual is the difinitive source
on how to use PHP.
The guide was only added directly into the manual quite recently. This is
exactly what I'm trying to say; its purpose has shifted since it became part
of the manual and it's lost whatever
BUT perhaps some of the more complex explanations should have their own
document. If it 'requires more explanation than we want to provide in
the documentation' that does seem to suggest that a development perhaps
DOES need better doumentation?
In the manual, really. But - quite.
- Steph
Hey,
I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was
changed by the fix for bug #42868, right?
If so, this patch shouldn't be MFH'ed as the #42868 patch was not
merged although I didn't remember any discussion on this.
See also:
Hi Steph:
It's nothing to do with structure. Everything makes for a very long
file, full stop.
It doesn't matter that the XML file is long. Each section is broken up
into a separate page in the manual.
You want the upgrade guide to contain just the things that will cause
difficulties
It doesn't matter that the XML file is long. Each section is broken up
into a separate page in the manual.
I'm talking about the UPGRADE file in the source, which is plain text.
Have you ever tried to read it?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi all,
A while back I published a patch for PHP 5.2 and SNMP. Anyone had time
to review it
and if so, any comments? Could this patch be considered as a PHP 5.3 TODO item?
Anything I need to do to accept the patch?
Thanks.
--
Best Regards,
Leon
--
PHP Internals - PHP Runtime
Hi Steph:
I'm talking about the UPGRADE file in the source, which is plain text.
AH! Pardon the misunderstanding. Yeah, it seems that file should be
short and sweet then point folks to the manual.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
Lukas Kahwe Smith wrote:
The following remain open and it does not seem someone is actively
working in it:
- PHP_5_3 missed merge from PHP_5_2 for write_func callback
Seeing as I have an interest in this getting in 5_3, I'll work up a patch for
this unless someone wants to speak up that
See the results of the following on 5.2.6, 5.2.9rc2 and 5.3:
php -r '$a[1e100] = 1; var_dump($a);'
5.2.6:
array(1) {
[-2147483648]=
int(1)
}
5.2.9rc2:
array(1) {
[-1]=
int(1)
}
5.3:
array(1) {
[2147483647]=
int(1)
}
I doubt the result of 5.2.9rc2 is quite what we expect, and
Hi,
On Wed, 2009-02-11 at 18:07 +0100, Lukas Kahwe Smith wrote:
- pcntl_signal needs declare(ticks) which is deprecated since 5.3
I marked this as a documentation issue. This has been discussed when it
was decided to deprecate ticks. Although it would be great to keep
ticks, at least for use
On 12.02.2009, at 21:59, Arnaud Le Blanc wrote:
On Wed, 2009-02-11 at 18:07 +0100, Lukas Kahwe Smith wrote:
- pcntl_signal needs declare(ticks) which is deprecated since 5.3
I marked this as a documentation issue. This has been discussed when
it
was decided to deprecate ticks. Although
Hi!
it should actually be a hard error. As we always claim PHP follows pure
IS-A relation ships.
I feel very uneasy with hard errors on something that is not indeed an
error preventing engine from continuing. I.e. my (personal) opinion is
that if the engine can move forward, even with
12 matches
Mail list logo
