Back
[03:09:57] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15trasz opened pull request #66: Use getopt(3) in a way that's compatible with FreeBSD. (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/66
[08:59:51] <trasz_> huh.
[09:00:16] <trasz_> porting is way easier if you disconnect 2/3 of the code from the build by accident.
[09:41:37] <jepler> trasz_: If I work by cherry-picking some of your commits to our master branch, are you comfortable/familiar with how to "git rebase" and continue working?
[09:50:22] <trasz_> jepler: i have no idea how to figure this out, but i'll learn, so it's fine :-)
[09:50:38] <trasz_> now, i got a little further, and could use some help.
[09:50:41] <trasz_> http://pastebin.com/HmDhktxj
[09:52:47] <trasz_> jepler: besides, i'm doing cherrypicking myself, manually; the branch i do 'git submit' from is a different git clone than the one i'm experimenting on.
[09:52:50] <jepler> your build is running to completion now?
[09:52:55] <trasz_> yup.
[09:53:04] <trasz_> i had to comment out a few things, like parport, though.
[09:54:28] <jepler> we have a testsuite in tests/ which is run by scripts/runtests. The next thing I would do is run one of the very simple tests that only involves hal: scripts/runtests tests/and-or-not-mux.0 (from the top dir of the source tree, not in src/)
[09:56:20] <jepler> if that fails, the contents of the files "result" and "stderr" may be helpful
[09:56:33] <jepler> in diagnosing whatever the next problem is
[09:59:11] <trasz_> i'll try that, thanks :-)
[10:00:45] <jepler> - for (n = 0, m = 0; (item = line[m]) != (char) NULL; m++) {
[10:00:45] <jepler> + for (n = 0, m = 0; (item = line[m]) != '\0'; m++) {
[10:00:53] <jepler> you sure are finding and fixing some stupid stuff in our code though, that's great
[10:02:25] <trasz_> it's not me, it's clang :-)
[10:03:49] <jepler> clang didn't submit a pull request so you still get props
[10:04:13] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master 0ff7df3 06linuxcnc 10src/hal/utils/halcmd_commands.c Use getopt(3) in a way that's compatible with FreeBSD. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0ff7df3
[10:04:13] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master 2f55c0a 06linuxcnc 10src/emc/rs274ngc/interp_internal.cc Fix build with clang. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f55c0a
[10:04:13] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master e32c296 06linuxcnc 10src/libnml/os_intf/_sem.c Avoid using SA_ONESHOT to fix build on FreeBSD. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e32c296
[10:05:41] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master e7be16c 06linuxcnc 10(5 files in 5 dirs) Tweak includes to make things build on FreeBSD. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e7be16c
[10:08:28] <trasz_> so, the test hangs waiting on halsampler, in _nanosleep called from hal_stream_wait_readable.
[10:08:53] <jepler> is there an rtapi_app process?
[10:09:54] <jepler> if so, attach with gdb and "thread apply all bt"
[10:09:57] <trasz_> yeah.
[10:10:06] <trasz_> hm, wait. need to check one more thing.
[10:11:50] <trasz_> - clock_nanosleep(CLOCK_MONOTONIC, 0, &delay, NULL);
[10:11:50] <trasz_> + nanosleep(&delay, NULL);
[10:11:53] <trasz_> does this look right?
[10:11:59] <jepler> no, unfortunately not
[10:12:14] <jepler> well let me double check something too
[10:12:36] <jepler> maybe it's OK
[10:12:55] <trasz_> hm, the nanosleep man page in linux says:
[10:12:57] <jepler> we also clock_nanosleep(TIME_ABSTIME)
[10:13:06] <trasz_> POSIX.1 specifies that nanosleep() should measure time against the
[10:13:09] <trasz_> CLOCK_REALTIME clock. However, Linux measures the time using the
[10:13:11] <trasz_> CLOCK_MONOTONIC clock.
[10:13:39] <trasz_> so this should end up the same?
[10:14:57] <jepler> what is the 'delay' argument? is it plausible (say, way under 1s)?
[10:15:08] <jepler> you're looking in the halsampler process, right?
[10:16:28] <jepler> also while in this stuck state, it might be worth looking at the output of 'halcmd show all'
[10:17:11] <jepler> I think it's more likely that the problem is in rtapi_app, it's totally plausible for halsampler to spend most of its time sleeping in hal_stream_wait_readable, particularly if rtapi_app is not working
[10:17:25] <trasz_> jepler: it's 10ms.
[10:17:42] <jepler> basically, we fake up a kind of FIFO in shared memory; one of the things in rtapi_app should be writing into the FIFO, and then halsampler takes the sample off the FIFO and prints it
[10:19:20] <trasz_> jepler: yes, halsampler.
[10:19:36] <trasz_> 'halcmd show all' works, and prints all kinds of stuff; what should i pay attention to?
[10:19:51] <jepler> go ahead and pastebin it
[10:20:44] <jepler> the first think I'm looking for is the information about threads, to get an indication of whether the realtime code seems to be executing
[10:20:56] <jepler> the all-threads backtrace of rtapi_app would be nice for that too
[10:23:17] <trasz_> http://pastebin.com/65XuZm1v
[10:23:43] <jepler> Realtime Threads:
[10:23:43] <jepler> Period FP Name ( Time, Max-Time )
[10:23:43] <jepler> 100000 YES fast ( 0, 0 )
[10:24:02] <jepler> the time numbers are zero, which means the real-time thread has never executed even once
[10:25:10] <trasz_> threads are here:
http://pastebin.com/XZdc3rLy
[10:25:30] <trasz_> and it seems #2 is stopped at another of my clock_nanosleep() changes...
[10:26:11] <jepler> Posix::wait calls clock_nanosleep(RTAPI_CLOCK, TIMER_ABSTIME, &task->nextstart, NULL);
[10:26:29] <jepler> that's the form of clock_nanosleep I was worried about, and the translation to nanosleep is less direct
[10:26:44] <jepler> in this case, the argument is the absolute time for the thread to execute next
[10:27:20] <jepler> so converting that to nanosleep(&task->nextstart, NULL) will be very wrong
[10:27:29] <trasz_> bingo :-)
[10:27:38] <jepler> clock_gettime(RTAPI_CLOCK, &now);
[10:27:56] <trasz_> and subtract?
[10:27:57] <jepler> you know when 'now' is, so you can do arithmetic between now and nextstart to get a relative length of time to sleep
[10:30:45] <trasz_> ok, let me try.
[10:33:27] <trasz_> hm.
[10:33:51] <trasz_> this call, "clock_nanosleep(RTAPI_CLOCK, TIMER_ABSTIME, &task->nextstart, NULL);", shouldn't it be CLOCK_REALTIME?
[10:34:21] <trasz_> ah, nevermind.
[10:36:31] <jepler> we want a clock not affected by "discontinuous jumps in the system time", as the linux clock_gettime manpage puts it
[10:36:43] <jepler> CLOCK_REALTIME doesn't have anything to do with meeting realtime deadlines
[10:45:23] <jepler> afk
[11:06:57] <linuxcnc-build_> build #1347 of 1903.clang-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1903.clang-wheezy-amd64/builds/1347 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:12:17] <linuxcnc-build_> build #3403 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3403 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:17:32] <linuxcnc-build_> build #1346 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/1346 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:20:03] <KGB-linuxcnc> 03Jeff Epler 05master 98fab3a 06linuxcnc 10src/emc/usr_intf/xemc.cc xemc: fix DBL_MAX compile errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=98fab3a
[11:20:34] <jepler> huh I wonder why I didn't observe that locally. no good deed.
[11:28:02] <linuxcnc-build_> build #4192 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4192 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:28:16] <linuxcnc-build_> build #4194 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4194 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:36:08] <linuxcnc-build_> build #2552 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2552 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:42:36] <linuxcnc-build_> build #2353 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2353 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:44:58] <linuxcnc-build_> build #1863 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1863 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:45:44] <linuxcnc-build_> build #2387 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2387 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[11:56:38] <seb_kuzminsky> do we have to rename our project now?
[11:57:10] <seb_kuzminsky> UnixCNC.org is not taken yet
[11:58:20] <linuxcnc-build_> build #2353 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2353 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[12:07:20] <linuxcnc-build_> build #2019 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/2019 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[12:34:56] <linuxcnc-build_> build #4207 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4207 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>
[12:35:07] <jepler> seb_kuzminsky: safe to say there's still work to be done. but if you're an optimist you could always register it.
[12:37:02] <jepler> you'd want permission from the UNIX trademark holder first of course :-P
[12:40:04] <mozmck> non-winCNC
[13:18:02] <KGB-linuxcnc> 05seb/2.6/statbuffer-g5x-abort 5a84454 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5a84454
[15:08:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 4a07c37 06linuxcnc 10src/rtapi/sim_common.h rtapi (sim): flush stdout/stderr after rtapi_print() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a07c37
[15:08:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 fd6e951 06linuxcnc 10src/emc/task/emctaskmain.cc Task: fixup indentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fd6e951
[15:08:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 72dd0e6 06linuxcnc 10src/emc/task/iotaskintf.cc 10src/emc/task/taskclass.cc Task: don't call emcAbortCleanup() in emcIoAbort() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=72dd0e6
[15:08:17] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 b996c77 06linuxcnc 10src/emc/task/emctaskmain.cc Task: don't call emcTaskPlanInit() again * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b996c77
[15:08:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 48daf71 06linuxcnc 10src/emc/task/emctask.cc 10tests/motion-logger/basic/expected.builtin-startup 10tests/motion-logger/mountaindew/expected.motion-logger Task: only turn off the spindle once, when entering Estop * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=48daf71
[15:08:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 eff7f58 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc Interp: consistently set feed rate to 0 on M2/M30 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eff7f58
[15:08:30] <KGB-linuxcnc> 05seb/2.6/task-cleanups eff7f58 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eff7f58
[15:14:57] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #65: Seb/2.6/task cleanups (062.6...06seb/2.6/task-cleanups) 02
https://github.com/LinuxCNC/linuxcnc/pull/65
[16:22:46] <linuxcnc-build_> build #376 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/376 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:08:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/task-abort-fix 3b82074 06linuxcnc 10(6 files) add a test to reproduce the preview-strangeness reported by Zultron * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3b82074
[17:08:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/task-abort-fix 16eec37 06linuxcnc 10(8 files in 2 dirs) add a test of STARTUP_GCODE vs Abort * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=16eec37
[17:08:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/task-abort-fix ba334e3 06linuxcnc 04tests/motion-logger/basic/expected.builtin-startup 03tests/motion-logger/basic/expected.builtin-startup.in 10tests/motion-logger/basic/test.sh tests/motion-logger/basic: allow comments in expected files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ba334e3
[17:08:40] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/task-abort-fix 1b7a523 06linuxcnc 10tests/motion-logger/basic/expected.builtin-startup.in tests/motion-logger/basic: comment 'expected' file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1b7a523
[17:08:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/task-abort-fix 3ad1ea2 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_interp.hh 10src/emc/rs274ngc/rs274ngc_pre.cc interp: move end-of-program cleanup code to its own function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3ad1ea2
[17:08:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/task-abort-fix 991984e 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc 10tests/motion-logger/basic/expected.builtin-startup.in 10tests/motion-logger/mountaindew/expected.motion-logger interp: reset Interp and Canon state on Abort * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=991984e
[17:08:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/task-abort-fix 516deae 06linuxcnc 10src/emc/task/emctaskmain.cc Task: simplify handling of emcCommand * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=516deae
[17:08:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/task-abort-fix 402c27b 06linuxcnc 10(5 files in 3 dirs) Task: add drain_interp_list * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=402c27b
[17:12:50] <seb_kuzminsky> cradek: i think something went wrong with my push
[17:13:28] <seb_kuzminsky> i have some commits at the tip of that branch that i didn't want to include in my push, so first i tried to push $SHA:seb/2.6./task-abort-fix
[17:13:44] <seb_kuzminsky> it failed saying that the seb/2.6/task-abort-fix ref was ambiguous, and to add ref/ to it
[17:13:50] <seb_kuzminsky> so i tried that too, and it also failed
[17:14:13] <seb_kuzminsky> then i moved my local branch pointer to the commit i wanted to be the remote tip (with reset --hard), and that's teh push that went through above
[17:14:27] <seb_kuzminsky> but it said this:
http://paste.debian.net/738012/
[17:14:35] <seb_kuzminsky> and no email went out, and the branch didn't show up on github
[17:15:35] <seb_kuzminsky> the buildbot did get started, which is good
[17:15:50] <seb_kuzminsky> i can fetch the branch from glo but i dont see it on github
[17:16:07] <seb_kuzminsky> it fixes #49 and the statbuffer/abort bug that zultron reported
[17:16:38] <seb_kuzminsky> it's super sketchy and invasive in Task, but it fixes real bugs that people have reported so i think we should take it anyway
[17:16:52] <seb_kuzminsky> i'd appreciate reviews & eyeballs
[17:16:54] <seb_kuzminsky> bbl
[17:18:28] <cradek> the github mirror is periodic, not at push time
[17:19:18] <seb_kuzminsky> ah, ok
[17:19:39] <seb_kuzminsky> oh yeah, there it is
[17:19:56] <cradek> To ssh://github/LinuxCNC/linuxcnc.git
[17:19:56] <cradek> * [new branch] github/seb/2.6/task-abort-fix -> github/seb/2.6/task-abort-fix
[17:20:01] <cradek> just kicked it off
[17:20:09] <cradek> it might take up to 12 minutes normally
[17:20:43] <cradek> gotta run, was on my way out the door
[18:22:23] <linuxcnc-build_> build #377 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/377 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:33:01] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened pull request #67: Seb/2.6/task abort fix (062.6...06seb/2.6/task-abort-fix) 02
https://github.com/LinuxCNC/linuxcnc/pull/67
[20:35:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #67: I reviewed the patch and did not spot any problems. 02
https://github.com/LinuxCNC/linuxcnc/pull/67#issuecomment-225403350
[20:36:07] <jepler> (I had started reviewing before the PR was opened, I'm not that fast)
[20:37:06] <seb_kuzminsky> thx
[21:11:20] <seb_kuzminsky> jepler: that reminds me of an old CS joke:
[21:11:40] <seb_kuzminsky> you can either make your program so simple that there are obviously no bugs, or you can make it so complex that there are no obvious bugs
[21:11:55] <seb_kuzminsky> task is in the second category
[21:11:59] <seb_kuzminsky> bbl ice cream
[21:33:01] <jepler> ooh ice cream