- Boost - lists.preview.boost.org

gsoc project(checks) plain
by Александр 31 Mar '11

31 Mar '11

In case there is a problem with sending zipped files i just list my code here(with no tests or docs,just hpp): #ifndef BOOST_CHECKSUM_HPP #define BOOST_CHECKSUM_HPP #include <boost/cstdint.hpp> #include <vector> namespace boost { typedef boost::uint8_t byte; class checksum { public: checksum(); checksum(const checksum&); checksum(const std::vector<byte>&); void process(); void put_data(const std::vector<byte>&); byte get_sum() const; bool proceeded() const; private: byte sum; std::vector<byte> in_data; bool done; };//boost::checksum inline checksum::checksum() : sum(0), done(false) { } inline checksum::checksum(const boost::checksum &cs) { sum=cs.sum; done=cs.done; in_data=cs.in_data; } inline checksum::checksum(const std::vector<byte> &_in_data) : sum(0), done(false), in_data(_in_data) { } inline void checksum::process() { if (!done) { uint8_t temp_sum=0; for (std::vector<byte>::const_iterator it=in_data.begin();it<in_data.end();it++) temp_sum+=*it; sum=temp_sum; done=true; } } inline void checksum::put_data(const std::vector<byte> &_in_data) { if (in_data!=_in_data) { in_data=_in_data; done=false; } } inline byte checksum::get_sum() const { return sum; } inline bool checksum::proceeded() const { return done; } } //namespace boost #endif // BOOST_CHECKSUM_HPP -- Alexandr mailto:daywalker@mail333.com

1 0

gsoc project
by Александр 31 Mar '11

31 Mar '11

Hello! I am a student from Moscow Institute of Physics and Technology and i wish to participate in Google Summer Of Code project. Boost C++ Libraries development seems really interesting for me, so that's why i decided to ask some questions about details. In the list of ideas there is "Checks & Hashes" project - i had experience in this area, writing a small lib for my university project, but it was mostly like a simple wrapper for RFC implementations of hashing algorithms like MD5 or SHA-1. As i understood this library is got to be something like a collection of different algorithms and it is got to be scalable, right? What are the requirements for me to be able to work on this project? Do i need to write some code for a start? -- Best wishes, Alexandr mailto:daywalker@mail333.com

5 9

[math] Warnings in version 1.46.1
by Richard Hadsell 31 Mar '11

31 Mar '11

I am trying to build the Boost 1.46.1 libraries on a Fedora 7 Linux system with the default g++ 4.1.2. The warnings from the math library produce zillions of lines of output. Each warning has a long description of the instantiation and then concludes with a couple of lines like this: ./boost/math/special_functions/binomial.hpp:65: instantiated from here ./boost/mpl/assert.hpp:79: warning: lowering visibility of 'int mpl_::assertion_failed(typename mpl_::assert<C>::type) [with bool C = false]' to match its type Is this problem known? I hope it doesn't continue in future releases. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

3 13

[submission] STL-compliant containers with copy-on-write
by Alexandr Sterligov 31 Mar '11

31 Mar '11

Is there any interest in a library of STL-compliant containers (vector, deque, map, set, list) with copy-on-write? -- Best regards, Alexander Sterligov

3 2

Problem with debug Boost, Mac OS X and g++ 4.6
by John Wiegley 31 Mar '11

31 Mar '11

I'm not sure yet whether this is a Boost issue, or a g++ 4.6 issue. I've compiled Boost 1.46.1 on Mac OS X using g++ 4.6 and these build options: sh bootstrap.sh && ./bjam debug \ --toolset=darwin --build-type=complete --layout=versioned \ define=_GLIBCXX_FULLY_DYNAMIC_STRING=1 define=_GLIBCXX_DEBUG=1 \ install Then I build and execute the following example code: #include <boost/regex.hpp> #include <string> int main(int argc, char *argv[]) { boost::regex expr("foo.*bar"); return boost::regex_search(std::string(argv[1]), expr) ? 0 : 1; } with this compile/link command: g++-mp-4.6 -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 -D_GLIBCXX_DEBUG=1 \ -g -o regex regex.cc -lboost_regex-xgcc46-d-1_46_1 and the result is: terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast This is happening in boost::re_detail::cpp_regex_traits_base<char>::imbue, on line cpp_regex_traits.hpp:218. The same everything, using g++ 4.5, works fine, so maybe this is a g++ 4.6 bug? I seem to recall having seen this problem before, due to mismatching a debug Boost with a non-debug client app, or something similar. But I've have verified that my client app is using the same flags that I build Boost with. Has anyone run into this? Do I need to take this bug to the g++ folks? Any pointers, ideas? Thanks, John

4 6

Re: [boost] Algebraic abstractions related to (big) integers in C++
by Brent Spillner 31 Mar '11

31 Mar '11

On 3/29/11 21:57 Thomas Klimpel wrote: >So there exists an int value for which the assertion "assert(std::abs(i) >= 0);" fails. But when you convert the result of std::abs to unsigned, you get at least the correct >value. Shouldn't that be another theoretical win for the 2's complement representation? I would say that the problem here is really that std::abs(int) returns another value of type int even though its range is logically unsigned. If you'd used printf("%u", std::abs(i)) instead of std::cout you would have seen the expected result. There's a certainly a tradeoff here--- if std::abs() is defined to return an unsigned value then it requires an explicit cast to be safely mixed with signed integers in many expressions, but if it's defined to return a signed value then its result requires a cast before being printed or converted to a float (at least when the argument to abs() is unconstrained.) I think the latter was the more pragmatic choice (note also that it can always be safely mixed into /unsigned/ integer expressions.) On 3/29/2011 14:06 Lucanus Simonson wrote: >I've heard this rationale before. He is serious. Promoting 32 bit unsigned to 32 bit signed, for example, could overflow, so is clearly not safe. Promoting signed to >unsigned is just as bad, of course, but it won't overflow. Again, pragmatic. There's a *lot* of code that uses signed variables in contexts where an unsigned would do, and overflow normally occurs much more frequently than the corner cases where 'abs(x) == x' is not an identity for 'x >= 0'. From a certain software engineering perspective overflow can be more easily detectable and is thus preferable to logic bugs, but I'd imagine that unintended integer promotions are negligible in comparison to other sources of software defects. Like many things in C/C++, the tools to avoid a problem (explicit casting) are there, but it's up to you to recognize when and how to use them. >I'd like a compiler warning for all auto promotion of signed to unsigned so that I can inspect the line and see if I think it is safe. If it happens when you didn't realize it -Wsign-conversion and -Wsign-compare will catch most abuse in GCC, but they generate considerable amounts of noise on many codebases (and nothing but pain for something like the Linux kernel.)

1 0

Re: [boost] [Boost-users] Fwd: [context review] Review starts today, Mars 21st 2011
by Vicente BOTET 30 Mar '11

30 Mar '11

FYI dev list Vicente > Message du 30/03/11 16:44 > De : "Nat Linden" > A : boost-users(a)lists.boost.org > Copie à : > Objet : [Boost-users] Fwd: [context review] Review starts today, Mars 21st 2011 > > From: Vicente BOTET > Date: Tue, Mar 29, 2011 at 7:00 PM > To: boost-users(a)lists.boost.org, boost(a)lists.boost.org > > > As Vladimir said you can post the review to the dev ML and follow up the > > review using some archives as nabble boost dev for example. > > As a non-member, I cannot post to the dev mailing list: my mail was rejected. > > > If you are yet interested in making a review I will accept it on this ML > > exceptionally as the review is almost finished. I will forward to the dev ML. > > > > Waiting for your review, > > Vicente > > Thank you! I appreciate that. > > Eight days ago I sent my review to you and to Oliver personally. > Although Oliver did receive that and subsequent mail messages, the > fact that you are still awaiting my review means that you did not. > > I must ask the Boost Review Wizards to reconsider the dev-list-only > review policy. Since a non-member can't post to the dev list and I > can't reach the Review Manager with personal mail, apparently I have > only two options: > > - post to boost-users and hope for the best > - hop on and off the dev list every time I want to interject a > comment. Frankly that doesn't scale well. > > I append my review and subsequent conversation with Oliver. > Disinterested parties can stop here. > > Forwarded conversation > Subject: [Boost-users] [context review] Review starts today, Mars 21st 2011 > ------------------------ > > ---------- > From: Nat Linden > Date: Tue, Mar 22, 2011 at 10:38 PM > To: Vicente BOTET > Cc: Oliver Kowalke > > > On Sun, Mar 20, 2011 at 8:18 PM, Vicente BOTET wrote: > > > The review of Oliver Kowalke Context library starts today Mars 21st 2011, and will end on Mars 30th. > > > > 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 see that Boost.Fiber is on the review queue, but Boost.Tasklet and > Boost.Task are not yet? > > > 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. > > Thumbs up on introducing a separate library at the Context level of > abstraction. YES, I think the library should be accepted into Boost. > > > 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). > > Note on the alternative implementation: I am not enthused about the > idea of embedding the fcontext decision in source code. I would rather > make that decision externally in the build machinery. > > > --------------------------------------------------- > > > > 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? > > It seems adequate, a thin wrapper around the underlying > implementations. Nonetheless I'm going to suggest a few possible > enhancements. > > void (fn)(void*) and void* vp are very classic-C. While I'm sure there > are those who prefer to work at that level, I'd also want overloads > supporting a templatized nullary callable, like Fiber, plus the > args-for-implicit-bind variant. Hopefully Fiber and other high-level > abstractions implemented on Context could simply leverage Context's > support rather than reimplementing it. Since every library built on > top of Context will want to support those constructs, if that support > can be centralized in Context, it should be. > > One tiny quibble about the order of the parameters in the existing > context() constructor supporting 'context const& nxt': I think of the > function pointer fn and its data pointer vp as a logical pair. It > seems odd to me that the 'nxt' parameter is inserted here: > > context(void (fn)(void*), context const& nxt, void* vp, stack_type && stack); > > instead of here: > > context(void (fn)(void*), void* vp, stack_type && stack, context const& nxt); > > especially considering that 'nxt' controls what happens when 'fn' is done. > > I'm not sure I understand the usefulness of a context object not > currently associated with a stack object, but I realize that > corresponds with a state designed into the underlying machinery, e.g. > ucontext.h. Oh: the initial current context doesn't manage an explicit > stack. Maybe a base class that represents a context with implicit > stack, and a subclass that represents a context with explicit stack? > > (Is the static variable that underlies boost::context::current() thread-local?) > > Fiber-local-storage on Windows: may I suggest a context-local > abstraction for this library, implemented as Fiber-local for the > Windows Fibers implementation and thread-local elsewhere? > > Exceptions: "must not throw exceptions" may be too limiting. It's hard > for a typical coder to guarantee that no underlying code will throw. > Of course you could require that every fn passed to context's > constructor must have an explicit outermost try/catch(...) -- but > that's the sort of boilerplate that's easy to forget. context could > provide a wrapper containing that try/catch(...). In fact, you could > even use Boost.Exception to propagate any such exception to "somewhere > else" -- perhaps a context user's policy decision? Then one such > policy choice could be "I guarantee no underlying code will throw," > for those anxious to avoid the overhead. > > Exception management may feel like a topic best left for a > higher-level abstraction -- but I don't see how that could work. If > the higher-level abstraction is implemented in terms of Context, and > if Context flatly forbids exceptions, how could the higher layer > support them? > > On the other hand, if it *is* reasonable for Context to defer > exception support to a higher level, then the documentation should be > revised to state the requirements for that support. > > But again -- since every library built on Context will want exception > support, if it can be centralized in Context, it should be. > > Maybe there should actually be three layers: platform-dependent > RawContext with the currently-proposed level of support, Context with > platform-independent extensions as suggested above, then > Fiber/Coroutine/Task/whatever above Context? > > What's the use of a stack object representing not-a-stack? Wouldn't > the abstraction be simpler and more robust if every stack object is > guaranteed to represent a valid stack? That would seem to simplify > some of the semantics of Context as well. > > That said -- I'm a bit concerned that the documentation seems to imply > that stacks always grow downwards. Are we really never going to > encounter machines on which the opposite is true? Shouldn't the stack > concept include some support for directionality? > > The stack concept is fairly dense. Would it make any sense to define > an actual stack abstract base class? Because Context is > template-based, an implementation can (and protected_stack should) > avoid that base class -- but it could provide user stack > implementations with a starting point. > > Thumbs up on providing protected_stack rather than a plain memory area. > > > - What is your evaluation of the implementation? > > I briefly looked over impl/context_ucontext.hpp, and it's pretty > clear, more or less what I'd expect. I glanced into > impl/context_fiber.hpp. I didn't review the rest of the > implementation. > > Again, the need to account for a context object that isn't currently > managing a stack feels like clutter. > > The Boost.Coroutines documentation contains a discussion of the > possible unreliability of the GetCurrentFiber() == 0x1E00 trick, and > the value of calling IsThreadAFiber() on systems that support it. I > note some ambivalence in context_fiber.hpp about that. Why is the > IsThreadAFiber() implementation commented out? > > > - What is your evaluation of the documentation? > > At first I was confused about the usefulness of release_stack(). > Here's my guess: although Context documentation doesn't say, Fiber > states: "When a fiber returns from its main function the fiber is said > to be finished and can not be further resumed." By implication, you > can't restart a context object that has finished, either. (Worth > stating in Context documentation.) However, you may want to create > another context object to perform the same work again, in which case > it would make sense to reuse the same stack object. Is that more or > less the rationale? Whether or not I've guessed right, I think we > could use a bit more explanation about your intended use of > release_stack(). > > The Boost.Coroutines documentation notes that you can save the cost of > ConvertThreadToFiber() and ConvertFiberToThread() per round trip by > explicitly calling ConvertThreadToFiber() beforehand. > context_fiber.hpp is implemented the same way; presumably the same > note could be useful. Or are you assuming that all cycle-conscious > users will select the fcontext implementation instead of the Fiber > implementation? > > The page describing the stack concept is a bit confusing: it doesn't > use the term "concept," and it actually references class > protected_stack. Please clarify that "stack" is a concept, whereas > "protected_stack" is an implementation of that concept bundled with > the Context library. > > There's a confusing phrase in the description of stack::address(): > "Function void* address() must return the address where the stack > begins to grow downwards (to lower addresses)" -- so far so good, with > a nod to the note above about stack direction -- "and the stack must > be moveable." > > This seems to say that the Context library might move the block of > memory in which the processor allocates stack frames. But that would > completely invalidate data residing in those stack frames! I *think* > the phrase is intended to mean that any class implementing the stack > concept (the object containing stack pointer and size) must be > moveable. Either way, the intent should be expressed more clearly. > What is that phrase doing attached to the description of > stack::address(), anyway? > > > - What is your evaluation of the potential usefulness of the library? > > C++ should have had standard library support for user-space > context-switching (coroutines, tasks, whatever) a decade or more ago. > As a stepping stone to getting there, Context is enormously valuable. > > > - Did you try to use the library? With what compiler? Did you have any > > problems? > > I hope to have time over the next few days to try using it. I thought > I'd better send these comments, based only on reading the > documentation and a bit of the code, in case I run out of time. > > > - How much effort did you put into your evaluation? A glance? A quick > > reading? In-depth study? > > I read through all the bundled documentation, plus a bit of the code. > > > - Are you knowledgeable about the problem domain? > > Yes. I've been using the (Vault) Boost.Coroutines library in > production code on Windows, Mac and Linux. Because Mac OS X 10.4 > doesn't support ucontext.h, I hacked in an alternate underlying > context-switching implementation for 10.4 based on the GNU Pth > library. (Having the Boost.Context API around, even without a viable > implementation yet, would have been useful for that work.) > > I intend to try replacing that Boost.Coroutines Pth implementation > with a Context implementation. (Those who still care about OS X 10.4 > could then provide a Context implementation based on Pth. However, I > myself no longer care.) If Context is accepted into Boost, It strikes > me that a version of Boost.Coroutines based on Context would be a > useful evolutionary step in the Vault. > > ---------- > From: Oliver Kowalke > Date: Wed, Mar 23, 2011 at 4:07 AM > To: Nat Linden , boost(a)lists.boost.org > > > I see that Boost.Fiber is on the review queue, but Boost.Tasklet and > > Boost.Task are not yet? > > boost.tasklet will be renamed to boost.strand (see my git repo). > because all of those lib require boost.context and hafe to be reqorked > (except boost.fiber) the review wizards requested to remove boost.task > from the review queue. > If boost.context is accepted and in a final state I'll request a > review for the other libs. > > > > 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). > > > > Note on the alternative implementation: I am not enthused about the > > idea of embedding the fcontext decision in source code. I would rather > > make that decision externally in the build machinery. > > I've pulished an alternative version of boost.context - the user can > decide in its code which implemention should be used. > > > void (fn)(void*) and void* vp are very classic-C. While I'm sure there > > are those who prefer to work at that level, I'd also want overloads > > supporting a templatized nullary callable, like Fiber, plus the > > args-for-implicit-bind variant. Hopefully Fiber and other high-level > > abstractions implemented on Context could simply leverage Context's > > support rather than reimplementing it. Since every library built on > > top of Context will want to support those constructs, if that support > > can be centralized in Context, it should be. > > Becuae most of the work is done ins assembler I'd like to keep the > things simple as possible. Supporting templatized ctors + > args-for-implicit-bind variant would make the assembler too much > complicated and thus error prone (different C++ calling conventions on > the platforms etc.). > So I want to stuck with the C-style callback and track boost.context > as a building block for other libs providing higher abstractions. > > > I'm not sure I understand the usefulness of a context object not > > currently associated with a stack object, but I realize that > > corresponds with a state designed into the underlying machinery, e.g. > > ucontext.h. Oh: the initial current context doesn't manage an explicit > > stack. Maybe a base class that represents a context with implicit > > stack, and a subclass that represents a context with explicit stack? > > You have to differentiate between a context created to execute a new > execution context (the ctor accepting funtion, stack etc.) which > manages its own stack (passed as argument) and the context instance > grapping the current execution context (default ctor) which collect > the CPU state but does not manage the current stack because it its > already managedd by the operating system (in the case of > main()-function for instance) or by another context create by its ctor > with protected_stack instance as argument. > > void main() > { > ... > // ctx1 grapps the current CPU state > // but does not manage a stack because the > // current stack belongs to the operating system/process > context ctx1; > > // ctx2 represent a new execution path executing my_fn() > // it manages its own stack > context ctx2( my_fn, 0, protected_stack( 65536) ); > > // now we jump from the curretn execution context ctx1 > // to the new execution context ctx2 which will execute > // function my_fn() > ctx1.jump_to( ctx2); > > // we return from my_fn() == jumped out of execution context ctx2 > // back to ctx1 > ... > } > > ctx1 pin-points (you could have mutliple) a specific point in the > code/execution path. > > > (Is the static variable that underlies boost::context::current() > > thread-local?) > > context has no static variables and no boost::context::current() > (maybe you are using an old version?). > > > Fiber-local-storage on Windows: may I suggest a context-local > > abstraction for this library, implemented as Fiber-local for the > > Windows Fibers implementation and thread-local elsewhere? > > hmm - this what I want to handle in libs with higher abstractions. So > boost.context can be thin as possible. > > > Exceptions: "must not throw exceptions" may be too limiting. It's hard > > for a typical coder to guarantee that no underlying code will throw. > > Of course you could require that every fn passed to context's > > constructor must have an explicit outermost try/catch(...) -- but > > that's the sort of boilerplate that's easy to forget. context could > > provide a wrapper containing that try/catch(...). In fact, you could > > even use Boost.Exception to propagate any such exception to "somewhere > > else" -- perhaps a context user's policy decision? Then one such > > policy choice could be "I guarantee no underlying code will throw," > > for those anxious to avoid the overhead. > > The function which is pased as first argument to the ctor of context > must not throw. The reason is that it is passed to C-functions (== > functions declared as extern "C") and throwing an exception through > C-code results in undefined behaviour. > > > Exception management may feel like a topic best left for a > > higher-level abstraction -- but I don't see how that could work. If > > the higher-level abstraction is implemented in terms of Context, and > > if Context flatly forbids exceptions, how could the higher layer > > support them? > > Exception hamdling should be done by higher abstractions. For instance > using packaged_task/future (as shown in boost.tasklet). > > > On the other hand, if it *is* reasonable for Context to defer > > exception support to a higher level, then the documentation should be > > revised to state the requirements for that support. > > I believe yes. > > > What's the use of a stack object representing not-a-stack? Wouldn't > > the abstraction be simpler and more robust if every stack object is > > guaranteed to represent a valid stack? That would seem to simplify > > some of the semantics of Context as well. > > stack must support move-semantics -> a moved stack must be represented > == not-a-stack. > This is usefull for reducing memory allocation/deallocation for stacks. > boost.tasklet reuses (== moves) stacks from a context which is > finished and caches the stack. If a new context has to created in > moves the recycled stack into the new context. That's trhre reason why > stack must be move-able. > > > That said -- I'm a bit concerned that the documentation seems to imply > > that stacks always grow downwards. Are we really never going to > > encounter machines on which the opposite is true? Shouldn't the stack > > concept include some support for directionality? > > On all platforms I've been working on the stack grows downwards. > > > The stack concept is fairly dense. Would it make any sense to define > > an actual stack abstract base class? Because Context is > > template-based, an implementation can (and protected_stack should) > > avoid that base class -- but it could provide user stack > > implementations with a starting point. > > because the stack is a template argument of context it represents an > implicit interface - so no explicit interface like abstract_stack is > required. The current solution doesn't require stakc to derive from a > base class. > > > Thumbs up on providing protected_stack rather than a plain memory area. > > protected_stack appends a guard page at the end of the stack. This > guard page issues sefault/access violation if you acces the address of > that page. > This is usefull if the size of the stack is too small. Ypou could use > your own stack implementation without such a guard page. But if you > excced the stack range you overwrite in the worst case the memory of > your own application. > > > Again, the need to account for a context object that isn't currently > > managing a stack feels like clutter. > > see above - pin-point of current execution path/context > > > The Boost.Coroutines documentation contains a discussion of the > > possible unreliability of the GetCurrentFiber() == 0x1E00 trick, and > > the value of calling IsThreadAFiber() on systems that support it. I > > note some ambivalence in context_fiber.hpp about that. Why is the > > IsThreadAFiber() implementation commented out? > > That is because of the fact that Windows XP + Sevice Pack 2/3 defines > _WIN32_WINNT >= _WIN32_WINNT_VISTA but doesn't declare > ::IsThreadAFiber(). > I didn't found a way to detect XP + SP 2/3 beside of _WIN32_WINNT. > > > > - What is your evaluation of the documentation? > > > > At first I was confused about the usefulness of release_stack(). > > moves the stack out of the context instance for inspection or recycling > > > The Boost.Coroutines documentation notes that you can save the cost of > > ConvertThreadToFiber() and ConvertFiberToThread() per round trip by > > explicitly calling ConvertThreadToFiber() beforehand. > > context_fiber.hpp is implemented the same way; presumably the same > > note could be useful. Or are you assuming that all cycle-conscious > > users will select the fcontext implementation instead of the Fiber > > implementation? > > Holger Grund has some concerns regarding exception handling in the > assembler implementation of fcontext on Windows. So I've dissabled it > - maybe if I could fix it I'll make it available too. > > > There's a confusing phrase in the description of stack::address(): > > "Function void* address() must return the address where the stack > > begins to grow downwards (to lower addresses)" -- so far so good, with > > a nod to the note above about stack direction -- "and the stack must > > be moveable." > > see my comments above > > > This seems to say that the Context library might move the block of > > memory in which the processor allocates stack frames. But that would > > completely invalidate data residing in those stack frames! I *think* > > the phrase is intended to mean that any class implementing the stack > > concept (the object containing stack pointer and size) must be > > moveable. Either way, the intent should be expressed more clearly. > > What is that phrase doing attached to the description of > > stack::address(), anyway? > > do refere to moving the stack out of a context? then this don for > reusing that memory junk - otherwise the stack get deallocated. > > > I intend to try replacing that Boost.Coroutines Pth implementation > > with a Context implementation. (Those who still care about OS X 10.4 > > could then provide a Context implementation based on Pth. However, I > > myself no longer care.) If Context is accepted into Boost, It strikes > > me that a version of Boost.Coroutines based on Context would be a > > useful evolutionary step in the Vault. > > I'm interessted in porting boost.context to MAC OS X (some first > stepps in Jamfiles -> allow ucontext) - unforutnately I've no box > running MAC OS X. I hope we can work together. > > best regards, > Oliver > -- > > ---------- > From: Nat Linden > Date: Wed, Mar 23, 2011 at 10:22 PM > To: Oliver Kowalke > Cc: boost(a)lists.boost.org, Vicente BOTET > > On Wed, Mar 23, 2011 at 4:07 AM, Oliver Kowalke wrote: > > > I've published an alternative version of boost.context - the user can decide in its code which implementation should be used. > > I saw your mail about that, but I haven't actually compared its > documentation with the review version's. > > Please give an example when it would be useful to have a mixture of > context-switching implementations, selected in source code? Since I > haven't thought of one myself, I'm not convinced it's a good idea. > > >> void (fn)(void*) and void* vp are very classic-C. While I'm sure there > >> are those who prefer to work at that level, I'd also want overloads > >> supporting a templatized nullary callable, like Fiber, plus the > >> args-for-implicit-bind variant. Hopefully Fiber and other high-level > >> abstractions implemented on Context could simply leverage Context's > >> support rather than reimplementing it. Since every library built on > >> top of Context will want to support those constructs, if that support > >> can be centralized in Context, it should be. > > > > Because most of the work is done ins assembler I'd like to keep the things simple as possible. Supporting templatized ctors + args-for-implicit-bind variant would make the assembler too much complicated and thus error prone (different C++ calling conventions on the platforms etc.). > > So I want to stuck with the C-style callback and track boost.context as a building block for other libs providing higher abstractions. > > I certainly wouldn't ask you to try to implement these higher-level > features in assembler. But I don't see why the library couldn't add > C++ header files providing such features wrapped around the (assembler > or native) underlying functionality. > > We will want features such as templatized callables and exception > support in every higher-level library built on top of Context. Must > every such library provide its own redundant, inconsistent > implementation? > > >> Maybe a base class that represents a context with implicit > >> stack, and a subclass that represents a context with explicit stack? > > > > You have to differentiate between a context created to execute a new execution context (the ctor accepting function, stack etc.) which manages its own stack (passed as argument) and the context instance wrapping the current execution context (default ctor) which collect the CPU state but does not manage the current stack because it its already managed by the operating system (in the case of main()-function for instance) or by another context create by its ctor with protected_stack instance as argument. > > > > void main() > > { > > ... > > // ctx1 grapps the current CPU state > > // but does not manage a stack because the > > // current stack belongs to the operating system/process > > context ctx1; > > > > // ctx2 represent a new execution path executing my_fn() > > // it manages its own stack > > context ctx2( my_fn, 0, protected_stack( 65536) ); > > ... > > } > > > > ctx1 pin-points (you could have multiple) a specific point in the code/execution path. > > Fair enough. > > Here are two different objects initialized in different ways, > containing different state. Maybe they should be different classes? > > They share some operations, but other operations are only valid on one > of these object types. Maybe these should be base class and subclass? > > >> (Is the static variable that underlies boost::context::current() > >> thread-local?) > > > > context has no static variables and no boost::context::current() (maybe you are using an old version?). > > I downloaded Context from the vault before the review began, so yes, I > guess that reference to boost::context::current() is obsolete. > > My question about a static variable is based on a mistaken guess. I > assumed that there would be a global pointer referencing the context > object passed to the last successful jump_to() call: the context > object running now. You're saying there is not. I believe I > understand. > > >> Fiber-local-storage on Windows: may I suggest a context-local > >> abstraction for this library, implemented as Fiber-local for the > >> Windows Fibers implementation and thread-local elsewhere? > > > > hmm - this what I want to handle in libs with higher abstractions. So boost.context can be thin as possible. > > Then I'd like to reiterate my suggestion that the library you're > proposing is the bottom level of a three-level library stack: this one > that implements "raw" functionality, a middle layer that implements > higher-level concepts useful to every top-level library, and whichever > top-level library suits the application. > > It bothers me to assume that every top-level library must redundantly > implement these high-level features. > > In terms of packaging, though, I actually think the library we're > calling Context should provide both lower layers. That's because of my > belief that every library implemented on top of Context will want the > high-level features. Put differently, I'm not sure how useful the > bottom layer is without the middle layer. Either way, I agree that we > want to be able to directly access the bottom layer. > > >> On the other hand, if it *is* reasonable for Context to defer > >> exception support to a higher level, then the documentation should be > >> revised to state the requirements for that support. > > > > I believe yes. > > Perhaps you're saying that the same wrapper machinery that handles a > templated callable could provide an outermost try/catch(...). That > wrapper, guaranteed not to throw a C++ exception, will be executed by > the top-level function passed to Context. > > Again, every realistic consumer of Context will need this... > > >> What's the use of a stack object representing not-a-stack? > > > > stack must support move-semantics -> a moved stack must be represented == not-a-stack. > > This is useful for reducing memory allocation/deallocation for stacks. > > boost.tasklet reuses (== moves) stacks from a context which is finished and caches the stack. If a new context has to created in moves the recycled stack into the new context. That's the reason why stack must be move-able. > > Okay, there's a default-constructed stack object which manages no > memory, a stack object managing a memory area which is potentially > useful for a processor stack, and a stack object managing a memory > area actually in use by a processor stack. I'm still unclear on the > usefulness of the first kind, a default-constructed stack object. > > >> Shouldn't the stack > >> concept include some support for directionality? > > > > On all platforms I've been working on the stack grows downwards. > > I'll defer to the community. If any Boost users are targeting machines > with stacks that grow upwards, I'll let them request Context > protected_stack support. > > >> Why is the > >> IsThreadAFiber() implementation commented out? > > > > That is because of the fact that Windows XP + Sevice Pack 2/3 defines _WIN32_WINNT >= _WIN32_WINNT_VISTA but doesn't declare ::IsThreadAFiber(). > > I didn't found a way to detect XP + SP 2/3 beside of _WIN32_WINNT. > > Understood, thanks. I'm rolling my eyes, but not at you. > > >> > - What is your evaluation of the documentation? > > > >> The Boost.Coroutines documentation notes that you can save the cost of > >> ConvertThreadToFiber() and ConvertFiberToThread() per round trip by > >> explicitly calling ConvertThreadToFiber() beforehand. > >> context_fiber.hpp is implemented the same way; presumably the same > >> note could be useful. Or are you assuming that all cycle-conscious > >> users will select the fcontext implementation instead of the Fiber > >> implementation? > > > > Holger Grund has some concerns regarding exception handling in the assembler implementation of fcontext on Windows. So I've disabled it - maybe if I could fix it I'll make it available too. > > Okay, so at present even cycle-conscious Windows users must use the > Fiber implementation. Therefore it does seem worth documenting the > fact that calling ConvertThreadToFiber() on the current thread before > first entry to Context can save a couple implicit > ConvertThreadToFiber() and ConvertFiberToThread() calls per round > trip. > > >> I intend to try replacing that Boost.Coroutines Pth implementation > >> with a Context implementation. > > > > I'm interested in porting boost.context to MAC OS X (some first steps in Jamfiles -> allow ucontext) - unfortunately I've no box running MAC OS X. I hope we can work together. > > Sure! As I said, unless one selects the 10.4u (or earlier) SDK, the > ucontext.h implementation should work. I haven't yet tried to build > the Context library; is the ucontext.h implementation header-only? > > ---------- > From: Oliver Kowalke > Date: Thu, Mar 24, 2011 at 3:06 AM > To: Nat Linden , boost(a)lists.boost.org > > > On Wed, Mar 23, 2011 at 4:07 AM, Oliver Kowalke > > wrote: > > > > > I've published an alternative version of boost.context - the user can > > decide in its code which implementation should be used. > > I think I follow Vicentes suggestion - boost.context provides only one > class (boost::context<>) which preferes fcontext(asm) implementation > if available otherwise ucontext/fiber. > I'll implement a test-app in order to check how this design influences > UNIX signal handling > (hopefully the impact will be only to require not to change the UNIX > signal mask in context<>). > > > I certainly wouldn't ask you to try to implement these higher-level > > features in assembler. But I don't see why the library couldn't add > > C++ header files providing such features wrapped around the (assembler > > or native) underlying functionality. > > It would require to do an additional allocation and it might be that > the higher implementations can do it more efficient/better suitable > for there purposes/not required by some higher libs. > Otherwise those libs would pay for the additional memory allocaton > even if it would not be required. > > > We will want features such as templatized callables and exception > > support in every higher-level library built on top of Context. Must > > every such library provide its own redundant, inconsistent > > implementation? > > The higher libs can implement what they want and how they want. > > > Here are two different objects initialized in different ways, > > containing different state. Maybe they should be different classes? > > I think they should not be different - both do the same (jumping to > other context). The difference is only the one does and the other > doesn't manage a stack - but bot represent an execution context. > > > Perhaps you're saying that the same wrapper machinery that handles a > > templated callable could provide an outermost try/catch(...). That > > wrapper, guaranteed not to throw a C++ exception, will be executed by > > the top-level function passed to Context. > > > > Again, every realistic consumer of Context will need this... > > I can add an additional trampoline function which has a try/catch-all > block and issues an assertion if an exception was thrown. But this > adds an additional indirection! > > > Okay, there's a default-constructed stack object which manages no > > memory, a stack object managing a memory area which is potentially > > useful for a processor stack, and a stack object managing a memory > > area actually in use by a processor stack. I'm still unclear on the > > usefulness of the first kind, a default-constructed stack object. > > The first is required to be able to jump from any position in the code > to the second kind of context (which starts a new execution context). > > > Sure! As I said, unless one selects the 10.4u (or earlier) SDK, the > > ucontext.h implementation should work. I haven't yet tried to build > > the Context library; is the ucontext.h implementation header-only? > > yes > > regards, > Oliver > -- > > ---------- > From: Nat Linden > Date: Thu, Mar 24, 2011 at 8:05 AM > To: Oliver Kowalke > Cc: Vicente BOTET > > On Thu, Mar 24, 2011 at 3:06 AM, Oliver Kowalke wrote: > > >> I certainly wouldn't ask you to try to implement these higher-level > >> features in assembler. But I don't see why the library couldn't add > >> C++ header files providing such features wrapped around the (assembler > >> or native) underlying functionality. > > > > It would require to do an additional allocation and it might be that the higher implementations can do it more efficient/better suitable for there purposes/not required by some higher libs. > > With a centralized implementation of high-level features, if someone > figures out how to make it more efficient, every consumer benefits. > > > Otherwise those libs would pay for the additional memory allocation even if it would not be required. > > I disagree. You need only continue to support the classic-C-style > (void (*function_ptr)(void*), void* data_ptr) pair as an alternative > to the templatized callable, for example by a different constructor > overload. If a consumer doesn't want to pay for extra > allocation/indirection, that caller can use the (function_ptr, > data_ptr) pair as you presently intend. > > But a consumer library that does want the high-level features can > leverage your central implementation. Everybody wins. > > >> there's a default-constructed stack object which manages no > >> memory, a stack object managing a memory area which is potentially > >> useful for a processor stack, and a stack object managing a memory > >> area actually in use by a processor stack. I'm still unclear on the > >> usefulness of the first kind, a default-constructed stack object. > > > > The first is required to be able to jump from any position in the code to the second kind of context (which starts a new execution context). > > This confuses me. > > I do understand that a default-constructed *context* object is useful > to be able to switch context from any place in the code. > > But I'm now asking about the usefulness of a default-constructed > *stack* object. A default-constructed *context* object is not passed a > stack object. > > If you're saying that a default-constructed context object must > nonetheless store a default-constructed stack object... this starts to > feel like an implementation detail leaking out into the API. > > (This might be another good reason to break out a context object base > class that stores only processor state without also storing a stack > object.) > > Let me suggest an alternative way to manage stacks. > > Consider a raw stack memory area which never moves. It is allocated > and managed by a stack class which either successfully allocates the > requested size, or throws. The stack class object, containing only a > pointer and length and other small state, is moveable; but even when > the stack object moves, the actual memory area used by the processor > stack does not move. This would eliminate the need to track a > "not-a-stack" state: every validly-constructed stack object is a valid > stack. > > Internally, a context object can store a pointer to a stack object, > possibly with std::auto_ptr for ownership transfer. > > I do not believe that the overhead of following a pointer would exceed > the overhead of having to check for a valid stack object on every > access. > > And as I've suggested, if you want to eliminate even that overhead, > break out a context class that always stores a valid stack, with a > separate context class that does not even have a stack data member. > > >> [For Mac OS X,] unless one selects the 10.4u (or earlier) SDK, the > >> ucontext.h implementation should work. I haven't yet tried to build > >> the Context library; is the ucontext.h implementation header-only? > > > > yes > > In that case, what further Context work is needed to support Mac OS X? > > If you're saying that you want to extend the fcontext implementation > for OS X, I'm sorry, I don't know details of how the assembler > implementation should differ on OS X. > > Perhaps you're confident in the existing assembly code, and you simply > want Boost.Build help in running the assembler on Mac. Unfortunately > (my guilty secret), I do not know Boost.Build. I tried using an > earlier version some years ago, but it failed in ways I found utterly > opaque; it was simpler to build Boost sources as part of my > application project. > > ---------- > From: Oliver Kowalke > Date: Thu, Mar 24, 2011 at 8:36 AM > To: Nat Linden > Cc: boost(a)lists.boost.org > > > This confuses me. > > > > I do understand that a default-constructed *context* object is useful > > to be able to switch context from any place in the code. > > > > But I'm now asking about the usefulness of a default-constructed > > *stack* object. A default-constructed *context* object is not passed a > > stack object. > > because og the move-semantics supported by the stack class an default > constructed stack instance means not-a-stack. It doesn't allocates > memory. > > > If you're saying that a default-constructed context object must > > nonetheless store a default-constructed stack object... this starts to > > feel like an implementation detail leaking out into the API. > > It is not leaking - all classes providing move-semantics are used in > this ways. Please look into boost.thread - boost::thread has a default > ctor -> constructs a boost::thread instance that refers to > Not-a-Thread. > > > In that case, what further Context work is needed to support Mac OS X? > > assembler implementation/fcontext - the source code has already an > assembler file for MAC OS X (x86-64/i386). I wasn't able to test the > code because I haven't a MAC OS X installation. > > Oliver > > -- > > ---------- > From: Nat Linden > Date: Thu, Mar 24, 2011 at 11:31 AM > To: Oliver Kowalke > > On Thu, Mar 24, 2011 at 8:36 AM, Oliver Kowalke wrote: > > >> what further Context work is needed to support Mac OS X? > > > > assembler implementation/fcontext - the source code has already an assembler file for MAC OS X (x86-64/i386). I wasn't able to test the code because I haven't a MAC OS X installation. > > Okay, I'll try building it on OS X 10.5 and running your tests. It may > take a little while for me to be able to pay attention to it. > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

[config] Why don't 32-bit and 64-bit Windows DLL's have different names?
by Beman Dawes 30 Mar '11

30 Mar '11

A C++ committee library working group member just asked me why Boost 32-bit and 64-bit Windows DLL's don't have different names. I couldn't remember; could someone please explain? --Beman PS: http://www.boost.org/development/separate_compilation.html is looking a bit dated due to the references to older VC++ versions. Perhaps someone could do a pass through it adding more modern references.

3 3

[context review] Review starts today, Mars 21st 2011
by Vicente BOTET 30 Mar '11

30 Mar '11

Hi all, The review of Oliver Kowalke Context library starts today Mars 21st 2011, and will end on Mars 30th. 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

3 4

Re: [boost] [Boost-users] [context review] Review starts today, Mars 21st 2011
by Vicente BOTET 29 Mar '11

29 Mar '11

> Message du 21/03/11 02:21 > De : "Nat Linden" > A : boost-users(a)lists.boost.org > Copie à : > Objet : Re: [Boost-users] [context review] Review starts today, Mars 21st 2011 > > On Sun, Mar 20, 2011 at 8:18 PM, Vicente BOTET wrote: > > > The review of Oliver Kowalke Context library starts today Mars 21st 2011, and will end on Mars 30th. > > > > 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 > > :-( > > I am not presently on the development mailing list; I am reluctant to > register because keeping up with the boost-users list already takes a > surprising amount of my time. > > I have opinions and a bit of experience with the topic area of this > library, and I was planning to submit a review. But I feel rebuffed. > > Perhaps I could submit a review on this list and have you, the review > manager, helpfully forward it to the development list? Hi Nat, I'm really sorry to miss your post. I should read the Users ML before , but as you can see I'm used to read only the dev ML as you are used to read only the user ML. I think that I should change my habits as Boost.Chrono and Boost.Ratio should be released in the next release :) As Michael has explained it is difficult for the review manager, the author and the other reviewers to follow the review in two ML. I hope you can understand that. As Vladimir said you can post the review to the dev ML and follow up the review using some archives as nabble boost dev for example. If you are yet interested in making a review I will accept it on this ML exceptionally as the review is almost finished. I will forward to the dev ML. Waiting for your review, Vicente

1 0

Google Summer of Code 2011
by Fajrin Azis 29 Mar '11

29 Mar '11

hi My name is Fajrin Azis. I'm an Indonesian. I forgot the date of the discussion time, I thought it's start on 28th, but unfortunately it was 18th. Poor me. That's why I wrote this email, maybe I can still discuss one or two things before I start my proposal. I'm really interested in algorithm, my favorite is dynamic programming. I hope my ability is capable to improvise and optimize Boost library. The problem is I have no clue to start with. My only hope is optimize Boost.graph library, but I don't know which part that I could develop. I have no idea on suggested project. Can you give me a hint? Sorry for my bad english. Regard.

2 1

Re: [boost] Algebraic abstractions related to (big) integers in C++
by Brent Spillner 29 Mar '11

29 Mar '11

On 3/27/11 00:21 Thomas Klimpel wrote: >The goal of this message is to reflect on the two's complement representation of negative integers, from a relatively abstract algebraic perspective. I suspect that practical arguments may resonate more deeply with this list than theoretical ones. Indeed, from a theoretical point of view it's trivial to convert operations on a sign bit + N-1 magnitude bit representation to/from operations on the N-bit 2's complement representation, and in fact there is one value representable in the two's complement representation that is not in the sign/magnitude representation of the same length, which seems like a (very minor) theoretical win for 2's complement. If the operands are the same size (even if that spans multiple machine words), I think 2's complement is clearly preferable to take advantage of the hardware instruction set. With the exception of the overflow flag, addition, subtraction, and the low-order result of a multiplication yield the same bitstring whether the operands (and result) are taken to be 2's complement or unsigned, which means that you can perform arithmetic on lower-order word-size chunks of a large integer without caring whether the highest-order chunk is positive or negative. Might as well take advantage of the instruction-level building blocks for 2's complement representation (with appropriate overflow, carry-in, etc. options) in this case. If you might be adding or subtracting large integers of different length, the sign-magnitude representation is arguably simpler than sign-extending the smaller operand (and potentially propagating carry-outs up to the highest-order chunk of the result.) This then lets you choose to represent negative numbers in the smallest possible number of words without worrying about an arithmetic performance tradeoff. On the other hand, multiword sign-magnitude arithmetic requires two code paths for every operation, with an initial test-and-branch to determine whether all your ADDs should be replaced by SUBs. And given that 2's complement seems preferable for fixed-width arithmetic, I think I'd want a library supporting both fixed- and variable-width representations to adopt the same convention for both. >"What I consider especially strange from an algebraic point of view, is to automatically promote a signed integer type to its corresponding unsigned integer type, when >an arithmetic expression contains both signed and unsigned integer types. Shouldn't it be the other way round? Or wouldn't it be even better, if there would be no >automatic conversion at all? At least from an algebraic point of view, any natural number is also an integer, not vice versa like in C." To be precise, this happens only when the rank of the unsigned type is greater than or equal to that of the signed type. In the case where both operands have non-negative values, this minimizes the risk of overflow during addition or multiplication. When performing an operation on a unsigned value and a signed value (or subtracting a unsigned value from a signed positive value of lesser magnitude), it is incumbent upon the programmer to have some notion of what he or she is doing. I believe the rationale may be that signed values are the default, so if you went out of your way to declare something as unsigned then you're accepting some responsibility for using it appropriately. Note also that (at least in ANSI C) when performing arithmetic between an unsigned value and a signed value of higher rank, the promotion is to the signed type--- so the "promote to the 'larger' type" principle is consistently applied across the board, particularly if you consider unsigned types "larger" than the signed equivalent (seems reasonable to me given how uncommon negative values are in most integer code.)

4 3

[context review] Updated vote
by Giovanni Piero Deretta 29 Mar '11

29 Mar '11

Hi all, There is a lack of reviews so far and the review deadline is getting close; as I really, really would like to see a context switching library into boost in one way or another, I would like to change my vote from a negative to conditional acceptance. These are the conditions: - A C (or low level), light weight API is publicly exposed and documented - Context is made movable, without additional memory allocation for non legacy (i.e. ucontext) implementations. - The documentation is polished and expanded with a discussion on context switching and use cases. I do not think these points are particularly contentious as Oliver has already stated that at least the first two is in his TODO list and that he will make context movable. Of course I would like Oliver to address the other points raised by me and others reviewers. I also encourage Oliver to engage more in discussions with the reviewers; the mail threads just died off after a few replies and not all issues raised were discussed. -- gpd

3 4

[context review] Review ends tomorrow Mars 30st 2011
by Vicente BOTET 29 Mar '11

29 Mar '11

Hi all, The review of Oliver Kowalke Context library ends tomorrow Mars 30th. If you have taken already a look at the library, please make a review even if you can do only a short one. Let me know if you think you need more time to do a deeper review, so I can see with Oliver and the review wizards if we can extend the library. Best regards, 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?

1 0

[GSOC] Thoughts about a metaheuristic library
by Murilo Adriano Vasconcelos 29 Mar '11

29 Mar '11

Hi, I'm thinking about proposing a library of genetic algorithms for this GSOC and wondered what the community thinks about it. The main idea is to provide a in extensible set of classes that a user can easily implement a GA without difficulty. /* Individual with double as fitness fuction type * An individual is a possible solution for the problem * In this case, bit_individual can be a class with boost::array<bool> * and some more information like the fitness function type * and an interface for basic things like sorting the population */ typedef bit_individual<double> individual_d; // Fitness function: evaluates a solution double fitness_func(const individual_d& ind) { double value = 0.0; // calc the fitness of ind return value; } // Fitness evaluator fitness_function fitness(fitness_func); // A population is a set of solutions population<individual_d> pop; // We can for example initialize the poulation with // some size passing a random number generator (rng) initialize_random_population(pop, SIZE, rng); // The tournament selector: chooses T_SIZE elements from population // and selects the one with greater fitness tournament_selector<individual_d> selector(T_SIZE); // roullete_selector<individual_d> ... // This specifies the mutation rate of each bit of each individual bit_mutation<individual_d> mutator(RATE); // Crossover in bit_crossover<individual_d> cross; // 1-point crossover // bit_crossover<individual_d> cross(n) : n-point crossover // When the algorithm will stop: in this case, number of generations generation_continuator<individual_d> continuator(MAX_GEN); // can be fitness_continuator<individual_d> cont(val) : continues until the best fitness is less than val // Genetic Algorithm functor ga<individual_d> algo(selector, cross, CROSS_RATE, mutator, fitness, continuator); // Run the GA taking pop as initial population algo(pop); // Gets the best element from the population individual_d best_element = pop.best_element(); // Prints the fitness of the best element std::cout << best_element.fitness() << std::endl; For this basic example, the user only have to choose the parameters (like selector, crossover, continuator, ...) and provide a fitness function with the problem specific rating for an individual. This library can be extended to cover more metaheuristics and be parallelized with Boost.MPI. Ideas about the design and other thinks are also welcome. Regards, -- Murilo Adriano Vasconcelos http://murilo.wordpress.com

3 3

lexical_cast crashing on solaris
by boostman 29 Mar '11

29 Mar '11

Hi Boost Experts Below is the code that is causing crash on solaris: entity::VecObj getData(const message::Message & msg) { entity::VecObj odfs; util::MyString keyStr; keyStr = _T("Test msg"); for(size_t i=2; msg.hasKey(keyStr) ; ++i) { util::MyString mdfAlias = msg.value(keyStr); entity::VecObj ret = storage::byAlias(mdfAlias); if(ret.size()) odfs.push_back(ret[0]); keyStr = _T("Test msg") + util::convert(util::getString(i)) + _T("]"); } if(!odfs.size()) throw util::Exception(util::ERROR_MDFNOTFOUND, util::ERROR_MDFNOTFOUND_STR); return odfs; } template std::string getString(const T & val) { std::string res(""); try { res = boost::lexical_cast(val); } catch(bad_lexical_cast &) { } return res; } Below is the stack trace corresponding to it. ----------------- lwp# 248 / thread# 248 -------------------- fd5c6d10 waitid (0, 4b5d, fa2faf40, 3) fd5b9a34 waitpid (4b5d, 0, 0, 0, 1c800, fd5f3580) + 60 000c76e4 void handleSignal(int) (b, 35d4, fa2fb208, fd5f4604, fd5f3580, 4b5d) + 114 fd5c5924 __sighndlr (b, 0, fa2fb208, c75d0, 0, 0) + c fd5ba868 call_user_handler (b, 0, 12, 0, fc395000, fa2fb208) + 3b8 fd3df5d4 void std::ios::init(std::streambuf *) (fa2fb738, 0, 45, fab18, 3, fd4e30a8) + a8 fd3dfce0 std::ios::basic_ios #Nvariant 1() (fa2fb738, fd4e52b8, 103408, 0, fd4e30a8, 348) + 44 fd467648 std::stringstream::basic_stringstream(int) (fa2fb6c8, c, 1e4, fa2fb738, fd4e800c, fd4e30a8) + 48 fc929ec8 boost::detail::lexical_stream<std::string,unsigned>::lexical_stream #Nvariant 1() (fa2fb6c8, fcb1d710, 0, fdbfff58, fd0ee26c, fd0ee830) + 10 fc929bd0 __type_0 boost::lexical_cast<std::string,unsigned>(__type_1) (fa2fb7f4, 2, fa2fb7fb, fcbcbd88, 57b5040, 0) + 28 fc925844 std::string util::getString(const __type_0&) (fa2fb89c, fa2fb8b8, 3, 4, 4bac880, fd0ee8f8) + 64 fca9cf00 std::vector<boost::shared_ptr<entity::Entity> >operation::getData(const message::Message&) (fa2fb964, 8195784, 1a86c, 4288d10, 4288d10, 4288d10) + 168 I am wondering how can this crash can happen for a very simple case of converting from unsigned to string using lexical cast. Any help would be highly appreciated. Regards Boostman -- View this message in context: http://boost.2283326.n4.nabble.com/lexical-cast-crashing-on-solaris-tp34137… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Parallel Graph] MPI installation procedure
by Cosimo Calabrese 29 Mar '11

29 Mar '11

Hi to all, I'm searching for a detailed procedure to install MPI (such OpenMPI) under Win32 (WinXP in my case) with Boost, and some sample code to use the parallel graph algorithm. Can someone help me? Thanks, Cosimo Calabrese.

3 8

Help needed for shared_ptr issue on iPad2 (dual core ARM)
by Peter Dimov 28 Mar '11

28 Mar '11

Hi everyone, Ticket #5372: https://svn.boost.org/trac/boost/ticket/5372 says that shared_ptr's ARM spinlock implementation (which uses the swp instruction) doesn't work properly on iPad2 (which has a dual core ARM processor). The sample program in the ticket compares it to a loop using __sync_fetch_and_add, which means that the __sync intrinsics are implemented by the compiler the submitter is using. These didn't work on gcc for ARM when we tested them, but may have been added meanwhile. (I can see some code samples that test for 4.4, but the official docs state that ARM intrinsics are only supported on Linux before 4.6, which was released yesterday.) So, we have two questions; first, why does the swp-based spinlock fail, and second, how can we detect support for __sync intrinsics and use them. Anybody with ARM knowledge and iPad2 development access?

4 10

GSOC LP library for Boost
by Chad Seibert 28 Mar '11

28 Mar '11

Hello, Previously, I mentioned implementing an LP library for Boost. However, there didn't seem to be a consensus on how I should go about it. If we can't agree on a method of attack, then there is no hope for me to get a proposal through the selection committee. So now, I solicit the communities advice on writing a wrapper for lp_solve, an LGPL library that purported to be one of the most stable free LP solvers. Do we care that a dependency is LGPL? I've done my due diligence and there doesn't seem to be a comparable MIT/Boost licensed library. Thanks for your consideration, Chad

4 7

[website] New build script
by Daniel James 28 Mar '11

28 Mar '11

Hi, I've been writing a new script for generating the release notes, the feeds and some other things. I'd like to put it in place on the live site soon, so that I can use it to update the site for the boost build release. It should now be easier for you to regenerate the release notes. You'll need python and quickbook on your path. Then run: python build/build.py update from the root of the beta site (you can actually run the script from anywhere, you just need to get the path to 'build.py' correct). There are some other commands, but they're probably not very interesting. You'll need to commit all the changes this makes. If something goes wrong, just commit the quickbook files, and let me know so that I can investigate. I'll still handle all of this if you wish, but it should be easier for you if you want to. I'll update the instructions on the site soon. Daniel

2 3

Call for Mentors
by Andrew Sutton 28 Mar '11

28 Mar '11

All, If you are planning to or would like to mentor a student project for GSoC this year, please login here http://www.google-melange.com/gsoc/homepage/google/gsoc2011 and a) sign up, update your info from last year etc. b) request to be a mentor for Boost c) or contact me with your linkid and I can invite you. I would have done this sooner, but Google was rolling out a new UI for the web app. It looks a lot nicer, but the timing is not especially good. Andrew

1 0

[context] very brief review
by Phil Endecott 28 Mar '11

28 Mar '11

Dear All, This is a very brief note about the proposed Boost.Context that is not really worthy of being called a "review". My main point is that I am pleased to see this functionality being broken out as a separate library, rather than being hidden as a detail of a higher-level functionality e.g. co-routines. This is something that should be encouraged, and furthermore I think that the weaknesses (e.g. documentation) should be reviewed in the context of the alternative being to hide all of this inside Boost.CoRoutine and not documented at all. I have had a quick look at the ARM assembler implementation. Parameter-passing conventions especially wrt the various FP and vector registers is not something that I know much about. If I were going to use this code somewhere, I would like to see a note in the docs or in the source pointing to the reference documentation that the author used to decide what should and what should not be saved. It seems that the ARM code assembles to only three or four instructions for each function. I would have written that as inline assembler, rather than in a .S file. In my view, after this very brief look, I believe that the library should be accepted. Cheers, Phil.

2 1

re-installing boost openMPI
by luxInteg 28 Mar '11

28 Mar '11

Greetings I am playing with boost on a machine with these:- --amd64 linux, gcc-4.5.2 boost-1_46_1 OpenMPI I have compiled boost-1_46_1. I do not yet have mpi installed and later on after MPI is installed I would like recompile boost with mpi support. I would like to know if there are any problems associated with reinstalling boost over an existing installation sincerely luxInteg

2 1

[phoenix] comma woes
by Steven Watanabe 28 Mar '11

28 Mar '11

AMDG I was going to post a response to Lorenzo's question using phoenix, but I ran into a few issues. The initial version I wrote compiles, but doesn't work. #include <boost/phoenix/core.hpp> #include <boost/phoenix/operator.hpp> #include <iostream> #include <vector> #include <algorithm> int main() { double sum = 0.0; int factor = 10; using namespace boost::phoenix; using namespace boost::phoenix::placeholders; std::vector<double> v(3); v[0] = 1.0; v[1] = 2.0; v[2] = 3.0; std::for_each(v.begin(), v.end(), ( ref(sum) += factor * _1, ref(std::cout) << "Summed: " << ref(sum) << std::endl )); return 0; } This is because the overloaded comma operator is provided by statement.hpp, not operator.hpp as I had erroneously assumed. Can we please make sure that the built-in comma operator can't get silently called? After I added #include <boost/phoenix/statement.hpp>, it still doesn't compile and I have no idea how to make it compile, because it tries to copy std::cout. I'm guessing that the result of the comma operator is being deduced as a non-reference, since the cout part compiles fine by itself. In Christ, Steven Watanabe

3 7

boost build: C/CXX(flags) and if testing howto
by luxInteg 28 Mar '11

28 Mar '11

I am building boost on a linux64-bit amd64 machine with these --gcc-4.5.2, boost-1_46_1 python-2.7.1 I have two questions regarding building boost: a) Is there a way to set options for ${CFLAGS}/${CXXFLAGS} when running sh bootstrap.sh ? b) Is it of any use to test a newly compiled build of boost AND IF SO is there a way to invoke testing the said build with bjam or whatever?

1 0