From a66540efa014b3716d252612bfc7f8f17ed765c4 Mon Sep 17 00:00:00 2001
From: datdenkikniet <jcdra1@gmail.com>
Date: Sun, 23 Apr 2023 15:33:56 +0200
Subject: Disable the playground on all of these

---
 book/en/src/internals/tasks.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

(limited to 'book/en/src/internals/tasks.md')

diff --git a/book/en/src/internals/tasks.md b/book/en/src/internals/tasks.md
index db7afad..a58db8f 100644
--- a/book/en/src/internals/tasks.md
+++ b/book/en/src/internals/tasks.md
@@ -26,7 +26,7 @@ is treated as a resource contended by the tasks that can `spawn` other tasks.
 Let's first take a look the code generated by the framework to dispatch tasks.
 Consider this example:
 
-``` rust
+``` rust,noplayground
 #[rtic::app(device = ..)]
 mod app {
     // ..
@@ -57,7 +57,7 @@ mod app {
 The framework produces the following task dispatcher which consists of an
 interrupt handler and a ready queue:
 
-``` rust
+``` rust,noplayground
 fn bar(c: bar::Context) {
     // .. user code ..
 }
@@ -121,7 +121,7 @@ There's one `Spawn` struct per task.
 The `Spawn` code generated by the framework for the previous example looks like
 this:
 
-``` rust
+``` rust,noplayground
 mod foo {
     // ..
 
@@ -206,7 +206,7 @@ task capacities.
 We have omitted how message passing actually works so let's revisit the `spawn`
 implementation but this time for task `baz` which receives a `u64` message.
 
-``` rust
+``` rust,noplayground
 fn baz(c: baz::Context, input: u64) {
     // .. user code ..
 }
@@ -268,7 +268,7 @@ mod app {
 
 And now let's look at the real implementation of the task dispatcher:
 
-``` rust
+``` rust,noplayground
 mod app {
     // ..
 
@@ -355,7 +355,7 @@ endpoint is owned by a task dispatcher.
 
 Consider the following example:
 
-``` rust
+``` rust,noplayground
 #[rtic::app(device = ..)]
 mod app {
     #[idle(spawn = [foo, bar])]
-- 
cgit v1.2.3