From 2ddbc2b056af0585b905606a2c6887d43f9c3b01 Mon Sep 17 00:00:00 2001 From: Leonardo Santiago Date: Sat, 1 Jun 2024 17:30:03 -0300 Subject: localize bearblog, update some UI --- .gitignore | 1 + .gitmodules | 3 - blog.org | 7 +- content/_index.md | 5 +- content/about.md | 3 +- content/blog/rust-is-not-about-memory-safety.md | 5 +- hugo.toml | 14 +- layouts/partials/custom_head.html | 2 +- layouts/partials/footer.html | 2 +- layouts/partials/header.html | 6 + layouts/partials/nav.html | 1 - public/404.html | 27 +- public/about/index.html | 45 +-- public/blog/correctness/index.html | 273 ------------- public/blog/correctness/index.xml | 19 - public/blog/index.html | 49 ++- public/blog/index.xml | 16 +- .../rust-is-not-about-memory-safety/index.html | 336 ++++++++++++++++ public/blog/rust/index.html | 273 ------------- public/blog/rust/index.xml | 19 - public/index.html | 45 +-- public/index.xml | 30 +- public/robots.txt | 2 +- public/rust-is-not-about-memory-safety/index.html | 337 ---------------- public/sitemap.xml | 24 +- public/tags/correctness/index.html | 272 +++++++++++++ public/tags/correctness/index.xml | 19 + public/tags/rust/index.html | 272 +++++++++++++ public/tags/rust/index.xml | 19 + themes/hugo-bearblog | 1 - themes/hugo-bearblog/.gitignore | 1 + themes/hugo-bearblog/.jsbeautifyrc | 27 ++ themes/hugo-bearblog/LICENSE | 20 + themes/hugo-bearblog/README.md | 86 +++++ themes/hugo-bearblog/archetypes/blog.md | 13 + themes/hugo-bearblog/archetypes/default.md | 22 ++ themes/hugo-bearblog/exampleSite/content/_index.md | 28 ++ themes/hugo-bearblog/exampleSite/content/bear.md | 18 + .../exampleSite/content/blog/_index.md | 3 + .../exampleSite/content/blog/markdown-syntax.md | 144 +++++++ themes/hugo-bearblog/exampleSite/content/hugo.md | 26 ++ themes/hugo-bearblog/exampleSite/hugo.toml | 52 +++ .../hugo-bearblog/exampleSite/static/favicon.ico | Bin 0 -> 15406 bytes .../exampleSite/static/images/favicon.png | Bin 0 -> 1312 bytes .../exampleSite/static/images/share.png | Bin 0 -> 25877 bytes themes/hugo-bearblog/layouts/404.html | 6 + themes/hugo-bearblog/layouts/_default/baseof.html | 43 +++ themes/hugo-bearblog/layouts/_default/list.html | 38 ++ themes/hugo-bearblog/layouts/_default/single.html | 20 + themes/hugo-bearblog/layouts/index.html | 3 + .../layouts/partials/custom_body.html | 3 + .../layouts/partials/custom_head.html | 3 + themes/hugo-bearblog/layouts/partials/favicon.html | 2 + themes/hugo-bearblog/layouts/partials/footer.html | 1 + themes/hugo-bearblog/layouts/partials/header.html | 4 + themes/hugo-bearblog/layouts/partials/nav.html | 7 + .../hugo-bearblog/layouts/partials/seo_tags.html | 13 + themes/hugo-bearblog/layouts/partials/style.html | 173 +++++++++ themes/hugo-bearblog/layouts/robots.txt | 2 + themes/hugo-bearblog/package-lock.json | 430 +++++++++++++++++++++ themes/hugo-bearblog/package.json | 28 ++ themes/hugo-bearblog/theme.toml | 25 ++ 62 files changed, 2300 insertions(+), 1068 deletions(-) create mode 100644 .gitignore create mode 100644 layouts/partials/header.html delete mode 100644 public/blog/correctness/index.html delete mode 100644 public/blog/correctness/index.xml create mode 100644 public/blog/rust-is-not-about-memory-safety/index.html delete mode 100644 public/blog/rust/index.html delete mode 100644 public/blog/rust/index.xml delete mode 100644 public/rust-is-not-about-memory-safety/index.html create mode 100644 public/tags/correctness/index.html create mode 100644 public/tags/correctness/index.xml create mode 100644 public/tags/rust/index.html create mode 100644 public/tags/rust/index.xml delete mode 160000 themes/hugo-bearblog create mode 100644 themes/hugo-bearblog/.gitignore create mode 100644 themes/hugo-bearblog/.jsbeautifyrc create mode 100644 themes/hugo-bearblog/LICENSE create mode 100644 themes/hugo-bearblog/README.md create mode 100644 themes/hugo-bearblog/archetypes/blog.md create mode 100644 themes/hugo-bearblog/archetypes/default.md create mode 100644 themes/hugo-bearblog/exampleSite/content/_index.md create mode 100644 themes/hugo-bearblog/exampleSite/content/bear.md create mode 100644 themes/hugo-bearblog/exampleSite/content/blog/_index.md create mode 100644 themes/hugo-bearblog/exampleSite/content/blog/markdown-syntax.md create mode 100644 themes/hugo-bearblog/exampleSite/content/hugo.md create mode 100644 themes/hugo-bearblog/exampleSite/hugo.toml create mode 100644 themes/hugo-bearblog/exampleSite/static/favicon.ico create mode 100644 themes/hugo-bearblog/exampleSite/static/images/favicon.png create mode 100644 themes/hugo-bearblog/exampleSite/static/images/share.png create mode 100644 themes/hugo-bearblog/layouts/404.html create mode 100644 themes/hugo-bearblog/layouts/_default/baseof.html create mode 100644 themes/hugo-bearblog/layouts/_default/list.html create mode 100644 themes/hugo-bearblog/layouts/_default/single.html create mode 100644 themes/hugo-bearblog/layouts/index.html create mode 100644 themes/hugo-bearblog/layouts/partials/custom_body.html create mode 100644 themes/hugo-bearblog/layouts/partials/custom_head.html create mode 100644 themes/hugo-bearblog/layouts/partials/favicon.html create mode 100644 themes/hugo-bearblog/layouts/partials/footer.html create mode 100644 themes/hugo-bearblog/layouts/partials/header.html create mode 100644 themes/hugo-bearblog/layouts/partials/nav.html create mode 100644 themes/hugo-bearblog/layouts/partials/seo_tags.html create mode 100644 themes/hugo-bearblog/layouts/partials/style.html create mode 100644 themes/hugo-bearblog/layouts/robots.txt create mode 100644 themes/hugo-bearblog/package-lock.json create mode 100644 themes/hugo-bearblog/package.json create mode 100644 themes/hugo-bearblog/theme.toml diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..ff51edf --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.direnv \ No newline at end of file diff --git a/.gitmodules b/.gitmodules index c53b474..e69de29 100644 --- a/.gitmodules +++ b/.gitmodules @@ -1,3 +0,0 @@ -[submodule "themes/hugo-bearblog"] - path = themes/hugo-bearblog - url = https://github.com/janraasch/hugo-bearblog.git diff --git a/blog.org b/blog.org index 2916438..5f0cfba 100644 --- a/blog.org +++ b/blog.org @@ -1,9 +1,10 @@ #+title: lowest case +#+description: a lower case only blog, purely for aesthetics #+author: santi #+hugo_base_dir: . #+hugo_auto_set_lastmod: t -* lowest case +* home :PROPERTIES: :EXPORT_HUGO_SECTION: / :EXPORT_FILE_NAME: _index @@ -35,7 +36,7 @@ this blog was built using emacs' excelent org-mode and [[https://github.com/gohu :PROPERTIES: :EXPORT_HUGO_SECTION: /blog :END: -** rust is not about memory safety :rust:correctness: +** rust is not about memory safety :rust:correctness: :PROPERTIES: :EXPORT_FILE_NAME: rust-is-not-about-memory-safety :END: @@ -67,7 +68,7 @@ i say /well behaved/ because i can't say /invalid/. it is in fact defined by the framing it this way really exposes the fragility of C, because undefined behavior has to always be taken into account. and, by the nature of it, there is no way to represent it other than as a black box, such that, if your code ever encounters it, then literally all you can say is that *the whole result of the program* is undefined - that is, it can be anything. you cannot show properties, nor say what will happen once your program enters this state, as the C specification literally does not define it. it may come to a halt, write garbage to the screen or completely delete half of the files of your program, and there's no way to predict what will come out of it, by definition. in the lucky case, it will segfault while executing and you'll be extremely pissed off, but that is not at all guaranteed. this is akin to having a float expression with some deep term being ~NaN~, in that it eventually must evaluate to ~NaN~ and you can't draw any conclusions about the result of the expression (other that it isn't a number). -language designers are by no means dumb, and yes, they know much, much more than me about these problems. undefined behavior exists exactly because there must be parts of your code that your compiler *must* assume that aren't possible, so that it can correctly compile. for example, let's say that you inadvertently try to dereference a pointer that you have no knowledge about. the C compiler simply does not have enough information to know if it is ~NULL~, if it is still pointing to valid memory, or if the memory has been initialized, so what it's approach is simply emit code *as if* it was a valid, initialized, non-null pointer. +language designers and compiler developers are by no means dumb, and yes, they know much, much more than me about these problems. undefined behavior exists exactly because there must be parts of your code that your compiler *must* assume that aren't possible, so that it can correctly compile. for example, let's say that you inadvertently try to dereference a pointer that you have no knowledge about. the C compiler simply does not have enough information to know if it is ~NULL~, if it is still pointing to valid memory, or if the memory has been initialized, so what it's approach is simply emit code *as if* it was a valid, initialized, non-null pointer. it is essential to realize that this is an *assumption*, and in almost most cases, it simply does not care whether or not it actually was actually still valid, so writing to it may have a myriad of effects of different effects (none of which are the compiler's concerns). sometimes, your system might correctly intercept a read/write from invalid/null memory and raise you a signal, but that is not guaranteed. diff --git a/content/_index.md b/content/_index.md index db8eace..a4f9a56 100644 --- a/content/_index.md +++ b/content/_index.md @@ -1,7 +1,8 @@ +++ -title = "lowest case" +title = "home" author = ["santi"] -lastmod = 2024-06-01T10:31:58-03:00 +description = "a lower case only blog, purely for aesthetics" +lastmod = 2024-06-01T17:29:17-03:00 draft = false +++ diff --git a/content/about.md b/content/about.md index 6f59209..5ca6f1b 100644 --- a/content/about.md +++ b/content/about.md @@ -1,7 +1,8 @@ +++ title = "about" author = ["santi"] -lastmod = 2024-06-01T12:12:47-03:00 +description = "a lower case only blog, purely for aesthetics" +lastmod = 2024-06-01T17:29:17-03:00 draft = false menu = "main" +++ diff --git a/content/blog/rust-is-not-about-memory-safety.md b/content/blog/rust-is-not-about-memory-safety.md index b060f3c..e794a39 100644 --- a/content/blog/rust-is-not-about-memory-safety.md +++ b/content/blog/rust-is-not-about-memory-safety.md @@ -1,7 +1,8 @@ +++ title = "rust is not about memory safety" author = ["santi"] -lastmod = 2024-06-01T15:21:30-03:00 +description = "a lower case only blog, purely for aesthetics" +lastmod = 2024-06-01T17:29:17-03:00 tags = ["rust", "correctness"] draft = false +++ @@ -36,7 +37,7 @@ i say _well behaved_ because i can't say _invalid_. it is in fact defined by the framing it this way really exposes the fragility of C, because undefined behavior has to always be taken into account. and, by the nature of it, there is no way to represent it other than as a black box, such that, if your code ever encounters it, then literally all you can say is that **the whole result of the program** is undefined - that is, it can be anything. you cannot show properties, nor say what will happen once your program enters this state, as the C specification literally does not define it. it may come to a halt, write garbage to the screen or completely delete half of the files of your program, and there's no way to predict what will come out of it, by definition. in the lucky case, it will segfault while executing and you'll be extremely pissed off, but that is not at all guaranteed. this is akin to having a float expression with some deep term being `NaN`, in that it eventually must evaluate to `NaN` and you can't draw any conclusions about the result of the expression (other that it isn't a number). -language designers are by no means dumb, and yes, they know much, much more than me about these problems. undefined behavior exists exactly because there must be parts of your code that your compiler **must** assume that aren't possible, so that it can correctly compile. for example, let's say that you inadvertently try to dereference a pointer that you have no knowledge about. the C compiler simply does not have enough information to know if it is `NULL`, if it is still pointing to valid memory, or if the memory has been initialized, so what it's approach is simply emit code **as if** it was a valid, initialized, non-null pointer. +language designers and compiler developers are by no means dumb, and yes, they know much, much more than me about these problems. undefined behavior exists exactly because there must be parts of your code that your compiler **must** assume that aren't possible, so that it can correctly compile. for example, let's say that you inadvertently try to dereference a pointer that you have no knowledge about. the C compiler simply does not have enough information to know if it is `NULL`, if it is still pointing to valid memory, or if the memory has been initialized, so what it's approach is simply emit code **as if** it was a valid, initialized, non-null pointer. it is essential to realize that this is an **assumption**, and in almost most cases, it simply does not care whether or not it actually was actually still valid, so writing to it may have a myriad of effects of different effects (none of which are the compiler's concerns). sometimes, your system might correctly intercept a read/write from invalid/null memory and raise you a signal, but that is not guaranteed. diff --git a/hugo.toml b/hugo.toml index d56797d..60878fa 100644 --- a/hugo.toml +++ b/hugo.toml @@ -6,24 +6,26 @@ baseURL = "https://o-santi.github.com" theme = 'hugo-bearblog' # Basic metadata configuration for your blog. -title = "lowestcase" +title = "lowest case" author = "leonardo santiago" languageCode = "en-US" # Generate a nice robots.txt for SEO enableRobotsTXT = true staticDir = [ "static" ] +titleCaseStyle = 'none' +pluralizeListTitles = false # Generate "Bearblog"-like URLs !only!, see https://bearblog.dev/. disableKinds = ["taxonomy"] ignoreErrors = ["error-disable-taxonomy"] [permalinks] - blog = "/:slug/" - tags = "/blog/:slug" + blog = "/blog/:slug" + tags = "/tags/:slug" [params] # The "description" of your website. This is used in the meta data of your generated html. - description = "a lowercase only blog" + description = "a lowercase only blog, purely for aesthetics" # The path to your "favicon". This should be a square (at least 32px x 32px) png-file. # Hint: It's good practise to also put a "favicon.ico"-file into your "static"-folder. @@ -38,7 +40,7 @@ ignoreErrors = ["error-disable-taxonomy"] # Another "title" :-). This one is used as the site_name on the Hugo's internal # opengraph structured data template. # See https://ogp.me/ and https://gohugo.io/templates/internal#open-graph. - title = "lowestcase" + title = "lowest case" # This theme will, by default, inject a made-with-line at the bottom of the page. # You can turn it off, but we would really appreciate if you don’t :-). @@ -49,4 +51,4 @@ ignoreErrors = ["error-disable-taxonomy"] # file. See [Hugo's Format function docs](https://gohugo.io/functions/format/) # for details. An example TOML config that uses [ISO # 8601](https://en.wikipedia.org/wiki/ISO_8601) format: - dateFormat = "02-01-2006" + dateFormat = "02 January, 2006" diff --git a/layouts/partials/custom_head.html b/layouts/partials/custom_head.html index 71cbf20..805fb4b 100644 --- a/layouts/partials/custom_head.html +++ b/layouts/partials/custom_head.html @@ -5,7 +5,7 @@ } a:hover { color:#d46b08; - text-decoration: dotted underline; + text-decoration: wavy underline; } ul.blog-posts li a:visited { color:#ffc069; diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html index a102ffa..0ff926e 100644 --- a/layouts/partials/footer.html +++ b/layouts/partials/footer.html @@ -1 +1 @@ -leonardo santiago | +

leonardo santiago |

diff --git a/layouts/partials/header.html b/layouts/partials/header.html new file mode 100644 index 0000000..a7928a6 --- /dev/null +++ b/layouts/partials/header.html @@ -0,0 +1,6 @@ + diff --git a/layouts/partials/nav.html b/layouts/partials/nav.html index 909fc98..48f96d0 100644 --- a/layouts/partials/nav.html +++ b/layouts/partials/nav.html @@ -1,4 +1,3 @@ -home {{ range .Site.Menus.main }} {{ .Name }} {{ end }} diff --git a/public/404.html b/public/404.html index 12d4704..8568043 100644 --- a/public/404.html +++ b/public/404.html @@ -1,33 +1,33 @@ - + 404 - + - - + + - + - + - + - - - - -
-

lowestcase

- - -
-
- - -

Filtering for "Correctness"

- - Remove filter - - - - - - - -
- - - - - - diff --git a/public/blog/correctness/index.xml b/public/blog/correctness/index.xml deleted file mode 100644 index 9b91eed..0000000 --- a/public/blog/correctness/index.xml +++ /dev/null @@ -1,19 +0,0 @@ - - - - Correctness on lowestcase - http://localhost:1313/blog/correctness/ - Recent content in Correctness on lowestcase - Hugo - en-US - Sat, 01 Jun 2024 15:21:30 -0300 - - - rust is not about memory safety - http://localhost:1313/rust-is-not-about-memory-safety/ - Sat, 01 Jun 2024 15:21:30 -0300 - http://localhost:1313/rust-is-not-about-memory-safety/ - most of rust discussions nowadays revolve about memory safety, and how it is safer than C / C++ / zig / go / whatever language is being trashed on twitter that day. while yes, that is true - not that the bar for most of these is particularly high - what I think is the main point of the language is always glossed over: correctness. when one tries to criticize any of the aforementioned languages, one is answered with the following argument: - - - diff --git a/public/blog/index.html b/public/blog/index.html index cfe0206..d136f7b 100644 --- a/public/blog/index.html +++ b/public/blog/index.html @@ -1,37 +1,37 @@ - + -Blogs | lowestcase - - +blog | lowest case + + - - - - + + + + - - + + - - - + + + - + + + + + +
+
+
+ +

rust is not about memory safety

+

+ + + +

+ + +

most of rust discussions nowadays revolve about memory safety, and how it is safer than C / C++ / zig / go / whatever language is being trashed on twitter that day. while yes, that is true - not that the bar for most of these is particularly high - what I think is the main point of the language is always glossed over: correctness. when one tries to criticize any of the aforementioned languages, one is answered with the following argument:

+
+

your program segfaults? skill issue

+
+

but i’d like to make the counter-argument that, no, this has nothing to do with skill issue.

+

formal language theory

+

the first thing one learns when they’re studying formal languages (the field that studies grammars, state automata, etc) is that the rules that describe a certain grammar must match exactly the ones that you want to include in your language. this means that there’s a bidirectional relationship between the grammar you describe (which directly define the automata that parses that language) and the words1 that it parses (which are related to the semantics of the program, how it executes).

+

from it, it can be inferred that the grammar must not allow in the language any words that does not have defined semantics, and in the opposite direction, that the language should not specify semantics to any program that cannot be parsed by the rules of the grammar. both of these are required in order to make study of this grammar <-> language partnership fun, pleasing, and most importantly sound.

+

going beyond, formal language theory also gives you the knowledge that the execution of any program can be given as a set of grammar rules in an abstract machine (the most famous one being a turing machine). in the same way you can define a set of grammar rules to parse parenthesized arithmetic expressions using a stack automaton, you can define a set of grammar rules to model the execution of a C program, and, albeit super complex, can be modeled as a turing machine. this usually gets the name of C abstract machine, and is the basis for formal specification of behavior in the language.

+

and no, i’m not talking about modeling a C parser as a state machine (which probably is easier than most languages, if you ignore pre-processor stuff). i’m talking about modeling C execution as a language being parsed. drawing a parallel, when parsing parenthesized expressions, you pop things in and out of the stack to represent “balancedness”, and in the same way, when “parsecuting” C code, you must write to memory, represent side effects, represent type casts and pointer conversions and everything as part of the language.

+

in the same way that you’d hope that a parenthesized arithmetic expression parser would recognize that (1 + 2) + 3) is an invalid expression, you’d expect that the C compiler would correctly verify that the following series of tokens is not a well behaved program:

+
int foo(int * myptr) {
+  *myptr = 5;
+}
+foo(NULL);
+

i say well behaved because i can’t say invalid. it is in fact defined by the spec that when you dereference a NULL pointer the result is undefined behavior. and this is C’s achilles heel: instead of outright banning programs like the one above (which i’d argue is the correct approach), it will happily compile and give you garbage output.

+

framing it this way really exposes the fragility of C, because undefined behavior has to always be taken into account. and, by the nature of it, there is no way to represent it other than as a black box, such that, if your code ever encounters it, then literally all you can say is that the whole result of the program is undefined - that is, it can be anything. you cannot show properties, nor say what will happen once your program enters this state, as the C specification literally does not define it. it may come to a halt, write garbage to the screen or completely delete half of the files of your program, and there’s no way to predict what will come out of it, by definition. in the lucky case, it will segfault while executing and you’ll be extremely pissed off, but that is not at all guaranteed. this is akin to having a float expression with some deep term being NaN, in that it eventually must evaluate to NaN and you can’t draw any conclusions about the result of the expression (other that it isn’t a number).

+

language designers and compiler developers are by no means dumb, and yes, they know much, much more than me about these problems. undefined behavior exists exactly because there must be parts of your code that your compiler must assume that aren’t possible, so that it can correctly compile. for example, let’s say that you inadvertently try to dereference a pointer that you have no knowledge about. the C compiler simply does not have enough information to know if it is NULL, if it is still pointing to valid memory, or if the memory has been initialized, so what it’s approach is simply emit code as if it was a valid, initialized, non-null pointer.

+

it is essential to realize that this is an assumption, and in almost most cases, it simply does not care whether or not it actually was actually still valid, so writing to it may have a myriad of effects of different effects (none of which are the compiler’s concerns). sometimes, your system might correctly intercept a read/write from invalid/null memory and raise you a signal, but that is not guaranteed.

+

and there are a huge number of tools to aid in finding undefined behavior, it’s just that 1. they are not by any means standards of C development (not in spec and not in standard compilers) and 2 they are fallible and will always let some undefined programs slip by.

+

runtime exceptions are not the solution

+

most languages try to handle this by introducing some sort of runtime exception system, which i think is a terrible idea. while this is much, much safer than what C does, it still makes reasoning about the code extremely hard by completely obliterating locality of reason. your indexing operation may still be out of bounds, and while this now has defined outcomes, it is one of the possible outcomes of your program (whether you like it or not), and you must handle it. and, of course, no one handles all of them, for it is humanely impossible to do it in most languages because:

+
    +
  1. it is hard to know when an operation can raise an exception, and under which conditions.
    2. +
  2. even if documented, it is never enforced that all exceptions must be gracefully handled, so some random function in a dependency of a dependency may raise an error from an unexpected corner case and you must deal with it.
    3. +
+

this is a symptom of virtually all modern languages, and none of them have any good answers to it. java mandates that you report in your function type signature the errors that it may raise (which is a rare java W), but it does let you write code with unchecked exceptions that won’t signal a compile error if ignored, which eventually will crash your minecraft game. python, ruby, php and most other languages (even haskell made this mistake) do not even attempt to signal when a function might raise an exception. javascript somehow manages to be even worse, by having horrible implicit-by-default type casts, having undefined AND null, using strings as UTF-16, using floats as standard numbers, implicitly inserting semicolons, and honestly the list could go on forever.

+

the root of all these problems is, quite literally, the same: that your compiler (or interpreter) lets into your program execution states that you didn’t anticipate for. one of the best of examples of the opposite, surprisingly enough, is regex matchers. while i concede that their syntax can be extremely confusing, they have the best property of software: if they compile, they work exactly as intended - which i henceforth will call correctness. this is because regular languages’ properties and their state automata have been studied to extreme depths, and it is entirely possible to write a regex implementation that is correct (in the same way as above), going as far as providing formal verifications of that 2.

+

from this definition of correctness we can also derive a semantically useful definition for the word bug: an unexpected outcome for the program, that shouldn’t be allowed in the language. of course java behavior might be defined for all inputs (for the most part, i’m sure there are might be problems here and there) but just because one possible outcome of program is NullPointerException doesn’t mean that it is expected, making it, by my definition, a bug.

+

make invalid states unrepresentable

+

what the regex example makes clear is that the key to correctness is to make your language tight enough to have defined and desired output for all possible inputs. this is not to say that it won’t raise errors; much to the contrary, it must have parser errors saying that some strings aren’t valid regexes. instead, it means that all errors are predictable, and well defined (in some sense).

+

you, as the programmer, is then in charge of ensuring that the resulting regex program actually solves the problem you have at hands. want to match 3 words of 2 digit numbers followed by a capital letter? great, they can do that. want to match balanced parenthesized expressions? sadly, regex is incapable of ever solving that, because that language is not regular, so no matter how hard you try it will never solve it.

+

in a way, there’s a beauty in how C sidesteps this: it defines one of the possible program outputs as being undefined, and it is on the programmers behalf to tightly ensure that the program has 0 paths to undefined behavior. in fact, it is probably one of the most well specified languages, which is what makes it suitable for writing formally verifiable programs 3.

+

the main strength of rust, and where it differs from all mainstream languages, is that it has a very clear focus on program correctness. the raison d’être of the borrow checker is statically assuring that all references are pointing to valid memory, such that it is literally impossible for any borrow be null or to point to some freed memory (modulus implementation errors of course). this completely rules out this possibility of bugs from the language we’re trying to “parse”. remember the C excerpt from above, where i said that the compiler should rule out the program as invalid? well, it is literally impossible to write that sort of program in rust, because one cannot construct a NULL reference.

+

not only that, but rust languages features makes it so, so much easier to write correct software: sum types (tagged unions), Option instead of NULL (which in and of itself is amazing), Result for errors (making obligatory to handle all possible branches your program can take), a strong and powerful static type system, and ditching inheritance and classes in favor of traits.

+

note that i never ever talked about memory safety. even in a world where C wasn’t in fact full of memory vulnerabilities, rust would still be miles better, because it statically assures you that the meaning of your program is tightly reproduced by the code you’ve written. it is, by design, more correct than C, and the only way a problem can possibly happen is by side stepping rust static checks by using unsafe.

+

it is just a happy coincidence that this leads to a language that isn’t garbage collected, that is relatively lean, fast, easy to embed, has good ergonomics and that enables you to write asynchronous and multi-threaded programs. these properties are awesome to boost rust to a very well regarded status between developers, but aren’t at all related to languages that enable you to build reliable, correct software. out of curiosity, i’d happily defend the case that coq is also one of these languages, and it absolutely does not hold any of these any of those.

+

software engineering as a craft

+

finally, i think this relates to how i personally model the software development job as a whole. it starts by having some problem you think you can use computers to solve, and then follow 3 clearly stratified steps:

+
    +
  1. define how one might solve the problem. this usually means splitting it into several possible cases and treating each and every one of them separately.
    2. +
  2. define an abstract machine that executes the very same steps, and making sure that it tightly adheres to your plan
    3. +
  3. implement the very same machine in a language, making sure that your implementation adheres tightly to your abstract machine
    4. +
+

the part that programmers usually get paid millions of dollars for is the step 1 -> 2, which is by far the hardest and that requires the most creativity and craftsmanship. what usually makes people say that software is in decline is that we don’t learn the value of executing step 3 properly. this leads to sloppy, half baked software that crashes when X Y Z happens, and we’ve just come to terms with software being so brittle.

+

it is not by chance that Yang et al. could only find measly 9 bugs after 6 CPU years of fuzzing in compcert, a formally verified c compiler (written in coq), where as in gcc and clang, they found and reported more than 300. all these 9 bugs where in the unverified front end of the compiler (the parser), and there were literally 0 middle end (compiler passes and AST translations) bugs found, which is unheard of. this is not by chance, they’ve spent many years writing proofs that all of their passes are correct, safe, and preserve the meaning of the original program.

+

i really think software developers should strive for that kind of resilience, which i believe can only be achieved through properly valuing correctness . i don’t think it is reasonable to expect that all software be built using coq and proving every little bit of it (due to business constraints) but i think that rust is a good enough language to start taking things more seriously.

+
+
+
    +
  1. +

    formally they are defined as a sequence of tokens in certain alphabet that the automata closures over. normally we think of “words” as the whole program that we’re parsing. ↩︎

    +
    2. +
  2. +

    the excellent software foundations book explains thoroughly how one might formally write one possible regex matcher, and prove that the implementation is correct ↩︎

    +
    3. +
  3. +

    through the use of external tools like Coq’s verifiable C series ↩︎

    +
    4. +
+
+ + +

+ + #rust + + #correctness + +

+ +
+ + + + + + diff --git a/public/blog/rust/index.html b/public/blog/rust/index.html deleted file mode 100644 index d61a2ab..0000000 --- a/public/blog/rust/index.html +++ /dev/null @@ -1,273 +0,0 @@ - - - - - - - -Rust | lowestcase - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

lowestcase

- - -
-
- - -

Filtering for "Rust"

- - Remove filter - - - - - - - -
- - - - - - diff --git a/public/blog/rust/index.xml b/public/blog/rust/index.xml deleted file mode 100644 index 8714ca6..0000000 --- a/public/blog/rust/index.xml +++ /dev/null @@ -1,19 +0,0 @@ - - - - Rust on lowestcase - http://localhost:1313/blog/rust/ - Recent content in Rust on lowestcase - Hugo - en-US - Sat, 01 Jun 2024 15:21:30 -0300 - - - rust is not about memory safety - http://localhost:1313/rust-is-not-about-memory-safety/ - Sat, 01 Jun 2024 15:21:30 -0300 - http://localhost:1313/rust-is-not-about-memory-safety/ - most of rust discussions nowadays revolve about memory safety, and how it is safer than C / C++ / zig / go / whatever language is being trashed on twitter that day. while yes, that is true - not that the bar for most of these is particularly high - what I think is the main point of the language is always glossed over: correctness. when one tries to criticize any of the aforementioned languages, one is answered with the following argument: - - - diff --git a/public/index.html b/public/index.html index 30dd6c4..0a3ba87 100644 --- a/public/index.html +++ b/public/index.html @@ -2,41 +2,39 @@ - + -lowest case | lowestcase - - +home | lowest case + + - - - - + + + + - - + + - - - - + + + + - + - - - - -
-

lowestcase

- - -
-
- -

rust is not about memory safety

-

- - - -

- - -

most of rust discussions nowadays revolve about memory safety, and how it is safer than C / C++ / zig / go / whatever language is being trashed on twitter that day. while yes, that is true - not that the bar for most of these is particularly high - what I think is the main point of the language is always glossed over: correctness. when one tries to criticize any of the aforementioned languages, one is answered with the following argument:

-
-

your program segfaults? skill issue

-
-

but i’d like to make the counter-argument that, no, this has nothing to do with skill issue.

-

formal language theory

-

the first thing one learns when they’re studying formal languages (the field that studies grammars, state automata, etc) is that the rules that describe a certain grammar must match exactly the ones that you want to include in your language. this means that there’s a bidirectional relationship between the grammar you describe (which directly define the automata that parses that language) and the words1 that it parses (which are related to the semantics of the program, how it executes).

-

from it, it can be inferred that the grammar must not allow in the language any words that does not have defined semantics, and in the opposite direction, that the language should not specify semantics to any program that cannot be parsed by the rules of the grammar. both of these are required in order to make study of this grammar <-> language partnership fun, pleasing, and most importantly sound.

-

going beyond, formal language theory also gives you the knowledge that the execution of any program can be given as a set of grammar rules in an abstract machine (the most famous one being a turing machine). in the same way you can define a set of grammar rules to parse parenthesized arithmetic expressions using a stack automaton, you can define a set of grammar rules to model the execution of a C program, and, albeit super complex, can be modeled as a turing machine. this usually gets the name of C abstract machine, and is the basis for formal specification of behavior in the language.

-

and no, i’m not talking about modeling a C parser as a state machine (which probably is easier than most languages, if you ignore pre-processor stuff). i’m talking about modeling C execution as a language being parsed. drawing a parallel, when parsing parenthesized expressions, you pop things in and out of the stack to represent “balancedness”, and in the same way, when “parsecuting” C code, you must write to memory, represent side effects, represent type casts and pointer conversions and everything as part of the language.

-

in the same way that you’d hope that a parenthesized arithmetic expression parser would recognize that (1 + 2) + 3) is an invalid expression, you’d expect that the C compiler would correctly verify that the following series of tokens is not a well behaved program:

-
int foo(int * myptr) {
-  *myptr = 5;
-}
-foo(NULL);
-

i say well behaved because i can’t say invalid. it is in fact defined by the spec that when you dereference a NULL pointer the result is undefined behavior. and this is C’s achilles heel: instead of outright banning programs like the one above (which i’d argue is the correct approach), it will happily compile and give you garbage output.

-

framing it this way really exposes the fragility of C, because undefined behavior has to always be taken into account. and, by the nature of it, there is no way to represent it other than as a black box, such that, if your code ever encounters it, then literally all you can say is that the whole result of the program is undefined - that is, it can be anything. you cannot show properties, nor say what will happen once your program enters this state, as the C specification literally does not define it. it may come to a halt, write garbage to the screen or completely delete half of the files of your program, and there’s no way to predict what will come out of it, by definition. in the lucky case, it will segfault while executing and you’ll be extremely pissed off, but that is not at all guaranteed. this is akin to having a float expression with some deep term being NaN, in that it eventually must evaluate to NaN and you can’t draw any conclusions about the result of the expression (other that it isn’t a number).

-

language designers are by no means dumb, and yes, they know much, much more than me about these problems. undefined behavior exists exactly because there must be parts of your code that your compiler must assume that aren’t possible, so that it can correctly compile. for example, let’s say that you inadvertently try to dereference a pointer that you have no knowledge about. the C compiler simply does not have enough information to know if it is NULL, if it is still pointing to valid memory, or if the memory has been initialized, so what it’s approach is simply emit code as if it was a valid, initialized, non-null pointer.

-

it is essential to realize that this is an assumption, and in almost most cases, it simply does not care whether or not it actually was actually still valid, so writing to it may have a myriad of effects of different effects (none of which are the compiler’s concerns). sometimes, your system might correctly intercept a read/write from invalid/null memory and raise you a signal, but that is not guaranteed.

-

and there are a huge number of tools to aid in finding undefined behavior, it’s just that 1. they are not by any means standards of C development (not in spec and not in standard compilers) and 2 they are fallible and will always let some undefined programs slip by.

-

runtime exceptions are not the solution

-

most languages try to handle this by introducing some sort of runtime exception system, which i think is a terrible idea. while this is much, much safer than what C does, it still makes reasoning about the code extremely hard by completely obliterating locality of reason. your indexing operation may still be out of bounds, and while this now has defined outcomes, it is one of the possible outcomes of your program (whether you like it or not), and you must handle it. and, of course, no one handles all of them, for it is humanely impossible to do it in most languages because:

-
    -
  1. it is hard to know when an operation can raise an exception, and under which conditions.
    2. -
  2. even if documented, it is never enforced that all exceptions must be gracefully handled, so some random function in a dependency of a dependency may raise an error from an unexpected corner case and you must deal with it.
    3. -
-

this is a symptom of virtually all modern languages, and none of them have any good answers to it. java mandates that you report in your function type signature the errors that it may raise (which is a rare java W), but it does let you write code with unchecked exceptions that won’t signal a compile error if ignored, which eventually will crash your minecraft game. python, ruby, php and most other languages (even haskell made this mistake) do not even attempt to signal when a function might raise an exception. javascript somehow manages to be even worse, by having horrible implicit-by-default type casts, having undefined AND null, using strings as UTF-16, using floats as standard numbers, implicitly inserting semicolons, and honestly the list could go on forever.

-

the root of all these problems is, quite literally, the same: that your compiler (or interpreter) lets into your program execution states that you didn’t anticipate for. one of the best of examples of the opposite, surprisingly enough, is regex matchers. while i concede that their syntax can be extremely confusing, they have the best property of software: if they compile, they work exactly as intended - which i henceforth will call correctness. this is because regular languages’ properties and their state automata have been studied to extreme depths, and it is entirely possible to write a regex implementation that is correct (in the same way as above), going as far as providing formal verifications of that 2.

-

from this definition of correctness we can also derive a semantically useful definition for the word bug: an unexpected outcome for the program, that shouldn’t be allowed in the language. of course java behavior might be defined for all inputs (for the most part, i’m sure there are might be problems here and there) but just because one possible outcome of program is NullPointerException doesn’t mean that it is expected, making it, by my definition, a bug.

-

make invalid states unrepresentable

-

what the regex example makes clear is that the key to correctness is to make your language tight enough to have defined and desired output for all possible inputs. this is not to say that it won’t raise errors; much to the contrary, it must have parser errors saying that some strings aren’t valid regexes. instead, it means that all errors are predictable, and well defined (in some sense).

-

you, as the programmer, is then in charge of ensuring that the resulting regex program actually solves the problem you have at hands. want to match 3 words of 2 digit numbers followed by a capital letter? great, they can do that. want to match balanced parenthesized expressions? sadly, regex is incapable of ever solving that, because that language is not regular, so no matter how hard you try it will never solve it.

-

in a way, there’s a beauty in how C sidesteps this: it defines one of the possible program outputs as being undefined, and it is on the programmers behalf to tightly ensure that the program has 0 paths to undefined behavior. in fact, it is probably one of the most well specified languages, which is what makes it suitable for writing formally verifiable programs 3.

-

the main strength of rust, and where it differs from all mainstream languages, is that it has a very clear focus on program correctness. the raison d’être of the borrow checker is statically assuring that all references are pointing to valid memory, such that it is literally impossible for any borrow be null or to point to some freed memory (modulus implementation errors of course). this completely rules out this possibility of bugs from the language we’re trying to “parse”. remember the C excerpt from above, where i said that the compiler should rule out the program as invalid? well, it is literally impossible to write that sort of program in rust, because one cannot construct a NULL reference.

-

not only that, but rust languages features makes it so, so much easier to write correct software: sum types (tagged unions), Option instead of NULL (which in and of itself is amazing), Result for errors (making obligatory to handle all possible branches your program can take), a strong and powerful static type system, and ditching inheritance and classes in favor of traits.

-

note that i never ever talked about memory safety. even in a world where C wasn’t in fact full of memory vulnerabilities, rust would still be miles better, because it statically assures you that the meaning of your program is tightly reproduced by the code you’ve written. it is, by design, more correct than C, and the only way a problem can possibly happen is by side stepping rust static checks by using unsafe.

-

it is just a happy coincidence that this leads to a language that isn’t garbage collected, that is relatively lean, fast, easy to embed, has good ergonomics and that enables you to write asynchronous and multi-threaded programs. these properties are awesome to boost rust to a very well regarded status between developers, but aren’t at all related to languages that enable you to build reliable, correct software. out of curiosity, i’d happily defend the case that coq is also one of these languages, and it absolutely does not hold any of these any of those.

-

software engineering as a craft

-

finally, i think this relates to how i personally model the software development job as a whole. it starts by having some problem you think you can use computers to solve, and then follow 3 clearly stratified steps:

-
    -
  1. define how one might solve the problem. this usually means splitting it into several possible cases and treating each and every one of them separately.
    2. -
  2. define an abstract machine that executes the very same steps, and making sure that it tightly adheres to your plan
    3. -
  3. implement the very same machine in a language, making sure that your implementation adheres tightly to your abstract machine
    4. -
-

the part that programmers usually get paid millions of dollars for is the step 1 -> 2, which is by far the hardest and that requires the most creativity and craftsmanship. what usually makes people say that software is in decline is that we don’t learn the value of executing step 3 properly. this leads to sloppy, half baked software that crashes when X Y Z happens, and we’ve just come to terms with software being so brittle.

-

it is not by chance that Yang et al. could only find measly 9 bugs after 6 CPU years of fuzzing in compcert, a formally verified c compiler (written in coq), where as in gcc and clang, they found and reported more than 300. all these 9 bugs where in the unverified front end of the compiler (the parser), and there were literally 0 middle end (compiler passes and AST translations) bugs found, which is unheard of. this is not by chance, they’ve spent many years writing proofs that all of their passes are correct, safe, and preserve the meaning of the original program.

-

i really think software developers should strive for that kind of resilience, which i believe can only be achieved through properly valuing correctness . i don’t think it is reasonable to expect that all software be built using coq and proving every little bit of it (due to business constraints) but i think that rust is a good enough language to start taking things more seriously.

-
-
-
    -
  1. -

    formally they are defined as a sequence of tokens in certain alphabet that the automata closures over. normally we think of “words” as the whole program that we’re parsing. ↩︎

    -
    2. -
  2. -

    the excellent software foundations book explains thoroughly how one might formally write one possible regex matcher, and prove that the implementation is correct ↩︎

    -
    3. -
  3. -

    through the use of external tools like Coq’s verifiable C series ↩︎

    -
    4. -
-
- - -

- - #Rust - - #Correctness - -

- -
- - - - - - diff --git a/public/sitemap.xml b/public/sitemap.xml index ff8dc18..d640e7b 100644 --- a/public/sitemap.xml +++ b/public/sitemap.xml @@ -2,22 +2,22 @@ - http://localhost:1313/blog/ - 2024-06-01T15:21:30-03:00 + https://o-santi.github.com/about/ + 2024-06-01T17:29:17-03:00 - http://localhost:1313/blog/correctness/ - 2024-06-01T15:21:30-03:00 + https://o-santi.github.com/blog/ + 2024-06-01T17:29:17-03:00 - http://localhost:1313/blog/rust/ - 2024-06-01T15:21:30-03:00 + https://o-santi.github.com/tags/correctness/ + 2024-06-01T17:29:17-03:00 - http://localhost:1313/rust-is-not-about-memory-safety/ - 2024-06-01T15:21:30-03:00 + https://o-santi.github.com/ + 2024-06-01T17:29:17-03:00 - http://localhost:1313/about/ - 2024-06-01T12:12:47-03:00 + https://o-santi.github.com/tags/rust/ + 2024-06-01T17:29:17-03:00 - http://localhost:1313/ - 2024-06-01T10:31:58-03:00 + https://o-santi.github.com/blog/rust-is-not-about-memory-safety/ + 2024-06-01T17:29:17-03:00 diff --git a/public/tags/correctness/index.html b/public/tags/correctness/index.html new file mode 100644 index 0000000..9e25c80 --- /dev/null +++ b/public/tags/correctness/index.html @@ -0,0 +1,272 @@ + + + + + + + +correctness | lowest case + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ + +

filtering for "correctness"

+ + remove filter + + + + + + + +
+ + + + + + diff --git a/public/tags/correctness/index.xml b/public/tags/correctness/index.xml new file mode 100644 index 0000000..765db57 --- /dev/null +++ b/public/tags/correctness/index.xml @@ -0,0 +1,19 @@ + + + + correctness on lowest case + https://o-santi.github.com/tags/correctness/ + Recent content in correctness on lowest case + Hugo + en-US + Sat, 01 Jun 2024 17:29:17 -0300 + + + rust is not about memory safety + https://o-santi.github.com/blog/rust-is-not-about-memory-safety/ + Sat, 01 Jun 2024 17:29:17 -0300 + https://o-santi.github.com/blog/rust-is-not-about-memory-safety/ + most of rust discussions nowadays revolve about memory safety, and how it is safer than C / C++ / zig / go / whatever language is being trashed on twitter that day. while yes, that is true - not that the bar for most of these is particularly high - what I think is the main point of the language is always glossed over: correctness. when one tries to criticize any of the aforementioned languages, one is answered with the following argument: + + + diff --git a/public/tags/rust/index.html b/public/tags/rust/index.html new file mode 100644 index 0000000..0fce287 --- /dev/null +++ b/public/tags/rust/index.html @@ -0,0 +1,272 @@ + + + + + + + +rust | lowest case + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ + +

filtering for "rust"

+ + remove filter + + + + + + + +
+ + + + + + diff --git a/public/tags/rust/index.xml b/public/tags/rust/index.xml new file mode 100644 index 0000000..bf11a4d --- /dev/null +++ b/public/tags/rust/index.xml @@ -0,0 +1,19 @@ + + + + rust on lowest case + https://o-santi.github.com/tags/rust/ + Recent content in rust on lowest case + Hugo + en-US + Sat, 01 Jun 2024 17:29:17 -0300 + + + rust is not about memory safety + https://o-santi.github.com/blog/rust-is-not-about-memory-safety/ + Sat, 01 Jun 2024 17:29:17 -0300 + https://o-santi.github.com/blog/rust-is-not-about-memory-safety/ + most of rust discussions nowadays revolve about memory safety, and how it is safer than C / C++ / zig / go / whatever language is being trashed on twitter that day. while yes, that is true - not that the bar for most of these is particularly high - what I think is the main point of the language is always glossed over: correctness. when one tries to criticize any of the aforementioned languages, one is answered with the following argument: + + + diff --git a/themes/hugo-bearblog b/themes/hugo-bearblog deleted file mode 160000 index efc24bc..0000000 --- a/themes/hugo-bearblog +++ /dev/null @@ -1 +0,0 @@ -Subproject commit efc24bc5e95f0ccb88051e1a7d95e8a1404e953e diff --git a/themes/hugo-bearblog/.gitignore b/themes/hugo-bearblog/.gitignore new file mode 100644 index 0000000..3c3629e --- /dev/null +++ b/themes/hugo-bearblog/.gitignore @@ -0,0 +1 @@ +node_modules diff --git a/themes/hugo-bearblog/.jsbeautifyrc b/themes/hugo-bearblog/.jsbeautifyrc new file mode 100644 index 0000000..4e39ba0 --- /dev/null +++ b/themes/hugo-bearblog/.jsbeautifyrc @@ -0,0 +1,27 @@ +{ + "indent_size": 2, + "indent_char": " ", + "indent_with_tabs": false, + "editorconfig": false, + "eol": "\n", + "end_with_newline": true, + "indent_level": 0, + "preserve_newlines": true, + "max_preserve_newlines": 10, + "space_in_paren": false, + "space_in_empty_paren": false, + "jslint_happy": false, + "space_after_anon_function": false, + "space_after_named_function": false, + "brace_style": "collapse", + "unindent_chained_methods": false, + "break_chained_methods": false, + "keep_array_indentation": false, + "unescape_strings": false, + "wrap_line_length": 0, + "e4x": false, + "comma_first": false, + "operator_position": "before-newline", + "indent_empty_lines": false, + "templating": ["auto"] +} diff --git a/themes/hugo-bearblog/LICENSE b/themes/hugo-bearblog/LICENSE new file mode 100644 index 0000000..3be3bb7 --- /dev/null +++ b/themes/hugo-bearblog/LICENSE @@ -0,0 +1,20 @@ +The MIT License (MIT) + +Copyright (c) 2020 Jan Raasch + +Permission is hereby granted, free of charge, to any person obtaining a copy of +this software and associated documentation files (the "Software"), to deal in +the Software without restriction, including without limitation the rights to +use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of +the Software, and to permit persons to whom the Software is furnished to do so, +subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS +FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR +COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER +IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. diff --git a/themes/hugo-bearblog/README.md b/themes/hugo-bearblog/README.md new file mode 100644 index 0000000..ab0a75e --- /dev/null +++ b/themes/hugo-bearblog/README.md @@ -0,0 +1,86 @@ +# Hugo ʕ•ᴥ•ʔ Bear Blog ![Test](https://github.com/janraasch/hugo-bearblog/workflows/CI/badge.svg?branch=master&event=push) + +🧸 A [Hugo](https://gohugo.io/)-theme based on [Bear Blog](https://bearblog.dev). + +> Free, no-nonsense, super-fast blogging. + +## Demo + +For a current & working demo of this theme, please check out https://janraasch.github.io/hugo-bearblog/ 🎯. + +## Screenshots + +⬜️ [Light][light-screenshot] + +⬛️ [Dark][dark-screenshot] + +When the user's browser is running »dark mode«, the dark color scheme will be used automatically. The default is the light/white color scheme. Check out the [`style.html`](https://github.com/janraasch/hugo-bearblog/blob/master/layouts/partials/style.html)-file for the implementation. + +## Installation + +If you already have a Hugo site on your machine, you can simply add this theme via + +```bash +git submodule add https://github.com/janraasch/hugo-bearblog.git themes/hugo-bearblog +``` + +Then, adjust the `hugo.toml` as detailed below. + +For more information, read the official [setup guide][hugo-setup-guide] of Hugo. + +## Adjust configuration / hugo.toml + +Please check out the [hugo.toml](https://github.com/janraasch/hugo-bearblog/blob/master/exampleSite/hugo.toml) included in the [exampleSite](https://github.com/janraasch/hugo-bearblog/tree/master/exampleSite) of this theme. + +## Content & structure + +### Starting fresh + +If you are starting fresh, simply copy over the contents of the `exampleSite`-directory included in this theme to your source directory. That should give you a good idea about how things work, and then you can go on from there to make the site your own. + +### Adding / editing content + +#### Index-Page + +The contents of the `index`-page may be changed by editing your `content/_index.md`-file. + +#### Page + +You can add **a new page** via running + +```bash +hugo new my-new-page.md +``` + +#### Blog-Post + +You can add **a new blog-post** via running + +```bash +hugo new blog/my-new-post.md +``` + +### Adding your branding / colors / css + +Add a `custom_head.html`-file to your `layouts/partials`-directory. In there you may add a ` diff --git a/themes/hugo-bearblog/layouts/robots.txt b/themes/hugo-bearblog/layouts/robots.txt new file mode 100644 index 0000000..0326f5c --- /dev/null +++ b/themes/hugo-bearblog/layouts/robots.txt @@ -0,0 +1,2 @@ +User-Agent: * +Sitemap: {{ "sitemap.xml" | absURL }} diff --git a/themes/hugo-bearblog/package-lock.json b/themes/hugo-bearblog/package-lock.json new file mode 100644 index 0000000..7a248e9 --- /dev/null +++ b/themes/hugo-bearblog/package-lock.json @@ -0,0 +1,430 @@ +{ + "name": "hugo-bearblog", + "version": "1.0.0", + "lockfileVersion": 1, + "requires": true, + "dependencies": { + "@isaacs/cliui": { + "version": "8.0.2", + "resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz", + "integrity": "sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==", + "dev": true, + "requires": { + "string-width": "^5.1.2", + "string-width-cjs": "npm:string-width@^4.2.0", + "strip-ansi": "^7.0.1", + "strip-ansi-cjs": "npm:strip-ansi@^6.0.1", + "wrap-ansi": "^8.1.0", + "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0" + }, + "dependencies": { + "ansi-regex": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", + "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "dev": true + }, + "ansi-styles": { + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz", + "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==", + "dev": true, + "requires": { + "color-convert": "^2.0.1" + } + }, + "emoji-regex": { + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", + "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==", + "dev": true + }, + "string-width-cjs": { + "version": "npm:string-width@4.2.3", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", + "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dev": true, + "requires": { + "emoji-regex": "^8.0.0", + "is-fullwidth-code-point": "^3.0.0", + "strip-ansi": "^6.0.1" + }, + "dependencies": { + "strip-ansi": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, + "requires": { + "ansi-regex": "^5.0.1" + } + } + } + }, + "strip-ansi-cjs": { + "version": "npm:strip-ansi@6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, + "requires": { + "ansi-regex": "^5.0.1" + } + }, + "wrap-ansi-cjs": { + "version": "npm:wrap-ansi@7.0.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz", + "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==", + "dev": true, + "requires": { + "ansi-styles": "^4.0.0", + "string-width": "^4.1.0", + "strip-ansi": "^6.0.0" + }, + "dependencies": { + "string-width": { + "version": "4.2.3", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", + "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dev": true, + "requires": { + "emoji-regex": "^8.0.0", + "is-fullwidth-code-point": "^3.0.0", + "strip-ansi": "^6.0.1" + } + }, + "strip-ansi": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, + "requires": { + "ansi-regex": "^5.0.1" + } + } + } + } + } + }, + "@one-ini/wasm": { + "version": "0.1.1", + "resolved": "https://registry.npmjs.org/@one-ini/wasm/-/wasm-0.1.1.tgz", + "integrity": "sha512-XuySG1E38YScSJoMlqovLru4KTUNSjgVTIjyh7qMX6aNN5HY5Ct5LhRJdxO79JtTzKfzV/bnWpz+zquYrISsvw==", + "dev": true + }, + "@pkgjs/parseargs": { + "version": "0.11.0", + "resolved": "https://registry.npmjs.org/@pkgjs/parseargs/-/parseargs-0.11.0.tgz", + "integrity": "sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==", + "dev": true, + "optional": true + }, + "abbrev": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-2.0.0.tgz", + "integrity": "sha512-6/mh1E2u2YgEsCHdY0Yx5oW+61gZU+1vXaoiHHrpKeuRNNgFvS+/jrwHiQhB5apAf5oB7UB7E19ol2R2LKH8hQ==", + "dev": true + }, + "ansi-regex": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.0.1.tgz", + "integrity": "sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==", + "dev": true + }, + "ansi-styles": { + "version": "6.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-6.2.1.tgz", + "integrity": "sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==", + "dev": true + }, + "balanced-match": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", + "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", + "dev": true + }, + "brace-expansion": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", + "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "dev": true, + "requires": { + "balanced-match": "^1.0.0" + } + }, + "color-convert": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz", + "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==", + "dev": true, + "requires": { + "color-name": "~1.1.4" + } + }, + "color-name": { + "version": "1.1.4", + "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz", + "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==", + "dev": true + }, + "commander": { + "version": "10.0.1", + "resolved": "https://registry.npmjs.org/commander/-/commander-10.0.1.tgz", + "integrity": "sha512-y4Mg2tXshplEbSGzx7amzPwKKOCGuoSRP/CjEdwwk0FOGlUbq6lKuoyDZTNZkmxHdJtp54hdfY/JUrdL7Xfdug==", + "dev": true + }, + "config-chain": { + "version": "1.1.13", + "resolved": "https://registry.npmjs.org/config-chain/-/config-chain-1.1.13.tgz", + "integrity": "sha512-qj+f8APARXHrM0hraqXYb2/bOVSV4PvJQlNZ/DVj0QrmNM2q2euizkeuVckQ57J+W0mRH6Hvi+k50M4Jul2VRQ==", + "dev": true, + "requires": { + "ini": "^1.3.4", + "proto-list": "~1.2.1" + } + }, + "cross-spawn": { + "version": "7.0.3", + "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.3.tgz", + "integrity": "sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==", + "dev": true, + "requires": { + "path-key": "^3.1.0", + "shebang-command": "^2.0.0", + "which": "^2.0.1" + } + }, + "eastasianwidth": { + "version": "0.2.0", + "resolved": "https://registry.npmjs.org/eastasianwidth/-/eastasianwidth-0.2.0.tgz", + "integrity": "sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==", + "dev": true + }, + "editorconfig": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/editorconfig/-/editorconfig-1.0.4.tgz", + "integrity": "sha512-L9Qe08KWTlqYMVvMcTIvMAdl1cDUubzRNYL+WfA4bLDMHe4nemKkpmYzkznE1FwLKu0EEmy6obgQKzMJrg4x9Q==", + "dev": true, + "requires": { + "@one-ini/wasm": "0.1.1", + "commander": "^10.0.0", + "minimatch": "9.0.1", + "semver": "^7.5.3" + } + }, + "emoji-regex": { + "version": "9.2.2", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz", + "integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==", + "dev": true + }, + "foreground-child": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/foreground-child/-/foreground-child-3.1.1.tgz", + "integrity": "sha512-TMKDUnIte6bfb5nWv7V/caI169OHgvwjb7V4WkeUvbQQdjr5rWKqHFiKWb/fcOwB+CzBT+qbWjvj+DVwRskpIg==", + "dev": true, + "requires": { + "cross-spawn": "^7.0.0", + "signal-exit": "^4.0.1" + } + }, + "glob": { + "version": "10.3.10", + "resolved": "https://registry.npmjs.org/glob/-/glob-10.3.10.tgz", + "integrity": "sha512-fa46+tv1Ak0UPK1TOy/pZrIybNNt4HCv7SDzwyfiOZkvZLEbjsZkJBPtDHVshZjbecAoAGSC20MjLDG/qr679g==", + "dev": true, + "requires": { + "foreground-child": "^3.1.0", + "jackspeak": "^2.3.5", + "minimatch": "^9.0.1", + "minipass": "^5.0.0 || ^6.0.2 || ^7.0.0", + "path-scurry": "^1.10.1" + } + }, + "ini": { + "version": "1.3.8", + "resolved": "https://registry.npmjs.org/ini/-/ini-1.3.8.tgz", + "integrity": "sha512-JV/yugV2uzW5iMRSiZAyDtQd+nxtUnjeLt0acNdw98kKLrvuRVyB80tsREOE7yvGVgalhZ6RNXCmEHkUKBKxew==", + "dev": true + }, + "is-fullwidth-code-point": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz", + "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==", + "dev": true + }, + "isexe": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz", + "integrity": "sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==", + "dev": true + }, + "jackspeak": { + "version": "2.3.6", + "resolved": "https://registry.npmjs.org/jackspeak/-/jackspeak-2.3.6.tgz", + "integrity": "sha512-N3yCS/NegsOBokc8GAdM8UcmfsKiSS8cipheD/nivzr700H+nsMOxJjQnvwOcRYVuFkdH0wGUvW2WbXGmrZGbQ==", + "dev": true, + "requires": { + "@isaacs/cliui": "^8.0.2", + "@pkgjs/parseargs": "^0.11.0" + } + }, + "js-beautify": { + "version": "1.15.1", + "resolved": "https://registry.npmjs.org/js-beautify/-/js-beautify-1.15.1.tgz", + "integrity": "sha512-ESjNzSlt/sWE8sciZH8kBF8BPlwXPwhR6pWKAw8bw4Bwj+iZcnKW6ONWUutJ7eObuBZQpiIb8S7OYspWrKt7rA==", + "dev": true, + "requires": { + "config-chain": "^1.1.13", + "editorconfig": "^1.0.4", + "glob": "^10.3.3", + "js-cookie": "^3.0.5", + "nopt": "^7.2.0" + } + }, + "js-cookie": { + "version": "3.0.5", + "resolved": "https://registry.npmjs.org/js-cookie/-/js-cookie-3.0.5.tgz", + "integrity": "sha512-cEiJEAEoIbWfCZYKWhVwFuvPX1gETRYPw6LlaTKoxD3s2AkXzkCjnp6h0V77ozyqj0jakteJ4YqDJT830+lVGw==", + "dev": true + }, + "lru-cache": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-6.0.0.tgz", + "integrity": "sha512-Jo6dJ04CmSjuznwJSS3pUeWmd/H0ffTlkXXgwZi+eq1UCmqQwCh+eLsYOYCwY991i2Fah4h1BEMCx4qThGbsiA==", + "dev": true, + "requires": { + "yallist": "^4.0.0" + } + }, + "minimatch": { + "version": "9.0.1", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.1.tgz", + "integrity": "sha512-0jWhJpD/MdhPXwPuiRkCbfYfSKp2qnn2eOc279qI7f+osl/l+prKSrvhg157zSYvx/1nmgn2NqdT6k2Z7zSH9w==", + "dev": true, + "requires": { + "brace-expansion": "^2.0.1" + } + }, + "minipass": { + "version": "7.0.4", + "resolved": "https://registry.npmjs.org/minipass/-/minipass-7.0.4.tgz", + "integrity": "sha512-jYofLM5Dam9279rdkWzqHozUo4ybjdZmCsDHePy5V/PbBcVMiSZR97gmAy45aqi8CK1lG2ECd356FU86avfwUQ==", + "dev": true + }, + "nopt": { + "version": "7.2.0", + "resolved": "https://registry.npmjs.org/nopt/-/nopt-7.2.0.tgz", + "integrity": "sha512-CVDtwCdhYIvnAzFoJ6NJ6dX3oga9/HyciQDnG1vQDjSLMeKLJ4A93ZqYKDrgYSr1FBY5/hMYC+2VCi24pgpkGA==", + "dev": true, + "requires": { + "abbrev": "^2.0.0" + } + }, + "path-key": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz", + "integrity": "sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==", + "dev": true + }, + "path-scurry": { + "version": "1.10.1", + "resolved": "https://registry.npmjs.org/path-scurry/-/path-scurry-1.10.1.tgz", + "integrity": "sha512-MkhCqzzBEpPvxxQ71Md0b1Kk51W01lrYvlMzSUaIzNsODdd7mqhiimSZlr+VegAz5Z6Vzt9Xg2ttE//XBhH3EQ==", + "dev": true, + "requires": { + "lru-cache": "^9.1.1 || ^10.0.0", + "minipass": "^5.0.0 || ^6.0.2 || ^7.0.0" + }, + "dependencies": { + "lru-cache": { + "version": "10.2.0", + "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-10.2.0.tgz", + "integrity": "sha512-2bIM8x+VAf6JT4bKAljS1qUWgMsqZRPGJS6FSahIMPVvctcNhyVp7AJu7quxOW9jwkryBReKZY5tY5JYv2n/7Q==", + "dev": true + } + } + }, + "proto-list": { + "version": "1.2.4", + "resolved": "https://registry.npmjs.org/proto-list/-/proto-list-1.2.4.tgz", + "integrity": "sha512-vtK/94akxsTMhe0/cbfpR+syPuszcuwhqVjJq26CuNDgFGj682oRBXOP5MJpv2r7JtE8MsiepGIqvvOTBwn2vA==", + "dev": true + }, + "semver": { + "version": "7.6.0", + "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.0.tgz", + "integrity": "sha512-EnwXhrlwXMk9gKu5/flx5sv/an57AkRplG3hTK68W7FRDN+k+OWBj65M7719OkA82XLBxrcX0KSHj+X5COhOVg==", + "dev": true, + "requires": { + "lru-cache": "^6.0.0" + } + }, + "shebang-command": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz", + "integrity": "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==", + "dev": true, + "requires": { + "shebang-regex": "^3.0.0" + } + }, + "shebang-regex": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz", + "integrity": "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==", + "dev": true + }, + "signal-exit": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.1.0.tgz", + "integrity": "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==", + "dev": true + }, + "string-width": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz", + "integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==", + "dev": true, + "requires": { + "eastasianwidth": "^0.2.0", + "emoji-regex": "^9.2.2", + "strip-ansi": "^7.0.1" + } + }, + "strip-ansi": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", + "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", + "dev": true, + "requires": { + "ansi-regex": "^6.0.1" + } + }, + "which": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz", + "integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==", + "dev": true, + "requires": { + "isexe": "^2.0.0" + } + }, + "wrap-ansi": { + "version": "8.1.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-8.1.0.tgz", + "integrity": "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==", + "dev": true, + "requires": { + "ansi-styles": "^6.1.0", + "string-width": "^5.0.1", + "strip-ansi": "^7.0.1" + } + }, + "yallist": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/yallist/-/yallist-4.0.0.tgz", + "integrity": "sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==", + "dev": true + } + } +} diff --git a/themes/hugo-bearblog/package.json b/themes/hugo-bearblog/package.json new file mode 100644 index 0000000..b8cd943 --- /dev/null +++ b/themes/hugo-bearblog/package.json @@ -0,0 +1,28 @@ +{ + "name": "hugo-bearblog", + "private": true, + "version": "1.0.0", + "description": "🧸 A [Hugo](https://gohugo.io/)-theme based on [Bear Blog](https://bearblog.dev).", + "main": "index.js", + "devDependencies": { + "js-beautify": "^1.15.1" + }, + "scripts": { + "test": "npm run beautify", + "beautify": "js-beautify layouts/**/*.html -r" + }, + "repository": { + "type": "git", + "url": "git+https://github.com/janraasch/hugo-bearblog.git" + }, + "author": { + "name": "Jan Raasch", + "email": "jan@janraasch.com", + "url": "https://www.janraasch.com" + }, + "license": "MIT", + "bugs": { + "url": "https://github.com/janraasch/hugo-bearblog/issues" + }, + "homepage": "https://github.com/janraasch/hugo-bearblog#readme" +} diff --git a/themes/hugo-bearblog/theme.toml b/themes/hugo-bearblog/theme.toml new file mode 100644 index 0000000..066e67a --- /dev/null +++ b/themes/hugo-bearblog/theme.toml @@ -0,0 +1,25 @@ +# theme.toml template for a Hugo theme +# See https://github.com/gohugoio/hugoThemes#themetoml for an example + +name = "Hugo Bear Blog" +license = "MIT" +licenselink = "https://github.com/janraasch/hugo-bearblog/blob/master/LICENSE" +description = "A Hugo theme based on »Bear Blog«. Free, no-nonsense, super-fast blogging. »Bear Blog« now includes a dark color scheme to support dark mode!" +homepage = "https://github.com/janraasch/hugo-bearblog" +demosite = "https://janraasch.github.io/hugo-bearblog/" +tags = ["blog", "responsive", "minimal", "seo", "clean", "simple", "light", "minimalist", "mobile", "fast", "white", "minimalistic", "reading", "dark mode"] +features = ["favicon", "seo", "no stylesheets", "no javascript", "rss", "dark mode"] +min_version = "v0.110.0" +# https://gohugo.io/content-management/taxonomies#default-taxonomies +# https://gohugo.io/templates/taxonomy-templates/#example-list-tags-in-a-single-page-template +# https://gohugo.io/templates/taxonomy-templates/#example-list-all-site-tags + +[author] + name = "Jan Raasch" + homepage = "https://www.janraasch.com" + +# If porting an existing theme +[original] + name = "ʕ•ᴥ•ʔ Bear Blog" + homepage = "https://bearblog.dev" + repo = "https://github.com/HermanMartinus/bearblog" -- cgit v1.2.3