Back
[06:33:29] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15ikcalB commented on issue #93: @jepler the default behavior, is that *only* for signals, only some keywords trigger a subtree - should say, when using dot-notation to group signals like: `X.motor.feedback` or `X.motor.set-pos`, `motor` is not seen as a parent leaf, and all `X.motor...` signals are displayed on the same hierarchy level, instead of being grouped together.... 02
https://github.com/LinuxCNC/linuxcnc/pull/93#
[06:37:30] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15ikcalB commented on issue #91: @jepler thank you!... 02
https://github.com/LinuxCNC/linuxcnc/pull/91#issuecomment-233601185
[07:13:49] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #93: ... 02
https://github.com/LinuxCNC/linuxcnc/pull/93#issuecomment-233608169
[07:18:30] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #93: Thank you for the explanation. Now that I see what is going on, I think this makes sense for master. 02
https://github.com/LinuxCNC/linuxcnc/pull/93#issuecomment-233609016
[07:20:10] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #93: @SebKuzminsky this is a purely cosmetic change, though it probably has a low risk of introducing problems. Do you want this in any of the stable trees, or shall we put it in master only? 02
https://github.com/LinuxCNC/linuxcnc/pull/93#issuecomment-233609352
[07:20:40] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15ikcalB commented on issue #93: @jepler exactely. That enables grouping signals, i.e. according to functional groups like motors, toolchanger, pallett changer,... And makes finding signals easy... 02
https://github.com/LinuxCNC/linuxcnc/pull/93#issuecomment-233609440
[07:40:05] <skunkworks> zlog
[08:53:41] <skunkworks> wow - I have never seen this page..
[08:53:42] <skunkworks> http://www.linuxcnc.org/docs/html/drivers/hostmot2.html
[08:53:44] <skunkworks> pretty cool
[08:54:02] <skunkworks> The tables of firmware sure will come in handy
[09:29:53] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #93: @ikcalB you're working on master, right? No need for this in 2.6 or 2.7? 02
https://github.com/LinuxCNC/linuxcnc/pull/93#issuecomment-233642516
[09:30:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #91: Let's put it in master, we can backport it if someone needs it in a stable branch. 02
https://github.com/LinuxCNC/linuxcnc/pull/91#issuecomment-233642760
[09:37:33] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15ikcalB commented on issue #91: Agreed. Closing this for now 02
https://github.com/LinuxCNC/linuxcnc/pull/91#issuecomment-233644758
[10:09:51] <KGB-linuxcnc> 03Jeff Epler 05master f7d6c47 06linuxcnc 10tcl/twopass.tcl Merge remote-tracking branch 'origin/jepler/master/ickalb-tp-personalities' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f7d6c47
[10:09:53] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #91: No need to create a fresh PR, I merged this one to our master branch. Thanks! 02
https://github.com/LinuxCNC/linuxcnc/pull/91#issuecomment-233654773
[10:12:11] <KGB-linuxcnc> 03Jeff Epler 05master 04c2bd4 06linuxcnc 10tcl/bin/halshow.tcl Merge remote-tracking branch 'gh-ickalb/2.6-halshow_signals' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=04c2bd4
[10:12:11] <KGB-linuxcnc> 03Jeff Epler 05master 8813045 06linuxcnc 10tcl/bin/halshow.tcl Remove unused proc makeNodeSig * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8813045
[10:12:55] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #93: I merged this, but to master branch only. Thanks! 02
https://github.com/LinuxCNC/linuxcnc/pull/93#issuecomment-233655813
[10:13:30] <jepler> hah all 4 open PRs are from me now
[10:13:49] <jepler> waaahhh nobody likes my PRs ;)
[10:15:42] <skunkworks> doesnt rob have one too?
[10:16:25] <jepler> not that I see
[10:17:04] <skunkworks> oh - it isn't a pull request..
[10:17:11] <skunkworks> https://github.com/robEllenberg/linuxcnc-mirror/commit/0ea768e0ae9424c3e299d2a50353c145b29bae37
[10:17:45] <skunkworks> https://github.com/LinuxCNC/linuxcnc/issues/68
[10:24:08] <seb_kuzminsky> JT-Shop: i can't repro the problem you reported with 2.7.5, i'm going to need your help
[10:24:39] <seb_kuzminsky> can you try to pare down your config until it's something that can run in sim, testing as you go to make sure you still see the problem?
[10:24:52] <skunkworks> https://www.youtube.com/watch?v=piXI3bjmcow
[10:26:34] <seb_kuzminsky> skunkworks: neat!
[10:29:32] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15ikcalB commented on issue #93: @SebKuzminsky my ex-company is on stables only, so 2.7.x was fine. They're able to deal with that manually though.... 02
https://github.com/LinuxCNC/linuxcnc/pull/93#issuecomment-233661240
[10:32:40] <cradek> I guess my comment doesn't generate an email:
https://github.com/robEllenberg/linuxcnc-mirror/commit/0ea768e0ae9424c3e299d2a50353c145b29bae37
[10:53:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 0845711 06linuxcnc 10src/emc/task/emctaskmain.cc 10src/emc/task/task.hh Task: make the all_homed() helper function available * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0845711
[10:53:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 2f6ad07 06linuxcnc 10src/emc/task/emctask.cc Task: make Manual mode use Teleop whenever possible * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f6ad07
[11:08:28] <skunkworks> cradek, so the g76 must do a spindle synced motion for the entry taper?
[11:08:54] <cradek> yes both tapers stay synced
[11:15:59] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek commented on issue #68: I think it would probably be good in 2.7 to have a 2.6-style blend at the end of a spindle-sync move, only because that sounds simple and easy to get right in the stable branch, and it's known to give good results for thread pullouts. Not stopping at the end of the synced move is important, as I tried to explain [here](
https://github.com/robEllenberg/linuxcnc-mirror/commit/0ea768e0ae9424c3e
[11:20:35] <cradek> hepme github: how do I comment on someone's branch?
[11:20:49] <seb_kuzminsky> i dont think you can
[11:20:58] <seb_kuzminsky> you can comment on a commit, pr, and issue
[11:21:08] <seb_kuzminsky> oh, and on a line in a diff
[11:21:39] <cradek> thanks
[11:22:20] <seb_kuzminsky> github has been very helpful in attracting developers/contributors, some casual and some fairly serious
[11:22:53] <cradek> yes I think that's true
[11:22:57] <jepler> I wonder why it's different now vs when I first put linuxcnc-mirror on github
[11:24:01] <cradek> I'm glad you guys are comfortable with it and are making it work
[11:39:58] <jepler> cradek: sounds like yo're feeling less comfortable with it, and that's too bad.
[11:40:08] <jepler> +u
[11:41:32] <cradek> it never seems to work how I expect/want, but I don't want to dwell on my feelings when using the it clearly is good for results in our project
[11:41:39] <cradek> using it
[11:42:59] <cradek> I'll just keep slowly learning it
[11:43:41] <jepler> there are sure things about it that remain irritations
[11:44:04] <jepler> but even if it doesn't 100% match the git workflow I would like to see, PRs are still great
[11:44:24] <seb_kuzminsky> it's like any other giant web app (or app of any kind): full of idiosynchracies and hidden assumptions
[11:45:05] <seb_kuzminsky> i'm of two minds about PRs: it's great that it's easy for folks to send us PRs and for everyone to discuss them, but it's a bit of a hassle to run them through the buildbot
[11:45:53] <seb_kuzminsky> i guess it's good that us core devs with push-rights to glo get to vet stuff before it goes to the buildbot, since some of our build runs as root
[11:47:58] <mozmck> PR's are also more of a pain than emailing a patch IMO - I guess unless you are using github all the way.
[11:49:02] <cradek> from where I'm sitting, I agree, but I don't think that's a reason to not use github
[11:49:13] <cradek> bringing in new people and having them be comfortable is more important
[11:49:26] <mozmck> no, it looks handy, and seems like it works pretty well having both.
[11:49:31] <seb_kuzminsky> github doesn't break email ;-)
[12:02:16] <seb_kuzminsky> jesus why does task implement abort in like 4 separate places
[12:09:33] <mozmck> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/151064
[12:10:39] <mozmck> Is what he says even true? I've used the parallel port for my router for years and that's the first I've heard of that pin.
[12:12:04] <cradek> I understand the g540 has weird charge pump issues, and he's maybe misremembering (or he misunderstood?) the problem and the advice
[12:12:31] <seb_kuzminsky> > guess linux cnc is ok if you are really nerdy
[12:12:48] <seb_kuzminsky> if being nerdy is wrong, i don't want to be right
[12:12:50] <cradek> "a pin checking for a printer" is not a thing
[12:13:16] <mozmck> good.
[12:13:28] <mozmck> I hadn't heard of that but thought I'd ask.
[12:13:47] <seb_kuzminsky> a machine at the local hackspace runs fine on a gecko G540
[12:13:59] <seb_kuzminsky> but we're running mach3 on that one
[12:14:01] <seb_kuzminsky> JUST KIDDING
[12:14:05] <mozmck> :-D
[12:24:35] <jepler> this is the years-old forum thread fwiw
https://forum.linuxcnc.org/forum/9-installing-linuxcnc/19622-mach3-works-with-my-g540-cp-but-unbuntu-doesn-t
[12:24:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/abort-debug 5c4caa1 06linuxcnc 10src/emc/task/emctask.cc 10src/emc/task/emctaskmain.cc Task: debugging for JT's softlimit crash * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c4caa1
[12:25:02] <seb_kuzminsky> JT-Shop: could you try that branch and paste the output again?
[12:27:35] <JT-Shop> let me get the mill up and going and I'll try it
[12:27:40] <seb_kuzminsky> thanks
[12:28:05] <cradek> jepler: thanks
[12:28:40] <cradek> jepler: not seeing the "they refused my one-line fix" part
[12:29:36] <cradek> I wonder if a more recent version that cooperates with the kernel parport stuff better would work for him
[12:29:37] <jepler> no I don't see any post from him with a one-line fix either
[12:29:51] <cradek> maybe there were other threads elsewhere
[12:29:59] <jepler> didn't find any here
https://forum.linuxcnc.org/forum/search?searchuser=dmauch&searchdate=all&childforums=1
[12:30:04] <JT-Shop> seb_kuzminsky: the plasma is still running Ubuntu 10.04 and I can't get git or anything else anymore :(
[12:32:06] <skunkworks> The issue as I remember it is for some reason - even though the bios is set to EPP - linux seems to switch to something other than EPP.
[12:32:14] <jepler> http://www.geckodrive.com/g540-initial-setup-guide sure claims that the port must be in EPP mode
[12:32:41] <cradek> jepler: this reminds me of "entering the museum of everything I've ever done wrong", how a friend of ours describes a stage in agruments he sometimes has
[12:32:41] <skunkworks> And EPP is required for the charge pump to work because the 540 requires TTL push pull
[12:33:02] <skunkworks> (higher current)
[12:34:52] <skunkworks> My thought is to add whatever magic is in the hm2 7i43 that tries to force the printer port to EPP
[12:35:24] <cradek> that sounds useful
[12:35:35] <cradek> I was just looking to see whether hal_parport already has that (it doesn't)
[12:35:52] <seb_kuzminsky> JT-Shop: try this apt source: deb
http://old-releases.ubuntu.com/ubuntu/ lucid main restricted
[12:36:01] <seb_kuzminsky> or just wait for the buildbot to make a scratch deb
[12:37:30] <cradek> I suspect uninstalling cups would have fixed the problem too, whatever it was doing
[12:42:34] <jepler> reading the kernel source, it looks like any open of /dev/lp* may be setting the mode of the underlying parallel port
[12:42:37] <jepler> /* Leave peripheral in compatibility mode */
[12:42:39] <jepler> afk
[12:42:42] <jepler> parport_negotiate (lp_table[minor].dev->port, IEEE1284_MODE_COMPAT);
[12:52:56] <kwallace> My unreasonable rant on the G540/LinuxCNC issues with Mach groupies. Long maybe fix = totally avoid learning how the parallel port and G540 works, avoid following and discredit any advise, swap parts willy nilly and hope for the best, and blame someone else when it doesn't work. Short fix for almost all configurations = add a buffered BOB, done.
[12:56:39] <archivist> I have seen insufficient drive from crappy BOBs too
[12:57:20] <archivist> but a real scope and diagnosis is beyond many
[13:04:48] <cradek> kwallace: you sound more ... experienced with this problem
[13:05:58] <pcw_home> Actual rather stupid to use active high drive from a parallel port for OPTOs
[13:06:09] <pcw_home> actually
[13:06:31] <cradek> it sure smells like a flaw in the g540 from here
[13:06:40] <cradek> but I understand that saying that makes people mad
[13:09:54] <pcw_home> I'd just use a Ethernet transformer (~$0.30) for parallel side isolated 5V power
[13:09:56] <pcw_home> complete with common mode choke and then use a buffer chip on the PP side
[13:11:31] <kwallace> here are some of my notes:
http://www.wallacecompany.com/machine_shop/G540/
[13:13:49] <cradek> ooh data
[13:14:45] <kwallace> I think the problem with the G540 charge pump is that they are using a pin that typically only sinks and they want to pump a capacitor through long wire and no buffer or power source.
[13:14:52] <kwallace> http://www.wallacecompany.com/machine_shop/G540/G540_upper_bottom_z-1b.png
[13:15:39] <cradek> so just adding a pullup fixes it?
[13:15:55] <kwallace> In my view, yes.
[13:15:58] <pcw_home> yeah pin 6 is open collector in SPP mode
[13:16:03] <pcw_home> pin 16
[13:16:10] <cradek> easy for us, scary and ridiculous for most
[13:16:33] <pcw_home> (with a weak pullup maybe 4.7 or 3.3K)
[13:16:36] <skunkworks> but - if there was a way to force the printer port back into EPP - problem sovled too..
[13:17:08] <cradek> if your port can do that, yes
[13:17:12] <skunkworks> many have said - worked fine in windows - didn't work in linux. (chargepump) same computer hardware
[13:17:51] <pcw_home> can windows set the port mode?
[13:19:29] <skunkworks> don't know.
[13:19:48] <skunkworks> it might just not change it.
[13:20:43] <archivist> probably jumps into epp mode for windows type printers these days
[13:20:55] <pcw_home> if the linux pp driver changes the setting shouldn't it know how to change it to EPP?
[13:20:56] <pcw_home>
[13:22:02] <cradek> it looks like you add PARPORT_MODE_EPP to hal_parport_get()'s modes argument
[13:22:24] <cradek> we currently have i(n), o(ut), and x
[13:22:37] <cradek> we could have a mode that's just like out except it adds that request for EPP
[13:22:59] <cradek> but I don't know if that *sets* it, or just asks for a port capable of it
[13:23:16] <kwallace> One can choose 1) add a pull up or BOB following simple instructions or 2) beat up on developers until LinuxCNC works just like Mach.
[13:23:38] <cradek> ... just requests
[13:24:19] <cradek> does anyone here have hardware that has this problem?
[13:24:52] <pcw_home> nothing recent on the forum that I recall
[13:25:09] <cradek> maybe newer G540s are fixed
[13:25:27] <cradek> kwallace: do you still have the problematic combination of hardware?
[13:25:34] <pcw_home> at least its not as bad as Tormachs issue with the MX3660
[13:27:41] <skunkworks> spindle turning on?
[13:27:50] <cradek> ?
[13:29:13] <kwallace> I have a G540 and the hardware used with my making my notes, so I guess yes.
[13:29:33] <pcw_home> AFAICT the MX3660s charge pump circuit only gates the step/dir signals, not the spindle enable or analog
[13:29:54] <pcw_home> a rather major oversight
[13:31:19] <kwallace> I haven't be involved with the spindle issue so I can't comment.
[13:32:27] <kwallace> been
[13:45:39] <jepler> cradek: in kernel realtime, hal_parport_get only uses the modes argument to warn that the parport doesn't support the mode
[13:45:56] <cradek> I think that's ok
[13:46:14] <jepler> uspace too
[13:46:24] <jepler> so no, sending the EPP flag in, whatever it's called, won't actually change anything
[13:46:44] <cradek> right, but I'm also poking the ECR
[13:47:01] <jepler> with rtapi_parport_ecr_write ?
[13:47:05] <KGB-linuxcnc> 03Chris Radek 05epp-parport-g540 c3b03d5 06linuxcnc 10src/hal/drivers/hal_parport.c Let the user request output mode with EPP to fix G540 charge pump * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3b03d5
[13:47:06] <jepler> or directly?
[13:47:29] <cradek> the same way the 7i43 driver did it :-/
[13:48:04] <jepler> that's probably fine
[13:48:23] <jepler> until somebody decides to put a memory-mapped PC parport in an ARM board :-P
[13:48:49] <cradek> kwallace: it would be cool if you could test this, or if not, we'll just wait for the next person to complain about their G540 and make them do it
[13:49:41] <cradek> kwallace: I fully realize it'll take more time to test than it did to write :-)
[13:54:53] <kwallace> I don't mind giving it a try, but I have been pretty bad at getting round to it these days. I still need to attend to the tapered thread issue that Gene was interested in.
[14:02:10] <cradek> seb_kuzminsky: rip-lucid-rtai builder is offline: waiting 31 hrs, 2 mins, 54 secs
[14:02:44] <cradek> ETA -108159 secs
[14:02:45] <cradek> haha
[14:02:56] <cradek> ... and it doesn't handle that very smoothly
[14:19:22] <jepler> IEEE 1284-2000 gives requirements for "level 1" and "level 2" receivers (8.3.2.2 and 8.3.3.2)
[14:19:25] <jepler> Level 1: "The receiver high-level input threshold shall not exceed 2.0 V." and "
[14:19:28] <jepler> The receiver high-level input sink current shall not exceed 0.32 mA at 2.0 V."
[14:19:31] <jepler> Level 2: "The receiver high-level input threshold shall not exceed 2.0 V." and "The receiver high-level input sink current shall not exceed 20μA at 2.0 V."
[14:19:34] <jepler> http://kazus.ru/nuke/modules/Downloads/pub/148/0/IEEE%201284-2000.pdf (or pay your friendly standards body for a copy)
[14:19:37] <jepler> Geckodrive specifies "Signal Voltage" minimum 3.3 VDC, maximum 5VDC
[14:19:40] <jepler> http://www.geckodrive.com/images/cms_files/images/G540%20REV8%20Manual.pdf
[14:22:47] <kwallace> Just in case anyone is interested in the MX3660 spindle issue:
http://www.tormach.com/uploads/1039/SB0051_PCNC440_SpindleAcceleration_0716B_WEB-pdf.html
[14:23:55] <mozmck> jepler: I don't believe "Signal Voltage is the same as "input threshold"
[14:24:14] <jepler> mozmck: no but it's the only value I have seen specified in the gecko datasheet
[14:24:36] <mozmck> Yeah
[14:26:52] <kwallace> I think the standard indicates that a high needs to trigger on 2 Volts.
[14:27:21] <kwallace> 3 Volts isn't good enough.
[14:28:45] <mozmck> I think it is 2 volts or lower. Which means that the receiver can't have a high threshold of 3 volts because the port may not supply that high a voltage.
[14:29:18] <jepler> IEEE 1284-2000 again: Level 1 driver requirements: The high-level output voltage shall be at least 2.4 V at a source current of 0.32 mA"
[14:29:20] <cradek> so they combined linuxcnc and dropbox
[14:29:59] <cradek> oh good, tormach is replacing the defective hardware. that's the right response.
[15:10:22] <seb_kuzminsky> cradek: thanks, i'll poke it
[15:11:54] <seb_kuzminsky> it was totally wedged and unresponsive
[15:12:30] <seb_kuzminsky> all better now
[15:15:16] <cradek> haha 9 builds to do
[15:15:39] <cradek> thanks for fixing it
[15:17:28] <JT-Shop> seb_kuzminsky: I've been unable to make any progress on testing your patch... 404 not found for the most part
[15:20:01] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc opened issue #114: TLO affects live plot in Axis 02
https://github.com/LinuxCNC/linuxcnc/issues/114
[15:54:46] <PCW_> does this ring a bell:
[15:54:48] <PCW_> ImportError: No module named numarray
[15:55:16] <seb_kuzminsky> PCW_: apt-get install python-numpy
[15:55:18] <cradek> yes in modern times it's called numpy
[15:55:34] <cradek> maybe your python is oooold and it needs a minor massage
[15:55:43] <PCW_> 2.7.12
[15:55:52] <cradek> or is there a compat layer?
[15:56:00] <cradek> no I mean the python program you're running
[15:56:34] <seb_kuzminsky> try this: >>> import numpy.numarray as numarray
[15:56:43] <jepler> very long ago image2gcode used numarray, but in 2010 we changed it (with backwards compatibility to numarray)
[15:56:46] <jepler> https://github.com/LinuxCNC/linuxcnc/commit/f787468983e507f2d5ed5680c5833ee1d529fa6b
[15:57:08] <jepler> of course in this case if you have neither, you'd get an error about numarray and not about numpy,
[16:00:37] <PCW_> Hmm.. I still get the error after installing python-numpy
[16:01:33] <cradek> what are you trying to run?
[16:02:23] <PCW_> image2gcode
[16:02:43] <cradek> the one that's part of linuxcnc?
[16:02:51] <PCW_> yes
[16:03:02] <cradek> on what platform?
[16:03:16] <PCW_> Mint 18
[16:04:46] <jepler> at the Python prompt, try importing the preferred modules:
[16:04:50] <jepler> >>> import numpy.numarray as numarray
[16:04:51] <jepler> >>> import numpy.core
[16:05:24] <cradek> fwiw, wfm on wheezy
[16:05:42] <seb_kuzminsky> wfm on jessie
[16:05:54] <jepler> if you look at that commit above, I think the real probablem is probably occuring in the 'try' part of the block
[16:06:05] <jepler> but you never see that error; it drops into the except part, where it tries to 'import numarray'
[16:06:20] <jepler> .. but to nobody's surprise, since it went out of style circa 2010, that gives an import error too.
[16:06:26] <jepler> PCW_: ^^
[16:11:16] <PCW_> I get no module named numarray
[16:11:44] <PCW_> import numpy.core works
[16:12:06] <seb_kuzminsky> which version of python-numpy do you have?
[16:12:20] <seb_kuzminsky> dpkg -s python-numpy | grep Version
[16:13:31] <seb_kuzminsky> python-numpy 1.11 (in debian stretch) doesn't have numpy.numarray
[16:14:38] <PCW_> yeah its 1.11
[16:14:42] <seb_kuzminsky> http://docs.scipy.org/doc/numpy/reference/routines.numarray.html
[16:15:03] <jepler> hm their package may just be busted :(
[16:15:17] <jepler> starting with a fresh 16.04 amd64 image from digitalocean
[16:15:22] <jepler> root@stench:~# apt-get install python-numpy
[16:15:31] <jepler> >>> import numpy.numarray
[16:15:32] <jepler> Traceback (most recent call last):
[16:15:32] <jepler> File "<stdin>", line 1, in <module>
[16:15:32] <jepler> ImportError: No module named numarray
[16:16:03] <seb_kuzminsky> jepler: the numpy folks removed numarray in 1.9
[16:16:09] <jepler> ah idiots
[16:16:17] <jepler> what use is an API if it won't be around for a thousand years
[16:17:12] <PCW_> What harm was it causing?
[16:17:27] <jepler> you'd have to talk to them
[16:17:56] <seb_kuzminsky> at a guess: extra effort to maintain backwards compatibility, and reduced mobility forward
[16:18:20] <jepler> I know it happens in all languages now, but this happens frequently enough in Python that I'm souring on it
[16:18:24] <linuxcnc-build> build #515 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/515 blamelist: Norbert Schechner <nieson@web.de>
[16:18:32] <PCW_> anyway no big deal just wanted to make a complex gcode file to run for a long time, i'll do it on another machine
[16:19:28] <PCW_> looks like maybe the stability problem on the Gigabyte BRIX is fixed
[16:20:50] <PCW_> or worked-around anyway
[16:21:02] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened issue #115: image2gcode: incompatible with numpy >= 1.9 02
https://github.com/LinuxCNC/linuxcnc/issues/115
[16:25:03] <PCW_> So if you have a GB-BXBT-1900, set intel_idle.max_cstate=1 in the kernel command line
[16:25:04] <PCW_> (if you dont like crashes every 1/2 hour or so)
[16:45:01] <linuxcnc-build> build #1004 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/1004 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle
[16:45:01] <linuxcnc-build> <flo.kerle@gmx.at>
[16:45:36] <linuxcnc-build> build #1002 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/1002 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle
[16:45:36] <linuxcnc-build> <flo.kerle@gmx.at>
[16:47:38] <linuxcnc-build> build #2733 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2733 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle
[16:47:38] <linuxcnc-build> <flo.kerle@gmx.at>
[16:59:44] <jepler> Issuing EMC_JOINT_HOME -- ( +123,+24, +3, +0,)
[16:59:45] <jepler> must be in joint mode to home
[16:59:58] <jepler> 5.682: failed to home joint-0 in halui
[17:00:20] <jepler> hm that's new
[17:02:36] <linuxcnc-build> build #2534 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2534 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:06:02] <linuxcnc-build> build #2568 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2568 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:06:33] <linuxcnc-build> build #2045 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/2045 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle
[17:06:33] <linuxcnc-build> <flo.kerle@gmx.at>
[17:09:38] <linuxcnc-build> build #2534 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2534 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:16:19] <linuxcnc-build> build #1002 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/1002 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:16:53] <seb_kuzminsky> grumble
[17:17:18] <jepler> I'll bisect it..
[17:18:54] <seb_kuzminsky> no, it's my bug again
[17:19:09] <jepler> oh. I won't bisect it then
[17:19:36] <seb_kuzminsky> i changed task this morning so that when a UI asks for Manual mode, it sometimes puts Motion in Free mode and sometimes in Teleop
[17:19:50] <seb_kuzminsky> halui/jogging homes, then goes to Manual (putting Motion in Free), then tries to joint-jog
[17:19:59] <linuxcnc-build> build #1002 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/1002 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:20:43] <seb_kuzminsky> err, actually that looks different
[17:21:18] <linuxcnc-build> build #4375 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4375 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:21:55] <jepler> for the tests/lathe failure, bisect says it is
[17:21:55] <jepler> 2f6ad078d47d37cc0bb8ed3c79b275086f08e4d1 is the first bad commit
[17:22:01] <jepler> Task: make Manual mode use Teleop whenever possible
[17:22:32] <seb_kuzminsky> right, that's the one i suspected, but i dont see a task mode switch before the error
[17:22:33] <jepler> $ git bisect run sh -c 'make -C src -j9 || exit 125; ./scripts/runtests tests/lathe'
[17:23:53] <linuxcnc-build> build #3584 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3584 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:24:09] <linuxcnc-build> build #2200 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/2200 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:24:32] <seb_kuzminsky> maybe i should have run the test before pushing that one...
[17:25:36] <linuxcnc-build> build #4373 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4373 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:25:36] <linuxcnc-build> build #4388 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4388 blamelist: Jeff Epler <jepler@unpythonic.net>, Matsche <tinker@play-pla.net>, Sebastian Kuzminsky <seb@highlab.com>, Florian Kerle <flo.kerle@gmx.at>
[17:26:33] <jepler> > He has written several books and his articles now infect the internet
[17:33:55] <seb_kuzminsky> so that commit makes it so task mode manual means motion mode teleop, always, on id-kins machines
[17:34:25] <seb_kuzminsky> which makes homing fail, unless you explicitly switch motion to free
[17:36:12] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/image2gcode-numpy 3d2aec7 06linuxcnc 10src/emc/usr_intf/axis/scripts/image-to-gcode.py image-to-gcode: compensate for incompatible changes in numpy * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3d2aec7
[17:36:18] <jepler> that was easier than I had feared
[17:37:00] <jepler> seb_kuzminsky: dunno what your philosophy is on fixing this in released versions. but it seems like we'd like our current stable version to run on current distros
[17:37:54] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master e376968 06linuxcnc 10src/emc/task/emctask.cc Task: be slightly less aggressive about switching to Teleop * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e376968
[17:38:28] <seb_kuzminsky> i've lost all confidence in my ability to tell improvements and bugfixes from disastrous charlie foxtrots
[17:39:24] <jepler> I hear ya
[17:41:58] <seb_kuzminsky> your branch looks like a good tech-debt-class fix
[17:42:09] <seb_kuzminsky> does it work on whatever the oldest 2.7 distro is?
[17:42:53] <seb_kuzminsky> which is lucid
[17:43:13] <jepler> it .. should
[17:44:03] <seb_kuzminsky> well, go for it then, i say
[17:44:19] <jepler> hah
[17:44:28] <jepler> too bad it can't be run without a UI
[17:44:42] <jepler> -> no real way to test it
[17:54:24] <JT-Shop> seb_kuzminsky: I get the same 404 not found on the BP mill too so it's not something I've done lately... I guess Ubuntu is worse than windoze in that respect at least my XP runs merrily along without complaint
[17:55:57] <seb_kuzminsky> JT-Shop: you get 404 when you run "apt-get update"?
[17:56:24] <JT-Shop> yes
[17:56:47] <seb_kuzminsky> paste the output?
[17:56:51] <JT-Shop> I just got a prompt from the update manager saying it is not supported and I had to force it closed lol
[17:57:00] <seb_kuzminsky> i'll show you mine if you show me yours:
http://paste.debian.net/783328/
[17:57:01] <JT-Shop> one moment
[18:01:52] <JT-Shop> http://paste.ubuntu.com/20101901/
[18:02:21] <JT-Shop> and
http://paste.ubuntu.com/20101951/
[18:05:22] <seb_kuzminsky> all the us.archive.ubuntu.com lines need to go
[18:05:49] <seb_kuzminsky> old-releases.ubuntu.com has those packages now
[18:06:03] <seb_kuzminsky> try commenting out the us.archive lines
[18:19:17] <JT-Shop> ok
[18:25:32] <JT-Shop> thanks that fixed 3 machines lol
[18:25:47] <JT-Shop> now back to the test
[18:28:01] <JT-Shop> I need to stop leaking first...
[18:32:38] <JT-Shop> just checked my usage and I better wait till morning to do the git clone
[18:49:04] <seb_kuzminsky> :-)
[19:32:56] <jepler> this channel is too narrow to contain a full explanation, but when it comes to making a fresh copy of the whole linuxcnc source without using much bandwidth, there are a lot of options even with old git versions
[19:33:34] <jepler> one of the simplest ways is: just copy the whole directory tree, then "git clean -d -x -f" in the copy. now everything is new again. You'll need to pull to get new commits, of course.
[19:35:01] <jepler> you can also operate a single "bare clone" (git clone --bare or git clone --mirror) and then create other clones with "git clone --reference". By always updating in the bare clone first, you reduce the bandwidth for pulls in the other copies that reference it to nearly nothing (but not quite nothing)
[19:35:28] <jepler> if you had a modern git version, you could use "git worktrees", but this requires a newer-than-jessie version of git so it's far from an option for you.
[19:37:12] <jepler> (and I've had some trouble with git worktrees becoming confused so I can't recommend it whole heartedly)
[19:50:00] <jepler> wow, stupid github doesn't show commits in (topological) order
https://github.com/LinuxCNC/linuxcnc/pull/110
[19:50:15] <jepler> I was very puzzled because I was looking at the list of commits vs what I have locally
[19:50:29] <jepler> the first commit since master, in git order, is
[19:50:29] <jepler> 8f2ff2d build: include a copy of boost lockfree for heritage platforms
[19:50:34] <jepler> and the last is a63d5f8 docs: document new RTOS support
[19:50:46] <jepler> so I was very puzzled that neither of those commits is "top" or "bottom" in github's list
[19:51:22] <jepler> but that a6... commit is in the list, so it's the right stuff
[19:51:25] <jepler> just in the wrong order
[19:52:16] <jepler> https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/
[19:57:23] <jepler> https://github.com/isaacs/github/issues/386
[19:57:39] <jepler> I just got a little sadder about github today
[19:59:21] <mozmck> heh, great response over on the mach list skunkworks_!
[20:11:13] <skunkworks_> ;)
[20:51:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 7f8f309 06linuxcnc 10src/hal/utils/halcompile.g halcompile: support r-strings * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f8f309
[20:51:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc c98d7e7 06linuxcnc 10src/hal/components/or2.comp or2: demonstrate a use of r-string documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c98d7e7
[20:51:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc c8e9a94 06linuxcnc 10docs/src/Submakefile build: "make man-html" builds all HTML files that derive from manpages * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c8e9a94
[20:51:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 898fbb4 06linuxcnc 10docs/src/Submakefile build: a few more "grep -q" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=898fbb4
[20:51:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 3a6fbb7 06linuxcnc 10src/hal/utils/halcompile.g halcompile: Allow documentation to be written in asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3a6fbb7
[20:51:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc fbd6f53 06linuxcnc 10debian/control.in packaging: asciidoc is now required for running halcompile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fbd6f53
[20:51:35] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 9a90992 06linuxcnc 10src/hal/components/and2.comp and2: convert a bit of documentation to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9a90992
[20:51:39] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 62ffec0 06linuxcnc 10docs/src/Submakefile 10src/hal/components/Submakefile docs: build html manpages using halcompile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62ffec0
[20:51:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 559a15b 06linuxcnc 10src/hal/utils/halcompile.g halcompile: Allow synopsis to be fully replaced (asciidoc only) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=559a15b
[20:51:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 91c679f 06linuxcnc 10(8 files) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=91c679f
[20:51:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 0eed3ff 06linuxcnc 10(31 files) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0eed3ff
[21:21:27] <linuxcnc-build> build #2537 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2537 blamelist: Chris Radek <chris@timeguy.com>
[21:27:52] <linuxcnc-build> build #1005 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/1005 blamelist: Chris Radek <chris@timeguy.com>
[21:43:14] <linuxcnc-build> build #2736 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2736 blamelist: Chris Radek <chris@timeguy.com>
[21:43:51] <linuxcnc-build> build #4376 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4376 blamelist: Chris Radek <chris@timeguy.com>
[21:46:46] <linuxcnc-build> build #4378 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4378 blamelist: Chris Radek <chris@timeguy.com>
[21:49:44] <linuxcnc-build> build #3587 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3587 blamelist: Chris Radek <chris@timeguy.com>
[21:52:09] <linuxcnc-build> build #2571 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2571 blamelist: Chris Radek <chris@timeguy.com>
[21:52:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 44a0c41 06linuxcnc 10src/hal/utils/halcompile.g halcompile: Allow documentation to be written in asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=44a0c41
[21:52:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 4786f13 06linuxcnc 10debian/control.in packaging: asciidoc is now required for running halcompile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4786f13
[21:52:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 31b8527 06linuxcnc 10src/hal/components/and2.comp and2: convert a bit of documentation to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=31b8527
[21:52:23] <linuxcnc-build> build #2048 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/2048 blamelist: Chris Radek <chris@timeguy.com>
[21:52:25] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc e143cb1 06linuxcnc 10docs/src/Submakefile 10src/hal/components/Submakefile docs: build html manpages using halcompile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e143cb1
[21:52:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 6e651cb 06linuxcnc 10src/hal/utils/halcompile.g halcompile: Allow synopsis to be fully replaced (asciidoc only) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6e651cb
[21:52:33] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc dea9ec6 06linuxcnc 10(8 files) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dea9ec6
[21:52:37] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc d7f4055 06linuxcnc 10(31 files) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d7f4055
[21:52:41] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc eb226d8 06linuxcnc 10(48 files) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eb226d8
[22:01:32] <linuxcnc-build> build #1005 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/1005 blamelist: Chris Radek <chris@timeguy.com>
[22:03:52] <linuxcnc-build> build #2203 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/2203 blamelist: Chris Radek <chris@timeguy.com>
[22:09:11] <linuxcnc-build> build #2537 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2537 blamelist: Chris Radek <chris@timeguy.com>
[22:11:09] <linuxcnc-build> build #1005 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/1005 blamelist: Chris Radek <chris@timeguy.com>
[22:11:12] <linuxcnc-build> build #1007 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/1007 blamelist: Chris Radek <chris@timeguy.com>
[22:11:12] <linuxcnc-build> build #4391 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4391 blamelist: Chris Radek <chris@timeguy.com>
[22:25:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 68e909a 06linuxcnc 10src/hal/utils/halcompile.g halcompile: Allow documentation to be written in asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=68e909a
[22:25:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc eea90a9 06linuxcnc 10debian/control.in packaging: asciidoc is now required for running halcompile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eea90a9
[22:25:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 446eabc 06linuxcnc 10src/hal/components/and2.comp and2: convert a bit of documentation to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=446eabc
[22:25:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 60b0040 06linuxcnc 10docs/src/Submakefile 10src/hal/components/Submakefile docs: build html manpages using halcompile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=60b0040
[22:25:49] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 0cc1bc5 06linuxcnc 10src/hal/utils/halcompile.g halcompile: Allow synopsis to be fully replaced (asciidoc only) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0cc1bc5
[22:25:53] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 6ecd9fe 06linuxcnc 10(8 files) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ecd9fe
[22:25:57] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc d5333c9 06linuxcnc 10(31 files) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d5333c9
[22:26:01] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 5bea97d 06linuxcnc 10(48 files) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5bea97d
[22:26:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 7f098a2 06linuxcnc 10src/hal/utils/halcompile.g halcompile: userspace components must go in section 1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f098a2
[22:26:09] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/comp-asciidoc 9c918b9 06linuxcnc 10(8 files in 3 dirs) docs: convert additional components to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9c918b9
[22:31:32] <cradek> issue 114: it seems to me the program should move up like that...? depends what's in it I suppose. assuming no g43/g10 stuff, and regular old g90 g0/1/2/3 moves
[22:42:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master a46b18f 06linuxcnc 03src/hal/components/differential.comp add a differential kinematics comp * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a46b18f
[22:42:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master b8e3e85 06linuxcnc 10debian/control.in 10src/Makefile 10src/hal/user_comps/Submakefile 03src/hal/user_comps/scorbot-er-3.py add a non-realtime driver for the scorbot-er-3 robot arm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8e3e85
[22:42:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 8fabd50 06linuxcnc 10src/Makefile 03src/emc/kinematics/scorbot-kins.c kins: add scorbot-kins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8fabd50
[22:42:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 58d258f 06linuxcnc 10(5 files) add a sample config for the scorbot-er-3 robot arm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58d258f
[22:42:38] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master befb904 06linuxcnc 10configs/by_machine/scorbot-er-3/scorbot-er-3.ini 03configs/by_machine/scorbot-er-3/shuttlexpress-customization.hal scorbot config: add support for ShuttleXpress USB jog pendant * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=befb904
[22:44:15] <KGB-linuxcnc> 05scorbot-er-3 bc9e113 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc9e113
[22:45:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 05scorbot-er-3-hm2 bc9e113 06linuxcnc 03configs/by_machine/scorbot-er-3/pyvcp-hm2.hal 03configs/by_machine/scorbot-er-3/scorbot-er-3-hm2.hal 03configs/by_machine/scorbot-er-3/scorbot-er-3-hm2.ini start adding configs for an hm2-base scorbot controller * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc9e113
[22:47:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05scorbot-er-3-hm2 bc9e113 06linuxcnc 03configs/by_machine/scorbot-er-3/pyvcp-hm2.hal 03configs/by_machine/scorbot-er-3/scorbot-er-3-hm2.hal 03configs/by_machine/scorbot-er-3/scorbot-er-3-hm2.ini start adding configs for an hm2-base scorbot controller * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc9e113
[23:39:12] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15robEllenberg commented on issue #68: @cradek Your explanation makes sense, and my hotfix branch should now be updated to reflect 2.6 behavior.... 02
https://github.com/LinuxCNC/linuxcnc/issues/68#issuecomment-233833729
