Over the many years Apple Computer have been in operation, they have made a success of nearly-seamlessly transitioning multiple times between both operating systems and their underlying architecture. There have been many overlapping versions, but there’s always a point at which a certain OS won’t run on newer hardware. Now [Jubadub] has pushed one of those a little further than Apple intended, by persuading classic Mac System 7 to run on a G4.

System 7 was the OS your Mac would have run some time in the mid ’90s, whether it was a later 68000 machine or a first-gen PowerMac. In its day it gave Windows 3.x and even 95 a run for their money, but it relied on an older Mac ROM architecture than the one found on a G4. The hack here lies in leaked ROMS, hidden backwards compatibility, and an unreleased but preserved System 7 version originally designed for the ’90s Mac clone programme axed by Steve Jobs.  It’s not perfect, but they achieved the impossible.

As to why, it seems there’s a significant amount of software that needs 7 to run, something mirrored in the non-Mac retrocomputing world. Even this hack isn’t the most surprising System 7 one we’ve seen recently, as an example someone even made a version for x86 machines.

Thumbnail Image Art: Apple PowerMac G4 by baku13, CC BY-SA 3.0

Who’s interested in a brand new, from-scratch boundary representation (BREP) kernel? How about one that has no topological naming problem, a web-native parametric CAD front end to play with, and has CAD-type operations making friends with triangle meshes? If you’re intrigued, check out [mmiscool]’s BREP project.

Functioning (let alone feature-filled, or efficient) CAD systems are not a software project we see a whole lot of. Ones that represent models as genuine BREP structures but cleverly use mesh-based operations where it makes sense? Even less so.

In theory, CAD programs are simple: allow a user to define features, keep track of what they are and how they relate to one another, and perform operations on them as requested. In practice, it’s significant work. Chains of operations and dependencies easily become complex, volatile things and there is really no room for error.

Read [Arya Voronova]’s best practices for using FreeCAD to get a few hints as to what goes on behind the scenes in a modern CAD program, and the kinds of challenges the back end has to deal with, like the topological naming problem (TNP). A problem [mmiscool]’s implementation completely avoids, by the way.

There is a live demo at BREP.io which acts as a playground for the state of the project. You can get started by clicking the + button towards the top on the left panel to add features and operations to the history (like add a cube, then add chamfers or fillets, or extrude a face, and so on).

[mmiscool] points out that all computation is done client-side; even complex operations like fillets, lofts, and multi-body booleans execute directly in the browser with no need to be offloaded to a back end. BREP’s development is being documented on Hackaday.io and there is a video embedded below that gives an overview. Why don’t you give it a spin?

We love and hate OpenSCAD. As programmers, we like describing objects we want to 3D print or otherwise model. As programmers, we hate all the strange things about OpenSCAD that make it not like a normal programming language. Maybe µCAD (or Microcad) is the answer. This new entry in the field lets you build things programmatically and is written in Rust.

In fact, the only way to get it right now is to build it from source using cargo. Assuming you already have Rust, that’s not hard. Simply enter: cargo install microcad. If you don’t already have Rust, well, then that’s a problem. However, we did try to build it, and despite having the native library libmanifold available, Rust couldn’t find it. You might have better luck.

You can get a feel for the language by going through one of the tutorials, like the one for building a LEGO-like shape. Here’s a bit of code from that tutorial:

use std::geo2d::*;
use std::ops::*;

const SPACING = 8mm;

op grid(columns: Integer, rows: Integer) {
@input
.translate(x = [1..columns] * SPACING, y = [1..rows] * SPACING)
.align()
}

sketch Base(
columns: Integer,
rows: Integer,
width: Length,
height: Length
) {
thickness = 1.2mm;
frame = Frame(width, height, thickness);
struts = Ring(outer_d = 6.51mm, inner_d = 4.8mm)
.grid(columns = columns-1, rows = rows-1);
frame | struts;
}

There are proper functions, support for 2D sketches and 3D objects, and even a VSCode extension.

Will you try it? If we can get it to build, we will. Meanwhile, there’s always OpenSCAD. Even TinkerCAD can do some parametric modeling.

Python has become one of the most popular programming languages out there, particularly for beginners and those new to the hacker/maker world. Unfortunately, while it’s easy to  get something up and running in Python, it’s performance compared to other languages is generally lacking. Often, when starting out, we’re just happy to have our code run successfully. Eventually, though, performance always becomes a priority. When that happens for you, you might like to check out the nifty tips from [Evgenia Verbina] on how to make your Python code faster.

Many of the tricks are simple common sense. For example, it’s useful to avoid creating duplicates of large objects in memory, so altering an object instead of copying it can save a lot of processing time. Another easy win is using the Python math module instead of using the exponent (**) operator since math calls some C code that runs super fast. Others may be unfamiliar to new coders—like the benefits of using sets instead of lists for faster lookups, particularly when it comes to working with larger datasets. These sorts of efficiency gains might be merely useful, or they might be a critical part of making sure your project is actually practical and fit for purpose.

It’s worth looking over the whole list, even if you’re an intermediate coder. You might find some easy wins that drastically improve your code for minimal effort. We’ve explored similar tricks for speeding up code on embedded platforms like Arduino, too. If you’ve got your own nifty Python speed hacks, don’t hesitate to notify the tipsline!

TinkerCAD had its first release all the way back in 2011 and it has come a long way since then. The latest release has introduced a raft of new, interesting features, and [HL ModTech] has been nice enough to sum them up in a recent video.

He starts out by explaining some of the basics before quickly jumping into the new gear. There are two headline features: intersect groups and smooth curves. Where the old union group tool simply merged two pieces of geometry, intersect group allows you to create a shape only featuring the geometry where two individual blocks intersect. It’s a neat addition that allows the creation of complex geometry more quickly. [HL ModTech] demonstrates it with a sphere and a pyramid and his enthusiasm is contagious.

As for smooth curves, it’s an addition to the existing straight line and Bézier curve sketch tools. If you’ve ever struggled making decent curves with Bézier techniques, you might appreciate the ease of working with the smooth curve tool, which avoids any nasty jagged points as a matter of course.

While it’s been gaining new features at an impressive rate, ultimately TinkerCAD is still a pretty basic tool — it’s not the sort of thing you’d expect to see in the aerospace world or anything. ut it’s a great way to start whipping up custom stuff on your 3D printer.