- Boost - lists.boost.org

[1.48.0] Status?
by Beman Dawes 15 Nov '11

15 Nov '11

Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now. There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC: accumulators (most or all compilers) assign flyweight (most or all compilers) graph ublas pool (all Windows compilers) ptr_container (most or all compilers) python spirit/repository (most or all compilers) tr1 (most or all compilers) wave (all Windows compilers) See http://beta.boost.org/development/tests/release/developer/summary.html Do we really want to release with this many failures? Worried, --Beman

12 33

[property_tree] Assign and Lua parser
by Renato Florentino Garcia 15 Nov '11

15 Nov '11

In my use of Boost Property Tree library I have coded some extensions, which are in a GitHub repository (http://github.com/renatoGarcia/boost-extensions) I would like to know if there are any interest in make any of then part of Boost Property Tree itself, probably after a suggest improvement. The more useful in my view is a Boost Assign Property Tree alike. Code: http://github.com/renatoGarcia/boost-extensions/blob/master/property_tree/i… For instance, to build in C++ code a ptree like: key1 value1 key2 { key3 12345 { key4 "value4 with spaces" } key5 value5 "" 10 "" 11 "" 12 } Instead the current: ptree pt; pt.add("key1", "value1"); ptree tmpPt1; tmpPt1.add("key3", 12345); ptree tmpPt2; tmpPt2.add("key4", "value4 with spaces"); tmpPt1.push_back(std::make_pair("", tmpPt2)); tmpPt1.add("key5", "value5"); ptree tmpPt3; tmpPt3.put_value(10); tmpPt1.push_back(std::make_pair("", tmpPt3)); ptree tmpPt4; tmpPt4.put_value(11); tmpPt1.push_back(std::make_pair("", tmpPt4)); ptree tmpPt5; tmpPt5.put_value(12); tmpPt1.push_back(std::make_pair("", tmpPt5)); pt.add_child("key2", tmpPt1); Would be a code like: ptree pt = tree() ("key1", "value1") ("key2", tree() ("key3", 12345) (tree() ("key4", "value4 with spaces")) ("key5", "value5") (10)(11)(12)); Another extension is a Lua parser, like the XML or JSON. But in this case I don't think that is desirable include it in the Boost, because of the needed of Lua libraries (at least not in a mandatory way). Code: http://github.com/renatoGarcia/boost-extensions/blob/master/property_tree/i… Regards, Renato Garcia

2 1

Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

Hi Lorenzo, I would like to provide some comments on Boost.Local. > Please state clearly whether you think this library should be accepted > as a Boost library. I am unable to give a yes/no answer. This is mostly because I am not clear who is the intended audience of the library. I explain this in detail below. I am impressed with the library documentation. It is very informative with lots of examples, benchmarks, comparisons, rationale, and layered design (overview, and then details). This is how a Boost library's documentation (and every documentation, IMO) should look like. Yet, one thing that I am missing is what practical problems (that are not already solved) this library is trying to solve. I am not saying that it doesn't solve any. I am just saying I cannot figure it out. A typical story for a Boost library is that there is a common problem that many developers face fairly often, and at some point someone decides to fix this problem comprehensively and ultimately. This is the impression that I had, for example, with Boost.Optional. When I read about it I thought "Yes! This is what I was missing for a long time". I cannot see this in Boost.Local. Perhaps I am not the intended audience of the library, but it would help me if it was clear who the audience is. (I provide examples of what I mean below.) Documentation clearly separates three parts: local functions, local scopes and local exits. Also my impression is different on the three parts. This suggests to me that they could be three separate libraries. What do they have in common? The syntax, I guess. And the fact that you declare them inside functions. But is that enough to bundle them together? Consequently, I divide my comments into three parts. LOCAL FUNCTIONS Why would I want to use it? Personally, I have one compiler that does support local classes as template parameters. All my other compilers support lambdas. So I guess local functions are not for me. So who will use them? Someone that does not have too new compiler (because they have superior - in terms of performance - alternatives: lambdas, local classes). Someone that does not have a too old compiler, because we read in the documentation that "The implementation of this library uses preprocessor and template metaprogramming (as supported by Boost.Preprocessor<http://www.boost.org/doc/libs/release/libs/preprocessor/doc/index.html>and Boost.MPL <http://www.boost.org/doc/libs/release/libs/mpl/doc/index.html>), templates with partial specializations and function pointers (similarly to Boost.Function<http://www.boost.org/doc/libs/release/doc/html/function.html>). As a consequence, this library is fairly demanding on compilers' compliance with the C++03 <http://www.open-std.org/JTC1/SC22/WG21/docs/standards>standard." Further someone who does not mind compile-time and run-time performance overhead. And someone,who prefers the new syntax to creating a functor class non-locally. I am not sure how many users that would be? The documentation mentions proposal N2511<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2511.html>, which says that even though with lambdas and local classes we already have a good tool, we still want to have a normal function syntax for local functions. Boost.LocalFunction does not enable a normal function syntax either, so it is no better an alternative than lambdas or local classes. Except for "const binding" which I find hard to appreciate. And except for compilers that don't support C++11 features, but than again, working only with the new compilers I may not be the right person to review the library. Is this supposed to provide a seamless migration of the code from compilers w/o lambdas to those that do support lambdas? I am not comfortable with the syntax: we first specify parameters, then function body and last, we specify the function name. I am not comfortable that the other Lorenzo's library (that I await impatiently) - Boost.Contract - will provide a different function syntax than Local Functions. This will render the situation where every library will require of me to learn different function declaration syntax. On the other hand, the documentation clearly says why this syntax is necessary, so I am not saying "change the syntax". I am suspicious about the local function overloading. While I can imagine writing a local function; writing a bunch of them inside another function would be likely be some error in my design. LOCAL BLOCKS Again, why would I need them? The example with assertion does not convince me. That is, I face the practical tradeoff: additional enforcement on assertions at the cost of slower build, slower execution time and less readable syntax. I will choose not to use the blocks. The only application that I can think of is a "temporary usage" while refactoring. If I work with the code where functions are 1000-line-long, I would like to divide them into blocks and check which parts reference what variables. In this case, as one of the footnotes in documentation suggests, allowing "return;" inside blocks would be a dangerous thing. But again, if I had a luxury of lambdas, I would choose lambdas for that purpose, because they allow specifying the default binding ( [&], [=] ). It looks like local blocks are only a syntax sugar over local functions. Am I right? LOCAL EXITS While exception specifications for locals blocks seam strange, I find allowing exception specifications for local exits an error. Local exits should be subject to the same restrictions as destructors (they are implemented as destructor calls anyways): you must not throw from them. And I expect the library documentation to say it explicitly. I find this "warning" missing from Boost.ScopeExit. So I suggest to disallow (if possible) specifying exceptions in local exit, and adding a section in documentation that warns against potential throws from an exit. I do not see anything against having two libraries for the same purpose. This is pretty much the same what we already have in Boost in case of state machines. But since we have two, it is useful to ask why I would choose local exit over scope exit. My answer is: 1. Local Exit allows me to specify an empty parameter list (I cannot do it with ScopeExit). - this is a practical problem I faced 2. I can bind to "this". I do not find const binding a practical advantage. Typically for short functions it is hardly a real problem that I confuse = with ==. And exits would typically be one-liners in my code. On the other hand there are reasons why I would prefer ScopeExit to LocalExit: it spells shorter. In LocalExit I have to type word 'bind' for every single parameter even though it is obvious I need to bind them all (because scope guards do not accept normal parameters). The same argument goes for blocks, obviously. I also like ScopeExit's potential to be implemented with lambdas, which might result in performance benefits, and allow the 'default binding'. On the other hand LocalExit cannot be implemented with a lambda, if not for any other reason, then due to the const binding. It is really nice that i can bind to variable of the name 'bind'; although I cannot use type 'bind' in local functions. GENERAL THOUGHTS I am really impressed with the usage of macros. It looks like thanks to Lorenzo we are reaching a new level of preprocessor programming. Who knows how far we can go. I do not think they are overused, given the difficult task. On the other hand, error messages that I encountered give me no clue on what I have typed wrong. Decsriptions in the documentation, and the rationale clearly indicates the very detailed knowledge of many C++ aspects. One suggestion for the future, although I am not sure how useful it would turn out in practice is to have something like local expression, or even not necessarily a local one. This would be a function whose body consists of a single expression. The benefit you get is that the programmer does not need to specify a return type for it (you can use BOOST_TYPEOF for that), or doesn't even have to type keyword 'return', but this may be too much off topic. Term 'C99 <http://www.open-std.org/jtc1/sc22/wg14/www/projects#9899> and later compilers' may be a bit of an overuse for C++ compilers. I suggest 'compilers supporting variadic macros'. Also, in reply to particular review questions: > What is your evaluation of the design? It is clear. Some macros are difficult to read, e.g. Function arguments first, function name second, but I guess this is a necessity given the domain. > What is your evaluation of the implementation? The impressive macro magic is beyond my cognitive capabilities > What is your evaluation of the documentation? It is very good. It meets Boost's and my personal criteria for a good documentation. > What is your evaluation of the potential usefulness of the library? > Are you knowledgeable about the problem domain? This is the part where I have problems. I am not sure about the scope and intended audience of the library. > Did you try to use the library? With what compiler? Did you have any problems? I tried to use the library (basic examples) with VC++8 and VC++10 and Boost 1.42. I found that it does not compile if I use compiler option /ZI (Debug Information Format: Program Database for Edit & Continue) on either compiler. > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent one evening on reading the documentation and playing with the basic examples. For the last remark, I believe that the criterion for accepting or rejecting a library is that if it addresses a real-life problems and if it is well designed. Boost.Local is well designed, but the intended audience and primary motivation is not clearly stated, so I find it hard to assess if the first criterion is met. All in all, Boost.Local is an impressive piece of work. Regards, &rzej

2 1

Determining interest: C++11 parser generator library
by Gene Bushuyev 15 Nov '11

15 Nov '11

Sorry if it turns out to be a duplicate, it looks my original post was lost in cyberspace, so I'm re-posting this request. I'm trying to determine if there is a sufficient interest for including AXE C++11 recursive descent parser generator library in Boost. The zipped sources and documentation are here: http://www.gbresearch.com/axe/axe.zip - Gene Bushuyev

4 7

[program_options] Improving error text in exceptions
by Leo Goodstadt 15 Nov '11

15 Nov '11

As a long time fan of boost::program_options, I would very much like to make the error messages in program_options exceptions more consistent and informative. Exception text is usually aimed at the developer as a diagnostic for rare errors. If the exception needs to be propagated to the end-user, it can be caught, and a more appropriate message substituted. This is not true for program_options: Exceptions from invalid program arguments are the common (and normal) reason for early program termination. It would be nice if, out of the box, exception text could be clear enough to present to the end user more or less as is. This would allow a single try/catch(exception) in main() cerr << "Error: " << e.what() << "\n"; return 1; >From the attached list of error messages, there are many, many different exception types which are thrown. The usual practice of repackaging / reformatting exceptions to be more user-friendly would be tedious or impractical. I grep-ed "boost::throw_exception" to get a list of all the exceptions and messages. I suggested revisions for all but 5. These I have set them aside at the end. I have modelled some of the proposed text on GNU genparse examples (i.e. the behaviour of "ls" and "cat" etc.). These, by dint of their frequent use / hammering by the huge linux user base, are probably good examples of the sort of friendlier clarity I would hope for. In some cases, I have tried to understand the exception text from the code but might have misunderstood the original intent. If this is useful, I shall painstaking go through the code and submit a patch. Leo Goodstadt P.S. I realise there are pitfalls to do with option prefix styles "--" and "/" but the addition of option prefixes to the exception text makes the message a lot clearer. P.P.S. I have kept the current style of starting the text in lower case even though my own preference would be for a capitalised sentence ending in a full stop. ======================================================= Original (CURRENT) and revised (CHANGED) text resulting from exception.what() ======================================================= CURRENT: <ambiguous option option_name> CHANGED: <option '--option_name' is ambiguous and matches options "--aa"," --b" and "--c".> // abbreviated instead of long/short because // length might imply too many/few letters CURRENT: <style disallows parameters for long options> CHANGED: <arguments are not allowed for unabbreviated option names> CURRENT: <style disallows parameters for short options> CHANGED: <arguments are not allowed for abbreviated option names> CURRENT: <style disallows all characters for short options> CHANGED: <abbreviated option names are not valid> CURRENT: <adjacent parameter is empty> CHANGED: <Invalid command line syntax: each option with an equal sign must be followed immediately by its argument.> CURRENT: <parameters adjacent to long options not allowed> CHANGED: <arguments are not allowed for unabbreviated options> CURRENT: <required parameter is missing in 'option_name'> CHANGED: <option '--option_name' requires an argument> CURRENT: <in option 'option_name': invalid option value> CHANGED: <invalid argument for option '--option_name'> CURRENT: <unrecognised line in 'DODGY LINE'> CHANGED: <options configuration file contained an invalid line: 'DODGY LINE'> CURRENT: <multiple occurrences> CHANGED: <option '--option_name' cannot be specified more than once> CURRENT: <can not read file NON_EXISTENT_FILE_NAME> CHANGED: <cannot read options configuration file 'FILE_NAME'> CURRENT: <missing required option required_option> CHANGED: <option '--option_name' is required> CURRENT: <too many positional options> CHANGED: <too many positional arguments have been specified> CURRENT: <unknown option unknown_option> CHANGED: <unrecognised option 'option_name'> CURRENT: <in option 'invalid_option': invalid bool value> CHANGED: <at least one argument is required for option '--option_name> CURRENT: <in option 'option_name': invalid bool value> CHANGED: <invalid argument for option '--option_name'. Valid arguments are 'on|off', 'yes|no', '1|0' and 'true|false'> CURRENT: <in option 'option_name': multiple values not allowed> CHANGED: <option '--option_name' only takes a single argument> Not sure what these mean and have left them alone. libs/program_options/src/parsers.cpp:112: boost::throw_exception(error("long name required for config file")); libs/program_options/src/config_file.cpp:60: boost::throw_exception(error("bad prefixes")); libs/program_options/src/value_semantic.cpp:102: boost::throw_exception(multiple_values()); libs/program_options/src/convert.cpp:66: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/convert.cpp:74: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/value_semantic.cpp:33: boost::throw_exception(std::runtime_error("UTF-8 conversion not supported.")); -- Dr. Leo Goodstadt University of Oxford United Kingdom

2 1

[Serialization] Proposal for TR2
by Ruediger Berlich 15 Nov '11

15 Nov '11

Dear Robert, dear all. from what I understand, Boost.ASIO has been proposed for TR2 quite a while ago. Since I use ASIO and Boost.Serialization quite a bit and feel that both strongly benefit from each other (and not only ASIO -- see e.g. Boost.MPI), are there any efforts to make Boost.Serialization part of TR2 ? We live in the era of cloud computing and networked execution. Without this facility, C++ will have a hard time to compete. And Boost.Serialization is established and mature (thanks, Robert!). Best, Ruediger

3 2

[context] ready
by Oliver Kowalke 14 Nov '11

14 Nov '11

Hi, https://github.com/olk/boost.context.git contains the new version of boost.context (docu at http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html) Any comments are welcome - in the meantime I'm awaiting Giovanni's OK for the mini-review. regards, Oliver

8 15

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011) by Krzysztof Czaiński
by Krzysztof Czainski 14 Nov '11

14 Nov '11

Hello, About me: I write C++ apps and RTS, mostly for embedded devices. I often use complicated C++ structures, and of course boost. Boost.Local caught my interest, so I decided to review it. I intend to try to use this library on MinGW-4.5, and on a Texas Instruments/DSP compiler, however I can't do that this week, so I won't make it until the end of this review. I studied the docs in depth. I state my comments below. Each of my comments is numbered in the style (0), so they can be referenced. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Variable Binding: [quote] programmers might want to bind variables of complex types by (constant) reference instead than by value [/qoute] (1) s/instead than/instead of/ Binding the Object this: [quote] It is also possible to bind the object this when it is in scope (e.g., from an enclosing non-static member function). This is done by using this as the name of the variable to bind in the local function declaration and by using the special symbol this_ (instead of this) to access the object within the local function body. [/qoute] (2) Why not use this_ in both places? Local Blocks: (3) How is a Local Block better then just an ordinary C++ block: {}? So far, I have an idea of what such a Local Block is for, but a reference to a rationale at this point in the tutorial would be nice. Local Exits: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. [16] [/qoute] (4) To me this note requires more explanation. Consider three examples: (4a) [code] int main() { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } // Local exit executed here. [/code] (4b) [code] int main() { try { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } catch ( ... ) {} } // Local exit executed here. [/code] (4c) [code] int main() { try { throw 0; BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END } catch ( ... ) {} } // Local exit executed here. [/code] I which of the abouve examples is printing "hello" guaranteed? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Assigning Local Functions: (5) In the example, variables named "l" (lowercase L) are used, which is easy to confuse with "1" (one), and therefore the example is hard to read. I suggest renaming that variable. Deducing Bound Types (concepts, etc): [qoute] it will also be a reference is the variable is bound by reference [/qoute] (6) typo: is -> if Inlining Local Functions [qoute]On C++03 compliant compilers, inlined local functions always have a run-time comparable to their equivalent implementation that uses local functors (see the Alternatives section). However, inlined local functions have the limitation that they cannot be assigned to other functors (like boost::function) and they cannot be passed as template parameters. [21] On C++11 compilers, inline has no effect because this library will automatically generate code that usesC++11 specific features to inline the local function calls whenever possible even if the local function is not declared inlined (unless the BOOST_LOCAL_CONFIG_COMPLIANT configuration macro is defined). Furthermore, non C++11local functions can always be passes as template parameters even when they are declared inlined.[/quote] (7) I read this paragraph four time, and still don't get it. Please rephrase is somehow ;-) (8) After reading the Introduction, Getting started, Tutorial and Advanced topics I still don't have an overview of the overhead, memory allocations, and exceptions that Local constructs can cause. Please add this information. Right now, I can deduce this information from the Implementation section. However, could things like lack of memory allocations or not emitting exceptions be promised in the public interface? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics). [/quote] (9)What are: the overhead, possible memory allocations, and exceptions, that Local constructs can cause? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [quote]If programmers leave this configuration macro undefined, its default value is to be left not defined.[/qoute] (10) What does it mean "its default value is to be left not defined"? Does it mean, that whether it's defined or not depends on the library, which tries to guess if the compiler supports variadic macros? [quote]If this macro is defined, variadic macros and empty macro parameters are not used by this library. Using variadic macros and empty macro parameters allows this library to provide the variadic macro and empty macro syntaxes which some programmers might find more readable than the sequencing macro syntax (see the Tutorial section, BOOST_LOCAL_FUNCTION_PARAMS, BOOST_LOCAL_BLOCK, and BOOST_LOCAL_EXIT). If this configuration macro is defined then only the sequencing macro syntax is allowed (regardless of whether the compiler supports variadic and empty macros or not).[/quote] (11)This paragraph is a bit unclear: first it says what happens if this macro is defined, then it says why variadic macros are useful, and lastly is says again what happens when this macro is defined. I suggest to make two paragraphs: first: state clearly what this macro does - disables the use of variadic macros, and second: comment on why variadic macros are useful. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/qoute] (12) Notes (4) and (9) apply here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/quote] (13) Note (9) applies here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: (14) What about the typename keyword inside templates? I think i remember from the previous sections, that typename is not required, but that information is missing here. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… Description: [qoute]For example, if the expression type is know (and contains no commas)[/quote] (15) typo: know -> known This concludes my study of the docs, and I won't be able to try to use this library before the end of this review, so I state my conclusions now. 2011/11/10 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> > Please state clearly whether you think this library should be accepted as a > Boost library. > Yes. Other questions you may want to consider: > > - What is your evaluation of the design? > I like it. > - What is your evaluation of the documentation? > I enjoyed reading it, and I think it gave me a pretty good idea about the library. > - What is your evaluation of the implementation? > >From what I read in the Implementation section of the docs, looks reasonable. > - What is your evaluation of the potential usefulness of the library? > I can imagine it would improve readability of some of my code. > - Did you try to use the library? With what compiler? Did you have any > problems? > No. I intend to, but not until the end of this review. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > In-depth study of the docs. > - Are you knowledgeable about the problem domain? > Hmm... I'll just say, I miss something like this for most of my 3-year experience of C++ programming. Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then some) > as Boost.ScopeExit. Does this duplication of functionality need to be > dealt with, and if so, how? I haven't used ScopeExit, so I don't have an opinion on this. - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template? > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > I don't remember missing any of the above in my experience. One of "more readable alternatives" described in the docs have sufficed. Thanks in advance to all who participate in the review discussion; I'm > looking forward to it! > > - Jeffrey Hellrung (Review Manager) > - Gregory Crosswhite (Review Assistant) This was my first review, and I hope it's useful ;-) Regards, Kris

3 3

Need for BOOST_PP_VARIADIC_POP_FRONT
by Gennadiy Rozental 14 Nov '11

14 Nov '11

Hi, I consider using Boost.PP variadic macros support, but I seems to be missing subject macro (with support for zero arguments). Any chance we can one? I'd hate to reinvent the wheel. Regards, Gennadiy

4 16

1.48 is another release without the logger
by Jeff Graham 14 Nov '11

14 Nov '11

Hello, Any progress on the logger?

2 1