gmane.comp.lib.boost.devel

Re: Mixed use of "include" directives with quoted vs.angle-bracketed params, causing havoc

Jonathan Franklin — 2008-09-08T03:10:36

On Sun, Sep 7, 2008 at 6:55 PM, Michael Fawcett gmail.com>wrote: I only use "" in source (.cpp) files for including headers that live in the same directory, in which case I don't qualify the filename w/ a directory prefix. I basically use <> for everything else, qualified w/ the top-most directory prefix (e.g. #include ). Using the directory-qualified includes is especially important in library headers so that the compiler is happy when building the library itself, as well as when building against the library. However, I find that always including in this fashion, even in stand-alone executables, makes it easier to move code into a library later. Using <> by default works well for me because I like to use -I to control include order. I like to specify a single -I for the library, and dont want the CPP to search the current directory first, which is what one of the compilers that I use will do if I use "". And perhaps I'm also a bit superstitious. ;-) Jon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Mixed use of "include" directives with quoted vs.angle-bracketed params, causing havoc

Michael Fawcett — 2008-09-08T00:58:25

I think that means for libraries it makes more sense to use angle brackets. Boost headers don't rely on any such thing as a "current directory", they require the boost path in the include search path, therefore, the semantics (and maybe performance?) favor angle brackets. Thanks for the reference, I didn't have a copy handy at home (only at work). --Michael Fawcett _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Mixed use of "include" directives with quoted vs.angle-bracketed params, causing havoc

Michael Fawcett — 2008-09-08T00:55:03

Ah, now I see the problem. I misunderstood. Indeed. So it sounds like libraries should prefer <>, and the only time "" should be used is in project specific headers (i.e. won't be reused). But then often times project specific code ends up being generalized into a library at a later date, at which point it should be <>, so shouldn't you just always use <> then? --Michael Fawcett _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Mixed use of "include" directives with quotedvs.angle-bracketed params, causing havoc

Michael Fawcett — 2008-09-08T00:51:10

I agree with your opinion, thanks for the info! --Michael Fawcett _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[dataflow][review] Dataflow.Signals and threading - newdocs and examples

Stjepan Rajko — 2008-09-07T21:18:20

Hello, I have added a section on threading to the Dataflow.Signals tutorial: http://tinyurl.com/69subd (my hosting provider appears to be having some intermittent problems today - I apologize to any reviewers impacted by this) This new section summarizes information related to threading, and presents a new example component that uses the Threadpool library by Oliver Kowalke to provide support for asynchronous signals. Here is an excerpt regarding the Threadpool component: The purpose of the component is to make a signal call asynchronous. Instead of the consumer component processing the signal immediately, the signal call will be added to a thread pool and processed later. async_component is a class template, templated on the threadpool type, and the type of the underlying component that will process the asynchronous signal. The three examples provided are: * mixing synchronous and asynchronous signals * assigning priorities to tasks / signals * using asynchronous signals for cyclic networks Thanks to everyone that has participated in the discussion regarding this library so far. I hope this documentation update will provide some additional information on how the library can be used / extended. Stjepan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [review] Dataflow Library

Stjepan Rajko — 2008-09-07T19:25:19

On Sat, Sep 6, 2008 at 4:03 PM, Michael Caisse objectmodelingdesigns.com> wrote: Nice! Out of curiosity, (if you can share) what XML syntax did you use? With one of the dataflow systems I worked on I ended up using something like this: At some point I hope to provide an example that uses XML configuration files to initialize a network, but built on top of the Dataflow Generic Support Layer so that it can be used with any framework with an implemented support layer (in the same way the GUI example does). There are some nice possibilities using Boost.Fusion with reading the parameters from the XML file and providing them type-safely to the constructor of the component. That would be great! Best, Stjepan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: What's up with the trunk test summary?

K. Noel Belcourt — 2008-09-07T19:07:43

Hi Rene, On Sep 7, 2008, at 1:00 PM, Rene Rivera wrote: What can I do on this end to help?

Re: What's up with the trunk test summary?

Rene Rivera — 2008-09-07T19:00:25

We've been trying to bring up an alternate results server and it's not entirely working :-( Hopefully we'll resolve the problem shortly.

Re: [review] Dataflow Library

Stjepan Rajko — 2008-09-07T18:57:21

Thank you for taking the time to join the discussion! I will answer your questions from the standpoint of what the Dataflow.Signals framework / layer offers, since that one is the focus of the review. Dataflow.Signals is intended for component-run, signal-driven processing. By that I mean that the network has no brains whatsoever. It is up to the components to send signals, decide when to propagate signals and when not to, etc. It is possible to have something controlling the network from the outside (e.g., activating a component, inserting some data, grabbing a result), but none of this is done by the framework - it has to be done by the user. Below, I will provide examples of what components you might need (unless I specify that a component is a Dataflow.Signals component, the component would have to be implemented) and how you'd connect them and run the network . Example: // this would be a component that can read a music file. // It provides a member function .send() that will send the // contents of the file via a signal of signature void(const MusicFile &) whole_music_file_reader reader("file.in"); // this would be a filter component that takes as input a music file // and outputs a filtered version music_filter filter; // this component is provided by Dataflow.Signals. It // will store values from incoming signals. signals::storage result; // connect reader >>= filter >>= result; // run once reader.send(); // we have the result - the at<0> member function will access it // (0 because the MusicFile is the 1st parameter of the signature) result.at<0>().play(); You could do this as long as the components could figure out everything locally - but depending on the details this might not be the most suited task for Dataflow.Signals. Here is something you could do: // A Dataflow.Signals component which will run in its own thread, // and generate periodic void() signals signals::timed_generator timer; // A packetised sound source. Each time it receives a void() signal, // it sends a void(const Packet &) signal sound_source source; // Some packet filters. Let's say that the filter will consume // 3 packets before producing 1, and then produce a packet // on each packet received. That is, if it's input packets are // ip1, ip2, ip3, ip4... and its output packets are opa, opb, opc... // the filter would use ip1, ip2, ip3 to produce opa, it would // use ip2, ip3, ip4 to produce opb, etc. packet_filter filter1(some_filter_fn), filter2(some_other_filter_fn); // connect the network connect(timer, source); connect(source, filter1); connect(source, filter2); // set the timer to produce a signal every 20ms timer.enable(0.02); So far so good - the timer will drive the source, which will provide the input to the filters (the filters need to take care of buffering the inputs themselves). But now we get to places where the suitability of Dataflow.Signals breaks down. For example, what about the results of filter1 and filter2? If they each go to separate outputs (call them output1 and output2), no problem: connect(filter1, output1); connect(filter2, output2); but what if they both go to the same output (which combines them in some way)? Then that output needs to be smart about how to handle two inputs. It has to provide two input ports: connect(filter1, ouput.input_port_1()); connect(filter2, ouput.input_port_2()); This is not the problem - the problem is that output will get calls from each of the filters, and have no idea what frames of source data the filtered data corresponds to. It could use a naive strategy where it waits to get both an input from port_1 and an input from port_2, then combine, then repeat, but that is not very robust (what if filter2 was connected a few frames after filter1?). So, we'd need to add some information to the data, which would allow the components to be "smart enough". In this case, we would explicitly need to add something like a frame number to the Packet, and the component would have to figure out what to do with data originating from different frames. Not ideal. If you could put all of the logic into the components, you could do this, but this is where the Dataflow.Signals framework would probably be unsuitable. I started working on a different framework (called Dataflow.Managed), which is an example of a smarter network. In what I have so far, the framework takes care of things like "only invoke a component when its inputs have changed", and figures out the correct order of invocation, but one could similarly extend Dataflow.Managed (or create a new framework) that would allow the user to specify things like "only invoke a component when all it's inputs are ready", or other things that are needed. One could make a Dataflow.Signals network where each component is connected to a clock, so that each component does get control at every clock cycle and does what it wants. But, the user would have to make sure that the order of invocation is correct - and that's why I'd say Dataflow.Signals is not the right tool for a network like this. This is not a problem - the network can be dynamically altered. I hope the above illustrated what the Dataflow.Signals layer is suitable or unsuitable for. Ideally, the Dataflow library as a whole will evolve to a point where it can accommodate frameworks that can handle all of the above appropriately - then it will be a matter of providing implementations of frameworks that function in the appropriate way (or writing support layers for frameworks that already do). Thanks! Kind regards, Stjepan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

What's up with the trunk test summary?

Emil Dotchevski — 2008-09-07T18:39:26

This link doesn't quite work for me: http://beta.boost.org/development/tests/trunk/developer/summary.html Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Mixed use of "include" directives with quoted vs.angle-bracketed params, causing havoc

Rene Rivera — 2008-09-07T18:21:34

You can't change the in any way the implementation defined aspect of ("") includes that differs from the (<>) includes. For example some compilers let you specify to treat ("") the same as (<>). Or to specify the ("") searched path independent of the (<>) searched paths. In the case of my use case I needed a way to remove "searching relative to the including file directory" aspect of ("") includes. This is because the library includes headers as (include "a.h") which *never* gets around to searching extra include paths I specify because it always finds the one in the including dir first. All of them. Or rather msvc6, msvc7, msvc8, and msvc9. Although I've used msvc1 long ago, I don't remember if it had the same "limitation" ;-) You misunderstood. Specifying the search paths works. But removing the local including dir from the search path is impossible. That would be because AFAIK all Boost headers start with "boost/..." and don't reference local includes. But moving to preferring ("") will likely encourage library authors to rely on what is essentially non-portable compiler behavior. The use of (<>) includes is technically also non-portable but is currently universally portable or can be made that way.

Re: Mixed use of "include" directives with quotedvs.angle-bracketed params, causing havoc

John Maddock — 2008-09-07T17:42:10

No, while this is all implementation defined, on every compiler I've used <> will always search paths supplied with -I directives before system paths. One could argue that "" is less efficient because it *may* search paths relative to the current file before looking at -I paths. But frankly any argument on efficiency grounds is likely to be fallacious: all strictly IMO of course! John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Mixed use of "include" directives with quoted vs.angle-bracketed params, causing havoc

Victor V. Terber — 2008-09-07T16:37:11

> Now, isn't there a slight performance and semantic difference? Semantic difference: With quotes you search an implementation defined path first, only then search the (also implementation-defined) paths you would have searched with angled bracket. > performance Not generally predictable, as it depends where the files are actually placed. But the maximum number of places to look at is guaranteed to be equal or less with angled brackets than with quotes. > Doesn't <> mean search compiler dependent search path for file, then > search user supplied paths in order supplied, and "" means search > user supplied path in order supplied, then fall back to compiler > dependent path? No, that is not guaranteed. It's wholly implementation-defined (according to the standard, paragraph 16.2.3). That may (or may not) involve e.g. concepts like "current directory", "any directories in the call graph" etc. As it says: "implementation-defined". For MSVS22005 see http://msdn.microsoft.com/en-us/library/36k2cdd4(VS.80).aspx. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [threadpool] determining whether a Threadpool type usesa priority/attribute

Stjepan Rajko — 2008-09-07T16:16:47

Thank you - the added metafunctions worked great. Stjepan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Mixed use of "include" directives with quoted vs.angle-bracketed params, causing havoc

Michael Fawcett — 2008-09-07T16:11:33

What exactly do you mean zero control? What kind of control are you looking for? Order of searched include paths? I think I understand what you are describing, which version? Order of include paths works just fine with their compilers for me since 2003 unless I am misunderstanding you. I frequently simply put a patched directory of boost above my main boost install and it always picks up the patched header files first. Now, isn't there a slight performance and semantic difference that should lead to using "" and not <>? Doesn't <> mean search compiler dependent search path for file, then search user supplied paths in order supplied, and "" means search user supplied path in order supplied, then fall back to compiler dependent path? If so, "" should clearly win. --Michael Fawcett _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Mixed use of "include" directives with quoted vs.angle-bracketed params, causing havoc

John Maddock — 2008-09-07T16:06:53

I believe it was GCC. John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [review] Dataflow Library

Paul Baxter — 2008-09-07T15:43:16

I've been lurking and have faced many of these problems both in VHDL and more recently in designing multi-processor pluggable signal processors in software that go even further than dataflow with their dynamic reconfigurability. I've found the separate concept of a wire to be useful in some situations (separating data distribution from the processing) particularly where flows can be 'one to many' either as copies or read only, where in-place data operations provide performance benefits and where persistence of the data (even if just short term) is usefully managed by some form of controller. Typically these all involve multiple threads so simple assumptions about data availability cannot be made. That said, when I've not needed it, the software complexity of having explicit wires over something implicit in the linking of components is an overhead. I really like the dataflow work and am watching with interest, but ongoing changes in my circumstances mean I can't do a full review or participate more fully. I would be interested in what the use cases are that dataflow is tackling. e.g. which of: 1) 'Single shot' data flow - all components run once. Typically the data being passed is pre-sized such that the size of the block on inputs gives rise to the answer on the output. e.g. Take the whole music file and then filter it all in one hit to give one answer 2) Packetised data flow (components laid out once and then operating on data packets) with explicit packet aggregation by components and having 'do_processing' events driven by the availability of a packet from its inputs. A component may consume three input packets and deliver one. e.g. Process music in 20ms lumps e.g. using FFTs for filtering 3) Streaming use cases (components laid out once and then operating on data streams). Each component called at a sample rate but perhaps only processing or packaging a 'packet' 1 out of every N calls or when all inputs have provided enough data to satisfy a block algorithm) e.g. do continuous processing at front end FIR filters, but explicitly decimate and manage a slower processing rate in the back end of the processing. This one is akin to much hardware I've designed where one may have clock domains and manage data events separate from processing events. In some places one can do processing every clock cycle, other places things are more complex. 4) Not only are data events managed, but the processing flow itself may be dynamically altered - e.g. music contains some vocals so I'll add a flow through a 'remove vocals' process (normally don't bother) or perhaps other dynamic constraints from user interaction will dynamically alter the flows being used and there are sufficient permutations not to pre-allocate a full network with switched decision points. Which of the above is dataflow suited to? Thanks to all who have provided various interesting links. To add to that list... I found the descriptions and tutorials accompanying the product Gedae (www.gedae.com) to nicely decouple and present many of the concepts familiar to hardware designers that a software based dataflow library may also want to consider. I also found the research and development pages at insomniac games provide another useful perspective where they manage both data and component instantiation and flow on the parallel cores of the playstation 3. http://www.insomniacgames.com/tech/techpage.php . While they largely deal with implementation issues with their SPU shaders and Dynamic component system, the focus is making things work in a multi-core system where dataflow also needs awareness of the resources on which to run. Regards and good luck with the review Paul Baxter _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [review] Dataflow Library

David Abrahams — 2008-09-07T15:25:10

on Thu Sep 04 2008, Hervé Brönnimann wrote: Wow, MAX is still around! Pretty cool. I started out in the music software biz.

Re: [threadpool] determining whether a Threadpool type usesa priority/attribute

2008-09-07T15:06:36

Hi Stjepan, I've added an new version of boost-threadpool to the boost-vault. regards, Oliver Am Samstag, 6. September 2008 22:00:53 schrieb Stjepan Rajko: _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [thread_pool]: formal review request

2008-09-07T15:05:42

Hello Ronald, I#ve added a new version of thread_pool to the vault(boost-threadpool.3.tar.gz: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-threadpool.3.tar.gz&directory=Concurrent%20Programming&). Could you please so kind to change the link in the review schedule page? I'm also not able to remove the old version from the vault - I get an HTTP-Error 404? if I click on the red cross! Thanks in advance, Oliver Am Donnerstag, 17. Juli 2008 17:39:23 schrieb Ronald Garcia: _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: lifetime of ranges vs. iterators

Arno Schödl — 2008-09-07T15:02:10

Could you give a specific example? Each bounded_iterator stores the information pertinent to its own operation (predicate, stride length, transform functor, whatever) + its base bounded iterator. The base bounded_iterator stores either two (for forward iterators: current and end) or three (for bidirectional and random_access: begin, current and end) base iterators. The only redundancy that I still see is that you may start with a random_access iterator at the base, but somewhere in the stack the traversal category is weakened to forward. Or the user of the iterator only uses forward traversal, although the iterator type would also support bidirectional traversal. Then the base bounded_iterator stores a begin that is never used. I am not sure this is worth optimizing for, but you could put the desired traversal category into the bounded_iterator template interface: bounded_iterator< I, traversal_category > bounded_iterator< char*, forward_traversal > would then be a forward bounded_iterator running on char*, of size 2x sizeof(char*). It only stores current char* and end char*, instead of begin char*, current char* and end char*. Arno -- Dr. Arno Schoedl · aschoedl< at >think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost