From ec7f78e034b6e8d3243dddf880f19eab281c7c3a Mon Sep 17 00:00:00 2001 From: Kevin Yap Date: Tue, 24 Dec 2024 02:56:43 -0500 Subject: [PATCH] Fix syntax declaration in code blocks --- content/1201-the-power-of-applescript.md | 3 +-- content/1302-hosting-with-github-pages.md | 3 +-- content/1303-styling-code-blocks-using-pelican.md | 3 +-- content/1401-on-programming-and-turtles.md | 12 ++++-------- .../1402-deploying-pelican-sites-using-travis-ci.md | 9 +++------ content/1501-on-git-and-github-flow.md | 5 +---- content/1701-breaking-the-engima-code-with-rust.md | 3 +-- pneumatic | 2 +- 8 files changed, 13 insertions(+), 27 deletions(-) diff --git a/content/1201-the-power-of-applescript.md b/content/1201-the-power-of-applescript.md index 792ab8cd..3dd7060a 100644 --- a/content/1201-the-power-of-applescript.md +++ b/content/1201-the-power-of-applescript.md @@ -15,8 +15,7 @@ All in all, the script was certainly not pretty, but it did the job. I didn't no If you want to use the script to rename to your own tracks (or just to examine my shoddily thrown together code), here is the source code; to use the script, copy it into AppleScript Editor, select the tracks in iTunes, and run it. -``` -#!applescript +```applescript tell application "iTunes" set sel to selection if sel is not {} then diff --git a/content/1302-hosting-with-github-pages.md b/content/1302-hosting-with-github-pages.md index 9fea0282..24ec40ca 100644 --- a/content/1302-hosting-with-github-pages.md +++ b/content/1302-hosting-with-github-pages.md @@ -15,8 +15,7 @@ While I use [GitHub for Mac](http://mac.github.com) to manage the repository for To achieve this, the script runs the following code after the `pelican` command generates the static site files. -``` -#!bash +```bash cd $sourceDirectory commitHash=$(git rev-parse HEAD) cd $outputDirectory diff --git a/content/1303-styling-code-blocks-using-pelican.md b/content/1303-styling-code-blocks-using-pelican.md index 5679623d..7c595ea1 100644 --- a/content/1303-styling-code-blocks-using-pelican.md +++ b/content/1303-styling-code-blocks-using-pelican.md @@ -30,8 +30,7 @@ Following this, the line numbering is styled by modifying the `linenos` class. T The horizontal margins of the `codehilite` class, which controls the code itself, are increased to add spacing between the code snippets and the line numbers. -``` -#!css +```css .linenos { border-right: 1px solid #d9d9d9; background: #eee; diff --git a/content/1401-on-programming-and-turtles.md b/content/1401-on-programming-and-turtles.md index 39071361..55fd4422 100644 --- a/content/1401-on-programming-and-turtles.md +++ b/content/1401-on-programming-and-turtles.md @@ -19,8 +19,7 @@ The terminology used in ComputerCraft is an obvious allusion to the programming The first major Turtle program that I wrote was a branch mining script. My goal was to write a program that a swarm of Turtles could execute simultaneously to excavate an area for ores. I tend to be meticulous about following patterns when I mine, and when branch mining, this entails digging tunnels with torches every eight blocks. Here is a very basic Turtle script with this functionality. -``` -#!lua +```lua function miningIteration() turtle.dig() -- digs the block in front turtle.forward() -- moves forward @@ -43,8 +42,7 @@ The function `miningIteration()` instructs the Turtle to dig the block in front There is a simple enough fix. The [Turtle API][16] contains functions that allow a Turtle to detect if there is a block in front of, above, or below itself. An improvement to the Turtle would be to detect if there is a block in front of the Turtle and if so, continue digging in front until it there is no block in front. To deal with overhead gravel, the same approach can be taken but by detecting blocks above the Turtle rather than in front of it. Here is the function rewritten to use these detection functions instead of movement functions. -``` -#!lua +```lua function miningIteration() while turtle.detect() do turtle.dig() end turtle.forward() @@ -56,8 +54,7 @@ However, this function is still flawed, though the cause of the problem may not If a Turtle were to execute the current version of `miningIteration()`, it would quickly become apparent that the Turtle still has problems with gravel. If it encountered a column of gravel above itself, it would move forward during the time that the gravel block above itself is was still falling, leaving a pillar of gravel in the middle of the branch mine. The reason for this is that directly after the Turtle finishes executing `turtle.digUp()`, the gravel block is still falling; therefore, `turtle.detectUp()` returns `false`. This causes the Turtle to continue mining instead of properly stopping to mine the gravel above it. This can be solved by pausing the script for just the right amount of time so that it can detect gravel after it had fallen. This timing turned out to be 0.2 seconds, so adding `sleep(0.2)` after the digging functions forces the Turtle to halt for a brief period of time, mining gravel correctly. -``` -#!lua +```lua function miningIteration() while turtle.detect() do turtle.dig() @@ -75,8 +72,7 @@ Another interesting behaviour that needed to be debugged was directional-based. With regards to torch placement, this directional behaviour means that mining in the northwards and southwards direction requires no special treatment. In the remaining two directions, the torch will be placed on the block in front of the Turtle, and in the next iteration of mining, it will get mined along with the block it is attached to. On its own, ComputerCraft does not provide a way for Turtles to automatically determine what direction they are facing (additional mods can add additional types of Turtles to the game). Utilizing ComputerCraft's [GPS API][18] to determine the axis along which a Turtle is travelling would be the only way to add this functionality. As I do not have any GPS infrastructure in my world, I opted to have the Turtle simply prompt the user for the direction that it is facing and store it in the variable `direction`. -``` -#!lua +```lua while true do for i = 1, 8 do miningIteration() end if direction == 1 or direction == 3 then diff --git a/content/1402-deploying-pelican-sites-using-travis-ci.md b/content/1402-deploying-pelican-sites-using-travis-ci.md index 4e5e1a6e..366d3e1b 100644 --- a/content/1402-deploying-pelican-sites-using-travis-ci.md +++ b/content/1402-deploying-pelican-sites-using-travis-ci.md @@ -16,23 +16,20 @@ One of the issues that I ran into in the process of setting this up was installi Since I liked some of the features that I had previously included in my site generation Bash script, I rewrote Andrea's `deploy.sh` script to work similarly to my existing workflow. The entirety of the file can be found [in the GitHub repository](https://github.com/iKevinY/iKevinY.github.io/blob/src/generate.sh) of my website's source. My rewritten script grabs the hash and message of the most recent commit to the source branch: -``` -#!bash +```bash commitHash=`git rev-parse HEAD` commitMessage=`git log -1 --pretty=%B` ``` These variables are used during the `git commit` command to create a descriptive commit message. The commit message in the source branch is used as the first line of the commit message, and the commit hash and Travis build number are included as the extended part of the commit message: -``` -#!bash +```bash git commit -m "$commitMessage" -m "Generated by commit $commitHash; pushed by Travis build $TRAVIS_BUILD_NUMBER." ``` There are a few minor changes I made to the `rsync` and `git` commands of Andrea's script as well. Within the `rsync` command, I removed the asterisk from the source directory and added the `--delete` flag to instruct the script to delete files in the destination directory that are not present in the source directory. Simply adding the `--delete` flag to the version of the command present in Andrea's script will not affect the command as a result of the to the wildcard search caused by the asterisk: -``` -#!bash +```bash rsync -r --exclude=.git --delete ../$PELICAN_OUTPUT_FOLDER/ ./ ``` diff --git a/content/1501-on-git-and-github-flow.md b/content/1501-on-git-and-github-flow.md index 356c7193..c02d8773 100644 --- a/content/1501-on-git-and-github-flow.md +++ b/content/1501-on-git-and-github-flow.md @@ -48,7 +48,6 @@ $ git rebase -i HEAD~n # rebase the last n commits The `-i` flag stands for *interactive*. Upon executing the command, your `$EDITOR` of choice will open with a list of commits from least recent to most recent preceded by the word "pick": ``` -#!text pick a5b977a Ensure all expected resource files exist pick f08e801 Add problems 311–320 pick 969f9e5 Update tests to ensure resource correspondence @@ -63,7 +62,6 @@ Below the list of commits are some instructions about rebasing, including the av Typically, a project maintainer might ask for you to squash your pull request. What this actually involves doing is rebasing and using the "squash" command to turn multiple commits into just one or a couple logical commits. For example, if you wanted to turn the three commits listed above into one larger commit, you would edit the file to look like the following: ``` -#!text pick a5b977a Ensure all expected resource files exist squash f08e801 Add problems 311–320 squash 969f9e5 Update tests to ensure resource correspondence @@ -77,8 +75,7 @@ I mentioned before that rebasing should only be done with local changes that hav After forking the project on GitHub, the typical GitHub workflow might look something like this: -``` -#!sh +```sh git clone https://github.com/YOUR_GITHUB_USERNAME/PROJECT_NAME.git cd PROJECT_NAME git branch my-feature diff --git a/content/1701-breaking-the-engima-code-with-rust.md b/content/1701-breaking-the-engima-code-with-rust.md index 7d27e387..4734b6a0 100644 --- a/content/1701-breaking-the-engima-code-with-rust.md +++ b/content/1701-breaking-the-engima-code-with-rust.md @@ -73,8 +73,7 @@ The bulk of `ultra`'s decryption algorithm involves iterating over Enigma settin Using the amazing [Rayon](https://github.com/nikomatsakis/rayon) data parallelism library, many Rust iterators can be parallelized nearly effortlessly. With `ultra`, I essentially just needed to import Rayon's prelude and add a couple of calls to `into_par_iter()`. (I also had to collect into a vector because the result of `iproduct!` can't be directly transformed into a parallel iterator.) -``` -#!rust +```rust use rayon::prelude::*; let (rotor, key) = iproduct!(rotors.iter(), keys.iter()) diff --git a/pneumatic b/pneumatic index 0cecc271..5bbfdcb5 160000 --- a/pneumatic +++ b/pneumatic @@ -1 +1 @@ -Subproject commit 0cecc271df7a41e060faafbe63e7e95f99792ad1 +Subproject commit 5bbfdcb5f7e18fbdff7a74d2645370e98fdeccb0