Back
[08:38:44] <pcw_home> I've thought that too. On faster machines they overlap so are not as distinct
[08:43:41] <pcw_home> on preempt-RT, there spikes are on the base thread, at least on this machine:
[08:43:42] <pcw_home> https://imagebin.ca/v/2r5WbPdeB8Od
[09:25:37] <jepler> wouldn't that mean the slow thread was interrupting the fast one? That's a "shouldn't happen"...
[09:37:48] <pcw_home> Yeah, but I dont know if thats the case (could be something else causing a relatively frequent but consistent latency )
[09:39:18] <pcw_home> let me try without a base thread
[09:41:35] <pcw_home> 10Khz servo thread only shows no spikes so maybe
[09:46:42] <jepler> I'll have to look into that further
[12:59:26] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron opened pull request #135: Execute finish in py remap lcnc (06master...06execute_finish_in_py_remap-lcnc) 02
https://github.com/LinuxCNC/linuxcnc/pull/135
[13:17:52] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #135: Assuming the project is interested in merging this fix, should the PR be against the master branch (as here) or 2.6, where remap was introduced? 02
https://github.com/LinuxCNC/linuxcnc/pull/135#issuecomment-238947290
[14:53:40] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #134: @robEllenberg, I'm finding files in the `state-tags-master` branch licensed as GPLv2 (only). Can I change the license to GPLv2 or later? 02
https://github.com/LinuxCNC/linuxcnc/issues/134#issuecomment-238976485
[16:11:32] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #134: Note that by project policy, new submissions to linuxcnc need to be covered by GPLv2+. GPLv2(only) is not OK.... 02
https://github.com/LinuxCNC/linuxcnc/issues/134#issuecomment-238997956
[16:12:40] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #135: @zultron 2.6 and 2.7 are mature branches, and so should only receive very safe fixes for things that are clearly regressions. Personally, I wouldn't try to do this in any branch older than master. 02
https://github.com/LinuxCNC/linuxcnc/pull/135#issuecomment-238998328
[16:13:46] <KGB-linuxcnc> 03John Morris 05pr135 56adc0f 06linuxcnc 10(10 files) reenterable remaps: unit test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=56adc0f
[16:13:46] <KGB-linuxcnc> 03John Morris 05pr135 4364dbd 06linuxcnc 10src/emc/rs274ngc/interpmodule.cc reenterable remaps: fix python body and prolog reentry * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4364dbd
[16:13:46] <KGB-linuxcnc> 03John Morris 05pr135 c978ffd 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc reenterable remaps: don't unnecessarily set `mdi_interrupt` flag * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c978ffd
[16:13:48] <KGB-linuxcnc> 03John Morris 05pr135 44377d8 06linuxcnc 10src/emc/rs274ngc/interp_o_word.cc reenterable remaps: fix epilog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=44377d8
[16:14:54] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #135: Buildbot is working now, you will be able to view results at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4456 02
https://github.com/LinuxCNC/linuxcnc/pull/135#issuecomment-238998997
[17:28:56] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15robEllenberg commented on issue #134: Sure, I see no reason for them not to be GPL 2+. For legal purposes, should
[19:57:57] <jmk-mcfaul_> is there a reason that .gitignore doesn't ignore editor backups? (*~)
[20:01:02] <cradek> no, go ahead and add it
[20:01:25] <cradek> many editors are smart enough to not make backup files when a file is under version control
[20:01:41] <jmk-mcfaul_> is .gitignore part of the repository, or is it repository metadata?
[20:01:51] <cradek> I guess all (both) editors I use have that feature
[20:02:16] <cradek> you change it like any normal file
[20:02:36] <cradek> you could also make an excludes file for your user (affecting all of your gitting)
[20:02:39] <jmk-mcfaul_> so it can be my very first commit (of this decade anyway)
[20:03:26] <cradek> git config core.excludesfile=~/.gitconfig
[20:03:37] <cradek> sure, whichever way you want
[20:07:04] <jmk-mcfaul_> still wrapping my head around git, especially branches
[20:07:41] <jmk-mcfaul_> i have a local branch here, called halonly, the is derived from remote/upstream/jepler/master/halonly
[20:08:06] <jmk-mcfaul_> I just committed to the local branch, I understand that is only on my PC
[20:08:22] <cradek> yes
[20:08:35] <jmk-mcfaul_> to stick it on my github fork of the repository I push, right?
[20:08:59] <cradek> did you initally clone this from github?
[20:09:58] <jmk-mcfaul_> I think so. initially from linuxcnc/linuxcnc, but later re-arranged the remotes to point at jmkasunich/linuxcnc
[20:10:17] <jmk-mcfaul_> machinekit@beaglebone:~/linuxcnc$ git remote -v
[20:10:18] <jmk-mcfaul_> origin
https://github.com/jmkasunich/linuxcnc.git (fetch)
[20:10:18] <jmk-mcfaul_> origin
https://github.com/jmkasunich/linuxcnc.git (push)
[20:10:18] <jmk-mcfaul_> upstream
https://github.com/LinuxCNC/linuxcnc.git (fetch)
[20:10:18] <jmk-mcfaul_> upstream
https://github.com/LinuxCNC/linuxcnc.git (push)
[20:10:33] <jmk-mcfaul_> so I think as long as I push to origin I'm good?
[20:11:23] <cradek> yes I think so. when you're unsure, always try `git push --dry-run' and see if it does what you expect first
[20:11:49] <cradek> also be sure you've signed-off your commit, or our git won't accept it. did you find that instruction?
[20:12:20] <cradek> while you're at it, check author: and committer: on the commit and make sure your name/email are right
[20:12:54] <jmk-mcfaul_> I'm reading the contributing page now (including signed-off-by)
[20:12:56] <cradek> #6 and #7 here:
http://linuxcnc.org/docs/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy
[20:12:59] <cradek> cool
[20:15:24] <cradek> fwiw, you have two ssh keys authorized on git.linuxcnc.org
[20:16:24] <cradek> they have labels john@ke-main-ubuntu and jmkasunich@ubuntu
[20:16:29] <cradek> probably long lost :-)
[20:17:15] <jmk-mcfaul_> thats OK - as I told jepler last night I've been away a long time. I'd rather push to my github repo and submit pull requests so others can review my stuff
[20:18:07] <cradek> sure
[20:18:25] <cradek> I bet it's also smart to become comfortable with github nowadays
[20:18:35] <jmk-mcfaul_> lol
[20:18:36] <cradek> something I should do ... someday
[20:26:08] <jmk-mcfaul_> arg - can't seem to make git commit --amend stick. it opens my editor, I add the signed off by line, save, exit, and nothing
[20:27:51] <cradek> what kind of nothing? that should change the commit and add that line...?
[20:28:48] <jmk-mcfaul_> machinekit@beaglebone:~/linuxcnc$ git log
[20:28:49] <jmk-mcfaul_> commit 601f4c3108dfbb626e388d7d1e625ff6dfefceea
[20:28:49] <jmk-mcfaul_> Author: John Kasunich <jmkasunich@fastmail.fm>
[20:28:49] <jmk-mcfaul_> Date: Wed Aug 10 20:39:02 2016 -0400
[20:28:49] <jmk-mcfaul_> .gitignore - ignore editor backups
[20:28:58] <jmk-mcfaul_> same thing as before the amend
[20:29:56] <cradek> the signed-off-by should show in the long part of the commit log
[20:30:13] <jmk-mcfaul_> duh, which isn't shown by git log
[20:30:31] <cradek> well it depends on the 900 commandline options I'm sure
[20:30:43] <jepler> is your text editor anything unusual? not nano or vim?
[20:31:26] <jmk-mcfaul_> gedit (lame)
[20:32:44] <jepler> did you use gedit to make your initial commit too? what I'm wondering is, some graphical editors like to appear to exit right away, but git needs the editor to wait around in the foreground until you're done editing the commit message and have saved and exited the editor
[20:32:56] <jepler> I don't have gedit here to test how it behaves
[20:33:16] <jmk-mcfaul_> bingo - I wondered why I got a prompt back while the editor was still open
[20:33:32] <jmk-mcfaul_> because the commit itself was trivial I did a one-line message with -m
[20:33:39] <jepler> okay
[20:33:50] <jmk-mcfaul_> I'll switch it to nano
[20:33:56] <cradek> jepler: I would have never guessed that.
[20:34:06] <jepler> cradek: in retrospect I'm surprised it hasn't come up at $DAY_JOB
[20:34:31] <cradek> I bet we no longer have gedit anywhere
[20:34:38] <cradek> but yeah, in the past
[20:38:02] <jmk-mcfaul_> machinekit@beaglebone:~/linuxcnc$ git log -1
[20:38:03] <jmk-mcfaul_> commit 24089f68801b0c4a641eb0ca63fbec392575feea
[20:38:03] <jmk-mcfaul_> Author: John Kasunich <jmkasunich@fastmail.fm>
[20:38:03] <jmk-mcfaul_> Date: Wed Aug 10 20:39:02 2016 -0400
[20:38:03] <jmk-mcfaul_> .gitignore - ignore editor backups
[20:38:03] <jmk-mcfaul_>
[20:38:05] <jmk-mcfaul_> Signed-off-by: John Kasunich <jmkasunich@fastmail.fm>
[20:38:07] <jmk-mcfaul_> more better
[20:39:04] <cradek> yay
[20:39:06] <cradek> looks good
[20:40:12] <jmk-mcfaul_> oh the pain of old things
[20:40:21] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pmcstone opened pull request #136: REMAP of M19 (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/136
[20:40:36] <jmk-mcfaul_> this box is old, github doesn't like the browser
[20:40:47] <jmk-mcfaul_> the bone has a current browser, but is dog slow
[20:40:59] <cradek> haha dog slow
[20:41:15] <jmk-mcfaul_> slow as an old beagle
[20:42:23] <cradek> well that PR just ain't right
[20:42:48] <cradek> Sorry, we could not display the entire diff because too many files (3,634) changed.
[20:44:47] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #137: build: include metadata for Travis CI integration (06master...06travis-test) 02
https://github.com/LinuxCNC/linuxcnc/pull/137
[20:47:14] <jmk-mcfaul_> git is confusing me (what else is new)
[20:47:35] <jmk-mcfaul_> I've pushed my trivial commit, but can't find any sign of it at github
[20:47:59] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #134: @robEllenberg, I think that your permission is sufficient. Thanks for replying, and thanks for the state tags work! 02
https://github.com/LinuxCNC/linuxcnc/issues/134#issuecomment-239051507
[20:48:29] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler closed pull request #136: REMAP of M19 (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/136
[20:50:16] <cradek> I can't find it in your repo either. what did git push say?
[20:52:03] <jmk-mcfaul_> machinekit@beaglebone:~/linuxcnc$ git push origin
[20:52:03] <jmk-mcfaul_> Username for '
https://github.com': jmkasunich
[20:52:03] <jmk-mcfaul_> Password for '
https://jmkasunich@github.com':
[20:52:03] <jmk-mcfaul_> Everything up-to-date
[20:52:28] <cradek> well it didn't push anything
[20:53:15] <jepler> yeah I know what is going on but it's going to take me a minute to decide how to start explaining it
[20:53:20] <jmk-mcfaul_> does "everything up to date" means "I did it, and now everything is up to date", or "everything is up to date, nothing for me to do"?
[20:53:31] <cradek> the latter
[20:53:57] <jmk-mcfaul_> I see
[20:54:17] <jmk-mcfaul_> machinekit@beaglebone:~/linuxcnc$ git status
[20:54:17] <jmk-mcfaul_> # On branch halonly
[20:54:17] <jmk-mcfaul_> # Your branch is ahead of 'upstream/jepler/master/halonly' by 1 commit.
[20:54:17] <jmk-mcfaul_> #
[20:54:17] <jmk-mcfaul_> # Changes not staged for commit:
[20:54:17] <jmk-mcfaul_> # (use "git add <file>..." to update what will be committed)
[20:54:18] <jmk-mcfaul_> # (use "git checkout -- <file>..." to discard changes in working directory)
[20:54:20] <jmk-mcfaul_> #
[20:54:25] <jmk-mcfaul_> # modified: src/hal/drivers/beaglebone_gpio.h
[20:54:25] <jmk-mcfaul_> #
[20:54:30] <jepler> aha that has the information that I was trying to figure out how to get!
[20:54:34] <cradek> yep
[20:54:37] <jepler> see how it says 'your branch is head of 'upstream/...'
[20:54:49] <jepler> so git thinks that you would want to push this branch to upstream, not to origin
[20:56:21] <jepler> I believe you should try this next (it's a dry run so it won't actually do anything): git push --dry-run origin --set-upstream halonly
[20:57:29] <jepler> also I recommend (one time setup): git config --global push.default upstream
[20:59:38] <jmk-mcfaul_> network drop
[20:59:48] <jmk-mcfaul_> don't you mean push.default origin?
[20:59:50] <jmk-mcfaul_> I want to push to jmkasunich
[21:00:31] <jepler> no, confusing collision of terminology
[21:00:38] <jepler> push.default
[21:00:38] <jepler> Defines the action git push should take if no refspec is given on the command line, no refspec is configured in
[21:00:40] <jmk-mcfaul_> I think I just saw it
[21:00:41] <jepler> the remote, and no refspec is implied by any of the options given on the command line. Possible values are:
[21:00:44] <jepler> ...
[21:00:47] <jepler> ยท upstream - push the current branch to its upstream branch.
[21:01:48] <jmk-mcfaul_> I was thinking that "upstream" is the upstream repo as shown by git remote -v
[21:02:06] <jmk-mcfaul_> but "upstream" means something else in this context doesn't it
[21:02:10] <jepler> right
[21:02:46] <jepler> so basically, the "git config" setting means that push (without any extra arguments) means: push the current branch to whereever git thinks it goes
[21:03:12] <jepler> "git push origin" means "push any branch to origin that git thinks is supposed to be pushed to origin", and this doesn't change that
[21:04:06] <jepler> bbiab
[21:05:39] <jmk-mcfaul_> cool, seems to have worked
[21:05:56] <jmk-mcfaul_> now I have another trivial commit (that is actually a bugfix)
[21:06:43] <cradek> if it's a bugfix that's not particular to halonly, you'll want to choose a different branch
[21:06:59] <jmk-mcfaul_> oh boy
[21:07:33] <jmk-mcfaul_> it is a bugfix of the hal_bb_gpio driver that jepler added yesterday
[21:07:45] <jmk-mcfaul_> I dunno if he added it globally or just to the branch
[21:07:46] <cradek> in general for bugfixes, the oldest affected release branch that we still make releases from is the one you want
[21:08:06] <jepler> hal_bb_gpio is still only in the rather misnamed "halonly" branch
[21:08:25] <cradek> yes that is on halonly
[21:08:41] <jmk-mcfaul_> so I can just commit from within that branch
[21:09:00] <jepler> yes
[21:10:47] <jmk-mcfaul_> so, git add to add the modified file, git status to see if I did that right, git diff -i --staged to really see what I'm about to commit, then git commit -s
[21:11:35] <cradek> then git push --dry-run to see what you're going to push ...
[21:11:51] <jepler> you may want to try out the program "git gui" (package name: git-gui), it's nice for preparing a commit
[21:12:31] <cradek> surprisingly, it does some things you really can't do on the commandline at all
[21:13:05] <cradek> in particular "stage these lines"
[21:13:45] <jmk-mcfaul_> you mean if you have multiple changes in one file and only want to commit some of them?
[21:14:02] <jepler> yes
[21:14:13] <jmk-mcfaul_> I'm going to try to avoid that
[21:14:33] <jmk-mcfaul_> I wouldn't want to commit anything that I haven't compiled
[21:14:50] <jmk-mcfaul_> and committing only some lines would do that
[21:15:12] <cradek> that is true
[21:15:33] <jepler> yes although there are incantations for "git, build and run the testsuite for each of these commits in turn"
[21:16:15] <jmk-mcfaul_> I'm going to stay in the shallow end of the pool for a while
[21:17:05] <jmk-mcfaul_> the bug I just fixed is in the machinekit version of the driver as well... I wish I could submit pull requests to both projects
[21:17:29] <cradek> it sure is extra work to do that
[21:18:21] <jmk-mcfaul_> yeah, not going to sweat it right now
[21:19:00] <jmk-mcfaul_> I've learned just enough to be dangerous now, gonna start diving into the gpio driver and try to make it a little more stable
[21:22:20] <jmk-mcfaul_> the bone CPU datasheet has 5041 pages
[21:40:03] <jepler> that is more pages than George R. R. Martin's "A Song of Ice and Fire"'s first 5 volumes, according to wikipedia
[21:41:35] <cradek> I'm impressed there are any coherent docs for it
[21:44:11] <jmk-mcfaul_> why? all IC's need datasheets if the manufacturers want to sell them
[21:44:18] <jmk-mcfaul_> complex ICs need complex datasheets
[21:44:25] <cradek> oh the cpu
[21:44:30] <cradek> I thought you meant for the beagle
[21:44:52] <jmk-mcfaul_> for the beagle, all you need is the schematic (and I have that)
[21:45:11] <jepler> assuming the problem does not reside in some other chip with its own multi-hundred-page datasheet
[21:45:21] <jepler> in ARM one persistent problem is that parts of the datasheets are often secret
[21:45:27] <jmk-mcfaul_> virtually everything on the bone is in the CPU
[21:45:29] <jepler> the GPU typically
[21:46:08] <jmk-mcfaul_> pinmuxes are in chapter 9, GPIO is in chapter 25
[21:46:23] <jmk-mcfaul_> I just hacked the driver to print the values of all 128 pinmuxes
[21:46:30] <jepler> nice
[21:47:00] <jepler> I suspect/worry that at some point, like when dealing with clock gating, that you'll run into "linux excepts to manage that register, and scorns your attempts at trickery"
[21:47:02] <jmk-mcfaul_> now I'm trying to correlate those values with what the pins are (possibly) being used for
[21:47:19] <jepler> like the way both linux and hal write to those LED I/O addresses, but with worse consequences
[21:47:35] <jmk-mcfaul_> probably device tree has its fingers in there
[21:47:55] <jmk-mcfaul_> charles has written some scripts to modify device tree entries
[21:48:06] <jmk-mcfaul_> and the device tree source files are in the machinekit repo
[21:50:11] <jmk-mcfaul_> power, reset, and clock management is chapter 8
[22:18:47] <jmk-mcfaul_> well, I've successfully _read_ the register that controls the clocks - so I can test to see if a bank of GPIO is clocked before I attempt to access it - that should fix the crashes