Re: [1.35.0] branches/release open for known-good merges

Rene Rivera wrote:

> NP... http://beta.boost.org/development/testing.html ...Has all the 
> links to the various test results.

thanks!

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

Re: [rfc] I/O Chain Library, Preview Release

Sebastian, 

> Back in June I posted some thoughts about what I'd expect 
> from a properly done I/O library.[1] Based on the ensuing 
> discussion I then designed such a library. Over the last 
> months, I've worked hard at implementing the thing.
> 
> It is with quite a bit of pride, then, that I announce the 
> IOChain preview release 1.

This looks really nice and modular allowing to have flexible IO components
readily available.

One (probably unrelated) thought I had when looking at the documentation
was, that it might be useful to allow integration with the new Spirit2
library (consisting out of parser and generator subsystems), allowing to do
IO of structured data. I'm not sure if this has to be done on the device or
filter level, but the essence would be to be able to read and write
arbitrarily formatted data, where the formatting is independent from the
data. 

We did such an integration with the exising iostreams (I'm mentioning this
here just to explain what I mean), allowing to write:

    os << karma::format(
              stream % ", ",    // format description
              c                 // data
          );

where stream invokes an existing operator<< for every element of the data

Boost.Test tests require write access in current directory

In particular, the tests that use output_test_stream supply filenames
that are interpreted relative to the current working directory.
That's not the best possible practice, for reasons of "hygiene:" if
testing Boost causes the Boost tree to be modified, it's hard to be
sure that one is testing the same thing the next time around.
Furthermore, it means one can't test from within a read-only copy of
the Boost sources.  This bit me as I tested from an NFS-mounted
working copy.

I realize that Boost.Test may not want to depend on something like
Boost.Filesystem, but it seems to me that any decent testing framework
has to be able to get ahold of a temporary directory anyway, so maybe
the ability to create files in /tmp or %TEMP% should be part of the
library?

--

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

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

[RFC] Header/namespace policy draft

Hi,

As promised, here's a draft of the proposed
"Boost Header And Namespace Policy" (attached)
Comments, suggestions, etc. very welcome.

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

Boost Header And Namespace Policy

There has been an unwritten standard practice on header placement and
namespaces that has been developed over the years. The Boost policy
gives library authors a huge amount of freedom to organize and evolve
their libraries as they see fit. Authors of newer libraries, however,
had to try and figure out from the way existing libraries are
structured or ask help from fellow boosters with more boost experience
in "boostifying" their code. With very few exceptions, this worked
well in the past. Library authors stayed within the bounds of the
standard practice. Yet, with the rate Boost is growing, it would be
crucial to put the Boost standard practice in writing to avoid
confusion in the future.

This short document will attempt to formalize the Boost standard
practice on header placement, subdirectory and library organization,
and namespace conventions. One purpose of the review process is to

Re: [RFC] Header/namespace policy draft

Joel de Guzman wrote:

>> * Un-reviewed implementation details of libraries have been placed in
>>  boost/detail if they need to be used by other libraries and a
>>  subdirectory of boost/<libraryname>/ otherwise. Their documented
>>  public components are placed in boost/detail and namespace
>> boost::detail.
>>

I think the current situation is a little problematic.

If there in boos/detail, presumable its because they might be
useful accross more than one library.  However,

There is no place for documentation of these things.  So there
is no guarenteed interface.

And of course no separate tests.

No guarentee that the interface won't change - after all
its an implementation detail.  So it can change without
warning an break other libraries.

So, one has a lot of reservations about depending upon
these modules.  On the other hand, they have proved
very useful so for the sake of expediency they're going
to get used - leading to surprise breakages.

So I think those things that have been going to boost/detail
should just go into boost / utility.  Approval for this would

Re: [RFC] Header/namespace policy draft

Robert Ramey wrote:
> Joel de Guzman wrote:
> 
>>> * Un-reviewed implementation details of libraries have been placed in
>>>  boost/detail if they need to be used by other libraries and a
>>>  subdirectory of boost/<libraryname>/ otherwise. Their documented
>>>  public components are placed in boost/detail and namespace
>>> boost::detail.
>>>
> 
> I think the current situation is a little problematic.
> 
> If there in boos/detail, presumable its because they might be
> useful accross more than one library.  However,
> 
> There is no place for documentation of these things.  So there
> is no guarenteed interface.
> 
> And of course no separate tests.
> 
> No guarentee that the interface won't change - after all
> its an implementation detail.  So it can change without
> warning an break other libraries.
> 
> So, one has a lot of reservations about depending upon
> these modules.  On the other hand, they have proved
> very useful so for the sake of expediency they're going
> to get used - leading to surprise breakages.
> 
> So I think those things that have been going to boost/detail

Re: [RFC] Header/namespace policy draft

On Nov 30, 2007 8:47 PM, Joel de Guzman <joel <at> boost-consulting.com> wrote:
> Hi,
>
> As promised, here's a draft of the proposed
> "Boost Header And Namespace Policy" (attached)
> Comments, suggestions, etc. very welcome.

[snip]

> The concept of "core library" is not new. boost::shared_ptr, for
> example, is a core library. It's pretty much common to all libraries.
> Having a core library gives us structure. Typically, "core" libraries
> have the highest number of dependencies. Looking at the dependency
> diagram of boost, the core libraries will be at the bottommost with
> lots of other libraries pointing acyclically at it. It's a must to
> avoid having them depend on other libraries in other layers above the
> core. More emphasis and constraints must be given to these "core"
> libraries as they form the backbone of boost as a whole. For instance,
> a broken core library will have disastrous effects on the whole Boost
> library --core libraries should be very stable.
>
> Determining wether a library is core can be part of the review. If the
> author of a library intends it to be a "core" library, he can
> explicitly say so and be subject for the review. A core library will
> have to accept more stringent requirements such as stability and
> non-dependence on other non-core libraries.
[snip]

This raises an interesting question for me. I recently received a bug
report against boost-dependent library that I work on (Adobe Source

Re: [RFC] Header/namespace policy draft

Mat Marcus wrote:
> On Nov 30, 2007 8:47 PM, Joel de Guzman <joel <at> boost-consulting.com> wrote:
>> Hi,
>>
>> As promised, here's a draft of the proposed
>> "Boost Header And Namespace Policy" (attached)
>> Comments, suggestions, etc. very welcome.
> 
> [snip]
> 
>> The concept of "core library" is not new. boost::shared_ptr, for
>> example, is a core library. It's pretty much common to all libraries.
>> Having a core library gives us structure. Typically, "core" libraries
>> have the highest number of dependencies. Looking at the dependency
>> diagram of boost, the core libraries will be at the bottommost with
>> lots of other libraries pointing acyclically at it. It's a must to
>> avoid having them depend on other libraries in other layers above the
>> core. More emphasis and constraints must be given to these "core"
>> libraries as they form the backbone of boost as a whole. For instance,
>> a broken core library will have disastrous effects on the whole Boost
>> library --core libraries should be very stable.
>>
>> Determining wether a library is core can be part of the review. If the
>> author of a library intends it to be a "core" library, he can
>> explicitly say so and be subject for the review. A core library will
>> have to accept more stringent requirements such as stability and
>> non-dependence on other non-core libraries.
> [snip]
> 
> This raises an interesting question for me. I recently received a bug

Re: [RFC][threads] Header/namespace policy draft

Joel de Guzman wrote:
> If the thread library's move function is undocumented, then it has
> no business being in the root boost namespace but in boost::detail.
> If indeed that is the case, I consider it a bug that should be fixed.
> We should be more vigilant in the review period on such violations.
> More stringent requirements should be put in place for core libraries.
> We should try to restrict as much as possible what goes into the
> boost root namespace and directory. I think it's best to add:
>
>     Only reviewed and documented components of a core library may be
>     placed in the root boost namespace. Violations are considered bugs
>     that must be fixed.
>
> in our core libraries policies.
>
> ((I did a quick search in boost thread's docs and indeed move is not
> documented.))

100% agreement from me: "move" is such a common name that we can't afford to 
pollute namespace boost with it: unless we really mean to of course 

Unfortunately the Boost.Thread docs aren't up to date, so I'm not sure what 
Anthony intended here: Anthony?

Regards John. 

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

Intel EM64T build with msvc

Hi,

I recently tried to build boost 64bits on an intel EM64T (core 2 duo) with
msvc. And bjam incorrectly selected the x86_amd64 toolset (cross compiler)
instead of the amd64 one (native 64bits compiler).

In the file boost/tools/build/v2/tools/msvc.jam at the line 314 the check
is:

if [ MATCH ^(AMD64) : [ os.environ PROCESSOR_IDENTIFIER ] ]

should it be 

if [ MATCH ^(AMD64) : [ os.environ PROCESSOR_ARCHITECTURE ] ]

or 

if [ MATCH ^(AMD64) : [ os.environ PROCESSOR_IDENTIFIER ]
  || MATCH ^(EM64T) : [ os.environ PROCESSOR_IDENTIFIER ] ]

(not certain about the syntax)

My os environement are:

PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=EM64T Family 6 Model 15 Stepping 6, GenuineIntel

Regards,

Ps: perhaps I should post this on boost.build ?