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

Back
[00:17:52] -!- calvinmetcalf has quit [Ping timeout: 264 seconds]
[00:17:52] -!- almccon_ has quit [Ping timeout: 264 seconds]
[00:18:28] -!- SkramX has quit [Ping timeout: 264 seconds]
[00:19:04] -!- AphelionZ has quit [Ping timeout: 264 seconds]
[00:28:04] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:45:31] <skunkworks> zlog
[00:45:31] <zlog> skunkworks: Log stored at http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-06-09.html
[00:47:05] <seb_kuzminsky> jepler: https://github.com/LinuxCNC/linuxcnc/commit/fb7e668d46c90894c57257a3df8b14cced8ed95a
[00:47:18] <seb_kuzminsky> does that one fix this? https://github.com/LinuxCNC/linuxcnc/issues/62
[01:43:22] <jepler> seb_kuzminsky: yes. I proposed the change to linuxcncmodule, dewey apparently found it good and added the change so the tests passed
[01:43:40] <seb_kuzminsky> great
[01:43:42] <jepler> I hadn't considered whether adding the abort would change the output of motion logger!
[01:43:46] <seb_kuzminsky> do you want to close it or should i?
[01:44:06] <jepler> that commit is not in master branch, so I don't think closing it is appropriate
[01:46:04] <seb_kuzminsky> maybe open should cause task to abort first? otherwise i might have broken the other UIs...
[01:47:27] <jepler> that commit ad06db2 was all about what axis/linuxcncmodule do, not sure other UIs matter
[01:48:56] <seb_kuzminsky> seb trying to play with Task: http://i.imgur.com/vJ1PWkS.gif
[01:49:13] <skunkworks> did you see
[01:49:15] <skunkworks> https://youtu.be/zq7rbsMW5ic
[01:49:44] -!- kingarma1illo has quit [Ping timeout: 250 seconds]
[01:49:50] <skunkworks> from
[01:49:51] <skunkworks> https://forum.linuxcnc.org/forum/20-g-code/27040-g71-g70-cycle-for-lathes-first-tests
[01:50:16] <seb_kuzminsky> hhnnnnngggggh
[01:50:54] <skunkworks> is that good or bad>
[01:50:56] <skunkworks> ?
[01:51:45] <jepler> it is doing a lathe feature someone wants, using remap? without looking, that seems dandy if it's robust
[01:54:12] -!- linuxcnc-build_ has quit [Ping timeout: 244 seconds]
[01:54:28] -!- KGB-wlo has quit [Ping timeout: 264 seconds]
[01:54:52] -!- seb_kuzminsky has quit [Ping timeout: 260 seconds]
[01:54:53] -!- hm2-buildmaster_ has quit [Ping timeout: 260 seconds]
[01:59:41] -!- skunksleep has quit [Ping timeout: 240 seconds]
[02:10:50] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:38:01] -!- GABY1 has quit [Ping timeout: 240 seconds]
[03:00:52] -!- skunksleep has quit [Ping timeout: 272 seconds]
[03:01:30] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:24:18] -!- skunksleep has quit [Ping timeout: 272 seconds]
[03:24:39] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:36:51] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[03:38:34] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@174-29-175-6.hlrn.qwest.net] has joined #linuxcnc-devel
[03:38:48] -!- KGB-wlo [KGB-wlo!~kgb-wlo@174-29-175-6.hlrn.qwest.net] has joined #linuxcnc-devel
[03:39:20] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@174-29-175-109.hlrn.qwest.net] has joined #linuxcnc-devel
[03:40:24] -!- hm2-buildmaster_ [hm2-buildmaster_!~hm2-build@174-29-175-163.hlrn.qwest.net] has joined #linuxcnc-devel
[03:40:40] -!- linuxcnc-build_ [linuxcnc-build_!~linuxcnc-@174-29-175-163.hlrn.qwest.net] has joined #linuxcnc-devel
[03:43:15] -!- KGB-wlo has quit [Ping timeout: 246 seconds]
[03:43:21] -!- seb_kuzminsky [seb_kuzminsky!~seb@174-29-175-163.hlrn.qwest.net] has joined #linuxcnc-devel
[03:43:21] -!- mode/#linuxcnc-devel [+v seb_kuzminsky] by ChanServ
[03:43:21] -!- linuxcnc-build has quit [Ping timeout: 276 seconds]
[03:43:41] -!- hm2-buildmaster has quit [Ping timeout: 240 seconds]
[03:49:58] -!- KGB-wlo [KGB-wlo!~kgb-wlo@174-29-175-163.hlrn.qwest.net] has joined #linuxcnc-devel
[04:06:30] -!- mozmck has quit [Quit: Leaving.]
[05:07:23] -!- Miner_48er has quit [Quit: Leaving]
[06:06:19] -!- kwallace [kwallace!~kwallace@162.222.30.254] has parted #linuxcnc-devel
[06:56:50] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[06:57:06] -!- teepee has quit [Ping timeout: 272 seconds]
[06:57:06] teepee_ is now known as teepee
[06:58:31] -!- Mathnerd314 has quit [Ping timeout: 244 seconds]
[08:59:54] -!- skunksleep has quit [Ping timeout: 276 seconds]
[09:06:07] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[09:14:35] -!- skunksleep has quit [Ping timeout: 244 seconds]
[09:15:52] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[09:53:41] -!- skunkworks has quit [Ping timeout: 240 seconds]
[10:26:38] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[10:48:41] -!- skunksleep has quit [Ping timeout: 240 seconds]
[11:09:28] <skunkworks> zlog
[11:09:28] <zlog> skunkworks: Log stored at http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-06-10.html
[11:45:24] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[12:23:16] -!- kingarmadillo has quit [Ping timeout: 272 seconds]
[12:49:07] -!- mozmck [mozmck!~moses@67.210.159.94] has joined #linuxcnc-devel
[12:53:31] <skunkworks> some assembly required
[12:53:32] <skunkworks> http://electronicsam.com/images/matsuura/20160608_185327.jpg
[12:56:19] <archivist> but it looks like it is mounted
[13:02:55] <skunkworks> it is actually together now.. that was when he got the nut re-mounted
[13:05:30] <archivist> you lot are having too much fun :)
[13:07:44] <archivist> although a fly press followed me home last Sunday and it was soon freed up
[13:08:09] <skunkworks> nice
[13:09:41] <archivist> I was surprised how little wear there was
[13:26:16] -!- kingarmadillo has quit [Ping timeout: 264 seconds]
[13:56:22] -!- tobias47n9e_ has quit [Ping timeout: 272 seconds]
[14:01:02] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[14:05:52] -!- ve7it has quit [Remote host closed the connection]
[14:16:55] amnesic_away is now known as amnesic
[14:56:36] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[15:08:26] -!- ivansanchez has quit []
[15:33:53] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[15:37:03] -!- skunkworks has quit [Ping timeout: 276 seconds]
[15:37:28] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[16:09:20] -!- tjtr33 [tjtr33!~tomp@cm-171-100-107-6.revip10.asianet.co.th] has joined #linuxcnc-devel
[16:41:47] -!- mozmck has quit [Read error: Connection reset by peer]
[16:44:04] -!- mozmck [mozmck!~moses@67.210.159.94] has joined #linuxcnc-devel
[17:16:25] -!- radish has quit [Ping timeout: 260 seconds]
[17:16:41] -!- tjtr33 has quit [Ping timeout: 240 seconds]
[17:48:40] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[18:39:42] <mozmck> Is there a way currently to make the error message tell which line of gcode the error was on?
[18:40:14] <cradek> the AXIS preview does that somehow, so yes
[18:41:08] <mozmck> Do you mean that it just shows the last line that was being executed in the preview?
[18:41:23] <cradek> no, it says such-and-such error at line whatever
[18:41:42] <cradek> when you load the program
[18:42:05] <mozmck> I had a guy with a file that would not show in the preview, and when I clicked run it just said something like "Nested Comment found" It would be nice if it told the line it found that on.
[18:42:31] <mozmck> Ah, ok - I'll dig around in there and see what it will take to make Gscreen do that.
[18:42:40] <cradek> are you saying AXIS doesn't say that?
[18:42:44] <cradek> oh I see
[18:42:55] <cradek> yeah pretty sure it'd say the line number in that situation
[18:52:32] <mozmck> Some messages are generated in linuxcnc, such as "G38.2 move finished without making contact". I guess you would generally know where you are with that one though.
[18:53:00] <cradek> I think in that case, AXIS would stop with that line showing and highlighted (with the line number next to it)
[18:54:14] <mozmck> Yes, that's what my gui does too. I have seen several though where it would be nice if it said what line had the error.
[18:55:02] <cradek> maybe we should make the interp always report it. why not?
[18:55:08] <mozmck> Oh, run-from-line done in the wrong place can give errors, but the actual error may be from a line a ways down from where you told it to start.
[18:55:56] <mozmck> That's expected, but could seem strange to a user.
[18:56:41] <cradek> yeah I can imagine some of those situations, and I agree it's expected. you mean srfl, right?
[18:57:00] <mozmck> I think it would be useful a lot of times.
[18:57:15] <mozmck> even normal rfl
[18:57:21] <cradek> hmm
[18:57:45] <mozmck> I would have to go back and do it again, but it had to do with arcs not starting and ending where expected.
[18:58:17] <mozmck> I think if you rfl and the next move is a G2/3, but the machine is not located at the right place to start the arc, it gives that error.
[18:58:53] <cradek> oh yeah, sure
[18:59:57] <cradek> I can imagine ways to get a totally different/wrong arc too
[19:00:15] <cradek> buyer beware
[19:45:12] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[19:59:04] -!- tobias47n9e__ has quit [Ping timeout: 240 seconds]
[20:00:25] amnesic is now known as amnesic_away
[20:15:07] -!- trasz_ [trasz_!~trasz@hackerspace.pl] has joined #linuxcnc-devel
[20:15:23] <trasz_> guys, i'm trying to port linuxcnc to freebsd, and i've stumbled upon a piece of code i can't figure out.
[20:15:30] <trasz_> it's in src/hal/utils/halcmd_commands.c, "args--; argc++;".
[20:15:37] <trasz_> how could this possibly work? the 'args--', I mean. it seems to me it just moves the pointer back, into unallocated memory.
[20:18:35] <jepler> well, it's that way because getopt() starts at argv[1], not argv[0]
[20:19:53] <cradek> is it crashy on freebsd?
[20:20:05] <trasz_> cradek: yes, due to uninitialized memory.
[20:20:09] <trasz_> jepler: hm. not sure I follow.
[20:20:21] <trasz_> jepler: the usual way to use getopt is to pass it argv and argc.
[20:20:29] <trasz_> jepler: just as the main() takes them.
[20:20:41] <cradek> man getopt(3) says: The variable optind is the index of the next element to be processed in argv. The system initializes this value to 1.
[20:20:58] <cradek> trasz_: on what line does it segfault?
[20:21:51] <trasz_> cradek: later on; the prog_name contains garbage.
[20:21:59] <cradek> (man getopt on freebsd says the same thing about starting on 1)
[20:22:24] <cradek> I don't undersatnd
[20:22:55] <trasz_> well, obviously it does start at 1.
[20:23:06] <trasz_> since argv[0] is binary name, and getopt doesn't need to mess with that.
[20:23:09] <cradek> can you say exactly what you're seeing?
[20:24:13] <trasz_> cradek: the end result is that hal_systemv_nowait() fails, because it tries to execve a string that's binary garbage.
[20:24:56] <cradek> which element of argv is garbage?
[20:25:03] <trasz_> cradek: argv[0].
[20:25:18] <cradek> what halcmd loadusr command did you execute?
[20:25:25] <trasz_> loadrt.
[20:25:36] <jepler> (loadrt calls over to loadusr in the case of uspace realtime)
[20:25:44] <trasz_> it can be 'loadrt meh', for example.
[20:27:36] <trasz_> <stdin>:1: module 'meh' not loaded
[20:27:44] <trasz_> <stdin>:1: execv(���H�=nX): No such file or directory
[20:28:44] <jepler> that is not what occurs on linux, but it sure could be due to some thing that is not guaranteed by the relevant standards
[20:29:14] <trasz_> well, obviously, otherwise it wouldn't work for anyone :-)
[20:29:33] <trasz_> still, that's why i'm wondering why you're doing the 'args--;'.
[20:30:00] <jepler> so that getopt's argv[1] is the right thing
[20:30:18] <jepler> does loadusr work?
[20:30:31] <trasz_> wait, so the argv there works in a different way from the system argv?
[20:30:55] <cradek> well for one thing it's null terminated
[20:31:00] <cradek> so there's no argc passed with it
[20:31:18] <cradek> so "args" is not really like argv
[20:31:32] <trasz_> erm, argv is null-terminated too.
[20:31:47] <trasz_> jepler: could you give me some valid module name for loadusr?
[20:31:55] <cradek> (I don't think that's true)
[20:32:08] <cradek> trasz_: loadrt abs
[20:32:08] <jepler> halcmd: loadusr meh
[20:32:11] <jepler> <stdin>:1: execv(meh): No such file or directory
[20:32:26] <jepler> cradek: yes, it is true (main's argv is terminated by a NULL pointer)
[20:32:28] <cradek> oh sorry I misread your question
[20:32:43] <cradek> jepler: oh!
[20:33:03] <trasz_> heh, it fails in a slightly different way: <stdin>:1: execv(loadusr): No such file or directory
[20:33:14] <trasz_> removing the subtraction seems to fix both loadrt and loadusr.
[20:33:53] <trasz_> it might break something else, though, so i'd prefer to understand why it's there in the first place, though.
[20:35:08] <jepler> if it is not there, then getopt will not consider the correct positional argument of loadusr first
[20:36:38] <trasz_> could you give me some example?
[20:37:06] <cradek> hm, the leading + is a GNU extension
[20:40:02] <trasz_> wait, so the args[0] does not contain the program name?
[20:40:57] <jepler> this program runs for me on linux and crashes on freebsd (9.2-RELEASE-p3). I wonder whether it is getting at the problem or off on a tangent: https://emergent.unpythonic.net/files/sandbox/one_before.c
[20:41:29] <jepler> If I change 'optind = 0' to 'optind = 1' both platforms give the same result
[20:42:01] <jepler> int optind = 1;
[20:42:25] <jepler> but then down in _getopt_internal_r, linux libc has
[20:42:25] <jepler> if (d->optind == 0)
[20:42:25] <jepler> d->optind = 1; /* Don't scan ARGV[0], the program name. */
[20:42:35] <jepler> trasz_: try with 'optind = 1'
[20:43:36] <trasz_> jepler: ok, seems to work.
[20:44:18] <jepler> trasz_: do you use github? if so I would love a pull request for this.
[20:45:06] <trasz_> jepler: ok. but i'd prefer to get some sleep first, tbh :-)
[20:45:17] <jepler> that's fine
[20:45:22] <cradek> trasz_: thanks for working on freebsd, yay
[20:45:24] <trasz_> thanks :-)
[20:45:37] <jepler> yes I would also love to get pull requests for portability improvements
[20:45:49] <trasz_> actually, i have a pretty general question.
[20:46:03] <trasz_> this 'loadrt', what does it load stuff into? i mean, is there some daemon in the background?
[20:46:17] <jepler> yes, with uspace realtime the "realtime" stuff is all in a process called rtapi_app
[20:46:58] <jepler> rtapi_app creates POSIX threads and tries to elevate them to realtime priority, probably a source of non-portability in itself
[20:47:51] <jepler> so halcmd loadrt invokes rtapi_app, which sends a message to another rtapi_app if it is already running to actually do the loading of the component
[20:47:55] <trasz_> ah, i see it now.
[20:48:50] <trasz_> ok. so, definitely time to get some sleep. see you :-)
[20:49:07] <jepler> also I don't know if you saw this but several years ago I worked on sort of the same thing, it's bitrotting in branch [origin/]jepler/kfreebsd
[20:49:17] <jepler> but that is a port to freebsd kernel + GNU userspace (debian kfreebsd)
[20:49:23] <jepler> might be something interesting in there for you though
[20:49:38] <trasz_> thanks; i'll take a look.
[20:49:51] <jepler> oh my, looks like that was 2014
[20:52:06] <jepler> nice talking to you, have a good sleep
[21:11:36] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:30:04] -!- radish has quit [Ping timeout: 240 seconds]
[21:30:28] -!- pozzoni has quit [Ping timeout: 264 seconds]
[21:34:35] <seb_kuzminsky> uspace on freebsd or kfreebsd/gnu would be great
[21:35:23] <seb_kuzminsky> any objections to this? https://github.com/LinuxCNC/linuxcnc/pull/65
[21:43:39] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[21:54:01] -!- kalxas has quit [Quit: Goodbye]
[22:10:28] <seb_kuzminsky> i think i'm finally getting close to having that task abort bug fixed
[22:17:08] -!- penpen has quit [Quit: Leaving.]
[22:44:01] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[23:02:35] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[23:02:46] -!- teepee has quit [Ping timeout: 244 seconds]
[23:02:47] teepee_ is now known as teepee
[23:09:43] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[23:12:47] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[23:41:21] -!- radish has quit [Ping timeout: 240 seconds]
[23:47:52] <jepler> seb_kuzminsky: thanks for the reminder, I intended to review that but never did
[23:51:02] amnesic_away is now known as amnesic
[23:51:56] <jepler> seb_kuzminsky: do you think these changes are good ground-work to help us fix other bugs (like maybe #49), in which case it might make sense for 2.6? or is it just paying down technical debt, in which case it would be better to put it on master so there's longer for any introduced problems to become apparent before they affect users?
[23:52:08] <jepler> I appreciate that there are only behavioral changes caught by our tests in one case
[23:52:18] <jepler> also M2 F100, maybe should be rejected g-code?
[23:52:33] <jepler> anyway, all that said I didn't spot any problems introduced by the code.
[23:54:33] <seb_kuzminsky> thanks for looking
[23:54:40] <seb_kuzminsky> there's nothing that's critical for 2.6 in those commits
[23:55:31] <seb_kuzminsky> they're all just minor tech-debt things i found while chasing the statbuffer/abort bug zultron reported
[23:56:02] <seb_kuzminsky> the M2 F thing should probably be rejected (in master though)
[23:56:48] <seb_kuzminsky> the M2 F thing looks like a real (though harmless) bug, that one should go in 2.6
[23:57:21] <seb_kuzminsky> the others could go in 2.6 too (i think they're safe improvements) or in master, i don't have a strong feeling either way
[23:57:34] <seb_kuzminsky> i'll be back after dinner