Shed Skin restricted-Python-to-C++ compiler 0.9.9

I have just released version 0.9.9 of Shed Skin, a restricted-Python-to-C++ compiler. It comes with many changes under the hood to improve the code base. For example, Shakeeb has started adding type annotations to Shed Skin itself, whereas I have fixed many C++ compiler warnings. We have also replaced the old CPython-based dict and set implementations with STL unordered_map and unordered_set. While this may cost some performance for especially small toy programs, it really helps with maintainability.

There was also a type inference improvement, which hasn't happened in a while since it wasn't needed. It was however needed to add a cool new example called "pycsg", which shows how one can perform CSG (constructive solid geometry) using binary space partitioning (BSP). After some investigation I decided to make the type inference slightly less "optimistic", which should make it scale a lot better, at the cost of being slower overall. In the end this new example runs about 15 times faster after compilation on my system (not 15%.. 15 times!).

Most notably on the outside, Shed Skin now comes with --floatXX/--intXXX options, which allow you to specify the desired float/int precision. Unfortunately under windows, --int128 does not yet work, since C++ has not yet standardized 128-bit integers.. The relatively new othello2 and collatz examples now require --int64 and --int128, respectively, to function properly.

For the full list of changes, please see the release notes.

I would like to take this opportunity to (once again) invite others to help out in Shed Skin development. There is always enough to do, also low-hanging fruit, on both the Python and the C++ side of things. I at least think it is rather fun to work on.. :) Let me know if you'd like to contribute but aren't sure what you could bring to the table.

Of course just sending in feedback or new example programs (especially if they fail!) can be very motivating as well to keep improving things.

LEGO Othello board

I have a weird bucket list. One remaining item was to create a full-size, playable Othello board, with ridges to avoid discs from moving around. I finally decided to try and mimic an existing board. The result looks pretty close to the original:

Unfortunately I was unable to figure out how to create smooth (and yet flat) discs, but they are at least quite playable. Suggestions for improvements are welcome. I'd also be happy to share more information or even a parts list anyone would like to recreate it.

Shed Skin restricted-Python-to-C++ compiler 0.9.7

I have just released version 0.9.7 of Shed Skin, a restricted-Python-to-C++ compiler. The highlight of this release is native Windows support, by moving to CMake (and Conan). Shakeeb Alireza came up with this idea and did most of the implementation. So to build something on Windows, one doesn't need a weird emulation layer like MingW anymore, just Visual Studio build tools, CMake and Conan (popular tools that many will already have installed). He also made sure that most things work under OSX. Here is a screenshot of an (also) new DOOM-engine example running under windows:

With the recent Python 3 and now native Windows support (plus an ever growing Python community), I'm hoping the project will see more usage and feedback/contributions over the coming years. Please consider joining the project, as there is always enough to do!

Besides other contributions from Folkert van Heusden and Humhue, the release comes with many other improvements, such as support for relative imports, the walrus operator and struct.pack_{from, into}. See here for the full release notes.

Fast DOOM WAD renderer in 999 lines of Python

For the longest time, I've wanted to re-implement the original DOOM engine in Python, and compile it with Shedskin to get reasonable performance. So when I finally ran across a pretty small engine written in Java, by Leonardo Ono, I decided to convert his version to Python.

I left out some optimizations (most notably "visplanes"), for readability and in order to keep everything under 1000 lines of code (while following PEP8). So it could run quite a bit faster still. This is including a WAD loader and interactive Pygame wrapper, that makes it almost feel like you are playing DOOM.

It's interesting how using Python (using just CPython) seems to be about as fast as using assembler back in the day.

This video shows the day-and-night difference in FPS after compilation using Shedskin.

The source code can be found in the Shedskin examples directory.

I may revisit the code now and then, to try and improve readability by adding comments and/or refactoring parts. Patches in this direction very much welcome of course.

Shed Skin restricted-Python-to-C++ compiler 0.9.6

I recently decided to sit down and finally port Shed Skin, an experimental restricted-Python-to-C++ compiler in the works since 2005 or so, to Python3. Three painful months and a total diff of 50k lines later, everything now works with Python3 (Shed Skin itself, and all tests and examples..)

This does not mean that every Python3 feature is supported, but what was there now at least works fine with Python3.. For example, unicode is still restricted to 1-byte characters, and there is no support (yet) for nice new features such as f-strings. Python2 support has been dropped with the new release, and subsequent releases should add support for various new Python3 features.

The following people have contributed along the way:

• Johan Kristensen (large patch for moving from compiler.ast to ast, still on Python2)
• Shakeeb Alireza (extension module support for Python3, ported many examples, improved OSX support, and various code cleanups)
• Folkert van Heusden (some fixes on the C++ side, move to c++17)
• Jeremie Roquet, Thomas Spura, Paul Boddie and others who kept doing maintenance on the project in my absence

I started work on the port after realizing that Shed Skin was being removed from distributions, especially Debian, as it was still tied to Python2, and I really want to keep Shed Skin in a working state if possible.

So what about the future of the project? Not really sure, but I'm happy to sit down again in a few months to prepare a new release. Any feedback on what to support or improve would be very welcome!

For fun, here are screenshots of some of the Shed Skin example programs (in total 75 working example programs can be found on the github site):

TACO VR: an Infento-based omnidirectional treadmill (unfinished prototype)

The initial excitement of owning a wireless headset such as the Oculus Quest is quickly followed by disappointment in the size of one's living room. Unfurtunately there does not seem to be a solution to the problem of not being able to move around by more than a few meters without using the controllers in an awkward manner, or a satisfactory solution to me at least. For example, I really feel like one should also be able to walk up and down hills, or climb stairs and that such a thing should be possible.

There are various categories of existing solutions, each with significant downsides. There are the infinideck-type omnidirectional treadmills, which seem really expensive and bulky by design, and probably very noisy as well. Not that great for most living rooms. And as I mentioned, they cannot offer up/down movement without a completely separate system. Then there are the 'gliding bowl' solutions such as the kat-vr. This works, and to be honest I haven't tried one, but this just cannot feel very realistic. I do appreciate the elegant, cheap solution, and I mean that as a compliment. But again, there is no possibility for up/down movement. Finally, there are the prototypical "magical" shoes, that can perhaps move up and down in theory, but having to wear (bulky) shoes doesn't do it for me either. I want to be able to "feel" the ground with my own shoes, or even with my bare feet.

With this blog post, I would like to introduce my own type of solution. I'm sure others have thought of similar things, and it's not entirely finished either, so I can't yet say if it will work like I think it will or if it will turn out to be a dead end. I have mostly just been having fun working out the mechanical concept using Infento, which is a highly-recommended product for protopying sturdy mechanical devices (initially developed for making/rebuilding children's bikes). I also had to 3d print some gears, as Infento doesn't sell these (perhaps out of safety concerns - you really don't want to have kids fingers in there..).

I was worried that some Infento parts would not be strong enough to hold my weight, but so far they have held up great.

The core idea is to have a central 'rail system' that rotates with the line between your feet. Each foot has its own moving platform on this rail, that (after adding sensors and motors) follow the respective foot, and ultimately catch the foot as it comes down. After catching a foot, and based on the motion and direction of the other foot, the platform moves back to a natural position to continue walking or may stay in the same place (for example while the user is turning). But all of this is a bit hard to explain, so I tried to film the general idea (note of course that for a final solution it should be possible to lift your feet and walk/turn naturally!).

Video showing movement

The gears connect to the stationary base plate and make sure that the platforms are always facing the same direction, much as the tiles of your floor. The same effect could be achieved by adding more motors, but I thought this was interesting anyway, and probably cheaper and more silent in the end as well.

So while there is no support for up/down movement at the moment, it is clearly possible to make the platforms go up and down, or potentially even tilt (slightly).

If this were to become a real product, for safety there would probably need to be a large circular encasing (could be much more flat!), plus something to catch you if you lose your balance, much like the other solutions. The platforms would stick out of a slit in the middle, again potentially moving up/down. It would not be cheap, but could perhaps be relatively cheap when built as an open source kit. But to be honest, I'm not sure I will ever continue work on this prototype, so I'm just putting it out there.

Additional photos

update: I've started to collect specifications, parts lists etc. on github.

interlocking modular origami unit 2 (IMORU2)

The original Sonobe modular origami unit is almost like a "lego block" for origami structures, but falls short in that the result is often not very rigid and/or falls apart without using adhesives. My previously published unit, called IMORU1, utilizes interlocking hooks to work around this problem.

It works a lot better, but after playing with it further for a while, I realized it also has two annoying issues: the hooks are a bit difficult to insert (and arguably a bit clunky/inelegant), and much worse, it is still not always completely rigid at the corners.

So I went back to the drawing board, and finally found something which has easier to insert hooks, is rigid in all corners and is actually also easier to fold. I'm not sure if it can still be called a Sonobe variation, but it's definitely inspired by it. This time I also tested it better. Here are some basic example structures:

And here's the diagram of how to fold it.

Photo of the completed unit:

Finally, a youtube video showing how to fold and join units.

Now, there still is one minor issue left with IMORU2, in that edges are not always taut, but this is basically cosmetic and doesn't affect its functionality. I may try to find an improved IMORU3 sometime in the not too distant future. But for now, let's first try to fold a few thousand of this.. O_o

Update: The diagram, plus some more details, were added to the OrigamiUSA diagrams page.