[nowide] Future

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

[nowide] Future

Boost - Dev mailing list
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

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

Re: [nowide] Future

Boost - Dev mailing list
On Sat, Nov 30, 2019 at 6:21 AM Artyom Beilis via Boost
<[hidden email]> wrote:
> 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__beast__file_stdio/open.html>

Thanks

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

Re: [nowide] Future

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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

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

Re: [nowide] Future

Boost - Dev mailing list
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




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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [nowide] Future

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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?


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

Re: [nowide] Future

Boost - Dev mailing list
> 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

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

Re: [nowide] Future

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Dec 2, 2019 at 11:26 AM Alexander Grund via Boost
<[hidden email]> wrote:

>
> 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

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

Re: [nowide] Future

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi Alexander,

> 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

I can only say waouh!

Thanks for your contribution.

Frédéric

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

Re: [nowide] Future

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> > 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.


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

Re: [nowide] Future

Boost - Dev mailing list
On 12/5/19 10:16, Peter Dimov via Boost wrote:
>
> 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.
>

+1

--
Michael Caisse
Ciere Consulting
ciere.com

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

Re: [nowide] Future

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> The Nowide library is now at boostorg/nowide, and has been added as a
> submodule to the develop branch of the superproject.

thanks a lot

F

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