Back
[09:25:16] <cradek> say I have two commits, one that fixes a bug and one that confirms the bug and tests the fix
[09:25:20] <cradek> which order do I put them in?
[09:25:48] <jepler> I prefer to put the test second, so that you don't introduce a ref where the testsuite fails.
[09:26:23] <jepler> others prefer to put it first, so that they can verify that the test does what it purports to do. in that case, I recommend adding whatever it is that causes the test to be skipped, then remove the skip file in the commit that fixes the problem.
[09:27:58] <cradek> hmm I hadn't considered the skip, that's a good idea
[09:28:45] <cradek> I agree about not making failures (for bisect later)
[09:29:28] <cradek> I ask because I flipped zultron's two commits because he did break-then-fix and I preferred fix-then-test. I wondered if that was a weird thing to do.
[09:32:28] <jepler> hm, that trick where you can just stick the pin end of a through hole DB connector on the edge of a double sided PCB, does it work with standard .100 headers or is the spacing too big?
[09:34:35] <jepler> .100 spacing, .025 square posts, so it's .075 distance
[09:34:37] <cradek> I think a normal double sided fr4 board is .063; pins are maybe .040
[09:35:01] <cradek> so yeah, pretty loose
[09:35:06] <cradek> but they bend
[09:35:10] <jepler> yeah I found .063 in my first search too
[09:35:39] <cradek> oh yeah I bet .040 is the drill size (across the diagonals)
[09:36:09] <jepler> yes that matches this mechanical drawing I found
[09:36:33] <jepler> it's in mm, posts 0.64 SQ, drill 1.02 dia
[09:51:56] <seb_kuzminsky> i've argued for the 'test then fix' order for a while, despite the drawback that it makes bisect harder
[09:52:20] <seb_kuzminsky> i like jepler's suggestion of 'test-with-skip, then fix-and-unskip', best of both worlds
[09:52:28] <seb_kuzminsky> to skip, touch a file named "skip" in the test dir
[09:53:15] <cradek> what is the argument for test then fix?
[09:54:27] <cradek> I can sure see doing the development in that order - it feels natural. but I don't see any advantage to pushing in that order
[09:54:45] <cradek> the purpose of the test post-push is only to guard against regressions
[10:27:20] <seb_kuzminsky> the goal during dev is to make sure the developer understands the failure and fixes it, as you say
[10:28:13] <seb_kuzminsky> the goal for pushing it in that order is to show the other devs that the test is sane and finds a real bug
[10:28:26] <seb_kuzminsky> they can repro it as part of the review, if they want
[10:29:22] <cradek> I agree with all that
[10:30:26] <cradek> in order to see the failure when reviewing, but then push in a way that does not make bisects fail, you have to shuffle or modify the commits somehow. I don't think you can have both goals without hankypanky.
[10:30:58] <cradek> maybe review branches should have them one way, and final push be the other way (or add skip)
[10:31:03] <seb_kuzminsky> i like jepler's suggestion of pushing the test+skip, then the fix+unskip (or unskip as a third commit)
[10:31:05] <cradek> maybe I'm overthinking this and whatever is fine
[10:32:02] <cradek> that's a fine approach and I have no objections to it
[10:32:11] <seb_kuzminsky> oh good :-)
[10:32:40] <cradek> removing the skip to run the test when reviewing is even easier than reordering or reverting to unfix
[10:33:13] <seb_kuzminsky> i'm sympathetic to the goal of not having spurious failures during bisect due to tests deliberately failing sometimes (as is the case with my old, no-skip, way of doing it)
[10:33:33] <cradek> yeah I really hate when bisect is broken
[10:33:48] <seb_kuzminsky> yeah
[10:33:49] <cradek> (most of the ja changes don't build when bisecting, and I hate it)
[10:33:50] <seb_kuzminsky> same here
[10:33:54] <cradek> hate hate hate
[10:34:10] <seb_kuzminsky> don't look too close at the hundreds of ja commits we just merged to master ;-)
[10:34:14] <cradek> hate hate too late too late
[10:34:32] <cradek> yeah I've already been bitten by it
[10:34:39] <seb_kuzminsky> me too
[10:34:51] <seb_kuzminsky> chasing that ridiculous tcl/python/"Y" thing
[10:35:16] <cradek> I forget what I was chasing (or whether I found it)
[10:35:46] <seb_kuzminsky> the worst is when the merge commit is bad, and the parent of the merge that builds is good
[10:36:23] <cradek> ouch
[10:37:05] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #147: M30 remap interaction lcnc26 (062.6...06m30-remap-interaction-lcnc26) 02
https://github.com/LinuxCNC/linuxcnc/pull/147
[10:39:56] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #150: Fix subs breaking when placed after main program 2.6 (062.6...06subs-follow-main-lcnc-2.6) 02
https://github.com/LinuxCNC/linuxcnc/pull/150
[11:35:19] <jepler> cradek: the most exciting thing is that between major memory usage improvements in gcc since 4.9 (or maybe in boost? not sure), I can build with "-j9" even though this board has a mere 2GB RAM (+1GB swap)
[11:35:45] <cradek> cool
[11:41:06] <jepler> uncached build: 3m20s. cached build: 36s. change one component and make: 3s
[11:41:17] <cradek> wow, it's a computer
[11:41:41] <jepler> heh I'm glad you approve
[11:45:51] <jepler> my 2016 desktop with a $300 CPU in it takes 33s for an uncached build, 13s for a cached build, and .4s to build one component so it's still not the speed that a "good workstation" will give
[12:02:33] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #150: Thanks, @cradek. I see commit 2e52efef60793fea36df72c536ccc6b546cf5b19 in the 2.6 branch. 02
https://github.com/LinuxCNC/linuxcnc/pull/150#issuecomment-241793755
[12:04:09] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #147: Thanks, @cradek. I see commits 8b97e39c019233042e09c252d9120415397fc6ad and ca7c2de2997f4928774e101f94d43296539ff7fc in the 2.6 branch. 02
https://github.com/LinuxCNC/linuxcnc/pull/147#issuecomment-241794254
[12:20:21] <jepler> hm I seem to have wedged the xu4 from afar
[12:20:59] <jepler> running a make, it still echoes back characters in my ssh window, but it's unresponsive to ctrl-c / ctrl-backslash
[15:16:37] <jepler> pcw_home: 7i90 in SPI mode, can I pull /SPICS permanently low with a resistor and have it work properly?
[15:49:09] <cradek> I'd appreciate it if someone else could read and test
https://github.com/LinuxCNC/linuxcnc/issues/157
[15:49:33] <cradek> this is super important and I don't understand what's going on. more eyes would be nice.
[16:25:09] <emcPT> Anyone with a lathe with a C axis working?
[16:29:52] <emcPT> If possible take a look at a post that I just made:
https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/31453-lathe-with-c-axis-almost-done-need-some-help
[16:55:39] <pcw_mesa> jepler: maybe...
[16:55:41] <pcw_mesa> /CS is not strictly needed (could be tied low), _but_ with /CS tied low you lose 2 things:
[16:55:42] <pcw_mesa> 1. The SPI (mod 2^5) bitcount is cleared on CS high
[16:55:44] <pcw_mesa> 2. CS high for 50 usec resets the burst transfer hardware
[16:55:45] <pcw_mesa> so it may take some fussyness to resync if anything messes up
[16:57:12] <pcw_mesa> ( the reset on idle could watch the SPICLK but that fails on systems that provide continuous clocks )
[16:57:59] <jepler> OK, I think I won't try to economize on pins quite that much
[16:58:17] <pcw_mesa> a GPIO bit would work for /CS since its not timing critical
[19:16:47] <skunkworks> zlog
[19:39:15] <skunkworks> jepler, any realtime data?
[19:42:10] <jepler> skunkworks: no realtime kernel yet