lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

142
hpr_transcripts/hpr2139.txt Normal file
View File

@@ -0,0 +1,142 @@
Episode: 2139
Title: HPR2139: From Org Mode to LaTeX Beamer to PDF
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2139/hpr2139.mp3
Transcribed: 2025-10-18 14:48:40
---
This is HPR episode 2,139 entitled, from Audemode to the TXMata PDF.
It is hosted by Clinton Roy and is about 8 minutes long.
The summary is, My Prementation Pipeline.
This episode of HPR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the offer code HPR15, that's HPR15.
Better web hosting that's honest and fair, at AnanasThost.com.
From Audemode to LatekBema to PDF.
I have recently been fortunate enough to give a presentation to two conferences,
Pike on Australia and KiwiPike on, the Australian and New Zealand Python conferences, respectively.
I'm not going to give a talk based around the presentation, as it's rather code heavy,
and we know that that doesn't translate well to an audio medium.
Instead, what I wanted to do was to talk a little bit about the presentation pipeline
that I used to prepare this talk.
The input is a plain text file, edited in EMAX, using a mode called org mode.
The intermediate form is a Latek file, using the document class Bema,
which is designed for presentations that are going to be projected.
Bema is apparently the German word for digital projector.
The final output form is a plain PDF.
HPR isn't known for having many EMAX talks, so I should probably explain the idea of modes.
EMAX has major modes and minor modes.
For every document that you're editing, there's one major mode and any number of minor modes.
So if I was editing a Python file, for example,
I would have the Python major mode, which understands Python,
and can thus do Python-specific things, like Python code completion,
and I would have a spell check in minor mode to check the spelling of comments,
and another minor mode to automatically line-wrap comment lines that are very long,
and another minor mode to show what line number I'm currently editing,
and another minor mode to blink the cursor, and so on.
The other topic that I haven't heard too much on is Latek.
Latek is the venimable type-setting solution for in-exface systems.
Latek documents have a single document class, and then any number of packages.
In the case of my presentation, the document class is Bema,
which sets up all margins and fonts to be good for presentations.
Some of the packages I'm using are the symbols package for arrows and math symbols,
and several graphics packages so that I can draw trees in my slides.
I'm fairly comfortable with Latek.
I could certainly write this presentation directly in Latek,
but I think there are some advantages in using alt mode to generate my Latek instead.
As the name suggests, alt mode is designed to be an organizational mode,
helping you write two-do lists and organized documents.
While the document is just a plain text document that you can read and write
with any text editor, the EMACs alt mode understands its own markup
and provides an outlining mode,
where you can hide and expand trees of bullet points.
The basic layout of a set of slides for presentation is a tree of bullet points,
where the top level bullet points are slides,
and the second level of bullet points are lists of information put into each slide.
Another markup that alt mode understands is that of codebox,
so that we can easily say this chunk of code is a Python block.
Alt mode understands how to export this Python code block as a separate file,
run it under Python, and can even insert the output of the program,
or the result of a function, back into the original document as a code output block.
The advantage of having just one file for my presentation,
versus one file for my presentation and separate files for each code block,
is that the code examples in my presentation never get out of sync
with the code that I'm actually running.
This style of programming, where the documentation is the primary document,
and the code files are generated secondary documents,
is the inverse of the typical way of programming,
where the code documents are the primary documents,
and the documentation, the secondary documents, are automatically generated.
This style of programming, where the primary document is documentation,
is called literate programming.
The process of creating the documentation, the PDF in my case, is called weaving.
The process of creating the code files is called tangling.
I really like having just one file to generate one PDF presentation file,
so I'm going to keep using this technique in the future.
Now, I have to admit that my presentation is not completely literate.
There are some bits of output in my presentation that are copied and pasted,
rather than automatically generated, so I've still got some work to do.
Down to brass tax.
The conventional file name extension for org mode files is .org.
The typical metadata you put in presentations are author, email, and title.
In mind, I've also added subtitle and institute.
Now, the interesting one here is institute.
For whatever reason, it's not a piece of metadata that org mode knows about,
but it's really easy to drop down into latex
and just use the latex institute command directly.
There's a metadata line that org mode understands called options.
I request that my presentation has a table of contents,
and that all the bullet points of level two become line items in that table of contents.
Then I'm straight into the slides.
Bullet points at the first level are converted to sections.
Bullet points at the second level are turned into slide headings,
and anything deeper than that are turned into the contents of that slide.
I have many code blocks, and I use options that specify what file this code block is tangled to,
and to leave the white space alone when the code block is exported,
as white space is critical to Python.
I also turn on an option that gets line numbers printed for the code blocks.
In a couple of places where I want to highlight certain areas of the code,
I add labels to the code.
Then, outside the code block, I can refer to the label,
and latex will replace this with the line number.
I think I'd prefer to do this referencing with highlighting or an arrow or something,
but I'm not sure I can do that.
Engineering is the process of dealing with trade-offs to get something done.
There are many trade-offs when writing code to solve a problem.
Writing code for slides has quite a different set of trade-offs.
You want code to be easy to read, in terms of using long variable names,
but you also need code blocks to contain as few lines as possible,
so that you can use a large font size on the projector,
and you also don't want to have to split an example across multiple slides if you can help it.
I'm also of the view that syntax highlighting is a waste of time.
It's just a pretty layer of obfuscation that the mind has to understand,
then drop in order to actually see the code.
This stance of mind was vindicated when several presenters with syntax highlighted code
realized on the day that the projected code was impossible to read,
due to the low contrast projectors used in a reasonably well lit room.
One feature that I would like to add is the ability to reveal new code.
It's quite common to have a code block, reveal a problem with it,
and display the same code block again,
but with a minor change that fixes the previously explained problem.
Ideally, the old code and the new code would be rendered differently,
but I don't think that's an option right now.
The other thing that I couldn't work out was how to run custom programs on my code blocks.
I was wanting to run the Python unit test program,
not the Python interpreter, and could not find a way to do that.
There's a single command to run inside EMAX to create the output PDF.
Metarex, org, beamer, export as PDF.
So overall, I'm very happy with this pipeline.
It lets me have a primary document with code snippets,
and it lets me have latex snippets wherever I like.
It's not perfect, but I'm hoping to find ways to improve it.
You've been listening to Hecker Public Radio at HeckerPublicRadio.org.
We are a community podcast network that release the shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing
to find out how easy it really is.
Hecker Public Radio was founded by the Digital Dove Pound and the Infonomicon Computer Club,
and is part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly,
leave a comment on the website or record a follow-up episode yourself,
unless otherwise stated.
Today's show is released under Creative Commons,
Attribution, ShareAlive, 3.0 license.