Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

• linux: https://make.mudlet.org/snapshots/53b2b2/Mudlet-4.6.2-testing-pr3648-afb3a57-linux-x64.AppImage.tar
• osx: https://make.mudlet.org/snapshots/a5d277/Mudlet-4.6.2-testing-pr3648-afb3a57.dmg
• windows: https://make.mudlet.org/snapshots/b1fb71/Mudlet-4.6.2-testing-pr3648-afb3a575-windows.zip

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

Hm... but I don't want to spend my energy helping people who install something else other than what we support - it doesn't work for them, so they come to us for help. Why can't they follow instructions and install what we require? Seems like less hassle for everyone involved? And the loading code doesn't have to be complicated with message queues (!).

I don't like having to use different luarocks for different systems and this will allow for flexibility if we add any more rocks to our requirements. It will also make it easier to swap the Linux and Windows installer builds to be swapped over to lua-zip from luazip as we won't have to jump through the changing two repositories (mudlet and installers) at the same time hoop.

Edit: I am quite happy to not have even an indirect dependence on that confusingly name extra library i.e. zzip/zziplib/libzzip or whatever is it's official name!

So you'd like it that way - okay sounds good.

It looks like the queue only ever stores one message at a time, can we use a multi-return from the function to return boolean+string ?

The queue stores the error messages for all the attempts to provide a particular Lua module - and either ends up with a single [ OK ] - message from the particular one that succeeded or the accumulated ones in order from all the alternatives for that one module.

Passing that Queue as a reference allows for a Queue<T>::swap(const T& other) to quickly both dump any accumulated [ ERROR ] messages and stick in the OK one without having to clear the existing ones out - and it was simpler/cleaner to do it that way than coding up a whole new abstraction for the multiple alternate luarocks for the same module/library that was different to the one for the single choice ones - however that does require a bool result so as to know whether to try another one - but that can be ignored for the single choice ones.

If I had been aware of it at the time the (QStringList) cTelnet::messageStack would also have been a QQueue<QString> I guess...

Sorry, I still only see it enqueing only 1 message at a time - either a success or a failure one. The queue's size is 1 item at most, ever. Am I missing something?

If you do not have/or they cannot both be loaded lua-zip NOR luazip for example you will get the list of all the file names and other possibilities that were tried. They will be different for each luarock or however it could be packaged, like the lfs often comes from it's own system package. Therefore it is valid (and bloody useful when working on a different OS/System to normal) to see every possibility that was actually tried. In that case you will have thus have as many sets of error messages as there are alternatives. Try deleting both lua-zip and luazip rocks from your test system and see.

BTW I am just finding that there is merit in ensuring that your system environment defines LUA_PATH and LUA_CPATH to include your path for --local rocks in the user login process...