[epochs] Proposal for an epoch-based organization of Boost libraries

Joaquin M López Muñoz

23 May 2020 23 May '20

9:56 a.m.

Hi, Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list: https://github.com/joaquintides/boost_epoch/blob/master/README.md I hope the proposal can start a productive conversation. Looking forward to your feedback. Best, Joaquín M López Muñoz [1]: https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/

Show replies by date

Andrey Semashev

23 May 23 May

11:24 a.m.

On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:

...

Hi,

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward to your feedback.

...

if you were writing a new candidate Boost library with C++11 as its

From the article: baseline, would you strive to use std components rather than their Boost counterparts, no matter how good the latter are? I would say you would. I would not. As a user (either in-Boost or external) I would choose the library that is technically better. Boost.Regex is actually a very good example of such, as it is considerably faster than at least some popular std::regex implementations. There are other examples where Boost equivalents are technically better in one regard or another than the standard counterparts. I do not think discouraging use of (better) Boost libraries just because there is a counterpart in the standard library is a good idea. Using the best available tool should be a welcome choice on Boost developers side. Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions? Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already. The above examples are not an exception. I think, almost every library that was adopted by the standard is not equivalent to the standard component. Some of them have continued to evolve since adoption, and results of this evolution may be adopted by the standard in the future. I see no point in creating new versions of such libraries on each iteration of such adoption.

degski

3:56 p.m.

On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:

...
Hi,

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward to your feedback.

From the article:

...
if you were writing a new candidate Boost library with C++11 as its baseline, would you strive to use std components rather than their Boost counterparts, no matter how good the latter are? I would say you would.

I would not. As a user (either in-Boost or external) I would choose the library that is technically better. Boost.Regex is actually a very good example of such, as it is considerably faster than at least some popular std::regex implementations. There are other examples where Boost equivalents are technically better in one regard or another than the standard counterparts.

The Microsoft STL is now open source (I'm sure you've all heard about it), So in the case of Microsoft, it suffices to create a PR and upstream the better boost library. I believe (to know) for boost::regex this has already happened or is going to happen. Boost should adopt <charconv> from Microsoft. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

Andrey Semashev

4:16 p.m.

On 2020-05-23 18:56, degski via Boost wrote:

...

On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...
On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:

...
Hi,

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward to your feedback.

From the article:

...
if you were writing a new candidate Boost library with C++11 as its baseline, would you strive to use std components rather than their Boost counterparts, no matter how good the latter are? I would say you would.

I would not. As a user (either in-Boost or external) I would choose the library that is technically better. Boost.Regex is actually a very good example of such, as it is considerably faster than at least some popular std::regex implementations. There are other examples where Boost equivalents are technically better in one regard or another than the standard counterparts.

The Microsoft STL is now open source (I'm sure you've all heard about it), So in the case of Microsoft, it suffices to create a PR and upstream the better boost library. I believe (to know) for boost::regex this has already happened or is going to happen. Boost should adopt <charconv> from Microsoft.

What if I don't use MSVC? Also, I'm not sure compiler vendors would be willing to accept non-standard extensions. Certainly, not all vendors would. Part of the reason why Boost exists is that such extensions have a place to be and could be used regardless of your compiler. That said, I absolutely welcome improvements in standard libraries.

Rene Rivera

10:33 p.m.

On Sat, May 23, 2020 at 10:56 AM degski via Boost wrote:

...

The Microsoft STL is now open source (I'm sure you've all heard about it), So in the case of Microsoft, it suffices to create a PR and upstream the better boost library. I believe (to know) for boost::regex this has already happened or is going to happen. Boost should adopt <charconv> from Microsoft.

Given the differing licenses not sure how that's possible. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

degski

4:15 p.m.

On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions? Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already.

The progression could be signified by another 'insertion mode' : increases begin(*X*) and executes end(*X*) = begin (*X*) +1. The epoch proposal is nice, thumbs up. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

Andrey Semashev

4:21 p.m.

On 2020-05-23 19:15, degski via Boost wrote:

...

On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...
Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions? Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already.

The progression could be signified by another 'insertion mode' : increases begin(*X*) and executes end(*X*) = begin (*X*) +1.

I'm not sure what you mean here.

degski

4:31 p.m.

On Sat, 23 May 2020 at 11:21, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

On 2020-05-23 19:15, degski via Boost wrote:

...
On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...
Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions? Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already.

The progression could be signified by another 'insertion mode' : increases begin(*X*) and executes end(*X*) = begin (*X*) +1.

I'm not sure what you mean here.

Like in the proposal [in this idea] the library is frozen (kicked out), but really not, the improvements that come after the frozen epoch are included in an annual 'update', of that years epoch. So you can (should be able to) keep on choosing between the boost and the std version on an epoch basis. One can express this idea by begin(*X*) and executes end(*X*) = begin (*X*) +1, as I suspect this rule will be implemented. That was the gist of it. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

Joaquin M López Muñoz

24 May 24 May

8:40 a.m.

El 23/05/2020 a las 13:24, Andrey Semashev via Boost escribió:

...

On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:

...
Hi,

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward to your feedback.

From the article:

...
if you were writing a new candidate Boost library with C++11 as its baseline, would you strive to use std components rather than their Boost counterparts, no matter how good the latter are? I would say you would.

I would not. As a user (either in-Boost or external) I would choose the library that is technically better. Boost.Regex is actually a very good example of such, as it is considerably faster than at least some popular std::regex implementations. There are other examples where Boost equivalents are technically better in one regard or another than the standard counterparts.

Boost.Regex is admittedly a controversial point (as mentionedin the proposal) due to its superior quality to some std implementations. But there are other components whose usage I find it hard to justify, such as Boost.Array and Boost.Tuple (there may be others). Whatever the intrinsic qualities of these foundational libraries, they seem to totally be losing the PR battle against std counterparts (if that was a battle to begin with, that is): https://github.com/joaquintides/boost_epoch/blob/master/boost_vs_std.md

...

[...]

Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions?

In the section quote from, "progress" means "be given the newer epoch badge". I'm not referring to preventing the author from evolving their lib, which is their unalienable right.

...

Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already.

The above examples are not an exception. I think, almost every library that was adopted by the standard is not equivalent to the standard component. Some of them have continued to evolve since adoption, and results of this evolution may be adopted by the standard in the future. I see no point in creating new versions of such libraries on each iteration of such adoption.

The crucial point here is to what degree this extra functionality in Boost.X is actually used by other Boost libraries when Boost.X is a dependency. I don't have hard data (you don't provide any either) but I suspect this degree is very low. On a more philosophical note, one of the goals of Boost is: "We aim to establish 'existing practice' and provide reference implementations so that Boost libraries are suitable for eventual standardization." In this regard, Boost has been extremely successful up to C++11, moderately so ever since. But one aspect that wasn't planned or even discussed when Boost started 22 years ago is: what do we do after standardization. Epochs is one answer to that. Regardless of the merits of this proposal, I think we owe ourselves a discussion around this central topic of coexisting with an evolving standard that is expected (and helped) to take over much of the user base of components originated outside. Joaquín M López Muñoz

Peter Dimov

2:15 p.m.

Joaquin M López Muñoz wrote:

...

Boost.Regex is admittedly a controversial point (as mentionedin the proposal) due to its superior quality to some std implementations.

There's nothing controversial about it. As of 2020, it should always be preferred over std::regex.

Joaquin M López Muñoz

4:44 p.m.

El 24/05/2020 a las 16:15, Peter Dimov via Boost escribió:

...

Joaquin M López Muñoz wrote:

...
Boost.Regex is admittedly a controversial point (as mentionedin the proposal) due to its superior quality to some std implementations.

There's nothing controversial about it.

I meant controversial as for epoch asignment within this proposal.

...

As of 2020, it should always be preferred over std::regex.

I shouldn't comment on opinions outside the scope of the proposal lest we wander off, but obviously not everybody agrees always with this assessment, not even within Boost: https://github.com/boostorg/fiber/blob/df4a190f5b92ba86395cf58b1040ed295caf9... https://github.com/boostorg/hana/blob/07b42492765f7384e053c4761f4d0eda32b758... That said, I'm with you Boost.Regex is a superb library. Joaquín M López Muñoz

Dimitri John Ledkov

25 May 25 May

8:28 a.m.

On Sun, 24 May 2020, 15:16 Peter Dimov via Boost, wrote:

...

Joaquin M López Muñoz wrote:

...
Boost.Regex is admittedly a controversial point (as mentionedin the proposal) due to its superior quality to some std implementations.

There's nothing controversial about it. As of 2020, it should always be preferred over std::regex.

Boost-regex depends on ICU, and re-exports ICU symbols making its ABI dependent on ICU ABI. In Ubuntu we split publish boost. Up until 2016, there were packages in "main" section that used boost-regex, since 2018 there are none - meaning either stuff switched to std::regex or got demoted from "main" for other reasons. I think it does line up with Ubuntu defaulting to c++11. If boost-regex is better, should Ubuntu switch to it as the default std::regex provider? Such that anything built on or for Ubuntu uses the faster implementation? Regards, Dimitri.

...

Peter Dimov

1:26 p.m.

Dimitri John Ledkov wrote:

...

If boost-regex is better, should Ubuntu switch to it as the default std::regex provider? Such that anything built on or for Ubuntu uses the faster implementation?

Probably not, all things considered. libstdc++ has a relatively good std::regex (by Tim Shen); in Boost.Regex's own benchmarks it's occasionally slower by a factor of 37: https://www.boost.org/doc/libs/1_73_0/libs/regex/doc/html/boost_regex/backgr... but typically holds its own. libc++ seems the worst of the three; in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1433r0.pdf it's slower by a factor of 80.

Andrey Semashev

2:59 p.m.

On 2020-05-25 11:28, Dimitri John Ledkov via Boost wrote:

...

If boost-regex is better, should Ubuntu switch to it as the default std::regex provider? Such that anything built on or for Ubuntu uses the faster implementation?

As a user of Ubuntu, I would certainly prefer if the faster implementation was used (which is Boost.Regex). That said, I think it's not so much a choice of Ubuntu (or Debian) package maintainers but rather that of the upstream projects. Somewhat on that note, just recently I (among other users) reported a KDE performance bug[1] which appeared in the latest Kubuntu and turned out to be caused by std::regex. The currently proposed solution is to replace it with a manual parser. [1]: https://bugs.kde.org/show_bug.cgi?id=414036

Alexander Grund

10:06 a.m.

...

...
if you were writing a new candidate Boost library with C++11 as its baseline, would you strive to use std components rather than their Boost counterparts, no matter how good the latter are? I would say you would.

I would not. As a user (either in-Boost or external) I would choose the library that is technically better. Boost.Regex is actually a very good example of such, as it is considerably faster than at least some popular std::regex implementations. There are other examples where Boost equivalents are technically better in one regard or another than the standard counterparts. I think this is the point with using any dependencies: Is the added value (in performance, features, ...) worth the cost (compile time increase, maintaining compatibility, ...) And as stated above: Using a stdlib part is not considered a dependency by most. Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions? Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already.

The above examples are not an exception. I think, almost every library that was adopted by the standard is not equivalent to the standard component. Some of them have continued to evolve since adoption, and results of this evolution may be adopted by the standard in the future. I see no point in creating new versions of such libraries on each iteration of such adoption.

There is no reason. The point of the proposal is to reduce dependencies and hence "bloat" most users complain about. Boost.Atomic can stay Boost03 and be fine. If it has features the std variant does not have AND does not use other Boost libraries subsumed by the std then it would even be considered part of Boost20

...

The Microsoft STL is now open source (I'm sure you've all heard about it), So in the case of Microsoft, it suffices to create a PR and upstream the better boost library

Sadly not. It mustn't break ABI. Example: I proposed they implement the never-valueless variant for cases where this is possible the same as GCC/Clang do, but it was refused due to ABI. So good luck with boost::regex...

...

User perceptions about bloat may be related to the download size.

It is also about compile times and binary size. Using MP11 over MPL reduces the former, using std:: types over boost types (may) allow to generate less code as template instantiations of the types in use are also used in user code already. So using `std::optional<bool>` in user code and `boost::optional<bool>` in boost internals or interfaces means twice the code for the same functionality (unless references inside are used of course)

...

But I fear that (like other projects like Cmake) the BIG hurdle that we struggle to get over, is *resources*.

This is the main point of the proposal: It is a gradual way. Lets say it is "switch to C++11 - lite". No one is forced to do anything but developers are incentivized to drop dependencies where possible and there would be a way to measure progress. This can happen Boy-Scout-Rule: Where you fix stuff, clean/update the surroundings. Gradually you'll have a "clean"/updated library

...

Tests and tests data are another area that many users rarely use, but separately them would be a big task.

Sorry? Simply remove all test folders before uploading the tarball. Done. For the tests-release: Simply remove all folders BUT the test folder. The names are standard already so that is easy.

...

Boost.MPL and Boost.Mp11 are very different in API, which means that a library that uses template metaprogramming and wants to support C++03 and later cannot be compliant with the Epoch requirements, unless it contains two versions of the TMP code

That is one of the points of the epoch proposal: MPL has known shortcomings (mostly compiletime) that are "fixed" in a C++11 library (MP11). So the authors/maintainers are incentivized to drop the MPL dependency for MP11. if they don't because they care about C++03 (from your statement above) for some reason, they (rightfully) don't get a badge saying "Boost11". So what? No harm done except C++11 and up users know the lib uses some old/slow dependency and can decide to not use it if they don't deem this useful enough to offset the cost (see top)

Andrey Semashev

10:41 a.m.

On 2020-05-25 13:06, Alexander Grund via Boost wrote:

...

...
Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions? Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already.

The above examples are not an exception. I think, almost every library that was adopted by the standard is not equivalent to the standard component. Some of them have continued to evolve since adoption, and results of this evolution may be adopted by the standard in the future. I see no point in creating new versions of such libraries on each iteration of such adoption.

There is no reason. The point of the proposal is to reduce dependencies and hence "bloat" most users complain about. Boost.Atomic can stay Boost03 and be fine. If it has features the std variant does not have AND does not use other Boost libraries subsumed by the std then it would even be considered part of Boost20

What I'm saying is most of the libraries that were adopted by the standard have features that were not (yet) adopted. And prohibiting further evolution of these libraries beyond the standard set of features is not a wise decision.

...

...
Boost.MPL and Boost.Mp11 are very different in API, which means that a library that uses template metaprogramming and wants to support C++03 and later cannot be compliant with the Epoch requirements, unless it contains two versions of the TMP code

That is one of the points of the epoch proposal: MPL has known shortcomings (mostly compiletime) that are "fixed" in a C++11 library (MP11). So the authors/maintainers are incentivized to drop the MPL dependency for MP11. if they don't because they care about C++03 (from your statement above) for some reason, they (rightfully) don't get a badge saying "Boost11". So what? No harm done except C++11 and up users know the lib uses some old/slow dependency and can decide to not use it if they don't deem this useful enough to offset the cost (see top)

Note that we don't have a technical reason for adopting any kind of tags for libraries. The proposal is primarily targeted at solving the PR problem of Boost. Saying that a library is Boost03 (and not Boost11 and later) is not solving the PR problem for the library, it's creating one. If you're really are concerned about technical deficiencies of some libraries (e.g. Boost.MPL) then the right solution is to work on improving those libraries.

Alexander Grund

11:42 a.m.

...

What I'm saying is most of the libraries that were adopted by the standard have features that were not (yet) adopted. And prohibiting further evolution of these libraries beyond the standard set of features is not a wise decision. What I'm saying is there is no one prohibiting anything. The epoch is only a label which correlates with "reduced bloat", you don't "need" it. Note that we don't have a technical reason for adopting any kind of tags for libraries. Correct. Those tags are meant as an incentive The proposal is primarily targeted at solving the PR problem of Boost.

Yes, by improving the most often named problem of Boost: Unnecessary compile time increase. Example from recent reddit:

...

of the major problem we had with Boost was that its use had a big impact in the compilation time, mostly due to the many headers and templates to parse and to the symbol duplication in the object files https://medium.com/@julienjorge/testing-c-signal-slot-libraries-1994eb120826

...

Saying that a library is Boost03 (and not Boost11 and later) is not solving the PR problem for the library, it's creating one.

No. It is improving the performance (overall) of Boost11 and up, produces good PR for those while giving users and developers a hint on what the library relies on Again: If e.g. Boost.Atomic is enhanced and improved over the std-counterpart and Boost.FooBar needs these enhancements then it can use it. But if Boost.FooBar does not need those or if Boost.Atomic does not provide any benefit (anymore), then why pay the cost for the additional dependency which is paid by all users? Or make users come up with own implementations for the 100th time because "the compiletime performance of Boost sucks".

...

If you're really are concerned about technical deficiencies of some libraries (e.g. Boost.MPL) then the right solution is to work on improving those libraries. Again, the point is to reduce dependencies. So the "technical deficienc[y]" in most cases is the usage of another boost library alone. And in the case of MPL: The solution already exists and is called Boost.MP11

Andrey Semashev

12:06 p.m.

On 2020-05-25 14:42, Alexander Grund via Boost wrote:

...

...
Saying that a library is Boost03 (and not Boost11 and later) is not solving the PR problem for the library, it's creating one.

No. It is improving the performance (overall) of Boost11 and up, produces good PR for those while giving users and developers a hint on what the library relies on

Again: If e.g. Boost.Atomic is enhanced and improved over the std-counterpart and Boost.FooBar needs these enhancements then it can use it. But if Boost.FooBar does not need those or if Boost.Atomic does not provide any benefit (anymore), then why pay the cost for the additional dependency which is paid by all users?

And if Boost.FooBar wants to support C++03 for some reason then you would mark it Boost03 only. This is bad PR for no reason. Again, if you want to give users a way to reduce dependencies then work on that. This is a technical task. Work on modularization, documentation, configurability, reducing the cost of C++03 support, etc. Tagging or otherwise ranging libraries is not involved in any of this, and C++03 (or any other) libraries are not penalized in the process.

...

Or make users come up with own implementations for the 100th time because "the compiletime performance of Boost sucks".

That's their right and their decision. I bet you many users will still find reasons not to use Boost or any other libraries, really. That's not to say Boost doesn't need to improve or has no problems. It's just don't expect people to stop reinventing the wheel.

...

...
If you're really are concerned about technical deficiencies of some libraries (e.g. Boost.MPL) then the right solution is to work on improving those libraries. Again, the point is to reduce dependencies. So the "technical deficienc[y]" in most cases is the usage of another boost library alone. And in the case of MPL: The solution already exists and is called Boost.MP11

If you mean "dropping support for C++03" by that then yes, that is one way. Maintaining backward compatibility and using Boost.MPL because of that is another, and it must be as viable option as others.

Joaquin M López Muñoz

4:38 p.m.

El 25/05/2020 a las 14:06, Andrey Semashev via Boost escribió:

...

[...]

And if Boost.FooBar wants to support C++03 for some reason then you would mark it Boost03 only. This is bad PR for no reason.

A library can support C++03 and yet be in epochs 11 and later.

...

[...]

Maintaining backward compatibility and using Boost.MPL because of that is another, and it must be as viable option as others.

It's a viable option, but then the lib won't get into Boost11, unless Boost.MPL inclusion is conditional on BOOST_ASSUME_CXX. Not being in epoch Boost11 does not mean the lib can't be actively maintained and work in C++11 and later (which is mostly the case for C++03-compatible code). Joaquín M López Muñoz

Edward Diener

7:32 p.m.

On 5/25/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:

...

El 25/05/2020 a las 14:06, Andrey Semashev via Boost escribió:

...
[...]

And if Boost.FooBar wants to support C++03 for some reason then you would mark it Boost03 only. This is bad PR for no reason.

A library can support C++03 and yet be in epochs 11 and later.

...
[...]

Maintaining backward compatibility and using Boost.MPL because of that is another, and it must be as viable option as others.

It's a viable option, but then the lib won't get into Boost11, unless Boost.MPL inclusion is conditional on BOOST_ASSUME_CXX. Not being in epoch Boost11 does not mean the lib can't be actively maintained and work in C++11 and later (which is mostly the case for C++03-compatible code).

I think you need to explain in your document that the criteria for a library to be in an Epoch level of c++11 on up is that the library depends on a C++ standard library rather than its Boost equivalent in any cases where this dependency might exist, as well as the fact that the library depends on other Boost libraries, in any cases where this dependency might exist, which themselves follow the C++ standard versus Boost library criteria. I personally would support such an idea for Epocjs. But I would want the decision based on the Epoch to which a library may belong to be solely based on this objective criteria, and not on any subjective idea of what constitutes a C++nn library or not.

Joaquin M López Muñoz

26 May 26 May

2:20 p.m.

El 25/05/2020 a las 21:32, Edward Diener via Boost escribió:

...

On 5/25/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:

...
El 25/05/2020 a las 14:06, Andrey Semashev via Boost escribió:

...
Maintaining backward compatibility and using Boost.MPL because of that is another, and it must be as viable option as others.

It's a viable option, but then the lib won't get into Boost11, unless Boost.MPL inclusion is conditional on BOOST_ASSUME_CXX. Not being in epoch Boost11 does not mean the lib can't be actively maintained and work in C++11 and later (which is mostly the case for C++03-compatible code).

I think you need to explain in your document that the criteria for a library to be in an Epoch level of c++11 on up is that the library depends on a C++ standard library rather than its Boost equivalent in any cases where this dependency might exist, as well as the fact that the library depends on other Boost libraries, in any cases where this dependency might exist, which themselves follow the C++ standard versus Boost library criteria. I personally would support such an idea for Epocjs. But I would want the decision based on the Epoch to which a library may belong to be solely based on this objective criteria, and not on any subjective idea of what constitutes a C++nn library or not.

Yes, in the context of the proposal you're referring to so-called "rejection rule 2", which is practically custom-made for the case of Boost.MPL. I personally find that this lib, which was a breakthrough back in the day, now it's too much of a burden in non-C++03 environments, given the much lighter alternatives. If epochs were ever a reality, I'd vote for deferring the exact decision on which "core" libraries promote to one central authority (the BSC, most likely), because there'd be controversy one way or another. This is just speculation right now, though. Joaquín M López Muñoz

Edward Diener

27 May 27 May

8:32 a.m.

On 5/26/2020 10:20 AM, Joaquin M López Muñoz via Boost wrote:

...

El 25/05/2020 a las 21:32, Edward Diener via Boost escribió:

...
On 5/25/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:

...
El 25/05/2020 a las 14:06, Andrey Semashev via Boost escribió:

...
Maintaining backward compatibility and using Boost.MPL because of that is another, and it must be as viable option as others.

It's a viable option, but then the lib won't get into Boost11, unless Boost.MPL inclusion is conditional on BOOST_ASSUME_CXX. Not being in epoch Boost11 does not mean the lib can't be actively maintained and work in C++11 and later (which is mostly the case for C++03-compatible code).

I think you need to explain in your document that the criteria for a library to be in an Epoch level of c++11 on up is that the library depends on a C++ standard library rather than its Boost equivalent in any cases where this dependency might exist, as well as the fact that the library depends on other Boost libraries, in any cases where this dependency might exist, which themselves follow the C++ standard versus Boost library criteria. I personally would support such an idea for Epocjs. But I would want the decision based on the Epoch to which a library may belong to be solely based on this objective criteria, and not on any subjective idea of what constitutes a C++nn library or not.

Yes, in the context of the proposal you're referring to so-called "rejection rule 2", which is practically custom-made for the case of Boost.MPL. I personally find that this lib, which was a breakthrough back in the day, now it's too much of a burden in non-C++03 environments, given the much lighter alternatives.

If epochs were ever a reality, I'd vote for deferring the exact decision on which "core" libraries promote to one central authority (the BSC, most likely), because there'd be controversy one way or another. This is just speculation right now, though.

I think the idea of a set of Boost libraries: 1) which do not have a C++ standard library equivalent 2) which do use one or more Boost libraries which do have a C++ standard library equivalent 3) producing an alternative version of an individual library which uses the C++ standard library equivalent(s) would be useful for end-users who want to use Boost in a C++11 on up environment where C++ standard equivalent libraries are being used. This is not a criticism in any way of any Boost libraries which have C++ standard library equivalents but rather an acknowledgment of the fact, suggested by cxx_dual originally, that end-users in C++11 on up environments most probably want to be able to consistently use the C++ standard libraries rather than to have to mix their use of such libraries with Boost equivalent libraries. But of course who would do the work, even given that a consensus were formed that this would be valuable to Boost in general, of creating alternative versions of all those Boost libraries, since many of those libraries are barely maintained as is in regards to issues and PRs, much less alternative versions meeting such a goal ?

Joaquin M López Muñoz

9:09 p.m.

El 27/05/2020 a las 10:32, Edward Diener via Boost escribió:

...

I think the idea of a set of Boost libraries:

1) which do not have a C++ standard library equivalent 2) which do use one or more Boost libraries which do have a C++ standard library equivalent 3) producing an alternative version of an individual library which uses the C++ standard library equivalent(s)

would be useful for end-users who want to use Boost in a C++11 on up environment where C++ standard equivalent libraries are being used. This is not a criticism in any way of any Boost libraries which have C++ standard library equivalents but rather an acknowledgment of the fact, suggested by cxx_dual originally, that end-users in C++11 on up environments most probably want to be able to consistently use the C++ standard libraries rather than to have to mix their use of such libraries with Boost equivalent libraries.

This is nicely aligned with the gols of the epochs proposal. I've just published a report that seems relevant for this conversation: https://github.com/joaquintides/boost_epoch/blob/master/boost_vs_std_interna... (

...

But of course who would do the work, even given that a consensus were formed that this would be valuable to Boost in general, of creating alternative versions of all those Boost libraries, since many of those libraries are barely maintained as is in regards to issues and PRs, much less alternative versions meeting such a goal ?

Firstly, we're far from having a consensus on this :-) That said, there's really no need to create alternative libs as long as some abstraction layer is plugged in, using something like cxx_dual for instance. In many cases this is routine work, but I agree with you the job is up to wiling authors (or the Boost Community Maintenance Team). Epochs merely try to make this effort more valuable/desireable from a PR point of view, as they give transparency about what's going on internally. If someone is willing to give this a shot (Boost.TTI?) I'd gladly volunteer to do a PR for such an abstraction layer. In most cases it's a no brainer (which is not to say it wil be done automagically). Removing C++03 support is even easier, FWIW. Joaquín M López Muñoz

degski

10:57 a.m.

On Tue, 26 May 2020 at 09:21, Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote:

...

Yes, in the context of the proposal you're referring to so-called "rejection rule 2", which is practically custom-made for the case of Boost.MPL. I personally find that this lib, which was a breakthrough back in the day, now it's too much of a burden in non-C++03 environments, given the much lighter alternatives.

Although I think the mechanics of the proposal are well worked out as I posted earlier, but on reflection, I don't think this is the right way forward. The world (linux had already) is moving to live-at-head, see the development of vcpkg. I consider this an old-school solution to a new-school problem, so it will stumble on. I think, that IIRC what pdimov5 suggested somewhere last year, to re-baptise master -> release, develop -> master, experimetal -> develop, and just live at head, is the best way forward. Doing a release comes down to adding a tag to a master-commit and everybody carries on busying themselves in experimental in the meanwhile. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

Joaquin M López Muñoz

9:10 p.m.

El 27/05/2020 a las 12:57, degski via Boost escribió:

...

On Tue, 26 May 2020 at 09:21, Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote:

...
Yes, in the context of the proposal you're referring to so-called "rejection rule 2", which is practically custom-made for the case of Boost.MPL. I personally find that this lib, which was a breakthrough back in the day, now it's too much of a burden in non-C++03 environments, given the much lighter alternatives.

Although I think the mechanics of the proposal are well worked out as I posted earlier, but on reflection, I don't think this is the right way forward. The world (linux had already) is moving to live-at-head, see the development of vcpkg. I consider this an old-school solution to a new-school problem, so it will stumble on. I think, that IIRC what pdimov5 suggested somewhere last year, to re-baptise master -> release, develop -> master, experimetal -> develop, and just live at head, is the best way forward. Doing a release comes down to adding a tag to a master-commit and everybody carries on busying themselves in experimental in the meanwhile.

In all honesty, I don't see how this idea (which seems interesting, BTW) is in any way connected to the epochs proposal. Would you care to elaborate? Thank you! Joaquín M López Muñoz

Brook Milligan

9:24 p.m.

...

On May 27, 2020, at 4:57 AM, degski via Boost wrote:

Although I think the mechanics of the proposal are well worked out as I posted earlier, but on reflection, I don't think this is the right way forward. The world (linux had already) is moving to live-at-head, see the development of vcpkg. I consider this an old-school solution to a new-school problem, so it will stumble on. I think, that IIRC what pdimov5 suggested somewhere last year, to re-baptise master -> release, develop -> master, experimetal -> develop, and just live at head, is the best way forward. Doing a release comes down to adding a tag to a master-commit and everybody carries on busying themselves in experimental in the meanwhile.

Just to be clear, do I understand you to mean by “live-at-head” that formal releases, with appropriate quality control, etc., are not a desirable requirement? It seems to me that there is indeed a trend in that direction. Increasingly, software seems to live in a repository somewhere with no releases whatsoever or very few at intermittent intervals. This means that quality control decisions are entirely left up to end users, who of course are rarely knowledgeable of the internals that in fact determine quality. At the very least, that places a large burden (researching each project and learning all the details) on a large population (the many users), to avoid a task (identifying a quality release) by those best positioned with the relevant knowledge (the author(s)). Exactly the opposite of the goal of reuse. I hope this is not your suggestion and that I have misunderstood. However, the clear trend elsewhere in this direction makes me wonder, so I would appreciate clarity on what you really think the “right way forward” is. Sorry if I mistook your intention. Thanks. Chees, Brook

Rene Rivera

28 May 28 May

1:34 a.m.

On Wed, May 27, 2020 at 4:32 PM Brook Milligan via Boost < boost@lists.boost.org> wrote:

...

...
On May 27, 2020, at 4:57 AM, degski via Boost wrote:

The world (linux had already) is moving to live-at-head

...

Just to be clear, do I understand you to mean by “live-at-head” that formal releases, with appropriate quality control, etc., are not a desirable requirement?

It seems to me that there is indeed a trend in that direction.

Since it's now been mentioned twice in this thread... We would need to see some statistics as to the claims that live-at-head is significant. As otherwise it just pollutes the conversation with hearsay. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Christopher Kormanyos

23 May 23 May

1:13 p.m.

> general feelings about Boost perceived lack> of modernization
> ... proposal for an epoch-based organization> of Boost libraries
I would welcome this. It does, however, sound likea reather large undertaking.
In a smaller but similar situation, I was once motivatedin my own research to identify various time epochsin C++.
Probably similar to others, I identified for my purposes:
1) Pre-C++11 (basically C++03)2) C++11 but no more.3) C++ newest
Intuitively, I think number 2 is a great first stepin moving and migrating toward moden C++.Most compilers are conformant with modernC++11 now, even embedded systems compilers.

Kind regards, Chris
Am Samstag, 23. Mai 2020, 11:57:26 MESZ hat Joaquin M López Muñoz via Boost Folgendes geschrieben:

Hi,

Prompted by general feelings about Boost perceived lack of modernization
and internal "bloat",
and after an explicit survey on what users dislike about Boost [1], I
decided to try and write a more
or less fleshed out proposal for an epoch-based organization of Boost
libraries. I've extensively
tested and refined the proposal during discussions on Reddit and the
Boost Slack channel,
and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward
to your feedback.

Best,

Joaquín M López Muñoz

[1]: https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/

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

Edward Diener

8:46 p.m.

On 5/23/2020 5:56 AM, Joaquin M López Muñoz via Boost wrote:

...

Hi,

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward to your feedback.

I wrote cxx_dual anticipating the problem that end-users might be disappointed that Boost libraries use other Boost libraries rather than C++11 on up equivalent libraries. So I am not at all surprised by some of the comments about Boost. I have always been for each library reporting what level of C++ that library supports, even in detail if the library optionally supports some features of later C++ standards. I do believe people overreact to dependencies, however. All good software design involves reusing established code when necessary. Reinventing code simply for the sake of less dependencies has always seemed to me a fool's game, unless there is a very good practical reason for not using established code. I am totally against the idea that some code which works perfectly in C++03, as well as all other C++ standard levels, needs to be unnecessarily updated to some later C++ standard level in order to be acceptable to anyone.

Joaquin M López Muñoz

24 May 24 May

8:20 a.m.

El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:

...

On 5/23/2020 5:56 AM, Joaquin M López Muñoz via Boost wrote:

...
Hi,

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward to your feedback.

I wrote cxx_dual [...]

I do believe people overreact to dependencies, however. All good software design involves reusing established code when necessary. Reinventing code simply for the sake of less dependencies has always seemed to me a fool's game, unless there is a very good practical reason for not using established code.

In this particular case, there are two establshed codes: Boost and std. Seems like some end users strongly favor the latter as it's not perceived as a real dependency in the sense that additional libs need be downloaded etc.

...

I am totally against the idea that some code which works perfectly in C++03, as well as all other C++ standard levels, needs to be unnecessarily updated to some later C++ standard level in order to be acceptable to anyone.

This looks somewhat at odds with one of the stated goals of your cxx_dual lib: "On a more practical basis the CXXD library is for: 1. Programmers writing code not using C++11 syntax who still want to target some C++11 libraries if the code is compiled in C++11 mode. [...]" Joaquín M Lopez Muñoz

Edward Diener

12:52 p.m.

On 5/24/2020 4:20 AM, Joaquin M López Muñoz via Boost wrote:

...

El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:

...
On 5/23/2020 5:56 AM, Joaquin M López Muñoz via Boost wrote:

...
Hi,

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward to your feedback.

I wrote cxx_dual [...]

I do believe people overreact to dependencies, however. All good software design involves reusing established code when necessary. Reinventing code simply for the sake of less dependencies has always seemed to me a fool's game, unless there is a very good practical reason for not using established code.

In this particular case, there are two establshed codes: Boost and std. Seems like some end users strongly favor the latter as it's not perceived as a real dependency in the sense that additional libs need be downloaded etc.

...
I am totally against the idea that some code which works perfectly in C++03, as well as all other C++ standard levels, needs to be unnecessarily updated to some later C++ standard level in order to be acceptable to anyone.

This looks somewhat at odds with one of the stated goals of your cxx_dual lib:

"On a more practical basis the CXXD library is for:

1. Programmers writing code not using C++11 syntax who still want to target some C++11 libraries if the code is compiled in C++11 mode. [...]"

I do not see why you think the statement above is at odds with what I previously asserted. Whatever might have been added to a Boost library which became a C++ standard library in C+11 or beyond could hardly have been done just to add unnecessary features. I am not against a library being updated to use features of a later C++ standard when those updates are predicated on improving a library in specific ways that make it worthwhile to add such features. The gist of your proposal which seems to me to be highly flawed is the idea that at a certain Epoch level all dependencies of a library must also exist at that same Epoch level or higher. How realistic is such a goal ? If library X at Epoch level nnn successfully uses library Y at Epoch level nnn-1, why should library Y be arbitrarily updated for no good practical reason to use C++ features of Epoch level nnn ? I am pretty sure you can see the absurdity of such a determination as that.

Joaquin M López Muñoz

4:38 p.m.

El 24/05/2020 a las 14:52, Edward Diener via Boost escribió:

...

On 5/24/2020 4:20 AM, Joaquin M López Muñoz via Boost wrote:

...
El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:

...
I am totally against the idea that some code which works perfectly in C++03, as well as all other C++ standard levels, needs to be unnecessarily updated to some later C++ standard level in order to be acceptable to anyone.

This looks somewhat at odds with one of the stated goals of your cxx_dual lib:

"On a more practical basis the CXXD library is for:

1. Programmers writing code not using C++11 syntax who still want to target some C++11 libraries if the code is compiled in C++11 mode. [...]"

I do not see why you think the statement above is at odds with what I previously asserted. Whatever might have been added to a Boost library which became a C++ standard library in C+11 or beyond could hardly have been done just to add unnecessary features. I am not against a library being updated to use features of a later C++ standard when those updates are predicated on improving a library in specific ways that make it worthwhile to add such features.

I'm not sure I'm parsing your sentences right, but does that mean you're ok with a library using cxx_dual from scracth but not ok if a Boost-reliant lib is later updated via cxx_dual *only* to reduce Boost dependencies in C++11?

...

The gist of your proposal which seems to me to be highly flawed is the idea that at a certain Epoch level all dependencies of a library must also exist at that same Epoch level or higher. How realistic is such a goal ? If library X at Epoch level nnn successfully uses library Y at Epoch level nnn-1, why should library Y be arbitrarily updated [...]

I understand you meant "should library X be arbitrarily updated" here.

...

[...]for no good practical reason to use C++ features of Epoch level nnn ?

The reason is to reduce internal Boost dependencies.

...

I am pretty sure you can see the absurdity of such a determination as that.

I admire your confidence but not your perspicacity, as I indeed see no absurdity here. Take for instance Boost.Beast, which depends on boost::string_view but can be made to depend on std::string_view instead via BOOST_BEAST_USE_STD_STRING_VIEW. Shall I take that you deem this ability absurd? Joaquín M López Muñoz

Edward Diener

6:02 p.m.

On 5/24/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:

...

El 24/05/2020 a las 14:52, Edward Diener via Boost escribió:

...
On 5/24/2020 4:20 AM, Joaquin M López Muñoz via Boost wrote:

...
El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:

...
I am totally against the idea that some code which works perfectly in C++03, as well as all other C++ standard levels, needs to be unnecessarily updated to some later C++ standard level in order to be acceptable to anyone.

This looks somewhat at odds with one of the stated goals of your cxx_dual lib:

"On a more practical basis the CXXD library is for:

1. Programmers writing code not using C++11 syntax who still want to target some C++11 libraries if the code is compiled in C++11 mode. [...]"

I do not see why you think the statement above is at odds with what I previously asserted. Whatever might have been added to a Boost library which became a C++ standard library in C+11 or beyond could hardly have been done just to add unnecessary features. I am not against a library being updated to use features of a later C++ standard when those updates are predicated on improving a library in specific ways that make it worthwhile to add such features.

I'm not sure I'm parsing your sentences right, but does that mean you're ok with a library using cxx_dual from scracth but not ok if a Boost-reliant lib is later updated via cxx_dual *only* to reduce Boost dependencies in C++11?

No. I am ok with a library changing itself to use C++ standard libraries instead of their Boost equivalents in any way it wants, whether using cxx-dual, whether creating its own interfaces for both Boost and the C++ standard equivalent, or whether just switching from using Boost to the C++ standard equivalent. But I am aware that such a change takes work, and will displease some end-users. If the Epoch proposal is merely to get a given Boost library to create another version of itself where it uses C++ standard libraries instead of Boost libraries so it can be part of a later Epoch I can see the value of your proposal, but again who will do the work of this transformation ? But if the Epoch proposal entails forcing a given library to use some features of a C++ standard so that it can be part of an Epoch, I see that is a failure of conception. If we are just talking about library dependencies, then a Boost library which has 0 or more dependencies on only C++ standard libraries of a given Epoch belonging to that Epoch is actually fine with me. But this of course means that a Boost library which has no dependencies on either Boost libraries or their C++ standard equivalent libraries of a given Epoch belongs to all Epochs, which is the way it should be IMO. So Boost PP, as an example, belongs to all Epochs.

...

...
The gist of your proposal which seems to me to be highly flawed is the idea that at a certain Epoch level all dependencies of a library must also exist at that same Epoch level or higher. How realistic is such a goal ? If library X at Epoch level nnn successfully uses library Y at Epoch level nnn-1, why should library Y be arbitrarily updated [...]

I understand you meant "should library X be arbitrarily updated" here.

No, I meant that library Y should not be arbitrarily updated so that library X can be considered valid for Epoch nnn. The only case I see where library Y would need to be updated, with perhaps another version at Epoch level nnn, would be if library Y had a dependency on a Boost library where an equivalent C++ standard library which works at Epoch level nnn was available.

...

...
[...]for no good practical reason to use C++ features of Epoch level nnn ?

The reason is to reduce internal Boost dependencies.

Adding C++ features at a certain C++ level rarely has to do with dependencies as opposed to the necessities of programming design. If adding a feature at a certain C++ level was able to reduce a dependency of a library to another library I would in general be all for it. But just let's take a library that is designed in such a way that it does not need any features of, let's say, C++11. Why would anybody want to add some feature just for the sake of saying that the library is at Epoch 11, when such a feature is unnecessary in the design of the library. This is what I mean by "absurdity".

...

...
I am pretty sure you can see the absurdity of such a determination as that.

I admire your confidence but not your perspicacity, as I indeed see no absurdity here.

Take for instance Boost.Beast, which depends on boost::string_view but can be made to depend on std::string_view instead via BOOST_BEAST_USE_STD_STRING_VIEW. Shall I take that you deem this ability absurd?

Not at all. But take a library which works fine at the C++03 on up level, such as TTI, and has no dependencies on other Boost libraries which can be dropped by adding some arbitrary feature of C++ 11 on up. Why should not this library be used by an Epoch library at the C++11 level if its usefulness is apparent to that Epoch library. And why disqualify that Epoch library from its level just because TTI does not use C++11 features. The gist of our disagreement is that I can see the usefulness of your proposal regarding Boost dependencies versus C++ standard equivalents, but not regarding the arbitrary distinction of whether some library uses some C++ feature of some C++ standard level. I would agree wholeheartedly with the idea that for any given Boost library, X, at no matter what C++ standard level, which uses 1 or more other Boost libraries when a C++ standard equivalent is available at some C++ standard level, that it would be advantageous for end-users to have another version of that library which uses the C++ standard equivalents. But doing such work is hardly trivial.

Joaquin M López Muñoz

8:15 p.m.

TL;DR: we basically agree on the same tenets, but there's been some mutual misunderstanding around during our conversation. El 24/05/2020 a las 20:02, Edward Diener via Boost escribió:

...

On 5/24/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:

...
I'm not sure I'm parsing your sentences right, but does that mean you're ok with a library using cxx_dual from scracth but not ok if a Boost-reliant lib is later updated via cxx_dual *only* to reduce Boost dependencies in C++11?

No.

I am ok with a library changing itself to use C++ standard libraries instead of their Boost equivalents in any way it wants, whether using cxx-dual, whether creating its own interfaces for both Boost and the C++ standard equivalent, or whether just switching from using Boost to the C++ standard equivalent. But I am aware that such a change takes work, [...]

This work is up to authors: if they are ok with not being given the shiny epoch badge, they can continue with the status quo.

...

and will displease some end-users.

I fail to see in which situations users would be displeased by internal dependencies being reduced.

...

If the Epoch proposal is merely to get a given Boost library to create another version of itself where it uses C++ standard libraries instead of Boost libraries so it can be part of a later Epoch I can see the value of your proposal, but again who will do the work of this transformation ?

Answered above.

...

But if the Epoch proposal entails forcing a given library to use some features of a C++ standard so that it can be part of an Epoch [...]

The proposal does not entail that.

...

If we are just talking about library dependencies, then a Boost library which has 0 or more dependencies on only C++ standard libraries of a given Epoch belonging to that Epoch is actually fine with me. But this of course means that a Boost library which has no dependencies on either Boost libraries or their C++ standard equivalent libraries of a given Epoch belongs to all Epochs, which is the way it should be IMO. So Boost PP, as an example, belongs to all Epochs.

Well, yes, exactly, Boost.PP belongs to all epochs. Another example (mentioned in the proposal) is Boost.Mp11: no internal dependencies, requires C++11, not subsumed by the standard yet --> it belongs to all epochs from Boost11 to Boost20. "Requires C++11" implies "works in C++N" for N>=11.

...

...
...
The gist of your proposal which seems to me to be highly flawed is the idea that at a certain Epoch level all dependencies of a library must also exist at that same Epoch level or higher. How realistic is such a goal ? If library X at Epoch level nnn successfully uses library Y at Epoch level nnn-1, why should library Y be arbitrarily updated [...]

I understand you meant "should library X be arbitrarily updated" here.

No, I meant that library Y should not be arbitrarily updated so that library X can be considered valid for Epoch nnn. The only case I see where library Y would need to be updated, with perhaps another version at Epoch level nnn, would be if library Y had a dependency on a Boost library where an equivalent C++ standard library which works at Epoch level nnn was available.

I understand your reasoning now and don't think there's more to discuss about it now we've clarified that belonging in BoostN implies belonging in BoostM (M>N) so long as the lib is not subsumed by the standard. (To be precise, there's also rejection rule 2, which denies promotion when a new library subsumes the old, case in point MPL and Mp11).

...

...
...
[...]for no good practical reason to use C++ features of Epoch level nnn ?

The reason is to reduce internal Boost dependencies.

Adding C++ features at a certain C++ level rarely has to do with dependencies as opposed to the necessities of programming design. If adding a feature at a certain C++ level was able to reduce a dependency of a library to another library I would in general be all for it.

The proposal says nothing about adding features to be granted epoch promotion.

...

But just let's take a library that is designed in such a way that it does not need any features of, let's say, C++11. Why would anybody want to add some feature just for the sake of saying that the library is at Epoch 11, when such a feature is unnecessary in the design of the library. This is what I mean by "absurdity".

I agree this is absurd. This is not what the proposal says.

...

...
[...]

Take for instance Boost.Beast, which depends on boost::string_view but can be made to depend on std::string_view instead via BOOST_BEAST_USE_STD_STRING_VIEW. Shall I take that you deem this ability absurd?

Not at all. But take a library which works fine at the C++03 on up level, such as TTI, and has no dependencies on other Boost libraries which can be dropped by adding some arbitrary feature of C++ 11 on up. Why should not this library be used by an Epoch library at the C++11 level if its usefulness is apparent to that Epoch library. And why disqualify that Epoch library from its level just because TTI does not use C++11 features.

I think the terms of promotion/rejection have been discussed in enough detail above. As for the particular case of Boost.TTI, it wouldn't enter into Boost11 because it uses Boost.MPL, which is subsumed by Boost.Mp11 in C++11. If you want to get the badge (if you don't then there's nothing else to do) then you'd have to conditionally use Mp11 or directly migrate to Mp11 and drop C++03 support. There's three options here, and the proposal does not mandate any, although authors are expected to aspire to newer epochs (that's the "incentivation" part).

...

The gist of our disagreement is that I can see the usefulness of your proposal regarding Boost dependencies versus C++ standard equivalents, but not regarding the arbitrary distinction of whether some library uses some C++ feature of some C++ standard level.

No disagreement here. The rules for membership in BoostN are: /"A Boost library //*X*////belongs//to epoch //*BoostN*//if: / * /*X*//is compatible with C++//*N*//,/ * /*(rejection rule 1)*//the functionality provided by //*X*//is not already covered by C++//*N*//,/ * /*(rejection rule 2)*//the functionality provided by //*X*//is not superseded by some other, more modern, library //*Y*//in //*BoostN*//,/ * /all the libraries in depN(//*X*//) belong to //*BoostN*//."/ "X is compatible with C++N" does not mean "X uses new features/libraries introduced in C++11".

...

I would agree wholeheartedly with the idea that for any given Boost library, X, at no matter what C++ standard level, which uses 1 or more other Boost libraries when a C++ standard equivalent is available at some C++ standard level, that it would be advantageous for end-users to have another version of that library which uses the C++ standard equivalents. But doing such work is hardly trivial.

Already discussed above, I think. Now that I think we are on the same page regarding what the proposal is and is not about, I'd like to ask you if you found some particular section on the proposal text misleading: I can try and make it more clear. Joaquín M López Muñoz

Andrey Semashev

8:27 p.m.

On 2020-05-24 23:15, Joaquin M López Muñoz via Boost wrote:

...

To be precise, there's also rejection rule 2, which denies promotion when a new library subsumes the old, case in point MPL and Mp11.

This is another point where I don't agree with the proposal. Boost.MPL and Boost.Mp11 are very different in API, which means that a library that uses template metaprogramming and wants to support C++03 and later cannot be compliant with the Epoch requirements, unless it contains two versions of the TMP code - one with Boost.MPL and another with Boost.Mp11. Or its own hand-rolled TMP primitives. This is impractical or advocates against code reuse.

Vinnie Falco

25 May 25 May

12:42 a.m.

On Sun, May 24, 2020 at 1:27 PM Andrey Semashev via Boost wrote:

...

a library that uses template metaprogramming and wants to support C++03

Maybe they should make a fork of Boost which is aimed at some of the more seasoned developers who want nostalgia for the good old days. I know, we can call it "Boost Classic" and it will be 32-bit only. Maybe. Regards

Peter Dimov

12:57 a.m.

Vinnie Falco wrote:

...

On Sun, May 24, 2020 at 1:27 PM Andrey Semashev via Boost wrote:

...
a library that uses template metaprogramming and wants to support C++03

Maybe they should make a fork of Boost which is aimed at some of the more seasoned developers who want nostalgia for the good old days.

You are missing the point. The claim is the the epoch proposal allows a library to belong to the 03 and 11 epochs with a single code base. The counterargument is that this is not possible if it does metaprogramming.

Edward Diener

12:38 a.m.

On 5/24/2020 4:15 PM, Joaquin M López Muñoz via Boost wrote:

...

TL;DR: we basically agree on the same tenets, but there's been some mutual misunderstanding around during our conversation.

El 24/05/2020 a las 20:02, Edward Diener via Boost escribió:

...
On 5/24/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:

...
I'm not sure I'm parsing your sentences right, but does that mean you're ok with a library using cxx_dual from scracth but not ok if a Boost-reliant lib is later updated via cxx_dual *only* to reduce Boost dependencies in C++11?

No.

I am ok with a library changing itself to use C++ standard libraries instead of their Boost equivalents in any way it wants, whether using cxx-dual, whether creating its own interfaces for both Boost and the C++ standard equivalent, or whether just switching from using Boost to the C++ standard equivalent. But I am aware that such a change takes work, [...]

This work is up to authors: if they are ok with not being given the shiny epoch badge, they can continue with the status quo.

...
and will displease some end-users.

I fail to see in which situations users would be displeased by internal dependencies being reduced.

...
If the Epoch proposal is merely to get a given Boost library to create another version of itself where it uses C++ standard libraries instead of Boost libraries so it can be part of a later Epoch I can see the value of your proposal, but again who will do the work of this transformation ?

Answered above.

...
But if the Epoch proposal entails forcing a given library to use some features of a C++ standard so that it can be part of an Epoch [...]

The proposal does not entail that.

...
If we are just talking about library dependencies, then a Boost library which has 0 or more dependencies on only C++ standard libraries of a given Epoch belonging to that Epoch is actually fine with me. But this of course means that a Boost library which has no dependencies on either Boost libraries or their C++ standard equivalent libraries of a given Epoch belongs to all Epochs, which is the way it should be IMO. So Boost PP, as an example, belongs to all Epochs.

Well, yes, exactly, Boost.PP belongs to all epochs. Another example (mentioned in the proposal) is Boost.Mp11: no internal dependencies, requires C++11, not subsumed by the standard yet --> it belongs to all epochs from Boost11 to Boost20. "Requires C++11" implies "works in C++N" for N>=11.

...
...
...
The gist of your proposal which seems to me to be highly flawed is the idea that at a certain Epoch level all dependencies of a library must also exist at that same Epoch level or higher. How realistic is such a goal ? If library X at Epoch level nnn successfully uses library Y at Epoch level nnn-1, why should library Y be arbitrarily updated [...]

I understand you meant "should library X be arbitrarily updated" here.

No, I meant that library Y should not be arbitrarily updated so that library X can be considered valid for Epoch nnn. The only case I see where library Y would need to be updated, with perhaps another version at Epoch level nnn, would be if library Y had a dependency on a Boost library where an equivalent C++ standard library which works at Epoch level nnn was available.

I understand your reasoning now and don't think there's more to discuss about it now we've clarified that belonging in BoostN implies belonging in BoostM (M>N) so long as the lib is not subsumed by the standard. (To be precise, there's also rejection rule 2, which denies promotion when a new library subsumes the old, case in point MPL and Mp11).

...
...
...
[...]for no good practical reason to use C++ features of Epoch level nnn ?

The reason is to reduce internal Boost dependencies.

Adding C++ features at a certain C++ level rarely has to do with dependencies as opposed to the necessities of programming design. If adding a feature at a certain C++ level was able to reduce a dependency of a library to another library I would in general be all for it.

The proposal says nothing about adding features to be granted epoch promotion.

...
But just let's take a library that is designed in such a way that it does not need any features of, let's say, C++11. Why would anybody want to add some feature just for the sake of saying that the library is at Epoch 11, when such a feature is unnecessary in the design of the library. This is what I mean by "absurdity".

I agree this is absurd. This is not what the proposal says.

...
...
[...]

Take for instance Boost.Beast, which depends on boost::string_view but can be made to depend on std::string_view instead via BOOST_BEAST_USE_STD_STRING_VIEW. Shall I take that you deem this ability absurd?

Not at all. But take a library which works fine at the C++03 on up level, such as TTI, and has no dependencies on other Boost libraries which can be dropped by adding some arbitrary feature of C++ 11 on up. Why should not this library be used by an Epoch library at the C++11 level if its usefulness is apparent to that Epoch library. And why disqualify that Epoch library from its level just because TTI does not use C++11 features.

I think the terms of promotion/rejection have been discussed in enough detail above. As for the particular case of Boost.TTI, it wouldn't enter into Boost11 because it uses Boost.MPL, which is subsumed by Boost.Mp11 in C++11.

The MPL library uses no Boost library where a C++11 on up standard library is available. So your "Boost.MPL, which is subsumed by Boost.Mp11 in C++11" does not make sense to me. While MP11 may be a C+11 library that is worthy to use, I see nothing wrong with a C++11 on up library using MPL as far as dependencies go.

Peter Dimov

12:54 a.m.

Edward Diener wrote:

...

While MP11 may be a C+11 library that is worthy to use, I see nothing wrong with a C++11 on up library using MPL as far as dependencies go.

Nothing except... everything, really, but mostly the compile times.

Edward Diener

1:18 p.m.

On 5/24/2020 8:38 PM, Edward Diener via Boost wrote:

...

On 5/24/2020 4:15 PM, Joaquin M López Muñoz via Boost wrote:

...
TL;DR: we basically agree on the same tenets, but there's been some mutual misunderstanding around during our conversation.

El 24/05/2020 a las 20:02, Edward Diener via Boost escribió:

...
On 5/24/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:

...
I'm not sure I'm parsing your sentences right, but does that mean you're ok with a library using cxx_dual from scracth but not ok if a Boost-reliant lib is later updated via cxx_dual *only* to reduce Boost dependencies in C++11?

No.

I am ok with a library changing itself to use C++ standard libraries instead of their Boost equivalents in any way it wants, whether using cxx-dual, whether creating its own interfaces for both Boost and the C++ standard equivalent, or whether just switching from using Boost to the C++ standard equivalent. But I am aware that such a change takes work, [...]

This work is up to authors: if they are ok with not being given the shiny epoch badge, they can continue with the status quo.

...
and will displease some end-users.

I fail to see in which situations users would be displeased by internal dependencies being reduced.

...
If the Epoch proposal is merely to get a given Boost library to create another version of itself where it uses C++ standard libraries instead of Boost libraries so it can be part of a later Epoch I can see the value of your proposal, but again who will do the work of this transformation ?

Answered above.

...
But if the Epoch proposal entails forcing a given library to use some features of a C++ standard so that it can be part of an Epoch [...]

The proposal does not entail that.

...
If we are just talking about library dependencies, then a Boost library which has 0 or more dependencies on only C++ standard libraries of a given Epoch belonging to that Epoch is actually fine with me. But this of course means that a Boost library which has no dependencies on either Boost libraries or their C++ standard equivalent libraries of a given Epoch belongs to all Epochs, which is the way it should be IMO. So Boost PP, as an example, belongs to all Epochs.

Well, yes, exactly, Boost.PP belongs to all epochs. Another example (mentioned in the proposal) is Boost.Mp11: no internal dependencies, requires C++11, not subsumed by the standard yet --> it belongs to all epochs from Boost11 to Boost20. "Requires C++11" implies "works in C++N" for N>=11.

...
...
...
The gist of your proposal which seems to me to be highly flawed is the idea that at a certain Epoch level all dependencies of a library must also exist at that same Epoch level or higher. How realistic is such a goal ? If library X at Epoch level nnn successfully uses library Y at Epoch level nnn-1, why should library Y be arbitrarily updated [...]

I understand you meant "should library X be arbitrarily updated" here.

No, I meant that library Y should not be arbitrarily updated so that library X can be considered valid for Epoch nnn. The only case I see where library Y would need to be updated, with perhaps another version at Epoch level nnn, would be if library Y had a dependency on a Boost library where an equivalent C++ standard library which works at Epoch level nnn was available.

I understand your reasoning now and don't think there's more to discuss about it now we've clarified that belonging in BoostN implies belonging in BoostM (M>N) so long as the lib is not subsumed by the standard. (To be precise, there's also rejection rule 2, which denies promotion when a new library subsumes the old, case in point MPL and Mp11).

...
...
...
[...]for no good practical reason to use C++ features of Epoch level nnn ?

The reason is to reduce internal Boost dependencies.

Adding C++ features at a certain C++ level rarely has to do with dependencies as opposed to the necessities of programming design. If adding a feature at a certain C++ level was able to reduce a dependency of a library to another library I would in general be all for it.

The proposal says nothing about adding features to be granted epoch promotion.

...
But just let's take a library that is designed in such a way that it does not need any features of, let's say, C++11. Why would anybody want to add some feature just for the sake of saying that the library is at Epoch 11, when such a feature is unnecessary in the design of the library. This is what I mean by "absurdity".

I agree this is absurd. This is not what the proposal says.

...
...
[...]

Take for instance Boost.Beast, which depends on boost::string_view but can be made to depend on std::string_view instead via BOOST_BEAST_USE_STD_STRING_VIEW. Shall I take that you deem this ability absurd?

Not at all. But take a library which works fine at the C++03 on up level, such as TTI, and has no dependencies on other Boost libraries which can be dropped by adding some arbitrary feature of C++ 11 on up. Why should not this library be used by an Epoch library at the C++11 level if its usefulness is apparent to that Epoch library. And why disqualify that Epoch library from its level just because TTI does not use C++11 features.

I think the terms of promotion/rejection have been discussed in enough detail above. As for the particular case of Boost.TTI, it wouldn't enter into Boost11 because it uses Boost.MPL, which is subsumed by Boost.Mp11 in C++11.

The MPL library uses no Boost library where a C++11 on up standard library is available. So your "Boost.MPL, which is subsumed by Boost.Mp11 in C++11" does not make sense to me. While MP11 may be a C+11 library that is worthy to use, I see nothing wrong with a C++11 on up library using MPL as far as dependencies go.

This is my error. The MPL library does use Boost type_traits where there is an equivalent C++ standard type_traits. So I concur that use of MPL would place a Boost library like TTI below the C11 Epoch.

Kostas Savvidis

24 May 24 May

8:53 a.m.

...

On May 23, 2020, at 12:56, Joaquin M López Muñoz via Boost wrote:

Hi,

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat",

User perceptions about bloat may be related to the download size. I was curious what in the world makes it weight 600MB and dig around a bit to get an idea. 1) 33MB of lookup tables as part of math special functions - and numbers are trailing zero padded, such as SC_(7.1529668608000000000000000000000000000000e+10) - (why?) These are only used for tests, not part of the library per se. 2) There appears to be some huge source files which must have been generated by another computer program of some sort, files such as a) epsg_traits.hpp in geometry - 2MB b) make_map50.hpp in fusion/container - 5MB c) switch_50.hpp in phoenix - 5MB 3) lots of binary files png, svg, bmp, pdf etc - e.g. math documentation weights 50MB due to many svg and png 4) 80MB of docs which is not a problem, but some library has its own doc folder with many MB (duplicated?), often the largest subfolder by far is doc and tests also often far larger than actual code 5) ok so the source tree is huge, but maybe the installation is much smaller? Not really, include tree is 150MB and libs are 500MB I have my suspicions about the wisdom of 2a,2b,2c, but to be clear I am not criticising the authors of these wonderful libraries --- only pointing out where the perceptions of bloat might be coming from. As a constructive proposal, maybe separating boost into three downloads - source,doc,tests - would help? On another note, it is pretty clear that "eventually" boost will remove everything which is in STL now, but the time is not now. But the time is right for decreasing mutual dependencies within boost by replacing stuff with STL equivalents and potentially make more libraries available on standalone basis. Potentially, some people might prefer to keep releasing updates under 1.XX under traditional structure and jump to boost 2.0 for a new boost using STL whenever possible. Best Regards, Kostas ========================================= Institute of Nuclear and Particle Physics NCSR Demokritos http://inspirehep.net/author/profile/K.G.Savvidy.1 https://github.com/kotika/random https://mixmax.hepforge.org

pbristow＠hetp.u-net.com

3:04 p.m.

...

-----Original Message-----

...

From: Boost On Behalf Of Joaquin M López Muñoz via Boost

...

Sent: 23 May 2020 10:56

...

To: boost@lists.boost.org

...

Cc: Joaquin M López Muñoz

...

Subject: [boost] [epochs] Proposal for an epoch-based organization of Boost libraries

...

Hi,

...

Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and

...

after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less

...

fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and

...

refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now

...

ready for presentation at the mailing list:

...

https://github.com/joaquintides/boost_epoch/blob/master/README.md

...

I hope the proposal can start a productive conversation. Looking forward to your feedback.

Your epoch ideas have merit, but some disadvantages. But I fear that (like other projects like Cmake) the BIG hurdle that we struggle to get over, is *resources*. And particularly, resources to update *all* existing libraries in any way. Boost does have a lot of dependencies, but they are there for excellent reasons. Documentation is a big part of the distribution (guilty) , but are needed by most. Tests and tests data are another area that many users rarely use, but separately them would be a big task. It is true that Boost has become very big, but Boost is only taking up space on builder's disks, not in end-users executables. If we could do something positive, it would be to make much clearer that nearly all Boost is header-only, and has no effect on the executables. The Getting Started instructions have been poor from the start, and are virtually unchanged while the Boost size has increased >10-fold. To suggest that everyone needs to build all the libraries for all the variants taking hours has become absurd when most users are only like to need a handful like system and chrono. So we could and should *sell* Boost much better. In conclusion, I don't think that we have the resources to do any useful split. So while we may regret that some avoid Boost, we must resign ourselves to continue muddling through ☹ Paul

Joaquin M López Muñoz

4:52 p.m.

El 24/05/2020 a las 17:04, Paul A Bristow via Boost escribió:

...

Your epoch ideas have merit, but some disadvantages.

But I fear that (like other projects like Cmake) the BIG hurdle that we struggle to get over, is *resources*.

And particularly, resources to update *all* existing libraries in any way.

Boost does have a lot of dependencies, but they are there for excellent reasons.

Documentation is a big part of the distribution (guilty) , but are needed by most.

Tests and tests data are another area that many users rarely use, but separately them would be a big task.

It is true that Boost has become very big, but Boost is only taking up space on builder's disks, not in end-users executables.

If we could do something positive, it would be to make much clearer that nearly all Boost is header-only, and has no effect on the executables.

The Getting Started instructions have been poor from the start, and are virtually unchanged while the Boost size has increased >10-fold.

To suggest that everyone needs to build all the libraries for all the variants taking hours has become absurd when most users are only like to need a handful like system and chrono.

So we could and should *sell* Boost much better.

I agree with much of what you say here, in particular with your appreciation that Boost has a PR problem. Most Boost libs are indeed header-only, which dispenses many users with the need of building. But even in this case one has to drag a lot of dependencies in. Users are comparing Boost (fairly or not) with header-only libs without any dependency whatsoever.

...

In conclusion, I don't think that we have the resources to do any useful split.

So while we may regret that some avoid Boost, we must resign ourselves to continue muddling through ☹

I'd say at least phases 0 and 1 of the proposed plan for this: https://github.com/joaquintides/boost_epoch/#work-plan are fairly economical in terms of needed effort. Once put in place, it'll all of course depend on how this actually incentivizes authors to do their part. Joaquín M López Muñoz

1627

Age (days ago)

1632

Last active (days ago)

List overview

Download

42 comments

13 participants

participants (13)

Alexander Grund
Andrey Semashev
Brook Milligan
Christopher Kormanyos
degski
Dimitri John Ledkov
Edward Diener
Joaquin M López Muñoz
Kostas Savvidis
pbristow＠hetp.u-net.com
Peter Dimov
Rene Rivera
Vinnie Falco