On 16th June 2014, Jeremiah Heaton declared 2,060km2 of arid land in Africa as the Kingdom of North Sudan, after promising his daughter that one day she would become a Princess.
Heaton, a farmer from the US state of Virginia, had been looking for unclaimed territory around the world and after some research settled on an area known as Bir Tawil, an uninhabited piece of land between Egypt and Sudan.
Due to two conflicting treaties drawn up by the British, both Egypt and Sudan interpreted the treaties as they saw fit. A claim on a piece of land close to Bir Tawil would disqualify the party from claiming Bir Tawil itself, and since the former enjoyed prospective mineral wealth, both sides claim this land as their own. Bir Tawil ended up a ‘terra nullius’ – land that belongs to no one until this was claimed by Heaton himself.
JWCC is a minimal extension to the widely used JSON file format with (1) optional commas after the final element of arrays and objects and (2) C/C++ style comments. These two features make it more suitable for human-editable configuration files, without adding so many features that it’s incompatible with numerous other (deliberate and accidental) existing JSON extensions.
Over the last 25 years, I’ve written a lot of event-driven code in C++. A typical example of event-driven code is registering a callback that gets invoked every time a socket has data to be read. Once you have read an entire message, possibly after many invocations, you parse the message and invoke another callback from a higher layer of abstraction, and so forth. This kind of code is painful to write because you have to break your code up into a bunch of different functions that, because they are different functions, don’t share local variables.
This is still an experiment and isn’t intended for real use yet. The biggest issue is that the generated code currently doesn’t delete anything (garbage collection is planned but not yet implemented). Also the WebAssembly specification is still being developed and the current binary format will stop working when WebAssembly is officially released.
In the first post in the Ruby Garbage Collection Deep Dive series, we went through a few definitions to give us a picture of how Ruby stores values in memory. If you haven’t read it yet, read it first! We’ll build on those definitions in this post. Particularly, we’ll talk more about the Ruby Heap, Pages, Slots and RVALUES.
Okay, now that we have those baseline definitions out of the way, this post is going to explain the algorithm Ruby’s garbage collector uses to determine which objects it can collect: the Tri-Color Mark and Sweep algorithm. There are two phases to this algorithm. You guessed it: marking and sweeping. In the marking phase, the garbage collector marks all slots which contain accessible RVALUES. In the sweeping phase, the garbage collector clears the RVALUES out of all slots which are not marked. Let’s dig in!
Submodules specifically have managed to be a thorn in my side on many occasions. While the concept of submodules is simple, figuring out how to actually work with them can be a chore. I say “figuring out” because not everything about working with submodules is well documented. I’ll cover two of the more difficult things to figure out: removing and updating submodules from your repository.
Ask anyone the identity of the world’s most famed turtles, and the answer is likely to be those legendary heroes in a half-shell, the Teenage Mutant Ninjas. Since first appearing in comic book form in 1984, the pizza-eating, nunchuk-wielding characters have shown the world the tougher side of turtles.
Part of the appeal of the Teenage Mutant Ninja Turtles is that, as animals, they seem to be playing against type. Turtles in the modern day are usually considered placid animals, an image exemplified by the easygoing surfer-turtle, Crush, in Finding Nemo.
To humans, the dawdling turtle is generally perceived as non-threatening. (An important exception here is made for the turtle with an accomplice. The Greek poet Aeschylus is said to have been killed by a tortoise dropped from the sky by an eagle). Indeed, the turtle’s “gentle” image may partially explain the animal’s enduring popularity with children.
Today the Go team is very happy to announce the release of Go 1.16. You can get it from the download page.
The new embed package provides access to files embedded at compile time using the new //go:embed directive. Now it is easy to bundle supporting data files into your Go programs, making developing with Go even smoother. You can get started using the embed package documentation. Carl Johnson has also written a nice tutorial, “How to use Go embed”.
Go 1.16 also adds macOS ARM64 support (also known as Apple silicon). Since Apple’s announcement of their new arm64 architecture, we have been working closely with them to ensure Go is fully supported; see our blog post “Go on ARM and Beyond” for more.
Note that Go 1.16 requires use of Go modules by default, now that, according to our 2020 Go Developer Survey, 96% of Go developers have made the switch. We recently added official documentation for developing and publishing modules.
Finally, there are many other improvements and bug fixes, including builds that are up to 25% faster and use as much as 15% less memory. For the complete list of changes and more information about the improvements above, see the Go 1.16 release notes.
Macros are a language feature which is very far in the “more power” side of the chart. Macros give you an ability to abstract over the source code. In exchange, you give up the ability to (automatically) reason about the surface syntax. As a specific example, rename refactoring doesn’t work 100% reliably in languages with powerful macro systems.
I do think that, in the ideal world, this is a wrong trade for a language which wants to scale to gigantic projects. The ability to automatically reason about and transform source code gains in importance when you add more programmers, more years, and more millions of lines of code. But take this with a huuuge grain of salt — I am obviously biased, having spent several years developing Rust IDEs.
That said, macros have a tremendous appeal — they are a language designer’s duct tape. Macros are rarely the best tool for the job, but they can do almost any job. The language design is incremental. A macro system relives the design pressure by providing a ready poor man’s substitute for many features.
In this post, I want to explore what macros are used for in Rust. The intention is to find solutions which do not give up the “reasoning about source code” property.
Have you ever started on some creative work, and given yourself an arbitrary restriction within which to do it? Like making some pixel art, but you will only use black or white pixels. I think it’s quite a fun way to drive the creative and problem solving juices, to test the limits of the restriction and learn new techniques.
Anyone who ever tried to cross-compile a C/C++ program knows how big a PITA the whole process could be. The main reasons for this sorry state of things are generally how byzantine build systems tend to be when configuring for cross-compilation, and how messy it is to set-up your cross toolchain in the first place…
While simple I/O code in Haskell looks very similar to its equivalents in imperative languages, attempts to write somewhat more complex code often result in a total mess. This is because Haskell I/O is really very different in how it actually works.
The following text is an attempt to explain the details of Haskell I/O implementations. This explanation should help you eventually learn all the smart I/O tips. Moreover, I’ve added a detailed explanation of various traps you might encounter along the way. After reading this text, you will be well on your way towards mastering I/O in Haskell.
In the two most recent posts we focused on the Python object system. We learned what Python objects and Python types are, how they are defined and what determines their behavior. This discussion gave us a good understanding of how Python objects work in general. What we haven’t discussed is how particular objects, such as strings, integers and lists, are implemented. In this and several upcoming posts we’ll cover the implementations of the most important and most interesting built-in types. The subject of today’s post is
Recent archaeological discoveries have shed new light on the history of Peru’s Chachapoya people. Until the 1990s most of what we knew about this pre-Columbian culture – referred to as the ‘Warriors of the Clouds’ by the Inca – was based on third-hand stories from unreliable Spanish chroniclers. Even today, the Chachapoya jigsaw has more gaps than pieces. Yet interest and knowledge in the erstwhile civilisation is growing. In 2017, the hilltop Chachapoya ruins of Kuélap were equipped with a cable car and marketed by the Peruvian government as a northern rival to Machu Picchu. Two years later Unesco placed the ‘Chachapoyas sites of the Utcubamba Valley’ on its tentative list of World Heritage Sites being considered for nomination…