#linuxcnc-devel | Logs for 2016-06-27

Back
[01:53:42] <linuxcnc-build> build #431 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/431 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:55:49] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #33: My repository is correct:... 02https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-228683726
[06:44:18] <trasz> jepler: damn, i didn't realize this was related to the lsmod thing.
[06:44:33] <trasz> jepler: however - your later commit fixes that problem, right?
[06:45:13] <trasz> jepler: the "revamp *mod detection"?
[07:18:33] <skunkworks> zlog
[07:25:51] <jepler> trasz: well looks like our buildbot hasn't finished building that yet(!) but that's my hope, that the configure-foomod branch would replace that commit I suggested to you, but which broke linux badly.
[07:54:06] <KGB-linuxcnc> 03Jeff Epler 05master 5657de0 06linuxcnc 10src/emc/usr_intf/stepconf/axisa.glade 10src/emc/usr_intf/stepconf/axisx.glade 10src/emc/usr_intf/stepconf/axisy.glade 10src/emc/usr_intf/stepconf/axisz.glade stepconf: take nicokid's version of these files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5657de0
[07:54:06] <KGB-linuxcnc> 03Jeff Epler 05master 44c5fb9 06linuxcnc 10src/emc/usr_intf/stepconf/stepconf.py stepconf: temporarily disable "sanity test" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=44c5fb9
[07:56:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #33: I can't directly take your branch because of the boring technical reason that not all the commits in your branch have the "signed-off-by" message. But when preparing #71 to fix that problem, I was not careful enough.... 02https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-228731786
[08:03:19] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened issue #86: entry fields blank on stepconf axis pages 02https://github.com/LinuxCNC/linuxcnc/issues/86
[08:05:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #87: configure: revamp *mod detection (06master...06jepler/master/configure-foomod) 02https://github.com/LinuxCNC/linuxcnc/pull/87
[08:13:56] <linuxcnc-build> build #684 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/684 blamelist: Jeff Epler <jepler@unpythonic.net>
[08:28:00] <linuxcnc-build> build #3480 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3480 blamelist: Jeff Epler <jepler@unpythonic.net>
[08:31:32] <jepler> > 33.373: timeout waiting for joint 0 to stop at -1.000 (pos=-0.805, vel=-0.269)
[09:27:49] <linuxcnc-build> build #4284 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4284 blamelist: Jeff Epler <jepler@unpythonic.net>
[09:37:39] <jepler> linuxcnc-build: force build --branch=jepler/master/pgrep 0000.checkin
[09:37:44] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[09:40:22] <jepler> trasz: have you noticed how for some (sigh) python scripts, we have Makefile rules that delete the shipped #!-line and replace it with the python interpreter detected by configure? e.g., emc/usr_intf/axis/Submakefile's rule starting $(PYBIN): ...
[09:43:52] <trasz> jepler: i've seen... "something", but didn't pay much attention to it, tbh.
[09:45:12] <trasz> jepler: i kind of assumed that you wouldn't do something like this, when you could just put some %%MARKERS%% there instead.
[10:02:41] <jepler> if there are two possible ways to do something, we develop a third and then do them all
[10:30:54] <linuxcnc-build> build forced [ETA 1h35m03s]
[10:30:55] <linuxcnc-build> I'll give a shout when the build finishes
[11:09:58] <seb_kuzminsky> laws and sausages and software
[11:11:11] <seb_kuzminsky> mozmck: as RM, do you want to do the honors on https://github.com/LinuxCNC/linuxcnc/pull/85 ?
[11:22:03] <skunkworks> wow - quite the list
[12:17:47] <mozmck> Hey seb_kuzminsky. I can try. How is that going to work doing it on Github? I guess I can merge, then pull locally then push to g.l.o?
[12:18:18] <mozmck> I don't know that I have permissions on github to do it
[12:23:43] <linuxcnc-build> Hey! build 0000.checkin #4286 is complete: Success [3build successful]
[12:23:43] <linuxcnc-build> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4286
[12:36:48] <seb_kuzminsky> mozmck: the process for merging a PR into linuxcnc is this:
[12:37:01] <seb_kuzminsky> fetch glo to your local repo
[12:37:12] <seb_kuzminsky> fetch the repo containing the PR branch into your local repo
[12:37:18] <mozmck> from github?
[12:37:35] <seb_kuzminsky> (in the case of #85 the PR branch is at glo as well, so it's easy, but sometimes it'll be a different repo on github)
[12:37:41] <mozmck> I have joint_axes16 locally
[12:37:47] <seb_kuzminsky> merge the PR into the destination branch in your local repo
[12:37:53] <seb_kuzminsky> push the result of the merge to glo
[12:38:10] <mozmck> Ok, so what happens to the PR then on Github?
[12:38:13] <seb_kuzminsky> cradek's glo-to-github mirror updater script will push the result to github
[12:38:20] <seb_kuzminsky> github will notice the merge and close the PR
[12:39:00] <mozmck> Oh, I see. I figured maybe it had to be closed manually.
[12:39:49] <mozmck> I'll do the merge here shortly then. Thanks for including me.
[12:40:09] <seb_kuzminsky> if you merge exactly the commit of the PR into the PR's destination branch, it'll get closed automatically once it gets to github
[12:40:29] <seb_kuzminsky> if you deviate in any way from that, you'll have to close the PR by hand
[12:41:23] <mozmck> I'll just pull the latest from glo and merge that I guess...
[12:43:49] <seb_kuzminsky> yeah, that sounds right
[12:44:02] <mozmck> Hmm, it wants a commit message.
[12:44:13] <seb_kuzminsky> you can verify that the commit sha of the PR is the same as the sha of the commit you're merging into master
[12:44:36] <mozmck> "Long anticipated merge of the joints/axes separation branch!"
[12:44:37] <seb_kuzminsky> for the merge? it should be pre-populated with something like "merge origin/ja16 into master"
[12:44:50] <seb_kuzminsky> aha yea that's a good one :-)
[12:46:20] <mozmck> this is a little scary - I should have let you push it :-)
[12:48:06] <seb_kuzminsky> here's a sanity check:
[12:49:44] <seb_kuzminsky> after your merge, run "git show"
[12:49:55] <mozmck> ok?
[12:49:57] <seb_kuzminsky> it should say this near the top:
[12:50:07] <mozmck> Merge: 44c5fb9 619da03
[12:50:26] <seb_kuzminsky> Merge: 44c5fb919801bdeef83035bebfd4a488c7278d0e 619da0300cb3a4765b6332472ca31925d625294e
[12:50:31] <seb_kuzminsky> yes, good
[12:50:48] <seb_kuzminsky> so the merge commit you made merges the right two commits together
[12:50:53] <mozmck> Ok, I guess I'm going to push then.
[12:50:59] <seb_kuzminsky> the current tip of origin/master and the tip of ja16
[12:51:02] <seb_kuzminsky> yeah man go for it
[12:55:16] <KGB-linuxcnc> 03Moses McKnight 05master a2f0de5 06linuxcnc Long anticipated merge of the joints/axes separation branch! * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a2f0de5
[12:55:36] <mozmck> It's just sitting there. It just occurred to me that I did not sign off so I bet it will be rejected. How do you even sign off on a merge?
[12:55:43] <mozmck> Oh, maybe it went through.
[12:56:37] <seb_kuzminsky> https://media.giphy.com/media/W62e03M7HqOvS/giphy.gif
[12:56:55] <cradek> you did the thing?
[12:56:57] <cradek> the thing is done?
[12:57:05] <seb_kuzminsky> it takes a long time to make a big push like that
[12:57:07] <seb_kuzminsky> the thing
[12:57:08] <mozmck> I think it is
[12:57:09] <seb_kuzminsky> it is done
[12:57:27] <cradek> http://imgur.com/c4jt321
[12:57:42] <cradek> :-)
[12:57:43] <seb_kuzminsky> heh
[12:57:51] <mozmck> :-)
[12:58:03] <seb_kuzminsky> https://media.giphy.com/media/s2qXK8wAvkHTO/giphy.gif
[12:58:16] <mozmck> No problems yet - better call it a success quickly before it's too late!
[12:58:17] <jepler> mozmck: you probably generated hundreds of e-mails, and those take time to send..
[12:59:05] <mozmck> I see, that ought to be fun!
[12:59:22] <cradek> yay to everyone
[12:59:51] <seb_kuzminsky> one of us should send a warning email to emc-users, since everyone's configs just broke
[13:00:00] <jepler> notme!
[13:00:21] <seb_kuzminsky> mozmck's the one that broke everything... :-P
[13:00:34] <seb_kuzminsky> see how this works?
[13:00:59] <mozmck> I saw that coming!
[13:01:13] <seb_kuzminsky> :-)
[13:02:24] <mozmck> So fixing the configs involves running a script (I've done it once), is there anything the script won't update? Any other items to note?
[13:03:10] <jepler> I'd wait until the html docs online update, then point at an anchor within http://linuxcnc.org/docs/master/html/getting-started/updating-linuxcnc.html
[13:03:12] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed issue #62: linuxcnc.stat.program_open() errors if called twice in a row 02https://github.com/LinuxCNC/linuxcnc/issues/62
[13:04:04] <jepler> (that closed as a result of pushing that branch, because I named that issue in a commit message that dewey applied in JA, but I'm not sure whether it's really fixed)
[13:07:48] <mozmck> jepler: ok, good idea
[13:08:42] <jepler> oh yay, it looks like it is fixed
[13:12:09] <micges> guys, do we still have any features request list anywhere?
[13:12:17] <seb_kuzminsky> i feel like i should smoke a cigarette now
[13:12:43] <seb_kuzminsky> micges: there's approx 6.02x10^23 on the mailing list
[13:12:58] <seb_kuzminsky> some are in the feature-request bugtracker on sourceforge
[13:13:07] <micges> hehe
[13:13:28] <jepler> github doesn't have separate bug and feature trackers, it has issues and pull requests and we don't get to create more groupings
[13:13:42] <seb_kuzminsky> this merge should probably be mentioned on the wlo frontpage
[13:14:02] <seb_kuzminsky> mozmck: do you want to learn how to do that, or have you had enough for one day?
[13:14:18] <seb_kuzminsky> if you send the email i'll volunteer to make a blog post from it
[13:15:01] <cradek> yay, alex said yay
[13:15:03] <mozmck> I'll try and send the email - but I might not get it done right now.
[13:15:47] <mozmck> I would not mind learning the webpage stuff sometime, but am pretty busy right now.
[13:15:51] <micges> I have so much machines to test with master ;)
[13:15:55] <seb_kuzminsky> sure, i understand :-)
[13:22:25] <linuxcnc-build> build #2467 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2467 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[13:22:25] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Kim Kirwan <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Andrew Kyrychenko <amkyrychenko@gmail.com>, Moses McKnight <moses@texband.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[13:22:35] <seb_kuzminsky> doh
[13:23:03] <seb_kuzminsky> Segmentation fault
[13:23:03] <seb_kuzminsky> basename: missing operand
[13:23:03] <seb_kuzminsky> Try `basename --help' for more information.
[13:23:10] <seb_kuzminsky> it's my arm machine overheating again
[13:23:18] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[13:23:24] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[13:24:02] <jepler> seb_kuzminsky: there are some newer odroids, want someone to send you one?
[13:24:16] <jepler> (might have 1.5 - 2x the compile performance of the u3 too)
[13:25:15] <seb_kuzminsky> you're looking at the xu4?
[13:25:26] <seb_kuzminsky> or c2?
[13:25:40] <jepler> xu4
[13:25:55] <seb_kuzminsky> wow, pretty inexpensive
[13:26:37] <jepler> not so much when you add a big e-mmc and boy can I recommend that for performance
[13:26:45] <seb_kuzminsky> let me see if i can improve the cooling on the u3 i have, before we spend any money
[13:27:30] <seb_kuzminsky> 0 12:00:21 seb@wheezy-armhf-u3 /home/seb> uptime 12:00:24 up 106 days, 21:32, 1 user, load average: 0.03, 1.91, 3.34
[13:27:36] <seb_kuzminsky> not bad
[13:29:43] <jepler> hmph apparently putting dry ice in 350°F cooking oil is not very exciting to see
[13:49:07] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 9d7f04e 06linuxcnc 10docs/src/Master_Documentation_es.txt docs: remove link to removed "mini" gui from spanish docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d7f04e
[13:59:26] <jepler> I have too many irons in the fire
[14:02:29] <linuxcnc-build> build #4287 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4287 blamelist: andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni <alex_joni@users.sourceforge.net>, Kim Kirwan
[14:02:29] <linuxcnc-build> <Kim@KimKirwan.com>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, sam sokolik <samcoinc@gmail.com>, Andrew Kyrychenko <amkyrychenko@gmail.com>, Moses McKnight <moses@texband.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[14:02:29] <linuxcnc-build> build forced [ETA 1h43m55s]
[14:02:29] <linuxcnc-build> I'll give a shout when the build finishes
[14:26:02] <mozmck> jepler: leave 'em there and crank the air up (may not make sense if you haven't done any blacksmithing...)
[14:34:39] <jepler> great, now I need to take up blacksmithing
[14:35:11] <mozmck> heh, if you leave the irons there and increase the air, they will melt and then you won't have as many irons in the fire.
[14:35:38] <mozmck> blacksmithing is pretty fun - I need to get a forge set back up.
[15:03:53] <linuxcnc-build> Hey! build 0000.checkin #4288 is complete: Success [3build successful]
[15:03:53] <linuxcnc-build> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4288
[15:17:47] <trasz> okay.
[15:18:21] <trasz> the freebsd port (as in, something like a source package) is almost ready.
[15:18:44] <trasz> now i only need to get libimg fixed.
[15:57:56] <seb_kuzminsky> the new master docs with the ja merge is up! http://linuxcnc.org/docs/devel/html/
[16:04:20] <mozmck> seb_kuzminsky: is there a good overview of the changes in joints_axes anywhere that I can point to in my email?
[16:11:07] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #88: configure: use (more) portable pgrep (06master...06jepler/master/pgrep) 02https://github.com/LinuxCNC/linuxcnc/pull/88
[16:11:52] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #88: will push a fresh version with merge conflict fixed soon. 02https://github.com/LinuxCNC/linuxcnc/pull/88#issuecomment-228869659
[16:15:15] <cradek> trasz: that's awesome
[16:18:51] <cradek> alex!
[16:19:03] <alex_joni> hiya
[16:19:13] <alex_joni> power went out, screen didn't restart ;)
[16:19:22] <seb_kuzminsky> mozmck: the only one we really have is this: http://linuxcnc.org/docs/devel/html/getting-started/updating-linuxcnc.html#_updating_configuration_files
[16:19:26] <seb_kuzminsky> hi alex_joni !
[16:19:29] <alex_joni> hi seb
[16:21:15] <jepler> alex_joni: you are officially congratulated
[16:21:21] <jepler> for your work on joints-axes
[16:21:25] <alex_joni> jepler: hah
[16:21:32] <alex_joni> I'm happy to see it finally got merged
[16:22:23] <alex_joni> it started with cleaning up names & such
[16:26:14] * alex_joni is off to bed
[16:26:22] <jepler> see you
[16:26:48] <alex_joni> hopefully less busy times await
[16:27:30] <seb_kuzminsky> no feature branch survives first contact with users
[16:29:37] <PCW__> Wow you guys have been busy
[16:29:38] <PCW__> so master is now JAx?
[16:29:46] <mozmck> ja
[16:29:47] <seb_kuzminsky> JA is merged into master
[16:30:25] <PCW__> That's really great
[16:30:40] <seb_kuzminsky> cradek thinks everything's fine
[16:30:56] <PCW__> just a little pain and suffering with configs
[16:31:21] <mozmck> I'm not sure I'm the best one to write this email :( How does this look? http://pastie.org/10892181
[16:31:23] <seb_kuzminsky> possibly one or two bugs to find
[16:32:24] <seb_kuzminsky> mozmck: that looks pretty good to me
[16:32:42] <seb_kuzminsky> my only suggestion is to call out the committers in the ja16 branch by name
[16:32:55] <mozmck> All of them?
[16:33:18] <mozmck> or the ones listed in the meeting?
[16:33:31] <jepler> git log --format=%aN 44c5fb9..619da03 | sort | uniq
[16:33:51] <jepler> I believe that ^^ will list all the authors in the range
[16:34:05] <jepler> and based on the earlier merge commit I think that's the list of authors whose commits were on JA-last
[16:35:25] <mozmck> Interesting - you do a lot more git than I do!
[16:35:49] <jepler> mozmck: yeah I spend literally hours a week using it
[16:35:54] <jepler> I want to say hours a day but that's probably not quite true
[16:36:09] <mozmck> I get this list: Alex Joni, Andrew Kyrychenko, andypugh, Andy Pugh, Chris Radek, Dewey Garrett, Jeff Epler, Kim Kirwan, Michael Geszkiewicz, sam sokolik, Sebastian Kuzminsky, Stephen Wille Padnos
[16:36:12] <jepler> .. I probably don't go an hour of my professional day not invoking git once
[16:36:43] <jepler> get rid of the andy dupe and you've got a good list to name
[16:36:48] <seb_kuzminsky> +1
[16:36:49] <mozmck> ok
[16:37:23] <mozmck> Should the title mention breaking configs to catch attention?
[16:37:28] <cradek> sweet
[16:37:37] <seb_kuzminsky> mozmck: oh, yeah, good idea
[16:37:48] <mozmck> ok
[16:38:13] <seb_kuzminsky> there's about to be storm of emails about machines that suddenly won't start
[16:38:53] <cradek> ... from folks who should have been using releases all along
[16:39:36] <seb_kuzminsky> maybe... it sure helps everyone when people test master
[16:39:49] <seb_kuzminsky> stable releases are for folks who have to get work done :-)
[16:54:19] <seb_kuzminsky> that email is great mozmck
[16:59:27] <mozmck> thanks
[17:32:18] <mozmck> Is there any way that the G64 setting can get lost or reset? I've had several reports where a machine will cut a part fine, and then they cut another one and all the corners are badly rounded.
[17:33:17] <seb_kuzminsky> is there a round-corners setting in [RS274NGC]RS274HGC_STARTUP_GCODE ? that could cause it
[17:33:36] <mozmck> round-corners?
[17:33:45] <jepler> the part program should always specify the relevant modal codes, not rely on them coming from somewhere else like startup codes
[17:33:46] <seb_kuzminsky> i mean, a g64 with a big P
[17:34:26] <seb_kuzminsky> or with no P
[17:34:51] <mozmck> jepler: I agree, and our sheetcam post does just that.
[17:35:04] <seb_kuzminsky> the G64 docs even say that: http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g64
[17:35:07] <jepler> Was RFL being used?
[17:35:08] <cradek> m2/m30 are not documented to reset g64
[17:35:54] <mozmck> So every file has G64 P0.010 Q0.001 at the top. But, I also put that in the startup code in the case the RFL gets used without running a part program first.
[17:37:02] <mozmck> But so far the reports I have had seem almost random. They will have it once, and I don't get good details, but then they will re-start linuxcnc and they say that fixed it and I don't hear any more from them.
[17:37:33] <jepler> I think seb_kuzminsky discovered that the execution of RS274NGC_STARTUP_CODE was *cough* less than fully dependable
[17:37:46] <jepler> and it's better now, in the unreleased tips of at least 2.7 and master
[17:38:04] <seb_kuzminsky> i recently changed abort (eg, Esc in Axis GUI) to run the RS274NGC_STARTUP_CODE, it used to not do that
[17:38:08] <seb_kuzminsky> not sure if that was right
[17:38:28] <seb_kuzminsky> also, at startup there used to be a race in Task to get the RS274NGC_STARTUP_CODE run
[17:38:38] <jepler> it's the latter race I was referring to
[17:38:48] <seb_kuzminsky> the race is in 2.6.12 and 2.7.4, but not in the tips of those branches (and not in the tip of master)
[17:38:52] <jepler> I didn't know you'd deliberately started executing RS274NGC_STARTUP_CODE based on UI actions
[17:39:24] <seb_kuzminsky> it was always getting executed, but then cleared
[17:39:31] <seb_kuzminsky> in the same racy way
[17:39:36] <jepler> oh interesting
[17:39:42] <jepler> insane, but interesting
[17:39:42] <mozmck> Hmm. I really need to get more information on what they did to get it to happen. The people that have reported have not mentioned doing a RFL
[17:40:06] <mozmck> Naturally we have not had it happen to us...
[17:40:17] <seb_kuzminsky> jepler: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/rs274ngc_pre.cc#L2567
[17:41:07] <seb_kuzminsky> all i did was add the call to program_end_cleanup()
[17:41:21] <seb_kuzminsky> oh, and "_setup.on_abort_command" is RS274NGC_STARTUP_GCODE
[17:41:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/pgrep 5c1ac50 06linuxcnc 10scripts/linuxcnc.in 10scripts/realtime.in 10src/configure.in configure: use (more) portable pgrep * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c1ac50
[17:48:17] <andypugh> Can halcompile have the -g flag?
[17:58:01] <cradek> I wonder if a drop of anti-seize belongs on my drawbar thread
[17:59:37] <andypugh> Interesting question
[17:59:51] <andypugh> Either yes, or no is the answer I think.
[17:59:57] <cradek> I agree
[17:59:59] <mozmck> grease it!
[18:00:23] <cradek> I'd like for it to be easier to work, but I don't want to screw up the collet or have it come loose when on
[18:00:54] <cradek> it'd be easy to clean off the collet, but not easy to get off the drawbar, which is fairly captive
[18:01:04] <andypugh> Anti-seized bolts don’t typically show more tendency to loosen
[18:01:17] <mozmck> This latest report of the rounded corners was an RFL - and it looks like the G64 in the STARTUP_CODE may not have been applied - I need to test that more, and try seb's fixes.
[18:01:18] <cradek> that's a very nice data point
[18:06:23] <jepler> andypugh: from a quick gander at the source, I expect RT modules built by halcompile to be built with -Os -g (optimize for size, include debugging information).
[18:06:52] <andypugh> jepler: Great
[18:07:02] <andypugh> Let me see if that works then
[18:09:15] <jepler> I'm able to add a breakpoint on the _ function of test_use.comp, which is built with halcompile inside our testsuite (so it won't exist in a package or if you haven't 'runtests' once)
[18:09:19] <jepler> Breakpoint 1, _ (__comp_inst=0x7fd3601540d8, period=1000000)
[18:09:21] <jepler> at test_define.comp:9
[18:09:24] <jepler> 9 test_define.comp: No such file or directory.
[18:09:24] <jepler> it finds the breakpoint but not the source file
[18:09:56] <andypugh> I was going to use the addr2line thing
[18:10:00] <andypugh> (or try to)
[18:10:00] <jepler> (gdb) directory ~/src/linuxcnc/tests/symbols.0
[18:10:00] <jepler> Source directories searched: /home/jepler/src/linuxcnc/tests/symbols.0:$cdir:$cwd
[18:10:16] <jepler> ah this is uspace so I can use a real debugger
[18:10:27] <jepler> anyway, after specifying the source directory, then gdb successfully shows the lines from the source file
[18:12:19] <andypugh> add2line is not playing with that PulseCard component someone was asking about. It’s showing a fault on line 240, which only contains a closing brace
[18:13:18] <seb_kuzminsky> mozmck: what version of linuxcnc is running on the machine that displays this round corners problem?
[18:13:34] <andypugh> I wonder if kernel_sendmsg is thread-safe? Perhaps that’s his problem?
[18:13:54] <jepler> you can't call general kernel functions from RTAI realtime code
[18:14:16] <andypugh> Do you want to tell him that?
[18:14:24] <jepler> no
[18:15:00] <andypugh> Any particular reason?
[18:22:40] <jepler> not feeling compassionate enough to wade into the discussion, and failing to find authoritative documentation for my above assertin quickly
[18:22:57] <andypugh> What does hm2_eth use?
[18:24:11] <jepler> it only runs on uspace, not rtai
[18:25:09] <andypugh> Maybe he is using uspace. I forgot that…
[18:30:22] <jepler> no, his code is for kernel space
[18:31:01] <jepler> afk
[18:33:41] <jepler> well as far as being authoritative in our documentation, "man 3rtapi info" says:
[18:33:44] <jepler> Only a few functions may be called from realtime
[18:33:47] <jepler> code. This includes functions that perform direct
[18:33:49] <jepler> device access such as rtapi_inb(3). It excludes
[18:33:52] <jepler> most Linux kernel APIs such as do_gettimeofday(3)
[18:33:54] <jepler> and many rtapi APIs such as rtapi_shmem_new(3).
[18:34:20] <jepler> http://linuxcnc.org/docs/2.7/html/man/man3/intro.3rtapi.html
[18:40:43] <andypugh> I will let him answer the question first, I think.
[18:41:34] <andypugh> Was hm2_eth as uspace-only mandatory, or just easier?
[18:46:05] <seb_kuzminsky> it's so much easier in uspace that it's nearly mandatory
[18:46:39] <seb_kuzminsky> socket io from user space is easy, socket io from rtai is totally unknown at this point
[18:47:06] <andypugh> So, our Chinese friend has probably wasted a lot of time?
[18:47:19] <seb_kuzminsky> i dont know
[18:47:39] <seb_kuzminsky> maybe he/she has figured out how to do socket io from rtai and we can learn something
[18:48:37] <seb_kuzminsky> bbl
[18:48:56] <andypugh> Well, they seem to be calling a kernel function. Googling kernel_sendmsg “threadsafe” you don’t find much.
[18:59:52] <mozmck> seb_kuzminsky: this would be 2.7.x - I think the latest release or maybe later
[19:42:22] <seb_kuzminsky> the STARTUP_GCODE fix(?) went into 2.7 after 2.7.4, so the exact version number is relevant here
[19:42:44] <seb_kuzminsky> if your customers are running linuxcnc from debs, 'dpkg -l linuxcnc*' will tell you the exact version number
[19:43:28] <seb_kuzminsky> if they're using run-in-place, use scripts/get-version-from-git instead
[20:19:26] <KGB-wlo> push to master branch: http://linuxcnc.org/
[20:19:32] -linuxcnc-github:#linuxcnc-devel- [13wlo] 15SebKuzminsky pushed 1 new commit to 06master: 02https://github.com/LinuxCNC/wlo/commit/3fc91c1ac8bf4b2f5552780b92e4790f3e6ad401
[20:19:32] -linuxcnc-github:#linuxcnc-devel- 13wlo/06master 143fc91c1 15Sebastian Kuzminsky: post: announce ja merge
[20:33:44] <seb_kuzminsky> this might be a good time for a 2.8.0~pre2 release (or a 3.0~pre0)
[20:54:36] <mozmck> seb_kuzminsky: pre2?
[20:54:49] <seb_kuzminsky> we have a ~pre0 and ~pre1 already
[20:55:11] <mozmck> Oh, I didn't know there were any releases of master at all.
[20:55:20] <mozmck> or 2.8
[20:55:35] <seb_kuzminsky> you can list the tags with 'git tag -l v2.8*'
[20:55:43] <seb_kuzminsky> well, they're pre-releases
[20:56:03] <seb_kuzminsky> more like place-holders to make the build automation come up with reasonable-sounding version numbers for the master packages
[20:56:34] <seb_kuzminsky> i tried to capture some info about how that all works here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList
[20:57:13] <mozmck> I'm building packages for our customers. I have a couple of things I'm adding right now. I'll have to look again at the exact version this latest customer is running. I'll be doing more testing myself and will test before and after your changes.
[20:59:07] <mozmck> Yes, I better read that again. I'm thinking of emailing the list and having a couple of weeks before we do a complete feature freeze - but no large features even then.
[21:00:16] <mozmck> I'd like to polish up my simple RFL and get it in - and maybe there are others in the works like that which would not be too invasive.
[21:02:01] <seb_kuzminsky> it would be cool if the freebsd port made it in
[21:02:17] <mozmck> seb_kuzminsky: so do I remember that you would prefer a 3.0 release and then use N.N versions instead of N.N.N? I'm not sure I really like how firefox and others are doing it with the version now up to 40 something
[21:02:28] <seb_kuzminsky> i like your idea of mailing emc-developers and announcing the impending freeze
[21:02:39] <seb_kuzminsky> you could ask what features people want to get in
[21:02:58] <seb_kuzminsky> the version number scheme is really up to you :-)
[21:03:04] <mozmck> Yeah, that was my thought. We can make a pre-release now (or soon) anyhow.
[21:03:18] <seb_kuzminsky> i notice we're not really using the most significant digit, just the second-most, so...
[21:04:06] <mozmck> Yeah, well at some point that should be bumped up - maybe about now would be good since it has some pretty major changes.
[21:05:31] <seb_kuzminsky> makes sense to me
[21:06:14] <mozmck> I'm fine with N.N numbering if others would prefer that.
[21:06:37] <mozmck> 3.0, 3.1, ... 3.389476
[21:08:04] <seb_kuzminsky> 3.1415
[21:08:27] <mozmck> or just PI?
[21:08:48] <seb_kuzminsky> my preference for a one-digit release number (like "3") over a 2-digit release number (like "2.8") is only slight, and i trust your judgement and opinion here
[21:08:51] <mozmck> we would have to make sure that version ran on the RPI
[21:08:56] <seb_kuzminsky> heh
[21:09:11] <seb_kuzminsky> the rpi is not armhf architecture, is it?
[21:09:25] <mozmck> it's arm - what is armhf?
[21:09:42] <seb_kuzminsky> arm with Hard Floating-point math
[21:09:49] <seb_kuzminsky> instead of software-emulated math
[21:10:11] <mozmck> Oh, I think it is hf but would have to look to be sure.
[21:10:19] <seb_kuzminsky> i think rpi runs its own build of debian, for that reason, called raspbian
[21:10:40] <mozmck> I think people have run linuxcnc and/or mk on the pi.
[21:11:22] <mozmck> It has issues if I recall with the graphics and realtime
[21:44:14] <skunkworks> stupid question - I added continuous jog switches to the matsuura. Looking around - It seems like halui has continuous jog inputs. But I wanted to hook it up to the axis gui jog slider
[21:44:25] <skunkworks> How does touchy handle that?
[21:49:50] <cradek> touchy has hal pin inputs for continuous jog switches
[21:50:21] <cradek> http://linuxcnc.org/docs/2.7/html/gui/touchy.html#_hal_connections
[21:50:53] <cradek> AXIS doesn't have that - you'd have to use halui and the two guis would have separate jog speed settings
[21:51:18] <cradek> ... although I think AXIS's maxvel slider might affect halui's jogs
[21:51:19] <mozmck> One thing I'm not clear on with the releases - when a feature freeze is made - does this freeze master or is that the time to create a new branch for the next release?
[21:51:21] <cradek> you'd have to check
[21:51:56] <cradek> mozmck: opinions might differ, but I think it's best to do them at about the same time, and never really freeze master
[21:52:49] <cradek> sometimes it's clear when to branch - when a release feels close but someone wants to work on something destabilizing
[21:53:22] <mozmck> Sounds reasonable to me - I just was not sure how we have typically done it (or is there a typical?)
[21:53:29] <cradek> other times you can kinda defer it, if master is getting more stable instead of less
[21:54:14] <cradek> I guess I don't remember for sure
[22:17:10] <jepler> seb_kuzminsky: raspbian is not quite compatible with debian armhf, but pi2 and newer can actually run debian armhf and I don't honestly know why anybody dabbles with not-quite-armhf hardware. the original pi, and the pi zero (sigh) are armv6. https://wiki.debian.org/RaspberryPi
[22:18:58] <mozmck> jepler: what about the pi-3?
[22:19:57] <mozmck> Looks like it is better: http://perens.com/blog/2016/04/07/installing-the-native-debian-armhf-architecture-on-raspberry-pi-3-instead-of-raspbian/
[22:19:57] <jepler> mozmck: also compatible with debian arhmf, I think.
[22:20:20] <jepler> of course you still have to get a linuxcnc-compatible realtime kernel on it
[22:21:11] <mozmck> Didn't someone do some work with that on the devel list a little bit ago?
[22:22:09] <jepler> yes, someone has worked on a variant of the hm2-spi driver that uses bitbang spi on some pi board
[22:22:40] <jepler> (oh and fwiw linuxcnc is probably source-level compatible with raspbian)
[22:23:17] <jepler> afk and goodnight
[23:33:39] <seb_kuzminsky> mozmck: take a look at this: gitk bf5bffb4..{60cf79ef,b954ad3e}
[23:33:55] <seb_kuzminsky> it shows how we did the branching for 2.7
[23:34:37] <seb_kuzminsky> we created the 2.7 branch off master at 2642c3c7
[23:34:57] <seb_kuzminsky> we made the first few 2.7 commits, then tagged it v2.7.0~pre1
[23:35:25] <seb_kuzminsky> also made the first post-2.7 commit in master (to the VERSION file) and tagged that as v2.8.0-pre0
[23:36:11] <seb_kuzminsky> from that point on mostly stabilizing commits were allowed in 2.7
[23:36:31] <seb_kuzminsky> we also accepted new drivers, since they usually can't break other (pre-existing) things
[23:36:52] <seb_kuzminsky> master (aka 2.8) stayed open for new experimental features and possibly destabilizing things
[23:39:00] <seb_kuzminsky> skunkworks: the continuous jog buttons on my bridgeport go to halui
[23:40:59] <seb_kuzminsky> jog speed for the buttons is controlled by a pyvcp panel in axis, with a slider conected to halui.jog-speed
[23:41:27] <seb_kuzminsky> it'd be better if it shared the axis jog speed slider, but alas
[23:43:55] <skunksleep> seb_kuzminsky: cradek thanks.. that was about where I was at.
[23:44:48] <seb_kuzminsky> probably wouldnt be too hard to have axis expose its sliders to hal
[23:45:03] <skunksleep> Too hard to make the sliders hal pins?
[23:45:08] <skunksleep> Heh
[23:45:17] <seb_kuzminsky> right, just like the pyvcp sliders