- Boost - lists.boost.org

Re: [boost] Compile time reflection for IPC using
by Brian Wood 25 Jan '14

25 Jan '14

> Ok. I would like to ask you about next > When we should use the RPC architect should we serrialize the call Oleg, Sorry, but I have no idea what you're talking about in your posts. I have some serialization related software on my website that you may be interested in. I'm available to talk on the phone if you like. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

Announcing the Boost Community Maintenance mailing list
by Marshall Clow 24 Jan '14

24 Jan '14

The Boost Community Maintenance mailing list (boost-maint) has been created, and you can sign up here: http://lists.boost.org/mailman/listinfo.cgi/boost-maint The goal of the Boost Community Maintenance team is to maintain those libraries whose creators no longer can. The initial proposal for the group is here: https://dl.dropboxusercontent.com/u/9897665/community-maintenance.html I will be posting status and working guidelines here and on the boost-maint mailing list over the weekend. I encourage everyone who wishes to participate to subscribe to the boost-maint mailing list, and we’ll get started by Monday. Thanks in advance! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[testing] How do you interpret the SHA1 revision (outdated results)?
by John Maddock 24 Jan '14

24 Jan '14

So... I'm looking into Boost.Regex and I'm seeing some failures which appear to refer to outdated sources (line numbers are all wrong for current source), for example: http://www.boost.org/development/tests/develop/developer/output/marshall-ma… But how on earth do I check this? Reported run date is yesterday, but this was fixed/changed on Dec 20th: almost a month ago. And the revision listed on the page is a SHA1 which I can't seem to relate to anything useful? Thanks, John.

6 13

Compile time reflection for IPC using
by Oleg Labutin 24 Jan '14

24 Jan '14

Do you now about one approach (for two compilers (gcc 3.7, and MSVC (last)) emulate compile time reflection with difference scope? Like struct some { META_STRUCT(some); FLD(int, a); FLD(int, b); METH(int, call_0, (int, a)); METH(int, call_1, (int, b)); }; void in() { typedef hl::reflection_extract<some>::field_accessors acc; some s; s.*hl::at<acc, a_accessor>::get() = 5; } We can see here https://github.com/ol72/hl/tree/ And you can try to compile this attached demo Use __J_ACTIVE define to see as reflection worked in json oriented part of project. For which you should install json. Without this you can see ability take meta information by query. But global goal I think we understanding Our backend can be something else. Like client server , data base oriented structures in which we can use by SQL like C++ syntax We can make (and I made it ) database like structures struct human_tables { TABLE(names) { fields((int) index, (std::string) name, .... ); }; TABLE(country) { fields((names_table::index) name, ... ); }; TABLE(human) { indexes(names_table::index_field); fields((names_table::index_field) name, (country_table::index) country...); }; };

3 11

C++03 and C++11 ABI compatibility for compiled libraries
by Andrey Semashev 24 Jan '14

24 Jan '14

Hi, I would like to raise the issue of binary compatibility of compiled Boost libraries between C++03 and C++11. I faced this problem with gcc on Linux, but other compilers and platforms may be affected as well. To summarize the problem: * Most, if not all Linux distributions build packages in C++03 mode. This is also the default in gcc. * Some Boost libraries conditionally use C++11 features in their binary interfaces (see [1] as an example). This makes C++03 and C++11 versions of the library binary incompatible. * Given that, users are unable to use C++11 in their code that uses Boost because of linker failures. I don't have the complete list of the offending C++11 features that break ABI, but it would seem that at least scoped enums and rvalue references are among them. Are there any more? I would like to hear opinions on the possible course of action to tackle this problem. Currently, I see 2 choices: 1. Avoid using C++11 features in binary interfaces. This may also mean avoiding STL types in binary interfaces, if they differ between C++03 and C++11 (I didn't verify that). This is my suggested hotfix solution for Boost.Filesystem [1] and the approach I took in Boost.Log. Obviously, this cripples code and error prone, but it keeps a single binary that can be used from any flavor of C++ on the user's side. 2. Compile different versions of Boost libraries, for each supported C++ version. The C++ version should be encoded into the library file names, so that different versions can coexist. This would require changes in Boost.Build and autolinking support code, but I think this would be a better long-term solution. Opinions? [1] https://svn.boost.org/trac/boost/ticket/6779

12 27

Boost.Fiber review January 6-15
by Nat Goodspeed 23 Jan '14

23 Jan '14

Hi all, The review of Boost.Fiber by Oliver Kowalke begins today, Monday January 6th, and closes Wednesday January 15th. ----------------------------------------------------- About the library: Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack. A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiber internally uses coroutines from Boost.Coroutine; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time. docs: http://olk.github.io/libs/fiber/doc/html/ git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip The documentation has been moved to another site; see the link above. If you have already downloaded the source, please refresh it; Oliver has added some new material. --------------------------------------------------- Please always state in your review whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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 what compiler? 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? Nat Goodspeed Boost.Fiber Review Manager ________________________________

16 129

Volunteers needed to run regression test reporting
by Beman Dawes 23 Jan '14

23 Jan '14

We have had a long term problem with regression test reporting going offline unexpectedly. The process used XSLT processing was hard to configure, horribly slow, and very fragile, and those factors made it a pain to run. Last year, Steven Watanabe rewrote the report generation in C++, and those issues have pretty much disappeared, so the process is now far easier to run. It runs in five minutes or less. Hooray C++! Hooray Steven! And Hooray Tom Kent who runs the reports! The remaining reliability factors are local ones like system crashes. Since the reports run as cron jobs, it can be quite a while before anyone is inconvenienced enough to report it to the Boost list, and Murphy's Law ensures that it is always the day after the person running the reports left for a week-long back country hike. We can mitigate that by having several people running the reports. I've written some docs, so it shouldn't be too hard, although right now it does require a *nix-like system. I've been running them on a Windows host using a VirtualBox virtual Ubuntu system, and have found it to be easy. One possibility would be for Tom to continue to run the reports on the hour, a second person to run them twenty minutes after the hour, and a third to run forty minutes after the hour. Please volunteer to help make regression reporting more timely and reliable! --Beman

12 21

[phoenix] 7181
by Fletcher, John P 23 Jan '14

23 Jan '14

________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Mathieu Champlon [m.champlon(a)free.fr] Sent: 23 January 2014 12:11 To: boost(a)lists.boost.org Subject: Re: [boost] [phoenix] 9111 and 9113 > Hi John, >There is https://svn.boost.org/trac/boost/ticket/7181 which is also >about a warning albeit a different one. >Thanks for doing this ! >MAT. I have pushed to phoenix develop using the patch in 7181 John _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[phoenix] 9111 and 9113
by Fletcher, John P 23 Jan '14

23 Jan '14

________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Mathias Gaunard [mathias.gaunard(a)ens-lyon.org] Sent: 21 January 2014 16:44 To: boost(a)lists.boost.org Subject: Re: [boost] [phoenix] New maintainer On 20/01/14 13:40, Fletcher, John P wrote: >> If you have any information on your problems with Phoenix, in particular any not already on the bug system, please let me know. >> > I filed bugs about warnings a while ago. (9111, 9113) > It shouldn't take much work to fix those and it would be great if I > could finally make my code compile without warnings. I have now pushed a fix for 9111 and some fixes for 9113 to the develop branch. The report on 9113 says there are others, so any other reports would be helpful. John _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

raw.github.com access from behind firewall
by Belcourt, Kenneth 22 Jan '14

22 Jan '14

Hi, When I try to run github hosted regression tests with run.py, access to raw.github.com times out even though it seems to be using the specified our proxy server. # Running regressions in /scratch/modular-boost... # Creating regression scripts at /scratch/modular-boost/tools_regression_src... # Dowloading regression scripts from https://raw.github.com/boostorg/boost/develop/tools/regression/src... --- http://wwwproxy.sandia.gov:80 What's interesting is that I'm able to clone from github.com just fine, as you can see here. -bash-4.1$ git clone https://github.com/boostorg/boost Initialized empty Git repository in /scratch/modular-boost/boost/.git/ remote: Counting objects: 180556, done. remote: Compressing objects: 100% (68339/68339), done. remote: Total 180556 (delta 111934), reused 180501 (delta 111879) Receiving objects: 100% (180556/180556), 68.21 MiB | 10.23 MiB/s, done. Resolving deltas: 100% (111934/111934), done. But we're not able to clone from raw. -bash-4.1$ git clone https://raw.github.com/boostorg/boost Initialized empty Git repository in /scratch/modular-boost/boost/.git/ error: The requested URL returned error: 403 while accessing https://raw.github.com/boostorg/boost/info/refs fatal: HTTP request failed which means this clone (https://raw.github.com/boostorg/boost/develop/tools/regression/src) will fail. Is this a known issue and / or is there a workaround for this? This is on RHE Linux with git 1.8.5.1. -- Noel Belcourt

3 9