They Never Learn

By now, most everyone has heard about the YouPorn Chat break in. John Graham-Cumming has the details. Due to very sloppy security YouPorn exposed the email addresses and passwords for many of their customers who signed up in 2008 and later. I’m guessing that there are a lot of very nervous spouses about now.

The story is actually a little worse than that according to Graham-Cumming. In addition to the email addresses at least some of the records included phone numbers, date of birth, username, and country. All of this information was in a plain text file. With no encryption. On a public server. How does this happen? Did Sony and the others teach these people nothing?

I suppose the good news for YouPorn Chat is that few, if any, of their customers will be inclined to anything public—like filing a law suit—about this and given the nature of their service, they may not even lose many customers. Still, there really is no excuse for this sort of behavior on the part of Web services and all it takes is one angry, single, customer to take these guys to the cleaners. If that happens, it will be hard to avoid the schadenfreude.

Posted in General | Tagged | Leave a comment

Site Outage

My hosting provider has informed me that Irreal.org will be down for maintenance from 12:01 am to 4:00 am on February 25.

Posted in Administrivia | Leave a comment

The Solution To Piracy: Cartoon Version

A while ago I wrote a post on Paul Tassi’s Forbes article You Will Never Kill Piracy, and Piracy Will Never Kill You. That was a great article with many cogent arguments but if it was TL;DR for you, here’s the cartoon version.

Update Removed superfluous “that”.

Posted in General | Leave a comment

Using Emacs

Vincent Foley over at Occasionally sane has an interesting post entitled Why I Still Use Emacs. Foley lists the usual suspects (extensibility, Org Mode, GUI or CLI operation, excellent built-in documentation, configurability, Tramp, and all the other reasons we love Emacs) for his decision to forgo IDEs, such as Eclipse, in favor of Emacs.

One of the things I have found throughout my career is that serious programmers pretty much stick to one of two (arguably three) editors: Emacs or Vi(m), and on OS X, TextMate. When I see an engineer using one of those editors I can be pretty sure that they know more than a single language, care about their tools and take the time to optimize their work flow around those tools, and care about speed and making development as frictionless as possible. When I see someone using notepad or a similar abomination, I can be pretty sure the above does not apply.

Are there exceptions? Of course but I think the generalization is a good one. Sure, the guy in the next cubicle uses Emacs to program in Basic and not very well at that and the polyglot wizard on your team turns out to prefer Nano for reasons that no one can understand but

serious_programmer == uses {Emacs | Vim | TextMate}

is a pretty good first order approximation.

Interestingly, the users of those 3 editors sometimes switch but almost always to another editor on the list. I’m guilty of that myself having been a Vim user for many many years and then switching to Emacs as I started to do mostly Lisp and Scheme programming. Others near and dear to me started with Emacs and switched to Vim. Likewise, I’m sure a lot of programmers switch to TextMate when they start using a Mac. I’ve never heard of anyone switching from Emacs to Notepad though.

Do I think using Emacs/Vim/TextMate makes you a better programmer? Possibly but the more likely explanation is that a craftsman picks the best tools available. Do I think everyone should use one of those editors? Frankly, it’s hard to see why they wouldn’t but choosing an editor is like choosing a mate and others had best stay out of the matter. I remember the feeling of horror I had when a manager from long ago suggested we settle on a standard editor. Happily I and some of the other senior engineers were able to explain the facts of life in time to prevent a mass exodus.

I’d be interested in hearing if my experience matches that of my readers. Do you find that most serious programmers use the Emacs/Vim/TextMate? Do you disagree with that observation for some reason other than hurt feelings? If so, leave a comment.

Posted in General | Tagged | 10 Comments

Lisp In The Debian Distribution

This is interesting and sort of surprising. James Bromberger over at JEB’s Blog takes a look at Debian’s forthcoming Wheezy distribution and, among many other interesting facts, reports that Lisp is the 8th most popular language for developing the packages in the distribution.

It’s not like this means that Lisp is becoming the go to language but it is nice to know that it’s solidly represented.

Posted in General | Tagged | Leave a comment

Not Macros; Read

James Long has an interesting post up at his blog entitled Lisp: It’s Not About Macros, It’s About Read in which he argues that what makes Lisp so powerful is not really macros but the read function. The reason for this is that read is really a parser that converts an input stream into Lisp objects. For example in

ELISP> (read "(+ x 1)")
(+ x 1)

read takes the string "(+ x 1)" and turns it into the Lisp S-expression (+ x 1). That may seen like a distinction without a difference but consider

ELISP> (car (read "(+ x 1)"))
+

This is another example of code equaling data that we’ve discussed here so often. We’ve taken a piece of data, "(+ x 1)", and turned it into a bit of Lisp code.

Here’s a more substantive example taken from Long’s post and converted from Scheme to Elisp. Consider the two line function

(defun parse-defun (forms)
  (list 'fset (cons 'quote (list (cadr forms)))
        (cons 'lambda (cons (caddr forms) (cdddr forms)))))

When we apply it to a defun expression

ELISP> (parse-defun (read "(defun add1 (x) (+ x 1))"))
(fset 'add1
      (lambda
        (x)
        (+ x 1)))

we get the Elisp code to make a function. Note that parse-defun will work with any function defined with defun. We haven’t merely rearranged some text here. It’s much more:

ELISP> (eval (parse-defun (read "(defun add1 (x) (+ x 1))")))
(lambda
  (x)
  (+ x 1))

ELISP> (add1 3)
4

When we evaluate the code from parse-defun we really do get a function. That’s pretty impressive for the amount of work that we did. If you’re not impressed, ask yourself if you could (easily) do this in C, or Python, or Ruby, or whatever your favorite non-Lisp language is.

Long says that the real power of macros is that they allow us to install functions like parse-defun into the Lisp compiler. When the compiler reads a macro name it passes the forms to the function that the macro represents and then processes its output. That’s a rather obvious point once someone points it out but I think it’s a profound one that helps place macros in their proper place in the Lisp universe.

If this stuff excites you, as it does me, be sure to head over to Long’s blog and read his post. You won’t be sorry.

Posted in Programming | Tagged , , | Leave a comment

(Re)Naming Functions

This is another note to myself. Quite often we want to give a function another name. Sometimes this is because we want a shorter name for a function that we use a lot. For example, even though I use smex I have several lines in my init.el file to quickly switch modes

(defalias 'om 'org-mode)
(defalias 'am 'abbrev-mode)
...

Another reason to rename a function is to change its functionality. The common example that everyone knows (even if they don’t do it) is to rename yes-or-no-p to y-or-n-p. We do this because we want to eliminate Emacs’ annoying insistence that we type “yes” or “no” in answer to certain questions.

There are two ways to rename functions

  1. Use defalias
  2. Use fset

Either one works where the other would but their operation is not identical. I can never remember the rules for when to use defalias versus fset, hence this note to myself.

Almost always, you want to use defalias because it records the file where the definition was made. Use it where a specific function name is being defined. The Elisp manual’s rule of thumb is that if you think of DEFINITION in

(defalias 'SYMBOL 'DEFINITION)

as the definition of the new function SYMBOL then you should use defalias.

Use fset for manipulation of function names. For example, if you want to change a function’s definition, you can use fset to save the old definition:

(fset 'old-some-func (symbol-function 'some-func))
(defalias 'some-func 'some-other-func-definition)

We use symbol-function in the fset so that we get the actual definition of some-func and not just its name, which is about to have its definition changed.

Posted in Programming | Tagged , | Leave a comment

Generalized Variables and Macros 2

Yesterday we talked about some of the difficulties in using setf in a macro and how these difficulties can sometimes be overcome by using the mysterious define-modify-macro. Today, I want to look at a more general approach that will also explain how define-modify-macro works.

Last time, we wrote the += macro to implement the C += operator. That worked out well so we might decide to do a -= and then a *= and so on. After awhile we realize that we’re repeating the same pattern over and over so we decide to write a general version, op=, that will take the operator we want as an argument. That is we want to write

(op= + x y)

instead of

(+= x y)

That way we have only one macro and it works for any operator:

(op= floor x y) → (setf x (floor x y))

We can’t use define-modify-macro here because it requires the name of the function at the time of the call to define-modify-macro and we want to make op= take the function as an argument. We also can’t write

(defmacro op= (op x y)
  `(setf ,x (,op ,x ,y)))

because of the problems we discussed last time.

To help us with problems like this, Common Lisp provides the function get-setf-expansion. To see how it works, let’s call it on the place we used last time, (aref a i):

CL-USER> (get-setf-expansion '(aref a i))
(#:G1409 #:G1410)
(A I)
(#:G1408)
(CCL::ASET #:G1409 #:G1410 #:G1408)
(AREF #:G1409 #:G1410)

The call returns 5 values. The second is a list of input arguments for the aref and the first is a list of corresponding temporaries into which those arguments should be evaluated. The third is a list (always of length 1) of a temporary into which the final value to be stored should be put. The fourth value is code to store the final value and the fifth is code to retrieve the value referenced by the setf argument.

We want our macro to expand into something like

(let* ((#:G1409 A)
       (#:G1410 I)
       (#:1408 (op (aref #:G1409 #:G1410) y)))
  (CCL::ASET #:G1409 #:G1410 #:G1408))

Notice that if the i variable is something like (incf i) this still works because i is evaluated only once.

With that skeleton, it’s pretty easy to write the macro

(defmacro op= (op place y)
  (multiple-value-bind (temps args val setter getter)
      (get-setf-expansion place)
    `(let* ,(append (mapcar #'list temps args)
                    `((,(car val) (,op ,getter ,y))))
       ,setter)))

When we expand it we get

CL-USER> (macroexpand '(op= + (aref a i) 3))
(LET* ((#:G1470 A) (#:G1471 I) (#:G1469 (+ (AREF #:G1470 #:G1471) 3))) (CCL::ASET #:G1470 #:G1471 #:G1469))
T

which is a slightly less well-formatted version of our skeleton. When we try it out, we get the expected result

CL-USER> (let ((a #(2 4 6 8)) (i 2))
           (op= + (aref a i) 3)
           a)
#(2 4 9 8‍)

The idea for the op= macro is based on Paul Graham’s _f macro from On Lisp, a great book for learning about macros.

We’re now in a position to understand define-modify-macro. What it does is to take its arguments and then build a defmacro much like op=‘s. The resulting macro calls get-setf-expansion, sets up a let* just like op=, and then inserts ,setter as the body of the let*.

Posted in Programming | Tagged | Leave a comment

Generalized Variables and Macros 1

One of the wonders of Common Lisp is the generalized variable. Roughly speaking, a generalized variable is an expression that can serve as the first argument to setf. The official explanation, as given in Common Lisp the Language, 2ed., is here. A convenient way of thinking about generalized variables is that they name a place that can contain a Lisp object.

The easiest such case is a simple variable such as x. In the expression

(setf x (* x 3))

x is the name of a place that will hold a value 3 times larger than its current value after the setf is executed. Notice that since x can occur as the first argument to setf it is a (trivial) example of a generalized variable.

A meatier example is (car x). The (car x) names a place (the car of the cons x) that can hold a value. As with the previous example, we can use the name of that place to both get and set the object it contains:

(setf (car x) (* (car x) 3))

Things get interesting when we try to use setf in macros. For example, suppose we want to write a macro that implements the C += operator. We might try something like

(defmacro += (x y)
  `(setf ,x (+ ,x ,y)))

This seems to work pretty well.

CL-USER> (let ((a #(2 4 6 8)) (i 2))
           (+= (aref a i) 3)
           a)
#(2 4 9 8‍)

But suppose we want to increment two entries in a row

(defun incr2 (a i)         
  (+= (aref a i) 3)
  (+= (aref a (incf i)) 3))

CL-USER> (let ((a #(2 4 6 8)) (i 1))
           (incr2 a i)
           a)
#(2 7 11 8‍)

What happened? Instead of #(2 7 9 8‍) we got #(2 7 11 8‍). The experienced macro writer will see immediately that the problem is that the += macro evaluates its first argument twice. Most of the time, as in the example before last, that doesn’t matter but in the last example it causes i to be incremented twice. Expanding the macro call (+= (aref a (incf i)) 3) shows what happened

CL-USER> (macroexpand '(+= (aref a (incf i)) 3))
(CCL::ASET A (INCF I) (+ (AREF A (INCF I)) 3))
T

The first (incf i) increments i to 2 so that the result will be stored in the 3rd slot of the array. The second (incf i) increments i to 3 so that we add 3 to the 4th slot of the array and store 11 in slot 3.

The usual way of handling this sort of thing is to evaluate the variable once into a temporary and then use the temporary in the rest of the macro. But that doesn’t work here because setf is itself a macro and needs the name of the place to figure out how to get and store the value. Fortunately, there’s an easy way of addressing this problem for the += macro. Instead of our previous definition, we use

(define-modify-macro += (y) +)

What’s happening here is not obvious but this says to create a macro named += that takes two arguments, the place to be set and y, operates on them with +, and stores the result in place. See the Common Lisp HyperSpec for the details on define-modify-macro.

With this definition of += things work correctly

CL-USER> (let ((a #(2 4 6 8)) (i 1))
           (+= (aref a (incf i)) 3)
           a)
#(2 4 9 8‍)

In this example, place is (aref a (incf i)) so the result is equivalent to

(let ((i (incf i)))
  (setf (aref a i) (+ (aref a i) 3)))

although that is not the actual expansion.

Next time, we’ll look at some macros using setf that require more general methods. After that, it will be easier to see what define-modify-macro is actually doing.

Posted in Programming | Tagged | Leave a comment

Some RSA Public Keys Are Insecure

According to The New York Times, a team of European and American researchers have discovered that some (about 0.2%) RSA public keys are insecure. The insecurity is the result of using prime factors that aren’t cryptographically random. I’m still reading the paper but it appears that poor random number generation resulted in shared factors between many of the keys and in many cases shared moduli. One group of keys sharing a modulus had 16,489 keys in it.

It’s an interesting paper and worth a read if you’re interested in cryptography and security. One startling fact from the paper is that the authors used “unsophisticated methods” in their work and said they find it hard to believe that their results haven’t already been used for exploits.

Posted in General | Tagged | Leave a comment