[Boost-announce] [metaparse] Review period starts May 25th and ends June 7th
Dear all, The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics. Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write MPLLIBS_REGEX("^[abcd][3-8]\\.foo$") instead of bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos and make the parser built with Metaparse generate the latter expression from the former one. (It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive) Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html). It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf. Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB. An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library): ..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> .... It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1. Metaparse can be downloaded from Github: https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse And a very complete tutorial: http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library: http://abel.web.elte.hu/shell/metashell.html Boost.Msm v3 also implements a new compile-time strings based front-end called eUML2 to demonstrate the power of the library and the conciseness and expressiveness it allows. Please have a look at the documentation: https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/ms... Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. 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? Regards, Christophe Review Manager
On 5/19/2015 5:39 PM, Christophe Henry wrote:
Dear all,
The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics.
Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write
MPLLIBS_REGEX("^[abcd][3-8]\\.foo$")
instead of
bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos
and make the parser built with Metaparse generate the latter expression from the former one.
(It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive)
Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html). It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf.
Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB.
An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library):
..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> ....
It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1.
Metaparse can be downloaded from Github:
https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse
It does not appear to be a git repository but part of a larger git repository called mpllibs. I can clone mpllibs but not just metaparse.
And a very complete tutorial:
http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html
I would like to suggest that since this library is up for review this documentation be part of metaparse itself on github.
The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library:
http://abel.web.elte.hu/shell/metashell.html
Boost.Msm v3 also implements a new compile-time strings based front-end called eUML2 to demonstrate the power of the library and the conciseness and expressiveness it allows. Please have a look at the documentation:
https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/ms...
Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list.
Please always include in your review a vote as to whether the library should be accepted into Boost.
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?
On Tue, May 19, 2015 at 7:43 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 5/19/2015 5:39 PM, Christophe Henry wrote:
Metaparse can be downloaded from Github:
https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse
It does not appear to be a git repository but part of a larger git repository called mpllibs. I can clone mpllibs but not just metaparse.
Which if the library gets accepted will be a problem.. As there will no git repo to transfer ownership of. The library will have to be extracted / and or just source copied. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Metaparse can be downloaded from Github:
https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse
It does not appear to be a git repository but part of a larger git repository called mpllibs. I can clone mpllibs but not just metaparse.
Which if the library gets accepted will be a problem.. As there will no git repo to transfer ownership of. The library will have to be extracted / and or just source copied.
this can easily be achieved via "git filter-branch --subdirectory-filter" ...
On May 20, 2015, at 2:00 AM, Tim Blechmann <tim@klingt.org> wrote:
Which if the library gets accepted will be a problem.. As there will no git repo to transfer ownership of. The library will have to be extracted / and or just source copied.
this can easily be achieved via "git filter-branch --subdirectory-filter" ...
Or perhaps even more easily with git-subtree. Josh
Hi Rene, On 2015-05-20 03:53, Rene Rivera wrote:
It does not appear to be a git repository but part of a larger git repository called mpllibs. I can clone mpllibs but not just metaparse. Which if the library gets accepted will be a problem.. As there will no git repo to transfer ownership of. The library will have to be extracted / and or just source copied. The Mpllibs respository has the same structure as the old Boost repository. If the library gets accepted, I'll move it to its own repository.
Regards, ��bel
Hi Edward, On 2015-05-20 02:43, Edward Diener wrote:
https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse
It does not appear to be a git repository but part of a larger git repository called mpllibs. I can clone mpllibs but not just metaparse.
Correct. The Mpllibs repository was created with the same directory structure as the (old) Boost repository. Metaparse is one of the libraries there.
And a very complete tutorial:
http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html
I would like to suggest that since this library is up for review this documentation be part of metaparse itself on github.
It is on Github in Markdown (https://github.com/sabel83/mpllibs/tree/master/libs/metaparse/doc) format and is in the same repository (and same branch) as the code. The generated HTML files are uploaded to the ELTE server. Regards, Ábel
On 5/20/2015 1:02 PM, Abel Sinkovics wrote:
Hi Edward,
On 2015-05-20 02:43, Edward Diener wrote:
https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse
It does not appear to be a git repository but part of a larger git repository called mpllibs. I can clone mpllibs but not just metaparse.
Correct. The Mpllibs repository was created with the same directory structure as the (old) Boost repository. Metaparse is one of the libraries there.
And a very complete tutorial:
http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html
I would like to suggest that since this library is up for review this documentation be part of metaparse itself on github.
It is on Github in Markdown (https://github.com/sabel83/mpllibs/tree/master/libs/metaparse/doc) format and is in the same repository (and same branch) as the code. The generated HTML files are uploaded to the ELTE server.
I missed the fact that it uses the old directory structure. Now I see everything.
On 5/19/2015 5:39 PM, Christophe Henry wrote:
Dear all,
The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics.
Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write
MPLLIBS_REGEX("^[abcd][3-8]\\.foo$")
instead of
bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos
and make the parser built with Metaparse generate the latter expression from the former one.
(It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive)
Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html). It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf.
Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB.
An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library):
..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> ....
It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1.
Metaparse can be downloaded from Github:
https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse
And a very complete tutorial:
http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html
In the tutorial it states: "This tutorial is long and therefore you might want to make shorter or longer breaks while reading it. To make it easy for you to stop at a certain point and continue later (or to start in the middle if you are already familiar with the basics) Metaparse has a getting_started directory in the examples. This contains the definitions for each section of this tutorial." There are no examples in Metaparse and there is no getting_started directory.
snipped...
Hi Edward, On 2015-05-20 05:23, Edward Diener wrote:
In the tutorial it states:
"This tutorial is long and therefore you might want to make shorter or longer breaks while reading it. To make it easy for you to stop at a certain point and continue later (or to start in the middle if you are already familiar with the basics) Metaparse has a getting_started directory in the examples. This contains the definitions for each section of this tutorial."
There are no examples in Metaparse and there is no getting_started directory.
Examples are here: https://github.com/sabel83/mpllibs/tree/master/libs/metaparse/example Getting started directory is here: https://github.com/sabel83/mpllibs/tree/master/libs/metaparse/example/gettin... Regards, Ábel
On 19 May 2015 at 23:39, Christophe Henry wrote:
- What is your evaluation of the design?
This isn't my field, so I can't say. It looks clever and useful to those needing such things (I don't).
- What is your evaluation of the implementation?
* Doesn't follow Boost naming conventions (macro names, namespace, directory layout). * Doesn't appear to actually be a standalone library, but some internal sublibrary. * Doesn't use Boost.Build. * Doesn't make use of Appveyor for MSVC per commit testing, if it supports MSVC (I couldn't tell). * I got very confused trying to find his unit testing. The link provided was something like https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse, but no unit testing was obvious. I did a github search, and unit testing appeared at https://github.com/sabel83/mpllibs/tree/master/libs/metaparse/test. Now I am confused, because if I go to: https://github.com/sabel83/mpllibs/tree/master/libs/metaparse ... that does indeed look a bit like a Boost directory layout but missing include and src. Which suggests we were given the wrong link, or Metaparse is split across two very similar looking paths, or something else weird is going on. So, please please just use the Boost directory layout, and make Metaparse a standalone library without all the other stuff. Let me put this more clearly: If it's not up for peer review, it shouldn't be in the git repo. * I don't get why he's using Boost.Test, and then uses BOOST_MPL_ASSERT all over the place? The need for Boost.Test seems redundant? In terms of really standout good things: * I very much like that he has version namespacing. All Boost libraries should do this by default.
- What is your evaluation of the documentation?
* Not in BoostBook. * Missing Design Rationale. * Academic publications shouldn't be on the front page of the docs (maybe an Appendix?). I also dislike the frequency the docs say "go read this paper for the thing you actually want to know". Just tell me what I want to know, don't make me go search a linked paper. * I have absolutely no idea what compilers, or their versions, this works on. I saw a mention of GCC 4.6 working. That's it. * The benchmarking at http://abel.web.elte.hu/mpllibs/metaparse/performance.html doesn't show me more than GCC 4.6, nor a graph showing how performance scales to complexity. I also want to know performance with optimisation enabled, and with precompiled headers enabled. Some mention of how much my binaries might bloat would be useful. Extra brownie points for some compiler memory consumption figures, as this sort of metaprogramming at scale can cause problems for 32 bit systems. In terms of really standout good things: * The tutorial is really great. Lots of baby steps with plenty of explanation each worked example. I only wish I had the time to do this for AFIO.
- What is your evaluation of the potential usefulness of the library?
Not my domain of expertise.
- Did you try to use the library?
No.
- 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?
About an hour reading the docs and the source code.
- Are you knowledgeable about the problem domain?
No, definitely not. My personal recommendation is that you withdraw this library from review immediately, and go turn it first into an actual standalone Boost library complying with Boost naming guidelines in Boost git modular format. Then come back to us. Otherwise you're risking the rejection due to non-quality problems which would be a shame. If you proceed with this review with the library in its current state, then I recommend rejection as this is not a Boost library in its present organisation. Which is a real shame, as the code looks to be of high quality, the quick start, user manual and especially tutorial are fantastic, and if properly named and laid out and not some internal implementation library of a superlibrary, this could be a valuable addition to Boost. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Hi Niall, Thank you for the review. On 2015-05-31 14:01, Niall Douglas wrote: >> - What is your evaluation of the implementation? > * Doesn't follow Boost naming conventions (macro names, namespace, > directory layout). Could you please be more specific about the naming convention issues? The intention was to make the adoption easy (mostly search and replace: mpllibs -> boost, MPLLIBS -> BOOST) in case of acceptance by using the Boost naming convection with a different "master" library name (mpllibs instead of boost). > * Doesn't appear to actually be a standalone library, but some > internal sublibrary. It is part of a library with same structure Boost used to have (It looks like this should have been pointed out in the announcement). This must have caused your confusion about the directory structure (parts that look similar). > * Doesn't use Boost.Build. > > * Doesn't make use of Appveyor for MSVC per commit testing, if it > supports MSVC (I couldn't tell). It does support MSVC (tested with the 2015 beta as well) except for the MPLLIBS_STRING macro. I agree that the documentation could (and should) be updated with compiler support information. > So, please please just use the Boost directory layout, and make > Metaparse a standalone library without all the other stuff. > Let me put this more clearly: If it's not up for peer review, it > shouldn't be in the git repo. I've been working on it as part of Mpllibs. In case it gets accepted, I'll move it to its own repository. > * I don't get why he's using Boost.Test, and then uses > BOOST_MPL_ASSERT all over the place? The need for Boost.Test seems > redundant? I was doing the same thing Mpl was doing when I made it "Boost-like" and I haven't changed it since then. I agree, that Boost.Test does not add value to the compile-time assertions. Removing it should be easy. >> - What is your evaluation of the documentation? > * Missing Design Rationale. Good point, I'll add that. > * Academic publications shouldn't be on the front page of the docs > (maybe an Appendix?). I also dislike the frequency the docs say "go > read this paper for the thing you actually want to know". Just tell > me what I want to know, don't make me go search a linked paper. The list of publications can be moved to a sub-page. Where are the places, where the doc redirects the reader to papers? The only place I'm aware of is the measurements page, where bechmarks (even more recent ones) can be added (see my comment below). > * The benchmarking at > http://abel.web.elte.hu/mpllibs/metaparse/performance.html doesn't > show me more than GCC 4.6, nor a graph showing how performance scales > to complexity. I also want to know performance with optimisation > enabled, and with precompiled headers enabled. Some mention of > how much my binaries might bloat would be useful. Extra brownie > points for some compiler memory consumption figures, as this sort of > metaprogramming at scale can cause problems for 32 bit systems. The most recent measurements and with optimisations enabled/disabled (no precompiled headers) can be found here: http://abel.sinkovics.hu/download.php?fn=2014_dsl.pdf, starting on slide 268. The slides compare multiple DSL embedding approaches, the "Compile-time parsing" one is about Metaparse. I agree, that those benchmarks and other measurements (already done ones from academic papers and probably some newer ones as well) could be added to the library documentation. > My personal recommendation is that you withdraw this library from > review immediately, and go turn it first into an actual standalone > Boost library complying with Boost naming guidelines in Boost git > modular format. Then come back to us. Otherwise you're risking the > rejection due to non-quality problems which would be a shame. I'm happy to fix naming convention-related issues (keeping the Boost/Mpllibs difference) if you point me to them. Moving the code to its own git repository should be straight forward in case of acceptance. > If you proceed with this review with the library in its current > state, then I recommend rejection as this is not a Boost library in > its present organisation. Which is a real shame, as the code looks to > be of high quality, the quick start, user manual and especially > tutorial are fantastic, and if properly named and laid out and not > some internal implementation library of a superlibrary, this could be > a valuable addition to Boost. Regards, Ábel
On 31 May 2015 at 15:03, Abel Sinkovics wrote: > >> - What is your evaluation of the implementation? > > * Doesn't follow Boost naming conventions (macro names, namespace, > > directory layout). > Could you please be more specific about the naming convention issues? > The intention was to make the adoption easy (mostly search and replace: > mpllibs -> boost, MPLLIBS -> BOOST) in case of acceptance by using the > Boost naming convection with a different "master" library name (mpllibs > instead of boost). I get that it's mostly find and replace, apart from the directory layout which will require include paths to be changed. My problem for me, as a reviewer, is that I want to review an as-if finished library, one that could be accepted immediately by the community and immediately enter Boost right now, no additional changes, because that is the ideal that a library submitter is supposed to be aiming for. That's the whole point of the communtiy review - to review Boost libraries. Not libraries which still need to be converted to Boost. > > * Doesn't appear to actually be a standalone library, but some > > internal sublibrary. > It is part of a library with same structure Boost used to have (It looks > like this should have been pointed out in the announcement). This must > have caused your confusion about the directory structure (parts that > look similar). If it's not part of the review, it shouldn't be in the git repo supplied to us. > I'm happy to fix naming convention-related issues (keeping the > Boost/Mpllibs difference) if you point me to them. Moving the code to > its own git repository should be straight forward in case of acceptance. I'm sorry, but I cannot vote in favour of a library not in a final form. Yours is a fine library, you've clearly put a ton of work into it, and the whole thing smells of polish and attention to detail, even maturity. But I would like to give an immediate acceptance vote for any library I review. I don't like recommending conditional acceptance. Yours I cannot even recommend conditional acceptance to in its present form because its present form bears no resemblence to a Boost library. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Hi Niall, On 2015-05-31 15:36, Niall Douglas wrote:
On 31 May 2015 at 15:03, Abel Sinkovics wrote:
I get that it's mostly find and replace, apart from the directory layout which will require include paths to be changed.
My problem for me, as a reviewer, is that I want to review an as-if finished library, one that could be accepted immediately by the community and immediately enter Boost right now, no additional changes, because that is the ideal that a library submitter is supposed to be aiming for.
That's the whole point of the communtiy review - to review Boost libraries. Not libraries which still need to be converted to Boost.
I've created a standalone git repository for Metaparse, moved the code there and did the renaming. Additionally I did the following changes as well: - removed the dependencies to the Metamonad utilities (very minor, eg. macro for metafunction definition) - removed the Metamonad-integration header This repository can be found here: https://github.com/sabel83/metaparse I've tried it in a modular Boost setup on Ubuntu. (I've tested the code with Visual Studio in Mpllibs, not with modular Boost yet). It is still using the Markdown documentation format. I've added a build.sh script for HTML generation and committed the HTML files to the repository as well. (Similar to the Boost.MPL repository) Regards, Ábel
On 1 Jun 2015 at 23:25, Abel Sinkovics wrote:
My problem for me, as a reviewer, is that I want to review an as-if finished library, one that could be accepted immediately by the community and immediately enter Boost right now, no additional changes, because that is the ideal that a library submitter is supposed to be aiming for.
That's the whole point of the communtiy review - to review Boost libraries. Not libraries which still need to be converted to Boost.
I've created a standalone git repository for Metaparse, moved the code there and did the renaming. Additionally I did the following changes as well: - removed the dependencies to the Metamonad utilities (very minor, eg. macro for metafunction definition) - removed the Metamonad-integration header
This repository can be found here: https://github.com/sabel83/metaparse
I've tried it in a modular Boost setup on Ubuntu. (I've tested the code with Visual Studio in Mpllibs, not with modular Boost yet).
Outstanding. Thank you.
It is still using the Markdown documentation format. I've added a build.sh script for HTML generation and committed the HTML files to the repository as well. (Similar to the Boost.MPL repository)
Unfortunately I won't get the time to review this library again until the 14th, which I suspect is too late. I am happy to withdraw my vote to reject this library now though. P.S.: I'd just love to see Travis + Appveyor in your newly modularised library, and whose test scripts install your library as a module into a copy of Boost for CI testing. Oh, and please do add a Readme.md with the status badges to said services! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Hi Niall, On 2015-06-02 02:37, Niall Douglas wrote:
P.S.: I'd just love to see Travis + Appveyor in your newly modularised library, and whose test scripts install your library as a module into a copy of Boost for CI testing. Oh, and please do add a Readme.md with the status badges to said services! I'll do the integration of the standalone repository with Travis and Appveyor (and make other changes based on other suggestions) after the review.
Regards, Ábel
Abel Sinkovics wrote:
This repository can be found here: https://github.com/sabel83/metaparse
What follows is my review of Metaparse.
- What is your evaluation of the design?
Of high quality. Based on the MPL paradigm, but I don't view this as a problem.
- What is your evaluation of the implementation?
Did not look in detail, but based on a cursory glance, appears to be of Boost quality.
- What is your evaluation of the documentation?
Very good.
- What is your evaluation of the potential usefulness of the library?
Looks very useful for its target domain. I especially like the Grammar (meta)feature, using which one can provide the grammar description as text.
- Did you try to use the library?
No.
- How much effort did you put into your evaluation?
I read the documentation in its entirety (minus the Tutorial) and some of the supporting material.
- Are you knowledgeable about the problem domain?
I'm not sure if anybody is. :-)
Please always include in your review a vote as to whether the library should be accepted into Boost.
I think that the library should be accepted, although the name BOOST_STRING is too ambitious. I suggest BOOST_MP_STRING.
Niall Douglas wrote:
My personal recommendation is that you withdraw this library from review immediately, and go turn it first into an actual standalone Boost library complying with Boost naming guidelines in Boost git modular format.
Personally, I'd prefer boost submissions to *not* use the boost:: namespace etc. until they're actually accepted, with the rationale that "Boost should mean accepted by Boost". A mechanical search-and- replace of foo:: by boost:: would then happen before merging. I know this isn't what has typically happened in the past, but I don't agree with your recommendation that it should be withdrawn because of it. Of more concern is that the unfamiliar directory structure made it difficult for you to review it. Submissions should be either familiar enough or sufficiently documented that reviewers can find the important stuff that needs reviewing quickly. Hopefully the author of this library will reply to your email with pointers that will help other reviewers. Cheers, Phil.
Hi Phil, On 2015-05-31 15:08, Phil Endecott wrote:
Niall Douglas wrote:
My personal recommendation is that you withdraw this library from review immediately, and go turn it first into an actual standalone Boost library complying with Boost naming guidelines in Boost git modular format.
Personally, I'd prefer boost submissions to *not* use the boost:: namespace etc. until they're actually accepted, with the rationale that "Boost should mean accepted by Boost". A mechanical search-and- replace of foo:: by boost:: would then happen before merging. I know this isn't what has typically happened in the past, but I don't agree with your recommendation that it should be withdrawn because of it. That is what is happening here.
Of more concern is that the unfamiliar directory structure made it difficult for you to review it. Submissions should be either familiar enough or sufficiently documented that reviewers can find the important stuff that needs reviewing quickly. Hopefully the author of this library will reply to your email with pointers that will help other reviewers. My intention was to create a directory structure that is familiar for most people, which is the old directory structure of Boost. It should have been pointed out.
Regards, Ábel
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Christophe Henry Sent: 19 May 2015 22:39 To: boost@lists.boost.org; boost-announce@lists.boost.org Subject: [boost] [Boost-announce] [metaparse] Review period starts May 25th and ends June 7th
Dear all,
The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics.
Metaparse is a parser generator library for template metaprograms.
- What is your evaluation of the design? Looks refined. - What is your evaluation of the implementation? Not qualified to judge. - What is your evaluation of the documentation?
Refined and 'glossy', with good tutorial and interactive Metashell to help prototype your DSL, but not in familiar Boost Quickbook format (though that is less useful for a meta-ish library than one of simple functions, but it still provides a useful reference).
- What is your evaluation of the potential usefulness of the library?
Invaluable, and underused.
- Did you try to use the library?
No. It was not obviously compatible with modular-boost without much work.
- How much effort did you put into your evaluation? A quick reading
- Are you knowledgeable about the problem domain?
No.
Please always include in your review a vote as to whether the library should be accepted into Boost.
I vote for acceptance. BUT it needs to be changed quite a lot to fit into the modular-boost GIT structure before it is 'release-ready'. It should be possible to clone into a Boost tree and run examples and tests without further ado. (I am sympathetic to those who expect a fully modular-boost ready library for review, but I do not believe that this is reasonable. Doing this is usually a lot of work and expecting it before full acceptance is far too much to ask. We might compromise by having a mini-re-review, but seeing a working set of Boost-style examples and tests will give good confidence that the structure is right. The tutorial is fine as-is to include in the docs, but Quickbook could be used to provide an additional reference section.) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Hi Paul, Thank you for the review. On 2015-06-01 10:52, Paul A. Bristow wrote:
I vote for acceptance.
BUT it needs to be changed quite a lot to fit into the modular-boost GIT structure before it is 'release-ready'.
It should be possible to clone into a Boost tree and run examples and tests without further ado.
Please take a look at this: https://github.com/sabel83/metaparse Regards, Ábel
This is my review of the Metaparse library: The original metaparse library was represented as a library within mpllibs in the old Boost directory structure. The documentation of this library was entirely a tutorial of the library. The tutorial was a very good general explanation of how to use the library. As such it showed the potential of the library and that the author of the library gave a great amount of thought to how the library should be used. I would rate the tutorial itself as excellent. But a tutorial by itself is inadequate as documentation to a Boost library. Documentation needs a reference of all the classes, functions, data, macros of the library whether it is a library of meatfunctions or a library of run-time constructs. Furthermore some explanation of how the different parts of the library are organized and meant to be used within that organization is needed in documentation is necessary for me to understand a software library. So while I would rate the tutorial as excellent the documentation was inadequate. Sometime during the review process the presentation of what was being reviewed completely changed. A new version of the library was presented using the current Boost directory structure, with a very full documentation set and the link to the tutorial documentation in the original version being reviewed was removed. I am no doubt a bit stodgier than most programmers but this is not acceptable during a Boost review process. I believe the rule that what one reviews must remain absolutely unchanged during the period of a review has to be enforced. Changing everything during the review process, as has been done with this library, causes havoc and confusion for reviewers. So while I welcome the need for such a library, have recognized the high quality of the library, and feel that the library would be extremely useful for Boost library developers among others in adding a well thought out parsing framework to the tools a template metaprogrammer would have in designing his own library my vote, given the irregularity of how this library was originally presented to Boost I vote NO for acceptance of this library into Boost. While I realize that it may be seen as a PITA for the developer and review manager I would love to see another review of this library with the actual library being reviewed not changing under me and being either what was secondarily presented as the library or as an improvement of what was secondarily presented as the library. Personally, and without any animosity whatsoever to the library developer or the review manager, I don't think this review can be considered a valid one given what has happened during the review. But it is not my call to decide on this and I can only vote based on my annoyance that this has happened.
On Tue, Jun 2, 2015 at 11:05 AM, Edward Diener wrote:
Sometime during the review process the presentation of what was being reviewed completely changed. A new version of the library was presented using the current Boost directory structure, with a very full documentation set and the link to the tutorial documentation in the original version being reviewed was removed.
Was the original repository completely changed? I was under the impression that Abel created sabel83/metaparse to demonstrate how this would look with the Boost structure, while the original sabel83/mpllibs remained untouched. Glen
Hi Glen, On 2015-06-02 20:16, Glen Fernandes wrote:
On Tue, Jun 2, 2015 at 11:05 AM, Edward Diener wrote:
Sometime during the review process the presentation of what was being reviewed completely changed. A new version of the library was presented using the current Boost directory structure, with a very full documentation set and the link to the tutorial documentation in the original version being reviewed was removed. Was the original repository completely changed? I was under the impression that Abel created sabel83/metaparse to demonstrate how this would look with the Boost structure, while the original sabel83/mpllibs remained untouched. That is correct. I have not changed the original repository (apart from adding copy-paste friendly versions of the code snippets to the tutorial and fixing a broken URL) since the beginning of the review.
Regards, Ábel
On Tue, Jun 2, 2015 at 12:20 PM, Abel Sinkovics wrote:
Hi Glen,
That is correct. I have not changed the original repository (apart from adding copy-paste friendly versions of the code snippets to the tutorial and fixing a broken URL) since the beginning of the review.
Abel - that's perfect, in my humble opinion. The whole exchange demonstrates that you, as a library author, are not opposed to comply with simple requests from the Boost community for convenience of reviewing/using/testing your library /and/ your original submission is well preserved enough for comparison. There are library authors, like Abel, who are very responsive, and willing to comply with any formality or request in the review process - but when there is contention about some of these formalities, or if some rules are not explicitly documented, it is unfair to punish the library author for it. I believe Abel's complied well with the spirit of the Boost review process, and I like Christophe's response very much. Perhaps, Ron, the formal review documentation on the Boost site can be updated for the benefit of reviewers as much as library authors, to clarify some of these issues. Glen
Edward Diener wrote:
Sometime during the review process the presentation of what was being reviewed completely changed. A new version of the library was presented using the current Boost directory structure, with a very full documentation set and the link to the tutorial documentation in the original version being reviewed was removed.
I am no doubt a bit stodgier than most programmers but this is not acceptable during a Boost review process.
Several people have explicitly mentioned that they have reservations about the fact that the library was not presented in its final Boost-ready form and that they would have liked to examine, and vote on, that final form. Abel has accommodated their wishes and has done the necessary work to present the library in its Boost-ready form. It strikes me as extremely unfair to hold that against him. Damned if he does, damned if he doesn't.
On 2 Jun 2015 at 21:28, Peter Dimov wrote:
Edward Diener wrote:
Sometime during the review process the presentation of what was being reviewed completely changed. A new version of the library was presented using the current Boost directory structure, with a very full documentation set and the link to the tutorial documentation in the original version being reviewed was removed.
I am no doubt a bit stodgier than most programmers but this is not acceptable during a Boost review process.
Several people have explicitly mentioned that they have reservations about the fact that the library was not presented in its final Boost-ready form and that they would have liked to examine, and vote on, that final form.
Abel has accommodated their wishes and has done the necessary work to present the library in its Boost-ready form. It strikes me as extremely unfair to hold that against him. Damned if he does, damned if he doesn't.
The precedent for handling this is very well understood. If during the early part of review it becomes obvious Rejection votes are occurring due to presentation problems, the precedent is to withdraw the library from review, make the fixes, and start the review again with the fixed edition. I certainly don't like libraries changing during review, and I also don't like two editions of a library being reviewed concurrently. It gets very confusing very quickly. I think peer reviews are very like academic paper peer reviews: it's all about reducing potential for confusion, objection, or any easy to predict reason to reject a library before you begin. It's about eliminating as many reasons as is possible for people to reject or find problem before you begin. Not submitting a library in the correct directory structure is guaranteed to create problems for some reviewers, and is easily predicted before a review begins. Lack of CI testing is another. This is why I wrote up that Best Practices Handbook so for C++ 11/14 libraries we can hopefully get more of the boxes preticked in the future before reviews of C++ 11/14 libraries begin. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
The precedent for handling this is very well understood.
I don't if its that well understood as their seems to be some disagreement.
If during the early part of review it becomes obvious Rejection votes are occurring due to presentation problems, the precedent is to withdraw the library from review, make the fixes, and start the review again with the fixed edition.
I think that is a huge waste of everyone's time for something as trivial as moving folders around.
I think peer reviews are very like academic paper peer reviews:
Except most of the time, its a volunteer effort, so I think its important to be respectful of everyone's time.
Not submitting a library in the correct directory structure is guaranteed to create problems for some reviewers, and is easily predicted before a review begins. Lack of CI testing is another. This is why I wrote up that Best Practices Handbook so for C++ 11/14 libraries we can hopefully get more of the boxes preticked in the future before reviews of C++ 11/14 libraries begin.
Perhaps Boost could agree on some minimum list of requirements for a library before it goes into review, but I doubt it will be same in your Best Practices Handbook. However, having some official list can help make this clearer in the future. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-announce-metaparse-Review-period-st... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 2 Jun 2015 at 12:59, Paul Fultz II wrote:
If during the early part of review it becomes obvious Rejection votes are occurring due to presentation problems, the precedent is to withdraw the library from review, make the fixes, and start the review again with the fixed edition.
I think that is a huge waste of everyone's time for something as trivial as moving folders around.
Thing is, it may or may not actually be trivial. In the past I've thought something was as simple as a find and replace, and then it turned into something quite tricky because the find and replace exposed a deeper design problem. The OP has demonstrated that isn't a problem in this case, hence I withdrew my objection.
I think peer reviews are very like academic paper peer reviews:
Except most of the time, its a volunteer effort, so I think its important to be respectful of everyone's time.
Academic journal peer reviews are usually a volunteer effort too.
Not submitting a library in the correct directory structure is guaranteed to create problems for some reviewers, and is easily predicted before a review begins. Lack of CI testing is another. This is why I wrote up that Best Practices Handbook so for C++ 11/14 libraries we can hopefully get more of the boxes preticked in the future before reviews of C++ 11/14 libraries begin.
Perhaps Boost could agree on some minimum list of requirements for a library before it goes into review, but I doubt it will be same in your Best Practices Handbook.
Agreed. My aim wasn't to write up the requirements, but to write up examples of what I thought was best practice with the later aim of scoring them via automated script. Very different goals.
However, having some official list can help make this clearer in the future.
The existing requirements documentation is long in the tooth. Someone ought to write up an official document and run it through multiple rounds of peer review until it's canonical. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On June 2, 2015 3:59:35 PM EDT, Paul Fultz II <pfultz2@yahoo.com> wrote:
Perhaps Boost could agree on some minimum list of requirements for a library before it goes into review, but I doubt it will be same in your Best Practices Handbook. However, having some official list can help make this clearer in the future.
"A proposed library should remain stable during the review period; it will just confuse and irritate reviewers if there are numerous changes. It is, however, useful to upload fixes for serious bugs right away, particularly those which prevent reviewers from fully evaluating the library. Post a notice of such fixes on the mailing list. "Library improvements suggested by reviewers should normally be held until after the completion of review period. If the suggested changes might affect reviewer's judgments, post a notice of the pending change on the mailing list." I think Abel followed this well.
"The library must come reasonably close to meeting the Guidelines below. "Design and Programming "Directory Structure "Documentation" There was a problem of not having a link to the top of the docs in the review announcement. The "Directory Structure" link mentions the directories build, doc, example, src, and test. Here, the library was deficient WRT the submission requirements. Fortunately, a second repository has rectified the issue in plenty of time for reviewers to examine in parallel with the original. That's not ideal, but it is tractable. At this point, everyone is agreed to proceed, so this will be a lesson for future library submitters and review managers. ___ Rob (Sent from my portable computation engine)
On 3 Jun 2015 at 5:07, Rob Stewart wrote:
At this point, everyone is agreed to proceed, so this will be a lesson for future library submitters and review managers.
I think that is exactly the wrong conclusion to draw, and the past drawing of that conclusion had led to us repeating, yet again, an unpleasant and inefficient review compared to what it should have been. No wonder the review pipeline ground to a halt in the past, everyone just gets put off. A much better conclusion to draw is this: 1. There is more than one kind of library peer review: a. "I'm working on this new library, I would like to hear comments on it" b. "I have this preexisting mature library which I would like to add to Boost, is Boost interested in it?" c. "I have an idea for a new library, would Boost be interested in it?" d. "I have finished this library and I believe it is ready to enter Boost" Also: e. "I have substantially refactored an existing Boost library into a breaking change which affects other Boost libraries" 2. Different types of library review have different procedures, so essentially: a => Incubator b => Formal Review, no Review Manager c => boost-dev mailing list d => Formal Review, needs Review Manager e => Whatever the maintainer thinks best 3. Different kind of library review should have detailed, step by step, "tick box" formalised procedures (formal workflow) to take the (prospective) library author from where they begin to a successfully completed conclusion with a minimum of inefficiency. 4. There is no shortage of free web tooling which can automate the ticking of those boxes and walk library authors through the formalised procedure. Indeed, Boost already is on Google Apps, and Google Forms is one of the best free web tooling for forms. Unlike most other Boost infrastructure needs (hint - is my volunteering to upgrade Trac approved? If so, a ball needs to start rolling) where our infrastructure requirements simply aren't there yet, for Forms and workflow programming we are ready to go. 5. Ideally in the future a review manager would have their own form with boxes to tick, and part of their form would be to check the form the library author filled in i.e. the forms themselves feed into one another as part of the programmed workflow. If the community likes this idea, I can spec it up into another grant proposal and submit that to the steering committee. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas Sent: 03 June 2015 11:04 To: boost@lists.boost.org Subject: [boost] Formalising the review process into a well specified workflow (was: Re: [Boost-announce] [metaparse] Review period star
On 3 Jun 2015 at 5:07, Rob Stewart wrote:
At this point, everyone is agreed to proceed, so this will be a lesson for future library submitters and review managers.
I think that is exactly the wrong conclusion to draw, and the past drawing of that conclusion had led to us repeating, yet again, an unpleasant and inefficient review compared to what it should have been. No wonder the review pipeline ground to a halt in the past, everyone just gets put off.
A much better conclusion to draw is this:
1. There is more than one kind of library peer review:
a. "I'm working on this new library, I would like to hear comments on it"
b. "I have this preexisting mature library which I would like to add to Boost, is Boost interested in it?"
c. "I have an idea for a new library, would Boost be interested in it?"
d. "I have finished this library and I believe it is ready to enter Boost"
Also:
e. "I have substantially refactored an existing Boost library into a breaking change which affects other Boost libraries"
2. Different types of library review have different procedures, so essentially:
a => Incubator b => Formal Review, no Review Manager c => boost-dev mailing list d => Formal Review, needs Review Manager e => Whatever the maintainer thinks best
3. Different kind of library review should have detailed, step by step, "tick box" formalised procedures (formal workflow) to take the (prospective) library author from where they begin to a successfully completed conclusion with a minimum of inefficiency.
4. There is no shortage of free web tooling which can automate the ticking of those boxes and walk library authors through the formalised procedure. Indeed, Boost already is on Google Apps, and Google Forms is one of the best free web tooling for forms. Unlike most other Boost infrastructure needs (hint - is my volunteering to upgrade Trac approved? If so, a ball needs to start rolling) where our infrastructure requirements simply aren't there yet, for Forms and workflow programming we are ready to go.
5. Ideally in the future a review manager would have their own form with boxes to tick, and part of their form would be to check the form the library author filled in i.e. the forms themselves feed into one another as part of the programmed workflow.
If the community likes this idea, I can spec it up into another grant proposal and submit that to the steering committee.
No -let's NOT formalise it. It ain't broke - don't fix it. KISS! Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 3 June 2015 at 06:02, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
No -let's NOT formalise it.
It ain't broke - don't fix it.
KISS!
How many full reviews have we had this year? Oh yeah, this is the first one. It seems ridiculous to add more process and procedures to this. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On Wed, Jun 3, 2015 at 1:04 PM, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 3 Jun 2015 at 5:07, Rob Stewart wrote:
At this point, everyone is agreed to proceed, so this will be a lesson for future library submitters and review managers.
I think that is exactly the wrong conclusion to draw, and the past drawing of that conclusion had led to us repeating, yet again, an unpleasant and inefficient review compared to what it should have been. No wonder the review pipeline ground to a halt in the past, everyone just gets put off.
A much better conclusion to draw is this:
1. There is more than one kind of library peer review:
a. "I'm working on this new library, I would like to hear comments on it"
b. "I have this preexisting mature library which I would like to add to Boost, is Boost interested in it?"
c. "I have an idea for a new library, would Boost be interested in it?"
d. "I have finished this library and I believe it is ready to enter Boost"
Also:
e. "I have substantially refactored an existing Boost library into a breaking change which affects other Boost libraries"
2. Different types of library review have different procedures, so essentially:
a => Incubator b => Formal Review, no Review Manager c => boost-dev mailing list d => Formal Review, needs Review Manager e => Whatever the maintainer thinks best
I think you're mixing reviews and interest polls and discussions. Of all above items, (d) seems the closest to the formal proposal for a review. Well, maybe (e) also, if the author wants the refactored library to be formally reviewed. The proposal, as well as requirements to the library and review process are already formalized on the website. The rest are informal discussions that cannot result in a library inclusion but may serve development. I don't see why we would need to formalize such communications.
3. Different kind of library review should have detailed, step by step, "tick box" formalised procedures (formal workflow) to take the (prospective) library author from where they begin to a successfully completed conclusion with a minimum of inefficiency.
4. There is no shortage of free web tooling which can automate the ticking of those boxes and walk library authors through the formalised procedure. Indeed, Boost already is on Google Apps, and Google Forms is one of the best free web tooling for forms. Unlike most other Boost infrastructure needs (hint - is my volunteering to upgrade Trac approved? If so, a ball needs to start rolling) where our infrastructure requirements simply aren't there yet, for Forms and workflow programming we are ready to go.
5. Ideally in the future a review manager would have their own form with boxes to tick, and part of their form would be to check the form the library author filled in i.e. the forms themselves feed into one another as part of the programmed workflow.
If the community likes this idea, I can spec it up into another grant proposal and submit that to the steering committee.
If I'm not mistaken, you already proposed an automated review process, like a checklist or something. I'm strongly opposed to any automated review scheme where expert opinions are not involved or required. I believe human review is the cornerstone of the whole review process and not any formal checks like directory layout, test coverage, VCS and build system used an so on. I'm not opposed to automating such checks but only to help the review manager and the author to assess whether the library is ready for inclusion (whether such assessment is done before or after the review).
On 3 Jun 2015 at 15:51, Andrey Semashev wrote:
The rest are informal discussions that cannot result in a library inclusion but may serve development. I don't see why we would need to formalize such communications.
I think the problems with the existing documentation of workflow are much more obvious if you're submitting a new library.
4. There is no shortage of free web tooling which can automate the ticking of those boxes and walk library authors through the formalised procedure. Indeed, Boost already is on Google Apps, and Google Forms is one of the best free web tooling for forms. Unlike most other Boost infrastructure needs (hint - is my volunteering to upgrade Trac approved? If so, a ball needs to start rolling) where our infrastructure requirements simply aren't there yet, for Forms and workflow programming we are ready to go.
If I'm not mistaken, you already proposed an automated review process, like a checklist or something.
Ehh, sorta. It actually has no forms nor checklist at all. What I have specced out here is a nightly cron job which spiders Robert's Incubator and github/boostorg for git repos. It then git fetches each and looks for a special YAML file in the meta directory. In that YAML file all the details required by the automated scripts are detailed, or at least as many of the script passes as the library author wishes. The automated scripts are then run upon the git repo, doing things like clang-tidy passes checking naming conventions, asking trac and github for how many unresolved issues and unmerged pull requests there are etc. These are entered into a database of results. A separate web service provides a way of displaying the database of results according to any arbitrary database query. My idea was that anyone wishing to include a live display of any indexed libraries with any custom query into their website could do so. My initial thoughts were for Robert's Incubator, and the Boost main download page, but one could also generate Slack notifications, Atlassian integration, or even just a RSS feed of recent updates to Boost libraries. It's a web service reusable for any purposes people can dream of, hopefully. I also see no reason why the index wouldn't index any C++ library desiring of it with whatever script passes they choose. Boost libraries simply get a boost tag, that's all. Anyway all that is shelved till after CppCon now that AFIO is up for review end of July.
I'm strongly opposed to any automated review scheme where expert opinions are not involved or required. I believe human review is the cornerstone of the whole review process and not any formal checks like directory layout, test coverage, VCS and build system used an so on. I'm not opposed to automating such checks but only to help the review manager and the author to assess whether the library is ready for inclusion (whether such assessment is done before or after the review).
I have no problem with the expert review as the final end stage for the absolute top end libraries highly likely to enter the C++ standard. I think relaxations of and alternatives to the expert review for other kinds of intermediate stage review make enormous sense if Boost is to stay relevant into the future. I definitely see no point in there being exactly one single completely unchanged process since 2005 which may have made sense in 2005, but does not in 2015 especially after the stagnation in 2013 and recent exodus of so many of the former big hitters. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote: [snip lots]
5. Ideally in the future a review manager would have their own form with boxes to tick, and part of their form would be to check the form the library author filled in i.e. the forms themselves feed into one another as part of the programmed workflow.
No no no no no no no. What we want is (a) common sense to be applied, and (b) domain experts to actually do reviews, and (c) in the absence of too many of those, non-experts to at least try the library and express their opinions or drive the discussion by asking questions. Regards, Phil.
On 3 Jun 2015 at 16:06, Phil Endecott wrote:
5. Ideally in the future a review manager would have their own form with boxes to tick, and part of their form would be to check the form the library author filled in i.e. the forms themselves feed into one another as part of the programmed workflow.
No no no no no no no.
What we want is (a) common sense to be applied, and (b) domain experts to actually do reviews, and (c) in the absence of too many of those, non-experts to at least try the library and express their opinions or drive the discussion by asking questions.
I was thinking of form questions for review managers such as: "Before beginning the review have you verified the library to be reviewed compiles on at least two compilers?" Tick yes/no. "Have you included a link to the root of the library documentation in the review announcement email?" Tick yes/no. It's not rocket science. But it makes the exact process and workflow crystal clear for the review manager involved instead of trying to interpret words scattered over at least three web pages, and then finding some reviewers have very different expectations to others because you didn't use conventional idioms prespecified by the workflow. This is all about saving everybody time, hassle and confusion. Not about prespecifying how reviews are written, understood, or interpreted. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Wed, Jun 3, 2015 at 8:28 AM, Niall Douglas wrote:
This is all about saving everybody time, hassle and confusion. Not about prespecifying how reviews are written, understood, or interpreted.
I think you're blowing this incident a little out of proportion. Just a difference of expectations on both the author and a reviewer (or two) is not so catastrophic that it requires an overhaul of the review process involving paid investment in some automated submission system. If anything is essential for reviewers to expect, for library authors to do, it can be clarified on the formal review process website. Rather, I hope that nobody needs to be funded to add more helpful detail for reviewers, library authors, review managers at http://www.boost.org/community/reviews.html Glen
On 06/02/2015 11:58 AM, Niall Douglas wrote:
On 2 Jun 2015 at 21:28, Peter Dimov wrote:
The precedent for handling this is very well understood.
Can you please cite specific examples of this "precedent"?
If during the early part of review it becomes obvious Rejection votes are occurring due to presentation problems, the precedent is to withdraw the library from review, make the fixes, and start the
I don't recall this happening. Despite what some people might want to think, the review process is not an equatable voting process. It is a process in which a competent review manager solicits community feedback and then makes an educated decision. The review manager's job is not to tally votes.
review again with the fixed edition. I certainly don't like libraries changing during review, and I also don't like two editions of a
Abel has not submitted a second version for review by the community. He was gracious enough to show what the other version might look like at your prodding. The more amazing thing to me is that the original version is the older Boost directory structure and some reviewers are confused by that.
I think peer reviews are very like academic paper peer reviews: it's
Boost reviews have nothing to do with academic paper reviews.
Not submitting a library in the correct directory structure is guaranteed to create problems for some reviewers, and is easily predicted before a review begins. Lack of CI testing is another. This is why I wrote up that Best Practices Handbook so for C++ 11/14 libraries we can hopefully get more of the boxes preticked in the future before reviews of C++ 11/14 libraries begin.
I've only been active in the Boost community for 10-years, but let me help correct some of your assertions. It is not uncommon for libraries to need a restructure of directories and namespaces *after* approval. The goal is that authors present a very high quality library without having to completely boostify it before finding out if it will be accepted. Directory structures and namespaces are not a requirement of a review. CI testing is also not a requirement for a review to be successful. You are free to voice your opinion and to write documents that promote it; however, you cannot force your requirements onto the process. michael -- Michael Caisse ciere consulting ciere.com
On 2 Jun 2015 at 13:37, Michael Caisse wrote:
The precedent for handling this is very well understood.
Can you please cite specific examples of this "precedent"?
After trying to find as you ask, I could find none - there was one withdrawal, and it was because the author no longer wished their library to enter Boost. It looks like there is no precedent. I withdraw my assertion.
I've only been active in the Boost community for 10-years, but let me help correct some of your assertions. It is not uncommon for libraries to need a restructure of directories and namespaces *after* approval. The goal is that authors present a very high quality library without having to completely boostify it before finding out if it will be accepted. Directory structures and namespaces are not a requirement of a review. CI testing is also not a requirement for a review to be successful. You are free to voice your opinion and to write documents that promote it; however, you cannot force your requirements onto the process.
This whole debate is mainly being caused by the gulf between what is officially documented and what individual people think the community is agreed upon and then what individual personal opinion is. That gulf is the root of a lot of wasted time and effort. Like us reading and writing these emails right now. This is why I recommend to those submitting libraries that you don't invite controversy when you submit a library for review. Instead of us discussing the OP's library as we should be, here we are arguing about what a review is or isn't or should be, which is really the argument about the future direction of Boost, yet again. Instead of viewing this as me "forcing my requirements onto the process", try considering it instead as me "advocating the least hard way of getting your library into Boost". Instead of viewing me as always negative like Hartmut and I would assume others on the steering committee, try viewing me as positive and actually trying to help library authors achieve their goal of getting into Boost. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Caisse Sent: 02 June 2015 21:37 To: boost@lists.boost.org Subject: Re: [boost] [Boost-announce] [metaparse] Review period starts May 25th and ends June 7th
On 06/02/2015 11:58 AM, Niall Douglas wrote:
On 2 Jun 2015 at 21:28, Peter Dimov wrote:
The precedent for handling this is very well understood. I've only been active in the Boost community for 10-years, but let me help correct some of your assertions. It is not uncommon for libraries to need a restructure of directories and namespaces *after* approval.
The goal is that authors present a very high quality library without having to completely boostify it before finding out if it will be accepted.
+1 Directory structures and namespaces are not a requirement of a review.
CI testing is also not a requirement for a review to be successful. You are free to voice your opinion and to write documents that promote it; however, you cannot force your requirements onto the process.
+1 *All* libraries need some work before being 'Boost release-ready', some more than others. And we have had mini-reviews in the past. Let's not make life for authors more difficult than it need be. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 6/2/2015 2:28 PM, Peter Dimov wrote:
Edward Diener wrote:
Sometime during the review process the presentation of what was being reviewed completely changed. A new version of the library was presented using the current Boost directory structure, with a very full documentation set and the link to the tutorial documentation in the original version being reviewed was removed.
I am no doubt a bit stodgier than most programmers but this is not acceptable during a Boost review process.
Several people have explicitly mentioned that they have reservations about the fact that the library was not presented in its final Boost-ready form and that they would have liked to examine, and vote on, that final form.
Abel has accommodated their wishes and has done the necessary work to present the library in its Boost-ready form. It strikes me as extremely unfair to hold that against him. Damned if he does, damned if he doesn't.
The Boost-ready form is what I would like to review but its not only the Boost-ready form that changed but the fact that the documentation set changed ( for the better I will add ). But that's not what was offered for the original review. I don't hold anything against the library author but I don't think I should be required to approve of this ability to change a library in the midst of a review so I voted NO. I think it is going to be really bad, and confusing, to set a precedent by which a library author in the midst of a review, changes the library being reviewed for any reason. My vote can be seen as a protest that this was allowed to happen and has absolutely nothing personal to do with the library author in question.
Hi Edward, On 2015-06-02 22:32, Edward Diener wrote:
The Boost-ready form is what I would like to review but its not only the Boost-ready form that changed but the fact that the documentation set changed ( for the better I will add ). But that's not what was offered for the original review. I don't hold anything against the library author but I don't think I should be required to approve of this ability to change a library in the midst of a review so I voted NO. I think it is going to be really bad, and confusing, to set a precedent by which a library author in the midst of a review, changes the library being reviewed for any reason. My vote can be seen as a protest that this was allowed to happen and has absolutely nothing personal to do with the library author in question.
The documentation set did not change (except for the mpllibs -> boost renaming in that as well). See: https://github.com/sabel83/mpllibs/tree/master/libs/metaparse/doc and https://github.com/sabel83/metaparse/tree/master/doc/src Regards, Ábel
On 6/2/2015 4:45 PM, Abel Sinkovics wrote:
Hi Edward,
On 2015-06-02 22:32, Edward Diener wrote:
The Boost-ready form is what I would like to review but its not only the Boost-ready form that changed but the fact that the documentation set changed ( for the better I will add ). But that's not what was offered for the original review. I don't hold anything against the library author but I don't think I should be required to approve of this ability to change a library in the midst of a review so I voted NO. I think it is going to be really bad, and confusing, to set a precedent by which a library author in the midst of a review, changes the library being reviewed for any reason. My vote can be seen as a protest that this was allowed to happen and has absolutely nothing personal to do with the library author in question.
The documentation set did not change (except for the mpllibs -> boost renaming in that as well). See: https://github.com/sabel83/mpllibs/tree/master/libs/metaparse/doc and https://github.com/sabel83/metaparse/tree/master/doc/src
When I clicked the index.html for the original docs I got a link to the tutorial and that's it. Now I see that has been changed and the link has been removed. When I click the index.html for your updated docs I get a page with an introduction and a whole bunch of links to: Getting started Tutorial User manual Library reference Versioning Performance I approve of this much better documentation but that's not what you originally had in HTML form. I like your HTML documentation improvement. It's what Boost users/developers expect and not just the tutorial which you originally offered, as good as that tutorial is. My point is that you did the right thing by greatly improving access to your documentation in HTML form, but you did it at the wrong time. It should have been done before the review, or once the review was over it should have been done. I object on principle to any libraary author making changes in any way to what is being reviewed once the review starts. My vote and point of view is a protest of that situation. I think it sets a very bad precedent, that of library authors making changes to what they are offering for review as the review is happening.
On 3/06/2015 10:00, Edward Diener wrote:
When I clicked the index.html for the original docs I got a link to the tutorial and that's it. Now I see that has been changed and the link has been removed.
Note that the link to the original docs in the original review post was to getting_started.html, not to index.html. This may be part of your confusion with the "changed documentation", especially if you did not notice the tiny [up] link at the very bottom of the Getting Started page. Of course, it was probably a mistake on the part of the review manager to post a link to a sub-page of the docs instead of to the whole thing, although it was in the context of "here's a tutorial" rather than "here's the docs".
Hi Edward, On 2015-06-03 00:00, Edward Diener wrote:
On 6/2/2015 4:45 PM, Abel Sinkovics wrote:
When I clicked the index.html for the original docs I got a link to the tutorial and that's it. Now I see that has been changed and the link has been removed.
When I click the index.html for your updated docs I get a page with an introduction and a whole bunch of links to:
Getting started Tutorial User manual Library reference Versioning Performance
That is strange, as it has been the HTML pages generated from the markdown files for the last couple of years (since the library is out there). You might have looked at the index.html of the type-safe printf's doc or have gone directly to Metaparse's getting_started.html when you first looked at the docs, as these were the links in the review's announcement. Regards, Ábel
On 6/3/2015 12:35 AM, Abel Sinkovics wrote:
Hi Edward,
On 2015-06-03 00:00, Edward Diener wrote:
On 6/2/2015 4:45 PM, Abel Sinkovics wrote:
When I clicked the index.html for the original docs I got a link to the tutorial and that's it. Now I see that has been changed and the link has been removed.
When I click the index.html for your updated docs I get a page with an introduction and a whole bunch of links to:
Getting started Tutorial User manual Library reference Versioning Performance
That is strange, as it has been the HTML pages generated from the markdown files for the last couple of years (since the library is out there).
You might have looked at the index.html of the type-safe printf's doc
Why would I ever think of doing that, when the review is about Metaparse.
or have gone directly to Metaparse's getting_started.html when you first looked at the docs, as these were the links in the review's announcement.
In the original presentation of your library I did find the original Getting Started. I didn't see any other links from there to the rest of the documentation. With your modified presentation of the library the index.html takes me to your main page with boost::metaparse on top and the rest of the documentation s I specified above below it. That's a whole lot better IMO. I apologize for getting so peevish about what others asked you to do and which you did to improve your library under review. I still intend to give an updated review of your library with my comments about the documentation as I now understand it and of your library's functionality. I assume as a reviewer I can modify my initial review and my vote of acceptance of a library as long as the review period is still underway.
Hi Edward,
I apologize for getting so peevish about what others asked you to do and which you did to improve your library under review. I still intend to give an updated review of your library with my comments about the documentation as I now understand it and of your library's functionality. I assume as a reviewer I can modify my initial review and my vote of acceptance of a library as long as the review period is still underway. Thank you.
Regards, Ábel
Edward Diener wrote:
I think it is going to be really bad, and confusing, to set a precedent by which a library author in the midst of a review, changes the library being reviewed for any reason.
I understand where you're coming from, but (1) the changes (in directory structure, namespace and identifier naming) were done in response to reviewers' requests and not on a whim, and (2) it takes years for a library's review to be scheduled. We cannot afford to tell library authors "do please wait another three years because you made changes which were requested of you during the review."
On 6/2/2015 4:49 PM, Peter Dimov wrote:
Edward Diener wrote:
I think it is going to be really bad, and confusing, to set a precedent by which a library author in the midst of a review, changes the library being reviewed for any reason.
I understand where you're coming from, but (1) the changes (in directory structure, namespace and identifier naming) were done in response to reviewers' requests and not on a whim, and (2) it takes years for a library's review to be scheduled. We cannot afford to tell library authors "do please wait another three years because you made changes which were requested of you during the review."
Nobody is going to make a library wait for more than a month or two if the library is deemed not presentable enough in its current form to be reviewed. Its not like the review schedule is actually so filled with exciting reviews that anybody has to wait. The reason for waits is always that a review manager hasn't been found. And since a review manager already exists for a library being reviewed it is hardly conceivable that a re-review will not occur in the very near future.
This whole thread illustrates one of the problems that the Boost Library Incubator was intended to solve. If a few reviews of the library had been submitted to the incubator, (or even comments) then there would bave been time to address the situation in a convenient way. As it stands, now we have a long discussion about whether the library should be changed during the review, whether it should be re-reviewed and what the review policy is and what precedents, etc., etc. ... The author has certainly demonstrated that he's interested in responding t comments and suggestions right away. Just think how much better this process would have been if some of the comments/reviews had been submitted a couple of weeks ago. Robert Ramey
Hi,
Edward Diener wrote:
Sometime during the review process the presentation of what was being reviewed completely changed. A new version of the library was presented using the current Boost directory structure, with a very full documentation set and the link to the tutorial documentation in the original version being reviewed was removed.
I am no doubt a bit stodgier than most programmers but this is not acceptable during a Boost review process.
Several people have explicitly mentioned that they have reservations about the fact that the library was not presented in its final Boost-ready form and that they would have liked to examine, and vote on, that final form.
Abel has accommodated their wishes and has done the necessary work to present the library in its Boost-ready form. It strikes me as extremely unfair to hold that against him. Damned if he does, damned if he doesn't.
I stayed silent until now but I feel I have to slightly steer the review in the right (IMO) direction, which means in the direction where the review is based on the quality of the library and documentation, not on pure formalities. I as review manager allowed this library to make it to the review based on the opinions that: - the quality of the library seemed high - the documentation seemed much higher than usual boost level (counting myself) - the structure is not important. If reviewers would be disturbed by this fact, a mini-review could have checked the new directory structure. Abel even obliged as to in record-time present a new boost-conform structure. The review is not finished, so I'm failing to see the problem. I can only agree with Peter's above comment. Taking the risk to see the Boost community criticize my decision, I want to make it clear that I will not base my acceptance decision on votes made by pure formality but on votes criticizing the library implementation, quality, documentation, scope, usefulness and this with any directory structure the reviewer feels more comfortable with. I eagerly welcome any review helping me to take a decision on the above criteria. Cheers, Christophe Review Manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
christophe.j.henry@gmail.com wrote:
I feel I have to slightly steer the review in the right (IMO) direction, which means in the direction where the review is based on the quality of the library and documentation, not on pure formalities.
I agree with your steering direction. So let me ask a question: how useful is this library in practice, beyond "toy examples"? Was this library developed with a real application, i.e. use in a product, as its motivation, or was it written to test the limits of what is possible using metaprogramming? My first reaction to the library was "cool!". My second reaction was "it's a toy to demonstrate metaprogramming". Then I saw the printf() example and my third (and for now final!) though is that, yes, this could be useful. In another thread, Peter Dimov asked about getting char packs from string literals. It seems to me that if we had that then we could implement printf() without needing a "parser library" at all: template <char c1, char... c> class formatter { public: template <typename... ARGS> void operator()(ARGS... args...) { std::cout << c1; formatter<c...>()(args...); } }; template <char... c> class formatter<'%','d',c...> { public: template <typename... ARGS> void operator()(int i, ARGS... args...) { std::cout << i; formatter<c...>()(args...); } }; template <char c1> class formatter<c1> { public: void operator()() { std::cout << c1; } }; int main() { formatter<'h','e','l','l','o','%','d','!'>()(42); } So maybe all that I really want is the preprocessor magic to turn string literals into something that's more useful at compile time. Or a language feature to do that. Or maybe somehow constexpr can do it all for me. Anyone have a constexpr implementation of printf()? Hmm. Cheers, Phil.
Phil Endecott wrote:
So let me ask a question: how useful is this library in practice, beyond "toy examples"?
Was this library developed with a real application, i.e. use in a product, as its motivation, or was it written to test the limits of what is possible using metaprogramming?
My first reaction to the library was "cool!". My second reaction was "it's a toy to demonstrate metaprogramming". Then I saw the printf() example and my third (and for now final!) though is that, yes, this could be useful.
The presentation at http://abel.sinkovics.hu/download.php?fn=2014_dsl.pdf is a very good illustration of the potential use cases of the library and the current alternatives that are commonly employed. It uses a regular expression parser as an example, but embedded SQL could be another good one. In short, it enables compile-time embedded domain-specific languages (EDSLs) to not be constrained by the C++ syntax. You write your regular expression as a string and the Metaparse parser compiles it into a C++ regexp matching engine for the expression. Another interesting example would be your writing a grammar for a language in EBNF (instead of Spirit syntax) and Metaparse generating the (runtime) parser from that. (Interestingly, Metaparse can currently take a grammar in EBNF and generate the compile-time parser from it. :-))
Hi Peter, On 2015-06-03 00:40, Peter Dimov wrote:
Another interesting example would be your writing a grammar for a language in EBNF (instead of Spirit syntax) and Metaparse generating the (runtime) parser from that. (Interestingly, Metaparse can currently take a grammar in EBNF and generate the compile-time parser from it. :-))
The grammar element in Metaparse (which can be used to generate a compile-time parser from a grammar) was originally developed as a demonstration of the expressiveness of the library (you can build the library using itself). I later decided to make it part of the interface as a tool to quickly get something to work, however, it slows the compilation process significantly down (this is mentioned in the reference). No measurements about it. The compilation time difference was seconds <-> minutes, so I found it pointless to actually measure it. Regards, Ábel
On 06/02/2015 03:18 PM, Phil Endecott wrote:
christophe.j.henry@gmail.com wrote:
I feel I have to slightly steer the review in the right (IMO) direction, which means in the direction where the review is based on the quality of the library and documentation, not on pure formalities.
I agree with your steering direction.
So let me ask a question: how useful is this library in practice, beyond "toy examples"?
Hi Phil - Did you see Christophe's eUML2 frontend for MSM that uses Metaparse? <https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/msm/msm3/doc/HTML/ch03s05.html> the code is very readable (for example): <https://github.com/boostorg/msm/blob/euml2/include/boost/msm/front/euml2/stt_grammar.hpp> <https://github.com/boostorg/msm/blob/euml2/include/boost/msm/front/euml2/state_internal.hpp> I had the same question and found the eUML2 frontend to be a compelling example of "real world" usefulness. I'm currently thinking about a Spirit X3 front end that allows proper "operators" for PEG grammars. michael -- Michael Caisse ciere consulting ciere.com
On 2 Jun 2015 at 23:18, Phil Endecott wrote:
christophe.j.henry@gmail.com wrote:
I feel I have to slightly steer the review in the right (IMO) direction, which means in the direction where the review is based on the quality of the library and documentation, not on pure formalities.
I agree with your steering direction.
So let me ask a question: how useful is this library in practice, beyond "toy examples"?
Was this library developed with a real application, i.e. use in a product, as its motivation, or was it written to test the limits of what is possible using metaprogramming?
I think back before the C++ 11 STL the question of usefulness was more important than now as Boost becomes more heterogeneous. I note how many reviewers of Metaparse said they are not experts in that field, or would even expect to use Metaparse any time soon themselves. It's like with Edward's VMD library. I still cannot see the point of it. But others said it was useful to their niche cases, and VMD was clearly well designed, well tested, well polished and would be well maintained with Edward as maintainer. So I felt it was a good addition to Boost despite me personally not getting its point. In other words, I think we're moving from an era of "many need this so we'll build it" into an era of "I think this is cool, so I'll build it and if one or two other people come to use it then great". If I am right on that, it has profound consequences on what Boost is and how it works going into the future, especially as there is little incentive to buy into individual ivory towers from a user's perspective if that tower is locked into its maintainer. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 06/02/2015 05:03 PM, Niall Douglas wrote:
I think back before the C++ 11 STL the question of usefulness was more important than now as Boost becomes more heterogeneous. I note how many reviewers of Metaparse said they are not experts in that field, or would even expect to use Metaparse any time soon themselves.
Have you ever heard or seen a library like metaparse? None of us are experts in the field because I think it is new. I also think this is exactly the type of library that Boost has been known to promote in the past. It is like MPL or Fusion. I'm excited to see something like it again. michael -- Michael Caisse ciere consulting ciere.com
On 2 Jun 2015 at 17:42, Michael Caisse wrote:
I think back before the C++ 11 STL the question of usefulness was more important than now as Boost becomes more heterogeneous. I note how many reviewers of Metaparse said they are not experts in that field, or would even expect to use Metaparse any time soon themselves.
Have you ever heard or seen a library like metaparse?
To be honest I had always assumed the concept wasn't feasible as a practical library. I was very glad to learn I was wrong.
None of us are experts in the field because I think it is new.
This is ancillory to the argument that it has niche use cases, and that new C++ libraries have a trend of becoming more specialised and less general.
I also think this is exactly the type of library that Boost has been known to promote in the past. It is like MPL or Fusion. I'm excited to see something like it again.
I am also positive on the library Michael. I had been hoping to give it an unconditional yes vote in fact, all the boxes were ticked for me except the silly easy to fix ones. I think though there is an enormous difference in the C++ field of practice today compared to pre-Fusion. Before Fusion few of us had the wisdom to not push C++ as far as it could go. Now we've all been burned trying to use these fancy libraries in big real world applications, few of us are itching to repeat that experience. There has been a big shift back towards simpler is better, and you probably saw some of that in the recent argumentation about next gen futures where there was a faction who felt nothing is fundamentally wrong with present futures, and a faction who think them too big for what they ought to be. And that's just futures, which are ridiculously simple compared to anything Eric or you are writing every day, though I've noticed arguments about library primitives are often the most vicious. It's a big reason I always ask about scalability benchmarking for compile times and compiler memory use for the major compilers for TMP libraries. Too few do what Louis did before writing a single line of finished library where he benchmarked every TMP technique for time and space so he knew what not to do. Louis should really write those TMP technique benchmarks into a book and publish it and make some money for himself. I'm sure that Pearson editor lady I was talking to at C++ Now would consider such a book, if not I have some tech publisher who reached out to me not too long ago somewhere in my records. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas <s_sourceforge <at> nedprod.com> writes:
[...]
Louis should really write those TMP technique benchmarks into a book and publish it and make some money for himself. I'm sure that Pearson editor lady I was talking to at C++ Now would consider such a book, if not I have some tech publisher who reached out to me not too long ago somewhere in my records.
Niall, I appreciate the shout out, and I might consider writing a book about TMP after I survive my formal review. However, right now I'm working pretty hard on Hana's tutorial, which is slowly becoming like a small book BTW. Sometimes, I feel like a bad Shakespeare more than like a programmer. Louis
Hi Louis, On 2015-06-03 05:30, Louis Dionne wrote:
I appreciate the shout out, and I might consider writing a book about TMP after I survive my formal review. However, right now I'm working pretty hard on Hana's tutorial, which is slowly becoming like a small book BTW. Sometimes, I feel like a bad Shakespeare more than like a programmer.
If you generate a pdf from the Metaparse tutorial, it is over 30 pages. Tutorials can grow quickly. :) Regards, Ábel
On Jun 2, 2015 5:07 PM, "Niall Douglas" <s_sourceforge@nedprod.com> wrote:
In other words, I think we're moving from an era of "many need this so we'll build it" into an era of "I think this is cool, so I'll build it and if one or two other people come to use it then great".
If I am right on that, it has profound consequences on what Boost is and how it works going into the future, especially as there is little incentive to buy into individual ivory towers from a user's perspective if that tower is locked into its maintainer.
I think you are misunderstanding these libraries a bit. These aren't really niche in the sense that they are highly domain specific or odd curiosities that are simply "cool." Both this and VMD (and mpl and preprocessor and fusion and proto, etc.) are general tools whose primary consumers are other library developers. I understand that you don't immediately see the "I need this library to accomplish X end goal," but that's because these libraries aren't of most use directly to the end user. If you are developing libraries, and especially if you are developing EDSLs, that's where these libraries shine and why they are so important. Saying that they are niche undersells them a bit. MPL and preprocessor, for example, are/were an important dependency of many other important boost libraries, despite most top-level users not necessarily even being aware (except in the crazy compile-time errors, heh). My point is, things actually haven't changed in boost, here. We have always embraced libraries that make it easier to develop other libraries. In my personal opinion, these are the most valuable kinds of facilities that boost provides, since their existence can make even higher-level libraries actually tractable when they may not have appeared so before. If you are stuck on not seeing a direct usage of a library for your average programmer, try to take a step back and think about what libraries you can build on top of the library now that such a facility is available. There have been a handful of examples already that are very compelling and it's not too difficult to come up with more -- the design of effectively any EDSL in C++ can be impacted by a library such as this.
So let me ask a question: how useful is this library in practice, beyond "toy examples"?
Was this library developed with a real application, i.e. use in a product, as its motivation, or was it written to test the limits of what is possible using metaprogramming? This library was generalised from the original version of a type-safe
Hi Phil, On 2015-06-03 00:18, Phil Endecott wrote: printf (after realising that a "real" parser makes things much simpler).
My first reaction to the library was "cool!". My second reaction was "it's a toy to demonstrate metaprogramming". Then I saw the printf() example and my third (and for now final!) though is that, yes, this could be useful. I see it as a tool to build library interfaces. Here is a (yet unfinished) attempt to build an Xpressive frontend for example:
https://github.com/istvans/mpllibs/blob/master/libs/xlxpressive/example/comp... (the link points to an example comparing the new frontend to the original interface, the library lives in a fork of Mpllibs and has the same structure as the rest of the Mpllibs libraries). you can write MPLLIBS_REGEX("....") and that gets validated at compile-time. Another usage area (not published and to the best of my knowledge slightly explored) is writing SQL libraries that are checked at compile-time but don't change the SQL syntax. A third usage area (again, I'm not aware of it being explored) is generating runtime parsers from grammars (something like metaparse::grammar, but building a runtime parser instead of a compile-time one).
In another thread, Peter Dimov asked about getting char packs from string literals. It seems to me that if we had that then we could implement printf() without needing a "parser library" at all:
template <char c1, char... c> class formatter { public: template <typename... ARGS> void operator()(ARGS... args...) { std::cout << c1; formatter<c...>()(args...); } };
template <char... c> class formatter<'%','d',c...> { public: template <typename... ARGS> void operator()(int i, ARGS... args...) { std::cout << i; formatter<c...>()(args...); } };
template <char c1> class formatter<c1> { public: void operator()() { std::cout << c1; } };
int main() { formatter<'h','e','l','l','o','%','d','!'>()(42); }
So maybe all that I really want is the preprocessor magic to turn string literals into something that's more useful at compile time. Or a language feature to do that.
Or maybe somehow constexpr can do it all for me. Anyone have a constexpr implementation of printf()? This approach to write a type-safe printf displays the characters one-by-one on an output stream. The printf library in Mpllibs does the validation at compile-time and calls the "unsafe" printf at runtime (and has therefore no runtime overhead).
This does not necessarily mean that it is not possible to build validation using a recursive (pattern matching) approach for printf. However, note that the printf grammar is a bit more complicated than the most commonly used %d, %f, etc. (see http://www.cplusplus.com/reference/cstdio/printf/ for example). When you decide to support the full syntax, then it quickly gets complex (and that is where grammars and parser generators become helpful). Regards, Ábel
Abel Sinkovics wrote:
This approach to write a type-safe printf displays the characters one-by-one on an output stream. The printf library in Mpllibs does the validation at compile-time and calls the "unsafe" printf at runtime (and has therefore no runtime overhead).
Well that's assuming that printf() is efficient at runtime. I would like to hope that string s = "hello" + t + "world"; would be more efficient than string s = wrapper_around_printf_returning_string("hello%sworld",t.c_str()); If it isn't, we're in trouble :-) This reminds me of a discussion on this list back in 2008 where I was investigating fast ways of checking whether a character is in a compile-time set of characters: http://article.gmane.org/gmane.comp.lib.boost.devel/171117 In effect, I implement a template like is_any_of<'a','e','i','o','u'>(c) or better is_any_of<"aeiou">(c) to compute return c=='a' || c=='e' || c=='i' || c=='o' || c=='u'; In that thread, I demonstrated that this was faster than looping over the characters at run-time: bool is_any_of(const char* chars, char c) { return strchr(chars,c); } The challenge is to instead convert it to something that does O(log N) comparisons, rather than O(N) i.e. if (c < 'i') return is_any_of<'a','e'>(c); else return is_any_of<'i','o','u'>(c); Does this have any relevance to Metaparse? I'm not sure. I think the hard part of this is the "meta code generation", not the "meta parsing". I mention it because of the string-to-char-pack stuff. Regards, Phil.
Abel Sinkovics wrote:
This approach to write a type-safe printf displays the characters one-by-one on an output stream. The printf library in Mpllibs does the validation at compile-time and calls the "unsafe" printf at runtime (and has therefore no runtime overhead). Well that's assuming that printf() is efficient at runtime. I would like to hope that
string s = "hello" + t + "world";
would be more efficient than
string s = wrapper_around_printf_returning_string("hello%sworld",t.c_str());
If it isn't, we're in trouble :-) Given that the format string is known at compile-time, it should be
This reminds me of a discussion on this list back in 2008 where I was investigating fast ways of checking whether a character is in a compile-time set of characters:
http://article.gmane.org/gmane.comp.lib.boost.devel/171117
In effect, I implement a template like
is_any_of<'a','e','i','o','u'>(c)
or better
is_any_of<"aeiou">(c)
to compute
return c=='a' || c=='e' || c=='i' || c=='o' || c=='u';
In that thread, I demonstrated that this was faster than looping over the characters at run-time:
bool is_any_of(const char* chars, char c) { return strchr(chars,c); }
The challenge is to instead convert it to something that does O(log N) comparisons, rather than O(N) i.e.
if (c < 'i') return is_any_of<'a','e'>(c); else return is_any_of<'i','o','u'>(c);
Does this have any relevance to Metaparse? I'm not sure. I think the hard part of this is the "meta code generation", not the "meta parsing". I mention it because of the string-to-char-pack stuff. Your input in this case is very simple: a list of characters, which is
Hi Phil, On 2015-06-03 17:39, Phil Endecott wrote: possible to generate "optimal" code for it using a metaprogram. But that is significantly more complicated than what safe_printf currently offers. the input of the parsers, so "parsing" can't really add anything to it. Metaparse provides tools for implementing the "meta code generation" (transform, the fold parsers), but you still have to write it yourself (so the "how to do it" part is still on you). BOOST_MP_STRING could help you here making the interface more compact: is_any_of<BOOST_MP_STRING("aeiou")>(c) or if you wrap it with a custom macro IS_ANY_OF("aeiou")(c). I see Metaparse as a tool for improving the interface of the libraries. I couldn't get to the responses following your link, so I don't know if you have already investigated this, but if your goal is to implement it for one-byte characters, then you might be able to try an O(1) solution. Something like: ------- template <char X, char... Cs> struct has; template <char X> struct has<X> : std::false_type {}; template <char X, char... Cs> struct has<X, X, Cs...> : std::true_type {}; template <char X, char C, char... Cs> struct has<X, C, Cs...> : has<C, Cs...> {}; template <char... Cs> bool is_any_of(char c) { switch (c) { case 0: return has<0, Cs...>::type::value; case 1: return has<1, Cs...>::type::value; // ... case 'a': return has<'a', Cs...>::type::value; // ... } } ----- Of course this needs to be refined (eg. is char signed...?) but I hope you get the idea. Regards, Ábel
03.06.2015 23:45, Abel Sinkovics:
This approach to write a type-safe printf displays the characters one-by-one on an output stream. The printf library in Mpllibs does the validation at compile-time and calls the "unsafe" printf at runtime (and has therefore no runtime overhead). Well that's assuming that printf() is efficient at runtime. I would like to hope that
string s = "hello" + t + "world";
would be more efficient than
string s = wrapper_around_printf_returning_string("hello%sworld",t.c_str());
If it isn't, we're in trouble :-) Given that the format string is known at compile-time, it should be possible to generate "optimal" code for it using a metaprogram. But that is significantly more complicated than what safe_printf currently offers.
JFYI, I made small test some time ago with "formatting" stuff at compile-time (ad-hoc parsing, without Metaparse). https://github.com/panaseleus/ctte Following code: { int counter = 2; char character = '!'; double value = 0.5; for_each_part ( auto x, "val = $value$, cnt = $counter$, ch = $character$, again v=$value$;\n", counter, character, value ) { print_it(x); }; } Produces identical ASM code to handwritten version: { int counter = 2; char character = '!'; double value = 0.5; print_it("val = "); print_it(value); print_it(", cnt = "); print_it(counter); print_it(", ch = "); print_it(character); print_it(", again v="); print_it(value); print_it(";\n"); } Best Regards, Evgeny Panasyuk
Hi Evgeny On 2015-06-03 23:32, Evgeny Panasyuk wrote:
03.06.2015 23:45, Abel Sinkovics:
JFYI, I made small test some time ago with "formatting" stuff at compile-time (ad-hoc parsing, without Metaparse). https://github.com/panaseleus/ctte Very interesting. Not just the way you generate code, but also the way you pass string literals to metafunctions. Your variadic template + std::make_index_sequence trick seems to be able to replace the macro magic for compile-time string construction. It looks like BOOST_<whatever we end up with>_STRING could be improved with that (I'll have to check).
Note that you should be able to "store" the length of the string in what CTTE_WRAP_STRING constructs (you can get the length with sizeof or with "pattern matching" on the char array length) and then you can also deal with the corner case when a string literal contains \0 characters. Regards, Ábel
2015-06-04 13:52 GMT+08:00 Abel Sinkovics <abel@elte.hu>:
Hi Evgeny
On 2015-06-03 23:32, Evgeny Panasyuk wrote:
03.06.2015 23:45, Abel Sinkovics:
JFYI, I made small test some time ago with "formatting" stuff at compile-time (ad-hoc parsing, without Metaparse). https://github.com/panaseleus/ctte
Very interesting. Not just the way you generate code, but also the way you pass string literals to metafunctions. Your variadic template + std::make_index_sequence trick seems to be able to replace the macro magic for compile-time string construction. It looks like BOOST_<whatever we end up with>_STRING could be improved with that (I'll have to check).
Note that you should be able to "store" the length of the string in what CTTE_WRAP_STRING constructs (you can get the length with sizeof or with "pattern matching" on the char array length) and then you can also deal with the corner case when a string literal contains \0 characters.
It seems to use the similar trick that I posted in an older thread (you'd been there too): http://boost.2283326.n4.nabble.com/Compile-Time-String-in-C-14-tp4666747p466... We all know that it can't replace your STRING implementation since it cannot be used in unevaluated context. Here's a demo of toy compile-time parser that mimics Boost.Spirit: http://coliru.stacked-crooked.com/a/b5c0d0afd8255b81
Hi, On 2015-06-04 08:49, TONGARI J wrote:
It seems to use the similar trick that I posted in an older thread (you'd been there too): http://boost.2283326.n4.nabble.com/Compile-Time-String-in-C-14-tp4666747p466...
We all know that it can't replace your STRING implementation since it cannot be used in unevaluated context. You're right, I forgot about that thread.
Here's a demo of toy compile-time parser that mimics Boost.Spirit: http://coliru.stacked-crooked.com/a/b5c0d0afd8255b81 This trick here seems to be the same as in Evgeny's code: create a lambda function from the string and pass it to a template function as argument and use it *inside* the template function, so no need to put decltype around the expression containing the lambda (and therefore using lambda in an unevaluated context can be avoided).
Regards, Ábel
04.06.2015 8:52, Abel Sinkovics:
JFYI, I made small test some time ago with "formatting" stuff at compile-time (ad-hoc parsing, without Metaparse). https://github.com/panaseleus/ctte Very interesting. Not just the way you generate code, but also the way you pass string literals to metafunctions. Your variadic template + std::make_index_sequence trick seems to be able to replace the macro magic for compile-time string construction. It looks like BOOST_<whatever we end up with>_STRING could be improved with that (I'll have to check).
I am still using lambda in order to get type with string inside: https://github.com/panaseleus/ctte/blob/master/proof_of_concept/proof_of_con... Perhaps we should have two versions? Like: BOOST_<whatever we end up with>_STRING_TYPE and BOOST_<whatever we end up with>_STRING_VALUE or *_LAMBDA In this format-processing case *_VALUE version was perfectly fine, without any trade-off.
Note that you should be able to "store" the length of the string in what CTTE_WRAP_STRING constructs (you can get the length with sizeof or with "pattern matching" on the char array length) and then you can also deal with the corner case when a string literal contains \0 characters.
I agree, I haven't thought about corner case with \0 in the middle of string. -- Evgeny Panasyuk
Hi Evgeny, On 2015-06-04 09:44, Evgeny Panasyuk wrote:
I am still using lambda in order to get type with string inside: https://github.com/panaseleus/ctte/blob/master/proof_of_concept/proof_of_con...
Perhaps we should have two versions? Like: BOOST_<whatever we end up with>_STRING_TYPE and BOOST_<whatever we end up with>_STRING_VALUE or *_LAMBDA
In this format-processing case *_VALUE version was perfectly fine, without any trade-off. Unfortunately the lambda trick does not work in general (so not good for BOOST_<...>_STRING), because you are not allowed to use a lambda inside a decltype, so you can use it only as long as you pass the lambda object to a template function (and use type deduction to get its type).
Regards, Ábel
I am still using lambda in order to get type with string inside: https://github.com/panaseleus/ctte/blob/master/proof_of_concept/proof_of_con...
Perhaps we should have two versions? Like: BOOST_<whatever we end up with>_STRING_TYPE and BOOST_<whatever we end up with>_STRING_VALUE or *_LAMBDA
In this format-processing case *_VALUE version was perfectly fine, without any trade-off. Unfortunately the lambda trick does not work in general (so not good for BOOST_<...>_STRING), because you are not allowed to use a lambda inside a decltype, so you can use it only as long as you pass the lambda object to a template function (and use type deduction to get its type).
Yes, this is why I propose to use special name for macro with lambda inside, and describe limitations in documentation. As I understand, currently there is trade-off between using labmda for compile-time string and other techniques like "macro iteration". So, by providing two versions we postpone decision to library user. Of course I expect that in future ISO C++ versions we would have some better option. Best Regards, Evgeny Panasyuk
Hi Evgeny, On 2015-06-04 21:36, Evgeny Panasyuk wrote:
Yes, this is why I propose to use special name for macro with lambda inside, and describe limitations in documentation. As I understand, currently there is trade-off between using labmda for compile-time string and other techniques like "macro iteration". So, by providing two versions we postpone decision to library user. Of course I expect that in future ISO C++ versions we would have some better option.
It will need to be done in a way not to confuse the library users (so what is the difference? which one should I use? why? etc). Note that when someone creates a library interface with this, people using his library are likely to create compile-time strings (eg. when someone is writing a regex, dot graph, etc). Regards, Ábel
Hi Edward, Thank you for the review. On 2015-06-02 20:05, Edward Diener wrote:
The original metaparse library was represented as a library within mpllibs in the old Boost directory structure. The documentation of this library was entirely a tutorial of the library.
The tutorial is just a part of the documentation. See http://abel.web.elte.hu/mpllibs/metaparse
But a tutorial by itself is inadequate as documentation to a Boost library. Documentation needs a reference of all the classes, functions, data, macros of the library whether it is a library of meatfunctions or a library of run-time constructs. Furthermore some explanation of how the different parts of the library are organized and meant to be used within that organization is needed in documentation is necessary for me to understand a software library. So while I would rate the tutorial as excellent the documentation was inadequate. You can find the reference here: http://abel.web.elte.hu/mpllibs/metaparse/reference.html
Sometime during the review process the presentation of what was being reviewed completely changed. A new version of the library was presented using the current Boost directory structure, with a very full documentation set and the link to the tutorial documentation in the original version being reviewed was removed. What was being reviewed remained the same. I have created a reformatted (namespace/macro renaming from mpllibs -> boost and removal of the parts not part of the review in the first place) version of the code based on
I agree that a description of the overall design of the library could be added to the documentation. The tutorial has been designed in a way to show the common patterns (by example) of how the library is expected to be used. (Tokenisation, sequence, repetition, operators with precedence, parens, errors, etc). the feedback of the reviewers. Regards, Ábel
Hello Abel and Christophe - First off, thank you Abel for submitting such an amazing library. The quality of the documentation and code is wonderful and it has been a pleasure to review Metaparse. Thank you Christophe for taking time to act as a review manager. I reviewed Abel's updated version that follows the newer modular layout: <https://github.com/sabel83/metaparse> I used the documentation link that was originally posted. On 05/19/2015 02:39 PM, Christophe Henry wrote:
And a very complete tutorial:
http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html
The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library:
I had some trouble using the on-line version of metashell. It kept timing out. I downloaded a recent version and struggled with the setup for a bit trying to get the include paths correct. Metashell is a very neat utility; however, you might want to add a quick start appendix for using Metashell (local version) with Metaparse considering the examples are illustrated using the tool.
Boost.Msm v3 also implements a new compile-time strings based front-end called eUML2 to demonstrate the power of the library and the conciseness and expressiveness it allows. Please have a look at the documentation:
https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/ms...
Christophe, this is wonderful work and a great example of the usefulness of Metaparse. Can you comment on the compile time compared to eUML? I perused the implementation of eUML2 as an example of using Metaparse in a "real" program. The code is very readable. Kudos!
- What is your evaluation of the design?
- Looks clean and what one might expect for a TMP library needing to support C++-98 compilers.
- What is your evaluation of the implementation?
- When renaming macros, please don't just change/replace MPLLIBS to BOOST. There are several (all?) (MPLLIBS_STRING, MPLLIBS_DEFINE_ERROR, ...) where this isn't going to work. Perhaps BOOST_MPARSE_ would be a good replacement. I'm not opposed to BOOST_METAPARSE_. - Helper include files are nice. metaparse/all.hpp or something like that. I find when I an first working out a solution that having everything included allows me to just concentrate on the grammar details. The calculator_with_parens_and_unary_ops example has 16 individual metaparse includes!
- What is your evaluation of the documentation?
Excellent Getting Started! I believe others have also mentioned the "...>" prompt in the metashell examples results in some initial confusion. I found the User Manual and the Library reference approachable and well written. I only briefly looked through the Tutorial. Nice job on the documentation. Refreshing!
- What is your evaluation of the potential usefulness of the library?
I believe that this library could be very useful in making cleaner interfaces for other libraries. I see it as a tool in creating libraries like MPL or Fusion -- a tool that can be employed to create a more natural interface. I'm looking forward to trying it out.
- Did you try to use the library?
Just the examples and modified versions of those.
- With what compiler?
gcc 5.1
- Did you have any problems?
Jamfiles had to be modified to force c++11 mode and a larger template depth.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
~ 8-hours
- Are you knowledgeable about the problem domain?
No. I believe metaparse should be accepted as a Boost library! Best regards - Michael -- Michael Caisse ciere consulting ciere.com
Hi Michael, Thank you for the review. On 2015-06-08 09:37, Michael Caisse wrote:
I had some trouble using the on-line version of metashell. It kept timing out. I downloaded a recent version and struggled with the setup for a bit trying to get the include paths correct. Metashell is a very neat utility; however, you might want to add a quick start appendix for using Metashell (local version) with Metaparse considering the examples are illustrated using the tool. I'll add that.
- When renaming macros, please don't just change/replace MPLLIBS to BOOST. There are several (all?) (MPLLIBS_STRING, MPLLIBS_DEFINE_ERROR, ...) where this isn't going to work. Perhaps BOOST_MPARSE_ would be a good replacement. I'm not opposed to BOOST_METAPARSE_. Sure, they won't remain BOOST_STRING, BOOST_DEFINE_ERROR, etc).
- Helper include files are nice. metaparse/all.hpp or something like that. I find when I an first working out a solution that having everything included allows me to just concentrate on the grammar details. The calculator_with_parens_and_unary_ops example has 16 individual metaparse includes! I'll add a metaparse.hpp that includes everything. I think that is the most straight forward thing to do here.
I believe others have also mentioned the "...>" prompt in the metashell examples results in some initial confusion. The first time it appears in the tutorial, it might be explained. I find the "...>" prompt making it clear what the user is supposed to type and what the response is (or is expected to be). With the links to the copy-paste friendly version of the code examples, they should be fine.
Jamfiles had to be modified to force c++11 mode and a larger template depth. Is there a way of telling the Jamfiles to use c++11/c++14 if supported?
Regards, Ábel
participants (23)
-
Abel Sinkovics -
Andrey Semashev -
Christophe Henry -
christophe.j.henry＠gmail.com
-
Edward Diener -
Evgeny Panasyuk -
Gavin Lambert -
Glen Fernandes -
Josh Juran -
Louis Dionne -
Matt Calabrese -
Michael Caisse -
Nevin Liber -
Niall Douglas -
Paul A. Bristow -
Paul Fultz II -
Peter Dimov -
Phil Endecott -
Rene Rivera -
Rob Stewart -
Robert Ramey -
Tim Blechmann -
TONGARI J