Stjepan Rajko | 1 Feb 01:26
Picon
Favicon

Re: BoostBook/QuickBook

On Jan 31, 2008 3:15 PM, Brook Milligan <brook <at> biology.nmsu.edu> wrote:
> I am ready to markup the documentation for a library, but am lost with
> respect to getting started with the documentation tools BoostBook and
> QuickBook.  I think I can understand the markup itself, but as far as
> I can tell there is no documentation on actually building and using
> the tools, the files produced, etc.  Any guidelines would be very
> appreciated.
>
> Cheers,
> Brook

Hi Brook,

Here are some URLs you might find helpful:

Boostbook docs (including setup instructions)
http://www.boost.org/doc/html/boostbook.html

Quickbook docs in the svn trunk (including setup instructions)
http://tinyurl.com/2smgta

There is also a mailing list for boost documentation / doc tools, if
you run into problems:
http://lists.boost.org/mailman/listinfo.cgi/boost-docs

Cheers,
Stjepan
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

(Continue reading)

Joel de Guzman | 1 Feb 01:31
Picon
Favicon

Re: BoostBook/QuickBook

Brook Milligan wrote:
> I am ready to markup the documentation for a library, but am lost with
> respect to getting started with the documentation tools BoostBook and
> QuickBook.  I think I can understand the markup itself, but as far as
> I can tell there is no documentation on actually building and using
> the tools, the files produced, etc.  Any guidelines would be very
> appreciated.

There is. Try to get the copy from SVN and see the installation sections.
http://svn.boost.org/svn/boost/trunk/tools/quickbook/doc/html/quickbook/install.html

Regards,
--

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

David Abrahams | 1 Feb 03:43
Picon
Picon
Favicon
Gravatar

Re: Boost pool allocator slower than STL allocator


on Sun Dec 30 2007, Robin <al-AT-cyberversion.com> wrote:

>> My understanding is that the pool allocator is made for repeated
>> allocation and deallocation of same-sized blocks, in which case the
>> result makes sense.  I think it's more intended for use with
>> node-based containers such as list and map.
>
> I tried with list, the std::allocator is still faster
>
> typedef list <A, boost::pool_allocator <list <A>::value_type > > ListA;
> ListA listA;
>
> then 
>
> listA.push_back (A ());
> listA.pop_front ();
>
> Or with boost::shared_ptr as I need to keep a polymorphic pointer.
>
> typedef list < boost::shared_ptr <A>, boost::pool_allocator <A> > ListA;
> ListA listA;
>
> then
>
> listA.push_back (boost::shared_ptr <A> (new A ()));
> listA.pop_front ();
>
>
> I can't get map to compile, 
(Continue reading)

Terence Wilson | 1 Feb 03:44

Boost serialization DLL issues on x64 platforms

Folks,

I've finally found the cause of a problem that has been tripping us up for
some time. We have a Windows application that we build for IA32 and x64.
Naturally the IA32 version links against 32-bit import libraries and the x64
64-bit import libraries. But here's the rub: Boost generates output binaries
with the same name for both platforms:

bjam -sTOOLS=vc-8_0
bjam -sTOOLS=vc-8_0-amd64

both result in 

boost_serialization-vc80-mt-gd-1_33_1.lib
boost_serialization-vc80-mt-gd-1_33_1.dll 

being created (among other things). Now because the Windows loader simply
searches the PATH for the first DLL that matches the name of the import
library, an x64 application linked against the x64 import library for Boost
Serialization might load the IA32 version at runtime.

Most other tool vendors solve this one by attaching a 'x64' suffix to the
import and DLL filenames. However, despite what the Boost Build
documentation says, the tool name "vc-8_0-amd64" is not used when building
the DLL file name. We get stuck with the same filename for both platforms.

Simply rename the files? Nope, the binary import library contains decorated
names prefixed with the DLL name. The best fix would be to make bjam do the
right thing:

(Continue reading)

David Abrahams | 1 Feb 03:50
Picon
Picon
Favicon
Gravatar

Re: Document python::handle behavior


on Thu Jan 03 2008, Neal Becker <ndbecker2-AT-gmail.com> wrote:

> To allow handle to work with various PyObject compatible types, handle
> relies on specializations of base_type_traits.
>
> I don't think that's mentioned in the reference docs, 

I think that's because it's an implementation detail.

> and leads to mysterious compile errors to the un-initiated.

If you'd like to create a ticket showing some erroneous code and its
suboptimal error message, I could try to improve it.

--

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

David Abrahams | 1 Feb 04:03
Picon
Picon
Favicon
Gravatar

Re: Errors in status/explicit-failures-markup.xml?


on Mon Jan 14 2008, Beman Dawes <bdawes-AT-acm.org> wrote:

> Jeff Garland wrote:
>> Beman Dawes wrote:
>>> Jens Seidel wrote:
>>>> Hi,
>>>>
>>>> I noticed that status/explicit-failures-markup.xml seems to contain some
>>>> errors. I really wonder e.g. about "These compilers are unfortunately
>>>> able to correctly compile". It looks like there is a "not" missing in
>>>> this sentence (multiple times!).
>>> Subversion "blame" pinpoints Jeff Garland as the guilty party:-)
>>>
>>> Jeff?
>> 
>> I haven't modified the markup since it's been moved to subversion....so I'm 
>> going to proclaim innocence.
>
> This isn't a new problem. It has existed since rev 29888. The wording says:
>
>>                 These compilers are unfortunately able to correctly compile the
>>                 new format-based input-output code for date time.  Suitable, but
>>                 less flexible, alternatives are available on these compilers.
>
> What Jens is suggesting is that the comment (which is repeated multiple 
> times) should read something like:
>
> These compilers are unfortunately *not* able to correctly compile the
> new format-based input-output code for date time.  Suitable, but
(Continue reading)

David Abrahams | 1 Feb 04:04
Picon
Picon
Favicon
Gravatar

Re: [1.35] proposal to add two platforms as release platforms for 1.35


on Mon Jan 14 2008, "Boris Gubenko" <Boris.Gubenko-AT-hp.com> wrote:

> Beman Dawes wrote:
>> I don't want to add any more platforms to 1.35.0. Every such change, no
>> matter how small it seems, adds to the delay. We need to finish 1.35.0
>> and start working on the next release.
>
> I understand the concern and this is why I'm proposing platforms which,
> based on test results, are ready for 1.35.
>
> Please, take into account the fact that some customers would not use
> Boost unless platform is tested and is listed as supported in a
> particular Boost release. Such customers would have to wait until
> "next release", whatever it means, which is unfortunate.
>
> I urge you to reconsider your decision. We can add the two platforms in
> question conditionally: run full tests against release branch and if the
> results are not as good as that on trunk, I'll remove zip archive(s) from
> the 1.35 ftp repository and it will be the end of the story.

This sounds reasonable to me.  Beman?

--

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

David Abrahams | 1 Feb 04:09
Picon
Picon
Favicon
Gravatar

Re: [trac][wiki] Correct wiki for development


on Sun Jan 20 2008, Jonathan Turkanis <turkanis-AT-coderage.com> wrote:

> Hi,
>
> I'd like to prepare some notes about future development of 
> Boost.Iostreams and make them available in a shared location.
>
> I'm wondering if I should use the trac wiki or the user wiki at 
> crystalclearsoftware.com. I'm inclined to say it should be the trac 
> wiki, 

Yep.

> but I don't see anything similar there, except for "Boost.Graph 
> Version 2", under "Projects" on the home page. Can I just create a 
> Boost.Iostreams link under "Projects"?

Do whatever you think is appropriate; you are one of the pioneers.

--

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

David Abrahams | 1 Feb 04:11
Picon
Picon
Favicon
Gravatar

Re: [1.35.0] Building the release?


on Tue Jan 22 2008, Beman Dawes <bdawes-AT-acm.org> wrote:

> Rene Rivera wrote:
>> Beman Dawes wrote:
>>> What else? Where do the beta.boost.org web pages come from?
>> 
>> Which web pages specifically? All of them? The docs?
>
> For example, in 1.34.x there was a page 
> boost-root/more/cpp_committee_meetings.html
>
> On the beta site, it has migrated to 
> http://beta.boost.org/community/committee.html

Are we inserting any redirects so that peoples' links won't break for a
while?

--

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

David Abrahams | 1 Feb 04:18
Picon
Picon
Favicon
Gravatar

Re: Boostcon 2008- should I book my flights?


on Sun Jan 27 2008, "Terence Wilson" <tez-AT-latte.com> wrote:

> Dave- thanks for all your hard work behind the scenes.

You're welcome!

--

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Gmane