- Boost - lists.boost.org

[acc.jam] Update for single/multi-threaded build on HP-UX
by Prashant Thakre 28 Feb '07

28 Feb '07

Hi, I have made some changes to RC_1_34_0/tools/build/v2/tools/acc.jam. With this change single/multi-threaded builds are possible but bjam still defaults to 32-bit binaries even though --address-model=64 is passed as a command line option. Also, this update doesn't require the macro *BOOST_HAS_THREADS* to be defined in boost/config/platform/hpux.hpp Would it be possible for me to specify following flag(s) for toolset *acc* and boost: 1. +Z/+z for position-independent code. 2. +DD64 for 64-bit through address-model=64. This requires the below listed toolset-tag patch. On HP-UX 11.23 for toolset *acc*, libraries are being built without the *acc* toolset-tag. This is due to the missing case statement in local rule toolset-tag {} for *acc* in tools/build/v2/tools/common.jam. Following line should fix this: case acc* : tag += acc ; # line number 691 -- regards, Prashant Thakre

1 0

interest in a "signal flow" library?
by Stjepan Rajko 28 Feb '07

28 Feb '07

Is there any interest in a library which facilitates the implementation and interconnection of objects using Boost.Signals? For example, in a video processing scenario, one might be using the following objects: * frame_rate - generates a void() signal at a consistent frame rate * video_generator - upon receiving a void() signal, produces a signal containing an image (e.g., a frame grabbed from a camera or read from a file) * differencer - upon receiving an image signal, outputs the pixel-difference between the image and the previous image received * flipper - upon receiving an image signal, outputs the horizontally flipped image * analysis - upon receiving an image signal, performs some sort of analysis and outputs a feature vector signal * database - upon receiving a feature vector signal, outputs an image from the database based on some relationship * display1, display2 - upon receiving an image, displays it in a window It would be nice to be able to easily connect these objects via intuitive signal flow "diagrams": // perform the whole video analysis and display the results frame_rate >>= video_generator >>= differencer >>= flipper >>= analysis >>= database >>= display1; // also display the video input video_generator >>= display2; ... or, to specify the entire signal flow in one shot using something like this: frame_rate >>= video_generator >= (differencer >>= flipper >>= analysis >>= database >>= display1) >= display2; Boost.Signals allows us to interconnect the components, and also change the connections as needed(for example, one could skip the flipper if necessary). However, in the absence of an easy connection mechanism such as the one above, one has to use signal::connect(...) for each connection, which can be tedious with a lot of connections, and not as readable. As a starting point, I implemented a little library that provides the above connection syntax (and a little more) - you can find most of it documented as the signal_link class at http://tinyurl.com/2npfcr. The code is attached - I've tested it under both VS.NET2005 and GCC 4.0.1 on OSX/Xcode. It has a little test app with test cases (an included script called g++_it should build it using g++ if you have boost includes and libs on your path). If you find this concept interesting please take a look at the documentation and the code, I'd be most interested to hear your feedback. There are quite a few things still missing (for example, the slot_selector mechanism is not fully integrated with the operators, and it's not possible to disconnect signals in all ways one would want to), so suggestions are more than welcome. In particular: * The current signal_link class provides a default output object. Would it be better to let the descendant class provide its own and supply a reference to signal_link? * I am having problems using signal::disconnect to disconnect equivalent slots (even trying to compile examples from the web documentation). I'm using 1_33_1. Any ideas? * I'm wondering whether the choice of operators (operator(), >>=., >=) used is appropriate or whether there are better alternatives. * Is there a better alternative to the current slot_selector mechanism? Also, please let me know whether you think this would be an interesting addition to Boost. I think the concept might be useful in any situation where the problem can be visualized as a flow of data/signals (e.g., any signal processing application). Regards, Stjepan

4 3

Re: [boost] interest in a "signal flow" library?
by Braddock 28 Feb '07

28 Feb '07

Tue, 27 Feb 2007 11:39:49 -0700, Stjepan Rajko wrote: > The whole mentality of using signals and slots encourages > development of components that are more concerned about the data > than where they are getting the data from I have had a similar revelation working on my similar data flow framework, combined with heavy use of boost::function and boost::bind. I find my programming is now FAR more functionally oriented. Step one of getting anything done is to produce a function that takes x as input and produces y as output. I can then queue that function, schedule that function, trigger that function on a signal, etc, etc. Feels downright lispy...and very powerful. However, adopting a functional style is one thing. But creating a new syntax which constrains you to that style, appears less expressive than the C++ language itself, and will undoubtedly be more difficult to maintain, is an act that requires considerable justification. I would have a legitimate need for your syntax if, for example, the different functions executed in parallel threads, or were queued to specific worker threads, if I could somehow otherwise control and schedule the execution of the invoked functions, or traverse the call graph. This could bring it closer to a "pipes and filters", LabView, or Petri Net design, but all are very different than straight signal wiring of serial processes. > I definitelly agree with you regarding debugging - debugging with > signals can be a bit of a pain :-) -braddock

1 0

[Boost-bugs] [ boost-Bugs-1670451 ] Possible bug in basic_iarchive_impl::reset_object_address
by SourceForge.net 28 Feb '07

28 Feb '07

Bugs item #1670451, was opened at 2007-02-27 17:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1670451&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: serialization Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Robert Ramey (ramey) Summary: Possible bug in basic_iarchive_impl::reset_object_address Initial Comment: In basic_iarchive_impl::reset_object_address (file libs/serialization/src/basic_iarchive.cpp), the loop index i gets incremented twice in each iteration of the second for loop: first in the "for" line, and then at the last line before the end of the loop. This causes some object addresses to not be updated as they should. In turn, this causes problems when serializing pointers to object contained in a map. This seems to be a bug. In some preliminary tests, the problem disappears if I take out the second "i++" (line 297 of version 1.20.2.2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1670451&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

String algorithms library
by Florin Trofin 28 Feb '07

28 Feb '07

Hello, I was looking at the string algo library hoping that I can use it with my own string class and I have some questions: 1. Is the library designed to work with variable length encoding characters (like UTF8, UTF16). The answer seems to be no, but wanted to find for sure. Are there any plans to make these algorithms compatible with this type of sequences? 2. Some algorithms seem to be strangely named and seem to overlap existing functionality in boost. For example split() and find_token() - why not using a boost::tokenizer? I think the library needs to be re-organized. 3. Internationalization support. I am not sure if these algorithms will work properly in all languages. For example to_upper/to_lower. I recall that in some languages, going from uppercase to lowercase (or viceversa) you go from one character to two (and viceversa). These two algorithms make the assumption that the correspondence is one to one. Thanks, Florin.

3 2

[thread] Patch for boost/config/platform/hpux.hpp
by Prashant Thakre 27 Feb '07

27 Feb '07

> Hi, On HP-UX for toolset *acc*(aCC 6.13) Boost.Threads fails to build without the hardcoded *-mt* flag in RC_1_34_0/tools/build/v2/tools/acc.jam for following actions: 1.acc.link bind NEEDLIBS 2.acc.link.dll bind NEEDLIBS 3.acc.compile.c 4.acc.compile.c++ Below mentioned patch defines the macro "BOOST_HAS_THREADS" in boost/config/platform/hpux.hpp for toolset *acc* and does away with the necessity of having to hardcode *-mt* flag. ---------------------------------------------------------------------------- 38a39 > # define BOOST_HAS_THREADS ---------------------------------------------------------------------------- regards, Prashant Thakre

3 5

Re: [boost] interest in a "signal flow" library?
by Stjepan Rajko 27 Feb '07

27 Feb '07

> From: Michael Marcin <mike(a)mikemarcin.com> > > These operator overloads for connecting multiple signals seem too cutesy > and confusing. How often do these long chains of signals get connected > together? I would imagine at most a dozen such chains for a complex > application but maybe I'm wrong. Braddock brings up good points and I > find his imagePipeline function much easier to read (it will also almost > certainly be easier to debug and to mentally assure myself of correctness). In the applications I'm currently working with there really aren't that many chains/pipelines and they really aren't that big (several to about a dozen). The whole signal mechanism involves a little hit on efficiency, so it probably shouldn't be used to connect the smallest components of the code. I found the greatest benefit of this mechanism after getting used to the syntax and developing a few components that used it. It became really easy to prototype applications and whip up new things from existing components in no time. The whole mentality of using signals and slots encourages development of components that are more concerned about the data than where they are getting the data from (and although good C++ practices should probably focus on the same I know that's not always the case at least for me). When you combine this with the ability to easily interconnect components (through simple syntax), it gives nice benefits. I definitelly agree with you regarding debugging - debugging with signals can be a bit of a pain :-) Stjepan

1 0

Re: [boost] interest in a "signal flow" library?
by Stjepan Rajko 27 Feb '07

27 Feb '07

> From: Braddock Gaskill <braddock(a)braddock.com> > A few comments: > > 1) This "signal flow" library sounds very similar to the "pipes and > filters" pattern. If the name invokes that relationship, it might get > more use (if it is up to the semantics of pipes and filters). Thanks for the tip - I'll look into that. > 2) Using functions or functors directly would avoid the need for any > signal_link glue in many cases. The output signal type could be > derived from the return type of the function. This would be clever - it limits the pipeline to signals of a single type, but like you say there are many cases where this is sufficient. I will try to add something that would allow the use of a function/functor as a filter. > I added the intermediate function object, because I know you can get > the result type and signature from it...perhaps you can be clever and > avoid it in most cases. Or at least provide an in-line glue syntax like: I'm already getting return types and args in the templates I wrote, so I can try to swing what you suggest both with and without using boost.function. > This has the benefit that I need no signal_link glue objects, nor does > my functional code require any knowledge of signals, slots, or > signal_links. This would indeed be great. > 3) Rationale? Your example usage seems to be almost equivalent to: > > void imagePipeline() { > Image img = video_generator(); > img = differencer(img); > img = flipper(img); > Vector vec = analysis(img); > database(vec); > display1(img); > } > > Obviously this code is more readable by any C++ programmer and has no > boost dependencies, and could even be called by a signal. So exactly > what is the rationale for signal_flow? > > The rationale could be the ability to dynamically reconfigure > pipelines at runtime. But your example doesn't seem to provide a way > to do this (no "flow traversal" or visitor iteration). > > The rationale could be to dynamically build pipelines at runtime. But > your syntax is primarily for multiple stages at compile-time, and if > you start building your pipeline one at a time you can just use > signal.connect() calls. > > The rationale could be to provide parallelism to a data flow. But > boost::signals doesn't have (yet) the functionality to provide this. > My inspriation for writing this was dynamic building/reconfiguring of pipelines at runtime, and the ease of syntax provided by the library. Using boost.signals directly was a little too cluttered for me when constructing large pipelines. With your tip above (making a filter out of a function by use of return type), the overall syntax becomes even simpler. After a little time using the library, the pipeline syntax became much more readable and configurable for me than the C++ equivalent. Although, that may be because I am also accustomed to graphical component based programming environments (MAX/MSP, LabView, EyesWeb), which make it really easy to connect things via a visual design. Part of my inspiration for signal_link was that I was curious if I could replicate some of that in C++. Thanks for a great discussion! Stjepan

1 0

[datetime] US DST issues
by Jody Hagins 27 Feb '07

27 Feb '07

I understand this topic has been discussed several times, but I am unable to find a clear, authoritative indication as to the current status of the library. Specifically, I use boost 1.33.1, as released. What do I have to do in order to use Boost.DataTime appropriately in light of the new US DST changes? Currently, my list includes applying the RPM update for glibc to all my linux boxes. Do I need to do anything else? Earlier emails made me think that DateTime uses an independent mechanism for applying timezone information. Is this true? Basically, I want to know what changes I need to make to my programs and/or libraries that use Boost.DateTime aside from the glibc update? Thanks!!!

3 6

xml serializer
by Michael A. Eriksen 27 Feb '07

27 Feb '07

Hi, Is it possible to modify the boost xml serializer to parse serialized objects from C#? The only difference I can see is that C# does not include a <count> element in arrays. I don't quite understand why the <count> element is required in boost especially for serializing stl::list and stl::vector.

2 1