From 46238db12b6178ce3826665a1fea180dd28b0356 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Fri, 9 Feb 2018 17:20:10 -0500 Subject: Update em-dashes for pandoc > 1.8.2.1 --- public/java-segfault-redux.md | 4 ++-- public/java-segfault.md | 4 ++-- public/nginx-mediawiki.md | 2 +- public/term-colors.md | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) (limited to 'public') diff --git a/public/java-segfault-redux.md b/public/java-segfault-redux.md index e91dcd3..6959498 100644 --- a/public/java-segfault-redux.md +++ b/public/java-segfault-redux.md @@ -70,10 +70,10 @@ through all of the JVM stuff to the OpenCV code, and the OpenCV stuff is opaque to Java debuggers. Eventually the issue lead me back into the WPICameraExtension, then -into WPIJavaCV--there was a native pointer being stored in a Java +into WPIJavaCV---there was a native pointer being stored in a Java variable; Java code called the native routine to `free()` the structure, but then tried to feed it to another routine later. This -lead to difficulty again--tracking objects with Java debuggers was +lead to difficulty again---tracking objects with Java debuggers was hard because they don't expect the program to suddenly segfault; it's Java code, Java doesn't segfault, it throws exceptions! diff --git a/public/java-segfault.md b/public/java-segfault.md index 7a2d4c3..fbffb52 100644 --- a/public/java-segfault.md +++ b/public/java-segfault.md @@ -49,10 +49,10 @@ the pointers that were causing the issue, because it was hard with native debuggers to see through all of the JVM stuff to the OpenCV code, and the OpenCV stuff is opaque to Java debuggers. -Eventually the issue lead me back into the Java code--there was a +Eventually the issue lead me back into the Java code---there was a native pointer being stored in a Java variable; Java code called the native routine to `free()` the structure, but then tried to feed it to -another routine later. This lead to difficulty again--tracking +another routine later. This lead to difficulty again---tracking objects with Java debuggers was hard because they don't expect the program to suddenly segfault; it's Java code, Java doesn't segfault, it throws exceptions! diff --git a/public/nginx-mediawiki.md b/public/nginx-mediawiki.md index 92d2d39..c450a3c 100644 --- a/public/nginx-mediawiki.md +++ b/public/nginx-mediawiki.md @@ -67,5 +67,5 @@ We are now using this configuration on FastCGI caching for PHP. The only thing I don't like about this is the `try_files /var/emtpy` -bits--surely there is a better way to have it go to one of the `@` +bits---surely there is a better way to have it go to one of the `@` location blocks, but I couldn't figure it out. diff --git a/public/term-colors.md b/public/term-colors.md index 47c583a..1682484 100644 --- a/public/term-colors.md +++ b/public/term-colors.md @@ -23,7 +23,7 @@ is a subset of the 256 color scheme, but I'm not sure. **8 colors: (actually 9)** First we had 8 colors (9 with "default", which doesn't have to be one of the 8). These are always roughly the same color: black, red, green, -yellow/orange, blue, purple, cyan, and white, which are colors 0-7 +yellow/orange, blue, purple, cyan, and white, which are colors 0--7 respectively. Color 9 is default. **16 colors: (actually 18)** @@ -33,7 +33,7 @@ attribute. So when bright is on, you get "bright red" instead of default"). **256 colors: (actually 274)** -You may have noticed, colors 0-7 and 9 are used, but 8 isn't. So, +You may have noticed, colors 0--7 and 9 are used, but 8 isn't. So, someone decided that color 8 should put the terminal into 256 color mode. In this mode, it reads another byte, which is an 8-bit RGB value (2 bits for red, 2 for green, 2 for blue). The bright property has no -- cgit v1.2.3-2-g168b