John Maddock wrote: > Paul A Bristow wrote: >>> > Personally I have no problems with QuickBook being in C++. A >>> > non-"appreciable" slowdown might be fine for the uses you >>> are thinking >>> > of, but some uses I want to put QuickBook to a small >>> slowdown will be >>> > appreciable. What really aggravates me about the doc chain is the >>> > boostbook+docbook+xslt stage. It's horrible slow and >>> extremely fragile. >> Well I agree that the error messages mean sometimes it is hard to >> find the real cause, >> but John Maddock and I are building the maths & stats docs which >> should eventually result in towards 200 pages of pdf (John's having >> some rpoblems with the conversion to pdf but that's another matter. >> >> Building the html only takes about 15 seconds which seems acceptable >> for the sort of job for which it is designed. > > I agree it's not too bad: and using the native Win32 build of xsltproc > produces more reliable and much faster builds than a cygwin build I was > using before (or at least that's my subjective impression). > > The main problem is the tracking down of errors, these either: > > 1) Don't cause quickbook to complain, but do generate invalid XML that > xsltproc rejects. > 2) Cause a quickbook error in the wrong place. > > As an example of the latter, Paul did a machine translation of the HTML > symbols this morning that ended up having some stray []'s in it. Quickbook > didn't complain until it tried to parse a table way down in the docs. I > think I've got reasonably proficient at tracking these down now, but a much > stricter gammer parser would be most welcome :-) Of course good error > messages are *hard* as most compiler vendors would probably attest too!
The context sensitive nature of markups/code/paragraphs make it difficult. If unmatched []'s are common, as I think they are, then I could do a first pass over a block to check for these. That way, we can be assured that an unmatched block does not have any stray []'s. I'm basically just adding more checks and more error messages as I encounter them. If you have any of those lurking, then, by all means, give them to me. QuickBook has a fairly robust regression testing facility. The testing facility makes me sleep well at night. Right now, they are rigged up to test correct qbk. It should also make sense to make them test improper code. As always, a minimal reproducable code (qbk) snippet goes a long way towards making Qbk as robust as possible. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
