Back
[06:23:47] <jthornton> well all is not well yet with LinuxMint, I get an error trying to run the Axis sim. This is the only thing that looks like an error "_tkinter.TclError: NULL main window" but I don't know what it means. The full error
http://pastebin.ca/3256626
[06:24:09] <jthornton> I guess some dependency issue is the problem
[06:25:53] <jthornton> OTOH gscreen and gommcappty or however you spell it runs
[06:27:37] <jthornton> a quick google shows me that my Tcl/Tk version is 8.6 on this computer
[06:29:21] <jthornton> and the wheezy is 8.5
[07:38:08] <jepler> axis works just fine on debian jessie, which also has Tcl/Tk 8.6.
[07:38:51] <jepler> If you installed any Tcl/Tk 8.5 packages in the process of installing build dependencies, remove them, reconfigure and rebuild
[07:39:05] <jepler> particularly any -dev packages which were for 8.5.
[07:56:21] <jthornton> ok, I'll check
[07:57:07] <jthornton> oh this is the installed version from buildbot not a RIP
[08:31:58] <seb_kuzminsky> jthornton: are you using the debs built for precise?
[08:32:34] <seb_kuzminsky> precise uses tcl 8.5
[08:33:13] <seb_kuzminsky> are you using rtai or uspace?
[08:36:08] <jepler> seb_kuzminsky: at the top it said something about run in place
[08:36:20] <jthornton> Linux mint 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 i686 i686 GNU/Linux
[08:36:27] <jepler> er it said =NO
[08:36:29] * jepler goes back to bed
[08:36:39] <jepler> yeah you can't run debs from the wrong operating system
[08:37:40] * jthornton heads for the shower, if warmer a bar of soap and standing outside on the deck would work
[08:37:44] <jthornton> dang rain
[08:48:37] <oshw> hello, i've a small patch for tooledit_widget.py regarding a bug into tool diameter sorting
[08:49:12] <seb_kuzminsky> oshw: do you have a git branch for us to look at? Or pastebin a diff and send us the link here
[08:51:03] <oshw> i can pastebin, but what's the procedure for push request on directly on git?
[08:52:08] <oshw> i've quite limited understanding on git. I imagine a sort of fork on github, then commit the patch, then make a pull request?
[08:52:20] <seb_kuzminsky> oshw: yeah, that's
[08:52:59] <oshw> good, i'll try
[08:53:00] <seb_kuzminsky> fork us on github, clone your fork to your local machine, commit, push to your fork, and then send us a pr with your new commit
[08:54:09] <oshw> http://pastebin.com/SK48M5Fu
[08:54:13] <seb_kuzminsky> in your commit message, write what problem your commit fixes (and how, if it's tricky)
[08:54:16] * seb_kuzminsky clicks
[08:54:31] <oshw> this is the patch for tooledit sorting problem
[08:55:03] <seb_kuzminsky> you pastebinned the whole file, so we can't easily tell what you changed and what's the old file
[08:55:26] <oshw> ok i'm going to follow git route
[08:55:33] <seb_kuzminsky> thanks
[08:55:40] <seb_kuzminsky> i've gotta go, but i'll read back later
[09:45:42] <oshw> pull request done
[09:48:39] <seb_kuzminsky> oshw: i see it
[09:50:18] <seb_kuzminsky> oshw: i'm not familiar with the tooledit widget, can you explain what it currently does that you think is wrong, and how your patch changes the behavior to fix it?
[09:51:28] <oshw> now the tooltable is sorted like: 1, 10, 1.1, 2, 3, etc.
[09:51:44] <oshw> sort is only for the first digit
[09:52:10] <oshw> very bad if you have a quite large tooltable :/
[09:52:42] <oshw> with this patch sorting is correct: 1, 1.1, 2, 3, 10, etc
[09:55:22] <seb_kuzminsky> i'm used to editing the tooltable file directly, or using the "tooledit" program, both sort by tool number by default (though i think the tooledit gui can sort by different columns)
[09:55:37] <seb_kuzminsky> does the tooledit widget sort by tool diameter (in the incorrect way you describe)?
[09:55:48] <oshw> yes
[09:56:00] <seb_kuzminsky> wow, strange
[09:56:05] <oshw> yep.
[09:56:11] <seb_kuzminsky> yeah, your fix seems like a big improvement in that case
[09:56:20] <seb_kuzminsky> i'm gonna try it out here
[09:56:31] <oshw> thank you Seb
[10:00:53] <seb_kuzminsky> is there a sample config in our tree that uses that widget?
[10:05:35] <oshw> gmoccapy
[10:15:38] <seb_kuzminsky> oshw: i'll try that one, thanks
[10:16:15] <seb_kuzminsky> hrm, our config picker isn't working for me (running 2.7.2 uspace on jessie, displaying over ssh X-forwarding, clicking Ok just locks it up)
[10:16:20] <seb_kuzminsky> i'll try RIP
[10:40:00] <seb_kuzminsky> how do i get to the tooledit widget in gmoccapy?
[10:45:54] <seb_kuzminsky> oh, i see it
[10:46:05] <seb_kuzminsky> you have to come out of estop and turn the machine on before you can edit the tool table
[10:46:25] <oshw> yes
[10:46:50] <seb_kuzminsky> oshw: i now see the error you're reporting, and i agree the current behavior is totally wrong
[10:47:59] <seb_kuzminsky> your commit fixes the sort order
[10:48:01] <seb_kuzminsky> looks good to me
[10:48:04] <oshw> :)
[10:48:19] <oshw> my first commit to linuxcnc!
[10:48:48] <seb_kuzminsky> c_morley: you know this code much better than i do, do you have any feedback? do you mind if i merge it?
[10:48:53] <seb_kuzminsky> oshw: thanks!! :-)
[10:49:03] <seb_kuzminsky> hmm, it should probably go on an earlier branch though
[10:49:13] <seb_kuzminsky> does 2.6 have tooledit_widget? 2.7?
[10:49:28] <oshw> yes also 2.6
[10:49:35] <seb_kuzminsky> ok
[10:49:46] <seb_kuzminsky> do you know how to move your commit to be based on 2.6?
[10:50:16] <oshw> git checkout 2.6, then do as done?
[10:50:23] <seb_kuzminsky> git checkout 2.6
[10:50:30] <oshw> ok
[10:50:43] <seb_kuzminsky> then "git cherry-pick $COMMIT"
[10:51:01] <oshw> ok
[10:51:02] <seb_kuzminsky> where COMMIT identifies the commit that's currently at the tip of your master branch
[10:51:06] <oshw> yep
[10:51:19] <seb_kuzminsky> you could use the sha of the commit, or just "master", since that happens to point to the commit you want
[10:52:31] <seb_kuzminsky> oshw: if you put into the commit message the explanation you gave me up above, about the sort order being wrong before and right afterwards, it'll help c_morley and niemand sonst (the gmoccapy author) when they look at it
[10:53:02] <seb_kuzminsky> also, commit with "-s", to add a signed-off-by line to your commit message, to indicate that you publish your commit under the GPLv2 license
[10:56:42] <oshw> after switch with "git checkout 2.6" i cant do the cherry-pick because of "merge problems"
[10:56:51] <oshw> i've to reset the branch?
[10:58:15] <seb_kuzminsky> hold on
[10:58:47] <seb_kuzminsky> what does "git status" say?
[10:59:21] <oshw> Unmerged paths: both modified: tooledit_widget.py
[10:59:24] <seb_kuzminsky> if it says there's a merge conflict in tooledit_widget.py, that means the original of that file in master and the original in 2.6 are different enough that your patch doesn't apply cleanly in 2.6
[10:59:29] <seb_kuzminsky> yep, that's it
[10:59:44] <seb_kuzminsky> ok, then you have to edit the file by hand and make it so your fix applies cleanly in 2.6
[10:59:48] <seb_kuzminsky> sorry :-/
[10:59:52] <seb_kuzminsky> hopefully it won't be too bad
[11:00:05] <oshw> ok np
[11:04:35] <oshw> arg.. i forgot -s
[11:05:12] <seb_kuzminsky> that's ok
[11:05:27] <seb_kuzminsky> with git you can modify your most recent commit with "git commit --amend"
[11:05:32] <seb_kuzminsky> so try "git commit --amend -s"
[11:07:40] <oshw> and should comment out the last commit?
[11:07:54] <seb_kuzminsky> i dont understand what you're asking?
[11:08:15] <seb_kuzminsky> do you mean the commit you originally made on your master branch, the one you sent the PR for?
[11:08:43] <oshw> git commit --amend -s open the COMMIT_EDITMSG, then what i should do?
[11:09:00] <seb_kuzminsky> oh, i see
[11:09:20] <seb_kuzminsky> you're currently editing the commit message, so if you're happy with what it says, just save and exit
[11:09:28] <seb_kuzminsky> what you save is what the final commit message will be
[11:09:36] <seb_kuzminsky> (unless you amend again and edit it)
[11:10:30] <oshw> but i've pushed it. I do add, commit, push automatically
[11:10:49] <oshw> so i have to with amend i can modify the commit, but i've pushed it
[11:10:56] <seb_kuzminsky> you pushed the un-signed-off commit to 2.6 on your github account?
[11:11:00] <oshw> yes
[11:11:03] <seb_kuzminsky> ah, i see
[11:12:02] <seb_kuzminsky> dont tell anyone i said this, but i think you should use "git push --force $GITHUB 2.6" (where $GITHUB is the name of your remote that points at your github repo)
[11:12:16] <oshw> hehe
[11:12:38] <seb_kuzminsky> that'll overwrite your 2.6 branch in your github repo with the 2.6 branch in your local repo, which you've set up to be more correct
[11:12:59] <seb_kuzminsky> normally we don't force-push, precisely because it overwrites remote branches (rather than append to them, like a normal push does)
[11:13:22] <seb_kuzminsky> but in this case it's your private remote repo, and you have not yet sent us a PR for the 2.6 branch, so it'll be ok
[11:13:59] <seb_kuzminsky> then you can close the PR you made for our master branch, and open a new PR asking us to merge your 2.6 branch into our 2.6 branch
[11:14:38] <seb_kuzminsky> c_morley and/or norbert (niemand) will look at it and merge it if they agree with your change, or give you better feedback than i can on what they think should change
[11:15:05] <seb_kuzminsky> as far as i can tell, it's a good change that makes the behavior better in a clean way, so it has my endorsement
[11:17:31] <oshw> 2.6 PR done
[11:18:21] <oshw> is it ok?
[11:19:43] <oshw> i see two PR, one for master other for 2.6
[11:34:56] <jepler> you should only make a pull-request for the oldest branch to receive the fix
[11:35:21] <jepler> newer branches will get the same fix by what is called "merging up"
[11:35:32] <jepler> that is, all changes in 2.6 are later merged to 2.7, and all changes in 2.7 are merged to master
[11:42:06] <oshw> ok
[11:42:13] <oshw> thank you for your time Seb
[11:47:57] <seb_kuzminsky> sure thing, thanks for your fix :-)
[12:51:33] <JT-Shop> I just did a fresh install in LinuxMint following these instructions
http://gnipsel.com/files/linuxmint/LinuxMint%20Notes.txt
[12:51:57] <JT-Shop> The docs showed up and the latency test works
[12:52:24] <JT-Shop> same as before Axis crashes with these errors
http://gnipsel.com/files/linuxmint/Errors.txt
[12:52:38] <JT-Shop> I made sure not to install and dev stuff
[12:55:21] <seb_kuzminsky> JT-Shop: i'm not sure about the crash, ubt i'd suggest removing the dkms stuff instead of forcing a recompile
[13:36:39] <cradek> [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
[13:36:44] <cradek> does this mean you have broken opengl?
[13:38:47] <jthornton> hmmm
[13:47:05] <skunkworks> does glxgears run?
[13:47:27] <jthornton> yes
[14:12:49] <jthornton> I ran sudo dmesg -c then ran Axis and the dmesg part is a lot shorter. sorry for not doing the before.
http://gnipsel.com/files/linuxmint/Errors.txt
[14:13:49] <cradek> _tkinter.TclError: NULL main window
[14:13:55] <cradek> this is still the error
[14:13:57] <cradek> I don't know what it means
[14:14:30] <jthornton> sounds like tkinter is having a problem creating the window
[14:15:06] <cradek> are you using wheezy debs on a nonwheezy system?
[14:15:22] <jthornton> precise
[14:15:36] <cradek> what
[14:16:08] <jthornton> deb
http://buildbot.linuxcnc.org/ precise 2.7-rt
[14:16:17] <cradek> is your system precise?
[14:16:40] <jthornton> on LinuxMint patched with Linux mint 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 i686 i686 GNU/Linux
[14:18:20] <cradek> which mint? is it based on precise?
[14:18:45] <jthornton> I'm looking to be sure
[14:20:52] <jthornton> oh crumb no its based on trusty
[14:21:11] <cradek> you'll probably have to build your own packages then
[14:21:37] <jthornton> yuck
[14:21:58] <cradek> why are you doing this? you want whatever they call the gnome2 successor?
[14:22:03] <jthornton> I'll install 13 which is based on precise
[14:22:24] <jthornton> debian wheezy is too hard to work with
[14:22:29] <jthornton> nothing works right
[14:22:44] <jthornton> can't get sharing to work
[14:23:00] <jthornton> tired of typing in my username and password
[14:23:06] <jthornton> and it goes on and on
[14:23:34] <jthornton> I just want something that works as good as Ubuntu 10.04
[14:23:50] <cradek> can't blame you :-(
[14:24:04] * jthornton goes back to work
[14:24:24] <cradek> ubuntu10 was definitely a local maximum
[14:25:39] <cradek> I think it was mint13 that I tried, and it was pretty wonky. hope it works for you.
[14:26:03] <skunkworks> jthornton: I have a samba file that seems to work ok with wheezy.
[14:26:09] <skunkworks> smb.conf
[14:26:43] <skunkworks> it allows you to connect to the share without a password. (I like living on the edge..)
[14:41:09] <KimK_laptop> "I just want something that works as good as Ubuntu 10.04", I have to say I agree with jthornton. BTW, Cinnamon is the fork of Gnome 3 and MATE (MAH-tay) is the fork of Gnome 2. I'm currently using Mint 17.2 Cinnamon for my laptop and liking it, but I haven't yet tried jthornton's forum script to install LinuxCNC. I will, though.
[14:42:00] <cradek> let's all pour one out for gnome2 and ubuntu10
[14:42:13] <cradek> thanks for the memories, you local maximums
[14:42:17] <KimK_laptop> Indeed!
[14:42:28] <cradek> ok I'm over it now
[14:49:55] <KimK_laptop> Mint 17.2 has Cinnamon 2.6, Mint 17.3 will have Cinnamon 2.8, which adds further desktop refinements.
http://segfault.linuxmint.com/2015/11/cinnamon-2-8-released/
[14:51:11] <mozmck> I'm using xubuntu 14.04 and mint 17.x with preempt-rt without any problems, but I'm compiling everything myself.
[14:51:39] <cradek> I just can't stomach ubuntu anymore, since they added the amazon spyware features
[14:52:02] <mozmck> I find mint to be the nicest overall, doesn't really matter which DE.
[14:52:19] <mozmck> I'm pretty sure that stuff is not in Xubuntu
[14:52:41] <cradek> yeah probably not, but I don't care
[14:52:58] <cradek> I don't trust them anymore because they aren't working in the interest of their users
[15:03:10] <KimK_laptop> mozmck: Have you written up a guide to that do-it-yourself preempt-rt compiling, for the rest of us?
[15:04:16] <mozmck> No, but I probably should. Parts of it are not real simple since I use the ubuntu kernel building scripts to generate packages.
[15:16:20] <KimK_laptop> I read that Mint 18 will be based on Ubuntu 16.04 LTS, and will have easy (one click in Synaptic?) desktop switching, but I don't have a link handy. So Mint 18 should be a good one to install long-term, regardless of DE. (Mint offers XFCE too, of course.)
[15:27:53] <mozmck> Yes, I use a hybrid of XFCE with the file manager from Cinnamon.
[15:37:17] <jepler> I bet if I used file managers and such I'd have a strong opinion about DEs too
[15:37:56] <cradek> true
[15:38:22] <jepler> and I do do things like change the window manager from the xfce default to openbox, so it's not like I'm thrilled with xfce as shipped
[15:39:31] <jepler> the core thing to remember is: it's not that we hate your particular choices when you prefer mint or ubuntu or fedora or gentoo to debian
[15:40:14] <jepler> but the core people who are actually writing the packaging scripts and building the kernels get to pick what they prefer and work on that
[15:46:25] <KimK_laptop> No problem. Plus there's the pure-open factor of Debian, which I get. (Yes, Mint has a mint-search-enhancer to remove. They get funding from that, they say.)
[19:24:16] <jepler> http://40.media.tumblr.com/8b229e2ab09785a69805172a73ce8e1c/tumblr_nxxcsnEdw91r9qk1io1_500.png
[19:30:43] <cradek> I know that guy
[20:06:56] <skunkworks> jepler: did you see that rob posted to the threading thread? he has a fix for the threading issue. (falling back to parabolic blending)
[20:37:23] <mozmck> skunkworks: where is that post?
[20:38:38] <jepler> skunkworks: I think I saw it go by, didn't pay much attention.
[20:39:44] <jepler> thi sone ?
http://forum.linuxcnc.org/forum/20-g-code/29685-g76-pause-in-z-during-exit-taper-linux-cnc-2-7-0?start=10#65302
[20:47:38] <skunkworks> yes.
[20:59:00] <jepler> mozmck: ^^
[21:42:49] <mozmck> thanks
[22:14:42] <mozmck> Hmm, I see in some configs that traj_period_nsec is set on the loadrt line. Does this directly set the variable of that name in motion?
[22:23:27] <mozmck> If so, it would appear that tp->cycleTime gets set to the TRAJ period, but it is called at the servo frequency
