We started producing shows as Today with a Techie on 2005-09-19, 15 years, 10 months, 24 days ago. Our shows are produced by listeners like you and can be on any topic that "are of interest to Hackers". If you listen to HPR then please consider contributing one show a year. If you record your show now it could be released in 14 days.
Please help out tagging older shows !
See the layout of an XML document
$ xmlstarlet elements planets.xml
xml
xml/sol
xml/sol/planet
xml/sol/planet/name
xml/sol/planet/albedo
xml/sol/planet
xml/sol/planet/name
xml/sol/planet/albedo
xml/sol/planet
xml/sol/planet/name
xml/sol/planet/albedo
See content of the planet node
$ xmlstarlet select -t --value-of '/xml/sol/planet' planets.xml
Mercury
0.11
Venus
0.7
Terra
0.39
Get the third instance of the planet node
$ xmlstarlet select -t --value-of '/xml/sol/planet[3]' planets.xml
Terra
0.39
Get only the planets with an albedo greater than 0.25
$ xmlstarlet select -t --value-of '/xml/sol/planet[albedo > 0.25]' planets.xml
Venus
0.7
Terra
0.39
Get only the planets closer to Sol than the third planet
$ xmlstarlet select -t --value-of '/xml/sol/planet[position() < 3]' planets.xml
Mercury
0.11
Venus
0.7
Learn more XPath functions at Mozilla Developer Network.
Download xmlstarlet from xmlstarlet.sourceforge.net.
Klaatu introduces XML.
The sample XML document discussed in this episode is:
<xml>
<sol>
<planet>
<name>
Mercury
</name>
<albedo>
0.11
</albedo>
</planet>
<planet>
<name>
Venus
</name>
<albedo>
0.7
</albedo>
</planet>
<planet>
<name>
Terra
</name>
<albedo>
0.39
</albedo>
</planet>
</sol>
</xml>
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
Get a full list of all our shows.