Hi release managers, I have been working to get the uuid library to pass for the different toolsets in trunk. The only failures (since my last check in, changeset 58370) are for 'codegear' and 'siliconman', which have to do with the random library or the test library, both of which have lots of failures as well. Should I somehow mark them as expected failures? Or is there a way (for test at least) to use the test library differently than I am? Do you want me (I assume me) to put the uuid library into the release branch? I know this is the last day to add new libraries. I am not trying to push it in. I just want to do know what you want me to do. Wait until the next release or put it in this release? Regards, Andy.
On Tue, Dec 15, 2009 at 2:35 AM, Andy Tompkins <atompkins@fastmail.fm> wrote:
I have been working to get the uuid library to pass for the different toolsets in trunk. The only failures (since my last check in, changeset 58370) are for 'codegear' and 'siliconman', which have to do with the random library or the test library, both of which have lots of failures as well. Should I somehow mark them as expected failures? Or is there a way (for test at least) to use the test library differently than I am?
Do you want me (I assume me) to put the uuid library into the release branch? I know this is the last day to add new libraries. I am not trying to push it in. I just want to do know what you want me to do. Wait until the next release or put it in this release?
I am not a Release Manager, but I think since you are the maintainer of the library it should be your call when you merge it to the release branch. I think the expected failures marking and the clear documentation that it won't be supported by certain compilers (with a promise to make it work on those compilers granted that other libraries you depend on if you intend to do that) should be enough. For one, I look forward to seeing this library released soon so that I can justify using it for one of my projects that needs UUID support. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
2009/12/14 Andy Tompkins <atompkins@fastmail.fm>:
Hi release managers,
I have been working to get the uuid library to pass for the different toolsets in trunk. The only failures (since my last check in, changeset 58370) are for 'codegear' and 'siliconman', which have to do with the random library or the test library, both of which have lots of failures as well. Should I somehow mark them as expected failures? Or is there a way (for test at least) to use the test library differently than I am?
You can mark them as expected failures by editing 'status/explicit-failures-markup.xml'. Hopefully, it's clear how to do that from the existing entries. Remember to validate the xml before checking (instructions are in the file). This isn't that time to change it, but you don't have to use Boost.Test if you don't want to, there's a very simple test library at 'boost/detail/lightweight_test.hpp'. It's a lot more portable, although it only has a small subset of Boost.Test's features. You can see other libraries' tests for examples (eg. bind, exception, filesystem, flyweight, smart_ptr), the most important thing is to remember to end your main function with 'return ::boost::report_errors()'.
Do you want me (I assume me) to put the uuid library into the release branch? I know this is the last day to add new libraries. I am not trying to push it in. I just want to do know what you want me to do. Wait until the next release or put it in this release?
Don't merge to release until you get our go ahead, there are few things we need to check first. I think the library's in pretty good shape at the moment, so it's okay if it's merged to release a little late because we held you up. Our checklist is here: https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#NewL... I've added your library to the root index.html file, and will add it to the website. The inspect results are clean, so I think the only things left to do are to check the documentation and make sure the test results are fine. I get the following when I run test_generators on darwin ppc. Could it be an endian issue? Running 1 test case... test_generators.cpp:95: error in "test_main_caller( argc, argv )": check u == wcorrect failed [86426ef2-6bb9-5e5b-9346-537c41af5346 != 5becf207-1cd2-5966-8b44-f57f230a68b9] test_generators.cpp:103: error in "test_main_caller( argc, argv )": check u == wcorrect failed [86426ef2-6bb9-5e5b-9346-537c41af5346 != 5becf207-1cd2-5966-8b44-f57f230a68b9] *** 2 failures detected in test suite "Test Program" EXIT STATUS: 201 Daniel
On Mon, 14 Dec 2009 20:46 +0000, "Daniel James" <daniel_james@fmail.co.uk> wrote:
2009/12/14 Andy Tompkins <atompkins@fastmail.fm>:
Hi release managers,
I have been working to get the uuid library to pass for the different toolsets in trunk. The only failures (since my last check in, changeset 58370) are for 'codegear' and 'siliconman', which have to do with the random library or the test library, both of which have lots of failures as well. Should I somehow mark them as expected failures? Or is there a way (for test at least) to use the test library differently than I am?
You can mark them as expected failures by editing 'status/explicit-failures-markup.xml'. Hopefully, it's clear how to do that from the existing entries. Remember to validate the xml before checking (instructions are in the file).
This isn't that time to change it, but you don't have to use Boost.Test if you don't want to, there's a very simple test library at 'boost/detail/lightweight_test.hpp'. It's a lot more portable, although it only has a small subset of Boost.Test's features. You can see other libraries' tests for examples (eg. bind, exception, filesystem, flyweight, smart_ptr), the most important thing is to remember to end your main function with 'return ::boost::report_errors()'.
Good to know. Thanks.
Do you want me (I assume me) to put the uuid library into the release branch? I know this is the last day to add new libraries. I am not trying to push it in. I just want to do know what you want me to do. Wait until the next release or put it in this release?
Don't merge to release until you get our go ahead, there are few things we need to check first. I think the library's in pretty good shape at the moment, so it's okay if it's merged to release a little late because we held you up. Our checklist is here:
https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#NewL...
I've added your library to the root index.html file, and will add it to the website. The inspect results are clean, so I think the only things left to do are to check the documentation and make sure the test results are fine.
I get the following when I run test_generators on darwin ppc. Could it be an endian issue?
Running 1 test case... test_generators.cpp:95: error in "test_main_caller( argc, argv )": check u == wcorrect failed [86426ef2-6bb9-5e5b-9346-537c41af5346 != 5becf207-1cd2-5966-8b44-f57f230a68b9] test_generators.cpp:103: error in "test_main_caller( argc, argv )": check u == wcorrect failed [86426ef2-6bb9-5e5b-9346-537c41af5346 != 5becf207-1cd2-5966-8b44-f57f230a68b9]
*** 2 failures detected in test suite "Test Program"
EXIT STATUS: 201
Daniel
Sorry I didn't realize I send my response already, as I was not finished. On Mon, 14 Dec 2009 20:46 +0000, "Daniel James" <daniel_james@fmail.co.uk> wrote:
2009/12/14 Andy Tompkins <atompkins@fastmail.fm>:
Hi release managers,
I have been working to get the uuid library to pass for the different toolsets in trunk. The only failures (since my last check in, changeset 58370) are for 'codegear' and 'siliconman', which have to do with the random library or the test library, both of which have lots of failures as well. Should I somehow mark them as expected failures? Or is there a way (for test at least) to use the test library differently than I am?
You can mark them as expected failures by editing 'status/explicit-failures- markup.xml'. Hopefully, it's clear how to do that from the existing entries. Remember to validate the xml before checking (instructions are in the file).
This does not look too hard. I will do this. Thanks.
This isn't that time to change it, but you don't have to use Boost.Test if you don't want to, there's a very simple test library at 'boost/detail/lightweight_test.hpp'. It's a lot more portable, although it only has a small subset of Boost.Test's features. You can see other libraries' tests for examples (eg. bind, exception, filesystem, flyweight, smart_ptr), the most important thing is to remember to end your main function with 'return ::boost::report_errors()'.
Good to know.
Do you want me (I assume me) to put the uuid library into the release branch? I know this is the last day to add new libraries. I am not trying to push it in. I just want to do know what you want me to do. Wait until the next release or put it in this release?
Don't merge to release until you get our go ahead, there are few things we need to check first.
No worries. That is why I asked.
I think the library's in pretty good shape at the moment, so it's okay if it's merged to release a little late because we held you up. Our checklist is here:
https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#NewL...
I've added your library to the root index.html file, and will add it to the website. The inspect results are clean, so I think the only things left to do are to check the documentation and make sure the test results are fine.
I get the following when I run test_generators on darwin ppc. Could it be an endian issue?
Running 1 test case... test_generators.cpp:95: error in "test_main_caller( argc, argv )": check u == wcorrect failed [86426ef2-6bb9-5e5b-9346- 537c41af5346 != 5becf207-1cd2-5966-8b44-f57f230a68b9] test_generators.cpp:103: error in "test_main_caller( argc, argv )": check u == wcorrect failed [86426ef2-6bb9-5e5b-9346-537c41af5346 != 5becf207-1cd2-5966-8b44-f57f230a68b9]
*** 2 failures detected in test suite "Test Program"
EXIT STATUS: 201
I did have endian issues as well as sizeof(wchar_t) issues. I checked in a fix (revision 58262) for this. The regression test details for 'Sandia-tiger- ppc' (http://tinyurl.com/ydtff27) are not helpful. So, what revision did you run yours with.
Daniel
Regards, Andy Tompkins
2009/12/15 Andy Tompkins <atompkins@fastmail.fm>:
I did have endian issues as well as sizeof(wchar_t) issues. I checked in a fix (revision 58262) for this. The regression test details for 'Sandia-tiger- ppc' (http://tinyurl.com/ydtff27) are not helpful. So, what revision did you run yours with.
I'm not sure. But I just reran the test and it passed, so I probably forgot to update it. The Sandia powerpc test failure is probably because the test times out, it takes 20 minutes on 1.9 GHZ G5. I've had a look at you documentation, and I've attached some markup changes. This is mainly cleaning it up so that it'll work better with our tools. I also added a border round the 'pre' blocks, which I find makes it a lot easier to read. It wasn't clear where the code started and ended. I found the order of the documentation a bit odd. The rationale sits oddly between the synopsis and interface sections. It also reads to me like it should be in the introduction at the start as it provides a nice motivation for the library. And generally we put the documentation for the members of a header next to the synopsis of that header. So I'd structure the reference something like this: Reference boost/uuid/uuid.hpp synopsis operators nil uuid byte extraction hash function boost/uuid/uuid_io.hpp synopsis input and output boost/uuid/uuid_serialize.hpp synopsis serialization boost/uuid/uuid_generators.hpp synopsis generation Does that make seem okay to you? Daniel
On Tue, Dec 15, 2009 at 3:29 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
2009/12/15 Andy Tompkins <atompkins@fastmail.fm>:
I did have endian issues as well as sizeof(wchar_t) issues. I checked in a fix (revision 58262) for this. The regression test details for 'Sandia-tiger- ppc' (http://tinyurl.com/ydtff27) are not helpful. So, what revision did you run yours with.
I'm not sure. But I just reran the test and it passed, so I probably forgot to update it. The Sandia powerpc test failure is probably because the test times out, it takes 20 minutes on 1.9 GHZ G5.
Ouch! Please remember that every test has some cost to testers, and Boost has hundreds, if not thousands, or tests. 20 minutes is an eternity. As a courtesy to testers, please structure tests for reasonable run times. --Beman
Daniel James wrote:
Do you want me (I assume me) to put the uuid library into the release branch? I know this is the last day to add new libraries. I am not trying to push it in. I just want to do know what you want me to do. Wait until the next release or put it in this release?
Don't merge to release until you get our go ahead, there are few things we need to check first. I think the library's in pretty good shape at the moment, so it's okay if it's merged to release a little late because we held you up. Our checklist is here:
https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#NewL...
I've added your library to the root index.html file, and will add it to the website. The inspect results are clean, so I think the only things left to do are to check the documentation and make sure the test results are fine.
Daniel, could you check the documentation? It surely exists and looks fine to me, except for slightly suboptimal formatting of examples, but I'd rather have you review that. As for tests, they seem to be mostly clean now. Andy, could you investigate the few remaining ones -- probably just adding 'expected' markup? - Volodya
On Thu, 31 Dec 2009 09:49 +0300, "Vladimir Prus" <vladimir@codesourcery.com> wrote:
Daniel James wrote:
Do you want me (I assume me) to put the uuid library into the release branch? I know this is the last day to add new libraries. I am not trying to push it in. I just want to do know what you want me to do. Wait until the next release or put it in this release?
Don't merge to release until you get our go ahead, there are few things we need to check first. I think the library's in pretty good shape at the moment, so it's okay if it's merged to release a little late because we held you up. Our checklist is here:
https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#NewL...
I've added your library to the root index.html file, and will add it to the website. The inspect results are clean, so I think the only things left to do are to check the documentation and make sure the test results are fine.
Daniel, could you check the documentation? It surely exists and looks fine to me, except for slightly suboptimal formatting of examples, but I'd rather have you review that.
As for tests, they seem to be mostly clean now. Andy, could you investigate the few remaining ones -- probably just adding 'expected' markup?
I believe this to be true. I will look into them again tonight and likely mark them as 'expected'.
- Volodya
Regards, Andy Tompkins
I've added your library to the root index.html file, and will add it to the website. The inspect results are clean, so I think the only things left to do are to check the documentation and make sure the test results are fine.
Daniel, could you check the documentation? It surely exists and looks fine to me, except for slightly suboptimal formatting of examples, but I'd rather have you review that.
As for tests, they seem to be mostly clean now. Andy, could you investigate the few remaining ones -- probably just adding 'expected' markup?
I believe this to be true. I will look into them again tonight and likely mark them as 'expected'.
I updated the documentation (added the markup - thank you, and reorganized). I also marked all the tests on a few platforms as expected failures (I hope I did it right). I don't know what is wrong with the tests for sun-5.10 (http://tinyurl.com/yeuelll).
- Volodya
Regards, Andy Tompkins
Regards, Andy Tompkins
2010/1/1 Andy Tompkins <atompkins@fastmail.fm>:
I updated the documentation (added the markup - thank you, and reorganized). I also marked all the tests on a few platforms as expected failures (I hope I did it right).
It looks good to me.
I don't know what is wrong with the tests for sun-5.10 (http://tinyurl.com/yeuelll).
Looks like a compiler bug. It gets confused by passing an array and a pointer. Try the attached patch, it also fixes a minor bug (digits_end is incorrect in your current version and will return an unspecified result if c is '\0') and adds a small optimization to avoid checking the pointer. There isn't actually much point in using std::distance, you could just subtract, but I left that alone. The patch also contains a fix for the very slow test_generators on OS X. It turns out that every time you open '/dev/random' it initiates it, which is very slow. So the patch opens it once when seed_rng is created and reuses the same stream. Daniel
Hi Daniel, On Sat, 02 Jan 2010 15:15 +0000, "Daniel James" <daniel_james@fmail.co.uk> wrote:
2010/1/1 Andy Tompkins <atompkins@fastmail.fm>:
I updated the documentation (added the markup - thank you, and reorganized). I also marked all the tests on a few platforms as expected failures (I hope I did it right).
It looks good to me.
Thanks.
I don't know what is wrong with the tests for sun-5.10 (http://tinyurl.com/yeuelll).
Looks like a compiler bug. It gets confused by passing an array and a pointer. Try the attached patch, it also fixes a minor bug (digits_end is incorrect in your current version and will return an unspecified result if c is '\0') and adds a small optimization to avoid checking the pointer. There isn't actually much point in using std::distance, you could just subtract, but I left that alone.
Thank you so much. I fixed the minor bug you pointed out, added the optimization. In the future I will remove std::distance.
The patch also contains a fix for the very slow test_generators on OS X. It turns out that every time you open '/dev/random' it initiates it, which is very slow. So the patch opens it once when seed_rng is created and reuses the same stream.
This is really great! I had no idea why the test was so slow.
Daniel
Thanks again so much! Andy Tompkins
participants (5)
-
Andy Tompkins -
Beman Dawes -
Daniel James -
Dean Michael Berris -
Vladimir Prus