- Boost - lists.boost.org

Re: [boost] [Release] Boost 1.70.0 Beta 1 Release Candidate 2
by Peter Dimov 09 Mar '19

09 Mar '19

> Tom Kent wrote: > > > * Can't create libraries for bzip2 and zlib (showstopper? anyone else > > seeing this?) > > I haven't seen your initial report of this issue (on the users list?) but > it's probably caused by this change: > > https://github.com/boostorg/build/commit/5ad92cd76ff393792f30aa50688c95eff2… Or maybe not. This is in 1.69.0, so it can't be the cause.

1 0

[release] Boost 1.70.0 Beta 1 Release Candidate 1
by Marshall Clow 09 Mar '19

09 Mar '19

The release candidates for the first 1.70.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.70.0.beta.1.rc1/source/ The release notes are not yet available. The SHA256 checksums are as follows: a7c570d6307d05dc8d45a3b4c69a0afdcba2b22eac0c4da4d496559f53db7b89 ./boost_1_70_0_b1_rc1.7z 4b91b9a203cf12f6001cf39de83c7cc005fbc5390e2b4b2fc29ce7b19c0537a7 ./boost_1_70_0_b1_rc1.tar.bz2 460dd6499bba9df04c6bfa219b26097bad803b8758304ba45f2fc291aa42c96e ./boost_1_70_0_b1_rc1.tar.gz f209c9a086ed2c7882a0bc8755792f436eb141eaeb8c823ed57295ca9ce25b93 ./boost_1_70_0_b1_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

4 9

Interest in GSoC Project
by Kanav Gupta 09 Mar '19

09 Mar '19

Hello, I am third-year undergrad research student at International Institute of Information Technology, Hyderabad. I would like to contribute to Boost.GIL as a part of GSoC '19. I am currently working on a research project involving image processing and have also worked on various projects involving C++ so I guess I am competent for the project. Can you please guide me on how should I proceed? Thanks and Regards, Kanav Gupta

1 0

[release] 1.70.0 closed for major changes
by Marshall Clow 07 Mar '19

07 Mar '19

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. As always, the calendar for the release cycle is available at: https://www.boost.org/development/ Thanks, -- The Boost Release Team

7 9

[Release 1.70] Master branch is now closed for the beta
by Marshall Clow 07 Mar '19

07 Mar '19

Except with explicit permission by a release manager. Do whatever you want on develop, just don't change master. We'll re-open master after the beta. As always, check the calendar at https://www.boost.org/development 6-Mar: Boost 1.70.0 closed for all changes 13-Mar: Boost 1.70.0 beta; master branch re-opened 2-Aug: Release closed for all changes, except by permission of a release manager. 3-Apr: Boost 1.70.0 closed for all changes 10-Apr: Boost 1.70.0 release -- The release managers

2 1

[build] Boost.Build/develop broken with msvc?
by John Maddock 07 Mar '19

07 Mar '19

Currently I see: D:/data/boost/boost/tools/build/src/tools\msvc.jam:1388: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup ? : default-global-setup-options : default-setup ) * called with: ( 14.16.27023 14.11.25503 : D:/compilers/visual studio/2017/VC/Tools/MSVC/14.11.25503/bin/HostX64/x64 : D:\compilers\visual studio\2017\VC\Tools\MSVC\14.11.25503\bin\HostX64 : <command>D:\compilers\visual studio\2017\VC\Tools\MSVC\14.16.27023\bin\Hostx64\arm\cl.exe <command>D:/compilers/visual studio/2017/VC/Tools/MSVC/14.11.25503/bin/HostX64/x64/cl.exe : i386 : : x86 : vcvars32.bat ) * extra argument 14.11.25503 D:/data/boost/boost/tools/build/src/tools\msvc.jam:1003:see definition of rule 'generate-setup-cmd' being called D:/data/boost/boost/tools/build/src/tools\msvc.jam:393: in configure D:/data/boost/boost/tools/build/src/tools\msvc.jam:345: in msvc.init D:/data/boost/boost/tools/build/src/build\toolset.jam:44: in toolset.using D:/data/boost/boost/tools/build/src/build\project.jam:1104: in using C:\cygwin64\home\John Maddock\user-config.jam:46: in modules.load D:/data/boost/boost/tools/build/src\build-system.jam:255: in load-config D:/data/boost/boost/tools/build/src\build-system.jam:453: in load-configuration-files D:/data/boost/boost/tools/build/src\build-system.jam:607: in load D:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import D:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build D:\data\boost\boost\boost-build.jam:17: in module scope Master is fine BTW. Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 3

[interprocess] support for a new synchronisation mechanism
by Dudi Likvornik 06 Mar '19

06 Mar '19

Hi, My name is David, I would like to suggest a new synchronisation mechanism based on linux futex. as far as I saw, its not being supported as of now with in the interprocess communication library. One suggestion is to support a mutex, here is an example, possible partial implementation, based upon the following paper: http://dept-info.labri.fr/~denis/Enseignement/2008-IR/Articles/01-futex.pdf Mutex::Mutex(): m_word(UNLOCK) {} void Mutex::lock() { int lockState = UNLOCK; if(std::atomic_compare_exchange_strong(&m_word, &lockState, static_cast<int>(LOCK_SINGLE)) == false) { if(lockState != LOCK_MANY) lockState = std::atomic_exchange(&m_word, static_cast<int>(LOCK_MANY)); while(lockState != UNLOCK) { #if defined(__linux) syscall(SYS_futex, &m_word, FUTEX_WAIT, LOCK_MANY, nullptr, nullptr, 0); #else throw Exception(__CORE_SOURCE, "wait is not being supported by current platform"); #endif lockState = std::atomic_exchange(&m_word, static_cast<int>(LOCK_MANY)); } } } void Mutex::unlock() { if(std::atomic_fetch_sub(&m_word, 1) == LOCK_SINGLE) return; m_word = UNLOCK; #if defined(__linux) syscall(SYS_futex, &m_word, FUTEX_WAKE, 1, nullptr, nullptr, 0); #else throw Exception(__CORE_SOURCE, "wake is not being supported by current platform"); #endif } bool Mutex::try_lock() { int lockState = UNLOCK; return std::atomic_compare_exchange_strong(&m_word, &lockState, static_cast<int>(LOCK_SINGLE)); } ————————————————————————————————————————————————————————— And a conditional variable: Condition::Condition(): m_command(SLEEP), m_waitersCount(0){} void Condition::signal(Command command) { m_wakeLock.lock(); if(m_waitersCount == 0) { m_wakeLock.unlock(); return; } m_command.store(command, std::memory_order_relaxed); #if defined(__linux) syscall(SYS_futex, &m_command, FUTEX_WAKE, command == NOTIFY_ONE ? 1 : std::numeric_limits<int>::max(), nullptr, nullptr, 0); #else throw Exception(__CORE_SOURCE, "wake is not being supported by current platform"); #endif while(m_command.load(std::memory_order_relaxed) != SLEEP && m_waitersCount.load(std::memory_order_relaxed) != 0){} m_wakeLock.unlock(); } void Condition::wait(std::unique_lock<core::Mutex> &lock) { m_waitersCount++; lock.unlock(); while(true) { while(m_command.load(std::memory_order_relaxed) == SLEEP) #if defined(__linux) syscall(SYS_futex, &m_command, FUTEX_WAIT, SLEEP, nullptr, nullptr, 0); #else throw Exception(__CORE_SOURCE, "wait is not being supported by current platform"); #endif int fromCommand_one = NOTIFY_ONE; if(m_command.compare_exchange_strong(fromCommand_one, static_cast<int>(SLEEP), std::memory_order_relaxed)) { m_waitersCount--; lock.lock(); return; } else if(m_command.load(std::memory_order_relaxed) == NOTIFY_ALL) { if(m_waitersCount.fetch_sub(1, std::memory_order_relaxed) == 1) m_command.store(SLEEP, std::memory_order_relaxed); lock.lock(); return; } } } ConditionVariable::ConditionVariable() {} void ConditionVariable::wait(std::unique_lock<core::Mutex> &lock) { m_condition.wait(lock); } void ConditionVariable::notify_one() { m_condition.signal(Condition::NOTIFY_ONE); } void ConditionVariable::notify_all() { m_condition.signal(Condition::NOTIFY_ALL); } class ConditionVariable { public: ConditionVariable(); ConditionVariable(const ConditionVariable&) = delete; ConditionVariable& operator=(const ConditionVariable&) = delete; void wait(std::unique_lock<Mutex>& lock); template<typename Predict> void wait(std::unique_lock<Mutex>& lock, const Predict& predict) { while(predict() == false) m_condition.wait(lock); } void notify_one(); void notify_all(); private: Condition m_condition; }; Your thoughts of the idea, if any. p.s. Please be soft, its my first post ever :).

1 0

Boost.uBLAS [gsoc19]
by Sarthakag 06 Mar '19

06 Mar '19

Hello, I am Sarthak Agarwal, 3rd-year undergraduate student from Birla Institute of Technology and Science, Pilani - Goa, India currently pursuing a double major MSc. Mathematics and B.E. Computer Science and Engineering. I am an active Competitive Programmer on various online judges for the last 4 years. I am comfortable in C/C++(STL) and Python(Django). I wish to contribute to Boost.uBLAS, specifically to Project 4 on implementing non-negative matrix factorization(NMF). I would also like to know if there are any upcoming ideas to implement in Boost.intrusive. I have completed the Boost Competency test and learned a lot while doing it. How can I share it for valuable feedback? I look forward to your guidance. Sarthak Agarwal -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

1 0

Regarding GSOC'19
by Keshav Gupta 05 Mar '19

05 Mar '19

Hi I am Keshav Gupta from India and wanted to work with Boost during GSOC 2019 on the major topic of Boost GIL. So can you tell me how to proceed with? Regards Keshav Gupta

1 0

[variant2] Need rationale for never-empty guarantee
by Andrzej Krzemienski 04 Mar '19

04 Mar '19

Hi Peter, Thank you for writing and sharing this implementation of variant. I am sorry if I am bringing back an issue that has been already discussed and solved before, but I do not understand the rationale behind doing compromises in order to provide the never-empty guarantee. The short rationale provided in Boost.Variant library: https://www.boost.org/doc/libs/1_69_0/doc/html/variant/design.html#variant.… was provided before we got C++11 the moved-from state in the language. Today, it should come as no surprise to programmers that a type might be in a "moved from" state where only a limited interface of an object can be used. The guarantee provided by variant's assignment is not a strong exception safety guarantee: it is possible that my variant has value A, I want to assign value B, and (due to an exception) I end up with value C. If this happens, the only thing I can reasonably do is to either abandon whatever I was doing or reset the variant to the state that I need. So the guarantee that it is not left empty does not seem to be of much use. But the cost to be paid is noticeable. I think that this question should be addressed in the documentation. Regards, Andrzej

13 51