- Boost - lists.boost.org

[context review] Review will end Mars 30st 2011
by Vicente BOTET 27 Mar '11

27 Mar '11

Hi all, The review of Oliver Kowalke Context library will end on Mars 30th. There were a few interesting reviews with quite constructive comments. I encourage you to make a review so you can help improving the library and also help me to take the right decision ;-) Please let me know if you needs more time so I can see if the review could be extended. Vicente Review Manager Boost.Context is a basic building block library that is used for more higher abstractions. It is used by Boost.Fiber, Boost.Tasklet and Boost.Task from the same author. I really hope to see your vote and your participation in the discussions on the Boost DEVELOPMENT mailing lists! WARNING !!!!!!!!!!!!! Only on the Boost DEVELOPMENT mailing lists Please use [context review] as prefix of your post to make easier the review follow up. You can download a frozen version for the review from the Vault, TinyURL: http://tinyurl.com/5r77rel or The documentation is available directly here: http://ok73.ok.funpic.de/boost/libs/context/doc/html/ --------------------------------------------------- About the library: Boost.Context provides a possibility to switch between different user-level context and is intended to be the basis for a higher abstraction like coroutine and fiber. A user-level context represents the current execution state, including all registers and CPU flags, the instruction pointer, the stack pointer. boost::context encapsulates such a user-level context and is able to store/restore its associated user-level context. This allows multiple execution paths running on a single thread using a sort of cooperative scheduling (in contrast a thread is preemptively scheduled) - the running boost::context decides explicitly when its yields to allow another boost::context to run (user-level context switching). A context can only run on a single thread at any point in time but may be migrated between thread. A context switch between threads costs usually thousands of CPU cycles on x86 compared to a user-level context switch with few hundreds of cycles. Boost.Context differes to setjmp()/longjmp() in the fact that the C99 standard does not require that longjmp() preserves the current stack frame, e. g. jumping into a function which was exited via a call to longjmp() is undefined. Boost.Context allows to select the mechanism provided by the operating system (ucontext on UNIX, Windows Fibers on Windows) or a faster implementation provided by this library (fcontext using assembler). --------------------------------------------------- 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? Have a good review, Vicente Review Manager

1 0

GSOC 2011: idea
by Xu Sun 27 Mar '11

27 Mar '11

Hi there, I have been working on the component detection problems for one year and Boost helps me a lot on my research. However, I found there is no implementation about doing component problems in Boost. Is it possible to get a chance to implement this idea in the summer ? Since I have been working on this problem for a time and I have my own codes to do it both in C++ and Java. So the time may not be a problem for modifying my codes and embedding it into Boost. Thanks, Xu

2 1

GSoC'11 [Own Idea] -Mentor Needed
by Sitesh Shrivastava 27 Mar '11

27 Mar '11

Hello Everyone!, I am a Junior Undergraduate at BIT Mesra, one of the premier institutes in the field of Engineering and Sciences in India, pursuing Computer Science & Engineering. I am looking forward for a challenging project as a part of GSOC '11 under Boost Organisation during summers. I would like to put forward my own idea for a Library which is: - Templatized General Purpose Tree based data structures and algorithms for them The idea is to provide template based containers which will provide general purpose tree containers as there are for Stack, Queue and few others in the Standard Template Library. As of now, I would like to propose the library to consist of 5 containers which includes: 1. Binary Search Trees 2. Red-Black Trees 3. B-Trees 4. Binomial Heaps 5. Fibonacci Heaps Now, these containers will provide the used a generic container set as they are used along with their common operations like Insertion, Deletion, Search etc. Also, they will provide the user with specific operations for each type of container like, Decreasing key of a node in Fibonacci Heaps, Rotation in Red-Black Trees etc. [PS: Any Additions as well as Modifications are welcome to be put forward] I am looking forward towards Boost Community so that I can find a mentor for this project. I would like to discuss more about the details of the above project so that I can contribute to the Boost as well as OSS Community. I would like to mention that I have strong foundations in algorithm intensive programming and have advanced foundations in C/C++ too. I am fully aware of the responsibilities and requirements for this position. To consolidate my knowledge in the fields of interest, I have acquired conceptual knowledge in the fields of algorithms and data structures & have done basic projects in these fields too. If any further information is required, I would be glad to furnish the same. -- Regards, Sitesh Shrivastava Junior Undergraduate, BIT Mesra Phone: +91-9470521313 E-Mail: siteshshrivastava(a)gmail.com Home-Page: https://sites.google.com/site/siteshshrivastava

8 13

[dynamic_bitset] tickets triaging
by Alexey Stukalov 26 Mar '11

26 Mar '11

Dear boost developers, there's a number of untriaged issues related to dynamic_bitset component in boost trac. In particular, there are 2 patches by me addressing the performance of find_first()/find_next(): https://svn.boost.org/trac/boost/ticket/5158 https://svn.boost.org/trac/boost/ticket/5159 Is there a possibility they would be reviewed? Thanks, Alexey

1 0

GUI objects for boost
by farah inamdar 26 Mar '11

26 Mar '11

hi; I would like to discuss my project idea with the boost developer mailing list and mentors. I wold like to work with the UI for box , btn , frame etc etc and this is the way I am going to do it. What ever road map you set for the project idea. -- Warm Regards, Farahnaj......... :-)

2 1

Boost.Polygon edge, polyline and edge set concepts
by farah inamdar 26 Mar '11

26 Mar '11

I am studying in Mtech cs. In my graduation i built software in java which has have most of functions like PowerPoint. So i am confident that i can handle this polygon edge related problem. just give me some guide lines. My Id is farahinamdar(a)gmail.com -- Warm Regards, Farahnaj......... :-)

2 1

[GSOC]Asking for advice
by Faiçal 26 Mar '11

26 Mar '11

I want to participate (for the first time) in GSoC, particularly boost's projects. I first choosed to apply for the "Checks & Hashes" project but I discussed briefly on #boost irc and people here convinced me to take a look on the SIMD Library project. This project seems very challenging, I'll try it despite my poor experience. I start reading about SIMD, I'm currently reading it's wikipedia article and some articles found by google and I download the AltiVec programming interface manual. It would be useful for me if some of you guys give me links for good references articles or documentation about this technology. This post is essentially for introducing myself to your community and asking advice in preparing my application for the project. Thanks.

2 2

Intel compilation
by barend 26 Mar '11

26 Mar '11

Hi, The Boost.Trunk summary now gives for some Intel compilers, since some time: Test output: Sandia-intel-10.1 - geometry - distance / intel-darwin-10.1Rev 70458 / Wed, 23 Mar 2011 01:41:17 +0000 Report Time: Thu, 24 Mar 2011 07:47:34 +0000 Compile [2011-03-23 04:42:50 UTC]: fail "/opt/intel/cce/10.1.024/bin/icpc" -xc++ -w1 -O0 -g -inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 -D__WINT_TYPE__=int -I".." -I"../boost/geometry/extensions/contrib/ttmath" -I"../libs/geometry/test" -c -o "/Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/geometry/test/algorithms/distance.test/intel-darwin-10.1/debug/distance.o" "../libs/geometry/test/algorithms/distance.cpp" ../boost/detail/fenv.hpp(11): catastrophic error: #error directive: This platform does not have a floating point environment #error This platform does not have a floating point environment ^ compilation aborted for ../libs/geometry/test/algorithms/distance.cpp (code 4) Meaning the boolean variable BOOST_NO_FENV_H is not set. Is that compiler-detection broken somehow? It is not on all Intel compilers. Regards, Barend

3 6

Compilation for PGI and ublas
by Barend Gehrels 26 Mar '11

26 Mar '11

hi, The Boost.Trunk regression report gives me for most of the tests, on Sandia-pgi-11.2: catastrophic error: #error directive: Your compiler and/or configuration is unsupported by this verions of uBLAS. Define BOOST_UBLAS_UNSUPPORTED_COMPILER=0 to override this message. Boost 1.32.0 includes uBLAS with support for many older compilers. This message is also reported for all tests in numeric/ublas. We're only slightly dependant on ublas (only in matrix transformations). They are indirectly included in many testfiles but are not really used there. Will I set BOOST_UBLAS_UNSUPPORTED_COMPILER to 0, for the tests? I checked and didn't notice any other library doing that. Regards, Barend

1 0

[Review] XInt Review
by Joel Falcou 26 Mar '11

26 Mar '11

Here is my review for XInt. Currently I think the library should not be included in boost as a lot of problems are, in my opinion, still to be fixed and the design has to be rethought. *********************************************************************** * What is your evaluation of the design? Large integer is a bit like XML and Unicode. Lots of people want to do such a library because it has a high impact of usefulness and, from afar, it doesn't sounds *this* complicated. Alas, it is :/ The premises are OK. We have some large integer type that has proper value semantic and can be used in a variety of operations and functions. So far, so good. The main culprit is that the current library design is rather hardwired to work with a choice of implementation the author thought to be OK at some point but which still have to be proven better than existing solution. The overall design lacks separation between the data and the algorithm that makes the library difficult to extend: what if i want to take an arbitrary range of integers and look at them as a huge series of bits ? What if i don't want the extra memory overhead so i can mmap some files directly into memory (cause reading a 10k bits integer is a no-no) ? Can I pass the integer type to a STD algorithm if I want to iterate over the bytes it contains ? or copy them using boost::range copy ? On the data side, i think being forced to use a given representation is wrong. The Ideal should be that the library provide a fall back implementation but provide adaptor to adapt any kind of data to be looked at as a large integer. The definition of a LargeInteger concept would help defining such an adapting interface and make the library more fluid. For example, what if i want to implement LCM ? * What is your evaluation of the implementation? The implementation is poor for various reasons: - author uses COW for performance reasons. Alas COW has been demonstrated again and again to be of little interest. Looking at the problem 10s (types holding arbitrary large amount of data to be chained in operations without copy) should have lead to an expression template based solution. Capture a whole chain of operations on values, compute the worst case nbr of bits to store, allocate once then compute inside. It prevent spurious allocation and make the algorithms easier to write. Additionally, ET would help detecting expression pattern for which a non naive algorithm could be applied. - virtual inheritance: looking at integer_t shows: class integer_t: virtual public .... Why ? It seems you're trying to implement some policy based design but i cant see why virtual inheritance is used ? Do you get problem not having multiple definition in your mixins ? - There is a lot of unwarranted pass-by-value function prototype which seriously impact performance even with COW. pass-by-ref > pass-by-value + COW. Moreover, the "thread safety" COW is dubious. - the headers are obscenely big. It could be easier to follow the code it there was not this 2k+ line mammoth files. * What is your evaluation of the documentation? The documentation is OK but it is rather hard to navigate as there is real links between sections, forcing me to go back and forth between sections. * What is your evaluation of the potential usefulness of the library? The problem the library tries to solve is a very important one as shown by the large amount of similar project. Having such a library is worthy of inclusion in boost but not in the present form and shape. * Did you try to use the library? With what compiler? Did you have any problems? I tried some examples from the doc on gcc 4.5 with no real 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? I've been doing research and development on scientific computing for 9 years. If the specific problem of large integer is a bit of a fringe domain for me, I have been collaborating on such design in some projects. * Do you think the library should be accepted as a Boost library? No. In its current form, the library *should not* be accepted into Boost. performances claims are not backed up (and other reviewers show it can be far better0 the design lacks of genericity and its implementation is , in my opinion, sub-optimal. To be accepted the following point should be addressed: - use expression template to handle efficient combination of operations and potentially detect optimisable pattern. Proto is a shoe-in for this. - the library entities should be made more generic by providing an extended integer adaptor facility that make one able to substitute a custom integer representation (like having extended_integer<GMP>) for corner case stuff. This adaptor will provide an interface able to turn these types into a type fulfilling the underlying Large Integer concept the library need to handle. Being compatible with GMP should even be a goal and a selling point for the library. - do real benchmarks and compare to existing state of the art solution, at least show benchmarks against GMP on realistic use cases. - the algorithm should be more generic and not be tied to the concrete type of large integer used. Frankly, licensing issues aside, a proto based library able to wrap GMP if needed and with Range based interface could already cover 80% of needs and provides correct speed. Then building on top of that to add new algorithm and new back end representation and adaptors would fill the library in a very smooth way.

13 34