Texas Instruments has long made graphing calculators beloved by school-goers and programmers alike. The calculators are simple, compact computing systems, and entire communities have formed over the years to celebrate the devices’ broad programming capabilities. All that’s about to change. Texas Instruments is pulling support for C-based and assembly-based programs on both the TI-84 Plus CE — the most popular calculator for sideloading — and the TI-83 Premium CE, its French sibling. The latest firmware for each completely removes the capability and leaves users with no way to roll back to previous versions of the firmware. Way back when I was in high school, I used to write my own TI-83 programs to… Well, to cheat on tests. These devices were a brand new addition to the education system at the time, and teachers had no clue what we as students were doing with them. One of my best friends and I also bought a communication cable for them so we could share stuff and play multiplayer games together in the back of class. Removing stuff like this is a terrible idea.
General Development Archive
Shells have been around forever and, for better or for worse, haven’t changed much since their inception. Until NuShell appeared to reinvent shells and defy our muscle memory. It brought some big changes, which include rethinking how pipelines work, structured input/output, and plugins. We wanted to learn more about NuShell so we interviewed both of its creators: Jonathan Turner and Yehuda Katz.
This release makes great progress in the C++20 language support, both on the compiler and library sides, some C2X enhancements, various optimization enhancements and bug fixes, several new hardware enablement changes and enhancements to the compiler back-ends and many other changes. There is even a new experimental static analysis pass. GCC is already 33 years old. That’s one heck of a legacy.
Colorado — like most states and territories across the country — is experiencing record unemployment numbers. But the state’s unemployment system is built on aging software running on a decades-old coding language known as COBOL. Over the years, COBOL programmers have aged out of the workforce, forcing states to scramble for fluent coders in times of national crisis. A survey by The Verge found that at least 12 states still use COBOL in some capacity in their unemployment systems. Alaska, Connecticut, California, Iowa, Kansas, and Rhode Island all run on the aging language. According to a spokesperson from the Colorado Department of Labor and Employment, the state was actually only a month or two away from “migrating into a new environment and away from COBOL,” before the COVID-19 pandemic hit. Are you one of the already 17 million people laid off in the US, losing what little health insurance you had in the process, and now you can’t even apply for unemployment assistance because some baby boomer coded the damn system in COBOL? Time to lift yourself up by the bootstraps and learn the wonders of COBOL!
The Cidco MailStation is a series of dedicated e-mail terminals sold in the 2000s as simple, standalone devices for people to use to send and receive e-mail over dialup modem. While their POP3 e-mail functionality is of little use today, the hardware is a neat Z80 development platform that integrates a 320×128 LCD, full QWERTY keyboard, and an internal modem. After purchasing one (ok, four) on eBay some months ago, I’ve learned enough about the platform to write my own software that allows it to be a terminal for accessing BBSes via its modem or as a terminal for a Unix machine connected over parallel cable. A year old story, but come on, this is timelessly cool.
Dropbox is a big user of Python. It’s our most widely used language both for backend services and the desktop client app (we are also heavy users of Go, TypeScript, and Rust). At our scale—millions of lines of Python—the dynamic typing in Python made code needlessly hard to understand and started to seriously impact productivity. To mitigate this, we have been gradually migrating our code to static type checking using mypy, likely the most popular standalone type checker for Python. (Mypy is an open source project, and the core team is employed by Dropbox.) This post tells the story of Python static checking at Dropbox, from the humble beginnings as part of my academic research project, to the present day, when type checking and type hinting is a normal thing for numerous developers across the Python community. It is supported by a wide variety of tools such as IDEs and code analyzers. I recently came across an article complaining about Python’s dynamic typing and couldn’t quite believe this was still the case. As it turns out, nowadays there is indeed a standardized way to do write type annotations and to type-check prior to runtime using mypy, all the while being driven forward by the good folks at Dropbox (which includes Python’s Benevolent Dictator for Life Guido van Rossum). This article provides a fascinating insider insight into the history of type-checking in Python and how it evolved in symbiosis with Dropbox’s codebase.
I have been curious about data compression and the Zip file format in particular for a long time. At some point I decided to address that by learning how it works and writing my own Zip program. The implementation turned into an exciting programming exercise; there is great pleasure to be had from creating a well oiled machine that takes data apart, jumbles its bits into a more efficient representation, and puts it all back together again. Hopefully it is interesting to read about too. This article explains how the Zip file format and its compression scheme work in great detail: LZ77 compression, Huffman coding, Deflate and all. It tells some of the history, and provides a reasonably efficient example implementation written from scratch in C. One for the ages. Articles like this don’t get written every day.
Under hard time pressure, the ground had to quickly figure out what was wrong and devise a workaround. What they came up with was the most brilliant computer hack of the entire Apollo program, and possibly in the entire history of electronic computing. To explain exactly what the hack was, how it functioned, and the issues facing the developers during its creation, we need to dig deep into how the Apollo Guidance Computer worked. Hold onto your hats, Ars readers—we’re going in. Amazing story.
This release represents a year of development effort and over 7,400 individual changes. It contains a large number of improvements that are listed in the release notes below. The main highlights are: – Builtin modules in PE format.– Multi-monitor support.– XAudio2 reimplementation.– Vulkan 1.1 support. Wine allows me to run virtually any Windows game I use on Linux – including League of Legends, my most-played game – so it’s a pretty amazing tool in my book. Since many people no longer directly interact with Wine, using it through tools like Steam’s compatibility tools or Lutris, instead, it’s easy to forget just how important of a project Wine really is.
This article demonstrates some of Magit’s most essential features in order to give you an impression of how the interface works. It also hints at some of the design principals behind that interface. But this is only the tip of the iceberg. Magit is a complete interface to Git, which does not limit itself to the “most essential features everyone needs”. I hope that this article succeeds in demonstrating how Magit’s focus on work-flows allows its users to become more effective Git users. Here we concentrate on some essential work-flows, but note that more advanced features and work-flows have been optimized with the same attention to detail. If you would rather concentrate on the big picture, then read the article Magit the magical Git interface instead (or afterwards). As a non-developer, I have no idea if this is a useful tool, but I do like the idea of it.
If ‘Hello World’ is the first program for C students, then printf() is probably the first function. I’ve had to answer questions about printf() many times over the years, so I’ve finally set aside time for an informal writeup. The common questions fit roughly in to two forms: Easy: How does printf mechanically solve the format problem?Complex: How does printf actually display text on my console? My usual answer? “Just open up stdio.h and track it down” This wild goose chase is not only a great learning experience, but also an interesting test for the dedicated beginner. Will they come back with an answer? If so, how detailed is it? What IS a good answer? This is incredibly detailed and definitely over my head, but I’m sure many of you will enjoy this one greatly.
RISC-V (“risk five”) and the Rust programming language both start with an R, so naturally they fit together. In this blog, we will write an operating system targeting the RISC-V architecture in Rust (mostly). If you have a sane development environment for RISC-V, you can skip the setup parts right to bootloading. Otherwise, it’ll be fairly difficult to get started. This tutorial will progressively build an operating system from start to something that you can show your friends or parents — if they’re significantly young enough. Since I’m rather new at this I decided to make it a “feature” that each blog post will mature as time goes on. More details will be added and some will be clarified. I look forward to hearing from you! Always wanted to to code your own operating system? This tutorial series shows how to create a simple operating system for RISC-V using Rust as your programming language. Currently the two first chapters are available. The code is also available on Github.
This release is the result of the LLVM community’s work over the past six months (up to trunk r366426 plus commits on the branch). Some highlights include: – Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang – The RISCV-V target is no longer experimental, but built by default – Experimental support for C++ for OpenCL As well as many bug fixes, optimizations, and diagnostics improvements. Read the release notes for the detailed information.
Today, we’re introducing a new shell, written in Rust. It draws inspiration from the classic Unix philosophy of pipelines, the structured data approach of PowerShell, functional programming, systems programming, and more. It’s called Nushell, or just Nu for short. We have a book (¡también se habla Español!). We have a repo.
This post recaps some of the C64 coding tricks used in my little Commodore 64 coding competition. The competition rules were simple: make a C64 executable (PRG) that draws two lines to form the below image. The objective was to do this in as few bytes as possible. These people are wizards.
The Visible Lisp Computer is a Lisp interpreter that displays the contents of the Lisp workspace on an OLED display, so you can see program execution and garbage collection in real time. It’s a special version of my uLisp interpreter for ARM boards, designed to run on an Adafruit ItsyBitsy M0, or an ATSAMD21E on a prototyping board, interfaced to an I2C OLED display. If I knew what any of this meant, you’d find a few words about this here. Sadly, I don’t know what any of this means.
Jupiter is an open source and education-oriented RISC-V assembler and runtime simulator. It is written in Java 11 and capable of simulate all the instructions of the base integer ISA (I extension) plus the M and F extensions (RV32IMF), including all the pseudo-instructions described in the user-level instruction set manual. It was developed taking into account that it could be used in various courses such as: Computer Architecture, Compilers and Assembly Programming.
I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness. Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why. Nothing to add.
In this talk, we’re going to look at how file systems differ from each other and other issues we might encounter when writing to files. We’re going to look at the file “stack” starting at the top with the file API, which we’ll see is nearly impossible to use correctly and that supporting multiple filesystems without corrupting data is much harder than supporting a single filesystem; move down to the filesystem, which we’ll see has serious bugs that cause data loss and data corruption; and then we’ll look at disks and see that disks can easily corrupt data at a rate five million times greater than claimed in vendor datasheets. Deeply technical, but well-written and pleasant to read.