samps

Someone should write a tool that scrapes these results and automatically files bugs at the associated bug trackers for open-source projects.

This looks pretty cool, but as a non-Rubyist, I remain confused about the purpose of all these "DSL" libraries that lispy aims to simplify.

In the examples, at least, the language was only used to declaratively build hierarchical list/dictionary structures. The only constructs I can see used are blocks and method invocations; there aren't any loops or conditionals or anything else imperative. Can someone more experienced with Ruby DSLs explain what lispy accomplishes that something like YAML or a simple custom parser doesn't? (Other than a bunch of extra "do"s and ":"s.)

Just released a new version of beets, an open-source CLI music management tool for nerds: http://beets.radbox.org/

It's supposed to be an extensible and fast alternative to iTunes, MusicBrainz Picard, and other tools. It's getting there.

Anyone else catch this tidbit from Apple's site?

File Sharing for iPad: Lion Server delivers wireless file sharing for iPad. Enabling WebDAV in Lion Server gives iPad users the ability to access, copy, and share documents on the server from applications such as Keynote, Numbers, and Pages.

This sounds like the OTA iOS file sync we've been waiting for.

This looks awesome. This may seem shallow, though, but when I got to the setup page, I was a little disappointed with the complexity of the setup required.

- Why are you using MySQL instead of SQLite or something even simpler? Surely my personal music streamer doesn't need serious scalability.

- Why does the setup require futzing with my Apache configs to use mod_rewrite? For just streaming music, I'm willing to put up with ugly ("something.php/directory") URLs. This would also make it easier to get up and running with non-Apache web servers (lighttpd, for instance).

- Do I really need to use a non-default PHP configuration? And increasing the interpreter's memory limit seems a little ominous.

This is all to say that perhaps the right way to deploy something like this would be as a single program you can run that has its own built-in Web server. As it is, the configuration is daunting for a home computer (although completely reasonable for a real server setting).

What's with the title of point 3 ("design is gay")? Is the author quoting a homophobic opinion of some Indian programmers, or is he being careless with his own wording?

The "no caching" effect is much less pronounced with fast app switching. Are you on iOS 3.x?

Also, in my experience, there are often weird consistency errors in the App Store when something new is rolling out. (I could only see it on my Mac for a while before it appeared on my phone.) Try again in an hour.

This bit is hilarious:

The best way for our users to always have the most up to date and secure version of Java will be to get it directly from Oracle.

Contrast that with a recent quote from Bill Evans:

We're happy to continue to support Flash on the Mac, and the best way for users to always have the most up to date and secure version is to download it directly from Adobe.

It's like they're just toying with the tech press.

What the hell is an Internet Explorer icon doing in the "Dock" on that screenshot?

This is very interesting. However, the OP's idea of "failure" is when something goes wrong with the system -- in this case, ext3 detected an error when trying to write to its journal. It's possible that silent data corruption occurred much earlier. If the OP reads this, I'd love to see the experiment repeated, with the added step of verifying the written data every time it's written.

That is, you would dd a random bit pattern to disk. Then you would read it back and XOR it with the pristine pattern you know you wrote. If you see any difference, you've got a much scarier kind of failure than the fail-stop behavior exhibited in the post.

Also, does the OP know whether any write buffering is going on? That could explain why some writes took much longer than others -- when the write actually goes to disk, it would take much longer than when it gets cached in memory. Use the "sync" command between each write to make everything go right to disk (I think?).

This doesn't seem to affect the (free) "My Library" station.

One possible takeaway from these graphs is the urgent need for better JavaScript benchmarks. Both SunSpider and the V8 benchmarks are sets of microbenchmarks and the difference between them is enormous: JM+TM is significantly faster than plain JM on V8 but is a little slower on SunSpider. The fact that the conclusions can vary so greatly among these two (both deeply flawed) benchmark suites suggests that the true "real-world" performance of the engines is all but entirely unmeasured. Which loads Gmail fastest? That would be a step in the right direction.

This is a little pedantic, but "begs the question" doesn't really mean "raises the question" even literally. It sounds weird to say that someone "begs a rebuke" when they really deserve a rebuke. Even more literally, you don't say that someone on the street "begs a dollar" -- they beg for a dollar. Just as you said, some situations beg for those questions to be asked (or perhaps they beg that they be asked); they don't simply beg them.

I realize this might not be your goal, but any chance you would consider targeting some features toward academics? Academic conferences are horrible to keep track of, and this seems like it might almost be a great solution.

The missing pieces, as I see them, include more structured programs (i.e., the sessions have titles; the speakers are listed even if they're not on Lanyrd or even Twitter) and the ability to follow series of conferences (i.e., I want to know what happens at OOPSLA every year, not just once).

Hefty! As an exercise, any sense in inlining the tracing into compiled code? That way you sacrifice the startup time benefits of the JIT (by AOT compiling at start) but still retain trace specialization.

Thanks for writing this -- it's awesome to see JIT principles boiled down to the point where you can easily understand the whole system. Please let us know if you publish the tutorial; I'd love to see more detail on the JIT. In particular, it would be the perfect template to demonstrate feedback-directed optimization opportunities and to measure the overhead of tracing; it would be incredibly interesting to see what has to be done to make the JIT outperform the AOT compiler.

I couldn't agree more -- especially when the job is a more researchy role. Right now, I'm at my first "real job", a research internship during my PhD program, and the contrast between my productivity at school and here is shocking. The need to clock in and out and the desire to "look busy" all the time actually end up hurting my productivity, I think, much more than helping it. When my responsibility is creative thinking and new research, much of my productive time is spend doodling in a notebook or staring into space. While sitting and coding is important too, I don't feel like the normal metrics for the appearance of productivity apply.

So, paradoxically, I get paid for the time I sit in my office and begrudgingly hammer out code; the time I spend at home coming up with the important ideas to drive the research goes pro bono.

Maybe I'm just lazy, but I really think that sitting in a windowless office for eight or nine hours a day is not the way to encourage maximum output. Personally, I find myself thinking I'd be much more productive if I just "worked" a little less.

Sorry to barrage you with self-links, but I felt the same thing recently and I've started working on an (open-source) tool for addressing exactly that: organizing my music collection correctly and painlessly (i.e., as automatically as possible).

It's called beets and the idea is this: just throw new albums at it; they get tagged correctly (from MusicBrainz), copied into a directory structure you specify, and catalogged in an sqlite database. Let me know what you think: http://beets.radbox.org/

An (open source) music library manager and automatic tag corrector. http://beets.radbox.org/

It's Python and all command-line. I'm trying to make something that's both better than iTunes for managing music (not that hard) and smarter than MusicBrainz Picard for correcting tags (a little harder).

For more Adam Lisagor, try the video for the Birdhouse iPhone app, which is even more charming than the Square video: http://www.youtube.com/watch?v=S8yRaWY1xV8

Unrelatedly, PadMapper is excellent (better than other Craigslist mappers I could find): it has a great filtering system, seems to fetch fresh results more often, and can alert you about new places. I found my current place using it.

I have a favorite one of these: "You and me, we're really on the same pagelength."

Unfortunately, a client/server model still does not solve all of our concurrency problems. The problem is that the algorithm we're running--contributing a handful to text responses to the same repository--is very simple. But more complicated algorithms--say, if you're Google for instance, looking for a few words in billions of documents--need significantly more expertise to be correct (and perform well on top of that!).

It's certainly feasible to imagine that single-threaded performance will improve to the point that parallelism will no longer be "necessary" (although many people have observed that, with Moore's Law no longer yielding the performance improvements it did just a few years ago, this may be too far out). However, applications arise and expand to fill whatever performance we have available. By achieving parallel performance gains, we'll enable things that weren't possible before, no matter how good single-threaded performance is. Also important is the distinction between parallelism and concurrency: many domains need multiple threads for reasons that have nothing to do with performance! A database server, for instance, needs to service many requests concurrently; it can't function correctly in a "single-threaded" world.

While you're right that the main problem has to do with sharing resources between different threads of execution, the difficult part is not actually doing that sharing. The simple act of sharing data is very simple, and can be accomplished via many different helpful abstractions (try looking at Wikipedia's description of "shared memory" or "message passing"). In the case of shared memory, sharing can be accomplished just by writing data to memory in one thread and reading it in another. Easy!

The difficult part is in how the threads actually coordinate. The problem is extremely application-specific (what exactly do threads need to share? When do they need to share it? These cannot be answered in a general way). It's generally accepted that concurrency bugs (examples: data races (colloquially "race conditions"), deadlock, atomicity violations, locking discipline violations) are extremely difficult bugs. This is probably either because (1) programmers are not accustomed to thinking about coordinating between parallel activities or (2) people are in just worse at thinking concurrently than thinking sequentially.

So new libraries/methods for accomplishing communication between threads are always welcome and can help reduce the complexity of parallel programming. However, nobody has yet found an abstraction that both works for most kinds of parallel programs (MapReduce is very simple to work with but also very restrictive) and is simple enough for people to program in without fear of hard-to-solve concurrency bugs (message passing and shared memory are both quite general but considered somewhat unsafe).

So, the problem is not that a good abstraction layer would be too computationally expensive -- it's that no one even knows what the abstraction should be! Hope this makes the issue clearer.

This is awesome. Congratulations to the always-incredible developers of ffmpeg.

One thing is worrisome about this: since H.264 (the current industry standard video codec) and VP8 are highly similar, we can share code (and more importantly: optimizations) between FFmpeg’s H.264 and VP8 decoders

So it looks like VP8 is so similar to H.264 that decoders for the two can share quite a bit of code (something Jason Garrett-Glaser suggested might be the case: http://x264dev.multimedia.cx/?p=377 ). Have to admit that this doesn't seem to bode too well for VP8's claim to relative freedom from patent litigation.

Alternatively: detect when a URL is pasted and remove the placeholder http:// only then. I certainly type URLs sometimes and would find it disorienting if the http:// just disappeared when I started typing.

At least here, there's the alternative of using existing ad-blockers for Safari, which are typically SIMBL plugins or otherwise sidestep the official plugin channels.

In this light, maybe people have started to be annoyed more by Gruber because, although his style and opinions haven't changed, he's suddenly for the Empire instead of the underdog. I have a feeling there would be much less anti-Gruber vitriol if he were defending an Apple that still seemed to be the "alternative" rather than the "mainstream".

I love all these HTML presentation demos, but many of them (including this one) don't seem to work on an iPad due to their reliance on the keyboard. Perhaps the author should consider detecting a touch device and allow single taps or swipes to advance the slides. (Double-taps, of course, just zoom.)

Agreed. In many ways, Python is the most "boring" of the modern dynamic languages, in the sense that it trades exciting features and hip syntax for predictability and elegance. So it gets a lot of the productivity, conciseness, and power of other dynamic languages without nearly as much cognitive dissonance for people familiar with C or Java.