From a4a2a0ee6b2a68b0bb0309d85e1995b49694099a Mon Sep 17 00:00:00 2001 From: octopus-prime Date: Wed, 6 Dec 2017 21:29:43 +0100 Subject: [PATCH] Fix phoenix links --- doc/faq.qbk | 4 ++-- doc/karma/auxiliary.qbk | 4 ++-- doc/karma/complex.qbk | 2 +- doc/karma/quick_reference.qbk | 4 ++-- doc/lex/lexer_quickstart2.qbk | 8 ++++---- doc/lex/lexer_quickstart3.qbk | 6 +++--- doc/lex/lexer_semantic_actions.qbk | 4 ++-- doc/lex/quick_reference.qbk | 4 ++-- doc/notes/porting_from_1_8.qbk | 2 +- doc/preface.qbk | 2 +- doc/qi/quick_reference.qbk | 4 ++-- doc/spirit2.qbk | 3 +-- doc/what_s_new.qbk | 6 +++--- repository/doc/spirit2_repository.qbk | 3 +-- 14 files changed, 27 insertions(+), 29 deletions(-) diff --git a/doc/faq.qbk b/doc/faq.qbk index 385a360e2..da4575495 100644 --- a/doc/faq.qbk +++ b/doc/faq.qbk @@ -113,9 +113,9 @@ Again, don't use any of the header files underneath the boost/spirit/home directory directly, always include files from the boost/spirit/include directory. -The last bit missing is __boost_phoenix__ (which currently still lives under the +The last bit missing is __phoenix__ (which currently still lives under the Spirit umbrella, but already has been accepted as a Boost library, so it will -move away). __boost_phoenix__ is a library allowing to write functional style C++, +move away). __phoenix__ is a library allowing to write functional style C++, which is interesting in itself, but as it initially has been developed for Spirit, it is nicely integrated and very useful when it comes to writing semantic actions. I think using the boost/spirit/include/phoenix_... headers diff --git a/doc/karma/auxiliary.qbk b/doc/karma/auxiliary.qbk index 94f5656ac..56c6edafb 100644 --- a/doc/karma/auxiliary.qbk +++ b/doc/karma/auxiliary.qbk @@ -389,7 +389,7 @@ not defined in __generator_concept__. [table [[Expression] [Semantics]] - [[`fg`] [The __boost_phoenix__ function object `fg` will be + [[`fg`] [The __phoenix__ function object `fg` will be invoked at generate time. It is expected to return a generator instance. This generator is then invoked in order to generate the output. This generator will @@ -399,7 +399,7 @@ not defined in __generator_concept__. [[`lazy(fg)`] [The function or function object will be invoked at generate time. It is expected to return a generator instance (note this version of `lazy` does not - require `fg` to be a __boost_phoenix__ function + require `fg` to be a __phoenix__ function object). This generator is then invoked in order to generate the output. This generator will succeed as long as the invoked generated succeeds as well (except diff --git a/doc/karma/complex.qbk b/doc/karma/complex.qbk index d8351a87a..0a2285dcc 100644 --- a/doc/karma/complex.qbk +++ b/doc/karma/complex.qbk @@ -15,7 +15,7 @@ are the real and imaginary parts of the complex number) or as a simple `real` if the imaginary part happens to be equal to zero. This example will highlight the power of __karma__ allowing to combine compile time definition of formatting rules with runtime based decisions which of the rules to apply. -Also this time, we're using __boost_phoenix__ to do the semantic actions. +Also this time, we're using __phoenix__ to do the semantic actions. Our goal is to allow for two different output formats to be applied depending on whether the imaginary part of the complex number is zero or not. Let's write diff --git a/doc/karma/quick_reference.qbk b/doc/karma/quick_reference.qbk index 541cf71f6..5980279ec 100644 --- a/doc/karma/quick_reference.qbk +++ b/doc/karma/quick_reference.qbk @@ -660,12 +660,12 @@ For more information see __karma_actions__. [/////////////////////////////////////////////////////////////////////////////] [section Phoenix] -__boost_phoenix__ makes it easier to attach semantic actions. You just +__phoenix__ makes it easier to attach semantic actions. You just inline your lambda expressions: g[phoenix-lambda-expression] -__karma__ provides some __boost_phoenix__ placeholders to access important +__karma__ provides some __phoenix__ placeholders to access important information from the `Attrib` and `Context` that are otherwise fiddly to extract. [variablelist Spirit.Karma specific Phoenix placeholders diff --git a/doc/lex/lexer_quickstart2.qbk b/doc/lex/lexer_quickstart2.qbk index d10893153..483761bc7 100644 --- a/doc/lex/lexer_quickstart2.qbk +++ b/doc/lex/lexer_quickstart2.qbk @@ -24,11 +24,11 @@ see here: [@../../example/lex/word_count_lexer.cpp word_count_lexer.cpp]). [heading Prerequisites] In addition to the only required `#include` specific to /Spirit.Lex/ this -example needs to include a couple of header files from the __boost_phoenix__ +example needs to include a couple of header files from the __phoenix__ library. This example shows how to attach functors to token definitions, which could be done using any type of C++ technique resulting in a callable object. -Using __boost_phoenix__ for this task simplifies things and avoids adding -dependencies to other libraries (__boost_phoenix__ is already in use for +Using __phoenix__ for this task simplifies things and avoids adding +dependencies to other libraries (__phoenix__ is already in use for __spirit__ anyway). [wcl_includes] @@ -59,7 +59,7 @@ brackets will be executed whenever the corresponding token has been matched by the lexical analyzer. This is very similar to __flex__, where the action code associated with a token definition gets executed after the recognition of a matching input sequence. The code above uses function objects constructed using -__boost_phoenix__, but it is possible to insert any C++ function or function object +__phoenix__, but it is possible to insert any C++ function or function object as long as it exposes the proper interface. For more details on please refer to the section __sec_lex_semactions__. diff --git a/doc/lex/lexer_quickstart3.qbk b/doc/lex/lexer_quickstart3.qbk index ab724bdec..68121d353 100644 --- a/doc/lex/lexer_quickstart3.qbk +++ b/doc/lex/lexer_quickstart3.qbk @@ -41,11 +41,11 @@ of semantic actions of a parser (for the full example code see here: This example uses two of the __spirit__ library components: __lex__ and __qi__, consequently we have to `#include` the corresponding header files. Again, we -need to include a couple of header files from the __boost_phoenix__ library. This +need to include a couple of header files from the __phoenix__ library. This example shows how to attach functors to parser components, which could be done using any type of C++ technique resulting in a callable object. -Using __boost_phoenix__ for this task simplifies things and avoids adding -dependencies to other libraries (__boost_phoenix__ is already in use for +Using __phoenix__ for this task simplifies things and avoids adding +dependencies to other libraries (__phoenix__ is already in use for __spirit__ anyway). [wcp_includes] diff --git a/doc/lex/lexer_semantic_actions.qbk b/doc/lex/lexer_semantic_actions.qbk index fd2fbec2f..b1b254412 100644 --- a/doc/lex/lexer_semantic_actions.qbk +++ b/doc/lex/lexer_semantic_actions.qbk @@ -116,7 +116,7 @@ gives an overview and a short description of the available functionality. Even if it is possible to write your own function object implementations (i.e. using Boost.Lambda or Boost.Bind), the preferred way of defining lexer semantic -actions is to use __boost_phoenix__. In this case you can access the parameters +actions is to use __phoenix__. In this case you can access the parameters described above by using the predefined __spirit__ placeholders: [table Predefined Phoenix placeholders for lexer semantic actions @@ -153,7 +153,7 @@ described above by using the predefined __spirit__ placeholders: ] The context object passed as the last parameter to any lexer semantic action is -not directly accessible while using __boost_phoenix__ expressions. We rather provide +not directly accessible while using __phoenix__ expressions. We rather provide predefined Phoenix functions allowing to invoke the different support functions as mentioned above. The following table lists the available support functions and describes their functionality: diff --git a/doc/lex/quick_reference.qbk b/doc/lex/quick_reference.qbk index 69010f1cf..1b837ec79 100644 --- a/doc/lex/quick_reference.qbk +++ b/doc/lex/quick_reference.qbk @@ -88,12 +88,12 @@ For more information see __lex_actions__. [/////////////////////////////////////////////////////////////////////////////] [section Phoenix] -__boost_phoenix__ makes it easier to attach semantic actions. You just +__phoenix__ makes it easier to attach semantic actions. You just inline your lambda expressions: l[phoenix-lambda-expression] -__lex__ provides some __boost_phoenix__ placeholders to access important +__lex__ provides some __phoenix__ placeholders to access important information from the `Context` that are otherwise difficult to extract. [variablelist Spirit.Lex specific Phoenix placeholders diff --git a/doc/notes/porting_from_1_8.qbk b/doc/notes/porting_from_1_8.qbk index d717d3c2c..e839972ac 100644 --- a/doc/notes/porting_from_1_8.qbk +++ b/doc/notes/porting_from_1_8.qbk @@ -50,7 +50,7 @@ refer to the corresponding reference documentation of this component. [table [[Include file in /Spirit.Classic/] [Include file in /Spirit.Qi/]] [[`classic.hpp`] [`qi.hpp`]] - [[`classic_actor.hpp`] [none, use __boost_phoenix__ for writing semantic actions]] + [[`classic_actor.hpp`] [none, use __phoenix__ for writing semantic actions]] [[`classic_attribute.hpp`] [none, use local variables for rules instead of closures, the primitives parsers now directly support lazy parameterization]] diff --git a/doc/preface.qbk b/doc/preface.qbk index 12e47c356..3680d765e 100644 --- a/doc/preface.qbk +++ b/doc/preface.qbk @@ -109,7 +109,7 @@ Another library had to be written: __fusion__. Fusion sits between MPL and STL --between compile time and runtime -- mapping types to values. Fusion is a direct descendant of both MPL and __boost_tuples__. Fusion is now a full-fledged __boost__ library. __phoenix__ also had to be -beefed up to support Spirit V2. The result is __boost_phoenix__. Last +beefed up to support Spirit V2. The result is __phoenix__. Last but not least, Spirit V2 uses an __exprtemplates__ library called __boost_proto__. diff --git a/doc/qi/quick_reference.qbk b/doc/qi/quick_reference.qbk index 8e1c2933f..dddd96852 100644 --- a/doc/qi/quick_reference.qbk +++ b/doc/qi/quick_reference.qbk @@ -486,12 +486,12 @@ For more detailed information about semantic actions see: [endsect] [section Phoenix] -__boost_phoenix__ makes it easier to attach semantic actions. You just +__phoenix__ makes it easier to attach semantic actions. You just inline your lambda expressions: p[phoenix-lambda-expression] -Spirit.Qi provides some __boost_phoenix__ placeholders to important +Spirit.Qi provides some __phoenix__ placeholders to important information from the `Attrib` and `Context` that are otherwise fiddly to extract. [variablelist Spirit.Qi specific Phoenix placeholders diff --git a/doc/spirit2.qbk b/doc/spirit2.qbk index 1f83e08cc..4d3233ef1 100644 --- a/doc/spirit2.qbk +++ b/doc/spirit2.qbk @@ -27,8 +27,7 @@ [def __spirit__ [@http://boost-spirit.com Spirit]] [def __spirit_list__ [@http://www.nabble.com/The-Spirit-Parser-Library-f3430.html Spirit General List]] -[def __phoenix__ [@../../phoenix/doc/html/index.html Phoenix]] -[def __boost_phoenix__ [@boost:/libs/phoenix/doc/html/index.html Boost.Phoenix]] +[def __phoenix__ [@boost:/libs/phoenix/doc/html/index.html Boost.Phoenix]] [def __fusion__ [@boost:/libs/fusion/doc/html/index.html Boost.Fusion]] [def __mpl__ [@http://www.boost.org/libs/mpl/index.html Boost.Mpl]] [def __stl__ [@http://www.sgi.com/tech/stl/ STL]] diff --git a/doc/what_s_new.qbk b/doc/what_s_new.qbk index 0a56dad7d..5a4c9b516 100644 --- a/doc/what_s_new.qbk +++ b/doc/what_s_new.qbk @@ -81,13 +81,13 @@ [heading What's changed in __qi__ and __karma__ from V2.4.2 (Boost V1.46.0) to V2.5 (Boost V1.47.0)] -This version of __spirit__ now supports the new version of __boost_phoenix__ (V3), +This version of __spirit__ now supports the new version of __phoenix__ (V3), which has been released as part of Boost V1.47. Please note that this support is purely preliminary and should not be considered production quality. The reason why we are releasing this now is to enable people who want to use the -new version of __boost_phoenix__ in their code to do so without any conflicts with +new version of __phoenix__ in their code to do so without any conflicts with existing code using __spirit__. Generally, no __spirit__ code needs to be -changed. To activate the use of __boost_phoenix__ V3 for __spirit__ you need to +changed. To activate the use of __phoenix__ V3 for __spirit__ you need to define the following preprocessor constant for your builds (before including any of Spirit's include files): diff --git a/repository/doc/spirit2_repository.qbk b/repository/doc/spirit2_repository.qbk index e36e861d3..0da3e2d0b 100644 --- a/repository/doc/spirit2_repository.qbk +++ b/repository/doc/spirit2_repository.qbk @@ -23,8 +23,7 @@ [def __spirit__ [@http://boost-spirit.com Spirit]] [def __spirit_list__ [@http://www.nabble.com/The-Spirit-Parser-Library-f3430.html Spirit General List]] -[def __phoenix__ [@../../phoenix/doc/html/index.html Phoenix]] -[def __boost_phoenix__ [@../../phoenix/doc/html/index.html Phoenix2]] +[def __phoenix__ [@boost:/libs/phoenix/doc/html/index.html Boost.Phoenix]] [def __fusion__ [@http://spirit.sourceforge.net/dl_more/fusion_v2/libs/fusion/doc/html/index.html Fusion]] [def __mpl__ [@http://www.boost.org/libs/mpl/index.html MPL]] [def __boost__ [@http://www.boost.org/ Boost]]