4 ms·

A few questions/notes from reading the post and looking at the repo: 1. Is the post trailing the repo, or vice-versa? This line in the README describes a diffe

A few questions/notes from reading the post and looking at the repo: 1. Is the post trailing the repo, or vice-versa? This line in the README describes a different command format and seems to suggest that {{}} caused trouble? https://github.com/codyd51/penpal/blob/4ff061b045aa447ac8976f581748387f36c1e28a/README.md?plain=1#L5 https://github.com/codyd51/penpal/blob/4ff061b045aa447ac8976... 2. Some of the code blocks, like the first `src/main.rs` block, link to divergent GH source. Is that coming from penpal in some way, or are you grafting that back on after somehow? (And if it's built in, is there a way to avoid/manage this divergence?) 3. The post and repo contradict on what `generate` does, and the post lets us dangle for a really long time before resolving it. The post says: "Let’s generate an executable representing our (tiny!) source tree so far." (and then shows a single-line code block with `{{generate}}`) The repo says: "When the `generate` command is used, the current state of every snippet is rendered into a source code tree." The last section of the article finally clarifies, but it'd be kind to be clear that generate creates only the source tree and note that you're grafting on a compile step separately that's outside of penpal's scope.

codyd51 3y ago
You're right, thank you for the thoughtful feedback. It's true that the blog post skims over the meaning of `generate` when introducing it, and that I'm doing a bit of extra work under the covers in this post. I thought keeping things light and interactive would help easing into the details, but it's true that the reader has to wait quite a long time to see what the preprocessor is doing exactly, and it's not clear until the end what exactly is going on. I'll add something in to signpost this a bit better. To answer your questions, the post is trailing the repo. I've uploaded the full source comprising this post here: https://github.com/codyd51/penpal-blog-post-preprocessed https://github.com/codyd51/penpal-blog-post-preprocessed. The code blocks link back to the Github source via a custom Hugo shortcode, and I currently need to maintain this by hand. While wrapping up this blog post, I added support for generating this shortcode via an extension to the `show` command. Here's what the penpal command to render a hotlinked code block looks like, in the source code of this blog post: https://github.com/codyd51/penpal-blog-post-preprocessed/blob/release/index-in.md?plain=1#L175-L177 https://github.com/codyd51/penpal-blog-post-preprocessed/blo... Here's what the shortcode generation for this looks like in penpal: https://github.com/codyd51/penpal/blob/release/penpal/render.py#L414-L417 https://github.com/codyd51/penpal/blob/release/penpal/render... I think it'd be really nice to maintain all of this automagically - it seems reasonable that the technical content being built up would frequently be hosted in a finished state somewhere!
- abathur 3y ago
  Thanks for the extra context. Nothing wrong with deferring unnecessary detail! The word "executable" implied it was also compiling, and that surprise sent me out from the text to confirm I was understanding (since I hadn't seen any hint that you were telling it how to do so). Anticipating the question should (imo) be enough. It's a tricky corner that could definitely use better tooling. I mentioned my own make-based solution in another comment, and it's definitely something I keep having to iterate on as I spot different needs.

codyd51 3y ago

You're right, thank you for the thoughtful feedback. It's true that the blog post skims over the meaning of `generate` when introducing it, and that I'm doing a bit of extra work under the covers in this post. I thought keeping things light and interactive would help easing into the details, but it's true that the reader has to wait quite a long time to see what the preprocessor is doing exactly, and it's not clear until the end what exactly is going on. I'll add something in to signpost this a bit better. To answer your questions, the post is trailing the repo. I've uploaded the full source comprising this post here: https://github.com/codyd51/penpal-blog-post-preprocessed https://github.com/codyd51/penpal-blog-post-preprocessed. The code blocks link back to the Github source via a custom Hugo shortcode, and I currently need to maintain this by hand. While wrapping up this blog post, I added support for generating this shortcode via an extension to the `show` command. Here's what the penpal command to render a hotlinked code block looks like, in the source code of this blog post: https://github.com/codyd51/penpal-blog-post-preprocessed/blob/release/index-in.md?plain=1#L175-L177 https://github.com/codyd51/penpal-blog-post-preprocessed/blo... Here's what the shortcode generation for this looks like in penpal: https://github.com/codyd51/penpal/blob/release/penpal/render.py#L414-L417 https://github.com/codyd51/penpal/blob/release/penpal/render... I think it'd be really nice to maintain all of this automagically - it seems reasonable that the technical content being built up would frequently be hosted in a finished state somewhere!

abathur 3y ago
Thanks for the extra context. Nothing wrong with deferring unnecessary detail! The word "executable" implied it was also compiling, and that surprise sent me out from the text to confirm I was understanding (since I hadn't seen any hint that you were telling it how to do so). Anticipating the question should (imo) be enough. It's a tricky corner that could definitely use better tooling. I mentioned my own make-based solution in another comment, and it's definitely something I keep having to iterate on as I spot different needs.