Wolverine Gives Your Python Scripts The Ability To Self-Heal

April 9, 2023 by Donald Papp 38 Comments

[BioBootloader] combined Python and a hefty dose of of AI for a fascinating proof of concept: self-healing Python scripts. He shows things working in a video, embedded below the break, but we’ll also describe what happens right here.

The demo Python script is a simple calculator that works from the command line, and [BioBootloader] introduces a few bugs to it. He misspells a variable used as a return value, and deletes the subtract_numbers(a, b) function entirely. Running this script by itself simply crashes, but using Wolverine on it has a very different outcome.

In a short time, error messages are analyzed, changes proposed, those same changes applied, and the script re-run.

Wolverine is a wrapper that runs the buggy script, captures any error messages, then sends those errors to GPT-4 to ask it what it thinks went wrong with the code. In the demo, GPT-4 correctly identifies the two bugs (even though only one of them directly led to the crash) but that’s not all! Wolverine actually applies the proposed changes to the buggy script, and re-runs it. This time around there is still an error… because GPT-4’s previous changes included an out of scope return statement. No problem, because Wolverine once again consults with GPT-4, creates and formats a change, applies it, and re-runs the modified script. This time the script runs successfully and Wolverine’s work is done.

LLMs (Large Language Models) like GPT-4 are “programmed” in natural language, and these instructions are referred to as prompts. A large chunk of what Wolverine does is thanks to a carefully-written prompt, and you can read it here to gain some insight into the process. Don’t forget to watch the video demonstration just below if you want to see it all in action.

While AI coding capabilities definitely have their limitations, some of the questions it raises are becoming more urgent. Heck, consider that GPT-4 is barely even four weeks old at this writing.

Continue reading “Wolverine Gives Your Python Scripts The Ability To Self-Heal” →

Pi Microcontroller Still Runs A Webserver

April 7, 2023 by Bryan Cockfield 14 Comments

At first glance, the Raspberry Pi Pico might seem like a bit of a black sheep when compared to the other offerings from the Raspberry Pi Foundation. While most of the rest of their lineup can run Linux environments with full desktops, the Pico is largely limited to microcontroller duties in exchange for much smaller price tags and footprints. But that doesn’t mean it can’t be coerced into doing some of the things we might want a mainline Pi to do, like run a web server.

The project can run a static web page simply by providing the Pico with the project code available on the GitHub page and the HTML that you’d like the Pico to serve. It can be more than a static web page though, as it is also capable of running Python commands through the web interface as well. The server can pass commands from the web server and back as well, allowing for control of various projects though a browser interface. In theory this could be much simpler than building a physical user interface for a project instead by offloading all of this control onto the web server instead.

The project not only supports the RP2040-based Raspberry Pi Pico but can also be implemented on other WiFi-enabled microcontroller boards like the ESP8266 and ESP32. Having something like this on hand could greatly streamline smaller projects without having to reach for a more powerful (and more expensive) single-board computer like a Pi 3 or 4. We’ve seen some other builds on these boards capable of not only running HTML and CSS renderers, but supporting some image formats as well.

Continue reading “Pi Microcontroller Still Runs A Webserver” →

Bus Stop Bloom Filter

March 27, 2023 by Matthew Carlson 19 Comments

Imagine you’re sitting on a nice bench, the sun shines warmly, and a bus pulls up. You’re headed to Stendal from Osnabrück, how can you tell if you should get on that bus? [Julian Vanecek] is trying to turn that from an O(n) problem to an O(1) one with a Bloom filter right at the bus stop.

In [Julian’s] sample code, each stop is a 3-bit number that can be encoded into a 192-bit array. Your ticket is just that 3-bit number encoded, so you can look at the graphic on the side of the incoming bus, match it against your ticket, and hop on. Gone are the days of waiting for the little LED screen to cycle through all the stops, waiting for yours to come up. Your ticket should have just a few boxes filled in so it is relatively quick to search against the bus’s graphic.

Of course, there is a potential for a false positive rate. [Julian] points out that this can be tuned to prevent errors and has achieved a < 0.5% false positive rate using the Deutsche Bahn bus system. The code is written in Python and available on GitHub. Perhaps buses could have a large flip-dop display on the side, to adjust to show which stops they’re headed to next. Additionally, it doesn’t encode which stops are next, just which stops the bus will eventually go to.

In the video after the break, [Julian] explains how the system works. Whether it would be ultimately adopted is somewhat beside the point. We love the seeing people re-imagining ideas and trying to apply new techniques to improve the things around them.

Continue reading “Bus Stop Bloom Filter” →

OpenSPICE: A Portable Python Circuit Simulator

February 14, 2023 by Dave Rowntree 22 Comments

[Roman Parise] and [Georgios Is. Detorakis] have created OpenSPICE a fork of the PySpice project, adding a new simulation engine written entirely in Python. This enables the same PySpice simulations to be executed on any platform that runs python (which we reckon is quite a few!) whilst leveraging the full power of the python infrastructure. Since it is a fork — for supported platforms — you can also run your simulations upon Ngspice as well as Xyce, giving options for scaling up to larger systems when required, but importantly without having to recreate your circuit from scratch.

The OpenSPICE simulator first converts the parsed netlist into a set of data structures that represent the equations describing the various parts of the system. These are then in turn passed along the scipy library “optimize.root” function which solves the system, generating a list of branch currents and node voltages. The output of the simulation is a numpy array, which can be further processed and visualized with the mathplotlib library. All pretty standard stuff in python circles. Since this is based upon PySpice, it’s also possible to use KiCAD netlists, so you have a nice way to enter those schematics. We’ve not dug into this much yet, but support for the vast libraries of spice models out there in circulation would be high up on our wish list if it already can’t handle this. This scribe will most definitely be checking this out, as LTSpice whilst good, is a bit of a pain to use and does lack the power of a Python backend!

Continue reading “OpenSPICE: A Portable Python Circuit Simulator” →

Hacking The Python For Loop

February 5, 2023 by Al Williams 33 Comments

In the early days of C, you’d occasionally see someone — probably a former Pascal programmer — write something like this:

#define BEGIN {
#define END }

This would usually initiate complaints about abusing the preprocessor and generally being anti-C. Surely no modern language would permit such things, right? Perhaps not. Consider [Tushar Sadhwani] who wanted to create a classic C-style for loop inside of Python. He did it, and the journey is perhaps more interesting than the result.

First, you can’t just transport straight C for loops into Python. There has to be some concession to Python syntax. The initial attempt was clever but not clever enough. However, the disassembly of the Python code was telling. The second attempt, however, was particularly interesting.

That attempt used an odd feature to examine the interpreter’s tree structure for the code and then modify it. This is sort of like a very painful C preprocessor but more powerful. That version works although it is pretty convoluted.

Ironically, [Tushar] then set up a third attempt after seeing code that tries to replace Python indentation with braces using a codec. In Python-speak, a codec lets you convert different text encodings. However, you can do other things than text encoding conversion. This is closest in spirit to the C preprocessor method. You can wade through the source code ahead of processing and make whichever changes you see fit.

Is any of this really useful? Probably not as it is. But you never know when you might need to do something exotic and one of these techniques could save the day. You probably couldn’t get away with some of this on MicroPython, of course. Your mileage may vary depending on where you find your Python running — like the Web.

Giving An Old Typewriter A Mind Of Its Own With GPT-3

January 15, 2023 by Dan Maloney 27 Comments

There was an all-too-brief period in history where typewriters went from clunky, purely mechanical beasts to streamlined, portable electromechanical devices. But when the 80s came around and the PC revolution started, the typewriting was on the wall for these machines, and by the 90s everyone had a PC, a printer, and Microsoft Word. And thus the little daisy-wheel typewriters began to populate thrift shops all over the world.

That’s fine with us, because it gave [Arvind Sanjeev] a chance to build “Ghostwriter”, an AI-powered automatic typewriter. The donor machine was a clapped-out Brother electronic typewriter, which needed a bit of TLC to bring it back to working condition. From there, [Arvind] worked out the keyboard matrix and programmed an Arduino to drive the typewriter, both read and write. A Raspberry Pi running the OpenAI Python API for GPT-3 talks to the Arduino over serial, which basically means you can enter a GPT writing prompt with the keyboard and have the machine spit out a dead-tree version of the results.

To mix things up a bit, [Arvind] added a pair of pots to control the creativity and length of the response, plus an OLED screen which seems only to provide some cute animations, which we don’t hate. We also don’t hate the new paint job the typewriter got, but the jury is still out on the “poetry” that it typed up. Eye of the beholder, we suppose.

Whatever you think of GPT’s capabilities, this is still a neat build and a nice reuse of otherwise dead-end electronics. Need a bit more help building natural language AI into your next project? Our own [Donald Papp] will get you up to speed on that.

Continue reading “Giving An Old Typewriter A Mind Of Its Own With GPT-3” →

The Whole Thing In Python

January 2, 2023 by Elliot Williams 6 Comments

[hsgw] built a macropad in Python, and that’s not a strange language to choose to program the firmware in these days. But that’s just the tip of the iceberg. The whole process — from schematic capture, through routing and generating the PCB, and even extending to making the case — was done programmatically, in Python.

The macropad itself isn’t too shabby, sporting an OLED and some nice silkscreen graphics, but the whole point here is demonstrating the workflow. And that starts with defining the schematic using skidl, laying out the board with pcbflow, which uses a bunch of KiCAD footprints, and then doing the CAD design for a case in cadquery, which is kind of like OpenSCAD.

The result is that the whole physical project is essentially code-defined from beginning to end. We’re not sure how well all the different stages of the workflow play together, but we can imagine that this makes versioning a ton easier. Coding a PCB is probably overkill for something simple like this — you’d be faster to lay it out by hand for sure — but it doesn’t really scale. There’s definitely some level of complexity where you don’t want to be clicking an pointing, but rather typing. Think of this as the “hello world” to designing in code.

Some of the tools in the workflow were new to us, but if you’d like an in-depth look at cadquery, we’ve got you covered. [Tim Böscke]’s insane CPU made from 555 timers (yes, really) uses pcbflow. And if you’d like to dig back a bit into the origins of Python PCB design, this post introduces CuFlow, on which pcbflow was based.