Back
[00:08:01] <seb_kuzminsky> yowser
[01:37:29] <linuxcnc-build> build #351 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/351 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[01:45:54] <linuxcnc-build> build #1151 of precise-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1151 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[01:49:09] <linuxcnc-build> build #1149 of lucid-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1149 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[01:50:33] <linuxcnc-build> build #1153 of precise-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1153 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[02:02:27] <linuxcnc-build> build #1154 of hardy-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1154 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[02:09:08] <linuxcnc-build> build #1152 of hardy-i386-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1152 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[02:10:35] <linuxcnc-build> build #1150 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1150 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[02:10:44] <linuxcnc-build> build #1151 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1151 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[02:17:33] <linuxcnc-build> build #1150 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1150 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[02:17:34] <linuxcnc-build> build #1148 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1148 blamelist: Jon Elson <elson@jeuser.pico-systems.com>
[03:16:24] <KGB-linuxcnc> 03git 05bug315-fix 13273aa 06linuxcnc 10src/emc/rs274ngc/interp_o_word.cc * bug315: terminate skipping state on endsub only, not on return
[03:44:24] <mhaberler> jepler: fp detect - what kernel was that? rt-preempt?
[04:09:23] <KGB-linuxcnc> 03git 05bug315-2-fix f27301c 06linuxcnc 10src/emc/rs274ngc/interp_read.cc * interp/params: do not require a named param to be defined when parsing a sub
[06:21:13] <jthornton> http://gnipsel.com/files/0001-increase-stepgen-to-16.patch
[06:21:37] <jthornton> I seem to be missing something the most I can get is 10 stepgens
[06:21:46] <jthornton> it builds ok
[06:37:04] <jthornton> I wonder if there is something else besides MAX_CYCLE and MAX_CHAN that limits it to 10 stepgens
[07:10:49] <cradek> mhaberler: thanks! I will look at it soon.
[07:11:08] <cradek> I wonder how elson does that...
[07:14:22] <jthornton> I thought I was the only one to break things...
[07:18:05] <jepler> mhaberler: fp detect is in good old sim (master branch)
[07:18:33] <jepler> mhaberler: I don't plan to merge it right now but I should throw it up on a branch somewhere
[07:25:05] <KGB-linuxcnc> 03jepler 05jepler/detect-x87 09a280f 06linuxcnc 10src/rtapi/sim_rtapi.c * sim: detect use of x87 instructions in nofp thread
[09:10:15] <zultron_> Hey seb_kuzminsky, nice idea about pushing commits to the base of your branch for pushing to master, I like it.
[09:12:02] <zultron_> Here's another one for you: we've agreed that each commit needs to build so cradek can bisect without frustration. Does that extend to unit tests, too?
[09:13:05] <cradek> fwiw, I think it's ok to commit failing tests and then the fix
[09:13:27] <cradek> if you were searching for breakage using a test, you'd run only the interesting test
[09:13:55] <zultron_> I think so too, and we've seen that happen. So the line can be drawn there, good.
[09:14:19] <cradek> "it builds" is really a very low bar
[09:15:14] <cradek> I bet I haven't thought this all through as much as seb - I should listen more than I talk
[09:19:57] <zultron_> Ha ha! Well, I recall examples such as Seb's commit of a unit test before there was a fix to the regression some months back, so obviously the "it tests" bar can't be strictly required.
[09:20:31] <zultron_> There could be commits that break *all* tests, though, even though they clear the "it builds" bar.
[09:21:26] <zultron_> I'm sure I've got commits like that in my tree, since there's a lot of change going on in there.
[09:21:34] <cradek> I suppose that's true - and you could use auto-bisect with any or all tests to find that problem commit
[09:22:27] <cradek> with our continuous testing, we don't break tests and not notice them -- so I don't think we'd ever want to use bisect to find a test-breaker commit
[09:26:18] <zultron_> Maybe I'm imagining an exotic scenario, but if I found a regression and wanted to figure out where it was introduced, I could write a unit test, use git rebase to stick it way back in the history, and then do the bisect.
[09:26:42] <cradek> that'd be awesome
[09:28:12] <cradek> or without rebase, you could just copy your test in and try it at every bisect point
[09:28:24] <zultron_> Oh yeah, duh. :)
[09:29:18] <zultron_> Anyway, you get the idea: if *all* tests are broken, you'll run into the same type of frustration from yesterday when you came across commits that don't build.
[09:29:24] <cradek> I guess bug 315 would have been like that, if we had a cleaner history through that time
[09:29:49] <cradek> yeah and if anything about the test infrastructure changes, etc, you'll have to change your test at the right time
[09:30:17] <cradek> but if ONE commit breaks all the tests and the next one fixes it, and you're unlucky enough to hit that one, you can just use bisect skip and get the next one
[09:30:47] <cradek> it's pretty normal to have to skip testing a commit here and there
[09:31:37] <cradek> my situation recently was that many in a row didn't build and that's pretty obnoxious
[09:31:48] <zultron_> So what ended up happening with your bisect yesterday? I imagine if you skipped enough, you'd have landed on one that compiled.
[09:32:03] <cradek> I just gave up after a couple hours of getting nowhere
[09:32:16] <zultron> That sucks.
[09:32:39] <cradek> and I was pretty sure it was in the remap changes because they were the only major changes, so I asked mhaberler to look at it and made a test program and runtest to help him
[09:33:08] <cradek> eh it's ok, but it makes me think more along the lines of seb being right when he wants our history to be pretty clean
[09:33:34] <zultron> Yep, that's a strong argument, and I personally like it that way, too.
[09:34:58] <cradek> for a while I thought he might be caring too much, but I think the more experience you have with source control, the more you care about things like that (my peeve is whitespace-only changes that break merges for no reason other than someone's aesthetic preferences)
[09:35:04] <zultron> The other argument that Seb hit on is I like to make it look like my development style is super organized and deliberate, even at the expense of being a history revisionist. ;)
[09:35:22] <cradek> haha yeah I like to look smarter than I am too
[09:36:11] <cradek> one time I made a big series of changes that included new files, and then at the end I remembered to add license statements to my new files. before sharing that work, I used rebase to put those in at the beginning instead, for future history's sake.
[09:38:06] <zultron> I don't have enough experience with git collaboration to have seen problems like your whitespace pet-peeve. I'm ambivalent about those kinds of commits.
[09:38:35] <zultron> Yeah, sounds like the perfect application of git rebase -i.
[09:38:43] <zultron> The license statements, that is.
[09:40:00] <cradek> I think after a while, catering to the source control is a primary task, and you make your changes with that in mind (not making merges hard, making future bisects work well, etc)
[09:40:39] <cradek> just like you try to write code that makes the compiler work right (it builds)
[09:40:49] <cradek> I'm not sure if that's a bug or feature of source control systems
[09:41:14] <zultron> Like I say, I'm still learning, but you're preaching to the choir here. :)
[09:41:21] <cradek> I think diff/patch works surprisingly well on source code, but something smarter would sure be better
[09:41:58] <cradek> now I'm philosophizing or something, sorry
[09:42:55] <cradek> like how changing whitespace is a problem ONLY because it makes diff/patch not work on the source code anymore. there's nothing wrong with whitespace changes otherwise.
[09:45:21] <zultron> Yes, there're a number of problems there. All kinds of things can make 'git blame' work incorrectly, as I found while trying to survey how much Paul C code needed to be dealt with for the relicense.
[09:46:45] <zultron> There were a few instances like his 1600-line patch where he ran a bunch of files through a source code reflow tool.
[09:46:47] <cradek> yep, he was a big whitespacer, you're right that blame is another way the line-by-line-changes assumptions are bad
[09:47:13] <cradek> yes he should've been shot at that time.
[09:47:37] <zultron> You couldn't tell whether the commit was a no-op, or whether there were actual changes in there. And his commit messages are rarely informative.
[09:47:49] <cradek> now I'm the choir!
[09:48:47] <cradek> the worst change is one that makes a change of substance AND changes whitespace everywhere else. the change is really well hidden then, and you break pretty much every feature of source control all at once.
[09:49:02] <zultron> Well, I don't care too much about whitespace commits, if they're isolated (no real changes) and labeled as no-op. I don't like extra whitespace, either.
[09:49:48] <cradek> that's sure the best way to do it if you must, but you still break blame and usually all future merges that cross that commit
[09:49:51] <zultron> Maybe that defines when I'm ok with them....
[09:50:23] <cradek> and any manual diff old..new across it is noisy
[09:50:25] <zultron> Git blame is broken anyway. :P git mv breaks git blame.
[09:50:59] <cradek> did not know that. I'm still trained to avoid mv because of my cvs days training.
[09:51:24] <zultron> Yeah, that's got problems too. There is 'git diff -w' or whatever that helps with the noise.
[09:52:30] <zultron> For the relicensing work, I was thinking about writing a git plugin that runs code through a reflow tool before taking a diff.
[09:52:37] <cradek> yes for some kinds of reformatting (that doesn't flow lines) that can help
[09:52:59] <zultron> That would help with the whitespace/reflow problems.
[09:53:20] <zultron> It would help with some other things that I've now forgotten....
[09:53:53] <cradek> I'd be interested to hear whether that works - I think indent is not idempotent - not sure if there's a smarter one
[09:55:52] <zultron> Another idea was, within a commit, to check whether - lines to one file match + lines in another file. That would help with file renames and general code reorganization.
[09:56:03] <zultron> Anyway, that's a topic for another time.
[10:44:44] <seb_kuzminsky> i'd like to join y'all's choir
[10:58:51] <cradek> the more the merrier. but can any of us sing?
[10:59:52] <jepler> cradek: I happen to know you can
[11:09:15] <mhaberler> jepler: fp.. gnu threads can have non-fp threads?
[11:09:41] <mhaberler> in xeno-user there's an fp flag for thread creation, but its always fp - so ignored
[11:09:53] <jepler> mhaberler: as far as I could discern, the gnu pth thread switching code saved the fp registers regardless
[11:10:12] <jepler> mhaberler: the goal is to learn about accidental use of fp in functions declared nofp
[11:10:27] <mhaberler> right, I get that
[11:10:47] <mhaberler> where was that patch again?
[11:10:56] <jepler> I pushed it to a branch in git.l.o
[11:11:32] <jepler> branch name is jepler/detect-x87
[11:12:09] <zultron> I'll sing under light interrogation.
[11:12:23] <zultron> seb_kuzminsky, any opinion on the unit test question?
[11:13:27] <jepler> zultron: can you re-state the unit test question?
[11:13:41] <jepler> it's nice to have the tests passing at every commit, just like it's nice to have it building
[11:13:49] <zultron> (Maybe it was cleared up by "with our continuous testing, we don't break tests and not notice them -- so I don't think we'd ever want to use bisect to find a test-breaker commit")
[11:13:54] <jepler> when a test is checked in before its fix, you can drop a turd in its directory to mark it as "expected to fail"
[11:14:36] <jepler> of course at some point we should drop our homegrown 'runtests' script and switch to something real.
[11:14:59] <jepler> what we have now was written by a demented NIH-monkey (me) who didn't really even investigate alternatives
[11:15:00] <cradek> I didn't think about the expect-to-fail flag
[11:15:48] <seb_kuzminsky> zultron: i've in the past committed the test first, and the fix second (and i also didn't think about expected-to-fail)
[11:16:15] <seb_kuzminsky> i like doing it that way because then you can run the test without the fix and see that it's a real problem, then hop forward to the fix and see that it really does make the test pass
[11:16:55] <seb_kuzminsky> it does create a window in history where runtests will not pass, which might be confusing or frustrating or harmful when spelunking later?
[11:17:16] <seb_kuzminsky> i've never been bit by that particular problem, so i haven't worried about it
[11:18:35] <seb_kuzminsky> i think i noted in the commit message when adding the expceted-to-fail test that the fix was coming in the next few commits, so a history-spelunker who *did* get bit would have a fighting chance of un-confusing themselves (though the frustration might linger)
[11:19:19] <cradek> I also have not been bitten by this
[11:19:44] <cradek> if someone told me I oughta use expected-to-fail I guess I might listen or might not...
[11:20:26] <seb_kuzminsky> 49ee157e63c61e267a8d4a37bffff8b1516b7b39
[11:21:38] <jepler> in the future we'll be able to conduct virtually all conversations merely by sharing the cryptographic hash of the conversation we wish to hold
[11:21:58] <seb_kuzminsky> maybe the best would be to first add the test with xfail, then add the fix and remove xfail in a later commit?
[11:22:02] <cradek> I think adding a new (failing) test that honestly represents an existing bug makes the whole of the tree better
[11:22:14] <seb_kuzminsky> +1
[11:22:21] <jepler> if there's a non-expected fail, I think buildbot won't give packages
[11:22:30] <seb_kuzminsky> yes that's right
[11:22:32] <jepler> .. but it also doesn't squawk publically about expected fails
[11:22:32] <cradek> I am pretty sure this doesn't bother me one bit
[11:22:47] <jepler> I would be happy if there was urgency to test failures; that's why they exist
[11:23:03] <cradek> there is, if only to stop that incessant squawking
[11:23:21] <seb_kuzminsky> "no packages without a clean runtests" is a feature
[11:23:44] <seb_kuzminsky> and yes, having the buildbot spam #linuxcnc-devel is a powerful motivator to get it to shut up :-)
[11:32:28] * jepler just ordered his rostock printer
[11:32:41] <jepler> too bad I may not have time to play with it until august
[11:32:43] <cradek> woo
[11:33:01] <jepler> (a week lead time, a week to ship, then I'm out of town, then it's august .. wth)
[11:33:51] <cradek> did you remember to order plenty of extra struts?
[11:34:42] <jepler> no
[11:34:45] <jepler> why so negative?
[11:35:13] <cradek> I have experience writing kinematics
[11:35:52] <cradek> did you get it with the drivers and controller and everything?
[11:36:03] <jepler> yes
[11:36:29] <jepler> by the time I'm working on linuxcnc kinematics I'll have printed some different attachment system like the magnetic one we've been talking about
[11:36:38] <cradek> cool
[11:42:53] <seb_kuzminsky> very cool jepler
[11:43:46] <seb_kuzminsky> the guy i've been machining mendelmax parts for got all excited when i told him about running 3d printers with linuxcnc and is going to give me a printer on "permanent loan"
[11:43:55] <seb_kuzminsky> i wonder what month it will be when i have time to work on it...
[11:49:37] <cradek> are you doing the aluminum parts on
http://www.mendelmax.com/2012/12/27/announcing-the-new-mendelmax-2-0/2012-12-24-19-25/
[11:52:41] <seb_kuzminsky> just this part for now:
http://store.terawattindustries.com/27-universal-y-axis-plate-t6061-aluminum.html
[11:53:11] <seb_kuzminsky> we keep talking about other parts but nothing's materialized yet
[11:53:43] <cradek> cool
[11:53:49] <cradek> do you do the tapping?
[11:54:09] <ssi> seb_kuzminsky: I have a mendelmax
[11:54:31] <seb_kuzminsky> cradek: heh no
[11:54:42] <seb_kuzminsky> i mill & drill, and he does the tapping by hand
[11:54:56] <seb_kuzminsky> one of these years i should finish the spindle encoder i started...
[11:55:08] <cradek> hand tapping! sacrilege!
[11:55:10] <seb_kuzminsky> ssi: does it work well for you?
[11:55:14] <ssi> yeah, very well
[11:56:00] <seb_kuzminsky> oh good! which hot end?
[11:56:08] <ssi> couple weeks ago, I did a solidworks drawing of the ProTram cause pete wanths to clone it
[11:56:11] <ssi> and for giggles, I printed it:
[11:56:12] <ssi> https://pbs.twimg.com/media/BKUIYZ1CMAAlTz2.jpg
[11:56:20] <ssi> I have the budaschnozzle on my max
[11:56:24] <ssi> I have a J-head on my prusa
[11:57:33] <seb_kuzminsky> i've heard good things about the budaschnozzle (who makes these names up?)
[11:57:35] <cradek> making 3d models actually appear is pretty neat
[11:57:52] <seb_kuzminsky> not having to worry about work holding and tool selection really lowers the barrier to entry
[11:58:07] <ssi> yea
[11:58:14] <cradek> or coolant or chips in the carpet
[11:58:15] <ssi> it's cool stuff... I've even used them to build machine parts
[11:58:18] <seb_kuzminsky> hmm this looks like a good idea:
http://lists.freebsd.org/pipermail/freebsd-stable/2013-July/074157.html
[11:59:08] <cradek> I'm for that
[11:59:27] <ssi> seb_kuzminsky: I designed and printed this little guy:
http://www.youtube.com/watch?v=VsHNA3oLXC8
[12:00:04] <seb_kuzminsky> wow!
[12:00:42] <seb_kuzminsky> oh, i just now realized that you're ian mcmahon
[12:00:49] <ssi> that's me :D
[12:01:14] <ssi> please don't follow that with "...you've been served"
[12:01:21] <seb_kuzminsky> i meant to ask you, there are some commits in rtos-master-v0 that claim to be written by "joe chipbreaker" or something, is that you too?
[12:01:49] <ssi> heh yeah... I was doing work on the linuxcnc beagle image, and I did the first couple commits before I realized that the git commit stuff was prepopulated :P
[12:01:57] <ssi> I told michael about it, and he shrugged :)
[12:02:01] <seb_kuzminsky> yeah
[12:02:27] <seb_kuzminsky> we don't have an official document that says "commit as yourself", afaik, but i think we should
[12:02:41] <ssi> oh believe me, I didn't intend for it to go in that way
[12:02:47] <ssi> would prefer it to be changed, but I don't know how
[12:02:48] <seb_kuzminsky> it'll mess up the *next* relicensing effort if we can't contact our contributors
[12:02:52] <seb_kuzminsky> heh
[12:02:55] <ssi> hahahah
[12:03:17] <seb_kuzminsky> ok, no problem, i'll fix it up when i merge it
[12:03:20] <ssi> cool
[12:03:28] <seb_kuzminsky> logger[psha]: link please
[12:03:28] <logger[psha]> seb_kuzminsky: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2013-07-09.html
[12:03:33] <jepler> git has a concept of a "mailmap" which can fix this when it is in the distant past and only noticed later
http://stacktoheap.com/blog/2013/01/06/using-mailmap-to-fix-authors-list-in-git/
[12:03:38] <ssi> I have that hm2 driver underway that I asked you about
[12:04:52] <seb_kuzminsky> neat
[12:05:18] <ssi> I have to do a bunch of corresponding work to the hostmot firmware though, and I'm not sure how that's going to go yet
[12:05:26] <jepler> ssi: what are you cooking?
[12:05:55] <ssi> I have a beaglebone cape with an s3a 200k on it, and I want to make up a hostmot firmware that fits in it and can communicate over SPI
[12:06:02] <ssi> and I'm writing an hm2 driver to run it
[12:07:18] <jepler> ssi: that sounds like a great idea
[12:07:26] <jepler> SPI clocks comfortably fast enough for this?
[12:07:32] <ssi> 48mbit
[12:07:41] <ssi> might limit how much stuff I can run, but I think it's doable
[12:07:46] <ssi> if not, I'll look at using the GPMC driver
[12:07:56] <ssi> but I'll have to give up hdmi framer for that, so no onboard video
[12:08:10] <ssi> my goal is to do it with SPI, so the BBB + fpga can be a complete self contained linuxcnc machine
[12:08:18] <ssi> plug in hdmi monitor and keyboard/mouse and go
[12:08:39] <jepler> nah, epp (7i43) is 2MB/s on a good day, 48Mb/s (=6MB/s) is comfortably faster
[12:08:52] <ssi> ok excellent
[12:09:21] <ssi> I'll have to write an SPI slave in vhdl for the firmware side
[12:09:24] <ssi> I haven't dug into that code yet
[12:09:38] <ssi> but fortunately I wrote an SPI slave in vhdl a cuople weeks ago for a bitcoin application
[12:09:40] <jepler> There must be SPI code already in there, but perhaps it's SPI master
[12:10:02] <ssi> I'm hoping I can get at least enough firmware to run a 7i77
[12:11:12] <jepler> surely it's easy to buy that much fpga real estate these days
[12:11:51] <ssi> well i'm working within what I have
[12:12:03] <ssi> this is a board that someone else designed
[12:12:12] <ssi> but if I have success, I'm going to do another board with an s6 lx9 on it
[12:12:16] <ssi> which is what the 5i25 has
[12:13:35] <jepler> 7i43_400 (3s400tq144) has an SV8 configuration, i20 (2s200pq208) has SV12.
[12:13:44] <jepler> and those are both several generations old
[12:14:11] <jepler> bbl
[12:16:12] <pcw_home> SmartSerial (uProc+RAM+ROM+UARTs) is pretty big as are stepgens and resolver interface
[12:16:50] <ssi> I don't need stepgens or resolvers
[12:17:15] <pcw_home> you have a SP3/200?
[12:17:20] <ssi> s3a 200
[12:17:28] <mhaberler> jepler: I'm delighted to hear you consider alternatives to runtests - interested to hear what you find appropriate
[12:17:51] <pcw_home> pretty sure what a 7I77 needs would fit
[12:18:02] <ssi> yeah that'd be enough for this iteration
[12:18:06] <ssi> next board will have the s6 lx9 on it
[12:18:11] <ssi> which I know for sure will fit :)
[12:18:41] <pcw_home> SP6 is noticeably faster and cheaper/LUT
[12:18:51] <ssi> yeah
[12:18:57] <ssi> I just have these already
[12:19:04] <ssi> I want to POC it before I spin another board
[12:19:38] <pcw_home> no problem running the sserial UARTs and uProc at 100 MHz in SP6
[12:21:08] <pcw_home> If you lay out a new card with SPI interface, make sure you use a GCLK for the SPI clock so you dont have to oversample if you dont want to
[12:23:50] <pcw_home> In that case SPI slave interface SR runs in its own local clock domain
[12:23:52] <pcw_home> with only doubleword rate parallel data crossing into the hm2 interface clock domain
[12:27:46] <ssi> I'll have to digest that a bit :)
[12:28:00] <ssi> I'm still pretty green at HDL
[12:28:27] <ssi> when I did the last SPI slave, I used a 3 bit shift register to cross clock domain, as per some stuff I read on fpga4fun.com
[12:28:35] <ssi> and I did have trouble with it until I oversampled 5x
[12:41:37] <ssi> pcw_home: so I'm looking at the schem for the existing board I have, and SPI_SCLK is brought in on a pin labeled IO_L12N_CCLK
[12:41:50] <ssi> is that what you meant? (or the s3a equivalent maybe)?
[12:44:17] <pcw_home> No thats the config clock
[12:44:46] <ssi> oh I see the GCLK pins
[12:46:22] <pcw_home> they probably have it wired that way so they can load the FPGA via the SPI interface
[12:46:44] <pcw_home> "serial slave mode"
[12:49:27] <pcw_home> SP6 will probably meet timing for a 250 MHz overclock but for Cubie for instance I need to support a 100 MHz SPI clk
[12:49:29] <pcw_home> so I pretty much have to use a GCLK
[13:03:22] <ssi> you think I can do a 48MHz sclk without a gclk?
[13:16:18] <jepler> mhaberler: I haven't investigated / am not investigating alternatives at the moment
[13:17:15] <mhaberler> thats ok - if it eventually happens, I'd be delighted
[13:17:19] <pcw_home> Possibly by making a HF clock (200 or 250 MHz) and oversampling
[13:17:57] <pcw_home> (in SP6, probably more difficult in SP3)
[13:19:10] <ssi> I guess I'm unclear about the purpose of the glck... I thought they were just buffers for distributing the clock to lots of different logic without much slew
[13:19:24] <ssi> if it's only driving the one spi receiver, which is a relatively small amount of logic, what does the gclk buy you
[13:19:48] <mhaberler> afaict a non-fp thread being really non-fp is a problem limited to kthreads
[13:21:28] <jepler> mhaberler: with more people using user threads models it will be even more important to catch this kind of error
[13:21:53] <jepler> maybe someday we can deprecate the flag but until we do I would like to have a way to find violations
[13:22:29] <mhaberler> that I dont understand.. why is it becoming more important? some performance reason?
[13:23:03] <jepler> because we will have more developers running systems where they can accidentally write fp-using code in a nofp context and not see problems
[13:23:15] <mhaberler> I see
[13:23:23] <jepler> i.e., bob q. programmer writes on rt-preempt and then we don't see the problem until someone with rtai/kthreads runs it
[13:23:36] <mhaberler> right
[13:24:09] <jepler> I am not 100% sure but in kernel threads I think the problem may appear as corruption of userspace FP regs
[13:24:18] <mhaberler> right
[13:24:37] <jepler> not fun to diagnose in the last
[13:24:39] <jepler> in the least
[13:24:49] <mhaberler> maybe there is a way to investigate statically by looking at the object files
[13:27:46] <pcw_home> If you have a high speed clock routed to multiple LUTS (like your input slave SPI SR) you probably want to use a clock spine
[13:30:29] <pcw_home> (clock skew is especially bad for hold time in your SRs)
[13:35:51] <skunkworks> emco lathe will do 40ipm
[13:37:10] <cradek> that's probably enough for threading
[13:37:20] <skunkworks> yes
[13:37:52] <skunkworks> that is about the limit...
[13:38:22] <seb_kuzminsky> that's great :-)
[14:01:26] <KGB-linuxcnc> 03elson 05master 069894e 06linuxcnc 10docs/src/drivers/pico_ppmc.txt
[14:01:26] <KGB-linuxcnc> 23:08:49 up 15 days, 0 min, 4 users, load average: 0.02, 0.08, 0.09
[14:01:26] <KGB-linuxcnc> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
[14:01:26] <KGB-linuxcnc> elson :-3 - 23Jun13 ?xdm? 4:29m 0.96s /usr/bin/gnome-
[14:01:27] <KGB-linuxcnc> elson pts/1 :0.0 24Jun13 0.00s 55:28 0.29s git commit pico
[14:01:30] <KGB-linuxcnc> elson pts/2 :0.0 26Jun13 22.00s 0.86s 0.03s info vi
[14:01:33] <KGB-linuxcnc> elson pts/3 :0.0 Sun19 25:30m 0.07s 0.07s bash
[14:01:36] <KGB-linuxcnc> Please enter the commit message for your changes. Lines starting
[14:01:53] <cradek> sigh
[14:02:01] <KGB-linuxcnc> 03git 05master 13273aa 06linuxcnc 10src/emc/rs274ngc/interp_o_word.cc * bug315: terminate skipping state on endsub only, not on return
[14:02:08] <KGB-linuxcnc> 03git 05master f27301c 06linuxcnc 10src/emc/rs274ngc/interp_read.cc * interp/params: do not require a named param to be defined when parsing a sub
[14:02:15] <KGB-linuxcnc> 03chris 05master b3bb409 06linuxcnc * Merge remote branch 'origin/bug315-2-fix' into v2.5_branch
[14:02:21] <KGB-linuxcnc> 03chris 05master f92d100 06linuxcnc 10tests/interp/ 03oword-bug315-p2/README 03oword-bug315-p2/expected 03oword-bug315-p2/test.ngc 03oword-bug315-p2/test.sh * Test for bug 315 part 2
[14:02:28] <KGB-linuxcnc> 03chris 05master 6233a2a 06linuxcnc 10docs/src/drivers/pico_ppmc.txt 03src/emc/rs274ngc/interp_namedparams.cc * Merge branch 'v2.5_branch'
[14:02:37] <KGB-linuxcnc> 03chris 05master 7a287c9 06linuxcnc * Merge remote branch 'origin/bug315-fix'
[14:02:41] <KGB-linuxcnc> 03git 05v2.5_branch f27301c 06linuxcnc 10src/emc/rs274ngc/interp_read.cc * interp/params: do not require a named param to be defined when parsing a sub
[14:02:48] <KGB-linuxcnc> 03chris 05v2.5_branch b3bb409 06linuxcnc * Merge remote branch 'origin/bug315-2-fix' into v2.5_branch
[14:02:54] <KGB-linuxcnc> 03chris 05v2.5_branch f92d100 06linuxcnc 10tests/interp/ 03oword-bug315-p2/README 03oword-bug315-p2/expected 03oword-bug315-p2/test.ngc 03oword-bug315-p2/test.sh * Test for bug 315 part 2
[14:07:13] <cradek> not the worst bug report I've ever seen, but in the running:
http://linuxcnc.org/index.php/english/forum/41-guis/26742-touchy-update#36461
[14:07:31] <cradek> apparently it was caused by updating? something?
[14:09:19] <cradek> hm clicking where there's no program listed in touchy causes a traceback
[14:09:33] <cradek> in the file chooser thingy
[14:11:15] <jepler> cradek: touchy crashes at startup if you don't have ~/linuxcnc/nc_files
[14:11:24] <jepler> move it out of the way and you'll see
[14:12:38] <cradek> oh is that what that report means?
[14:13:25] <jepler> I think so
[14:13:27] <cradek> OSError: [Errno 2] No such file or directory: '/home/swatson/linuxcnc/nc_files'
[14:13:30] <cradek> duh
[14:13:52] <cradek> that's not very graceful
[14:14:34] <jepler> I saw it when hacking on touchy but did the mkdir and moved on ..
[14:14:36] <seb_kuzminsky> thanks for pushing that #315 fix
[14:14:37] <jepler> I should have noted it somewhere
[14:14:59] <cradek> seb_kuzminsky: the merges were hairy - I think I got both fixes in right
[14:15:05] <cradek> thanks mhaberler for doing the work
[14:15:12] <jepler> yes thanks mhaberler
[14:15:16] <seb_kuzminsky> yeah thanks michael :-)
[14:15:19] <mhaberler> sure; looks ok?
[14:15:44] <cradek> I tested both of them and am at least 80% confident they are right :-/
[14:16:06] <cradek> this shows how little test coverage we have of flow control and that makes me nervous...
[14:16:25] <mhaberler> uhum.
[14:16:43] <cradek> if you'd check the 2.5->master merge of p2 I'd appreciate it. it's a merge across a refactor.
[14:16:56] <mhaberler> let me clean them up first
[14:17:03] <mhaberler> sure, I'll do that
[14:17:11] <cradek> clean what up?
[14:17:38] <mhaberler> this one: the conditional expression is now useless:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commitdiff;h=13273aadcc931148238d997343cfdf5a1a344952
[14:17:58] <seb_kuzminsky> err
[14:18:28] <cradek> I don't understand what you mean
[14:18:56] <mhaberler> thats ok - try 'trust' ;)
[14:19:51] <seb_kuzminsky> mhaberler: the bug315-fix and bug315-2-fix branches got merged and pushed to master just now, was that premature?
[14:20:02] <mhaberler> nah, doesnt matter
[14:20:45] <mhaberler> ah, the indirect call actually works.. didnt test that
[14:20:55] <seb_kuzminsky> i dont know what you're talking about now
[14:21:57] <mhaberler> bug315-2-fix: this is about a computed call (indirect) - I just tested it for parsing ok, not that it actually executes; cradeks test does this
[14:23:54] <jepler> that's an unusual "rigid tap"
http://youtu.be/i4fTythQj5s
[14:24:21] <jepler> andy posts that he 'used g33.1 in an unusual way last night'
[14:25:26] <seb_kuzminsky> that's very cool :-)
[14:26:12] <jepler> it's lucky the spindle can go slow enough
[14:26:31] <cradek> that's really cool
[14:29:51] <cradek> is that two start? he changes the cutting radius between the two cycles, but they end at different places (depths?)
[14:30:13] <jepler> I don't know anything more than that
[14:39:12] <jepler> except for all the warnings about eye damage I think putting a laser engraver on a delta would be neat
[14:39:36] <jepler> .. something else you can do in a machine not designed for cutting
[14:40:01] <cradek> I have a low power IR laser (and the appropriate goggles) somewhere
[14:40:16] <cradek> it can make marks on things but that's about it
[14:41:05] <ssi> jepler: that would be pretty fun
[14:41:36] <ssi> but a solid state laser of any consequence might be too big and heavy to run on the effector
[14:41:45] <seb_kuzminsky> here's a friend's laser on a mini-mill:
https://plus.google.com/u/0/114208008796430745286/posts/Fp876zrAzdz
[14:41:45] <ssi> and I dunno how you'd transmit with optics on a delta
[14:42:21] <jepler>
[14:42:51] <pcw_home> Laser diode
[14:43:12] <jepler> these DIYers seem to use DVD burner diodes (650nm, 300mW give or take)
[14:43:21] <ssi> I dunno what you can do with that
[14:43:23] <ssi> not much I imagine
[14:43:31] <ssi> friend of mine has a 3W blue laser, and it can burn paper
[14:43:35] <ssi> and it's pretty big and heavy
[14:43:41] <cradek> you can put markings on things with that
[14:44:09] <jepler> cut 2mm craft foam at 75mm/min, mark balsa wood at 100mm/min
[14:44:18] <jepler> or give yourself a cataract
[14:44:27] <pcw_home> I have a bunch of 15W IR diodes (but they are FC not sure thats usable )
[14:44:36] <ssi> FC?
[14:44:44] <pcw_home> Fiber Coupled
[14:44:48] <ssi> ah
[14:45:40] <pcw_home> 8 of them with the fibers bound together (120W total)
[14:45:57] <ssi> can that be focused relatively fine?
[14:46:15] <pcw_home> Ive never got the nerve to fire it up
[14:46:34] <ssi> heheh
[14:51:40] <jepler> anyway, the 300mW ones would sure be light enough to mount directly on the delta platform, unless it turns out you need too much heatsinking
[14:51:55] <ssi> yeah should be
[14:52:04] <ssi> hm I wonder if you could cut mylar with it
[14:52:08] <ssi> like for pcb stencils or something
[14:53:10] <jepler> surely the reflectiveness means no
[14:53:43] <ssi> yeah that's true
[14:54:15] <jepler> metallized PET film .. reflects up to 99% of light, including much of the infrared spectrum -- wikipedia
[15:59:49] <seb_kuzminsky> it just occurred to me that setting [TRAJ]NO_FORCE_HOMING may make those annoying linuxcncrsh tests run reliably
[16:02:05] <seb_kuzminsky> then i could be lazy and not rewrite them in python
[17:47:31] <CaptHindsight> huh, eager inling had to be enabled to compile RTAI for the older 2.6 kernel
[18:09:02] <CaptHindsight> jepler:
https://www.youtube.com/watch?v=QvcSd0cNaho Casio Laser projector burns some stuff
[19:07:11] <jepler> CaptHindsight: I'm scared he's going to burn his hand
[21:34:49] <KGB-linuxcnc> 03seb 05v2.5_branch 7c32c4a 06linuxcnc 10tests/ 10(12 files in 11 dirs) * tests: use NO_FORCE_HOMING with the linuxcncrsh tests
