#linuxcnc-devel | Logs for 2016-06-14

[04:48:26] <trasz_> seb_kuzminsky: last time i've seen debian stable, i was missing my freebsd 11 :-)
[04:48:33] <trasz_> seb_kuzminsky: what did you stumble upon, though?
[04:50:36] <trasz_> hm.
[04:50:45] <trasz_> ok, one of the things i have all over my tree is this:
[04:50:54] <trasz_> -#!/bin/bash
[04:50:54] <trasz_> +#!/usr/local/bin/bash
[04:51:11] <trasz_> i guess i could replace it with '#!/usr/bin/env bash' instead.
[04:51:17] <trasz_> question is, is that acceptable for you?
[06:03:18] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15trasz opened pull request #69: Another push of FreeBSD-specific changes. Sorry for the mess. (06master...06master) 02https://github.com/LinuxCNC/linuxcnc/pull/69
[06:12:16] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #33: My gtk3 version of stepconf is already working, but for sure there will be some bugs that I have not discovered.... 02https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-225845348
[06:47:30] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_2 057af44 06linuxcnc 10(5 files in 2 dirs) gmoccapy_2_0_3 - bug in DRO size handling and hal pin names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=057af44
[07:09:33] <jepler> trasz_: another strategy would be to remove bashisms from as many of those shell scripts as possible
[07:10:09] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #33: I should ask my question more plainly: Would you consider becoming a de-facto maintainer of stepconf, which means things like responding to stepconf issues and pull requests on github and participating to help with users of stepconf either the mailing list or the forum? The past maintainers of stepconf are putting their energies into other projects at the moment, and I don't think we have an
[07:10:54] <jepler> trasz_: do you have any links about best practies to invoke bash from a #!-line? env bash sounds plausible to me, though we could also turn them all into .in scripts with #!@BASH@ substituted by configure, as another alternative
[07:13:13] <trasz_> jepler: yeah, but it's much more work. they can result in rather obscure errors, so just using bash instead is safer, and definitely quicker.
[07:13:33] <trasz_> jepler: now, this occurs quite frequently, and the usual solution is to fix this in the port.
[07:13:55] <trasz_> jepler: where port means Ports Collection, the freebsd equivalent of source packages.
[07:13:58] <jepler> trasz_: another thing .. I suggested that you use "git rebase" to move your commits so that they are on top of our current master branch without merge commits. but you encountered errors. do you want to take the time for me to show you how to deal with a few common error patterns during git rebase?
[07:14:31] <trasz_> jepler: sure!
[07:14:37] <jepler> trasz_: I am aware of ports but not familiar with it
[07:14:46] <jepler> trasz_: OK, so I think when you rebased it stopped with an error similar to:
[07:14:48] <trasz_> jepler: i'll take care of the ports stuff.
[07:15:00] <jepler> CONFLICT (content): Merge conflict in src/emc/usr_intf/xemc.cc
[07:15:00] <jepler> Recorded preimage for 'src/emc/usr_intf/xemc.cc'
[07:15:00] <jepler> error: Failed to merge in the changes.
[07:15:00] <jepler> Patch failed at 0005 Tweak includes to make things build on FreeBSD.
[07:15:21] <trasz_> yeah. then i've edited it, did 'git add', 'git commit', and then 'rebase --continue'.
[07:15:47] <jepler> in this case, I took a cherry-pick of your patch, but then one of the headers needed to be changed again
[07:15:57] <jepler> so I would say to "git rebase --skip" this patch
[07:16:49] <jepler> I mean, I believe that our master branch already had "Tweak includes"
[07:18:04] <trasz_> it did, yeah.
[07:18:40] <trasz_> to be honest it would be simpler if i didn't do the merge/rebase at all :-)
[07:20:01] <jepler> I know there are a lot of different conceptions of git
[07:20:26] <trasz_> well, in my case the problem probably comes from trying to use my usual svn workflow.
[07:20:49] <trasz_> i kind of get that figured out, actually.
[07:21:02] <jepler> what is nice about me using cherry-pick and you using rebase is this:
[07:21:07] <trasz_> git stash, git pull, git rebase, git stash pop, git reset
[07:21:33] <jepler> the number of patches you have to maintain can eventually get to 0
[07:21:35] <trasz_> and voila, 'git diff -a' again shows all the changes to the master, and i can split them into individual patches.
[07:21:58] <trasz_> jepler: that's the plan; that's why i'm doing this pull request thing :-)
[07:22:33] <jepler> and to the extent that they are independent changes, I can take them out of order and request that you re-work the parts where I prefer a different approach
[07:23:00] <jepler> (or maybe you end up with 2 or 3 really gross patches on top of our git, and you put those into the patches applied by the ports process)
[07:23:22] <trasz_> jepler: exactly.
[07:23:53] <trasz_> jepler: btw, do you intend to commit that setup_struct patch?
[07:24:30] <jepler> what do you think, vs just fixing the place where gcc is accepting obviously stupid code?
[07:24:52] <jepler> I don't like the 'typedef { ... } name;' style in C++ personally, because it's redundant
[07:25:52] <jepler> anyway, if you completed the rebase by using skip or by resolving the conflict and continuing, you will get to the end with no further interruptions
[07:26:12] <jepler> .. but in the log of commits since linuxcnc.org's master branch you'll see:
[07:26:15] <jepler> 332cb19 Revert "Add GNU-specific libm #defines."
[07:26:17] <jepler> fcd91ae Add GNU-specific libm #defines.
[07:26:25] <jepler> (you'll have different hex refs of course)
[07:27:28] <jepler> what you really want is to have neither of those commits, so invoke 'git rebase -i origin/master' and you get a list of commits in your editor
[07:28:20] <jepler> you can just delete those two lines, write and exit your editor, and now it's as though those commits never happend
[07:28:59] <trasz_> wait, origin/master, or upstream/master?
[07:29:17] <jepler> ummm
[07:29:21] <jepler> it depends what you have called things
[07:29:26] <jepler> whatever linuxcnc.org's master branch is called in your git
[07:29:33] <trasz_> upstream/master.
[07:29:39] <jepler> OK then
[07:29:44] <trasz_> can i do that for past commits?
[07:30:33] <jepler> yes, you can do that for commits you have already pushed
[07:30:48] <jepler> later, push will require that you specify "-f" to push a "non-fast-forward" commit
[07:31:55] <jepler> this is a good workflow for what is commonly called a "topic branch", where you are working on a specific task ("port to freebsd") and sometimes the middle steps need to be re-worked even after you share them with someone else
[07:32:20] <jepler> it's not a good workflow for release branches, or really any branch that others will be using as a starting point for their branch
[07:33:27] <trasz_> okay. thanks for the explanation, i'll need to spend some more time on it :-)
[07:34:12] <trasz_> jepler: as for the setup_struct - i prefer the cleaner version, ie yours.
[07:34:34] <jepler> OK, I'll try to get it pushed soon.
[07:34:38] <trasz_> thanks!
[07:34:41] <jepler> I'll also try to look at your current set of patches soon
[07:34:48] <jepler> $DAY_JOB is calling my name though
[07:37:42] <trasz_> see you :-)
[09:31:38] <KGB-linuxcnc> 03Jeff Epler 05master 9e477ca 06linuxcnc 10src/emc/rs274ngc/interp_internal.hh 10src/emc/rs274ngc/interp_setup.cc 10src/emc/rs274ngc/rs274ngc.hh 10src/emc/rs274ngc/rs274ngc_pre.cc rs274ngc: get rid of setup_struct and typedef * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9e477ca
[09:32:01] <seb_kuzminsky> yay, cleanups!
[09:36:52] <jepler> trasz_: looks like your more recent commits are missing signed-off-by, oops
[09:37:33] <seb_kuzminsky> trasz_: i'm using the 11.0-CURRENT qcow image from freebsd.org, but after installing sudo (via pkg, not ports) it complains this:
[09:37:36] <seb_kuzminsky> sudo: unable to load /usr/local/libexec/sudo/sudoers.so: Shared object "libpam.so.6" not found, required by "sudoers.so"
[09:38:09] <seb_kuzminsky> there's no libpam.so.6, but there is a /usr/lib/libpam.so.5
[09:38:14] <jepler> another task that can be fixed with git rebase. You can "git rebase -i -x 'git commit --amend -CHEAD -s' ..." to get a list of rebase instructions that will add signed-off-by to each commit as it goes
[09:39:16] <seb_kuzminsky> but according to 'pkg which /usr/lib/libpam*', no packages claim those files
[09:39:33] <seb_kuzminsky> this is not a freebsd support forum and i'm going to stop complaining now
[09:40:11] <seb_kuzminsky> i really appreciate what you and jepler are doing, i'm trying to run along side with you and get a freebsd buildslave up and running
[09:40:20] <seb_kuzminsky> bbl
[10:04:55] <jepler> seb_kuzminsky: thanks, you and buildbot both rock
[10:07:29] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #33: Hi Jeff,... 02https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-225903238
[10:13:28] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #33: Your english has been perfectly clear while discussing this issue. But I understand if you are reluctant to offer help on the forum for this reason.... 02https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-225905258
[10:26:22] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #33: Besides the problem I noted in the "Mio commento" commit, there's one other important thing to take care of before. It is called the "signed-off-by" policy, and it is described here: https://github.com/LinuxCNC/linuxcnc/blob/master/docs/SubmittingPatches — basically, it is your promise to the project that your contribution is under an appropriate open source license.... 02https://github
[11:31:03] <seb_kuzminsky> https://s3.amazonaws.com/uploads.hipchat.com/95477/2483272/u48HzwVwvGfKL3H/truth..png
[11:41:14] <cradek> still working on task, I see
[11:44:30] <seb_kuzminsky> heh, actually i'm not
[11:45:32] <seb_kuzminsky> i think the fix in https://github.com/LinuxCNC/linuxcnc/pull/67 takes care of it, i'm holding off on merging while (i think) zultron chases some bug in machinekit
[12:15:26] <mozmck> Should I put a link to the MeetingsOnIRC wiki page on the main wiki TOC?
[12:16:21] <seb_kuzminsky> if you think it would make things better, go for it
[12:16:34] <cradek> you should link to it from http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingsOnIRC
[12:16:49] <cradek> the threads on the mailing list are more important than a front page link
[12:17:00] <cradek> I don't really think anyone browses the front page looking for links :-/
[12:17:09] <cradek> it's very ... full
[12:17:10] <seb_kuzminsky> he's proposing adding a link to the front page pointing to MeetingsOnIRC
[12:17:24] <mozmck> Yeah, that's because the most interesting are not there as well!
[12:17:24] <seb_kuzminsky> not to the page for this month's meeting
[12:17:35] <mozmck> what seb said.
[12:18:33] <mozmck> I was thinking maybe a link in the "Communication" section. But as cradek said, maybe it won't be much use.
[12:18:50] <cradek> oh to the general meetings page
[12:18:55] <mozmck> yes
[12:18:56] <cradek> I think that would be good
[12:18:59] * cradek shrugs
[12:18:59] <cradek> sorry
[12:19:03] <mozmck> ok :-)
[12:19:52] <mozmck> how do I create a new page?
[12:20:10] <cradek> just go to the url that it would have
[12:20:18] <cradek> change the thing after the ? to your page name
[12:20:27] <mozmck> oh... interesting! thanks,
[12:20:28] <cradek> (I don't know if there's another friendlier way)
[12:20:35] <seb_kuzminsky> that's how i do it too
[12:20:58] <mozmck> I was looking for a link or something.
[12:21:02] <cradek> I guess if you were normal, you'd make a link to it on an existing page, and then click that link
[12:21:11] <mozmck> I see.
[12:21:19] <cradek> <- abnormal
[12:21:26] <seb_kuzminsky> heh
[12:21:57] <cradek> "oh... interesting!" made me laugh
[12:22:13] <cradek> if only I could feel that way about terrible user interfaces
[12:22:18] <cradek> you're so polite :-)
[12:22:45] <mozmck> :-) I like laughing. Sometimes I rant though.
[12:22:51] <trasz_> seb_kuzminsky: hm.
[12:23:25] <trasz_> seb_kuzminsky: that basically means the image is slightly old. the library versions for libpam were bumped a week or two agon.
[12:23:36] <seb_kuzminsky> makes sense
[12:23:41] <jepler> trasz_: is there a way to update it all?
[12:23:42] <seb_kuzminsky> which package has libpam?
[12:23:54] <seb_kuzminsky> or rather, what command tells me which package has libpam ;-)
[12:24:02] <cradek> isn't there something like pkg update?
[12:24:05] <trasz_> seb_kuzminsky: it's basically something that can only happen once per few years on CURRENT :-)
[12:24:13] <jepler> .. or should seb_kuzminsky use a stabler freebsd instead for his purposes?
[12:24:14] <seb_kuzminsky> jepler: there's "pkg update" and "pkg upgrade", but they claim i'm up to date
[12:24:17] <trasz_> jepler: ugh. ok, i'll try.
[12:24:32] <jepler> https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#change-control
[12:25:07] <trasz_> seb_kuzminsky: no package has libpam; libpam is part of the base system.
[12:25:13] <jepler> (hum does repo_interim forbid using git rebase?)
[12:25:16] * seb_kuzminsky squints at freebsd
[12:25:38] <trasz_> seb_kuzminsky: so basically checkout the sources and do the usual 'make buildworld buildkernel installkernel installworld && reboot'.
[12:26:25] <seb_kuzminsky> cool, thanks for the help
[12:26:32] <trasz_> and, well, yeah, this is CURRENT, aka "we're assuming you know how to develop freebsd".
[12:26:53] <seb_kuzminsky> heh right
[12:27:10] <seb_kuzminsky> STABLE might be more my speed
[12:27:46] <trasz_> hm.
[12:28:34] <trasz_> so, on STABLE there's this stupid error in math.h that will break build.
[12:28:38] <trasz_> goes like this:
[12:28:52] <trasz_> long double frexpl(long double value, int *);
[12:30:57] <jepler> and we #define value or something dumb like that?
[12:35:08] <trasz_> exactly.
[12:35:28] <trasz_> also, the Tk::img is broken, i have a local fix.
[12:35:57] <trasz_> but i'm still investigating if i'm not using the wrong package, as it seems absolutely no other package in freebsd depends on this one.
[12:41:29] <jepler> I think users of Tk are dropping steadily towards zero
[12:43:44] <trasz_> jepler: heh.
[12:43:53] <trasz_> jepler: ok, so that git thing looks like it worked.
[12:43:55] <trasz_> however.
[12:44:05] <trasz_> fatal: You are not currently on a branch.
[12:44:05] <trasz_> To push the history leading to the current (detached HEAD)
[12:44:07] <trasz_> state now, use
[12:44:31] <jepler> are you still in the middle of your rebase? ifyou are, git status will say so.
[12:44:40] <trasz_> hm.
[12:46:36] <trasz_> okay, tried that again, this time avoiding one problematic commit, and now its:
[12:46:52] <trasz_> To git@github.com:trasz/linuxcnc.git ! [rejected] master -> master (non-fast-forward)
[12:46:55] <trasz_> error: failed to push some refs to 'git@github.com:trasz/linuxcnc.git'
[12:46:57] <trasz_> hint: Updates were rejected because the tip of your current branch is behind
[12:47:01] <trasz_> hint: its remote counterpart. Integrate the remote changes (e.g.
[12:47:03] <trasz_> hint: 'git pull ...') before pushing again.
[12:47:22] <jepler> yes, this is expected after you rebase commits that you have previously pushed.
[12:47:32] <jepler> since that is what you intend, you can add "-f" to your git push commandline
[12:48:08] <trasz_> okay.
[12:48:10] <trasz_> yolo.
[12:49:29] <trasz_> jepler: ok, how does it look now?
[12:49:33] <jepler> trasz_: let me check
[12:52:22] <jepler> trasz_: the signed-off-bys are there on the newest commits now, so I can resume cherry-picking where I want
[12:52:29] <trasz_> jepler: :-)
[12:52:32] <mozmck> I started a page for the next meeting http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Meeting201606
[12:52:53] <jepler> mozmck: are you done editing it for now? I will want to add my stuff after I get back from lunch, which I think I'm about to do
[12:52:57] <jepler> trasz_: afk and ttyl
[12:52:58] <mozmck> jepler: I put the items from your email in it - you might want to review
[12:53:10] <jepler> mozmck: thanks! I will
[12:53:13] <mozmck> jepler: yes, I'll quit for now.
[12:57:58] <mozmck> I don't know if I need to add agenda items. We had discussed version numbering a while back, and I don't remember exactly what was proposed. I think seb_kuzminsky wanted to go to something other than x.x.x?
[13:00:53] <mozmck> The other thing that would be nice is if we could make some things default that currently require a setting in the ini: FEATURES=xx
[13:03:30] <mozmck> I use FEATURES = 12 so I can read ini values and hal pins from gcode, and that seems to work quite well.
[13:15:49] <andypugh> How important is backwards compatibility in emcrsh>
[13:15:51] <andypugh> ?
[13:19:20] <andypugh> Supplementary question: What does emcsh.cc do?
[13:24:42] <andypugh> It looks like it ought to be linuxcncsh, but there is no manpage of that name, and I haven’t found a command that makes anything happen. It definitely gets compiled, I spent most of yesterday evening making it handle multi-spindles.
[13:25:09] <andypugh> (or, more specifically, making it compile with multi-spindles)
[13:25:36] <jepler> andypugh: yes, it is built into tcl/linuxcnc.so which is the way that tklinuxcnc does stuff
[13:26:27] <andypugh> Ah, yes. I wonder how the GUIs will handle multiple spindles? The answer is likely to be that they won’t, initially.
[13:26:48] <jepler> you mean if they press the spindle start/stop/go faster/go slower buttons?
[13:26:54] <andypugh> Yes.
[13:26:59] <jepler> yeah they'd need to all be changed to use a non-default spindle
[13:27:42] <andypugh> At the moment if you don’t specifiy a spindle, the commands affect all spindles. As the default number of spindles is 1, that’s fine.
[13:28:16] <mozmck> Is there going to be another linuxcnc meeting this year?
[13:35:32] <jepler> mozmck: I still disagree very stridently with reading other-component pins from gcode. I know it is expedient, but it violates the HAL model thoroughly. I am on the record about this so I'll leave it at that for now.
[13:37:50] <andypugh> It does cause unexpected behaviour. I did use it for my lathe macros, but went off the idea and now do things a different way.
[13:38:06] <andypugh> Reading INI file data seems less wrong.
[13:40:02] <seb_kuzminsky> yeah, reading ini files seems ok
[13:40:42] <seb_kuzminsky> mozmck: i would love to have a linuxcnc developer hackfest this year
[13:41:00] <jepler> I think it makes more sense to live within the design of realtime analog/digital I/O from motion; but increase the pin counts or make them inifile-able up to a reasonable limit
[13:41:19] <jepler> .. and then if the names still offend, document how to use hal aliases to give nice names to the motion I/O pins
[13:42:48] <seb_kuzminsky> if there are no better offers, i can host the hackfest in Boulder, CO
[13:42:56] <jepler> I guess that doesn't help as far as making memorable names, rather than inscruatable numbers, appear in part programs or remap code
[13:43:21] <seb_kuzminsky> we have a scummy little hackspace with nearly no space to work, but some linuxcnc machines (including two different non-trivkins machines)
[13:43:47] <seb_kuzminsky> and the local library will probably let us monopolize one of their super nice meeting rooms for a weekend or so
[13:43:56] <jepler> .. and no AC
[13:44:29] <seb_kuzminsky> right, the hackspace has no AC
[13:44:46] <seb_kuzminsky> on the other hand, it's open 24/7, whereas the library is only open 10-6 on weekends
[13:44:57] <seb_kuzminsky> er, 12-6 on sunday :-(
[13:45:35] <jepler> quitting at 6 would never fly with this lot
[13:45:43] <jepler> heck even I can go until 7 or 8pm :-P
[13:46:04] <pcw_home> A way to keep hal structure and names separate so portable structural hal file modules could be "included" seems
[13:46:06] <pcw_home> like it would be nice. I think HM2 is especially bad in this respect in not using canonical names for things
[13:50:35] <mozmck> jepler: interesting - I didn't know you had that disagreement. It is reasonable I think but as you mention - motion.digital-in.47 doesn't mean much in gcode unless there is a comment explaining it.
[13:51:04] <mozmck> no AC? that's no problem mine is not working here either :-)
[13:51:11] <jepler> I'm in the same club
[13:52:01] <mozmck> didn't Stuart offer his new place as well?
[13:53:30] <seb_kuzminsky> yes he did!
[13:53:39] <seb_kuzminsky> he suggested early fall
[13:54:00] <seb_kuzminsky> fHelix Machine, in Wichita
[13:54:06] <cradek> I would happily go to a hackfest
[13:56:16] <seb_kuzminsky> i'll revive the email thread with Stuart
[13:56:50] <cradek> someone just has to pick a date, and then we all show up
[13:59:03] <seb_kuzminsky> we can haggle about an "early fall" date in email
[14:14:10] <jepler> hm our irc meeting procedure is a poorly-documented shambles
[14:14:46] <jepler> the standard boilerplate on the individual meeting page says it is "common to send a message to the dev maillist"
[14:15:13] <jepler> actually both pages say that, MeetingsOnIRC too
[14:17:20] <jepler> should I ride roughshod over the MeetingsOnIRC page to re-make it in my image, or is that in itself an IRC meeting topic?
[14:18:43] <cradek> I think it depends on what you want to change. use your best judgment?
[14:20:01] <mozmck> Yeah, it also says there is a meeting every month
[14:20:28] <mozmck> In my link on the main page I said "occasional meetings are held..."
[14:21:34] <mozmck> Is the "only a little discussion is allowed" rule still valid?
[14:21:56] <jepler> I think the intent is for the vast majority of the discussion to take place on the mailing list before the meeting
[14:22:15] <cradek> that's sure my preference
[14:22:28] <mozmck> ok
[14:22:55] <jepler> > To further the discussion before the meeting, send a message to the dev maillist with the title similar to: 'DISCUSS: my agenda item idea', changing my agenda item idea to an appropriate title.
[14:22:55] <cradek> a meeting where people are unprepared and unread about an issue, but get to vote their opinion anyway, is a very stupid meeting that makes stupid decisions
[14:22:59] <jepler> The mailing list is the place to discuss, sell and adjust an idea. The meeting is for voting on an item - only a little discussion is allowed (approx max 15 mins)
[14:23:30] <jepler> so the changes I made are to delete the bit that says "it is common", and direct that a message be sent to the developer list
[14:23:40] <jepler> and to change a "this" to "the mailing list"
[14:23:40] <mozmck> ok
[14:24:03] <jepler> I also in point 1 say to create the page if it's not there, not that the page will be created; nobody should think that, because the page doesn't exist, they can't add an item
[14:24:16] <jepler> the wiki of course documents all my revisiions
[14:24:50] <mozmck> are we going to try to hold a meeting every month - or just when deemed necessary?
[14:24:54] <jepler> mozmck: the latter
[14:25:05] <jepler> if there are no items, there's no meeting
[14:25:21] <jepler> which has been the case, more often than not, since the first one about 3 years ago
[14:25:37] <mozmck> ok, so I guess the MeetingsOnIRC should be changed to reflect that
[14:26:32] <jepler> add a last point that says: #If there are no issues, no IRC meeting is held.
[14:26:36] <jepler> which is what we've done all along
[14:26:41] <mozmck> ok
[14:27:25] <mozmck> how about "agenda items" instead of issues?
[14:28:01] <jepler> yes
[16:08:56] <andypugh> spindle override lives in emcStatus->traj. Spindle speeds live in emcStatus->motion->spindle.
[16:10:08] <andypugh> It seems to me that spindle override should be a spindle property not a traj property. I can’t decide if there should be a spindle-override per spindle.
[16:10:18] <mozmck> sounds like we need another structure ;-)
[16:10:39] <mozmck> just kidding of course.
[16:11:13] <andypugh> Well, no, that is exactly what i am thinking.
[16:11:32] <mozmck> You mean for spindle?
[16:11:36] <andypugh> Yes
[16:11:50] <mozmck> I was joking that we could spread spindle values out in more places.
[16:12:11] <andypugh> Ah, OK.
[16:12:41] <mozmck> But yes, putting them all in one place makes the most sense to me - little as I know about spindle stuff in linuxcnc yet.
[16:13:23] <andypugh> Actually, I am not quite right, spindle override is in emcStatus->motion.traj and spindle speed is in emcStatus->motion.spindle[N]
[16:14:25] <andypugh> the number of _axes_ seems to live in emcStatus->motion.traj but I can’t find num_joints or num_spindles in there.
[16:15:03] <andypugh> Any objections to me adding int emcStatus->motion.num_spindles ?
[16:15:53] <andypugh> It will help with backwards compatibility as more “things” will know to stop short of EMCMOT_MAX_SPINDLES
[16:29:37] <jepler> giit makes sense to add a variable for the actual number of spindles at the same time as you add some new arrays sized to a maximum like EMCMOT_MAX_SPINDLES
[16:29:46] <jepler> s/gi//
[17:06:15] <seb_kuzminsky> he can't even type it without typing git
[17:08:35] <KGB-linuxcnc> 03Edward Tomasz Napierala 05jepler/master/from-trasz a143bd9 06linuxcnc 10src/rtapi/rtapi_byteorder.h Fix byteorder detection under FreeBSD. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a143bd9
[17:08:35] <KGB-linuxcnc> 03Edward Tomasz Napierala 05jepler/master/from-trasz 56ac6bb 06linuxcnc 10src/Makefile Make setuid detection work under FreeBSD. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=56ac6bb
[17:08:36] <KGB-linuxcnc> 03Edward Tomasz Napierala 05jepler/master/from-trasz 17b4eaf 06linuxcnc 10(8 files in 6 dirs) In FreeBSD, python lives in /usr/local/bin/, not /usr/bin/. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17b4eaf
[17:08:38] <KGB-linuxcnc> 03Edward Tomasz Napierala 05jepler/master/from-trasz 8033574 06linuxcnc 10tests/module-loading/rtapi-app-main-fails/checkresult 10tests/symbols.0/checkresult Fix two regression tests to work under FreeBSD. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8033574
[17:08:42] <KGB-linuxcnc> 03Edward Tomasz Napierala 05jepler/master/from-trasz f76a39c 06linuxcnc 10src/emc/rs274ngc/interp_o_word.cc Avoid get_current_dir_name(). * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f76a39c
[17:08:42] <jepler> linuxcnc-build_: lmk!
[17:08:43] <linuxcnc-build_> What you say!
[17:08:46] <KGB-linuxcnc> 03Edward Tomasz Napierala 05jepler/master/from-trasz 642955d 06linuxcnc 10src/rtapi/uspace_common.h Improve debugging: warn about errors during shmem removal. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=642955d
[17:08:51] <KGB-linuxcnc> 03Edward Tomasz Napierala 05jepler/master/from-trasz 236fee9 06linuxcnc 10src/hal/components/sim_axis_hardware.comp Don't use nested functions. They don't work with clang. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=236fee9
[17:13:16] <seb_kuzminsky> yay
[19:58:06] <KGB-linuxcnc> 03Jeff Epler 05master 236fee9 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=236fee9
[20:25:57] <seb_kuzminsky> well that went smoothly
[20:31:34] <jepler> hi seb_kuzminsky
[20:32:19] <jepler> may I just say that worktrees are one of the best features added to git this year?
[20:32:32] <jepler> I think that it's a feature that bzr had 1,000 years ago but that's beside the point
[20:44:23] <seb_kuzminsky> hmm worktrees you say?
[20:44:30] * seb_kuzminsky googles
[20:49:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/configure-libdl 6d62289 06linuxcnc 10(6 files in 5 dirs) configure: check whether dlopen needs -ldl * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6d62289
[20:56:55] <jepler> hm, every once in awhile it would be nice to see the git diff --stat associated with each commit in a rebase todo list
[20:57:00] <jepler> I wonder if there's a way to make that happen
[20:59:32] <jepler> or you could go all the way to having a gitk-style program for preparing rebase todo lists
[21:00:00] <jepler> see full commits in bottom pane, drag & drop to reorder, etc
[21:19:28] <KGB-linuxcnc> 05jepler/master/from-trasz 236fee9 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=236fee9
[21:49:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #70: configure: check whether dlopen needs -ldl (06master...06jepler/master/configure-libdl) 02https://github.com/LinuxCNC/linuxcnc/pull/70
[22:05:42] <seb_kuzminsky> jepler: that'd be a great tool
[22:07:59] <seb_kuzminsky> http://stackoverflow.com/questions/4830344/how-to-do-a-rebase-with-git-gui