Re: [PHP-DOC] Re: Error when compiling PHP manual.
On Wed, May 26, 2010 at 15:32, Richard Quadling rquadl...@googlemail.com wrote: On 25 May 2010 19:37, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, May 25, 2010 at 13:08, Richard Quadling rquadl...@googlemail.com wrote: On 24 May 2010 16:00, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Mon, May 24, 2010 at 03:25, Philip Olson phi...@roshambo.org wrote: At this stage, I'm wondering why we don't simply collect all the errors ... ?php libxml_use_internal_errors(true); ? I thought we did? Unless --enable-xml-details was set Then how are the warnings being displayed on the online editor from the xinclude() call? And then the penny drops. The editor is using --disable-segfault-error to NOT capture the errors. http://svn.php.net/viewvc/web/doc-editor/trunk/php/conf/project.php.ini?view=markup#l25 So, if we are not interested in xinclude errors, captured by libxml_use_internal_errors(true) or otherwise, then a simple @$dom-xinclude(); libxml_clear_errors(); @ is never the solution. Fix print_xml_errors() to discard the error and call it after -xinclude(). And remove --disable-segfault-error frrom the OE --disable-segfault-error should *NOT* be enabled by default. It is the last resort to workaround a bug in libxml2 and should only be used when stuff breaks that badly. -Hannes
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 27 May 2010 11:51, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Wed, May 26, 2010 at 15:32, Richard Quadling rquadl...@googlemail.com wrote: On 25 May 2010 19:37, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, May 25, 2010 at 13:08, Richard Quadling rquadl...@googlemail.com wrote: On 24 May 2010 16:00, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Mon, May 24, 2010 at 03:25, Philip Olson phi...@roshambo.org wrote: At this stage, I'm wondering why we don't simply collect all the errors ... ?php libxml_use_internal_errors(true); ? I thought we did? Unless --enable-xml-details was set Then how are the warnings being displayed on the online editor from the xinclude() call? And then the penny drops. The editor is using --disable-segfault-error to NOT capture the errors. http://svn.php.net/viewvc/web/doc-editor/trunk/php/conf/project.php.ini?view=markup#l25 So, if we are not interested in xinclude errors, captured by libxml_use_internal_errors(true) or otherwise, then a simple @$dom-xinclude(); libxml_clear_errors(); @ is never the solution. Fix print_xml_errors() to discard the error and call it after -xinclude(). And remove --disable-segfault-error frrom the OE --disable-segfault-error should *NOT* be enabled by default. It is the last resort to workaround a bug in libxml2 and should only be used when stuff breaks that badly. -Hannes Fair enough. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
Hi Richard: On Tue, May 25, 2010 at 12:08:17PM +0100, Richard Quadling wrote: In the event that the xpointer evaluation doesn't return anything, the XPointer evaluation failed warning is always thrown and the xfallback kicks in. If there's nothing for a query to find, why is the query being put in at all? I mean we know whether there's something to be found ahead of time. So how about only including the lookups where there actually is something to lookup? 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 data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 27 May 2010 15:41, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Richard: On Tue, May 25, 2010 at 12:08:17PM +0100, Richard Quadling wrote: In the event that the xpointer evaluation doesn't return anything, the XPointer evaluation failed warning is always thrown and the xfallback kicks in. If there's nothing for a query to find, why is the query being put in at all? I mean we know whether there's something to be found ahead of time. So how about only including the lookups where there actually is something to lookup? 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 data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 You are right. And that is how it is (with the exception of datetime classes). But there are instances where getting just the first entry from the method synopsis list isn't right. The DatePeriod class has 3 constructors. That led me to see the difference between a methodsynopsis and a constructorsynopsis and that the xpointer results were being truncated to only the first entry. Then realised that a fallback was needed when there is no data. So, I put in the construct/destruct/method synopsis xincludes and handled the difference between an OOP and procedural. The fallback was needed when there is nothing to retrieve, but instantly allows for the addition of them without having to modify the class file. Currently, the end result provides for ... 1 - Any number of prototypes for the OOP and procedural constructor/destructor/methods. 2 - Separate constructor and destructor from the methods. And by having the constructor/destructor before the other methods, it feels more right than having them tucked away in the list due to the __ prefix being ignored when the list is displayed. I suspect the sort order is based upon the filename and so if it was __construct.xml rather than, then this would sort them and we could just use methodsynopsis. I would like to have the class synopsis look like ... __construct()'s __destruct()'s __magicMethod's localMethod's inheritedMethod's (public's, protected's as well as final private's to show what methods cannot be overloaded if this class is inherited or sub-classed). For me, it is one of consistency. Also, you have the benefit of being able to identify constructor/destructor/methods x oop/proc in PhD and show them differently if required. I suppose some consensus on this would be nice. I'm more than happy to leave off what I've done. Richard. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 25 May 2010 19:37, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, May 25, 2010 at 13:08, Richard Quadling rquadl...@googlemail.com wrote: On 24 May 2010 16:00, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Mon, May 24, 2010 at 03:25, Philip Olson phi...@roshambo.org wrote: At this stage, I'm wondering why we don't simply collect all the errors ... ?php libxml_use_internal_errors(true); ? I thought we did? Unless --enable-xml-details was set Then how are the warnings being displayed on the online editor from the xinclude() call? And then the penny drops. The editor is using --disable-segfault-error to NOT capture the errors. http://svn.php.net/viewvc/web/doc-editor/trunk/php/conf/project.php.ini?view=markup#l25 So, if we are not interested in xinclude errors, captured by libxml_use_internal_errors(true) or otherwise, then a simple @$dom-xinclude(); libxml_clear_errors(); should do the trick. Currently, final private methods are documented as part of the class (http://docs.php.net/LogicException for example). The __clone() method is neither part of nor callable from any sub-class of Exception and shouldn't be documented as such. It isn't documented as method of that class, it is documented as inherited method. It needs to be there because its a final method. If you create an exception extending LogicException you cannot declare a method called __clone(). -Hannes Of course. I read it completely wrong. Missed the Inherited part on the docs. Are you _sure_ you want me playing around with all of this?!!!? -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 24 May 2010 02:25, Philip Olson phi...@roshambo.org wrote:
?php
$doc = new DOMDocument();
$doc-load('doc-base/manual.xml', LIBXML_NOENT);
$doc-xinclude();
var_dump($doc-validate());
?
[Late post - need to talk to the postman.]
Aha! Yes. Got it. doc-xinclude(LIBXML_NOWARNING) still produces the warnings.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 24 May 2010 16:00, Hannes Magnusson hannes.magnus...@gmail.com wrote:
On Mon, May 24, 2010 at 03:25, Philip Olson phi...@roshambo.org wrote:
I can't get the errors locally, Considering we already throw away a
LOT of errors regarding xinclude when things go wrong
(print_xml_errors()), I can only suggest excluding the warnings from
the xinclude() call in configure.php.
I don't remember exactly why these errors were hidden before, maybe Hannes
remembers as he committed them.
We don't care about xi:include errors.
If they fail then we haven't lost anything - because the data didn't
exist to begin with.
So, a hack would be to use @$dom-xinclude();
But ...
// xinclude will generate warnings like XPointer evaluation failed:.
These can safely be ignored.
// But in case any other errors occur, pass them through our error
handler and re-instate the current
// libxml error handling.
$handlingLibxmlErrors = libxml_use_internal_errors(true);
$dom-xinclude();
print_xml_errors();
libxml_use_internal_errors($handlingLibxmlErrors);
could be an option also.
At this stage, I'm wondering why we don't simply collect all the errors ...
?php libxml_use_internal_errors(true); ?
and handle them ourselves
?php print_xml_errors(); ?
after each $dom call?
IIRC we decided that the xi:fallback was useless because we didn't
wan't to say no inherited methods (or something along those lines),
so we simply ignored xi:include errors.
The same thing applies to the new xi:includes, although I don't know
why they generate different error string.
There are 336 xincludes in phpdoc/en. If an xinclude fails the
xfallback is a required child element. As there are no other
xfallbacks (except in CDATA examples), this suggests that all the
xpointer evaluations pass and therefore no errors are generated.
In the event that the xpointer evaluation doesn't return anything, the
XPointer evaluation failed warning is always thrown and the
xfallback kicks in. Supplying LIBXML_NOWARNING has no effect (I think
this flag relates only to the XML parser and not the xinclude/xpointer
work - I'm out of my depth with libxml2 code at this stage).
So, capturing the warnings and simply discarding them, just like we do
with other xinclude related warnings (which occur during document
loading) would seem to suffice.
-Hannes
So. What would you like to do.
Related to this is the need to document non inheritable methods (final
private methods). Currently, the only one I've found is
Exception::__clone(). I've not been looking very hard.
xi:include xpointer=xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.x')/db:refentry/db:refsec...@role='description']/descendant::db:methodsynopsis[not(@role='procedural')
and (modifier='final') and (modifier='private')])
xi:fallback /
/xi:include
would cover it the xinclude, but I don't know how to wrap this to be
able to add a comment, or to exclude it from the classsynopsis.
Currently, final private methods are documented as part of the class
(http://docs.php.net/LogicException for example).
The __clone() method is neither part of nor callable from any
sub-class of Exception and shouldn't be documented as such.
Admittedly, when I get this all sorted, only non private methods will
be part of classsynopsis, and so we need to handle non inheritables.
Any ideas?
Richard.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On Tue, May 25, 2010 at 13:08, Richard Quadling rquadl...@googlemail.com wrote: On 24 May 2010 16:00, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Mon, May 24, 2010 at 03:25, Philip Olson phi...@roshambo.org wrote: At this stage, I'm wondering why we don't simply collect all the errors ... ?php libxml_use_internal_errors(true); ? I thought we did? Unless --enable-xml-details was set Currently, final private methods are documented as part of the class (http://docs.php.net/LogicException for example). The __clone() method is neither part of nor callable from any sub-class of Exception and shouldn't be documented as such. It isn't documented as method of that class, it is documented as inherited method. It needs to be there because its a final method. If you create an exception extending LogicException you cannot declare a method called __clone(). -Hannes
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 23 May 2010 05:35, Philip Olson phi...@roshambo.org wrote:
On May 21, 2010, at 1:12 PM, David Tajchreber wrote:
On Fri, 21 May 2010 11:23:06 +0100, Richard Quadling wrote:
On 21 May 2010 11:15, Richard Quadling rquadl...@googlemail.com wrote:
On 21 May 2010 10:08, Philip Olson phi...@roshambo.org wrote:
The problem is not the tags per se. I can and have successfully
compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from
the XML through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
For example, add paraFOO/para to strlen.xml outside of a refsect1
and you'll see the datetime xcinlude errors along with the real error.
It's confusing, and annoying, but I'm unsure how to solve said
annoyance.
Regards,
Philip
configure.php already suppresses xinclude errors when the errors are
being reported ( see print_xml_errors() ).
It would seem that we also need to include the ability to suppress
xpointer errors.
But sometimes the errors may be needed, so I think the option
--enable-xml-details should show the xinclude and the xpointer errors.
Using ...
if ($details || (!strpos($err-message, 'xi:include')
!strpos($err-message, 'element include') False ===
strpos($err-message, 'XPointer evaluation failed:'))) {
will now also suppress the XPointer errors, but show all the errors if
the --enable-xml-details option is enabled.
Enough do you think?
Nope. Seems that there are a LOT of errors which we suppress. Maybe
something to work on there.
So, going to just suppress the XPointer evaluation errors along with the
other errors.
The problem is definitely the xi:include tags. They reference sections
that don't exist, notably destructorsynopsis for the datetime classes.
Your patch to standardize the xi:include tags in the datetime files,
r299458, introduced the bug. configure.php hides the warnings by default
and that's why you're able to build all the manuals without seeing any of
the warnings (the xi:fallback tag is a recovery for the missing resources
but a warning is still generated). When a non-recoverable error occurs,
configure.php iterates over all the warnings/errors, printing them out as
it goes, which explains why the datetime xi:include warnings only show up
when there is another error in the documentation tree. If you want to
generate them, something as simple as what's below will do it.
$doc = new DOMDocument();
$doc-load('doc-base/manual.xml', LIBXML_NOENT);
$doc-xinclude();
var_dump($doc-validate());
The datetime documentation has essentially become (or is becoming) our model
for future (or ideal) documentation, at least when it comes to writing
DocBook XML for an extension that has both an OOP and Procedural API.
That said, the introduced xi:include tags sound a bit broken, so should be
fixed or reverted. I'm hopeful some DocBook geeks here will find the best
answer, but in the meantime it sounds like reverting this is the correct
solution.
Regards,
Philip
I can't get the errors locally, Considering we already throw away a
LOT of errors regarding xinclude when things go wrong
(print_xml_errors()), I can only suggest excluding the warnings from
the xinclude() call in configure.php.
If someone can replicate the warnings locally (i.e line 615), then try ...
$dom-xinclude(LIBXML_NOWARNING);
The xinclude tags are not broken. They correctly include what is
required/available. The issue is the warning which I am hoping will be
suppressed by the use of the above code.
Ideally, I'd like a greater amount of accuracy in targeting the
warnings, especially if a fallback is in place to handle the lack of
results from the pointer.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 23 May 2010 05:35, Philip Olson phi...@roshambo.org wrote:
On May 21, 2010, at 1:12 PM, David Tajchreber wrote:
On Fri, 21 May 2010 11:23:06 +0100, Richard Quadling wrote:
On 21 May 2010 11:15, Richard Quadling rquadl...@googlemail.com wrote:
On 21 May 2010 10:08, Philip Olson phi...@roshambo.org wrote:
The problem is not the tags per se. I can and have successfully
compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from
the XML through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
For example, add paraFOO/para to strlen.xml outside of a refsect1
and you'll see the datetime xcinlude errors along with the real error.
It's confusing, and annoying, but I'm unsure how to solve said
annoyance.
Regards,
Philip
configure.php already suppresses xinclude errors when the errors are
being reported ( see print_xml_errors() ).
It would seem that we also need to include the ability to suppress
xpointer errors.
But sometimes the errors may be needed, so I think the option
--enable-xml-details should show the xinclude and the xpointer errors.
Using ...
if ($details || (!strpos($err-message, 'xi:include')
!strpos($err-message, 'element include') False ===
strpos($err-message, 'XPointer evaluation failed:'))) {
will now also suppress the XPointer errors, but show all the errors if
the --enable-xml-details option is enabled.
Enough do you think?
Nope. Seems that there are a LOT of errors which we suppress. Maybe
something to work on there.
So, going to just suppress the XPointer evaluation errors along with the
other errors.
The problem is definitely the xi:include tags. They reference sections
that don't exist, notably destructorsynopsis for the datetime classes.
Your patch to standardize the xi:include tags in the datetime files,
r299458, introduced the bug. configure.php hides the warnings by default
and that's why you're able to build all the manuals without seeing any of
the warnings (the xi:fallback tag is a recovery for the missing resources
but a warning is still generated). When a non-recoverable error occurs,
configure.php iterates over all the warnings/errors, printing them out as
it goes, which explains why the datetime xi:include warnings only show up
when there is another error in the documentation tree. If you want to
generate them, something as simple as what's below will do it.
$doc = new DOMDocument();
$doc-load('doc-base/manual.xml', LIBXML_NOENT);
$doc-xinclude();
var_dump($doc-validate());
The datetime documentation has essentially become (or is becoming) our model
for future (or ideal) documentation, at least when it comes to writing
DocBook XML for an extension that has both an OOP and Procedural API.
That said, the introduced xi:include tags sound a bit broken, so should be
fixed or reverted. I'm hopeful some DocBook geeks here will find the best
answer, but in the meantime it sounds like reverting this is the correct
solution.
Regards,
Philip
I can't get the errors locally, Considering we already throw away a
LOT of errors regarding xinclude when things go wrong, I can only
suggest excluding the warnings from the xinclude() call in
configure.php.
If someone can replicate the warnings locally (i.e
DOMDocument::xinclude() warning on line 615), then try ...
$dom-xinclude(LIBXML_NOWARNING);
as line 615 ($Id: configure.php 299572 2010-05-21 11:04:34Z rquadling $)
The xinclude tags are not broken. They correctly include what is
required/available. The issue is the warning which I am hoping will be
suppressed by the use of the above code.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
I can't get the errors locally, Considering we already throw away a
LOT of errors regarding xinclude when things go wrong
(print_xml_errors()), I can only suggest excluding the warnings from
the xinclude() call in configure.php.
I don't remember exactly why these errors were hidden before, maybe Hannes
remembers as he committed them. Regardless, please try the script David used to
demonstrate the errors (or did you?). It really should show them:
?php
$doc = new DOMDocument();
$doc-load('doc-base/manual.xml', LIBXML_NOENT);
$doc-xinclude();
var_dump($doc-validate());
?
I tested with libxml 2.6.16, 2.7.3 and 2.7.4.
Regards,
Philip
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On May 21, 2010, at 1:12 PM, David Tajchreber wrote:
On Fri, 21 May 2010 11:23:06 +0100, Richard Quadling wrote:
On 21 May 2010 11:15, Richard Quadling rquadl...@googlemail.com wrote:
On 21 May 2010 10:08, Philip Olson phi...@roshambo.org wrote:
The problem is not the tags per se. I can and have successfully
compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from
the XML through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
For example, add paraFOO/para to strlen.xml outside of a refsect1
and you'll see the datetime xcinlude errors along with the real error.
It's confusing, and annoying, but I'm unsure how to solve said
annoyance.
Regards,
Philip
configure.php already suppresses xinclude errors when the errors are
being reported ( see print_xml_errors() ).
It would seem that we also need to include the ability to suppress
xpointer errors.
But sometimes the errors may be needed, so I think the option
--enable-xml-details should show the xinclude and the xpointer errors.
Using ...
if ($details || (!strpos($err-message, 'xi:include')
!strpos($err-message, 'element include') False ===
strpos($err-message, 'XPointer evaluation failed:'))) {
will now also suppress the XPointer errors, but show all the errors if
the --enable-xml-details option is enabled.
Enough do you think?
Nope. Seems that there are a LOT of errors which we suppress. Maybe
something to work on there.
So, going to just suppress the XPointer evaluation errors along with the
other errors.
The problem is definitely the xi:include tags. They reference sections
that don't exist, notably destructorsynopsis for the datetime classes.
Your patch to standardize the xi:include tags in the datetime files,
r299458, introduced the bug. configure.php hides the warnings by default
and that's why you're able to build all the manuals without seeing any of
the warnings (the xi:fallback tag is a recovery for the missing resources
but a warning is still generated). When a non-recoverable error occurs,
configure.php iterates over all the warnings/errors, printing them out as
it goes, which explains why the datetime xi:include warnings only show up
when there is another error in the documentation tree. If you want to
generate them, something as simple as what's below will do it.
$doc = new DOMDocument();
$doc-load('doc-base/manual.xml', LIBXML_NOENT);
$doc-xinclude();
var_dump($doc-validate());
The datetime documentation has essentially become (or is becoming) our model
for future (or ideal) documentation, at least when it comes to writing DocBook
XML for an extension that has both an OOP and Procedural API.
That said, the introduced xi:include tags sound a bit broken, so should be
fixed or reverted. I'm hopeful some DocBook geeks here will find the best
answer, but in the meantime it sounds like reverting this is the correct
solution.
Regards,
Philip
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 21 May 2010 05:01, Philip Olson phi...@roshambo.org wrote:
On May 20, 2010, at 8:52 PM, Yago Ferrer wrote:
Hi Philip!
When I´m trying to compile the Spanish PHP manual I´m getting these errors,
do you know what is it?
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php on
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:methodsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php on
line 613
Nope, and I can't reproduce (even after trying a fresh doc-es checkout).
However, yesterday people saw these errors when unrelated errors occurred in
the manual. The mongo docs briefly had a para in the wrong place, yet these
nasty looking datetime errors showed up (along with the correct mongo errors
too). Therefore I wonder, whenever we have a problem we might see these too
which is very confusing. Anyone have an idea regarding how to fix that?
Regards,
Philip
Can you check the version of libxml that is being used by the online
editor please?
I recently added the new xinclude/xpointer/xfallback to the datetime
(in all the translations).
I did do a thorough test locally.
I'm using Windows and have to use the --disable-libxml-check as the
last official win32 version of PHP is using ...
Constant [ integer LIBXML_VERSION ] { 20703 }
Constant [ string LIBXML_DOTTED_VERSION ] { 2.7.3 }
Constant [ string LIBXML_LOADED_VERSION ] { 20703 }
and 2.7.4+ is required or use the --disable-libxml-check to skip the
version check.
Regards,
Richard.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On Fri, May 21, 2010 at 1:20 PM, Richard Quadling
rquadl...@googlemail.com wrote:
On 21 May 2010 05:01, Philip Olson phi...@roshambo.org wrote:
On May 20, 2010, at 8:52 PM, Yago Ferrer wrote:
Hi Philip!
When I´m trying to compile the Spanish PHP manual I´m getting these
errors, do you know what is it?
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php
on line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:methodsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php
on line 613
Nope, and I can't reproduce (even after trying a fresh doc-es checkout).
However, yesterday people saw these errors when unrelated errors occurred
in the manual. The mongo docs briefly had a para in the wrong place, yet
these nasty looking datetime errors showed up (along with the correct mongo
errors too). Therefore I wonder, whenever we have a problem we might see
these too which is very confusing. Anyone have an idea regarding how to fix
that?
Regards,
Philip
Can you check the version of libxml that is being used by the online
editor please?
I recently added the new xinclude/xpointer/xfallback to the datetime
(in all the translations).
I did do a thorough test locally.
I'm using Windows and have to use the --disable-libxml-check as the
last official win32 version of PHP is using ...
Constant [ integer LIBXML_VERSION ] { 20703 }
Constant [ string LIBXML_DOTTED_VERSION ] { 2.7.3 }
Constant [ string LIBXML_LOADED_VERSION ] { 20703 }
and 2.7.4+ is required or use the --disable-libxml-check to skip the
version check.
The problem comes from some xinclude tags added recently which I can't
trace them.
Regards,
Pedram
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 21 May 2010 10:00, pedram salehpoor pedram.salehp...@gmail.com wrote:
On Fri, May 21, 2010 at 1:20 PM, Richard Quadling
rquadl...@googlemail.com wrote:
On 21 May 2010 05:01, Philip Olson phi...@roshambo.org wrote:
On May 20, 2010, at 8:52 PM, Yago Ferrer wrote:
Hi Philip!
When I´m trying to compile the Spanish PHP manual I´m getting these
errors, do you know what is it?
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in
/local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php
on line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in
/local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in
/local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:methodsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php
on line 613
Nope, and I can't reproduce (even after trying a fresh doc-es checkout).
However, yesterday people saw these errors when unrelated errors occurred
in the manual. The mongo docs briefly had a para in the wrong place, yet
these nasty looking datetime errors showed up (along with the correct
mongo errors too). Therefore I wonder, whenever we have a problem we might
see these too which is very confusing. Anyone have an idea regarding how
to fix that?
Regards,
Philip
Can you check the version of libxml that is being used by the online
editor please?
I recently added the new xinclude/xpointer/xfallback to the datetime
(in all the translations).
I did do a thorough test locally.
I'm using Windows and have to use the --disable-libxml-check as the
last official win32 version of PHP is using ...
Constant [ integer LIBXML_VERSION ] { 20703 }
Constant [ string LIBXML_DOTTED_VERSION ] { 2.7.3 }
Constant [ string LIBXML_LOADED_VERSION ] { 20703 }
and 2.7.4+ is required or use the --disable-libxml-check to skip the
version check.
The problem comes from some xinclude tags added recently which I can't
trace them.
Regards,
Pedram
The problem is not the tags per se. I can and have successfully
compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from
the XML through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
[2010/05/21 9:42:59] [D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules\doc-all\doc-base]
[] configure --with-lang=es --enable-xml-details
--with-partial=book.datetime --disable-libxml-check
configure.php: $Id: configure.php 299087 2010-05-06 17:17:45Z philip $
PHP version: 5.3.3-dev
Checking for source directory... D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules\doc-all\doc-base
Checking for output filename... D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules\doc-all\doc-base/.manual.xml
Checking whether to save an invalid .manual.xml... no
Checking whether to include CHM... no
Checking for PHP executable... C:/PHP5/php.exe
Checking for language to build... es
Checking whether the language is supported... yes
Checking for partial build... book.datetime
Checking whether to enable detailed XML error messages... yes
Generating D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules\doc-all\doc-base/manual.xml...
done
Generating D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules\doc-all\doc-base/entities/version.ent...
done
Generating D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules\doc-all\doc-base/scripts/file-entities.php...
done
Iterating over extension specific version files... OK
Saving it... OK
Creating file D:\Personal
Re: [PHP-DOC] Re: Error when compiling PHP manual.
The problem is not the tags per se. I can and have successfully compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from the XML through to a Windows CHM (I'm on Windows after all). I'm not getting the warnings that you are seeing. For example, add paraFOO/para to strlen.xml outside of a refsect1 and you'll see the datetime xcinlude errors along with the real error. It's confusing, and annoying, but I'm unsure how to solve said annoyance. Regards, Philip
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 21 May 2010 10:08, Philip Olson phi...@roshambo.org wrote:
The problem is not the tags per se. I can and have successfully
compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from
the XML through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
For example, add paraFOO/para to strlen.xml outside of a refsect1 and
you'll see the datetime xcinlude errors along with the real error. It's
confusing, and annoying, but I'm unsure how to solve said annoyance.
Regards,
Philip
configure.php already suppresses xinclude errors when the errors are
being reported ( see print_xml_errors() ).
It would seem that we also need to include the ability to suppress
xpointer errors.
But sometimes the errors may be needed, so I think the option
--enable-xml-details should show the xinclude and the xpointer errors.
Using ...
if ($details || (!strpos($err-message, 'xi:include')
!strpos($err-message, 'element include') False ===
strpos($err-message, 'XPointer evaluation failed:'))) {
will now also suppress the XPointer errors, but show all the errors if
the --enable-xml-details option is enabled.
Enough do you think?
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On 21 May 2010 11:15, Richard Quadling rquadl...@googlemail.com wrote:
On 21 May 2010 10:08, Philip Olson phi...@roshambo.org wrote:
The problem is not the tags per se. I can and have successfully
compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from
the XML through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
For example, add paraFOO/para to strlen.xml outside of a refsect1 and
you'll see the datetime xcinlude errors along with the real error. It's
confusing, and annoying, but I'm unsure how to solve said annoyance.
Regards,
Philip
configure.php already suppresses xinclude errors when the errors are
being reported ( see print_xml_errors() ).
It would seem that we also need to include the ability to suppress
xpointer errors.
But sometimes the errors may be needed, so I think the option
--enable-xml-details should show the xinclude and the xpointer errors.
Using ...
if ($details || (!strpos($err-message, 'xi:include')
!strpos($err-message, 'element include') False ===
strpos($err-message, 'XPointer evaluation failed:'))) {
will now also suppress the XPointer errors, but show all the errors if
the --enable-xml-details option is enabled.
Enough do you think?
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Nope. Seems that there are a LOT of errors which we suppress. Maybe
something to work on there.
So, going to just suppress the XPointer evaluation errors along with
the other errors.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual - possible fix.
On 21 May 2010 11:23, Richard Quadling rquadl...@googlemail.com wrote:
On 21 May 2010 11:15, Richard Quadling rquadl...@googlemail.com wrote:
On 21 May 2010 10:08, Philip Olson phi...@roshambo.org wrote:
The problem is not the tags per se. I can and have successfully
compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from
the XML through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
For example, add paraFOO/para to strlen.xml outside of a refsect1 and
you'll see the datetime xcinlude errors along with the real error. It's
confusing, and annoying, but I'm unsure how to solve said annoyance.
Regards,
Philip
configure.php already suppresses xinclude errors when the errors are
being reported ( see print_xml_errors() ).
It would seem that we also need to include the ability to suppress
xpointer errors.
But sometimes the errors may be needed, so I think the option
--enable-xml-details should show the xinclude and the xpointer errors.
Using ...
if ($details || (!strpos($err-message, 'xi:include')
!strpos($err-message, 'element include') False ===
strpos($err-message, 'XPointer evaluation failed:'))) {
will now also suppress the XPointer errors, but show all the errors if
the --enable-xml-details option is enabled.
Enough do you think?
Nope. Seems that there are a LOT of errors which we suppress. Maybe
something to work on there.
So, going to just suppress the XPointer evaluation errors along with
the other errors.
The warnings are being generated by the DOMDocument::xinclude() call,
not as part of the reporting that configure.php does when errors are
found which I've fixed when the xml is invalid.
It also seems that xinclude() is reporting warnings and not errors.
Errors would break the configure.
So, the only option I can see is to use ...
$dom-xinclude(LIBXML_NOWARNING);
on line 615 ($Id: configure.php 299572 2010-05-21 11:04:34Z rquadling $)
But I can't determine the efficacy of this without being able to
generate the fault in the first place. Also, it may suppress other
warnings which are not related to this issue.
The online editor is using libxml 2.7.5 compared to my 2.7.3 ( Anyone
help me upgrade my libxml please?)
Regards,
Richard.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On Fri, 21 May 2010 11:23:06 +0100, Richard Quadling wrote:
On 21 May 2010 11:15, Richard Quadling rquadl...@googlemail.com wrote:
On 21 May 2010 10:08, Philip Olson phi...@roshambo.org wrote:
The problem is not the tags per se. I can and have successfully
compiled all the manuals I've altered (en, es, fa, fr, ja, tr) from
the XML through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
For example, add paraFOO/para to strlen.xml outside of a refsect1
and you'll see the datetime xcinlude errors along with the real error.
It's confusing, and annoying, but I'm unsure how to solve said
annoyance.
Regards,
Philip
configure.php already suppresses xinclude errors when the errors are
being reported ( see print_xml_errors() ).
It would seem that we also need to include the ability to suppress
xpointer errors.
But sometimes the errors may be needed, so I think the option
--enable-xml-details should show the xinclude and the xpointer errors.
Using ...
if ($details || (!strpos($err-message, 'xi:include')
!strpos($err-message, 'element include') False ===
strpos($err-message, 'XPointer evaluation failed:'))) {
will now also suppress the XPointer errors, but show all the errors if
the --enable-xml-details option is enabled.
Enough do you think?
--
-
Richard Quadling
Standing on the shoulders of some very clever giants! EE :
http://www.experts-exchange.com/M_248814.html EE4Free :
http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified
Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA :
http://uk.zopa.com/member/RQuadling
Nope. Seems that there are a LOT of errors which we suppress. Maybe
something to work on there.
So, going to just suppress the XPointer evaluation errors along with the
other errors.
The problem is definitely the xi:include tags. They reference sections
that don't exist, notably destructorsynopsis for the datetime classes.
Your patch to standardize the xi:include tags in the datetime files,
r299458, introduced the bug. configure.php hides the warnings by default
and that's why you're able to build all the manuals without seeing any of
the warnings (the xi:fallback tag is a recovery for the missing resources
but a warning is still generated). When a non-recoverable error occurs,
configure.php iterates over all the warnings/errors, printing them out as
it goes, which explains why the datetime xi:include warnings only show up
when there is another error in the documentation tree. If you want to
generate them, something as simple as what's below will do it.
$doc = new DOMDocument();
$doc-load('doc-base/manual.xml', LIBXML_NOENT);
$doc-xinclude();
var_dump($doc-validate());
David
Re: [PHP-DOC] Re: Error when compiling PHP manual.
On Fri, 21 May 2010 10:05:49 +0100, Richard Quadling wrote:
On 21 May 2010 10:00, pedram salehpoor pedram.salehp...@gmail.com
wrote:
On Fri, May 21, 2010 at 1:20 PM, Richard Quadling
rquadl...@googlemail.com wrote:
On 21 May 2010 05:01, Philip Olson phi...@roshambo.org wrote:
On May 20, 2010, at 8:52 PM, Yago Ferrer wrote:
Hi Philip!
When I´m trying to compile the Spanish PHP manual I´m getting these
errors, do you know what is it?
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsect1
[...@role='description']/descendant::db:destructorsynopsis[not
(@role='procedural')])
in
/local/web/sites/edit.php.net/data/phpdoc-all/doc-base/
configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsect1
[...@role='description']/descendant::db:destructorsynopsis[not
(@role='procedural')])
in
/local/web/sites/edit.php.net/data/phpdoc-all/doc-base/
configure.php
on line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsect1
[...@role='description']/descendant::db:destructorsynopsis[not
(@role='procedural')])
in
/local/web/sites/edit.php.net/data/phpdoc-all/doc-base/
configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsect1
[...@role='description']/descendant::db:destructorsynopsis[not
(@role='procedural')])
in
/local/web/sites/edit.php.net/data/phpdoc-all/doc-base/
configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsect1
[...@role='description']/descendant::db:methodsynopsis[not
(@role='procedural')])
in
/local/web/sites/edit.php.net/data/phpdoc-all/doc-base/
configure.php
on line 613
Nope, and I can't reproduce (even after trying a fresh doc-es
checkout).
However, yesterday people saw these errors when unrelated errors
occurred in the manual. The mongo docs briefly had a para in the
wrong place, yet these nasty looking datetime errors showed up
(along with the correct mongo errors too). Therefore I wonder,
whenever we have a problem we might see these too which is very
confusing. Anyone have an idea regarding how to fix that?
Regards,
Philip
Can you check the version of libxml that is being used by the online
editor please?
I recently added the new xinclude/xpointer/xfallback to the datetime
(in all the translations).
I did do a thorough test locally.
I'm using Windows and have to use the --disable-libxml-check as the
last official win32 version of PHP is using ...
Constant [ integer LIBXML_VERSION ] { 20703 } Constant [ string
LIBXML_DOTTED_VERSION ] { 2.7.3 } Constant [ string
LIBXML_LOADED_VERSION ] { 20703 }
and 2.7.4+ is required or use the --disable-libxml-check to skip the
version check.
The problem comes from some xinclude tags added recently which I can't
trace them.
Regards,
Pedram
The problem is not the tags per se. I can and have successfully compiled
all the manuals I've altered (en, es, fa, fr, ja, tr) from the XML
through to a Windows CHM (I'm on Windows after all).
I'm not getting the warnings that you are seeing.
[2010/05/21 9:42:59] [D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules
\doc-all\doc-base]
[] configure --with-lang=es --enable-xml-details
--with-partial=book.datetime --disable-libxml-check configure.php: $Id:
configure.php 299087 2010-05-06 17:17:45Z philip $ PHP version:
5.3.3-dev
Checking for source directory... D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules
\doc-all\doc-base
Checking for output filename... D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules
\doc-all\doc-base/.manual.xml
Checking whether to save an invalid .manual.xml... no Checking whether
to include CHM... no Checking for PHP executable... C:/PHP5/php.exe
Checking for language to build... es
Checking whether the language is supported... yes Checking for partial
build... book.datetime Checking whether to enable detailed XML error
messages... yes Generating D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules
\doc-all\doc-base/manual.xml...
done
Generating D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules
\doc-all\doc-base/entities/version.ent...
done
Generating D:\Personal
Files\Downloads\Software\Programming\PHP\Checkouts\svn\phpdoc\modules
\doc-all\doc-base/scripts/file-entities.php...
done
Iterating over
[PHP-DOC] Re: Error when compiling PHP manual.
On May 20, 2010, at 8:52 PM, Yago Ferrer wrote:
Hi Philip!
When I´m trying to compile the Spanish PHP manual I´m getting these errors,
do you know what is it?
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php on
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phpon
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:methodsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php on
line 613
Nope, and I can't reproduce (even after trying a fresh doc-es checkout).
However, yesterday people saw these errors when unrelated errors occurred in
the manual. The mongo docs briefly had a para in the wrong place, yet these
nasty looking datetime errors showed up (along with the correct mongo errors
too). Therefore I wonder, whenever we have a problem we might see these too
which is very confusing. Anyone have an idea regarding how to fix that?
Regards,
Philip
[PHP-DOC] Re: Error when compiling PHP manual.
Hey Philip,
if you login into http://edit.php.net/ and try to compile from
'Herramientas de compilación - Probar de compilar' you will see the error
that I'm talking about.
Yago
On Thu, May 20, 2010 at 9:01 PM, Philip Olson phi...@roshambo.org wrote:
On May 20, 2010, at 8:52 PM, Yago Ferrer wrote:
Hi Philip!
When I´m trying to compile the Spanish PHP manual I´m getting these
errors, do you know what is it?
Warning: DOMDocument::xinclude(): XPointer evaluation failed: #xmlns(db=
http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phponline
613
Warning: DOMDocument::xinclude(): XPointer evaluation failed: #xmlns(db=
http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php on
line 613
Warning: DOMDocument::xinclude(): XPointer evaluation failed: #xmlns(db=
http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phponline
613
Warning: DOMDocument::xinclude(): XPointer evaluation failed: #xmlns(db=
http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:destructorsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.phponline
613
Warning: DOMDocument::xinclude(): XPointer evaluation failed: #xmlns(db=
http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/descendant::db:methodsynopsis[not(@role='procedural')])
in /local/web/sites/edit.php.net/data/phpdoc-all/doc-base/configure.php on
line 613
Nope, and I can't reproduce (even after trying a fresh doc-es checkout).
However, yesterday people saw these errors when unrelated errors occurred
in the manual. The mongo docs briefly had a para in the wrong place, yet
these nasty looking datetime errors showed up (along with the correct mongo
errors too). Therefore I wonder, whenever we have a problem we might see
these too which is very confusing. Anyone have an idea regarding how to fix
that?
Regards,
Philip
--
Yago Ferrer
[PHP-DOC] Re: Error when compiling PHP manual.
On May 20, 2010, at 9:13 PM, Yago Ferrer wrote: Hey Philip, if you login into http://edit.php.net/ and try to compile from 'Herramientas de compilación - Probar de compilar' you will see the error that I'm talking about. Realized it was edit.php.net after pressing send. Anyway, everything appears fine except for those errors. It ends with: All good. Saving .manual.xml... done. However, why the errors? I don't know, hopefully someone else does. But fwiw, no errors locally for es or en. Regards, Philip
[PHP-DOC] Re: Error when compiling PHP manual.
Sounds good. Thanks for taking a look. Yago On Thu, May 20, 2010 at 9:49 PM, Philip Olson phi...@roshambo.org wrote: On May 20, 2010, at 9:13 PM, Yago Ferrer wrote: Hey Philip, if you login into http://edit.php.net/ and try to compile from 'Herramientas de compilación - Probar de compilar' you will see the error that I'm talking about. Realized it was edit.php.net after pressing send. Anyway, everything appears fine except for those errors. It ends with: All good. Saving .manual.xml... done. However, why the errors? I don't know, hopefully someone else does. But fwiw, no errors locally for es or en. Regards, Philip -- Yago Ferrer
