- Boost - lists.boost.org

Re: [boost] Status of FSM viewer
by Michal Sojka 09 Sep '10

09 Sep '10

Hi Andreas, thanks for the prompt answers. See my comments bellow. On Thu, 09 Sep 2010, Andreas Huber wrote: > > we are looking for a solution to visualize FSMs in our robotic > > applications. Before starting the development of our own tool I'd > > like to ask whether there exists something able to visualize > > Boost.Statecharts FSMs. > > No, as far as I know. > > > I was only able to find the > > following GSOC > > project: > [snip links] > > but in my quick tests it produced only empty figures. I > > believe that > > after some debugging I could make it work. > > Personally I wouldn't bother. IIRC, the project depends on GCC_XML, > the latest release of which is still 0.6, from 2004. There is activity > in source control but I'm not sure it has anything to do with the > tool. > > > My question is whether the development of this tool continues or > > whether there are some other tools. In case of negative answers, do > > you have any suggestions for the development of the new tool? > > Currently, we consider the development of a GCC plugin which will > > generate dot (graphviz) source. > > I don't know anything about GCC plugins, but I guess that is certainly > an option. Personally, I'd also check out clang, which presumably can > provide you with a much more C++-like representation of the parsed > source code. I had also thought about using clang but I was not able to compile even simple FSMs with it. I produced a lot of strange errors. I guess that clang's C++ support is not as mature as of GCC. Do you have more positive experience with clang++? > P.S. If you make your tool public, I'd love to be informed when you > have a first version to check out. Thanks! A student of mine will work on this in his bachelor thesis so the tool will definitely be public. If we have something that works, I'll let you know. Cheers, -Michal

4 3

[iostreams][1.44] file_descriptor constructor deprecated
by Hartmut Kaiser 09 Sep '10

09 Sep '10

Hey, Why has the iostreams::file_descriptor constructor taking a file descriptor (OS handle) being deprecated (BOOST_IOSTREAMS_USE_DEPRECATED)? This seems to be somewhat counter-intuitive to me. Even more as our code depends on this functionality and I see no way to rewrite it in order to accommodate for this change (we're wrapping a pipe handle here). The worst is that defining BOOST_IOSTREAMS_USE_DEPRECATED while compiling our application makes the compilation succeed, but linking fails as this function has not been compiled by default into the iostreams library. Regenerating the boost libraries is not an option for us, as we need to rely on pre-installed libraries most of the time (HPC systems have their own weird rules...). Any ideas? Regards Hartmut --------------- http://boost-spirit.com

2 2

[filesystem][v3] Fixed-size char array constructor
by Richard Hazlewood 09 Sep '10

09 Sep '10

The v3 path has a constructor/converter that takes a fixed-size char array. It uses the size of the array to determine the characters to use in the path. This can have unintended consequences for use cases like the following (common with Windows system calls): namespace bfs = boost::filesystem; bfs::path GetTemporaryPath() { // (Okay, it may be tidier to use allocated char* buffers for // these type of calls, but this approach is not unusual.) char buf[MAX_PATH]; GetTempPath(sizeof(buf) / sizeof(buf[0]), buf); return bfs::path(buf); //return bfs::path(&buf[0]); //work-around } The path that is returned contains all of the MAX_PATH characters, even though the system call does not fill all of these. It appears that the constructor assumes the array is null-terminated because it subtracts one. I presume this is to work with cases such as: char const buf[] = "mypath/myfile"; return bfs::path(buf); However, the null-terminator may not be the last char, as in the case given.

1 0

Status of FSM viewer
by Andreas Huber 09 Sep '10

09 Sep '10

Hi Michal > we are looking for a solution to visualize FSMs in our > robotic > applications. Before starting the development of our own > tool I'd like > to ask whether there exists something able to visualize > Boost.Statecharts FSMs. No, as far as I know. > I was only able to find the > following GSOC > project: [snip links] > but in my quick tests it produced only empty figures. I > believe that > after some debugging I could make it work. Personally I wouldn't bother. IIRC, the project depends on GCC_XML, the latest release of which is still 0.6, from 2004. There is activity in source control but I'm not sure it has anything to do with the tool. > My question is whether the development of this tool > continues or whether > there are some other tools. In case of negative answers, do > you have any > suggestions for the development of the new tool? Currently, > we consider > the development of a GCC plugin which will generate dot > (graphviz) > source. I don't know anything about GCC plugins, but I guess that is certainly an option. Personally, I'd also check out clang, which presumably can provide you with a much more C++-like representation of the parsed source code. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

[graph] dfs depending on VertexList container
by fabien.castan＠free.fr 09 Sep '10

09 Sep '10

Hi, We can't use the easiest syntax of dfs, if we use another container than vecS as VertexList container. boost::depth_first_search( graph, boost::visitor( vis ) ); So the only way is to initialize the colormap ourself and give it to the depth_first_search function. The problem is that the dfs use operator[]. I looked at the code and if I understand correctly, it seems that this operator is only use to init the colormap. Best regards, Fabien Castan

3 3

[graph] out_edges sort
by fabien.castan＠free.fr 09 Sep '10

09 Sep '10

Hi, I would like to visit my graph in a particular order using a dfs visitor. To do this I tried to order the out_edges of each node. I use the std sort function, like this: GraphContainer::out_edge_iterator oe_it, oe_itEnd; boost::tie( oe_it, oe_itEnd ) = boost::out_edges( vd, graph ); std::sort( oe_it, oe_itEnd, OrderEdge<GraphContainer>(graph) ); But it does nothing. It seems that there is an empty operator= on out_edge_descriptor. So, how can I sort the out_edges ? Best regards, Fabien Castan

3 3

What about a Spirit-powered C++ syntax analysis library in Boost?
by Florian Goujeon 08 Sep '10

08 Sep '10

Hi Boosters, I've written a C++ syntax analysis library using Boost.Spirit. (This 'library' is actually a subset of the Scalpel library. I talked about it in the Boost mailing list here: http://article.gmane.org/gmane.comp.lib.boost.devel/208217 ) For the sake of brevity, let's call it Salsa (for Stand-ALone Syntax Analysis). While most C++ compilers need semantic information to perform the syntax analysis, Salsa is a standalone syntax analyzer. Its Spirit grammar doesn't run any semantic action. Consequently, you can use it to parse some C++ code without having to analyze a whole translation unit (i.e. without processing #include directives). At this point, you may wonder how syntax ambiguities are managed. In most cases, there's always an interpretation which is more obvious than the other one(s). In all cases, you may reasonably ask the programmer to disambiguate its code. Whatever the case, Salsa (predictably) chooses one of the interpretations. Here are some examples: The following statement…: a * b; … may be either a multiplication or a pointer declaration. The default interpretation is the pointer declaration. You can reasonably ask the programmer to disambiguate the code by putting parenthesis if he wants the syntax analyzer to interpret it as the former: (a * b); Trickier. In the following declaration…: bool bool_ = a< b || c> (d&& e); … the right-hand side expression may be either a boolean expression (where 'a', 'b', 'c', 'd' and 'e' are variables of type bool) or a function template call (whose name is 'a', which takes one bool template parameter and where 'b', 'c', 'd' and 'e' are all variables of type const bool). The default interpretation is the boolean expression. Once again, you can reasonably ask the programmer to disambiguate the code by putting parenthesis if he wants Salsa to interpret it as the latter: bool bool_ = a< (b || c)> (d&& e); (Actually, I wonder why the standard allows such ambiguities.) Note: Salsa isn't finalized yet, but it successfully parses Apache's implementation of the C++ standard library. I'd like to know: is there a reasonable chance that such a library will be accepted into Boost?

3 2

[preprocessor] missing IS_EMPTY documentation?
by Lorenzo Caminiti 08 Sep '10

08 Sep '10

Hello all, Is there a reason why `BOOST_PP_IS_EMPTY()` is not part of Boost.Preprocessor reference documentation? 1) I think this macro is part of the library public API because it is in <boost/preprocessor/facilities/is_empty.hpp> (outside the "detail/" directory and same location as `BOOST_PP_EMPTY` which is documented). 2) Is it OK to use `PP_IS_EMPTY()` to check if a macro expansion is actually empty or not? For example: #include <boost/preprocessor/facilities/empty.hpp> #include <boost/preprocessor/facilities/is_empty.hpp> #define X /* expand to nothing */ #define Y BOOST_PP_EMPTY #define Z a b c BOOST_PP_EMPTY BOOST_PP_IS_EMPTY(X) // expand to 1 BOOST_PP_IS_EMPTY(Y()) // expand to 1 BOOST_PP_IS_EMPTY(Y) // expand to 0 BOOST_PP_IS_EMPTY(Z()) // expand to 0 Thank you for the clarification. -- Lorenzo

3 5

Status of FSM viewer
by Michal Sojka 08 Sep '10

08 Sep '10

Dear Andreas and others, we are looking for a solution to visualize FSMs in our robotic applications. Before starting the development of our own tool I'd like to ask whether there exists something able to visualize Boost.Statecharts FSMs. I was only able to find the following GSOC project: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… http://www.boost.org/community/gsoc_2006_boost_overview.html#accepted_proje… and its result: http://svn.boost.org/svn/boost/sandbox/SOC/2006/fsm-viewer/trunk/src/ but in my quick tests it produced only empty figures. I believe that after some debugging I could make it work. My question is whether the development of this tool continues or whether there are some other tools. In case of negative answers, do you have any suggestions for the development of the new tool? Currently, we consider the development of a GCC plugin which will generate dot (graphviz) source. Best regards, Michal Sojka

1 0

Adam/Eve DSEL - Re: De Bruijn Bind (alternate bind syntax) Interest?
by Gottlob Frege 08 Sep '10

08 Sep '10

On Tue, Sep 7, 2010 at 1:24 PM, Smith, Jacob N <jacob.n.smith(a)intel.com> wrote: > > For an Adam/Eve DSEL in C++ we used this syntax: > > sheet save_file = > "save_file" == sheet > { > interface == section > { > var{"file_name"} == [](arg_map args){ return any(""); }, > var{"file_type"} == "txt", > (var{"password"} <= (var{"file_type"}, var{"password1"})) == > [](arg_map args) > { > return args.get<string>("file_type") == "txt" ? any("") : args["password1"]; > } > // more constraints > }, > output == section > { > // more constraints > }, > invariant == section > { > // more constraints > } > }; > Interesting. At Adobe we had a DSEL that looked something like (from memory): dialog(name = "Clipping Path") [ column(child_horizontal = align_fill) [ popup(name = "Path:", bind = &path, items = list [ item(name = "None", value = empty), item(name = "Path 1", value = 1), item(name = "Path 2", value = 2) ]), edit_number(name = "Flatness:", digits = 9, bind = &flatness) ], button(name = "OK", dephault = true, bind = &result) ]; Or something like that. Of course we didn't have C++0x at the time. Tony

1 0