July 2010 - Boost - lists.preview.boost.org

[fiber] with assembler
by Oliver Kowalke 11 Jul '10

11 Jul '10

I've uploaded a new version of boost.fiber to boost vault. It provides assembler for x86 (32/64bit) - PowerPC and ARM are planed. Performance of the raw context-switch is 6-12 times faster than swapcontext(POSIX). Mutexes, condition- and event-variables suspend fibers waiting on those sync. primitives and can be shared by fiber running on different threads (schedulers).

2 2

library proposal : odeint
by Karsten Ahnert 11 Jul '10

11 Jul '10

Hi, I proposed a library for solving ordinary differential equations some months ago. Since this time, we have worked a lot on this topic and we would like to start a discussion about the needs and the design of the library. The library odeint ("odeint" comes from integration of ordinary differential equations ) can be found in the sandbox and some preliminary documentation is also available: http://svn.boost.org/svn/boost/sandbox/odeint/ http://svn.boost.org/svn/boost/sandbox/odeint/libs/numeric/odeint/doc/html/… One of our main aims is the independence on a specific container or array type, such that the library can work with ODEs defined on arbitrary topologies, like networks, lattices , grids, etc. So, any comments on this library are highly welcome, as well as contributions (of any kind). Best regards, Karsten

8 13

Maintenance suspended
by David Abrahams 10 Jul '10

10 Jul '10

All --- I tried, I really did, to resolve the trunk and release branches of my libraries for the upcoming release. But the truth is that I'm finding Boost's current interdependent structure and the sluggishness of SVN on a project of our size just makes everything too hard to do. I'm now just declaring openly what has effectively been true for the past couple of months: I'm not maintaining my libraries until I complete the transition to Git that goes along with using Ryppln (http://ryppl.org) I'm sorry, I know it's not good or right, but I know it's going to be for the best in the long run. That should all happen fairly quickly now, anyway. -- David Abrahams BoostPro Computing http://boostpro.com

8 13

[Query] Cross Compiling for mipsel-linux
by Alapkumar Sinha 10 Jul '10

10 Jul '10

Hi, Pardon me if it is not the right forum to ask the below question. I am trying to build the boost library for mipsel-linux. I followed the following procedure. 1. Changed user-config.jam a. using gcc : mipsel : mipsel-linux-g++ ; 2. Then called bjam as: ./bjam --toolset=gcc-mipsel When I do this I am getting the following error. /******/ gcc.compile.c++ bin.v2/libs/math/build/gcc-mipsel/release/threading-multi/cyl_bessel_i.o /tmp/ccgLCiZn.s: Assembler messages: /tmp/ccgLCiZn.s:14975: Error: opcode not supported on this processor: mips1 (mips1) `ll $3,4($4)' /tmp/ccgLCiZn.s:14977: Error: opcode not supported on this processor: mips1 (mips1) `sc $5,4($4)' /tmp/ccgLCiZn.s:15063: Error: opcode not supported on this processor: mips1 (mips1) `ll $3,8($4)' /tmp/ccgLCiZn.s:15065: Error: opcode not supported on this processor: mips1 (mips1) `sc $10,8($4)' /tmp/ccgLCiZn.s:15105: Error: opcode not supported on this processor: mips1 (mips1) `ll $3,4($4)' And so on /******/ Can someone help me on where I am going wrong? Regards, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

2 1

Re: [boost] Maintenance suspended
by Christophe Henry 10 Jul '10

10 Jul '10

David Abrahams wrote: > All --- > >> I tried, I really did, to resolve the trunk and release branches of my libraries for the upcoming release. >But the truth is that I'm finding Boost's current interdependent structure and the sluggishness of SVN on >a project of our size just makes everything too hard to do. I'm now just declaring openly what has >effectively been true for the past couple of months: I'm not maintaining my libraries until I complete the >transition to Git that goes along with using Ryppln (http://ryppl.org) I'm sorry, I know it's not good or >right, but I know it's going to be for the best in the long run. That should all happen fairly quickly now, anyway. > > -- > David Abrahams > BoostPro Computing > http://boostpro.com > Dave, having a single library to maintain I probably cannot fully appreciate your situation. However, I would like to attract your attention to the very special position you have in this community, especially among newcomers I count myself with. Seeing dave (I mean THE dave! ;-) ) not maintaining his libraries creates a precedent and sends a wrong signal, which deals a blow to boost's credibility. Companies could wonder, waow, if the community cannot even help dave maintain his libraries, in which state must be others? Also considering that ryppl is so far not a reality yet and not even agreed on, we need a solution for the time being. Why not simply request help from the community to which you brought so much? I'm sure that many would be happy to help you on this. So, concretely, what is the problem? Do you have no time handling the feature requests or is svn the problem? If it is just about merging and doing some mechanical svn-related tasks, this is a very workable solution and I gladly offer my help. If it is about feature requests, this is a more complicated one (but seemingly unrelated to svn) and you could also ask for support on this list. Surely, someone competent will step forward and free you from much work. You could simply review patches before commit. It would also help the community by having more than one person familiar with your libraries. Christophe PS: Thinking about it more, it would be a good idea if every boost author would mentor one or several "young" members who could take over when the author's situation changes. In any company, we usually try to avoid having only one person knowing a subject. Maybe a boostcon would be a good place where authors would explain the inside of their library?

5 7

[serialization] tests broken on release branch?
by Richard Webb 09 Jul '10

09 Jul '10

I'm getting error: Unable to find file or target named error: 'test_diamond_complex.cpp' error: referred from project at error: '../libs/serialization/test' on the release branch regression tests.

2 1

[Format] Broken on release branch?
by Richard Webb 09 Jul '10

09 Jul '10

The release branch test results are showing new failures in a number of libs, several of which look to be because of a breakage in Format -> looks like it might have been partially merged from Trunk, and has some bits missing?

2 1

[trac] spam
by Steven Watanabe 09 Jul '10

09 Jul '10

AMDG #4350 was spammed an hour ago. https://svn.boost.org/trac/boost/ticket/4350 In Christ, Steven Watanabe

1 0

Mentoring (Was: Maintenance suspended)
by Christophe Henry 09 Jul '10

09 Jul '10

>>On Jul 8, 2010, at 8:39 PM, Joel de Guzman wrote: >> >> On 7/8/10 8:28 PM, Christophe Henry wrote: >> >>> PS: >>> Thinking about it more, it would be a good idea if every boost author >>> would mentor one or several "young" members who could take over when >>> the author's situation changes. In any company, we usually try to >>> avoid having only one person knowing a subject. >>> Maybe a boostcon would be a good place where authors would explain the >>> inside of their library? >> >> This is exactly what happened to Fusion and now happening to Phoenix >> with the past and present GSOC projects. > >Hey, that's a great idea. To actually institute such a program requires someone to come up with "young" >members who are ready and willing to be mentored. Christophe, would you like to take that project on? It's the key point, to find interested and competent potential "young" (or not ;-) ) members. It seems to me pretty clear that the most motivated candidates are to be found at the boostcon. I will happily take that project on if my idea is viable, and it would be: Authors (and I offer myself as testperson) prepare a talk or a paper where they show the inside of their library, as detailed as possible. - Participants get to learn some of the advanced techniques used in boost libraries - Boost gains an extended circle of possible contributors - Authors prepare a succession if needed later, or the possibility of having more people able to implement changes / fixes. They also get an in-depth review by very clever guys (honestly, I am every year impressed). Preparing others is especially important for people like me who are developing a library alone. Looks to me like a win/win scenario :) This can be coupled with GSOC projects. After learning the inside of a library, these participants could extend it. Alternatively, we can organize this with participants of this list, but it would require a greater deal of work for authors who would have to write down a lot. Some thoughts about it? Potential candidates (as speaker or attendee)? Christophe

6 9

Re: [boost] Parsing boost 1.43 with gcc-xml (bug #4324 - fixed in trunk)
by Benoît Leveau 09 Jul '10

09 Jul '10

Steven Watanabe wrote: > Benoît Leveau wrote: > > I have problems parsing boost 1.43 with gcc-xml, due to the lack of > > several preprocessor flags in /boost/config/compiler/gcc_xml.hpp. > > > > I saw this problem has been fixed in the trunk 4 weeks ago: > > /trunk/boost/config/compiler/gcc_xml.hpp > > Revision 62666: Disable all C++0x features in GCC-XML for now. Fixes #4324. > > > > I am not familiar with the details of the release process, so I'm > > wondering if a patched 1.43 version will be released? > > This bug is quite serious as it prevents boost from being parsed by > > gccxml (which, I guess, is listed as a supported compiler), > > and 1.44 hasn't been released yet, which leaves no option other than > > patching my local copy with the fix from the trunk. > > I would prefer to use an official release as it's not for a personal > > project, but will do the patch if I have to. > > > > 1.44 is scheduled for August 2nd. If you need this fix now, you'll > have to patch your copy. Ok, that's what I thought.. Thanks for the answer! Benoit

1 0