svdree

Pat Metheny has done something similar with his orchestrion project, 12 years ago (https://www.youtube.com/watch?v=KsYEOUKS4Yk). At the time I went to see him perform with it in the Concertgebouw in Amsterdam, which was impressive, but still missing the band energy that normally makes the music come alive. He did mention that it was the first gig on the tour without major technical issues, it does seem like a nightmare to set it all up correctly.

There was some discussion on this years ago on lkml, you can read it e.g. here: https://koblents.com/Ches/Links/20-Using-Goto-in-Linux-Kerne...

MiniFB is also nice for this purpose: https://github.com/emoon/minifb

It's a sad moment for gamers. He started working at Sharp, where he sold solar cell and light sensor technology, but he's best remembered for a long and highly influential run at Nintendo that effectively revived the video game industry following the 1983 crash.

Ah, nostalgia settles in my brain. Old times = good times, at least most of the time.

I'll add my packages: xdoctest and mkinit as well. Also redbaron and astunparse are nice tools when doing static analysis.

Great article nevertheless!

This post is about automatic generation of programs that in turn produce creative visuals.

This post is about automatic generation of programs that in turn produce creative visuals.

So China is getting data from both phones and Facebook?

"Do not draw a penis!" - was the first I did after opening the link (I mean, I draw a penis).

Why is everybody always so concerned with developer time, but never with user time? The author of this tool even complains about the startup time of photoshop, but somehow has no problem with building a tiny tool on Electron. The irony is quite strong here.

That sounds reasonable, until you have to debug an issue that only manifests itself when working with a huge dataset, in which case the whole thing becomes pretty much unusable. As the article says, debug mode is expected to be slower, but the difference between MSVC and the other 2 is just crazy.

Back in university I had a side job as a security guard in an office building, when this happened. Someone took the cargo elevator, which was built to carry a higher load than the regular elevators, so it had a massive counter weight. The thing slammed into the ceiling with a bang that could be heard through the entire building, and the damage was quite extensive. Took a while for the guy to calm down as well.

Yeah, I can understand preparing for the job itself, e.g. brushing up on your financial knowledge when applying for an HFT job or something. But interviews and actual jobs seem to have diverged to the point that there is now somewhat of an industry around 'preparing for the tech interview'. It's almost like a new branch of science.

Sean Barrett (who I think popularized the idea) has a FAQ on this (https://github.com/nothings/stb) where he justifies it by pointing at difficulties with deploying libraries on Windows. Which is a fair point, but by going straight to header-only he skips the step where you can also just distribute a bunch of headers and .C files. The convenience of only having to include a single header is nice for quick weekend projects, but for anything bigger you're dealing with dependencies and build issues anyway.

I get some of the reasons that you would initially start out with a header-only implementation, but when your library grows, you probably want to split it at some point. For me personally, that point would be some time before the header reached 25k (!!) lines.

You can, if the scene fits into GPU memory. Otherwise the data transfers will quickly dominate your render time.

If this line of thinking ever takes off, it will be just another one of those meaningless rituals you have to go through to signal that you're part of the club. Polish your resume, dress up nicely, read 'cracking the coding interview' the night before. There might actually be a great idea for a new book in there: "How to fill up your GitHub account with random crap so future employers think you're really really passionate".

Actually, the K80 does run OpenGL. Source: I'm building a remote rendering solution that runs on a couple of K80's, and it works just fine.

There's a nice write up on how this was done at https://blog.sketchfab.com/art-spotlight-calvin-hobbes-3d-st...

Could it be that the distance between the top and bottom 20% is less in Canada, making it easier to move from one to the other?

It's not about wear and tear. Brakes heat up when they're used, and descending an entire mountain on the brakes is likely to overheat them to the point where you have no braking power left at all. Not a good situation to be in on a steep slope. Using engine braking to keep your speed under control prevents this.

What you'll often find however, is that in the last step ("make it fast") you have limited room to maneuver, because of the stuff you did in the first 2 steps. If you really need high performance, you need to design for high performance, not just leave it as an afterthought.

But at the point where you're ready for careful observation and measurement, you've already designed and written your solution, and the amount of room you have for optimization is constrained by the thing you just built.

If you want performance, you have to design for performance, not just build the first thing that comes to mind and try to optimize it later.