🌠 Nightly Build 🌠 (5.10 Alpha)

[wawanbreton]

A Nightly build with upgraded Python 🐍 and Conan 🐸

During the last months, we have been pretty busy upgrading 2 core components of Cura:

• Python has been bumped from 3.10 to 3.12. Athough this is not major, Python is the engine that runs the Cura front-end and even the slightest change in its behavior can have an impact.
• We are now using Conan 2 instead of Conan 1. This tool is the basis of our build system, as it orchestrates the way each component of Cura is built and packaged. Cura uses multiple Python and C++ packages altogether, so assembling them all to a standalone application on 3 platforms is a sensitive task.

Why are these changes required ?

• Python keeps evolving, and we want to take advantages of its upgrades and last features. This also allows new developers to use the most recent version.
• Python 3.12 also comes with native speed improvements, so it is always good to take 🙂
• Conan 1 is on a deprecation path, so we really needed to switch to version 2, which is considered the more mature and robust version. Recent packages are now using Conan 2, so if we want to keep up-to-date, we need to use it.

Why do we need you ?

• We have tested many builds of Cura, on many systems, but we know everyone has a different execution environment. The idea of this Alpha release is to make sure that it still works on all the platforms where it used to work before.
• We don't exactly know how everyone uses Cura. There may be some actions that you do, which will reveal a bug we didn't see in our tests.
• There are tons of plugins, all based on Python code. So we want to make sure that they keep working with the new version.

What do you need to do ?

Well, not much, just download this version, use it as you would usually do, and send a brief feedback on the discussion: describe your environment, and tell us if everything went fine, or if you encountered some crashes or strange behaviors !

⚠️ Remember that this is an Alpha version, which means that only the basic functionalities have been tested. Some features are missing, incomplete or still in development, and may not be usable for production.

---

This discussion was created from the release 🌠 Nightly Build 🌠 (5.10 Alpha).

[jszymon]

Everything fine on Linux.

[kalkishnu]

os: Archlinux
kernel: 6.13.0-2
WM: Hyprland
gpu driver: nvidia-open 570

./Descargas/UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage UM/Settings/SettingFunction.py:244: DeprecationWarning: ast.Str is deprecated and will be removed in Python 3.14; use ast.Constant instead def visit_Str(self, node: ast.Str) -> None: fish: Job 1, './Descargas/UltiMaker-Cura-5.10…' terminated by signal SIGSEGV (Address boundary error)
Additional info: version 5.9b1/b2/r crash the same way, last version i can run on this environment is 5.8.1.
Worth to mention that i tried all this version also on a nested lxqt_kwin_wayland session on the same user and all of them launched.

[wawanbreton]

Hi, thanks for the feedback !
This seems to be related to wayland indeed. In 5.9 we added an environment variable at start to force QT to use the xcb platform:
QT_QPA_PLATFORM=xcb
So you could also try the other platform plugins. Giving the plugin with the environment variable doesn't seem to work though, because it is embedded in the AppImage, but you can do the following:

./UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage -platform ...

In order to get the list of available plugins, just set a wrong one:

$ ./UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage -platform something
...
qt.qpa.plugin: Could not find the Qt platform plugin "something" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-egl, wayland, xcb.

Anyway, if the issue is present since 5.9, it is not a regression related to the Python/Conan changes, which is at least some good news for me.

[glx-seven]

Win11 24H2
Cura 5.10.0-alpha.0

The gradual infill setting seems just to respect the uppermost surface, the lower ones are treated with the reduced density (somehow offsetted tho). Doesn't seem to be affected which material or printcore is selected, the screenshots are from extruder 2 but I included a project with extruder 1 that behaves the same.

One below the uppermost:

Uppermost:

Project file:
Project-files_UMS5_vallejo_multi_rack.zip

[wawanbreton]

Hi, thanks for the feedback !
I'm not very familiar with the gradual infill feature, but I will discuss this with the team to see if this is somehow intended behavior.

This part aside, it seems that the application works pretty well overall 🙂

[GrimQuagle]

Hey fellas, I'm the main maintainer of the LulzBot fork of Cura, just popping in to see if I can lend a quick hand.

Very recently, the version numbers of many dependencies was bumped up to match the version number of Cura itself. While that's all well and good, you'll notice that the latest Windows installer from this run now crash during boot. What happened?

I ran into this while working on the LulzBot fork a few weeks ago. I couldn't for the life of me figure out why I wasn't able to get the Windows installer to work properly. After digging and digging, I figured it out.

What appears to have happened is that for quite a while now, Cura has been being built with an Arcus package for Windows that was created many months ago. Between then and now, MSVC updated from 19.3X to 19.4X and it just so happens that a change that was made to the constructor of std::mutex managed to break the implementation used by Arcus and results in Arcus attempting to reference a memory location that was instantiated as 0s. Windows doesn't like that and kills the entire application. This crash occurs when sendQueueMutex.lock(); is called on line 238 of libArcus/src/Socket_p.h.

Now, I'll be the first to tell you that my understanding of C++ is a bit shaky at best, so for my purposes (and what I feel is an adequate temporary solution), I simply added a few lines to the LulzBot fork of the conan-config repo that ensures when building Arcus, Conan uses MSVC version 193.

I'm sure you guys can probably get a much better long term solution figured out faster than I can, but I figured I'd swing by and give you my findings along with creating a quick pull request if you'd like to use it. Hopefully someone finds this helpful!

Best regards

[rburema]

@GrimQuagle

Very recently, the version numbers of many dependencies was bumped up to match the version number of Cura itself. While that's all well and good, you'll notice that the latest Windows installer from this run now crash during boot. What happened?

Hi! Thanks so much for digging up all of this -- Jaime forwarded me the mail and I meant to get back to you (will do so soon).

As far as I can see, what (I think) happened was that: Due to unrelated reasons, quite recently, we had to redo our windows-build server (private github runner), on which we installed a newer version of Visual Studio -- This initially seemed to work, since Arcus was pre-build and thus cached. However, we then bumped the version-number, which caused it to be finally be actually build on the server, which runs into the problem you've described.

Since we're closing in on release-related stuff (feature freezes and all that), I think I'll just try your fix for now -- We should fix this more properly (as in 'not a workaround') once (soon after, hopefully) 5.10 is released.

[GrimQuagle]

A non-workaround fix is definitely needed, I absolutely agree.

An example of this workaround being a bit finicky is that it appears in my haste I unfortunately implemented it incorrectly! The check to have Conan use compiler.version=193 for Arcus should've been located in the installer profile rather than the cura profile. With how I'd implemented it, the CuraEngine package workflow fails to build for Windows...

I've got another PR out with the change. Sorry for the inconvenience!