From b74ae0a86e6d33f95dba5977887b63bf6e4ce847 Mon Sep 17 00:00:00 2001 From: Christian Granzin Date: Sat, 2 May 2026 12:08:52 -0400 Subject: [PATCH] fix(doc): broken links --- doc/local-playbook.yml | 5 +++++ .../pages/reference/back-end-headers.adoc | 4 ++-- doc/modules/ROOT/pages/tutorial.adoc | 22 ++++++------------- doc/modules/ROOT/pages/tutorial/back-end.adoc | 8 +++---- .../ROOT/pages/tutorial/basic-front-end.adoc | 15 ++++++++----- .../ROOT/pages/tutorial/euml-front-end.adoc | 4 ++-- 6 files changed, 29 insertions(+), 29 deletions(-) diff --git a/doc/local-playbook.yml b/doc/local-playbook.yml index 92d562e3..11740e31 100644 --- a/doc/local-playbook.yml +++ b/doc/local-playbook.yml @@ -70,6 +70,11 @@ asciidoc: - '@cppalliance/asciidoctor-boost-links' - '@asciidoctor/tabs' +runtime: + log: + level: warn + failure_level: warn + # Libraries that support Antora should be included here content: sources: diff --git a/doc/modules/ROOT/pages/reference/back-end-headers.adoc b/doc/modules/ROOT/pages/reference/back-end-headers.adoc index aeaf717b..299aac10 100644 --- a/doc/modules/ROOT/pages/reference/back-end-headers.adoc +++ b/doc/modules/ROOT/pages/reference/back-end-headers.adoc @@ -35,7 +35,7 @@ ShallowHistory. Default is NoHistory. The trade-off performance / compile-time. There are two predefined policies, favor_runtime_speed and favor_compile_time. Default is favor_runtime_speed, best performance, longer compile-time. See -link:#backend-tradeof-rt-ct[the backend]. +xref:tutorial/back-end.adoc#backend-tradeof-rt-ct[the backend]. [[methods]] @@ -47,7 +47,7 @@ link:#backend-tradeof-rt-ct[the backend]. The start methods must be called before any call to process_event. It activates the entry action of the initial state(s). This allows you to -choose when a state machine can start. See link:#backend-start[backend]. +choose when a state machine can start. See xref:tutorial/back-end.adoc#backend-start[backend]. void start diff --git a/doc/modules/ROOT/pages/tutorial.adoc b/doc/modules/ROOT/pages/tutorial.adoc index 5bb18d4b..2fdd123e 100644 --- a/doc/modules/ROOT/pages/tutorial.adoc +++ b/doc/modules/ROOT/pages/tutorial.adoc @@ -2,24 +2,16 @@ = Tutorial -MSM is divided between front-ends and back-ends. At the moment, there is -just one back-end. On the front-end side, you will find three of them -which are as many state machine description languages, with many more +MSM is divided between front-ends and back-ends. +You will find four front-ends, which are as many state machine description languages, with many more possible. For potential language writers, this document contains a -link:#internals-front-back-interface[description of the interface -between front-end and back-end]. +xref:internals.adoc#internals-front-back-interface[description of the interface between front-end and back-end]. The first front-end is an adaptation of the example provided in the http://boostpro.com/mplbook[MPL book] with actions defined as pointers to state or state machine methods. The second one is based on functors. -The third, eUML (embedded UML) is an experimental language based on +The third, eUML (embedded UML) is a deprecated language based on Boost.Proto and Boost.Typeof and hiding most of the metaprogramming to -increase readability. Both eUML and the functor front-end also offer a -functional library (a bit like Boost.Phoenix) for use as action language -(UML defining none). - -// * xref:tutorial/basic-front-end.adoc[Basic front-end] -// * xref:tutorial/functor-front-end.adoc[Functor front-end] -// * xref:tutorial/puml-front-end.adoc[PUML front-end (C++20, experimental)] -// * xref:tutorial/euml-front-end.adoc[eUML front-end (deprecated)] -// * xref:tutorial/back-end.adoc[Back-end] +increase readability. It is superseded by an experimental PUML front-end that allows a more intuitive syntax. +Both eUML and the functor front-end also offer a functional library (a bit like Boost.Phoenix) +for use as action language (UML defining none). diff --git a/doc/modules/ROOT/pages/tutorial/back-end.adoc b/doc/modules/ROOT/pages/tutorial/back-end.adoc index 824e6c01..3b8df22d 100644 --- a/doc/modules/ROOT/pages/tutorial/back-end.adoc +++ b/doc/modules/ROOT/pages/tutorial/back-end.adoc @@ -464,7 +464,7 @@ cases: * many transition conflicts * submachines -The back-end `msm::back11::state_machine` has a policy argument (first +The back-end `msm::back::state_machine` has a policy argument (first is the front-end, then the history policy) defaulting to `favor_runtime_speed`. To switch to `favor_compile_time`, which is declared in ``, you need to: @@ -491,9 +491,9 @@ Independently, transition conflicts resolution will also be much faster. This policy uses boost.any behind the hood, which means that we will lose a feature which MSM offers with the default policy, -link:#event-hierarchy[event hierarchy]. The following example takes our -iPod example and speeds up compile-time by using this technique. We -have: +xref:tutorial/basic-front-end.adoc#event-hierarchy[event hierarchy]. +The following example takes our iPod example and speeds up compile-time +by using this technique. We have: * xref:attachment$iPod_distributed/iPod.cpp[our main state machine and main function] diff --git a/doc/modules/ROOT/pages/tutorial/basic-front-end.adoc b/doc/modules/ROOT/pages/tutorial/basic-front-end.adoc index e9dfdbda..fad08e7f 100644 --- a/doc/modules/ROOT/pages/tutorial/basic-front-end.adoc +++ b/doc/modules/ROOT/pages/tutorial/basic-front-end.adoc @@ -317,9 +317,9 @@ state machine just after creation. The start method will initiate the state machine, meaning it will activate the initial state, which means in turn that the initial state's entry behavior will be called. The reason why we need this will be explained in the -link:#backend-start[back-end part]. After a call to start, the state -machine is ready to process events. The same way, calling `stop()` will -cause the last exit actions to be called. +xref:tutorial/back-end.adoc#backend-start[back-end part]. +After a call to start, the state machine is ready to process events. +The same way, calling `stop()` will cause the last exit actions to be called. [[defining-a-submachine]] @@ -577,7 +577,7 @@ replaced by a History symbol (the H inside a circle). As explained in the `small UML tutorial`, History is a good concept with a not completely satisfying specification. MSM kept the concept but not the specification and goes another way by making this a policy and you -can add your own history types (the link:#history-interface[reference] +can add your own history types (the xref:reference/back-end-headers.adoc#history-interface[reference] explains what needs to be done). Furthermore, History is a backend policy. This allows you to reuse the same state machine definition with different history policies in different contexts. @@ -1133,8 +1133,11 @@ if (p.template is_flag_active()) ... The following diagram displays the flag situation in the tutorial. -image:FlagsTutorial.jpg[image] ### [[event-hierarchy]]Event -Hierarchy +image:FlagsTutorial.jpg[image] + +[[event-hierarchy]] + +== Event Hierarchy There are cases where one needs transitions based on categories of events. An example is text parsing. Let's say you want to parse a string diff --git a/doc/modules/ROOT/pages/tutorial/euml-front-end.adoc b/doc/modules/ROOT/pages/tutorial/euml-front-end.adoc index 66ab5c0e..ff257a86 100644 --- a/doc/modules/ROOT/pages/tutorial/euml-front-end.adoc +++ b/doc/modules/ROOT/pages/tutorial/euml-front-end.adoc @@ -379,7 +379,7 @@ machine where the transition table, initial state, entry and exit actions are defined. Furthermore, attributes (read further on), flags, deferred events and configuration capabilities (no message queue / no exception catching) are added and a non-default base state (see the -link:#backend-base-state[back-end description]) is defined. +xref:tutorial/back-end.adoc#backend-base-state[back-end description]) is defined. For example, a minimum state machine could be defined as: @@ -963,7 +963,7 @@ a functional programming paradigm, for example: In a nutshell, almost every STL method or algorithm is matched by a corresponding functor, which can then be used in the transition table or -state actions. The link:#Reference-begin[reference] lists all eUML +state actions. The xref:reference/euml-operators-and-basic-helpers.adoc[reference] lists all eUML functions and the underlying functor (so that this possibility is not reserved to eUML but also to the functor-based front-end). The file structure of this Phoenix-like library matches the one of Boost.Phoenix.