Back
[06:36:07] <skunkworks> zlog
[08:20:10] <skunkworks> some assembly required
[08:20:12] <skunkworks> http://electronicsam.com/images/matsuura/20160608_185327.jpg
[08:22:59] <archivist> but it looks like it is mounted
[08:29:35] <skunkworks> it is actually together now.. that was when he got the nut re-mounted
[08:32:09] <archivist> you lot are having too much fun :)
[08:34:24] <archivist> although a fly press followed me home last Sunday and it was soon freed up
[08:34:49] <skunkworks> nice
[08:36:21] <archivist> I was surprised how little wear there was
[14:06:22] <mozmck> Is there a way currently to make the error message tell which line of gcode the error was on?
[14:06:54] <cradek> the AXIS preview does that somehow, so yes
[14:07:47] <mozmck> Do you mean that it just shows the last line that was being executed in the preview?
[14:08:03] <cradek> no, it says such-and-such error at line whatever
[14:08:22] <cradek> when you load the program
[14:08:45] <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.
[14:09:11] <mozmck> Ah, ok - I'll dig around in there and see what it will take to make Gscreen do that.
[14:09:20] <cradek> are you saying AXIS doesn't say that?
[14:09:24] <cradek> oh I see
[14:09:35] <cradek> yeah pretty sure it'd say the line number in that situation
[14:19:12] <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.
[14:19:40] <cradek> I think in that case, AXIS would stop with that line showing and highlighted (with the line number next to it)
[14:20:54] <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.
[14:21:42] <cradek> maybe we should make the interp always report it. why not?
[14:21:47] <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.
[14:22:35] <mozmck> That's expected, but could seem strange to a user.
[14:23:21] <cradek> yeah I can imagine some of those situations, and I agree it's expected. you mean srfl, right?
[14:23:39] <mozmck> I think it would be useful a lot of times.
[14:23:55] <mozmck> even normal rfl
[14:24:02] <cradek> hmm
[14:24:24] <mozmck> I would have to go back and do it again, but it had to do with arcs not starting and ending where expected.
[14:24:57] <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.
[14:25:33] <cradek> oh yeah, sure
[14:26:37] <cradek> I can imagine ways to get a totally different/wrong arc too
[14:26:55] <cradek> buyer beware
[15:42:03] <trasz_> guys, i'm trying to port linuxcnc to freebsd, and i've stumbled upon a piece of code i can't figure out.
[15:42:09] <trasz_> it's in src/hal/utils/halcmd_commands.c, "args--; argc++;".
[15:42:17] <trasz_> how could this possibly work? the 'args--', I mean. it seems to me it just moves the pointer back, into unallocated memory.
[15:45:15] <jepler> well, it's that way because getopt() starts at argv[1], not argv[0]
[15:46:34] <cradek> is it crashy on freebsd?
[15:46:45] <trasz_> cradek: yes, due to uninitialized memory.
[15:46:49] <trasz_> jepler: hm. not sure I follow.
[15:47:01] <trasz_> jepler: the usual way to use getopt is to pass it argv and argc.
[15:47:08] <trasz_> jepler: just as the main() takes them.
[15:47:21] <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.
[15:47:38] <cradek> trasz_: on what line does it segfault?
[15:48:31] <trasz_> cradek: later on; the prog_name contains garbage.
[15:48:39] <cradek> (man getopt on freebsd says the same thing about starting on 1)
[15:49:04] <cradek> I don't undersatnd
[15:49:35] <trasz_> well, obviously it does start at 1.
[15:49:46] <trasz_> since argv[0] is binary name, and getopt doesn't need to mess with that.
[15:49:49] <cradek> can you say exactly what you're seeing?
[15:50:53] <trasz_> cradek: the end result is that hal_systemv_nowait() fails, because it tries to execve a string that's binary garbage.
[15:51:36] <cradek> which element of argv is garbage?
[15:51:42] <trasz_> cradek: argv[0].
[15:51:58] <cradek> what halcmd loadusr command did you execute?
[15:52:04] <trasz_> loadrt.
[15:52:16] <jepler> (loadrt calls over to loadusr in the case of uspace realtime)
[15:52:24] <trasz_> it can be 'loadrt meh', for example.
[15:54:16] <trasz_> <stdin>:1: module 'meh' not loaded
[15:54:23] <trasz_> <stdin>:1: execv(���H�=nX): No such file or directory
[15:55:24] <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
[15:55:54] <trasz_> well, obviously, otherwise it wouldn't work for anyone :-)
[15:56:13] <trasz_> still, that's why i'm wondering why you're doing the 'args--;'.
[15:56:40] <jepler> so that getopt's argv[1] is the right thing
[15:56:58] <jepler> does loadusr work?
[15:57:11] <trasz_> wait, so the argv there works in a different way from the system argv?
[15:57:35] <cradek> well for one thing it's null terminated
[15:57:40] <cradek> so there's no argc passed with it
[15:57:58] <cradek> so "args" is not really like argv
[15:58:12] <trasz_> erm, argv is null-terminated too.
[15:58:26] <trasz_> jepler: could you give me some valid module name for loadusr?
[15:58:35] <cradek> (I don't think that's true)
[15:58:48] <cradek> trasz_: loadrt abs
[15:58:48] <jepler> halcmd: loadusr meh
[15:58:51] <jepler> <stdin>:1: execv(meh): No such file or directory
[15:59:06] <jepler> cradek: yes, it is true (main's argv is terminated by a NULL pointer)
[15:59:08] <cradek> oh sorry I misread your question
[15:59:23] <cradek> jepler: oh!
[15:59:43] <trasz_> heh, it fails in a slightly different way: <stdin>:1: execv(loadusr): No such file or directory
[15:59:54] <trasz_> removing the subtraction seems to fix both loadrt and loadusr.
[16:00:33] <trasz_> it might break something else, though, so i'd prefer to understand why it's there in the first place, though.
[16:01:48] <jepler> if it is not there, then getopt will not consider the correct positional argument of loadusr first
[16:03:18] <trasz_> could you give me some example?
[16:03:47] <cradek> hm, the leading + is a GNU extension
[16:06:42] <trasz_> wait, so the args[0] does not contain the program name?
[16:07:37] <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
[16:08:09] <jepler> If I change 'optind = 0' to 'optind = 1' both platforms give the same result
[16:08:41] <jepler> int optind = 1;
[16:09:04] <jepler> but then down in _getopt_internal_r, linux libc has
[16:09:05] <jepler> if (d->optind == 0)
[16:09:05] <jepler> d->optind = 1; /* Don't scan ARGV[0], the program name. */
[16:09:15] <jepler> trasz_: try with 'optind = 1'
[16:10:16] <trasz_> jepler: ok, seems to work.
[16:10:58] <jepler> trasz_: do you use github? if so I would love a pull request for this.
[16:11:46] <trasz_> jepler: ok. but i'd prefer to get some sleep first, tbh :-)
[16:11:56] <jepler> that's fine
[16:12:02] <cradek> trasz_: thanks for working on freebsd, yay
[16:12:04] <trasz_> thanks :-)
[16:12:17] <jepler> yes I would also love to get pull requests for portability improvements
[16:12:29] <trasz_> actually, i have a pretty general question.
[16:12:43] <trasz_> this 'loadrt', what does it load stuff into? i mean, is there some daemon in the background?
[16:12:56] <jepler> yes, with uspace realtime the "realtime" stuff is all in a process called rtapi_app
[16:13:38] <jepler> rtapi_app creates POSIX threads and tries to elevate them to realtime priority, probably a source of non-portability in itself
[16:14:30] <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
[16:14:35] <trasz_> ah, i see it now.
[16:15:30] <trasz_> ok. so, definitely time to get some sleep. see you :-)
[16:15:47] <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
[16:15:56] <jepler> but that is a port to freebsd kernel + GNU userspace (debian kfreebsd)
[16:16:03] <jepler> might be something interesting in there for you though
[16:16:17] <trasz_> thanks; i'll take a look.
[16:16:31] <jepler> oh my, looks like that was 2014
[16:18:46] <jepler> nice talking to you, have a good sleep
[17:01:15] <seb_kuzminsky> uspace on freebsd or kfreebsd/gnu would be great
[17:02:02] <seb_kuzminsky> any objections to this?
https://github.com/LinuxCNC/linuxcnc/pull/65
[17:37:07] <seb_kuzminsky> i think i'm finally getting close to having that task abort bug fixed
[19:14:32] <jepler> seb_kuzminsky: thanks for the reminder, I intended to review that but never did
[19:18:36] <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?
[19:18:48] <jepler> I appreciate that there are only behavioral changes caught by our tests in one case
[19:18:57] <jepler> also M2 F100, maybe should be rejected g-code?
[19:19:12] <jepler> anyway, all that said I didn't spot any problems introduced by the code.
[19:21:13] <seb_kuzminsky> thanks for looking
[19:21:20] <seb_kuzminsky> there's nothing that's critical for 2.6 in those commits
[19:22:11] <seb_kuzminsky> they're all just minor tech-debt things i found while chasing the statbuffer/abort bug zultron reported
[19:22:42] <seb_kuzminsky> the M2 F thing should probably be rejected (in master though)
[19:23:28] <seb_kuzminsky> the M2 F thing looks like a real (though harmless) bug, that one should go in 2.6
[19:24:01] <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
[19:24:14] <seb_kuzminsky> i'll be back after dinner
[19:57:51] <jepler> I should consider finding dinner
[20:24:00] <jepler> hm freebsd doesn't have clock_nanosleep
https://wiki.freebsd.org/FreeBSD_and_Standards#POSIX_2008.1
[20:48:30] <seb_kuzminsky> just replace the system call with a function that ssh'es to a linux box and runs it there
[20:58:22] <jepler> Subject: [ANNOUNCE] 4.6.2-rt5
[21:12:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss b081282 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: doc updates * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b081282
[21:26:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 914f4da 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2_eth: record information so hm2_eth can compute deadlines * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=914f4da
[21:26:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss f414552 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: use read deadline for queued reads * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f414552
[21:26:38] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 05f5696 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hostmot2: introduce "needs_soft_reset" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=05f5696
[21:26:41] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss ce80671 06linuxcnc 10docs/man/man9/hm2_eth.9 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: detect lost reads and writes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ce80671
[21:26:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 83cf336 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: fix array-vs-pointer thinko * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=83cf336
[21:26:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 2ff8c2b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/lbp16.h hm2_eth: make macros more robust * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2ff8c2b
[21:26:54] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 0c4b769 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: read-request-packet is not just a sequence of lbp16_cmd_addr * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0c4b769
[21:26:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 19b2a2e 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h 10src/hal/drivers/mesa-hostmot2/lbp16.h hm2_eth: detect late read packets * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=19b2a2e
[21:27:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 126d307 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: switch from using rxudp count to confirm_write_cnt * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=126d307
[21:27:08] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 52febb5 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: improve docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=52febb5
[21:27:12] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 35d14b7 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: Treat -EAGAIN from hm2_finish_read specially * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=35d14b7
[21:27:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss f04ffde 06linuxcnc 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: fix trivial typo in diagnostic message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f04ffde
[21:27:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss ad3bf04 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid glitches when starting to run * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ad3bf04
[21:27:25] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss 15aa477 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid long wait after lost packet * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=15aa477
[21:27:29] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/eth-packet-loss f581fae 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: doc updates * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f581fae
[21:27:33] <KGB-linuxcnc> 05jepler/master/eth-packet-loss b081282 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b081282
[21:30:33] <jepler> pcw, or anybody else who has tested the packet loss branch: I've rebased the work to be on 2.7, and the branch name has changed accordingly. you'll have to do more steps in git next time you want to play with the newest version of that work.
[21:47:18] <jepler> Now we get to(*) trace the boot process
[21:47:19] <jepler> one sector, one page, one instruction
[21:47:19] <jepler> at a time.
[21:47:19] <jepler> (*) If you replace the words "need to"
[21:47:19] <jepler> with the words "get to," life
[21:47:21] <jepler> becomes amazing.
