The nowide library was reviewed and accepted into Boost almost 3 years ago. I implemented most of fixes required under Review Fixed branch https://github.com/artyom-beilis/nowide/tree/reviewfixes Unfortunately I don't have any capacity to do maintenance for it on all various platforms: MSVC, mingw. cygwin etc mostly because virtually I don't develop on Windows and any time I need to go there I need to figure it out from the beginning (installations, environment, msvc) and I don't even have windows machine in my hands (all done in VM) I realized that I'm not windows developer any more and it would be impossible for me to complete the mission of maintaining the code mostly due to personal reasons and lack of development resources. I deeply regret wasting the time and effort of so many boost developers who invested to review. I understand that it is highly desired library but I just can get the job done I seek for your advice. Do I need to seek for an another maintainer or withdraw the library entirely? Once again sorry for disappointing the community and people who were invested in this library. Artyom Beilis
On Sat, Nov 30, 2019 at 6:21 AM Artyom Beilis via Boost
Do I need to seek for an another maintainer or withdraw the library entirely?
This library looks useful. Beast promises the ability to open files with utf-8 encoded pathnames, but I never did around to implementing it: https://www.boost.org/doc/libs/1_71_0/libs/beast/doc/html/beast/ref/boost__b... Thanks
Hi Artyom, Thanks for coming back on this topic. I am still convinced that your library is the best way to go and I continue to use it.
Unfortunately I don't have any capacity to do maintenance for it on all various platforms: MSVC, mingw. cygwin etc
When I submitted my additions to the type traits library, I relied on others for the tests on Windows and MSVC because I, also, am not a Windows programmer. I tested only gcc and intel compilers at that time. I guess that now, I would also test clang. For mingw and cygwin, I could probably help.
I seek for your advice. Do I need to seek for another maintainer or withdraw the library entirely?
It would be too bad to withdraw the library. What is the status of the library? Could you comment review_notes.txt on what is done, what is not? It seems to me that the doc has not been updated yet? For example, I do not see references to 0xFFFD as replacement character. Is it already fully functional on linux with gcc and clang? Do you have full tests available? If so, we can first run the tests on Windows and see what happens. There should be a way to run the tests automatically. Someone from the list can probably help us. By the way, I noticed something strange: you say that you do not develop in Windows but 3 files have Windows line endings: - include/boost/nowide/utf8_codecvt.hpp - test/test_codecvt.cpp - test/test_fs.cpp Regards, F
Hi all, I'm a user of this library AND developing under Windows. After the library went supposedly stale I did a huge effort in the last 2 weeks to bring it into shape: - Implement CI: Appveyor (MSVC 2017/2019), Github actions (Linux, MSVC, MinGW) - Fix/Update & Test standalone version (requires C++11 though) - Incorporate the whole reviewfixes branch and fix ALL remaining issues from the reviewnotes but Boost.Build integration (no clue of Jamfiles, sorry) - CMake based build with support for submodules (add_subdirectory), installation and proper CMake targets (find_package(nowide) just works) - Merge all my previously opened PRs and work through open issues fixing more or less serious bugs (wrong return values, wrong behaviour on corner conditions, formatting, line-ends, pointer confusion, warnings) It can be found at https://github.com/Flamefire/nowide. It also has proper Github release integration ("Boost" and standalone version) with an extra asset for the (updated) docu: https://github.com/Flamefire/nowide/releases I'm currently tackling the hardest part: The StdIO based filebuf which turned out way harder than I though. I went over every single function and checked it against the standard to avoid excessive flushes and make sure it behaves as mandated. In the process I enhanced the test cases greatly. In tests with MSVC I see big improvements on read/write bandwidth which were complained about. They now match the std::fstream performance *on average*, meaning they are sometimes even faster (for small IO on my PC). However it is not done yet, as MinGW shows failures so I got to double-check that I didn't miss anything. So from my POV the library is/will be ready for inclusion into the next Boost release (not the currently prepared one). Some points though: - I'd need someone familiar with Jamfiles to check/fix them, especially with the Jamfiles based CMake install - Maintenance could be done by CMT, I could "lead" that though for a bit of time. To ease that I added as much as possible to CI, including a clang-format test (helps wasting review time about style discussion) - The library scope should stay narrow, i.e. as-is. Feature requests should be carefully considered, IMO it is pretty much complete. Again: Ease of maintenance is key. - Maintaining/Testing the standalone version should be continued, as should be the CMake-based build. The library scope is narrow already, and being able to use it standalone or as a submodule seems to be valuable. - Require C++11 (not sure if this is acceptable, as the review didn't point that out) - Allows reduced dependencies (cstdint, scoped_ptr, static_assert) - Standalone does already (dummy-headers redirect to std headers which could be removed then) - "Fuzzy" detection of `*::filesystem::path` to be not only compatible to boost::filesystem for also to C++17 On the importance of this library: - It has already been included into linux distros: https://bugzilla.redhat.com/show_bug.cgi?id=1502584 - Boost.Beast (as written) does not support UTF-8 against it advertising it, it could use Boost.Nowide - UTF8 codepages recently introduced IMO don't solve the problem: Unless the standard codepage is UTF8, you'll never get UTF8 arguments to `main` (unless I missed something) Regards, Alex
On Mon, Dec 2, 2019 at 11:26 AM Alexander Grund via Boost
Hi all,
I'm a user of this library AND developing under Windows. After the library went supposedly stale I did a huge effort in the last 2 weeks to bring it into shape:
- Implement CI: Appveyor (MSVC 2017/2019), Github actions (Linux, MSVC, MinGW) - Fix/Update & Test standalone version (requires C++11 though) - Incorporate the whole reviewfixes branch and fix ALL remaining issues from the reviewnotes but Boost.Build integration (no clue of Jamfiles, sorry) - CMake based build with support for submodules (add_subdirectory), installation and proper CMake targets (find_package(nowide) just works) - Merge all my previously opened PRs and work through open issues fixing more or less serious bugs (wrong return values, wrong behaviour on corner conditions, formatting, line-ends, pointer confusion, warnings)
It can be found at https://github.com/Flamefire/nowide.
It also has proper Github release integration ("Boost" and standalone version) with an extra asset for the (updated) docu: https://github.com/Flamefire/nowide/releases
I'm currently tackling the hardest part: The StdIO based filebuf which turned out way harder than I though. I went over every single function and checked it against the standard to avoid excessive flushes and make sure it behaves as mandated. In the process I enhanced the test cases greatly. In tests with MSVC I see big improvements on read/write bandwidth which were complained about. They now match the std::fstream performance *on average*, meaning they are sometimes even faster (for small IO on my PC). However it is not done yet, as MinGW shows failures so I got to double-check that I didn't miss anything.
So from my POV the library is/will be ready for inclusion into the next Boost release (not the currently prepared one). Some points though:
- I'd need someone familiar with Jamfiles to check/fix them, especially with the Jamfiles based CMake install - Maintenance could be done by CMT, I could "lead" that though for a bit of time. To ease that I added as much as possible to CI, including a clang-format test (helps wasting review time about style discussion) - The library scope should stay narrow, i.e. as-is. Feature requests should be carefully considered, IMO it is pretty much complete. Again: Ease of maintenance is key. - Maintaining/Testing the standalone version should be continued, as should be the CMake-based build. The library scope is narrow already, and being able to use it standalone or as a submodule seems to be valuable. - Require C++11 (not sure if this is acceptable, as the review didn't point that out) - Allows reduced dependencies (cstdint, scoped_ptr, static_assert) - Standalone does already (dummy-headers redirect to std headers which could be removed then) - "Fuzzy" detection of `*::filesystem::path` to be not only compatible to boost::filesystem for also to C++17
On the importance of this library: - It has already been included into linux distros: https://bugzilla.redhat.com/show_bug.cgi?id=1502584 - Boost.Beast (as written) does not support UTF-8 against it advertising it, it could use Boost.Nowide - UTF8 codepages recently introduced IMO don't solve the problem: Unless the standard codepage is UTF8, you'll never get UTF8 arguments to `main` (unless I missed something)
Regards, Alex
Hello Alex, I want to be second on that on what you said. If somebody can take the maintainance of the library for the Boost it is you. I really see the effort you put into and I'm really glad. If you volunteer to maintain and continue to improve this small library this would be amazing @Peter Dimov Since from what I understand Alex's version already includes that reviewfixes branch it may be good idea to start from his version. Thank You! Artyom
Artyom Beilis wrote:
The nowide library was reviewed and accepted into Boost almost 3 years ago.
I implemented most of fixes required under Review Fixed branch
https://github.com/artyom-beilis/nowide/tree/reviewfixes
Unfortunately I don't have any capacity to do maintenance for it on all various platforms: MSVC, mingw. cygwin etc mostly because virtually I don't develop on Windows and any time I need to go there I need to figure it out from the beginning (installations, environment, msvc) and I don't even have windows machine in my hands (all done in VM)
I realized that I'm not windows developer any more and it would be impossible for me to complete the mission of maintaining the code mostly due to personal reasons and lack of development resources.
I deeply regret wasting the time and effort of so many boost developers who invested to review. I understand that it is highly desired library but I just can get the job done
I seek for your advice. Do I need to seek for an another maintainer or withdraw the library entirely?
Hi Artyom, I think that it would be a net win for the community if we release the library, so as a first step, you can transfer the repository to me (pdimov), I'll move it to boostorg, and we'll take it from there. The 'reviewfixes' branch isn't merged yet, I gather?
Hi Artyom,
I think that it would be a net win for the community if we release the library, so as a first step, you can transfer the repository to me (pdimov), I'll move it to boostorg, and we'll take it from there.
Thanks a Lot! It would indeed be a win-win for the community. I don't really know how can I transfer the repository. I'll take it to the private.
The 'reviewfixes' branch isn't merged yet, I gather?
No it wasn't
Thanks, Artyom Beilis
I think that it would be a net win for the community if we release the library, so as a first step, you can transfer the repository to me (pdimov), I'll move it to boostorg, and we'll take it from there.
Status update: The Nowide library is now at boostorg/nowide, and has been added as a submodule to the develop branch of the superproject. The master branch is at a stable state with Travis/Appveyor passing, but before the 'reviewfixes' changes. The develop branch is master with reviewfixes merged. https://ci.appveyor.com/project/pdimov/nowide https://travis-ci.org/boostorg/nowide I've added the generated Doxygen documentation in html/ to the repo, because that's what Locale does, and because I didn't have the time to get this integrated with b2. It shows up properly at https://www.boost.org/doc/libs/develop/libs/libraries.htm#System https://www.boost.org/doc/libs/develop/libs/nowide/doc/html/index.html Tests have started appearing at https://www.boost.org/development/tests/develop/developer/nowide.html Artyom has strongly recommended that Alexander Grund take over as a Nowide maintainer. Unless there are objections, I'll give him write access and let him take things from there.
participants (6)
-
Alexander Grund -
Artyom Beilis -
Frédéric -
Michael Caisse -
Peter Dimov -
Vinnie Falco