This has come up a few times recently, so a little note:

/./ will match any character—except a newline.

/[\s\S]/, /[\w\W]/ and so forth are the only way to portably match every character including newlines.

what about /./m?

/./m does not match a newline (usually—see below).

The m modifier does not alter . in any way (usually—see below).

m changes what ^ and $ match—normally they’ll match only the start and end of the string, but m alters them to also match the start and end of any line, i.e. immediately after and prior a newline.

Mnemonic: m for “multiline”.

what about /./s?

Yes, that will do what you want—unless you’re using Ruby or JavaScript.

In Ruby, the s modifier is inexplicably unused—in 1.8, it stays on the Regexp object, but in no way affects matching, and in 1.9, it doesn’t even stay on the object, it just disappears. Note that these behaviours are different to using a complete nonsense modifier, like f, which causes a SyntaxError¹.

Even more inexplicable, this feature has been rolled into m instead! So in Ruby, you can use /./m to match a newline, and you can also use /^a/m to match an a at the beginning of the string, or after any newline in the string.

In JavaScript, the s modifier is absent entirely, and it’s not rolled into anything else. Use /[\s\S]/.

Mnemonic: s for “single line” (the string is treated as one line, in a twisted sense).

conclusion

Yay, regular expressions. Be sure what you mean.

To match any character including newlines:

• In JavaScript or any other language lacking the s modifier, use /[\s\S]/.
• In Ruby, use /./m, but be aware that this also modifies ^ and $. If unsure, use /[\s\S]/.
• If you have true PCREs, you may safely use /./s.

Note that this is often what you really want—rarely do you want to explicitly match every character except newlines. If you do that on purpose, at least leave a comment to that effect, otherwise your coworkers will just assume you didn’t know what you were doing.

1. Or just gets thrown away if you use Regexp.new directly. ↩

Writers of all stripes enjoy engaging in the most cynical readings of human behavior because they think it makes them appear hyper-rational. But in fact here is a perfect example of how trying to achieve that makes you irrational. Human emotion is real. It is an observable phenomenon. It observably influences behavior. Therefore to fail to account for it when discussing coupling and relationships is the opposite of cold rationality; it is in fact a failure of empiricism.

L’Hote on Kate Bolick’s “All the Single Ladies”.

coworker: If it were a critical task, how long to get that UI up and running?
me: Probably about the same amount of time if it were non-critical, all things considered
me: Maybe a little longer
me: Stress tends to make tasks drag out

Reference.

An employee of the company who mantains Mongo, who appears to be assigned Erlang driver maintenance lately, seems to deduce that the tests fail¹, and so changes an API which has been stable for 2 years in order to “make the tests pass”, despite also changing the tests.

WAT.

1. they don’t. ↩

Practical Common LISP by Peter Seibel

My rating: 4 of 5 stars

Just what Common Lisp needed: a book that doesn’t bubble at the mouth, frothing over how every other language is attempting to be CL but failing; a book that doesn’t tell you how macros mean you can write EVERY LANGUAGE EVER in CL; a book that doesn’t tell you how CL’s macros are the best thing since sliced bread, then follow it up with totally shit examples of what macros are actually used for; a book that actually tours the standard library in a semi-sensical fashion, and covers practical things you might actually want to do, and in the meantime does a pretty decent justice to the rather large language that is Common Lisp.

In short, a rather good book, suitable for total beginners to Lisp and Common Lisp.

I found that it lost traction at times—sometimes it degenerated into a little bit of a reference, and you felt like you were reading a dictionary—but fairly quickly it recovered and had your attention again (while still being didactic). Similarly, the practicals in the last few chapters were almost too well-architected; I really just felt like I was building the target application, sort of learning the techniques, but ultimately it wasn’t necessarily interesting.

Finally, the topics glossed over in the conclusion are probably more important to someone wanting to build real applications with Common Lisp (i.e. relating to “practical Common Lisp”) than some of the stuff that could probably be gleaned from an evening with the HyperSpec—finding libraries and deploying applications are two very big question marks for any Lisp developer. This is partly a result of developments in these areas being even more recent than the book (e.g. QuickLisp development began in 2010, after the book’s last copyright year of 2009).

All in all, an excellent introduction to the world of Common Lisp.