3D view broken in own-compiled package, Debian repo version is good -- part deux! #1390
Comments
|
Hmm, seemingly wxPython fails to create the GLCanvas. 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. |
Yep, it works perfectly in that regard. The repo build has some stylistic issues, but those don't impact the 3d view.
No clue there. I didn't see any errors during the build, but in all fairness there was a LOT of spew.
Dunno, I've had relatively poor luck in the past trying to mix |
|
Hi, 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) Long story short, don't use any Printrun v2.0.0 release candidate versions. 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... |
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) |
|
Good point, I missed that already ... |
|
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 720So 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). |
Hi @VanessaE, thank you for your detailing your findings. Would you mind sharing the output of
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 |
...returns (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
I kinda doubt it, since Debian is, as far as I know, pretty generic in that regard.
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) |
|
I guess you guys missed my earlier question: why should I use a venv if Pronterface runs correctly without one? |
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.
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. |
rockstorm101
added
the
2.x
|
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? |
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 |
|
The program is no longer willing to run at all without a virtual environment, like it would before. It throws these errors: vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose -c /home/vanessa/.config/Printrun/pronsolerc-2.x-small-HC
Traceback (most recent call last):
File "/home/vanessa/RepRap/Printrun/pronterface.py", line 30, in <module>
from printrun.pronterface import PronterApp
File "/home/vanessa/RepRap/Printrun/printrun/pronterface.py", line 32, in <module>
from . import pronsole
File "/home/vanessa/RepRap/Printrun/printrun/pronsole.py", line 32, in <module>
from platformdirs import user_cache_dir, user_config_dir, user_data_dir
ModuleNotFoundError: No module named 'platformdirs'Run inside a venv as one is normally told to, and I still have the problem of a completely broken 3d view as described above. When doing so, it also complains on the console about not finding Cython, even though I installed it as in the usual manner: I suppose that's another pyglet-related bug. So as of this moment, Pronterface is completely broken. I had to restore the older build from my backup drive in order to continue what I was working on (protip: don't play around with upgrading while in the middle of a big project 😛 ). What do I do now? |
|
Hi @VanessaE Maybe I can help a little for the warning message. The warning for gcoder_line happens if building the printrun.gcoder_line extension fails when I remember correct. For my installation I have 3 additional files after the building process runs successfully. Here is where the files are located for a Windows build (the last file should be named different depending on OS and python version). You can force building this with For the first error, this should be a easy fix. Looks like you missed importing modules via requirements.txt, The module platformdirs is not available: Best regards, |
|
I'm on Debian "Bookworm" 12.6. The install process shows pyglet at version 1.5.29, and wXpython is version 4.2.1 (and still no wheels, it has to be built). Here's the entire build log... note that I cloned into a dir in /tmp and cleared my pip cache, doing my work there instead of my usual location. You can also see the errors described in #1442: Show build log...For comparison, Debian's build of Pronterface 2.0.0-rc8 from the repository uses pyglet 1.5.27 and wxpython 4.2.0 (I think). Note that I do not have that build or its repository-supplied dependencies installed.
About that, no. That command doesn't work for me, don't think it ever did. The errors it produces are shown above. In the past it's been safe to just ignore those errors -- I had this noted in a small document I maintain for doing system installs and manual builds of various programs.
Well, I didn't miss anything, for sure -- if a module is missing from |
|
Thanks for the update. I got a bit lost between all the issues and thought I better ask. Anyway, this do not help you. I'll try to build a VM with your Linux version and try do install Pronterface from source. But this will take some time as I have a very slow line here and my Linux knowledge is very limited these days. Well, I will see what happen. |
|
Hi @VanessaE, I was able to install a VM with Debian 12.6 in the end and go thru all the quirks to get a usable Python environment with everything what is needed for Pronterface. Even the compiling the G-Code parser works fine after I managed all quirks with GCC and Python. But I'm not able to create a working wxPython version that supports the Debian version and Python 3.11. What a waste of time. Sorry, I can't help on this as long as wxPython do not support matching packages for Debian 12.6 |
|
Hi all, sorry I've been terribly busy AFK lately.
I seem to remember you run Pronterface using system packages instead of a virtual environment. I guess you already tried but just in case, installing the Debian package
That's weird, after migrating to
Please try using one of the pre-built wheels meant for Ubuntu instead of the Debian ones. They'll probably work on Debian. |
You remember correctly, because of the broken 3d view when I try to run it from inside of the venv.
Ah HAH! That made it work, outside of the venv. Meanwhile, here's a revised build and run log with the Show log...EDIT: replaced that log with a new build that includes erasing and re-cloning Printrun and wiping my pip cache and running the new build with my usual config file. I did not try to USE the first build that I did in a temp dir, that was just a quick compile and run to see if it looks right, and it does. Since it seems right, and it's able to at least connect to my printer, I've replaced my working install with a whole new build (not done in the temp dir of course 😛 ). I will report back if it has any problems. Still has that damn autoraise thing happening tho.
I tried that previously, no bueno. One of the Ubuntu wheels did "work", but it didn't behave any better than just letting it compile WxP. But that was before you mentioned the right package to install for the platformdirs issue. |
|
Hi @rockstorm101,
I tried that as well with https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-22.04/wxPython-4.2.1-cp311-cp311-linux_x86_64.whl and got a lot of errors with not available wxPython and missing library imports for all kind of lib* when I try to use it with Ppronterface. I don't know if his a a problem with the Debian-12.6.0-amd64-netinst.iso I had install in a newly created VM. I tried to add a bunch of those missing modules but that never seems to end 🙂 |
Hi @VanessaE, since you didn't report back, may we assume everything is running smooth for you so far? That would mean the "only" remaining issue would be the broken 3D view. |
|
Oh, yes, sorry about that. The program runs pretty much as it did before when I realized back then I had been running it outside the venv (i.e. it's only broken when inside it). |
|
May I ask, are there any reasons not to migrate to pyglet>=2 ? |
|
Yes, because it isn't compatible with 1.5.x. See https://pyglet.readthedocs.io/en/latest/programming_guide/migration.html |
Sure, I meant are there any reasons, besides that it will require time and know-how =) On the other hand as far as I can see printrun uses pyglet merely as bindings to libGL, in such a case I suppose the migration won't be as drastic and we could keep most of the current legacy opengl code as-is. Unfortunately, as for now I've run into the original issue reported by @VanessaE: 3D view of Pronterface doesn't work even within a venv with pyglet-1.5. I'll have to debug this first otherwise I won't know whether the problems are caused by migration or whatever causes that issue. My current working hypothesis is that it has something to do with the fact that wxWidgets-3.2 is by default built without wxWidgets-2.8 compatibility support (at least here in Gentoo). And it seems they changed quite a bit how wxGLCanvas works between 2.8 and 3.2. |
On Windows we use wxPython 4.2.2 already and if I remember correctly our minimum release is 4.2 (or better 4.2.1) since Pronterface 2.1. We had quite some compatibility trouble with the version before 4.2. I also had tried to run Debian on a virtual machine what in the end works somehow but I didn't got Pronterface running from source and give up after 2 days of frustrating efforts in finding compatible python libraries. I had never seen so much compiling errors all over the place. But to be serious, I'm not a Debian specialist and it is quite possible that my lack of knowledge was a bigger part of this experience. |
All graphics hardware since around 2008 should support OpenGL3 ("modern opengl") I would be surprised if many people run Pronterface with 3D view on something older. |
|
Ok, since there are no major reasons not to migrate, I'll create an issue to discuss/track progress on the migration. Now to this particular bug... I've did some testing and prepared a small example that reproduces the same issue. So clearly the issue is somewhere between pyglet and wxPython. I suspect particularly this lines which were copied from the printrun. It seems to be an attempt to marry wxWidget's GLCanvas's context with the pyglet's one but looking at it more closely the code seems pretty nonsensical to me now. The weird fact is that when I import opengl functions like So I also suspect that the issue is also related to order of initialization.
I was wrong and it seems there is no direct connection to the issue. |
|
If you choose to migrate anything, please just make sure Pronterface and its deps still build fine in Debian stable. 🙂 |
|
I found what conflicts with wxWidgets GLCanvas: it's pyglet's diff --git a/printrun/gl/panel.py b/printrun/gl/panel.py
index 0253599..3497fdc 100644
--- a/printrun/gl/panel.py
+++ b/printrun/gl/panel.py
@@ -24,6 +24,7 @@ from wx import glcanvas
import pyglet
pyglet.options['debug_gl'] = True
+pyglet.options['shadow_window'] = False
from pyglet.gl import glEnable, glDisable, GL_LIGHTING, glLightfv, \
GL_LIGHT0, GL_LIGHT1, GL_LIGHT2, GL_POSITION, GL_DIFFUSE, \It should be relatively safe to do since pronterface doesn't use pyglet's windows anyway and can't take any advantages of sharing context with them. I suspect it happens because there is a deeper underlying regretion in wxWidgets, but I'm not sure, if I want to debug this any further. So, can we just apply the fix?
It's not up to me to decide, but generally it depend of how hard it would be to maintain support for both old and new pyglet; and since bookworm packages pyglet-1.5, the master will might not work out of the box on it. In such case you could always use older versions of printrun or a |
It looks like on linux/X11 pyglet's shadow_window conflicts with wxWidget's GLContext. Since pronterface can't make use of it anway, it makes sense to just disable it. Bug: kliment#1390
Yes it should be save because pronterface does not share data between contexts (3d panels). so we don't need the shadow context. There is btw already PR #1314 that proposes this change. |
Correct me if I'm wrong, but as far as I understand pronterface doesn't use contexts provided by pyglet at all; instead it uses the one created by wxWidgets. So even if we wanted it wouldn't be possible to use it (without some low-level shenanigans). Right?
mm... it's exactly the same... I'll close my then... |
|
Yes we use wxWidgets to create the context, but it is then handed over to pyglet and used by pyglet. It always stays the same context. So if we have another compatible opengl context, it should work. But I don't have much experience with context sharing specifically. |
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:
These errors seem suspiciously similar to #1389, but
requirements.txtalready 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.
The text was updated successfully, but these errors were encountered: