Menu
▾
▴
plplot-devel — Technical discussion about PLplot development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(58) |
Nov
(95) |
Dec
(55) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(205) |
Feb
(106) |
Mar
(36) |
Apr
(25) |
May
(34) |
Jun
(36) |
Jul
(161) |
Aug
(66) |
Sep
(100) |
Oct
(62) |
Nov
(77) |
Dec
(172) |
| 2003 |
Jan
(101) |
Feb
(202) |
Mar
(191) |
Apr
(97) |
May
(27) |
Jun
(21) |
Jul
(16) |
Aug
(55) |
Sep
(155) |
Oct
(166) |
Nov
(19) |
Dec
(134) |
| 2004 |
Jan
(569) |
Feb
(367) |
Mar
(81) |
Apr
(62) |
May
(124) |
Jun
(77) |
Jul
(85) |
Aug
(80) |
Sep
(66) |
Oct
(42) |
Nov
(20) |
Dec
(133) |
| 2005 |
Jan
(192) |
Feb
(143) |
Mar
(183) |
Apr
(128) |
May
(136) |
Jun
(18) |
Jul
(22) |
Aug
(33) |
Sep
(20) |
Oct
(12) |
Nov
(80) |
Dec
(44) |
| 2006 |
Jan
(42) |
Feb
(38) |
Mar
(17) |
Apr
(112) |
May
(220) |
Jun
(67) |
Jul
(96) |
Aug
(214) |
Sep
(104) |
Oct
(67) |
Nov
(150) |
Dec
(103) |
| 2007 |
Jan
(111) |
Feb
(50) |
Mar
(113) |
Apr
(19) |
May
(32) |
Jun
(34) |
Jul
(61) |
Aug
(103) |
Sep
(75) |
Oct
(99) |
Nov
(102) |
Dec
(40) |
| 2008 |
Jan
(86) |
Feb
(56) |
Mar
(104) |
Apr
(50) |
May
(45) |
Jun
(64) |
Jul
(71) |
Aug
(147) |
Sep
(132) |
Oct
(176) |
Nov
(46) |
Dec
(136) |
| 2009 |
Jan
(159) |
Feb
(136) |
Mar
(188) |
Apr
(189) |
May
(166) |
Jun
(97) |
Jul
(160) |
Aug
(235) |
Sep
(163) |
Oct
(46) |
Nov
(99) |
Dec
(54) |
| 2010 |
Jan
(104) |
Feb
(121) |
Mar
(153) |
Apr
(75) |
May
(138) |
Jun
(63) |
Jul
(61) |
Aug
(27) |
Sep
(93) |
Oct
(63) |
Nov
(40) |
Dec
(102) |
| 2011 |
Jan
(52) |
Feb
(26) |
Mar
(61) |
Apr
(27) |
May
(33) |
Jun
(43) |
Jul
(37) |
Aug
(53) |
Sep
(58) |
Oct
(63) |
Nov
(67) |
Dec
(16) |
| 2012 |
Jan
(97) |
Feb
(34) |
Mar
(6) |
Apr
(18) |
May
(32) |
Jun
(9) |
Jul
(17) |
Aug
(78) |
Sep
(24) |
Oct
(101) |
Nov
(31) |
Dec
(7) |
| 2013 |
Jan
(44) |
Feb
(35) |
Mar
(59) |
Apr
(17) |
May
(29) |
Jun
(38) |
Jul
(48) |
Aug
(46) |
Sep
(74) |
Oct
(140) |
Nov
(94) |
Dec
(177) |
| 2014 |
Jan
(94) |
Feb
(74) |
Mar
(75) |
Apr
(63) |
May
(24) |
Jun
(1) |
Jul
(30) |
Aug
(112) |
Sep
(78) |
Oct
(137) |
Nov
(60) |
Dec
(17) |
| 2015 |
Jan
(128) |
Feb
(254) |
Mar
(273) |
Apr
(137) |
May
(181) |
Jun
(157) |
Jul
(83) |
Aug
(34) |
Sep
(26) |
Oct
(9) |
Nov
(24) |
Dec
(43) |
| 2016 |
Jan
(94) |
Feb
(77) |
Mar
(83) |
Apr
(19) |
May
(39) |
Jun
(1) |
Jul
(5) |
Aug
(10) |
Sep
(28) |
Oct
(34) |
Nov
(82) |
Dec
(301) |
| 2017 |
Jan
(53) |
Feb
(50) |
Mar
(11) |
Apr
(15) |
May
(23) |
Jun
(36) |
Jul
(84) |
Aug
(90) |
Sep
(35) |
Oct
(81) |
Nov
(13) |
Dec
(11) |
| 2018 |
Jan
(15) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(6) |
Jul
(4) |
Aug
(13) |
Sep
(31) |
Oct
(4) |
Nov
(25) |
Dec
(64) |
| 2019 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
(13) |
Jun
(8) |
Jul
(16) |
Aug
(7) |
Sep
(27) |
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(3) |
| 2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(9) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
|
| 2022 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(8) |
| 2023 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(10) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
|
From: Rafael L. <lab...@ps...> - 2003-03-10 17:35:24
|
* Alan W. Irwin <ir...@be...> [2003-03-09 10:49]:
> Currently, the reason why most developers would want to avoid
> --enable-docbook (even if it is straightforward to get the prerequisite
> packages installed) is it currently takes something like 6 minutes on my
> computer just to configure --enable-docbook. Rafael, do you know why it is
> so slow? That's a ridiculous amount of computer time just to configure
> something.
Which system are you using? In my Debian workstation (Pentium III, 930
MHz), the time spent between the first and the last of these output lines of
configure --enable-docbook:
checking DSSSL Style Sheet DTD... found
checking DocBook HTML Stylesheet... found
checking DocBook Print Stylesheet... found
checking DocBook DTD... found
checking for makeinfo... found
checking XML::DOM... yes
checking XML::Parser::PerlSAX... yes
checking XML::Writer... yes
is only 6 seconds (seconds, not minutes). I obtain this figure consistently
in successive runs. Something must be terribly wrong with your system,
unless you are talking about _build_ time, not _configure_ time.
> There has got to be a better way.
Buy a better computer? :-)
--
Rafael
|
|
From: Rafael L. <lab...@ps...> - 2003-03-10 17:26:41
|
* 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
"°", ">", and "–" 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
|
|
From: Rafael L. <lab...@ps...> - 2003-03-10 16:58:48
|
* Alan W. Irwin <ir...@be...> [2003-03-09 19:24]: > I have already noticed the search function in acroread for the pdf form > sometimes doesn't work (try searching for plplot repeatedly and you soon > run into problems with "unlocked objects" Which version of Acroread are you using. I have 5.0 here and never noticed the problem above. > info cross-references sometimes don't work Could you be more explicit on this, please? -- Rafael |
|
From: <jc...@fe...> - 2003-03-10 15:12:42
|
On Sunday 09 March 2003 03:48, Joao Cardoso wrote: | On Sunday 09 March 2003 02:44, Alan W. Irwin wrote: | | Thanks Alan for trying to help. | | But I don't think that is the reason. I have an old plplot build tree | and in that build tree I was able to generated the Octave online | docs, while now I can't do it anymore. | | Then I remembered that I had done a software "online update" recently | (the equivalent to apt-get), two days ago, on both my office and home | computer, and I tried to undo it, but I was not yet successfull. | | So, it looks like after all that the fault is in my system. After some effort I was not able to undo what "online update" did, and so I will not be able to build the Octave online docs. This means that I will do "make -i" and errors will be more difficult to diagnose, so be suspicious of my next bug reports -- I will be carefull, however. When I worked with a unix system without rpms, and I needed to compile everything from source, even X11 or Motif, this has never happened. The "No Free Lunch" theorem strikes again :) Joao |
|
From: Alan W. I. <ir...@be...> - 2003-03-10 03:25:38
|
On Sun, 9 Mar 2003, Alan W. Irwin wrote: > I am also having some other www-install troubles for non-html results > which I am investigating further. The problems I alluded to (which caused only part of the documentation to be installed at SF) are almost certainly more dependency issues. For now I worked around these problems for the Debian docbuild by starting with a fresh checkout which insured ultimately that all documentation was installed at SF by make www-install. Please everybody have a look at these documentation results (http://plplot.sourceforge.net/resources/docbook-manual/) to make sure the current content is presented properly for *all output forms*. I have already noticed the search function in acroread for the pdf form sometimes doesn't work (try searching for plplot repeatedly and you soon run into problems with "unlocked objects", info cross-references sometimes don't work, and Rafael's last name is not presented properly for many forms of the documentation. There may be other backend problems as well. BTW Rafael, I am glad you gracefully gave in to my wishes and kept the dvi form. You should try using xdvi on that form; the result looks good and the cross-references seem to work which is already a step up from the postscript form (where I believe cross-references are outside the postscript paradigm completely). My PLplot priorities before the April release are the following: * Get the RedHat doc build working as well as the Debian build. (To be started later tonight, but this will probably be finished next weekend because this is a critical week for my fortran contract job.) Update README.developers according to my RedHat experiences. * Collaborate with Joao to help him build the documentation on SuSe. * Sort out the dependency issues in the Makefile.am files in doc/docbook and subdirectories. * Report documentation backend issues (as above) so that Rafael can attempt to deal with them. * Try to sort out any syntax problems in docbook/xml content that you guys provide. I want to strongly encourage your contributions this way and also by helping you to build the documentation yourself (see the higher priority above). Ultimately documentation is every developer's responsibility so I don't like the present setup where only Rafael and I can do it. * Upgrade some documentation content myself. (I doubt I will have any time for this before the release compared to the above priorities.) 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2003-03-10 00:34:01
|
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 __________________________ |
|
From: Rafael L. <ra...@de...> - 2003-03-09 22:22:30
|
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 |
|
From: Alan W. I. <ir...@be...> - 2003-03-09 21:40:02
|
Joao, please have a look at http://plplot.sourceforge.net/resources/docbook-manual/plplot-html-5.2.0/ to see the results of your api.xml changes (as corrected by Rafael and me, and just built and www-installed by me). The corrections I applied concerned adding the new plenv0 entity to plplotdoc.xml.in, fully defining plenv0 (including a full description of the arguments), using the correct <sect1> attributes for plotsh3d, and correcting badly nested tags. Actually these fixes are no problem at all, and I want to encourage you to continue documenting this way. Rafael, there is still one openjade error left when you build the documentation; openjade -d plplotdoc-print.dsl -t tex \ -o plplot-5.2.0.jadetex /usr/lib/sgml/declaration/xml.dcl plplotdoc.xml openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbttlpg.dsl:2635 :6:E: flow object not accepted by port; only display flow objects accepted jadetex plplot-5.2.0.jadetex I don't know how to fix this one, but I also don't think it has anything to do with the recent api.xml changes. I am also having some other www-install troubles for non-html results which I am investigating further. All these issues have occurred for the Debian build of the documentation. Sorting out the rest of the problems (other than the above openjade error) may take the rest of the day so it is unlikely I will be able to address RedHat documentation build problems today. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2003-03-09 18:51:12
|
On Sun, 9 Mar 2003, Alan W. Irwin wrote: > Joao, could you please try a fresh checkout to see whether my recent commit > will solve the parsing problem on your system? Never mind. It still isn't right. > > I found an error in the stanza in question. Reference was made to > plplotdoc.xml.in rather than the correct plplotdoc.xml. The principal > difference between the two is DOCTYPE (the key to finding system files > required by sgml/xml applications and libraries) is configured so that > plplotdoc.xml is the file where this is defined properly. The only way this > could have worked before when using plplotdoc.xml.in for Debian is if there > is a broad default set of entities defined when no DOCTYPE is specified. But > I think it is much better to define the DOCTYPE like is done now. If this > is still incomplete (Rafael, would you check this please?), then I suggest > the required DOCTYPE lines should be configured in plplotdoc.xml so that > api2text.pl has a chance to work correctly on all systems. Problem is that @DOCBOOK_DTD_PUBID@ is not defined and therefore the DOCTYPE is not configured properly in plplotdoc.xml for the --disable-docbook case. Rafael, can you fix this (or send me a patch to fix it if you still don't have cvs access)? What we want is something minimal that configures things sufficiently so that api2text.pl works properly whether --enable-docbook or --disable-docbook. Currently, the reason why most developers would want to avoid --enable-docbook (even if it is straightforward to get the prerequisite packages installed) is it currently takes something like 6 minutes on my computer just to configure --enable-docbook. Rafael, do you know why it is so slow? That's a ridiculous amount of computer time just to configure something. There has got to be a better way. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2003-03-09 17:45:32
|
P.S. Another problem in the old RedHat 6.2 days is the various applications had different ideas about the location of the top-level catalog file, and I am concerned this may still be the case for perl modules. Rafael, do the various raw CPAN (as opposed to Debian-patched) sgml/xml perl modules all use /etc/sgml/catalog for the location of the top-level catalog? If they assume locations other than /etc/sgml/catalog, then how can we specify the correct location to them? 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2003-03-09 17:36:41
|
On Sun, 9 Mar 2003, Rafael Laboissiere wrote: > This is not related to a parsing error or ill-formed XML, so the Perl > modules are working fine for him. I looked at the position of the file and > the script is choking at a "°" entity use. I traced down in my > computer, and I discovered that this entity is defined in file > > /usr/share/sgml/entities/xml-iso-entities-8879.1986/ISOnum.ent > > which is included in DocBook through: > > /usr/share/sgml/docbook/dtd/xml/4.2/dbcentx.mod > > In Debian, the former file is in package sgml-data (version 1.8) and the > later in docbook-xml (version 4.2-6). Notice that sgml-data is a native > package of Debian, which includes definitions for several different markup > languages. Debian (as usual) has a very sophisticated dependency and > organisational system that insures that things work correctly. In the case > of SGML/XML, all the infrastructure is well implemented, such that catalogs > are correctly found, for instance. Thanks, Rafael, for that analysis. To expand that a bit further, sgml/xml keeps track of important files through a hierarchy of catalog files. The top-level catalog is normally located at /etc/sgml/catalog. At execution time the catalog hierarchy is searched for the appropriate files (identified by DOCTYPE statements in files that are directly input to the application in question). That is why I made my recent commit so that the plplotdoc.xml (rather than plplotdoc.xml.in) that is input for api2text.pl had a well-defined DOCTYPE line. That bug fix may be enough to solve the parsing problem on Joao's system. However, if not, another possibility is the hierarchy of catalogs has been screwed up on his system. The problem is that every different distribution organizes this hierarchy differently and manages it with different tools. For example, Debian uses update-catalog to manage these catalogs while RedHat (and SuSe?) use xmlcatalog. (To see what is used on your system try rpm -q --scripts docbook-dtds. That rpm is the appropriate one on RedHat, but it may have a different name on SuSe.) If you try and install an sgml/xml package from a different distribution than yours or from a tarball or if the packager naively adapts another distribution's sgml/xml rpm without paying attention to catalogs, you can have a screwed up catalog hierarchy. Fortunately, the catalog hierarchy is easy to trace by hand (all the files are human-readable) so problems are straightforward to diagnose (with massive uses of locate, find, xargs, and grep). In the near future, Rafael will be addressing the catalog issue for the octave front-end to plplot by putting in configuration checks to test the catalog hierarchy is working well enough to support api2txt.pl. BTW, I don't agree with Rafael's claim that Debian has more sophisticated tools than other distributions. (Although I am a Debian advocate like Rafael, I try not to go too overboard with it....;-)) In my view what really distinguishes Debian is the high quality assurance enforced by a rather raucous group of users who will publically hound and embarass packagers (and also submit helpful patches) until they get it right. Thus, way back for Debian potato the sgml catalogs were fine while they were completely screwed up for RH 6.2. I am hoping that will not be a problem for RH 7.3 and 8.0, but I hope to know a lot more about that later today. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2003-03-09 17:02:58
|
Joao, could you please try a fresh checkout to see whether my recent commit will solve the parsing problem on your system? I found an error in the stanza in question. Reference was made to plplotdoc.xml.in rather than the correct plplotdoc.xml. The principal difference between the two is DOCTYPE (the key to finding system files required by sgml/xml applications and libraries) is configured so that plplotdoc.xml is the file where this is defined properly. The only way this could have worked before when using plplotdoc.xml.in for Debian is if there is a broad default set of entities defined when no DOCTYPE is specified. But I think it is much better to define the DOCTYPE like is done now. If this is still incomplete (Rafael, would you check this please?), then I suggest the required DOCTYPE lines should be configured in plplotdoc.xml so that api2text.pl has a chance to work correctly on all systems. 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 __________________________ |
|
From: Rafael L. <ra...@de...> - 2003-03-09 14:21:22
|
Hi,
I am still without access to my email and production workstation, but I am
following the discussion in the mailing list through the web. Thanks for
your efforts, Alan, regarding the Perl modules. Joao: I was half-joking
about your "pestering" after the Perl modules and Docbook. Actually, I am
pleased and surprised that even if you dislike the DocBook markup, you are
still contributing with the documentation and willing to get things working.
Contrary to Joao, I dislike visual editors (like LyX and the Mozilla
Composer). When I edit LaTeX and HTML/SGML/XML, I use AUC-TeX and
PSGML-mode, respectively, under XEmacs. They are not WYSIWYG tools
(fortunately!), but they are incredible helpers. With a normal editor, I
would find it almost impossible to do productive work with such "verbose
technologies".
These comments apart, let me share with you some insights I had about the
source of the problem that Joao is experiencing. The error message that he
is getting now is:
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
This is not related to a parsing error or ill-formed XML, so the Perl
modules are working fine for him. I looked at the position of the file and
the script is choking at a "°" entity use. I traced down in my
computer, and I discovered that this entity is defined in file
/usr/share/sgml/entities/xml-iso-entities-8879.1986/ISOnum.ent
which is included in DocBook through:
/usr/share/sgml/docbook/dtd/xml/4.2/dbcentx.mod
In Debian, the former file is in package sgml-data (version 1.8) and the
later in docbook-xml (version 4.2-6). Notice that sgml-data is a native
package of Debian, which includes definitions for several different markup
languages. Debian (as usual) has a very sophisticated dependency and
organisational system that insures that things work correctly. In the case
of SGML/XML, all the infrastructure is well implemented, such that catalogs
are correctly found, for instance.
In sum, I do not think that Joao's present problems are related to Perl
modules that are lacking or outdated, but purely related to problematic
SGML/XML infrastructure in rpm-based systems.
Some time ago I made a private joke to Alan saying that it would be easier
to convert all the developers to Debian instead of trying to fix those
crappy rpm-based systems. ;-)
Of course, I was only half-joking...
--
Rafael (aka Debian Evangelist)
|
|
From: Alan W. I. <ir...@be...> - 2003-03-09 07:27:46
|
On Sun, 9 Mar 2003, Joao Cardoso wrote: > Meanwhile, I would also like to be able to build the docs, even without > understanding what I'm doing! I will try to help you as much as possible since I also would like more developers than just Rafael and me to be able to build the documentation. I am sorry README.developers is so out of date and only relevant to Debian, but I hope to fix that soon. I am trying to build the documentation on a RedHat system this weekend. I am keeping good notes (the first part of which is the personal perl module install which you quote from my prior post below). Once I am successful with the whole documentation build on RH 7.3 and 8.0 (which I think should be much easier than what I used to have to do for RH 6.2), I should be able to give a nice cookbook for RedHat. That should be fairly close to what you have to do on SuSe, but I am willing to help you with further adjustments for that distribution if those are needed. > > You can figure out virtually everything you need to know by using man CPAN > > (especially the FAQ number 5 at the end: "I am not root, how can I install > > a module in a personal directory?" However, that FAQ is wrong in one key > > aspect. It recommends using (after you have invoked perl -MCPAN -e shell) > > > > o conf makepl_arg \ > > "LIB=~/myperl/lib \ > > INSTALLMAN1DIR=~/myperl/man/man1 \ > > INSTALLMAN3DIR=~/myperl/man/man3" > > > > You need to define the PREFIX as well (I found that out from a google > > search). > > > > Thus use instead: > > > > o conf makepl_arg \ > > "PREFIX=~/myperl \ > > LIB=~/myperl/lib \ > > INSTALLMAN1DIR=~/myperl/man/man1 \ > > INSTALLMAN3DIR=~/myperl/man/man3" > > > > After creating all these directories and setting PERL5LIB and MANPATH > > appropriately I found > > > > install MD5 > > install Bundle::CPAN > > install XML::DOM > > install XML::Parser > > > > all worked fine to install personal versions of these modules. (The last > > two are versions 1.42 and 2.31). > > > > The first two installs are to make sure MD5 sums are checked on download > > and to bootstrap to the latest version of the CPAN module. My initial > > impressions are the CPAN module is great for downloading and installing > > modules from CPAN, and I think it is probably the way to go if your Linux > > distribution has incomplete (RedHat) or out-of-date (SuSe?) perl modules. > > Note, I have just installed XML::Writer (which was completely unavailable as an rpm for RedHat) in the above way so I am hoping that will take care of the last of the perl module problems for the full documentation build on RH. When I look further into this tomorrow I am sure there will also be other issues such as using the correct XML catalog (which RH always seems to mess up) and making sure there is a big enough pdflatex version around, but I am confident I can sort out all those issues. 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 __________________________ |
|
From: Joao C. <jc...@fe...> - 2003-03-09 03:51:51
|
On Sunday 09 March 2003 02:44, Alan W. Irwin wrote: Thanks Alan for trying to help. But I don't think that is the reason. I have an old plplot build tree and in that build tree I was able to generated the Octave online docs, while now I can't do it anymore. Then I remembered that I had done a software "online update" recently (the equivalent to apt-get), two days ago, on both my office and home computer, and I tried to undo it, but I was not yet successfull. So, it looks like after all that the fault is in my system. I apologize for all. But I still thing that docbook is like killing flies with a riffle. Meanwhile, I would also like to be able to build the docs, even without understanding what I'm doing! As I have already spent two afternoons and one night reading doc/docbook/README.developers and searching for the correct files in my system (what I think I have done, but configure says no!) please send to me the actual files specified in --with-xml-declaration=<one file> and --with-sgml-catalogs=<four_files> so I can search my system based on file content! Thanks, Joao > From Joao's recent post, his perl system cannot parse api.xml version 1.47 > while my Debian woody perl system (and presumably Rafael's Debian testing > system once he is back on line) can. The perl script > doc/docbook/bin/api2text.pl has the following statements: > > use XML::Parser; > use XML::DOM; > > so I am wondering if one of those perl modules is the source of > Joao's problem parsing api.xml. From his previous post he has > > > perl-XML-DOM-1.39-24 > > perl-XML-Parser-2.31-30 > > It is hard to correlate Debian packages (also RedHat packages) with perl > module versions since the modules tend to be bundled in much bigger > packages for both Debian and RedHat. For example, on RedHat perl-XML-DOM is > part of the perl-libxml-enno-1.02-15 package. However, I did check CPAN, > and the latest versions of these two modules are perl-XML-DOM-1.42 and > perl-XML-Parser-2.31. So Joao, your perl-XML-Parser package seems up to > date, but you probably need to upgrade to a later perl-XML-DOM and try > again. One way to do that with CPAN is given below. > > I know virtually no perl, but I am beginning to experiment with the CPAN > module to get the latest modules from CPAN. (RedHat rpm perl module > support is incomplete. Although it is good enough to build the octave > documention, it will be necessary to use CPAN to get the required modules > for the complete documentation build.) > > You can figure out virtually everything you need to know by using man CPAN > (especially the FAQ number 5 at the end: "I am not root, how can I install > a module in a personal directory?" However, that FAQ is wrong in one key > aspect. It recommends using (after you have invoked perl -MCPAN -e shell) > > o conf makepl_arg \ > "LIB=~/myperl/lib \ > INSTALLMAN1DIR=~/myperl/man/man1 \ > INSTALLMAN3DIR=~/myperl/man/man3" > > You need to define the PREFIX as well (I found that out from a google > search). > > Thus use instead: > > o conf makepl_arg \ > "PREFIX=~/myperl \ > LIB=~/myperl/lib \ > INSTALLMAN1DIR=~/myperl/man/man1 \ > INSTALLMAN3DIR=~/myperl/man/man3" > > After creating all these directories and setting PERL5LIB and MANPATH > appropriately I found > > install MD5 > install Bundle::CPAN > install XML::DOM > install XML::Parser > > all worked fine to install personal versions of these modules. (The last > two are versions 1.42 and 2.31). > > The first two installs are to make sure MD5 sums are checked on download > and to bootstrap to the latest version of the CPAN module. My initial > impressions are the CPAN module is great for downloading and installing > modules from CPAN, and I think it is probably the way to go if your Linux > distribution has incomplete (RedHat) or out-of-date (SuSe?) perl modules. > > 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 > __________________________ > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
|
From: Alan W. I. <ir...@be...> - 2003-03-09 02:46:13
|
From Joao's recent post, his perl system cannot parse api.xml version 1.47 while my Debian woody perl system (and presumably Rafael's Debian testing system once he is back on line) can. The perl script doc/docbook/bin/api2text.pl has the following statements: use XML::Parser; use XML::DOM; so I am wondering if one of those perl modules is the source of Joao's problem parsing api.xml. From his previous post he has > perl-XML-DOM-1.39-24 > perl-XML-Parser-2.31-30 It is hard to correlate Debian packages (also RedHat packages) with perl module versions since the modules tend to be bundled in much bigger packages for both Debian and RedHat. For example, on RedHat perl-XML-DOM is part of the perl-libxml-enno-1.02-15 package. However, I did check CPAN, and the latest versions of these two modules are perl-XML-DOM-1.42 and perl-XML-Parser-2.31. So Joao, your perl-XML-Parser package seems up to date, but you probably need to upgrade to a later perl-XML-DOM and try again. One way to do that with CPAN is given below. I know virtually no perl, but I am beginning to experiment with the CPAN module to get the latest modules from CPAN. (RedHat rpm perl module support is incomplete. Although it is good enough to build the octave documention, it will be necessary to use CPAN to get the required modules for the complete documentation build.) You can figure out virtually everything you need to know by using man CPAN (especially the FAQ number 5 at the end: "I am not root, how can I install a module in a personal directory?" However, that FAQ is wrong in one key aspect. It recommends using (after you have invoked perl -MCPAN -e shell) o conf makepl_arg \ "LIB=~/myperl/lib \ INSTALLMAN1DIR=~/myperl/man/man1 \ INSTALLMAN3DIR=~/myperl/man/man3" You need to define the PREFIX as well (I found that out from a google search). Thus use instead: o conf makepl_arg \ "PREFIX=~/myperl \ LIB=~/myperl/lib \ INSTALLMAN1DIR=~/myperl/man/man1 \ INSTALLMAN3DIR=~/myperl/man/man3" After creating all these directories and setting PERL5LIB and MANPATH appropriately I found install MD5 install Bundle::CPAN install XML::DOM install XML::Parser all worked fine to install personal versions of these modules. (The last two are versions 1.42 and 2.31). The first two installs are to make sure MD5 sums are checked on download and to bootstrap to the latest version of the CPAN module. My initial impressions are the CPAN module is great for downloading and installing modules from CPAN, and I think it is probably the way to go if your Linux distribution has incomplete (RedHat) or out-of-date (SuSe?) perl modules. 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 __________________________ |
|
From: Joao C. <jc...@fe...> - 2003-03-08 23:14:09
|
On Saturday 08 March 2003 08:48, Rafael Laboissiere wrote: > Could one of you make me a favor and apply the patch below to api.xml? > Past night I had problems with my production workstation and I cannot > easily connect to the cvs server @ SF. Also, I am unable to check my > e-mail now (I am following plplot-devel at the Web interface, though). > > This patch fixes some typos and xml syntactical problems that have been > introduced recently. Hopefully, the building of the Octave documentation > will work now for everybody. > > I am just realizing that when Octave bindings building is enable, we must > check in configure.ac for the presence of some of the Perl modules. This > is done currently only for the DocBook documentation. > > Also, this last problem with api.xml makes me think that it is very > important that all developers could at least check for validity of the xml > code they cvs commit. For instance, one of the typos my patch below fixes > is a stupid '</setc1>' that should be '</sect1>'. > > Joao, I understand that you dislike DocBook, but could you please clarify > why? Because it's too verbose. Markup languages like latex are still managables, HTML is in the limit, XML it too much. I just don't understand what I wrote, specially when I'm reviewing my own writing. Perhaps that's OK for writing book chapters, or even manual sections, but I think that it is completely innadequate for the API section of our manual. I have the same feelings about the HTML page structure of our web site. Thinks could be better if *visual* editors would be available. That's why I use lyx most of the time, instead of plain latex; and mozilla visual HTML editor, when I can. And our docbook setup is too complex. If I *work* in a field that requires a complex setup, that's OK. But if I'm just a *user* of something, I want an express setup, otherwise I will try something else. > When you say that you are not going to "serve" this technology, what > do you mean exactly? Slavery. Machines are done to do services for mens, not the other way around. When I fell that I have to adapt myself in order to use a technology, then the technology was not done with attention to men's limitations. Or should I say, the tecnology was not devised for mens to use it, but only because of intellectual presumption. I think this is more a philosophical than a technical discussion. If I were a bit older I would be a hippy :) Joao |
|
From: Joao C. <jc...@fe...> - 2003-03-08 23:14:08
|
On Saturday 08 March 2003 19:37, Rafael Laboissiere wrote:
> * Alan W. Irwin <ir...@be...> [2003-03-08 08:46]:
> > Done. It solves the problem, but also highlights some dependency issues
> > that need to be fixed, see below.
>
> Thanks, Alan. I am still without network access to my email machine and I
> am replying essentially from the SF web interface. This problem should be
> fixed by Monday.
>
> This is for Joao: the next time you break one of the XML files, there is no
> problem at all, we can fix the bugs that you introduce. However, stop
> pestering about scripts that are not working anymore or about the DocBook
> system as a whole :-)
I sent the report *before* I made the modifications to api.xml.
And, as a matter of fact, after I cvs update, configure, etc:
[jcard@feup] cvs -f -z3 update -R -d -P .
[jcard@feup] cvs status doc/docbook/src/api.xml
===================================================================
File: api.xml Status: Up-to-date
Working revision: 1.47
Repository revision: 1.47
/cvsroot/plplot/plplot/doc/docbook/src/api.xml,v
[jcard@feup] ./bootstrap.sh && ./myconfig && make clean && make
...
mkdir -p plplot_octave_txt
cp etc/plplot.doc plplot_octave_txt/plplot.doc
cd plplot_octave_txt; \
../../../doc/docbook/bin/api2text.pl \
../../../doc/docbook/src/plplotdoc.xml.in \
../../../doc/docbook/src/api.xml
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
make[4]: *** [plplot_octave_txt/plplot.doc] Error 255
The fact that Alan can make it is (I think) only because he can also make the
documentation. I changed nothing in my system.
Joao
> > > I am just realizing that when Octave bindings building is enable, we
> > > must check in configure.ac for the presence of some of the Perl
> > > modules. This is done currently only for the DocBook documentation.
> >
> > I agree, but keep the list of modules to the absolute minimum required.
> > At the moment, there is no problem with generating the octave
> > documentation on RedHat with their standard perl modules, but if you ask
> > for anything more that is not needed to generate the octave
> > documentation, you probably won't be able to build octave on RH since
> > their perl module support is so minimal.
>
> I have been thinking about another idea: why do not include those .txt file
> in the tarbal, in a similar way we do for the swig and DocBook files? I
> can easily change the rules in bindings/octave/Makefile.am to achieve this,
> such that make dist will build this files previous to inclusion in the
> tarball. The neat implication is that, at the user's side, no perl module
> will be needed to build the Octave bindings.
>
> > Now to the dependency issue. I applied the patch and re-ran make, but
> > the perl script in question was not executed again unless I ran make
> > clean first. Here is the bad stanza from Makefile.am:
> >
> > [makefile rule removed]
> >
> > There are substantial dependency problems with this stanza. First, the
> > prerequisite list should include ../../../doc/docbook/bin/api2text.pl \
> > ../../../doc/docbook/src/plplotdoc.xml.in \
> > ../../../doc/docbook/src/api.xml. That is easy enough to put in and
> > solves the current dependency issue.
>
> Yes, this must be done.
>
> > However, I also notice the target list needs
> > an additional entry since api2text.pl generates a very large number of
> > *.txt files. I don't think we want to put those in the target list since
> > it would be a maintenance headache. However, could you make some sort of
> > timestamp file to be put in the target list that was updated *only if*
> > api2text.pl was a success? Without this time stamp, if you simply rerun
> > make after a syntax problem in api.xml, the make would go through without
> > any apparent problems. The only symptom would be the
> > plplot_octave_txt/*.txt files were not there or incomplete.
>
> Interesting: I just started some hours ago to make the changes in the
> Makefile.am in order to address exactly the two issues that you mention
> above. In general lines, it will work like this:
>
> if enable_octave
> # Yes the next addition to EXTRA_DIST must be inside the AM conditional
> EXTRA_DIST += doc-stamp
> # [...]
> doc-stamp: etc/plplot.doc \
> ${top_builddir}/doc/docbook/src/plplotdoc.xml.in \
> ${top_builddir}/doc/docbook/src/api.xml
> mkdir -p plplot_octave_txt
> cp etc/plplot.doc plplot_octave_txt/plplot.doc
> ( cd plplot_octave_txt; \
> ${top_builddir}/doc/docbook/bin/api2text.pl \
> ${top_builddir}/doc/docbook/src/plplotdoc.xml.in \
> ${top_builddir}/doc/docbook/src/api.xml ) \
> && touch doc-stamp
>
> (Notice that the doc-stamp file is created only if the api2txt.pl script
> suceeds.)
>
> I will commit this change when I will have access to my production machine
> again.
|
|
From: Rafael L. <ra...@de...> - 2003-03-08 19:38:15
|
* Alan W. Irwin <ir...@be...> [2003-03-08 08:46]:
> Done. It solves the problem, but also highlights some dependency issues
> that need to be fixed, see below.
Thanks, Alan. I am still without network access to my email machine and I
am replying essentially from the SF web interface. This problem should be
fixed by Monday.
This is for Joao: the next time you break one of the XML files, there is no
problem at all, we can fix the bugs that you introduce. However, stop
pestering about scripts that are not working anymore or about the DocBook
system as a whole :-)
> > I am just realizing that when Octave bindings building is enable, we must
> > check in configure.ac for the presence of some of the Perl modules. This is
> > done currently only for the DocBook documentation.
>
> I agree, but keep the list of modules to the absolute minimum required. At
> the moment, there is no problem with generating the octave documentation on
> RedHat with their standard perl modules, but if you ask for anything more
> that is not needed to generate the octave documentation, you probably won't
> be able to build octave on RH since their perl module support is so minimal.
I have been thinking about another idea: why do not include those .txt file
in the tarbal, in a similar way we do for the swig and DocBook files? I can
easily change the rules in bindings/octave/Makefile.am to achieve this, such
that make dist will build this files previous to inclusion in the tarball.
The neat implication is that, at the user's side, no perl module will be
needed to build the Octave bindings.
> Now to the dependency issue. I applied the patch and re-ran make, but the
> perl script in question was not executed again unless I ran make clean first.
> Here is the bad stanza from Makefile.am:
>
> [makefile rule removed]
>
> There are substantial dependency problems with this stanza. First, the
> prerequisite list should include ../../../doc/docbook/bin/api2text.pl \
> ../../../doc/docbook/src/plplotdoc.xml.in \
> ../../../doc/docbook/src/api.xml. That is easy enough to put in and solves
> the current dependency issue.
Yes, this must be done.
> However, I also notice the target list needs
> an additional entry since api2text.pl generates a very large number of *.txt
> files. I don't think we want to put those in the target list since it would
> be a maintenance headache. However, could you make some sort of timestamp
> file to be put in the target list that was updated *only if* api2text.pl was
> a success? Without this time stamp, if you simply rerun make after a syntax
> problem in api.xml, the make would go through without any apparent problems.
> The only symptom would be the plplot_octave_txt/*.txt files were not there
> or incomplete.
Interesting: I just started some hours ago to make the changes in the
Makefile.am in order to address exactly the two issues that you mention
above. In general lines, it will work like this:
if enable_octave
# Yes the next addition to EXTRA_DIST must be inside the AM conditional
EXTRA_DIST += doc-stamp
# [...]
doc-stamp: etc/plplot.doc \
${top_builddir}/doc/docbook/src/plplotdoc.xml.in \
${top_builddir}/doc/docbook/src/api.xml
mkdir -p plplot_octave_txt
cp etc/plplot.doc plplot_octave_txt/plplot.doc
( cd plplot_octave_txt; \
${top_builddir}/doc/docbook/bin/api2text.pl \
${top_builddir}/doc/docbook/src/plplotdoc.xml.in \
${top_builddir}/doc/docbook/src/api.xml ) \
&& touch doc-stamp
(Notice that the doc-stamp file is created only if the api2txt.pl script
suceeds.)
I will commit this change when I will have access to my production machine
again.
--
Rafael
|
|
From: Alan W. I. <ir...@be...> - 2003-03-08 16:46:29
|
On Sat, 8 Mar 2003, Rafael Laboissiere wrote: > Could one of you make me a favor and apply the patch below to api.xml? Done. It solves the problem, but also highlights some dependency issues that need to be fixed, see below. > > I am just realizing that when Octave bindings building is enable, we must > check in configure.ac for the presence of some of the Perl modules. This is > done currently only for the DocBook documentation. I agree, but keep the list of modules to the absolute minimum required. At the moment, there is no problem with generating the octave documentation on RedHat with their standard perl modules, but if you ask for anything more that is not needed to generate the octave documentation, you probably won't be able to build octave on RH since their perl module support is so minimal. Now to the dependency issue. I applied the patch and re-ran make, but the perl script in question was not executed again unless I ran make clean first. Here is the bad stanza from Makefile.am: plplot_octave_txt/plplot.doc: etc/plplot.doc mkdir -p plplot_octave_txt cp etc/plplot.doc plplot_octave_txt/plplot.doc cd plplot_octave_txt; \ ../../../doc/docbook/bin/api2text.pl \ ../../../doc/docbook/src/plplotdoc.xml.in \ ../../../doc/docbook/src/api.xml There are substantial dependency problems with this stanza. First, the prerequisite list should include ../../../doc/docbook/bin/api2text.pl \ ../../../doc/docbook/src/plplotdoc.xml.in \ ../../../doc/docbook/src/api.xml. That is easy enough to put in and solves the current dependency issue. However, I also notice the target list needs an additional entry since api2text.pl generates a very large number of *.txt files. I don't think we want to put those in the target list since it would be a maintenance headache. However, could you make some sort of timestamp file to be put in the target list that was updated *only if* api2text.pl was a success? Without this time stamp, if you simply rerun make after a syntax problem in api.xml, the make would go through without any apparent problems. The only symptom would be the plplot_octave_txt/*.txt files were not there or incomplete. 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 __________________________ |
|
From: Rafael L. <ra...@de...> - 2003-03-08 08:49:29
|
Could one of you make me a favor and apply the patch below to api.xml? Past night I had problems with my production workstation and I cannot easily connect to the cvs server @ SF. Also, I am unable to check my e-mail now (I am following plplot-devel at the Web interface, though). This patch fixes some typos and xml syntactical problems that have been introduced recently. Hopefully, the building of the Octave documentation will work now for everybody. I am just realizing that when Octave bindings building is enable, we must check in configure.ac for the presence of some of the Perl modules. This is done currently only for the DocBook documentation. Also, this last problem with api.xml makes me think that it is very important that all developers could at least check for validity of the xml code they cvs commit. For instance, one of the typos my patch below fixes is a stupid '</setc1>' that should be '</sect1>'. Joao, I understand that you dislike DocBook, but could you please clarify why? When you say that you are not going to "serve" this technology, what do you mean exactly? |
|
From: Alan W. I. <ir...@be...> - 2003-03-08 00:19:23
|
On Fri, 7 Mar 2003, Rafael Laboissiere wrote: > * Joao Cardoso <jc...@fe...> [2003-03-07 09:18]: > Unless I gain access to a system similar to your, there is very little I can > do through e-mail. I confirm the bug on my Debian system: Clean checkout, nothing unusual about bootstrap.sh, ./configure --prefix=/usr/local/plplot_at --enable-java --enable-gnome (I don't think anything is relevant here except a non-standard prefix is used and lack of --enable-doc). make .... cp BUGS BUGS.octave cp INSTALL INSTALL.octave cp FGA FGA.octave cp ToDo ToDo.octave cp USAGE USAGE.octave cp README README.octave mkdir -p plplot_octave_txt cp etc/plplot.doc plplot_octave_txt/plplot.doc cd plplot_octave_txt; \ ../../../doc/docbook/bin/api2text.pl \ ../../../doc/docbook/src/plplotdoc.xml.in \ ../../../doc/docbook/src/api.xml mismatched tag at line 1929, column 8, byte 61833 at /usr/lib/perl5/XML/Parser.p m line 185 make[4]: *** [plplot_octave_txt/plplot.doc] Error 255 make[4]: Leaving directory /home/software/plplot_cvs/HEAD/plplot_working/bindin gs/octave' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory /home/software/plplot_cvs/HEAD/plplot_working/bindin gs/octave' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory /home/software/plplot_cvs/HEAD/plplot_working/bindin gs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory /home/software/plplot_cvs/HEAD/plplot_working' make: *** [all] Error 2 Rafael, to confirm the bug on your own system, I suggest you try a clean checkout and use a configure with a non-standard prefix and no --enable-docbook. 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 __________________________ |
|
From: Rafael L. <lab...@ps...> - 2003-03-07 22:11:50
|
* Joao Cardoso <jc...@fe...> [2003-03-07 09:18]: > Yes, of course, as you can generate the documentation you can parse > api.xml. As I can't generate the documentation (I'm a regular user in > this context), I can't parse api.xml. But you wrote that api2text.pl worked for you before and it is not working anymore. So, even if you could never build the documentation, you could use that script (which you have adapted from api2man.pl). If things were working for you before and are not working anymore, I see only two explanations: either something changed in your system regarding the Perl installation or changes were introduced in the doc/docbook directory that makes the parsing stop for you. The only things that I changed recently under that directory was the file api.xml itself and some of the Makefile.am. The error message you are getting: > undefined entity at line 2858, column 62, byte 84237 at > /usr/lib/perl5/site_perl > /5.8.0/i586-linux-thread-multi/XML/Parser.pm line 185 makes me think that the api.xml file is ill-formed, but this is not the case, since I can parse/validate it here correctly. > I don't know what info to give you other then the error message and the > perls that I have installled. > > But notice that I have installed almost all from perl with something > like xml/sgml in its name, and in this respect I'm not a regular user, > as I believe that most systems don't have this all. As you wrote, the list of Perl modules installed in your system is of little help for me. You are apparently using the same versions I am using here. I am puzzled. Unless I gain access to a system similar to your, there is very little I can do through e-mail. -- Rafael |
|
From: <jc...@fe...> - 2003-03-07 17:49:23
|
Hi, I have updated/changed/added some API entries in api.xml. PLEASE review the changes, which are in: plenv, plenv0, plclear, plgriddata, plmesh, plmeshc, plot3d, plot3dc, plsurf3d. plotsh3d was deleted. I'm not sure that I haven't mess anything. If I have, and it is severe, please just revert to the previous cvs version. I promise that I will not write more documentation in docbook format. I like new technologies if, besides being nice, elegant and usefull, they serve me; I will not use them if I have to serve them. Sorry for the bad temper, Joao |
|
From: <jc...@fe...> - 2003-03-07 17:18:02
|
On Friday 07 March 2003 15:59, Rafael Laboissiere wrote: | * Jo=E3o Cardoso <jc...@fe...> [2003-03-07 15:26]: | > Hi, | > | > I got the following error with a clean cvs. | > | > ... | > mkdir -p plplot_octave_txt | > cp etc/plplot.doc plplot_octave_txt/plplot.doc | > cd plplot_octave_txt; \ | > ../../../doc/docbook/bin/api2text.pl \ | > ../../../doc/docbook/src/plplotdoc.xml.in \ | > ../../../doc/docbook/src/api.xml | > | > undefined entity at line 2858, column 62, byte 84237 at | > /usr/lib/perl5/site_perl | > /5.8.0/i586-linux-thread-multi/XML/Parser.pm line 185 | > make[4]: *** [plplot_octave_txt/plplot.doc] Error 255 | > | > | > I never was able to build the docbook documentation, but there was | > no problem in running the scripts that generated the online Octave | > docs. | | It works fine here. Yes, of course, as you can generate the documentation you can parse=20 api.xml. As I can't generate the documentation (I'm a regular user in=20 this context), I can't parse api.xml. I may be wrong when I say "parse the api.xml", but when I say that I'm a=20 regular user in this context I'm right :( | I need more information in order to understand where your bug comes=20 from. I don't know what info to give you other then the error message and the=20 perls that I have installled. But notice that I have installed almost all from perl with something=20 like xml/sgml in its name, and in this respect I'm not a regular user,=20 as I believe that most systems don't have this all. [jcard@feup] rpm -qa | fgrep perl perl-gettext-1.01-310 perl-XML-Generator-0.91-42 perl-CDDB_get-2.10-38 perl-SNMP-4.2.0-312 perl-HTML-Tagset-3.03-285 perl-Parse-RecDescent-1.80-18 perl-Tie-IxHash-1.21-317 perl-PDA-Pilot-0.8.0-311 perl-GnuPG-0.07-299 perl-URI-1.20-30 perl-HTML-Parser-3.26-29 perl-XML-DOM-1.39-24 mod_perl-1.27-31 perl-libwww-perl-5.65-29 perl-5.8.0-45 perl-Tk-800.024-40 perl-XML-Parser-2.31-30 perl-IO-Socket-SSL-0.81-22 perl-DateManip-5.40-232 perl-Parse-Yapp-1.05-134 perl-SGMLS-1.03ii-128 perl-Unicode-String-2.06-212 perl-XML-RegExp-0.03-216 perl-XML-Simple-1.08-33 perl-XML-Writer-0.4-234 perl-libxml-perl-0.07-219 perl-XML-Stream-1.15-20 perl-XML-XSLT-0.40-15 perl-XML-XQL-0.67-33 perl-Net_SSLeay-1.18-44 Joao |
76 messages has been excluded from this view by a project administrator.
