- Boost - lists.preview.boost.org

[release] 1.69.0 closed for release
by Marshall Clow 12 Dec '18

12 Dec '18

The master branch is now closed for all changes except by permission. The commit-bot isn't running on master, so the super project will need to be manually updated for any changes. If all goes well, the release candidate should be out later today. Thanks, -- The Boost Release Team

4 7

The Master branch is still closed; it will be opened tomorrow
by Marshall Clow 12 Dec '18

12 Dec '18

Thanks for your patience -- The boost release managers

1 0

Fwd: [run-clang-tidy] new replacement overlaps with an existing replacement
by Mateusz Loskot 11 Dec '18

11 Dec '18

(I'm forwarding here my clang-tidy problem I posted to cfe-user mailing list, since it touches Boost library, a highly templated library, and I'm hoping we have experienced clang-tidy users among Boost developers. Considering it a part of Boost library development, I hope it is not off-topic here.) ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Mon, 10 Dec 2018 at 22:14 Subject: [run-clang-tidy] new replacement overlaps with an existing replacement To: <cfe-users(a)lists.llvm.org> Hi, I'm running clang-tidy 7.0 (also tried 5.0) to modernise some aspects of Boost.GIL (https://github.com/boostorg/gil) source code. I've noticed, clang-tidy 7.0 (also 5.0) does not apply fixes for some of modernize-use-* checks, especially modernize-use-using. I run it this way: ``` cd ${BOOST_ROOT}/libs/gil cmake -S . -B _build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .. run-clang-tidy.py -p=_build -header-filter='boost\/gil\/.*' -checks='-*,modernize-use-using' -fix ``` Then, I see huge number of "The new replacement overlaps with an existing replacement." diagnostics. Below, I copied an extract that hopefully is useful to figure out what is happening and going wrong. Basically, there are two class templates and a bunch of tag types: 1. file_stream_device https://github.com/boostorg/gil/blob/e0288ece9ec50534e7d02166863d6799a5932e… 2. get_write_device with partial specialisations, `enable_if`-ed https://github.com/boostorg/gil/blob/e0288ece9ec50534e7d02166863d6799a5932e… The file_stream_device is specialised for a tag and final get_write_device specialisation is matched. And, clang-tidy tries to substitute this alias in get_write_device typedef detail::file_stream_device< FormatTag > type; not with using type = detail::file_stream_device< FormatTag > ; but with `using type` for each FormatTag-based specialisation ``` New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<bmp_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<bmp_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<jpeg_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<pnm_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<targa_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<targa_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<tiff_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<tiff_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. ``` Why clang-tidy tries to re-fix the typedef with new replacement instead of keeping the existing one, the generic one? i.e. using type = detail::file_stream_device<FormatTag> I've tried to prepare a minimal example, but I couldn't reproduce this issue. I observed, that if I manually prepare compile_database.json with single .cpp file that just `#include <boost/gil/io/device.hpp>`, that is the header with definition of the base templates and no definitions with higher level specialisations for format tags are included, then clang-tidy applies the expected fixes without any warnings. Could anyone share any insights about this issue? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

How to install boost core
by Nipun Ramani 11 Dec '18

11 Dec '18

I am very new to boost and I have been wanting to build the library from scratch. I am using CMake with VS2017. I successfully created the project files of boost-core using CMake however I am unable to locate .lib file or .dll file after I run the build in VS2017.

2 1

[Website] Revised $Date$
by Olaf van der Spek 11 Dec '18

11 Dec '18

Hi, I don't think this is what it's supposed to be. > Revised $Date$ https://www.boost.org/development/index.html -- Olaf

1 1

Reminder: 1.69 closes for major changes Wednesday
by Marshall Clow 10 Dec '18

10 Dec '18

Upcoming dates: * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release -- The Boost Release Team

4 3

Will the boost::asio::streambuf keep in sequency order when ostream write to boost::asio::streambuf multiple time?
by hh h 10 Dec '18

10 Dec '18

Hi, Are there any problems in following statements? The receiver works a few minutes, then got wrong number in header field. std::shared_ptr<boost::asio::streambuf> buffer = std::make_shared<boost::asio::streambuf>(); std::ostream os(buffer.get()); os.write((char *) &sendHeader, sizeof(sendHeader)); os.write((char *) sb.data(), sb.size()); boost::asio::async_write(socket_, *buffer.get(), .....); Thank you. - JHH

2 1

Is the async_read more reliable than async_read_some?
by hh h 09 Dec '18

09 Dec '18

Hi, I have been using asio::async_read with protobuf for some time, it is relative easy to use protobuf function SerializeToOstream to attach a packet header and send the packet header along with to protobuf message, with fixed packet header size and message size in the header, I was able to use async_read. But I have to change to use msgpack which I could not find a way like protobuf to attach a packet header to msgpack message. The only way I could do is to use async_read_some, but I am very concerning the remark in the async_read_some document. Appreciate your comments. "The read operation may not read all of the requested number of bytes. Consider using the async_read function if you need to ensure that the requested amount of data is read before the asynchronous operation completes." Thank you. - JH

3 9

Re: [boost] Can we skip the __boost_check_library__.test ?
by Rene Rivera 07 Dec '18

07 Dec '18

Rerouting to appropriate lists.. On Sun, Dec 2, 2018 at 6:00 PM Kuhl, Brian via Boost-build < boost-build(a)lists.boost.org> wrote: > Hi Boost builders, > > We currently running the Boost test suite using ./b2 in the status > directory. > > We run nightly on several simulators and real boards using ARM, PowerPC, > Intel processors compiling Boost 1.68 with clang and GCC > > Our test results are being peppered with the occasional failure of > __boost_check_library__ > > I’m pretty sure we don’t care about the results of this test in the > context cross-compiling VxWorks? > Probably not. > What exactly is it testing for? > It checks various requirements and guidelines of the library structure. > And assuming it isn’t relevant, how do we “turn it off”? > Add the "--no-check-libs" per < https://github.com/boostorg/boost/blob/develop/status/Jamfile.v2#L18> (I believe running b2 --help in that dir would have shown you that info also). > The library Jam files don’t have an explicit reference to this that I can > find? > It's added here < https://github.com/boostorg/boost/blob/develop/status/Jamfile.v2#L119>. And it runs this script < https://github.com/boostorg/boost/blob/master/status/boost_check_library.py >. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

[release] Boost 1.69.0 Release Candidate 1
by Marshall Clow 07 Dec '18

07 Dec '18

The release candidates for the 1.68.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.69.0/source/> The SHA256 checksums are as follows: af05616f71006f97833e130aad886c96136457511ace4b5496d6566e69cbe0ca boost_1_69_0_rc1.7z 8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406 boost_1_69_0_rc1.tar.bz2 9a2c2819310839ea373f42d69e733c339b4e9a19deab6bfec448281554aa4dbb boost_1_69_0_rc1.tar.gz d074bcbcc0501c4917b965fc890e303ee70d8b01ff5712bae4a6c54f2b6b4e52 boost_1_69_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

1 1

Executable files in Boost git repostories
by Edward Diener 06 Dec '18

06 Dec '18

We have again run into the situation where files with a Linux executable permission have been committed to various Boost git repositories, with Jim King creating a PR and list of these files in Boost Admin. I have fixed these for the repositories for which I have write access, and created PRs for the other repositories. But this begs the question as to what Boost's stance should be about adding actual executable files to a Boost git repository ? As an example a Linux bash command file was added to a particular repository and I created a PR to remove the executable file permission from the file. But the maintainer of the repository feels this is wrong and the Linux bash file should retain the executable file permissions and that the file should be part of the repository. But of course I am more interested here about the general principal of the matter. Obviously operating system command/batch files are executable files, but should they be so in a repository. Finally should be not have some sort of git hook that somehow eliminates this recurring problem of files with executable permissions being periodically committed to a Boost git repository ? Most all of the files I "fixed" or created PRs for are clearly source files what can not be "executed" in any way. But this happening again is a real problem to have to clean up each time.

9 22

Reminder: Boost Master branch will close for release tomorrow (12/5)
by Marshall Clow 05 Dec '18

05 Dec '18

Calendar at https://www.boost.org/development -- Marshall

3 3

[histogram] should some_axis::size() return unsigned or int?
by Hans Dembinski 04 Dec '18

04 Dec '18

Dear community (especially the reviewers of boost.histogram), I am still working on finishing the library based on the excellent reviews I got in September. I cannot make up my mind about a specific detail of the library interface and would like to ask for your input. Every axis type is required to have a size() method, which returns the number of bins along that axis (without counting extra bins for under- and overflow). Should this method return `unsigned` or `int`? = The case for `unsigned` = The size of an axis is non-negative, so the return type should reflect this. All the STL containers return their size as an unsigned integer. Naturally, boost.histogram should be as consistent as possible with the STL, so you don't have think about exceptions from the general rule. Whether `size()` returns a signed or unsigned type matters even in times of `auto`, since compilers like to warn about comparisons between signed and unsigned integers. These warnings and the STL have slowly thought people to write indexed loops with unsigned integers, like so: ``` auto h = make_histogram(…); // 1D histogram for (unsigned i = 0; i < axis.size(); ++i) { auto x = h[i]; // do something with bin } ``` We don't want to break this painfully learned habit by letting `size()` return a signed integer, because it would generate a warning in this naive loop. = The case for `int` = The type of the bin index returned by an axis is `int`, because it can be negative. An axis is required to return -1 when the axis represents an ordered range and the value fall below the low edge of the first bin. So the index must be signed. The size of an axis is highest index + 1. It would be natural to use the same type for `size()` and for the returned index. Internally in the library, there are many less-than comparisons between the index and the size of the axis. If the type of the latter is unsigned, the size must be cast to `int` in all these comparisons to avoid compiler warnings, which is adding code clutter in the implementation. The library provides a range adaptor, called `indexed`, which allows one to iterate over the bins of a histogram with a special proxy, that can return the current bin index and the accumulated value for that bin. The following naive code to ignore under/overflow bins while iterating will generate a warning when `size()` returns `unsigned` ``` auto h = make_histogram(…); // 1D histogram // iterate over indexed bin range, ignore indices < 0 and indices > size (= underflow/overflow bins) for (auto x : indexed(h)) { if (x[0] < 0 || x[0] >= h.axis().size()) // without warning only when x[0] and h.axis().size() both return `int` continue; // do something with bin } ``` People are supposed to use the indexed range to iterate over the bins and not a combination of simple loops like in the first listing, because it scales nicely to multi-dimensional histograms. In multiple dimensions, it is also potentially more efficient. The `indexed` range adaptor automatically moves sequentially in memory, which this is not guaranteed if the index is created by looping manually over several indices, like so ``` for (unsigned i = 0; i < h.axis(0).size(); ++i) for (unsigned j = 0; j < h.axis(1).size(); ++j) { auto x = h.at(i, j); // this may jump around in memory, causing cache misses } ``` How the linear index is generated from the multi-dimensional index is an implementation detail (although the implementation should probably anticipate these naive loops…) So, if `indexed` is anyway the default recommended way of iterating over a histogram, then size() should return `int` to be compatible with the index type, which is also `int`, because it makes naive code work better. Sorry for the long email, I would really appreciate your input. Best regards, Hans

6 13

Re: [boost] [graph] Tree data structure
by Bjorn Reese 02 Dec '18

02 Dec '18

On 11/28/18 11:51 AM, Jeremy Murphy via Boost wrote: > long ago, back in 2002 and 2009, Kasper Peeters proposed adding his tree > data structure to Boost. There is also Rene's proposal, which sounds like a useful Boost library: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3700.html

2 1

Re: [boost] [histogram] should some_axis::size() return unsigned or int?
by Hans Dembinski 01 Dec '18

01 Dec '18

Dear Jim, > On 29. Nov 2018, at 13:31, Jim Pivarski <jpivarski(a)gmail.com> wrote: > > It seems to me that if other C++ containers use unsigned integers for size(), you should too, for minimal surprise. The issue you raise about the "which bin?" function returning -1 would be solved in a very-strongly typed language like Haskell as an optional<int>. I know that C++ has optional types now, but I don't know how widely they're used or if there's a significant performance penalty. If this wouldn't look too weird in a C++ program and wouldn't slow it down (or needlessly complicate the code), an optional type would describe your intent more fully than -1. there is boost::optional, which has the semantics of a pointer and can be used to represent a type that stores a value or not. ``` boost::optional o = some_fickle_function(); if (o) { // optional has a value? auto value = *o; // "dereference" to get the value } else { // handle case where value is missing } ``` This is not a good match here, because -1 here does not have the meaning of "value is missing", but it really is the logical index for the virtual bin that spans from -infinity to the lower edge of the first bin in the axis. Value arrow: -inf ——————— | ——————— | —————— | —————— |—————————> +inf bin -1 bin 0 bin 1 bin 2 bin 3 I think representing the underflow bin with -1 and the overflow bin with the value returned by size() is very intuitive and elegant. Best regards, Hans

5 10

C++ project suggestion for Google summer of code (summer, 2019 )
by Ahmed Hussein 30 Nov '18

30 Nov '18

Dear boost , My name is Ahmed Mohamed Ahmed. I ‘m an Egyptian second year electrical engineering student (this is my third year but in Egypt we count 0,1,2,3,4). This my first time ever getting involved in open source. Nevertheless, I am eager to contribute to the vast open source community . I would love to create a C++ library under your supervision and guiding in the next Google summer of code (summer,2019). The attached document is an overview of the library, it is not a proposal with a time line but it answers questions regarding: How is this library going to benefit the open source community? What facilities will be provided by that library? What kind of libraries can be built by fellow programmers using this library? How can this library be extended in the future, whether by me or others? Thank you for your time . Sincerely Advanced mathematics for engineering applications <https://docs.google.com/document/d/1hxKHm0vv5nvia-d_OcGd3SG07gCf2ZtMQvDn_LF…>

1 0

Current Guidance on Compiler Warnings?
by Brian Kuhl 29 Nov '18

29 Nov '18

I'd like to confirm the guidance on Warnings I find here https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines is still considered current? context ... At Wind River we are in the process of working with Boost 1.68 and VxWorks 7 (with Dinkum 7.00 with and Clang 6.0 for ARM and IA boards and GCC 8.1 for PowerPC ) with the hope of bundling Boost with our product. Many of our customers make certified systems ( Planes, Trains, Medical Equipment, Factory Automation, etc. ) and the trend in theses industries is to be pedantic about eliminating all compiler warnings. While we have not traditionally required zero warnings in open source code shipped with our product, there is pressure on us to move in that direction, and as result we will probably be contributing pull requests specifically to fix or suppress compiler warnings over the coming years. I'd like to establish clear guidelines for my team as to what is an appropriate "coding standard" for Boost in regards to compiler warnings. While it is simple to say, everything displayed by -Wall, in practice there are many edge cases, e.g. is an unused parameter acceptable in test code? So I'd like to get the maintainers guidance. Many thanks Brian Kuhl

23 103

[graph] Tree data structure
by Jeremy Murphy 28 Nov '18

28 Nov '18

Dear Boost community, long ago, back in 2002 and 2009, Kasper Peeters proposed adding his tree data structure to Boost. http://tree.phi-sci.com/ There was a lot of discussion but nothing eventuated (so far as I am aware). There are links to the historical discussions on his website. ...2018.... Recently, a Boost.Graph user suggested adding a tree class to it, and I was like, "No, no, a tree is just a graph that satisfies certain constraints: a tree class won't yield better performance." But I also happen to be re-reading for nth time, Element of Programming, which touches ever so briefly but intensely on binary trees, and I realized "Oh, hold on, there is a world of conceptual difference between an arbitrary tree, and a k-ary tree." That discussion is here: https://github.com/boostorg/graph/issues/123 It seems very awkward to even try to represent a k-ary tree in existing Boost.Graph data structures, let alone a mutable k-ary tree. So I made a proof-of-concept, a mutable k-ary tree data structure with specialized implementations of depth-first search and isomorphism. Unless I've made a terrible mistake (which is possible), the performance gains are huge, and the ease of use in an existing library is also huge. OK, so huge things aside, this is really early days, exploratory work. And I'm no Boost.Graph expert. I'm interested in what people think, particularly whether they think it is an idea worth pursuing. I do. But I basically need help from people smarter and more experienced. I have made a PR for the sake of discussion, not for actually merging: https://github.com/boostorg/graph/pull/139 Cheers. Jeremy

1 0

[threads] Launch deferred for async
by Stephan Menzel 28 Nov '18

28 Nov '18

Hello all, I am using boost::async() to create futures from tasks in order to wrap some behavior that may or may not be sync. This behavior is implemented behind an interface and can be small and fast operations or longer running and blocking things. All return a future as a result type, so I can hide the ugly truth. For the smaller stuff I'd like to use launch::deferred to avoid threading altogether and just execute the task when the user get()s the future. boost::future<bool> ret = boost::async(boost::launch::deferred, [this] () -> bool { // do some small cpu only impl return result; }); But when i get the result: const bool result = ret.get(); ...the application crashes. Debugging this I came to this in boost/thread/future.hpp:9373 } else if (underlying_cast<int>(policy) & int(launch::deferred)) { std::terminate(); //BOOST_THREAD_FUTURE<R> ret; //return ::boost::move(ret); // return boost::detail::make_future_deferred_shared_state<Rp>( // BF( // thread_detail::decay_copy(boost::forward<F>(f)) // ) // ); } else { To me this sounds like the application will always std::terminate() when launch::deferred is chosen. Why is that? When I use launch::any it seems to work but why is there a parameter that always yields unwanted results. What is the reason behind it? Can I get launch::deferred as it is described (not threading, just executing the task sync when get() is called) somehow? Platform is x64 Windows 10, MSVC14.1. Cheers, Stephan

2 4

[release] 1.69.0 post-beta merges
by Marshall Clow 26 Nov '18

26 Nov '18

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See < https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy> The master branch will close for the 1.69.0 release on 5-December. The release calendar is at https://www.boost.org/development/index.html -- The Boost release team.

8 17

[release] 1.69.0 post-beta merges
by Oliver Kowalke 26 Nov '18

26 Nov '18

Hi, boost.context needs a post-beta merge in order to fix some issue on ELF asm. Do I get permission to merge to master? best, Oliver

2 1

Guidence on #pragma once
by Robert Ramey 25 Nov '18

25 Nov '18

In the safe numerics library my *.hpp files start with the following boiler plate: #ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif ... I would like to replace all this in every file with just #pragma once according to https://en.wikipedia.org/wiki/Pragma_once#cite_note-9 this should be possible while supporting almost all which claim to be C++ 14 conformant. The exception noted is C++ for Cray. I realize that strictly speaking I shouldn't do this. But it would instantaneously remove some cruft from my code as long as the occasional error from repeating the same include guard text in multiple files. It might have some performance benefits and some other repercussions related to pre-compiled headers. Who knows what else. It would be interesting to know what others might have to say about this. Robert Ramey

10 10

[Boost][DoubleEnded] Status?
by degski 25 Nov '18

25 Nov '18

We had the review of this library proposal/addition quite a while back and ever since I've been [eagerly] waiting for its official entry into Boost. https://github.com/erenon/double_ended does not show any activity and there is nothing in the Boost.Container going on either. What is the status? degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

4 6

Geometry path length breaking windows regression runs
by Tom Kent 23 Nov '18

23 Nov '18

There has been a change to the geometry library, sometime around Nov 14, that is causing the windows regression runners I manage to crash. The issue is that it is creating *very* long filesystem paths, even with the regression --abbreviate-paths option set. There are a bunch of files such as: D:\teeks99-08\run\results\boost\bin.v2\libs\geometry\test\self_contained_headers\self-contained-algorithms-detail-buffer-buffered_piece_collection~hpp.test\msvc-14.1\dbg\adrs-mdl-64\async-excpt-on\thrd-mlt\self-contained-algorithms-detail-buffer-buffered_piece_collection~hpp.obj.rsp That seem to be created alright, but when I try to cleanup the run afterwards, windows doesn't allow me to delete the files. Tom

5 4

Help - my disk is full! (of bin.v2 stuff)
by Paul A. Bristow 21 Nov '18

21 Nov '18

I note with surprise (and alarm) that my Boost-stuff disk partition is nearly full! Closer inspection reveals that I have a bin.v2 folder of over 50 GB. Obviously, I need to delete something. What are the implications of deleting things? What is the best option? Should I simply delete the whole folder bin.v2 (I have, in desperation, gone nuclear some time ago) or just bin/v2/libs or ? Expert advice welcome. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 4