- Boost - lists.boost.org

Boost lists back up but messages since May 9 probably lost
by Beman Dawes 13 May '14

13 May '14

Here are the details: ---------- Forwarded message ---------- From: DongInn Kim Date: Tue, May 13, 2014 at 6:48 AM Subject: Re: Boost lists are down To: Beman Dawes <bdawes(a)acm.org> Hi Beman, I am so sorry that there was a problem that I could not notice. The boost mail server and mailing list server were working OK but the spam filter server that the boost mail server use disabled our access, which I did not do and I can not do. I talked to the guy who manages the spam filter and make sure that they take care of the boost mails as well. It seems that it starts to flow but I am afraid that the mails that wowbagger had not delivered since May 9 are missing. :-( I will talk to the guy to see if there is a way to push the valid mails (i.e., non-spam mails) in the spam filter. I suspect that they are all already gone. Regards, -- - DongInn

1 0

A problem in the boost mailing list
by Kim, DongInn 13 May '14

13 May '14

Dear Boost mailing list users, My name is DongInn Kim, sysadmin of the boost mailing list. I am so sorry that there was a problem that I could not notice until this morning. The boost mail server and mailing list server have been working OK but the spam filter server that the boost mail server uses disabled our access, which I did not do and I can not do. I talked to the guy who manages the spam filter and make sure that they take care of the boost mails as well. It seems that it starts to flow but I am afraid that the mails that wowbagger had not delivered since May 9 are missing. :-( I will talk to the guy to see if there is a way to push the valid boost mails (i.e., non-spam mails) in the spam filter but I am afraid that they are all already gone. Again, I am sorry for the missing emails. Regards, -- - DongInn

1 0

Re: [boost] boost] [asio] intergrate with message loop how to
by microcai 13 May '14

13 May '14

2014-05-09 20:08 GMT+08:00 Nat Goodspeed <nat(a)lindenlab.com>: > On May 9, 2014, at 6:18 AM, microcai <microcai(a)fedoraproject.org> wrote: > >> 2014-05-05 21:57 GMT+08:00 Nat Goodspeed <nat(a)lindenlab.com>: >>> >> >>> Perhaps you might propose a cross-platform asio API extension that could give you control at the times you want, using the completion-handler mechanism? >> >> then there will be endless ways of loops that you need to integrated >> into asio. glib, qt, WIN32 message loop ... etc. > > Understood. I am not proposing that specific message-loop code be absorbed into Asio. I am asking whether you (or any interested reader) might be able to define an extension API that permits / facilitates a consuming Asio application to integrate with any required message loop. some thing like io_service::wait_events(); but , does not dispatch the event. I can run seperated thread to call this, then post message to gui thread, let gui thread run io_service::poll() to dispatch the handlers; if the hander is executed in gui thread, we can avoid lots of synchronization code between gui thread and asio thread( if io_service::run() has to be run in seperated thread. ).

1 0

test msg, please ignore
by Joaquín Mª López Muñoz 13 May '14

13 May '14

________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

1 0

Boost Python Xcode Example
by Jared McIntyre 12 May '14

12 May '14

I have been trying to get the Boost Python example working when compiling in Xcode. Everything compiles at the moment, but the module fails to load in python. It fails to find the module if it has an extension of either .pyd or .dylib, and .so has the error "ImportError: dynamic module does not define init function” even though the function should be there. I’m sure that I have something setup incorrectly and was wondering is anyone has a working Xcode project example that I could take a look at to see where I’ve gone wrong. Thank you, Jared McIntyre

1 1

[GitHub] List open pull requests for all libraries? [resend]
by Beman Dawes 12 May '14

12 May '14

We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman

1 0

[asio] Windows 2000 no longer supported?
by Andrey Semashev 11 May '14

11 May '14

Hi, I've been reported this ticket: https://svn.boost.org/trac/boost/ticket/10016 that says that Boost.ASIO requires SO_UPDATE_CONNECT_CONTEXT now, which is only implemented since Windows XP. Is Windows 2000 support officially dropped in Boost.ASIO?

1 1

[GitHub] List open pull requests for all libraries?
by Beman Dawes 10 May '14

10 May '14

We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman

1 0

Lack of response to pull requests
by Beman Dawes 10 May '14

10 May '14

IMO it should be a Boost policy that anyone who submits a pull request deserves a response within a reasonable period of time. *What is a "response"?* GitHub pull requests have a "Comment" mechanism, so that's the best mechanism as it ensures reaching the submitter even they don't read the developer list. We also need to delineate some common responses, but that can wait until the overall policy is agreed upon. *What is a "reasonable period of time"?* This may be a bit of a bike shed discussion since whatever we start with may need adjustment based on experience. Would two weeks be a good starting point? *Who should step in if there is no response from the library maintainer?* The Community Maintenance Team IMO is the logical choice. A pull request that does not receive a timely response may be an early warning sign that the library involved does not have an active maintainer. The CMT folks are interested maintenance and already have processes to review pull requests. This would be an expansion of their mandate, and details need to be worked out such as what happens if the library maintainer is just busy at the moment. *What should the pull submitter do if there is no response within the reasonable period of time?* Send an email to the CMT pointing to the open pull request. (It would be nice if the submitter didn't have to do anything, but that implies the ability to monitor open pull requests. See "[GitHub] List open pull requests for all libraries?") Comments? --Beman

1 0

Re: [boost] [GSoC, MPL11] Community probe
by Louis Dionne 09 May '14

09 May '14

Gonzalo Brito Gadeschi <g.brito <at> aia.rwth-aachen.de> writes: > I have a question: the proposal and library are called MPL11. That is true, but I'm starting to realize that it's a very bad name. The project started about two years ago, when C++14 was still out of my sight. Be reassured that I always consider the latest version of the language, not only C++11. > In my experience, relaxed constexpr allows for beautiful metaprogramming > with respect to C++11, in particular when combined with Boost.Fusion, and I > think that it is really a game changer with respect to C++11 constexpr, > since it allows not only "functional" metaprogramming but also "imperative" > metaprogramming, significantly lowering the learning curve of > metaprogramming for C++ programmers. Could you please expand on the nature of metaprogramming you have been doing with constexpr? Are you talking about manipulating values of a literal type, or about "pure type" computations? See below for more on that. > Have you consider the influence of relaxed constexpr (C++14) in your > library? > > Could it simplify the design/implementation/usage of the MPL? I did consider the impact of C++14 on the design of the library, and I still am. At this point, my conclusion is that we must define what we mean by a "template metaprogramming library". I differentiate between two main kinds of computations that can be done at compile-time. The first is manipulating "pure types" with metafunctions (e.g. type traits): using void_pointer = std::add_pointer_t<void>; using pointers = mpl::transform< mpl::list<int, char, void, my_own_type>, mpl::quote<std::add_pointer> >::type; The above example is completely artificial but you get the point. The second kind of computation is manipulating values of a literal type at compile-time. using three = mpl::plus<mpl::int_<1>, mpl::int_<2>>::type; The MPL wraps these values into types so it can treat computations on those as computations of the first kind, but another library could perhaps handle them differently (probably using constexpr). constexpr int three = plus(1, 2); It is easy to see how constexpr (and relaxed constexpr) can make the second kind of computation easier to express, since that is exactly its purpose. However, it is much less clear how constexpr helps us with computations of the first kind. And by that I really mean that using constexpr in some way to perform those computations might be more cumbersome and less efficient than good old metafunctions. As for using constexpr to express computations on literal values, another question arises. Should there be a general library for handling those at compile-time, or should it be the responsibility of a well written domain- specific library to provide means to perform domain-specific computations at compile-time whenever possible? For example, should the MPL11 provide constexpr math functions, or should the std:: math functions be constexpr whenever possible? Another example is std::array. While the MPL11 could provide a constexpr container for homogeneous values of a literal type, simply changing the `begin` and `end` of `std::array` to be constexpr would make it possible to iterate on the array at compile-time. template <typename T, std::size_t n> constexpr T sum(std::array<T, n> array) { T s{0}; for (T i: array) // awesome s += i; return s; } constexpr std::array<int, 5> array{{1, 2, 3, 4, 5}}; static_assert(sum(array) == 15, ""); Unfortunately, I don't think this is happening in C++14, but I could be mistaken. Still, you certainly understand the implications. So a valid question that must be answered before I/we can come up with a "final" version of the library that can be proposed to Boost (or for standardization) is: "What is the purpose of a TMP library?" Once that is well defined, we won't be shooting at a moving target anymore. Right now, I have avoided these questions as much as possible by focusing on computations of the first kind. For those computations, my research so far shows that constexpr is unlikely to be of any help. If someone can come up with counter-examples or ideas that seem to refute this, _please_ let me know and I'll even buy you a beer in Aspen. This is _very_ important; it's central to my current work. > Would a rewrite of MPL11 be necessary afterwards (MPL14)? If constexpr turns out to be a game changer for computations of the first kind, then I suspect a large part of the current MPL11 would have to be rewritten. Of course, I tried to prevent this from happening by going slowly and looking at all the possibilities, but these things happen and it's part of the game. As for computations of the second kind, not _much_ work (comparatively) has been done on them because I knew it was a can of worms. So even drastic changes would not kill the library as it stands. Finally, if any of this does not make sense to someone, please let me know (on this list or privately) so I can explain further and correct any fallacious reasoning on my part. I hope this answers your questions; sorry for the long-winded answer but I think it can be informative for others too. Regards, Louis

5 13