- Boost-users - lists.boost.org

Re: [Boost-users] Boost in xeus-cling jupyter kernel
by Giorgino R 16 Jun '20

16 Jun '20

> Ηi there, > > I ve been using boost (geometry) with xeus-cling kernel without any > issues, so far. I install boost from conda forge: > > conda install boost -c conda-forge > > I tried to include odeint.hpp without any issues on my cling environment: > > see also > https://stackoverflow.com/questions/61205040/how-do-i-use-boost-with-the-xe… > > BW > G > > > On Fri, 12 Jun 2020, 19:46 A. de Windt via Boost-users, < > boost-users(a)lists.boost.org> wrote: > >> Hi everyone, >> >> As my first post in this mailing list I would like to ask, has anyone >> tried using boost in a xeus-cling jupyter kernel? Or just cling? >> >> My plan is to use odeint in the jupyter notebook for some simulations. >> However I had issues when I tried to run one of the odeint examples. I >> originally posted my issue on stackoverlfow but didn;t get any feedback. So >> I'm going to mostly copy my original question in this email. >> >> >> https://stackoverflow.com/questions/61205040/how-do-i-use-boost-with-the-xe… >> >> I'm running Pop!_OS (ubuntu derivative) and apt installed boost >> (libboost-all-dev) from the default repositories. I know it has been >> installed properly since I can compile and run the simple boost odeint >> example with GCC. >> >> However when I tried to run the same example inside a jupyter notebook >> using the zeus-cling kernel I got an error while including the odeint >> header. I can recreate the error while executing this code: >> >> #pragma cling add_include_path("/usr/include")#include <boost/numeric/odeint.hpp> >> >> The error message I get is: >> >> In file included from input_line_8:1: >> In file included from /usr/include/boost/numeric/odeint.hpp:22: >> In file included from /usr/include/boost/numeric/odeint/config.hpp:44: >> In file included from /usr/include/boost/config.hpp:48: >> In file included from /usr/include/boost/config/stdlib/libstdcpp3.hpp:78: >> /usr/include/unistd.h:756:28: error: expected function body after function declarator >> extern __pid_t fork (void) __THROWNL; >> ^ >> /usr/include/unistd.h:869:11: fatal error: 'bits/getopt_posix.h' file not found >> # include <bits/getopt_posix.h> >> ^~~~~~~~~~~~~~~~~~~~~ >> Interpreter Error: >> >> From what I understand bits/getopt_posix.h is a GCC only header, thus I >> think the problem might be because the boost headers are configuring >> themselves as if they are compiling under GCC instead of cling/clang. >> >> My solution so far has been to submodule the boost super project into my >> repository and add all the include paths necessary to get odeint and it's >> dependencies to compile. This is fine since odeint is a header only library >> anyways. But I'm pretty sure there is a better solution to this problem. >> >> Thanks in advance and hope to hear from someone back soon. >> >> >> Cheers, >> Aaron M. de Windt >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> https://lists.boost.org/mailman/listinfo.cgi/boost-users >> >

1 0

Boost in xeus-cling jupyter kernel
by A. de Windt 13 Jun '20

13 Jun '20

Hi everyone, As my first post in this mailing list I would like to ask, has anyone tried using boost in a xeus-cling jupyter kernel? Or just cling? My plan is to use odeint in the jupyter notebook for some simulations. However I had issues when I tried to run one of the odeint examples. I originally posted my issue on stackoverlfow but didn;t get any feedback. So I'm going to mostly copy my original question in this email. https://stackoverflow.com/questions/61205040/how-do-i-use-boost-with-the-xe… I'm running Pop!_OS (ubuntu derivative) and apt installed boost (libboost-all-dev) from the default repositories. I know it has been installed properly since I can compile and run the simple boost odeint example with GCC. However when I tried to run the same example inside a jupyter notebook using the zeus-cling kernel I got an error while including the odeint header. I can recreate the error while executing this code: #pragma cling add_include_path("/usr/include")#include <boost/numeric/odeint.hpp> The error message I get is: In file included from input_line_8:1: In file included from /usr/include/boost/numeric/odeint.hpp:22: In file included from /usr/include/boost/numeric/odeint/config.hpp:44: In file included from /usr/include/boost/config.hpp:48: In file included from /usr/include/boost/config/stdlib/libstdcpp3.hpp:78: /usr/include/unistd.h:756:28: error: expected function body after function declarator extern __pid_t fork (void) __THROWNL; ^ /usr/include/unistd.h:869:11: fatal error: 'bits/getopt_posix.h' file not found # include <bits/getopt_posix.h> ^~~~~~~~~~~~~~~~~~~~~ Interpreter Error: >From what I understand bits/getopt_posix.h is a GCC only header, thus I think the problem might be because the boost headers are configuring themselves as if they are compiling under GCC instead of cling/clang. My solution so far has been to submodule the boost super project into my repository and add all the include paths necessary to get odeint and it's dependencies to compile. This is fine since odeint is a header only library anyways. But I'm pretty sure there is a better solution to this problem. Thanks in advance and hope to hear from someone back soon. Cheers, Aaron M. de Windt

2 1

Re: [Boost-users] [boost] [review] [text] Text formal review
by Emil Dotchevski 13 Jun '20

13 Jun '20

On Fri, Jun 12, 2020 at 10:36 AM Rainer Deyke via Boost < boost(a)lists.boost.org> wrote: > String layer: overall, a solution looking for a problem. I tend to agree with this but I had assumed there is a reason why it exists. Zach indicated that he doesn't care much about it, so it probably should be deleted, but I don't feel strongly about this because there are plenty of C++ APIs which define their own string type, and I don't see this as a problem. In C++, we have many of everything.

1 0

[review] [text] Text review begins June 11
by Glen Fernandes 12 Jun '20

12 Jun '20

The Boost formal review of Zach Laine's Unicode library, Text, commences on June 11th and concludes June 20th. We welcome the participation of Boost developers and users, and the C++ community. Quote: This library includes three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides Try the library today, and please consider submitting a review, or even contributing to the discussion next week. Glen

4 3

[asio] tcp non blocking sync read query (bug?)
by Keith Robinson 11 Jun '20

11 Jun '20

Hi, I'm sending data from one process to another using a tcp connection. Sender use scatter-gather to send the data using 3 buffers (total just over 2000 bytes). The reader uses 2 separate sync reads to read the data (using the asio free function read()) using a non blocking socket. Sometimes everything is fine, the 2 reads return the amount of data requested, but sometimes I see strange behaviour. I'm trying to work out whether I am doing something wrong, or whether I've stumbled across a bug. When it goes wrong for me, the second read always returns less data than I requested, along with the error code 'would_block'. I then loop, performing further reads (using the same buffer as before), eventually (one read, or multiple reads later) the read function returns the remainder of the data, but still with the error code 'would_block' set. However, when I check the contents of the buffer, it is not what I expected. I think, but haven't been able to confirm, that the start of the buffer is not the start of the data. 1. Is it expected that the read() free function, when the socket is non blocking, can return less data than requested, along with the error code 'would_block'? 2. If it is expected, does the buffer passed in subsequent reads have to be adjusted to read only the remaining about of data? 3. If the buffer does have to be changed to only read what is left, how does this work with scatter-gather reads using multiple buffers? As a little bit of extra info, I confirmed using tcpdump that the correct data is sent/received, although it arrives in 2 chunks (MTU size of 1500). This is on Linux using Boost 1.73.0. Cheers, Keith

3 3

[review] [text] Text formal review
by Glen Fernandes 11 Jun '20

11 Jun '20

Dear Boost community, The formal review of Zach Laine's Unicode library, Text, begins today (June 11th) and ends on June 20th. The library provides three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text The master branch of the repository will be frozen for the duration of the review. Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Any conditions for acceptance - Your name and knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? Even if you are not submitting a formal review, your feedback on the library is welcome. Glen

1 0

Impossible to download a boost source from bintray: 403 Forbidden
by Eisuke Kawashima 08 Jun '20

08 Jun '20

Dear All, I cannot download a boost source from bintray, e.g., https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.bz2 returns 403 Forbidden. OTOH, sourceforge works: https://sourceforge.net/projects/boost/files/boost/1.73.0/boost_1_73_0.tar.…. Best -- Eisuke Kawashima e.kawaschima+boost(a)gmail.com

3 4

[review][LEAF] Review period is over
by Michael Caisse 04 Jun '20

04 Jun '20

I apologize for not sending this out earlier. The review period is officially complete. A few people have contacted me about completing reviews that they in the middle of and I will be waiting until after this coming weekend to publish the review results. Thank you to those that joined the conversation and provided a review. michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[SPAM] Boost.Container monotonic_buffer_resource and overaligned types
by Patrick Northon 03 Jun '20

03 Jun '20

Is there a reason why it won't allocated for anything over memory_resource::max_align? Inspecting the code, it seem to me that it would just work.

1 0

[review][LEAF] Review of LEAF starts today : May 22 - May 31
by Michael Caisse 02 Jun '20

02 Jun '20

The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error Augmentation Framework) library will take place from May 22 through May 31st. LEAF isn't just another error reporting library in the family of expected-like types. It provides a unique take on error handling which plays into usability, flexibility, and performance. Every software developer must deal with handling errors which makes this review relevant to all. Please participate! I will be grateful to receive a review based on whatever level of effort or time you can devote. LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception. Similar to Boost.Exception, this library allows arbitrary error objects to be returned; however, unlike Boost.Exception it does not require dynamic memory. The library can be used with or without exception handling. The LEAF documentation highlights the following features: * Efficient delivery of arbitrary error objects to the correct error handling scope. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. * Support for multi-thread programming. "LEAF is designed with a strong bias towards the common use case where callers of functions which may fail check for success and forward errors up the call chain but do not handle them." LEAF offers a pattern matching facility to specify which errors to handle and how to handle them. Take a look at the 5-minute Introduction. <https://zajo.github.io/leaf/#introduction> You can find the source code to be reviewed here: <https://github.com/zajo/leaf/tree/review> You can find the documentation here: <https://zajo.github.io/leaf/> The documentation includes a tutorial, examples, reference, design rationale, and comparisons to other error handling approaches/libraries. There is a benchmark document also: <https://github.com/zajo/leaf/blob/master/benchmark/benchmark.md> and a whitepaper: <https://github.com/zajo/leaf/blob/master/doc/whitepaper.md> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including LEAF as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

3 2