AMDG This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The patch itself is rather large, even compressed, so I uploaded it to http://www.cs.hmc.edu/~swatanabe/random.patch.zip Okay to commit? In Christ, Steven Watanabe
This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/
Steven, I've only scanned those docs a little but this looks really good: much better than the old documentation! One thing I did notice were some very long lines in the reference section, for example: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/boost/taus8... These are verging on the unreadable in HTML, but will just get truncated in PDF output :-( I suspect though that this is Doxygen mangling the formatting?
Okay to commit?
+1 from me. Nice work, John.
AMDG John Maddock wrote:
This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/
Steven, I've only scanned those docs a little but this looks really good: much better than the old documentation!
One thing I did notice were some very long lines in the reference section, for example: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/boost/taus8...
These are verging on the unreadable in HTML, but will just get truncated in PDF output :-(
I suspect though that this is Doxygen mangling the formatting?
Yep. You mentioned this before, but I couldn't find a way to force it to be formatted properly. The best I can think of would be to get rid of the long type name and change it to something like typedef xor_combine<...> taus88; for doxygen builds. In Christ, Steven Watanabe
2010/2/22 Steven Watanabe <watanabesj@gmail.com>
AMDG
John Maddock wrote:
This is hopefully the final version of the work I did back in November
to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/<http://www.cs.hmc.edu/%7Eswatanabe/random_doc/libs/random/doc/html/>
Steven, I've only scanned those docs a little but this looks really good: much better than the old documentation!
One thing I did notice were some very long lines in the reference section, for example: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/boost/taus88.html<http://www.cs.hmc.edu/%7Eswatanabe/random_doc/libs/random/doc/html/boost/taus88.html>
These are verging on the unreadable in HTML, but will just get truncated in PDF output :-(
I suspect though that this is Doxygen mangling the formatting?
Yep. You mentioned this before, but I couldn't find a way to force it to be formatted properly. The best I can think of would be to get rid of the long type name and change it to something like
typedef xor_combine<...> taus88;
for doxygen builds.
I have the same problem in my reference section. E.g. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost/itl/int...
If someone knew a trick for a better formatting result, I'd be very interested. Regards, Joachim
Joachim Faulhaber wrote:
2010/2/22 Steven Watanabe <watanabesj@gmail.com>
John Maddock wrote:
This is hopefully the final version of the work I did back in November
to convert the Random docs to Quickbook/Doxygen/Boostbook.
Steven, I've only scanned those docs a little but this looks really good: much better than the old documentation!
One thing I did notice were some very long lines in the reference section, for example:
http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/boost/taus8...
These are verging on the unreadable in HTML, but will just get truncated in PDF output :-(
I suspect though that this is Doxygen mangling the formatting?
Yep. You mentioned this before, but I couldn't find a way to force it to be formatted properly. The best I can think of would be to get rid of the long type name and change it to something like
typedef xor_combine<...> taus88;
for doxygen builds.
I suppose that intermediate typedefs are not desirable? They could be put in the detail namespace: namespace detail { typedef random::linear_feedback_shift< uint32_t, 32, 31, 13, 12, 0 > type1; typedef random::linear_feedback_shift< uint32_t, 32, 29, 2, 4, 0 > type2; typedef random::xor_combine< detail::type1, 0, detail::type2, 0, 0 > type3; typedef random::linear_feedback_shift< uint32_t, 32, 28, 3, 17, 0 > type4; } typedef random::xor_combine< detail::type3, 0, detail::type4, 0, 0 > taus88; I think that's easier to read just because the separate parts can be parsed and digested more easily.
I have the same problem in my reference section. E.g. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost/itl/int...
If someone knew a trick for a better formatting result, I'd be very interested.
typedef interval_base_map< type, DomainT, CodomainT, Traits, Compare, Combine, Section, Interval, Alloc > base_type; That doesn't help with the base class type, however, and there are still plenty of long sequences of tokens in that class definition. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2010/2/22 Stewart, Robert <Robert.Stewart@sig.com>
Joachim Faulhaber wrote:> > I have the same problem in my reference section. E.g.
http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost/itl/int...
If someone knew a trick for a better formatting result, I'd be very interested.
typedef interval_base_map< type, DomainT, CodomainT, Traits, Compare, Combine, Section, Interval, Alloc > base_type;
Thanks for the hint. This improves the html output:) Substituting common sub expressions is always good!
Joachim.
Joachim Faulhaber wrote:
2010/2/22 Steven Watanabe <watanabesj@gmail.com>
AMDG
John Maddock wrote:
This is hopefully the final version of the work I did back in November
to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/<http://www.cs.hmc.edu/%7Eswatanabe/random_doc/libs/random/doc/html/>
Steven, I've only scanned those docs a little but this looks really good: much better than the old documentation!
One thing I did notice were some very long lines in the reference section, for example: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/boost/taus88.html<http://www.cs.hmc.edu/%7Eswatanabe/random_doc/libs/random/doc/html/boost/taus88.html>
These are verging on the unreadable in HTML, but will just get truncated in PDF output :-(
I suspect though that this is Doxygen mangling the formatting?
Yep. You mentioned this before, but I couldn't find a way to force it to be formatted properly. The best I can think of would be to get rid of the long type name and change it to something like
typedef xor_combine<...> taus88;
for doxygen builds.
I have the same problem in my reference section. E.g. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost/itl/int...
If someone knew a trick for a better formatting result, I'd be very interested.
Well the easy way would have been to change the wrapping with a "white-space: pre-wrap" CSS style. But, when I tried that, it produces rather bad rendering since those synopsis sections have white-space "columns". So to really fix things someone first has to change the doc generation to not use the rather bad white-space column format. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
If someone knew a trick for a better formatting result, I'd be very interested.
Well the easy way would have been to change the wrapping with a "white-space: pre-wrap" CSS style. But, when I tried that, it produces rather bad rendering since those synopsis sections have white-space "columns". So to really fix things someone first has to change the doc generation to not use the rather bad white-space column format.
That would only fix HTML formatting though? Not PDF's? John.
Joachim Faulhaber wrote:
2010/2/22 Steven Watanabe <watanabesj@gmail.com>
I have the same problem in my reference section. E.g.
http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost/itl/int...
If someone knew a trick for a better formatting result, I'd be very interested.
Indenting source code itself usually helps: template < typename DomainT, typename CodomainT, class Traits = itl::partial_absorber, ITL_COMPARE Compare = ITL_COMPARE_INSTANCE(std::less, DomainT), ITL_COMBINE Combine = ITL_COMBINE_INSTANCE(itl::inplace_plus, CodomainT), ITL_SECTION Section = ITL_SECTION_INSTANCE(itl::inplace_et, CodomainT), template<class, ITL_COMPARE> class Interval = itl::interval, ITL_ALLOC Alloc = std::allocator > class interval_map : public boost::itl::interval_base_map < boost::itl::interval_map < DomainT, CodomainT, Traits, Compare, Combine, Section, Interval, Alloc >, DomainT, CodomainT, Traits, Compare, Combine, Section, Interval, Alloc > { ... }; Best regards, -- Mateusz Loskot http://mateusz.loskot.net
Hi Mateusz, 2010/2/22 Mateusz Loskot <mateusz@loskot.net>
Joachim Faulhaber wrote:
2010/2/22 Steven Watanabe <watanabesj@gmail.com>
I have the same problem in my reference section. E.g.
http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost/itl/int...
If someone knew a trick for a better formatting result, I'd be very interested.
Indenting source code itself usually helps:
In this case unfortunately no. My source code had some line breaks already and I further broke it down and indented according to your suggestion. But the formatting result was the same as before. Best regards, Joachim
Joachim Faulhaber wrote:
Hi Mateusz,
2010/2/22 Mateusz Loskot <mateusz@loskot.net>
Joachim Faulhaber wrote:
2010/2/22 Steven Watanabe <watanabesj@gmail.com>
I have the same problem in my reference section. E.g. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost/itl/int...
If someone knew a trick for a better formatting result, I'd be very interested. Indenting source code itself usually helps:
In this case unfortunately no. My source code had some line breaks already and I further broke it down and indented according to your suggestion. But the formatting result was the same as before.
I did a quick test calling Doxygen directly and it preserves formatting but it is for source code listings, which may behave differently to synopsis generated from XML output. Indeed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
2010/2/22 Mateusz Loskot <mateusz@loskot.net>:
Joachim Faulhaber wrote:
Hi Mateusz,
2010/2/22 Mateusz Loskot <mateusz@loskot.net>
Joachim Faulhaber wrote:
2010/2/22 Steven Watanabe <watanabesj@gmail.com>
I have the same problem in my reference section. E.g. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost/itl/int...
If someone knew a trick for a better formatting result, I'd be very interested. Indenting source code itself usually helps:
In this case unfortunately no. My source code had some line breaks already and I further broke it down and indented according to your suggestion. But the formatting result was the same as before.
I did a quick test calling Doxygen directly and it preserves formatting but it is for source code listings, which may behave differently to synopsis generated from XML output. Indeed.
No problem, thanks for your suggestion anyway. To be honest, I have no idea how the integration of quickbook and doxygen works but I like the uniform typographical style of the quickbook docs very much and the generated references are IMO nicer than those generated by doxygen alone. Most of the time the generated docs are looking good. Those few exceptions are a challenge for the future. With thanks to the quickbook authors and maintainers Joachim
On 22 February 2010 15:00, Steven Watanabe <watanabesj@gmail.com> wrote:
Yep. You mentioned this before, but I couldn't find a way to force it to be formatted properly. The best I can think of would be to get rid of the long type name and change it to something like
typedef xor_combine<...> taus88;
for doxygen builds.
I'll look into adding an optional formatter to the xsl. Although, it might not be able to cope with marked up text (so it would loose the links). It might be easier to rewrite the doxygen to boostbook converter in python, which is a lot better suited for such things. Daniel
Daniel James wrote:
On 22 February 2010 15:00, Steven Watanabe <watanabesj@gmail.com> wrote:
Yep. You mentioned this before, but I couldn't find a way to force it to be formatted properly. The best I can think of would be to get rid of the long type name and change it to something like
typedef xor_combine<...> taus88;
for doxygen builds.
I'll look into adding an optional formatter to the xsl. Although, it might not be able to cope with marked up text (so it would loose the links). It might be easier to rewrite the doxygen to boostbook converter in python, which is a lot better suited for such things.
Like this.. <https://svn.boost.org/trac/boost/browser/trunk/tools/build/v2/tools/doxproc.py> ? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 22 February 2010 16:49, Rene Rivera <grafikrobot@gmail.com> wrote:
I'll look into adding an optional formatter to the xsl. Although, it might not be able to cope with marked up text (so it would loose the links). It might be easier to rewrite the doxygen to boostbook converter in python, which is a lot better suited for such things.
Like this.. <https://svn.boost.org/trac/boost/browser/trunk/tools/build/v2/tools/doxproc.py> ?
Yes, thanks. I'd missed that. I'll look into when I get a chance. Daniel
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, February 22, 2010 9:14 AM To: boost@lists.boost.org Subject: Re: [boost] [random] new documentation
This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/
Steven, I've only scanned those docs a little but this looks really good: much better than the old documentation!
Okay to commit?
+1 from me.
Nice work, John.
There is just one important addition to the acknowledgements section you should make first - adding a 'thanks to Steven Watanabe for doing this really useful docs update' ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
On Sun, Feb 21, 2010 at 9:14 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/
I'm getting missing images for some of the icons. They are supposed to be located at: http://www.cs.hmc.edu/~swatanabe/random_doc/doc/src/images/callouts/1.png This is with Chrome and IE7. In Firefox they appear correctly as numbers. This happens on http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/boost_rando... for instance. The docs look much better, thanks! --Michael Fawcett
AMDG Michael Fawcett wrote:
On Sun, Feb 21, 2010 at 9:14 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/
I'm getting missing images for some of the icons. They are supposed to be located at: http://www.cs.hmc.edu/~swatanabe/random_doc/doc/src/images/callouts/1.png
This is with Chrome and IE7. In Firefox they appear correctly as numbers.
This happens on http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/boost_rando... for instance.
My bad. I didn't upload quite everything. They should be there now. In Christ, Steven Watanabe
participants (9)
-
Daniel James -
Joachim Faulhaber -
John Maddock -
Mateusz Loskot -
Michael Fawcett -
Paul A. Bristow -
Rene Rivera -
Steven Watanabe -
Stewart, Robert