Back
[00:52:48] <seb_kuzminsky> CaptHindsight: yes
[00:53:13] <seb_kuzminsky> http://linuxcnc.org/docs/2.7/html/man/man9/pwmgen.9.html
[00:53:43] <seb_kuzminsky> something like: "loadrt pwmgen output_type=0,1"
[01:00:18] <CaptHindsight> thanks, I get it now
[01:01:15] <CaptHindsight> I was trying to load 2 types on different lines of my HAL file
[08:05:44] <jepler> someone needs to go back and resurrect "newinst", an alternative to "loadrt" that creates an instance at a time..
[08:06:27] <jepler> I wonder, but I'm too scared to ask, why machinekit's approach to something-like-newinst involved making two versions of halcompile and two versions of every component's source code
[08:31:27] <cradek> maybe the remaining 20% of the project that will never get done is deleting all the old stuff?
[08:32:50] <archivist> it amuses me that some can only "improve" code by rewriting, they never bother to understand current code
[08:34:22] <jepler> as I originally wrote it, I think newinst just goes "la la laaa I can't hear you" about the subject of loadrt parameters, and obviously that's not a great plan
[09:40:17] <cradek> do you guys think there are zultron fixes waiting for a merge? I'm afraid I haven't kept up, and it seems like he's working on fixing tricky things for us.
[09:50:40] <jepler> cradek: I know there are some pull requests where I don't feel I can evaluate whether they're the right thing or not
[09:51:02] <jepler> I'm not sure I understand the question though
[09:51:25] <cradek> well I guess that was my question
[09:52:11] <jepler> I feel like you're a better judge than me of what it's good to do to interp
[09:54:10] <cradek> ah there's just this one? I thought there were probably more.
[10:05:29] <cradek> ok, so my take is zultron understands this better than any of us and he even wrote a test
[10:11:40] <jepler> if we're talking master branch, that is good enough for me.
[14:39:04] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #133: Should I do anything else to get this PR merged? 02
https://github.com/LinuxCNC/linuxcnc/pull/133#issuecomment-239898789
[15:08:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 54c72e1 06linuxcnc Merge remote-tracking branch 'pkmcnc/master' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=54c72e1
[15:09:44] <jepler> seb beat me to it
[15:11:11] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #133: Merged, thanks! 02
https://github.com/LinuxCNC/linuxcnc/pull/133#issuecomment-239906935
[15:11:24] <seb_kuzminsky> hope i didnt step on your toes - i didn't notice you were commenting on it still
[15:11:48] <jepler> no problem
[15:12:04] <jepler> I was just in the middle of realizing there were of course no automated tests of genhexkins
[15:12:30] <seb_kuzminsky> yeah
[15:12:42] <seb_kuzminsky> i built it on uspace & rtai, and that was all i could think to try
[15:13:05] <seb_kuzminsky> pkmcnc probably knows more about hexapods than all the rest of us combined
[15:13:13] <jepler> that was basically my thought
[15:13:41] * jepler waits for the build to show up at https://travis-ci.org/LinuxCNC/linuxcnc since that's the new hotness
[15:15:38] <seb_kuzminsky> yeah, that's cool, thanks for setting it up
[15:15:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #133: genhexkins: add new functionality (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/133
[15:20:55] <seb_kuzminsky> the travis-ci web interface is nice and clean
[15:21:36] <jepler> clearly a tremendous effort in their github integration.
[15:51:54] <cradek> jepler: have you found that github could also poke buildbot and send emails?
[15:54:28] <jepler> cradek: that's a good point. we would have to host the machinery for doing those two things.
[15:54:59] <jepler> cradek: basically, github sends a http(s) request to your registered service when an event happens, and you can do whatever you like in response
[16:11:49] <seb_kuzminsky> that's how the wlo-builder works
[16:12:49] <seb_kuzminsky> https://github.com/LinuxCNC/wlo/blob/master/scripts/post-receive.cgi
[16:21:46] <jepler> a cgi implemented with bash -- courageous
[16:22:09] <seb_kuzminsky> everything looks like a nail to me
[16:22:32] <jepler> what is "jq"?
[16:22:43] <seb_kuzminsky> is a json parser tool
[16:23:00] <seb_kuzminsky> the post contains a big json blob that i had to pull some fields out of
[16:23:26] <seb_kuzminsky> it works well and it's really easy to use, i'm a fan
[16:25:06] <seb_kuzminsky> json is a breath of fresh air after years of xml
[16:27:21] <seb_kuzminsky> you can see the bare json that gihub posts:
https://github.com/LinuxCNC/wlo/settings/hooks/6350580
[16:27:35] <seb_kuzminsky> by clicking on one of the recent deliveries
[16:27:36] <JT-Shop> interesting this example look slike a dictionary of dictionaries in Python
http://www.w3schools.com/json/
[16:27:54] <seb_kuzminsky> yeah, that's about right
[16:28:01] <jepler> I use somebody else's python package for receiving the github message
[16:28:03] <JT-Shop> that would be a lot easier than all the xml stuff
[16:28:12] <seb_kuzminsky> though i think of it as a struct of structs, being a C guy ;-)
[16:28:40] <seb_kuzminsky> jepler: that sounds very sensible
[16:28:48] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #133: Thanks! 02
https://github.com/LinuxCNC/linuxcnc/pull/133#issuecomment-239927907
[16:28:51] <jepler> https://media.unpythonic.net/emergent-files/sandbox/pull_request.py
[16:28:56] <JT-Shop> probably more accurate than my description
[16:29:02] <jepler> and then some other library for making API calls to github
[16:29:14] <jepler> payload['pull_request']['base']['repo']['clone_url'],
[16:29:30] <jepler> I have a feeling the `jq` for this is much terser
[16:29:34] <seb_kuzminsky> '][' is a funny way to spell .
[16:29:38] <jepler> jq .pull_request.base.repo.clone_url probably
[16:29:41] <jepler> seb_kuzminsky: yes I agree
[16:30:14] <jepler> >>> j = json.loads('{"a": 1}')
[16:30:14] <jepler> >>> j.a
[16:30:16] <jepler> AttributeError: 'dict' object has no attribute 'a'
[16:30:16] <jepler> >>> j['a']
[16:30:16] <jepler> 1
[16:30:29] <jepler> but in python's built-in json implementation it seems to be the spelling you need
[16:31:03] <seb_kuzminsky> makes sense
[16:33:06] <jepler> >>> j = json.loads('{"a": 1}', object_hook=object_hook)
[16:33:06] <jepler> >>> j.a
[16:33:07] <jepler> 1
[16:33:14] <jepler> ah you can write an "object_hook" that lets you do magic things like this
[17:19:58] <jmk-mcfaul_> jepler: I think the duplicate newinst implementations are due to a desire not to break existing configs
[17:22:55] <jmk-mcfaul_> I'm not sure if either newinst or newthread (another nice improvement) are possible as long as RTAI style kernel-module RT must be supported
[17:23:11] <jmk-mcfaul_> they're actively trying to deprecate that, and go with user-space only
[17:23:43] <jmk-mcfaul_> s/possible/possible without abominations/
[17:24:03] <jmk-mcfaul_> anything's possible
[17:24:04] <jepler> yeah the newinst I implemented, long before sim or uspace, was abomination
[17:24:15] <jepler> I think the implementation was: write a function pointer to a magic address and then read a file from proc
[17:24:23] <jepler> what's not to love?
[17:24:52] <jmk-mcfaul_> speaking of proc - I recall something from andy about setting rtapi_msg_level
[17:25:46] <jepler> yeah we lost the original way of doing that, which was via /proc, because that code bitrotted as kernel APIs changed
[17:25:54] <jepler> I agree somebody should do something about it
[17:26:08] <jmk-mcfaul_> understood...
[17:26:20] <jmk-mcfaul_> do the -v and -V args to halcmd do anything anymore?
[17:26:44] <jmk-mcfaul_> I thought they changed the msg level, but maybe only for messages generated from halcmd in user space, and maybe only for the duration of the halcmd run
[17:27:35] <jepler> without looking I suspect they only affect the halcmd process
[17:27:58] <jmk-mcfaul_> sadly, the days when I could work on something like that have passed
[17:28:14] <jmk-mcfaul_> the code and the OS have changed, my understanding is out of date
[17:28:52] <jmk-mcfaul_> I do have some relatively trivial changes I would like to contribute - hal component tweaks
[17:29:11] <jepler> ok
[17:29:26] <jmk-mcfaul_> 1) change the limit value inputs on limit1 and limit2 from params to pins. You did that for limit3 in 2010
[17:29:27] <jepler> aside from the bb gpio driver right?
[17:29:47] <jepler> sounds good
[17:30:03] <jmk-mcfaul_> 2) add an "in-limit" output to the limit blocks (I implemented it for limit3 in 2013, but never committed)
[17:30:34] <jmk-mcfaul_> 3) add the ability to have comments in hal-streamer input files (if line[0] = '#' skip line)
[17:31:13] <jepler> those all sound nice
[17:31:39] <jepler> each pull request should do just one of those things
[17:31:42] <jmk-mcfaul_> 4) add nand and nor to logic.comp
[17:31:45] <jmk-mcfaul_> agreed
[17:32:13] <jmk-mcfaul_> I did all those changes on an old computer belonging to tesla orchestra, which I was messing with Friday
[17:32:21] <jepler> and although they seem unlikely to break anything, I'd be happiest making the changes on master branch only
[17:32:26] <jmk-mcfaul_> carefully brought that checkout up to current master
[17:32:32] <jmk-mcfaul_> and committed each change
[17:32:49] <jmk-mcfaul_> but I was unable to push them to github/jmkasunich/linuxcnc
[17:33:05] <jmk-mcfaul_> that machine is ancient (ubuntu 8.04) and so is the git on it
[17:33:31] <jepler> I think you said something the other day about getting the changes in patch form too?
[17:33:34] <jmk-mcfaul_> I resorted to emailing the modified source to myself, and can apply it to the checkout I have on this machine
[17:34:06] <jmk-mcfaul_> that machine is back in storage, but I have the source files for each comp
[17:34:38] <jmk-mcfaul_> the other problem with that machine is that after updating the git checkout to current master I couldn't build on it
[17:34:58] <jepler> yes, we dropped support for 8.04 in our master branch
[17:35:10] <jmk-mcfaul_> too many missing dependencies (tcl8 and others)
[17:35:37] <jmk-mcfaul_> do you still support ubuntu 9.10?
[17:35:56] <jepler> I don't know to be honest
[17:36:06] <jepler> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
[17:36:08] <jepler> I guess not for master
[17:36:18] <jepler> the oldest we support in master seems to be 12.04.
[17:36:27] <jmk-mcfaul_> mcfaul is 9.10... beaglebone is debian wheezy and much more current, but I can't build master there, need halonly
[17:37:14] <jepler> it's sounding like it'd be easiest for you to just mail me the patches or source files and I can make it happen
[17:37:42] <jmk-mcfaul_> what do you think about pushing the halonly option to master? seems like it should be safe for anyone who doesn't invoke the option in ./configure
[17:38:07] <jmk-mcfaul_> or are there lots of debian and other packaging implications that haven't been addressed?
[17:38:34] <jepler> debian packaging isn't important, it's simply not an option at this point to build a package that way
[17:38:59] <jepler> without reviewing the commits, my main concerns are: 1) the testsuite will have a bunch of failing tests when you use the new option; you have to know to just ignore the failures
[17:39:15] <jepler> and 2) whether it is a hack that will be a pain to keep working properly if it's not regularly tested
[17:39:40] <jepler> let me look at the commits again and think about it for a minute
[17:39:40] <jmk-mcfaul_> understood - good enough reasons to keep it in its own branch
[17:40:06] <jmk-mcfaul_> I can also investigate swap on the bone - but not sure about the concept of swap to a flash device
[17:40:47] <jmk-mcfaul_> oddly, machinekit would build (complete, emc + nml + hal) on the bone without running out of memory
[17:41:32] <jepler> it would be interesting to know why.
[17:41:55] <jepler> hm there's at least one mistake in that branch bad enough that I want to rebase it, which unfortunately is a complicating factor for your work based on top of mine
[17:42:06] <jepler> I have made you fall in the deep end of git
[17:42:15] <jmk-mcfaul_> feces occur
[17:42:29] <jmk-mcfaul_> I'm learning
[17:42:48] <jmk-mcfaul_> by neccessity, which sometimes might be the only way
[17:43:55] <jmk-mcfaul_> my component patches are very isolated from makefiles, etc... I can apply them to pretty much any branch, commit, and push to jmkasunich/linuxcnc, then you could cherry pick for master... of course I used several terms in that sentence that I only partly understand
[17:44:32] <jepler> yes, I think that's approximately right usage of terminology
[17:45:49] <jmk-mcfaul_> I see that there are three tests for limit3... they'll have to be changed for the params-to-pins change, and again for the "add in-limit pin" change
[17:45:52] <jepler> the answer seems to be: machinekit has disabled compiler optimizations
[17:46:17] <jepler> src/Makefile: drop -Os, fix profiling
[17:46:17] <jepler>
[17:46:17] <jepler> known to tickle gcc bugs, and of dubious value
[17:46:19] <jmk-mcfaul_> for ARM? or for all archs
[17:46:22] <jepler> -OPT := -Os $(INTEGER_OVERFLOW_FLAGS)
[17:46:22] <jepler> +OPT := $(INTEGER_OVERFLOW_FLAGS)
[17:46:26] <jepler> for all arches
[17:47:09] <jmk-mcfaul_> I have experienced gcc bugs when running various -O on AVR32 (at work), the generally accepted solution is to turn optimization off or down
[17:47:45] <jmk-mcfaul_> I had simple math expressions that yielded grossly wrong answers
[17:48:37] <jepler> at $DAY_JOB we have about 100x more bogus "it's a compiler bug" claims than proven ones. that's with i386 and amd64 as targets, though, not oddball stuff like arm32
[17:49:17] <jmk-mcfaul_> I was able to reduce it to a program of "hello world" complexity that displayed the bug
[17:49:36] <jmk-mcfaul_> a = someval
[17:49:39] <jmk-mcfaul_> b = someother val
[17:49:42] <jmk-mcfaul_> c = a / b
[17:50:02] <jmk-mcfaul_> if ( c != right_answer ) printf("ouch");
[17:50:12] <jepler> huh to my surprise removing the optimization flags in this case doesn't change memory usage much
[17:50:18] <jmk-mcfaul_> or just printf c
[17:50:34] <jmk-mcfaul_> on the beagle? or on an x86 machine?
[17:50:36] <jepler> on x86
[17:51:08] <jepler> using about 650MB RAM in any case
[17:51:22] <jmk-mcfaul_> maybe the optimizer works differently on ARM?
[17:51:47] <jmk-mcfaul_> how big is the patch, I can try it here. just one line in top makefile?
[17:57:35] <jmk-mcfaul_> I've been gitted again
[17:57:55] <jmk-mcfaul_> I did "git checkout master", and git status agrees that I'm on that branch
[17:58:12] <jmk-mcfaul_> but ./configure --help shows the "halonly" option ?!?
[18:02:02] <jmk-mcfaul_> oh, ./configure is a generated file, needed to run autogen.sh
[18:02:52] <jepler> yes
[18:02:59] <jepler> sorry for disappearing for a minute, and I may disappear again
[18:03:09] <jepler> I think there's a failed hard drive at my wife's organization that I'll need to deal with tonight
[18:03:34] <jmk-mcfaul_> ok.. I made the one line change (remove -Os in src/Makefile) and am running a test build on the bone
[18:04:16] <jepler> configure may be supplying -O2, I'd have to look at build logs of machinekit to know for sure
[18:04:43] <jmk-mcfaul_> I'll report back on build results
[18:04:52] <jmk-mcfaul_> if it doesn't work I'll switch back to halonly
[18:04:57] <jepler> OK
[18:05:18] <jmk-mcfaul_> either way, I'll apply my patches, (and update tests for comps that have them), then commit and push to jmkasunich
[18:05:20] <jepler> if they do have a change besides turning off optimization that fixes memory used by the build, I'd really love to find what that is and apply it to linuxcnc
[18:05:55] <jepler> yes, please create a pull request and if it's not suitable as is I can work by cherry picking
[18:06:03] <jmk-mcfaul_> I'm afraid I could spend all evening digging and not find that
[18:06:19] <jepler> yes, please don't spend your time that way
[18:06:23] <jepler> I may need to spend mine though
[18:06:36] <jepler> and I have a bbb so I can test how much memory is used there
[18:16:38] <jepler> machinekit doesn't even build on debian jessie
[18:16:52] <jepler> their messaginging library is too fresh to be available there
[18:17:24] <jmk-mcfaul_> I think I'm feeling very stupid right now
[18:17:58] <jepler> new roadblock?
[18:18:05] <jmk-mcfaul_> no
[18:18:19] <jmk-mcfaul_> I think that when the build failed I had a firefox running on the bone
[18:18:42] <jmk-mcfaul_> the dmesg "out of memory" message was preceeded by something that resembles a top listing showing process size
[18:18:52] <jmk-mcfaul_> firefix was much much bigger than the compiler
[18:18:53] <jepler> sigh I wouldn't think of closing the browser either
[18:19:15] <jmk-mcfaul_> the build has progressed past the point that it crashed last time
[18:19:25] <jepler> .. though you also changed a compiler flag
[18:19:31] <jepler> right?
[18:19:41] <jmk-mcfaul_> yes, will have to go back and un-change it
[18:20:01] <jmk-mcfaul_> I'll do that before I got to bed tonight
[18:20:18] <seb_kuzminsky> our compile-time memory usage went way up, when mah added python to task i think
[18:20:47] <jepler> seb_kuzminsky: yeah that is the main suck
[18:20:55] <jepler> beyond having c++ at all, having boost is next
[18:21:14] <seb_kuzminsky> fwiw i swap to flash on my bbb and it hasn't blown up yet
[18:21:25] <seb_kuzminsky> but i guess the flash card is wearing out faster than it would otherwise
[18:21:26] <jepler> oh you have a bbb too?
[18:21:41] <seb_kuzminsky> i think everyone except for cradek has one :-P
[18:21:45] <jepler> hah
[18:21:47] <jmk-mcfaul_> I have a bbg
[18:22:04] <seb_kuzminsky> beagle bone *
[18:22:11] <jepler> despite my misgivings about their heat problems I ordered an odroid xu4, maybe it'll come this week
[18:22:22] <seb_kuzminsky> shiny
[18:23:27] <jmk-mcfaul_> does that have gpio? or is it more of a computer platform than a controller platform?
[18:24:00] <seb_kuzminsky> it's got a little gpio header, but no bb*-like pru
[18:24:12] <seb_kuzminsky> http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825
[18:24:20] <jmk-mcfaul_> I found the header
[18:24:31] <jepler> it has an I/O header with SPI, if I ran linuxcnc with it, it would be using a mesa 7i90
[18:24:31] <jmk-mcfaul_> 30 pins, not bad
[18:24:50] <seb_kuzminsky> it's got spi, which jepler got working talking to a 7i90 on an older odroid board (u3)
[18:25:24] <jmk-mcfaul_> I'm doing very bare-bones - the three projects that I have right now all need only 2-3 steppers, plus a jogwheel and a few other bits of IO
[18:25:43] <seb_kuzminsky> nice
[18:25:46] <seb_kuzminsky> what are your projects?
[18:25:50] <jmk-mcfaul_> bbg + 7" LCD touchscreen is about $120
[18:26:15] <jmk-mcfaul_> surface grinder automation (move back and forth over a preset stroke, advancing crossfeed by a preset amount each stroke)
[18:26:33] <jepler> afk
[18:26:47] <jmk-mcfaul_> cylindrical grinder automation (spin workhead stepper, while moving crossfeed and infeed synchronously)
[18:27:06] <jmk-mcfaul_> giant claw game (run inverted tripod kins from a joystick)
[18:27:17] <seb_kuzminsky> sounds like great use cases for hal-only :-)
[18:27:23] <jmk-mcfaul_> zactly
[18:27:39] <jmk-mcfaul_> the claw game is the one that got me moving again, it has a deadline
[18:27:51] <jmk-mcfaul_> mid september
[18:28:00] <seb_kuzminsky> jepler: when you rtk,
http://odroid.com/dokuwiki/doku.php?id=en:howto_install_heatsink_xu4
[18:28:30] <seb_kuzminsky> for the claw game, are you using strings and stepper-driven spools for the tripod?
[18:28:36] <jmk-mcfaul_> yes
[18:28:52] <seb_kuzminsky> didn't you do some giant-sized flying dance machine with that kind of technology a while back?
[18:28:57] <jmk-mcfaul_> https://www.youtube.com/watch?v=rcjW8E-msyw&feature=youtu.be
[18:29:06] <jmk-mcfaul_> yes - same winches, different application
[18:29:23] <seb_kuzminsky> oh wow, it's bigger than i imagined when you said claw game
[18:29:40] <seb_kuzminsky> looks like the wind's not helping her
[18:29:49] <jmk-mcfaul_> winches are NEMA 42 steppers driving 4.5" diameter x 12" long drums with a level-wind mechanism, can hold 400 feet of kevlar line
[18:29:57] <jmk-mcfaul_> and move at 10 ft/sec
[18:30:30] <seb_kuzminsky> wow
[18:31:26] <jmk-mcfaul_> we haven't had the opportunity to fully utilize it - the event in that video we had 16' tall 4x4s in about a 30 foot triangle
[18:31:40] <jmk-mcfaul_> given suitable anchor points we could cover half a football field
[18:31:56] <jmk-mcfaul_> and it can lift a couple pounds
[18:32:32] <jmk-mcfaul_> I'd love to equip the claw with jaws that could hold a 12oz red dixie cup, and use it for beer delivery
[18:33:09] <seb_kuzminsky> make it carry a beer hose and fill people's cups up
[18:33:10] <seb_kuzminsky> bbl
[18:38:01] <jmk-mcfaul_> jepler, build succeeded with -Os removed (and no firefox running)
[18:43:48] <jmk-mcfaul_> gotta run an errand - I just fetched and merged from upstream, make clean, autogen, config, and restarted build
[19:04:56] <cradek> haha "beer hose"
[19:05:46] <jmk-mcfaul_> hi cradek
[19:05:49] <cradek> hey
[19:06:20] <cradek> think you'll go to wichita?
[19:06:26] <jmk-mcfaul_> when?
[19:06:32] <cradek> pretty sure I'm going, hopefully riding with seb
[19:06:45] <cradek> umm october I think? lemme find the thread
[19:07:06] <jmk-mcfaul_> found it
[19:07:49] <cradek> oct 17-23ish
[19:08:31] <jmk-mcfaul_> tesla orchestra (claw game) gig on oct 13
[19:08:40] <jmk-mcfaul_> in theory I could do something the following week
[19:08:45] <cradek> sweet
[19:08:53] <cradek> in theory maybe we'll see you there
[19:09:01] <jmk-mcfaul_> a friend and I are thinking about a short trip to watkins glen NY in october
[19:09:45] <cradek> is the friend better looking than us?
[19:09:51] <jmk-mcfaul_> indeed
[19:10:01] <cradek> heh, then you better not cancel
[19:10:58] <jmk-mcfaul_> no idea when it will be
[19:11:05] <jmk-mcfaul_> probably decide the last minute
[19:11:19] <cradek> driving?
[19:11:33] <jmk-mcfaul_> to NY? yes - and taking dogs, so no sitter needed
[19:11:43] <jmk-mcfaul_> for wichita I need plane tickets and dogsitter
[19:11:44] <cradek> then 10-20 minutes planning ahead is plenty
[19:11:57] <cradek> well maybe a couple hours for laundry
[19:12:03] <jmk-mcfaul_> heh
[19:12:41] <jmk-mcfaul_> the prettiest trail at watkins glen is "no dogs allowed", need to arrange a place for them to stay a few hours
[19:12:46] <jmk-mcfaul_> so a day or two
[19:14:59] <jmk-mcfaul_> wichita added to my calendar, we'll see how things work out
[19:15:04] <jmk-mcfaul_> and yay, the build finished
[19:15:23] <jmk-mcfaul_> so the entire "halonly" thing wasn't even needed
[19:15:50] <jmk-mcfaul_> and it built in only 38 minutes instead of an hour
[19:31:57] <jmk-mcfaul_> hmm, running the testsuite on unmodified master gives several fails
[19:33:17] <jmk-mcfaul_> Running test: tests/halui/jogging
[19:33:17] <jmk-mcfaul_> *** tests/halui/jogging: FAIL: test run exited with 1
[19:33:17] <jmk-mcfaul_> Running test: tests/halui/mdi
[19:33:17] <jmk-mcfaul_> *** tests/halui/mdi: FAIL: test run exited with 1
[19:33:17] <jmk-mcfaul_> Running test: tests/hard-limits
[19:33:18] <jmk-mcfaul_> *** tests/hard-limits: FAIL: test run exited with 1
[19:33:29] <jmk-mcfaul_> Running test: tests/interp/mdi-oword-m66
[19:33:29] <jmk-mcfaul_> *** tests/interp/mdi-oword-m66: FAIL: test run exited with 1
[19:33:51] <jmk-mcfaul_> Running test: tests/interp/subroutine-return
[19:33:51] <jmk-mcfaul_> *** tests/interp/subroutine-return: FAIL: test run exited with 1
[19:33:55] <jmk-mcfaul_> Running test: tests/io-startup/nonrandom/no-tool-in-P0
[19:33:55] <jmk-mcfaul_> *** tests/io-startup/nonrandom/no-tool-in-P0: FAIL: test run exited with 1
[19:33:55] <jmk-mcfaul_> Running test: tests/io-startup/nonrandom/tool-in-P0
[19:33:55] <jmk-mcfaul_> *** tests/io-startup/nonrandom/tool-in-P0: FAIL: test run exited with 1
[19:33:55] <jmk-mcfaul_> Running test: tests/io-startup/random/no-tool-in-P0
[19:33:56] <jmk-mcfaul_> *** tests/io-startup/random/no-tool-in-P0: FAIL: test run exited with 1
[19:34:00] <jepler> those all look like tests that run linuxcnc
[19:34:00] <jmk-mcfaul_> Running test: tests/io-startup/random/tool-in-P0
[19:34:02] <jmk-mcfaul_> *** tests/io-startup/random/tool-in-P0: FAIL: test run exited with 1
[19:34:05] <cradek> you can find evidence in the test directory
[19:35:04] <jepler> there might be some leftover from halonly that needs to be cleaned out more aggressively
[19:35:11] <jepler> jepler@beaglebone:~/src/linuxcnc/linuxcnc/src$ ../scripts/rip-environment runtests ../tests/halui/jogging/
[19:35:14] <jepler> Running test: ../tests/halui/jogging
[19:35:17] <jepler> Runtest: 1 tests run, 1 successful, 0 failed + 0 expected
[19:38:16] <jepler> yay ingrid's work server simply rebooted and resilvered, but there is a drive with SMART problems that indicates it should be replaced
[19:38:16] <jmk-mcfaul_> complete list:
[19:38:23] <jmk-mcfaul_> Runtest: 185 tests run, 155 successful, 30 failed + 0 expected
[19:38:23] <jmk-mcfaul_> Failed:
[19:38:23] <jmk-mcfaul_> tests/halui/jogging
[19:38:23] <jmk-mcfaul_> tests/halui/mdi
[19:38:23] <jmk-mcfaul_> tests/hard-limits
[19:38:24] <jmk-mcfaul_> tests/interp/mdi-oword-m66
[19:38:25] <jmk-mcfaul_> tests/interp/subroutine-return
[19:38:29] <jmk-mcfaul_> tests/io-startup/nonrandom/no-tool-in-P0
[19:38:31] <jmk-mcfaul_> tests/io-startup/nonrandom/tool-in-P0
[19:38:33] <jmk-mcfaul_> tests/io-startup/random/no-tool-in-P0
[19:38:36] <jmk-mcfaul_> tests/io-startup/random/tool-in-P0
[19:38:37] <jmk-mcfaul_> tests/lathe
[19:38:39] <jmk-mcfaul_> tests/linuxcncrsh-tcp
[19:38:41] <jmk-mcfaul_> tests/linuxcncrsh
[19:38:43] <jmk-mcfaul_> tests/mdi-queue/oword-queue-buster
[19:38:45] <jmk-mcfaul_> tests/mdi-queue/simple-queue-buster
[19:38:47] <jmk-mcfaul_> tests/motion-logger/basic
[19:38:49] <jmk-mcfaul_> tests/motion-logger/mountaindew
[19:38:51] <jmk-mcfaul_> tests/motion-logger/startup-gcode-abort
[19:38:53] <jmk-mcfaul_> tests/motion/jogwheel-axis
[19:38:55] <jmk-mcfaul_> tests/motion/jogwheel-joint
[19:38:59] <jmk-mcfaul_> tests/statbuffer-g5x-abort
[19:39:01] <jmk-mcfaul_> tests/t0/nonrandom
[19:39:03] <jmk-mcfaul_> tests/t0/random-with-t0
[19:39:05] <jmk-mcfaul_> tests/t0/random-without-t0
[19:39:07] <jmk-mcfaul_> tests/tclsh-extensions
[19:39:09] <jmk-mcfaul_> tests/tlo
[19:39:11] <jmk-mcfaul_> tests/toolchanger/m61
[19:39:13] <jmk-mcfaul_> tests/toolchanger/toolno-pocket-differ/nonrandom
[19:39:16] <jmk-mcfaul_> tests/toolchanger/toolno-pocket-differ/random
[19:39:17] <jmk-mcfaul_> tests/twopass-personality
[19:39:19] <jmk-mcfaul_> tests/twopass
[19:39:21] <jmk-mcfaul_> I picked the first one and started looking at the "results" file
[19:39:23] <jmk-mcfaul_> says to check logs
[19:39:25] <jmk-mcfaul_> debug log is empty, print log has routine startup stuff in it
[19:39:52] <cradek> dmesg?
[19:39:54] <jepler> those all look like tests that actually run linuxcnc, not just hal. except for tclsh-extensions
[19:40:20] <jepler> that one uses LINUXCNC_EMCSH which is probably skipped by halonly
[19:40:31] <jmk-mcfaul_> dmesg is completely empty (I did a dmesg -c a while ago)
[19:40:40] <jepler> my suspicion: something is "left over" from building with halonly
[19:40:49] <jmk-mcfaul_> the bone used xenomai, I don't think it logs to dmesg
[19:41:05] <jmk-mcfaul_> how agressive should I be - I did make clean, autogen, config, and make
[19:41:58] <jepler> honestly that should have been enough
[19:42:28] <jepler> there is a command that will erase all files not known to git, that's what I do if "other cleaning" wasn't enough, but right now you don't need to do that and then lose another 45 minutes to building again
[19:42:41] <jepler> I recommend you ignore the reported failures and go ahead and prepare your pull request
[19:43:01] <jmk-mcfaul_> yeah, I'll run individual tests for the comps I care about
[19:43:14] <jepler> sounds like a plan
[19:43:53] <jepler> anyway, "git clean -d -x -n" will show you what git would clean, including directories (-d) and usually ignored files (-x) but not do anything (-n)
[19:44:03] <jepler> change the -n to -f to actually clean those things up
[19:44:12] <jmk-mcfaul_> hmm - when I did configure, I included --disable-check-runtime-deps
[19:44:20] <jmk-mcfaul_> I wonder if some required runtime is missing
[19:45:00] <jepler> I don't think that's it, because installing the debian build-time deps is enough for the tests to pass on our buildbot
[19:45:37] <jmk-mcfaul_> I'm not going to do the git clean, because it would clean some stuff I care about - new components, etc
[19:49:40] <jepler> anyway, one of these annoyingly long-compiling files, interp-python.cc, uses 100MB RAM on beaglebone with g++ 4.6, 150MB RAM on amd64 with g++ 4.6, and 490MB RAM on amd64 with g++ 4.9
[19:49:47] <jepler> so they have some pretty serious memory regressions going on
[19:50:01] <jmk-mcfaul_> wow
[19:50:26] <jepler> "maxresident" as measured by /usr/bin/time /usr/bin/g++... and rounded by eye
[19:51:21] <jepler> it's no surprise amd64 uses somewhat more memory, since pointers are 8 bytes instead of 4, and compilers have a lot of pointers
[19:54:42] <jmk-mcfaul_> I think I've successfully pushed a commit to jmkasunich/linuxcnc
[19:55:00] <jmk-mcfaul_> damn browser on this old machine won't run github properly, gotta go to another computer to try a PR
[19:55:48] <jepler> I found the commit on github, looks plausible
[19:57:00] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jmkasunich opened pull request #140: limit1 & limit2: change params to pins (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/140
[19:58:31] <jepler> as far as I can see there are no limit1/2 tests
[19:58:59] <KGB-linuxcnc> 03John Kasunich 05master 9dd93d3 06linuxcnc 10src/hal/components/limit1.comp 10src/hal/components/limit2.comp limit1 & limit2: change params to pins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9dd93d3
[19:59:00] <jmkasunich> yes, that made my life simple
[20:00:39] <jmkasunich> looks like buildbot is doing its thing?
[20:01:33] <jepler> actually looks like buildbot is stuck. :( but travis-ci is doing its thing
[20:01:54] <jmkasunich> travis is a buildbot at github?
[20:01:58] <jepler> seb_kuzminsky: wheezy-preempt-rt fell off the planet again
[20:02:58] <jepler> jmkasunich: buildbot is the service that seb_kuzminsky hosts and that we have had for many many years. it builds on a bunch of different architectures and RT kernels, but only stuff pushed to git.linuxcnc.org
[20:03:09] <jmkasunich> thought so
[20:03:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #140: limit1 & limit2: change params to pins (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/140
[20:03:36] <jepler> jmkasunich: travis-ci is a free-to-use service that integrates with github, can build stuff from pull requests without intervention by devs, but can only build for amd64 ubuntu without a realtime kernel
[20:03:47] <jmkasunich> and that message from kgb also implies a push to git.linuxcnc.org.... how did that happen, the pull request hasn't even been merged at github yet
[20:03:50] <jepler> we just started using it in the last few days, so that's new for us
[20:04:11] <jepler> I pushed your thing to git.linuxcnc.org, which immediately sends notice to irc and sometime later pushes to github
[20:04:23] <jepler> that second step just happened, and caused the pull request to be closed ^^
[20:05:01] <jmkasunich> ok - my mental model was backwards - I thought you'd merge it into github and then to g.l.o
[20:06:05] <jepler> either way is a possibility, but we still think of g.l.o as the primary thing and github as a mere mirror (except that we're thrilled to get pull requests on github)
[20:06:53] <jmkasunich> starting to understand - even tho the request arrives from github, the flow takes it to GLO first, then the github mirror is updated
[20:07:32] <jmkasunich> I have three more tweaks to existing comps, and then 2-3 new comps that may or may not merit inclusion
[20:11:53] <jepler> > The following default environment variables are available to all builds.
[20:11:58] <jepler> > HAS_JOSH_K_SEAL_OF_APPROVAL=true
[20:13:33] <jmk-mcfaul_> what does .LP mean in a .comp file?
[20:14:10] <jmk-mcfaul_> oh, I think I see my error
[20:14:17] <jepler> jmkasunich: it's manpage markup. it roughly means "paragraph break" I think
[20:14:26] <jmk-mcfaul_> back quotes != singlequotes
[20:14:27] <jepler> .LP .PP and .P are all mutual aliases says the documentation
[20:14:44] <jepler> I'll be happy to fix up any documentation crud, that stuff is thankless and opaque
[20:14:52] <jmk-mcfaul_> I edited a line preceeding a .LP line, comp barfed on the .LP because I screwed up quotes
[20:14:56] <jmk-mcfaul_> I will fix
[20:15:44] <jepler> the reference I use is: man 7 groff_man but even it doesn't really explain what .LP *means* only what it *does* in terms of messing with margins and vertical spacing...
[20:16:00] <jmk-mcfaul_> the issue here isn't really what it does
[20:16:45] <jmk-mcfaul_> here is the git diff showing my change:
[20:16:49] <jmk-mcfaul_> function _ nofp;
[20:16:50] <jmk-mcfaul_> description """
[20:16:50] <jmk-mcfaul_> -General `logic function' component. Can perform `and', `or'
[20:16:50] <jmk-mcfaul_> -and `xor' of up to 16 inputs.
[20:16:50] <jmk-mcfaul_> +General `logic function' component. Can perform `and', `or',
[20:16:50] <jmk-mcfaul_> +`nand', `nor' and `xor' of up to 16 inputs.
[20:16:52] <jmk-mcfaul_> .LP
[20:16:54] <jmk-mcfaul_> Determine the proper value for `personality'
[20:17:19] <jmk-mcfaul_> and the resulting error message
[20:17:20] <jmk-mcfaul_> Preprocessing logic.comp
[20:17:20] <jmk-mcfaul_> hal/components/logic.comp:27:1: Trying to find one of "$", "pin", "param", "function", "variable", "option", "see_also", "notes", "description", "license", "author", "include", "modparam"
[20:17:20] <jmk-mcfaul_> > .LP
[20:17:20] <jmk-mcfaul_> > ^
[20:17:31] <jmk-mcfaul_> note that I didn't change the .LP, only the line preceding it
[20:18:13] <jepler> I confess to not spotting the problem right away either
[20:18:42] <jmk-mcfaul_> my mistake again, there are two .LPs, that isn't the broken one
[20:19:12] <jepler> (".IP \\(bu" is "start of a bullet item" and the extra backslash is to appease comp)
[20:20:02] <jmk-mcfaul_> in my copy/paste haste I put an extra """
[20:20:31] <jepler> OK so the mystery is solved?
[20:20:32] <jmk-mcfaul_> compiles correctly now
[20:20:35] <jepler> yay
[20:21:01] <jmk-mcfaul_> hah, no tests for logic either
[20:21:19] <jmk-mcfaul_> I suppose that isn't really a good thing, but it leaves me off the hook
[20:27:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jmkasunich opened pull request #141: logic.comp: add 'nand' and 'nor' outputs (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/141
[20:32:42] <jmk-mcfaul_> the test for limit3 is pretty lame
[20:32:54] <jmk-mcfaul_> it doesn't actually set an accel limit
[20:33:22] <jmk-mcfaul_> so limit2 would deliver the same result
[20:41:03] <jmk-mcfaul_> ok, test limit3.2 does test accel limiting
[20:41:17] <jmk-mcfaul_> however, tests limit3.0 and limit3.1 are _exactly_ the same test
[20:51:16] <jmk-mcfaul_> I'm going to make a better test case for limit3
[20:51:58] <jmk-mcfaul_> given that limit3.1 is currently an exact copy of limit3.0, should I overwrite limit3.1 with my new test? or should I ignore that and make my new test limit3.3?
[20:56:10] <KGB-linuxcnc> 03John Kasunich 05master c1cc04c 06linuxcnc 10src/hal/components/logic.comp logic.comp: add 'nand' and 'nor' outputs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c1cc04c
[20:59:38] <jepler> jmkasunich: it is? I'm sure that wasn't intended
[20:59:53] <jepler> sure, delete it / replace it / whatever
[21:03:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #141: logic.comp: add 'nand' and 'nor' outputs (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/141
[21:12:47] <jepler> damnit, that server crashed again
[21:14:07] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jmkasunich opened pull request #142: limit3.comp: add 'in-limit' output pin (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/142
[21:25:25] <jmk-mcfaul_> does anyone know what happened to the hal_streamer man page?
[21:32:27] <jmk-mcfaul_> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=eaff4f05eb48a0a38da154dfe3eb9e454b244824
[21:32:44] <jmk-mcfaul_> "convert streamer man pages to asciidoc"
[21:33:15] <jmk-mcfaul_> seb_kuzminsky: was this an experiment? why only streamer?
[22:04:36] <skunkworks> So I for grins threaded with the emco lathes with single index (instead of using the 100 line channel)
[22:04:47] <skunkworks> it worked very well
[22:09:30] <pcw_home> probably a better scheme for a 1 wire encoder is a "A" only encoder with 100 or so slots and a simulated (mod count) index
[22:09:57] <jmkasunich> as long as it never turns backwards
[22:10:56] <pcw_home> For threading 1 wire is ok
[22:10:59] <jmkasunich> including when you stop between passes to test-fit the nut
[22:12:02] <pcw_home> Why would you ever lose count unless you shut down LinuxCNC?
[22:12:27] <jmkasunich> if its A only, it doesn't know which way the spindle is turning
[22:12:36] <jmkasunich> suppose you stop the lathe to test the nut
[22:12:43] <pcw_home> Yeah thats an issue
[22:12:54] <jmkasunich> and accidently turn it 5 degrees backwards
[22:13:06] <pcw_home> so 2 wires (A,B) if you need to test
[22:13:33] <pcw_home> (or rigid tap)
[22:15:37] <pcw_home> just saying that an simulated encoder index would be helpful (and allow non 1:1 encoder/spindle ratios also)
[22:17:59] <skunkworks> https://youtu.be/jHKmcjoCyLg
[22:18:19] <skunkworks> https://youtu.be/o2eqf9CGnUY
[22:18:39] <skunkworks> 280 ish rpm - 3/4 10
[22:19:09] <skunkworks> not the best work - not an actual threading insert. Just wanted to show tracking
[22:27:03] <pcw_home> how much does the RPM drop when threading vs retract?
[22:29:54] <skunkworks> I forgot to really watch.
[22:30:00] <skunkworks> it is a 800w motor
[22:30:36] <skunkworks> you can hear it laboring a bit - but I could not tell you what it was dropping
[22:30:53] <pcw_home> seems like the rate of change of RPM would determine the error on the first threads
[22:34:41] <skunkworks> putting it next to all-thread I could not tell the difference
[22:35:06] <skunkworks> plus it was 10tpi as best as I could measure peaks with a caliper
[22:36:03] <skunkworks> (printer port)
[22:38:16] <skunkworks> that was 5+ inches of threads also
[22:38:51] <skunkworks> I was pretty impressed with the emco - without doing anyting - it only had about .001 taper over 6 inches
[22:42:02] <skunkworks> that hit about 27ipm at that rpm.. its current max feed was 30ipm
[23:02:13] <mozmck> I've had a couple of people now cutting several of the same part out of a sheet, and one or more parts will cut fine and then the next one will have rounded corners as if linuxcnc lost it's G64 tolerance setting in mid-stream. The parts are nested so are all in the same gcode file.
[23:38:12] <skunksleep> mozmck: is it consistant?
[23:38:41] <skunksleep> Can you reproduce it with a given file?
[23:38:42] <mozmck> skunksleep: no, it's intermittent.
[23:38:52] <skunksleep> Yeck
[23:39:21] <mozmck> I don't know. One guy today had it happen twice, but I don't know how many times he ran the file. I have the file so I could do some testing.
[23:41:05] <skunksleep> If you lowered the acceleration - you could really see it in the plot when it happens
[23:43:54] <mozmck> Oh, it's quite visible. On this piece it seemed to only round the inside corner, but did it badly.
[23:44:56] <skunksleep> Only 1 corner?
[23:47:21] <mozmck> Now that you mention it, it does look like that. I better take a look at this file a little more.
[23:49:13] <mozmck> The file sure looks fine in the preview.