Back
[01:11:01] <linuxcnc-build> build #1 of 4017.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-rtai-i386/builds/1
[02:34:03] <seb_kuzminsky> jepler: if you convince scripts/platform-is-supported that rt-preempt is ok in your branch, the buildbot will (maybe) magically just start building it
[02:43:56] <seb_kuzminsky> cradek: linuxcnc debs for wheezy rtai are up on the buildbot
[02:44:34] <seb_kuzminsky> and i changed the deb archive management from my homebrewed monstrosity to apt-ftparchive, and added repo signing
[02:44:53] <seb_kuzminsky> sudo apt-key adv --keyserver hkp://keys.gnupg.net --recv-key E0EE663E
[02:47:09] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 0000.checkin
[02:47:09] <linuxcnc-build> build #2196 forced
[02:47:10] <linuxcnc-build> I'll give a shout when the build finishes
[03:52:13] <linuxcnc-build> Hey! build 0000.checkin #2196 is complete: Success [3build successful]
[03:52:13] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2196
[05:32:15] <jthornton> cradek, got it
[08:38:30] <cradek> seb_kuzminsky: thank you! I'm rebuilding with that added. News in 2h.
[08:38:37] <cradek> ... maybe 3h.
[08:38:48] <cradek> jthornton: thank you
[09:44:43] <cradek> kwallace: have you looked at arcspiral.ngc?
[09:45:15] <cradek> using R format for quarter-circle arcs is a really easy way to do it (you don't have to calculate the centers)
[10:05:02] <kwallace> cradek, thank you for the arcspiral link. So far the quarter-circle arcs seems like the way to go.
[10:17:13] <jepler> anyway, next order of business with rtos-uspace is to get hm2-pci going. I hope to be able to mostly reuse the userspace pci implementation from ubc3, though I'm going to rtapi_-prefix the hell out of it
[10:17:39] <jepler> .. maybe the weekend will provide enough time for me to show positive progress
[10:18:34] <cradek> jepler: sorry for not working on that like I said I would
[10:18:46] <jepler> cradek: I know you've been up to other important stuff, no worries
[10:19:05] <cradek> yes this thing is shiny too
[10:35:38] <mozmck> cradek: what shiny thing are you working on? or can you say?
[10:41:42] <cradek> new live/install image based on debian wheezy+rtai for linuxcnc 2.6
[10:42:48] <cradek> debian uses a hybrid image so it can be written directly to dvd or usb stick, which is really nice
[10:46:19] <mozmck> I see - neat!
[11:41:11] <seb_kuzminsky> jthornton: do you know anything about the issue Marius Liebenberg is having with thcud? he mailed emc-developers about it last night
[11:42:22] <jthornton> I fixed an issue with thc a while back when someone else mentioned it.
[11:44:10] <seb_kuzminsky> in 2.6 or master?
[11:44:42] <seb_kuzminsky> here's the bug he's referencing:
http://sourceforge.net/p/emc/bugs/348/
[11:44:45] <jthornton> 2.5 then that was pushed to 2.6, but I didn't make the exact fix he proposed
[11:44:55] <seb_kuzminsky> not that i look at it, i think you and i talked about it back then
[11:45:00] <seb_kuzminsky> s/not/now/
[11:45:22] <jepler> cradek: for a typical machine that does not print the "Local API disabled by BIOS" line in dmesg, specifying lapic on the kernel commandline looks like it will have no effect
[11:45:26] <jepler> .. so it won't break any working systems
[11:45:28] <jthornton> yes I think so
[11:45:39] <jepler> according to my reading of detect_init_APIC in kernel 3.2
[11:45:52] <cradek> aha, maybe I should always add it, then
[11:48:12] <jepler> also kernel 3.2 deactivates the lapic before trying to reboot or shut down, if it was enabled by the kernel commandline flag
[11:48:27] <jepler> .. which might be the fix for the laptop shutdown problem that one random page referred to
[11:49:16] <cradek> nice
[11:49:17] <jepler> also the #ifdef CONFIG_X86_64 blocks make me thing that anything x86-64 capable has to have lapic enabled by default
[11:51:57] <seb_kuzminsky> jthornton: thcud.comp isn't in 2.5
[11:52:40] <seb_kuzminsky> it's in 2.6 and master, and those branches have the same version, which is just the single commit that originally adds the comp
[11:52:49] <jthornton> no, I fixed thc.comp in 2.5... did I miss thcud?
[11:52:55] <seb_kuzminsky> ah
[11:54:04] <seb_kuzminsky> yes, thc is in 2.5, 2.6, and master, and looks fully merged, including the commit "Component: fix incorrect calculation of velocity tolerance percent"
[11:55:38] <seb_kuzminsky> i think something like that commit needs to be applied to thcud too maybe?
[11:56:15] <jthornton> yes, just looking at it now... and it still has the old broken code
[11:59:22] <KGB-linuxcnc> 03John Thornton 052.6 360dd7f 06linuxcnc 10docs/src/gcode/gcode.txt Docs: 4 dashes before and after denote a code block * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=360dd7f
[11:59:23] <KGB-linuxcnc> 03John Thornton 052.6 602c6de 06linuxcnc 10docs/src/gcode/gcode.txt Docs: fix column alignment * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=602c6de
[11:59:23] <KGB-linuxcnc> 03John Thornton 052.6 2394f70 06linuxcnc 10src/hal/components/thcud.comp Component: fix incorrect calculation of velocity tolerance percent * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2394f70
[12:10:02] <jthornton> there you go seb_kuzminsky
[12:19:19] <seb_kuzminsky> thank you
[12:19:37] <seb_kuzminsky> do you want to respond to marius or do you want me to?
[12:22:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 79fd496 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=79fd496
[14:13:20] <seb_kuzminsky> i wonder if Marius Liebenberg knows he's emailing the dev list, and not me personally?
[14:18:47] <jepler> odd -- this board has an SPI header with no GND signal. I guess you're supposed to pick up GND from the other I/O header an inch away. (4-pin header has /CS, CLK, MISO, MOSI)
[14:19:26] <cradek> can I ask apt why a package got installed? for instance, was it requested specifically vs. sucked in as a dependency, and if so, of what?
[14:19:39] <jepler> cradek: you can apt-get remove the package, and it'll remove anything that depended on it
[14:19:49] <jepler> cradek: if it was installed because it was a "recommends", then you won't learn anything
[14:19:50] <seb_kuzminsky> apt-cache rdepends?
[14:20:45] <cradek> ding ding
[14:21:11] <jepler> internet also suggests aptitude why $package
[14:21:15] <seb_kuzminsky> what did you call me
[14:22:23] <jepler> "aptitude why" knows about recommends, "apt-cache rdepends" seems not to
[14:22:27] <cradek> "Unable to find a reason to install $package"
[14:22:37] <cradek> so it was done on purpose by live-build somehow
[14:22:38] <jepler> cradek: you could say that about so many packages
[14:22:39] <cradek> thanks guys
[14:22:49] <jepler> cradek: same for "aptitude why"?
[14:23:46] <cradek> yes
[14:23:53] <jepler> what package?
[14:24:03] <cradek> linux-image-...-dbg
[14:24:08] <jepler> ah, hm
[14:24:09] <cradek> it's > 1 GB installed (!!!)
[14:24:12] <jepler> wow
[14:24:26] <cradek> it's 10x bigger than the next biggest package (office something something)
[14:24:40] <cradek> so, needless to say, I need to make it not do that
[14:25:28] <jepler> yeah
[14:38:32] <cradek> Note, selecting 'linux-image-3.4-9-rtai-686-pae-dbg' for regex 'linux-image-3.4.9-rtai-686-pae'
[14:38:42] <cradek> it's because I spelled it wrong!
[14:38:42] <jepler> doop doop
[14:38:57] <jepler> I don't spot the spelling error, but ok
[14:40:32] <cradek> .9 vs -9
[14:40:44] <jepler> oh
[14:40:52] <cradek> thanks apt
[14:42:02] <cradek> yep that fixed it
[14:46:52] <seb_kuzminsky> i dont understand why jepler said doop doop, google presents this by way of explanation:
https://www.youtube.com/watch?v=tvLDm8821jQ
[14:47:07] <seb_kuzminsky> (i still dont understand)
[14:48:03] <jepler> well it's no harlan shake
[14:51:01] <seb_kuzminsky> did you mean 'woop woop'?
https://www.youtube.com/watch?v=zUXow3d3-b0
[14:52:43] <jepler> I'd rather watch your doop doop video than your woop woop video
[15:13:20] <cradek> is it wrong that the doop doop video makes me want to get a white tux with tails?
[15:13:46] <cradek> (the woop woop video does not make me want to get an annoying muffler)
[15:15:23] <seb_kuzminsky> there is nothing wrong with cradek in a white tux
[15:17:56] <seb_kuzminsky> i think i'd go for the argyle sweater-vest myself
[15:29:55] <seb_kuzminsky> hi skunkworks, do you have time to test a new rtai kernel? it's for wheezy, and it's in the normal deb archive at linuxcnc.org
[15:30:30] <seb_kuzminsky> i'm mostly wondering if it boots & gets decent latency numbers on a wide range of hardware
[15:31:00] <cradek> it'd be great if you had a machine that formerly required adding lapic to the kernel commandline
[15:41:47] <seb_kuzminsky> and could you do the testing while wearing a white tux with tails pls
[15:51:52] <skunkworks> I will - I don't know if I can this weeked though.. Tomorrow I am going to tormach to meet rob.
[15:53:03] <seb_kuzminsky> cool
[15:58:36] <skunkworks> I am a little sad...
https://groups.google.com/forum/#!msg/machinekit/LcLpKcLBPEw/v2sN2NtQEtsJ
[16:01:07] <cradek> that knocked it down to 1.1GB
[16:01:41] <memfrob> heh.. Pumping Station One i been there a few times.
[16:02:09] <jepler> skunkworks: oh I wish 'em luck with their projects
[16:02:32] <jepler> heck, I've frequently fantasized about throwing away all the bits from NIST and just keeping HAL for some new project
[16:02:57] <skunkworks> I am just worried that any new tp stuff he does won't be usable to linuxcnc
[16:02:58] <seb_kuzminsky> i've also daydreamed about that
[16:03:01] <skunkworks> but oh well..
[16:03:03] <jepler> the only good thing about the stuff from nist -- task, nml, interpreter -- is that they work and we really don't spend that much time fighting with them
[16:05:06] <jepler> It's true, though: MAH could take care to structure 'minimot' so that even when Robert keeps his work nice and tidy in terms of git hygene, it's impossible to cherry-pick to linuxcnc.
[16:05:55] <jepler> much like after a certain point, emc2 / linuxcnc work was totally useless to a developer of an emc1 derivative
[16:06:21] <jepler> (even if 'cherry pick' had been a phrase in our vocabulary at the time)
[16:09:08] <mozmck> what would be involved in making 'motion' more flexible in linuxcnc? would it really require a complete re-write?
[16:09:36] <cradek> that's not a specific enough goal to even guess
[16:10:09] <seb_kuzminsky> there are plenty of things in linuxcnc that would probably benefit from a redesign & rewrite, but motion is not high on my list
[16:10:10] <mozmck> MH's mention of each motion command tagged with a kinematic to apply sounds interesting.
[16:10:19] <seb_kuzminsky> i think nml is first, then task
[16:10:45] <mozmck> ...to get rid of the modal operation, but how much work would it take to try something like that?
[16:11:24] <cradek> I don't think rewriting things is a worthy goal at all. If a new design is needed for user functionality we want, and that makes a rewrite necessary, so be it
[16:11:45] <cradek> changing offsets while a program is running might be one of those things
[16:12:21] <mozmck> agreed, but MH seems to think a re-write is necessary, hence my question I guess.
[16:12:32] <seb_kuzminsky> the nml 'sequence number' collision issue might be one of those things
[16:12:48] <mozmck> why would you want to change offsets while a program is running?
[16:13:07] <cradek> mozmck: because you paused and changed the tool to one with a different length
[16:13:17] <mozmck> Oh, I see.
[16:13:31] <cradek> seb_kuzminsky: that's true (but I think we already have a patch languishing that fixes it)
[16:14:01] <seb_kuzminsky> we do? it must have been buried under all the other things languishing in my mind
[16:14:41] <cradek> http://sourceforge.net/p/emc/bugs/328/
[16:14:47] <jepler> some days I think we *should* switch to github to get their features like pull requests
[16:16:33] <seb_kuzminsky> cradek: thanks, that jogs my memory
[16:16:36] <jepler> alternately, self-host gitlab CE which has merge requests
[16:17:01] <jepler> it really does seem to help people collaborate
[16:17:37] <jepler> and while the github workflow is not perfect, it is still encourages a better workflow (topic branches) than many people actually practice
[16:17:41] <mozmck> It does seem nice from the little I've used it.
[16:19:04] <jepler> it may be optimistic to think we can solve what is effectively a social problem (accepting patches from first-time or one-time contributors) with a technological change
[16:19:13] <jepler> s/may be/is/
[16:19:22] <cradek> is
[16:19:24] <jepler> but that's an ongoing social problem we have in linuxcnc
[16:22:13] <seb_kuzminsky> we can accept github pull requests today, i think - against the github linuxcnc mirror
[16:22:37] <jepler> no, if I went into the linuxcnc-mirror and accepted a pull request, it'd be blown away by the next update from git.l.o.
[16:23:05] <seb_kuzminsky> yeah, *our* part of the workflow would be different, but the casual contributor's workflow would look like a PR
[16:24:50] <jepler> oh, say to people: "you *may* create pull requests on github", but we have to use regular git to pull them and push to git.l.o .. ?
[16:25:01] <seb_kuzminsky> yeah
[16:25:29] <jepler> if there were some people with push access to git.l.o who were willing to look at push requests on github, I think that's a fine idea
[16:25:47] <seb_kuzminsky> all the same people who're willing to look at patches mailed to the list, i'd guess
[16:26:08] <seb_kuzminsky> err, i mean, i'd be willing to look at github PRs
[16:27:22] <cradek> I'd be willing to learn to use github if I have to. My limited experience trying to figure out the git history of a github project using just git is terrible, but maybe with the things they've tacked on top of plain git, it's less bad
[16:29:34] <cradek> otoh, I don't want to worry about this right now. lots of us are busy with things that are real progress.
[16:30:07] <jepler> cradek: I don't understand what you're saying
[16:30:47] <jepler> cradek: are you saying that something about github made you have trouble using the regular git commandline tools to understand the history of the code?
[16:31:17] <seb_kuzminsky> jepler: that's how i use github currently - it's just another remote to me
[16:32:32] <jepler> on another topic, are the monthly irc meetings still a thing, or did that fall by the wayside?
[16:32:46] <cradek> jepler: they are still a thing, but there has been no agenda for a while.
[16:33:50] <jepler> a difference (and, I think, advantage) of a github pull request over the mailing list is that the items stay there until someone makes a decision.
[16:34:01] <jepler> just like bug trackers are better than mailing lists for tracking bugs and knowing whether they're open or not
[16:34:18] <jepler> (or, more to the point, whether in the eyes of project admins they're open or not)
[16:34:46] <jepler> another element of using GH PRs would be that someone would have to be able to reject ones that we want to reject. not all PRs end up with a merge...
[16:34:59] <jepler> I wonder if I can delegate the ability to do that to interested parties
[16:39:05] <jepler> cradek, seb_kuzminsky: for grins, I made you both "collaborators" on the linuxcnc-mirror repository
[16:39:47] <jepler> I'm off
[16:39:52] <seb_kuzminsky> i got the email from github - thanks!
[16:39:55] <seb_kuzminsky> have a good weekend
[16:40:17] <jepler> hopefully I get at least 6 quality hours to spend working rtapi_pci
[16:40:42] <jepler> seb_kuzminsky: you too
[17:22:24] <skunkworks> in case anyone is interested..
https://groups.google.com/forum/#!topic/machinekit/xClIoVR2Bp4
[17:30:37] <skunkworks> andypugh: !
[17:30:42] <skunkworks> how is the bike coming?
[17:31:04] <andypugh> I have been doing something slightly different :-)
[17:31:10] <skunkworks> oh...
[17:31:45] <skunkworks> that is surprising.... ;)
[17:33:34] <andypugh> https://picasaweb.google.com/108164504656404380542/Sniper?authuser=0&authkey=Gv1sRgCJ6K36Pg5_T5ew&feat=directlink
[17:34:12] <skunkworks> neat!
[17:34:25] <skunkworks> I saw the bolt - nice job bending that
[17:47:10] <memfrob> which rifle is that?
[17:50:52] <andypugh> It isn’t really any rifle at all.
[17:52:25] <andypugh> The bolt mechanism operates a microswitch which fires an LED.
[17:52:48] <andypugh> The only way that would be a “rifle” would be if the LEd was circularly polarised :-)
[17:53:18] <seb_kuzminsky> is the ne'er-a-car running?
[17:53:34] <memfrob> ohh.. heh
[17:53:37] <seb_kuzminsky> you were close last time i looked
[18:01:18] <andypugh> The engine runs
[18:02:00] <andypugh> I have a transmission. Today I was making a front sprocket, and when that is done and a chain fitted it would be self-mobile. But no seat or any brakes.
[18:31:11] <seb_kuzminsky> andypugh:
https://www.youtube.com/watch?v=rWHniL8MyMM
[18:33:38] <andypugh> seb_kuzminsky: Did you see:
https://www.youtube.com/watch?v=4VLv9fmIqcQ&list=UUexvgsGz_QFvOublovDYoTQ
[18:34:50] <seb_kuzminsky> neato
[18:35:12] <seb_kuzminsky> some kind of spindle-synchronized motion hack?
[18:47:32] <andypugh> Just feed-per-rev mode
[18:47:40] <jepler> hey, I know the guy in that video!
[18:57:40] <skunkworks> logger[psha]:
[18:57:41] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-06-27.html
[22:03:19] <skunkworks> cradek:
http://electronicsam.com/images/KandT/testing/DSC_1794.JPG
[22:04:03] <skunkworks> (only computer that could have decent latency that I have here) although the laptop was under 1ms - better than I have ever seen it ;)
