- Boost - lists.boost.org

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

[xint] Design Question
by Chad Nelson 09 Jul '10

09 Jul '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm adding an "unsigned" option to the XInt library, so that fixed-length integers act exactly like their built-in counterparts. That in itself is not a problem, since unsigned fixed-length integers have a well-known and standard behavior. The problem is: what should the library do if the user asks for an unsigned *non*-fixed-length integer? The options I've come up with so far, in order of my personal preference: A: Make the unsigned option part of the fixed-length option, so it *can't* be specified separately. (The most elegant solution, but perhaps not the most useful.) B: Refuse to compile (or if I can't find a way to do that, instantiate) it, on the grounds that the combination can't logically be supported. C: Throw an exception if any calculation results in a negative number. (Not very useful, but logical because under the built-in types' unsigned rules, a negative number in an unlimited-length library would be infinitely long.) D: Force any negative numbers to a different value, such as zero or maybe their positive counterparts. (I can't think of any use for this, I just put it here for completeness.) Can anyone think of a potential reason for options C or D? Or a reason to prefer option B? Or maybe come up with a different idea entirely? - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwY2EYACgkQp9x9jeZ9/wSZuACgqIjJ85p0wUrwhCR/tcvY8QUL bagAniFZU/UGwKfpK7juhuWYxXwMb2Ar =qvcJ -----END PGP SIGNATURE-----

7 24

[quickbook] Question about macros and templates
by Andrey Semashev 09 Jul '10

09 Jul '10

Hi, I'm writing docs in quickbook and stumbled upon a problem. I have this document structure: main.qbk [include a.qbk] [include b.qbk] [include c.qbk] [include x.qbk] [include y.qbk] [include z.qbk] [xinclude r.xml] In files a, b and c I define macros that would unfold into headerref, classref, etc. for the items described in the auto-generated r.xml Reference. I want to use these macros in x, y and z, both in text and code samples. The problem is that, it seems, quickbook doesn't unfold these macros in x, y and z. My guess is that the scope of the macros is limited to the files they are defined in. Is that true? I tried to do the same with templates. It seems that templates are visible in x, y and z, but still are not unfolded in code samples. Is there a way around this problem? Thanks.

2 2