Menu
▾
▴
plplot-devel
|
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 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: 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: 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: Alan W. I. <ir...@be...> - 2003-03-11 17:15:50
|
On Sun, 9 Mar 2003, Alan W. Irwin wrote: > 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. Rafael and I finally found the cause of this problem. Upgrading the sgml tools installed on my machine increased my docbook configuration speed by literally a factor of 30! So once the rest of you are starting to try documentation builds, be careful of this tool version issue. I will eventually document in README.developers the minimum recommended versions of everything. 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-11 17:35:28
|
* Alan W. Irwin <ir...@be...> [2003-03-11 09:14]: > Rafael and I finally found the cause of this problem. Upgrading the sgml > tools installed on my machine increased my docbook configuration speed by > literally a factor of 30! I am relieved. Waiting for your next 30 GHz workstation would take way too long... :-) -- Rafael |
|
From: Joao C. <jc...@fe...> - 2003-03-15 23:28:02
|
On Tuesday 11 March 2003 17:14, Alan W. Irwin wrote: > On Sun, 9 Mar 2003, Alan W. Irwin wrote: > > 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. > > Rafael and I finally found the cause of this problem. Upgrading the sgml > tools installed on my machine increased my docbook configuration speed by > literally a factor of 30! Is this the only issue? From what I understand, if one supplies to configure a catalog focused on the needed DTDs, the search will be faster; if by contrary the catalog has many entries and the required ones are at the end, the search will be slower. I'm right? Joao > So once the rest of you are starting to try > documentation builds, be careful of this tool version issue. I will > eventually document in README.developers the minimum recommended versions > of everything. > > Alan |
|
From: Alan W. I. <ir...@be...> - 2003-03-16 01:12:31
|
On Sat, 15 Mar 2003, Joao Cardoso wrote: > On Tuesday 11 March 2003 17:14, Alan W. Irwin wrote: > > Rafael and I finally found the cause of this problem. Upgrading the sgml > > tools installed on my machine increased my docbook configuration speed by > > literally a factor of 30! > > Is this the only issue? From what I understand, if one supplies to configure a > catalog focused on the needed DTDs, the search will be faster; if by contrary > the catalog has many entries and the required ones are at the end, the search > will be slower. I'm right? I think yes, but it may not be worth going to this extra trouble if you have a good version of openjade to start with. In my case, the default openjade for woody actually turned out to be a development version (1.4devel1-8) that lead to 5-minute catalog searches. (Rafael confirmed these long times when he experimentally installed that version as well. BTW, Rafael, have you made a bug report about that?) When I installed an older version (openjade1.3) that search is reduced to a few seconds. I think you are right and you could get even smaller search times than that by making your own catalog, but it is probably not worth it if you already have a version of openjade that can do fast system catalog searches. 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-16 12:37:32
|
* Alan W. Irwin <ir...@be...> [2003-03-15 17:11]:
> I think yes, but it may not be worth going to this extra trouble if you have
> a good version of openjade to start with. In my case, the default openjade
> for woody actually turned out to be a development version (1.4devel1-8) that
> lead to 5-minute catalog searches. (Rafael confirmed these long times when
> he experimentally installed that version as well. BTW, Rafael, have you
> made a bug report about that?)
Somebody has already done it exactly one year ago:
http://bugs.debian.org/138924
--
Rafael
|
|
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: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: <jc...@fe...> - 2003-03-10 20:12:12
|
On Sunday 09 March 2003 14:19, Rafael Laboissiere wrote: | 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. You was right! No joking :) (how do you read this?) | 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. Well, I don't have a choice, do I? You are not changing the docs back to latex, nor using MS-word, right? I'm joking here? | 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". aahhh, you agree! But syntax highlighting is not enough for me. I also use Xemacs, but I don't use emacs/w3 for web browsing -- do you? As a mater of fact I'm surprised you don't use Emacs -nw. I'm fully joking :) I have a fellow colleague who does porogramming in Postscript! In a text editor, of course. He says that it's easier for him to "see" a postscript picture included in Latex that looking at it under lyx! ... | 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... Was you? what half of the joke? Joao ::::))))) |
|
From: Rafael L. <lab...@ps...> - 2003-03-10 20:57:59
|
* João Cardoso <jc...@fe...> [2003-03-10 20:11]: > | 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". > > aahhh, you agree! But syntax highlighting is not enough for me. I also > use Xemacs, but I don't use emacs/w3 for web browsing -- do you? No, but compare things that are comparable. IMHO, w3 is a rather poor piece of software, because the overload of lisp. But have you tried links (_not_ lynx)? To come back to the subject, PSGML mode in (X)Emacs is not only about syntax highlighting. It does DTD parsing, can check syntax and insert closing targets, has a nice menu that can propose tags to insert (based on the parsed DTD) and many things more. I cannot imagine how to edit XML files without this emacs mode. > As a mater of fact I'm surprised you don't use Emacs -nw. I'm fully > joking :) I am right now using jed to compose this email (mutt is my MUA). I do use console based tools from time to time :-) -- Rafael |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X