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

Back
[00:02:36] -!- Rob_H [Rob_H!~R@97e42a64.skybroadband.com] has joined #linuxcnc-devel
[00:06:09] -!- Robh__ has quit [Ping timeout: 276 seconds]
[00:14:00] -!- kingarmadillo has quit [Ping timeout: 246 seconds]
[00:16:23] <jepler> looks like a detailed report, hope somebody will be able to look at it
[00:22:03] <skunkworks> I wonder if it is the same issue with slow acceleration...
[00:22:24] <skunkworks> if you put a F0 before the G33 it also fixed it (maybe)
[00:48:59] -!- andypugh has quit [Quit: andypugh]
[00:51:33] -!- Rob_H has quit [Ping timeout: 240 seconds]
[00:55:27] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[00:55:34] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[00:56:23] -!- KimK [KimK!~Kim__@ip68-102-66-31.ks.ok.cox.net] has joined #linuxcnc-devel
[01:06:37] -!- botcrusher has quit [Quit: Page closed]
[01:07:51] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15sleepybishop commented on issue #55: wrt to the exp() function, similar issue, pow() is defined but exp() is not, i think a... 02https://github.com/LinuxCNC/linuxcnc/pull/55#issuecomment-225471427
[01:22:32] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[01:23:12] -!- teepee has quit [Ping timeout: 244 seconds]
[01:23:13] teepee_ is now known as teepee
[01:30:39] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[01:34:02] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #55: http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/2025/steps/compile/logs/stdio... 02https://github.com/LinuxCNC/linuxcnc/pull/55#issuecomment-225467341
[01:35:20] -!- BeachBumPete has quit [Ping timeout: 272 seconds]
[01:42:20] <KGB-linuxcnc> 03Jeff Epler 05sleepybishop-max31855 7781095 06linuxcnc 10src/rtapi/rtapi_math.h rtapi_math: provide declaration for c99-compatible exp() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7781095
[01:57:32] -!- basiclaser has quit [Quit: Connection closed for inactivity]
[02:39:08] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #55: Yes, now the rtai-based systems are happy. @SebKuzminsky what else needs to happen before merging this to master? 02https://github.com/LinuxCNC/linuxcnc/pull/55#issuecomment-225478514
[03:25:17] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #55: The merge is @mozmck's call, he's the release manager for 2.7+1, but it looks good to me.... 02https://github.com/LinuxCNC/linuxcnc/pull/55#issuecomment-225482265
[03:32:27] -!- skunksleep has quit [Ping timeout: 246 seconds]
[03:33:30] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:38:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 05sleepybishop-max31855 75c2329 06linuxcnc 10tests/realtime-math/rtmath.comp tests/realtime-math: test for exp() and nan() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75c2329
[03:43:04] -!- skunksleep has quit [Ping timeout: 264 seconds]
[03:43:37] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:47:49] -!- skunksleep has quit [Ping timeout: 250 seconds]
[03:48:39] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:56:54] -!- skunksleep has quit [Read error: Connection reset by peer]
[04:20:10] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[05:16:28] -!- kwallace1 [kwallace1!~kwallace@162.222.30.254] has parted #linuxcnc-devel
[05:42:32] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #55: After 75c2329b7b6502 i have no reservations. 02https://github.com/LinuxCNC/linuxcnc/pull/55#issuecomment-225493388
[06:22:41] -!- kingarmadillo has quit [Ping timeout: 258 seconds]
[07:31:21] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[07:31:42] -!- sel has quit [Client Quit]
[07:37:48] -!- Mathnerd314 has quit [Ping timeout: 246 seconds]
[08:06:10] -!- b_b has quit [Changing host]
[08:07:29] -!- Miner_48er has quit [Quit: Leaving]
[08:20:13] -!- Rob_H [Rob_H!~R@97e42a64.skybroadband.com] has joined #linuxcnc-devel
[10:21:42] -!- Rob_H has quit [Ping timeout: 276 seconds]
[10:31:44] -!- b_b has quit [Remote host closed the connection]
[10:47:34] -!- skunkworks has quit [Ping timeout: 258 seconds]
[11:41:42] -!- skunkworks [skunkworks!~skunkwork@2600:1008:b11b:f3bb:120b:a9ff:fee7:4918] has joined #linuxcnc-devel
[11:54:15] <jepler> seb_kuzminsky: ooh tests, yay
[12:02:41] <jepler> http://devopsreactions.tumblr.com/post/145850323084/just-returned-from-vacation-git-pull
[12:28:26] -!- Rob_H [Rob_H!~R@97e42a64.skybroadband.com] has joined #linuxcnc-devel
[12:30:45] -!- Robh__ [Robh__!~R@97e42a64.skybroadband.com] has joined #linuxcnc-devel
[12:33:12] -!- Rob_H has quit [Ping timeout: 246 seconds]
[12:41:56] <trasz_> why do we create shmem segments with mode 0666?
[12:42:02] <trasz_> isn't it a litle insecure?
[12:43:46] <jepler> you mean here? src/rtapi/uspace_common.h: shmem->id = shmget((key_t) key, (int) size, IPC_CREAT | 0666);
[12:44:07] <trasz_> yup.
[12:46:40] <jepler> If I thought about it, I bet I erroneously assumed that umask was applied to this mode, just like for open/creat
[12:49:07] <trasz_> it would be the intuitive behaviour, so it obviously doesn't happen with sysv ipc.
[12:49:42] <trasz_> i've just checked, and the http://man7.org/linux/man-pages/man2/umask.2.html explicitly says it doesn't apply to sysv.
[12:49:45] <jepler> Yes, from ipcs I can see the segments actually get 0666 permission
[12:49:58] <jepler> I'll write 0600 and see what breaks in runtests
[12:50:06] <trasz_> thanks :-)
[12:50:43] <trasz_> do you know if there's a reason the shmem segment allocated in rtapi_init isn't freed in rtapi_exit?
[12:50:57] <jepler> .. is there some other non-file-backed shared memory abstraction we should be using?
[12:51:13] -!- skunkworks has quit [Ping timeout: 250 seconds]
[12:51:31] <trasz_> hm. not sure, to be honest.
[12:51:46] <trasz_> i don't yet understand how do you use it, ie what the requirements are.
[12:52:30] <trasz_> but i'd say if sysv ipc works for you, and you already have that working, then why change?
[12:56:47] <jepler> anyway, I don't have a good answer about why this shmem is never destroyed
[12:56:50] <jepler> uuid_mem_id = rtapi_shmem_new(UUID_KEY,uuid_id,sizeof(uuid_data_t));
[12:57:34] <trasz_> okay, so the change i have for this one might be valid :-)
[12:57:46] <trasz_> i could use some github advice, btw.
[12:58:00] <trasz_> i should be pushing all this to a feature branch in my fork, not to my master, right?
[12:58:58] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15trasz closed pull request #66: Use getopt(3) in a way that's compatible with FreeBSD. (06master...06master) 02https://github.com/LinuxCNC/linuxcnc/pull/66
[12:59:57] <jepler> I may not be the best person to give advice about how to use github, but I'll try.
[13:00:26] <jepler> we don't fully use their pull-request workflow in linuxcnc, in part because our real git is still self-hosted
[13:00:53] <jepler> so what has made your stuff easy for me to incorporate is twofold
[13:01:10] -!- b_b has quit [Changing host]
[13:01:20] <jepler> first, your pull request was almost all composed of simple commits that changed one thing and I had no concerns about the way it was done
[13:01:59] <jepler> er, I guess that's really the thing
[13:02:38] <trasz_> ah, so i'm basically doing this properly already?
[13:03:09] <jepler> from my point of view you have done an exemplary job with providing changes I can cherry-pick and put into our git
[13:03:15] <trasz_> ok :-)
[13:10:26] <jepler> initial tests also look OK if deleting uuid_mem_id in rtapi_exit
[13:11:05] <jepler> src/libnml/os_intf/_shm.c: shm->id = shm_open(shm->name, O_RDWR, 0777);
[13:11:08] <jepler> src/libnml/os_intf/_shm.c: shm->id = shm_open(shm->name, oflag | O_RDWR, 0777);
[13:11:17] <jepler> there are a couple more of these to fix however
[13:21:00] <trasz_> according to that man page those should take umask into account.
[13:21:16] <trasz_> still, would be nice to fix it just to be safe.
[13:28:09] <trasz_> jepler: ok, i'm trying to create a new pull request, and it still shows the previous commits. any way around that, or should i just ignore it?
[13:31:38] <mozmck> jthornton, JT-Shop: since you seem to be the asciidoctor expert here, I have some questions if you are around.
[13:32:03] <mozmck> asciidoc that is... one of my questions is about asciidoctor
[13:37:39] <mozmck> jepler, seb_kuzminsky: regarding the github PR #55 for the max31855 - I would think that would be fine in master even if we stop taking new features, since comp files really can't mess up anything else in linuxcnc right?
[13:38:00] -!- skunkworks [skunkworks!~skunkwork@2600:1008:b11b:f3bb:120b:a9ff:fee7:4918] has joined #linuxcnc-devel
[13:38:05] <mozmck> I know we added some comps in 2.7.x
[13:42:48] <mozmck> bbl
[13:49:16] -!- Robh__ has quit [Ping timeout: 258 seconds]
[13:56:37] <cradek> mozmck: I think so far all the RMs have agreed that isolated new drivers/components are ok in the stable branches.
[14:06:00] <jepler> trasz_: that is what "git rebase" can help solve. It will let you move your branch to be based on current linuxcnc master branch, and gets rid of your commit where it is already applied in our master branch.
[14:06:49] <KGB-linuxcnc> 03Jeff Epler 05master 48bd31b 06linuxcnc 10src/rtapi/uspace_common.h uspace: Create shm segment with owner-only permissions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=48bd31b
[14:06:49] <KGB-linuxcnc> 03Jeff Epler 05master 7c0c274 06linuxcnc 10src/rtapi/uspace_common.h uspace: delete the "uuid"(sic) shared memory at exit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7c0c274
[14:06:49] <KGB-linuxcnc> 03Jeff Epler 05master 3934097 06linuxcnc 10src/libnml/buffer/shmem.cc 10src/libnml/os_intf/_shm.c libnml: Create shm segment with owner-only permissions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3934097
[14:08:16] <cradek> I like how this is exposing our closets' skeletons
[14:08:32] <KGB-linuxcnc> 03Jeff Epler 05master 5a81a49 06linuxcnc 10src/rtapi/rtapi_math.h Merge remote-tracking branch 'origin/sleepybishop-max31855' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5a81a49
[14:09:54] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler closed pull request #55: add bitbang spi driver for the max31855 thermocouple to digital conve… (06master...06max31855) 02https://github.com/LinuxCNC/linuxcnc/pull/55
[14:27:32] -!- basiclaser has quit [Quit: Connection closed for inactivity]
[14:38:21] <trasz_> jepler: ok, i'll try.
[14:39:17] <trasz_> jepler: now: in regression tests, what makes sure that rtapi_app exits before the next test begins?
[14:40:31] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[14:45:51] <jepler> trasz_: "halcmd unload all" is supposed to
[14:47:02] <trasz_> hm.
[14:54:09] <seb_kuzminsky> trasz_: the "realtime" script waits for the last rtapi_app to die
[14:54:19] <seb_kuzminsky> 77918d27a8d
[14:54:55] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[14:56:14] <trasz_> huh.
[14:56:40] <trasz_> so, it looks like the shmem segments can linger for a moment, after the rtapi_app exits.
[15:02:05] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[15:03:19] <trasz_> hm, i'd rather avoid having to fix _that_.
[15:04:12] -!- ivansanchez has quit []
[15:06:13] -!- joekline9 [joekline9!4917529f@gateway/web/freenode/ip.73.23.82.159] has joined #linuxcnc-devel
[15:06:55] <seb_kuzminsky> iirc we looked as some ways to release the shm during rtapi_app_exit in the master, and decided it was too invasive for our stable branch, and this bandaid was the compromise
[15:07:51] <seb_kuzminsky> it seems like it should be possible to explicitly free up the resources that matter during the master's exit, and use acquisition of those resources rather than presence of the process itself as the definitive check for whether rtapi_app is up
[15:08:08] <trasz_> i suspect even those might not fix the problem here.
[15:08:23] <jepler> is it possible it's just the has-rtapi_app-exited detection is wrong for trasz_ ?
[15:08:51] <trasz_> i mean, i think when the process exits it "disappears" from ps output _before_ the shmem segments get destroyed.
[15:09:18] <trasz_> hm, in fact i can easily test that.
[15:11:16] <joekline9> ?
[15:12:13] <joekline9> how do I report an issue with ver 2.7 and G33 ?
[15:13:58] <trasz_> jepler: the detection itself works, the problem is that it's possible that the segments stay there for a while after the rtapi_app exited.
[15:14:11] <cradek> joekline9: https://github.com/LinuxCNC/linuxcnc/issues/68 is a really good bug report, thank you for doing it
[15:14:41] <joekline9> ok
[15:14:50] <seb_kuzminsky> joekline9: trasz_ that's... disturbing
[15:15:20] <seb_kuzminsky> joekline9: yeah, #68 is a good report
[15:15:25] <trasz_> jepler: how about adding "halcmd busy", that simply shows "1" or "0", and using that instead of pidof?
[15:16:36] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[15:17:00] -!- joekline9 has quit [Quit: Page closed]
[15:21:52] <seb_kuzminsky> trasz_: how would 'halcmd busy' be implemented?
[15:21:53] <trasz_> jepler: or just use "halcmd -s show comp | wc -l" and see if it's > 2 (1 for connected halcmd, 1 for newline).
[15:23:39] -!- archivist has quit [Ping timeout: 246 seconds]
[15:25:52] <trasz_> seb_kuzminsky: i believe the problem i'm seeing is caused by the fact that the state - as shown by "halcmd show" - can exist for a fraction of second after rtapi_app has exited; and it messes up subsequent setexact_for_test_suite_only in the regression script that's run next.
[15:29:52] <seb_kuzminsky> do you know if you can observe the presence of the haldata shm while there is no rtapi_app in the process listing?
[15:33:26] <trasz_> seb_kuzminsky: yes.
[15:33:52] <trasz_> but it's even weirder.
[15:34:36] -!- the_wench [the_wench!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[15:35:50] <trasz_> bin/halcmd loadrt threads; bin/halcmd unload all; ps auxwww | grep rtapi_app; ipcs -a
[15:35:56] <trasz_> this is what i'm doing.
[15:36:29] <trasz_> however, i thought if i see the segments still there, they get removed just a moment later.
[15:36:32] <trasz_> they don't.
[15:36:44] <trasz_> they get removed when i do "halcmd show".
[15:37:11] <jepler> that's interesting
[15:37:12] <trasz_> so basically, exiting the rtapi_app sometimes clears them, and sometimes doesn't.
[15:37:33] <jepler> we have a scheme where the last closer of a segment is supposed to destroy it
[15:37:40] <jepler> there may be a race condition in there or something
[15:38:13] <jepler> /* destroy the shared memory */
[15:38:13] <jepler> r2 = shmctl(shmem->id, IPC_STAT, &d);
[15:38:13] <jepler> if(r2 == 0 && d.shm_nattch == 0) {
[15:38:13] <jepler> r2 = shmctl(shmem->id, IPC_RMID, &d);
[15:38:13] <jepler> }
[15:38:20] <jepler> having unmapped the memory, we check if the number of attachments is zer0
[15:38:24] <jepler> zero
[15:38:25] <jepler> if it is, we actually remove the segment
[15:39:00] <trasz_> where does the stderr of rtapi_app go?
[15:39:18] <jepler> it's a good clue that it's running halcmd that makes them disappear, I'm just not 100% sure what it means yet.
[15:39:18] <trasz_> i've added some error reporting in that piece of code.
[15:39:38] <jepler> but I assume you'll find that the number of attachments is somehow not 0 at any of the times rtapi_shmem_delete is called
[15:39:42] -!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[15:39:44] <trasz_> fwiw, ipcs shows NATTCH 0 for those.
[15:41:31] <jepler> I assume the segment is HAL_KEY 0x48414C32 ?
[15:42:41] <trasz_> there are two: 1212238898 (the above) and 1212697652.
[15:43:12] <jepler> that's UUID_KEY 0x48484c34
[15:45:51] <jepler> I wish this problem showed up on linux :-/
[15:46:26] <jepler> it may be that it's time to change uspace so that it works in one way more like the old kernel-module-model realtime
[15:46:38] <jepler> .. rtapi_app has to be running before anything else, and has to be shut down after everything else
[15:46:55] <jepler> .. so it doesn't have to carefully keep counts of shared memory segments, it can just delete (IPC_RMID) them at exit
[15:47:45] <KGB-linuxcnc> 05sleepybishop-max31855 75c2329 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75c2329
[15:54:31] <trasz_> jepler: do you know where does the stderr of rtapi_app go?
[15:55:33] <jepler> hm I would have said to terminal but I must be wrong
[15:55:42] <seb_kuzminsky> i'm on debian jessie and i'm also seeing the shm segments persist past the lifetime of the last rtapi_app fwiw
[15:55:55] <seb_kuzminsky> trasz_: it depends how you run it, i think
[15:56:09] <trasz_> hm.
[15:56:14] <seb_kuzminsky> the launcher script named "linuxcnc" puts it in a tmp file and copies it to your home at the end
[15:56:25] <jepler> seb_kuzminsky: hm, okay ... then I wonder why we don't see the overt misbehavior that seems to be related, namely that the testsuite gets lots of failures about "setexact_for_testsuite_only" being run after the creation of a thread?
[15:56:48] <seb_kuzminsky> trasz_: our logging is a bit of a mess :-/
[15:56:53] <jepler> at least I think that's why trasz_ is looking into this
[15:57:33] <seb_kuzminsky> jepler: maybe we just get lucky in the race?
[15:57:37] * seb_kuzminsky handwaves
[16:01:54] <jepler> maybe so
[16:02:45] <trasz_> seb_kuzminsky: actually, the realtime script doesn't seem to wait for rtapi_app to die.
[16:02:53] <trasz_> seb_kuzminsky: it checks, and if it's still running, it exits.
[16:03:58] <seb_kuzminsky> i'm looking at the loop commented "wait 5 seconds ..." in Unload(), it looks right to me
[16:04:04] <seb_kuzminsky> did we get something backwards?
[16:04:43] <trasz_> ah.
[16:04:52] <trasz_> i was looking at CheckStatus.
[16:08:11] <seb_kuzminsky> right, the intent of CheckStatus is to see if realtime is currently up and running, so that's right
[16:08:25] <seb_kuzminsky> the intent of Unload is to stop realtime and not return until realtime is gone, so that's right too
[16:08:42] <seb_kuzminsky> modulo this "lingering shm" problem
[16:17:09] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-posix-spawn 4307524 06linuxcnc 10src/hal/utils/halcmd.c halcmd: posix_spawnv makes running subprocesses easier * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4307524
[16:18:07] <jepler> (that ^^ works on uspace so I want buildbot to tell me if it works on rtai)
[16:25:17] -!- skunkworks has quit [Ping timeout: 250 seconds]
[16:38:01] <trasz_> okay.
[16:38:05] <trasz_> down to two failing tests.
[16:38:53] <seb_kuzminsky> wow
[16:38:56] <jepler> which two?
[16:41:29] <trasz_> hm2-idrom - which fails because i've commented out everything hm2 for now, because it didn't build - and symbols.0.
[16:41:55] <trasz_> erm, and tests/linuxcncrsh-tcp. no idea what's wrong with this one.
[16:42:25] <trasz_> apart from a cryptic "linuxcncrsh: invalid option -- i
[16:44:04] <jepler> symbols.0 is testing that one component can use a function exported by another component
[16:44:28] <seb_kuzminsky> trasz_: that linuxcncrsh error is a meaningless red herring
[16:44:53] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[16:45:05] <jepler> we do a bit of funny business with the linker in the rule for making ../rtlib/%.so, around Makefile:966
[16:45:53] <jepler> basically, only symbols named in the .rtapi_export section are supposed to be visible in the resulting .so
[16:47:25] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[16:54:26] <jepler> looks like I should change uspace realtime to use POSIX timers (timer_create et al) and it could simplify the code and be more portable to where clock_nanosleep isn't available
[16:54:34] <jepler> not sure how robust your workaround for that is
[16:54:40] <jepler> but it looks like timer_* are in freebsd
[16:55:02] -!- pcw_home has quit [Remote host closed the connection]
[16:56:20] -!- mal`` has quit [Ping timeout: 244 seconds]
[17:05:45] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[17:06:20] -!- teepee has quit [Ping timeout: 272 seconds]
[17:06:23] teepee_ is now known as teepee
[17:08:16] amnesic_away is now known as amnesic
[17:15:01] wtsmer is now known as remstw
[17:32:12] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[17:32:13] <trasz_> okay, i somehow managed to introduce a merge conflict with my own repo, and am kind of fed up with git atm; can someone take a look at https://github.com/LinuxCNC/linuxcnc/commit/84f5b59ebe5cefa635f4308c43e83b3371b836c5 and https://github.com/LinuxCNC/linuxcnc/commit/59d542606e53457745f176ed3d8f9d9b6388fc8e?
[17:33:29] <skunkworks_> zlog
[17:33:29] <zlog> skunkworks_: Log stored at http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-06-13.html
[17:37:43] <seb_kuzminsky> trasz_: in https://github.com/LinuxCNC/linuxcnc/commit/59d542606e53457745f176ed3d8f9d9b6388fc8e, the last hunk uses ifndef while the others use ifdef, so it took me a second to get the sense of the compare right, i'd prefer consistency
[17:38:20] <seb_kuzminsky> also, use rtapi_print_msg() instead of perror(), see the block just above the one you changed
[17:40:00] <seb_kuzminsky> the other commit looks good
[17:51:01] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[17:54:18] -!- mal`` [mal``!~mal``@68.ip-149-56-14.net] has joined #linuxcnc-devel
[17:56:51] <trasz_> seb_kuzminsky: ok, i'll fix that.
[17:57:22] <seb_kuzminsky> cool
[17:57:37] <seb_kuzminsky> was that really all it took to get it to build on FreeBSD? pretty amazing
[18:09:30] <trasz_> seb_kuzminsky: nah.
[18:09:40] <trasz_> seb_kuzminsky: i'm pushing the cleaned up parts.
[18:09:54] <trasz_> seb_kuzminsky: there's lot of ugly stuff, mostly to the autotools.
[18:10:13] <trasz_> seb_kuzminsky: i need to get that to a more... civilised shape before i push it.
[18:10:14] <seb_kuzminsky> hah right
[18:10:30] <seb_kuzminsky> do you have all the runtests passing now? can you run Axis?
[18:11:30] <seb_kuzminsky> it might be fun to add a freebsd machine to the buildbot
[18:11:44] <seb_kuzminsky> to ensure we don't break it, after all your hard work
[18:11:56] <seb_kuzminsky> are you using freebsd 11?
[18:12:33] <trasz_> yes, i'm running 11, yes, i can run axis and run job in simulation mode, no, a few tests are still failing, working on it :-)
[18:12:41] <seb_kuzminsky> sweet
[18:13:17] <cradek> wow, what numbers does the latency test show?
[18:13:19] <seb_kuzminsky> huh, it's handy that freebsd.org publishes their releases in qcow format (among others)
[18:13:34] <cradek> q
[18:14:00] <seb_kuzminsky> :wq
[18:14:18] <cradek> need focus-follows-eyes
[18:14:28] <seb_kuzminsky> ;-)
[18:15:14] <trasz_> cradek: they are quite bad, hadn't started to work on that yet.
[18:16:18] <skunkworks_> uspace or rtai? both?
[18:16:24] <trasz_> uspace.
[18:16:25] <seb_kuzminsky> must be uspace
[18:16:34] <seb_kuzminsky> the rtai patch is only for linux afaik
[18:16:42] <skunkworks_> bad is relative then.. ;)
[18:16:52] <skunkworks_> <100us?
[18:17:20] <trasz_> no, _bad_.
[18:17:34] <trasz_> like, max jitter 61471278 ns.
[18:17:37] <skunkworks_> heh
[18:17:42] <skunkworks_> puch
[18:17:45] <skunkworks_> ouch
[18:17:57] <trasz_> but the whole realtime stuff is disabled at the moment, if i understand it correctly.
[18:18:10] <trasz_> so, no SCHED_FIFO etc.
[18:18:59] <cradek> is your eventual goal to run hardware with freebsd+linuxcnc?
[18:20:01] <trasz_> yes.
[18:20:11] <cradek> yay!
[18:20:35] <trasz_> after i'm done with cleaning up and pushing the changes i'll have to write a libgpio backend, and figure out what's wrong with SCHED_FIFO.
[18:20:44] <skunkworks_> Your most likely going to need external hardware like mesa then with rt_prempt.
[18:21:09] <skunkworks_> you're
[18:21:17] <trasz_> well, for now the plan is to try with some rather smaller first.
[18:21:20] <trasz_> arm-based.
[18:21:28] <trasz_> and see how that works.
[18:23:19] <trasz_> hm, i wonder if i could just bind a thread to one core, and replace delays with busyloops with time measurement inside; that should keep the jitter reasonably low :-)
[18:25:54] <cradek> argh I should really update all my freebsd9 machines
[18:26:02] <cradek> and also the (sigh) older ones
[18:33:10] <jepler> trasz_: untested, but I think I would like to see something more like this for working around the clock_nanosleep difference: http://paste.ubuntu.com/17301720/
[18:33:44] <jepler> we're not going to get out with some #ifdefs, but I think that #ifdefs that encompass the whole function body are better than #ifdefs in the middle of a function
[18:33:49] -!- Robh__ [Robh__!~R@97e42a64.skybroadband.com] has joined #linuxcnc-devel
[18:36:00] <trasz_> jepler: i like it :-)
[18:36:29] <jepler> and actually once we end up with a whole raft of functions whose implementations are different on linux vs freebsd, we can just use separate source files instead
[18:37:14] <trasz_> yup.
[18:37:39] <trasz_> jepler: this symbols.0 test.
[18:38:07] <trasz_> jepler: which function is that?
[18:39:24] <trasz_> jepler: i mean, one of them declares - but not defines - testuse(), and calls it from FUNCTION(_), whatever it is.
[18:39:27] <jepler> hm actually it may be the opposite of what I said
[18:39:53] <trasz_> jepler: and the other defines testdefine(), and doesn't do anything with testuse().
[18:40:17] <jepler> it still has to do with symbol visiblity between components, but this test is checking that a symbol that is not EXPORT_SYMBOL is *not* available
[18:40:32] <jepler> what's in your "stderr" file after the test fails?
[18:40:47] <jepler> #!/bin/sh
[18:40:48] <jepler> grep -q 'test_use: dlopen: .*: undefined symbol: testuse' `dirname $1`/stderr \
[18:40:50] <jepler> || dmesg | grep -q 'test_use: Unknown symbol testuse'
[18:40:59] <trasz_> ah, stupid me.
[18:41:13] -!- LawrenceG [LawrenceG!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[18:44:47] <jepler> I should add a description of those tests in their READMEs. http://paste.ubuntu.com/17302207/
[18:46:02] <trasz_> okay, symbols.0 works good now.
[18:46:14] <trasz_> basically a little different error message.
[18:46:53] <jepler> after I looked at checkresult I was tempted to bet that was the case
[18:47:51] -!- kingarmadillo has quit [Read error: Connection reset by peer]
[18:48:38] <trasz_> after i was reminded to look at checkresult that was my bet too :-)
[18:48:49] <trasz_> especially given i've already fixed one or two such problems today.
[19:02:40] <trasz_> can somebody show me a valid - ie passing - stderr from linuxcncrsh-tcp?
[19:03:15] amnesic is now known as amnesic_away
[19:14:58] <jepler> hold on
[19:15:01] <cradek> one sec, it's big
[19:15:44] -!- LawrenceG has quit [Remote host closed the connection]
[19:16:43] <jepler> https://emergent.unpythonic.net/files/sandbox/linuxcncrsh-tcp-stderr https://emergent.unpythonic.net/files/sandbox/linuxcncrsh-tcp-result
[19:17:05] <cradek> he's faster than me
[19:17:21] <jepler> hm did I make these with one of my not very tested changes? HAL: ERROR: Component 'halcmd13818' already ready
[19:20:36] <trasz_> jepler: thanks :-)
[19:30:28] -!- kingarmadillo has quit [Ping timeout: 264 seconds]
[19:31:47] -!- Connor has quit [Read error: Connection reset by peer]
[19:32:49] -!- Connor [Connor!~Connor@c-67-187-108-117.hsd1.tn.comcast.net] has joined #linuxcnc-devel
[19:36:32] <trasz_> the Submakefile files are hand-written or generated by autotools?
[19:36:43] <cradek> hand
[19:37:22] <trasz_> ok.
[19:37:23] <CaptHindsight> J.F.C. a guberment lab just asked if we could make Linuxcnc run on Winders
[19:37:30] <trasz_> another question: does this diff make any sense? http://pastebin.com/Urmri56P
[19:37:42] <trasz_> it fixes build with clang.
[19:38:02] <jepler> typedef struct setup_struct
[19:38:06] <jepler> { ... } setup;
[19:39:07] <jepler> typedef struct setup_struct setup;
[19:39:11] <jepler> typedef setup *setup_pointer;
[19:39:15] <jepler> my head is spinning by now
[19:42:15] <jepler> the other alternative is to get rid of the typedef
[19:42:51] <jepler> http://paste.ubuntu.com/17304414/
[19:45:19] -!- Robh__ has quit [Quit: Leaving]
[19:45:20] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[19:48:12] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #49: Seb, I've verified the fix for 2.6. Nice work!... 02https://github.com/LinuxCNC/linuxcnc/issues/49#issuecomment-225687774
[19:52:21] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[19:59:47] amnesic_away is now known as amnesic
[19:59:49] <cradek> heh, your paste isn't very useful
[20:00:05] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[20:00:50] <jepler> oops!
[20:01:13] <jepler> http://paste.ubuntu.com/17304996/
[20:04:24] -!- skunkworks has quit [Ping timeout: 244 seconds]
[20:08:02] <trasz_> would it be ok if I've added -ldl to LDFLAGS in the main Makefile and removed it from Submakefiles?
[20:08:14] <trasz_> the rationale is that there's no -ldl under FreeBSD.
[20:08:50] <jepler> not every target using LDFLAGS needs -ldl though
[20:09:19] <jepler> can you change them to $(LIBDL) and make a configure test so that LIBDL expands to either -ldl or nothing based on platform?
[20:10:04] <trasz_> hm, that should work.
[20:22:51] -!- b_b has quit [Remote host closed the connection]
[20:28:22] amnesic is now known as amnesic_away
[20:37:06] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[20:53:18] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[21:14:14] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:43:59] <andypugh> Still fiddling with multiple spindles. It’s big. The assumption that there can be only one is implicit in so many places. Currently looking in emcsh.cc
[21:53:26] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[22:03:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-posix-spawn 7c76d93 06linuxcnc 10src/hal/utils/halcmd.c 10src/hal/utils/halcmd_commands.c halcmd: posix_spawnv makes running subprocesses easier * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7c76d93
[22:03:10] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[22:04:14] <jepler> > Each 6 months, the new release (Gtk 4.2, Gtk 4.4, Gtk 4.6) will break API and ABI vs. the release that came before it.
[22:04:17] <jepler> they. are. nuts.
[22:04:19] <jepler> https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
[22:05:35] <andypugh> jepler: Switch to, err, that other thing I can’t recall the name of?
[22:06:08] <jepler> motif?
[22:09:58] <andypugh> Not what I was thinking of. cncbasher likes it.
[22:10:49] <jepler> openlook?
[22:11:12] <jepler> er excuse me, OPEN LOOK
[22:11:40] <jepler> sorry, if you're being serious I am guessing Qt is what she would have mentioned.
[22:18:19] <andypugh> That’s the one. I know nothing about it, but is it more stable?
[22:19:11] amnesic_away is now known as amnesic
[22:22:50] <JT-Shop> he likes QT
[22:22:56] <JT-Shop> I think
[22:28:49] -!- kalxas has quit [Quit: Goodbye]
[22:30:26] <mozmck> Qt is supposed to be really good. I haven't used it yet, but am definitely interested in using it.
[22:30:56] <mozmck> the gtk folks have been doing this since 3.0
[22:31:47] <JT-Shop> I tried QT a few times but never got very far... have to learn C++ first
[22:32:15] <mozmck> even Linus switched to qt for his diving software - and he is not known for being a c++ fan ;-)
[22:34:01] <mozmck> Well, if you can learn python with it's classes and all, you can learn c++ I'm sure.
[22:34:19] <mozmck> JT-Shop: have you looked at asciidoctor?
[22:34:54] <JT-Shop> yes I have and did a page on my web site with it because you could tell it to open a link in a new page
[22:35:30] <mozmck> how does it compare to asciidoc? They claim it is up to 25 times faster.
[22:35:45] <JT-Shop> went for a ride on the road bike and realized I need a summer bike shirt and shorts
[22:35:52] <mozmck> It also has a direct to pdf plugin as well.
[22:36:04] <JT-Shop> it looks the same to me just has a few more things
[22:36:14] <JT-Shop> I didn't try that
[22:36:40] <mozmck> I suppose our docs go to docbook first and then pdf?
[22:37:04] <JT-Shop> it's magic I think
[22:37:07] <mozmck> I don't know if the asciidoctor pdf plugin is as good or not, but I may play with it.
[22:37:28] <JT-Shop> and you must be careful or you will upset them lol
[22:37:37] <JT-Shop> let me know if it works
[22:37:51] <mozmck> So do you still like asciidoc pretty well? I am looking at trying it for some of our stuff.
[22:37:57] <JT-Shop> I don't even look at the pdf docs any more I prefer the html version
[22:38:32] <JT-Shop> asciidoc works and we know how to use it
[22:38:47] <JT-Shop> I think there is still an issue with formulas
[22:39:09] <mozmck> I see. Is that the main issue you know of?
[22:39:55] <JT-Shop> that and you can't make a link open in a new tab
[22:40:05] <mozmck> There is an asciidoc editor that uses MathJax to render formulas: http://asciidocfx.com/
[22:41:00] <mozmck> I see. That would be nice, but for my stuff it probably won't matter much.
[22:41:51] <jepler> mozmck: I think that markdown is roughly comparable to asciidoc in what it can do, but it is more popular as a markup language right now
[22:42:06] <jepler> for instance, github uses markdown for README files, wikis, etc
[22:42:11] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[22:42:27] <jepler> popular static blogging engines like jekyll choose markdown as their primary language
[22:42:28] -!- teepee has quit [Ping timeout: 244 seconds]
[22:42:29] teepee_ is now known as teepee
[22:42:40] <mozmck> jepler: I'm looking at making 100+ page manuals with it, and from what I've read markdown is far inferior.
[22:43:37] <mozmck> https://medium.com/@chacon/living-the-future-of-technical-writing-2f368bd0a272#.9a1k8kwn5
[22:46:41] <mozmck> I've also read several projects looking at moving away from markdown for technical docs because of the limitations.
[22:47:11] <skunkworks> there was a big discussion about markdown and other options... I didn't pay much attention...
[22:47:25] <skunkworks> heh - machinekit
[22:48:02] <mozmck> regarding qt vs gtk: http://www.phoronix.com/scan.php?page=news_item&px=MTU2ODM and also https://www.youtube.com/watch?v=ON0A1dsQOV0
[22:48:34] <mozmck> from the above article, "the biggest problem with GTK is the attitude of the core community."
[22:49:29] <skunkworks> I mainly read the list to see how snotty mah answers everyone's questions..
[22:49:32] <jepler> I wouldn't listen to phoronix guy when it comes to saying how attitude affects community
[22:49:54] <jepler> that site is chock full of attitude
[22:50:26] <jepler> mozmck: is pdf / print an important target for your manuals?
[22:50:27] <JT-Shop> http://www.twistedhobbys.com/TH-32-EPP-Edge-540-GH-RCF-32-Edge-540-GH.htm
[22:50:33] <JT-Shop> watch the video
[22:51:02] <JT-Shop> opps wrong channel
[22:51:17] <jepler> is there another video showing what would happen if I tried to fly it?
[22:51:37] <JT-Shop> well we can make one if you like
[22:51:38] <jepler> *wobbles forward for about 3s* *crashes into ground*
[22:52:00] <JT-Shop> then he gets the glue out and 5 min later flying again
[22:52:36] <JT-Shop> that kind of plane you don't worry about crashing
[22:52:43] <JT-Shop> it's foam
[22:56:26] <seb_kuzminsky> playing with freebsd 11 (their equivalent to debian testing, i think) for half a day sure makes me appreciate debian stable
[22:56:50] <mozmck> jepler: yes, pdf is the main output format now. My boss does the manuals currently in *CorelDraw*!
[22:57:55] <mozmck> Another option would be to use LibreOffice, but I don't think it is a nice for exporting html
[22:58:01] <JT-Shop> manuals in CorelDraw?
[22:58:13] <mozmck> yes, some up to 200 pages
[22:58:44] <mozmck> I don't consider it to be the best tool for that :-)
[23:00:50] <mozmck> heh, re phoronix - I don't read it much, but saw that looking for the stuff I had seen about Dirk and Linus switching to Qt from Gtk. The quote was from Dirk Hohndel.
[23:00:59] <JT-Shop> looks like ligreoffice will save as html
[23:02:02] <PCW> is that a cross between tigeroffice and lionoffice?
[23:02:25] <JT-Shop> been a long hot day for me... heading inside and switching on the magnet on the couch
[23:02:36] <JT-Shop> kinda
[23:02:47] <JT-Shop> typing without looking really
[23:03:10] <JT-Shop> the b is close to the g lol
[23:05:25] <mozmck> it will save is html, but I wasn't real happy with the results last time I tried. I should look at it again though.
[23:06:44] <jepler> markdown's most important target is definitely HTML, moreso than asciidoc, latex, etc
[23:07:24] <jepler> you might look at lyx, it makes excellent PDFs. its HTML output was weak, back in the day when we used it
[23:07:43] <jepler> (to the point that I wrote my own lyx -> html toolchain, which we no longer use; I suspect they have done something better in the last 8 years or so for HTML)
[23:07:59] <jepler> lyx gets you a GUI editor, and you get latex's strengths with layout for print targets
[23:08:24] <mozmck> hmm, yes, I've used lyx a little bit.
[23:08:57] <mozmck> http://asciidocfx.com/ looks like a pretty good GUI editor for asciidoc
[23:09:01] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[23:09:32] <mozmck> And it will output to latex as well. But the formatting capability may not be as good.
[23:10:52] <jepler> I think our PDFs use an asciidoc -> latex -> pdf chain of translation
[23:11:41] <jepler> there's also the asciidoctor fork(?) of asciidoc; I think asciidoc development is very slow at this point
[23:11:43] <mozmck> I see this in synaptic for lyx->html http://alexfernandez.github.io/elyxer/
[23:11:54] <jepler> http://asciidoctor.org/docs/user-manual/#asciidoctor-s-most-notable-benefits
[23:11:56] <mozmck> Yes, I downloaded asciidoctor
[23:12:36] <jepler> looks like it's maybe a fully independent implementation, ruby vs python
[23:12:48] <jepler> I see asciidoctor is in debian jessie
[23:12:58] <mozmck> Yes. They claim it's 25 times faster than the python version
[23:12:59] <jepler> of course with linuxcnc we have trailing edge problems when it comes to our choices of doc toolchain
[23:13:11] <jepler> i.e., what can we choose that exists on 8-year-old platforms, ugh
[23:13:29] <mozmck> yeah, at least I don't have that for what I need to do.
[23:14:07] <mozmck> You can install ruby and get asciidoctor via "gem install asciidoctor" and get the latest one.
[23:14:26] <jepler> yeah, but that's no good for building the linuxcnc package
[23:14:40] <jepler> .. that should be a network-free process, after installing debian packages according to build-depends
[23:15:13] <mozmck> some debian packages download things from other sites and install them ;-)
[23:15:23] <mozmck> not that I'm suggesting we should do that though.
[23:15:28] <jepler> yeah those are bad packages and should feel bad
[23:16:06] <jepler> you mean packages like apt itself, right?
[23:16:09] <mozmck> bbl - supper time.
[23:16:28] <mozmck> No, things like ttf_mscorefonts or whatever it's called.
[23:17:11] <mozmck> I don't know if that's in debian though...
[23:17:46] <jepler> ttf-mscorefonts-installer is in "contrib", which is an indication that it doesn't fully live up to the requirements of debian "main"
[23:18:05] <jepler> since it downloads files that are not redistributable
[23:19:07] <jepler> >> This package is not part of the Debian GNU/Linux system but located in
[23:19:11] <jepler> the contrib section. This is because it's not functional in and of itself
[23:19:14] <jepler> but depends on downloading the fonts which are not under a free licence.
[23:37:38] -!- gaute has quit [Ping timeout: 250 seconds]
[23:44:01] -!- Tom_L [Tom_L!~Tom@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[23:44:23] -!- Tom_L has quit [Client Quit]