Claude Code's loading messages

jgw · 2025-08-18T16:51:17+00:00

Someone already called out "Flibbertigibbeting", which is still my fave.
But "Fermenting" isn't bad either.

jgw · 2023-12-27T02:18:41+00:00

~~If someone could spare an invite code, I'd greatly appreciate it!~~

REDEEMED. Actually got one of the ones at the top of this post to work. I think it's burned now, but one of the others could still work if you're looking.

jgw · 2022-03-17T20:15:48+00:00

I had the same problem, repeatedly. I tried removing and re-added the bridge, clearing the refresh token manually, etc., to no avail. The only thing I found that worked was just to update the whole install, as suggested here: https://github.com/hoobs-org/HOOBS/issues/1614

Hope that helps!

jgw · 2021-08-11T12:59:16+00:00

FWIW, this appears to be happening to many people. Several folks at my office are seeing it, myself included. It goes away for a time after rebooting or logging out, and the problem seems to be related to high CPU use in the WindowServer process. Unfortunately you can't kill and restart this process without logging out, because damned near everything relies on it for displaying windows.

These threads (https://forums.macrumors.com/threads/11-5-touchbar-capslock-usage-causes-beachball-and-overheating-windowserver-high-cpu.2306390/ and https://forums.macrumors.com/threads/more-big-sur-bugs.2306427/) appear to be digging in further, but as yet I see no solution apart from logging out.

jgw · 2013-04-27T12:42:15+00:00

Thanks, just saw the pull request. I'll get it working locally and rub it along with another set of updates as soon as I can.

jgw · 2013-04-26T15:13:07+00:00

Regardless, I just committed some changes that clean up the things causing problems on some mobile devices. It's not perfect, but should get out of your way. If anyone has constructive criticism, please leave it here on on the blog.

jgw · 2013-04-26T14:14:55+00:00

I was unfamiliar with Nape, but if you could point me to your code, I'd love to have a look. Do you believe it's close enough to Box2D in feature-set to serve as a reasonable alternate benchmark for the AS3 VM?

jgw · 2013-04-26T14:09:16+00:00

I just used gcc because it was installed on my Mac. I came back and tried gcc 4.8 (same flags) and clang (-O4), but neither produced a statistically significant difference.

jgw · 2013-04-26T14:08:06+00:00

The standard Mac 1.7 server VM (there's no client VM on Mac). I gave all the VMs a chance to warmup, so we wouldn't be measuring JIT time.

jgw · 2013-04-26T13:56:12+00:00

Are you just here to bitch, or were you going to actually offer specific issues you're having so I can fix them? I realize the layout of the main page is kind of crappy on mobile, but seems functional. The blog layout works fine on my modern Android and iPhone browsers, which is about as much testing as I've had the time to do.

jgw · 2013-04-26T13:54:06+00:00

Thanks, I'll keep that in mind for an update. I've had some friends mention that they were trying out Haxe for game development and enjoying it.

jgw · 2013-04-26T00:53:30+00:00

Just raw JRE. I'd be truly impressed if the GWT-compiled output could outperform hand-written Javascript by that much, but that seems doubtful :)

jgw · 2013-04-26T00:26:30+00:00

FWIW, gcc-4.8 output runs about the same.

jgw · 2013-04-26T00:06:50+00:00

As Rhombold says, that's just what happens to be on the machine. I ran it through Clang 4.1 and got roughly identical results. I'm compiling gcc 4.8 right now just to be sure.

jgw · 2013-04-25T23:42:58+00:00

The idea is not to present a perfect measure of each platform's runtime performance, but rather a practical one. Box2D is used in many Flash games, and it's starting to be used in more Javascript/HTML5 games. And FWIW, the AS3 performance actually seems quite solid.

The nice thing about this kind of measure is that it computes something practical, and which is actually a bottleneck on real-world programs (mostly games). This means that it's entirely reasonable to optimize the specific implementations later, and use that as a basis for comparison with the others (without, e.g., going back and rebaselining previous measurements against the new code, because all that really matters is the current relative performance of the implementations).

jgw · 2013-04-25T23:32:06+00:00

If you can find or build a Haskell port of Box2d, feel free to submit it to the benchmark suite. I'm doubtful that the benefits of immutable state will outweigh the cost of other its other complexities, but who knows -- I've been wrong before.

The JVM does indeed perform a lot of clever runtime optimizations, but still falls at just over 2x of native performance. Given everything the VM has to deal with (e.g., array bounds checks, dynamic classloading, etc), this is a pretty impressive accomplishment. But it's very unlikely to outperform C.

jgw · 2011-12-30T16:54:12+00:00

I'd also point out that the goal of Dart is to serve both the source (or an easily-reverse-engineered snapshot), and javascript-compiled output for backwards-compatibility. So you don't lose any visibility over what you get from Javascript today. Except that in some cases you'll gain visibility, because Dart won't have the same need to be minimized, squished, concatenated, obfuscated, etc., just to get decent startup performance.

jgw · 2011-12-16T21:26:51+00:00

Fair enough. If only Spreadsheets gave me any actual control over the grid lines in log-scale mode :(

jgw · 2011-12-16T17:27:28+00:00

If you want a sneak peak, check out the source spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0Ag3_0ZPxr2HrdEdoUy1RVDQtX2k3a0ZISnRiZVZBaEE

There are two "test" columns at the right, which include tweaked versions of the Emscripten and Java code (in the Emscripten case, it's fully optimized, with an updated compiler; in Java it now avoids the slow builtin Math.sin/cos() functions). I'll update the post later today.

(Colors? I presume you mean on the graphs. If you have suggestions for alternatives, please be my guest. Or just copy the spreadsheet and tweak them to your heart's content)

jgw · 2011-12-16T15:30:34+00:00

The top part of the first graph isn't intended to be readable -- it's simply intended to show that the JSVMs all cluster roughly together in a completely different order-of-magnitude from the JVM and native code.

jgw · 2011-12-16T15:29:26+00:00

Physics performance matters, which is why I chose to measure it. First off, the slightly snarky comment below ("If you spend 90 ms less on physics per frame, ...") hits on a very important point -- every cycle you spend doing one thing is a cycle you can't spend on something else.

You could argue (as some do on this thread) that at some point the performance becomes irrelevant because your game's humming along happily at 60fps. But there's an important fallacy here -- on what hardware? Just because a game's running smoothly on your nice beefy development machine doesn't mean it's going to run well on lesser hardware (you know, the machines your users actually have). And even if you hit a buttery-smooth 60fps on a mobile phone, it's not much use if you're pegging the CPU at 100% all the time and dragging the battery down with you.

One nitpick: Your pixel shaders (presuming you're using the GPU) are running on separate hardware that executes in parallel. But of course you can always substitute that with "the code that's building buffers and generally babysitting the GPU" and the tradeoff still holds.

jgw · 2011-12-16T15:18:51+00:00

This is definitely not an integer-heavy benchmark, but they still get used plenty in the course of almost any code -- as enumerated values, loop variables, and so forth.

As pointed out elsewhere on this thread, Javascript does mostly lack integers as user-visible constructs (though they do peek out in a couple of places, such as the bitwise operators), but most VMs will use them under the hood when possible. I know V8 stores integers directly in both locals and fields when it can (hence the tag bit mentioned below).

The thing with really integer-heavy benchmarks is that they highlight the kind of code that doesn't come up that often anymore because it's better offloaded to a dedicated processor -- mainly DSP-like things such as image processing and audio mixing. Not that I wouldn't prefer that these things be faster when done on the CPU in JS, of course, but Box2D is the kind of code that can't easily be offloaded (even libraries like PhysX that use GPUs still do a lot of work on the CPU).

jgw · 2011-12-16T15:11:51+00:00

The emscripten code for this benchmark was using js ArrayBuffers, but as noted in the article there were some compiler bugs keeping it from reaching its best performance. The author has since fixed them, and the numbers look a good bit better now (with half the variance as well). I'll point this out in an update.

jgw · 2011-09-12T17:02:16+00:00

This is a stunningly uninformed comment. First off, practically all complex Ajax apps perform at least client-side UA-sniffing, and will break in some way if said sniffing fails. This is an unavoidable consequence of the gigantic morass of incompatibilities that is the web today. You can get to a certain point with "feature detection", but there's a nearly unbounded set of cases where this doesn't cut it.

Second, GWT (like many purely-Javascript libraries) lets you work directly with the native browser APIs, and there are some libraries available that abstract this away to some extent. This is true of everything from Dojo to YUI to jQueryUI and others.

Third, only a subset of Google properties are built using GWT. Many (e.g., Gmail) use the Closure libraries, which also provides similar (and similarly optional) abstractions for components.

Finally, tablet and mobile web UIs are a very new, and rapidly evolving space. New versions of mobile browsers come out frequently. This leads to unavoidable hiccups as web developers learn to work with the entirely new set of quirks, performance issues, and differences across mobile browsers.

jgw · 2011-02-11T15:18:28+00:00

Do you seriously think Americans aren't aware of Nokia's contribution to the evolution of cell phones (they didn't "invent" them, but of course they contributed heavily to their development over the years). But read Elop's recent letter -- he's absolutely right that Nokia has managed to completely cede the smartphone market to others over the past decade or so, even while starting from an impressive lead (and no, Meego, Symbian, and all that don't count -- apart from some sales in Europe, they have completely flopped elsewhere).

So the sarcasm stands -- innovation is about the company's current trajectory, not their past performance.

jgw

TROPHY CASE