- Boost - lists.preview.boost.org

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> Apart from that, https://travis-ci.org/boostorg/bcp/builds/537447552 After fixing the two problems in Jamroot, testing the library after --namespace still doesn't work, because libs/program_options/test/Jamfile.v2 refers to the library as boost_program_options, but it's no longer called that.

1 0

[iostreams] Interest in multithreaded lzma filter?
by Mike 26 May '19

26 May '19

Accidentally only sent this to James and not the ML: > Gesendet: Donnerstag, 23. Mai 2019 um 15:19 Uhr > Von: "James E. King III" <jking(a)apache.org> > > > On Thu, May 23, 2019 at 8:39 AM Mike via Boost <boost(a)lists.boost.org> wrote: > > > > > Gesendet: Mittwoch, 22. Mai 2019 um 23:40 Uhr > > > Von: "Jeff Bonyun via Boost" <boost(a)lists.boost.org> > > > > > > > ... How will we detect whether > > > > liblzma is capable? If it is not capable but specified, will we allow > > > > the compression anyway? > > > > > > I've been investigating this. liblzma defines a version macro, > > > LZMA_VERSION. It looks like liblzma obtained its multithreaded function > > > in 5.1.1 (in 2011). So the idea would be to branch on this macro, and > > > fall back to the currently-used single-threaded function for an older > > > liblzma version. In that case, requesting any number of threads will > > > carry out the operation, but will only use a single thread. This makes > > > it tolerant of different versions, but does mark up the code with a few > > > #if branches. I'm assuming boost goes for tolerance in this case. > > > > Does a 2019 Boost release really have to be compatible with a Pre 2011 > > release of liblzma? Is this combination even tested? > > I.e. are we sure this would be the only incompatibility? > > > > How about just adding this functionality unconditionally and see if > > someone complains? > > > > So basically if someone has an older lzma they are limited to boost > 1.70.0 or earlier. That's perhaps reasonable as long as it is > documented, but it hasn't been the typical way I have seen things > added to existing code. Well, my second question was if you are confident that 1.70 does actually work with liblzma versions older than 5.1.1? If this isn't tested, it is not supported and if it is not supported it imho makes little sense to complicate the source code to achieve potential compatibility with (what I assume to be) a very, very small number of setups. > > Another way to handle it is to keep the old path in a macro like > BOOST_IOSTREAMS_NO_MULTITHREADED_LZMA. This is common through boost. > Ideally, detecting the liblzma version from the header could then set > BOOST_IOSTREAMS_NO_MULTITHREADED_LZMA and it would always do the right > thing, but the simplest way to do it is to let the consumer of the > library set this if they need it. > Personally I'm not a fan of configuration macros when they are not absolutely necessary because it effectively means you introduce yet another variant of boost that may or may not be tested and may or may not be compatible with the variant another dependency in my project was tested with (The total configuration space of boost is already far too large for my taste). As Robert Schumacher said in his cppcon talk: It's not just about you and the user, but also every library between you and the user. All of them now either have to support both choices or have to make one choice and hope they don't become incompatible with a different 3rd party library. Yet another reason, why package & dependency management is so hard in c++. However, as long as the interface is untouched by this macro I guess it would be fine. Best Mike

3 3

Non-ASCII Path Names in Repo
by Tom Kent 25 May '19

25 May '19

In the last few days we've had a non-ASCII path name added to the repo: tools/boostdep/test/utf8-test-ßµ™∃ Which came with commit 8893d1c57951a [1] I noticed this because a python 2 script (calling shutil.copytree) I had running on windows that copied the repo around started to fail. I've long needed to update that script to python 3, and am working on this. However, I wanted to point this out to the list so we could discuss if there are any other ramifications of having a non-ascii path. I vaguely remember some discussion about something like this in the past, but couldn't find it via search. If this is already a settled topic, that's great. Tom [1] https://github.com/boostorg/boostdep/commit/8893d1c57951a4a83705ed203005576…

2 1

bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Mathias Gaunard 25 May '19

25 May '19

Hi, I'd like to point out that bcp namespace aliasing has been broken for quite a while, which impacts package providers of Boost which choose to package it with a versioned namespace. We should try to fix to enable more people to upgrade. The bug has been reported March 2018 on trac https://svn.boost.org/trac10/ticket/13460 Then again by me this week on github https://github.com/boostorg/bcp/issues/4 Things have been made worse since 1.69 because libraries now build with visibility hidden by default, which means that with this bug symbols don't get exported and nothing links. Also I would argue that this set-up should be tested as part of the release validation process. The boost build system is arcane enough that we don't need a pretty standard build configuration to be subtly broken for more than a year. Could we try to address this before 1.71?

3 3

[iostreams] Interest in multithreaded lzma filter?
by Jeff Bonyun 23 May '19

23 May '19

I've implemented a multithreaded update to iostreams' lzma filter for my own purposes, and I was wondering if this change would be considered for including in Boost.iostreams? It uses liblzma's own multithreaded functions, so the changes to boost are actually pretty minimal. It does add a new member to the boost-provided lzma options struct -- to specify your desired number of threads -- which changes how people might use the constructor for the filter. My two biggest concerns with including it in Boost.iostreams are: - Making the filter constructor backwards compatible. Right now, users can initialize the options struct with a single unbraced int when calling the filter constructor. With the change to the struct, I want to make sure this old way still works. I.e. not requiring a braced initializer list if you only want to provide the compression level. - Handling older versions of liblzma that didn't offer multithreading. I'll work on identifying the exact versions needed, and branching on their #defined version numbers. If there is appetite for it, I can make a pull request on github. As this would be my first submission to boost, I'm sure I'll screw something up and need correcting, so be patient. Jeff

3 5

Using 'vcunk' toolset.
by Olaf van der Spek 22 May '19

22 May '19

Hi, Any chance to support 16.2 (preview 1)? ********************************************************************** ** Visual Studio 2019 Developer Command Prompt v16.2.0-pre.1.0 ** Copyright (c) 2019 Microsoft Corporation ********************************************************************** C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview>cd \vc C:\VC>cd boost_1_70_0 C:\VC\boost_1_70_0>./boost '.' is not recognized as an internal or external command, operable program or batch file. C:\VC\boost_1_70_0>./bootstrap.bat '.' is not recognized as an internal or external command, operable program or batch file. C:\VC\boost_1_70_0>bootstrap.bat Building Boost.Build engine Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics. bootstrap.log: Found with vswhere Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959] Found with vswhere Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959] ### ### Using 'vcunk' toolset. ### C:\VC\boost_1_70_0\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap C:\VC\boost_1_70_0\tools\build\src\engine>md bootstrap C:\VC\boost_1_70_0\tools\build\src\engine>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0 command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c Generating Code... Compiling... option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c Generating Code... Compiling... native.c set.c path.c regex.c property-set.c sequence.c order.c Generating Code... C:\VC\boost_1_70_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=vcunk "--toolset-root=Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959]\Common7\Tools\..\..\VC\ " clean ### ### Unknown toolset: vcunk ### ### Known toolsets are: acc, borland, cc, como, clang, darwin, gcc, gcc-nocygwin, intel-darwin, intel-linux, intel-win32, kcc, kylix, metrowerks, mipspro, msvc, qcc, pathscale, pgi, sun, sunpro, tru64cxx, vacpp, xlcpp, vc7, vc8, vc9, vc10, vc11, vc12, vc14, vc141, vc142, vmsdecc ### C:\VC\boost_1_70_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=vcunk "--toolset-root=Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959]\Common7\Tools\..\..\VC\ " ### ### Unknown toolset: vcunk ### ### Known toolsets are: acc, borland, cc, como, clang, darwin, gcc, gcc-nocygwin, intel-darwin, intel-linux, intel-win32, kcc, kylix, metrowerks, mipspro, msvc, qcc, pathscale, pgi, sun, sunpro, tru64cxx, vacpp, xlcpp, vc7, vc8, vc9, vc10, vc11, vc12, vc14, vc141, vc142, vmsdecc ### C:\VC\boost_1_70_0\tools\build\src\engine>exit /b 1 -- Olaf

1 0

[config] Disabling symbol visibility?
by John Maddock 19 May '19

19 May '19

We have an open ticket from someone that wants all symbols hidden, including those marked with BOOST_SYMBOL_VISIBLE, is this sensible to support? What are the likely consequences of doing so? See https://github.com/boostorg/config/issues/243 Thanks in advance, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

[gsoc19] Introduction
by Thomas Ferrand 18 May '19

18 May '19

Hello everyone, I am Thomas Ferrand a french student in computer science and I am happy to take part in GSoC this summer. I will be working on Boost.SafeFloat (https://github.com/sdavtaker/safefloat) a library that aims at helping developers detecting errors in floating point numbers computations. Best regards, Thomas Ferrand

3 2

[GSoC19] Greetings
by Kim 18 May '19

18 May '19

Hello, Another student and I will be contributing to the proposed Boost library, Real, with mentors Damian Vicino and Laouen Belloli. My name is Kimberly Swanson. I am a mathematics undergrad at University of Central Florida. My primary focus during the summer will be to improve the memory complexity of Real's internal representation. After the main changes, I plan to implement benchmarks with Google Benchmark (though I am open to using other libraries, if recommended). Future changes made regarding memory/computational complexity would refer to results from the benchmark. I aim to get it to a review-ready state before the end of GSoC (fingers crossed). Warm Regards, Kim

2 1

[variant2] Acceptance conditions met - Targeted for 1.71.0
by Michael Caisse 17 May '19

17 May '19

Peter Dimov has updated the Variant2 library based on review acceptance criteria. I have reviewed the changes and "OK" Variant2 to be included as a Boost library. My understanding is that Peter is targeting Variant2 to be available in the 1.71.0 release. Congratulations Peter! Thank you for your quick work in updating the library based on the review feedback. -- Michael Caisse Ciere Consulting ciere.com

2 1