- Boost - lists.boost.org

Potentially include xproc library in boost?
by Samuel Venable 08 Aug '22

08 Aug '22

Hi, I've tried sending an email about this already and no one responded from what I can tell. I guess because I was saying way too much. I was wondering if this code of mine could potentially be added to boost. xproc/process.cpp at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp> It lets you get process information from foreign processes on a lot of platforms. Thanks. Samuel [https://opengraph.githubassets.com/b27d922324c973dacc517314510a40f1739ffa17…]<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp> xproc/process.cpp at main · time-killer-games/xproc<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp> Contribute to time-killer-games/xproc development by creating an account on GitHub. github.com

3 3

Upcoming Boost.URL review
by Klemens Morgenstern 06 Aug '22

06 Aug '22

This is a reminder that the boost.url review will start in a week on the 13th. The source code can be found here https://github.com/CPPAlliance/url and the documentation here https://master.url.cpp.al/ . I am looking forward to plenty of reviews.

4 3

Boost 1.80.0 closed for all changes
by Glen Fernandes 04 Aug '22

04 Aug '22

The master branch is closed for all changes. Release expected on 2022-08-10. - Release Managers

1 0

Boost 1.80.0 master open for bug fixes
by Glen Fernandes 03 Aug '22

03 Aug '22

Now open for bug fixes and documentation changes. Other changes by release manager permission. The next deadline: On August 3rd, master closes for all changes. Glen

6 10

Binary Serialization
by Benedict Bede McNamara 02 Aug '22

02 Aug '22

It appears that the main fact determining collection build speed is the heap you use. I++ now uses its own binary heap to perform allocations for the collection forward_list (which is what oarchive uses). So binary serialization goes even faster now. Here are some figures for collections with a million elements: stl list build time is: 0:0:0:0:27 stl list sort time is: 0:0:0:0:21 stl forward_list build time is: 0:0:0:0:20 stl forward_list sort time is: 0:0:0:0:20 stl set build time is: 0:0:0:0:111 I++ set build time is: 0:0:0:0:61 stl unordered_set build time is: 0:0:0:0:149 stl map build time is: 0:0:0:0:118 I++ dictionary build time is: 0:0:0:0:60 Linked list build time is: 0:0:0:0:23 Linked list sort time is: 0:0:0:0:23 Forward list build time is: 0:0:0:0:16 Forward list sort time is: 0:0:0:0:17 I++ serialization/deserialization time is: 0:0:0:0:150 list build time is: 0:0:0:0:74 stl vector build time is: 0:0:0:0:5 Vector sort time is: 0:0:0:0:12 Quick Sort time is: 0:0:0:0:10 heap allocations: 12000007 heap allocations: 0 >From this we see that in general binary serialization/deserialization takes a bit longer than collection allocation. For example the serialization/deserialization time is 150 milliseconds for a million elements whereas forward_list only takes 16 milliseconds to build. I would be interested to see what the equivalent figures are for Boosts text based serialization. Yours Sincerely, Benedict Bede McNamara P.S. The program that produced these figures is attached. Sent from Mail for Windows

1 0

Why was the boostorg/sort master branch deleted
by Glen Fernandes 02 Aug '22

02 Aug '22

Why was the boostorg/sort master branch deleted? The repository has only a develop branch now. I'm going to recreate the master branch and reset its head to before the recent commits, but - I'd like to know why the branch was removed. Glen

3 2

Re: [boost] Boost Digest, Vol 6764, Issue 1
by Benedict Bede McNamara 29 Jul '22

29 Jul '22

I++ Binary Serialization I++ binary serialization just got twice as fast by using linked lists rather than binary trees as before. Sent from Mail for Windows From: boost-request(a)lists.boost.org Sent: Friday, 29 July 2022 10:00 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6764, Issue 1 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: Questions about incorporating my library into a new library within Boost (Phil Endecott) 2. Re: Questions about incorporating my library into a new library within Boost (Jooseong Lee) ---------------------------------------------------------------------- Message: 1 Date: Thu, 28 Jul 2022 13:57:50 +0100 From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> To: <boost(a)lists.boost.org> Subject: Re: [boost] Questions about incorporating my library into a new library within Boost Message-ID: <1659013070554(a)dmwebmail.dmwebmail.chezphil.org> Content-Type: text/plain; format="flowed"; charset="UTF-8" Jooseong Lee wrote: >> What is not stored contiguously is child, this is stored in >> std::vector<std::unique_ptr>. >> But when N keys are erased, the number of children erased is not O(N), >> because a node can have #(fanout) keys. > > I have to correct this sentence, the number of children erased is O(N). > But the coefficient is small, because practically B-Trees use large fanouts. > > Most technically, a call for erase_range(a, b) would be O(log N) + O(K) > where N is the number of whole keys and K is the number of keys being > erased. > I've updated the repo description, thanks for the catch. Good, I'm glad I don't have to give the CS101 complexity lecture :-) One other comment - how do you deal with strings? To get the locality benefits of the B-Tree you can't store variable-size data totally out-of-band. Regarding the general "how do I get this in Boost?" question, I encourage you to look back through the mailing list archive at the last few "Is Boost interested in my XYZ libary?" threads. Some people post useful replies about what to do next which. Cynically, what happens most often is that there are one or two emails and then the library author and any replies disappear. Some persistence is required to make anything happen. One hint: put something more descriptive (i.e. "B-Tree") in your subject line! Regards, Phil. ------------------------------ Message: 2 Date: Thu, 28 Jul 2022 22:18:33 +0900 From: Jooseong Lee <frozenca91(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] Questions about incorporating my library into a new library within Boost Message-ID: <CAPPJyCuKa8mRMzhKhwaVWXbyuECQDVjXCs_m8kcM_EtDz8dZvg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" > One other comment - how do you deal with strings? To get the locality > benefits of the B-Tree you can't store variable-size data totally out-of-band. For std::string and its friends (i.e. not trivially copyable types) it is stored as something like std::vector<std::string>, so it is not *that* good (but still better than std::set<std::string>). Google Abseil's B-Tree implementation use similar approach. When I personally use my B-Tree for strings, I use raw char arrays like std::array<char, 16> > Regarding the general "how do I get this in Boost?" question, I > encourage you to look back through the mailing list archive at the > last few "Is Boost interested in my XYZ libary?" threads. Thanks, I'll have a look. Best, Jooseong On Thu, Jul 28, 2022, 9:58 PM Phil Endecott via Boost <boost(a)lists.boost.org> wrote: > Jooseong Lee wrote: > >> What is not stored contiguously is child, this is stored in > >> std::vector<std::unique_ptr>. > >> But when N keys are erased, the number of children erased is not O(N), > >> because a node can have #(fanout) keys. > > > > I have to correct this sentence, the number of children erased is O(N). > > But the coefficient is small, because practically B-Trees use large > fanouts. > > > > Most technically, a call for erase_range(a, b) would be O(log N) + O(K) > > where N is the number of whole keys and K is the number of keys being > > erased. > > I've updated the repo description, thanks for the catch. > > Good, I'm glad I don't have to give the CS101 complexity lecture :-) > > One other comment - how do you deal with strings? To get the locality > benefits of the B-Tree you can't store variable-size data totally > out-of-band. > > Regarding the general "how do I get this in Boost?" question, I > encourage you to look back through the mailing list archive at the > last few "Is Boost interested in my XYZ libary?" threads. Some people > post useful replies about what to do next which. Cynically, what > happens most often is that there are one or two emails and then > the library author and any replies disappear. Some persistence is > required to make anything happen. One hint: put something more > descriptive (i.e. "B-Tree") in your subject line! > > > Regards, Phil. > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6764, Issue 1 **************************************

1 0

Is there any interest in a library that solves genetic simulations?
by Arnaud Becheler 27 Jul '22

27 Jul '22

Hi, I am Arnaud, software engineer in genetics, always eager to learn more about C++! Happy to be on this mailing list :) Is there any interest in a library that solves genetic simulations? A proof of concept library that focuses on a particular simulation framework (spatial coalescence) can be found here: https://github.com/Quetzal-framework/quetzal-CoaTL It lacks many basics including genetic code, mutations, sequences, recombination etc. Such algorithms and data structures are constantly re-implemented in the scientific community, and providing a generic implementation could help significantly. Best, Arnaud Becheler

1 0

C++11 or C++14?
by Vinnie Falco 25 Jul '22

25 Jul '22

I'm considering bumping up the C++ language requirement for Boost.URL from C++11 to C++14. I have concerns about doing this, because it affects all my downstream libraries (HTTP.Proto, HTTP.IO, Websocket.Proto, Websocket.IO, and any examples or complete clients/servers that I write). My main fear is that there are still a considerable number of individuals or corporations who, for whatever reason, cannot build with -std=c++14 or later despite having access to newer compilers. I don't mind if there is a small percentage of loss but I do mind if 20% or more of potential users will be locked out. The questions are: 1. Would you or your company be prevented from using Boost.URL if it required C++14? 2. Do you know any other organizations who cannot use C++14 or later? 3. Do you know of any regional or global metrics on who _cannot_ use libraries which require C++14? See also, this reddit thread on r/cpp: <https://www.reddit.com/r/cpp/comments/w6zuo5/c11_or_require_c14/> -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

2 1

xproc: get process information from foreign processes
by Samuel Venable 20 Jul '22

20 Jul '22

Hi all. The main developer of the boost process library liked what he saw when I showed him my xproc API. He recommended me to send it to the boost mailing list and see what the other developers at boost think of it and whether it could be modified and adjusted into making it worthy of becoming an official part of the boost libraries. The Windows build currently only works with MSYS2/MinGW, see the open issue here for the full details on what works and what doesn't on the Windows platform and why: currently known Windows-related bugs · Issue #1 · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/issues/1> The build.sh to build and example.sh to test is all you need to test all features, the only thing that isn't verified by the scripts is whether any memory leaks exist, and afaik in my testing Windows might be the only platform whith memory leaks, but its very unclear to me how to debug the source of them, because the code looks very correct, as I'm freeing memory everywhere online Microsoft documentation tells me to. Also supports Mac, Linux, FreeBSD, DragonFly BSD, NetBSD, and OpenBSD. If I ever find hardware that will work with an Illumos-based Operating System, then that will be added to the mix, (I refuse to use a VM, my personal hang-up). If the libprocps library the linux version depends on were ported to Android, that is another potential platform, but the "Enable Windowing Macro" will need to not be defined as that is more of a desktop-related thing. iOS can work with windowing disabled as well, but some sysctl() with KERN_PROCARGS2 may only work when running in developer/debug mode due to Apple's publishing restrictions. Linux and android are the only platforms with the third party library dependency. All other platforms only rely on dependencies already provided by the OS base and/or kernel. Here's everything you need for the API to work on most platforms, source & header... * xproc/process.cpp at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp> * xproc/process.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.h> And only on Windows you will need these helper blobs generated by the build script... * xproc/process32.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process32.h> * xproc/process64.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process64.h> Here's an example of how to use the library and repository source tree... * xproc/main.cpp at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/main.cpp> * time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc> * You guys have my permission to relicense this code under any version of the Boost license we can agree on if this work gets accepted at any point in time. All functions get process information in their current state at the time the functions are called expect on macOS KERN_PROCARGS2 gets the cmdline and environ of the process in its initial state when the process first launched, so if the cmdline or environ get modified after initialization or process lanch, you will have no way to get the updated values (OS-level limitation of macOS). Lastly, I have helper functions to optionally suspend and resume foreign processes to avoid race conditions where applicable. Let me know what you think and if you have any critiques or questions regarding my code do not hesitate to address that with me in a reply to this email! Thanks! Samuel

1 0