headers
Beman Dawes | 15 Aug 03:04
Favicon

Boost 1.36.0 release notice

Boost 1.36.0 has been released and is available from SourceForge. See 
http://sourceforge.net/projects/boost/

This release include four new libraries:

* Accumulators: Framework for incremental calculation, and collection
  of statistical accumulators, from Eric Niebler.

* Exception: A library for transporting of arbitrary data in exception
  objects, and transporting of exceptions between threads, from
  Emil Dotchevski.

* Units: Zero-overhead dimensional analysis and unit/quantity
  manipulation and conversion, from Matthias Schabel and Steven Watanabe

* Unordered: Unordered associative containers, from Daniel James.

Updated libraries include Asio, Assign, Function, Hash, Interprocess, 
Intrusive, Math, MPI, Multi-index Containers, PtrContainer, Spirit, 
Thread, Wave, and Xpressive.

The release managers were Beman Dawes, Rene Rivera, and Daniel James.

One note of caution: the initial SourceForge release files were missing 
some of the documentation. If you downloaded before 16:00 UTC, August 
14th, please download again to be sure to get the full distribution. 
Sorry for the inconvenience!

--Beman Dawes
(Continue reading)

Permalink | Reply |
headers
Emil Dotchevski | 15 Aug 03:42

Re: Boost 1.36.0 release notice

On Thu, Aug 14, 2008 at 6:04 PM, Beman Dawes <bdawes <at> acm.org> wrote:
> PS: The 1.36.0 version of the web site should be up within a few hours. If
> you can't wait, see http://beta.boost.org now!

Clicking the XHTML 1.0 link in the documentation (which checks for
conformance) seems to report errors on the pages of all of the few
libraries I clicked, including the Exception library. Note that the
documentation at
http://svn.boost.org/svn/boost/branches/release/libs/exception/doc/boost-exception.html
is XHTML 1.0 compliant.

Is this a bug in documentation processing? Is there anything library
authors can do to fix it?

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Daniel James | 15 Aug 08:13
Favicon

Re: Boost 1.36.0 release notice

On 15/08/2008, Emil Dotchevski <emil <at> revergestudios.com> wrote:
>
> Clicking the XHTML 1.0 link in the documentation (which checks for
>  conformance) seems to report errors on the pages of all of the few
>  libraries I clicked, including the Exception library. Note that the
>  documentation at
>  http://svn.boost.org/svn/boost/branches/release/libs/exception/doc/boost-exception.html
>  is XHTML 1.0 compliant.
>
>  Is this a bug in documentation processing? Is there anything library
>  authors can do to fix it?

It's because the underlying documentation is HTML and we don't really
try to convert it or it's invalid XHTML and we don't do anything to
fix it. Fixing this is a fairly large job, and far down on the
priorities. The simplest thing we could do is run every page through
tidy, but that could lead to other problems (because it would change
markup).

We're actually serving the files as HTML, so the browsers just treat
them as tag soup anyway (XHTML is generally not valid HTML, athough
that could change with HTML5). This is a very common situation as
Internet Explorer doesn't support XHTML.

Daniel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Beman Dawes | 15 Aug 17:49
Favicon

Re: Boost 1.36.0 release notice

Daniel James wrote:
> On 15/08/2008, Emil Dotchevski <emil <at> revergestudios.com> wrote:
>> Clicking the XHTML 1.0 link in the documentation (which checks for
>>  conformance) seems to report errors on the pages of all of the few
>>  libraries I clicked, including the Exception library. Note that the
>>  documentation at
>>  http://svn.boost.org/svn/boost/branches/release/libs/exception/doc/boost-exception.html
>>  is XHTML 1.0 compliant.
>>
>>  Is this a bug in documentation processing? Is there anything library
>>  authors can do to fix it?
> 
> It's because the underlying documentation is HTML and we don't really
> try to convert it or it's invalid XHTML and we don't do anything to
> fix it. Fixing this is a fairly large job, and far down on the
> priorities.

I'd like to second Daniel on this. Right now we are holding 
documentation generation together with duct tape. It took much behind 
the scenes work by Daniel, me, Eric Niebler, Rene, and others to get the 
release out. We need to smooth all that out before worrying about XHTML.

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Emil Dotchevski | 15 Aug 19:58

Re: Boost 1.36.0 release notice

On Fri, Aug 15, 2008 at 8:49 AM, Beman Dawes <bdawes <at> acm.org> wrote:
> Daniel James wrote:
>> It's because the underlying documentation is HTML and we don't really
>> try to convert it or it's invalid XHTML and we don't do anything to
>> fix it. Fixing this is a fairly large job, and far down on the
>> priorities.
>
> I'd like to second Daniel on this. Right now we are holding documentation
> generation together with duct tape. It took much behind the scenes work by
> Daniel, me, Eric Niebler, Rene, and others to get the release out. We need
> to smooth all that out before worrying about XHTML.

If we don't care whether the documentation format validates correctly,
we should not advertise it as XHTML-conformant, and we should instruct
documentation writers to not include any conformance claims in their
HTML.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 16 Aug 01:09
Favicon
Gravatar

Re: Boost 1.36.0 release notice


on Fri Aug 15 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:

> On Fri, Aug 15, 2008 at 8:49 AM, Beman Dawes <bdawes <at> acm.org> wrote:
>> Daniel James wrote:
>>> It's because the underlying documentation is HTML and we don't really
>>> try to convert it or it's invalid XHTML and we don't do anything to
>>> fix it. Fixing this is a fairly large job, and far down on the
>>> priorities.
>>
>> I'd like to second Daniel on this. Right now we are holding documentation
>> generation together with duct tape. It took much behind the scenes work by
>> Daniel, me, Eric Niebler, Rene, and others to get the release out. We need
>> to smooth all that out before worrying about XHTML.
>
> If we don't care whether the documentation format validates correctly,
> we should not advertise it as XHTML-conformant, and we should instruct
> documentation writers to not include any conformance claims in their
> HTML.

Seems reasonable to me.  Would you like to propose a specific patch?

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Joe Gottman | 15 Aug 04:15

Re: Boost 1.36.0 release notice

Beman Dawes wrote:
> Boost 1.36.0 has been released and is available from SourceForge. See 
> http://sourceforge.net/projects/boost/
> 
> This release include four new libraries:
> 
    I just downloaded the version 1.36 and the release history is 
completely blank.

Joe Gottman
Permalink | Reply |
headers
Daniel James | 15 Aug 08:28
Favicon

Re: Boost 1.36.0 release notice

On 15/08/2008, Joe Gottman <jgottman <at> carolina.rr.com> wrote:

>    I just downloaded the version 1.36 and the release history is completely
> blank.

I assume you mean on the website. As Beman said, the 1.36 information
wasn't up at the time of release. Rene put it up a couple of hours
ago.

Daniel
Permalink | Reply |
headers
Beman Dawes | 15 Aug 17:54
Favicon

Re: Boost 1.36.0 release notice

Joe Gottman wrote:
> Beman Dawes wrote:
>> Boost 1.36.0 has been released and is available from SourceForge. See 
>> http://sourceforge.net/projects/boost/
>>
>> This release include four new libraries:
>>
>    I just downloaded the version 1.36 and the release history is 
> completely blank.

Grrr...

One of my highest priority tasks for the next release is going to be to 
get a system in place that will automatically scan a release snapshot 
for the presence of certain files, and optionally verify size, date, and 
other properties.

Thanks for the heads up.

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Stefan Seefeld | 15 Aug 18:03

Re: Boost 1.36.0 release notice

Beman Dawes wrote:
> Joe Gottman wrote:
>> Beman Dawes wrote:
>>> Boost 1.36.0 has been released and is available from SourceForge. 
>>> See http://sourceforge.net/projects/boost/
>>>
>>> This release include four new libraries:
>>>
>>    I just downloaded the version 1.36 and the release history is 
>> completely blank.
>
> Grrr...
>
> One of my highest priority tasks for the next release is going to be 
> to get a system in place that will automatically scan a release 
> snapshot for the presence of certain files, and optionally verify 
> size, date, and other properties.

 From the various posts I have read related to the release process it 
sounds as if there is still a fair amount of manual work to be done in 
the process. Not only does this make life hard for release managers, but 
it is also quite error-prone, as this example demonstrates.

Why can't the packaging process be automatized, making it fully 
reproducible ? Trying to increase the amount of tests run on the final 
package attacs the problem from the wrong end, IMO.

Regards,
       Stefan
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 16 Aug 01:11
Favicon
Gravatar

Re: Boost 1.36.0 release notice


on Fri Aug 15 2008, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:

> Why can't the packaging process be automatized, making it fully
> reproducible ? Trying to increase the amount of tests run on the final
> package attacs the problem from the wrong end, IMO.

reproducability != correctness.

I agree that automation is a good idea, but it might also be a good idea
to test the results of that automation, neh?

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Stefan Seefeld | 16 Aug 01:39

Re: Boost 1.36.0 release notice

David Abrahams wrote:
> on Fri Aug 15 2008, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
>
>   
>> Why can't the packaging process be automatized, making it fully
>> reproducible ? Trying to increase the amount of tests run on the final
>> package attacs the problem from the wrong end, IMO.
>>     
>
> reproducability != correctness.
>
> I agree that automation is a good idea, but it might also be a good idea
> to test the results of that automation, neh?
>   
Indeed. My point, however, was that I would *first* automatize, *then* 
validate. The point of reproducibility is to cut down on the amount of 
(repeated) validation you have to do afterwards, no ? :-)

Regards,
       Stefan

--

-- 

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 16 Aug 01:53
Favicon
Gravatar

Re: Boost 1.36.0 release notice


on Fri Aug 15 2008, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:

> David Abrahams wrote:
>> on Fri Aug 15 2008, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
>>
>>   
>>> Why can't the packaging process be automatized, making it fully
>>> reproducible ? Trying to increase the amount of tests run on the final
>>> package attacs the problem from the wrong end, IMO.
>>>     
>>
>> reproducability != correctness.
>>
>> I agree that automation is a good idea, but it might also be a good idea
>> to test the results of that automation, neh?
>>   
> Indeed. My point, however, was that I would *first* automatize, *then*
> validate. The point of reproducibility is to cut down on the amount of
> (repeated) validation you have to do afterwards, no ? :-)

Makes sense to me.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Beman Dawes | 17 Aug 19:57
Favicon

Re: Boost 1.36.0 release notice

Stefan Seefeld wrote:
> Beman Dawes wrote:
>> Joe Gottman wrote:
>>> Beman Dawes wrote:
>>>> Boost 1.36.0 has been released and is available from SourceForge. 
>>>> See http://sourceforge.net/projects/boost/
>>>>
>>>> This release include four new libraries:
>>>>
>>>    I just downloaded the version 1.36 and the release history is 
>>> completely blank.
>>
>> Grrr...
>>
>> One of my highest priority tasks for the next release is going to be 
>> to get a system in place that will automatically scan a release 
>> snapshot for the presence of certain files, and optionally verify 
>> size, date, and other properties.
> 
>  From the various posts I have read related to the release process it 
> sounds as if there is still a fair amount of manual work to be done in 
> the process. Not only does this make life hard for release managers, but 
> it is also quite error-prone, as this example demonstrates.

Yep.

> Why can't the packaging process be automatized, making it fully 
> reproducible?

That's what I've been trying to do, with some success, since last October.
(Continue reading)

Permalink | Reply |
headers
Robert Ramey | 18 Aug 05:14

Re: Boost 1.36.0 release notice

Beman Dawes wrote:

> Probably, but I don't know how to attack some of the tool problems
> otherwise. For example, the problem of people changing the tool chain
> without realizing it has an impact on the automated release tools, and
> the problem of the automated release tools no longer producing some
> component (like docs) because of a tool change, and no one noticing.

How about subjecting the tool chain the the same process as libraries are.
That would be:

a) proposal for boost tool - e.g. docbook.
b) enough implementation, code, and test to request formal review
c) normal formal review process
d) normal acceptance process.
e) normal test procedure.

Test procedure would be similar to that of libraries.  Test files,
expected results etc.  When all tests are passing, the release
manager would have the option of permiting trunk version
to be rolled into the release ready version.

This would work well with other testing and release procedures.
That is, testing and release would use the last released tool
version, NOT the one being refined in the trunk. This would
be in line with what I hope will be the future of boost in that
libraries are tested against last release and rolled into the
release ready version as they prove that they are ready
for prime time.
(Continue reading)

Permalink | Reply |
headers
Rene Rivera | 17 Aug 21:45

Re: Boost 1.36.0 release notice

Robert Ramey wrote:
> Beman Dawes wrote:
> 
>> Probably, but I don't know how to attack some of the tool problems
>> otherwise. For example, the problem of people changing the tool chain
>> without realizing it has an impact on the automated release tools, and
>> the problem of the automated release tools no longer producing some
>> component (like docs) because of a tool change, and no one noticing.
> 
> How about subjecting the tool chain the the same process as libraries are.
> That would be:
> 
> a) proposal for boost tool - e.g. docbook.
> b) enough implementation, code, and test to request formal review
> c) normal formal review process
> d) normal acceptance process.
> e) normal test procedure.
> 
> Test procedure would be similar to that of libraries.  Test files,
> expected results etc.  When all tests are passing, the release
> manager would have the option of permiting trunk version
> to be rolled into the release ready version.
> 
> This would work well with other testing and release procedures.
> That is, testing and release would use the last released tool
> version, NOT the one being refined in the trunk. This would
> be in line with what I hope will be the future of boost in that
> libraries are tested against last release and rolled into the
> release ready version as they prove that they are ready
> for prime time.
(Continue reading)

Permalink | Reply |
headers
Beman Dawes | 18 Aug 03:12
Favicon

Re: Boost 1.36.0 release notice

Robert Ramey wrote:
> Beman Dawes wrote:
> 
>> Probably, but I don't know how to attack some of the tool problems
>> otherwise. For example, the problem of people changing the tool chain
>> without realizing it has an impact on the automated release tools, and
>> the problem of the automated release tools no longer producing some
>> component (like docs) because of a tool change, and no one noticing.
> 
> How about subjecting the tool chain the the same process as libraries are.
> That would be:
> 
> a) proposal for boost tool - e.g. docbook.
> b) enough implementation, code, and test to request formal review
> c) normal formal review process
> d) normal acceptance process.
> e) normal test procedure.
> 
> Test procedure would be similar to that of libraries.  Test files,
> expected results etc.  When all tests are passing, the release
> manager would have the option of permiting trunk version
> to be rolled into the release ready version.
> 
> This would work well with other testing and release procedures.
> That is, testing and release would use the last released tool
> version, NOT the one being refined in the trunk. This would
> be in line with what I hope will be the future of boost in that
> libraries are tested against last release and rolled into the
> release ready version as they prove that they are ready
> for prime time.
(Continue reading)

Permalink | Reply |
headers
Robert Ramey | 18 Aug 03:19

Re: Boost 1.36.0 release notice

Beman Dawes wrote:
> Robert Ramey wrote:
>> This would work well with other testing and release procedures.
>> That is, testing and release would use the last released tool
>> version, NOT the one being refined in the trunk. This would
>> be in line with what I hope will be the future of boost in that
>> libraries are tested against last release and rolled into the
>> release ready version as they prove that they are ready
>> for prime time.
>
> Yes, although the problems we've been having aren't so much with new
> tools as with existing tools that break unexpectedly (and/or worse
> yet, silently).
>
> Also, the breaking change may be in a tool that Booster's don't
> maintain, such as Doxygen or xsltproc.
>

The same could be said for libraries.  Actually, to me, the most important
part of the testing process is detecting when something that I depend upon 
changes.
 I complain about this all the time - but even if no one introduced breaking
changes, there is always new stuff - new compilers, new versions
of stl, new os variations, corrections in libraries which catch
previously undetected errors of my own.

My real point is that there is no reason that any tools that
are used by boost should be treated any differently than
any libraries used by boost.
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 18 Aug 05:48
Favicon
Gravatar

Re: Boost 1.36.0 release notice


on Sun Aug 17 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> My real point is that there is no reason that any tools that
> are used by boost should be treated any differently than
> any libraries used by boost.

Does that assertion have any practical implications for the issue
being discussed?

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Robert Ramey | 18 Aug 07:59

Re: Boost 1.36.0 release notice

David Abrahams wrote:
> Beman Dawes wrote:
>
>> Probably, but I don't know how to attack some of the tool problems
>> otherwise. For example, the problem of people changing the tool chain
>> without realizing it has an impact on the automated release tools, and
>> the problem of the automated release tools no longer producing some
>> component (like docs) because of a tool change, and no one noticing.
>
> on Sun Aug 17 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>
>> My real point is that there is no reason that any tools that
>> are used by boost should be treated any differently than
>> any libraries used by boost.
>
> Does that assertion have any practical implications for the issue
> being discussed?

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.

Robert Ramey 

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

Permalink | Reply |
headers
David Abrahams | 18 Aug 08:22
Favicon
Gravatar

Re: Boost 1.36.0 release notice


on Sun Aug 17 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> David Abrahams wrote:
>> Beman Dawes wrote:
>>
>>> Probably, but I don't know how to attack some of the tool problems
>>> otherwise. For example, the problem of people changing the tool chain
>>> without realizing it has an impact on the automated release tools, and
>>> the problem of the automated release tools no longer producing some
>>> component (like docs) because of a tool change, and no one noticing.
>>
>> on Sun Aug 17 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>>
>>> My real point is that there is no reason that any tools that
>>> are used by boost should be treated any differently than
>>> any libraries used by boost.
>>
>> Does that assertion have any practical implications for the issue
>> being discussed?
>
> 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.

Thanks for spelling that out; it wasn't obvious to me.

--

--
(Continue reading)

Permalink | Reply |
headers
Vladimir Prus | 18 Aug 08:35
Favicon

Re: Boost 1.36.0 release notice

Robert Ramey wrote:

> David Abrahams wrote:
>> Beman Dawes wrote:
>>
>>> Probably, but I don't know how to attack some of the tool problems
>>> otherwise. For example, the problem of people changing the tool chain
>>> without realizing it has an impact on the automated release tools, and
>>> the problem of the automated release tools no longer producing some
>>> component (like docs) because of a tool change, and no one noticing.
>>
>> on Sun Aug 17 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>>
>>> My real point is that there is no reason that any tools that
>>> are used by boost should be treated any differently than
>>> any libraries used by boost.
>>
>> Does that assertion have any practical implications for the issue
>> being discussed?
> 
> LOL - of course it does.

Is there any reason the above exchange makes you laughing out loud?

> 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.
(Continue reading)

Permalink | Reply |
headers
Robert Ramey | 18 Aug 09:12

Re: Boost 1.36.0 release notice

Vladimir Prus wrote:

>> 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.

> Last time I've checked, boost.serialization had some automatic tests.
> Does it mean that no issue has ever occurred with
> boost.serialization, and no issue
> will ever occur in future? I don't think so.

Of course not, but I'm sure that the extensive testing of the
boost serialization has avoided untold numbers of problems
for users.  And, it has made the package much easier to develop.
I believe that it would do the same for boost tools.
It's well known that testing can't prove the absense
of faults, only their existence.  That doesn't make testing
pointless.

> Quoting Beman:
>
>        Case in point, the doc build tool chain broke for this
>        release, forcing a really messy workaround. Joel is trying to
>        fix it now, but it is slow going since the test cases that
>        fail for others works for him.
>
> So, it appears like the problem is not that there's no *testing
> infrastructure* is missing, it's that for some behaviours, there are
(Continue reading)

Permalink | Reply |
headers
Vladimir Prus | 18 Aug 09:30
Favicon

Re: Boost 1.36.0 release notice

Robert Ramey wrote:

>> Quoting Beman:
>>
>>        Case in point, the doc build tool chain broke for this
>>        release, forcing a really messy workaround. Joel is trying to
>>        fix it now, but it is slow going since the test cases that
>>        fail for others works for him.
>>
>> So, it appears like the problem is not that there's no *testing
>> infrastructure* is missing, it's that for some behaviours, there are
>> no tests or those tests are not sufficiently reliable.
> 
> Taking the case of boost book.  As far as I know there is
> no regression testing to verify that it works when something
> it depends upon changes.

I don't know, either. But large part of the doc toolchain is outside
of Boost -- e.g. Docbook and FOP. Those are huge, and it's not
likely somebody will be able to create tests for those. So, manual
inspection of results remain the only solution.

> 
>>Therefore, it does not seem like
>> generic advice of "we need tests" is going to help much -- there
>> needs to be actual work on specific tests.
> 
> My suggestion is a lot more than "we need tests".  My suggestion
> is that boost tools should be subjected to the same procedures
> that boost libaries are.  Using boost book as an example, I would
(Continue reading)

Permalink | Reply |
headers
Robert Ramey | 18 Aug 17:59

Re: Boost 1.36.0 release notice

Vladimir Prus wrote:
> Robert Ramey wrote:

>> Taking the case of boost book.  As far as I know there is
>> no regression testing to verify that it works when something
>> it depends upon changes.
>
> I don't know, either. But large part of the doc toolchain is outside
> of Boost -- e.g. Docbook and FOP. Those are huge, and it's not
> likely somebody will be able to create tests for those. So, manual
> inspection of results remain the only solution.

I'm not advocating that tests be create for those things outside of
boost.  I'm advocating tests for those things in boost which
depend on things outside of boost as well as the thing itself.
We do the same thing with our libraries.  We write code
which depends up STL.  In the course of testing ,we discover
that we either made a mistake in using STL, or that various
verstions of STL have differing interpretations of
ambiguous points in some standard or have bugs in thier own.

>> My suggestion is a lot more than "we need tests".  My suggestion
>> is that boost tools should be subjected to the same procedures
>> that boost libaries are.  Using boost book as an example, I would
>> like to see boost/tools/boostbook/test/Jamfile ... and see that
>> boost book shows up in the test matrix just like any library does.

> I think that presence or lack of boost/tools/boostbook/test/Jamfile
> is an implementation detail.
(Continue reading)

Permalink | Reply |
headers
John Maddock | 18 Aug 10:17

Re: Boost 1.36.0 release notice

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) :-(

John. 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Hajo Kirchhoff | 16 Aug 18:47

Re: Boost 1.36.0 release notice

Beman Dawes wrote:
> Boost 1.36.0 has been released and is available from SourceForge. See
> http://sourceforge.net/projects/boost/
[snip]
> One note of caution: the initial SourceForge release files were missing
> some of the documentation. If you downloaded before 16:00 UTC, August
> 14th, please download again to be sure to get the full distribution.
> Sorry for the inconvenience!

The docs seem to be broken still.

When I click on 'asio' in the alphabetical list of libraries
boost_1_36_0/libs/libraries.htm#Alphabetically

I get redirected to
http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boost_asio.html

and get a 404 not found error.

I just now (aug-16th) downloaded boost_1_36_0.tar.bz2 from a sourceforge
mirror.

Any ideas why?

Best regards

Hajo

> 
> --Beman Dawes
(Continue reading)

Permalink | Reply |
headers
Beman Dawes | 17 Aug 20:24
Favicon

Re: Boost 1.36.0 release notice

Hajo Kirchhoff wrote:
> Beman Dawes wrote:
>> Boost 1.36.0 has been released and is available from SourceForge. See
>> http://sourceforge.net/projects/boost/
> [snip]
>> One note of caution: the initial SourceForge release files were missing
>> some of the documentation. If you downloaded before 16:00 UTC, August
>> 14th, please download again to be sure to get the full distribution.
>> Sorry for the inconvenience!
> 
> The docs seem to be broken still.
> 
> When I click on 'asio' in the alphabetical list of libraries
> boost_1_36_0/libs/libraries.htm#Alphabetically
> 
> I get redirected to
> http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boost_asio.html
> 
> and get a 404 not found error.
> 
> I just now (aug-16th) downloaded boost_1_36_0.tar.bz2 from a sourceforge
> mirror.
> 
> Any ideas why?

I suspect you got a stale version from some (SourceForge?) cache.

I tried (and failed) to reproduce the problem by downloading and 
unpacking boost_136_0.tar.bz2 from SourceForge, and then clicking down 
to the Alphabetic library listing, then clicking Asio. It worked fine.
(Continue reading)

Permalink | Reply |
headers
Hajo Kirchhoff | 18 Aug 09:14

Re: Boost 1.36.0 release notice

Hi Beman,
Beman Dawes wrote:
> I suspect you got a stale version from some (SourceForge?) cache.
> 
> I tried (and failed) to reproduce the problem by downloading and
> unpacking boost_136_0.tar.bz2 from SourceForge, and then clicking down
> to the Alphabetic library listing, then clicking Asio. It worked fine.

that is very strange. I've just tried the third sourceforge mirror (two
in europe and the last one in new york) and tried a different format
(7z) but still end up at
http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boost_asio.html

when I click on asio in
file:/// ... boost_1_36_0/libs/libraries.htm#Alphabetically

BTW, the checkout from the svn repository also shows the same behaviour.

If you look at
http://svn.boost.org/trac/boost/browser/tags/release/Boost_1_36_0/doc/html/boost_asio.html
you see that it contains the same odd redirection.

Is there any postprocessing done in the release process so that the
documentation contained in the release package is different from what is
checked in?

And is there any place I get a working copy from?

Thank you very much in advance.
(Continue reading)

Permalink | Reply |
headers
Hajo Kirchhoff | 18 Aug 09:49

Re: Boost 1.36.0 release notice

Hi all,
Hajo Kirchhoff wrote:
> And is there any place I get a working copy from?

I finally got my asio documentation working again. It was probably an
error on my part.

Sorry for the trouble.

Regards and thanks for the new release

Hajo
Permalink | Reply |

Gmane