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.

@smarkusg

I respect your opinion, don't worry, no offense taken!

@AlexC

Thanks a lot for your technical observations which I find truly interesting and valuable for improving the project. To be honest with you and the entire community I do not consider myself a C expert at all as my programming knowledge is actually quite basic. This is why I find it surprising that I was able to complete such a port because without the help of AI I would never have made it. For me AI has been a tireless tutor that allowed me to learn coding concepts while producing something useful and I believe this is a fundamental point for the future of AmigaOS. A clear example happened during the CuraEngine port where the AI initially pointed out the PowerPC big-endian issue but then during the conversion it actually forgot to handle the little-endian to big-endian transition. While testing the program I noticed it wouldn't read binary STL files even though ASCII STLs worked perfectly so I remembered the issue and explicitly asked the AI if we had done the conversion. Only after this correction of mine and a new compilation did CuraEngine start reading binary STL files correctly. I am currently also developing my own project from scratch which is a video processing program that uses ffmpeg and a MUI graphical interface. This is primarily an educational project for me and AI is helping me immensely to understand the complex logic behind MUI development. I must say that sometimes the AI makes mistakes and in those cases it is actually me who by studying the code and the SDK manages to correct it. It is a very active way of learning and today I wouldn't find any human tutor able to teach me how to program on Amiga so this has become a significant educational training ground for me. If someone with little experience can achieve these results just imagine what a veteran and trained developer like you could do by giving precise directions to the AI to accelerate the work and saving hours of tedious tasks. My work is not perfect yet but I hope it serves as proof that with AI and the right determination even those starting from zero can actively contribute to growing our software library.

@joerg

I don’t think it makes sense to work on more up to date browser, before we have 64bit version of AmigaOS4, if keep running out memory, its no point having latest version, its nice to see progress on SMP.. but we have a long way to go..

@ldg72

the main issue with AI, is that when code base gets too big, the AI can’t keep track, and if you don’t understand the code, your stuck. As for sloppy code, AI often produce example quality code, and always need to read the code, before using it.

Often mistakes are unnoticed, memory is not cleaned up correct, things are not checked correctly. LLM produce code from what has learned from human mistakes. its not a inventor, but can stick different things to a degree to a degree.

The more you ask it to fix something, the more confused it gets, and suddenly see it undoing stuff.

AI is good learning tool, it help you get started, and it come up suggestions, it can prof read code, if you ask it, and it can be a aid, but it lacks creativity, focus and does not actually understand the impotence of the work its doing. the AI tool need guidance.

@smarkusg

It be stupid to not use tool that can help speed up development, we lack developers, we lack funding, and we lack the time. Anything can speed up development, or help if used correct should be used.