3D view broken in own-compiled package, Debian repo version is good -- part deux!

[VanessaE]

Using Debian Bookworm, which comes with Python 3.11

I tried to do a new build on a cleanly-installed system, but ran into trouble again. The build itself appeared to go okay, as there were no obvious errors or warnings, but when I try to run the result, the 3d view doesn't work.

This happens whether I point pronterface to my config or not (it has a unique filename, so if I don't point it there it'll use the defaults).

The program automatically falls back to 2d, with these errors:

(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose

(pronterface.py:45465): Gtk-WARNING **: 20:45:08.798: Theme parsing error: gtk-widgets.css:80:34: Expected a valid selector

(pronterface.py:45465): Gtk-WARNING **: 20:45:08.799: Theme parsing error: gtk-widgets.css:979:19: '' is not a valid color name
INFO:root:Loading config file /home/vanessa/.config/Printrun/pronsolerc
DEBUG:root:set last_window_maximized False
DEBUG:root:set last_window_width 1276
DEBUG:root:set last_window_height 1440
DEBUG:root:set last_file_path /home/vanessa
DEBUG:root:set recentfiles ["/home/vanessa/.pronsolerc-2.x-small-HC"]
3D view mode requested, but we failed to initialize it.
Falling back to 2D view, and here is the backtrace:
NotImplementedError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/vanessa/RepRap/Printrun/printrun/gui/viz.py", line 70, in __init__
    root.gviz = printrun.gcview.GcodeViewMainWrapper(
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vanessa/RepRap/Printrun/printrun/gcview.py", line 374, in __init__
    self.glpanel = GcodeViewPanel(parent, realparent = self,
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vanessa/RepRap/Printrun/printrun/gcview.py", line 86, in __init__
    super().__init__(parent, wx.DefaultPosition,
  File "/home/vanessa/RepRap/Printrun/printrun/gl/panel.py", line 90, in __init__
    self.canvas = glcanvas.GLCanvas(self, wx.ID_ANY, attribList, pos, size, style)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SystemError: <class 'wx._glcanvas.GLCanvas'> returned a result with an exception set

These errors seem suspiciously similar to #1389, but requirements.txt already has the change mentioned there, so that isn't it.

Steps to reproduce: er... install a clean Debian Bookworm system and try to build pronterface per the instructions at https://github.com/kliment/Printrun#linux--macos .

If it matters, I did not have to install the out-of-index wxPython wheel, as the build process automatically brought in and compiled wxPython-4.2.1 without any issues.

[neofelis2X]

Hmm, seemingly wxPython fails to create the GLCanvas.
And 2.0.0~rc8 from the repo has a working 3D view?

Could it be that the wxPyton that you compiled is missing the wx.glcanvas module? Or maybe this module failed and the rest finished normally.
Also, I'm not using debian myself, but Printrun 2.0.1 is in the 'unstable' section of debian packages. Does the 3D view work in that?

[VanessaE]

And 2.0.0~rc8 from the repo has a working 3D view?

Yep, it works perfectly in that regard. The repo build has some stylistic issues, but those don't impact the 3d view.

Could it be that the wxPyton that you compiled is missing the wx.glcanvas module? Or maybe this module failed and the rest finished normally.

No clue there. I didn't see any errors during the build, but in all fairness there was a LOT of spew.

Does the 3D view work in [2.0.1 from unstable]?

Dunno, I've had relatively poor luck in the past trying to mix stable with unstable, so I just don't do it anymore.

[DivingDuck]

Hi,
Printrun v2.0.0RC8 (and all other RC versions) are known to have serious problems with wxPython. If I remember correct there was a lot of compatibility problems especially with different Linux versions and distros (e.g #1283) as well. In addition there were changes in the GUI for 3D view that need to have a minimum version of wxPython >= 3.1 and those wasn't really successful with all the distros versions and also well known in the wxPython forum.

Question, why do you not use the actual Pronterface version in combination with wxPython 4.2.1? (I mention this version especially because this version seems to be the most stable version since long time over all supported operating systems)
In addition there were some problems with Python 3.11 as well and this was why we didn't recommend Python 3.11 in the past.

Long story short, don't use any Printrun v2.0.0 release candidate versions.
We did a lot of adjustments along the way dealing with all the wxPython versions below 4.1 (and issues around them) in combination with all the supported operating systems and it wasn't a very successful time and experience. This was the main reason why there wasn't a official Pronterface version 2.0 for a long time (>2 years).

Side mark: I was tinkering the last days on some tests with wxPython regarding a Windows x32 version of Pronterface as wxPython now have x32 support again with version 4.2.1 only. This version as well do not work out of the box and you need to restrict at least one the library (Pillow) to an older version. The actual version(s) do not support x32 any longer. In the end I got it to compile, , running and tested today with Python 3.11.6 (but not tested for older versions of python so fare). But I'm not sure if I really want to make a official version because for now I have no clue if this will work for all other operating systems too or what else issues in addition will pop up then. Is it worth doing it? I don't know...

[rockstorm101]

why do you not use the actual Pronterface version in combination with wxPython 4.2.1?

I'll wear my Debian maintainer hat here. The reason why 2.0.0rc8 is the last package available in Debian stable is because I could not push the 2.0.1 version of Printrun due to pyglet being > 2.0 for the next release of Debian. So unless we solve the pyglet incompatibility (see #1291), Debian/Ubuntu users will need to install from source from now on to get the very latest Printrun as suggested here. (Printrun is no longer packaged for Ubuntu since 23.10 and Debian 13 won't have it either)

[DivingDuck]

Good point, I missed that already ...

[VanessaE]

I decided to try again today, fresh clone of Pronterface (commit 69bed06), and something is... not right -- but at the same time, something is WORKING unexpectedly.

The first time I tried to run it, the result was worse than before -- the part of the window where the 2d/3d view should be just showed a copy of whatever was under the window at the moment it started, and if I rolled/unrolled the window or minimized/restored it, that area changed to show whatever's under the window at that moment.

There was no meaningful output in the terminal. Not even a warning about the 3d view, nor anything about falling back to 2d mode.

Then played around a bit, trying a couple of variations, just to make absolutely sure I didn't do anything wrong. On the third try, for no immediately-obvious reason, it worked just fine!

And then I realized: On that run, I had launched another terminal after closing a few others (just reducing clutter on my desktop), and ran Pronterface from there, but forgot to enable the venv there beforehand. The GUI seemed completely normal and 3d view worked. I even loaded some gcode and it seemed just fine! Here's the output from such a run:

vanessa@rainbird:~$ cd RepRap/Printrun/
vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose
INFO:root:Loading config file /home/vanessa/.config/Printrun/pronsolerc
DEBUG:root:set last_window_maximized False
DEBUG:root:set last_window_width 1050
DEBUG:root:set last_window_height 720

So apparently something is being written or copied to the venv wrongly when it's being created. But what? And why should I even be using a venv if it runs correctly without one?

Here's the install spew:

vanessa@rainbird:~$ cd RepRap/
vanessa@rainbird:~/RepRap$ rm -rf Printrun/
vanessa@rainbird:~/RepRap$ git clone https://github.com/kliment/Printrun.git
Cloning into 'Printrun'...
remote: Enumerating objects: 13210, done.
remote: Counting objects: 100% (730/730), done.
remote: Compressing objects: 100% (315/315), done.
remote: Total 13210 (delta 466), reused 613 (delta 398), pack-reused 12480
Receiving objects: 100% (13210/13210), 81.03 MiB | 13.18 MiB/s, done.
Resolving deltas: 100% (8332/8332), done.
vanessa@rainbird:~/RepRap$ cd Printrun
vanessa@rainbird:~/RepRap/Printrun$ python3 -m venv venv
vanessa@rainbird:~/RepRap/Printrun$ source venv/bin/activate
(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 -m pip install -r requirements.txt
Ignoring pillow: markers 'sys_platform == "win32"' don't match your environment
Ignoring pyobjc-framework-Cocoa: markers 'sys_platform == "darwin"' don't match your environment
Ignoring pyreadline3: markers 'sys_platform == "win32"' don't match your environment
Collecting pyserial>=3.0
  Using cached pyserial-3.5-py2.py3-none-any.whl (90 kB)
Collecting wxPython>=4.2.0
  Using cached wxPython-4.2.1.tar.gz (73.7 MB)
  Preparing metadata (setup.py) ... done
Collecting numpy>=1.8.2
  Using cached numpy-1.26.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (18.3 MB)
Collecting pyglet<2.0,>=1.1
  Using cached pyglet-1.5.28-py3-none-any.whl (1.1 MB)
Collecting psutil>=2.1
  Using cached psutil-5.9.7-cp36-abi3-manylinux_2_12_x86_64.manylinux2010_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (285 kB)
Collecting lxml>=2.9.1
  Using cached lxml-5.1.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (8.1 MB)
Collecting appdirs>=1.4.0
  Using cached appdirs-1.4.4-py2.py3-none-any.whl (9.6 kB)
Collecting dbus-python>=1.2.0
  Using cached dbus_python-1.3.2-cp311-cp311-linux_x86_64.whl
Collecting pillow
  Using cached pillow-10.2.0-cp311-cp311-manylinux_2_28_x86_64.whl (4.5 MB)
Collecting six
  Using cached six-1.16.0-py2.py3-none-any.whl (11 kB)
Installing collected packages: pyserial, pyglet, appdirs, six, psutil, pillow, numpy, lxml, dbus-python, wxPython
  DEPRECATION: wxPython is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559
  Running setup.py install for wxPython ... done
Successfully installed appdirs-1.4.4 dbus-python-1.3.2 lxml-5.1.0 numpy-1.26.3 pillow-10.2.0 psutil-5.9.7 pyglet-1.5.28 pyserial-3.5 six-1.16.0 wxPython-4.2.1
(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 -m pip install Cython
Collecting Cython
  Using cached Cython-3.0.8-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (3.6 MB)
Installing collected packages: Cython
Successfully installed Cython-3.0.8
(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 setup.py build_ext --inplace
Compiling printrun/gcoder_line.pyx because it changed.
[1/1] Cythonizing printrun/gcoder_line.pyx
running build_ext
building 'printrun.gcoder_line' extension
creating build
creating build/temp.linux-x86_64-cpython-311
creating build/temp.linux-x86_64-cpython-311/printrun
x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -fPIC -I/home/vanessa/RepRap/Printrun/venv/include -I/usr/include/python3.11 -c printrun/gcoder_line.c -o build/temp.linux-x86_64-cpython-311/printrun/gcoder_line.o
creating build/lib.linux-x86_64-cpython-311
creating build/lib.linux-x86_64-cpython-311/printrun
x86_64-linux-gnu-gcc -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv -O2 build/temp.linux-x86_64-cpython-311/printrun/gcoder_line.o -L/usr/lib/x86_64-linux-gnu -o build/lib.linux-x86_64-cpython-311/printrun/gcoder_line.cpython-311-x86_64-linux-gnu.so
copying build/lib.linux-x86_64-cpython-311/printrun/gcoder_line.cpython-311-x86_64-linux-gnu.so -> printrun
(venv) vanessa@rainbird:~/RepRap/Printrun$ 

It took a bit of time to build wxPython, maybe 10 minutes (I didn't time it).

[rockstorm101]

I decided to try again today, fresh clone of Pronterface [...] the part of the window where the 2d/3d view should be just showed a copy of whatever was under the window at the moment it started, and if I rolled/unrolled the window or minimized/restored it, that area changed to show whatever's under the window at that moment.

There was no meaningful output in the terminal. Not even a warning about the 3d view, nor anything about falling back to 2d mode.

[...] On the third try, for no immediately-obvious reason, it worked just fine! [...] On that run, I [...] ran Pronterface from there, but forgot to enable the venv there beforehand. The GUI seemed completely normal and 3d view worked.

Hi @VanessaE, thank you for your detailing your findings. Would you mind sharing the output of reportbug --template pronterface in your Bookworm system? Only the part where it says "Versions of packages pronterface depends on" really. Two thoughts come to mind:

1. The combination of dependencies installed by the package manager works while the one installed via pip install -r requirements.txt doesn't. Hence why I'm trying to find the mismatch.
2. Or, dependencies installed via Debian's repositories are configured in a way which is better suited to fit your system/GPU/window-server configuration.

I confirm I can reproduce the behavior you describe. In my machine, when running from source, I followed your steps and found the same issue where the 2D/3D view did not work and showed the background instead. Installing pyglet 2+ inside the virtual environment via python3 -m pip install -v "pyglet>2" made the 2D/3D view work again though only in 2D mode (as expected) throwing an import error on pyglet.gl. Could you please try to confirm that this behaves the same for you?

[VanessaE]

reportbug --template pronterface

...returns Unable to identify a valid from address, please run 'reportbug --configure' which makes sense, since I've never set that up (it asks too many questions). However, I can get the output you want with a quick one-liner:

(venv) vanessa@rainbird:~/RepRap/Printrun$ for i in $(apt-cache depends pronterface|cut -f 2 -d ":"|grep -v "<"|sort|uniq); do echo -n $i " -- "; apt-cache show $i |grep Version; done
printrun  -- Version: 2.0.0~rc8-2
pronsole  -- Version: 2.0.0~rc8-2
pronterface  -- Version: 2.0.0~rc8-2
python3  -- Version: 3.11.2-1+b1
python3-cairosvg  -- Version: 2.5.2-1.1+deb12u1
python3-gi  -- Version: 3.42.2-3+b1
python3-libxml2  -- Version: 2.9.14+dfsg-1.3~deb12u1
python3-numpy  -- Version: 1:1.24.2-1
python3-pyglet  -- Version: 1.5.27+ds-2
python3-wxgtk4.0  -- Version: 4.2.0+dfsg-3
slic3r  -- Version: 1.3.0+dfsg1-5+b2

2. Or, dependencies installed via Debian's repositories are configured in a way which is better suited to fit your system/GPU/window-server configuration.

I kinda doubt it, since Debian is, as far as I know, pretty generic in that regard.

Installing pyglet 2+ inside the virtual environment via python3 -m pip install -v "pyglet>2" made the 2D/3D view work again though only in 2D mode (as expected)

Yep, I can reproduce this behavior too, and terminal output looks like I'd expect:

(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose
INFO:root:Loading config file /home/vanessa/.config/Printrun/pronsolerc
DEBUG:root:set last_window_maximized False
DEBUG:root:set last_window_width 1050
DEBUG:root:set last_window_height 720
3D view mode requested, but we failed to initialize it.
Falling back to 2D view, and here is the backtrace:
Traceback (most recent call last):
  File "/home/vanessa/RepRap/Printrun/printrun/gui/viz.py", line 69, in __init__
    import printrun.gcview
  File "/home/vanessa/RepRap/Printrun/printrun/gcview.py", line 22, in <module>
    from .gl.panel import wxGLPanel
  File "/home/vanessa/RepRap/Printrun/printrun/gl/panel.py", line 28, in <module>
    from pyglet.gl import glEnable, glDisable, GL_LIGHTING, glLightfv, \
ImportError: cannot import name 'GL_LIGHTING' from 'pyglet.gl' (/home/vanessa/RepRap/Printrun/venv/lib/python3.11/site-packages/pyglet/gl/__init__.py)

[VanessaE]

I guess you guys missed my earlier question: why should I use a venv if Pronterface runs correctly without one?

[rockstorm101]

python3-wxgtk4.0  -- Version: 4.2.0+dfsg-3

I failed to build a wxPython 4.2.0 wheel for Python 3.11 (stumbled upon wxWidgets/Phoenix#2296) and I couldn't find one online so I'm unable to try exactly the combination that (allegedly) works. I suspect it is the wxPython-pyglet combination that is to blame/thank but I can't prove it.

why should I use a venv if Pronterface runs correctly without one?

Oh no, please use whatever works best for you. It is sad but, as you found out, running from source with an venv has a broken 2D/3D view as of today so probably not the best thing to do on your system.

[VanessaE]

Well since this combo works, perhaps that's a good enough reason to update the official Debian build and not worry about pyglet?

I mean, just use what's there like mine's doing now, and lock the version numbers of Pronterface's requirements according to the list I gave above?

[rockstorm101]

Well since this combo works, perhaps that's a good enough reason to update the official Debian build and not worry about pyglet?

If by "official Debian build" you mean the Printrun package at official Debian repositories, we (Debian maintainers) can't force the pronterface package to require pyglet < 2.0 and wxPython == 4.2.0 because that would break the next Debian release. Which is where virtual environments come handy, you can have any combination of dependencies for your program, regardless of the versions currently present in your system. Ideal scenario would be for Printrun to migrate to pyglet 2.x.