(), u32::MAX);
### Defensive Programming
-When using operations that could panic, comment exactly above it why you are sure it won't panic.
+- When using operations that could panic, comment exactly above it why you are sure it won't panic.
-```
+```rust
let pos = announcements
.binary_search(&announcement)
.ok()
@@ -839,7 +842,7 @@ announcements.remove(pos);
Or when using options or results that need to be unwrapped but are known to be `Ok(_)`, `Some()`:
-```
+```rust
let maybe_value: Option<_> = ...
if maybe_value.is_none() {
return "..."
@@ -848,7 +851,8 @@ if maybe_value.is_none() {
let value = maybe_value.expect("value checked to be 'Some'; qed");
```
-> Q.E.D. or QED is an initialism of the Latin phrase quod erat demonstrandum, meaning "which was to be demonstrated".
+- Q.E.D. or QED is an initialism of the Latin phrase "quod erat demonstrandum", meaning "**which was
+ to be demonstrated**".
---v
@@ -877,9 +881,45 @@ pub fn try_insert(&mut self, index: usize, element: T) -> Result<(), ()> {
### Defensive Programming
-The overall ethos of defensive programming is along the lines of:
+- Speaking of documentation, [here's a very good guideline](https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html)!
+
+````
+/// Multiplies the given input by two.
+///
+/// Some further information about what this does, and where it could be used.
+///
+/// ```
+/// fn main() {
+/// let x = multiply_by_2(10);
+/// assert_eq!(10, 20);
+/// }
+/// ```
+///
+/// ## Panics
+///
+/// Panics under such and such condition.
+fn multiply_by_2(x: u32) -> u32 { .. }
+````
+
+---v
+
+### Defensive Programming
```
+/// This function works with module x and multiples the given input by two. If
+/// we optimize the other variant of it, we would be able to achieve more
+/// efficiency but I have to think about it. Probably can panic if the input
+/// overflows u32.
+fn multiply_by_2(x: u32) -> u32 { .. }
+```
+
+---v
+
+### Defensive Programming
+
+- The overall ethos of defensive programming is along the lines of:
+
+```rust
// we have good reasons to believe this is `Some`.
let y: Option<_> = ...
@@ -893,13 +933,13 @@ let x = y.unwrap_or(reasonable_default);
let x = y.ok_or(Error::DefensiveError)?;
```
+- But, for example, you are absolutely sure that `Error::DefensiveError` will never happen, can we enforce it better?
+
---v
### Defensive Programming
-Slightly better:
-
-[Defensive traits](https://paritytech.github.io/substrate/master/frame_support/traits/trait.Defensive.html):
+- Yes: [Defensive traits](https://paritytech.github.io/substrate/master/frame_support/traits/trait.Defensive.html):
```
// either return a reasonable default..
diff --git a/syllabus/5-FRAME/4-Exotic_Stuff/Migrations_and_try_runtime_slides.md b/syllabus/5-FRAME/4-Exotic_Stuff/Migrations_and_try_runtime_slides.md
index efdef7fd6..302b7ad88 100644
--- a/syllabus/5-FRAME/4-Exotic_Stuff/Migrations_and_try_runtime_slides.md
+++ b/syllabus/5-FRAME/4-Exotic_Stuff/Migrations_and_try_runtime_slides.md
@@ -35,11 +35,10 @@ https://www.crowdcast.io/e/substrate-seminar/41
### When is a Migration Required?
-In a typical runtime upgrade, you typically only replace `:code:`. This is _Runtime Upgrade_.
+- In a typical runtime upgrade, you typically only replace `:code:`. This is _**Runtime Upgrade**_.
+- If you change the _storage layout_, then this is also a _**Runtime Migration**_.
-If you change the _storage layout_, then this is also a _Runtime Migration_.
-
-> What is a change here? Anything that changes **encoding**!
+> Anything that changes **encoding** is a migration!
---v
@@ -51,10 +50,10 @@ pub type FooValue = StorageValue<_, Foo>;
```
```rust
- // old
- pub struct Foo(u32)
- // new
- pub struct Foo(u64)
+// old
+pub struct Foo(u32)
+// new
+pub struct Foo(u64)
```
A clear migration.
@@ -71,15 +70,15 @@ pub type FooValue = StorageValue<_, Foo>;
```
```rust
- // old
- pub struct Foo(u32)
- // new
- pub struct Foo(i32)
- // or
- pub struct Foo(u16, u16)
+// old
+pub struct Foo(u32)
+// new
+pub struct Foo(i32)
+// or
+pub struct Foo(u16, u16)
```
-Not so clear: The data still fits, but the interpretations is almost certainly different!
+The data still _fits_, but the _interpretations_ is almost certainly different!
@@ -93,14 +92,12 @@ pub type FooValue = StorageValue<_, Foo>;
```
```rust
- // old
- pub struct Foo { a: u32, b: u32 }
- // new
- pub struct Foo { a: u32, b: u32, c: u32 }
+// old
+pub struct Foo { a: u32, b: u32 }
+// new
+pub struct Foo { a: u32, b: u32, c: u32 }
```
-Extending a struct is an interesting edge case...
-
This is still a migration, because `Foo`'s decoding changed.
@@ -115,10 +112,10 @@ pub type FooValue = StorageValue<_, Foo>;
```
```rust
- // old
- pub struct Foo { a: u32, b: u32 }
- // new
- pub struct Foo { a: u32, b: u32, c: PhantomData<_> }
+// old
+pub struct Foo { a: u32, b: u32 }
+// new
+pub struct Foo { a: u32, b: u32, c: PhantomData<_> }
```
If for whatever reason `c` has a type that its encoding is like `()`, then this would work.
@@ -143,6 +140,8 @@ pub type FooValue = StorageValue<_, Foo>;
Extending an enum is even more interesting, because if you add the variant to the end, no migration is needed.
+
+
Assuming that no value is initialized with `C`, this is _not_ a migration.
@@ -157,10 +156,10 @@ pub type FooValue = StorageValue<_, Foo>;
```
```rust
- // old
- pub enum Foo { A(u32), B(u32) }
- // new
- pub enum Foo { A(u32), C(u128), B(u32) }
+// old
+pub enum Foo { A(u32), B(u32) }
+// new
+pub enum Foo { A(u32), C(u128), B(u32) }
```
You probably _never_ want to do this, but it is a migration.
@@ -176,8 +175,6 @@ Enums are encoded as the variant enum, followed by the inner data:
- The order matters!
- Enums that implement `Encode` cannot have more than 255 variants.
-> Remember: It is all about how a type `encode` and `decodes`.
-
---v
### When is a Migration Required?
@@ -193,8 +190,13 @@ pub type FooValue = StorageValue<_, u32>;
pub type BarValue = StorageValue<_, u32>;
```
-So far everything is changing the _value_ format.
-The _key_ changing is also a migration!
+- So far everything is changing the _value_ format.
+
+
+
+- The _key_ changing is also a migration!
+
+
@@ -204,14 +206,14 @@ The _key_ changing is also a migration!
```rust
#[pallet::storage]
-pub type FooValue = StorageValue<_, Foo>;
+pub type FooValue = StorageValue<_, u32>;
```
```rust
// new
#[pallet::storage_prefix = "FooValue"]
#[pallet::storage]
-pub type I_can_NOW_BE_renamEd = StorageValue<_, u32>;
+pub type I_can_NOW_BE_renamEd_hahAA = StorageValue<_, u32>;
```
Handy macro if you must rename a storage type.
@@ -223,25 +225,21 @@ This does _not_ require a migration.
## Writing Runtime Migrations
-Notes:
-
-Now that we know how to detect if a storage change is a **migration**, let's see how we write one.
+- Now that we know how to detect if a storage change is a **migration**, let's see how we write one.
---v
### Writing Runtime Migrations
-Once you upgrade a runtime, the code is expecting the data to be in a new format.
-
-Any `on_initialize` or transaction might fail decoding data, and potentially `panic!`
+- Once you upgrade a runtime, the code is expecting the data to be in a new format.
+- Any `on_initialize` or transaction might fail decoding data, and potentially `panic!`
---v
### Writing Runtime Migrations
-We need a **_hook_** that is executed **ONCE** as a part of the new runtime...
-
-But before **ANY** other code (on_initialize, any transaction) with the new runtime is migrated.
+- We need a **_hook_** that is executed **ONCE** as a part of the new runtime...
+- But before **ANY** other code (on_initialize, any transaction) with the new runtime is migrated.
> This is `OnRuntimeUpgrade`.
@@ -251,11 +249,8 @@ But before **ANY** other code (on_initialize, any transaction) with the new runt
### Writing Runtime Migrations
-`OnRuntimeUpgrade` is called before any block being `initialize`ed, every time the spec version changes.
-
-> Q: why don't we need to keep the old storage definitions in the code (similar to host functions)?
->
-> A: Every block is executed with the wasm code of **that block**.
+- Optional activity: Go into `executive` and `system`, and find out how `OnRuntimeUpgrade` is called
+ only when the code changes!
---
-
-
+
+
+
+
+
+
+NOTE:
+
+I was asked this yesterday as well. My latest answer is: if you don't need any of the customizations
+that a blockchain client/runtime gives to you, and the performance of a shared platform is okay for
+you, then go with a smart contract. If you need more, you need a "runtime" (some kind of chian,
+parachain or solo)
+
+An example of customization is that a runtime has access to `on_initialize` etc.
+
+Also, a contract usually depends on a token for gas, while a runtime can be in principle token-less
+fee-less.
+
+---v
+
+### Substrate and Smart Contracts
+
+
+
+---v
+
+### Substrate and Smart Contracts
+
+- So a SMOLDOT instance, syncing a substrate based chain which has pallet-contracts is ...๐ค
+
+---v
+
+### Substrate and Smart Contracts
+
+
+
+
+
+
+---v
+
+### Example #2: Block Import
+
```rust [1-100|1-2|4-6|8-9|1-100]
// fetch the block from the outer world. It is opaque.
let opaque_block: Vec