more consistent update notes

diff --git a/ralf/_posts/2017-05-23-internship-starting.md b/ralf/_posts/2017-05-23-internship-starting.md
index c8a7252ec018c3c7bd6d1ff27bbc4336b2a1ff3e..c8283166c6db29e0b25cc569df66d0a9a92f5323 100644 (file)
--- a/ralf/_posts/2017-05-23-internship-starting.md
+++ b/ralf/_posts/2017-05-23-internship-starting.md
@@ -37,7 +37,7 @@ That's it for now.
 I don't have the answers to these questions, but hopefully my work will help getting closer to an answer.
 I will keep you posted on my progress (or lack thereof), probably on a weekly or bi-weekly basis.
 
-**Update.** I realized I should probably expand on the parenthetical remark about specifying MIR rather than specifying Rust.
+**Update:** I realized I should probably expand on the parenthetical remark about specifying MIR rather than specifying Rust.
 What we are planning to do here is to specify Rust by specifying (a) how Rust code translates to MIR, and (b) specifying MIR.
 This has two advantages.
 First of all, part (a) actually is already done and implemented in the Rust compiler!
@@ -51,3 +51,4 @@ Now, this is *not* to say that every Rust compiler has to use MIR in its compila
 It just means that the way I imagine a specification of Rust to look like is as consisting of two parts: The Rust-to-MIR translation, and a specification for MIR.
 If another compiler uses a different implementation strategy, it can still be compliant with the specification; it just has to ensure that Rust programs behave as specified.
 This is a common approach that can also be found, e.g., in the specification of CPU instruction sets: The specification describes the behavior of a complex instruction as a series of commands in some lower-level language.  The CPU does not actually use that language as part of its implementation, but *it behaves as if it would*, and that's the only part that matters.
+**/Update**

diff --git a/ralf/_posts/2017-07-08-rustbelt.md b/ralf/_posts/2017-07-08-rustbelt.md
index 0773db6407d7f5ae2fb82502d2e7bfef8c1a38cc..1dfee5b99eec2a9c4bc8e8ddde90ceeb3ff9013d 100644 (file)
--- a/ralf/_posts/2017-07-08-rustbelt.md
+++ b/ralf/_posts/2017-07-08-rustbelt.md
@@ -38,6 +38,6 @@ All these results were only possible because of my great collaborators, [Jacques
 I also benefited a lot from countless discussions with the Rust community at large, and with Aaron and Niko in particular.
 You guys rock!
 
-**Update**: I have changed the link to point to the [final version of the paper](https://plv.mpi-sws.org/rustbelt/popl18/).
+**Update:** I have changed the link to point to the [final version of the paper](https://plv.mpi-sws.org/rustbelt/popl18/). **/Update**
 
-**Update**: The conference talk is now available [on YouTube](https://www.youtube.com/watch?v=Cy9NUVaiYUg).
+**Update:** The conference talk is now available [on YouTube](https://www.youtube.com/watch?v=Cy9NUVaiYUg). **/Update**

diff --git a/ralf/_posts/2017-08-11-types-as-contracts-evaluation.md b/ralf/_posts/2017-08-11-types-as-contracts-evaluation.md
index edb2a45be04673d60662cebfa78821aa69268e5b..e3ccfd155a986c28208386ae279b0c6b90ca9716 100644 (file)
--- a/ralf/_posts/2017-08-11-types-as-contracts-evaluation.md
+++ b/ralf/_posts/2017-08-11-types-as-contracts-evaluation.md
@@ -268,4 +268,4 @@ Still, I certainly intend to stay involved. This problem is way too interesting
 As always, please [comment](https://internals.rust-lang.org/t/https-www-ralfj-de-blog-2017-08-11-types-as-contracts-evaluation-html/5753) with your thoughts on the topic.
 I am particularly curious about what kind of test cases you are throwing at miri, and how it is doing!
 
-**Update**: I added a proposal for how to fix the `Arc` problem.
+**Update:** I added a proposal for how to fix the `Arc` problem. **/Update**