Nope, it's months later and I still haven't had the insight necessary to make function arguments of the C type RgnHandle * work properly. SIGH

#m68kmicropython

Today's #m68kMicroPython #Codeberg journey: Codeberg furnishes some very low capacity CI for projects. I previously found it was not hard to adapt a github actions yml file to forgejo actions.

However, there's a request from the Codeberg team to make sure these actions are as lean on their limited CI resources as they can be. This makes sense, as GitHub is interested in maintaining its dominance as the default git forge and well the resources of Azure are sitting right there.

Anyway, I noticed that the docker image I use to build m68k-micropython was about 3GB and naturally I wondered if it could be reduced.

I re-targeted the Retro68 docker image from Ubuntu 22.04 to Debian Trixie (slim version), and did a few more things like ensure the m68k toolchain binaries were stripped as they were being installed. This reduced it down to under 800MB.

Additionally I measured the size of my build directory and it's under 200MB, so in all I'm accounting for about 1GB of peak storage usage. It also takes under 1 minute real time to run. Again, this doesn't cover everything github does, like code quality checks. Just the main build of the micropython disk image.

Ironically, I'm currently building the container image on github, because I don't think forgejo would be too happy with the large size of the intermediate build steps, which are still somewhere in the 3GB to 4GB range and takes between 15 and 20 minutes.

I'm continuing to poke around at forgejo as an alternative to github, using the codeberg.org flagship instance. I also made a donation to codeberg in recognition of the value of the software they've produced and the codeberg resources I'm consuming. (Nominally $5 a month though I paid a year at once to reduce payment fees)

I adapted one of the workflows of #m68kMicroPython to work on codeberg; the syntax for workflows is "mostly compatible", but details of attaching files to releases were different. I eventually found how to use the "tea" commandline program to do so.

I'm not committed to removing any of my projects from github at the moment, but I would be remiss if I didn't do an investigation of alternatives.

On the whole, I think I would rather pay someone to run a forge for me (vs self-hosting) and codeberg seem to have a structure that aligns their incentives with their users and members which is notably lacking at GitHub.

However, depending on my CI needs I would sure consider setting up one of my PCs at home to work as a CI runner. Heck, even a Pi with an nvme disk would probably meet my needs (and encourage me to ensure my needs are modest).

#forgejo #codeberg

I've been toying with the idea of moving m68k-micropython off of github because of [gestures at the external world].

milestone: I can build it using the free CI on codeberg! I "ported" just one of several workflows over to their system, which is of course designed to imitate GA pretty closely. except where it doesn't. (like requiring nodejs in the container you use for build steps, because actions/checkout runs with the docker container's version of node...surprise!)

If I continue much further down this trail I'll have to send some money their way.

#m68kMicroPython #codeberg #forgejo

better repr for uctypes structures

#m68kMicroPython #macintosh #retroComputing #python

some progress on #m68kMicroPython finally?

I'm still not proud of my "mkapi" program for wrapping Mac APIs into MicroPython, but I have worked out some of the bugs. This is the return of a demo from some weeks ago, but now it also successfully calls DisposeRgn and can print the bounding box size of the region as well.

In other testing, accessing the quick draw globals also seems to be working better.

Finally, I have added some basic functionality tests for the wrapper generator to the compile-time tests (running on a modern computer, not in an emulator).

This is in yet-to-be-merged https://github.com/m68k-micropython/micropython/pull/16

#retroComputing #macintosh #m68k

Wrapping system APIs in #m68kmicropython is breaking my head again, and I've been spinning my wheels for going on a full week.

In Python "everything's a reference". So when a Mac API like FillRect takes a Rect* (pointer to a rectangle) the Python type of the right object is simplyRect, and you pass it in as itself. Great, right?

Now I'm trying to make Handle types work right. A Handle such as RgnHandle is a pointer to a RegionPtr (an alternative spelling of Region* created through a C typedef), which is a pointer to a Region. However, the wrapping "architecture" I've invented so far this would end up saying "RegionPtr" as the Python type.

I think this confusion between pointers & handles & objects is probably why a few operations on regions work but many do not.

In other news I've thrown my name in the ring to give a lightning talk about the m68k-micropython generally here at #pyOhio today.

For those not following #m68kMicroPython development, a lot has been happening rather quickly in the last couple of weeks!

There's enough support for the Toolbox now that I've been able to re-create the #Macstodon splash/loading screen with it - see below.

Big thanks to @stylus for all his hard work developing the port and making this possible!

#RetroComputing #RetroProgramming #VintageMac #Apple #Mac #MacOS #ClassicMac #68k #Python #MicroPython https://oldbytes.space/@smallsco/114889267494614758

I made a new release of m68k-micropython: https://github.com/m68k-micropython/micropython/releases/tag/20250720

This adds the following groups of mac APIs (which I didn't actually test):

• deskmgr
• dialogmgr
• fontmgr
• menumgr
• textedit

#m68kMicroPython #micropython #macintosh #vintageMacintosh #retroComputing