#linuxcnc-devel Logs

Mar 06 2018

07:49 AM jepler: weird, you can't use a commandline like this to see when support ends for packages on Ubuntu LTS:
07:51 AM jepler: root@forum:~# faketime -f "+9year" check-support-status --type ended
07:51 AM jepler: .. I would expect this to list all the packages on the system, but it doesn't.
07:51 AM jepler: # faketime -f "+9year" date
07:51 AM jepler: Thu Mar 4 08:49:04 EST 2027
07:56 AM rene-dev: jepler you know stuff about the python bindings?
07:57 AM rene-dev: It seems there is a mix of both c api, and c++ boost pyhton bindings.
07:57 AM rene-dev: and I think both can be greatly simplified
08:00 AM jepler: rene-dev: I'm the author of the Python API that UIs use. I didn't write and have no great familiarity with the Python APIs for remap. (I do have to confess to boost::python experience at my day job though)
08:01 AM rene-dev: I was wondering about all those stuff: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interpmodule.cc#L235
08:02 AM rene-dev: the boost stuff claims it can just export it using rtti
08:09 AM jepler: http://www.boost.org/doc/libs/1_61_0/libs/python/doc/html/tutorial/tutorial/exposing.html#tutorial.exposing.class_data_members
08:09 AM jepler: class_<Var>("Var", init<std::string>())
08:09 AM jepler: .def_readonly("name", &Var::name)
08:09 AM jepler: you can expose things this way only if they are direct members of the class being exposed
08:09 AM jepler: but where those functions are used, it is exposing members of a contained structure
08:10 AM jepler: '&Interp::_setup::tool_offset' is not a valid way to get a pointer to the member of the contained structure that can be used with an Interp*, and I don't think there is a valid way in C++
08:10 AM rene-dev: ok... I have no experience with pyhton c bindings whatsoever
08:11 AM rene-dev: but suppose I want to work on python 3 support, where would I change it to pyhton 3?
08:12 AM jepler: rene-dev: I suppose you can start here and fix what breaks: $ ./configure --with-python=python3
08:12 AM rene-dev: ah, ok :D
08:12 AM jepler: here that gets me:
08:12 AM jepler: checking for python3... /usr/bin/python3
08:12 AM jepler: checking for python pango and cairo modules...
08:12 AM jepler: configure: error: Python pango and cairo modules not found!
08:12 AM jepler: install with "sudo apt-get install python-gtk2"
08:12 AM jepler: that last advice almost certainly being wrong
08:13 AM jepler: afk, have to go to that day job I mentioned earlier
09:12 AM rene-dev: hmm, I cant get past here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/configure.ac#L105
09:13 AM rene-dev: https://pastebin.com/u54WmyLR
09:32 AM jepler: you might try --with-boost-python=boost_python-py35 or similar (e.g., 3.5 for python 3.5 in debian stretch)
09:37 AM rene-dev: ./autogen.sh && ./configure --verbose --with-python=python3 --with-boost-python=boost_python-py35
09:38 AM rene-dev: configure.ac really only required a few brackets on prints, and stuff...
09:40 AM rene-dev: https://pastebin.com/2KqBSeY8
09:41 AM rene-dev: I removed the # && test "x$BOOST_PYTHON_LIBS" != x form line 106, maybe that was a bad idea? :D
09:41 AM jepler: -if $PYTHON -c 'import pango,cairo'; then
09:41 AM jepler: +if $PYTHON -c 'from gi.repository import cairo, Pango, PangoCairo'; then
09:41 AM jepler: also need to fix the site where pango, cairo are actually imported
09:41 AM jepler: site(s)
09:42 AM rene-dev: yes, apparently that is how you have to do it in python3...
09:42 AM jepler: wellllll not exactly
09:42 AM rene-dev: yes, of course. but that is much later...
09:42 AM jepler: that's about gtk2 vs gtk3 which is another whole burrito
09:43 AM rene-dev: I think we can use gtk2 with python3, with only minor changes
09:43 AM jepler: please pull-request the change to python3 compatible print() in configure.ac, that's easy to accept
09:44 AM rene-dev: yes, but there are also a few changes that break python2... that gi stuff for example
09:44 AM rene-dev: and the BOOST_PYTHON_LIBS
09:44 AM rene-dev: and the python version check I just removed
09:44 AM jepler: also try raise SystemExit(sys.hexversion<...) for python2/3 compatible syntax
09:45 AM rene-dev: but yes, a branch where we work together on py3 support sounds like a good idea...
09:45 AM jepler: yes, don't pull-request the broken stuff
09:45 AM rene-dev: yes
09:45 AM rene-dev: I just wantet to see how far I can get
09:45 AM rene-dev: unfortunately I dont know anything about autoconf...
09:46 AM jepler: well one thing you might not know is to look at config.log after a failure
09:46 AM jepler: then scroll back about 500 lines from the end to find the real error
09:46 AM jepler: "cannot find -lpython3.5" is the actual error when it fails to find the boost python library
09:46 AM rene-dev: if it just builds, thats already a huge step. then I can get norbert to fix the gui stuff. but he cant fix the configure stuff.
09:46 AM jepler: also it just says -lboost_python so that's wrong
09:47 AM jepler: oh, scroll back another 100 lines and it also tried with the requested boost_python library name
09:47 AM jepler: so the problem is, where's -lpython3.5 .. ?
09:48 AM rene-dev: https://pastebin.com/u383DXT5
09:48 AM rene-dev: im not sure if -lpython3.5 is wrong, or is I need to install something.
09:49 AM rene-dev: libpython3-dev is installed
09:49 AM jepler: it looks like the library name on debian is -lpython3.5m for some reason
09:54 AM rene-dev: thats better
09:58 AM jepler: python -c 'import distutils.sysconfig; print("python" + (distutils.sysconfig.get_config_vars().get("LDVERSION") or distutils.sysconfig.get_config_vars().get("VERSION")))'
09:58 AM rene-dev: undefined reference to `PyString_Size'
09:58 AM jepler: that's terrible but it seems to work on 2.7 on debian wheezy, 2.7 on debian stretch, and 3.5 on debian stretch
09:58 AM rene-dev: looks like -lboost_python must be -lboost_python3
09:59 AM jepler: that's what --with-boost-python= is supposed to control, is it working or not?
10:01 AM rene-dev: nope
10:01 AM rene-dev: ./configure --verbose --with-python=python3 --with-boost-python=boost_python-py35m
10:02 AM jepler: I don't have "m" on the library name here, debian stretch
10:02 AM jepler: I have /usr/lib/x86_64-linux-gnu/libboost_python-py35.so
10:03 AM rene-dev: so do I
10:04 AM rene-dev: if I remove the m I get /usr/bin/ld: cannot find -lpython3.5
10:05 AM rene-dev: but python and boost_python are 2 things
10:05 AM rene-dev: I have /usr/lib/x86_64-linux-gnu/libpython3.5m.so
10:06 AM jepler: Right, you need to change configur.ac where it's using get("VERSION") to be like mine above with LDVERSION
10:06 AM jepler: that makes it find -lpython35m
10:07 AM rene-dev: yes, I did that now
10:09 AM rene-dev: configure:8705: g++ -o conftest -g -O2 -I/usr/include/python3.5m conftest.cpp -lXinerama -l -lboost_python >&5
10:09 AM rene-dev: thats 1 -l to much
10:20 AM rene-dev: ah, LIBPYTHON was empty
10:21 AM rene-dev: better, but still not working :D https://pastebin.com/futvuJBF
10:25 AM rene-dev: ./autogen.sh && ./configure --verbose --with-python=python3 --with-boost-python=boost_python-py35 && make
10:47 AM jepler: it's got -lboost_python, so it's not using the --with-boost-python= that you specified. but that *IS* working for me.
10:47 AM jepler: Look further above in the log for an earlier link that used -lboost_python-py35 for the real error
10:48 AM rene-dev: thats working now
10:48 AM rene-dev: https://pastebin.com/svndjbB7
10:49 AM rene-dev: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/utils/Submakefile#L88
10:49 AM jepler: that latest pastebin still shows the wrong -lboost_python
10:49 AM rene-dev: yes, the --with-boost-python=boost_python-py35 fixed that
10:49 AM rene-dev: now its stuck at the halcompile
10:51 AM rene-dev: aaah, its not complainign about the endings
10:51 AM rene-dev: it complaing about your raise sytnax :D
10:51 AM jepler: yes
10:54 AM rene-dev: so now we are getting to the real problems
10:55 AM rene-dev: TabError: inconsistent use of tabs and spaces in indentation
11:24 AM rene-dev: jepler can you explain how halcompile works? whats up with the && and >>f
11:51 AM rene-dev: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762804
03:23 PM andypugh: Well, Dewey seems to have fixed another problem with the 7i73 LCD, but whether it is _the_ problem remains to be seen.
03:24 PM andypugh: In some ways it is nice to be fixing all these bugs. But I wish we could also fix the bug that is causing the users’ problem.
05:06 PM KimK: andypugh: But just think of your future self thanking you for fixing all those bugs that he never had to deal with... or something?
05:09 PM seb_kuzminsky: and all the users thanking you for fixing them before they ran into them
05:12 PM rene-dev: andypugh I reported that gl issue upstream. there is as much response as you would expect form gtk :)
05:17 PM jepler: which gl issue was reported to gtk?
05:17 PM hazzy: rene-dev: I know, it is very disappointing :(
05:18 PM sync: hazzy: on which gpu?
05:18 PM rene-dev: https://github.com/KurtJacobson/hazzy/issues/45
05:18 PM hazzy: Thanks rene, you were faster at the link :D
05:20 PM andypugh: As far as I can tell GTK has no support at all, and PyGTK has even less.
05:20 PM hazzy: sync: It seems to occur on all gpus
05:21 PM rene-dev: there are bugs in GPUs and drivers, but I doubt you can hit one by creating a context and drawing ONE vertex
05:21 PM sync: cannot confirm
05:22 PM sync: works for me on intel and nvidia
05:22 PM rene-dev: which os?
05:23 PM sync: linux
05:23 PM rene-dev: which distro?
05:23 PM sync: archlinux to be exact
05:23 PM rene-dev: TurBoss reports it working on ubuntu, but not on debian.
05:24 PM rene-dev: the bugtracker also reports it not working on freebsd
05:24 PM sync: it even works fine when I switch from nvidia to intel and back
05:27 PM TurBoss: hello
05:27 PM TurBoss: i think that could be GPU drivers..
05:29 PM sync: probably
05:30 PM TurBoss: it doesn't work on ubuntu 16.10 with amd radeon and mesa drivers
05:32 PM hazzy: sync: You may need to resize/drag the window around to trigger the problem
05:34 PM TurBoss: for me it triggers on some elemets hover
05:34 PM sync: I see the rendering bug but only between redraws
05:35 PM sync: once it redraws it works fine
05:35 PM hazzy: I just tested with a nvidia geforce 310 graphics and debian 9 and, it actually renders the triangle now, but if I resize the window I get the screen tearing
05:35 PM skunkworks_: what is the current best environment.. if gtk isn't good
05:39 PM sync: a geforce 310 might just be too old
05:40 PM rene-dev: to draw a triangle?
05:40 PM sync: yes
05:40 PM TurBoss: working system is a GT640 with propietary drives
05:40 PM sync: :)
05:41 PM sync: I had huge issues with drivers dropping support for my gpu at some point
05:41 PM sync: so I just upgraded
07:18 PM jepler: rene-dev: It would be best if you started with a pull request that doesn't break anything, like just the ones fixing print(), so that we can actually merge it into our master branch; you would omit things that we can't take in their current form, like 'from gi.repository import cairo, Pango, PangoCairo'
07:18 PM rene-dev: it does now pass tests with python2, I just messed up the indentation
07:19 PM rene-dev: Im not sure about the gi.repositoty
07:19 PM rene-dev: what needs fixing is the python version check: https://github.com/LinuxCNC/linuxcnc/pull/416/files#diff-3c97568e02244484e9302d85471d8c30L1564
07:20 PM rene-dev: all other changes so far dont break python2
07:20 PM rene-dev: probably best to do the gtk checks based on the python version check?
07:22 PM jepler: did you see that travis-ci has encountered errors on all your commits so far, though?
07:23 PM jepler: I did not investigate why
07:23 PM rene-dev: yes, thats fixed now
07:23 PM rene-dev: wait for the new check
07:24 PM jepler: 09:43:55 <jepler> also try raise SystemExit(sys.hexversion<...) for python2/3 compatible syntax
07:24 PM jepler: I suggested this fix for the sys.hexversion version check
07:25 PM jepler: earlier today
07:25 PM rene-dev: ah, didnt see that, sorry
07:25 PM jepler: s'oka
07:25 PM jepler: s'okay
07:26 PM rene-dev: I also think there is a problem with make clean, it leaves behind some .pyc files.
07:27 PM jepler: that sounds like it's also a good candidate for its own pull request
07:28 PM rene-dev: for that I need to find out where that is :D
07:31 PM TurBoss: hit this : http://dpaste.com/348M962
07:35 PM rene-dev: jepler ok, tests pass, version check fixed
07:36 PM rene-dev: TurBoss where was that .pyc file? I think thats a problem of the make clean target...
07:36 PM TurBoss: I managed to replace the halcomp.py but is recreated on make
07:37 PM rene-dev: yeah, dont do that. fix it in the source
07:37 PM rene-dev: what did you change?
07:37 PM TurBoss: cant figure from where it comes
07:37 PM TurBoss: I moved line 25 to the top of the file
07:38 PM rene-dev: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/utils/halcompile.g
07:38 PM TurBoss: yes
07:38 PM TurBoss: i'm working on that file
07:38 PM TurBoss: but can't figure from where the __future__ is
07:39 PM rene-dev: hm?
07:39 PM TurBoss: I mean
07:40 PM rene-dev: I just fixed the indentation problem
07:40 PM TurBoss: the objects/hal/utils/halcompile.py comes with a "from __future__ import print_function"
07:41 PM TurBoss: it should go in first place
07:41 PM TurBoss: but I can't figure from where it is generated
07:41 PM rene-dev: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/utils/Submakefile#L87
07:41 PM jepler: comp processes halcompile.g to produce halcompile.py, which is copied to bin/halcompile
07:41 PM jepler: er, "yapps processes..."
07:42 PM TurBoss: ok
07:43 PM rene-dev: jepler it seems like redirecting the print to the file is the only thing that stops halcompile form working
07:46 PM jepler: the __future__ is a bug in the python3 version of yapps at https://github.com/smurfix/yapps
07:47 PM jepler: http://paste.debian.net/1013528/ showing a modified version of expr.py, how it can be processed by debian system yapps, and how it cannot be processed with smurfix's yapps
07:48 PM jepler: oh the pyc problem is because python3 changed the rules AGAIN, introducing the __pycache__ intermediate directory!
07:49 PM jepler: at least I'm guessing that explains your report of leftover files with make clean + pyc
07:49 PM rene-dev: ah, so the clean target needs to know about that
07:49 PM rene-dev: yeah, it gives wired errors about magic numbers mismatching
07:50 PM jepler: I find nothing to like about python3, except that I'm not threatened with it being unsupported by python.org. yet.
07:50 PM rene-dev: do you think it would be better to provide a deb instead of unsing the pip3 version of yapps?
07:51 PM jepler: we follow Debian guidelines about packaging as best we can. Introducing software downloads during build, like using pip would, is not accepted by Debian.
07:51 PM rene-dev: well, there is no choice, is there?
07:51 PM rene-dev: can you make a deb?
07:52 PM rene-dev: norbert often complains how much easier stuff in python3 is for the gui, but I cant tell you what exactly it is.
07:53 PM jepler: yes, if we wanted to ship linuxcnc using python3 from linuxcnc.org before yapps using python3 is in the relevant debian release, some volunteer would have to make the yapps package and arrange for it to be hosted on linuxcnc.org.
07:53 PM jepler: I have the technical expertise to write debian packaging scripts if that is your question
07:54 PM rene-dev: that was my question :) because I know nothing about distributing packages :)
07:56 PM jepler: while you are working on getting the system to just "configure && make" with python3 you don't have to worry about it; get a compatible yapps in any way you see fit.
07:56 PM hazzy: jepler as far as I know the 'from gi.repository' imports are only for migrating from PyGTK to PyGobject, and have nothing to do with migrating from Py2 to Py3
07:56 PM jepler: hazzy: yes that sounds right to me.
07:56 PM jepler: thank you for stating it clearly
07:57 PM jepler: so the real work is to fix all the scripts listed by this search: $ git grep -E 'import.*(cairo|pango)'
07:57 PM rene-dev: You dont have to do it tonight, but it would probably be good if we had a solution within the next 2 years :D
07:57 PM hazzy: jepler good, i thought there might be some confusion on that, I know I had some initially :)
07:58 PM jepler: (the real work wrt "gi.repository")
07:59 PM jepler: ah/sigh the __future__ bug has been reported at least twice in the smurfix/yapps issue tracker :-/ https://github.com/smurfix/yapps/issues/5 https://github.com/smurfix/yapps/issues/4
08:15 PM jepler: https://github.com/smurfix/yapps/pull/6 should help, I think. I didn't actually test halcompile with it, mind yo
08:15 PM jepler: +u
08:24 PM rene-dev: cool :) how do I install that? it seems you cant print to file for 2 and 3 without future
08:29 PM TurBoss: With open():
08:29 PM TurBoss: As f
08:29 PM TurBoss: F.write
08:29 PM TurBoss: Without prints
08:31 PM TurBoss: I'll try that Tomorrow
10:16 PM hazzy: What part of LinuxCNC depends on Inkscape?
10:36 PM jepler: hazzy: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766945
10:37 PM jepler: hazzy: so .. doc building depends on it
10:37 PM jepler: and while on modern debian the dependency does not need to be expliclty listed anymore, we almost certainly have people building on systems with buggy dblatex packaging
10:37 PM rene-dev: halcompile works... f.write works on 2 and 3
10:37 PM jepler: 'night
10:38 PM rene-dev: now hitting errors in the bindings
11:07 PM hazzy: jepler: Thank you, that makes sense. Seems like most of the deps are for building the docs :)
11:11 PM hazzy: rene-dev: I got a fresh dev machine set up so now I can look at what you are doing (the previous os was FUBAR from trying to get Qt5 to work with Py2 for Qtvcp :D)
11:11 PM rene-dev: hazzy cool :) let me push what I have at the moment
11:12 PM hazzy: Great, thank you!
11:13 PM rene-dev: ok, all here: https://github.com/LinuxCNC/linuxcnc/pull/416
11:14 PM rene-dev: thats where it currently stops: https://pastebin.com/wdEkfy8L
11:15 PM hazzy: Fantastic! What is the build command for Py3?
11:15 PM rene-dev: its all there
11:15 PM rene-dev: first comment, currently you need to install yaps via pip3
11:16 PM rene-dev: if you need any additional deps, please post them there