Merge pull request #738 from ApexAI/iox-#482-add-asciinema-recordings

mossmaurice-apexai · web-flow · commit 8fd54b65efca · 2021-04-15T19:26:30.000+02:00
Iox #482 add asciinema recordings
diff --git a/iceoryx_examples/callbacks/README.md b/iceoryx_examples/callbacks/README.md
@@ -24,7 +24,7 @@ concurrently, even from inside a callback that was triggered by an event!
 
 ## Expected Output
 
-<!-- @todo Add expected output with asciinema recording before v1.0-->
+[![asciicast](https://asciinema.org/a/407365.svg)](https://asciinema.org/a/407365)
 
 ## Code Walkthrough
 
diff --git a/iceoryx_examples/callbacks/ice_callbacks_listener_as_class_member.cpp b/iceoryx_examples/callbacks/ice_callbacks_listener_as_class_member.cpp
@@ -28,7 +28,7 @@
 #include <iostream>
 
 std::atomic_bool keepRunning{true};
-constexpr char APP_NAME[] = "iox-cpp-callbacks-subscriber";
+constexpr char APP_NAME[] = "iox-cpp-callbacks-listener-as-class-member";
 
 iox::posix::Semaphore shutdownSemaphore =
     iox::posix::Semaphore::create(iox::posix::CreateUnnamedSingleProcessSemaphore, 0U).value();
diff --git a/iceoryx_examples/callbacks_in_c/README.md b/iceoryx_examples/callbacks_in_c/README.md
@@ -18,7 +18,7 @@ and at the Glossary of the
 
 ## Expected Output
 
-<!-- @todo Add expected output with asciinema recording before v1.0-->
+[![asciicast](https://asciinema.org/a/407369.svg)](https://asciinema.org/a/407369)
 
 ## Code Walkthrough
 
diff --git a/iceoryx_examples/callbacks_in_c/ice_c_callbacks_with_context_data.c b/iceoryx_examples/callbacks_in_c/ice_c_callbacks_with_context_data.c
@@ -92,7 +92,7 @@ int main()
     signal(SIGINT, sigHandler);
     signal(SIGTERM, sigHandler);
 
-    iox_runtime_init("iox-c-callback-subscriber");
+    iox_runtime_init("iox-c-callbacks-with-context-data");
 
     // the listener starts a background thread and the callbacks of the attached events
     // will be called in this background thread when they are triggered
diff --git a/iceoryx_examples/ice_access_control/README.md b/iceoryx_examples/ice_access_control/README.md
@@ -10,7 +10,7 @@ It provides a custom RouDi, a radar and a display application.
 
 ## Expected output
 
-<!-- Add asciinema link here -->
+[![asciicast](https://asciinema.org/a/407451.svg)](https://asciinema.org/a/407451)
 
 ## Code walkthrough
 
diff --git a/iceoryx_examples/icecrystal/Readme.md b/iceoryx_examples/icecrystal/Readme.md
@@ -2,37 +2,17 @@
 
 ## Introduction
 
-> This Readme.md is slightly outdated and not all functionality of the introspection is available with v1.0
-
 This example teaches you how to make use of the introspection for debugging purposes. With the introspection you can
 look into the machine room of RouDi. It shows live information about the memory usage and all
 registered processes. Additionally, it shows the publisher and subscriber ports that are created inside the shared
 memory.
 
-## Run icecrystal
+## Expected Output
 
-We reuse the binaries from 
+We re-use the binaries from
 [icedelivery](https://github.com/eclipse-iceoryx/iceoryx/tree/master/iceoryx_examples/icedelivery).
-Create four terminals and run one command in each of them.
-
-```sh
-# If installed and available in PATH environment variable
-iox-roudi
-# If build from scratch with script in tools
-$ICEORYX_ROOT/build/iox-roudi
-
-build/iceoryx_examples/icedelivery/iox-cpp-publisher
-
-build/iceoryx_examples/icedelivery/iox-cpp-subscriber
-
-build/iox-introspection-client --all
-```
-
-<!-- @todo Add expected output of RouDi, publisher, subscriber and introspection with asciinema recording before v1.0-->
-
-## Expected Output
 
-![introspection_screenshot](https://user-images.githubusercontent.com/22388003/75041206-672feb80-54bc-11ea-8621-2acf95bf376e.png)
+[![asciicast](https://asciinema.org/a/407442.svg)](https://asciinema.org/a/407442)
 
 ## Feature walkthrough
 
@@ -53,9 +33,9 @@ The process view will show you the processes (incl. PID), which are currently re
 
     --port            Subscribe to port introspection data.
 
-The port view shows both publisher and subscriber ports that are created by RouDi in the shared memory. Their respective service 
-description (service, instance, event) is shown to identify them uniquely. The columns `Process` and `Node` display to which 
-process and node the ports belong. The service discovery protocol allows you to define the `Propagation scope` of the data. This 
+The port view shows both publisher and subscriber ports that are created by RouDi in the shared memory. Their respective service
+description (service, instance, event) is shown to identify them uniquely. The columns `Process` and `Node` display to which
+process and node the ports belong. The service discovery protocol allows you to define the `Propagation scope` of the data. This
 can enable data forwarding to other machines e.g. over network or just consume them internally.
 
     --all             Subscribe to all available introspection data.
diff --git a/iceoryx_examples/icedelivery/README.md b/iceoryx_examples/icedelivery/README.md
@@ -9,7 +9,7 @@ It provides publisher and subscriber applications. They come in two C++ API flav
 
 Create three terminals and start RouDi, a publisher and a subscriber. You can also mix the typed and untyped versions.
 
-[![asciicast](https://asciinema.org/a/382036.svg)](https://asciinema.org/a/382036)
+[![asciicast](https://asciinema.org/a/407359.svg)](https://asciinema.org/a/407359)
 
 ## Code walkthrough
 
diff --git a/iceoryx_examples/icedelivery_in_c/README.md b/iceoryx_examples/icedelivery_in_c/README.md
@@ -11,7 +11,7 @@ so that we explain here only the C API differences and not the underlying mechan
 
 ## Expected Output
 
-<!-- @todo Add expected output with asciinema recording before v1.0-->
+[![asciicast](https://asciinema.org/a/407361.svg)](https://asciinema.org/a/407361)
 
 ## Code walkthrough
 
diff --git a/iceoryx_examples/iceensemble/README.md b/iceoryx_examples/iceensemble/README.md
@@ -35,9 +35,12 @@ Alternatively, you can use the provided [tmux](https://en.wikipedia.org/wiki/Tmu
 ./iceoryx_examples/iceensemble/run_iceensemble.sh
 ```
 
+!!! info
+    As `iox-subscriber-with-options` requests the blocking publisher feature, although having the same `capro::ServiceDescription` `{"Radar", "FrontLeft", "Object"}` it is only connected to `iox-publisher-with-options`
+
 ## Expected Output
 
-<!-- add asciiema link here -->
+[![asciicast](https://asciinema.org/a/407432.svg)](https://asciinema.org/a/407432)
 
 <center>
 [Check out iceensemble on GitHub :fontawesome-brands-github:](https://github.com/eclipse-iceoryx/iceoryx/tree/master/iceoryx_examples/iceensemble){ .md-button }
diff --git a/iceoryx_examples/icehello/README.md b/iceoryx_examples/icehello/README.md
@@ -7,7 +7,7 @@ It provides a publisher and a subscriber application.
 
 ## Expected Output
 
-<!-- Add asciinema link here -->
+[![asciicast](https://asciinema.org/a/407357.svg)](https://asciinema.org/a/407357)
 
 ## Code walkthrough
 
diff --git a/iceoryx_examples/iceoptions/README.md b/iceoryx_examples/iceoptions/README.md
@@ -7,7 +7,7 @@ side. The options can be used for the typed and untyped C++ API flavors as well
 
 ## Expected Output
 
-<!-- Add asciinema link here -->
+[![asciicast](https://asciinema.org/a/407362.svg)](https://asciinema.org/a/407362)
 
 ## Code walkthrough
 
diff --git a/iceoryx_examples/singleprocess/README.md b/iceoryx_examples/singleprocess/README.md
@@ -9,33 +9,7 @@ threads that are interacting without starting RouDi every time separately.
 
 ## Run singleprocess
 
-The example can be started with
-
-```sh
-build/iceoryx_examples/singleprocess/single_process
-```
-
-<!-- @todo Replace this with asciinema recording before v1.0-->
-
-After you have started the example you should see an output like
-
-```bash
-Log level set to: [ Error ]
-Reserving 71546016 bytes in the shared memory [/iceoryx_mgmt]
-[ Reserving shared memory successful ]
-Reserving 149655680 bytes in the shared memory [/users]
-[ Reserving shared memory successful ]
-RouDi is ready for clients
-Sending   -> 0
-Sending   -> 1
-Receiving <- 0
-Receiving <- 1
-Sending   -> 2
-Receiving <- 2
-Sending   -> 3
-...
-Finished
-```
+[![asciicast](https://asciinema.org/a/407439.svg)](https://asciinema.org/a/407439)
 
 The first lines until `RouDi is ready for clients` are coming from the RouDi
 startup in which the shared memory management segment and user data segment are
diff --git a/iceoryx_examples/waitset/README.md b/iceoryx_examples/waitset/README.md
@@ -47,8 +47,7 @@ samples present in the subscriber.
 
 ## Expected Output
 
-<!-- @todo Add expected output with asciinema recording before v1.0-->
-<!-- @todo multiple examples described in here, expected output should be in front of every example -->
+[![asciicast](https://asciinema.org/a/407372.svg)](https://asciinema.org/a/407372)
 
 ## Glossary
 
@@ -121,6 +120,7 @@ are stored inside of the **NotificationInfo** and can be acquired by the user.
 |acquire _NotificationOrigin_|`notification->getOrigin<OriginType>();`|
 
 ## Use Cases
+
 This example consists of 6 use cases.
 
  1. `ice_waitset_basic`: A single subscriber is notified by the WaitSet if data arrives.
@@ -149,9 +149,8 @@ send by `iox-cpp-waitset-publisher`. The publisher does not contain any _WaitSet
 logic and is explained in detail in the 
 [icedelivery example](https://github.com/eclipse-iceoryx/iceoryx/tree/master/iceoryx_examples/icedelivery).
 
-<!-- @todo Add expected output with asciinema recording before v1.0-->
-
 ### Basic
+
 We create one subscriber and attach it to the WaitSet. Afterwards we wait for data in 
 a loop and process it on arrival. To leave the loop and exit the application 
 we have to register a signal handler that calls `waitset.markForDestruction()`
@@ -191,9 +190,9 @@ waitset->attachState(subscriber, iox::popo::SubscriberState::HAS_DATA).or_else([
 });
 ```
 
-We create a loop which we will exit as soon as someone presses CTRL+c and our 
-signal handler sets shutdown to true. If this happens `markForDestruction` turns 
-the `waitset->wait()` into an empty non-blocking method and makes sure that we do 
+We create a loop which we will exit as soon as someone presses CTRL+c and our
+signal handler sets shutdown to true. If this happens `markForDestruction` turns
+the `waitset->wait()` into an empty non-blocking method and makes sure that we do
 not wait until infinity.
 
 ```cpp
@@ -214,15 +213,16 @@ while (!shutdown.load())
   }
 }
 ```
+
 Processing just one sample even if more might have arrived will cause `wait` to unblock again immediately to process the next sample (or shut down if requested). Due to the overhead of the `wait` call it may still be more efficient to process all samples in a loop until there are none left before waiting again, but it is not required. It would be required if we attach via `attachEvent` instead of `attachState`, since we might wake up due to the arrival of a second sample, only process the first and will not receive a wake up until a third sample arrives (which could be much later or never).
 
 ### Gateway
 
 We have a list of subscribers which can be subscribed to any arbitrary topic
 and everytime we received a sample we would like to send the bytestream to a socket,
 write it into a file or print it to the console. But whatever we choose to do
-we perform the same task for all the subscribers. And since we process all incoming 
-data right away we attach the `SubscriberEvent::DATA_RECEIVED` which notifies us 
+we perform the same task for all the subscribers. And since we process all incoming
+data right away we attach the `SubscriberEvent::DATA_RECEIVED` which notifies us
 only once.
 
 Let's start by implementing our callback which prints the subscriber pointer, the
@@ -231,7 +231,7 @@ as long as there are samples in the subscriber since we attached an event that n
 us only once. But it is impossible to miss samples since the notification is reset
 right after `wait` or `timedWait` is returned - this means if a sample arrives after
 those calls we will be notified again.
-Additionally, we would like to count the sum of all processed samples therefor we 
+Additionally, we would like to count the sum of all processed samples therefor we
 add a second argument called `sumOfAllSamples`, the user defined context data.
 
 ```cpp
@@ -249,16 +249,16 @@ void subscriberCallback(iox::popo::UntypedSubscriber* const subscriber, uint64_t
 }
 ```
 
-The _Event_ callback requires a signature of either `void (NotificationOrigin)` or 
-`void(NotificationOrigin, ContextDataType *)` when one would like to provide an additional 
+The _Event_ callback requires a signature of either `void (NotificationOrigin)` or
+`void(NotificationOrigin, ContextDataType *)` when one would like to provide an additional
 data pointer to the callback.
 In our example the _NotificationOrigin_ is a
 `iox::popo::UntypedSubscriber` pointer which we use to acquire the latest sample by calling
-`take()` and the `ContextDataType` is an `uint64_t` used to count the processed 
+`take()` and the `ContextDataType` is an `uint64_t` used to count the processed
 samples. When `take()` was successful we print our message to
 the console inside of the `and_then` lambda.
 
-The `shutdownTrigger` uses a simpler callback which just informs us that we are 
+The `shutdownTrigger` uses a simpler callback which just informs us that we are
 exiting the program. Therefor we do not need an additional `ContextDataType` pointer.
 ```cpp
 void shutdownCallback(iox::popo::UserTrigger*)
@@ -285,8 +285,8 @@ attach the subscribers to our _WaitSet_ with the `SubscriberEvent::DATA_RECEIVED
 Everytime one of the subscribers is receiving a new sample it will trigger the _WaitSet_.
 
 !!! attention 
-    The user has to ensure that the contextData (`sumOfAllSamples`) in `attachEvent` 
-    lives as long as the attachment, with its callback, is attached otherwise 
+    The user has to ensure that the contextData (`sumOfAllSamples`) in `attachEvent`
+    lives as long as the attachment, with its callback, is attached otherwise
     the callback context data pointer is dangling.
 
 ```cpp
@@ -307,7 +307,7 @@ for (auto i = 0; i < NUMBER_OF_SUBSCRIBERS; ++i)
 ```
 
 `attachEvent` is returning a `cxx::expected` which informs us if attaching the event
-succeeded. In the `.or_else([&](auto){/*...*/})` part we perform the error handling 
+succeeded. In the `.or_else([&](auto){/*...*/})` part we perform the error handling
 whenever `attachEvent` failed.
 
 Now our system is prepared and ready to work. We enter the event loop which
@@ -345,7 +345,7 @@ while (true)
 
 In our next use case we would like to divide the subscribers into two groups
 and we do not want to attach a callback to them. Instead we perform the calls on the
-subscribers directly. Additionally, we would like to be notified as long as there 
+subscribers directly. Additionally, we would like to be notified as long as there
 are samples in the subscriber queue therefore we have to attach the `SubscriberState::HAS_DATA`.
 
 We again start by creating a _WaitSet_ with a capacity of 5 (4 subscribers and 1 shutdownTrigger),
@@ -525,7 +525,7 @@ class SomeClass
 ```
 
 !!! attention
-    The user trigger is event based and always reset after the WaitSet 
+    The user trigger is event based and always reset after the WaitSet
     has acquired all triggered objects.
 
 We begin as always, by creating a _WaitSet_ with the default capacity and by
@@ -887,9 +887,9 @@ state was requested.
 
 The next thing we define is a free function, our `eventLoop`, which will handle
 all events of our _WaitSet_. Since we would like to attach the `IS_ACTIVATED` state
-we have to reset the state whenever it occurs otherwise the _WaitSet_ will 
-notify us right away since the state still persists. The second attachment will 
-be an event attachment and the _WaitSet_ informs us just once that the event 
+we have to reset the state whenever it occurs otherwise the _WaitSet_ will
+notify us right away since the state still persists. The second attachment will
+be an event attachment and the _WaitSet_ informs us just once that the event
 has occurred which makes the `reset` call obsolete.
 
 ```cpp
@@ -927,19 +927,19 @@ After that we can attach the `IS_ACTIVATED` state and `PERFORM_ACTION_CALLED` ev
 to the waitset and provide a callback for them.
 
 ```cpp
-    waitset->attachState(*triggerClass, 
-                         MyTriggerClassStates::IS_ACTIVATED, 
-                         ACTIVATE_ID, 
+    waitset->attachState(*triggerClass,
+                         MyTriggerClassStates::IS_ACTIVATED,
+                         ACTIVATE_ID,
                          iox::popo::createNotificationCallback(callOnActivate))
         .or_else([](auto) {
             std::cerr << "failed to attach MyTriggerClassStates::IS_ACTIVATED state " << std::endl;
             std::exit(EXIT_FAILURE);
         });
     waitset
         ->attachEvent(
-            *triggerClass, 
-            MyTriggerClassEvents::PERFORM_ACTION_CALLED, 
-            ACTION_ID, 
+            *triggerClass,
+            MyTriggerClassEvents::PERFORM_ACTION_CALLED,
+            ACTION_ID,
             iox::popo::createNotificationCallback(MyTriggerClass::callOnAction))
         .or_else([](auto) {
             std::cerr << "failed to attach MyTriggerClassEvents::PERFORM_ACTION_CALLED event " << std::endl;
diff --git a/iceoryx_examples/waitset_in_c/README.md b/iceoryx_examples/waitset_in_c/README.md
diff --git a/tools/introspection/source/introspection_app.cpp b/tools/introspection/source/introspection_app.cpp
