We started producing shows as Today with a Techie on 2005-09-19, 15 years, 10 months, 22 days ago. Our shows are produced by listeners like you and can be on any topic that "are of interest to hobbyists". If you listen to HPR then please consider contributing one show a year. If you record your show now it could be released in 8 days.
Please help out tagging older shows !
When I originally wanted a unified error reporting on the server-side, I made one huge type that enumerated all the possible error cases that could be reported:
-- | Error codes for all errors returned by API
data ErrorCode
-- common error codes
= ResourceNotFound
| InsufficientRights
| FailedToParseDataInDatabase
-- errors specific to news
| SpecialEventHasAlreadyBeenResolved
| UnsupportedArticleType
| SpecialNewsExtractionFailed
| TriedToMakeChoiceForRegularArticle
-- errors specific to simulation state
| SimulationStatusNotFound
| DeltaTIsTooBig
| TurnProcessingAndStateChangeDisallowed
| SimulationNotOpenForCommands
| SimulationNotOpenForBrowsing
-- errors specific to people
| StatIsTooLow Text
| CouldNotConfirmDateOfBirth
| DateOfBirthIsInFuture
| FirstNameIsEmpty
| FamilyNameIsEmpty
| CognomenIsEmpty
| RegnalNumberIsLessThanZero
-- errors specific to new person creation
| AgeBracketStartIsGreaterThanEnd
| PersonCreationFailed
deriving (Show, Read, Eq)
Then I had some helper functions to turn any value of that type into a nice error message:
errorCodeToStatusCode :: ErrorCode -> Int
statusCodeToText :: Int -> ByteString
errorCodeToText :: ErrorCode -> Text
raiseIfErrors :: [ErrorCode] -> HandlerFor App ()
errorCodeToStatusCode was responsible for turning ErrorCode into http status code. For example StatIsTooLow "intrigue" would be 400. statusCodeToText would take this code and turn it into short error message given in http response. 400 would be Bad Request. errorCodeToText would give a bit more verbose explanation of what happened, StatIsTooLow "intrigue" would be mapped to "Stat intrigue is too low". Finally raiseIfErrors would take a list of ErrorCode and use these helper functions to turn them into a http response with correct status code, error message and json body detailing all errors that had happened:
[
{ code:
{ tag: "StatIsTooLow"
, contents: "intrique"
}
, error: "Stat intrigue is too low"
}
]
There’s two tags: code, which contains machine readable details about the error and error, which contains error message that can be shown to user.
While this worked fine, there was some problems with it. ErrorCode type was growing larger and larger and the module it was defined in was referred all over the codebase. Every time I added a new error message, all the modules that used error reporting had to be compiled and it was getting slow.
Breaking up the ErrorCode to smaller types and moving them to different modules would means less modules were going to built when I added a new error code. The problem was that raiseIfErrors :: [ErrorCode] -> HandlerFor App () wanted a list of ErrorCode and elements in a list have to be of same type.
I started by splitting ErrorCode to smaller types. Each of the smaller error types have automatically derived toJSON and fromJSON functions for serializing them to and from JSON:
data PersonCreationError =
StatIsTooLow Text
| CouldNotConfirmDateOfBirth
| DateOfBirthIsInFuture
| FirstNameIsEmpty
| FamilyNameIsEmpty
| CognomenIsEmpty
| RegnalNumberIsLessThanZero
deriving (Show, Read, Eq)
$(deriveJSON defaultOptions ''PersonCreationError)
That $(deriveJSON defaultOptions ''PersonCreationError) is template haskell call. Basically it invokes a deriveJSON function with PersonCreationError as parameter and compiles and splices the resulting code here. This is fast and easy way of generating ToJSON and FromJSON instances and avoiding having to write them by hand. It is very similar to how Lisp macros work.
Then I defined a type class, that has functions for getting a http status code and a error message that can be shown to user. statusCodeToText I could use as is, without any modifications:
class ErrorCodeClass a where
httpStatusCode :: a -> Int
description :: a -> Text
I have to have instance of ErrorCodeClass defined for each and every smaller error type. Here’s an excerpt of PersonCreationError showing how it would look like:
instance ErrorCodeClass PersonCreationError where
httpStatusCode = \case
StatIsTooLow _ -> 400
CouldNotConfirmDateOfBirth -> 500
...
description = \case
StatIsTooLow s ->
"Stat " ++ s ++ " is too low"
...
A little note: description = \case relies on lambda case extension. It is just a slightly different way of writing:
description d =
case d of
This allows me to turn values of these smaller error types into error messages that could be sent to the user.
The second part of the solution is to figure out a way to put values of these smaller error types into same list. If a list is of type [PersonCreationError], it can’t contain values of CommonError and vice versa. Creating a wrapper like:
data ECode a = ECode a
doesn’t work, because then I would have elements of type ECode PersonCreationError and ECode CommonError, which are of different type. What I need, is a way to wrap all these different types into a wrapper that loses the type of wrapped value. Another problem is that I need to place constraints on what kind of values can be wrapped. I need them to have instances for ErrorCodeClass (for getting error information) and ToJSON (for serializing them into JSON). There’s several ways of doing this, but I chose to use generalized algebraic data types (GADTs for short):
{-# LANGUAGE GADTs #-}
data ECode where
ECode :: (ErrorCodeClass a, ToJSON a) => a -> ECode
Now type ECode has one value constructor, also named to ECode, which takes one parameter a. a can be anything, as long as there’s ErrorCodeClass and ToJSON instances defined for it. Calling this constructor will return ECode. If you compare this with the previous definition of ECode, you’ll notice two major differences:
a is constrained to have specific type class instancesECode, not ECode aThe second part means that I can wrap different types into ECode and place them into a same list without problems. Type of that list is simply [ECode].
But having a list of error codes wrapped in ECode isn’t going to do much to us. We need to be able to turn them into http status code, text and list of error messages. Luckily we have a type class just for that:
instance ErrorCodeClass ECode where
httpStatusCode (ECode a) =
httpStatusCode a
description (ECode a) =
description a
httpStatusCode of ECode is httpStatusCode of the value ECode wraps. Similarly description of ECode is description of the wrapped value.
For turning ECode into JSON, I opted for hand written instance:
instance ToJSON ECode where
toJSON (ECode a) =
object [ "HttpCode" .= httpStatusCode a
, "FaultCode" .= toJSON a
, "ErrorDescription" .= description a
]
This gives me complete control over how I want to report errors to the client.
Final piece of the puzzle is raiseIfErrors function:
raiseIfErrors :: [ECode] -> HandlerFor App ()
raiseIfErrors errors = do
when (not $ null errors) $ do
let code = fromMaybe 500 $ errors ^? ix 0 . to httpStatusCode
let msg = statusCodeToText code
sendStatusJSON (Status code msg) $ toJSON errors
If there are any elements in the passed in list, grab the http status code and text from the first element of the list. I was considering writing some sort of logic to deduce which error code to return in case there are more than one type in the list, but decided against it. There doesn’t seem to be any easy way to decide between HTTP 400 Bad Request and HTTP 500 Internal Server Error. So I just return the first one. Body of the response contains list of errors codes:
[
{ HttpCode: 400
, FaultCode: {
Tag: "StatIsTooLow"
, Contents: "intrique"
}
, ErrorDescription: "Stat intrigue is too low"
}
]
Since manually wrapping things in ECode gets tedious after a while, I defined function for each type of error that does that for me:
statIsTooLow :: Text -> ECode
statIsTooLow s = ECode $ StatIsTooLow s
Now, instead of writing ECode $ StatIsTooLow "intrigue", I can write statIsTooLow "intrigue". And if I ever decide to change internals of errors again, I can change how these functions are defined and hopefully don’t have to change each and every place where they’re being used.
Another way to tackle this problem is to use records instead of algebraic data types:
data ECode = ECode
{ httpCode :: Int
, description :: Text
}
statIsTooLow :: Text -> ECode
statIsTooLow s =
ECode
{ httpCode = 400
, description = "Stat " ++ s ++ " is too low"
}
Hosted by HPR Volunteers on 2021-08-02 is flagged as Explicit and released under a CC-BY-SA license.
Tags: Community News.
Listen in ogg, spx, or mp3 format.
Series: HPR Community News | Comments (0)
There were no new hosts this month.
These are comments which have been made during the past month, either to shows released during the month or to past shows. There are 18 comments in total.
There are 5 comments on 3 previous shows:
There are 13 comments on 8 of this month's shows:
Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mail List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman.
The threaded discussions this month can be found here:
http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/2021-July/thread.htmlWith the kind permission of LWN.net we are linking to The LWN.net Community Calendar.
Quoting the site:
This is the LWN.net community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page.
This month 35 additional shows in the range 1-870 have been uploaded.
Since we don't want to upload shows without summaries or tags the old shows and tag and summary projects are now tied together. So we will be all the more welcoming of tag and summary updates submitted as described on the summary page.
Thanks to the following contributors for sending in updates in the past month:
Archer72, Rho`n, Dave Morriss
Over the period tags and/or summaries have been added to 71 shows which were without them.
There are currently 222 shows which need a summary and/or tags.
If you would like to contribute to the tag/summary project visit the summary page at https://hackerpublicradio.org/report_missing_tags.php and follow the instructions there.
Hosted by Ahuka on 2021-07-30 is flagged as Clean and released under a CC-BY-SA license.
Tags: DOS, early PC computing.
Listen in ogg, spx, or mp3 format.
Series: DOS | Comments (2)
This Introduction to the series also serves as a brief recap of my early history with computers, and the path that brought me to where I am today.
Hosted by Archer72 on 2021-07-29 is flagged as Clean and released under a CC-BY-SA license.
Tags: tags,mplayer,Android,Termux,vim,i3 window manager.
Listen in ogg, spx, or mp3 format.
Comments (0)
https://hackerpublicradio.org/report_missing_tags.php
Please send simple ASCII email. No HTML please, and no multipart, encrypted or signed messages; the script can't handle them at the moment! (We are working on a solution to some of this though). Remember, the internals of an email are complex and the script isn't clever enough to deal with all the many possible formats. Please be gentle with it!
Format the message as follows:
show:12345
summary:Using Linux at Christmas to make tomato soup in a sporran
tags:linux,christmas,sporran,tomato soup
show: 12346
tags: sausage,clothing,hairpieceUpdates will be processed with a script, which is run manually, and this page will be refreshed once the changes have been made. The timestamp above shows when it was last refreshed.
Play audio file faster without pitch increase
https://kenfallon.com/speeding-up-speech-with-mplayer
{ key will slow down by 50% of the current rate
[ key will slow down by 10% of the current rate
Backspace will return the speed to normal
] key will speed up 10% of the current rate
} key will speed up by 50% of the current rate
9 key will decrease the volume
0 key will increase the volume
alias mplayer='mplayer -af scaletempo'
In this episode our aging heroes host the Free Software Foundation Europe (FSFE). Its president, Matthias Kirschner talk about the past, the present and the future of free and open source software not only from an FSFE perspective. Never mind how he got into computers in the first place. Also, different opinions about communism in general and its implementations (and the flaws of the first rounds of implementations) are touched upon. So historians, FLOSS users and enthusiasts, communists and free spirits: This is your episode! Plus: Ever wondered what the Towel Day is all about? Check out the second half of the episode! At our guest's request: Please note that this episode was recorded on June 1st 2021.
Inoffensive in every region of the world.
Thank you to everyone who has listened to my previous episodes. I hope I am not boring you all to death!
Why am I recording this series?
Because there are so many podcasts to list, I have broken them down into 6 different episodes based on topics:
Malicious Life Ran Levi sponsored by Cybereason (Periodically)
Darknet Diaries - Jack Rhysider (Bi-Weekly)
Digital Forensic Survival Podcast - Michael Leclair (Weekly)
The Offensive Security Podcast - TJ Null and Jeremy Miller (Harbinger) and sponsored by Offensive Security (Creators of the OSCP Offensive Security Certified Professional certification)
Command Line Heroes - Saron Yitbarek and sponsored by Red Hat (Weekly with gaps between seasons)
Beers with Talos - Mitch Neff, Craig Williams, Joel Esler, Matt Olney all part of Cisco Talos Research Center (Periodically)
I hope that this series has helped introduce you to some new and interesting listening options. Give some of them a try, and I would love to get your feedback in the episode comments on the HPR website.
The next and final episode of this series will be about Information Security Leadership podcasts.
Thank you for listening.
Hosted by Dave Morriss on 2021-07-26 is flagged as Explicit and released under a CC-BY-SA license.
Tags: Perl,SQLite3,database,food.
Listen in ogg, spx, or mp3 format.
Comments (0)
I live on my own, but I cook for members of my family from time to time. Each week we all get together and cook dinner for Wednesday and Thursday. I usually do the cooking but we are starting to share these duties for certain meals.
In 2019 I thought it would be useful if I had some sort of random chooser to decide what next week’s meal was going to be. I wrote a Bash script called choose_meal, using a simple CSV file of meal names and the date last eaten to avoid choosing the same one too often. The shortcomings of this approach soon became apparent!
It wasn’t long before choose_meal was rewritten in Perl. This time I decided to use a database, and chose SQLite to create it. My database contained just two tables, one for the meals themselves (called slightly confusingly 'meal_history'), and another for a record of the choices made (called 'meal_log') – the ability to produce historical reports seemed like a desirable feature!
In 2019 the design of this system was very specific to our needs: one choice per week on a Wednesday. It was not something that could be used by anyone else – which seemed like a bad idea.
In late 2020 and early 2021 the system was redesigned, as will be discussed in the detailed notes. In May 2021 a more general design was added to the public GitLab repository and the preparation of this show was begun.
I had never intended this system to hold recipes. This was partly because I have built a collection of recipes I have constructed from various sources and amended as I have made them. I print these and keep them in a ring-binder for reference as I cook. In some cases the meals described in the database are multi-component ones (such as the dishes that make up a curry for example), so it doesn’t seem appropriate to hold these here.
I might rethink this in the future however.
Follow this link to read the detailed notes associated with this episode.
SQLite: a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine.
In this episode operat0r builds a cat feeder based on thingiverse.com
Hosted by Jon Kulp on 2021-07-22 is flagged as Clean and released under a CC-BY-SA license.
Tags: ebooks, epub, scripting, calibre.
Listen in ogg, spx, or mp3 format.
Comments (0)
This episode is a response to hpr3367 by Andrew Conway and Dave Morriss. One of the topics they brought up was the thorny issue of page numbers in e-books. Most of the time you don't need to worry about page numbers in ebooks, if you're reading fiction for example. The whole point of an ebook is that the texts can reflow to fit the page no matter what size the screen is or what font-size you've chosen. This is a major accessibility feature of all e-book formats. One reason you might want to specify actual page numbers, though, is if you're dealing with a technical or academic book, and you need to be able to refer to specific passages in the book by page number, as you are expected to do in academic research. Or, as Andrew and Dave were discussing, you might need to create an index in your ebook that would send your readers back to specific pages like in a paper book.
I've thought about this before but never really gotten into the weeds and figured out how to make it happen. In fact, when I was creating the new digital editions of the Counterpoint textbooks like I discussed in hpr1512, I actually took the trouble to put page number anchors through the entire thing, so that at a future date I would be able to enable real page numbers. This was a key part of the source file's infrastructure, which helped me quickly find the passages I was working on in my huge HTML file. Those anchors are not quite in the correct format for EPUB, but they are consistent and I will easily be able to write a script to fix them. I haven't done that yet, but now that I figured out how to do it on some smaller examples, this is on my to-do list.
Anyway while I was listening to Dave and Andrew talk about this, I thought I remembered reading somewhere that in the newest ePub specification, EPUB 3, there was support for publisher's page numbers to deal with precisely this issue. Their discussion prompted me to see if I could make it work. I'm happy to report success, although with some qualifications, which I will get into.
The first thing to do is to upgrade your ebook from EPUB2 to EPUB3. There are a couple of ways to do this. The way I did it was to use the ebook editor in a recent version of Calibre. When you open up the EPUB for editing, go to the Tools menu and choose Upgrade book internals. This will create the new navigation file nav.xhtml to replace the old toc.ncx file. You'll need to edit this new file later to enable the page numbers.
Next you need to put your page anchors in there. This could be very tedious if you haven't done any preparatory work, such as putting visible page numbers in plain sight in square brackets [21] the way I did for a couple of ebooks. It wasn't very elegant, but at least it was easy to find where the page breaks were. I have a Blather voice command that triggers a python script to create these things. Here's an example of page number anchor, which goes in the main text of the book wherever you want to insert a page number. This will not be visible to the reader inline. This is for page 57:
<span epub:type="pagebreak" id="page57" title="57"></span>
Finally you need to put a page list in the new navigation file. This is simply an ordered list with hyperlinks to every page anchor that you put in your ebook. This will not be visible to the reader, but it's critical to making everything work. Here's a minimal example from my first attempt. This only covers Pages 122 to 126. This is the kind of page numbering you might need if you created an ebook from a five-page article from an academic journal that appeared in the middle of the volume.
<nav epub:type="page-list" hidden="hidden">
<ol>
<li><a href="filename.html#page122">122</a></li>
<li><a href="filename.html#page123">123</a></li>
<li><a href="filename.html#page124">124</a></li>
<li><a href="filename.html#page125">125</a></li>
<li><a href="filename.html#page126">126</a></li>
</ol>
</nav>
I'm not sure it matters where you put this navigation block in the nav.xhmtl file, but I put mine between the table of contents and the landmarks blocks.
It could be very tedious to create a page list like this, so of course I wrote a script to automate a lot of the heavy lifting. I'm sure Dave can write one that's more elegant than this, but this is what I came up with in about 5 minutes and it did the job, with the exception of putting the right URL for each link. I did a little bit of post-production to search and replace the URLs generated in the script with what I needed for the specific eBook. I think if you added a third command-line argument with a URL, you can solve this problem. The difficulty with larger books will be when you have more than one internal HTML file in the book, you will have to go through very carefully and make sure that the link goes to the correct file. I saved the script as pagelist.sh and put it in my $PATH.
Command to run to generate a page list from pages 42 to 61:
pagelist.sh 42 61
And here's the script:
#!/bin/bash # grab beginning and ending pages from 1st and 2nd # CLI arguments, and specify a tmp file to put stuff start="$1" end="$2" navfile=/tmp/navfile.txt # put the top matter for the nav block echo '<nav epub:type="page-list" hidden="hidden">' > $navfile echo " <ol>" >> $navfile # iterate through the page numbers making list item for each one. # should replace filename with your ebook's actual filename for i in $(seq $start $end); do echo " <li><a href=\"filename.html#page$i\">$i</a></li>" >> $navfile done # close out the list and nav block echo " </ol>" >> $navfile echo "</nav>" >> $navfile exit 0Then you just need to copy and paste what was generated from the script into your editor and make sure all of the URLs are correct, then stick that navigation block into the
nav.xhtml file.
So, once you have the page anchors and the page list in place in your EPUB3 ebook, everything should work. The problem is that so far the only ebook reader I have found that renders the page numbers correctly on the screen is the iBooks app on iOS. I tried it on my Kobo dedicated eReader, on the Marvin ePub reader on iOS and on Overdrive on Android, and none of them displayed my shiny page numbers. iBooks was the only one, but it did so perfectly after choosing "show publisher page numbers" on the table of contents menu. It was pretty magical. A quick internet search confirms that there is very little e-book reader or app support for displaying these page numbers.
However, the embedded page numbers will still be useful if what you want to do is create an index that directs readers back to specific pages. On the one hand, indexes are not as critical as they used to be because you can search through the text of e-books very easily. What you can't do easily is browse an eBook the way you can browse a paper book index to see what topics might catch your eye. This might be something only academics do. It's not uncommon for an academic to pick up a book and flip right to the bibliography and the index!
CPU on my Dell Latitude E6410 via sysctl: hw.model=Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
Get a full list of all our shows.