Back
[00:15:42] -!- lerman has quit [Remote host closed the connection]
[00:15:58] -!- lerman [lerman!~lerman@24-151-1-146.static.nwtn.ct.charter.com] has joined #linuxcnc-devel
[00:18:26] -!- patrickarlt has quit [Remote host closed the connection]
[00:20:05] -!- patrickarlt has quit [Remote host closed the connection]
[00:38:21] -!- nofxx has quit [Ping timeout: 255 seconds]
[00:39:08] -!- jdqx has quit [Quit: Leaving]
[00:48:24] -!- Loetmichel has quit [Ping timeout: 264 seconds]
[00:54:12] -!- lerman has quit [Remote host closed the connection]
[00:56:04] -!- lerman [lerman!~lerman@24-151-1-146.static.nwtn.ct.charter.com] has joined #linuxcnc-devel
[01:09:46] -!- r0ute has quit [Ping timeout: 240 seconds]
[01:12:26] -!- anarchos2 has quit [Read error: Connection reset by peer]
[01:12:44] -!- anarchos2 [anarchos2!~mike@S010600259ce59399.vn.shawcable.net] has joined #linuxcnc-devel
[01:12:49] <skunkworks> PID USER PR NI VIRT RES SHR S PU %MEM TIME+ COMMAND
[01:12:50] <skunkworks> 19675 skunkwo+ 20 0 1161644 749496 26016 S 76.9 18.6 200:06.70 axis
[01:16:44] -!- zeeshan-mill has quit [Ping timeout: 244 seconds]
[01:20:29] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[01:20:54] -!- just_pink has quit [Ping timeout: 246 seconds]
[01:21:18] just_pink_ is now known as just_pink
[01:21:47] -!- capricorn_1 has quit [Ping timeout: 250 seconds]
[01:23:31] -!- Mr_Sheesh has quit [Remote host closed the connection]
[01:24:33] -!- tannewt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[01:29:10] -!- Roguish has quit [Quit: ChatZilla 0.9.91.1 [Firefox 39.0/20150630154324]]
[01:33:46] -!- Mr_Sheesh has quit [Changing host]
[01:35:09] -!- stelicho has quit [Quit: Lost terminal]
[01:35:45] -!- Mr_Sheesh has quit [Remote host closed the connection]
[01:36:18] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[01:40:25] <cradek> what the heck
[01:42:42] -!- AR_ has quit [Read error: Connection reset by peer]
[01:45:39] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[01:49:07] <skunkworks> big prigram
[01:49:50] <cradek> oh it's working how you expect?
[01:51:22] -!- Mr_Sheesh has quit [Remote host closed the connection]
[01:54:18] <skunkworks> i think so ;)
[01:54:46] <skunkworks> 78000inhes
[01:54:53] <skunkworks> inches
[01:55:02] <cradek> jeez
[01:56:24] <Tom_itx> is that with rob's recent fix?
[01:56:59] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[01:57:04] -!- Mr_Sheesh has quit [Remote host closed the connection]
[01:58:10] -!- Mr_Sheesh has quit [Changing host]
[02:01:09] -!- Mr_Sheesh has quit [Remote host closed the connection]
[02:01:59] -!- lerman has quit [Remote host closed the connection]
[02:07:40] -!- Mr_Sheesh has quit [Excess Flood]
[02:08:49] <cradek> this kind of thing is a really good test:
https://www.youtube.com/watch?v=d8IgJFfTqME
[02:10:25] <Tom_itx> that or a 3d surface with lots of short moves
[02:12:13] <Tom_itx> that looks like mostly planar moves
[02:12:23] <Tom_itx> or 'waterline'
[02:13:50] -!- almostworking has quit [Ping timeout: 265 seconds]
[02:13:58] -!- Mr_Sheesh has quit [Remote host closed the connection]
[02:13:59] <Tom_itx> still probably alot of shorter moves..
[02:21:30] -!- Mr_Sheesh has quit [Excess Flood]
[02:21:58] -!- anth0ny_ has quit [Quit: anth0ny_]
[02:25:01] -!- arekm has quit [Ping timeout: 246 seconds]
[02:32:50] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[02:33:37] -!- mpmckenna8 has quit [Read error: No route to host]
[02:33:44] -!- SpeedEvil has quit [Changing host]
[02:35:38] -!- mpmckenna8 has quit [Client Quit]
[02:50:09] -!- tchaddad has quit []
[02:52:00] -!- AR_ has quit [Ping timeout: 255 seconds]
[03:20:56] -!- anth0ny_ has quit [Quit: anth0ny_]
[03:26:34] -!- LikeVinyl has quit [Quit: LikeVinyl]
[03:30:42] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[03:37:50] -!- anarchos2 has quit [Read error: Connection reset by peer]
[03:38:23] -!- anarchos2 [anarchos2!~mike@S010600259ce59399.vn.shawcable.net] has joined #linuxcnc-devel
[03:47:58] -!- skunksleep has quit [Ping timeout: 246 seconds]
[03:55:02] -!- ve7it has quit [Remote host closed the connection]
[03:55:34] -!- patrickarlt has quit [Remote host closed the connection]
[03:56:40] -!- zeeshan-mill has quit [Ping timeout: 272 seconds]
[03:59:39] -!- anth0ny_ has quit [Client Quit]
[04:16:35] -!- mal`` has quit [K-Lined]
[04:18:36] -!- sumpfralle has quit [Quit: Leaving.]
[04:19:29] -!- mal`` [mal``!~mal``@105.ip-167-114-152.net] has joined #linuxcnc-devel
[04:34:18] -!- FinboySlick has quit [Quit: Leaving.]
[04:57:54] -!- xrr has quit [Quit: No Ping reply in 180 seconds.]
[05:05:09] -!- jdqx has quit [Quit: Leaving]
[05:29:29] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[05:56:46] -!- arekm_ has quit [Ping timeout: 244 seconds]
[06:03:31] -!- furrywolf has quit [Ping timeout: 246 seconds]
[06:13:35] -!- LatheBuilder has quit [Quit: Leaving]
[06:15:05] -!- kwallace [kwallace!~kwallace@142.147.85.210] has parted #linuxcnc-devel
[06:27:07] -!- teepee has quit [Ping timeout: 256 seconds]
[06:28:28] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[06:31:02] -!- tchaddad has quit [Remote host closed the connection]
[06:44:29] DJ9DJ is now known as Deejay
[07:03:54] -!- bkboggy has quit [Quit: Leaving]
[07:10:26] -!- LikeVinyl has quit [Quit: LikeVinyl]
[07:17:31] -!- rob_h [rob_h!~robh@90.208.149.243] has joined #linuxcnc-devel
[07:29:08] -!- ivansanchez has quit [Read error: Connection reset by peer]
[07:30:13] -!- mozmck has quit [Read error: Connection reset by peer]
[07:33:30] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[07:33:54] -!- ivansanchez has quit [Ping timeout: 244 seconds]
[07:36:35] -!- tchaddad has quit [Ping timeout: 252 seconds]
[07:37:46] -!- ivansanchez has quit [Remote host closed the connection]
[07:38:25] -!- ivansanchez has quit [Remote host closed the connection]
[07:55:06] -!- ivansanchez has quit [Remote host closed the connection]
[08:00:14] -!- ivansanchez has quit [Client Quit]
[08:04:58] -!- ivansanchez has quit [Remote host closed the connection]
[08:20:48] -!- Mr_Sheesh has quit [Ping timeout: 264 seconds]
[08:22:15] -!- tocka has quit [Client Quit]
[08:30:04] -!- tlab has quit [Quit: Leaving]
[08:50:35] -!- b_b has quit [Changing host]
[09:04:49] -!- asdfasd1 has quit [Read error: Connection reset by peer]
[09:05:10] -!- asdfasd has quit [Ping timeout: 246 seconds]
[09:57:28] Loetmichel2 is now known as Loetmichel
[10:09:53] -!- b_b has quit [Remote host closed the connection]
[10:24:24] -!- skunkworks has quit [Ping timeout: 244 seconds]
[10:41:06] -!- carper [carper!~carper@host86-142-93-254.range86-142.btcentralplus.com] has joined #linuxcnc-devel
[11:00:40] -!- awallin [awallin!awallin@lakka.kapsi.fi] has joined #linuxcnc-devel
[11:03:12] -!- anarchos2 has quit [Read error: Connection reset by peer]
[11:03:55] -!- anarchos2 [anarchos2!~mike@S010600259ce59399.vn.shawcable.net] has joined #linuxcnc-devel
[11:20:22] <carper> thinking of building a cnc cam/spindle grinder at some point in the next 12 months about the size of a 9 x 36 lathe using a slant bed with hybrid steppers/encoders with an autoprobing to. can anyone see any problems with the idea? i just dont want to start the bad practice of using a machine post grider on my cnc lathe.
[11:20:53] <carper> https://www.sherlinedirect.com/index.cfm?fuseaction=product.display&Product_ID=1032
[11:21:30] <carper> grinder
[11:28:38] <carper> upps wrong room
[11:49:26] <KGB-linuxcnc> 03John Thornton 052.7 c0d55e5 06linuxcnc 10docs/src/Master_Documentation.txt 10docs/src/Master_Getting_Started.txt 10docs/src/index.tmpl Docs: make the html and pdf docs include all chapters * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c0d55e5
[11:49:26] <KGB-linuxcnc> 03John Thornton 052.7 ad3328b 06linuxcnc 10(75 files in 9 dirs) Docs: move files from the common directory that are no longer common. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ad3328b
[11:49:26] <KGB-linuxcnc> 03John Thornton 052.7 d11a828 06linuxcnc 10docs/src/gui/axis.txt Docs: add info on axisui pins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d11a828
[11:53:59] -!- carper has quit [Quit: Leaving]
[12:03:09] -!- terinjokes has quit [Ping timeout: 256 seconds]
[12:10:14] -!- lerman [lerman!~lerman@24-151-1-146.static.nwtn.ct.charter.com] has joined #linuxcnc-devel
[12:12:11] <linuxcnc-build> build #1666 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1666 blamelist: John Thornton <bjt128@gmail.com>
[12:20:15] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:20:32] -!- lerman has quit [Remote host closed the connection]
[12:20:51] -!- lerman [lerman!~lerman@24-151-1-146.static.nwtn.ct.charter.com] has joined #linuxcnc-devel
[12:26:32] <linuxcnc-build> build #3325 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3325 blamelist: John Thornton <bjt128@gmail.com>
[12:31:37] -!- MacGalempsy has quit [Remote host closed the connection]
[12:35:46] <skunkworks> That would be really cool to be able to select the reatlime at boot time on the livecd.
[12:40:01] -!- skunkworks_ [skunkworks_!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:59:31] -!- tchaddad has quit [Remote host closed the connection]
[13:02:00] -!- b_b has quit [Changing host]
[13:02:57] -!- nofxx has quit [Ping timeout: 265 seconds]
[13:12:01] -!- carper [carper!~carper@host86-142-93-254.range86-142.btcentralplus.com] has joined #linuxcnc-devel
[13:15:40] -!- zz has quit [Quit: Leaving...]
[13:22:15] <skunkworks> building (make and make setuid) seems like it would take a boot a long time..
[13:23:49] -!- MacGalempsy has quit [Remote host closed the connection]
[13:28:09] -!- MattyMatt has quit [Ping timeout: 256 seconds]
[13:28:37] -!- patrickarlt has quit [Remote host closed the connection]
[13:35:12] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[13:35:40] -!- patrickarlt has quit [Remote host closed the connection]
[13:38:04] -!- PetefromTn_ [PetefromTn_!~IceChat9@75-136-59-160.dhcp.jcsn.tn.charter.com] has joined #linuxcnc-devel
[13:39:30] -!- tchaddad has quit [Remote host closed the connection]
[13:40:14] -!- Valen has quit [Remote host closed the connection]
[13:42:27] -!- carper has quit []
[13:55:45] -!- carper [carper!~carper@host86-142-93-254.range86-142.btcentralplus.com] has joined #linuxcnc-devel
[14:00:49] asheppard is now known as sheppard
[14:03:12] -!- kwallace [kwallace!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[14:03:36] -!- tchaddad has quit [Remote host closed the connection]
[14:13:52] -!- DaPeace has quit [Ping timeout: 250 seconds]
[14:17:16] <cradek> yeah getting the multiple kernels on the cd is easy. getting the corresponding linuxcnc installed is hard
[14:18:07] <cradek> I think making it easy to switch between the versions, just using apt in a normal way, is the most important goal
[14:31:19] <seb_kuzminsky> wow, the halui/mdi test fails often now
[14:31:45] <jepler> nobody's touching that stuff, why would it get worse?
[14:32:06] <seb_kuzminsky> last one touching it was... me, early july
[14:32:51] <seb_kuzminsky> i was trying to fix occasional failures we were having, guess it didnt work
[14:36:40] <seb_kuzminsky> there's a bad behavior in halui in several places, where it tries to do something, and if it fails it doesn't print a message about it
[14:38:12] <seb_kuzminsky> i added some error reporting (logging) to halui about the same time, but i guess it's not any of the things that i added checks for
[14:40:05] -!- ivansanchez has quit []
[14:40:18] -!- anth0ny_ has quit [Quit: anth0ny_]
[14:42:07] <seb_kuzminsky> oh wait
[14:42:14] <seb_kuzminsky> halui *did* say what was wrong
[14:42:22] <seb_kuzminsky> it's one of the new checks i added
[14:42:28] <cradek> ooh
[14:42:48] <seb_kuzminsky> but the output wasn't flushed, so it came after all the other output, down at the bottom after the test failed
[14:42:59] <seb_kuzminsky> halui: emcCommandSend: no echo from Task after 2.000 seconds
[14:42:59] <seb_kuzminsky> halui: sendMdiCommand: failed to Set Mode MDI
[14:43:43] -!- Rickta59 has quit [Quit: leaving]
[14:43:59] <seb_kuzminsky> our logging sure is wonky
[14:47:19] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[14:52:00] <jepler> how frequently does that test fail? 40 iterations here and no failures yet
[14:52:05] <jepler> wheezy, vanilla
[14:52:17] <cradek> 2 seconds is a long time
[14:53:00] <seb_kuzminsky> maybe my VMs suck? maybe the hypervisor host was doing something? idfk
[14:54:22] <seb_kuzminsky> it's happened several times, usually on rtpreempt, sometimes on vanilla, never on rtai
[14:54:36] <jepler> failed on iteration 67 here
[14:54:54] <seb_kuzminsky> i've got 5 instances in my "unexplained buildbot failures" file, but i probably didnt record all of them
[14:54:55] <jepler> halui: emcCommandSend: no echo from Task after 2.000 seconds
[14:54:56] <jepler> halui: old_echo_serial_number=6 emcCommandSerialNumber=7 new_echo_serial_number=6
[14:54:57] <seb_kuzminsky> ooh, yay, repro!
[14:54:58] <jepler> halui: sendMdiCommand: failed to Set Mode MDI
[14:55:05] <jepler> so it's not your VMs
[14:55:21] <seb_kuzminsky> there should be another "halui: " line saying more, nearby?
[14:55:40] <seb_kuzminsky> bbl work :-/
[14:56:03] <jepler> http://paste.ubuntu.com/12014092/ ["result" file]
[14:59:45] -!- Daerist has quit [Quit: Leaving]
[15:01:29] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[15:22:46] <jepler> added more debugging but haven't hit the problem in the next 200 iterations
[15:31:27] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[15:32:18] -!- SEL [SEL!~SEL@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[15:34:35] -!- Komzpa has quit [Ping timeout: 245 seconds]
[15:38:50] <jepler> .. 400
[15:38:51] <jepler> groan
[15:40:10] -!- amiri_ has quit [Read error: Connection reset by peer]
[15:41:55] <skunkworks> taking out the debugging?
[15:46:56] -!- b_b has quit [Remote host closed the connection]
[15:49:49] -!- mozmck has quit [Quit: Leaving.]
[15:51:22] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[15:51:49] <pcw_home> This seems like a big latency win:
[15:51:51] <pcw_home> [PATCH RT 2/7] mm/slub: move slab initialization into irq enabled region
[15:58:00] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[15:59:37] -!- tchaddad has quit [Remote host closed the connection]
[16:03:32] -!- Mr_Sheesh has quit [Quit: BBL]
[16:12:50] -!- tchaddad has quit [Remote host closed the connection]
[16:18:54] -!- anth0ny_ has quit [Quit: anth0ny_]
[16:20:48] -!- tocka has quit []
[16:21:04] <jepler> .. 900 :-/
[16:29:14] -!- mozmck has quit [Quit: Leaving.]
[16:30:12] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[16:31:47] <jepler> .. 993 and it failed
[16:32:29] <jepler> too bad I don't really trust how the various output is interleaved
[16:32:42] <jepler> emcTaskPlan() new serial number 6 -> 7
[16:32:45] <jepler> update echo_serial_number 6 -> 7
[16:32:53] <jepler> halui: emcCommandSend: no echo from Task after 2.000 seconds
[16:32:53] <jepler> halui: old_echo_serial_number=6 emcCommandSerialNumber=7 new_echo_serial_number=6
[16:35:10] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[16:40:47] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[16:42:01] -!- Komzpa has quit [Read error: No route to host]
[16:45:50] -!- arekm has quit [Ping timeout: 245 seconds]
[16:51:24] <jepler> // since emcStatus was passed to the WM init functions, it
[16:51:24] <jepler> // will be updated in the _update() functions above. There's
[16:51:24] <jepler> // no need to call the individual functions on all WM items.
[16:51:24] <jepler> int result = emcStatusBuffer->write(emcStatus);
[16:51:27] <jepler> what is WM ?
[16:58:14] -!- tocka has quit [Remote host closed the connection]
[17:00:32] <jepler> not sure if this is significant or not...
[17:00:39] <jepler> in a failed run the first "setting mode to Manual" comes at ~2s
[17:00:40] <jepler> 2.089: setting mode to Manual
[17:00:52] <jepler> in a random good run it's earlier
[17:00:52] <jepler> 0.386: setting mode to Manual
[17:01:25] <jepler> 0.396: setting mode to Manual
[17:01:47] -!- SEL has quit [Quit: Leaving]
[17:02:12] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[17:02:38] <jepler> another failed run: 2.704: setting mode to Manual
[17:05:24] <skunkworks> does your skin crawl looking at that code?
[17:05:40] <jepler> veteran programmers have already had all their skin flayed off...
[17:05:54] <jepler> speaking of which, lunchtime!
[17:05:56] <skunkworks> heh
[17:18:29] -!- Komzpa has quit [Ping timeout: 252 seconds]
[17:20:28] -!- kh0d has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[17:28:07] -!- sheppard has quit [Ping timeout: 250 seconds]
[17:41:24] -!- podarok has quit [Remote host closed the connection]
[17:43:15] -!- tchaddad has quit [Remote host closed the connection]
[18:04:54] <jepler> boh and I think I missed pasting this log
http://paste.ubuntu.com/12014583/
[18:10:52] -!- anth0ny_ has quit [Quit: anth0ny_]
[18:12:23] <jepler> 9.700: setting mode to Manual
[18:12:34] <jepler> the next failed run didn't do its first mode setting until 9.7s!
[18:13:37] <jepler> http://paste.ubuntu.com/12015132/
[18:14:24] -!- Tecan has quit [Changing host]
[18:19:52] <archivist> I like to use spare nixies to repair old test gear :)
[18:21:47] <cradek> I've never seen a single thing that uses the b5971 tubes. probably why they are so rare.
[18:22:56] <archivist> I fired up a HP 3591A a few days ago t to test the probe I got with LVDT mesurement
[18:26:28] <archivist> nixies seem ok but the counter part is duff, need to make an extender and scope it
[18:26:57] <cradek> nixies don't fail, they only eventually darken
[18:27:15] <cradek> and the burroughs long life don't really ever darken that I've seen
[18:29:06] <archivist> I have seen inter electrode faults
[18:29:33] <cradek> huh - manufacturing defects, or shock, or something else you think?
[18:30:13] <archivist> probably the seal failing and gas contamination
[18:32:54] <jepler> 1438885300 halui: old_echo_serial_number=3 emcCommandSerialNumber=4 new_echo_serial_number=3
[18:32:57] <jepler> 1438885301 update echo_serial_number 3 -> 4
[18:33:20] <jepler> so in this run I can see that halui gave up waiting on the serial number to change before it was changed by task
[18:34:16] <jepler> it looks like *something* happens, and it may be system load, that makes task sluggish
[18:34:42] <jepler> consistently I see the first 'setting mode to Manual' be long in the test that fails and short in other tests, >1.5s vs <.5s
[18:38:15] <jepler> 1438885301 emcTaskPlan() new serial number 3 -> 4
[18:38:26] <jepler> actually the command wasn't even received by task until after halui gave up waiting on it
[18:45:42] <cradek> yay, something makes it slow is a much better failure to see than a deadlock
[18:47:35] <jepler> http://paste.ubuntu.com/12015373/
[18:48:01] <jepler> well this one breaks the pattern, first "setting mode" at 0.347
[18:48:27] <jepler> 1438886792 emcTaskPlan() new serial number 6 -> 7
[18:48:29] <jepler> 1438886794 halui: old_echo_serial_number=6 emcCommandSerialNumber=7 new_echo_serial_number=6
[18:48:33] <jepler> 1438886801 update echo_serial_number 6 -> 7
[18:49:46] <cradek> have you figured out why the state of the world (serial numbers) is different from what we expect (we have queues now instead)?
[18:52:16] <jepler> c4c7fb9d57143251eb3907886833a61bca035875 which is my version of Sascha's patch for SF#328 implements emcCommandSend with "wait for received" semantics
[19:06:17] <jepler> 27757 1438887711.586678 rename("sim.var", "sim.var.bak" <unfinished ...>
[19:06:17] <jepler> 27757 1438887713.991722 <... rename resumed> ) = 0
[19:06:19] <jepler> boom
[19:06:35] <jepler> so yes, it's a failure that happens in high disk latency situations
[19:06:40] <cradek> wow
[19:06:52] <cradek> 2.4 seconds
[19:07:57] <cradek> does task do any disk IO other than at startup and shutdown?
[19:08:39] <cradek> oh sure it does, it reads gcode if nothing else
[19:08:40] <jepler> it reads part programs and can write stuff like probe logs directed by gcode
[19:08:43] <cradek> duh
[19:09:47] <jepler> it opens halui.ini a surprising number of times, but all at atartup
[19:10:45] <seb_kuzminsky> task should probably use something like uspace_rtapi_app's harden_rt()
[19:11:16] <jepler> that won't help disk I/O not go out to lunch
[19:11:58] <seb_kuzminsky> and harden_rt() should probably call sched_setscheduler(SCHED_RR) and sched_setparam() to raise its priority
[19:12:16] <seb_kuzminsky> but yes, that probably(?) won't help (much?) with disk latency
[19:12:40] <jepler> particularly not in a VM
[19:13:13] <skunkworks> random thought - could that be the issue with gmoccopy? did he add some extra disk access?
[19:13:34] <cradek> what issue?
[19:13:36] -!- PCW has quit [Remote host closed the connection]
[19:14:01] <jepler> the "ui stops responding for a few seconds" bug I think
[19:14:03] <seb_kuzminsky> the thing rick lair reported, where latency went way up
[19:14:04] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[19:14:11] <skunkworks> yes - rick
[19:14:22] <jepler> I forget what operation triggers the latency
[19:14:22] <cradek> oh the halui button was slow to respond
[19:14:27] <skunkworks> yes
[19:14:48] <cradek> he bisected that and found the breakage but I haven't seen any progress on it
[19:15:11] <jepler> what operation does he do in halui to trigger the unresponsiveness?
[19:15:15] <jepler> was it a mode switch?
[19:15:22] <cradek> no
[19:15:31] <cradek> I think it's pause and resume while running gcode
[19:15:33] <seb_kuzminsky> it was an interp pause, iirc
[19:15:35] <seb_kuzminsky> yeah
[19:15:37] <seb_kuzminsky> bug #427
[19:15:56] <seb_kuzminsky> http://sourceforge.net/p/emc/bugs/427/
[19:16:42] -!- anth0ny_ has quit [Quit: anth0ny_]
[19:16:48] <seb_kuzminsky> we should probably run all our tasks with SCHED_RR, and Task should have the highest priority
[19:17:16] <jepler> pause/resume/step don't do anything in task that makes strace -e file report any syscalls
[19:17:30] <skunkworks> halui pause/resume?
[19:17:32] <jepler> abort and machine on/off/estop all do
[19:17:37] <jepler> skunkworks: no, axis pause/resume
[19:17:49] <skunkworks> he specifically is using halui
[19:17:56] <jepler> for this particular problem (task takes a long time calling rename()) it should not be UI dependent
[19:18:00] <jepler> -> rick's problem is not this problem
[19:18:05] <skunkworks> ok
[19:18:59] <jepler> well it is possible that his halui is sending commands that are different than what aixs pause/resume/step send though
[19:20:07] <cradek> I think gmoccapy might control halui somehow
[19:20:15] <cradek> I suspect something is giving him a flood of messages
[19:20:19] <jepler> I don't know why you'd design your software that way
[19:21:00] <jepler> anyway, that rename() looks like a smoking gun, and I've also shown to my own satisfaction that it happens a lot more readily while the system is doing a lot of I/O
[19:21:07] <jepler> I don't know what to propose doing about it however
[19:21:44] <jepler> preview-generating UIs need to have a way to know the var file is up to date, and knowing that the mode change command has been acted on is that way..
[19:22:02] <seb_kuzminsky> it's valuable to have a reliable backup of the var file, like that rename gives us
[19:22:08] <jepler> a mode change is normally instant, so task isn't ack'ing it via echo_serial_number before completing it
[19:22:53] <cradek> well having a wall-clock based timeout is the bug, right?
[19:22:59] <jepler> well
[19:23:19] <seb_kuzminsky> cradek: yeas, but...
[19:24:07] <cradek> there used to be a heartbeat. wonder where that was. if it was something that task twiddles when it's bored otherwise, that would be a timeout that makes sense to use.
[19:24:42] <cradek> xemc used to show it
[19:24:46] <cradek> I don't know from where
[19:25:08] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[19:25:12] <seb_kuzminsky> that would be better than just wallclock time, but i think you still need a wallclock timeout too
[19:25:28] <seb_kuzminsky> one of the things task could do wrong is not twiddle the heardbeat counter, and the test should time out if that happens
[19:25:34] <cradek> emcTaskUpdate increments heartbeat
[19:26:14] <cradek> what's the harm in just making the wall-clock timeout much much longer?
[19:26:30] <cradek> like minutes
[19:26:42] <seb_kuzminsky> that's probably fine
[19:26:45] <cradek> it will still tell us about any real deadlock
[19:26:54] <jepler> if task is unresponsive for a minute that's bad, because you can't software-estop
[19:26:58] <seb_kuzminsky> we'd like to know if Task goes out to lunch for seconds and seconds
[19:27:02] <seb_kuzminsky> yeah
[19:27:04] <jepler> you might even think it's bad if task is unresponseive for a second
[19:27:10] <seb_kuzminsky> or 10 ms
[19:27:12] <cradek> well it does
[19:27:22] <cradek> because it does file IO
[19:27:26] <cradek> ok, question answered
[19:28:20] <skunkworks> Task is unresponsive. Click ok to estop..
[19:28:32] <seb_kuzminsky> *pull the plug to estop
[19:28:37] <cradek> and even if we fix that somehow, the gui can still do it, and you still can't software anything-stop
[19:29:02] <jepler> "task was unresponsive for 60s. don't you wish you had a physical estop chain?"
[19:29:08] <jepler> [OK] [Cancel]
[19:29:08] <skunkworks> heh
[19:29:13] <cradek> no kidding
[19:29:14] <seb_kuzminsky> the further up from the core we can push the badness, the better i'll feel
[19:29:57] <seb_kuzminsky> specifically i think it'd be really neat if Task and IO were reliable, and any badness generally came from bad GUIs
[19:29:58] <cradek> well a real machine tool probably won't have buildbot or VMs running on it
[19:30:15] <cradek> yes, that would be nice
[19:30:19] <jepler> making task realtime would be a long term goal
[19:30:38] <jepler> of course someday we'll just rewrite task from a blank screen and it'll be good this time
[19:30:42] <cradek> we've already moved some of it into motion, so it is
[19:30:44] <skunkworks> do we know if anyone has had this issue on real computer hardware?
[19:31:20] <skunkworks> *non vm
[19:31:25] <seb_kuzminsky> i dont know of any in-the-wild problems from this particular thing, but the general thing of "much of linuxcnc runs in non-realtime" *might* be what's biting rick lair
[19:32:57] <skunkworks> well - rick lairs problem seems to be something that changed in gmoccopy
[19:33:18] <skunkworks> changing from responsive to not responsive
[19:33:25] <skunkworks> or some definition of
[19:35:06] <skunkworks> well then - back to the o-word issue. :)
[19:41:07] <seb_kuzminsky> why is task updating the var file in this test? it's not changing any of the persisted parameters is it?
[19:41:26] <cradek> it rewrites it when you sync (part of switching modes)
[19:41:38] <jepler> seb_kuzminsky: task isn't smart enough to know whether the var file contents would be different if written
[19:41:53] * seb_kuzminsky imagines a dirty flag on each parameter
[19:42:15] <cradek> that doesn't fix any fundamental problem
[19:42:20] <seb_kuzminsky> yeah
[19:42:36] -!- tjtr33 has quit [Quit: Leaving]
[19:50:06] <seb_kuzminsky> rename(2) causes sync() on ext3 fs, which i bet is the slow part
[19:50:34] <seb_kuzminsky> i bet it'd be much faster to treat the var file as a log and just append changed values as needed
[19:51:10] <seb_kuzminsky> at startup task would read through the log, updating on each line, then maybe writing out a condensed vars file with just one line per parameter
[19:51:15] <jepler> so now the var file grows forever?
[19:51:22] <jepler> per session?
[19:51:33] <seb_kuzminsky> the file would grow in an unbounded but slow way until task is restarted
[19:52:14] <seb_kuzminsky> it's 14 bytes per line
[19:53:06] <jepler> you'd have to check how existing programs use the var file
[19:53:15] <seb_kuzminsky> is it more than just task?
[19:53:21] <cradek> yep
[19:53:25] <cradek> that's why it's rewritten
[19:53:26] <jepler> for instance, if they do it by reading until hitting the *first* instance of a variable number, your idea is sunk
[19:53:41] <cradek> if it was just task, why bother rewriting it during runtime
[19:53:53] <jepler> axis implicitly reads the var file via rs274 so it can show the correct offsets in preview
[19:54:07] <jepler> librs274 that is
[19:54:11] <seb_kuzminsky> cradek: to persist the params asap, in case it crashes?
[19:54:33] <cradek> ok, that too
[19:54:38] <seb_kuzminsky> jepler: hrm, so the vars file is yet another wonky ipc mechanism we have, i didn't realize that
[19:54:49] <jepler> seb_kuzminsky: most of the time we manage to forget it
[19:55:02] <seb_kuzminsky> maybe a big array of floats in shm would be better
[19:55:29] <jepler> still breaks existing code
[19:55:32] <seb_kuzminsky> sure
[19:55:48] <jepler> if the var file were arranged right you could seek(offset); write(new value of var)
[19:56:02] <seb_kuzminsky> ... and we're kind of trying to get away from shm between task & the uis, and moving towards networking
[19:56:15] <seb_kuzminsky> jepler: not if you're using ascii encoding like we are now
[19:56:15] <jepler> e.g., if every line was known to be 32 bytes long or whatever would let you print any floating point value with full accuracy and be a nice power of 2
[19:56:26] <seb_kuzminsky> or you'd have to reserve space on each line
[19:56:28] <seb_kuzminsky> right
[19:56:56] <seb_kuzminsky> that doesn't give you the backup we have now, which is nice to have
[19:56:56] <cradek> remember the var file is also a special list of keys, not just a key/value store
[19:57:03] <jepler> I've spent enough years yelling at people for writing the var file, though, that I know other programs probably do
[19:57:18] <jepler> there used to be a GUI just for writing that file
[19:57:26] <jepler> instead of MDI #1234=567.89
[19:57:32] <cradek> yes, I hope it's gone now
[19:57:53] <cradek> either way, I bet others have reinvented it
[19:58:04] <cradek> and the units-related bugs that go with that bad idea
[19:58:11] <jepler> grnrnnnarmg
[19:58:23] <jepler> yeah and a similar thing for programs writing the tool table
[19:58:39] <jepler> but we don't offer an alternative for *reading* the var file; you can't MDI that
[19:58:39] <cradek> yeah, I suppose so
[19:58:43] <jepler> like you can for setting vars and tools
[20:01:50] <skunkworks> (DEBUG [#8]) works in mdi... ;)
[20:02:04] <jepler> "%6d % 24.17g\n" fits in 32 bytes and should allow any FP number to be printed with full precision
[20:02:12] <jepler> skunkworks: no, because only one UI out of all UIs can receive a debug message
[20:02:20] <skunkworks> ah
[20:02:34] <jepler> so if you run badideaui + worseideaui, and one of them does (DEBUG #8), no guarantee that one sees the message
[20:02:37] <skunkworks> you mean the best ui?
[20:03:15] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:03:50] <jepler> one of those two is probably the best ui out of those two
[20:07:53] -!- skunkworks_ has quit [Ping timeout: 252 seconds]
[20:13:03] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[20:15:25] -!- DenSchub has quit [Ping timeout: 245 seconds]
[20:26:17] <seb_kuzminsky> sounds like some changes went into linux 3.1 to make ext3 slower but safer, specifically relating to fsync (which rename uses)
[20:26:46] <seb_kuzminsky> maybe that's why this shows up on our wheezy machines (3.2 for uspace and 3.4 for rtai) and not on lucid
[20:27:01] <seb_kuzminsky> hmm, no, we should see it on precise too, and i dont think we do (or maybe i just didnt notice)
[20:27:33] <seb_kuzminsky> http://kernelnewbies.org/Linux_3.1#head-7536ebf800edb3e888431812b283b63ed2b2b7ea
[20:29:14] <cradek> interesting
[20:31:40] <mozmck> doesn't precise use ext4 by default?
[20:31:47] <seb_kuzminsky> i'll check
[20:32:11] <jepler> this system seems to be using ext4 on kernel 3.2.
[20:32:12] -!- Komzpa has quit [Read error: Connection reset by peer]
[20:32:14] <seb_kuzminsky> yep, you're right, precise uses ext4
[20:32:18] <seb_kuzminsky> *our precise VMs
[20:32:41] <seb_kuzminsky> hm, my wheezy machine uses ext4 too
[20:32:54] <seb_kuzminsky> (which already had the slow, safe behavior prior to 3.1)
[20:34:12] <mozmck> Looks like ext4 was default for lucid as well:
https://wiki.ubuntu.com/LucidLynx/ReleaseNotes
[20:34:26] <seb_kuzminsky> our wheezy VMs use ext4 with barriers enabled
[20:35:05] <jepler> /dev/mapper/install14-home /home ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
[20:35:09] <seb_kuzminsky> heh yep, our lucid vms use ext4 too
[20:35:15] <seb_kuzminsky> ok, never mind, red herring
[20:46:31] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.91.1 [Firefox 34.0.5/20141126041045]]
[20:49:06] -!- Mr_Sheesh has quit [Remote host closed the connection]
[20:49:16] -!- anth0ny_ has quit [Quit: anth0ny_]
[20:53:07] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:53:43] -!- Mr_Sheesh has quit [Remote host closed the connection]
[20:55:10] -!- FinboySlick has quit [Quit: Leaving.]
[20:55:49] -!- Komzpa has quit [Read error: Connection reset by peer]
[20:59:29] -!- tchaddad has quit [Remote host closed the connection]
[21:02:46] -!- Mr_Sheesh has quit [Remote host closed the connection]
[21:04:41] -!- Komzpa has quit [Read error: Connection reset by peer]
[21:06:58] <Patang> Anyone here know how (if possible) to assign a value to a gmoccapy-variable from a gcode subroutine?
[21:07:12] -!- Mr_Sheesh has quit [Excess Flood]
[21:07:20] <cradek> I don't know what a gmoccapy-variable is
[21:08:52] -!- Komzzpa has quit [Read error: Connection reset by peer]
[21:09:10] <Patang> well, a glade-variable might be more correct....
[21:11:06] <cradek> what's it displaying?
[21:13:26] -!- tchaddad has quit [Remote host closed the connection]
[21:14:47] <Patang> Its a just a setting for blockheight, ment to be entered manually in GUI, but Im making a routine using 2 toolsensors to get it automatically measured
[21:16:25] <cradek> it sounds like you need to use the remap facility to customize something, instead of trying to bend a preconceived hardcoded setup
[21:17:11] <Patang> basically Im just wondering if there is a variant of "gmoccapy.blockheight = 24" available in gcode subroutines
[21:17:49] <cradek> there's no way to set anything from gcode unless it's a hal pin
[21:18:05] <Patang> ok, thanks
[21:18:45] <andypugh> Patang: Open a terminal and type “halcmd chow pin gm*” and see if there is anything likely
[21:18:59] <andypugh> No, don’t type that. The computer will act puzzled
[21:19:12] <andypugh> halcmd show pin gm*
[21:19:39] -!- tchaddad has quit [Remote host closed the connection]
[21:20:13] <seb_kuzminsky> chow
[21:20:40] <Patang> I thought hal-pins were read-only in gcode
[21:21:46] <Patang> but then Im very new at this
[21:23:46] <Patang> ref
http://linuxcnc.org/docs/html/remap/structure.html#_named_parameters_and_hal_items_a_id_remap_referto_hal_items_a
[21:27:14] <andypugh> It’s possible to read them
[21:27:39] <andypugh> But you can also output on an “analog output” that is netted to a pin in HAL.
[21:28:37] <Patang> hm, ok. Is that M68 then?
[21:29:38] -!- Mr_Sheesh has quit [Remote host closed the connection]
[21:31:45] -!- Deejay has quit [Quit: bye]
[21:34:15] -!- Mr_Sheesh has quit [Changing host]
[21:35:24] <andypugh> I forget, but it’s in the 60’s
[21:37:06] <Patang> thanks, Ill work something out with this
[21:38:50] -!- Mr_Sheesh has quit [Remote host closed the connection]
[21:41:23] -!- tchaddad has quit [Remote host closed the connection]
[21:41:33] -!- Mr_Sheesh has quit [Changing host]
[21:47:00] -!- Mr_Sheesh has quit [Remote host closed the connection]
[21:48:29] -!- carper has quit []
[21:49:38] -!- Mr_Sheesh has quit [Changing host]
[21:53:14] -!- Mr_Sheesh has quit [Remote host closed the connection]
[21:54:58] -!- Komzpa has quit [Ping timeout: 260 seconds]
[22:00:17] amnesic_away is now known as amnesic
[22:01:12] amnesic is now known as amnesic_away
[22:02:57] -!- Camaban has quit [Quit: Leaving]
[22:04:10] <seb_kuzminsky> the vars file gets written sequentially, but there seems to be no way to communicate to the readers that it's complete. for example, we don't write to a temp file and atomically rename it when we're finished writing
[22:04:46] <seb_kuzminsky> so readers race the writer, and may reach eof before the writer (task) is done writing, and erroneously not see the vars that task hasn't written yet
[22:08:17] <mozmck> erroneously?
[22:09:36] -!- Mr_Sheesh has quit [Remote host closed the connection]
[22:11:50] <seb_kuzminsky> yeah that seems like a bug
[22:13:57] <mozmck> Yeah, I was being a little nit-picky - perhaps erroneously :) I think the error is not that the readers don't see the vars that haven't been written yet, but that there is no blocking mechanism to keep them from reading while the file is being written.
[22:14:16] <seb_kuzminsky> ah, yeah
[22:14:30] -!- gonzo_nb has quit [Remote host closed the connection]
[22:14:45] <seb_kuzminsky> i'd argue that the error is that we try to use rewriting of files as an IPC mechanism in the first place :-/
[22:14:56] <mozmck> I know a lot of things use a lockfile, I wonder if that would work here?
[22:15:06] <mozmck> hah! probably so.
[22:15:41] <seb_kuzminsky> we could use flock(2) to arbitrate access to the vars file
[22:15:56] <seb_kuzminsky> that might introduce even worse latencies in task than what we have now
[22:16:00] <mozmck> heh
[22:16:19] <mozmck> what is using vars for IPC?
[22:16:33] <seb_kuzminsky> a poorly written gui could flock the vars file indefinitely, preventing task from acquiring the lock needed to re-write it
[22:17:14] <seb_kuzminsky> task writes the vars file, and axis reads it to learn things like coordinate system offsets
[22:18:46] <seb_kuzminsky> we have the current G5x coordinate system offset in EMC_TASK_STAT
[22:18:59] <seb_kuzminsky> and the G92 offset
[22:19:16] <mozmck> So I wonder if it would be better for the gui's to ask task for the settings, instead of reading the file directly?
[22:19:17] <seb_kuzminsky> i wunner what else is needed
[22:19:39] <seb_kuzminsky> the guis already read the task stat buffer, so they have those fields
[22:20:01] <mozmck> but they read the file directly?
[22:20:03] <seb_kuzminsky> there are params that get written to the vars file that do not appear in the task stat buffer, maybe some of those are needed by some of the guis?
[22:20:09] <mozmck> oh
[22:20:15] <seb_kuzminsky> the guis read the file directly, says jepler
[22:21:35] <mozmck> I would think having a single reader and writer would seem be ideal, then you just query the reader/writer - but I don't know what all is involved.
[22:22:17] <seb_kuzminsky> in the old-school shared-memory way, the params should all live in a giant array of floats, with task having a read/write mapping to it and everyone else who cares having a read-only mapping to it
[22:22:49] <seb_kuzminsky> in the new-school networky way, guis should connect to task and subscribe to the params they care about, and task should send them updates when those params change
[22:22:52] <mozmck> Does the OS do read/write controls?
[22:23:02] <seb_kuzminsky> on shared memory?
[22:23:04] <mozmck> yes
[22:23:26] <andypugh> Does #define lead to textual substitution in strings?
[22:23:28] <seb_kuzminsky> yeah, you'd use mmap(2), which lets you request read-only or read-write mappings
[22:24:01] <seb_kuzminsky> andypugh: inside quoted strings, cpp does *not* do macro expansion
[22:24:05] <seb_kuzminsky> but you can do this:
[22:24:12] <seb_kuzminsky> #define NAME "Seb"
[22:24:25] <seb_kuzminsky> char *str = "My name is " NAME;
[22:24:45] <mozmck> ok, I haven't done any of that. I would do it the networky way :) I do that kind of thing in totally non-networked programs.
[22:24:53] <andypugh> Ah, that explains why
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/rs274ngc/interp_internal.hh;h=34a6c9ef961036e8956270c2e29c26d39b4c6289;hb=HEAD#l160 does not mess up
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/rs274ngc/interp_o_word.cc;h=084631e898b3ce00a9e5df5316b636fbe8bed1a8;hb=HEAD#l132
[22:27:21] <seb_kuzminsky> andypugh: one gripe i have with C is that you can't easily render the names of enums or #define macros as strings, makes for gross error-prone hacks like that
[22:28:25] <skunkworks> andypugh: I am cheering you on...
[22:28:34] <andypugh> I think I prefer “case 1: //O - IF”
[22:29:20] <seb_kuzminsky> i dont see where axis reads the parameter file
[22:30:32] <seb_kuzminsky> axis and gremlin both make a copy of the parameter file (?) but dont open it
[22:33:18] <seb_kuzminsky> and gremlin uses the g5x_offset field of the stat struct, just like you'd expect, rather than try to read it from a flaky file, like a crazy person would do
[22:36:18] -!- tinkerer has quit [Remote host closed the connection]
[22:36:31] <andypugh> I am finding this hard, I don’t really do C++, so stuff like this baffles me
[22:36:32] <andypugh> typedef std::map<const char *, offset, nocase_cmp>::iterator offset_map_iterator;
[22:37:21] <mozmck> I like C++ :) the new C++11 has some very nice improvements though that can make things more readable.
[22:37:45] <seb_kuzminsky> andypugh: me too
[22:38:30] <mozmck> They are typedef'ing that so when they want an iterator of type std::map<const char*, offset, nocase_cmp> later, they can just say offset_map_iterator instead.
[22:39:30] <andypugh> Typedef I get
[22:39:51] <andypugh> Its std::map<…. that I can’t parse
[22:40:04] <mozmck> yeah, it's a template class, which can be hairy
[22:40:31] <mozmck> a map is a key->value mapping container
[22:40:57] <seb_kuzminsky> i dont think anyone reads the var file but task
[22:41:20] <seb_kuzminsky> bbl
[22:41:20] <andypugh> I didn’t know C++ was so high-level
[22:41:26] <mozmck> the stuff in the <...> are the types of the key, value, and a pointer to a comparison function I think - I'd have to look up maps
[22:41:33] <andypugh> Or is that some sort of macro?
[22:41:58] <mozmck> No, not a macro, c++ is pretty high level in many ways.
[22:42:04] -!- Fox_Muldr has quit [Ping timeout: 246 seconds]
[22:42:23] <mozmck> http://en.cppreference.com/w/cpp/container/map
[22:42:29] <andypugh> Of more immediate use, is there a way to find where a function is being called from when inside the function?
[22:44:12] <mozmck> I'm not sure what you are asking?
[22:45:30] <andypugh> I asume not then. Maybe it would be possible in an interpreted language
[22:45:33] <mozmck> You mean while running, have the function tell you who called it?
[22:45:48] <andypugh> Yes. I can see that is basically impossible.
[22:46:15] <andypugh> There would be a return pointer, but that’s not going to give any useful info about source code
[22:46:16] <mozmck> I don't know. You can get a backtrace from gdb.
[22:46:41] <mozmck> You can also set breakpoints, and see the call stack.
[22:46:43] <cradek> seb_kuzminsky: AXIS/gremlin runs another interpreter to generate the preview, and that interpreter needs the var file
[22:46:47] <andypugh> If I knew how to use gdb I wouldn’t be asking the question
[22:47:21] <mozmck> I haven't done a lot of that. Most of my debugging for a while has been in microcontrollers. I flash an LED or something :)
[22:47:48] <mozmck> I often add printf() statements to track what get's called and when.
[22:49:18] <mozmck> I've barely used gdb either. Mostly through eclipse when I do though.
[22:53:18] -!- alex_joni has quit [Ping timeout: 260 seconds]
[22:53:57] <andypugh> I installed Eclipse with that intention, but LinuxCNC is rather a complex system to set up Eclipse for.
[22:54:17] -!- alex_joni [alex_joni!~alex_joni@81.196.65.201] has joined #linuxcnc-devel
[22:54:33] <andypugh> (For example, the eclipse gdb gui wants to knwo the name of the executable)
[22:55:47] <mozmck> I haven't debugged linuxcnc using gdb, but I see your point, I don't know what executable you'd load to debug anyhow.
[22:56:13] <Tom_itx> i had nothing but trouble with eclipse when using it with avr-gcc
[22:57:43] <mozmck> I've liked eclipse pretty well. Especially for it's editing and code reading stuff. Hitting F3 over any variable and it taking me to where it is defined saves a lot of time. As well as a bunch of other stuff.
[22:59:43] <andypugh> That’s _nearly_ working for me after rebuilding the index. It’s only taking me to the file, not the line of code
[23:00:18] -!- mhaberler has quit [Quit: mhaberler]
[23:00:18] -!- rob_h has quit [Ping timeout: 260 seconds]
[23:02:43] <cradek> andypugh: milltask is what you want to debug
[23:02:52] <cradek> gdb path/to/milltask `pidof milltask`
[23:02:56] <cradek> will attach to it
[23:03:28] <andypugh> I think I tried the GUI version f that, but possibly when I didn’t have GDB installed
[23:04:04] <cradek> unfortunately I bet guis don't help if you don't already know how to use the debugger
[23:04:28] <cradek> getting attached to the running program is simple, but sometimes getting the program interrupted where you care about what's happening is harder
[23:04:58] <mozmck> Well, guis can make that part easier.
[23:05:01] <cradek> for an error you can just set a breakpoint at the spot where the error is issued, then continue, then do whatever causes the error to happen
[23:05:13] <andypugh> I have added a printf to the control_find_o_word function, and the output is curious.
[23:05:14] <andypugh> http://www.pastebin.ca/3091490
[23:05:48] <andypugh> There are a lot more calls to the function than expected, and many fail.
[23:06:49] <cradek> I think that fail means "nope it's not yet defined" which is maybe normal for every O line as you pass it?
[23:07:13] <andypugh> I don’t know.
[23:07:47] <andypugh> I am resentful of the fact that this isn’t my buggy code but I seem to be trying to fix it
[23:08:13] <cradek> that sucks
[23:08:30] <cradek> I'm pretty sure it's a remap problem, so it's not ken's either
[23:10:03] <andypugh> Well, there is something about the context in which the O-word parsing is happening that is confusing a test. It has the look of a rather brain-dead test to me
[23:25:25] -!- Topy44 has quit [Ping timeout: 256 seconds]
[23:25:25] -!- putnik has quit [Ping timeout: 256 seconds]
[23:32:38] -!- GeorgeHahn has quit [Read error: Connection reset by peer]
[23:35:49] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[23:39:37] -!- tannewt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
[23:57:27] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/task-latency-reporting 4ebfe45 06linuxcnc 10src/emc/task/emctaskmain.cc task: report if main loop takes too long * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4ebfe45