Bridging A Gap Between LLMs And Programming With TypeChat

By now, large language models (LLMs) like OpenAI’s ChatGPT are old news. While not perfect, they can assist with all kinds of tasks like creating efficient Excel spreadsheets, writing cover letters, asking for music references, and putting together functional computer programs in a variety of languages. One thing these LLMs don’t do yet though is integrate well with existing app interfaces. However, that’s where the TypeChat library comes in, bridging the gap between LLMs and programming.

TypeChat is an experimental MIT-licensed library from Microsoft which sits in between a user and a LLM and formats responses from the AI that are type-safe so that they can easily be plugged back in to the original interface. It does this by generating JSON responses based on user input, making it easier to take the user input directly, run it through the LLM, and then use the output directly in another piece of code. It can be used for things like prototyping prompts, validating responses, and handling errors. It’s also not limited to a single LLM and can be fairly easily modified to work with many of the existing models.

The software is still in its infancy but does hope to make it somewhat easier to work between user inputs within existing pieces of software and LLMs which have quickly become all the rage in the computer science world. We expect to see plenty more tools like this become available as more people take up using these new tools, which have plenty of applications beyond just writing code.

Who’s Afraid Of Assembly Language?

This week, [Al Williams] wrote a great thought piece about whether or not it was worth learning an assembly language at all anymore, and when. The comments overflowed, and we’re surprised that so many people basically agree with us: yes. Of course, it’s a Hackaday crowd, but I still didn’t expect the outpouring of love for the most primitive of languages.

Assembly language isn’t really one language, though. Every chip speaks its own dialect. Of course there are similarities: every CPU has an add function, right? But almost no CPU has just one add – there are variants with and without carry, storing and reading from working registers or RAM. And once you start talking about memory access, direct or indirect, the individual architectures of the chips demand different assembly languages.

But still, although the particular ways that CPUs do what they do can be incompatible from a strictly language perspective, they are a lot more similar in terms of the programming idioms that you’ll pick up along the way. Just as learning a set of solid algorithms will help you no matter which higher-level language you use, learning the concepts behind crafting loops and simple memory structures out of raw assembly language will serve you no matter which CPU you choose.

I have only written assembly language for a handful of CPUs, and not much of it at that, but I’ve found the microcontrollers to be the friendliest. So if you want to dip your toes in that water, pick up an AVR or an MSP430. Or maybe even the new hotness – a RISC-V. You’ll find the instruction sets small enough that you have to do most of the work yourself. And that is, after all, the point of learning an assembly language: learning to think like the silicon. If you treat it like a fun puzzle to solve, you’ll probably even enjoy the experience.

[Al]’s original question was when you should learn an assembly language: before or after a higher-level language. For 99% of our readers, I’d say the answer is right now.

Modern Software Brings Back The Timex Datalink

As much as some people on the Internet might like to think — no, Apple did not come up with the idea of the smart watch. Even if you ignore the calculator watches that we imagine a full 60% of Hackaday readers wore at one time or another in their lives, the Timex Datalink was already syncing with computers and pulling down the user’s list of appointments back in 1994 by decoding the pulses of light produced by a CRT monitor. Hey, it sounded like a good idea at the time.

Unfortunately, this idea hasn’t aged well. The technique doesn’t work on more modern displays, and naturally the companion software to generate the flashing patterns was written for Windows 3.1. But thanks to the reverse engineering efforts of [Synthead], you can now sync any version of the Timex Datalink to your computer using nothing more complex than the onboard LED of the Teensy LC or Raspberry Pi Pico.

There’s actually several different projects working together to make this happen. In place of a CRT, there was an official “Timex Datalink Notebook Adapter” back in the day that was designed to be used on laptops and featured a single blinking LED. That’s what [Synthead] has recreated with timex-datalink-arduino, allowing a microcontroller to stand in for this gadget and featuring 100% backwards compatibility with the original Datalink software.

Appointment data is loaded from a text file.

But since you’re probably not rocking Windows 3.1 anymore, having access to that software is far from a given. That’s why [Synthead] also created timex_datalink_client, which is a Ruby library that lets you generate data fit for upload into the Timex Datalink. At the time of this writing there doesn’t seem to be a friendly user interface (graphical or otherwise) for this software, but it’s easy enough to feed data into it using plain-text configuration files.

Helpfully [Synthead] provides screenshots of information loaded into the original software, followed by a config file example that accomplishes the same thing. It looks like writing some glue code that pulls your schedule from whatever service you fancy and formats it for the Datalink client should be relatively simple.

We’ve previously seen projects that got the Timex Datalink synced without the need for a CRT, but they still required the original software. To our knowledge, this is the first complete implementation of the Datalink protocol that doesn’t rely on any original hardware or software. Expect eBay prices to go up accordingly.

Practical Inductors In LTSpice

LTSpice and the underlying Spice engine does a great job of simulating ideal components. But it is also capable — if you know how — of handling models of real-world devices. Inductors, for example, are one of the most imperfect components. Their constituent wire has resistance, and there is parasitic capacitance between the windings. If there is a core, it also will have many imperfections and losses. [Sam Ben-Yaakov] has a lecture about modeling real inductors in LTSpice, and he covers how you can capture some of these imperfections in the video below.

There is a bit of math in the presentation, but we liked that it relates back to datasheets for actual components. Being able to understand what the parameters on a datasheet mean is crucial, and if you ever wondered what some of these entries mean, you’ll get a lot from this video.

The main feature of the model is the flux equation. The tanh (hyperbolic tangent) function is similar to the curve you want for the flux equation, so it plays a major part. Of course, there are other parts of the inductor you may have to model, too, but this is one of the most difficult parts.

You can also model transformers using LTSpice. You can also create custom components.

Continue reading “Practical Inductors In LTSpice”

Illumos Gets A New C Compiler

Illumos is an OpenSolaris-derived Unix system, and no Unix is complete without a C compiler or two. And with a name like Portable C Compiler (PCC), you would think that would be a great bet to get up and running on Illumos. That’s probably what [Brian Callahan] thought, too, but found out otherwise.

PCC already generates x86 code, so that wasn’t the problem. It was a matter of reconfiguring the compiler for the environment, ironic since PCC probably started on true Unix but now won’t work with 64-bit Solaris-like operating system. According to the post:

It looks like some time ago someone added configuration for 32-bit x86 and SPARC64 support for the Solaris family. But no one ever tried to support 64-bit x86. So first we had to teach the configure script for both pcc and pcc-libs that 64-bit x86 Solaris

Continue reading “Illumos Gets A New C Compiler”

Phone Thermal Cameras Get Open Source Desktop Tools

Whenever phone-based thermal cameras are brought up here on Hackaday, we inevitably receive some comments about how they’re a bad investment compared to a standalone unit. Sure they might be cheaper, but what happens in a couple years when the app stops working and the manufacturer no longer feels like keeping it updated?

It’s a valid concern, and if we’re honest, we don’t like the idea of relying on some shady proprietary app just to use the camera in the first place. Which is why we’re so excited to see open source software being developed that allows you to use these (relatively) inexpensive cameras on your computer. [Les Wright] recently sent word that he’s been working on a project called PyThermalCamera which specifically targets the TOPDON TC001, which in turn is based on a project called P2Pro-Viewer developed by LeoDJ for the InfiRay P2 Pro.

Readers may recall we posted a review of the P2 Pro last month, and while the compact hardware was very impressive, the official Android software lacked a certain degree of polish. While these projects won’t help you on the mobile front in their current form, it’s good to know there’s at least a viable “Plan B” if you’re unwilling or unable to use the software provided from the manufacturer. Naturally this also opens up a lot of new possibilities for the camera, as being connected to a proper Linux box means you can do all sorts of interesting things with the video feed.

The two video feeds on the left are combined to produce the final thermal image.

Speaking of the video feed, we should say that both of these projects were born out of a reverse engineering effort by members of the EEVblog forums. They figured out early on that the InfiRay (and other similar models) were picked up as a standard USB video device by Linux, and that they provided two video streams: one being a B&W feed from the camera where the relative temperature is used as luminance, and the other containing the raw thermal data cleverly encoded into a green-tinted video. With a little poking they found an FFmpeg one liner that would combine the two streams, which provided the basis for much of the future work.

In the video below, you can see the review [Les] produced for the TOPDON TC001, which includes a demonstration of both the official Windows software and his homebrew alternative running on the Raspberry Pi. Here’s hoping these projects inspire others to join in the effort to produce flexible open source tools that not only unlock the impressive capabilities of these new thermal cameras but save us from having to install yet another smartphone application just to use a device we purchased.

Continue reading “Phone Thermal Cameras Get Open Source Desktop Tools”

Jenny’s Daily Drivers: Slackware 15

As a recent emigre from the Ubuntu Linux distribution to Manjaro, I’ve had the chance to survey the field as I chose a new distro, and I realised that there’s a whole world of operating systems out there that we all know about, but which few of us really know. Hence this is the start of what I hope will be a long-running series, in which I try different operating systems in my everyday life as a Hackaday writer, to find out about them and then to see whether they can deliver on the promise of giving me a stable platform on which to earn a living.

For that they need an internet connection and a web browser up-to-date enough to author Hackaday stories, as well as a decent graphics package. In addition to using the OS every day though, I’ll also be taking a look at what makes it different from all the others, what its direction and history is, and how user-friendly it is as an experience. Historical systems such as CP/M are probably out of the question as are extremely esoteric ones such as the famous TempleOS, but this still leaves plenty of choice for an operating system tourist. Join me then, as I try all the operating systems.

A Distro From The 1990s, Today

A desktop mini tower PC with monitor showing the Slackware boot screen
The Hackaday test PC gets its first outing.

When deciding where to start on this road, there was an obvious choice. Slackware was the first Linux-based distribution I tried back in 1995, I’m not sure which version it was , but it came to me via a magazine coverdisk. It was by no means the first OS that captured my attention as I’d been an Amiga user for quite a few years at that point, but at the moment I can’t start with AmigaOS as I don’t have nay up-to-date Amiga-compatible hardware.

July 2023 also marks the 30th anniversary for the distro making it the oldest one still in active development, so this seems the perfect month to start this series with the descendant of my first Linux distro. Slackware 15 comes as a 3.8 GB ISO file download for 64-bit computers, and my target for the distro was an old desktop PC with an AMD processor and a big-enough spinning rust hard disk which had been a high-end gaming system a little over ten years ago. Not the powerhouse it once was, but it cost me nothing and it’s adequate for my needs. Installed on a USB Flash drive the Slackware installer booted, and I was ready to go. Continue reading “Jenny’s Daily Drivers: Slackware 15”