dripton

Neat. I've wanted ZeroMQ in my browser.

I checked the README file for a license, but instead it says "ZeroMQ in your brower, yo!" Which tells me that:

1. I can't use it.

2. The author is 12.

3. It probably doesn't work.

No, they also asked for my email password, so they could harvest my address book. It was optional, but optional phishing is still phishing. Maybe they've stopped doing that now, but they were doing it a year ago.

I tried signing up for a Udacity course once, but they asked for my email password, which I consider phishing. They're on my boycott list now.

I am not a lawyer, but the DMCA makes an exception for compatibility. So I believe you have the right to break the DRM on a Kindle book so that you can read it on Linux.

It may be a more capable device, but I seriously doubt it's cheaper. Kindle Fire is $199 no strings attached. Android phones costing less than that up-front tend to come with 2-year voice+data contracts at $50+ per month, or at least $1200.

dub-dub-dub

I doubt it.

For example, there was a famous study a few years ago showing that NFL teams punt way too often. (http://fifthdown.blogs.nytimes.com/2009/09/17/a-new-study-on...). It didn't seem to have much effect on play-calling. Being conventionally wrong appears to be safer for coaches than being unconventionally correct.

Of course there are exceptions. To their credit, the Patriots let the Giants have a free touchdown near the end of the Super Bowl, rather than letting them run the clock out. An obvious tactic to most Madden players, but not one you see much in the pros, because That's Not The Way It's Done. And Belichick is one of the few coaches with the job security to do things his own way.

Where's the link to the actual regulations?

I hate articles like this that could easily refer to the primary source, but fail to do so.

Hell, I'm a grownup with a job, and I don't have a smartphone. They're very expensive toys.

Of course, if you just want to launch programs by typing a word, you don't need Unity. You can just type their names into a terminal.

Maybe.

cpyext is a hack to let PyPy run Python/C API modules. It works for some, but not all, and it's slow. I'm sure it'll keep getting better, but not sure if it'll ever be good enough to run PyGTK or PyQt.

PyPy has good support for ctypes, so ctypes bindings are a good option. There are projects out there like pygir-ctypes and ctypes-gtk. One of them just needs to become complete enough to be a good choice for GTK programming. Compatibility with new PyGObject is more likely than compatibility with legacy PyGTK, though.

PyQt is harder because it's C++.

My grandfather had stomach cancer in the 1960s, when he was in his 40s. He was very fortunate that it was detected quickly and removed successfully. He ended up dying of a heart attack in his 70s.

Nobody lives forever, but some people do survive cancer.

Yep. The GIL means that individual Python bytecode operations are atomic, and so by extension single Python statements that translate to individual bytecode instructions can be treated as atomic (if you don't care about portability to alternate Python implementations that lack a GIL). But complicated Python statements that translate into multiple bytecode instructions (like dict.setdefault) can't. And, of course, neither can sequences of multiple statements. So you still need locks for most cases where you mutate objects that are shared across threads.

This is why pair programming and code reviews work so well.

Pedestrian and bicycle fatalities outnumber car occupant fatalities in Manhattan for this reason.

I saw a billboard last time I drove through NYC, explaining why the speed limit is 35 rather than 45. It basically said that if a car hits a pedestrian going 35, the pedestrian will probably live, but if a car hits a pedestrian going 45, the pedestrian will probably die.

3 hours? You're doing something wrong. I just built PyPy in 49 minutes on a $99 3 GHz Phenom II.

Last fall I had two roughly equal job offers, one for a telecommute, the other for a job 12 miles away.

I took the one 12 miles away, partly to avoid losing my bike commute. I figured losing 90 minutes per day of forced exercise would be bad for my health. (Of course if I'd taken the telecommute gig I still could have gone for a bike ride every day -- but would I have done it, when the weather was bad?)

I won't take a job that requires a car commute. (Unless it's the only thing I can find, which seems incredibly unlikely.)

The article seems to make the unstated assumption that every commute is in a car. My bike commute is one of the best parts of my day. In fact, I turned down a telecommute job so that I could continue riding to work.

Of course the company is the customer and you are the product. They pay; you don't. Follow the money.

My mother-in-law bought me a Lego F1 Ferrari for my birthday a couple of years ago. Probably the best gift I've received since I was a kid. Because it turns out that I still I like playing with Lego, but I no longer think to buy it for myself.

I have a use case for this in a wargame with hidden units. You know the size of an opponent's stacks, and the total forces he commands, but not always which units are in which stacks. But you can observe some, and deduce some, and guess some.

Yes, I'll include IronPython next time.

IronPython is at 2.6. PyPy and Jython are at 2.5. psyco is at 2.6.

Most of my Euler solvers are compatible with Python 2.5. The ones that don't work in 2.5 end up getting excluded from the benchmark, because the benchmark only shows programs that worked and finished in less than a minute on every tested Python.

You want me to port all my Project Euler solutions from Python to Lua so that I can tell you that LuaJIT is much faster than any Python implementation, which you already know?

Yes, I will also include peak memory used next time.

I thought about that, but decided against subtracting out startup time. This is a real-world benchmark of how long it takes to run some actual code that I care about. Startup time counts, but the cumulative execution time will be dominated by time taken to run the slower programs, not startup time in the trivial ones, so I don't think I'm counting it too much.

But I think next time I do this I'll increase the max runtime from 1 minute to 3. That will keep more of the slower programs in the benchmark, and make startup time count that much less. Without actually removing it, because that seems too artificial and contrived to me.

As does every other JIT. This is an apples-to-apples comparison.

Yes, execution time in seconds. And I throw out any program that fails on any Python, or takes longer than a minute on any Python.