Hello everyone, Just a quick warning that due to the delay releasing 1.50, the 1.51 release cycle is going to be a lot shorter than normal. It's a little under 2 months until the scheduled 1.51 release date. This means that the deadlines are pretty soon. If you haven't checked it yet, please take a look at the calendar at: http://www.boost.org/community/ The current deadline for new libraries and breaking changes is 9th July, which is less than two weeks. If you do have a new library that want to release in 1.51, you should probably let us know very soon. thanks, Daniel
If you do have a new library that want to release in 1.51, you should probably let us know very soon.
I think boost.context is a candidate for 1.51?! Is it OK to merge the lib into the release branch next monday? Oliver -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
On 29 June 2012 07:02, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:
If you do have a new library that want to release in 1.51, you should probably let us know very soon.
I think boost.context is a candidate for 1.51?! Is it OK to merge the lib into the release branch next monday?
Not yet, there's a few things we need to sort out. The most important is that the regression test results are good. Can you mark up expected failures in 'status/explicit-failures-markup.xml' (remember to check the xml before committing, there's instructions at the top of the file)? Do you have any idea why Visual C++ 10 is failing? We also need to add the documentation to the build, I can take care of that, do you want the documentation to be standalone (i.e. in 'libs/context/doc/html') or part of the combined documentation (in 'doc/html')? Finally, please add your details to 'libs/maintainers.txt' and your library to 'libs/libraries.htm' - putting it in appropriate sections as well the alphabetical list. thanks, Daniel
Not yet, there's a few things we need to sort out. The most important is that the regression test results are good. Can you mark up expected failures in 'status/explicit-failures-markup.xml' (remember to check the xml before committing, there's instructions at the top of the file)? Do you have any idea why Visual C++ 10 is failing?
You are refering to tests RW_VC10 and RW_Mingw45? This is because the owner of this computers does not have the MASM (assembler) in its search dir. Some regression tests will fail because the platform (for instance architecture SPARC) is not supported (but might be added later).
We also need to add the documentation to the build, I can take care of that, do you want the documentation to be standalone (i.e. in 'libs/context/doc/html') or part of the combined documentation (in 'doc/html')?
standalone
Finally, please add your details to 'libs/maintainers.txt' and your library to 'libs/libraries.htm' - putting it in appropriate sections as well the alphabetical list.
OK - if I've done it I've 'go ahead'? Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
On 29/06/2012 12:07, Oliver Kowalke wrote:
Not yet, there's a few things we need to sort out. The most important is that the regression test results are good. Can you mark up expected failures in 'status/explicit-failures-markup.xml' (remember to check the xml before committing, there's instructions at the top of the file)? Do you have any idea why Visual C++ 10 is failing?
You are refering to tests RW_VC10 and RW_Mingw45? This is because the owner of this computers does not have the MASM (assembler) in its search dir.
Some regression tests will fail because the platform (for instance architecture SPARC) is not supported (but might be added later).
I've just tested context on trunk, and it passed (VC10 x64, Win7 x64). KTC
Am 29.06.2012 16:44, schrieb KTC:
On 29/06/2012 12:07, Oliver Kowalke wrote:
Not yet, there's a few things we need to sort out. The most important is that the regression test results are good. Can you mark up expected failures in 'status/explicit-failures-markup.xml' (remember to check the xml before committing, there's instructions at the top of the file)? Do you have any idea why Visual C++ 10 is failing?
You are refering to tests RW_VC10 and RW_Mingw45? This is because the owner of this computers does not have the MASM (assembler) in its search dir.
Some regression tests will fail because the platform (for instance architecture SPARC) is not supported (but might be added later).
I've just tested context on trunk, and it passed (VC10 x64, Win7 x64).
KTC
thank you - KTC :) Oliver
On 29 June 2012 12:07, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:
Not yet, there's a few things we need to sort out. The most important is that the regression test results are good. Can you mark up expected failures in 'status/explicit-failures-markup.xml' (remember to check the xml before committing, there's instructions at the top of the file)? Do you have any idea why Visual C++ 10 is failing?
You are refering to tests RW_VC10 and RW_Mingw45? This is because the owner of this computers does not have the MASM (assembler) in its search dir.
Thanks for the explanation. That probably shouldn't go in to explicit-failures-markup.xml as it's machine specific (i.e. can work on other testers with the same compiler). An unfortunate limitation of our current test system.
Some regression tests will fail because the platform (for instance architecture SPARC) is not supported (but might be added later).
That's the kind of thing that should be put in explicit-failures-markup.xml. You want something like: <!-- context --> <library name="context"> <mark-unusable> <toolset name="cray*"/> <toolset name="intel-linux*"/> <note author="Oliver Kowalke"> This platform is not supported (but might be added later). </note> </mark-unusable> </library> The asterisk in 'cray*' can only come at the end.
We also need to add the documentation to the build, I can take care of that, do you want the documentation to be standalone (i.e. in 'libs/context/doc/html') or part of the combined documentation (in 'doc/html')?
standalone
OK, I'll sort that out over the weekend and run a build.
Finally, please add your details to 'libs/maintainers.txt' and your library to 'libs/libraries.htm' - putting it in appropriate sections as well the alphabetical list.
OK - if I've done it I've 'go ahead'?
Before merging, wait until I've sorted out the documentation (also, the release branch isn't open yet). I'll have a more detailed look over the weekend, but the library does seem to be in good shape.
On 29 June 2012 19:14, Daniel James <dnljms@gmail.com> wrote:
We also need to add the documentation to the build, I can take care of that, do you want the documentation to be standalone (i.e. in 'libs/context/doc/html') or part of the combined documentation (in 'doc/html')?
standalone
OK, I'll sort that out over the weekend and run a build.
It's here: http://boost-sandbox.sourceforge.net/libs/context/ I had to change the Jamfile to get the documentation to build properly, I also added a html file to redirect from 'libs/context/index.html' to the documentation.
Am 29.06.2012 20:14, schrieb Daniel James:
That's the kind of thing that should be put in explicit-failures-markup.xml. You want something like:
<!-- context --> <library name="context"> <mark-unusable> <toolset name="cray*"/> <toolset name="intel-linux*"/> <note author="Oliver Kowalke"> This platform is not supported (but might be added later). </note> </mark-unusable> </library>
The asterisk in 'cray*' can only come at the end.
Is it possible to express: architectures (not only toolsets) different from 'intel', 'ppc', 'arm' and 'mips' are not supported? regards, Oliver
On 7 July 2012 12:07, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:
Am 29.06.2012 20:14, schrieb Daniel James:
That's the kind of thing that should be put in explicit-failures-markup.xml. You want something like:
<!-- context --> <library name="context"> <mark-unusable> <toolset name="cray*"/> <toolset name="intel-linux*"/> <note author="Oliver Kowalke"> This platform is not supported (but might be added later). </note> </mark-unusable> </library>
The asterisk in 'cray*' can only come at the end.
Is it possible to express: architectures (not only toolsets) different from 'intel', 'ppc', 'arm' and 'mips' are not supported?
No, you can only match against the 'library/toolset' row of the results table. If you can't make an appropriate match, then it's probably best to leave it. You could possibly put a check in the build files so that the tests just aren't run. That will presumably leave an empty space for that column, although I'm not sure.
Am 07.07.2012 13:16, schrieb Daniel James:
Am 29.06.2012 20:14, schrieb Daniel James:
That's the kind of thing that should be put in explicit-failures-markup.xml. You want something like:
<!-- context --> <library name="context"> <mark-unusable> <toolset name="cray*"/> <toolset name="intel-linux*"/> <note author="Oliver Kowalke"> This platform is not supported (but might be added later). </note> </mark-unusable> </library>
The asterisk in 'cray*' can only come at the end.
Is it possible to express: architectures (not only toolsets) different from 'intel', 'ppc', 'arm' and 'mips' are not supported? No, you can only match against the 'library/toolset' row of the results table. If you can't make an appropriate match, then it's
On 7 July 2012 12:07, Oliver Kowalke <oliver.kowalke@gmx.de> wrote: probably best to leave it. You could possibly put a check in the build files so that the tests just aren't run. That will presumably leave an empty space for that column, although I'm not sure.
OK - I've already pre-processor statements (#error) but I'll try to adapt the Jamfile accordingly too. regards, Oliver
On 7 July 2012 12:51, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:
Am 07.07.2012 13:16, schrieb Daniel James:
No, you can only match against the 'library/toolset' row of the results table. If you can't make an appropriate match, then it's probably best to leave it. You could possibly put a check in the build files so that the tests just aren't run. That will presumably leave an empty space for that column, although I'm not sure.
OK - I've already pre-processor statements (#error) but I'll try to adapt the Jamfile accordingly too.
Just to be clear, you don't need to sort this out before merging (or at all really, if our tools aren't good enough then that isn't your fault). And I'm not entirely sure if handling it in the build files is the right thing to do.
Hi Oliver, On Friday, 29. June 2012 13:07:04 Oliver Kowalke wrote:
Not yet, there's a few things we need to sort out. The most important is that the regression test results are good. Can you mark up expected failures in 'status/explicit-failures-markup.xml' (remember to check the xml before committing, there's instructions at the top of the file)? Do you have any idea why Visual C++ 10 is failing?
You are refering to tests RW_VC10 and RW_Mingw45? This is because the owner of this computers does not have the MASM (assembler) in its search dir.
Any chance of getting a gas implementation to support working without MASM? What happens if one wants to cross compile Boost.Context from Linux or OS X? Do you know if there is a MASM compatible cross compiler available? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
Not yet, there's a few things we need to sort out. The most important is that the regression test results are good. Can you mark up expected failures in 'status/explicit-failures-markup.xml' (remember to check the xml before committing, there's instructions at the top of the file)? Do you have any idea why Visual C++ 10 is failing?
You are refering to tests RW_VC10 and RW_Mingw45? This is because the owner of this computers does not have the MASM (assembler) in its search dir.
Any chance of getting a gas implementation to support working without MASM? What happens if one wants to cross compile Boost.Context from Linux or OS X? Do you know if there is a MASM compatible cross compiler available?
Yours, Jürgen
I'm no expert on x86_64 assembly, and it's been a while, but I think the go-to assembler for those interested in cross Windows and Linux platforms is NASM, the Netwide Assembler. http://www.nasm.us/ I prefer using NASM if I need to write x86_64 assembly. But sigh... the syntax of NASM slightly differs from that of MASM. Best regards, Chris.
Am 01.07.2012 12:19, schrieb Jürgen Hunold:
Hi Oliver,
On Friday, 29. June 2012 13:07:04 Oliver Kowalke wrote:
Not yet, there's a few things we need to sort out. The most important is that the regression test results are good. Can you mark up expected failures in 'status/explicit-failures-markup.xml' (remember to check the xml before committing, there's instructions at the top of the file)? Do you have any idea why Visual C++ 10 is failing? You are refering to tests RW_VC10 and RW_Mingw45? This is because the owner of this computers does not have the MASM (assembler) in its search dir. Any chance of getting a gas implementation to support working without MASM? What happens if one wants to cross compile Boost.Context from Linux or OS X? Do you know if there is a MASM compatible cross compiler available?
Yours,
Jürgen The syntax could be transformed into NASM syntax but the problem is that each assembler has its own syntax and I beleive it is likly that I'm faced to requests to support assembler 'xyz' on platform 'abc' too. Therefore I decided to support only a standard assembler on a platform. (MASM is distributed with the Windows SDKs)
regards, Oliver
Hi Oliver, On Thursday, 5. July 2012 20:00:48 Oliver Kowalke wrote:
The syntax could be transformed into NASM syntax but the problem is that each assembler has its own syntax and I beleive it is likly that I'm faced to requests to support assembler 'xyz' on platform 'abc' too.
Yes, I can understand where this might lead to.
Therefore I decided to support only a standard assembler on a platform. (MASM is distributed with the Windows SDKs)
And there are people out there not using the SDK, but mingw-w64. And the interesting question is: How do I cross-compile Boost.Context from Linux to Windows? Setting up an Wine driven MASM call and linking the resulting files with a cross-gcc/clang toolchain might be a real challenge. I can fully understand not to support every compiler/assembler combination. I think that gcc/clang and gas are special cases especially when considering cross compilation. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
On Thursday, 5. July 2012 20:00:48 Oliver Kowalke wrote:
The syntax could be transformed into NASM syntax but the problem is that each assembler has its own syntax and I beleive it is likly that I'm faced to requests to support assembler 'xyz' on platform 'abc' too.
Yes, I can understand where this might lead to.
Therefore I decided to support only a standard assembler on a platform. (MASM is distributed with the Windows SDKs)
And there are people out there not using the SDK, but mingw-w64. And the interesting question is: How do I cross-compile Boost.Context from Linux to Windows? Setting up an Wine driven MASM call and linking the resulting files with a cross-gcc/clang toolchain might be a real challenge.
I can fully understand not to support every compiler/assembler combination. I think that gcc/clang and gas are special cases especially when considering cross compilation.
+1 Regards, Nate
Hello Jürgen,
Hi Oliver,
On Thursday, 5. July 2012 20:00:48 Oliver Kowalke wrote:
The syntax could be transformed into NASM syntax but the problem is that each assembler has its own syntax and I beleive it is likly that I'm faced to requests to support assembler 'xyz' on platform 'abc' too. Yes, I can understand where this might lead to. Another reason I remember is that MASM allows to specify the exception handler and MASM does the required operations for the Win64-ExeptionHandling (pseudo-operations to create .pdata and .xdata etc.). I believe with gcc I would have to do all this stuff be myself.
regards, Oliver
The current deadline for new libraries and breaking changes is 9th July, which is less than two weeks. If you do have a new library that want to release in 1.51, you should probably let us know very soon.
what's the policy for c++11-only libraries? i could make boost.lockfree depend on std::atomic to avoid that it will have to wait for boost.atomic forever. tim
On 29 June 2012 08:11, Tim Blechmann <tim@klingt.org> wrote:
The current deadline for new libraries and breaking changes is 9th July, which is less than two weeks. If you do have a new library that want to release in 1.51, you should probably let us know very soon.
what's the policy for c++11-only libraries?
I don't know. I guess the main issue is if it will be adequately supported by our testers.
i could make boost.lockfree depend on std::atomic to avoid that it will have to wait for boost.atomic forever.
It isn't in trunk yet, so I'm not sure if you'll have enough time for 1.51. The deadline is very tight. You'll really have to get in and the tests running straight away, and you still might not have enough time unless it goes very smoothly (the testers aren't that frequent, I'm afraid). Daniel
The current deadline for new libraries and breaking changes is 9th July, which is less than two weeks. If you do have a new library that want to release in 1.51, you should probably let us know very soon.
what's the policy for c++11-only libraries?
I don't know. I guess the main issue is if it will be adequately supported by our testers.
me neither ... i guess no one knows, because i've asked this question before without getting any reply.
i could make boost.lockfree depend on std::atomic to avoid that it will have to wait for boost.atomic forever.
It isn't in trunk yet, so I'm not sure if you'll have enough time for 1.51. The deadline is very tight. You'll really have to get in and the tests running straight away, and you still might not have enough time unless it goes very smoothly (the testers aren't that frequent, I'm afraid).
well, i must admit, i'm kind of upset by the situation: * boost.atomic seems to be dead, at least helge does not respond anymore and the library will probably be obsolete, because once it is merged, all compilers will support std::atomic * there is no policy about c++11 libraries, so i cannot merge boost.lockfree into trunk by cutting the boost.atomic dependency * merging boost.lockfree now is too late, for the next release, as it is not in trunk because of the reasons mentioned above. well, it is not like it could introduce any regressions .... ... kind of awkward, since boost.lockfree has passed the review about one year ago ... the upside is, that maybe boost will be migrated to git, before it will be added, so i won't have to struggle with svn merges :/ tim
Tim Blechmann wrote:
what's the policy for c++11-only libraries?
I don't know. I guess the main issue is if it will be adequately supported by our testers.
me neither ... i guess no one knows, because i've asked this question before without getting any reply.
Unfortunately, cannot admit a library -- into a release -- that isn't being tested, so you need C++11 testers. However, that doesn't prevent you from putting it into trunk.
i could make boost.lockfree depend on std::atomic to avoid that it will have to wait for boost.atomic forever.
That's a reasonable tack.
It isn't in trunk yet, so I'm not sure if you'll have enough time for 1.51. The deadline is very tight. You'll really have to get in and the tests running straight away, and you still might not have enough time unless it goes very smoothly (the testers aren't that frequent, I'm afraid).
Note that only means you may not get it into 1.51; it doesn't preclude putting it in trunk.
well, i must admit, i'm kind of upset by the situation:
* boost.atomic seems to be dead, at least helge does not respond anymore and the library will probably be obsolete, because once it is merged, all compilers will support std::atomic
That's unfortunate. There will be many using C++03 for years yet.
* there is no policy about c++11 libraries, so i cannot merge boost.lockfree into trunk by cutting the boost.atomic dependency
Don't take this as policy, but I don't see any problem with adding a C++11-only library if your code is conditionally compiled to avoid problems with C++03 compilers (which could mean no code for those compilers). Trying to do so may reveal issues with config, but that will be helpful.
* merging boost.lockfree now is too late, for the next release, as it is not in trunk because of the reasons mentioned above. well, it is not like it could introduce any regressions ....
If you put it in trunk, C++11 testers are spun up, and tests go well, you might make 1.51. If there's insufficient time, try again for 1.52. Either way, keep seeking C++11 testers! _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 6/29/12 6:56 AM, Stewart, Robert wrote:
Tim Blechmann wrote:
well, i must admit, i'm kind of upset by the situation:
* boost.atomic seems to be dead, at least helge does not respond anymore and the library will probably be obsolete, because once it is merged, all compilers will support std::atomic That's unfortunate. There will be many using C++03 for years yet.
+1 I have to agree with Robert. We will be on older tool chains for the foreseeable future. We have a on-going need for a portable supported C++03 atomic library and have been eagerly waiting for the boost.atomic to be released as a boost library. It's disappointing that boost.atomic (as well as boost.lockfree) have been delayed for so long. Regards, Tim Moore
On 29 June 2012 11:36, Tim Blechmann <tim@klingt.org> wrote:
The current deadline for new libraries and breaking changes is 9th July, which is less than two weeks. If you do have a new library that want to release in 1.51, you should probably let us know very soon.
what's the policy for c++11-only libraries?
I don't know. I guess the main issue is if it will be adequately supported by our testers.
me neither ... i guess no one knows, because i've asked this question before without getting any reply.
I'd take that as a yes. As long as you've asked on the development list with a clear subject line, then you've given the community sufficient opportunity to say otherwise. If you're not happy with this, then maybe ask on the steering committee list? (Although, they might not be happy with me for saying that....)
* there is no policy about c++11 libraries, so i cannot merge boost.lockfree into trunk by cutting the boost.atomic dependency
No, as long as your review manager is happy, you have every right to add your library to *trunk* and it really is advisable to do so.
* merging boost.lockfree now is too late, for the next release, as it is not in trunk because of the reasons mentioned above. well, it is not like it could introduce any regressions ....
Sure, I'm sympathetic as it sounds like you've been left in the lurch. I don't know how the other release managers would feel about it though so I can't promise anything. Daniel
soon.
what's the policy for c++11-only libraries?
I don't know. I guess the main issue is if it will be adequately supported by our testers.
me neither ... i guess no one knows, because i've asked this question before without getting any reply.
I'd take that as a yes. As long as you've asked on the development list with a clear subject line, then you've given the community sufficient opportunity to say otherwise.
well, to me getting no reply, means neither yes nor no, but more a `don't know' or `don't care' ... but the question is, how to disable the library for non-c++11 compilers? e.g. shall the tests fail or be disabled, shall the library print a warning?
If you're not happy with this, then maybe ask on the steering committee list? (Although, they might not be happy with me for saying that....)
well, i was not aware that there is a separate list for the steering committee, was under the impression that the discussions about the boost development takes place on the boost-dev list ...
* there is no policy about c++11 libraries, so i cannot merge boost.lockfree into trunk by cutting the boost.atomic dependency
No, as long as your review manager is happy, you have every right to add your library to *trunk* and it really is advisable to do so.
hartmut?
* merging boost.lockfree now is too late, for the next release, as it is not in trunk because of the reasons mentioned above. well, it is not like it could introduce any regressions ....
Sure, I'm sympathetic as it sounds like you've been left in the lurch. I don't know how the other release managers would feel about it though so I can't promise anything.
please don't understand me wrong, i don't want to push the library for 1.51 (nor did i do that for 1.50 when i raised that question in the first place) ... it took two years between review request and review and the review took place during last year's summer of code ... i simply don't want to wait for another three years tim
On 29 June 2012 12:31, Tim Blechmann <tim@klingt.org> wrote:
me neither ... i guess no one knows, because i've asked this question before without getting any reply.
I'd take that as a yes. As long as you've asked on the development list with a clear subject line, then you've given the community sufficient opportunity to say otherwise.
well, to me getting no reply, means neither yes nor no, but more a `don't know' or `don't care' ...
If we always wait for a positive 'yes' then even less things would get done.
but the question is, how to disable the library for non-c++11 compilers? e.g. shall the tests fail or be disabled, shall the library print a warning?
Whatever you think best I think. I would be inclined to let the tests fail naturally, and mark them up as expected failures, but it's quite hard to do that for non-c++11 compilers, so maybe the tests should be disabled? But it's up to you really.
On 29 June 2012 12:31, Tim Blechmann <tim@klingt.org> wrote:
* there is no policy about c++11 libraries, so i cannot merge boost.lockfree into trunk by cutting the boost.atomic dependency
No, as long as your review manager is happy, you have every right to add your library to *trunk* and it really is advisable to do so.
hartmut?
Just looked at the review results, and there are no conditions, so you can add to trunk. I only mentioned about the review manager being happy because often conditions are placed on acceptance. So do go ahead.
* there is no policy about c++11 libraries, so i cannot merge boost.lockfree into trunk by cutting the boost.atomic dependency
No, as long as your review manager is happy, you have every right to add your library to *trunk* and it really is advisable to do so.
hartmut?
I have no objections. However I'd suggest leaving the boost.atomics library as an implementation detail as part of your library. We will have many users of C++03 for quite some time. It would be a pity to have your library available on C++11 platforms only. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
* there is no policy about c++11 libraries, so i cannot merge boost.lockfree into trunk by cutting the boost.atomic dependency
No, as long as your review manager is happy, you have every right to add your library to *trunk* and it really is advisable to do so.
hartmut?
I have no objections. However I'd suggest leaving the boost.atomics library as an implementation detail as part of your library. We will have many users of C++03 for quite some time. It would be a pity to have your library available on C++11 platforms only.
i'm not a big fan of adding boost.atomic as implementation detail: * atomic should not be pulled into the namespace boost, but should live in boost::lockfree::detail. however i'm pulling either std::atomic or boost::atomic into boost::lockfree::detail, which means that everything should be in boost::lockfree::atomic_detail. with the highly templated design of boost.atomic this is quite a pains, because i have to touch about every other line. i could simply leave atomic in namespace boost, but that does not sound right to me, either * the examples require atomic_int. i could however just make the examples c++11-only tim
On Fri, Jun 29, 2012 at 12:36:01PM +0200, Tim Blechmann wrote:
* boost.atomic seems to be dead, at least helge does not respond anymore and the library will probably be obsolete, because once it is merged, all compilers will support std::atomic
I strongly disagree with this statement. There's a lot of compilers that Boost still pretends to care about. It would be very unfortunate if we devolve into just targetting the "popular" few. -- Lars Viklund | zao@acc.umu.se
* boost.atomic seems to be dead, at least helge does not respond anymore and the library will probably be obsolete, because once it is merged, all compilers will support std::atomic
I strongly disagree with this statement.
There's a lot of compilers that Boost still pretends to care about. It would be very unfortunate if we devolve into just targetting the "popular" few.
well, atm, only very few compilers provide std::atomics. no idea about the m$ world, but boost.lockfree requires gcc-4.7 or the latest clang (the one currently shipped by xcode is not sufficient) so for now one has to look hard for a compiler, that boost.lockfree would support out of the box. boost.atomic would be wonderful way to support older (read current) compilers, but helge would have to show up again, or someone would have to adopt boost.atomic tim
On Fri, Jun 29, 2012 at 9:47 AM, Tim Blechmann <tim@klingt.org> wrote:
well, atm, only very few compilers provide std::atomics. no idea about the m$ world, but boost.lockfree requires gcc-4.7 or the latest clang (the one currently shipped by xcode is not sufficient) so for now one has to look hard for a compiler, that boost.lockfree would support out of the box.
The libc++ version of Xcode coming out this month (4.5) supports C++11 atomics, also currently accessible if you are a member of one of Apple's developer programs. I've been watching and waiting for Boost.lockfree for some time now, I know of two separate open source projects that could really make use of this tool. I would be happy to participate in testing as I see it is already in svn trunk, although please forgive me for being slow as I've so far only been using boost from compiled binaries. Happy to see this moving forward! Cheers, Rich
On 29.06.2012 17:30, Lars Viklund wrote:
There's a lot of compilers that Boost still pretends to care about. It would be very unfortunate if we devolve into just targetting the "popular" few. I think that Boots should support not the "popular" compilers but the modern ones. The users of the old compilers may use the old versions of Boost. The existence of old and unpopular compilers should not prevent the Boost from using the modern language features. Note that these compilers will never disappear.
-- Sergey Cheban
There's a lot of compilers that Boost still pretends to care about. It would be very unfortunate if we devolve into just targetting the "popular" few.
I think that Boots should support not the "popular" compilers but the modern ones. The users of the old compilers may use the old versions of Boost. The existence of old and unpopular compilers should not prevent the Boost from using the modern language features. Note that these compilers will never disappear.
I'd thought the Boost community had invested a ton of effort specifically so one could write modern code for both old and new compilers. - Rhys
On 29.06.2012 18:26, Rhys Ulerich wrote:
I think that Boots should support not the "popular" compilers but the modern ones. The users of the old compilers may use the old versions of Boost. The existence of old and unpopular compilers should not prevent the Boost from using the modern language features. Note that these compilers will never disappear. I'd thought the Boost community had invested a ton of effort specifically so one could write modern code for both old and new compilers. So, should we forbid the exceptions usage in the Boost because there are some old compilers that do not support them?
The future of the boost::atomic is not clear, the maintainer is unresponsive. So, we have only two options: 1. Use std::atomic and make boost.lockfree available for the modern compilers. 2. Don't add the boost.lockfree. I think that the first option is better. And it doesn't prevent us from switching to the boost::atomic. -- Sergey Cheban
Sergey Cheban wrote:
On 29.06.2012 17:30, Lars Viklund wrote:
There's a lot of compilers that Boost still pretends to care about. It would be very unfortunate if we devolve into just targetting the "popular" few.
I think that Boots should support not the "popular" compilers but the modern ones. The users of the old compilers may use the old versions of Boost.
The existence of old and unpopular compilers should not prevent the Boost from using the modern language features. Note that these compilers will never disappear.
Boost cannot afford to be so purist or there will be few that use our libraries. We do, and must, drop support for old compilers. We should permit individual libraries to target only very recent compilers, if the library author so chooses and there is good reason. However, that's not the same as all of Boost supporting only very recent compilers. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 29.06.2012 18:39, Stewart, Robert wrote:
The existence of old and unpopular compilers should not prevent the Boost from using the modern language features. Note that these compilers will never disappear.
Boost cannot afford to be so purist or there will be few that use our libraries. We do, and must, drop support for old compilers.
We should permit individual libraries to target only very recent compilers, if the library author so chooses and there is good reason. I think this is the case with boost.lockfree. It is not easy to implement it without atomics, and there are no atomics for the C++03 (yet).
However, that's not the same as all of Boost supporting only very recent compilers. Agree.
-- Sergey Cheban
Sergey Cheban wrote:
On 29.06.2012 18:39, Stewart, Robert wrote:
The existence of old and unpopular compilers should not prevent the Boost from using the modern language features. Note that these compilers will never disappear.
Boost cannot afford to be so purist or there will be few that use our libraries. We do, and must, drop support for old compilers.
We should permit individual libraries to target only very recent compilers, if the library author so chooses and there is good reason.
I think this is the case with boost.lockfree. It is not easy to implement it without atomics, and there are no atomics for the C++03 (yet).
I already suggested that Tim add Lockfree to trunk with only C++11 support, so you're arguing against the wind, I guess. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Fri, Jun 29, 2012 at 05:17:51PM +0000, Stewart, Robert wrote:
Sergey Cheban wrote:
On 29.06.2012 18:39, Stewart, Robert wrote:
The existence of old and unpopular compilers should not prevent the Boost from using the modern language features. Note that these compilers will never disappear.
Boost cannot afford to be so purist or there will be few that use our libraries. We do, and must, drop support for old compilers.
We should permit individual libraries to target only very recent compilers, if the library author so chooses and there is good reason.
I think this is the case with boost.lockfree. It is not easy to implement it without atomics, and there are no atomics for the C++03 (yet).
I already suggested that Tim add Lockfree to trunk with only C++11 support, so you're arguing against the wind, I guess.
And thus begins the downfall. One library will start to depend on Lockfree, and soon it's all a right mess of trying to get anything to work on a perfectly conformant C++03 compiler. -- Lars Viklund | zao@acc.umu.se
On 29 June 2012 19:37, Lars Viklund <zao@acc.umu.se> wrote:
I already suggested that Tim add Lockfree to trunk with only C++11 support, so you're arguing against the wind, I guess.
And thus begins the downfall.
One library will start to depend on Lockfree, and soon it's all a right mess of trying to get anything to work on a perfectly conformant C++03 compiler.
It's only in trunk, we can discuss this before release (under an appropriate subject line so that people see it....). There are a number of possible solutions to the issue, but I don't think it's fair to block an accepted library that is in condition. A successful review process should mean something.
We should permit individual libraries to target only very recent compilers, if the library author so chooses and there is good reason.
I think this is the case with boost.lockfree. It is not easy to implement it without atomics, and there are no atomics for the C++03 (yet).
I already suggested that Tim add Lockfree to trunk with only C++11 support, so you're arguing against the wind, I guess.
And thus begins the downfall.
at one point, library authors will want to use c++11 language features which cannot be emulated like lambdas? of course we could use c++03 forever ... one way could be to provide a c++11-only version of boost (boost), which includes c++11 libraries and possibly strips all boost libraries, which have been included in c++11?
One library will start to depend on Lockfree, and soon it's all a right mess of trying to get anything to work on a perfectly conformant C++03 compiler.
boost.atomic cannot really be implemented in c++03, as it requires assembly code and/or thread locks ... so one will always have to use something on top like inline assembly or system-specific thread libraries ... but that is probably also the case for things like shared_ptr. that said, if a library starts to depend on lockfree, it can still be supported by old compilers, if boost.atomic will ever be added. i (as in boost.atomic review manager) would be very happy to see that someone adopts the library! iac, will try to add lockfree to trunk this weekend tim
On Jun 29, 2012, at 1:20 PM, Tim Blechmann wrote:
We should permit individual libraries to target only very recent compilers, if the library author so chooses and there is good reason.
I think this is the case with boost.lockfree. It is not easy to implement it without atomics, and there are no atomics for the C++03 (yet).
I already suggested that Tim add Lockfree to trunk with only C++11 support, so you're arguing against the wind, I guess.
And thus begins the downfall.
at one point, library authors will want to use c++11 language features which cannot be emulated like lambdas? of course we could use c++03 forever ...
one way could be to provide a c++11-only version of boost (boost), which includes c++11 libraries and possibly strips all boost libraries, which have been included in c++11?
One library will start to depend on Lockfree, and soon it's all a right mess of trying to get anything to work on a perfectly conformant C++03 compiler.
iac, will try to add lockfree to trunk this weekend
I just turned on a Linux and Darwin clang trunk c++0x build. Hope that helps. -- Noel
One library will start to depend on Lockfree, and soon it's all a right mess of trying to get anything to work on a perfectly conformant C++03 compiler.
iac, will try to add lockfree to trunk this weekend I just turned on a Linux and Darwin clang trunk c++0x build. Hope that helps.
nice! i suppose darwin/clang uses libc++, not libstdc++? that's a platform i don't have access to tim
On Jun 29, 2012, at 1:38 PM, Tim Blechmann wrote:
One library will start to depend on Lockfree, and soon it's all a right mess of trying to get anything to work on a perfectly conformant C++03 compiler.
iac, will try to add lockfree to trunk this weekend I just turned on a Linux and Darwin clang trunk c++0x build. Hope that helps.
nice! i suppose darwin/clang uses libc++, not libstdc++?
Yes, I believe that's correct.
that's a platform i don't have access to
Once the tests cycle and your library is in trunk, email me directly and I'll help you as best I can. -- Noel
On 30 June 2012 10:26, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Jun 29, 2012, at 1:38 PM, Tim Blechmann wrote:
> One library will start to depend on Lockfree, and soon it's all a > right mess of trying to get anything to work on a perfectly > conformant C++03 compiler.
iac, will try to add lockfree to trunk this weekend I just turned on a Linux and Darwin clang trunk c++0x build. Hope that helps.
nice! i suppose darwin/clang uses libc++, not libstdc++?
Yes, I believe that's correct.
As of Xcode 4.3, new C++ projects default to clang and libstdc++; the settings are orthogonal. Default settings for new projects do not specify a C++ dialect, and produce warnings when C++11 features (i.e. variadic templates, auto/overload/final keywords) are encountered. The default dialect may change soon; I've no personal information regarding Apple's confidence in clang's C++11 support. I would expect better IDE (autocomplete, etc.) support for 'auto' variables at least. I doubt the default standard library selection will change soon, because of the lack of debug introspection support for the std::string changes. At least... I hope they're planning to fix that first/soon.
I think this is the case with boost.lockfree. It is not easy to implement it without atomics, and there are no atomics for the C++03 (yet).
I already suggested that Tim add Lockfree to trunk with only C++11 support, so you're arguing against the wind, I guess.
And thus begins the downfall.
One library will start to depend on Lockfree, and soon it's all a right mess of trying to get anything to work on a perfectly conformant C++03 compiler.
Apologies for not following this discussion in full - but Boost has *always* pushed the compiler envelope. Right from the start libraries required C++98 features that at the time were implemented in very few compilers. It's not new for a library to be at the bleeding edge waiting for it's time to come. John.
On Sat, Jun 30, 2012 at 08:38:57AM +0100, John Maddock wrote:
I think this is the case with boost.lockfree. It is not easy to implement it without atomics, and there are no atomics for the C++03 (yet).
I already suggested that Tim add Lockfree to trunk with only C++11 support, so you're arguing against the wind, I guess.
And thus begins the downfall.
One library will start to depend on Lockfree, and soon it's all a right mess of trying to get anything to work on a perfectly conformant C++03 compiler.
Apologies for not following this discussion in full - but Boost has *always* pushed the compiler envelope. Right from the start libraries required C++98 features that at the time were implemented in very few compilers. It's not new for a library to be at the bleeding edge waiting for it's time to come.
There's a major difference between C++98 and C++11. Before '98, there was no standard. Before '11, there is a perfectly usable standard that bajillions depend on. I'm just fearing that there'll be more premature C++11 taint by the day in Boost, making it less and less usable on C++03 as versions come out. -- Lars Viklund | zao@acc.umu.se
On Jun 30, 2012, at 8:43 AM, Lars Viklund wrote:
I'm just fearing that there'll be more premature C++11 taint by the day in Boost, making it less and less usable on C++03 as versions come out.
My thinking on this is that just because you're forced to live in a cave and code on bongos is no reason why I can't have nice things. Besides, it's a bit difficult to "establish 'existing practice' and provide reference implementations so that Boost libraries are suitable for eventual standardization" when you aren't even targeting the current standard. Steve
Steve Ramsey wrote:
On Jun 30, 2012, at 8:43 AM, Lars Viklund wrote:
I'm just fearing that there'll be more premature C++11 taint by the day in Boost, making it less and less usable on C++03 as versions come out.
Standard compliant code is hardly a taint.
My thinking on this is that just because you're forced to live in a cave and code on bongos is no reason why I can't have nice things.
Hyperbole aside, I agree with your sentiment.
Besides, it's a bit difficult to "establish 'existing practice' and provide reference implementations so that Boost libraries are suitable for eventual standardization" when you aren't even targeting the current standard.
Right. Boost is much less about long term support than it is about advancing the state of the art in C++ library design and standardization. Accommodating users of older compilers has always been up to the individual library author. Conditional compilation is a pain they must choose to incur and endure. If you want a library to add support for your platform, it's up to you to encourage the library maintainer to add support or to contribute patches in the hopes the maintainer will adopt them. There is no other option. You're asking that no C++11-only library -- despite passing the review process -- be permitted in Boost solely on the grounds that it doesn't support your platform or that it will ease the development and maintenance of other libraries which will then no longer support your platform. Older platforms are deprecated either by consensus or attrition. If you have one of those platforms, you necessarily must use an older version of Boost. I have several of those to support. My preference is to push ahead those languishing on older platforms. That reduces the number of platforms I must support both in terms of building my libraries and applications and in ongoing maintenance. Why should a *volunteer* organization like Boost be expected to do anything different? _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Tue, Jul 03, 2012 at 11:05:10AM +0000, Stewart, Robert wrote:
Steve Ramsey wrote:
On Jun 30, 2012, at 8:43 AM, Lars Viklund wrote:
I'm just fearing that there'll be more premature C++11 taint by the day in Boost, making it less and less usable on C++03 as versions come out.
Standard compliant code is hardly a taint.
My thinking on this is that just because you're forced to live in a cave and code on bongos is no reason why I can't have nice things.
Hyperbole aside, I agree with your sentiment.
Besides, it's a bit difficult to "establish 'existing practice' and provide reference implementations so that Boost libraries are suitable for eventual standardization" when you aren't even targeting the current standard.
Right. Boost is much less about long term support than it is about advancing the state of the art in C++ library design and standardization. Accommodating users of older compilers has always been up to the individual library author. Conditional compilation is a pain they must choose to incur and endure. If you want a library to add support for your platform, it's up to you to encourage the library maintainer to add support or to contribute patches in the hopes the maintainer will adopt them. There is no other option.
Fair enough, it seems like I've misunderstood some aspects of our mission. I've always thought it was to smooth out the fragmented ecosystem. Seems like I was wrong all along then. -- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote:
On Tue, Jul 03, 2012 at 11:05:10AM +0000, Stewart, Robert wrote:
Steve Ramsey wrote: Right. Boost is much less about long term support than it is about advancing the state of the art in C++ library design and standardization. Accommodating users of older compilers has always been up to the individual library author. Conditional compilation is a pain they must choose to incur and endure. If you want a library to add support for your platform, it's up to you to encourage the library maintainer to add support or to contribute patches in the hopes the maintainer will adopt them. There is no other option.
Fair enough, it seems like I've misunderstood some aspects of our mission. I've always thought it was to smooth out the fragmented ecosystem.
I haven't read all the posts on this thread - but I'll add a couple observations anyway. a) I don't see any real conflict between these points of view. b) This is a variation on a problem boost has successfully dealt with for years. Three is a wide variety of C++ compilers which boost supports. Most of these fail in some way to be exactly standard conforming. In some cases, there are very few failures and in other cases there are many. This has been handled by boost.config in a very systematic, convenient and complete way by defiining macros which indicate the failures, non-supported features etc of the particular compiler. see for example BOOST_NO_0X_HDR_ARRAY etc. Boost has never required that a library support a non conforming compiler - only that it be compatible with the C++ standard. Never the less, authors who want to see their library used have used the above system to make their library as widely useful as is practical. That is, a library author may a) use C++03 (or decline to re-implement an existing library using C++11) b) selectivly use C++11 features and support both via the macros above. c) require C++11 features - and gracefully fail to compile when the macros above indicate that the compiler can't be supported. The size and nature of the library itself will likely determine which of the above will be the best course. It's not so much that I'm advocating any thing in the above list. It's more that I believe that this will happen and that it's a good solution. Perhaps the only thing I would add is that library documentation and website library list might add a little data as to what level of C++ compliance the library requires. Robert Ramey
On 30 June 2012 10:43, Lars Viklund <zao@acc.umu.se> wrote:
There's a major difference between C++98 and C++11. Before '98, there was no standard. Before '11, there is a perfectly usable standard that bajillions depend on.
And there is a perfectly useable Boost they can use with it.
I'm just fearing that there'll be more premature C++11 taint by the day in Boost, making it less and less usable on C++03 as versions come out.
Why is it premature? It doesn't make Boost less useable on C++03; it just means that less and less *new* libraries will be for that dead end dialect of C++.-- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On Sat, Jun 30, 2012 at 02:51:30PM -0500, Nevin Liber wrote:
On 30 June 2012 10:43, Lars Viklund <zao@acc.umu.se> wrote:
There's a major difference between C++98 and C++11. Before '98, there was no standard. Before '11, there is a perfectly usable standard that bajillions depend on.
And there is a perfectly useable Boost they can use with it.
I'm just fearing that there'll be more premature C++11 taint by the day in Boost, making it less and less usable on C++03 as versions come out.
Why is it premature? It doesn't make Boost less useable on C++03; it just means that less and less *new* libraries will be for that dead end dialect of C++.-- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Please let me in through the dimensional portal where there's widely spread compilers that properly targets C++11. It's cold on this side. Seriously though, are you proposing that anyone that has to use C++03 should be locked for all eternity at some ancient Boost version, even though there's functionality in newer ones they very much would like to use? Should we doom a large majority of developers to keep personal patch sets against their Boosts, resulting in a largely fragmented and impossible-to-handle ecosystem? Things might get slightly less horrible with modularized Boost, where everyone can run their own vaguely compatible "releases" of Boost, but it's still a major support nightmare. I see this primarily from an end-user support and end-user perspective, not as any library author or release mangler. -- Lars Viklund | zao@acc.umu.se
On 30 June 2012 16:19, Lars Viklund <zao@acc.umu.se> wrote:
Seriously though, are you proposing that anyone that has to use C++03 should be locked for all eternity at some ancient Boost version, even though there's functionality in newer ones they very much would like to use?
I don't see how they are stuck on an ancient version of Boost. It just means there are some libraries they can't use. At some point in the future, they will be stuck. But it will be gradual, not abrupt. Just as has been done for those "dialects" (for lack of a better word) of C++ embodied by gcc before 4.2, Visual Studio before 8.0, etc., eventually you don't get supported.
Should we doom a large majority of developers to keep personal patch sets against their Boosts, resulting in a largely fragmented and impossible-to-handle ecosystem?
I don't see how adding C++11 only libraries to Boost has this result.
I see this primarily from an end-user support and end-user perspective, not as any library author or release mangler.
What I don't understand is how people who have the ability to upgrade both Boot boost and compilers (you have to, because Boost periodically drops support for old ones) don't have the ability to ever turn on the C++11 flag. (Other than some pathological cases, like having multiple targets for a product where you have to wait until all your various compilers and libraries catch up with each other). It's a burden to target two different languages (even with one being close to a superset of the other), and I'd rather see C++11 only libraries than no libraries because that burden is too high. Because that is the choice we have to make. Right now that burden is too high for boost.lockfree. If that burden gets lower (by, say, someone so concerned that Boost is going to drop C++03 support that they take over boost.atomic), by all means add C++03 functionality (and I believe the author is certainly willing to do so). The purpose of C++ standardization is not to fragment the community, but to grow it and push it ahead. If it ends up fragmenting, either we didn't put enough effort into backwards compatibility (blocking people from moving forward) or way too much effort into backwards compatibility (people just don't care to move their code bases over to C++11). -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
participants (21)
-
Belcourt, Kenneth -
Christopher Kormanyos -
Daniel James -
Hartmut Kaiser -
John Maddock -
Jürgen Hunold -
KTC -
Lars Viklund -
Nathan Ridge -
Nevin Liber -
Oliver Kowalke -
Rhys Ulerich -
Rich E -
Robert Ramey -
Rowan James -
Sergey Cheban -
Stephan T. Lavavej -
Steve Ramsey -
Stewart, Robert -
Tim Blechmann -
Tim Moore