Fossil Files: My .Emacs

Last week, I wrote about cargo culting in a much more general context, so this week I’m going to come clean. The file that had me thinking about the topic was the worst case you’ve probably ever seen: I have a .emacs file kicking around that I haven’t really understood since I copied it from someone else – probably Ben Scarlet whose name is enshrined therein – in the computer lab in 1994! Yes, my .emacs file is nearly 30, and I still don’t really understand it, not exactly.

Now in my defence, I switched up to vim as my main editor a few years ago, but this one file has seen duty on Pentiums running pre-1.0 versions of Linux, on IBM RS/6000 machines in the aforementioned computer lab, and on a series of laptops and desktops that I’ve owned over the years. It got me through undergrad, grad school, and a decade of work. It has served me well. And if I fired up emacs right now, it would still be here.

For those of you out there who don’t use emacs, the .emacs file is a configuration file. It says how to interpret different files based on their extensions, defines some special key combos, and perhaps most importantly, defines how code syntax highlighting works. It’s basically all of the idiosyncratic look-and-feel stuff in emacs, and it’s what makes my emacs mine. But I don’t understand it.

Why? Because it’s written in LISP, for GNU’s sake, and because it references all manner of cryptic internal variables that emacs uses under the hood. I’m absolutely not saying that I haven’t tweaked some of the colors around, or monkey-patched something in here or there, but the extent is always limited to whatever I can get away with, without having to really learn LISP.

This ancient fossil of a file is testament to two things. The emacs codebase has been stable enough that it still works after all this time, but also that emacs is so damn complicated and written in an obscure enough language that I have never put the time in to really grok it – the barriers are too high and the payoff for the effort too low. I have no doubt that I could figure it out for real, but I just haven’t.

So I just schlep this file around, from computer to computer, without understanding it and without particularly wanting to. Except now that I write this. Damnit.

Featured image: “A Dusty Old Book” by Marco Verch Professional.

Create A Compiler Step-By-Step

While JavaScript might not be the ideal language to write a production compiler, you might enjoy the “Create Your Own Compiler” tutorial that does an annotated walkthrough of “The Super Tiny Compiler” and teaches you the basics of writing a compiler from scratch.

The super tiny compiler itself is about 200 lines of code. The source code is well, over 1,000 but that’s because of the literate programming comments. The fancy title comments are about half as large as the actual compiler.

The compiler’s goal is to take Lisp-style functions and convert them to equivalent C-style function calls. For example: (add 5 (subtract 3 1) would become add(5,subtract(3,1)).

Of course, there are several shortcut methods you could use to do this pretty easily, but the compiler uses a structure like most full-blown modern compilers. There is a parser, an abstract representation phase, and code generation.

Continue reading “Create A Compiler Step-By-Step”

Lisp In 436 Bytes

You would assume that any programming language available back in the 1960s would be small enough to easily implement on today’s computers. That’s not always true though, since old languages sometimes used multiple passes. But in some cases, you can implement what would have been a full language decades ago in a tiny footprint. A case in point is a pretty good implementation of Lisp — including garbage collection — in 436 bytes.

SectorLISP claims to be the tiniest real language, beaten only by toy languages that are not really very useful. If you want to, you can try it in your browser, but that version has better error messages and persistent bindings, so it hogs up a whole 509 bytes.

Continue reading “Lisp In 436 Bytes”

AVR Bare Metal With Lisp

There are two kinds of programmers: those who don’t use Lisp, and those who need new parenthesis keycaps every six months. Lisp is one of those languages you either really love or really hate. If you love it, you may have checked out ulisp, which runs on Arduino boards of the AVR and ARM variety, as well as ESP chips, RISC-V, and others. A recent update allows the language to insert assembler into AVR programs.

We probably don’t need to convince anyone reading Hackaday why adding assembler is a good thing. It seems to integrate well with the environment, too, so you can write assembler macros in Lisp, which opens up many possibilities.

Continue reading “AVR Bare Metal With Lisp”

Stay Focused With This Distraction Free Cyberdeck

While on the surface they might seem like little more than cosplay accessories, there are perfectly valid and practical reasons for building a custom cyberdeck. For one thing, a hand-built deck is going to be easier to upgrade and modify down the line. A bespoke rig can also be made to fit your exacting specifications, with each and every design choice made specifically to support your personal style and workflow.

For [Conrad Barski], that meant a computer that would stay out of his way and allow him to take notes and write code while keeping distractions to the absolute minimum. All he wanted in his dream machine was a nice mechanical keyboard, a widescreen display, and enough battery power to go mobile should the need arise. Anything else would be gilding the lily. For those who want to distill personal computing down to its simplest form, this build is really the high water mark.

[Conrad] is currently in the early stages of turning his Lisperati1000 into a kit others can build for themselves, so details are a bit sparse at the moment. But we do know there’s a Raspberry Pi Zero W, a Vortex Core 40% keyboard, and 4,400 mAh worth of battery power wrapped up in that slick 3D printed enclosure. Readers may recognize the 1920×480 ultra-wide LCD from the modernized TRS-80 Model 100 we covered recently, or perhaps the gorgeously reimagined retro terminals of [Oriol Ferrer Mesià]. If you’ve got retro-futurism on the brain, this seems to be the display to beat.

Whether you want to explore vintage computing, stylishly take control of your custom race car, or cruise the airwaves with an integrated software defined radio, a completely custom portable computing device can make for an interesting alternative to another ho-hum laptop from the Big Box electronics store.

The Strangest Gameboy Emulator We’ve Seen Yet

In the secret Hackaday bunker, we have some emacs users, some vi users, and some people who don’t really care. However, even the staunchest of our emacs supporters had to do a double take at [Vreeze’s] project that creates a GameBoy emulator using the venerable text editor. You can see [Alexei Nunez’s] reaction to the emulator in the video below.

The Eboy uses unicode characters to output the graphics. You can use emacs commands to load ROM images and use your keyboard to control the game.

Continue reading “The Strangest Gameboy Emulator We’ve Seen Yet”

Program This Badge In Lisp

This hardware badge is a computer programmed with Lisp. You can write your own programs right on the badge using the built-in keyboard, as long as you know Lisp.

If there’s one thing we really like to see, it’s people advancing their own projects based on inspiration from others. The Lisp Badge by [David Johnson-Davies] is a perfect example. With an interface inspired by [Voja Antonic’s] hardware design for the 2018 Hackaday Belgrade Conference Badge, this version is an upgrade of an earlier single-board Lisp machine, now sporting an integrated keyboard.

Unlike the Belgrade badge, which is programmed in BASIC, this new badge is programmed in uLisp, a subset of common lisp designed for microcontrollers. Let’s face it, BASIC is retro, but Lisp is even more so, only pre-dated by FORTRAN as the oldest high-level language. So, if you’re into retro-style programming on small devices (physically small, that is), you should consider building one of these.

A 16 MHz ATmega 1284P serves as the badge’s brain, allowing storage for 2,816 Lisp cells, while the 256×64 pixel OLED display shows 8 lines of 42 characters in 16 gray levels. A full complement of I/O connections includes four analog inputs, two analog outputs, I2C, SPI, serial, and a handful of GPIOs for interfacing with just about anything. Power comes from a LiPO battery, which at a nominal voltage of 3.7 V doesn’t quite meet the datasheet requirements for running the processor at 16 MHz, although it seems to work fine in practice. Really cautious builders could opt for a 12 MHz crystal transplant to avoid any possibility of problems.

The keyboard layout is optimized for uLisp programming: unnecessary keys have been removed and the all-important parenthesis are afforded their own dedicated keys on the bottom row. This is presumably for convenience of use, but we suspect this will also make it easier to replace the parenthesis key switches when they inevitably wear out from overuse [obligatory Lisp/parenthesis joke].

As far as entering uLisp programs, you can simply use the keyboard. The built-in editor buffers a full screen of text, and includes parenthesis matching that highlights each pair as you type. We’re guessing that we won’t see Emacs implemented in the near future, so this bracket management is a great feature for a badge-based editor. If you find the keyboard difficult to type on, you can also enter programs over the serial port.

The other thing we really like to see is open-source projects. [David] doesn’t let us down on this point, either. The Eagle design files for the PCB as well as the source code for the badge are available on GitHub. The PCB is also shared on OSH Park, and there are detailed instructions for installing the bootloader and uploading the code.

If programmable badges is your thing, also check out the 2018 Hackaday Supercon Badge, the successor the Belgrade design.

Thanks to [Sven] for the tip!