housel

I worked for him as well, from 1988 through 1990. He mentored me as I helped sysadmin various BSD machines the university was beta-testing (CCI Tahoe and Gould NP-1), and supervised my work fixing bugs in the Berkeley Pascal compiler. It was fun watching him put his early-model Motorola cell phone into service mode and tweak register values... while he was driving. And of course I enjoyed finding him in his office at all sorts of weird hours and listening to him rant about various technical topics.

The ADM3a was just a UART chip, RAM chips, character ROMs, and a bunch of 74LS chips to glue it all together. No CPU, and no way to generate graphics.

Given that it's an essential/definitional issue, I would have preferred that the author at least showed awareness of the differences between languages intended for marking up text and languages intended to represent data in a structured way.

Back when XML was first being developed, I was really anticipating having a standardized, easier-to-implement successor to SGML (which was hampered by its complexity and by the cost of the ISO standard) in the text markup space. It was that disappointing it ended up filling the vacuum in the space of serialized representations for for structured data, then getting rejected when it wasn't quite as suitable for that as alternatives such as JSON.

Yes, we overlapped around then.

I was a student part-time administrator/systems programmer at the Purdue Engineering Computer Network at the time. Our OS installs had enough local mods (and we had enough non-VAX, non-Sun architectures) that we were immune to some of the worm's modalities, but the sendmail debug mode exploit at least still caused a lot of consternation.

"clang -Xclang -ast-dump=json" will take you partway there.

Though "null pointer" and "null value" are correct, for bytes it should be "NUL byte", since ASCII code point 0 is NUL.

Depends on when "back in the day" was; even in the mid-to-late 80s, especially if you were on a multi-user system, on BSD 4.2/4.3 local and networked printer access went through the Line Printer Daemon (still available on the BSDs).

For PostScript printers, there was a filter application (provided by Adobe) that would turn plain text (without the %! magic) into PostScript.

At a previous employer we generated assemblers and disassemblers for various DSP cores based on an Excel spreadsheet that the software tools team shared with the processor architects. The spreadsheet cells described the layout of the various instruction fields; this was converted with a script to an architecture description DSL, from which the assembler, disassembler, and other tools could be generated. Another DSL described the pipeline stalls and hazards, and code generated from the combined descriptions drove instruction schedulers and code checkers.

There is the Inkplate (https://www.crowdsupply.com/soldered/inkplate-5), which has an ESP32 and so should be just as hackable as a Linux system.

While I couldn't find any characters with more than three or four readings in this list, the Taiwan list (https://language.moe.gov.tw/files/people_files/%e5%88%9d%e7%...) has one character with five readings (著) and one with six (和). Still a long way from 15, though.

Overall this is helpful, but it seems a bit ranty, and doesn't do as much as (for example) John Day's Patterns in Network Architecture to provide a positive alternative model.

A lot of Douyin content ends up on YouTube Shorts if you know where to look.

This is a serious criticism... even if it's not likely to catch on enough to have a real effect on the sea level, it is a complete waste of energy to accomplish something that could be done much more efficiently some other way, if it is indeed worth doing at all.

There's no special "bootstrap compiler"; you can download a binary release for your platform from the page you linked, and then use that to bootstrap a newer version from a source checkout. If it would help, we could provide a minimalistic build that was only useful for bootstrapping, but at present our builds are "batteries included" (with LLVM/Clang and the BDW garbage collector already provided in the tarball).

(Open) Dylan is surviving just fine, and we expect to do a new release later this month.

I think it would be great to experiment with building this sort of thing for an e-ink tablet, adding an enhanced layer of interactivity to by-hand notetaking.

I have a hard copy of this issue; it predated my subscription to Byte by a couple years, but I was able to purchase it as a back issue some time in the early 80s.

Fairness doctrine made sense at the time because broadcast spectrum was a very scarce resource. When cable and Internet are available to disseminate a broad range of viewpoints, it's no longer necessary for the FCC to be involved in regulating speech.

Supabase is featured in the latest episode of the IEEE SE-Radio podcast: https://www.se-radio.net/2022/05/episode-511-ant-wilson-on-s...

The name CodeWarrior is now used by NXP for development tools targeting legacy (old Motorola/Freescale) platforms; see for instance https://www.nxp.com/design/software/development-software/cod...

At that point it was probably the free Franz Lisp that was included in BSD Unix 4.2 or 4.3, which had an interpreter and compiler (with basically MACLISP semantics so it could run Macsyma) on VAX and mc68k platforms. As an undergraduate in 1986 I ported it to the CCI Tahoe, which was a VAX clone with a slightly simplified instruction set (and the main platform on which the BSD 4.3Tahoe release was developed).

TeX (and Metafont, and the original Tangle and Weave) were written in Pascal, which is much more rigid with respect to ordering than early C was. The CWEB used for the Stanford Graphbase came later. (Silvio Levy did the initial adaptation of Pascal WEB to C, and Knuth took it over when he switched to programming in C.)

I got a TRS-80 Model I when I was 14. For the next four years, I didn't have a disk drive, and was stuck with the 500bps cassette interface for storage. When I finally did get a disk drive, I didn't want to spend $50 purchasing the DOS edition of the Z-80 assembler when I already owned the cassette version. So, instead, I used TASMON to reverse-engineer the edition I had, relocated the assembler/editor program into a memory range that would run under DOS, and patched in new disk load/save routines (written, naturally, in Z-80 assembly). I don't think I ever built anything particularly innovative for the Model I, but I got a lot of neat learning experiences like this one out of it.

https://maskray.me/blog/ has plenty of solid information on the LLVM and GCC/Binutils toolchains.

BSD 4.3 still used the Portable C Compiler. By 4.4 Berkeley was starting to use GCC, but that wasn't available in time to incorporate into A/UX. Plus, IIRC the GNU project was actively boycotting Apple at the time, and so Apple was probably adverse to incorporating any GNU software.

People may also find interesting the Open Dylan project's alternative implementation of an LLVM bitcode writer, https://github.com/dylan-lang/opendylan/blob/master/sources/... and https://github.com/dylan-lang/opendylan/blob/master/sources/...

No, the Model II had only a 4MHz Z-80. The Model 16 (and later the Model 6000) had a 68k-series coprocessor, and Xenix ran in that (using the Z-80 for I/O).

Do we know what distribution they use?

Opportunity lost or not, we're sticking with it, including preparing for a new release in the next few days (see our testing pre-release at https://github.com/dylan-lang/opendylan/releases/tag/v2020.1...).