From 4c8f5d2fa05b35131a2bddf98305a01393ea3e4d Mon Sep 17 00:00:00 2001 From: Steve Klabnik Date: Thu, 7 Jul 2016 16:00:22 -0400 Subject: [PATCH] Update site to kramdown https://help.github.com/articles/updating-your-markdown-processor-to-kramdown/ Major changes include: * using a center CSS class instead of
tags * kramdown already does curly quotes/tables, no need for the extension * including jekyll in the Gemfile so we get a specific version --- Gemfile | 1 + Gemfile.lock | 70 +++++++++---------- _config.yml | 3 - _includes/head.html | 1 + _posts/2016-04-19-MIR.md | 40 +++-------- .../2016-06-30-State-of-Rust-Survey-2016.md | 56 ++++----------- css/center-img.css | 5 ++ 7 files changed, 64 insertions(+), 112 deletions(-) create mode 100644 css/center-img.css diff --git a/Gemfile b/Gemfile index 825baa500..1466a27a2 100644 --- a/Gemfile +++ b/Gemfile @@ -1,3 +1,4 @@ source "https://rubygems.org" gem 'github-pages' +gem 'jekyll', '~>3.1.6' diff --git a/Gemfile.lock b/Gemfile.lock index b2258ed9e..5ca24638f 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -1,7 +1,6 @@ GEM remote: https://rubygems.org/ specs: - RedCloth (4.2.9) activesupport (4.2.6) i18n (~> 0.7) json (~> 1.7, >= 1.7.7) @@ -14,35 +13,32 @@ GEM execjs coffee-script-source (1.10.0) colorator (0.1) - ethon (0.8.1) + ethon (0.9.0) ffi (>= 1.3.0) - execjs (2.6.0) + execjs (2.7.0) faraday (0.9.2) multipart-post (>= 1.2, < 3) - ffi (1.9.10) + ffi (1.9.13) gemoji (2.1.0) - github-pages (69) - RedCloth (= 4.2.9) + github-pages (86) github-pages-health-check (= 1.1.0) - jekyll (= 3.0.3) + jekyll (= 3.1.6) jekyll-coffeescript (= 1.0.1) - jekyll-feed (= 0.4.0) + jekyll-feed (= 0.5.1) jekyll-gist (= 1.4.0) - jekyll-github-metadata (= 1.11.0) - jekyll-mentions (= 1.1.2) + jekyll-github-metadata (= 2.0.2) + jekyll-mentions (= 1.1.3) jekyll-paginate (= 1.1.0) jekyll-redirect-from (= 0.10.0) jekyll-sass-converter (= 1.3.0) - jekyll-seo-tag (= 1.3.3) + jekyll-seo-tag (= 2.0.0) jekyll-sitemap (= 0.10.0) - jekyll-textile-converter (= 0.1.0) jemoji (= 0.6.2) - kramdown (= 1.10.0) + kramdown (= 1.11.1) liquid (= 3.0.6) + listen (= 3.0.6) mercenary (~> 0.3) - rdiscount (= 2.1.8) - redcarpet (= 3.3.3) - rouge (= 1.10.1) + rouge (= 1.11.1) terminal-table (~> 1.4) github-pages-health-check (1.1.0) addressable (~> 2.3) @@ -50,11 +46,11 @@ GEM octokit (~> 4.0) public_suffix (~> 1.4) typhoeus (~> 0.7) - html-pipeline (2.4.0) + html-pipeline (2.4.1) activesupport (>= 2, < 5) nokogiri (>= 1.4) i18n (0.7.0) - jekyll (3.0.3) + jekyll (3.1.6) colorator (~> 0.1) jekyll-sass-converter (~> 1.0) jekyll-watch (~> 1.1) @@ -65,12 +61,13 @@ GEM safe_yaml (~> 1.0) jekyll-coffeescript (1.0.1) coffee-script (~> 2.2) - jekyll-feed (0.4.0) + jekyll-feed (0.5.1) jekyll-gist (1.4.0) octokit (~> 4.2) - jekyll-github-metadata (1.11.0) + jekyll-github-metadata (2.0.2) + jekyll (~> 3.1) octokit (~> 4.0) - jekyll-mentions (1.1.2) + jekyll-mentions (1.1.3) html-pipeline (~> 2.3) jekyll (~> 3.0) jekyll-paginate (1.1.0) @@ -78,45 +75,43 @@ GEM jekyll (>= 2.0) jekyll-sass-converter (1.3.0) sass (~> 3.2) - jekyll-seo-tag (1.3.3) - jekyll (~> 3.0) + jekyll-seo-tag (2.0.0) + jekyll (~> 3.1) jekyll-sitemap (0.10.0) - jekyll-textile-converter (0.1.0) - RedCloth (~> 4.0) - jekyll-watch (1.3.1) - listen (~> 3.0) + jekyll-watch (1.4.0) + listen (~> 3.0, < 3.1) jemoji (0.6.2) gemoji (~> 2.0) html-pipeline (~> 2.2) jekyll (>= 3.0) json (1.8.3) - kramdown (1.10.0) + kramdown (1.11.1) liquid (3.0.6) listen (3.0.6) rb-fsevent (>= 0.9.3) rb-inotify (>= 0.9.7) mercenary (0.3.6) - mini_portile2 (2.0.0) - minitest (5.8.4) + mini_portile2 (2.1.0) + minitest (5.9.0) multipart-post (2.0.0) net-dns (0.8.0) - nokogiri (1.6.7.2) - mini_portile2 (~> 2.0.0.rc2) + nokogiri (1.6.8) + mini_portile2 (~> 2.1.0) + pkg-config (~> 1.1.7) octokit (4.3.0) sawyer (~> 0.7.0, >= 0.5.3) + pkg-config (1.1.7) public_suffix (1.5.3) rb-fsevent (0.9.7) rb-inotify (0.9.7) ffi (>= 0.5.0) - rdiscount (2.1.8) - redcarpet (3.3.3) - rouge (1.10.1) + rouge (1.11.1) safe_yaml (1.0.4) sass (3.4.22) sawyer (0.7.0) addressable (>= 2.3.5, < 2.5) faraday (~> 0.8, < 0.10) - terminal-table (1.5.2) + terminal-table (1.6.0) thread_safe (0.3.5) typhoeus (0.8.0) ethon (>= 0.8.0) @@ -128,6 +123,7 @@ PLATFORMS DEPENDENCIES github-pages + jekyll (~> 3.1.6) BUNDLED WITH - 1.11.2 + 1.12.5 diff --git a/_config.yml b/_config.yml index 151d76c9b..fecf859c0 100644 --- a/_config.yml +++ b/_config.yml @@ -10,8 +10,5 @@ github_username: rust-lang # Build settings highlighter: rouge -markdown: redcarpet -redcarpet: - extensions: ["with_toc_data", "smart"] root: http://blog.rust-lang.org diff --git a/_includes/head.html b/_includes/head.html index 8dba01e36..777c3999a 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -7,6 +7,7 @@ + diff --git a/_posts/2016-04-19-MIR.md b/_posts/2016-04-19-MIR.md index a176479fd..bdfe0360b 100644 --- a/_posts/2016-04-19-MIR.md +++ b/_posts/2016-04-19-MIR.md @@ -10,9 +10,7 @@ compiler internals. Over the past year or so, we have been steadily working on a plan to change our internal compiler pipeline, as shown here: -
-![Compiler Flowchart][flow] -
+![Compiler Flowchart][flow]{:class="center"} That is, we are introducing a new intermediate representation (IR) of your program that we call **MIR**: MIR stands for *mid-level* IR, because @@ -262,9 +260,7 @@ of that cycle. Here is the running example from the previous section, expressed as a control-flow graph: -
-![Control-flow-graph][cfg] -
+![Control-flow-graph][cfg]{:class="center"} Building a control-flow graph is typically a first step for any kind of flow-sensitive analysis. It's also a natural match for LLVM IR, @@ -345,9 +341,7 @@ break: Of course, the actual MIR is based on a control-flow-graph, so it would look something like this: -
-![Loop-break control-flow graph][loop-break] -
+![Loop-break control-flow graph][loop-break]{:class="center"} ### Explicit drops and panics @@ -394,18 +388,14 @@ control-flow-graph to show explicitly where the `iterator` value gets freed. Take a look at the new graph, and in particular what happens when a `None` variant is found: -
-![Drop control-flow graph][drop] -
+![Drop control-flow graph][drop]{:class="center"} Here we see that, when the loop exits normally, we will drop the iterator once it has finished. But what about if a panic occurs? Any of the function calls we see here could panic, after all. To account for that, we introduce panic edges into the graph: -
-![Panic control-flow graph][drop-unwind] -
+![Panic control-flow graph][drop-unwind]{:class="center"} Here we have introduced `panic` edges onto each of the function calls. By looking at these edges, you can see that if the call to @@ -522,9 +512,7 @@ like the current overwriting semantics. So this means that the MIR for `send_if` might look like this (for simplicity, I'll ignore unwinding edges). -
-![Non-zeroing drop example][nzd] -
+![Non-zeroing drop example][nzd]{:class="center"} We can then transform this graph by identifying each place where `data` is moved or dropped and checking whether any of those places @@ -532,9 +520,7 @@ can reach one another. In this case, the `send_to_other_thread(data)` block can reach `drop(data)`. This indicates that we will need to introduce a flag, which can be done rather mechanically: -
-![Non-zeroing drop with flags][nzd-flags] -
+![Non-zeroing drop with flags][nzd-flags]{:class="center"} Finally, we can apply standard compiler techniques to optimize this flag (but in this case, the flag is needed, and so the final result @@ -558,26 +544,20 @@ fn send_if2(data: Vec) { This would generate MIR like: -
-![Control-flow graph for send_if2][send_if2] -
+![Control-flow graph for send_if2][send_if2]{:class="center"} As before, we still generate the drops of `data` in all cases, at least to start. Since there are still moves that can later reach a drop, we could now introduce a stack flag variable, just as before: -
-![send_if2 with flags][send_if2-flags] -
+![send_if2 with flags][send_if2-flags]{:class="center"} But in this case, if we apply constant propagation, we can see that at each point where we test `data_is_owned`, we know statically whether it is true or false, which would allow us to remove the stack flag and optimize the graph above, yielding this result: -
-![Optimized send_if2][send_if2-opt] -
+![Optimized send_if2][send_if2-opt]{:class="center"} ### Conclusion diff --git a/_posts/2016-06-30-State-of-Rust-Survey-2016.md b/_posts/2016-06-30-State-of-Rust-Survey-2016.md index 9a08d6674..0fa856ad3 100644 --- a/_posts/2016-06-30-State-of-Rust-Survey-2016.md +++ b/_posts/2016-06-30-State-of-Rust-Survey-2016.md @@ -14,17 +14,13 @@ We plan to run a similar survey each year to track how we're progressing and spo We wanted to make sure the survey was open to both users of Rust and to people who didn't use Rust. Rust users give us a sense of how the current language and tools are working and where we need to improve. Rust non-users shed light on missing use-cases and obstacles for Rust’s adoption. -
-![Do you use Rust][do-you-use-rust] -
+![Do you use Rust][do-you-use-rust]{:class="center"} We're happy to report that more than a third of the responses were from people not using Rust. These respondents gave a lot of great feedback on adoption roadblocks, which we'll talk about later in this blog post. ## Growing numbers trying Rust -
-![Time using Rust][time-using-rust] -
+![Time using Rust][time-using-rust]{:class="center"} Almost 2,000 people responded saying they were Rust users. Of these, almost 24% were new users. This is encouraging to see. The community is growing, with a healthy portion of newcomers playing with Rust now that could become long-term users. @@ -34,29 +30,21 @@ Equally encouraging is seeing that once someone has become a Rust user, they ten We asked a number of questions trying to get a clear picture of what it's like to use Rust today. The first questions focused on the Rust compiler. -
-![Versions of Rust you use][versions-of-rust] -
+![Versions of Rust you use][versions-of-rust]{:class="center"} In the above chart, you see the top five rustc version combinations for users writing Rust. At the time of the survey, version 1.8 was the latest stable release. This factors strongly in the results as the most popular version of Rust to use. Perhaps surprisingly is how much the nightly also plays a key role in for many developers, with over 400 using it as their only Rust compiler version. Stabilizing features and APIs, and thereby encouraging transition to the stable channel, continues to be a priority for the team. -
-![Has an upgrade broken code][after_1_0_broke_code] -
+![Has an upgrade broken code][after_1_0_broke_code]{:class="center"} In the pre-1.0 days, Rust releases would regularly break user's code. In reaching 1.0, we began releasing versions that maintained backwards compatibility with 1.0. For stable Rust, 83.6% of users did not experience any breakage in their project as they upgraded to the next stable version. Previous research based on automated testing against the ecosystem put this number [closer to 96%](https://internals.rust-lang.org/t/rust-regressions-2015-year-end-report/2993), which is more in line with expectations. Why the discrepancy? Looking at the data more closely, it seems people used this question as a catch-all for any kind of breakage, including packages in cargo, compiler plugins needing updates, and the changes to libc. We'll be sure to word this question more clearly in the future. But we also plan to launch a forum discussion digging further into the details, to make sure that there’s not something missing from the test automation that runs against crates.io. -
-![Fixing broken code][easy_to_fix] -
+![Fixing broken code][easy_to_fix]{:class="center"} Luckily, regardless of what bucket the breakage fell into, they were largely easy to solve as people upgraded. -
-![Do you like Cargo][like_cargo] -
+![Do you like Cargo][like_cargo]{:class="center"} Another big piece of the Rust development experience is using the Cargo tool. Here we saw overwhelming support for Cargo, with 94.1% of people saying they would rate it a 4 or 5. This helps to emphasize that Cargo continues to be a core part of what it means to write Rust (and that people enjoy using it!) @@ -64,35 +52,25 @@ Another big piece of the Rust development experience is using the Cargo tool. H An important part of a programming language's success is that it's used for "real" work. We asked a few questions to understand how Rust was doing in the workplace. Were people using it in their day jobs? How much was it being used? -
-![Using Rust at work][rust_at_work] -
+![Using Rust at work][rust_at_work]{:class="center"} We were pleasantly surprised to see that already, in Rust's first year, 16.1% of Rust users are using Rust at work part-time and 3.7% are using at work full-time. Combined, **nearly 1/5th of Rust users are using Rust commercially**. We're seeing this reflected in the growing number of [companies using Rust](https://www.rust-lang.org/friends.html). We also asked about the size of the codebases that Rust developers were building. -
-![Size of part-time codebases][part_time] -
+![Size of part-time codebases][part_time]{:class="center"} -
-![Size of full-time codebases][full_time] -
+![Size of full-time codebases][full_time]{:class="center"} We see strong numbers in project size as developers put more time into Rust at work. Over half of the Rust users using Rust full-time at work have codebases that are tens or hundreds of thousands of lines of code. Equally encouraging is the growth we expect to see in Rust in the workplace, as we see in the next chart. -
-![Using Rust at work in future][rust_at_work_future] -
+![Using Rust at work in future][rust_at_work_future]{:class="center"} Of those not currently using Rust at work, more than 40% plan on being able to use Rust at work. This will help carry Rust to more places and in more areas. Speaking of carrying to more areas, we saw a wide variety of job domains represented in the survey: -
-![Demographics of work areas][demo_areas] -
+![Demographics of work areas][demo_areas]{:class="center"} It's encouraging to see people from so many different backgrounds interested in Rust. It underscores Rust’s potential across a broad spectrum of programming tasks and the need for libraries to support these areas. @@ -150,23 +128,17 @@ We've also been investing in other tooling muscles, including a [new installer w ## Survey Demographics -
-![Popular meetup locations][meetup_locations] -
+![Popular meetup locations][meetup_locations]{:class="center"} Today, Rust has a worldwide audience. Rather than being lumped in one place, we see Rust users in Europe, Japan, Australia, with new meetups popping up everyday. We also asked where people who responded lived, and over 1000 of the 3000 survey responses mentioned living in Europe (with USA following it up at 835). -
-![Demographics on programming language background][what_languages] -
+![Demographics on programming language background][what_languages]{:class="center"} The parents of most modern languages, C and C++, show strongly in terms of the programming languages that people are most comfortable with. Close by are Java and JavaScript. Perhaps one surprising point here is the large number of Python users attracted to Rust. For those who already have existing projects in other languages but want to use Rust, it's worth mentioning here the on-going efforts to aide in using Rust with other languages, including work to [integrate with Ruby](https://github.com/rustbridge/helix) and [integrate with JavaScript/Node.js](https://github.com/rustbridge/neon). -
-![Members of underrepresented groups][underrepresented] -
+![Members of underrepresented groups][underrepresented]{:class="center"} Rust strives to be a [warm, welcoming and inclusive community](https://www.rust-lang.org/conduct.html). The survey shows that, despite that spirit, we have a ways to go in terms of diversity. We have nascent efforts, like [RustBridge](https://github.com/rust-community/rustbridge), to more proactively reach out to underrepresented groups and make Rust more accessible, but there is a lot more work to be done. We'll be watching the results of this part of the survey closely and continue to invest in outreach, mentoring, and leadership to foster inclusivity. diff --git a/css/center-img.css b/css/center-img.css new file mode 100644 index 000000000..8715bfa3b --- /dev/null +++ b/css/center-img.css @@ -0,0 +1,5 @@ +.center { + display: block; + margin-left: auto; + margin-right: auto; +}