Documentation Redux (was Re: Boost 1.36.0 release notice)
On Mon, Aug 18, 2008 at 4:17 PM, John Maddock <john@johnmaddock.co.uk> wrote:
Robert Ramey wrote:
LOL - of course it does. If regression testing were setup for boost tools, they would be demonstrated to be functioning as expected before they were used in the actual release process. Had this been procedure been in place, the issue raised above would not have occurred.
This is a good point, in fact is there any reason why the doc build shouldn't be part of the regression tests?
Ah.... but it requires external tools that might not be available (especially now that accumulators has introduced a dependency on Latex and Ghostscript) :-(
I think this may be something that should be solved by policy rather than technical solutions. For instance, libraries follow a certain set of guidelines regarding how the code is organized (namespaces, macro names, type names, directory structure, directory naming, etc.). Why shouldn't there be guidelines regarding the documentation of these libraries? I know the guidelines are minimal by design (for example should be in HTML and/or PDF) but right now it's getting quite unwieldy -- and arguably, the documentation is becoming as important as the actual code is. I understand that documentation is largely an author/maintainer domain, and that currently the choice of documentation tools used is left to the author/maintainer. If we can somehow standardize on a tool set and help authors/maintainers convert their documentation from their current format to another then maybe we can make some progress regarding fixing the documentation-building/generation process and "improvement" of the library documentation. This also allows interested contributors to (more easily) learn the tools required and help out in the "improvement" of the documentation effort. Traditionally, Wiki's have worked well for other projects. Should Boost start doing this too, and just export documentation from the Wiki into properly cross-linked HTML pages in release builds? I understand Trac has the Wiki functionality already available -- should we start using it for documentation? Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain). Quickbook is also a nice documentation language to use, but the reliance on Boostbook+XSLT makes it harder to pull-off. I don't know though if Quickbook can be made to generate HTML directly instead of XML. Joel? I understand there's also a Boost Documentation project. Anything happening in that front? [0] - http://docutils.sourceforge.net/rst.html -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
2008/8/18 Dean Michael Berris <mikhailberis@gmail.com>:
Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain).
We haven't a single problem with boostbook or xslt. It's actually quite stable. The problems have been with boost build, quickbook (possibly due to Spirit), doxygen and latex. Basically everything but boostbook. Most of the problems seem to involve poor support for windows. I've been testing on linux which is why they weren't discovered sooner. Daniel
Daniel James wrote:
2008/8/18 Dean Michael Berris <mikhailberis@gmail.com>:
Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain).
We haven't a single problem with boostbook or xslt. It's actually quite stable. The problems have been with boost build, quickbook (possibly due to Spirit), doxygen and latex. Basically everything but boostbook. Most of the problems seem to involve poor support for windows.
And even on Windows the doc build process has been mostly trouble-free. The only reason the doc build was such an upset 1.36.0 was that a breakage was detected very late in the release process. So I really don't think we should be talking about major changes. It should be sufficient (1) quickly fixing the current bug (which the docs folks are already working on), and (2) tweaking the process to make sure doc build failures are detected much earlier in a release cycle. The "big bang" major change we need is to get CMake based building, testing, and reporting working well enough to use in production work. IIUC, that project is making lots of progress with building and testing, but hasn't really gotten into reporting yet. So rather than spend a lot of energy in a long discussion here, it would be better IMO if the Boost brainpower dusted off their SQL skills, and started working on report generation and query for the CMake based testing system. Meanwhile those of us working on release management will keep churning out quarterly releases! --Beman
On Mon, Aug 18, 2008 at 10:49 PM, Beman Dawes <bdawes@acm.org> wrote:
Daniel James wrote:
2008/8/18 Dean Michael Berris <mikhailberis@gmail.com>:
Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain).
We haven't a single problem with boostbook or xslt. It's actually quite stable. The problems have been with boost build, quickbook (possibly due to Spirit), doxygen and latex. Basically everything but boostbook. Most of the problems seem to involve poor support for windows.
And even on Windows the doc build process has been mostly trouble-free. The only reason the doc build was such an upset 1.36.0 was that a breakage was detected very late in the release process. So I really don't think we should be talking about major changes. It should be sufficient (1) quickly fixing the current bug (which the docs folks are already working on), and (2) tweaking the process to make sure doc build failures are detected much earlier in a release cycle.
Just a thought: If building docs in windows for the release is a pain (like most of the time I try it with the Boost.Build+Boostbook+XSLT toolchain), shouldn't we just generate the documentation in Linux and offer that as a separate download (or packaged with every new release)? And would it hurt to have a documentation-only, source/header-only, and combined package available from sourceforge?
The "big bang" major change we need is to get CMake based building, testing, and reporting working well enough to use in production work. IIUC, that project is making lots of progress with building and testing, but hasn't really gotten into reporting yet. So rather than spend a lot of energy in a long discussion here, it would be better IMO if the Boost brainpower dusted off their SQL skills, and started working on report generation and query for the CMake based testing system. Meanwhile those of us working on release management will keep churning out quarterly releases!
The discussion I was actually looking for is more on policy (but apparently the technology part of my post got more attention) regarding library documentation. The technology is the easy part to address -- we can always get better tools -- but one recurring theme in discussions about documentation problems (in generating the docs) is the lack of consistency/coherence/singularity with regards to not only the look/feel of the documentation, but also with the presentation both aesthetically (admonitions, images, indentation, etc.) and structurally (w/ or w/o quickstart, reference documentation format, etc.). Right now each library has its own structure as far as documentation goes -- and people can use whatever tools they want/need (like LaTeX recently) to generate them. We can standardize on the tools fine, but I guess the bigger question really is having guidelines (or templates, if it's more appropriate) as to what each document contains, how certain presentations have to be made (like mention the header in which a function/class/template can be found, etc.), and what the structure of every library documentation package should look like (Introduction, Tutorial, Reference, Rationale, Design, etc.). So one part of me says I agree with you Beman about getting to the work that actually needs to be done regarding testing and reporting, while another part of me says I'd like to be part of a solution to make library documentation more coherent and more consistent across the board. Part of that other conversation I'm looking forward to is what tools we may have to standardize on to actually pull it off, but if people feel that's a conversation that should happen later than sooner (if ever) then that's fine by me. :) Thanks for the attention, and I look forward to your thoughts. :) -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Dean Michael Berris wrote:
Just a thought: If building docs in windows for the release is a pain (like most of the time I try it with the Boost.Build+Boostbook+XSLT toolchain), shouldn't we just generate the documentation in Linux and offer that as a separate download (or packaged with every new release)? And would it hurt to have a documentation-only, source/header-only, and combined package available from sourceforge?
I think this is an excellent suggestion. What about having a single christened platform be responsible for the generation of a 'Golden' source tarball which everything else is then built from. This source tarball could contain generated docs, so as far as that process is concerned, you don't have to be as portable as if this was to be run on every platform where boost is tested on. Comments ? Stefan -- ...ich hab' noch einen Koffer in Berlin...
Daniel James wrote:
2008/8/18 Dean Michael Berris <mikhailberis@gmail.com>:
Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain).
We haven't a single problem with boostbook or xslt. It's actually quite stable. The problems have been with boost build, quickbook (possibly due to Spirit), doxygen and latex. Basically everything but boostbook. Most of the problems seem to involve poor support for windows. I've been testing on linux which is why they weren't discovered sooner.
I changed the subject to emphasize that my point isn't about boost book but rather boost tools. I picked boost book as an example in part because I didn't remember who was responsable for it. But this illustrates the heart of my proposal. Let suppose that the following tools each had its own test suite, library, review, etc. - the whole boost process. Here is what we would have boost/ /tools /bjam /boostbuild (depends upon bjam) /boostbook (depends upon fop, doxygen, docbook and ?) /quickbook (depends upon boostbook, and spirit) Now how would things look now? a) testing on windows would be done - it couldn't be avoided! b) "Getting Started: would look a lot different. toos/bjam would contain the documentation for bjam. and boostbuild would probably contain the rest of it. c) The bjam tests would not depend on all the *.jam files testing of boostbuild (all the *.jam) files would be run whenever bjam was recompiled c) boostbuild would be tested independently of quickbook. I know this would be helpful because I believe that docbook has evolved somewhat. d) quick book would be either tested independently or if that isn't possible, it would be tested if and only if boostbook tests passed. Actually, I know that lots of stuff is sprinkled around the directories already. So a lot of it would be just moving things around. Here are a number of other advantages a) I loaded my amended "Library Status" into the directory which contains "compiler status" because that was a logical place. Its looked good on my windows and gcc compilers but crashed the whole boost test process on certain compilers. Further, this tool wasn't subjected to any kind of boost review process. Is this a good idea? Application of the "boost process" would permit ideas for tools to be subjected to wider scrutiny and improve quality. b) As noted above, it would be alot easier to find the source of bugs. c) It would more clearly delineate responsability. That is the author of bjam wouldn't necessarily get sucked in to issues related to errors in the creation of Jamfiles - unless he want's to. d) Documentation would be more logical and easier to maintain. The "Getting Started" guide is an example. It's a heroic effort and quite well written. But by trying to cover bjam and boost build together, it's less clear than it could be. It's also much harder to maintain since it covers such a wide territory in the area of responsability of various persons. By factoring the boost toolset in smaller more orthogonal pieces, efforts such as the "Gettings Started Guide" would be more productive and more easily divided amongst several people. e) It would improve tool usability and range of application. There are two ways of looking at bjam. The first is "Key part of the boost build system". The second is "The next/great 'make'". I believe that it's currently thought of as the former - which leads to tight coupling with Jamfiles in boostbuild. If it were looked at as the latter, it might be of wider use, this would benefit the author with the exposure he deserves and lead to a higher quality better defined, and tested product. In short, applying the "boost process" to boost tools as well as boost libraries would lead to a similar set of benefits. In the above, I've used examples from bjam, boost book etc. Truth is I don't know the exact current state of all these tools so I maybe wrong on some of the details or my examples may not be the ideally suited to make my point. If that's the case - I'm sorry about that. But, my proposal remains: The "boost process" for libraries is effective in producing better libraries and diminishing wasted effort. Application of the same process to boost tools would be expected to achieve comparable results. Robert Ramey
On Mon, Aug 18, 2008 at 6:02 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
2008/8/18 Dean Michael Berris <mikhailberis@gmail.com>:
Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain).
We haven't a single problem with boostbook or xslt. It's actually quite stable. The problems have been with boost build, quickbook (possibly due to Spirit), doxygen and latex. Basically everything but boostbook. Most of the problems seem to involve poor support for windows. I've been testing on linux which is why they weren't discovered sooner.
Actually, not having access to a proper xslt implementation in Windows is the big problem with boostbook+xslt. Another is the relatively harder-to-maintain format that is XSLT -- I mean honestly, does anybody even _like_ reading/writing XSLT? This leads to the questions like: if we somehow wanted to change the structure of an HTML page generated by the documentation tools or add certain (new) page elements? We'd then have XSLT to deal with which is just hard to test, hard to maintain, and hard to understand. I understand though that having something like Django template support for our documentation might be too ambitious instead of using XSLT to generate static pages, then something like RST (or quickbook that generates straight HTML) might be more manageable. Then again there's the problem with Windows and XSLT which makes it brittle. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
on Mon Aug 18 2008, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
On Mon, Aug 18, 2008 at 6:02 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
2008/8/18 Dean Michael Berris <mikhailberis@gmail.com>:
We haven't a single problem with boostbook or xslt. It's actually quite stable. The problems have been with boost build, quickbook (possibly due to Spirit), doxygen and latex. Basically everything but boostbook. Most of the problems seem to involve poor support for windows. I've been testing on linux which is why they weren't discovered sooner.
Actually, not having access to a proper xslt implementation in Windows is the big problem with boostbook+xslt. Another is the relatively harder-to-maintain format that is XSLT -- I mean honestly, does anybody even _like_ reading/writing XSLT?
This leads to the questions like: if we somehow wanted to change the structure of an HTML page generated by the documentation tools or add certain (new) page elements? We'd then have XSLT to deal with which is just hard to test, hard to maintain, and hard to understand. I understand though that having something like Django template support for our documentation might be too ambitious instead of using XSLT to generate static pages, then something like RST (or quickbook that generates straight HTML) might be more manageable.
Then again there's the problem with Windows and XSLT which makes it brittle.
Whatever else happens, I think having an intermediate representation that is DocBook is important because of all the tools that can process it. Don't forget that we probably want to generate PDF among other things. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Mon Aug 18 2008, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain).
Quickbook is also a nice documentation language to use, but the reliance on Boostbook+XSLT makes it harder to pull-off. I don't know though if Quickbook can be made to generate HTML directly instead of XML. Joel?
We could "easily" build a python-based BoostBook/DocBook -> xxx converter. What I'd actually do, though, is transform BoostBook/DocBook into docutils' internal format, then feed that into docutils and use its already-written backend writers to generate whatever xxx we chose ;-). -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Mon Aug 18 2008, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain).
Quickbook is also a nice documentation language to use, but the reliance on Boostbook+XSLT makes it harder to pull-off. I don't know though if Quickbook can be made to generate HTML directly instead of XML. Joel?
We could "easily" build a python-based BoostBook/DocBook -> xxx converter. What I'd actually do, though, is transform BoostBook/DocBook into docutils' internal format, then feed that into docutils and use its already-written backend writers to generate whatever xxx we chose ;-).
If we were to explore that path, http://sphinx.pocoo.org might be of interest. It's a documentation framework built on docutils, that could give us a uniform look and feel, plus cross referencing. Seems geared toward Python, but I'm sure it could be extended with whatever docnodes we could need. -- Daniel Wallin BoostPro Computing http://www.boostpro.com
Daniel Wallin wrote:
David Abrahams wrote:
on Mon Aug 18 2008, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
Another option (that I think Dave Abrahams has been doing) is to use RST [0] to make writing/reading the source documentation easier than having to rely on Boostbook+XSLT (which I personally think is a brittle tool-chain).
Quickbook is also a nice documentation language to use, but the reliance on Boostbook+XSLT makes it harder to pull-off. I don't know though if Quickbook can be made to generate HTML directly instead of XML. Joel?
We could "easily" build a python-based BoostBook/DocBook -> xxx converter. What I'd actually do, though, is transform BoostBook/DocBook into docutils' internal format, then feed that into docutils and use its already-written backend writers to generate whatever xxx we chose ;-).
If we were to explore that path, http://sphinx.pocoo.org might be of interest. It's a documentation framework built on docutils, that could give us a uniform look and feel, plus cross referencing. Seems geared toward Python, but I'm sure it could be extended with whatever docnodes we could need.
As a user, I would prefer the OP's suggestion of using the Trac wiki. Then only the server would need the LaTeX plug in configured. Plus Trac already has a plug in available to include the output of Doxygen, and a wiki processor for RST and Docbook. --John
John C. Femiani wrote:
Daniel Wallin wrote:
If we were to explore that path, http://sphinx.pocoo.org might be of interest. It's a documentation framework built on docutils, that could give us a uniform look and feel, plus cross referencing. Seems geared toward Python, but I'm sure it could be extended with whatever docnodes we could need.
As a user, I would prefer the OP's suggestion of using the Trac wiki.
As a developer, editing documentation in a wiki is horrible. In fact, IIRC, even the trac project itself is moving away from having the docs in the wiki.
Then only the server would need the LaTeX plug in configured.
That's true for whatever solution we use. -- Daniel Wallin BoostPro Computing http://www.boostpro.com
Daniel Wallin wrote:
As a user, I would prefer the OP's suggestion of using the Trac wiki.
As a developer, editing documentation in a wiki is horrible.
Violent agreement here. How would I integrate MathML/SVG/PNG equations into a Wiki is just one of many questions that springs to mind? John.
John Maddock wrote:
Daniel Wallin wrote:
As a user, I would prefer the OP's suggestion of using the Trac wiki.
As a developer, editing documentation in a wiki is horrible.
Violent agreement here.
How would I integrate MathML/SVG/PNG equations into a Wiki is just one of many questions that springs to mind?
John.
Using the appropriate wiki processor... [[Image(eqn1.png)]] (with eqn1.png as an attachment) As I said, a number of wiki processors are available for Trac already, including Latex and RST (and I think docbook) --John
Daniel Wallin wrote:
Quickbook is also a nice documentation language to use, but the reliance on Boostbook+XSLT makes it harder to pull-off. I don't know though if Quickbook can be made to generate HTML directly instead of XML. Joel?
We could "easily" build a python-based BoostBook/DocBook -> xxx converter. What I'd actually do, though, is transform BoostBook/DocBook into docutils' internal format, then feed that into docutils and use its already-written backend writers to generate whatever xxx we chose ;-).
If we were to explore that path, http://sphinx.pocoo.org might be of interest. It's a documentation framework built on docutils, that could give us a uniform look and feel, plus cross referencing. Seems geared toward Python, but I'm sure it could be extended with whatever docnodes we could need.
Guys, before we get too carried away, please be aware that some of us are already generating very nice html and PDF docs from Docbook thankyou very much, and already have a significant investment in quickbook templates that output raw Docbook. Unless you're planning on supporting the entire Docbook DTD, complete with at least the same amount of flexibility and configuration as the Docbook XSLT toolchain has, then I don't see an advantage, just a whole ton of work trying to convert to yet another format :-( What we really should do (and I suspect could be done quite easily) is: 1) Split the build so that building the docs for library X *only* builds the docs for lib X, and so that building from /libs/X/doc has *exactly* the same effect as building from /doc/. In other words build multiple "books" rather than trying (and mostly failing) to build one big "book". 2) Have the doc build automatically invoke the inspect program over the generated docs - to catch for broken links etc, hopefully this should eliminate most of the "partial build" problems. 3) Add the doc build for each library to the tests. 4) The only drawback I see, is the difficulty of one library linking/referencing to another, I guess it would be possible to generate a Docbook file containing just the link URL's to all the libraries sections that could be included and referenced? Don't know if it's worth the hassle though? Unfortunately most of the above represent Boost.Build changes :-( John.
John Maddock wrote:
Daniel Wallin wrote:
Quickbook is also a nice documentation language to use, but the reliance on Boostbook+XSLT makes it harder to pull-off. I don't know though if Quickbook can be made to generate HTML directly instead of XML. Joel?
We could "easily" build a python-based BoostBook/DocBook -> xxx converter. What I'd actually do, though, is transform BoostBook/DocBook into docutils' internal format, then feed that into docutils and use its already-written backend writers to generate whatever xxx we chose ;-).
If we were to explore that path, http://sphinx.pocoo.org might be of interest. It's a documentation framework built on docutils, that could give us a uniform look and feel, plus cross referencing. Seems geared toward Python, but I'm sure it could be extended with whatever docnodes we could need.
Guys, before we get too carried away, please be aware that some of us are already generating very nice html and PDF docs from Docbook thankyou very much, and already have a significant investment in quickbook templates that output raw Docbook. Unless you're planning on supporting the entire Docbook DTD, complete with at least the same amount of flexibility and configuration as the Docbook XSLT toolchain has, then I don't see an advantage, just a whole ton of work trying to convert to yet another format :-(
What we really should do (and I suspect could be done quite easily) is:
1) Split the build so that building the docs for library X *only* builds the docs for lib X, and so that building from /libs/X/doc has *exactly* the same effect as building from /doc/. In other words build multiple "books" rather than trying (and mostly failing) to build one big "book".
How exactly is it different from what we have now?
2) Have the doc build automatically invoke the inspect program over the generated docs - to catch for broken links etc, hopefully this should eliminate most of the "partial build" problems. 3) Add the doc build for each library to the tests. 4) The only drawback I see, is the difficulty of one library linking/referencing to another, I guess it would be possible to generate a Docbook file containing just the link URL's to all the libraries sections that could be included and referenced? Don't know if it's worth the hassle though?
Unfortunately most of the above represent Boost.Build changes :-(
(3) is trivial, but it requires that everybody who runs tests has docbook installed -- do you want it? (2) is some work, but not very much. But -- do we actually need to run inspect program for *all* test runs. After all, doc build is fairly platform-independent, there's no point to test docs on all platforms and compilers. - Volodya
Vladimir Prus wrote:
1) Split the build so that building the docs for library X *only* builds the docs for lib X, and so that building from /libs/X/doc has *exactly* the same effect as building from /doc/. In other words build multiple "books" rather than trying (and mostly failing) to build one big "book".
How exactly is it different from what we have now?
Currently the docs for a number of libraries are built as a single "book" from within /doc/ it takes a rediculous amount of time to build, and the results when you build from /doc/ are quite different from when you build from /libs/X/doc. It's also not possible to tweek the XSLT params for your specific library when using this method. As a result several libraries have split away from this centralised build (including Boost.Math). Decentralising things would speed up building and testing docs for a specific library no end, changes to one library would no longer break the whole process, and the process would be just so much more scalable.
(3) is trivial, but it requires that everybody who runs tests has docbook installed -- do you want it?
Can we rig things so that the documentation "test" is only run if the required tools are present in user-config.jam? I'm assuming the incremental builds would actually only need to rebuild these quite infrequently anyway. At the very least a regular test build on Win32 and Linux would have spotted the problems Beman had with this release much earlier (and alerted the appropriate developers).
(2) is some work, but not very much. But -- do we actually need to run inspect program for *all* test runs. After all, doc build is fairly platform-independent, there's no point to test docs on all platforms and compilers.
All platforms yes, all compilers no maybe not. The objective is to verify that the build proceded correctly, with no missing components. Currently we have a situation where some things that should be errors aren't treated as such by the tools used: for example if Latex/Ghostscript are missing the accumulators docs will be lacking equations, but the build will "apparently" succeed, because Doxygen doesn't report this as a fatal error, just a warning :-( It's maybe questionable whether the a general build like this should be dependent on those tools, but there are other situations where Doxygen appears not to report errors as such as well. Checking the result with the inspect program would catch these failures I believe. Again if the "test" can just be skipped if the necessary tools (boostbook, doxygen etc) aren't configured that would probably address most of the concerns? Cheers, John.
John Maddock wrote:
4) The only drawback I see, is the difficulty of one library linking/referencing to another, I guess it would be possible to generate a Docbook file containing just the link URL's to all the libraries sections that could be included and referenced? Don't know if it's worth the hassle though?
I have done exactly that on other docbook based documentation. But I think the primary goal then was to allow XML validation of idref --> id consistency without pulling in the whole project. It worked Ok and I think it was a simple XSL script that pulled out all the tags with id and some minimal context such as related titles into a small index file for each section. Then each section used a dummy wrapper referring all those indexes rather then the real sections surrounding it. The generated index was also useful for work in tools like XMLMind or OXygen which provide nice author features for those allergic to XML text. If you generate your document with the stub, all your links to other sections take you into the index of that section. For external url based links the same approach may be useful, but it may be nicer to have a daily special purpose server building all the docs with custom processing which expose additional information useful for authors that is noise to readers. That way a standard web browser can be used to find information you need in a simple way. -- Bjørn
participants (11)
-
Beman Dawes -
Bjørn Roald -
Daniel James -
Daniel Wallin -
David Abrahams -
Dean Michael Berris -
John C. Femiani -
John Maddock -
Robert Ramey -
Stefan Seefeld -
Vladimir Prus