plplot-devel

[Plplot-devel] Will disappear until next Thursday

[Rafael L. <ra...@de...>]

Hi,

I am cumulating problems right now.  Besides the screwed up network access,
I will be competley busy the next two days and unavailable to do actual work
on PLplot.  The situation should improve around next Wednesday or Thursday.
Sorry about that.

Just a comment on Alan's last posts: I have the feeling that you are
following the wrong path regarding that @DOCBOOK_DTD_PUBID@.  I am almost
sure that api2txt.pl should work with plplotdoc.xml.in, i.e. that it does
not need the DOCTYPE PUBID definition.  This has always worked in Debian and
also in Joao's system some time ago.  In sum, it is not a problem of the
script not finding the DocBook definitions.  Actually, api2txt.pl does not
need to know anything about DocBook.

I will let you know when I will have made some progress, but it will not be
very soon.

-- 
Rafael

Re: [Plplot-devel] Will disappear until next Thursday

[Alan W. I. <ir...@be...>]

On Sun, 9 Mar 2003, Rafael Laboissiere wrote:

> Hi,
>
> I am cumulating problems right now.  Besides the screwed up network
access....

Hope you get it all straightened out quickly.

> Just a comment on Alan's last posts: I have the feeling that you are
> following the wrong path regarding that @DOCBOOK_DTD_PUBID@.  I am almost
> sure that api2txt.pl should work with plplotdoc.xml.in, i.e. that it does
> not need the DOCTYPE PUBID definition.  This has always worked in Debian and
> also in Joao's system some time ago.  In sum, it is not a problem of the
> script not finding the DocBook definitions.  Actually, api2txt.pl does not
> need to know anything about DocBook.

You are probably right; we need to learn more about this aspect, and my
educated guesses may be leading us astray. The critical question then is how
does the perl parser know the location of those xml/sgml files you mentioned
where the required entities are defined?  Those locations do vary quite a
bit from distribution to distribution so I think the perl parser must use
the catalog system to find them so that requires a DOCTYPE.  I suppose it is
possible the perl parser has the equivalent of DOCTYPE defined internally so
it has something to search for within the catalogs.  But I hope you research
that and come up with the definitive answer.  I wouldn't want us to depend
on some DOCTYPE default fall-back that usually works (as it has for Debian,
RedHat, and the old SuSe), but which sometimes can fail.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Will disappear until next Thursday

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-03-09 16:32]:

> You are probably right; we need to learn more about this aspect, and my
> educated guesses may be leading us astray. The critical question then is
> how does the perl parser know the location of those xml/sgml files you
> mentioned where the required entities are defined?

I dug a little bit deeper and found the following: the Perl module
XML::DOM::Parser extends the module XML::Parser, which uses the expat
library (package libexpat1 in Debian).  The error that Joao gets:

    undefined entity at line 2915, column 62, byte 85921 at
    /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi/XML/Parser.pm 
    line 185

comes for the expat library (I am 100% sure about this).  What is intriguing
is that the expat library have different behaviors in Joao's system than in
Debian.  However, I could replicate the bug above when I changed the first
line of src/plplotdoc.xml.in to:

    <?xml version="1.0" standalone="yes"?>

The standalone declaration tells the parser that the document has no
external definitions.  It seems that Joao system's expat library is assuming
this.  

I did a commit recently that may fix this problem.  I added an explicit
declaration standalone="yes" to the temporary file that is parsed by
api2txt.pl, which is a "concatenation" of plplotdoc.xml.in (yes, Alan,
*.in!) and api.xml.  I also added "text" definition for the entities usually
found in api.xml.  The nice side-effect of this change is that, contrary to
what happened before, the output in the *.txt is correct, with entities like
"&deg;", "&gt;", and "&ndash;" being translated into " degrees", ">", and
"--", respectively.

Test this, please.

When I will have some time, I will commit the change in bindings/octave/
Makefile.am to include the files in plplot_octave_txt into the tarball
through make dist, such that regular users won't need XML Perl modules in
order to build the Octave bindings.

-- 
Rafael

Re: [Plplot-devel] Will disappear until next Thursday (hmmm, doesn't look like)

[<jc...@fe...>]

On Monday 10 March 2003 17:19, Rafael Laboissiere wrote:
| * Alan W. Irwin <ir...@be...> [2003-03-09 16:32]:
| > You are probably right; we need to learn more about this aspect,
| > and my educated guesses may be leading us astray. The critical
| > question then is how does the perl parser know the location of
| > those xml/sgml files you mentioned where the required entities are
| > defined?
|
| I dug a little bit deeper and found the following: the Perl module
| XML::DOM::Parser extends the module XML::Parser, which uses the expat
| library (package libexpat1 in Debian).  The error that Joao gets:
|
|     undefined entity at line 2915, column 62, byte 85921 at
|    
| /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi/XML/Parser.pm
| line 185
|
| comes for the expat library (I am 100% sure about this).  What is
| intriguing is that the expat library have different behaviors in
| Joao's system than in Debian.  However, I could replicate the bug
| above when I changed the first line of src/plplotdoc.xml.in to:
|
|     <?xml version="1.0" standalone="yes"?>
|
| The standalone declaration tells the parser that the document has no
| external definitions.  It seems that Joao system's expat library is
| assuming this.
|
| I did a commit recently that may fix this problem.  I added an
| explicit declaration standalone="yes" to the temporary file that is
| parsed by api2txt.pl, which is a "concatenation" of plplotdoc.xml.in
| (yes, Alan, *.in!) and api.xml.  I also added "text" definition for
| the entities usually found in api.xml.  The nice side-effect of this
| change is that, contrary to what happened before, the output in the
| *.txt is correct, with entities like "&deg;", "&gt;", and "&ndash;"
| being translated into " degrees", ">", and "--", respectively.
|
| Test this, please.

Yes, it works. And also in a straight RH-8.0 from a colleague. And also 
in a plain SuSE-8.1 from another colleague.

|
| When I will have some time, I will commit the change in
| bindings/octave/ Makefile.am to include the files in
| plplot_octave_txt into the tarball through make dist, such that
| regular users won't need XML Perl modules in order to build the
| Octave bindings.

Good idea.

Joao