Back
[09:21:23] <jepler> I am just sad at the failure to communicate that mini and keystick were broken in any recent branch, not jaX
[09:22:01] <jepler> or my failure to understand, as the case may be
[09:22:22] <jepler> that being the case, the *removal* of the UIs really doesn't belong in a jaX branch
[09:22:30] <jepler> does that viewpoint make sense?
[09:23:54] <cradek> you're right, but I think it's only a big deal if we're still very far from merge
[09:24:43] <cradek> I don't think removing them is any kind of emergency, and if it happens at the ja merge time, that's fine
[09:26:27] <mozmck> What is preventing a merge from happening soon?
[09:27:10] <cradek> it feels like it's close
[09:28:04] <jepler> two things: if someone decides they want to fix one of those UIs, it makes the revision history worse (whether the fixing happens before or after jaX is merged to master)
[09:29:03] <jepler> .. and putting it in jaX means that we have tied the choice "remove mini" to the choice "merge jaX" (though it can be undone, see first thing)
[09:30:01] <cradek> if you coordinated with dewey I bet he wouldn't mind if you picked that commit onto master now, or else moved it to be first in his branch
[09:30:59] <cradek> or do you think you'll want to fix them in master or an earlier branch? maybe I'm not understanding
[09:36:22] <seb_kuzminsky> i like the idea of having a text-mode gui, though i admit to never having used it beyond very basic testing
[09:36:38] <cradek> I like that too
[09:37:26] <cradek> but it's so far behind. it fell behind when (or even before) they added abc axes.
[09:37:51] <cradek> I used it in emc1, but I bet I never have in emc2/linuxcnc
[09:46:18] <jepler> I don't understand that there's any valid motivation to put those commits on jaX, except if we ERRONEOUSLY put "jaX busted keystick and mini" on a list somewhere of things that prevent merging jaX
[09:46:29] <jepler> and by all indications it is erroneous
[09:48:43] <cradek> my understanding is: they were broken before ja; working guis need massaging to work in ja => even if they weren't broken already, ja would break them unless someone did the extra work.
[09:52:05] <seb_kuzminsky> dewey did something no one else did, and actually tested all our guis and took notes, because he wanted to make sure they worked with JA
[09:52:06] <jepler> http://linuxcnc.org/iso/ now shows a directory listing of the old isos
[09:52:29] <jepler> .. my small contribution of the day
[09:53:21] <cradek> wow those are old!
[09:53:54] <cradek> I guess we didn't have an iso with 5.10
[09:54:07] <jepler> I don't remember what we did have
[09:54:10] <seb_kuzminsky> i guess we should probably move the current isos there too, and update the install links in the git docs
[09:54:15] <seb_kuzminsky> bbl, work
[09:54:28] <cradek> we used the virgin cd and had install instructions
[09:54:40] <cradek> remember we even ordered them from ubuntu
[09:55:37] <jepler> I do remember that
[09:58:46] <jepler> so AIUI it seems a lot more likely we should fix mini, which is only unusable when tk8.6 is in the mix (i.e., never on a fully supported linux distro yet), compared to keystick which has pretty clearly been unusable since 2.3.0
[09:58:59] <jepler> and I think dgarr even said he thinks he has a fix
[11:07:18] <skunkworks> zlog
[11:12:06] <skunkworks> I don't think Yishin stuff was no where near working. micges if I understand it - took his branch and tried to make it work - the little testing I did - still a ton of violations... I don't think people really know what is going on.
[11:12:39] <skunkworks> Plus with only a 1 segment look ahead planner - you are not going to get a speed increase - just slower and smoother.
[11:16:33] <seb_kuzminsky> skunkworks: your observation-based facts are ruining my emotional narrative
[11:17:40] <skunkworks> and as far as I know - I don't think any of that is in machinekit..
[11:19:22] <cradek> http://thread.gmane.org/gmane.linux.distributions.emc.devel/6364
[11:19:54] <cradek> I think this is the last code and test results I saw
[11:59:54] <KGB-linuxcnc> 03John Thornton 052.6 a18f23c 06linuxcnc 10docs/src/gcode/gcode.txt Docs: fix incorrect description for g43.1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a18f23c
[11:59:54] <KGB-linuxcnc> 03John Thornton 052.7 5af856c 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5af856c
[12:01:16] <seb_kuzminsky> wait, that's wrong
[12:02:49] <cradek> oops 2.7 and master are now the same
[12:03:54] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 2dcaff3 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2dcaff3
[12:04:03] <seb_kuzminsky> that resets 2.7 to where it was a minute ago
[12:05:04] <seb_kuzminsky> i'm resolving the merge of 2.6 into 2.7 now...
[12:07:22] <JT-Shop> what did I do?
[12:07:23] <jepler> oops I didn't merge that overleaf change did I
[12:09:18] <JT-Shop> I thought the merge from 2.6 to 2.7 on the doc change didn't work due to a conflict? So I was going to change 2.7 then push that and merge to master
[12:09:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 03ecf78 06linuxcnc 03docs/src/gcode/g-code.txt 10src/emc/usr_intf/axis/extensions/emcmodule.cc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=03ecf78
[12:10:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master ecc24a0 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ecc24a0
[12:10:43] <seb_kuzminsky> JT-Shop: you somehow accidentally made 2.7 point to master
[12:10:57] <seb_kuzminsky> that's the same mistake i made a few weeks ago, that jepler fixed for me
[12:11:26] <jepler> Subject: [ANNOUNCE] 4.1.15-rt17
[12:11:28] <seb_kuzminsky> i reset 2.7 to where it was before your push, then merged 2.6 into it (and resolved the conflicts), then merged 2.7 into master
[12:11:29] <JT-Shop> wow
[12:11:38] <JT-Shop> thanks
[12:11:39] <jepler> lots of changes related to the "omap" architecture. Isn't that beaglebone?
[12:11:45] <seb_kuzminsky> no problem
[12:11:47] <seb_kuzminsky> jepler: yeah
[12:12:23] <seb_kuzminsky> the dude who's the kernel.org official maintainer for the omap arm architecture is a big fan of linuxcnc, we've started collaborating on producing an rt-preempt bbb kernel
[12:12:33] <seb_kuzminsky> but it's slow going, like everything in my life :-/
[12:15:39] <jepler> no need to apologize
[12:29:22] <jepler> http://docs.emlid.com/navio/Downloads/Real-time-Linux-RPi2/ wonder if anybody's tried this with uspace
[14:27:05] <skunkworks> https://www.youtube.com/watch?v=wC9Ghj_I6OQ
[14:29:00] <archivist> the dwell at the end of each cut....
[14:37:39] <cradek> ooh that's some low acceleration
[14:39:17] <cradek> blending might even be turned off? the corners on the backplot are super sharp
[14:39:46] <cradek> cool parts though - wonder what they are
[14:40:46] <archivist> oil drilling pipe thread methinks
[14:41:33] <archivist> although I thought that was more rounded
[16:09:20] <linuxcnc-build> build #931 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/931 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Michael Geszkiewicz <micges@wp.pl>
[16:09:20] <linuxcnc-build> build #1613 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1613 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Michael Geszkiewicz <micges@wp.pl>
[17:03:37] <jepler> we're all doomed who wish to write software in C. I gave up about when I reached the second code fragment on page 3...
[17:03:40] <jepler> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf
[17:06:49] <andypugh> Clearly too subtle for me. I would no longer expect p and q to be identical after the *p = 10.
[17:08:22] <jepler> the memcmp establishes that the bit patterns of p and q are the same, so *p and *q would naively refer to the same "int"-sized storage in memory..
[17:08:25] <jepler> and yet by magic they don't
[17:10:26] <andypugh> No, not seeing it. The contents of p are changed after the memcmp?
[17:14:29] <jepler> I am not sure I understand it myself so I'll stop trying to explain it as though I do.
[17:15:10] <andypugh> It seems to say “If the contents of these two addresses are identical, then change one of them, and print the new value”
[17:49:40] <cradek> I don't know what the standard says, but since P points to unallocated memory, I doubt you can trust it to act how you expect
[17:51:21] <cradek> oh the memcmp is supposed to tell us whether Y is after X on the stack?
[17:51:22] <cradek> hmm
[17:51:25] <cradek> forget I said anything
[17:58:32] <cradek> VI is pretty funny/sad
[19:33:37] <KGB-linuxcnc> 03Chris Morley 05panelui d894f05 06linuxcnc 10(13 files in 3 dirs) component: panelui -add keyboard to command ui decoder * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d894f05
[19:33:38] <KGB-linuxcnc> 03chris morley 05panelui 50962ad 06linuxcnc 10src/emc/usr_intf/pyui/Submakefile panelui: fix submakefile to include validation spec * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=50962ad
[19:33:38] <KGB-linuxcnc> 03chris morley 05panelui dba6bdc 06linuxcnc 10(5 files) panelui: paper cuts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dba6bdc
[19:33:39] <KGB-linuxcnc> 03chris morley 05panelui 0682879 06linuxcnc 10src/emc/usr_intf/pyui/widgets.py panelui: fix radio button state change if re-pushed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0682879
[19:42:18] <linuxcnc-build> build #3770 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3770 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>, chris morley <chrisinnanaimo@hotmail.com>
[19:42:46] <linuxcnc-build> build #3772 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3772 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>, chris morley <chrisinnanaimo@hotmail.com>
[19:43:45] <linuxcnc-build> build #2980 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2980 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>, chris morley <chrisinnanaimo@hotmail.com>
[20:09:58] <linuxcnc-build> build #3784 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3784 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>, chris morley <chrisinnanaimo@hotmail.com>
[21:18:25] <KGB-linuxcnc> 03Dewey Garrett 05master 3f4b049 06linuxcnc 10tcl/mini.tcl mini.tcl: remove duplicate geo mgmt of widget * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f4b049
[21:24:03] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10v4 67d540d 06linuxcnc New branch with 217 commits pushed, 10517 files changed, 0325470(+), 0418746(-) since master/3f4b049
[21:25:21] <KGB-linuxcnc> 05dgarr/ja10v3 12b0495 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=12b0495
[21:25:48] <KGB-linuxcnc> 05dgarr/ja9_updates 9e7e955 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9e7e955
[21:47:59] <jepler> Changes from 0.9.2
[21:48:02] <jepler> Added love.system.vibrate.
[21:48:07] <jepler> sounds like my kind of softwaer
[21:48:15] <jepler> Added love.touch.getTouches
[21:48:24] <mozmck> interesting - after a branch is deleted on glo, and after I do a git pull, git branch -r still shows the deleted branch?
[21:49:07] <jepler> -p, --prune
[21:49:07] <jepler> After fetching, remove any remote-tracking references that no
[21:49:07] <jepler> longer exist on the remote.
[21:49:22] <jepler> you can remove them with this, if you are confident you no longer need the reference to the deleted branch
[21:49:49] <mozmck> I deleted my local branch that was tracking the remote - I guess that doesn't do that?
[21:50:21] <mozmck> why would I need a reference to a deleted branch? can you still access it?
[21:51:44] <mozmck> -p worked. I guess I don't understand how those references work or why I might need one still.
[21:52:02] <jepler> mozmck: yes, before you did that you could have still accessed the branch in the state it had the last time you pulled before its deletion
[21:53:34] <mozmck> interesting - I guess that means it was not really deleted out of my local clone - that is starting to make sense now.
[21:53:39] <jepler> I don't know the exact rationale (the manpage didn't give one) but if the deletion was accidental it increases the chances that someone else will still have the branch and can push its restoration
[21:54:04] <mozmck> Sounds like a safe default
[21:55:25] <jepler> looks like about 17 branches would be deleted here if I did that in my longest-lived linuxcnc repository
[22:00:42] <jepler> can't do that (UNKNOWN:136) in manual mode
[22:00:45] <jepler> this ring a bell for anybody?
[22:01:04] <jepler> (2.7, will re-test after making clean)
[22:02:58] <jepler> 2.7 with dgarr's mini fix cherry-picked, uspace, amd64, jessie
[22:03:05] <jepler> run the mini sample config, press left arrow
[22:03:12] <jepler> machine starts jogging, never stops, prints that message when trying to stop..
[22:03:54] <jepler> weird, it's gone in a fresh terminal
[22:04:02] <jepler> I wonder if I'd done a . scripts/rip-environment in another clone
[22:24:15] <KGB-linuxcnc> 03Jeff Epler 052.6 0957d2a 06linuxcnc 10src/emc/usr_intf/keystick.cc Revert "fix a hang seen in keystick, possibly the same as a problem reported by twice2" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0957d2a
[22:24:15] <KGB-linuxcnc> 03Jeff Epler 052.6 e29363a 06linuxcnc 10src/emc/usr_intf/keystick.cc keystick: fix signal handler a second time * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e29363a
[22:24:16] <KGB-linuxcnc> 03Dewey Garrett 052.6 b336895 06linuxcnc 10tcl/mini.tcl mini.tcl: remove duplicate geo mgmt of widget * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b336895
[22:31:58] <mozmck> Is there any requirements for joint order in JA? can I have JOINT_1 and JOINT_3 for AXIS_Y and JOINT_2 for AXIS_Z?
[22:34:58] <jepler> I think that you are supposed to have joint numbers starting at 0 and without any gaps
[22:35:21] <jepler> but maybe you implicitly mean that X is joint 0 in this case
[22:36:48] <jepler> my guess is that gentrivkins is supposed to work equally well with X=0, Y=1,2, Z=3, X=0, Y=1,3, Z=2 or anything else that maps X and Z each to one joint and Y to two joints
[22:38:38] <jepler> 'night