Jason is getting MARRIED!

classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Jason is getting MARRIED!

Boost - Dev mailing list
My JSON library is going to propose to Boost soon, is there anyone who
might be willing and able to function in the role of review manager?

Thanks!

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
On 11/16/19 7:09 PM, Vinnie Falco via Boost wrote:
> My JSON library is going to propose to Boost soon, is there anyone who
> might be willing and able to function in the role of review manager?

Before we get to that point, there are some questions that the community
should address.

These days there are a huge number of JSON libraries out there. Some
focus on features (e.g. binary JSON or JSONPath), others on performance,
and others on user-friendliness. What competitive edge should a
potential Boost JSON library offer?

Which use cases should a potential Boost JSON library support? Should
the library work seemlessly with standard algorithms? Should it be
possible to create parser combinators? Should there be a JSON archive
for Boost.Serialization? Should it replace parts of Boost.PropertyTree?

PS: On a procedural note, you need an endorsement of the library before
seeking a review manager.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
Bjorn Reese wrote:

> PS: On a procedural note, you need an endorsement of the library before
> seeking a review manager.

I endorse the library.

Although not necessarily the subject line.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Nov 17, 2019 at 3:45 AM Bjorn Reese via Boost
<[hidden email]> wrote:
> Before we get to that point, there are some questions

Yes these are good questions. I thought I had answered them but it
could certainly use more explaining (and in the documentation as
well).

In terms of parsing and serialization I don't think there will be any
single solution that will satisfy all use cases. The emphasis of my
JSON library is on the container that represents the JSON In memory.
It is designed to be useful as a vocabulary type. This means that if
someone wants to write a library that does things with JSON (e.g.
implementing JSON-RPC[1]), their public interfaces can confidently use
`boost::json::value`[2] in function signatures and declarations for
several reasons:

* `json::value` is SemiRegular
* `json::value` is small (16/24 bytes on 32/64 bit architecture)
* `json::value` behaves predictably with respect to special members (copy, move)
* `json::value` supports custom allocators (without being a template parameter)
* The physical structure of the value types is designed to reduce
compilation times:
  - No class templates
  - No configurability (well-defined, predictable behavior)
  - Strong separation of concerns
* The object[3], array[4], and string[5] types, used for the
underlying representation of
   the corresponding JSON kind, are first class types[3,4,5]
* All operations provide the strong exception safety guarantee

That said, parsing and serialization are still important and in this
area my library is quite competitive in terms of performance.
RapidJSON is currently the top-performing library for parsing and
serialization using a general purpose container (I don't count
SIMDJson, which produces a read-only structure). In comparison to
RapidJSON, my library outperforms RapidJSON in most cases and
completely blows away nlohmann [6].

This library also supports both incremental parsing and incremental
serialization using caller-provided buffers, an important use-case for
building high performing network programs. To my knowledge no other
JSON library supports this.

> These days there are a huge number of JSON libraries out there. Some
> focus on features (e.g. binary JSON or JSONPath), others on performance,
> and others on user-friendliness. What competitive edge should a
> potential Boost JSON library offer?

A problem that I see with some other libraries is that they attempt to
do too much, resulting in poor API designs with no separation of
concerns, and long compilation times. Something that I am doing these
days, based on things I've learned while maintaining Beast, is to
design my new libraries differently:

* Keep the scope narrow: solve one problem and solve it well
* Minimize the use of templates where doing so does not diminish functionality
* Design with modularity in mind: minimize dependencies
* Be mindful of compilation times

This new thinking addresses the most common complaints that users have
about Boost libraries. A planned feature is to enable this JSON
library to be used without Boost simply by defining
BOOST_JSON_STANDALONE. This way stubborn users who refuse to use boost
because Reasons can still enjoy a wonderful JSON library.

> Which use cases should a potential Boost JSON library support? Should
> the library work seemlessly with standard algorithms?

I'm not sure what supporting standard algorithms means, but the
object, array, and string containers have interfaces that are
identical to their C++20 equivalents (unordered_map, vector, and
string) except that for the `object` type:

* The elements are stored contiguously
* Iterators are ordinary pointers, and may become invalidated on
  insertions and removals.
* The order of insertions is preserved, as long as there are no removals.
* All inserted values will use the same allocator as the container itself.
* All hash, bucket, and node interfaces are removed

> Should it be
> possible to create parser combinators? Should there be a JSON archive
> for Boost.Serialization? Should it replace parts of Boost.PropertyTree?

These are out of scope for my library. If parser combinators are
important, they can be developed as a separate library. The same goes
for bindings for Boost.Serialization and Boost.PropertyTree. Generally
speaking, I think new Boost library offerings need to be more
numerous, smaller, modular, and with fewer dependencies from now on. I
would like to break up Beast into 4 or 5 individual libraries at some
point (the logistics of that being not-yet-determined).

Thanks

[1] <https://www.jsonrpc.org/specification>
[2] <https://vinniefalco.github.io/doc/json/json/ref/boost__json__value.html>
[3] <https://vinniefalco.github.io/doc/json/json/ref/boost__json__object.html>
[4] <https://vinniefalco.github.io/doc/json/json/ref/boost__json__array.html>
[5] <https://vinniefalco.github.io/doc/json/json/ref/boost__json__string.html>
[6] <https://vinniefalco.github.io/doc/json/json/benchmarks.html>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Bjorn Reese wrote:

> Should there be a JSON archive for Boost.Serialization?

There are many possible ways to write Boost.Serialization JSON archives,
depending on the JSON produced. You could for instance output structs as
`{ "x": 1, "y": 2 }`, or `[ "x", 1, "y", 2 ]`, or `[ 1, 2 ]`, or even `{
"size": 3, "data": [ 1, 2 ] }`. The first representation is the most natural
and human-editable, but can't be deserialized incrementally because the
fields can come in any order. (Arrays can also include the size or not.)

Assuming we're talking about the first option, it should be possible to use
the proposed JSON library to implement a JSON input archive that reads from
a json::value. The output archive doesn't really need a library.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> or even `{ "size": 3, "data": [ 1, 2 ] }`.

Er, "size": 2 obviously. :-)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/17/19 7:40 AM, Peter Dimov via Boost wrote:
> Bjorn Reese wrote:
>
>> Should there be a JSON archive for Boost.Serialization?
>
> There are many possible ways to write Boost.Serialization JSON archives,
> depending on the JSON produced. You could for instance output structs as
> `{ "x": 1, "y": 2 }`, or `[ "x", 1, "y", 2 ]`, or `[ 1, 2 ]`, or even `{
> "size": 3, "data": [ 1, 2 ] }`.

> The first representation is the most natural and human-editable,

Human editable archives are something people ask for.  But it's not
really possible in a general way because archives have to reflect the
the C++ data structures that they correspond to.  If one want's to be
able to edit data off line - better would be to start with a free
standing archive design using something like google protocol buffers.
Then you're into the normal trade offs regarding such libraries.

> but can't be deserialized incrementally ...

Which is pretty much a requirement for a generally function
serialization system.

> Assuming we're talking about the first option, it should be possible to
> use the proposed JSON library to implement a JSON input archive that
> reads from a json::value. The output archive doesn't really need a library.

Implementing json for boost serialization should not be a target
requirement for a json library which is meant to be simple, efficient,
easy to use.

Implementing JSON for boost serialization wouldn't be very hard. I'm
suprised that in 15? years no one has done it.  In fact no one has even
asked for it!.  Were I to do it, I'd follow the design using boost
spirit which has served me well for many years.  It's easy to maintain,
relatively simple to implement, efficient enough so that no one has
complained about when used for xml.  It turned xml serializaton ( a dumb
concept I felt I had to implement) into a non-issue.

Robert Ramey


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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
On Sun, Nov 17, 2019 at 8:06 AM Robert Ramey via Boost
<[hidden email]> wrote:
> Implementing JSON for boost serialization wouldn't be very hard.

Sounds like this "not very hard" implementation using Boost.JSON with
Boost.Serialization is a perfect task for you as part of your upcoming
review of the library.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Robert Ramey wrote:

> Implementing JSON for boost serialization wouldn't be very hard. I'm
> surprised that in 15? years no one has done it.

Your second sentence should make you at least question the first one.

The problem is as I already outlined; if you want to support field
reordering, you need a JSON library like the one proposed, because you have
to parse the entire JSON into a `value` and then deserialize from the
`value`.

If you don't support field reordering, the format would basically only
interoperate with itself, which defeats the purpose of using JSON. You might
as well just use the text archive.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
On 11/17/19 8:57 AM, Peter Dimov via Boost wrote:
> Robert Ramey wrote:
>
>> Implementing JSON for boost serialization wouldn't be very hard. I'm
>> surprised that in 15? years no one has done it.
>
> Your second sentence should make you at least question the first one.
>
> The problem is as I already outlined; if you want to support field
> reordering,

serialization doesn't require reordering.  the json reader for
serialization only needs to be able to read archives created by the json
writer for serialization which specifies the order.

> If you don't support field reordering, the format would basically only
> interoperate with itself, which defeats the purpose of using JSON. You
> might as well just use the text archive.

Exactly.  Which is probably why no one ever bothered to write a JSON
archive.  Which is exactly the reason that writing an xml version was an
unnecessary waste of time.

The idea that it's possible to make an "editable archive" with XML or
JSON or anything else is fundamentally false.  There is no way that one
could map in the general case an "edited" archive to a pre-determined
C++ data structure.  Of course one could conjure up some specific cases
where it would be conceivable - but then we be in the C++ committee trap
of engaging in a fools errand of trying to implement a general idea by
specifying a bunch of special cases.  Nothing would be served by going
there.

If someone wants to make a JSON version of boost serialization that's
fine.  But don't think that you can make an implementation which is
independent of the C++ data structures being serialized.

Look to a different model.  Ideally one would have parse JSON to some
general C++ format which one can then pick through and retrieve what he
wants or determine that it's not in there.  Another way to think about
it is to replace google protocol  buffers.  The later requires that you
make a separate structural syntax which is a pain.  But protocol buffers
is even more popular than boost serialization.  So I think a Boost JSON
parser would success.

My personal requirements for such a system would be:

a) ability to handle unlimited/unterminated data.  As data is read in -
an event is triggered when a grammatical element is recognized.

b) Events are implemented by the users (though the library would provide
a bunch of defaults).  This provides for infinite flexibility, parallel
execution for large datasets.

c) Of course such a system could be implemented in a direct, verifiably
correct manner with boost spirit.  I don't know what the performance
implications would be.  Boost XML de-serialization has been done by
spirit (first version) for 15 years and no one has complained about the
speed.  Whenever anyone complains about the speed of text based archives
it always goes back to the file system - which presumably would be the
case with any JSON library.

Robert Ramey


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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Nov 17, 2019 at 11:06 AM Robert Ramey via Boost
<[hidden email]> wrote:

>
> On 11/17/19 7:40 AM, Peter Dimov via Boost wrote:
> > Bjorn Reese wrote:
> >
> >> Should there be a JSON archive for Boost.Serialization?
> >
> > There are many possible ways to write Boost.Serialization JSON archives,
> > depending on the JSON produced. You could for instance output structs as
> > `{ "x": 1, "y": 2 }`, or `[ "x", 1, "y", 2 ]`, or `[ 1, 2 ]`, or even `{
> > "size": 3, "data": [ 1, 2 ] }`.
>
> > The first representation is the most natural and human-editable,
>
> Human editable archives are something people ask for.  But it's not
> really possible in a general way because archives have to reflect the
> the C++ data structures that they correspond to.  If one want's to be
> able to edit data off line - better would be to start with a free
> standing archive design using something like google protocol buffers.
> Then you're into the normal trade offs regarding such libraries.
>

Since you already support JSON, if you supported YAML as well, you would
satisfy the human editable request.

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
On 11/17/19 11:41 AM, James E. King III via Boost wrote:
> On Sun, Nov 17, 2019 at 11:06 AM Robert Ramey via Boost

>> Human editable archives are something people ask for.  But it's not
>> really possible in a general way because archives have to reflect the
>> the C++ data structures that they correspond to.  If one want's to be
>> able to edit data off line - better would be to start with a free
>> standing archive design using something like google protocol buffers.
>> Then you're into the normal trade offs regarding such libraries.
>>
>
> Since you already support JSON, if you supported YAML as well, you would
> satisfy the human editable request.

Hmmm - did you read the above?  Of course serialization could support
JSON, YAML, or even some version of the english language.  But this
would not mean the the archive is editable unless it's write only. The
problem is that the archive contents are strictly dependent upon the C++
data structures being serialized.  If you edit the archive in a general
way, that is not necessarily preserving the original structure, it won't
map the the C++ data structure.  So what would be the point?  If you
restrict your editing to some specific requirements - like just changing
some data values - it would be pretty complex to specify and enforce
which kinds of editing are allowed.  Much easier would be just to write
a general purpose JSON parser which the user can one way or another map
to his C++ data structure.


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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
On 11/17/19 11:58 AM, Robert Ramey via Boost wrote:
> On 11/17/19 11:41 AM, James E. King III via Boost wrote:
>> On Sun, Nov 17, 2019 at 11:06 AM Robert Ramey via Boost
>
> Hmmm - did you read the above?  Of course serialization could support
> JSON, YAML, or even some version of the english language.  But this
> would not mean the the archive is editable unless it's write only. The
> problem is that the archive contents are strictly dependent upon t
Off topic - nothing to do with parsing - but interesting and sort of
related.

write only archives in fact do have a usage.  Suppose you want to create
some sort of log - debug, transaction, etc....  It's a pain to include
all that formating code in your app - especially since you're not
usually using it.  And you've mixed in the formating into your program
creating a maintainence PITA.  Its worse since the minute you do that
everyone and his brother will want a different format or for the screen
or PDF or ...

Solution - a write only XML archive!

Create the XML archive and write to in the normal serialization way.
Then let every user use his own XSLT script to transform into doc book
or whatever.  Then using docbook-> hmtl, or docbook pdf, or -> ... to
produce his desired output.  Actually since the archive is write only,
you could also edit it using your favorite XML editor.

This is rich territory that so far no one (besides myself) has ever
mined.  Ironically, the one person who thought it was a waste of time to
invest effort in an XML archive (me) is likely the only person who every
found a useful purpose for it (besides debugging).

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, 16 Nov 2019 at 19:09, Vinnie Falco via Boost <[hidden email]>
wrote:

> My JSON library is going to propose to Boost soon, is there anyone who
> might be willing and able to function in the role of review manager?


Great idea. Once again you’re serving the needs of c++ enthusiasts who
value utility. Thank you.

I’m probably not qualified to engage in review but I wanted to offer my
support.

This is a great compliment to beast when writing c++ programs that must
interface with node et al. Something I do a lot of.

Until now I have used nlohmann because it’s easy. If this library is as
easy but more efficient, then we all win.



>
> Thanks!
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
On 11/17/19 3:52 PM, Richard Hodges via Boost wrote:
> On Sat, 16 Nov 2019 at 19:09, Vinnie Falco via Boost <[hidden email]>
> wrote:
>

>
> I’m probably not qualified to engage in review

LOL - of course you're qualified.  We always need more reviewers who
actually have some real world experience using similar libraries.

> This is a great compliment to beast when writing c++ programs that must
> interface with node et al. Something I do a lot of.
>
> Until now I have used nlohmann because it’s easy.

Right - we can always reviews from people who know what it means for
something to be easy.

> If this library is as
> easy but more efficient, then we all win.
>
>
>
>>
>> Thanks!
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Nov 17, 2019 at 3:53 PM Richard Hodges <[hidden email]> wrote:
> I’m probably not qualified to engage in review

Actually quite the opposite, you would be an ideal reviewer because
your current use-case uses JSON and you would be in the best position
to report on the extent to which Boost.JSON fulfills that current
need.

Thanks!

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
OK, I'll make some time (somehow) to retrofit it into liquid's market data
distribution code. We have good timing metrics in that plant, and it's
battle-hardened in production.



On Mon, 18 Nov 2019 at 01:21, Vinnie Falco <[hidden email]> wrote:

> On Sun, Nov 17, 2019 at 3:53 PM Richard Hodges <[hidden email]> wrote:
> > I’m probably not qualified to engage in review
>
> Actually quite the opposite, you would be an ideal reviewer because
> your current use-case uses JSON and you would be in the best position
> to report on the extent to which Boost.JSON fulfills that current
> need.
>
> Thanks!
>


--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Nov 17, 2019 at 3:38 PM Vinnie Falco via Boost <
[hidden email]> wrote:

> [...] RapidJSON is currently the top-performing library for parsing and
> serialization using a general purpose container (I don't count
> SIMDJson, which produces a read-only structure). In comparison to
> RapidJSON, my library outperforms RapidJSON in most cases and
> completely blows away nlohmann [6].
>

Looking at your own benchmarks, that's not obvious to me, at least on the
parsing side.

  [6] <https://vinniefalco.github.io/doc/json/json/benchmarks.html>

Regarding those benchmarks, could you please:
1) provide synthetic graphs?
2) better explain what the benchmark does? Those sizes and durations
yield very low throughput numbers,
 so you're obviously doing the parsing several times in a loop, so please
adds details on that page, and
 calculate the real MB/s throughput as well please. Also peak memory would
be of interest.
3) Smallest files parsed is ~ 600KB, while in some (important IMHO)
use-cases, it's much smaller files
 of just a few bytes or low-KBs, but lots of them (thousands, millions). In
such cases, the constant-overhead
 of setting up the parser matters and/or instantiating the root value
matters, since might dominate over the parsing time.
 Would it be possible to test that use case too please?

Could you also please explain (or link to) on that page the PROs and CONs
of default vs block storage
for boot::json::value? There seems to be a speed advantage, so what's the
catch since not the default?

Thanks for the detailed post and your efforts to propose this to Boost.
Might be my first review. --DD

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
On Mon, Nov 18, 2019 at 1:14 AM Dominique Devienne via Boost
<[hidden email]> wrote:
> Also peak memory would be of interest.

How do you calculate this?

> Could you also please explain (or link to) on that page the PROs and CONs
> of default vs block storage for boot::json::value?

I added this page of exposition:

<https://vinniefalco.github.io/doc/json/json/usage/storage.html>

Still working on the benchmarks...

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Jason is getting MARRIED!

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Nov 18, 2019 at 1:14 AM Dominique Devienne via Boost
<[hidden email]> wrote:

> Regarding those benchmarks, could you please:
> 1) provide synthetic graphs?
> 2) better explain what the benchmark does? Those sizes and durations
> yield very low throughput numbers,
>  so you're obviously doing the parsing several times in a loop, so please
> adds details on that page, and
>  calculate the real MB/s throughput as well please. Also peak memory would
> be of interest.
> 3) Smallest files parsed is ~ 600KB, while in some (important IMHO)
> use-cases, it's much smaller files
>  of just a few bytes or low-KBs, but lots of them (thousands, millions). In
> such cases, the constant-overhead
>  of setting up the parser matters and/or instantiating the root value
> matters, since might dominate over the parsing time.
>  Would it be possible to test that use case too please?

How about this

<https://vinniefalco.github.io/doc/json/json/benchmarks.html>

Thanks

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