Software Development

824 Articles

Open Source CAM Software In The Browser

March 1, 2021 by 24 Comments

3D printers, desktop CNC mills/routers, and laser cutters have made a massive difference in the level of projects the average hacker can tackle. Of course, these machines would never have seen this level of adoption if you had to manually write G-code, so CAM software had a big part to play. Recently we found out about an open-source browser-based CAM pack created by [Stewert Allen] named Kiri:Moto, which can generate G-code for all your desktop CNC platforms.

To get it out of the way, Kiri:Moto does not run in the cloud. Everything happens client-side, in your browser. There are performance trade-offs with this approach, but it does have the inherent advantages of being cross-platform and not requiring any installation. You can click the link above and start generating tool paths within seconds, which is great for trying it out. In the machine setup section you can choose CNC mill, laser cutter, FDM printer, or SLA printer. The features for CNC should be perfect for 90% of your desktop CNC needs. The interface is intuitive, even if you don’t have any previous CAM experience. See the video after the break for a complete breakdown of the features, complete with timestamp for the different sections.

All the required features for laser cutting are present, and it supports a drag knife. If you want to build an assembly from layers of laser-cut parts, Kiri:Moto can automatically slice the 3D model and nest the 2D parts on the platform. The slicer for 3D printing is functional, but probably won’t be replacing our regular slicer soon. It places heavy emphasis on manually adding supports, and belt printers like the Ender CR30 are already supported.

Kiri:Moto is being actively improved, and it looks as though [Stewart] is very responsive to community inputs. The complete source code is available on GitHub, and you can run an instance on your local machine if you prefer to do so. Continue reading “Open Source CAM Software In The Browser” →

The Famous Basic Computer Games Book Gets A 2021 Update

February 26, 2021 by 53 Comments

If you are a certain age, your first programming language was almost certainly BASIC. You probably at least saw the famous book by Ahl, titled BASIC Computer Games or 101 BASIC Computer Games. The book, published in 1973 by [David Ahl] was a staple in its day and the first computer book to sell over one million copies. Of course, if you want to run Super Star Trek or Hamurabi, you better fire up an old retrocomputer or a simulator because BASIC in 1973 doesn’t look like what we have today. Or, you can head to GitHub where [coding-horror] is inviting people to help update the programs using modern languages.

One of our favorites, Bagels, is there with directories for C#, Java, Javascript, Python, Ruby, and VB.net. It doesn’t appear that all of the games are in all the languages, though. There’s also a .Net solution file that apparently has a few entries in it. We were also happy to see Super Star Trek represented, along with a link to an article about a C++ language port. The original games were tweaked to run on VintageBasic.

Continue reading “The Famous Basic Computer Games Book Gets A 2021 Update” →

Oddball X86 Instructions

February 25, 2021 by 66 Comments

David Letterman made the top ten list famous. [Creel] has a top ten that should appeal to many Hackaday readers: the top 10 craziest x86 assembly language instructions. You have to admit that the percentage of assembly language programmers is decreasing every year, so this isn’t going to have mass appeal, but if you are interested in assembly or CPU architecture, this is a fun way to kill 15 minutes.

Some would say that all x86 instructions are crazy, especially if you are accustomed to reduced instruction set computers. The x86, like other non-RISC processors, has everything but the kitchen sink. Some of these instructions might help you get that last 10 nanoseconds shaved off a time-critical loop.

Continue reading “Oddball X86 Instructions” →

Free RTOS

Real-Time OS Basics: Picking The Right RTOS When You Need One

February 24, 2021 by 60 Comments

When do you need to use a real-time operating system (RTOS) for an embedded project? What does it bring to the table, and what are the costs? Fortunately there are strict technical definitions, which can also help one figure out whether an RTOS is the right choice for a project.

The “real-time” part of the name namely covers the basic premise of an RTOS: the guarantee that certain types of operations will complete within a predefined, deterministic time span. Within “real time” we find distinct categories: hard, firm, and soft real-time, with increasingly less severe penalties for missing the deadline. As an example of a hard real-time scenario, imagine a system where the embedded controller has to respond to incoming sensor data within a specific timespan. If the consequence of missing such a deadline will break downstream components of the system, figuratively or literally, the deadline is hard.

In comparison soft real-time would be the kind of operation where it would be great if the controller responded within this timespan, but if it takes a bit longer, it would be totally fine, too. Some operating systems are capable of hard real-time, whereas others are not. This is mostly a factor of their fundamental design, especially the scheduler.

In this article we’ll take a look at a variety of operating systems, to see where they fit into these definitions, and when you’d want to use them in a project. Continue reading “Real-Time OS Basics: Picking The Right RTOS When You Need One” →

BASIC: Cross-Platform Software Hacking Then And Now

February 16, 2021 by 125 Comments

Surely BASIC is properly obsolete by now, right? Perhaps not. In addition to inspiring a large part of home computing today, BASIC is still very much alive today, even outside of retro computing.

There was a time, not even that long ago, when the lingua franca of the home computer world was BASIC. This wasn’t necessarily always the exact same BASIC; the commands and syntax differed between whatever BASIC dialect came with any given model of home computer (Commodore, Atari, Texas Instruments, Sinclair or any of the countless others). Fortunately most of these licensed or were derived from the most popular microcomputer implementation of BASIC: Microsoft BASIC.

BASIC has its roots in academics, where it was intended to be an easy to use programming language for every student, even those outside the traditional STEM fields. Taking its cues from popular 1960s languages like FORTRAN and ALGOL, it saw widespread use on time-sharing systems at schools, with even IBM joining the party in 1973 with VS-BASIC. When the 1970s saw the arrival of microcomputers, small and cheap enough to be bought by anyone and used at home, it seemed only natural that they too would run BASIC.

The advantage of having BASIC  integrated into these systems was obvious: not only were most people who bought such a home computer already familiar with BASIC, it allows programs to be run without first being compiled. This was good, because compiling a program takes a lot of RAM and storage, neither of which were plentiful in microcomputers. Instead of compiling BASIC source code, BASIC interpreters would interpret and run the code one line at a time, trading execution speed for flexibility and low resource use.

After turning on one’s microcomputer, the BASIC interpreter would usually be loaded straight from an onboard ROM in lieu of a full-blown operating system. In this interpreter shell, one could use the hardware, write and load BASIC programs and save them to tape or disk. Running existing BASIC code as well as compiled programs on one’s computer, or even typing them in from a listing in a magazine all belonged to the options. As BASIC implementations between different home computers were relatively consistent, this provided for a lot of portability.

That was then, and this is now. Are people actually still using the Basic language?

Continue reading “BASIC: Cross-Platform Software Hacking Then And Now” →

Some Tips For Monetizing Work In Open Source

February 9, 2021 by 25 Comments

Free and open-source software (FOSS) doesn’t have to be entirely separate from the concept of bringing in money, but the path to monetizing is maybe less clear than it could be. To help address this, [Drew DeVault] has shared some concise thoughts on different ways to monetize FOSS work and projects. [Drew] observes that monetizing one’s own projects is one approach, but that it is entirely possible, and less difficult, to make money by participating in open source work in a more general sense.

There are companies and organizations out there who may make their money otherwise, but are nevertheless involved in or reliant upon open source software for running their business. Such companies are a good starting point for anyone looking to work in FOSS, and [Drew] shares a clever tip for finding them: use git to clone the software repositories of large projects that are of interest to you, then run this command:

git log -n100000 --format="%ae" | cut -d@ -f2 | sort | uniq -c | sort -nr | less

This will extract the domain names from the last 100,000 commits to the repository in question; a good set of leads to companies and organizations that are invested enough in FOSS to contribute, and who may be willing to pay for such work.

There is also the option of monetizing one’s own projects, which [Drew] says is the more difficult approach. He shares tips on monetization options, but cautions that fundamentally one is building a business when going this route. One should therefore be prepared to face the attendant non-software-related problems in the process.

[Drew] runs SourceHut and works entirely in FOSS, but still makes time for fun hacks like using this old line printer to emulate the experience of working on a teletype, which is how it was done when terminal output went to paper, instead of a CRT monitor.

13,000 Regular Expressions Make An Editor’s Life Easier

February 1, 2021 by 41 Comments

Being an editor is a job that seems deceptively easy until you are hauled over the coals for letting a textual howler go to print (or website). Most publications have style guides to ensure that their individual voice is preserved, but even the most eagle-eyed will sometimes slip up in their application. At the Guardian newspaper in the UK they have been struggling with this against an ever-evolving style guide that must adapt to fast-moving world events, to the extent that they had a set of regular expressions to deal with commonly-occurring problems. A lot of regular expressions, in fact around 13,000 of them.

Clearly some form of management was required, and  a team of developers set about taming this monster. The result is Typerighter, their server-side document-checker, which can be found in a GitHub repository. Surprisingly for rule management they started with a Google Sheet, a choice which proved unexpectedly robust when working with such a long list even though they later replaced it. The back end doing the job of text matching was written in Scala, and for the front end a plugin was created for their Prosemirror text editor.

For a publication of course this is extremely interesting, but where’s the interest for hackers? The answer lies in any text-processing engine that uses a lot of regular expressions; those of you who have dabbled in this space will know how unwieldy this work can become. Any user of computational linguistic techniques in the pursuit of language processing could probably find much of interest here.

If you’re a bit hazy on regular expressions, how about the episode on them from our long-running Linux-fu series?