You’ve probably heard of multithreaded programs where a single process can have multiple threads of execution. But here is yet another layer of creating multitasking programs known as a fiber. [A Graphics Guy] lays it out in a lengthy but well-done post. There are examples for both x64 and arm64, although the post mainly focuses on x64 for Windows. However, the ideas will apply anywhere.
In the old days, there was a CPU and when your program ran on it, it was in control. But that’s wasteful, so software quickly moved to where many programs could share the CPU simultaneously. Then, as that got overloaded, computers got more CPUs. Most operating systems have the idea of a process, which is a program that thinks it is in complete control, but it is really sharing the CPU with other processes. The problem arises when you want to have multiple “little” programs that cooperate. Processes are not really supposed to know about one another and, if they do, there’s usually some heavy-weight communication mechanism allowing them to talk.
Continue reading “Processes, Threads, And… Fibers?”
[John Earnest]’s passion project Decker is creative software with a classic MacOS look (it’s not limited to running on Macs, however) for easily making and sharing interactive documents with sound, images, hypertext, scripted behavior, and more to allow making just about anything in a WYSIWYG manner.
Decker creates decks, which can be thought of as a stack of digital cards that link to one another. Each card in a deck can contain cozy 1-bit art, sound, interactive elements, scripted behavior, and a surprisingly large amount of other features.
Curious? Check out the Decker guided tour to get a peek at just what Decker is capable of. Then download it and prototype an idea, create a presentation, make a game, or just doodle some 1-bit art with nice tools. Continue reading “Decker Is The Cozy Retro Creative Engine You Didn’t Know You Needed”
At first, string processing might seem very hard to optimize. If you’re looking for a newline in some text, you have to check every character in the string against every type of newline, right? Apparently not, as [Abhinav Upadhyay] tells us how CPython does some tricks in string processing.
The trick in question is based on bloom filters, used here to quickly tell whether a character possibly matches any in a predefined set. A bloom filter works by condensing a set of more complex data to a couple of bits in an array. When an element is added, a bit is set, the index of which is determined by a hash function. To test whether an element might be in the filter, the same is done but by testing the bit instead of setting it. This effectively allows a fast check of whether an element might be in the filter.
CPython doesn’t stop optimizing there: instead of a complicated hash function, it simply uses the lowest 6 bits. It also has a relatively small bit array at only 64 bits which allows it to avoid memory all together, which in turn makes the comparisons much faster. [Abhinav] goes far into more detail in his article, definitely worth a read for any computer scientists among us.
Nowadays there is ever increasing amounts of talk about AI (specifically large language models), so why not apply an LLM to Python to fix the bugs for you?
Robots are cool. Robots you build yourself are cooler, especially ones that use stuff you have lying around already. Snoopy is a new open-source robot that uses an Arduino as a brain but with a 3D printed body and a short list of parts that can probably be sourced from the junk drawer. It’s still being developed, but it looks like a cool project heading in the right direction to produce an interesting robot.
It’s based on a new robot software platform called Kaia.ai that is built on top of the Robot Operating System 2 (ROS2), but with a more friendly and beginner-focused interface. Currently, the Snoopy project includes enough to get up and running with a printed frame and the electronics to install an Arduino running ROS2 that controls it. That’s an excellent place to start if you want to get into robotics, but without diving straight into the technical challenges of working with real-time operating systems.
It is also interesting that the previous project from the creator (called Kiddo) fell into the complexity trap, where you keep adding features and create an overly complex design that is a pain to build. Hopefully the designers have learned from Kiddo and will keep Snoopy simple.
We’ve covered plenty of other robot projects here at Hackaday, from ones that venture into nuclear reactors to ones that write your thank-you notes for you or give you hugs. We’ve even looked at how to give your robots a personality. Combine all those together with Snoopy and you could build a hugging, compassionate robot that has nice handwriting and can repair a nuclear reactor. And if you do, write it up and send it to our tips line!
Most people use their computer to run pre-packaged programs: usually a web browser, games, or office applications. Whether the machine is a PC or a Mac, they don’t generally write their own software. For them, the computer is an appliance, and they do what their computer allows them to do.
It shouldn’t have to be that way, if only programming were easier. The Eclectic Light Company has a fascinating article looking at the various attempts that Apple has made to lure their users into creative programming.
Probably the most familiar of them all is AppleScript, with its origins in late 1993. Or maybe you’re thinking of Hypertalk, the scripting component of 1987’s Hypercard. That would go on to be a mainstay of mid-1990s multimedia software, but while it’s fallen by the wayside it’s AppleScript which still has support in the latest MacOS.
The biggest surprise for us lies in the forgotten products. 1989’s Prograph graphical language looks amazing. Was it simply before its time? In the modern era, Apple describes the reach of Shortcuts diplomatically: “its impact has so far been limited”.
Maybe the most forward-thinking line on programming from Apple came in 2007, even if it wasn’t recognized as such. The original iPhone didn’t have any third-party apps, and instead developers were supposed to write web apps to take advantage of the always-connected device. Would that be such a bad piece of advice to give a non-developer writing software for their Mac today?
Many people, one way or another, got started programming computers using some kind of Basic. The language was developed at Dartmouth specifically so people could write simple programs without much training. However, Basic found roots in small computers and grew to where it is today, virtually unrecognizable. Writing things in something like Visual Basic may be easier than some programming tasks, but it requires a lot of tools and some reading or training. We aren’t sure where the name EndBasic came from, but this program — written in Rust — aims to bring Basic back to a simpler time. Sort of.
You can run the program in a browser, locally, or connected to a cloud service. It looks like old-fashioned Basic at first. But the more you dig in, the odder it gets. The command line is more akin to a Python REPL. You type things, and they happen. It took a while to figure out that you need to enter EDIT to write a program. Then, what you type gets saved until you press escape. The syntax is Basic-like but has oddities. There are no line numbers, but you can use labels that start with an at sign.
Continue reading “The End Of Basic?”
The ways in which we interact with computers has changed dramatically over the decades. From flipping switches on the control panels of room-sized computers, to punching holes into cards, to ultimately the most common ways that we interact with computers today, in the form of keyboards, mice and touch screens. The latter two especially were developed as a way to interact with graphical user interfaces (GUI) in an intuitive way, but keyboards remain the only reasonable way to quickly enter large amounts of text, which raises many ergonomic questions about how to interact with the rest of the user interface, whether this is a command line or a GUI.
For text editors, perhaps the most divisive feature is that of modal versus non-modal interaction. This one point alone underlies most of the Great Editor War that has raged since time immemorial. Practically, this is mostly about highly opiniated people arguing about whether they like Emacs or vi (or Vim) better. Since in August of 2023 we said our final farewell to the creator of Vim – Bram Moolenaar – this might be a good point to put down the torches and pitchforks and take a sober look at why Vim really is the logical choice for fast, ergonomic coding and editing.
Continue reading “On Vim, Modal Interfaces And The Way We Interact With Computers”