- Boost-users - lists.preview.boost.org

Program-options and priority
by DV Henkel-Wallace 31 Aug '20

31 Aug '20

Hi. I'm finding program_options pretty handy but I have a usage question which is not clear from the documentation. Is a hierarchy of sources not possible if I use value<T>(&my_arg)? My use case is the following: I have a hierarchy of sources: command line, environment variables, user-specified config file or default config file, and lastly a system default. I just set my_arg to whatever default is appropriate and then let parse_command_line do all the work. This is convenient because I can have a module simply define an options_description for callers to use. This works fine unless the option is specified twice (say command line and then environment). The last of the two values is used rather than the first one. Is this hierarchy only possible if I use value<T>() and not value<T>(&my_var)? That will add some complexity for callers. Thanks, d

1 0

Re: [Boost-users] Beast for IMAP
by Kenneth Porter 29 Aug '20

29 Aug '20

--On Saturday, August 29, 2020 11:27 AM +0300 Zhivko Vasilev via Boost-users <boost-users(a)lists.boost.org> wrote: > And IMAP complexity by itself is a "Beast" compared with SMTP. > > Not from boost libraries, but have you look at these libraries if you need > IMAP support. > https://github.com/dinhviethoa/libetpan > https://github.com/MailCore/mailcore2 > > As far as I know, most of the "modern" email apps which haven't used > proprietary code are based on these libraries. Thanks. I'd seen those and also this one: https://www.vmime.org/ I'm coming from using Mulberry and Thunderbird, which have their own IMAP implementation, but neither of those look easy to extract as standalone libraries. In addition to the complexity of IMAP, there's the need for authentication and encryption support, so there's a stack of additional libraries like GnuTLS, cyrus-sasl, and openssl needed. Some of these are hard to build on Windows. Fortunately the new Windows Linux Subsystem allows one to run Linux-based GUI programs in a VM and display on the Windows desktop. So I may go that route.

1 0

Beast for IMAP
by Kenneth Porter 29 Aug '20

29 Aug '20

I've been thinking about writing some email utilities and have looked at various IMAP libraries. I'm wondering if I should roll my own using Beast. I've seen an SMTP library using Beast on GitHub. Has anyone else attempted an IMAP client with Beast?

5 6

Re: [Boost-users] Beast for IMAP
by Richard Hodges 29 Aug '20

29 Aug '20

I maintain boost.beast. If you need any guidance or help you can find me on the cpplang slack most days in the #beast channel. https://cppalliance.org/slack/ On Sat, 29 Aug 2020 at 01:48, Kenneth Porter via Boost-users < boost-users(a)lists.boost.org> wrote: > I've been thinking about writing some email utilities and have looked at > various IMAP libraries. I'm wondering if I should roll my own using Beast. > I've seen an SMTP library using Beast on GitHub. Has anyone else attempted > an IMAP client with Beast? > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users > -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

1 0

Re: [Boost-users] Beast for IMAP
by Zhivko Vasilev 29 Aug '20

29 Aug '20

SMTP build with HTTP library sounds very strange. Beast is an HTTP 1.1 protocol library. IMAP and SMTP are also protocols and have nothing related to their syntax with HTTP. I had worked on the IMAP/SMTP app, and I think it is better to build with Asio only. The only one related point between HTTP and IMAP/SMTP, is if you need OAuth auth integration. Regards, Zhivko On Sat, Aug 29, 2020 at 2:48 AM Kenneth Porter via Boost-users < boost-users(a)lists.boost.org> wrote: > I've been thinking about writing some email utilities and have looked at > various IMAP libraries. I'm wondering if I should roll my own using Beast. > I've seen an SMTP library using Beast on GitHub. Has anyone else attempted > an IMAP client with Beast? > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

[LEAF] Review Results
by Michael Caisse 28 Aug '20

28 Aug '20

I want to thank Emil for his patience for the publishing of the review results as life got in my way. Thank you Emil for submitting LEAF to be reviewed for inclusion into Boost. As an already-Boost-author, you knew what you were getting into and continued into the process. I also want to thank you for once again pushing our thoughts on error handling. -------- Result -------- This is the part everybody scrolls to the bottom to read, so let’s just put it at the top. Boost.LEAF is ACCEPTED into Boost. After the following modifications are made to the library, the repository can be transitioned to Boost for inclusion into the next release (with the release cycle timing constraints): Specify the TLS requirement sooner in the documentation. Optional usage of Boost.Config to perform all of the Boost Configy things. (further discussion on this below) Macro naming and general Boostification clean-up. -------- Reviews -------- There was a good amount of discussion about the library on both the dev and user mail lists. I want to personally thank those who got involved in the review. You make the process work! Result summary: Accept: 7 Reject: 1 No-decision: 3 The no-decision reviews provided valuable input and discussion threads. While it would be my preference to have the review authors provide a final verdict, I was grateful for the time and energy they spent with the library and formulating thoughts into emails for discussion. Some comments from reviews: “I find function preload() really great and novel. … This really makes the error reporting code brief, clean and bug-free.” “I like LEAF very much and there's a lot offered here…” “I like it.” “...it allows bridging multiple error handling strategies and usage patterns in an efficient way.” About the docs: “They look good and manage to explain hard concepts in a very approachable fashion.” “The documentation is great -- in terms of styles it's probably the best I've seen for a C++ library.” “Clear, friendly and complete.” -------------- Some Thoughts -------------- While there was overwhelming consensus that LEAF should be included into Boost, the process is not democratic. I have spent considerable time understanding the concerns raised in each of the reviews and in particular the singular rejection. Emil took time responding to each of the reviews. The exchanges were fruitful and both “conditional accept” and “reject” reviewers changed their verdicts to accept along the way. Most of the concerns were amicably resolved. I am comfortable with the design choices and implementation made by the author for the remaining items. One reviewer brought up the re-implementation of Boost.Config type facilities. This of course is a complex issue for a library with zero dependencies. The ability to simply drop the Boost.LEAF directory into a project and run is a definite plus for a specific user segment. Being able to modify a single Boost.Config repository to support WackyCompiler14 targeting LEG Core and get a bunch of libraries for the ride is also a plus. Emil and I have discussed these concerns and the best choice seems to be defaulting to zero dependencies and the option to pull in Boost.Config to provide configuration type facilities if needed. Accepting a library into Boost is as much about the library as it is bringing the author into a group. While Emil is already part of the author crowd, it was clear to me through his careful, informative, and patient responses that the addition of Boost.LEAF brings professional maturity that strengthens the community. A user with more than a year of experience with the library voted acceptance based on the “qualities of the library itself and the responsiveness and openness for feedback of its author.” Throughout the review period, Emil integrated feedback to both the documentation and code in another branch. It was wonderful to see the community provide input and the author respond so quickly to produce a better final result. Thank you Emil for your vision of better error handling and striving to bring us along! -- Michael Caisse Ciere Consulting ciere.com

1 0

[Lockfree] spsc example query
by Sean Farrow 25 Aug '20

25 Aug '20

Hi, I'm just about to start using the spsc queue in a project and whilst reading the example at: https://www.boost.org/doc/libs/1_74_0/doc/html/lockfree/examples.html#lockf… looking at the consumer function, there appears to be two while loops retrieving items from the queue inside the outer loop that checks whether the done variable is true. Can somebody please explain why this is, or, is it a bug in the example? I would have thought one inner while loop would be enough. Thanks, Sean.

2 1

JSON library scheduled for review
by Mateusz Loskot 25 Aug '20

25 Aug '20

Hi, A brief announcement from the review wizards: Formal review of the JSON library has been scheduled to take place between October 9 and October 18, 2020. Details and links available here https://www.boost.org/community/review_schedule.html We'd like to thank Pranam Lashkari (Boost.GIL, [Boost.]Astronomy, Boost GSoC) for volunteering to act as the review manager. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

[Log] Formatting multiple attributes in a single formatter
by Michael Jones 24 Aug '20

24 Aug '20

TL;DR; I'm looking for help/advice/code on creating a custom formatter, or formatter factory, to format more than one attribute at a time into a single "placeholder" in the format expression. I do not yet have code, working or otherwise, to try to solve this, because I am still trying to understand the design space of Boost.Log's API. I have been using Boost.Log successfully in my project for about 1-2 years now, with many hundreds of log statements of the style MY_LOG_MACRO(Normal) << "My Log Message" << std::endl << "- Attribute 1:" << myAttributeVar1 << std::endl << "- Attribute 2:" << myAttributeVar2; I now want to convert these hand-formatted attributes that are directly inserted into the message into attributes in the Boost.Log meaning. However, these attributes are "free form", in the sense that they are not pre-registered with Boost.Log before use (which is obvious given they are manually formatted into the message string), and they do not conform to any specific naming conventions or value-type scheme. I estimate that there are a few hundred different attributes that are printed to my logs in various places as "one off" attributes that are not really meaningful outside of the specific log statement they are used in. My current plan is to provide my developers with a way to incrementally move their logging toward using Boost.Log's attributes without requiring a flag-day where every log statement is changed in a single merge. I want to do this by allowing these attributes to be added to the log message using boost::log::add_value() from boost/log/utility/manipulators/add_value.hpp, such as: MY_LOG_MACRO(Normal) << "My Log Message" << boost::log::add_value("Attribute 1", myAttributeVar1) << boost::log::add_value("Attribute 2", myAttributeVar2); However, I want to provide the same formatting semantics that they are used to, to make the transition easier. At this stage, it is not clear whether I'll ever be able to get a set of standardized attributes that can be pre-registered with the Boost.Log library. A surface level estimate shows me that I have, at the minimum, many dozens of different attributes with unique names / value-types. This would make addressing each such attribute name individually prohibitively expensive to add to the format expression Currently, using boost::log::import_from_stream(), I use a format expression like: Format="%Process%/%Channel% - [%Severity%] %Message%" And I would like to change that to the following, or something similar: Format="%Process%/%Channel% - [%Severity%] %Message%\n%Attributes%" The intention of %Attributes% here would be a placeholder in the format expression that gets resolved to a custom formatter, or formatter factory, which will iterate through the list of attributes in the current record_view and print each attribute name and value with a new line separator. Ideally, this formatter or format factory would be able to recognize that a particular attribute has already been printed, or will be printed, so that it only adds new information to the log. However, I believe this is not something that can be easily done, so I currently plan to have this duplicated information in the log with the intention to resolve it another time. One way I could resolve the duplicate information problem is by adding an option block to the %Attribute% placeholder, e.g. %Attribute[Exclude:Process, Exclude:Channel, Exclude:Severity, Exclude:Message]%. It would be ugly, but it would do the job. So far I've gathered the following information about this subject: How the default formatter factory works by creating a default_formatter, which has special handling for various time types, but otherwise just calls operator<<(stream_type, value); https://github.com/boostorg/log/blob/develop/src/setup/default_formatter_fa… How the format parser works by, well, parsing the format expression to get attribute names and other important information for later use. I don't have a complete understanding of this, but I get the gist of it. https://github.com/boostorg/log/blob/develop/src/format_parser.cpp How sinks_repository from init_from_settings.cpp works by pre-defining multiple different sink-factories with the repository, and then init_from_settings() uses those pre-defined factories to support loading the settings. Notably, I use default_text_file_sink_factory, and default_console_sink_factory in my own code. Both of those sink factories just use boost::log::parse_formatter() to create the formatter from the format string in the settings file. https://github.com/boostorg/log/blob/develop/src/setup/init_from_settings.c… How formatter_repository and works by storing a map between the Attribute name and the Formatter Factory to use. https://github.com/boostorg/log/blob/develop/src/setup/formatter_parser.cpp Record_view, it's read-only nature, and how to access the attributes for the record using the boost::log::record_view::attribute_values() function. https://github.com/boostorg/log/blob/develop/include/boost/log/core/record_… The next thing I am going to try is to define a custom formatter for the %Attributes% attribute name, and pre-define some constant value for it so that it is always defined for each record. Then I'll have a formatter factory like this (psuedo code, not compile tested) template< typename char_type > struct abitrary_attribute_formatter { void operator() ( boost::log::record_view const& rec, boost::log::basic_formatting_ostream< char_type >& strm ) const { for(auto const& attr : rec.attribute_values()) { strm << "- " << attr.name() << ": " << attr.value(); } } }; What I'm currently trying to understand is how I can create a custom formatter that dispatches to other formatters. How is this done? Is there a more straight-forward way to accomplish the goal of providing a formatter for the concept of "All available attributes"? If not, can anyone offer implementation or design advice?

1 0

[Boost.Accumulator] retrieve percentage corresponding to a value
by Timo Sachsenberg 24 Aug '20

24 Aug '20

Hi, Boost offers convenient methods in the accumulator library to get e.g. a value (let's say 1234) corresponding to a certain quantile (let's say 0.995). For my specific use-case I wonder if the opposite (value input=1234, output=0.995) is also possible. Is there an elegant way to calculate/estimate the percentile of value in an online fashion (=while accumulating) and without storing all values? One thing I came up with is using extended_p_square_quantile with many probabilities and then do a binary search over the values output by the quantile() function. Is there an easier way to directly get the percentile from the value that I am missing? Best, Timo

1 0