New Port: Paho MQTT C and CuraEngine for AmigaOS4

Hi everyone,

I wanted to share some exciting news regarding a project I’ve been working on. I have successfully ported the Paho MQTT C library to AmigaOS4.

To be honest, I don’t consider myself a professional developer—I am still a beginner in many ways. However, I wanted to experiment with AI-assisted development to see if it could help bridge the gap for porting libraries to our platform. To my surprise, I managed to complete the Paho MQTT port in just 4.5 hours.

Progress & Testing
Environment: The entire development and compilation were done using QEMU/Pegasos2 emulation on a MacBook Air M4.

Results: I successfully compiled the included examples and connected to my local MQTT server running on a Raspberry Pi. I was able to publish topics without issues.

CuraEngine: Additionally, I spent about 1.5 hours porting CuraEngine 15.4.6. The command-line tool works correctly on my emulated AmigaOS4; I tested slicing both binary and ASCII STL files with success.

Call for Feedback
I am releasing the source code on GitHub. Since this was a fast-paced experiment heavily aided by AI, I would love for more experienced Amiga developers to take a look at the code. I am curious to hear your thoughts on the quality of the implementation and how the AI handled the Amiga-specific requirements.

GitHub Repository: https://github.com/ldg72/paho.mqtt.c-amigaos4

I hope this can be useful to the community and perhaps spark a discussion on how AI can help us bring more modern software to AmigaOS4.

Best regards, Luca De Giovanni

That is very cool!

I don't know enough about these things and... I hate ‘AI’.
If the code was based on ‘AI’, as far as I'm concerned, it ‘doesn't exist’ – it's sludge.

I'm just expressing my opinion and I hope you won't be offended
I'm sure you put a lot of work into it and it works great.

@ldg72

It's quite impressive that AI was able to help, considering that it's very biased when it comes to code, assuming most of the data used by the LLMs comes from linux, some from windows, and presumably not a lot of source code comes from OS4 projects.
I took a quick look at the client source code and there's a lot of platform-dependent code in there. I'd replace the calls to malloc() with calls to AllocVecTags() but I don't know if that's necessary or more of a principle when porting code.

It begs the question whether AI would be helpful with porting FireFox, as the main obstacle is the broad array of libraries that need to be ported and endian conversions needed all over the place.

@AlexC
Quote:The main problem porting modern browsers like FireFox or Chromium to AmigaOS is no longer the libraries, but even much lower level parts like support for the programming languages used, for example Rust in case of FireFox.
And of course still assembler for the JavaScript JIT (no PowerPC support any more, even if it was unfinished and unusable, a PPC port was at least started for JavaScriptCore, usually not even any big endian support any more in any parts) and WebAssembly.
Additionally required, compared to about 15-20 years ago with OWB:
A 3D gfx library like Skia for Chromium, instead of the 2D Cairo gfx library (+ some small AmigaOS 4.x parts) used in OWB, support for colour outline fonts (not only for emoji, at least FireFox uses them for GUI parts as well, and colour outline fonts aren't supported by AmigaOS at all yet, i.e. you'd need to use something like the much slower libfreetype instead of native AmigaOS text rendering OWB used).

@smarkusg

wow

@joerg

Quote:

But OS4 itself also uses FreeType. At least there's an Amiga makefile included in every source archive. Where does this speed increase originate? Assuming OS4's font engine hasn't simply been highly fine-tuned.

Sorry, this is getting OT, but I am genuinely curious.