- Boost - lists.boost.org

[exception] missing graphic
by Daniel James 06 Aug '08

06 Aug '08

Just a minor issue - the exception libraries' css refers to a file 'left.png' which doesn't exist. Can you have a look at this? thanks, Daniel

2 1

[Boost-testing] Trunk reports update... And a plea for help.
by Rene Rivera 06 Aug '08

06 Aug '08

Trunk test report generation is still not running. The power is temporarily back in my building, in the form of what must be a rather large generator. As it's providing power for a few buildings. But because it's a generator I'm only running essentials. Which means the server that is dedicated to the test results is not running. Only my main server is up. I've mentioned in the past that I want to move the report generation someplace else. So I'm asking again... Is there a kind person out there with the appropriate resources and wants to donate them for running reports? Yes, this is a hefty request, I'm sorry. But it just doesn't seem practical for me to keep devoting the resources to this. And since I'm asking, the ideal situation would be if someone, or some company, would donate a dedicated Boost test server in some data center. For example something like this <http://tinyurl.com/64mhx9>. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing

1 1

Re: [boost] data_binding
by Brian Davis 06 Aug '08

06 Aug '08

>Stjepan Rajko writes: > I have tried to tackle the value/domain transformation problem a while > back, inspired by Brook Milligan's (CC-d) probability library (which > can nicely transition probability values between linear and log > domains). > Brook Milligan also worked on a generic domain transformation library, > so he might comment on this as well. There is also the Boost.Units > library which might offer transformations for some cases. >Thanks, Stjepan. I've continued to refactor that, actually, to make >it support the more generic problem under discussion here. So far it >is mostly done. I think the only issues are some silly overloading >resolution issues that have little to do with the basic ideas. For >the discussion I'll outline my approach. The goal I have/desire is to preform type transformations and allow the programmer to specify these transformations in a generic way For type T1 and T2 allow the programmer to specify f(T1 t1, T2 t2 ) and g(T1 t1, T2 t2 ) where f and g are transformation functions from T1 -> T2 and T2->T1 respectively. Overloading operator= and specifying f(T1 t1, T2 t2 ) := t2 = t* 1/2 and g(T1 t1, T2 t2 ):= t1 = t2*2 allowing the programmer to type float t1; float t2; bind_values<float ,float > t1t2ValueBinder( t1, t2 ); t1 = 12; printf( "%f", t2 ); // produces output of 6 Transformations shall allow chaining/cascaded to be specified. int a; int b; float c; boost::uint32_t d; bind_values<int,int> abBinder( a, b ); bind_values<int,float> abBinder( b, c ); bind_values<float,boost::uint32_t> abBinder( c, d ); // a->b->c->d a = 12; printf( "%f", d ); // produces output of 6 Transformations shall allow for fanout int a; int b; float c; boost::uint32_t d; boost::uint32_t e; boost::uint32_t f; bind_values<int,int> abBinder( a, b ); bind_values<int,float> abBinder( a, c ); bind_values<float,boost::uint32_t> abBinder( c, d ); bind_values<float,boost::uint32_t> abBinder( c, e ); bind_values<float,boost::uint32_t> abBinder( c, f ); // a-+->b // | // +->c-+->d // | // +->e // | // +->f // a->b->c->d a = 12; printf( "%f", f ); // produces output of 12 as f and g default to 1 to one mapping a = 12; printf( "%f", f ); // produces output of 12 as f and g default to 1 to one mapping printf( "%f",e); // produces output of 12 as f and g default to 1 to one mapping f=32; printf( "%f", a ); // produces output of 32 as f and g default to 1 to one mapping printf( "%f",f ); // produces output of 32 as f and g default to 1 to one mapping printf( "%f",c ); // produces output of 32 as f and g default to 1 to one mapping Transformations shall support bidirectional and unidirectional updates. >The basic observation that motivates this is that in some (many?) >situations there exist a group of related types that clearly have >common semantics in the application domain but may impose different >constraints in their implementation. Yes. Agreed >Indeed, some operations may not >be practical or feasible for some of the types but could be for others >and there may exist transformations from one to another. Where if there exists no clear transformation... the programmer shall be allowed to specify one. >In the case >of probabilities think of two types, one for a probability and one for >its logarithm with appropriate operators defined for each domain and > the interconversions. Another example involves the representation of > polynomials, which can be in terms of coefficients or in spectral > terms that ease their multiplication. In this case, it may be > completely undesirable to implement a polynomical multiplication for > the coefficient representation. Yes so some types can not be automatically transformed. My example provides absolutely no support for this except for 1 to 1 translation... for disparate types it is... well... compiler errors waiting to happen if no translation functions are supplied. > Conceptually then, the Domain library seeks to create a framework for > implementing sets of such types that work smoothly together, and > enable the compiler to make choices about how to handle mixed domain > operations (e.g., adding a probability and a log probability) or > operations that must be performed in another domain (e.g., multiplying > two polynomials represented as coefficients). I think these are most > of the salient points, all of which are currently supported. The software engineer shall be allowed to specify a transform is the compiler cannot automatically figure it out. How difficult is it to specify new types and tranforms.... Are we talking about the types like thoes defined by the section titled "A Deeper Look at Meatafunctions - 3.1 Dimensional Analysis" in "C++ Template Metaprogramming" by David and Aleksey? If so ... ouch... could be quite painful to specify new types and conversions... What is your approach? > - Allow definition of families of types (domains) based upon each > member of a family sharing common semantics in the application > domain. Providing type conversions across known domains where they exist. Yes sounds great. > - Allow implementation (or not) of any within-domain operators that > make sense in the application domain. Yes sounds great with the exception of the "operators portion"... like every one in boost using operators for new purposes (think Spirit - and I don't mean this in a bad way) we are running out of operators which provide meaningful schematics... Food for thought: Wouldn't it be nice if we had our compilers be able to compile unicode source files ... call them .ucpp... and define new operators in the C++ language... then we would be able to utilize these new operators to write code which looks ascetically pleasing and readable. Another benifit could be easier support internationalization of software. I'll digress. > - Allow implementation (or not) of any appropriate interdomain type transformations. > - Decouple the domain type information from the value types used to > represent the internal domain-specific information. This I also provided for in my simple example. Though kinda a cheesy example as "domain" is completely specified by the programmer and there is no automatic domain logic . > - Allow specification of a default value type for any domain type so > that unspecified templates (i.e., T<>) provide meaningful results. > - Allow specification of which domains are interconvertible as a > series of pairwise conversions. so you have a chain a->b->c->d change a and b, c, and d are changed... correct? This was in my example Should also allow for fanout // a-+->b // | // +->c-+->d // | // +->e // | // +->f and avoid recursion. a->b->c->a->a->b->c->a... you get the idea > - Allow specification of which domains support which operations so > that the compiler can seek an appropriate domain for arguments that > may (or may not) be directly usable. What happens when and operation cannot be found in a domain, but the programmer can or needs to specify one? Is it extensible? > The goal is to clearly define all these points of extension so that > the "real" types (e.g., probabilities or polynomials) can be > constructed on top of the Domain library, thereby simplifying the > specification of domain families for any application or library. The easier it is to provide new specifications for types and their transformations the better.... you'll never think of every domain and translation. Need to supply a clear path to adding new types, domains, and translations. > I have been using this to refactor the Probability library as a proof > of concept. As mentioned, most of what the old version could do, the > new one will also do. > There are a few issues with overloads that are > confusing to me, so help is welcome. How do I obtain the code and where is the problem? > Thus, I am certain that there is > some merit in this approach to a generic domain solution. However, I > am also certain that there are other ideas out there that could > improve this. Gerneric domain is exactly what I am after. We have type T1, T2, T3,....TN and we have to translate between them... What's the easiest way to specify this for the programmer? > Because of the interaction in development between the two libraries > (Domain and Probability) I haven't quite finished everything. I'll > try to roll them up for viewing shortly, though. > I look forward to continuing discussion, receiving input, and > discovering how these ideas might be put to use in other contexts. Context.... Let me speak to context... Let's say your one of thoes down to earth engineer types... you got to get your product out... you have all this incoming and out going data at multiple layers of the software form hardware<->driver<->user space lib<->executable<->network<->client and you have to translate between types for each interface... Bitfields... don't get me started on bit fields... Why is a bit such a degenerative type in C++ (try typeid(bit.in_a_bitfield).name() and wonder why you get back unsigned... would be nice to get the position info of where the bit or bits are withing a bit field) ... I'll digress again... any way you want to easily specify type conversions at each layer. You've received the event in the past and called the appropriate conversion routine after conversion routine and thought to yourself.. Hey is there any way to get rid of all of these calls to conversion functions in my callback routine... they're kinda making the code messy. Sure would be nice if I had a data_binding library where I could specify the types and specify the conversion functions and when the value arrives just set it and have the conversion take place bidirectionally. Then you write it up... think to yourself who might be able to use this... maybe those boost guys :-) Hope my input is helpful. Brain

4 12

[Range] Not reinventing the wheel!
by Robert Jones 06 Aug '08

06 Aug '08

I came to boost.range looking for, and expecting to find, everything I needed to able to uniformly apply standard algorithms to containers and arrays, and maybe other things too, and that seems to be what boost.range is about. Maybe I've missed something, but it seems to supply only the 'scaffolding' to allow me to do-it-myself? Is this right? Some of the examples show how to do this, but that was what I was expecting the library itself to so. Is there some component I've missed here, or perhaps an 'algorithm' library build on top of boost.range? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

3 3

Re: [boost] [operators] euclidean vs euclidian (was: fixed-pt [improved])
by Michael Fawcett 06 Aug '08

06 Aug '08

On Fri, Aug 1, 2008 at 10:17 AM, Hervé Brönnimann <hervebronnimann(a)mac.com> wrote: > This is not related to fixed-point per se, but why did boost.operators > choose the spelling euclidian instead of the more common euclidean? I did > check the Merriam-Webster, and both spellings are accepted (to my surprise), > but I believe that most mathematicians use Euclidean... I'm surprised too - I've never seen it spelled otherwise. I checked the APIs we're currently using and they all use Euclidean. Google pulls up 3,820,000 for euclidean, and 325,000 for euclidian (it also says "Did you mean: euclidean"). In Google Code Search it pulls up 44,600 for euclidean, and 7,000 for euclidian. --Michael Fawcett

3 2

Trying to fix -Wshadow warnings - some help needed.
by John Maddock 06 Aug '08

06 Aug '08

Folks I have a large amount of code that generates warnings of the kind: t.cpp:6: warning: shadowing built-in function `double std::acos(double)' Actually many thousands of these warnings when building with g++ -Wshadow :-( Normally I would just fix the code, but in this case I don't see how, I have code that looks like: #include <cmath> template <class T> T f(T v) { // We want acos found via ADL in case T is a class type: using std::acos; return acos(v); } int main() { f(2.0); return 0; } Which just on it's own produces: $ g++ -I. -Wall -Wshadow -c t.cpp 2>&1 | less t.cpp: In function `void f(T)': t.cpp:6: warning: shadowing built-in function `double std::acos(double)' t.cpp: In function `void f(T) [with T = double]': t.cpp:12: instantiated from here t.cpp:6: warning: shadowing built-in function `double std::acos(double)' t.cpp:12: instantiated from here But I can't see any other way to code this... certainly using a "using namespace std;" in place of the "using std::functionname;" is *not* a valid fix (it can lead to lookup ambiguities). Any ideas folks? Thanks, John.

4 5

[1.36.0 beta] Beta release available on SourceForge
by Beman Dawes 06 Aug '08

06 Aug '08

New libraries: Accumulators, Exception, Units, Unordered. Updated Libraries: Assign, Foreach, Interprocess, Intrusive, Math, Multi-index Containers, PtrContainer, Spirit, Thread, Xpressive, plus a bunch more. Many thanks to Daniel James, Rene Rivera, Marshall Clow, Eric Niebler, the testers, and all the others who helped to get this beta release together. The beta period will be approximately one week. Please post bug reports here, but also let us hear about success stories too! --Beman

3 3

[mpl] doc issues in release beta
by Eric Niebler 06 Aug '08

06 Aug '08

In the reference section of the MPL docs, there are a couple of issues. The biggest is that there is some new CSS wackiness that is making cross-links look like regular text until you hover over the links with the mouse. This is a regression from 1.35. The other issue is a broken link. In the reference section for mpl::for_each, there is a link to the docs for value_initialized that goes nowhere. This problem exists in the 1.35 docs as well. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] out of date release results?
by Eric Niebler 06 Aug '08

06 Aug '08

Beman Dawes wrote: > Eric Niebler wrote: >> >> Beman Dawes wrote: >>> Eric Niebler wrote: >>>> Just spoke with Rene about this ... >>>> >>>> Eric Niebler wrote: >>>>> How come the "report time" on nearly every page of release >>>>> test results is dated July 15th? >>>>> >>>>> For example: >>>>> http://www.boost.org/development/tests/release/developer/summary_release.ht… >>>>> >>> >>> AFAIK, that's the wrong page to be looking at. The page I use to >>> make decisions is >>> http://beta.boost.org/development/tests/release/developer/summary.html >>> >>> >> >> Whew, thanks Beman! How do you get to that page? I go to boost.org, >> click on "Development", and then on "Release Summary". > > I don't look at www.boost.org, because I assume it applies to the > current release. > > Instead I look at beta.boost.org, because I assume it applies to the > release under development. Then why does www.boost.org have results for Boost.Accumulators (some of which are quite out of date), when Accumulators is new in 1.36. In particular, I never saw your response to this exchange from yesterday. I think this is a serious problem: Rene Rivera wrote: > Eric Niebler wrote: >> >> Oh whoa. Something really strange is going on with these pages. >> >> These results are old: >> http://www.boost.org/development/tests/release/developer/accumulators_relea… >> >> These results are new: >> http://www.boost.org/development/tests/release/developer/accumulators.html >> >> I can reach either page via different sequences of clicks. At first >> I thought that maybe one page represents results from 1.35, but >> that's not possible because accumulators wasn't in 1.35. >> >> What's going on? > > This sounds like the release view of the results is not getting > generated, on Beman's machine, and it's using some old set of > results. Hence only the developer view has the current results. Thoughts? <snip> >> >> OK, but that doesn't address the concern about test reporting. >> Currently, it takes a human (you, Rene, people on the boost-testing >> list) to manually verify that the results are being updated. > > Say we had a tool that looked at web pages to see if they had been > updated, and sent email if not. We would point it at > http://beta.boost.org/development/tests/release/developer/summary.html, > and set the required update frequency to say 24 hours. The email > address could be set to either the testing list, the site admins, > release managers, or whoever else was interested. That would not be good enough unless it checked every web page with test results on it. For instance, checking summary.html as you suggest would reveal nothing amiss, however this page on beta.boost.org is out of date: http://beta.boost.org/development/tests/release/developer/summary_release.h… -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[atomic count] boost on apple gcc 4.2
by David Abrahams 06 Aug '08

06 Aug '08

Well, first, I think you prolly ought to be posting to the developers' list, and second I think you need a tag in the subject like "atomic count" so that the right people will look at it :-) on Thu Jul 31 2008, "Mat Marcus" <mat-lists-AT-emarcus.org> wrote: > On Mon, Apr 28, 2008 at 3:22 PM, Peter Dimov <pdimov(a)pdimov.com> wrote: >> Daniel Oberhoff: >>> Hi, >>> >>> Has anyone successfully used boost with the "new" apple gcc 4.2? I >>> would like to since gcc42 has openmp, but I cant seem to be able to use >>> boost. I compiled and installed boost with apple gcc 4.2 by directly >>> using bjam with --toolset=darwin-4.2. When I try to use it I get an >>> error (detailed output of gcc below) which hints towards problems with >>> inline assembly. Actually, to get it compiled at all I had to set >>> -fasm-blocks. Am I missing a flag of sorts? Or is it "just" another woe >>> with apple's modified assembler? >> >> Is the new Apple GCC documented somewhere? I wasn't able to find anything >> related to a new assembler syntax or -fasm-blocks. Can you ask Apple to >> explain the issue? Stock g++ 4.2.x compiles the code, so the problem must be >> Apple-specific. > > Ok, I've got a little bit more information on the Apple gcc 4.2 > situation. Here is a snippet from an email dialog between a user and > an apple compiler engineer: > > user appears below with with prefix ">>" > apple compiler engineer appears below with with prefix ">" > >>> Thank you very much for the detailed reply. >>> Based on your information I deduce: >>> >>> 1) Using gcc 4.2 with 4.0 (c++) libraries is a supported >>> configuration by Apple >> >> Right. >> >>> I then conclude that the C++ ABI is fully compatible between 4.0 and >>> 4.2 >> >> Right. > > [snip, then user hypothesizes as to why there are problems with boost > under gcc 4.2/libstdc++ 4.0 on current Apple systems] > >>> This is the case because boost assumes that a 4.2 compiler implies >>> 4.2 libraries in flies such as boost/detail/atomic_count_gcc.hpp: >>> >>> #if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) >>> # include <ext/atomicity.h> >>> #else >>> # include <bits/atomicity.h> >>> #endif >> >> Yes, this is a bug or faulty assumption in boost. > > [snip] > >> The 4.2 library issue is a bug in Boost, not a problem with >> our compiler. I'd suggest raising the issue on one of the boost >> mailing lists and see what they say. > > Comments? > Mat > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0