You can find them at https://www.ubu.com/ubu/pdf/moore_spleen.pdf, or in his published Selected Poems, along with an essay (written afterwards) about translation. Worth looking out.

(I particularly admire the sarcastic one that begins "I'm like The Winner of The Competition / The one who wrote the strong, rewarding phrase...")

What that link doesn't give you is the dictionary files I used as input for the preprocessing step - which of course were also 1998 vintage. There are copies on the server (https://all-day-breakfast.com/chinese/cedict.b5_saved, https://all-day-breakfast.com/chinese/big5-PY.tit)

My Chinese got somewhat better, then a lot worse, then a little bit better again - obviously mostly to do with whether I was actually using it, which on the whole I haven't been. But back then I was really working on it and I just wanted something to help - there were a few useful resources I knew of (CEDICT obviously, and Rick Harbaugh's zhongwen.com was mindblowing at the time) and this seemed like a way to glue them together that I actually knew how to do.

Writing learning tools is obviously not the same thing as learning though.

https://all-day-breakfast.com/chinese/

What is kind of interesting is that the script itself (a single Perl CGI script) has survived the passage of time better than the text documenting it.

Besides all the broken links, the text refers throughout to Big-5 encoding, and the form at https://all-day-breakfast.com/chinese/big5-simple.html has a warning that the popups only work in Netscape or MSIE 4. You can now ignore all of that because browsers are more encoding aware (it still uses Big-5 internally but you can paste in Unicode) and the popups work anywhere.

I think they were initially using the Chordino chroma features (NNLS-Chroma) but a different chord language model "front end". Their page at https://chordify.net/pages/technology-algorithm-explained/ seems to imply they've since switched to a deep learning model (not surprisingly)

- The Vamp Plugin Pack for Mac finally got an ARM/Intel universal build in its 2.0 release last year, so hopefully the caveat mentioned about the M1 Mac should no longer apply

- Most of the Vamp plugins in the Pack pre-date the pervasive use of deep learning in academia, and use classic AI or machine-learning methods with custom feature design and filtering/clustering/state models etc. (The associated papers can be an interesting read, because the methods are so explicitly tailored to the domain)

- Audacity as host only supports plugins that emit time labels as output - this obviously includes beats and chords, but there are other forms of analysis plugins can do if the host (e.g. Sonic Visualiser) supports them

- Besides the simple host in the Vamp SDK, there is another command-line Vamp host called Sonic Annotator (https://vamp-plugins.org/sonic-annotator/) which is even harder to use, equally poorly documented, and even more poorly maintained, but capable of some quite powerful batch analysis and supporting a wider range of audio file formats. Worth checking out if you're curious

(I'm the main author of the Vamp SDK and wrote bits of some of the plugins, so if you have other questions I may be able to help)

Yes. Apple called them apps in the 80s, at least on the Mac - this is Apple II but it's plausible they were also referred to as apps there?

For my part I read the title as "Taking over a wall changed my direction as a programmer" which had me really confused for a while. I'd like to read that article, I think.

A paragraph in praise of its display reads:

"Now lets move on to the display - and what a display it is. No less than 30 colours are available from Basic: white, off-white, cream, dark cream, light tan, light brown, bamboo, medium tan, medium brown, wood brown, sepia, burnt umber, oxtail, mustard (both French and English), khaki, off-brown, chocolate, dark tan, dark brown, dark burnt umber, burnt chocolate, drinking chocolate, ovaltine, light black, medium black, dark black, brown with a hint of green, brown with a hint of red, and brown with a hint of reddy-green. On some televisions these colours tend to look a little muddy, but with a little hunting around compatible sets can be found. For the purpose of this review I am using a VictoriVision Super Compatible available at most good electrical shops in Taiwan."

Qt does have a locale-aware equivalent (QLocale::toUpper/toLower) which calls out to ICU if available. Otherwise it falls back to the QString functions, so you have to be confident about how your build is configured. Whether it works or not has very little to do with the design of QString.

If (like me) you hadn't seen this one, I think it is https://news.ycombinator.com/item?id=41172531

(Some of the top-level comments do indeed seem a bit oddly negative to me)

In some sense car manufacturers do do this - their designs are famous for being full of functionally empty retro cues that customers nonetheless go for.

Instinctively I find this absurd too. I always thought it was funny that, at least at the level of student instruments, the more you spend, the more beaten-up your new instrument looks. Basic ones have an even spray varnish (which I generally quite like). My slightly better* Chinese factory instrument is antiqued to the extent of having a more worn-looking patch where the hand rests when playing in higher positions, as if to suggest decades of performance as a soloist. It's nonsense.

But plainly people do like this and makers do make it. See e.g. the instruments at https://www.myluthier.co/category/violins (I can't afford to shop there, I just picked it because they have pretty preview images) which stand as quite good evidence against any suggestion that "reputable luthiers would never". Yes at some point you just have to make a living, but there's enough skill put into it to suggest there might be something more artistically interesting going on as well. The results are certainly quite personal.

There are practical arguments for antiquing. It's kind of handy when you're playing in an ensemble: from a distance my cello looks basically the same as the others around me in the orchestra even though some of them are a century older and genuinely quite harshly used. And you never have the pain of getting the first obvious scratch or chip in a pristine instrument.

Curiously this doesn't seem to be a very new practice either - I think even 150 years ago, new instruments were being turned out designed to look like much older ones.

* Sounds and plays better, not just cost a bit more. I didn't choose it for the antiquing!

Totally agree. Four years on, and it still trips me up daily.

Ironically, the usual failure mode for me is actually the one this change was supposed to help with - I want to select the whole URL, so I instinctively double-click it. This has the effect of selecting everything on the first click, then reducing the selection to a single word on the second. I am momentarily perplexed, then I recover and start clicking again, but now it takes three more clicks to get the whole URL selected.

It's surprising how annoying this is!

The explanation given in the tracker seems to amount to "at some point in the future, we might do something else that justifies this". Four years later and I'm not seeing it?

I was curious about this as well, as I found the images in the README a bit hard to read. In fact the program itself seems to use quite sensible colours in my white-background terminal, and it also respects the NO_COLOR environment variable.

That library was so good to me! (In Crook, County Durham in north-east England) As well as providing what was probably, if I'm really honest, the most fascinating technical book of my programming career, it also had a load of LP records I wouldn't have heard anywhere else - the Go-Betweens and Peter Murphy's "Deep" I remember particularly.

As an example I can look at my own Sonic Visualiser application, largely written 15-18 years ago and entirely CPU-driven. Relative to then, it's now horrible on contemporary Macs for example - it feels far slower than it did a decade ago. It just isn't what the hardware expects.

(There may be an element of toolkit-platform impedance and simple poor design on my part - it uses Qt and feels quicker on other platforms - and I don't want to argue the details here, but I think the basic principle that you really want to avoid CPU in the frame update is sound. Preparing things on a non-time-critical path via CPU should be another matter however, there's quite a lot of capacity there.)

That's a mindboggling thought. How much did 2005 Cocoa have in common with 1985 Cocoa? (That's a real question, I have no idea)

Qt and GTK were released (or first labelled stable) in 1995 and 98 respectively, so 20 years gives us 2015 and 2018 which is well within the Qt5 and GTK3 era.

For Qt, I would say Qt4 in 2005 marks a point of maturity, if not terminal stability. Ten years. After that there have been whole substructures and programming idioms added and removed and all sorts of things tidied up, but anything you wrote directly to Qt4 is going to be conceptually similar in current Qt versions.

The Qt2 to Qt3 and Qt3 to Qt4 transitions (I never used Qt 1) broke almost every line of Qt code, but from 4 to 6 is a different prospect. It's a question of updating some details and seeking replacements for specific APIs that haven't been carried across. That can be difficult or totally blocking but it's quite different from having to rewrite everything.

(I'm not well placed to compare them, since I let my own idagio subscription lapse a couple of years ago due to lack of income, I never tried Primephonic before Apple bought it, and I don't have an iPhone so can't try the Apple service... aside from all that, I'm right in the target market!)