Proposal: Add Loki Library's SafeFormat to Boost:
The last Loki thread I see here is the one from 2002 discussing adding Loki to Boost. I asked Andrei once about doing that specifically for the Loki SafeFormat functions (FPrint, Printf, and SPrintf) and he said FPrintf wasn't good enough yet. However, I find all of them very useful and would love to see them added to the Boost library I know Boost has Format now, but SafeFormat has some advantages over Boost.Format, one of which is that FPrintf can be output to C++ streams as well as to FILE pointers--very handy when one is gradually converting legacy code to using C++ streams. In addition, I find the SafeFormat family much easier to use than Boost.Format. Andrei's original comments regarding FPrintf's shortcomings are here: https://sourceforge.net/forum/message.php?msg_id=4525195 His "Dr. Dobb's Journal" article describing SafeFormat is here: http://www.ddj.com/cpp/184401987 Thank you for your consideration. Warmest regards, -Tom Tom Browder Niceville, Florida USA
Tom Browder wrote:
The last Loki thread I see here is the one from 2002 discussing adding Loki to Boost.
Why would you want to add Loki to Boost? - One good reason would be to allow boost libraries to rely on Loki libraries. Are there examples where this would be beneficial? - Another reason might be to reduce overlap between Loki and Boost, thereby enabling clearer recommendations to user as to which library to use for a certain task. However, the question I'm now asking to you came to my mind earlier when reading an "Interest check on logging library": http://lists.boost.org/Archives/boost/2008/12/146500.php The author writes "I know there are two proposed logging libraries out there for Boost, already, but I had a different itch to scratch on a project.", but googling for "c++ logging" showed that there are many mature logging libraries for c++ out there. The interesting thing was that some of the more actively maintained libraries seemed to be associated with some "larger" project already (log4cxx -> http://logging.apache.org/, Pantheios -> http://www.stlsoft.org/), so they were definitely not candidates for a "boost-logging" library. So I asked myself why one would want to have a special "boost-logging" library, and one good reason I could see was to allow other boost libraries to rely on this library (like they rely on boost-test). One drawback that I could see was that the "boost-logging" library would probably not end up being the fastest logging library out there (http://www.pantheios.org/performance.html). The same will probably be true for the "Boost.Format" library (http://www.fastformat.org/performance.html).
I asked Andrei once about doing that specifically for the Loki SafeFormat functions (FPrint, Printf, and SPrintf) and he said FPrintf wasn't good enough yet.
So what would be the advantages of having Loki's SafeFormat library in boost? Do other boost libraries currently rely on "boost-format" and could rely on "boost-fastformat" instead, if it were part of boost? I don't know, but it should be easy to find out. What would be the consequences of "cherry-picking" libraries from Loki for inclusion into boost? I don't know, but I somehow have the impression that whether FPrintf is good enough is not the major open question here.
However, I find all of them very useful and would love to see them added to the Boost library
I use both Loki and Boost side by side, and see no problems with this approach. There is some overlap in functionality with respect to "Function objects" and "Smart pointers", but I guess this is just a sign that the stl is lacking in this area. A strength of Loki is that it is so well designed that it is possible to cherry pick libraries from it. However, actually doing this seems to undermine the continued maintenance of the Loki library. Loki doesn't depend on boost, so as soon as a Loki library would be included into boost, Loki could no longer depend on it (or one would have to come up with a way to avoid conflicts between the same library in boost and in Loki). But this would give the impression that the remaining Loki library is just what wasn't good enough for inclusion into boost. There must be other ways of coexistence between boost and other library-collections than inclusion of the other library-collection into boost. Perhaps some sort of documentation of library-collections somehow "related" to boost, and some recommendations of how to use them together, maybe also some words about their overlap.
I know Boost has Format now, but SafeFormat has some advantages over Boost.Format, one of which is that FPrintf can be output to C++ streams as well as to FILE pointers--very handy when one is gradually converting legacy code to using C++ streams. In addition, I find the SafeFormat family much easier to use than Boost.Format.
I just took a look at the introduction of the Boost.Format documentation: The format library provides a class for formatting arguments according to a format-string, as does printf, but with two major differences : * format sends the arguments to an internal stream, and so is entirely type-safe and naturally supports all user-defined types. * The ellipsis (...) can not be used correctly in the strongly typed context of format, and thus the function call with arbitrary arguments is replaced by successive calls to an argument feeding operator% You can find more Details in : ... The line "and naturally supports all user-defined types." makes me wonder how SafeFormat supports user-defined types. On the other hand, this question might be less important than it looks at first sight, and the solution adopted by Boost.Format might give a false sense of security with respect to user-defined types.
Andrei's original comments regarding FPrintf's shortcomings are here:
This thread doesn't seem to be about inclusion of SafeFormat into boost, but just about how a specific (technical) shortcoming in SafeFormat should be addressed. So I have the impression that Andrei didn't really answer to your question about proposing SafeFormat as a boost library.
His "Dr. Dobb's Journal" article describing SafeFormat is here:
That's an interesting article, but I guess I will just use Boost.Format with less reservations now (because its main drawback seems to be that it is slow, but that is totally unimportant for my use-cases). The other valid point is that there is no scanf counterpart. However, scanf is not really my favorite, and parsing input seems to me like a completely different problem from formating output. Does SafeFormat really contains functionality similar for scanf for parsing input?
Thank you for your consideration.
Thank you for helping to maintain Loki. You should interpret my comments as the comments of a user of both Boost and Loki, who's main concern is to have good and well maintained c++ libraries that help him get his job done. Regards, Thomas
On Wed, Dec 31, 2008 at 8:02 AM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
So what would be the advantages of having Loki's SafeFormat library in boost?
As far as I know, nothing in boost relies on SafeFormat. The advantages of adding it to boost include: (1) active maintenance [Loki maintenance interest is fading rapidly] and (2) boost (and thus SafeFormat) is included and supported with many main GNU/Linux distributions.
A strength of Loki is that it is so well designed that it is possible to cherry pick libraries from it. > However, actually doing this seems to undermine the continued maintenance of the Loki library. Loki
Again, Loki maintenance seems to be fading. I'm pretty sure that Andrei would agree to allow SafeFormat to be removed from Loki (with a pointer to Boost remaining on the Loki site).
But this would give the impression that the remaining Loki library is just what wasn't good enough for inclusion into boost.
That may be an impression, but that I don't believe should be a show stopper. Any remaining Loki maintainers could ensure an appropriate message on the Loki site.
The line "and naturally supports all user-defined types." makes me wonder how SafeFormat supports user-defined types.
I'm not sure that it does. The main thing it does is provide a safe version of the printf family.
Andrei's original comments regarding FPrintf's shortcomings are here:
This thread doesn't seem to be about inclusion of SafeFormat into boost,
Actually, the thread started earlier. The previous msg is where I asked about adding SafeFormat to Boost: http://sourceforge.net/forum/message.php?msg_id=4524896 and the whole thread began here: http://sourceforge.net/forum/message.php?msg_id=4522502
Does SafeFormat really contains functionality similar for scanf for parsing input?
I can't answer because I have no need for scanf (but I don't think that was ever completed).
Thank you for helping to maintain Loki.
You're very generous, Thomas--I just added a little bit for my own use of SafeFormat.
You should interpret my comments as the comments of a user of both Boost and Loki, who's main concern is to have good and well maintained c++ libraries that help him get his job done.
We certainly agree on that! Regards, -Tom
on Wed Dec 31 2008, "Tom Browder" <tom.browder-AT-gmail.com> wrote:
On Wed, Dec 31, 2008 at 8:02 AM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
So what would be the advantages of having Loki's SafeFormat library in boost?
As far as I know, nothing in boost relies on SafeFormat. The advantages of adding it to boost include: (1) active maintenance [Loki maintenance interest is fading rapidly] and (2) boost (and thus SafeFormat) is included and supported with many main GNU/Linux distributions.
If SafeFormat has a maintenance deficit as part of Loki, it would have the same deficit as part of Boost. Also, you might want to take a look at http://www.boost.org/development/submissions.html to see whether you can suggest something that fits with the Boost process. Things don't just get added; they have to pass through a review process first. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Jan 1, 2009 at 1:03 AM, David Abrahams <dave@boostpro.com> wrote:
As far as I know, nothing in boost relies on SafeFormat. The advantages of adding it to boost include: (1) active maintenance [Loki maintenance interest is fading rapidly] and (2) boost (and thus ... If SafeFormat has a maintenance deficit as part of Loki, it would have the same deficit as part of Boost.
But I believe there is a wider audience here, thus possibly more recruits. And there is at least one other Loki supporter who supports a move to Boost if possible.
Also, you might want to take a look at http://www.boost.org/development/submissions.html to see whether you can suggest something that fits with the Boost process. Things don't just
I looked at it before--this is the soliciting interest stage. Quote. Determine interest Potential library submitters should use the Boost developers mailing list as a forum to gauge interest [in] a possible submission. End quote. -Tom
on Thu Jan 01 2009, "Tom Browder" <tom.browder-AT-gmail.com> wrote:
On Thu, Jan 1, 2009 at 1:03 AM, David Abrahams <dave@boostpro.com> wrote:
As far as I know, nothing in boost relies on SafeFormat. The advantages of adding it to boost include: (1) active maintenance [Loki maintenance interest is fading rapidly] and (2) boost (and thus ... If SafeFormat has a maintenance deficit as part of Loki, it would have the same deficit as part of Boost.
But I believe there is a wider audience here, thus possibly more recruits. And there is at least one other Loki supporter who supports a move to Boost if possible.
Supporting the idea of a move to Boost is not remotely the same as being a maintainer of that library.
Also, you might want to take a look at http://www.boost.org/development/submissions.html to see whether you can suggest something that fits with the Boost process. Things don't just
I looked at it before--this is the soliciting interest stage.
Quote.
Determine interest
Potential library submitters should use the Boost developers mailing list as a forum to gauge interest [in] a possible submission.
OK, but what's missing is someone behind the solicitation who is clearly taking responsibility for the code, prepared to take it through a formal review, and willing to maintain it for the forseeable future. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Tom Browder wrote:
As far as I know, nothing in boost relies on SafeFormat. The advantages of adding it to boost include: (1) active maintenance [Loki maintenance interest is fading rapidly] and
Don't confuse active development with active maintenance. The Loki developers quickly respond to questions, which indicates active maintenance. Adding SafeFormat to boost would probably induce some form of active development (like improving documentation and regression tests to conform to boost standards), but probably just for a limited time. Many people today seem to think that things have to constantly change to be "alive". I personally see no problems if Loki just does a release every three years. Boost currently does four releases per year, if I'm not mistaken, but so what? What would be the advantages to the users of Loki if it would have four releases per year?
(2) boost (and thus SafeFormat) is included and supported with many main GNU/Linux distributions.
But I somehow got the impression that this created more problems for boost-users than it solved. People are often advised to use the distribution from boost.org instead of the one that comes with their GNU/Linux distribution, because these packages seem to have subtle issues.
A strength of Loki is that it is so well designed that it is possible to cherry pick libraries from it. > However, actually doing this seems to undermine the continued maintenance of the Loki library. Loki
Again, Loki maintenance seems to be fading.
But adding SafeFormat to boost would not help me with this, if my code relies much more on Loki.Singleton than on Loki.SafeFormat. So again, cherry picking libraries from Loki doesn't look like a good solution for this problem to me.
But this would give the impression that the remaining Loki library is just what wasn't good enough for inclusion into boost.
That may be an impression, but that I don't believe should be a show stopper. Any remaining Loki maintainers could ensure an appropriate message on the Loki site.
And what about an appropriate message on the Boost site? Think about why you want to include Loki.SafeFormat into Boost. I guess because it is important to you. But then, if Loki.Singleton is important to me, should I also try to get it included into Boost? But suppose there would be another library collection called StlSoft. Should users with special interest in a specific library from that collection now try to get this specific library included into Boost? I don't think so. It may be a different story if it is the developer of the specific library that tries to get it included into Boost.
This thread doesn't seem to be about inclusion of SafeFormat into boost,
Actually, the thread started earlier. The previous msg is where I asked about adding SafeFormat to Boost:
I did read that thread, and I came to the conclusion that you read more into Andrei's response than he has actually said. This also made me careful with respect to your answer in another post:
David Abrahams wrote:
If SafeFormat has a maintenance deficit as part of Loki, it would have the same deficit as part of Boost.
But I believe there is a wider audience here, thus possibly more recruits. And there is at least one other Loki supporter who supports a move to Boost if possible.
Do you refer to the thread http://sourceforge.net/forum/forum.php?thread_id=2593488&forum_id=93010 ? The "Loki supporter" just wrote "Loki is great and I still use it but I wish it were integrated to Boost." I don't have the impression that this "Loki supporter" has expressed his support for cherry picking libraries from Loki for inclusion into Boost. If I would have made that statement, the integration of Loki into Boost would be more related to facilities like "typelist", "functor" and "smart pointer", that are present in both Loki and Boost.
Does SafeFormat really contains functionality similar for scanf for parsing input?
I can't answer because I have no need for scanf (but I don't think that was ever completed).
Hartmut Kaiser's answer that Spirit V2 supports both input parsing with Spirit.Qi and output formating with Spirit.Karma makes me inclined to be against the inclusion of SafeFormat into boost. In any case, I will now take a deeper look at Spirit.Karma to see whether it is really as nice as I expect. But as indicated earlier, the reason that I replied to your post is not really related to SafeFormat. I'm more interested in the relation of boost to other library collections, because I think that there must be more option of coexistence than reinvention or inclusion. Regards, Thomas
The last Loki thread I see here is the one from 2002 discussing adding Loki to Boost. I asked Andrei once about doing that specifically for the Loki SafeFormat functions (FPrint, Printf, and SPrintf) and he said FPrintf wasn't good enough yet.
However, I find all of them very useful and would love to see them added to the Boost library
I know Boost has Format now, but SafeFormat has some advantages over Boost.Format, one of which is that FPrintf can be output to C++ streams as well as to FILE pointers--very handy when one is gradually converting legacy code to using C++ streams. In addition, I find the SafeFormat family much easier to use than Boost.Format.
Andrei's original comments regarding FPrintf's shortcomings are here:
https://sourceforge.net/forum/message.php?msg_id=4525195
His "Dr. Dobb's Journal" article describing SafeFormat is here:
I know this has been touched before (at least during the library in a week sessions at BoostCon 2007/2008). Furthermore, the topic of adding some output formatting facilities to Boost pops up occasionally. So, please let me use this thread for a selfless plug :-P. Boost already has a versatile and powerful output formatting library: Spirit V2! You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have problems using Spirit.Karma either. Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point. Regards Hartmut
Hartmut Kaiser wrote:
You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have problems using Spirit.Karma either. Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users. The fact that names are in no way descriptive is another huge time waster. Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review? Robert Ramey
Robert Ramey wrote:
Hartmut Kaiser wrote:
You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have problems using Spirit.Karma either. Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster.
I'd like to second that concern. I know, this is your library and you are to decide how to name it, but all these words, like Spirit, Qi, Proto or Karma, tell me nothing about what these things are for.
Mathias Gaunard wrote:
Andrey Semashev wrote:
I'd like to second that concern. I know, this is your library and you are to decide how to name it, but all these words, like Spirit, Qi, Proto or Karma, tell me nothing about what these things are for.
Actually, Proto does.
Well, not to me. I may be missing something, though...
Andrey Semashev wrote:
Mathias Gaunard wrote:
Andrey Semashev wrote:
I'd like to second that concern. I know, this is your library and you are to decide how to name it, but all these words, like Spirit, Qi, Proto or Karma, tell me nothing about what these things are for.
Actually, Proto does.
Well, not to me. I may be missing something, though...
Proto means "first", "before" or "ancestor". It's the base language you use to describe new ones. It could also stand for prototyping, I guess. Anyway it's not as unrelated as Phoenix, Karma or Qi.
Andrey Semashev wrote:
Robert Ramey wrote:
Hartmut Kaiser wrote:
You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have problems using Spirit.Karma either. Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster.
I'd like to second that concern. I know, this is your library and you are to decide how to name it, but all these words, like Spirit, Qi, Proto or Karma, tell me nothing about what these things are for.
So does Haskell, or Python, or Loki, Rails, or even Boost. But so what? I don't understand the problem. It takes a few seconds to know that Boost is (a set of) "free peer-reviewed portable C++ source libraries". Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Andrey Semashev wrote:
Robert Ramey wrote:
Hartmut Kaiser wrote: The fact that names are in no way descriptive is another huge time waster.
I'd like to second that concern. I know, this is your library and you are to decide how to name it, but all these words, like Spirit, Qi, Proto or Karma, tell me nothing about what these things are for.
So does Haskell, or Python, or Loki, Rails, or even Boost. But so what? I don't understand the problem. It takes a few seconds to know that Boost is (a set of) "free peer-reviewed portable C++ source libraries".
I disagree. Programming languages usually are difficult to describe in one word that would outline its specific features. Although, Lisp and Basic are quite descriptive even then. Boost, Loki, etc. are library collections that help people in very different domains, so it's difficult to come with descriptive names for them, too. However, IIRC, Andrei has outlined rationale for his library name in his book. But we are talking about Boost components that have a well defined usage domain and a set of tasks they are intended to help in. Function, Bind, Variant, Filesystem, DateTime - when I see these names I already grasp what sort of things they are, and I don't have to dig into docs for that. When I see Spirit - I don't. BTW, on the library requirements page, there's a recommendation to use meaningful names for C++ symbols. I don't see why it doesn't apply to the library names, too. In connection to other posts in this thread: no, I don't think that Spirit is a library with a difficult to describe usage domain. It's a parsing library and let's leave it at that. The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost. The situation with so-called sub-libraries, IMHO, is a bad thing to allow in Boost. This turns libraries like Spirit into a playground where actually live several libraries with totally different classes of tasks being solved. What's worse, these libraries don't get reviewed (which may be a tempting reason to add such libraries), they duplicate other existing libraries in Boost (which confuse users), and they honor further duplication in the upcoming libraries (which wastes time of these libraries' developers).
Andrey Semashev wrote:
Joel de Guzman wrote:
Andrey Semashev wrote:
Robert Ramey wrote:
Hartmut Kaiser wrote: The fact that names are in no way descriptive is another huge time waster.
I'd like to second that concern. I know, this is your library and you are to decide how to name it, but all these words, like Spirit, Qi, Proto or Karma, tell me nothing about what these things are for.
So does Haskell, or Python, or Loki, Rails, or even Boost. But so what? I don't understand the problem. It takes a few seconds to know that Boost is (a set of) "free peer-reviewed portable C++ source libraries".
I disagree. Programming languages usually are difficult to describe in one word that would outline its specific features. Although, Lisp and Basic are quite descriptive even then.
Boost, Loki, etc. are library collections that help people in very different domains, so it's difficult to come with descriptive names for them, too. However, IIRC, Andrei has outlined rationale for his library name in his book.
You can disagree as much as you want. You can rationalize as much as you want. Well, programmers tend to do so. As far as I am concerned, a name is a name and I, as author, reserve the right to naming my work.
But we are talking about Boost components that have a well defined usage domain and a set of tasks they are intended to help in. Function, Bind, Variant, Filesystem, DateTime - when I see these names I already grasp what sort of things they are, and I don't have to dig into docs for that. When I see Spirit - I don't. BTW, on the library requirements page, there's a recommendation to use meaningful names for C++ symbols. I don't see why it doesn't apply to the library names, too.
In connection to other posts in this thread: no, I don't think that Spirit is a library with a difficult to describe usage domain. It's a parsing library and let's leave it at that.
Are you suggesting that Spirit be renamed to Boost Parsing Library? Sorry, but no thanks.
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost.
I disagree. Karma was never advertized as a top-level Boost Library. It is a Spirit sub-library. Parsing and generation are two sides of the same coin.
The situation with so-called sub-libraries, IMHO, is a bad thing to allow in Boost. This turns libraries like Spirit into a playground where actually live several libraries with totally different classes of tasks being solved. What's worse, these libraries don't get reviewed (which
Phoenix and Fusion got reviewed. They were once sub-libraries under Spirit. Proto got reviewed. It was once a sub-library under Xpressive.
may be a tempting reason to add such libraries), they duplicate other existing libraries in Boost (which confuse users), and they honor further duplication in the upcoming libraries (which wastes time of these libraries' developers).
Which upcoming libraries are you referrring to? Could you be more specific? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
You can disagree as much as you want. You can rationalize as much as you want. Well, programmers tend to do so. As far as I am concerned, a name is a name and I, as author, reserve the right to naming my work.
Now that's a very "constructive" approach, I must say. Yes, you may name it as you like, but if the name is nothing but a funny word to you, you just push away users of your library. Unless you don't care about that, that is...
Are you suggesting that Spirit be renamed to Boost Parsing Library? Sorry, but no thanks.
I understand that it's too late to rename the library now. However, I'd like to ask to reconsider naming of yet to be released libraries, like Karma or Qi (or what was it?).
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost.
I disagree. Karma was never advertized as a top-level Boost Library.
It should, IMO.
It is a Spirit sub-library. Parsing and generation are two sides of the same coin.
These tasks are the opposite. I don't see why they should be mixed in a single library.
The situation with so-called sub-libraries, IMHO, is a bad thing to allow in Boost. This turns libraries like Spirit into a playground where actually live several libraries with totally different classes of tasks being solved. What's worse, these libraries don't get reviewed (which
Phoenix and Fusion got reviewed. They were once sub-libraries under Spirit. Proto got reviewed. It was once a sub-library under Xpressive.
How long did they exist as parts of Spirit? Were they approved to be included as parts of Spirit and/or recommended/allowed to be used independently? Why would Spirit contain a duplicate for Lambda and how they can (or should they?) coexist gracefully in the user's code? Which one should be used by default? These questions may sound silly to you, but I recently happened to write an article about Boost libraries, and such questions took a lot of time to answer. I believe, every developer exploring Boost will stumble on such questions sooner or later.
may be a tempting reason to add such libraries), they duplicate other existing libraries in Boost (which confuse users), and they honor further duplication in the upcoming libraries (which wastes time of these libraries' developers).
Which upcoming libraries are you referrring to? Could you be more specific?
I was saying in general. The current state of code in the repository introduces the "common practice" which can be followed by the new library authors.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrey Semashev wrote:
How long did they exist as parts of Spirit? Were they approved to be included as parts of Spirit and/or recommended/allowed to be used independently?
Should adding new functionality or changing implementation details in an accepted boost library cause a re-review? That's what I hear you saying in the above. I know I'm stretching "implementation detail" a bit regarding Spirit, but in general...
Why would Spirit contain a duplicate for Lambda and how they can (or should they?) coexist gracefully in the user's code? Which one should be used by default?
Should one? Is it bad for boost to contain two libraries covering the same domain? I always thought of boost as a "winnowing grounds" for libraries. If we do have two lambda (or whatever) libraries, both can be tested in the real world. Eventually, probably, one or the other will retire, but who can currently say which?
These questions may sound silly to you, but I recently happened to write an article about Boost libraries, and such questions took a lot of time to answer. I believe, every developer exploring Boost will stumble on such questions sooner or later.
Not silly, really. I just think that boost is a special place as software libraries go, and doubling on functionality here is not as much a crime, as it would be in some other libraries. IOW I don't think either should be used "by default". People should choose the library that best suits their needs. /Brian R. Riis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJXkWhk1tAOprY6QERAspZAKDhTkJYug0Fb+WTpzcpKhHj5se4cQCeJOdR SUeZOcPnofN+MRynlEDC104= =EGKr -----END PGP SIGNATURE-----
Brian Ravnsgaard Riis wrote:
Andrey Semashev wrote:
How long did they exist as parts of Spirit? Were they approved to be included as parts of Spirit and/or recommended/allowed to be used independently?
Should adding new functionality or changing implementation details in an accepted boost library cause a re-review? That's what I hear you saying in the above. I know I'm stretching "implementation detail" a bit regarding Spirit, but in general...
No, I'm not saying that every change in the library implementation should be reviewed. But in case of Karma we have a major change in the Spirit feature set, and the new functionality is not related to parsing (the domain, in which Spirit was once proposed and reviewed). Such changes, IMO, should be reviewed, because they are equivalent to a new library submission.
Why would Spirit contain a duplicate for Lambda and how they can (or should they?) coexist gracefully in the user's code? Which one should be used by default?
Should one? Is it bad for boost to contain two libraries covering the same domain? I always thought of boost as a "winnowing grounds" for libraries. If we do have two lambda (or whatever) libraries, both can be tested in the real world. Eventually, probably, one or the other will retire, but who can currently say which?
That is a good point if taken from the Boost point of view. As for users, such duplication really complicates their lives. A user has to learn both libraries, chose what he likes more and then get caught by surprise because his fellow co-worker have chosen the other one.
Andrey Semashev wrote:
Joel de Guzman wrote:
You can disagree as much as you want. You can rationalize as much as you want. Well, programmers tend to do so. As far as I am concerned, a name is a name and I, as author, reserve the right to naming my work.
Now that's a very "constructive" approach, I must say. Yes, you may name it as you like, but if the name is nothing but a funny word to you, you just push away users of your library. Unless you don't care about that, that is...
I'm sure everybody knows what Boost is? Are we considering renaming to "Peer Reviewed Formative C++ Library Collection". Sorry if that's a slightly silly example, but we cope with names such as Google, Boost, Spirit, Qi, Karma etc. every day, it takes very little time to get used to them. The more explicit names aren't always more helpful, renaming Fusion to "heterogeneous container library" would IMO be a backward step for example. IMO library authors should be left to pick the names, and Boost should not waste valuable time over analyzing them.
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost.
I disagree. Karma was never advertized as a top-level Boost Library.
It should, IMO.
It is a Spirit sub-library. Parsing and generation are two sides of the same coin.
These tasks are the opposite. I don't see why they should be mixed in a single library.
Precisely because, as you say they are opposite (dual) to each other, and so present a good opportunity to address some missing symmetry in previous versions of spirit. I personally believe we should lean towards allowing authors creative freedom, even if they do grow the scope of their libraries. It's difficult enough for Boost to recruit sufficient high quality developers to produce libraries the community need. Regards Dan
dan marsden wrote:
I'm sure everybody knows what Boost is? Are we considering renaming to "Peer Reviewed Formative C++ Library Collection". Sorry if that's a slightly silly example, but we cope with names such as Google, Boost, Spirit, Qi, Karma etc. every day, it takes very little time to get used to them. The more explicit names aren't always more helpful, renaming Fusion to "heterogeneous container library" would IMO be a backward step for example.
I've already answered this to Joel. I didn't say the name should be more verbose, but it should be descriptive. "Qi", for example, doesn't look descriptive to me.
IMO library authors should be left to pick the names, and Boost should not waste valuable time over analyzing them.
I think, library names are no less important than names of classes and functions they consist of. Library name is the first thing a user knows about the library, and it's a shame when it tells nothing.
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost. I disagree. Karma was never advertized as a top-level Boost Library. It should, IMO.
It is a Spirit sub-library. Parsing and generation are two sides of the same coin. These tasks are the opposite. I don't see why they should be mixed in a single library.
Precisely because, as you say they are opposite (dual) to each other, and so present a good opportunity to address some missing symmetry in previous versions of spirit.
Ok, you and Joel may have a point here, although I'm not entirely convinced.
I personally believe we should lean towards allowing authors creative freedom, even if they do grow the scope of their libraries. It's difficult enough for Boost to recruit sufficient high quality developers to produce libraries the community need.
I'm not against creative freedom at all. What I'm saying are two things: 1. Please, chose more descriptive names for your libraries. 2. Major changes in library functionality should be reviewed.
on Fri Jan 02 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
I'm not against creative freedom at all. What I'm saying are two things:
1. Please, chose more descriptive names for your libraries. 2. Major changes in library functionality should be reviewed.
Not commenting on #1. As for #2, a. That has never been Boost's official policy. We can have a debate about it, but that debate has yet to occur and there's certainly no consensus. b. I have never seen an example where such a change was conducted with good library evolution practices and it caused major problems. c. I've seen several examples where undertaking even minor changes without good library evolution practices causes major pain. d. I myself did a major, total (seriously interface-breaking) rewrite of Boost.Python in 2001-2002 without review, and it didn't cause any serious problems for users (that I know of). -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Fri Jan 02 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
2. Major changes in library functionality should be reviewed.
Not commenting on #1. As for #2,
a. That has never been Boost's official policy. We can have a debate about it, but that debate has yet to occur and there's certainly no consensus.
That's true. I was just expressing my point of view. To me, a major addition to an accepted library or a major overhaul of its interface is equivalent to a new library submission, and therefore it should undergo a review. Maybe, a lightweight one.
b. I have never seen an example where such a change was conducted with good library evolution practices and it caused major problems.
c. I've seen several examples where undertaking even minor changes without good library evolution practices causes major pain.
I remember a lengthy discussion about a change in Boost.Range recently. Technically, it may not have been a major change in code, and I'm not judging now whether that change improved the library or not. But the fact is that it caused problems for the end users. I'm not sure whether it applies to (b) or (c), because I didn't see any guidelines of good library evolution practice on the web site.
on Sun Jan 04 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Fri Jan 02 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
2. Major changes in library functionality should be reviewed.
Not commenting on #1. As for #2,
a. That has never been Boost's official policy. We can have a debate about it, but that debate has yet to occur and there's certainly no consensus.
That's true. I was just expressing my point of view. To me, a major addition to an accepted library or a major overhaul of its interface is equivalent to a new library submission, and therefore it should undergo a review. Maybe, a lightweight one.
b. I have never seen an example where such a change was conducted with good library evolution practices and it caused major problems.
c. I've seen several examples where undertaking even minor changes without good library evolution practices causes major pain.
I remember a lengthy discussion about a change in Boost.Range recently. Technically, it may not have been a major change in code, and I'm not judging now whether that change improved the library or not. But the fact is that it caused problems for the end users.
Exactly. It was a relatively minor change especially when compared to the Spirit-2 rewrite, which is many orders of magnitude more significant. It was probably /more/ of a problem for users than any major change because it happened relatively quietly without any "this is going to change your world" fanfare.
I'm not sure whether it applies to (b) or (c), because I didn't see any guidelines of good library evolution practice on the web site.
It's true; someone started to write something, but I think the effort has flagged a bit (https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines) Nonetheless, you don't need to have guidelines written down for there to be such a thing as good practice ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Andrey Semashev wrote:
Joel de Guzman wrote:
You can disagree as much as you want. You can rationalize as much as you want. Well, programmers tend to do so. As far as I am concerned, a name is a name and I, as author, reserve the right to naming my work.
Now that's a very "constructive" approach, I must say. Yes, you may name it as you like, but if the name is nothing but a funny word to you, you just push away users of your library. Unless you don't care about that, that is...
Hmmm. Why would we choose a funny name? I find it hard to parse that. It's either a) you are being sarcastic b) you think the names are funny and think that we chose funny names because we don't care about our users c) what else? This is getting nowhere. To me there are more important issues. This naming issue is a bike shed issue I would want to simply ignore.
Are you suggesting that Spirit be renamed to Boost Parsing Library? Sorry, but no thanks.
I understand that it's too late to rename the library now. However, I'd like to ask to reconsider naming of yet to be released libraries, like Karma or Qi (or what was it?).
These "yet to be released libraries" have been with us since 2006. There were presentations at BoostCon 07 and BoostCon 08. It's been in use and is slowly starting to gain a user-base. So far, I haven't heard any complaints related to the reasons you and Robert mention like wasting other people's time, difficulty in understanding, etc. Nor were there protests to change the names. If we change the names now, it would cause more confusion and destabilize the code more than the meager advantage it may provide. That said, I will discuss it with Hartmut and with the Spirit users. Let's see how it goes.
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost.
I disagree. Karma was never advertized as a top-level Boost Library.
It should, IMO.
It is a Spirit sub-library. Parsing and generation are two sides of the same coin.
These tasks are the opposite. I don't see why they should be mixed in a single library.
Traditionally, that's true. Have you seen a formal language like EBNF describe generation yet? But if you think outside the box, these really *are* two sides of the same coin. Should Boost.Serialization should be broken into two libraries, for example? Perhaps, but those sub-libraries are under Serialization. Ditto for IOStreams.
The situation with so-called sub-libraries, IMHO, is a bad thing to allow in Boost. This turns libraries like Spirit into a playground where actually live several libraries with totally different classes of tasks being solved. What's worse, these libraries don't get reviewed (which
Phoenix and Fusion got reviewed. They were once sub-libraries under Spirit. Proto got reviewed. It was once a sub-library under Xpressive.
How long did they exist as parts of Spirit? Were they approved to be included as parts of Spirit and/or recommended/allowed to be used independently? Why would Spirit contain a duplicate for Lambda and how they can (or should they?) coexist gracefully in the user's code? Which one should be used by default? These questions may sound silly to you, but I recently happened to write an article about Boost libraries, and such questions took a lot of time to answer. I believe, every developer exploring Boost will stumble on such questions sooner or later.
I suggest you go back to the list archives and peruse the Phoenix (and perhaps also Fusion) review. These questions are discussed in depth there. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
That said, I will discuss it with Hartmut and with the Spirit users. Let's see how it goes.
Thanks.
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost.
I disagree. Karma was never advertized as a top-level Boost Library.
It should, IMO.
It is a Spirit sub-library. Parsing and generation are two sides of the same coin.
These tasks are the opposite. I don't see why they should be mixed in a single library.
Traditionally, that's true. Have you seen a formal language like EBNF describe generation yet? But if you think outside the box, these really *are* two sides of the same coin.
Should Boost.Serialization should be broken into two libraries, for example? Perhaps, but those sub-libraries are under Serialization. Ditto for IOStreams.
You may have a point here, although I regard parsing and formatting as more disconnected tasks than serialization and deserialization. I guess, that's because I often do one without the other. However, that doesn't change my opinion regarding the library naming or reviewing sub-libraries.
For what it's worth -- IMHO Andrey's suggestion is very practical and sensible and is a huge help to occasional users (as the vast majority of developers-practitioners are). Best, V.
Joel de Guzman wrote:
You can disagree as much as you want. You can rationalize as much as you want. Well, programmers tend to do so. As far as I am concerned,
a
name is a name and I, as author, reserve the right to naming my work.
Now that's a very "constructive" approach, I must say. Yes, you may name it as you like, but if the name is nothing but a funny word to you, you just push away users of your library. Unless you don't care about that, that is...
Spirit got well known all over the world even while being named with the 'funny' name. IMHO, this whole issue mainly is a matter of taste, so I doubt we'll find any consensus.
Are you suggesting that Spirit be renamed to Boost Parsing Library? Sorry, but no thanks.
I understand that it's too late to rename the library now. However, I'd like to ask to reconsider naming of yet to be released libraries, like Karma or Qi (or what was it?).
Just read the first paragraphs of the 'Introduction' in the docs and you'll know. That's something you'll have to do anyways, even if the library has a 'functional' name.
The formatting capability is a brand new domain, and therefore it should be extracted as another distinct Boost library. It may build on top of Spirit, it may use the same coding guidelines, but it should a be separately reviewed library in its own directory under boost.
I disagree. Karma was never advertized as a top-level Boost Library.
It should, IMO.
Think about this again and you'll see Joel's point. Karma is based on the idea, that a grammar usable to parse an input sequence may as well be used to generate the very same sequence in the output. Qi and Karma use exactly the same description of the (expected/generated) format - a grammar.
It is a Spirit sub-library. Parsing and generation are two sides of the same coin.
These tasks are the opposite. I don't see why they should be mixed in a single library.
For the same reason as Boost.Serialization consists out of two parts: serialization and de-serialization.
The situation with so-called sub-libraries, IMHO, is a bad thing to allow in Boost. This turns libraries like Spirit into a playground where actually live several libraries with totally different classes of tasks being solved. What's worse, these libraries don't get reviewed (which
Phoenix and Fusion got reviewed. They were once sub-libraries under Spirit. Proto got reviewed. It was once a sub-library under Xpressive.
How long did they exist as parts of Spirit? Were they approved to be included as parts of Spirit and/or recommended/allowed to be used independently? Why would Spirit contain a duplicate for Lambda and how they can (or should they?) coexist gracefully in the user's code? Which one should be used by default? These questions may sound silly to you, but I recently happened to write an article about Boost libraries, and such questions took a lot of time to answer. I believe, every developer exploring Boost will stumble on such questions sooner or later.
All these question do not have any connection to the naming issue related to which you're trying to make a point.
may be a tempting reason to add such libraries), they duplicate other existing libraries in Boost (which confuse users), and they honor further duplication in the upcoming libraries (which wastes time of these libraries' developers).
Which upcoming libraries are you referrring to? Could you be more specific?
I was saying in general. The current state of code in the repository introduces the "common practice" which can be followed by the new library authors.
Boost is a very dynamic collection of libraries. And the existing libraries provide an excellent playground for the library authors to improve what's there and to add new capabilities. It was a Boost guideline from the very beginning, that a library is reviewed once and afterwards the authors are free to develop new versions of this library without further review. This approach has lead to the development of Proto (former part of Xpressive) and Phoenix and Fusion (former parts of Spirit). IHMO, this is a very productive way of gaining new insights and developing useful libraries. Regards Hartmut
Hartmut Kaiser:
I understand that it's too late to rename the library now. However, I'd like to ask to reconsider naming of yet to be released libraries, like Karma or Qi (or what was it?).
Just read the first paragraphs of the 'Introduction' in the docs and you'll know. That's something you'll have to do anyways, even if the library has a 'functional' name.
I offer no opinion on the naming issue but a small note: a Google search for Spirit.Karma doesn't find the library.
Peter,
I understand that it's too late to rename the library now. However, I'd like to ask to reconsider naming of yet to be released libraries, like Karma or Qi (or what was it?).
Just read the first paragraphs of the 'Introduction' in the docs and you'll know. That's something you'll have to do anyways, even if the library has a 'functional' name.
I offer no opinion on the naming issue but a small note: a Google search for Spirit.Karma doesn't find the library.
Yep, I know. If you search for 'boost spirit karma' you get some hits, though. The docs are not finished yet (as said before). The whole Spirit V2 is still in beta. But some introduction can be found here: http://www.boost.org/doc/libs/1_37_0/libs/spirit/doc/html/spirit/introductio n.html. Regards Hartmut
Hartmut Kaiser wrote:
Are you suggesting that Spirit be renamed to Boost Parsing Library? Sorry, but no thanks. I understand that it's too late to rename the library now. However, I'd like to ask to reconsider naming of yet to be released libraries, like Karma or Qi (or what was it?).
Just read the first paragraphs of the 'Introduction' in the docs and you'll know. That's something you'll have to do anyways, even if the library has a 'functional' name.
No, I wouldn't have to read the docs, if the library had a more descriptive name and I was looking for something else. If I'm looking for smart pointers and see a Boost.Format library, I immediately know that it's not what I'm looking for.
I disagree. Karma was never advertized as a top-level Boost Library. It should, IMO.
Think about this again and you'll see Joel's point.
Karma is based on the idea, that a grammar usable to parse an input sequence may as well be used to generate the very same sequence in the output. Qi and Karma use exactly the same description of the (expected/generated) format - a grammar.
I've already admitted that this thought has its merit. However, this major submission still has to pass the review, IMHO.
How long did they exist as parts of Spirit? Were they approved to be included as parts of Spirit and/or recommended/allowed to be used independently? Why would Spirit contain a duplicate for Lambda and how they can (or should they?) coexist gracefully in the user's code? Which one should be used by default? These questions may sound silly to you, but I recently happened to write an article about Boost libraries, and such questions took a lot of time to answer. I believe, every developer exploring Boost will stumble on such questions sooner or later.
All these question do not have any connection to the naming issue related to which you're trying to make a point.
These questions have connection to my second point about treating sub-libraries. This topic that was highlighted during the original discussion.
Andrey Semashev wrote:
Hartmut Kaiser wrote:
Are you suggesting that Spirit be renamed to Boost Parsing Library? Sorry, but no thanks. I understand that it's too late to rename the library now. However, I'd like to ask to reconsider naming of yet to be released libraries, like Karma or Qi (or what was it?).
Just read the first paragraphs of the 'Introduction' in the docs and you'll know. That's something you'll have to do anyways, even if the library has a 'functional' name.
No, I wouldn't have to read the docs, if the library had a more descriptive name and I was looking for something else. If I'm looking for smart pointers and see a Boost.Format library, I immediately know that it's not what I'm looking for.
Disagree. It just so happens that you have prior knowledge. Without it, Boost.Format can be anything. It can be for formatting hard disks, for all you know. Or perhaps providing different file formats? "Boost.Format" in itself does not convey enough information. A title is too short to convey the intent of a library. You need at least a sentence. "The Boost Format library" Duh, what does that do? Provide cross platform file formats? "The Boost Format library: The format library provides a class for formatting arguments according to a format-string, as does printf, but with two major differences" Ah, format-strings.. ah printing! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Andrey Semashev wrote:
No, I wouldn't have to read the docs, if the library had a more descriptive name and I was looking for something else. If I'm looking for smart pointers and see a Boost.Format library, I immediately know that it's not what I'm looking for.
Disagree. It just so happens that you have prior knowledge. Without it, Boost.Format can be anything. It can be for formatting hard disks, for all you know. Or perhaps providing different file formats? "Boost.Format" in itself does not convey enough information. A title is too short to convey the intent of a library. You need at least a sentence.
"The Boost Format library"
Duh, what does that do? Provide cross platform file formats?
"The Boost Format library: The format library provides a class for formatting arguments according to a format-string, as does printf, but with two major differences"
Ah, format-strings.. ah printing!
It can be many things, but it definitely isn't a library of smart pointers, is it? On the other hand, Boost.SmartPtr is most likely what I'm looking for - therefore I will put more attention to it (read the docs, for a start). Look, I'm not arguing that the library name is everything you need to know about the library. I'm just saying that informative names really do help to find what you need.
Andrey Semashev wrote:
Joel de Guzman wrote:
Andrey Semashev wrote:
No, I wouldn't have to read the docs, if the library had a more descriptive name and I was looking for something else. If I'm looking for smart pointers and see a Boost.Format library, I immediately know that it's not what I'm looking for.
Disagree. It just so happens that you have prior knowledge. Without it, Boost.Format can be anything. It can be for formatting hard disks, for all you know. Or perhaps providing different file formats? "Boost.Format" in itself does not convey enough information. A title is too short to convey the intent of a library. You need at least a sentence.
"The Boost Format library"
Duh, what does that do? Provide cross platform file formats?
"The Boost Format library: The format library provides a class for formatting arguments according to a format-string, as does printf, but with two major differences"
Ah, format-strings.. ah printing!
It can be many things, but it definitely isn't a library of smart pointers, is it? On the other hand, Boost.SmartPtr is most likely what I'm looking for - therefore I will put more attention to it (read the docs, for a start).
Look, I'm not arguing that the library name is everything you need to know about the library. I'm just saying that informative names really do help to find what you need.
How about Boost.Any? For the uninitiated, that could contain smart pointers. I look at the current names. Only a very few give me the enough information to know what they are for. What is assign? What is enable_if? What is parameter? asio? ref? variant? mpl? units? optional? etc. I wouldn't know by just the names! If I was looking for a particular library in Boost. I'd look at the categories. It's a shame that the current web interface lost this very useful page: http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Andrey Semashev wrote:
Joel de Guzman wrote:
Andrey Semashev wrote: Look, I'm not arguing that the library name is everything you need to know about the library. I'm just saying that informative names really do help to find what you need.
How about Boost.Any? For the uninitiated, that could contain smart pointers. I look at the current names. Only a very few give me the enough information to know what they are for. What is assign? What is enable_if? What is parameter? asio? ref? variant? mpl? units? optional? etc. I wouldn't know by just the names!
Some of them are quite telling (iostreams, variant, filesystem, datetime, threads, function, program_options, serialization, should I go on?). At least, more telling than Qi. And I repeat myself, the name does give a hint on the library purpose, and I find it useful. I'm not sure what exactly you are trying to convince me in. Is it that library names are irrelevant to their domain? Well, we could name libraries like GUIDs, at least we would have world-wide unique names. Do you think it would make life easier for users? Seriously, I'm not sure what we are arguing about.
If I was looking for a particular library in Boost. I'd look at the categories. It's a shame that the current web interface lost this very useful page:
http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category
Yes, that's quite a useful page.
Look, I'm not arguing that the library name is everything you need to know
about the library. I'm just saying that informative names really do help to find what you need.
How about Boost.Any? For the uninitiated, that could contain smart pointers. I look at the current names. Only a very few give me the enough information to know what they are for. What is assign? What is enable_if? What is parameter? asio? ref? variant? mpl? units? optional? etc. I wouldn't know by just the names!
Some of them are quite telling (iostreams, variant, filesystem, datetime, threads, function, program_options, serialization, should I go on?). At least, more telling than Qi. And I repeat myself, the name does give a hint on the library purpose, and I find it useful.
I'm not sure what exactly you are trying to convince me in. Is it that library names are irrelevant to their domain? Well, we could name libraries like GUIDs, at least we would have world-wide unique names. Do you think it would make life easier for users? Seriously, I'm not sure what we are arguing about.
If I was looking for a particular library in Boost. I'd look at
the categories. It's a shame that the current web interface lost this very useful page:
http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category
It can be many things, but it definitely isn't a library of smart pointers,
is it? On the other hand, Boost.SmartPtr is most likely what I'm looking for - therefore I will put more attention to it (read the docs, for a start).
Look, I'm not arguing that the library name is everything you need to know about the library. I'm just saying that informative names really do help to find what you need.
Obviously, having a simple, denotative name for a library is a good thing, but it's only really effective when the name can succinctly describe the features and functionality of the library. It's also easier, when those features are limited to a few well-known abstractions like FileSystem, ProgramOptions, Graph, etc. This arguably isn't the case for Joel's work. The breadth of abstractions represented by those libraries (DSELs, Parsing, Generating, etc.) aren't necessarily best described by a single term. In such cases, it's probably better to pick a neutral name (Spirit, for example) than to pick one that could be misrepresentative or misleading. I think the crux of the problem is not really the name of the library, but the ability to associate a library with a task. I think that Joel is right that it's a presentation issue. The documentation index is just a flat listing of libraries organized alphabetically, which is kind of an arbitrary presentation and not especially conducive to this kind of task. The category listing is substantially more useful in these regards. I would argue for moving this to the top-level documentation page or providing a very obvious link to it. Perhaps there are even better presentations for the breadth and scope of Boost libraries. Andrew Sutton andrew.n.sutton@gmail.com
Obviously, having a simple, denotative name for a library is a good thing, but it's only really effective when the name can succinctly describe the features and functionality of the library. It's also easier, when those features are limited to a few well-known abstractions like FileSystem, ProgramOptions, Graph, etc. This arguably isn't the case for Joel's work. The breadth of abstractions represented by those libraries (DSELs, Parsing, Generating, etc.) aren't necessarily best described by a single term.
Why Boost.Parsing or Boost.Generating are bad? I agree, these names don't look as fancy as Spirit or Karma, but, personally, I usually care more about practical matters than exterior fancyness.
In such cases, it's probably better to pick a neutral name (Spirit, for example) than to pick one that could be misrepresentative or misleading.
I think the crux of the problem is not really the name of the library, but the ability to associate a library with a task. I think that Joel is right that it's a presentation issue.
The documentation index is just a flat listing of libraries organized alphabetically, which is kind of an arbitrary presentation and not especially conducive to this kind of task. The category listing is substantially more useful in these regards. I would argue for moving this to the top-level documentation page or providing a very obvious link to it.
Perhaps there are even better presentations for the breadth and scope of Boost libraries.
I agree that categorized index could help a lot. However, I can't say that it would allow library names to be completely irrelevant to their purpose.
Andrey Semashev wrote:
Why Boost.Parsing or Boost.Generating are bad?
I guess because they raise the question where the grammar lives. (I guess some "common" parts of the grammar live in the namespace boost::spirit, and the "noncommom" parts live in the namespaces boost::spirit::qi and boost::spirit::karma.) Both Qi and Karma are "strongly grammar based", but neither "Parsing" nor "Generating" hints at the important role of the grammar. This is probably also the reason why the lexer was granted the descriptive namespace boost::spirit::lex, because it is completely independent of any spirit-grammar. But this is just a guess. Regards, Thomas
Thomas Klimpel wrote:
Andrey Semashev wrote:
Why Boost.Parsing or Boost.Generating are bad?
I guess because they raise the question where the grammar lives.
Are Boost.Grammar.Parsing and Boost.Grammar.Generating better in this regard?
Andrey Semashev wrote:
Thomas Klimpel wrote:
Andrey Semashev wrote:
Why Boost.Parsing or Boost.Generating are bad?
I guess because they raise the question where the grammar lives.
Are Boost.Grammar.Parsing and Boost.Grammar.Generating better in this regard?
Not for me. They give me a false impression of what they mean, which is worse than no impression at all. Try to see it from a different perspective: Spirit.Lex is a sub-library, like Phoenix was a sub-library from Spirit, that is really different from Spirit itself. But Spirit.Qi and Spirit.Karma really "are" Spirit, they are not sub-libraries in the same sense as Phoenix or Spirit.Lex. So it makes sense that they have "Spirit-like" names. Regards, Thomas
Andrey Semashev wrote:
Obviously, having a simple, denotative name for a library is a good thing, but it's only really effective when the name can succinctly describe the features and functionality of the library. It's also easier, when those features are limited to a few well-known abstractions like FileSystem, ProgramOptions, Graph, etc. This arguably isn't the case for Joel's work. The breadth of abstractions represented by those libraries (DSELs, Parsing, Generating, etc.) aren't necessarily best described by a single term.
Why Boost.Parsing or Boost.Generating are bad? I agree, these names don't look as fancy as Spirit or Karma, but, personally, I usually care more about practical matters than exterior fancyness.
They are not bad. But they are not good either. Doug (Gregor) intuited long ago that Spirit can host several parsing methods in addition to recursive descent. Ok, let me try to be more constructive: 1) The name Spirit cannot be changed. Doing so at this time will cause more damage than the "advantage" you claim (for which I am not convinced). 2) There's only one compelling reason I've heard so far, and that is from Dave (A): "if there are 4-5 sublibraries that also have non-mnemonic names, it does start to look pretty confusing." I am open to changing the names "Qi" and "Karma" to something non-abstract. The names: Spirit.RD and spirit.Gen come to mind. Spirit.Parsing is not a good name because there can be a Spirit.LL1, Spirit.LR, Spirit.Packrat. I am open to suggestions. At any rate, I'd want to reserve the right to choosing the names. Whether or not these new features, when they finally arrive, should be subject to a review, depends on what the rules are at that time. Right now, I stand by the current rules: A library can be extended without further review.
I agree that categorized index could help a lot. However, I can't say that it would allow library names to be completely irrelevant to their purpose.
I am not against non-abstract library names. No, they are not irrelevant. I'm just not inclined to put too much emphasis on them. One must not judge a library by its name. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Sat Jan 03 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
2) There's only one compelling reason I've heard so far, and that is from Dave (A): "if there are 4-5 sublibraries that also have non-mnemonic names, it does start to look pretty confusing."
well, thanks, but...
I am open to changing the names "Qi" and "Karma" to something non-abstract. The names: Spirit.RD and spirit.Gen come to mind. Spirit.Parsing is not a good name because there can be a Spirit.LL1, Spirit.LR, Spirit.Packrat.
I am open to suggestions. At any rate, I'd want to reserve the right to choosing the names.
...I agree 100%, and I wouldn't necessarily want you to change the names of Qi and Karma based on my argument. You have built a vibrant Spirit community and the names that community came up with are an expression of its culture. Frankly, I think it would be un-boost-like to impose such a mandate. We traditionally leave such choices in the hands of the library developer. If you choose to leave the names as they are, I only ask that you be aware of the cognitive value that is lost by using non-mnemonic names, and go the extra mile to make it easy for users to learn (and remember!) what the names mean. Frankly, I think I've forgotten -- I think Qi is the parsing part, but I wouldn't lay any serious money on it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Andrew Sutton wrote:
Obviously, having a simple, denotative name for a library is a good thing, but it's only really effective when the name can succinctly describe the features and functionality of the library. It's also easier, when those features are limited to a few well-known abstractions like FileSystem, ProgramOptions, Graph, etc. This arguably isn't the case for Joel's work. The breadth of abstractions represented by those libraries (DSELs, Parsing, Generating, etc.) aren't necessarily best described by a single term. In such cases, it's probably better to pick a neutral name (Spirit, for example) than to pick one that could be misrepresentative or misleading.
I think the crux of the problem is not really the name of the library, but the ability to associate a library with a task. I think that Joel is right that it's a presentation issue.
The documentation index is just a flat listing of libraries organized alphabetically, which is kind of an arbitrary presentation and not especially conducive to this kind of task. The category listing is substantially more useful in these regards. I would argue for moving this to the top-level documentation page or providing a very obvious link to it.
Perhaps there are even better presentations for the breadth and scope of Boost libraries.
Thank you, Andrew. That is a very good and effective explanation. I am not against "descriptive" names. It can be good, especially for small, specific libraries, in some cases, as small as a single class, surrounded perhaps by a few support classes. That is not the case for Spirit. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Sat, Jan 3, 2009 at 21:53, Joel de Guzman <joel@boost-consulting.com> wrote:
Thank you, Andrew. That is a very good and effective explanation. I am not against "descriptive" names. It can be good, especially for small, specific libraries, in some cases, as small as a single class, surrounded perhaps by a few support classes. That is not the case for Spirit.
For Spirit as a whole I agree, since I'm not convinced a perfect descriptive name exists, but I fail to see the harm in something simple like Spirit.Parse, Spirit.Grammar, and Spirit.Print. One could also argue that, in general, not being able to find a good name is indicative of broad purpose (like Boost) rather than specific functionality (as a Boost library ought to be). I won't say that it necessarily applies in this case, as my gut likes the grouping of the 3 functionalities, but I do think it's a valid twist to Andrew's comments. Still not concerned by the naming, ~ Scott
Scott McMurray wrote:
On Sat, Jan 3, 2009 at 21:53, Joel de Guzman <joel@boost-consulting.com> wrote:
Thank you, Andrew. That is a very good and effective explanation. I am not against "descriptive" names. It can be good, especially for small, specific libraries, in some cases, as small as a single class, surrounded perhaps by a few support classes. That is not the case for Spirit.
For Spirit as a whole I agree, since I'm not convinced a perfect descriptive name exists, but I fail to see the harm in something simple like Spirit.Parse, Spirit.Grammar, and Spirit.Print.
Good points!
One could also argue that, in general, not being able to find a good name is indicative of broad purpose (like Boost) rather than specific functionality (as a Boost library ought to be). I won't say that it necessarily applies in this case, as my gut likes the grouping of the 3 functionalities, but I do think it's a valid twist to Andrew's comments.
Indeed. Spirit is not a single library since day one when it became a Boost citizen. It's more of a project than a single library.
Still not concerned by the naming,
Ditto. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Hi Andrey,
I'm not sure what exactly you are trying to convince me in. Is it that library names are irrelevant to their domain?
the truth typically lies somewhere in the middle. A descriptive project name is helpful to some degree -- yet there are plenty of projects out there that succeed admirably despite their non-descriptive names. Think "Firefox", if you like. Arguably, the name "Boost" is not excessively descriptive either. It so happens, however, that the users of these projects appear to care more about technical excellence than about names. To say that library names would be "irrelevant" is an exaggeration. The amount of attention you appear to be paying to this subject, however, is exaggerated too. Frankly, your repeated complaints about Spirit's naming decisions feel like nitpicking. I, for one, wouldn't mind if you would drop the subject now and instead spend your time, say, finalizing the Boost.Log library? Logging seems to be a controversial subject. I will be a lot of effort to get your code past the review. Take care, Peter
Peter Simons wrote:
To say that library names would be "irrelevant" is an exaggeration. The amount of attention you appear to be paying to this subject, however, is exaggerated too.
Maybe the amount of discussion of this topic was indeed a bit excessive.
Frankly, your repeated complaints about Spirit's naming decisions feel like nitpicking.
I have nothing against the library or Joel, if that is what you mean. In fact, I like Spirit very much and have used it in several projects with great success. The discussion concentrated around Spirit because this is the library with the most abstract name(s) in Boost.
Andrey Semashev wrote:
Joel de Guzman wrote:
Andrey Semashev wrote:
Joel de Guzman wrote:
Andrey Semashev wrote: Look, I'm not arguing that the library name is everything you need to know about the library. I'm just saying that informative names really do help to find what you need.
How about Boost.Any? For the uninitiated, that could contain smart pointers. I look at the current names. Only a very few give me the enough information to know what they are for. What is assign? What is enable_if? What is parameter? asio? ref? variant? mpl? units? optional? etc. I wouldn't know by just the names!
Some of them are quite telling (iostreams, variant, filesystem, datetime, threads, function, program_options, serialization, should I go on?). At least, more telling than Qi. And I repeat myself, the name does give a hint on the library purpose, and I find it useful.
I'm not sure what exactly you are trying to convince me in. Is it that library names are irrelevant to their domain? Well, we could name libraries like GUIDs, at least we would have world-wide unique names. Do you think it would make life easier for users? Seriously, I'm not sure what we are arguing about.
What I am trying to say is that the so-called "descriptive names" are not always that descriptive either. Without real descriptions, an uninitiated boost user can never tell what some of the names listed above mean. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Andrey Semashev wrote:
Joel de Guzman wrote:
Andrey Semashev wrote: ...
If I was looking for a particular library in Boost. I'd look at the categories. It's a shame that the current web interface lost this very useful page:
http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category
Regards,
I agree with Joel, that this was an invaluable view of the boost libraries, and in my mind would alleviate many of the issues raised here pertaining to new users finding the appropriate libraries, regardless of names. Is there someone who could get this page back to a more prominent place on the website? I'd volunteer but I'm fairly illiterate in html. I could probably get someone at work to help me over the next week. Any suggestions on where it would be integrated? Jeff
AMDG Jeff Flinn wrote:
If I was looking for a particular library in Boost. I'd look at the categories. It's a shame that the current web interface lost this very useful page:
http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category
I agree with Joel, that this was an invaluable view of the boost libraries, and in my mind would alleviate many of the issues raised here pertaining to new users finding the appropriate libraries, regardless of names.
Is there someone who could get this page back to a more prominent place on the website? I'd volunteer but I'm fairly illiterate in html. I could probably get someone at work to help me over the next week. Any suggestions on where it would be integrated?
It's still accessible by the following convoluted chain of links: www.boost.org -> Documentation -> 1.37 -> accumulators (e.g.) -> Libraries Instead of making the page easily accessible its content should be integrated with http://www.boost.org/doc/libs/1_37_0, IMO. In Christ, Steven Watanabe
AMDG Joel de Guzman wrote:
If I was looking for a particular library in Boost. I'd look at the categories. It's a shame that the current web interface lost this very useful page:
http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category
This has been available on the beta site since November http://beta.boost.org/doc/libs/1_37_0?view=categorized but hasn't been merged to the live site. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Joel de Guzman wrote:
If I was looking for a particular library in Boost. I'd look at the categories. It's a shame that the current web interface lost this very useful page:
http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Category
This has been available on the beta site since November http://beta.boost.org/doc/libs/1_37_0?view=categorized but hasn't been merged to the live site.
In Christ, Steven Watanabe
Nice find Steve, is it just waiting to be merged for 1.38? Jeff
2009/1/4 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Steven Watanabe wrote:
This has been available on the beta site since November http://beta.boost.org/doc/libs/1_37_0?view=categorized but hasn't been merged to the live site.
Nice find Steve, is it just waiting to be merged for 1.38?
That was me. I didn't put it on the live site because I wasn't entirely happy with it. I didn't like the interface for switching between different 'views', although trying it now, it doesn't seem that bad. Daniel
Daniel James wrote:
2009/1/4 Jeff Flinn <TriumphSprint2000@hotmail.com>:
Steven Watanabe wrote:
This has been available on the beta site since November http://beta.boost.org/doc/libs/1_37_0?view=categorized but hasn't been merged to the live site. Nice find Steve, is it just waiting to be merged for 1.38?
That was me. I didn't put it on the live site because I wasn't entirely happy with it. I didn't like the interface for switching between different 'views', although trying it now, it doesn't seem that bad.
It seems fine to me as well. Having the Category view is much better than not having it. Can you update the live site Daniel? Thanks, Jeff
Hi Robert,
I wish [the Spirit team would] appreciate how all this name changing makes things much more difficult for us poor library users.
others are more qualified to explain the technical rationale behind those decisions, but my impression is that version 2 of the Spirit library has been re-designed from ground up. The new API doesn't look radically different from version 1 (Spirit.Classic), not at all, but some details changed, so version 2 (Spirit.Qi) is not entirely backwards compatible. The classic API is still fully supported in current versions of the library -- you don't have to upgrade your parsers if you don't want to. If you *do* upgrade your parsers, however, you'll most likely find that the re-written code will be simpler, cleaner, and more efficient. Now, changes that disrupt backwards compatibility are always costly and should be avoided unless there is a major advantage to be had by making those changes. My impression is that the advantages Spirit.Qi offers over Spirit.Classic outweigh those costs. Once you've decided to change the API, it is only sensible software engineering to place the modified API into a new namespace. Whether you call it boost::spiritv2, boost::spirit::v2, or boost::spirit::qi is a matter of taste and there is no accounting for taste. As far as I am concerned, the Spirit team does an amazing job at providing a high-quality parser DSL for C++. Just my 2 cents, Peter
Peter Simons wrote:
Hi Robert,
Once you've decided to change the API, it is only sensible software engineering to place the modified API into a new namespace.
Agreed - so there's at least two of us.
As far as I am concerned, the Spirit team does an amazing job at providing a high-quality parser DSL for C++.
Agreed. Robert Ramey
Robert Ramey wrote:
Peter Simons wrote:
Hi Robert,
Once you've decided to change the API, it is only sensible software engineering to place the modified API into a new namespace.
Agreed - so there's at least two of us.
And indeed they are (in separate sub-namespaces). So that makes the four of us, and surely a lot more :-)
As far as I am concerned, the Spirit team does an amazing job at providing a high-quality parser DSL for C++.
Agreed.
Thank you! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Peter Simons wrote:
Hi Robert,
I wish [the Spirit team would] appreciate how all this name changing makes things much more difficult for us poor library users.
others are more qualified to explain the technical rationale behind those decisions,
But why should there be a technical rationale behind a name? That's the real question that I haven't seen answered yet. A name is a name, be it Boost, STL, C, ASIO, Pascal, ICU, USA, Peter, Joel, Spot, Star Trek, Microsoft, Apple, Metallica, etc. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Robert Ramey wrote:
Hartmut Kaiser wrote:
You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have problems using Spirit.Karma either. Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster.
Just curious. How much time did you waste before you realize that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review?
Where is this custom/rules and when did this it start to apply? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Thu Jan 01 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
Robert Ramey wrote:
Hartmut Kaiser wrote:
You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have problems using Spirit.Karma either. Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster.
Just curious. How much time did you waste before you realize that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
True, but once you learn that, if there are 4-5 sublibraries that also have non-mnemonic names, it does start to look pretty confusing.
Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review?
Where is this custom/rules and when did this it start to apply?
There are no such rules. There's nothing wrong with extending the functionality of a library. Obviously, tacking the functionality of the filesystem library onto Boost.Python wouldn't make sense, but I think parsing and generation may be a bit more related than that ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Thu Jan 01 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
The fact that names are in no way descriptive is another huge time waster. Just curious. How much time did you waste before you realize that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
True, but once you learn that, if there are 4-5 sublibraries that also have non-mnemonic names, it does start to look pretty confusing.
That's a good and valid point alright.
Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review? Where is this custom/rules and when did this it start to apply?
There are no such rules. There's nothing wrong with extending the functionality of a library. Obviously, tacking the functionality of the filesystem library onto Boost.Python wouldn't make sense, but I think parsing and generation may be a bit more related than that ;-)
Actually, we are contemplating on asking for an informal review. There's no precedence for this in boost, so we're not quite sure how to approach it. We do value feedback, critiques, suggestions from the community --give people a chance to weigh in their thoughts on issues like API, usability, implementation, documentation, etc. Surely, it can't be the accept/reject kind of review, as it would be quite odd if Spirit gets rejected in its second review. Your thoughts? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
David Abrahams wrote:
Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review?
Where is this custom/rules and when did this it start to apply?
There are no such rules. There's nothing wrong with extending the functionality of a library. Obviously, tacking the functionality of the filesystem library onto Boost.Python wouldn't make sense, but I think parsing and generation may be a bit more related than that ;-)
OK - here is my example. The serialization library includes and depends upon another component which is logically separate: This is extended_typeinfo. It extends the standard typeinfo in order permit one to use a portable string as a universal identifier. So, given this, one can access the static extended typeinfo record, And given this one can request the construction of object of the corresponding type. This is effectively a (mostly) portable C++ system similiar to COM / CORBA and is used and tested as part of the serialization library. Now suppose I decide - this is really a new library whose functionality I would like to see included in boost. Can I just promote this to that status without a review of some sort? How about BOOST_STATIC_WARNING? Can I promote this as well? Is this the same as creating a new library Karma, or Qi or ? which formats data? Well, given the names, I have no idea? But the question remains - should a whole new facility different than what exists just be added? How would the author of a previously rejected log library feel if someone else just gets his alternative accepted without any kind of review. Robert Ramey
Robert Ramey wrote:
David Abrahams wrote:
Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review? Where is this custom/rules and when did this it start to apply? There are no such rules. There's nothing wrong with extending the functionality of a library. Obviously, tacking the functionality of the filesystem library onto Boost.Python wouldn't make sense, but I think parsing and generation may be a bit more related than that ;-)
OK - here is my example.
The serialization library includes and depends upon another component which is logically separate: This is extended_typeinfo. It extends the standard typeinfo in order permit one to use a portable string as a universal identifier. So, given this, one can access the static extended typeinfo record, And given this one can request the construction of object of the corresponding type. This is effectively a (mostly) portable C++ system similiar to COM / CORBA and is used and tested as part of the serialization library.
Now suppose I decide - this is really a new library whose functionality I would like to see included in boost. Can I just promote this to that status without a review of some sort? How about BOOST_STATIC_WARNING? Can I promote this as well?
No and no.
Is this the same as creating a new library Karma, or Qi or ? which formats data?
No. You are asking for a top level library. Karma/Qi are sub- libraries still under Spirit.
Well, given the names, I have no idea?
If you get to know beyond the name, you will.
But the question remains - should a whole new facility different than what exists just be added? How would the author of a previously rejected log library feel if someone else just gets his alternative accepted without any kind of review.
If you asking for a top-level library, then yes, it must be reviewed. If, on the other hand, it is a part of your library (a component, a sub-library), then I see no problem. Qi/Karma are all under Spirit. They are not top level Boost libraries (so were Phoenix and Fusion, before they were reviewed). They all live under the spirit namespace in sub-namespaces. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Thu Jan 01 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
Now you want to mix in another facility? At least I know (Or think I know) what spirit was intended to be used for. Now I'm not so sure. If this is a new facitity - wouldn't Boost custom/rules require that it be subjected a new review?
Where is this custom/rules and when did this it start to apply?
There are no such rules. There's nothing wrong with extending the functionality of a library. Obviously, tacking the functionality of the filesystem library onto Boost.Python wouldn't make sense, but I think parsing and generation may be a bit more related than that ;-)
OK - here is my example.
The serialization library includes and depends upon another component which is logically separate: This is extended_typeinfo. It extends the standard typeinfo in order permit one to use a portable string as a universal identifier. So, given this, one can access the static extended typeinfo record, And given this one can request the construction of object of the corresponding type. This is effectively a (mostly) portable C++ system similiar to COM / CORBA and is used and tested as part of the serialization library.
Now suppose I decide - this is really a new library whose functionality I would like to see included in boost. Can I just promote this to that status without a review of some sort? How about BOOST_STATIC_WARNING? Can I promote this as well?
You can promote them to "exposed and supported features/sub-libraries of Boost.Serialization" but not to top-level Boost libraries. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Joel de Guzman wrote:
Robert Ramey wrote:
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster.
Just curious. How much time did you waste before you realize that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
Here are examples where time has been wasted. All of a sudden, one some platform the serialization library fails to build. After a time, an investigation reveals that the #include <boost/spiritsomefile> get redirected in some baroque non-obvious way to something like boost/spirit/class.. or something like that. OK - I'll just tweak the library so that it includes the "classic" targets directly. Now, the library won't build for borland compilers. Turns out that this compiler needs spirit 1.6x - which I have on my machine but the directory structure is different. To top it off, there isn't enough information - or its not sufficiently obvious to find - to conditionally include the right stuff. Now, it looks like spirit is going to be "upgraded" how will this effect the current code? No way to know. How much time have I wasted on this? I didn't keep track. Not that it matters since we're not apparently done yet. Here's a suggestion. for your latest/greatest, put in the namespace boost::spirit and in directory boost/sprit For your old version, with an incompatible API, put it in namespace boost::spririt_1_8 and directory boost/spririt_1_8. and for your older version put it in boost::spririt_1_6 and directory boost/spririt_1_6 And include a macro BOOST_SPIRIT_VERSION with the version string or number Leave the tests in the previous versions even though they are no longer being tested. This would be really helpful and I don't think it would create much work for you. Robert Ramey
Robert Ramey wrote:
Joel de Guzman wrote:
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster. Just curious. How much time did you waste before you realize
Robert Ramey wrote: that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
Here are examples where time has been wasted.
All of a sudden, one some platform the serialization library fails to build. After a time, an investigation reveals that the #include <boost/spiritsomefile> get redirected in some baroque non-obvious way to something like boost/spirit/class.. or something like that. OK - I'll just tweak the library so that it includes the "classic" targets directly. Now, the library won't build for borland compilers. Turns
Spirit 1.8 never ever worked on Borland.
out that this compiler needs spirit 1.6x - which I have on
Yes, you need 1.6 for that.
my machine but the directory structure is different. To
Not true! The directory structure was never changed. The old headers will be deprecated (after a couple of releases [2, I think, starting from 1.37]), but not without warning.
top it off, there isn't enough information - or its not sufficiently obvious to find - to conditionally include the right stuff.
Not true! If you use a deprecated include and the warning starts to kick in (after Boost 1.38 I think), it will warn you and point you to the right file. Example: #if BOOST_VERSION >= 103800 #if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__DMC__) # pragma message ("Warning: This header is deprecated. Please use: boost/spirit/include/classic_dynamic.hpp") #elif defined(__GNUC__) || defined(__HP_aCC) || defined(__SUNPRO_CC) || defined(__IBMCPP__) # warning "This header is deprecated. Please use: boost/spirit/include/classic_dynamic.hpp" #endif #endif
Now, it looks like spirit is going to be "upgraded" how will this effect the current code?
You do not have to lift a finger. The new code is 100% backward compatible. No way to know. How No need to know. Unless you want to stay current. In which case you have various ways. 1) Simply tweak the paths 2) port to Spirit2.
much time have I wasted on this? I didn't keep track.
Does not have anything to do with naming. I see no connection. What you say above are totally different issues.
Not that it matters since we're not apparently done yet.
Here's a suggestion.
for your latest/greatest, put in the namespace boost::spirit and in directory boost/sprit
For your old version, with an incompatible API, put it in namespace boost::spririt_1_8 and directory boost/spririt_1_8.
and for your older version put it in boost::spririt_1_6 and directory boost/spririt_1_6
And include a macro BOOST_SPIRIT_VERSION with the version string or number
Leave the tests in the previous versions even though they are no longer being tested.
This would be really helpful and I don't think it would create much work for you.
It seems you haven't really tried to know more beyond the name(s). Except for spririt 1.6, our recipe is similar to what was done. "Classic" Spirit will not, I repeat: will not, go away anytimne soon. It is, and will be, in the namespace "classic". This is the technical rationale behind the "baroque" include paths. We want 100% backward compatibility while at the same time usher in the new generation. It's not an easy task, mind you. A lot of neurons were employed until we came up with the best practical approach. Then again, all these does not have anything to do with naming. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Robert Ramey wrote:
my machine but the directory structure is different. To
Not true! The directory structure was never changed.
Well, something is different. The build failed on some compiler (PGI I think) and it was related to this change. I looked through what was going on (a waste of time) and concluded that chang
top it off, there isn't enough information - or its not sufficiently obvious to find - to conditionally include the right stuff.
Not true! If you use a deprecated include and the warning starts to kick in (after Boost 1.38 I think), it will warn you and point you to the right file. Example:
Doesn't work on all compilers. That's why I made the change.
Now, it looks like spirit is going to be "upgraded" how will this effect the current code?
You do not have to lift a finger. The new code is 100% backward compatible.
LOL - If that were the case, I wouldn't have changed anything
No way to know. How
No need to know.
I realize that this is the intent. It just work in all cases.
Unless you want to stay current. In which case you have various ways. 1) Simply tweak the paths 2) port to Spirit2.
much time have I wasted on this? I didn't keep track.
Does not have anything to do with naming. I see no connection. What you say above are totally different issues.
Not that it matters since we're not apparently done yet.
Here's a suggestion.
for your latest/greatest, put in the namespace boost::spirit and in directory boost/sprit
For your old version, with an incompatible API, put it in namespace boost::spririt_1_8 and directory boost/spririt_1_8.
and for your older version put it in boost::spririt_1_6 and directory boost/spririt_1_6
And include a macro BOOST_SPIRIT_VERSION with the version string or number Leave the tests in the previous versions even though they are no longer being tested.
This would be really helpful and I don't think it would create much work for you.
It seems you haven't really tried to know more beyond the name(s). Except for spririt 1.6, our recipe is similar to what was done. "Classic" Spirit will not, I repeat: will not, go away anytimne soon. It is, and will be, in the namespace "classic". This is the technical rationale behind the "baroque" include paths. We want 100% backward compatibility while at the same time usher in the new generation.
I realize that, I'm just letting you know that it was failure.
It's not an easy task, mind you. A lot of neurons were employed until we came up with the best practical approach.
The problem is that you tried to make it too clever. So it works in almost all cases. However, if it fails in just one case, then I have to start spending time to investigate. First there is the baroque directory structure. This creates a problem for me in that I never included just "spirit" but rather the lower level directories in order to included just the facilities that I used. So then I had to spend time to figure out what I should include. Then I come accross new names, etc. so then I have to try to "know more beyond the name(s)." which takes more time. The most irksome part of this is that it is totally unnecessary.
Then again, all these does not have anything to do with naming.
Actually, this thread started with the idea that spirit::karma (or whatever it is) should be considered as an alternative to including a separate logging library in boost. This raised 2 issues 1) choosing one logging library implementation for boost over another proposal by default rather than through the review process. 2) the fact that no one looking to see if boost had a logging library would be expected to find "sprite::karma". This wastes time of anyone preparing a logging library for submission. Robert Ramey
Regards,
Robert Ramey wrote:
Actually, this thread started with the idea that spirit::karma (or whatever it is) should be considered as an alternative to including a separate logging library in boost. No, it didn't. The logging thread is entirely separate and has absolutely nothing to do with this one. This thread started about adopting Loki.SafeFormat, which is similar to Boost.Format. 2) the fact that no one looking to see if boost had a logging library would be expected to find "sprite::karma". A good thing Karma is a text manipulation library then, as is all of Spirit.
Sebastian
whoops, let me rephrase that: Actually, this thread started with the idea that spirit::karma (or whatever it is) should be considered as an alternative to including Loki.SafeFormat in boost. ... 2) the fact that no one looking to see if boost had a safe formating library library would be expected to find "sprite::karma". Robert Ramey Sebastian Redl wrote:
Robert Ramey wrote:
Actually, this thread started with the idea that spirit::karma (or whatever it is) should be considered as an alternative to including a separate logging library in boost. No, it didn't. The logging thread is entirely separate and has absolutely nothing to do with this one. This thread started about adopting Loki.SafeFormat, which is similar to Boost.Format. 2) the fact that no one looking to see if boost had a logging library would be expected to find "sprite::karma". A good thing Karma is a text manipulation library then, as is all of Spirit.
Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
2) the fact that no one looking to see if boost had a safe formating library library would be expected to find "sprite::karma".
I don't know about other people, but my method of discovering Boost was reading through all the short descriptions on the library overview page and filing them away in my mind, not looking at just the titles and guessing what they're for. If I had to find a library for a specific purpose, I'd do a search on the library overview page, which looks in the descriptions too. So if I'm looking for a formatting library, I'll go to the library overview, hit Ctrl+F and type "format", maybe hit F3 to find alternatives. I'm certainly not going to scroll over the page scanning library names only. Because even names derived from the actual use case often don't really help. Would you know, without looking at the description, what Boost.Any really is for? How about Boost.Assign? Does the name really say that it's a library that gives you a very convenient syntax for filling containers? Let alone the initialism libraries like the MPL. Most Boost libraries have simple and intuitive names, to their great credit. But I really don't think that a beautiful name (and I think Spirit's naming theme is beautiful) is any worse. Sebastian
Robert Ramey wrote:
Joel de Guzman wrote:
Now, it looks like spirit is going to be "upgraded" how will this effect the current code? You do not have to lift a finger. The new code is 100% backward compatible.
LOL - If that were the case, I wouldn't have changed anything
No way to know. How
No need to know.
[...]
It seems you haven't really tried to know more beyond the name(s). Except for spririt 1.6, our recipe is similar to what was done. "Classic" Spirit will not, I repeat: will not, go away anytimne soon. It is, and will be, in the namespace "classic". This is the technical rationale behind the "baroque" include paths. We want 100% backward compatibility while at the same time usher in the new generation.
I realize that, I'm just letting you know that it was failure.
Again: post a minimal cpp file that exhibits the problem you mention. If you've done so, we would have corrected it, instead of you "wasting" your time. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Robert Ramey wrote:
It seems you haven't really tried to know more beyond the name(s). Except for spririt 1.6, our recipe is similar to what was done. "Classic" Spirit will not, I repeat: will not, go away anytimne soon. It is, and will be, in the namespace "classic". This is the technical rationale behind the "baroque" include paths. We want 100% backward compatibility while at the same time usher in the new generation.
I realize that, I'm just letting you know that it was failure.
Again: post a minimal cpp file that exhibits the problem you mention. If you've done so, we would have corrected it, instead of you "wasting" your time.
Robert, I'm still waiting for you to post a minimal cpp file that exhibits the problem you mention. You just can't say our attempt was a failure without detailing exactly why and then just drop the ball. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Well, it will take me some time to reconstruct what happened. Briefly, from memory: a) I noticed that running the serialization tests most compilers emitted a warning "....deprecated - ? redirectored or ?" I forget. b) Also the PGI compiler choked on the code which emitted the warning - preventing the build of the serialization library. c) I figured - no big deal - I'll just tweak the "#include boost/spirit/.." as suggested by the warning message. Hey it is only a couple of files which use spirit. d) First problem was that I had included not boost/spirit.hpp - but some deeper level files like boost/spirit/chmod or ? whatever. I had done this in the interest of saving compiler time an making it less likely that spirt code would confuse this or that compiler. In the course of figuring this out, I came on a really confusing sequence of #includes whold purpose seemed to make something automatic and invisible but left me baffled. I thik I changed things to include the "convenience header" e) The borland version of the serialization library builds with spirit 1.6x in the include path. With the header changes I was forced to make, that didn't work anymore. f)I couldn't make the #includes conditional on the spirit version - because there is / was no manifest constant indicating the spirit version g)I couldn't make the #include conditional on boost version since the boot version is always the latest and doesn't match the spirit 1.6x version i)I tried to use the lastest version of spirit with the latest version of borland but this fails to compile. To top it off, the PGI compiler got over that spirit hump and tripped up on something else. So the net result is: a) The serializatoin library can no longer built for borland compilers. - a regression. b) The serializatoin library can no longer built for PGI compilers. - no change here. I may have some details wrong in the above recollection. Of course had I known this was going to be such a hassle, I might have kept better notes and brought it up at the time. But then again if I had known how much time was going to be wasted on this, I would have just ignored the "deprecation" warnings. I'll probably just back out these changes and do that. But to go back and verify all this with a minimal.cpp file is more than I have time for right now. Sorry. Robert Ramey Joel de Guzman wrote:
Joel de Guzman wrote:
Robert Ramey wrote:
It seems you haven't really tried to know more beyond the name(s). Except for spririt 1.6, our recipe is similar to what was done. "Classic" Spirit will not, I repeat: will not, go away anytimne soon. It is, and will be, in the namespace "classic". This is the technical rationale behind the "baroque" include paths. We want 100% backward compatibility while at the same time usher in the new generation.
I realize that, I'm just letting you know that it was failure.
Again: post a minimal cpp file that exhibits the problem you mention. If you've done so, we would have corrected it, instead of you "wasting" your time.
Robert, I'm still waiting for you to post a minimal cpp file that exhibits the problem you mention. You just can't say our attempt was a failure without detailing exactly why and then just drop the ball.
Regards,
Robert Ramey wrote:
Well, it will take me some time to reconstruct what happened. Briefly, from memory:
a) I noticed that running the serialization tests most compilers emitted a warning "....deprecated - ? redirectored or ?" I forget.
Here's an example of PP code that does that: #if BOOST_VERSION >= 103800 #if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__DMC__) # pragma message ("Warning: This header is deprecated. Please use: boost/spirit/include/classic_actor.hpp") #elif defined(__GNUC__) || defined(__HP_aCC) || defined(__SUNPRO_CC) || defined(__IBMCPP__) # warning "This header is deprecated. Please use: boost/spirit/include/classic_actor.hpp" #endif #endif So, I do not understand how you got that warning, unless you are referring to code in the trunk at the time we were refactoring. Things have changed since then and to say that our work on migration to a new version was a failure based on early code is unfair.
b) Also the PGI compiler choked on the code which emitted the warning - preventing the build of the serialization library.
Ditto. I cannot understand why PGI will have choked on that code unless the Boost version is >= 1.38 and it emulated some compiler's IDs.
c) I figured - no big deal - I'll just tweak the "#include boost/spirit/.." as suggested by the warning message. Hey it is only a couple of files which use spirit. d) First problem was that I had included not boost/spirit.hpp - but some deeper level files like boost/spirit/chmod or ? whatever.
Might you be using some implementation details? I'll never know. I have no complaints on using just the public header files. All public header files are forwarded properly.
I had done this in the interest of saving compiler time an making it less likely that spirt code would confuse this or that compiler. In the course of figuring this out, I came on a really confusing sequence of #includes whold purpose seemed to make something automatic and invisible but left me baffled. I thik I changed things to include the "convenience header" e) The borland version of the serialization library builds with spirit 1.6x in the include path. With the header changes I was forced to make, that didn't work anymore.
Again, I'll never know why unless you report the exact problem. You can't just declare something broken without detailing the circumstances that lead to the problem.
f)I couldn't make the #includes conditional on the spirit version - because there is / was no manifest constant indicating the spirit version
I recall this was your *only* public complaint and we acted on it the very moment you mentioned it. This happened on the trunk.
g)I couldn't make the #include conditional on boost version since the boot version is always the latest and doesn't match the spirit 1.6x version i)I tried to use the lastest version of spirit with the latest version of borland but this fails to compile.
Again, without some more info, we are in the dark. We can't help you if you don't provide the info we need to fix what you claim is broken.
To top it off, the PGI compiler got over that spirit hump and tripped up on something else.
Ditto.
So the net result is:
a) The serializatoin library can no longer built for borland compilers. - a regression. b) The serializatoin library can no longer built for PGI compilers. - no change here.
I may have some details wrong in the above recollection. Of course had I known this was going to be such a hassle, I might have kept better notes and brought it up at the time. But then again if I had known how much time was going to be wasted on this, I would have just ignored the "deprecation" warnings. I'll probably just back out these changes and do that.
But to go back and verify all this with a minimal.cpp file is more than I have time for right now. Sorry.
Robert, you cannot claim that our stragegy was a failure just because of that account! If you can't provide a minimal test case, then what you are saying is unfounded. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Sun Jan 04 2009, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
Robert Ramey wrote:
Well, it will take me some time to reconstruct what happened. Briefly, from memory:
a) I noticed that running the serialization tests most compilers emitted a warning "....deprecated - ? redirectored or ?" I forget.
Here's an example of PP code that does that:
#if BOOST_VERSION >= 103800 #if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__DMC__) # pragma message ("Warning: This header is deprecated. Please use: boost/spirit/include/classic_actor.hpp") #elif defined(__GNUC__) || defined(__HP_aCC) || defined(__SUNPRO_CC) || defined(__IBMCPP__) # warning "This header is deprecated. Please use: boost/spirit/include/classic_actor.hpp" #endif #endif
So, I do not understand how you got that warning
Me neither. I thought at first that PGI might be #defining _MSC_VER as some others do, but http://www.pgroup.com/userforum/viewtopic.php?t=831 seems to belie that notion. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Joel de Guzman wrote:
Robert Ramey wrote:
Robert, you cannot claim that our stragegy was a failure just because of that account!
I suppose your right. Since, I didn't know what you were trying to accomplish - and still don't, I guess I can't really say whether or not your strategy is/was a failure. Remember all I wanted to do was to tweak a couple of files to avoid a warning which included the word "deprecated" in it and permit one more compiler to build the serialization library.
If you can't provide a minimal test case, then what you are saying is unfounded.
LOL - well I didn't make up the scenario I described. So I can't agree it's unfounded. Maybe it would be more accurate to say what I'm saying is "not reproducible" or "unverified" or "unproved". And all I'm saying is that your nomenclature and practices regarding #include, versioning, deprecation, etc. create a lot of confusion and extra work - at least for me. This thread seems to indicate I'm not alone in this. Feel free to address or ignore this complaint as you see fit. Robert Ramey
Robert Ramey wrote:
Joel de Guzman wrote:
Robert Ramey wrote:
Robert, you cannot claim that our stragegy was a failure just because of that account!
I suppose your right. Since, I didn't know what you were trying to accomplish - and still don't, I guess I can't really say whether or not your strategy is/was a failure. Remember all I wanted to do was to tweak a couple of files to avoid a warning which included the word "deprecated" in it and permit one more compiler to build the serialization library.
If you can't provide a minimal test case, then what you are saying is unfounded.
LOL - well I didn't make up the scenario I described. So I can't agree it's unfounded. Maybe it would be more accurate to say what
You can LOL all you want, but what was your basis? The problems you mention might be symptoms of other problems not related to Spirit at all. At best, these are just wild guesses and suspicions. And without real proof, we cannot really know.
I'm saying is "not reproducible" or "unverified" or "unproved".
Unfounded: "Without a basis in reason or fact" seems a better fit, IMO. Your reasoning is flawed because it is not based on hard facts, just suspicions based on circumstances.
And all I'm saying is that your nomenclature and practices regarding #include, versioning, deprecation, etc. create a lot of confusion and extra work - at least for me. This thread seems to indicate I'm not alone in this. Feel free to address or ignore this complaint as you see fit.
So, tell me who else has this problem? AFAICT, it's only you. Andrey has "used it in several projects with great success". His concern has nothing to do with the include structures you complain about so vehemently. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Unfounded: "Without a basis in reason or fact" seems a better fit, IMO. Your reasoning is flawed because it is not based on hard facts, just suspicions based on circumstances.
Robert says: "I had trouble", You say "You shouldn't". The whole thread is in a dead lock here, because both sides IMHO are right in some sense: Yes, your solution is fine and withstands complaints, because the educated can migrate. Yes, Robert (and I) had some head scratch at first contact with your solution. Take it or not. This is what we find in the world literature (Winnie the Pooh): <cite author="A.A.Milne"> When you [...] Think of Things, you find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it. </cite> Robert looks at your solution and states:
And all I'm saying is that your nomenclature and practices regarding #include, versioning, deprecation, etc. create a lot of confusion
Confusion is the keyword.
and extra work - at least for me.
This is debatable. I give you some points here, Joel.
This thread seems to indicate I'm not alone in this. Feel free to address or ignore this complaint as you see fit.
So, tell me who else has this problem?
The problem is: your perfect solution is perfect, but disliked. Me, too, voting against it, due to confusion. I already stated in the thread "Breaking existing libraries" that the complete redesign of the interface should have forced a new name for the library. I know there is a thin line between new library and new version of a library, but spirit2 is NOT a new version of spirit at all. It is a 250% redesign and concept rework based on completely different libs like proto. I drop into this discussion here because for future changes of the boost library I'd like to see some rules established that disallow such header magic for well-established, mature parts of boost. best regards, Markus
Markus Werle wrote:
Joel de Guzman wrote:
The problem is: your perfect solution is perfect, but disliked. Me, too, voting against it, due to confusion.
I already stated in the thread "Breaking existing libraries" that the complete redesign of the interface should have forced a new name for the library.
I know there is a thin line between new library and new version of a library, but spirit2 is NOT a new version of spirit at all. It is a 250% redesign and concept rework based on completely different libs like proto.
I drop into this discussion here because for future changes of the boost library I'd like to see some rules established that disallow such header magic for well-established, mature parts of boost.
Oh man! Here I go again: If you have some problems, please do as a we normally do: post a minimal cpp file that exhibits the problem. Better yet, submit a trac ticket. Otherwise, I can never every know what the problem really is. What you are saying is not what Robert is saying. Robert says that the solution is flawed. You say it is perfect but disliked. Did you lose context here? Is what you are saying related to the new header structure at all? What "header magic" is it you are talking about? Header forwarding is not magic at all. People do it all the time. I'm confused. More confused than ever. If it is the new features and names you are complaining about, then this is the wrong thread. This thread is about Robert's assertion that the new header structure causes breakage. If it is the new names you are complaining about, I won't comment further on it as I've said enough in the other threads. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Markus Werle wrote:
I drop into this discussion here because for future changes of the boost library I'd like to see some rules established that disallow such header magic for well-established, mature parts of boost.
Oh man! Here I go again: If you have some problems, please do as a we normally do: post a minimal cpp file that exhibits the problem. Better yet, submit a trac ticket. Otherwise, I can never every know what the problem really is.
First of all: I am sorry to add to your frustration here. You did not deserve this, since the work you do for us all outweighs *any* pain we might have with one of your libraries. So I am in a beggars position anyway. All I am trying to do is give you the feedback about some issues about decisions which were made to ease user's life, but probably do not always completely reach this goal as expected. I read with great interest about how many people get confused about what has happened to spirit in the last few releases. Therefore I really think that we have a problem here, even - yes! - even if we cannot write a ticket about it or write a minimal cpp file. I'll give it another try below, because maybe I am wrong and then this should be clarified once for all times.
What you are saying is not what Robert is saying. Robert says that the solution is flawed.
I *thought* we aim into the same direction, namely *not* to do the /classic/ header magic.
You say it is perfect but disliked.
The result is the same: Spirit-2 and Spirit-1 should not be in the same directory.
Did you lose context here?
I hope not. But I am unsure, of course. We were talking about issues with Spirit-1 vs. Spirit-2?
Is what you are saying related to the new header structure at all? What "header magic" is it you are talking about? Header forwarding is not magic at all. People do it all the time.
So here I try again. I see 3 main issues with the new spirit: 1. A lot of Confusion is due to some _minor_ potential for improvement in the docs. 2. Spirit-2b is a break-all-of-the-interface-change. Merging it with the old Spirit was the wrong decision. Here are some details: 1. I was mislead by the directory structure of spirit: When I had obtained the new boost version I directly went to libs/spirit/index.html and found the Spirit-2b docs. OK, so Spirit-2b is a first class citizen and the preferred version to use? No, I got it wrong. From the ML I learned you had taken measures to make migration as smooth as possible. Also I found: <cite thread="[spirit2] Documentation?">
[Joel writes:] Caveat: It's a work in progress. I hope we can finally find the time to complete the docs. </cite> I really do not understand, why the beta version of the library Spirit-2b has its beta docs at the *standard* place libs/spirit/index.html while Spirit-1 is what I get when I #include <boost/spirit.hpp>. So I felt uncomfortable. More uncertainity when you come from http://www.boost.org/doc/libs/1_37_0: Now you are pointed to http://www.boost.org/doc/libs/1_37_0/libs/spirit/classic/index.html. Sigh. That's really uncool. Really. It made me *feel* something was broken here, even if it is not. Confusion also due to this: The place of the Spirit-2b docs indicates to me that Spirit-2b is the preferred library to use from now on, but at the same time you write in the ML that there are performance issues and that the docs are incomplete. Also Spirit-1 still is the first class citizen regarding the header files. I think most *confusion* can be erased if libs/spirit/index.html had some explanatory text (copy'n'paste from all of your many many postings and include portions of the change log) about what is what and which version is where, just in order to help people decide which version of spirit to use and HOW to use it. Also 1_37_0/libs/spirit/classic/change_log.html says "For more details about this change please consult the documentation." But which documentation is meant? The new one? The old one? Any links? 2. Spirit-2b is a break-all-of-the-interface-change. I understand that some people prefer it to be in directory spirit2 and you prefer it to be merged with spirit-1. I respect your opinion and your freedom but I strongly disagree. Since Spirit-1 is very important, I am happy to hear it will stay in boost for a looong time. I have so much code depending on spirit-1 I cannot afford a removal of spirit-1 from boost. I am not the only one. So you cannot deprecate the usage of Spirit-1, due to so many people using it around the world. Spirit-1 and Spirit-2 must stay inside the boost distro side-by-side. This is the key point. Where we disagree is the semantics of side-by-side. IMHO spirit/home/classic/* and spirit/* are not side-by-side. IMHO spirit/ and spirit2/ is truly side-by-side. You wrote a new library. It retakes the ideas of spirit-1. It uses completely different concepts. It is based on new cool stuff like fusion/proto/etc. . It has a completely different interface. It introduces many many new features and functionality. For me this library (which you call Spirit-2) is something so fundamentally new, it should a) undergo some review (at least concerning the interface) b) reside in its own directory
I'm confused. More confused than ever. If it is the new features and names you are complaining about, then this is the wrong thread.
No, not complaining here.
This thread is about Robert's assertion that the new header structure causes breakage.
I think even in the absence of a minimal.cpp or other proof we should believe Robert who said that he had some trouble. He described it earlier in this thread. Would be nice to fix that using minimal.cpp, but if (!show_proof()) { no_problem_exists(); } else { fix_code(); } is not the perfect code. I prefer: if (true) { separate_the_two_libraries(); } Markus
Let me say up front that I have a *lot* of sympathy for your experience with the documentation not matching the code. That sounds like a serious problem. on Fri Jan 09 2009, Markus Werle <numerical.simulation-AT-web.de> wrote:
Since Spirit-1 is very important, I am happy to hear it will stay in boost for a looong time. I have so much code depending on spirit-1 I cannot afford a removal of spirit-1 from boost.
I am not the only one. So you cannot deprecate the usage of Spirit-1, due to so many people using it around the world.
Well, yeah, he can... and he can do it without affecting anyone (other than psychologically). Deprecation merely announces an intention to stop supporting the legacy technology someday.
For me this library (which you call Spirit-2) is something so fundamentally new, it should a) undergo some review (at least concerning the interface) b) reside in its own directory
Well, Joel doesn't develop his library in a vacuum. There's a strong Spirit community that reviews all of his design decisions. There's no voting, of course, but I don't think that would be appropriate here.
This thread is about Robert's assertion that the new header structure causes breakage.
I think even in the absence of a minimal.cpp or other proof we should believe Robert who said that he had some trouble. He described it earlier in this thread.
Nobody doubts that Robert had some trouble, but I am not at all sure whether to believe his diagnosis of the reasons for his trouble or whether those reasons are still present in the released Spirit codebase or just the pre-release code he was using.
Would be nice to fix that using minimal.cpp, but
if (!show_proof()) { no_problem_exists(); } else { fix_code(); }
is not the perfect code. I prefer:
if (true) { separate_the_two_libraries(); }
The problem is that, without knowing what really went wrong, we have no assurance that separate_the_two_libraries() will fix the problems. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Let me say up front that I have a *lot* of sympathy for your experience with the documentation not matching the code. That sounds like a serious problem.
And clearly, Markus is wrong. The main link is the one found in http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm: http://www.boost.org/doc/libs/1_37_0/libs/spirit/index.html That has been the main link since Spirit was accepted into Boost. It has not changed. This: BOOST_ROOT/libs/spirit/index.html Points to that documentation. And it contains the original 1.8 docs. Not 2.0 as Markus pointed out. Please check it out again, Markus. You might have seen the one in the trunk. The one we released in 1.37 has the 2.0 docs well hidden. And it will be so in each release until we have 2.0 final. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
And clearly, Markus is wrong. [...] You might have seen the one in the trunk.
Yes, you are right. I should have checked more carefully, sorry. It was the svn trunk, not 1.37
The one we released in 1.37 has the 2.0 docs well hidden. And it will be so in each release until we have 2.0 final.
Maybe retake my proposal to have a document from which one can fork in both directions. I already tested version 2 and find it awesome in may aspects. best regards, Markus
Markus Werle wrote:
And clearly, Markus is wrong. [...] You might have seen the one in the trunk.
Yes, you are right. I should have checked more carefully, sorry. It was the svn trunk, not 1.37
The one we released in 1.37 has the 2.0 docs well hidden. And it will be so in each release until we have 2.0 final.
Maybe retake my proposal to have a document from which one can fork in both directions. I already tested version 2 and find it awesome in may aspects.
That is indeed the plan. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
David Abrahams wrote:
For me this library (which you call Spirit-2) is something so fundamentally new, it should a) undergo some review (at least concerning the interface) b) reside in its own directory
Well, Joel doesn't develop his library in a vacuum.
Really? How can he move so fast then? ;-P
There's a strong Spirit community that reviews all of his design decisions. There's no voting, of course, but I don't think that would be appropriate here.
Could you please explain why you think it is not appropriate to vote about a completely new interface that enters boost? I mean Spirit-X maybe once enters the C++ standard. It's already the most important parser library of the world. So it is better not to carve errors in stone at a stage that yet allows changes. Is it a problem if we all check this for user's issues *after* the inner circle is satisfied? best regards, Markus
on Sat Jan 10 2009, Markus Werle <numerical.simulation-AT-web.de> wrote:
David Abrahams wrote:
For me this library (which you call Spirit-2) is something so fundamentally new, it should a) undergo some review (at least concerning the interface) b) reside in its own directory
Well, Joel doesn't develop his library in a vacuum.
Really? How can he move so fast then? ;-P
There's a strong Spirit community that reviews all of his design decisions. There's no voting, of course, but I don't think that would be appropriate here.
Could you please explain why you think it is not appropriate to vote about a completely new interface that enters boost?
The rules of Boost strike a careful balance between quality control and author freedom. I never thought I'd hear myself say this, but "excessive regulation hurts the marketplace and suppresses innovation." Aside from that, it's _not_ a completely new interface. The code I see in the Spirit-2 tutorial looks *very* familiar to me as someone familiar with Spirit-1. Certainly, the interface to Boost.Python 2.0 was much more different from Boost.Python 1 than that is.
I mean Spirit-X maybe once enters the C++ standard. It's already the most important parser library of the world. So it is better not to carve errors in stone at a stage that yet allows changes. Is it a problem if we all check this for user's issues *after* the inner circle is satisfied?
Go ahead, please. I have every confidence that the Spirit developers will be responsive to your observations. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Markus Werle wrote:
Joel de Guzman wrote:
Markus Werle wrote:
I drop into this discussion here because for future changes of the boost library I'd like to see some rules established that disallow such header magic for well-established, mature parts of boost. Oh man! Here I go again: If you have some problems, please do as a we normally do: post a minimal cpp file that exhibits the problem. Better yet, submit a trac ticket. Otherwise, I can never every know what the problem really is.
First of all: I am sorry to add to your frustration here. You did not deserve this, since the work you do for us all outweighs *any* pain we might have with one of your libraries. So I am in a beggars position anyway.
No apologies needed. This thread you replied to was intended to clarify one point: Robert's statement that the new header structure causes breakage. I think the confusion is that so many issues are bundled together into one. That is why I renamed the title of this thread to focus on only that specific issue: 1) I said we want 100% backward compatibility while at the same time usher in the new generation. 2) Robert says it was a "failure" and gave a narative of the events leading to his conclusion that the include strategy causes code breakage, hence, not 100% backward compatible. 3) I asked for a minimal cpp file that exhibits the problem.
All I am trying to do is give you the feedback about some issues about decisions which were made to ease user's life, but probably do not always completely reach this goal as expected.
Fair enough. I'll try to reply to each of your points below. It's unfortunate that the focus is lost again, but, anyway...
1. A lot of Confusion is due to some _minor_ potential for improvement in the docs.
2. Spirit-2b is a break-all-of-the-interface-change. Merging it with the old Spirit was the wrong decision.
Here are some details:
1. I was mislead by the directory structure of spirit:
When I had obtained the new boost version I directly went to libs/spirit/index.html and found the Spirit-2b docs.
See my other post too. No, that is wrong. BOOST_ROOT/libs/spirit/index.html still (as of 1.37) points to the classic documents. You must be confusing it with the one in the trunk.
OK, so Spirit-2b is a first class citizen and the preferred version to use?
No. Not at this point.
No, I got it wrong. From the ML I learned you had taken measures to make migration as smooth as possible.
Also I found: <cite thread="[spirit2] Documentation?">
[Joel writes:] Caveat: It's a work in progress. I hope we can finally find the time to complete the docs. </cite>
I really do not understand, why the beta version of the library Spirit-2b has its beta docs at the *standard* place libs/spirit/index.html while Spirit-1 is what I get
Check the Boost 1.37 again, please. The *standard* place libs/spirit/index.html *HAS* spirit-1.
when I #include <boost/spirit.hpp>. So I felt uncomfortable.
Which also has Spirit1.
More uncertainity when you come from http://www.boost.org/doc/libs/1_37_0: Now you are pointed to http://www.boost.org/doc/libs/1_37_0/libs/spirit/classic/index.html.
Again, Spirit1.
Sigh. That's really uncool. Really. It made me *feel* something was broken here, even if it is not.
Agreed.
Confusion also due to this: The place of the Spirit-2b docs indicates to me that Spirit-2b is the preferred library to use from now on,
No. It is not.
but at the same time you write in the ML that there are performance issues and that the docs are incomplete. Also Spirit-1 still is the first class citizen regarding the header files.
I think most *confusion* can be erased if libs/spirit/index.html had some explanatory text
That is a good idea, but that is not the case. As far as the release is concerned. Perhaps we can do that for the trunk to avoid further confusion.
(copy'n'paste from all of your many many postings and include portions of the change log) about what is what and which version is where, just in order to help people decide which version of spirit to use and HOW to use it.
Sure. Ok.
Also 1_37_0/libs/spirit/classic/change_log.html says "For more details about this change please consult the documentation." But which documentation is meant? The new one? The old one? Any links?
Ok.
2. Spirit-2b is a break-all-of-the-interface-change. I understand that some people prefer it to be in directory spirit2 and you prefer it to be merged with spirit-1. I respect your opinion and your freedom but I strongly disagree.
Right now, a developer can update/enhance/improve his library anyway he sees fit without further review. If you or anyone else want to change the rules, work on it actively. Writing a draft proposal is a good first step. I'll abide by the rules when we have them. For now, we don't have such a rule.
Since Spirit-1 is very important, I am happy to hear it will stay in boost for a looong time. I have so much code depending on spirit-1 I cannot afford a removal of spirit-1 from boost.
I am not the only one. So you cannot deprecate the usage of Spirit-1,
Spirit-1 is *NOT* deprecated. Only the old headers are deprecated.
due to so many people using it around the world. Spirit-1 and Spirit-2 must stay inside the boost distro side-by-side. This is the key point.
Where we disagree is the semantics of side-by-side. IMHO spirit/home/classic/* and spirit/* are not side-by-side. IMHO spirit/ and spirit2/ is truly side-by-side.
You wrote a new library. It retakes the ideas of spirit-1. It uses completely different concepts. It is based on new cool stuff like fusion/proto/etc. . It has a completely different interface. It introduces many many new features and functionality.
For me this library (which you call Spirit-2) is something so fundamentally new, it should a) undergo some review (at least concerning the interface) b) reside in its own directory
Again, if you want to see the rules changed. Work on it. Advocacy is good. You can start with a formal proposal for discussion. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Markus Werle wrote: [...]
2. Spirit-2b is a break-all-of-the-interface-change. I understand that some people prefer it to be in directory spirit2 and you prefer it to be merged with spirit-1. I respect your opinion and your freedom but I strongly disagree.
Right now, a developer can update/enhance/improve his library anyway he sees fit without further review.
That is exactly my point. I do not regard Spirit-2 as update, enhancement or improvement. I see it as something completely new and different. OK, yes, it is an enhancement and improvement, but not in an evolutionary sense. I do not see any evolution, I see big changes. There's no brick on the other anymore.
If you or anyone else want to change the rules,
I thought that the rules already disallow the change of 90% of the interface at once. I thought that the boost community was rather conservative regarding interface changes. Are there any tools to measure code distances? Or should we write on based on Spirit-2?
[...] Spirit-1 is *NOT* deprecated. Only the old headers are deprecated.
Can you write this sentence into the main html page Introduction chapter of the docs? best regards, Markus
Markus Werle wrote:
Joel de Guzman wrote:
Markus Werle wrote: [...]
2. Spirit-2b is a break-all-of-the-interface-change. I understand that some people prefer it to be in directory spirit2 and you prefer it to be merged with spirit-1. I respect your opinion and your freedom but I strongly disagree. Right now, a developer can update/enhance/improve his library anyway he sees fit without further review.
That is exactly my point. I do not regard Spirit-2 as update, enhancement or improvement. I see it as something completely new and different. OK, yes, it is an enhancement and improvement, but not in an evolutionary sense. I do not see any evolution, I see big changes. There's no brick on the other anymore.
AFAIK, there's no rule that prevents an author from completely rewriting his library either. Such things are common when moving to a major version.
If you or anyone else want to change the rules,
I thought that the rules already disallow the change of 90% of the interface at once. I thought that the boost community was rather conservative regarding interface changes.
I am not aware of such a rule. I've seen major changes happen. Yet, we took great pains in ensuring that the old headers are kept intact (100% backward compatibility). We made sure that the user can be able to migrate at her own pace without panic. That was a must. Many already rely on Spirit 1.8.x codebase and we do not want to cause the slightest disruption ever. Even Hartmut Kaiser's (a major Spirit developer) wave project still relies on Spirit 1.8.x.
Are there any tools to measure code distances? Or should we write on based on Spirit-2?
[...] Spirit-1 is *NOT* deprecated. Only the old headers are deprecated.
Can you write this sentence into the main html page Introduction chapter of the docs?
Definitely. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Sat Jan 10 2009, Markus Werle <numerical.simulation-AT-web.de> wrote:
I thought that the rules already disallow the change of 90% of the interface at once.
There is no such rule.
I thought that the boost community was rather conservative regarding interface changes.
It is, rather. And as far as I can tell, the Spirit developers are being conservative, and painstakingly responsible to their existing users. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Robert Ramey wrote:
Joel de Guzman wrote:
It's not an easy task, mind you. A lot of neurons were employed until we came up with the best practical approach.
The problem is that you tried to make it too clever. So it works in almost all cases. However, if it fails in just one case, then I have to start spending time to investigate. First there is the baroque directory structure. This creates a problem for me in that I never included just "spirit" but rather the lower level directories in order to included just the facilities that I used. So then I had to spend time to figure out what I should include. Then I come accross new names, etc. so then I have to try to "know more beyond the name(s)." which takes more time. The most irksome part of this is that it is totally unnecessary.
Yes, this is totally unnecessary. Show us the problem code that caused you this misery and we'll fix it. The changes came before two release cycles (IIRC). I haven't seen you report anything other than adding a version info for Spirit2 (which we did). Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Robert Ramey wrote:
Joel de Guzman wrote:
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster. Just curious. How much time did you waste before you realize
Robert Ramey wrote: that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
Here are examples where time has been wasted.
All of a sudden, one some platform the serialization library fails to build. After a time, an investigation reveals that the #include <boost/spiritsomefile> get redirected in some baroque non-obvious way to something like boost/spirit/class.. or something like that. OK - I'll just tweak the library so that it includes the "classic" targets directly.
This should not happen. We engineered the code to be 100% backward compatible. You do not even have to tweak the include paths. At most, you'll get a warning, but that warning should not kick in until Boost 1.38. Please post a minimal cpp file that exhibits the problem. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Robert Ramey wrote:
Here's a suggestion.
for your latest/greatest, put in the namespace boost::spirit and in directory boost/sprit
Doing so will break existing code.
For your old version, with an incompatible API, put it in namespace boost::spririt_1_8 and directory boost/spririt_1_8.
Doing so will break existing code.
and for your older version put it in boost::spririt_1_6 and directory boost/spririt_1_6
Doing so will break existing code. If you look beyond the name(s) I'm sure you'll see why our recipe is superior to your suggestion. 100% backward compatibility is a primary concern. Here's our strategy: "classic" 1) Keep the old header/directory structure as-is. 2) Move the 1.8 directory tree to spirit/home/classic 3) Make the old headers forward to the moved headers. 4) Provide a deprecation warning that will point the user to the new header file. This warning should not kick in until Boost 1.38. 5) Put the "classic" components in namespace spirit::classic 6) Provide a macro, BOOST_SPIRIT_USE_OLD_NAMESPACE, such that if the user includes the old headers, the components are not hoisted into the "classic" namespace (backward compatibility mode)) "new generation" 1) Place them in spirit/home/xxx, where xxx is a new module (sub-library) name. 2) Place them in namespace spirit::xxx. If you see compatibility problems with the current strategy, we'll appreciate it if you provide a minimal cpp file that exhibits the problem. Otherwise, we'll never really know what it is you are complaining about. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Robert Ramey wrote:
Hartmut Kaiser wrote:
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster.
Just curious. How much time did you waste before you realize that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
I'll just chip in my 2 cents. If I may be so bold, I think a lot of the discussion about "descriptive names" is looking at things in a somewhat backwards fashion. It's rare that I see a library name and then look up what it does (I'd have to be pretty bored). What is more commonly the case for me as boost user is that I need to find a library to perform a specific task. After using boost for a number of years, I know what most libraries are for. But when I first started using it, I often had thoughts along the following lines: "Hmm, I'm about to do some parsing here" "Boost *must* have some libraries for this kind of thing" [Points browser at http://www.boost.org/doc/libs/1_37_0] "Hmmm..." [Skim-reads list of libraries] "Format might be useful too..." "Regex, perhaps?" "Tokenizer might be handy..." "That's about it." It is from this point that I'll read more about the libraries that I've identified as being relevant (from their names). I admit the example is somewhat contrived and I'm only picking on Spirit because it is already part of this discussion, but it isn't in my list because I wouldn't have guessed from its name that it does parsing. So I solider on, writing some kind of ad-hoc parser out of these libraries. Now there's *a lot* of (hypothetical) time wasted there. With all that said, I personally have absolutely nothing against "cute" library names. But I am in full agreement with those that have already have highlighted the removal/hiding of a categorization page as a bad thing. If I can search for libraries by the task they perform, I couldn't care less what they're called. In summary: 1. descriptive names can help 2. but they wouldn't matter if I could find libraries based on task. 3. I like Spirit :) FWIW, I would prefer a tag cloud/list over flat or even hierarchical categorization of libraries e.g. http://delicious.com/edd_dawson Kind regards, Edd
Hartmut Kaiser wrote:
So, please let me use this thread for a selfless plug :-P. Boost already has a versatile and powerful output formatting library: Spirit V2!
You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have problems using Spirit.Karma either.
This sounded so cool that I took a look at it...
Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I first tried reading the docs, but karma is not yet covered. So I went to "boost_trunk\libs\spirit\example\karma" and typed "bjam --toolset=msvc", in order to play with the examples. bjam complained about line 11 of Jamfile ("exe actions : actions.cpp ;", "actions" seems to collide with a bjam keyword), so I removed this line and tried again. It took a surprising long time, and two files failed to compile (quick_start1.cpp and basic_facilities.cpp). I guess I should have used V1.37 instead of trunk, but I'm too lazy to check this. Instead I attached the error-output (errors.txt), because I guess it is something trivial, for somebody with enough experience :-) Regards Thomas
So, please let me use this thread for a selfless plug :-P. Boost already has a versatile and powerful output formatting library: Spirit V2!
You might think, well Spirit used to be a parser library, not something usable for output formatting. But with the event of Spirit V2 this has changed. Spirit V2 now is not only a parser generator library anymore (Spirit Classic, aka V1.x, now called Spirit.Qi), but got extended to cover the domain of (output) generators as well (Spirit.Karma). Admittedly, the docs are not complete yet, but if you know how to build a parser using Spirit.Qi you shouldn't have
Hartmut Kaiser wrote: problems using Spirit.Karma either.
This sounded so cool that I took a look at it...
Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I first tried reading the docs, but karma is not yet covered. So I went to "boost_trunk\libs\spirit\example\karma" and typed "bjam -- toolset=msvc", in order to play with the examples. bjam complained about line 11 of Jamfile ("exe actions : actions.cpp ;", "actions" seems to collide with a bjam keyword),
Doh! Is that documented somewhere?
so I removed this line and tried again. It took a surprising long time, and two files failed to compile (quick_start1.cpp and basic_facilities.cpp).
Yes, compile times are an issue right now. But we're working on improving things.
I guess I should have used V1.37 instead of trunk, but I'm too lazy to check this. Instead I attached the error-output (errors.txt), because I guess it is something trivial, for somebody with enough experience :-)
Thanks, I'll have a look. Shouldn't be something serious. Regards Hartmut
Thomas,
Everything is in the SVN (and in Boost V1.37, BTW) and the examples should provide a fairly good starting point.
I first tried reading the docs, but karma is not yet covered. So I went to "boost_trunk\libs\spirit\example\karma" and typed "bjam -- toolset=msvc", in order to play with the examples. bjam complained about line 11 of Jamfile ("exe actions : actions.cpp ;", "actions" seems to collide with a bjam keyword), so I removed this line and tried again. It took a surprising long time, and two files failed to compile (quick_start1.cpp and basic_facilities.cpp). I guess I should have used V1.37 instead of trunk, but I'm too lazy to check this. Instead I attached the error-output (errors.txt), because I guess it is something trivial, for somebody with enough experience :-)
These things are fixed in SVN now. Thanks! Regards Hartmut
participants (21)
-
Andrew Sutton -
Andrey Semashev -
Brian Ravnsgaard Riis -
dan marsden -
Daniel James -
David Abrahams -
Edd Dawson -
Hartmut Kaiser -
Jeff Flinn -
Joel de Guzman -
Markus Werle -
Mathias Gaunard -
Peter Dimov -
Peter Simons -
Robert Ramey -
Scott McMurray -
Sebastian Redl -
Steven Watanabe -
Thomas Klimpel -
Tom Browder -
Vladimir Batov