General Development Archive

GCC 6.3 is a bug-fix release from the GCC 6 branch containing important fixes for regressions and serious bugs in GCC 6.2 with more than 79 bugs fixed since the previous release.

A while back I decided to try to write a Game Boy emulator in Common Lisp based on this series of articles. I made some good progress but eventually got bogged down because I was trying to learn a bunch of complex new things at once.

Instead of dragging on, I decided to take a break and try something simpler: a CHIP-8 emulator/interpreter. The CHIP-8 is much simpler than the Game Boy, which made it easier to experiment with the rest of the infrastructure.

In this post and a couple of future ones I'll walk through all of my CHIP-8 emulator implementation.

The 1.13 release includes several extensions to the language, including the long-awaited ? operator, improvements to compile times, minor feature additions to cargo and the standard library. This release also includes many small enhancements to documentation and error reporting, by many contributors, that are not individually mentioned in the release notes.

The goal was to publish source code to a GPU that is register compatible with the late 90's era Number Nine "Ticket To Ride IV" GPU. Although the project didn't meet its funding goal, the person behind it later published the code on github.

Despite the fact that this is an older design, it has lots of stuff that is worth studying. It's interesting to compare this design to the VideoCore GPU that I walked through in a previous post. While there are some fundamental differences, there are surprising number of functions that are similar, which shows how modern GPUs evolved from earlier ones.

By now, simply taking over a game and replacing it with a brand new app was beginning to feel a little predictable. So this year, TASBot decided to show off a new skill. At the AGDQ marathon, the bot set out to edit new features onto a game that's still running in active memory. TASBot wanted to be magnanimous with its new capabilities, too, allowing human players (and livestream viewers) the opportunity to edit the game on the fly.

But just how did TASBot - and the team of coders behind it - intend to turn an old game of Super Mario World, running on a standard SNES, into a heavily editable game of Super Mario Maker? Luckily, we had a behind-the-scenes invite to the event and the opportunity to find out.

Today, the US Department of Energy announced that it had established a partnership with NVIDIA that would be enhancing the LLVM compiler collection. The goal will be to port an existing FORTRAN compiler that targets massively parallel GPUs. The results are expected to be released as open source in late 2016.

Cutting-edge research still universally involves Fortran; a trio of challengers wants in. While FORTRAN isn't a mainstream language, it's still heavily used in scientific computing, and there's lots of legacy code that relies on it. A lot of that code is maintained by people at the US National Labs, and the new project is being organized by staff at Lawrence Livermore, Sandia, and Los Alamos.

League of Legends players collectively send millions of messages every day. They're asking friends to duo-queue, suggesting a team comp on the champ select screen, and thanking opponents for a good game. On July 21st of this year (I picked a day at random), players forged 1.7 million new friendships in the game - that's a lot of love! And each time players send a message they trigger a number of operations on the back-end technology that powers Riot chat.

In the previous episode of this series on chat, I discussed the protocol we chose to communicate between client and server: XMPP (Extensible Messaging and Presence Protocol). Today I'll dive into the mechanisms in place on the server-side and the architecture of the infrastructure, and I’ll discuss the work we’ve done to ensure that our servers are scalable and robust. Like the last article, I hope it’ll be interesting to anyone building out chat features to a distributed client base.

I spent a lot of time as a kid playing (generally, pretty terrible) games on my Game Boy. Having never written code for anything other than 'regular' general purpose computers before, I've been wondering recently: how easy is it to write a Game Boy (Advance) game?

This release includes significant changes to the implementation. The compiler tool chain was translated from C to Go, removing the last vestiges of C code from the Go code base. The garbage collector was completely redesigned, yielding a dramatic reduction in garbage collection pause times. Related improvements to the scheduler allowed us to change the default GOMAXPROCS value (the number of concurrently executing goroutines) from 1 to the number of logical CPUs. Changes to the linker enable distributing Go packages as shared libraries to link into Go programs, and building Go packages into archives or shared libraries that may be linked into or loaded by C programs (design doc).

In our exploration of alternate formats, we came across FlatBuffers, an open source project from Google. FlatBuffers is an evolution of protocol buffers that includes object metadata, allowing direct access to individual subcomponents of the data without having to deserialize the entire object (in this case, a tree) up front.

But the people calling for a bytecode for the browser never went away, and they were never entirely wrong about the perceived advantages. And now they're going to get their wish. WebAssembly is a new project being worked on by people from Mozilla, Microsoft, Google, and Apple, to produce a bytecode for the Web.

WebAssembly, or wasm for short, is intended to be a portable bytecode that will be efficient for browsers to download and load, providing a more efficient target for compilers than plain JavaScript or even asm.js. Like, for example, .NET bytecode, wasm instructions operate on native machine types such as 32-bit integers, enabling efficient compilation. It's also designed to be extensible, to make it easy to add, say, support for SIMD instruction sets like SSE and AVX.

Today we are very proud to announce the 1.0 release of Rust, a new programming language aiming to make it easier to build reliable, efficient systems. Rust combines low-level control over performance with high-level convenience and safety guarantees. Better yet, it achieves these goals without requiring a garbage collector or runtime, making it possible to use Rust libraries as a "drop-in replacement" for C. If you'd like to experiment with Rust, the "Getting Started" section of the Rust book is your best bet (if you prefer to use an e-reader, Pascal Hertleif maintains unofficial e-book versions as well).

I work for a certain corporation which uses a certain product. This is its story. To put the quality of this product into perspective, let me say it's been in development for about 20 years and has pretty much no users (besides my corp and some "hey - let's make our own Linux crappy distro, which no one will ever use" fanatics) and no community. It was written by a C programmer who "doesn't like the notion of 'type' in programming". Let that be a prelude of what's to follow. Envy those who don't know it; pity those who use it.

The product is called Enlightenment Foundation Libraries and it's the absolutely worst piece of shit software you can imagine.