Some thoughts on testing parsers
I've been writing a parser lately. Since I am not completely crazy,this means that I've been writing tests for it too. This has naturallyleft me with some thoughts about testing one's parsers in ways thatdon't completely drive you up the wall.
(The disclaimer is that I've never tried to write a parser for aserious language. All of mine have been for relatively modest DSLs.)
First off, you really want to be able to serialize your parsedsyntax
An irritating and interesting su change from Ubuntu 12.04 to 14.04
In Ubuntu 12.04, the su manpage describes the -c option with thisminimal description:
- -c, --command COMMAND
- Specify a command that will be invoked by theshell using its -c [option].
In Ubuntu 14.04, the following note was added as well:
The executed command will have no controlling terminal. This optioncannot be used to execute interactive programs which need acontrolling TTY.
This change broke part of my customary environment. For years Ihave been
A challenge in new languages: learning to design good APIs
Working on a new Go project has once again illustrated to me that one of the subtle andtime-consuming parts about learning a new language is learning howdesign good APIs for your code. As traditional I've learned this bythrowing together a number of APIs and then realizing that they'reclumsy and awkward in various ways.
Every language has a collection of API idioms ranging from the smallscale to the large (and often some more idioms on how to documentyour APIs), and with them another collection
The fundamental problem that created su
There is a fundamental problem that su , sudo , and many othertools are used to try to solve. Actually there are two problems, but su only addresses the one so let's start with it.
The first problem is that you have the right to exercise all powerbut you do not normally want to exercise that power. Most of thetime you want to have no power and perhaps some of the time youmight like to have some focused power; this is primarily to limitthe scope of accidents and
Some ways to do sleazy duck typing in Go (from a Python perspective)
Normal duck typing in Go is straightforward;you define an interface type (if necessary) and then create somefull implementations of it. I can think of a number of ways toenable code reuse in the style of inheritance, none of which I'mgoing to ramble on about because I've never done this. But sometimesin Python we do what I'll call sleazy duck typing , where we aren'tactually a duck but we need to look enough like one to fool someother code.
On the Internet, weirdness is generally uncommon
One of the things that my exposure to SMTP daemons and SMTP'soddities has shown me vividly is that perhapssurprisingly, weirdness is uncommon on the practical Internet. Most clients and servers do the usual, common thing . Perhaps'almost all'. For example, SMTP may contain very dark corners butthese corners are also dank and unused, so dank and unused thatyour MTA may never encounter them.
(I can't find any trace of route addresses in 90 days of our mailgateway's
SMTP's crazy address formats didn't come from nowhere
Broadly speaking, SMTP addresses have two crazy things in them: routeaddresses and quoted local parts. Route addresses theoretically giveyou a way of specifying a chain of steps the message is supposed totake on its way to (or from) its eventual destination:
RCPT TO:<@a.ex.org,@barney:user@fred.dibney>
Quoted local parts allow you to use any random characters and charactersequences in the local mailbox name:
MAIL FROM:<"abney..
Why I don't like SMTP command parameters
Modern versions of SMTP have added something called 'commandparameters'. These extend the
MAIL FROMandRCPT TOcommandsto add optional parameters to communicate, for example, the roughsize of a message that is about to be sent (that's RFC 1870 ). On the surface these appearperfectly sensible and innocent:MAIL FROM:SIZE=99999 That is, the parameters are tacked on as 'NAME=VALUE' pairs afterthe address
My just-used Go logging idiom and why it is in fact wrong
I've just gotten through writing a Go package and command in whichI rolled my own logging. I know, I should probably master thestandard log package . But it seems tobe a constant that in every new language I fiddle around with Iwind up rolling my own logging for whatever reason. Fortunatelythis time I can not only tell you about my idiom but tell you whyit's wrong.
As you might guess from my entry on how
nilis sometimes notanil, the fundamental model is
Vi's composability antecedent (or one of them)
These days the venerable vi editor is getting a bunch of praise forits genuine and core innovation of composable commands, such as inMike Kozlowski's Why Atom Can't Replace Vim .I wholeheartedly support this; vi's command composability is amazingand powerful and I wish more programs used or even embraced theideas behind it (as far as I know, vi's basically the only editorthat's ever really done this).
But today I want to mention that vi's composability is not
Menu
![]()