Back
[00:03:15] -!- zlog has quit [Ping timeout: 252 seconds]
[00:04:50] -!- adb has quit [Ping timeout: 255 seconds]
[00:05:19] -!- Tom_itx has quit [Ping timeout: 256 seconds]
[00:08:24] -!- zzolo has quit [Quit: zzolo]
[00:29:28] -!- gumis [gumis!~gumis@dfv137.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[00:29:44] gumis is now known as micges
[00:37:03] -!- micges has quit [Quit: Wychodzi]
[00:40:21] -!- danielfalck [danielfalck!~danielfal@static-50-53-1-104.bvtn.or.frontiernet.net] has joined #linuxcnc-devel
[00:50:08] -!- dr00bie has quit [Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201190337]]
[00:52:00] -!- jfire has quit [Quit: Leaving.]
[00:53:19] -!- Tecan has quit [Quit: Ex-Chat]
[00:56:07] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:57:49] -!- zlog has quit [Remote host closed the connection]
[00:57:54] -!- Tom_itx has quit []
[00:59:12] -!- paideia has quit [Quit: Leaving]
[00:59:53] -!- jfire has quit [Quit: Leaving.]
[01:03:31] -!- asdfasd has quit [Ping timeout: 248 seconds]
[01:06:18] -!- jacobroufa has quit [Ping timeout: 245 seconds]
[01:06:55] -!- ve7it has quit [Remote host closed the connection]
[01:10:36] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[01:11:50] -!- rob_h has quit [Ping timeout: 252 seconds]
[01:19:06] -!- sumpfralle1 has quit [Ping timeout: 272 seconds]
[01:31:51] -!- chopper79 has quit [Quit: Leaving.]
[01:35:37] gumis is now known as micges
[01:50:53] -!- Dupe has quit [Quit: Leaving]
[01:55:22] -!- micges has quit [Quit: Wychodzi]
[02:03:14] -!- paideia has quit [Quit: Leaving]
[02:24:34] -!- ravenlock has quit [Ping timeout: 240 seconds]
[02:37:21] -!- Tecan has quit [Ping timeout: 276 seconds]
[02:39:55] -!- Valen has quit [Quit: Leaving.]
[02:41:44] -!- syyl_ has quit [Read error: Connection reset by peer]
[02:50:50] -!- Wildhoney has quit [Ping timeout: 276 seconds]
[03:03:50] -!- chopper79 has quit [Quit: Leaving.]
[03:08:04] -!- nOStahl has quit [Quit: nOStahl]
[03:10:43] -!- FinboySlick has quit [Quit: Leaving.]
[03:16:51] <seb_kuzminsky> interesting article in todays LWN about the architecture of google's self-driving cars
[03:17:14] <seb_kuzminsky> http://lwn.net/SubscriberLink/539232/c8db881fe736edd4/
[03:25:36] -!- Tecan has quit [Changing host]
[03:27:54] <seb_kuzminsky> There are two main computers in the car. One is a very simple "drive by wire system" that has no operating system and is just in a tight loop controlling the brakes, steering, and accelerator. The second is a "workstation class system running FreeBSD", Chatham joked. In reality it is running a lightly customized Ubuntu 12.04 LTS. It is not running the realtime kernel, but uses SCHED_FIFO and control groups to provide "realtime-ish"
[03:46:40] -!- Valen has quit [Remote host closed the connection]
[03:49:05] -!- chopper79 has quit [Quit: Leaving.]
[03:50:59] -!- Valen has quit [Client Quit]
[03:59:51] -!- wildbilldonovan has quit [Quit: EOT]
[04:06:32] -!- mhaberler [mhaberler!~mhaberler@188-23-199-25.adsl.highway.telekom.at] has joined #linuxcnc-devel
[04:08:31] -!- dhoovie has quit [Read error: Connection reset by peer]
[04:24:15] -!- Keknom has quit [Quit: Leaving.]
[04:25:54] <seb_kuzminsky> this is quite the cringe-fest:
https://www.youtube.com/watch?v=ik4g40eLpGE
[04:42:24] -!- AR_ has quit [Ping timeout: 272 seconds]
[04:45:18] -!- abetusk has quit [Quit: Leaving]
[04:46:14] -!- Valen has quit [Quit: Leaving.]
[04:46:19] -!- dhoovie has quit [Ping timeout: 246 seconds]
[04:58:27] -!- tjb1 has quit [Quit: tjb1]
[04:59:30] -!- danielfalck has quit [Ping timeout: 264 seconds]
[05:02:22] -!- oeon has quit [Quit: Leaving.]
[05:03:18] -!- joe9 has quit [Quit: leaving]
[05:05:59] -!- zzolo has quit [Quit: zzolo]
[05:09:54] <mhaberler> hi seb! we should pick up that boring mdi bug again :-/
[05:10:05] <mhaberler> did you read back wrt queue sizes I tried?
[05:10:22] <seb_kuzminsky> is queue size relevant to this bug?
[05:10:41] <mhaberler> let me see if I can find it
[05:11:41] <mhaberler> that's what I tried:
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-02-17.html#21:37:39
[05:11:43] <seb_kuzminsky> whoa a tiff!
[05:11:48] <seb_kuzminsky> heh
[05:11:54] <mhaberler> ha, that looks pretty scientific
[05:12:06] <mhaberler> unfortunately it doesnt help zilch ;)
[05:12:30] <seb_kuzminsky> i think the queue size never gets above 5 because every 5th mdi command is an m6, which stalls everything
[05:14:01] <mhaberler> ah, that could be
[05:14:27] <mhaberler> the interesting one is qs=0
[05:14:32] <seb_kuzminsky> hm, it sounds like you're saying you got lots of failures with the mdi-queue-bugfix branch, i expected you to get 0 failures with that branch
[05:14:39] <seb_kuzminsky> am i understanding you right?
[05:14:43] <mhaberler> yes
[05:14:54] <seb_kuzminsky> well that sucks
[05:15:06] <seb_kuzminsky> did you try the mdi-queue-bugfix-2 branch? i trust that fix better
[05:15:23] <seb_kuzminsky> at least you can repro the bug, i guess that's an improvement
[05:15:30] <mhaberler> well I can try
[05:15:57] <seb_kuzminsky> you said you're getting 126 or 7 fails, how many runs did you do? what's the failure rate?
[05:16:34] <mhaberler> that is the count in the diff - how many of the expected lines were missing
[05:16:39] <mhaberler> just one run each
[05:17:12] <mhaberler> just let me make sure I did the above with the right branch, hold on
[05:17:27] <seb_kuzminsky> also try the mdi-queue-bugah, that makes sense
[05:18:21] <seb_kuzminsky> wwo, 126 dropped mdi commands, the test tries to do 1000 of them
[05:19:11] <seb_kuzminsky> hm, 7 of every 8 mdi commands is an m100 that makes output that we look for, then the 8th one is an m6 that we don't look for
[05:19:21] <mhaberler> yes, that was mdi-queue-bugfix e1d92566d2593a4f1a62d6789eecc880cf05776f
[05:19:48] <seb_kuzminsky> and 1/8 is 0.125, that's suspiciously close to the 126/1000 that you saw failed
[05:19:54] <mhaberler> hm
[05:20:16] <mhaberler> sounds like a hypothesis
[05:20:38] <seb_kuzminsky> e1d9 is not one of my commits, i'm not sure what you're testing
[05:21:30] <seb_kuzminsky> oh, heh
[05:21:40] <seb_kuzminsky> it's the mdi-queue-bug branch
[05:21:49] <seb_kuzminsky> that one's supposed to demonstrate the bug, not fix it!
[05:21:50] <seb_kuzminsky> whew!
[05:22:14] <seb_kuzminsky> try ad79255a7f6f072835ede1a70aee813dcdc6c7fb (mdi-queue-bugfix-2) instead
[05:22:45] <mhaberler> f…k.. I managed to screw up branches, yes
[05:22:53] <mhaberler> ok, will do
[05:23:27] <seb_kuzminsky> i'd rather it's something simple like "test the wrong branch" instead of "the fix doesn't work" ;-)
[05:24:40] <mhaberler> esp qs=0 takes very long and I'm on the road, so it's going to be evening here until I have results
[05:24:53] <seb_kuzminsky> ok
[05:24:53] -!- pikeaero has quit [Remote host closed the connection]
[05:24:59] <seb_kuzminsky> i can't work on this tonight anyway
[05:25:07] <mhaberler> fair enough
[05:25:15] <seb_kuzminsky> i don't know what qs=0 would do, exactly
[05:25:23] <seb_kuzminsky> i guess i would expect it to do something reasonable
[05:25:40] <mhaberler> in effect it _should_ not queue at all, i.e. emulate previous behavior
[05:25:42] <seb_kuzminsky> what are you doing differently that you can repro the problem now?
[05:26:23] <seb_kuzminsky> it'd be good to extend the mdi-queue test to try different queue sizes
[05:26:39] <mhaberler> that is a good question, I'm not firm right now I did anything on the right branch
[05:26:58] <mhaberler> oh I see
[05:27:00] <mhaberler> hold on
[05:28:53] <mhaberler> in the ini file: [TASK]MDI_QUEUED_COMMANDS=<n>
[05:29:14] <mhaberler> its configurable, default size 10
[05:30:07] <seb_kuzminsky> if you add more queue sizes to the test, either rebase & squash it into the original test or put it on top of the mdi-queue-bugfix-2 branch and i'll squash them before i ff-merge to master
[05:30:44] <mhaberler> sorry, that was straight from the 'Hitler uses git' video ;)
[05:30:51] <seb_kuzminsky> haha
[05:31:04] <seb_kuzminsky> then i'll just cherry-pick HEAD^^
[05:31:09] <mhaberler> exactly
[05:31:23] <mhaberler> writing crappy code to jack up consulting rates
[05:31:36] <seb_kuzminsky> oh man, i can jack up my rates?! no one told me
[05:31:59] <mhaberler> no, thats a quote from the video, too
[05:32:08] <seb_kuzminsky> yeah ;-)
[05:32:26] <seb_kuzminsky> everyoen who has never successfully run a git command, leave the irc channel now
[05:33:16] <seb_kuzminsky> well, i'm off for the night. i'll read back tomorrow
[05:33:31] <mhaberler> fine - just let me recap sequence before:
[05:33:36] <seb_kuzminsky> ok
[05:34:25] <mhaberler> rebase mdi-queue-bugfix-2 onto mdi-queue-bugfix? (doesnt look it makes sense?)
[05:34:30] <seb_kuzminsky> no!
[05:34:43] <seb_kuzminsky> mdi-queue-bugfix{,-2} are two alternative fixes, not complimentary
[05:34:47] <seb_kuzminsky> it's one or the other
[05:34:56] <seb_kuzminsky> i prefer -2, it's much less invasive
[05:35:02] <seb_kuzminsky> i was suggesting:
[05:35:04] <mhaberler> ok, permission to runtests, sir
[05:35:08] <seb_kuzminsky> heh
[05:35:11] <seb_kuzminsky> i was suggesting:
[05:35:20] <seb_kuzminsky> ignore mdi-queue-bugfix
[05:35:32] <seb_kuzminsky> try your test on mdi-queue-bugfix-2, i bet it won't fail
[05:35:56] <seb_kuzminsky> if you feel like it, add some more tests (in additional commits on top of mdi-queue-bugfix-2) of different queue-sizes
[05:36:10] <seb_kuzminsky> that's all
[05:36:30] <mhaberler> ah now I see, ok - so only on mdi-queue-bugfix-2 but varying knobs
[05:36:41] <seb_kuzminsky> right
[05:36:51] <mhaberler> ok, got it (git it?)
[05:37:18] <seb_kuzminsky> i guess the other knob to twiddle would be the ratio of m100 to m6 in the test.sh script
[05:37:26] <seb_kuzminsky> i picked 1/8 at random pretty much
[05:37:48] <mhaberler> ok
[05:38:01] <seb_kuzminsky> it might be fun to make the test do a random number of m100, say 0-2*QueueSize?
[05:38:05] <mhaberler> well one of those should fit into today's trainride
[05:38:12] <seb_kuzminsky> random number of m100 after each m6, i mean
[05:38:49] <seb_kuzminsky> but mostly i'll be happy if you sign off on the bugfix in mdi-queue-bugfix-2
[05:38:57] <mhaberler> ok
[05:39:02] <seb_kuzminsky> since it's your code and all ;-)
[05:39:38] <mhaberler> opinions may differ on the correctness of the status ante, but yes
[05:40:27] <mhaberler> sometimes it looks as if consistent buggy is preferrable to randomly correct
[05:41:08] <mhaberler> anyway, we'll figure
[05:41:09] <seb_kuzminsky> we aim for consistently correct, but we're happy if we merely make it less buggy ;-)
[05:42:02] <mhaberler> btw on the replacement theme; I was working on a similar thing like emcsh but in Python - 'import cmd2' and most of the cli/parsing job is done
[05:42:26] <mhaberler> (different code; just needed a cli)
[05:42:32] <mhaberler> pretty neat module
[05:42:47] <seb_kuzminsky> cool
[05:42:51] <seb_kuzminsky> i like python
[05:43:18] <mhaberler> tack on 'import linuxcnc' and you probably can have the same functionality in a fifth of the lines of code
[05:43:38] <seb_kuzminsky> i was trying to use the 'linuxcnc' python module in the mdi queue test instead of linuxcncrsh, but i couldnt see how to do it
[05:44:05] <seb_kuzminsky> i can't write a "DISPLAY" ui in python and use it in the test, because the linuxcnc starter script won't know to look for it in the test dir
[05:44:08] <mhaberler> ah, should I have a look at that? that would enable taking out some variables
[05:44:37] <seb_kuzminsky> i guess i could add the test dir to the PATH in test.sh before starting the linuxcnc script
[05:45:16] <seb_kuzminsky> can you have a .ini without a [DISPLAY]DISPLAY?
[05:45:32] <mhaberler> not sure; maybe a sleep 10000 does it
[05:45:52] <seb_kuzminsky> guh, i'm getting sucked into hacking on linuxcnc instead of doing what i need to do tonight
[05:45:54] <mhaberler> need to check whether some initialisation sequence is expected; probably not
[05:45:57] <mhaberler> duh
[05:46:08] <seb_kuzminsky> seeya tomorrow! have a fun train ride!
[05:46:13] <mhaberler> see you!
[05:47:05] -!- tjb1 has quit [Quit: tjb1]
[05:47:07] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[06:01:39] -!- Fox_Muldr has quit [Ping timeout: 248 seconds]
[06:04:27] -!- jmkelly has quit [Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]]
[06:19:44] -!- kwallace [kwallace!~kwallace@smb-249.sonnet.com] has parted #linuxcnc-devel
[06:26:07] -!- gene_ has quit [Remote host closed the connection]
[06:41:03] -!- jfire has quit [Quit: Leaving.]
[07:06:30] -!- L33TG33KG34R has quit [Ping timeout: 260 seconds]
[07:09:07] -!- ve7it has quit [Remote host closed the connection]
[07:46:30] -!- mhaberler has quit [Quit: mhaberler]
[07:49:56] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[07:56:17] <KGB-linuxcnc> 03chrisinnanaimo 05master c8f4b01 06emc2 10src/emc/usr_intf/gscreen/emc_interface.py * gscreen -add a function to get linuxcnc's current mode
[07:56:18] <KGB-linuxcnc> 03chrisinnanaimo 05master bc60d11 06emc2 10configs/sim/gscreen_custom/industrial_handler.py 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -remove references to numerical entry widget
[07:56:22] <KGB-linuxcnc> 03chrisinnanaimo 05master 3bf98ee 06emc2 10configs/sim/gscreen_custom/industrial.glade * gascreen config -remove entry widget from screen
[08:18:00] -!- b_b has quit [Changing host]
[08:24:36] -!- toastydeath has quit [Ping timeout: 245 seconds]
[09:08:42] -!- rob_h [rob_h!~rob_h@5e0473f7.bb.sky.com] has joined #linuxcnc-devel
[09:13:48] -!- hewball has quit [Read error: Operation timed out]
[09:20:47] -!- emel has quit [Excess Flood]
[09:28:48] -!- racycle has quit [Quit: racycle]
[09:36:23] -!- logger[mah] has quit [Ping timeout: 245 seconds]
[09:53:58] -!- logger[mah] [logger[mah]!~loggermah@mah2.mah.priv.at] has joined #linuxcnc-devel
[10:13:44] -!- mhaberler [mhaberler!~mhaberler@public-wlan.oe3.sil.at] has joined #linuxcnc-devel
[10:15:50] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[10:24:43] -!- logger[mah] has quit [Remote host closed the connection]
[10:27:22] -!- mattions has quit [Read error: Connection reset by peer]
[10:28:46] -!- logger[mah] [logger[mah]!~loggermah@mah2.mah.priv.at] has joined #linuxcnc-devel
[10:30:55] -!- vladimirek has quit [Remote host closed the connection]
[10:31:26] -!- odogono has quit [Read error: Connection reset by peer]
[10:31:30] odogono_ is now known as odogono
[10:32:53] -!- mhaberler has quit [Quit: mhaberler]
[10:52:58] -!- dway has quit [Client Quit]
[10:55:03] -!- Simooon has quit [Remote host closed the connection]
[10:59:16] -!- tayy has quit [Remote host closed the connection]
[11:44:14] -!- syyl_ has quit [Ping timeout: 256 seconds]
[11:44:14] -!- hewball has quit [Quit: No Ping reply in 180 seconds.]
[11:59:06] -!- mhaberler [mhaberler!~mhaberler@089144206029.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[12:03:15] -!- skunkworks has quit [Remote host closed the connection]
[12:14:56] -!- mhaberler has quit [Read error: Connection reset by peer]
[12:22:13] -!- mackerski_ has quit [Client Quit]
[12:24:25] -!- mackerski has quit [Ping timeout: 260 seconds]
[12:53:23] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:55:28] -!- mhaberler [mhaberler!~mhaberler@089144206029.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[13:04:34] -!- WolfieZero has quit [Quit: WolfieZero]
[13:12:47] -!- mhaberler has quit [Ping timeout: 255 seconds]
[13:13:06] -!- mhaberler_ [mhaberler_!~mhaberler@089144206029.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[13:20:33] -!- mhaberler_ has quit [Ping timeout: 248 seconds]
[13:23:07] -!- mackerski has quit [Remote host closed the connection]
[13:35:31] -!- mhaberler [mhaberler!~mhaberler@89.144.206.29] has joined #linuxcnc-devel
[13:52:30] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[13:58:55] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[14:01:51] -!- mhaberler has quit [Read error: Connection reset by peer]
[14:06:40] -!- JesusAlos has quit [Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344]]
[14:09:51] -!- dway has quit [Quit: dway]
[14:10:38] -!- mk0 has quit [Quit: Leaving]
[14:12:32] -!- nOStahl has quit [Ping timeout: 255 seconds]
[14:12:32] nOStahl_ is now known as nOStahl
[14:14:04] -!- chopper79 has quit [Quit: Leaving.]
[14:15:53] -!- tmcw has quit [Remote host closed the connection]
[14:17:06] -!- RagingComputer has quit [Ping timeout: 276 seconds]
[14:33:10] -!- Wildhoney has quit []
[14:52:12] -!- psha[work] has quit [Quit: Lost terminal]
[15:04:34] -!- JT-Shop has quit [Read error: Connection reset by peer]
[15:04:34] -!- jthornton has quit [Read error: Connection reset by peer]
[15:05:10] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[15:05:18] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[15:11:21] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[15:13:04] <seb_kuzminsky> bad news friends... the mdi queue test fails on 2.5 too, but in a different way
[15:13:19] <seb_kuzminsky> mdi commands get re-ordered :-/
[15:16:46] -!- cevad has quit [Quit: Leaving]
[15:19:40] <seb_kuzminsky> mdi commands get re-ordered :-/
[15:19:47] <seb_kuzminsky> oops, i think i said that already
[15:25:13] -!- nOStahl_ has quit [Remote host closed the connection]
[15:25:32] -!- tayy has quit [Remote host closed the connection]
[15:28:10] -!- nOStahl has quit [Ping timeout: 260 seconds]
[15:28:10] nOStahl_ is now known as nOStahl
[15:31:13] -!- AR_ has quit [Ping timeout: 248 seconds]
[15:32:09] -!- mackerski has quit [Ping timeout: 276 seconds]
[15:32:09] mackerski_ is now known as mackerski
[15:37:20] -!- tayy_ has quit [Remote host closed the connection]
[15:37:21] -!- The_Ball has quit [Ping timeout: 276 seconds]
[15:38:18] -!- DaViruz has quit [Quit: Lost terminal]
[15:38:56] -!- i_tarzan has quit [Read error: Connection reset by peer]
[15:39:20] -!- syyl_ws has quit [Quit: Verlassend]
[15:40:17] -!- tayy has quit [Ping timeout: 255 seconds]
[15:44:27] <skunkworks> what>
[15:44:36] <skunkworks> ? ;)
[15:46:28] -!- V0idExp has quit [Read error: No route to host]
[15:49:33] -!- V0idExp1 has quit [Ping timeout: 240 seconds]
[15:53:00] -!- kwallace [kwallace!~kwallace@tmb-223.sonnet.com] has joined #linuxcnc-devel
[15:57:49] -!- mephux has quit [Excess Flood]
[15:58:41] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[15:58:57] -!- mhaberler has quit [Read error: Connection reset by peer]
[15:59:06] -!- smsfail has quit [Read error: Connection reset by peer]
[15:59:08] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[16:06:29] -!- zzolo has quit [Quit: zzolo]
[16:14:06] -!- nOStahl has quit [Ping timeout: 276 seconds]
[16:14:07] nOStahl__ is now known as nOStahl
[16:16:23] -!- nOStahl_ has quit [Ping timeout: 255 seconds]
[16:19:05] -!- nOStahl has quit [Ping timeout: 255 seconds]
[16:19:05] nOStahl_ is now known as nOStahl
[16:19:24] -!- tmcw has quit [Remote host closed the connection]
[16:31:21] <mhaberler> seb_kuzminsky: mdi-queue-bugfix-2 passes runtests linuxcncrsh with qs=0,1,10000 - I vote for it!
[16:33:20] -!- r00t4rd3d has quit [Read error: Connection reset by peer]
[16:39:28] -!- mackerski has quit [Quit: mackerski]
[16:45:43] <seb_kuzminsky> he
[16:45:45] <seb_kuzminsky> h
[16:46:02] <seb_kuzminsky> do you think the logic of the patch is right?
[16:47:03] <seb_kuzminsky> the root of the problem was that the global (cough) emcCommand variable was used inconsistently
[16:48:55] <seb_kuzminsky> in main(), it's used to mean "the most recently seen command in the NML Command channel", but in emcTaskPlan() it sometimes meant that and sometimes "the MDI command we just took off the mdi_queue"
[16:55:45] <cradek> awesome
[16:56:07] <seb_kuzminsky> hi cradek
[16:56:13] <cradek> hi!
[16:59:43] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/mdi-queue/runtest-output-2.5
[17:00:14] <seb_kuzminsky> that's the mdi-queue test from master running on 2.5
[17:00:19] <seb_kuzminsky> i has a sad
[17:01:33] <seb_kuzminsky> at least the mdi queueing bug in 2.5 has excitingly different symptoms!
[17:04:26] -!- mephux has quit [Excess Flood]
[17:08:49] <skunkworks> did you guys see the name of the kmotions var file?
http://www.cnczone.com/forums/1237106-post2.html
[17:09:56] <seb_kuzminsky> cool :-)
[17:10:27] <skunkworks> makes you wonder how much has been taken from linuxcnc...
[17:14:13] <seb_kuzminsky> i don't know anything about kmotion... they sell machines? running linuxcnc apparently?
[17:15:08] -!- WolfieZero has quit [Remote host closed the connection]
[17:15:44] -!- tjb1 has quit [Quit: tjb1]
[17:16:10] <cradek> http://www.dynomotion.com/Software/Download.html
[17:16:41] <mhaberler> seb: here's an example for python scripting a linuxcnc test:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commit;h=2712e2facad053e0aa4ab93b4e918f3bda011c2b
[17:16:56] <cradek> I think I looked at their offerings some years ago and I was satisfied at the time that they were providing corresponding source
[17:17:12] <mhaberler> (runcmds.py is really slapped together from various leftovers)
[17:18:28] <seb_kuzminsky> i see they say they provide source for the cnc app, gcode interpreter, etc, but i don't see the actual link to the source
[17:20:39] <mhaberler> I _think_ the logic is right; I've never seen the serial go backwards or being compared <
[17:20:47] <mhaberler> we'll see ;)
[17:21:01] <seb_kuzminsky> maybe the source is in their .exe
[17:21:26] <mhaberler> re linuxcnc/DISPLAY: running without DISPLAY fails, but a fake shell script which does a sleep is fine
[17:22:08] <seb_kuzminsky> mhaberler: cool, i'll check out that python script
[17:22:26] <cradek> iirc, DISPLAY=halui works fine too
[17:22:33] <mhaberler> really just a proof of concept; machine does move
[17:27:15] <seb_kuzminsky> hmm, if you have multiple UIs (halui & axis, say), how do they coordinate their NML Command serial numbers?
[17:28:24] <cradek> they start at different numbers and hope for the best
[17:30:20] -!- mackerski has quit [Quit: mackerski]
[17:31:46] -!- WolfieZero has quit [Quit: WolfieZero]
[17:33:17] <seb_kuzminsky> sketchy!
[17:33:47] -!- jfire has quit [Quit: Leaving.]
[17:34:13] <cradek> see halui.cc:402
[17:34:21] -!- The_Ball has quit [Ping timeout: 276 seconds]
[17:38:08] <seb_kuzminsky> haha
[17:38:42] <seb_kuzminsky> i guess that particular wheel hasn't squeaked yet
[17:41:47] -!- tmcw has quit [Remote host closed the connection]
[17:42:47] <seb_kuzminsky> ok, in 2.5, mdi commands coming in to task get queued if interp is busy, that part looks good
[17:43:30] <mhaberler> why ?
[17:43:50] <seb_kuzminsky> but if a new mdi command comes in while the queue is draining, task issues the new one instead of appending it to the queue
[17:44:00] <seb_kuzminsky> this looks like an easy fix
[17:44:31] <mhaberler> do we have that mdi queuing fix just in master or in v2.5branch too?
[17:44:39] <mhaberler> I think its just master, hm
[17:45:47] <seb_kuzminsky> yeah, incoming mdi commands are handled just like any other in 2.5, independent of what the mdi queue is doing
[17:45:57] <seb_kuzminsky> in master, task handles incoming mdi specially
[17:46:13] <seb_kuzminsky> mhaberler: was that a bugfix you did in master a while ago?
[17:46:41] <mhaberler> there are 2 mdi queues - pavel's stunt and for queuebusters (mdi_execute_queue) and mine, which is only in master
[17:47:20] <mhaberler> the bug was: the perceived queuing feature was none, it was an error
[17:47:36] <mhaberler> commands in the interp cannot be considered atomic
[17:48:15] <mhaberler> so you _have_ to wait for interp_idle before fetching the next one, otherwise you have 2 cmds in the interp if the first one was a queue buster
[17:48:30] <seb_kuzminsky> mdi commands are atomic with regard to other mdi commands, but there's a big class of non-mdi commands that can change the state of the machine while an mdi command is executing
[17:48:30] <mhaberler> I gave a lengthy explanation on the devlist, letme see
[17:48:46] <mhaberler> you overlook queuebusters
[17:48:57] <seb_kuzminsky> i dont know what queuebusters are
[17:48:57] <mhaberler> toolchange, pin wait etc
[17:49:08] <seb_kuzminsky> what queue do they bust?
[17:49:16] <mhaberler> the motion queue.
[17:49:30] <mhaberler> hold on, lets find that devlist post
[17:49:30] <seb_kuzminsky> is that an NML channel from interp to motion?
[17:49:58] <mhaberler> forget those, those arent relevant - the issue is this:
[17:50:43] <mhaberler> the interp is waiting for the canon/motion q to drain because it is waiting for say a toolchange, or a synchronized pin read
[17:51:16] <mhaberler> while it is waiting, the next MDI command was pushed into the interp, overwriting state
[17:51:23] <mhaberler> hold on
[17:52:18] -!- adb has quit [Ping timeout: 256 seconds]
[17:52:44] <mhaberler> please read the thread 'queued MDI execution does not work in master' starting May 3
[17:53:03] * seb_kuzminsky reads
[17:54:43] <mhaberler> re queuebusters: see
http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_a_short_survey_of_emc_program_execution 17-17.5 has a short intro on it
[18:00:15] <mhaberler> so the purpose of _my_ MDI queue is: you can send a command to task, while interp/task is chewing on something, and that command will not trample on the state of an executing command - which happened to be the case, and AFAICT still is in v2.5_branch
[18:01:51] <seb_kuzminsky> there's definitely an mdi queueing bug in 2.5, but i'm not seeing the behavior i think you just described
[18:02:29] <mhaberler> it's quite difficult to trigger, see my post from:
[18:02:57] <seb_kuzminsky> i see task marking interp idle while interp is still working on a long-running mdi command (m6 in my case)
[18:03:05] <mhaberler> May 3, for instance:
[18:03:09] <mhaberler> - a call to an oword sub executing and that sub has a toolchange, probe or read HAL pin read operation
[18:03:10] <mhaberler> - that call is immediately followed by some other operation
[18:03:18] <seb_kuzminsky> but while interp is doing that, task correctly queues the mdi commands
[18:03:27] <seb_kuzminsky> hmm
[18:03:36] <seb_kuzminsky> do you have a test script somewhere?
[18:04:12] <mhaberler> not sure if I did a runtests script, need to look
[18:04:46] <mhaberler> the scenario is this: assume the oword proc does some feed moves, and then a m6
[18:05:23] <mhaberler> example: you push an MDI command which changes feed
[18:05:43] <mhaberler> the rest of the commands after M6 execute with the changed feed!
[18:06:24] <mhaberler> because there is just one static state blob, not per-command local state (_setup)
[18:06:52] <mhaberler> there was zero protection against that case
[18:08:37] -!- V0idExp has quit [Quit: Leaving.]
[18:08:59] <mhaberler> if the operation doesnt block, like a simple command which immediately queues a canon command, you are rarely if ever going to hit it due to the way interp scheduling works; you need a queuebuster to trip it (toolchange, read pin, probe); only then there is a chance a new command runs into an still executing command and changes its globale state before its done
[18:11:17] <mhaberler> it really tripped in master because you could remap say a M6 to a whole oword procedure, and then - after the actual TC in the procedure - the remaining commands are affected - depending on what part of _setup they reference, and which part of _setup the new command changes
[18:13:25] <mhaberler> the chance of hitting it by accident is rather low, but if it bites it could be fatal
[18:13:34] <seb_kuzminsky> well, do you want to fix this in 2.5? seems like you know a lot more about the issue than i
[18:14:06] <mhaberler> I have no opinion on that. I dont think backporting it to 2.5 was ever discussed
[18:14:24] <seb_kuzminsky> commit 877511a5eb46e9ff07dc207532a4c33ae1f41084 adds the mdi-queue test in master, it cherry-picks cleanly to 2.5 and fails pretty reliably for me
[18:14:41] <seb_kuzminsky> bugfixes generally should go into 2.5, then be merged into master in the usual way
[18:15:09] <seb_kuzminsky> we can do it retroactively with cherrypick, no problem
[18:15:17] <mhaberler> due to the fact that M6 is a fixed sequence in v2.5 the chance of hitting it is next to zero
[18:15:47] <seb_kuzminsky> what about other o-word subs?
[18:15:55] <seb_kuzminsky> non-remap subs, i mean
[18:16:28] <mhaberler> good question; if there's a probe, tc, pin read I would think it is likely to happen
[18:16:46] <mhaberler> I didnt find a test, but as an outline:
[18:17:39] <seb_kuzminsky> well, i guess i'll fix the bug i see, for now, and if you want to write a test and fix the bug you're talking about in 2.5 that'd be much appreciated
[18:18:30] <mhaberler> build an oword proc which : sets feed A, does a toolchange, then a feed move; execute that oword proc from mdi with 'osub call'; before acknowledging the M6 with the iocontrol pins, send a F<B> command in MDI
[18:18:51] <mhaberler> pretty sure the post-M6 feed move in the oword proc executes with feed B, not with feed A
[18:19:18] <mhaberler> that should work for pretty much any setting, not just feed
[18:19:49] <mhaberler> I'll think through a runtests trap for it
[18:20:23] <seb_kuzminsky> cool
[18:20:40] <mhaberler> the real issue is the inverted way interp is called
[18:20:54] <mhaberler> this stems from pre-oword/control flow times
[18:21:05] <seb_kuzminsky> you mean how task thinks interp is idle when it's really not? or something else?
[18:21:31] <mhaberler> no, its a structural problem which came through control flow
[18:22:08] <mhaberler> the way it works is: task calls interp to execute a command
[18:22:20] <mhaberler> now that could be a line, or a whole procedure
[18:22:32] <KGB-linuxcnc> 03seb 052.5-mdi-queue-test 279156b 06emc2 10tests/ 10(7 files in 2 dirs) * add an MDI queueing test
[18:22:54] <mhaberler> only the interp knows for sure, so task must jump these ugly hoops Pavel and Cradek came up with
[18:23:10] <KGB-linuxcnc> 03seb 052.5-mdi-queue-test 07ba5c6 06emc2 10src/emc/task/emctaskmain.cc * task: fix an MDI queueing bug
[18:23:11] <KGB-linuxcnc> 03seb 052.5-mdi-queue-test abcb719 06emc2 10src/emc/ 10task/emctask.cc 10task/emctaskmain.cc 10usr_intf/emcrsh.cc 10usr_intf/shcom.cc * some useful debug printing for the mdi queue bug
[18:23:19] <mhaberler> the issue wouldnt come up if interp were a thread, and tells task what it needs
[18:23:25] <seb_kuzminsky> ok, 279156 should fail if we're lucky
[18:23:27] <mhaberler> its kinda upside down
[18:23:37] <seb_kuzminsky> then the second push should make it pass again
[18:23:58] <seb_kuzminsky> 07ba5c6 fixes the bug, abcb719 just adds some logging i found helpful
[18:24:03] -!- Loetmichel has quit [Ping timeout: 260 seconds]
[18:25:02] <mhaberler> so you backported my mdi queue and your fix to 2.5, right?
[18:25:04] <seb_kuzminsky> i guess i haven't spelunked my way to that part of the code yet :-)
[18:25:09] <seb_kuzminsky> no
[18:25:24] <seb_kuzminsky> i just fixed the mdi reordering bug i saw in 2.5
[18:25:31] <mhaberler> ah ok
[18:25:51] <seb_kuzminsky> it used to immediately issue incoming mdi commands, even if there were queued ones from a long-running mdi like m6
[18:26:40] <seb_kuzminsky> oops, i left some debug printing in the bugfix commit
[18:26:54] <mhaberler> MDI is going to remain a mess until the calling inversion is removed - interp needs to tell task what it needs, not task guessing what interp might need
[18:27:09] <seb_kuzminsky> it
[18:27:45] <seb_kuzminsky> it's a pretty useful mess, but yes, from looking at the code i am not at all sure there's no more bugs in there ;-)
[18:28:13] <seb_kuzminsky> what's the joke, "you can make things so simple that there are obviously no bugs, or you can make them so complex that there are no obvious bugs"
[18:28:48] <mhaberler> unrelated, on support: a classic:
https://www.youtube.com/watch?v=rksCTVFtjM4
[18:29:09] <seb_kuzminsky> roy!
[18:30:48] -!- BenJacks1n [BenJacks1n!~bjj@kronos.home.ben.com] has joined #linuxcnc-devel
[18:31:21] -!- mephux has quit [Excess Flood]
[18:31:26] <seb_kuzminsky> "did she continue talking to you once you'd fixed her computer?" "no"
[18:31:27] <seb_kuzminsky> gold
[18:31:54] <seb_kuzminsky> but they cut off the follow-up line :-(
[18:32:06] <seb_kuzminsky> "and while i was fixing her computer, she rested a coffee cup on my back!"
[18:32:08] <mhaberler> there's a variation of that scene where he has a revox hooked to the phone giving the standard answers
[18:32:28] -!- BenJackson has quit [Read error: Connection reset by peer]
[18:32:28] -!- joe9 has quit [Read error: Operation timed out]
[18:32:29] -!- syyl__ has quit [Ping timeout: 256 seconds]
[18:32:29] -!- nevyn has quit [Write error: Broken pipe]
[18:32:35] -!- roh has quit [Read error: Operation timed out]
[18:33:33] <mhaberler> anyway, I'll see how that can be trapped; I definitely had it with GDB but thats probably not the greatest method for runtests
[18:34:19] <seb_kuzminsky> heh
[18:34:19] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[18:34:34] <mhaberler> and then lets patch that system call table since we dont wanna windup in invalid memory!
[18:34:34] <seb_kuzminsky> ok cool, i'm going to go do the kind of work that pays bills :-/
[18:34:41] <mhaberler> fair enough
[18:35:12] <mhaberler> good progress - thanks for being tenacious about it
[18:35:31] <seb_kuzminsky> i'll be back tonight or tomorrow, then if there are no objections i'll clean up and push the mdi queue test & fix to 2.5, and then figure out how that merges to master
[18:35:54] <seb_kuzminsky> *then* i'll go back to the toolno/pocketno bug i've been after for months now
[18:35:59] <mhaberler> ah
[18:36:12] <mhaberler> state change hell
[18:36:15] <seb_kuzminsky> the test & the fix for that is all ready, but these other bugs needed handling first
[18:38:55] <mhaberler> hm, actually the python method looks promising - with that you can wiggle hal pins without going through the interp, and that is needed to trigger it
[18:39:15] <mhaberler> (probe touch or t/c complete)
[18:39:37] <seb_kuzminsky> yeah, that's way more convenient than shell & halcmd
[18:39:46] <seb_kuzminsky> NO, I'M WORKING
[18:39:49] <mhaberler> ok.
[18:40:05] <mhaberler> I'm cooking, its 7:40pm
[18:42:18] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:46:52] -!- jthornton has quit [Read error: Connection reset by peer]
[18:46:52] -!- JT-Shop has quit [Read error: Connection reset by peer]
[18:48:17] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[18:48:18] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[18:51:37] Cylly is now known as Loetmichel
[18:52:45] -!- JT-Shop has quit [Ping timeout: 256 seconds]
[18:53:21] -!- jthornton has quit [Ping timeout: 276 seconds]
[18:54:32] -!- stsydow has quit [Remote host closed the connection]
[19:01:07] -!- JesusAlos has quit [Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]]
[19:05:15] -!- WolfieZero has quit [Quit: WolfieZero]
[19:06:11] -!- mhaberler has quit [Quit: mhaberler]
[19:07:23] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 18.0/20130108033621]]
[19:08:38] -!- holgi has quit [Quit: ChatZilla 0.9.90 [Firefox 19.0/20130218165301]]
[19:16:23] -!- skorasaurus has quit [Ping timeout: 245 seconds]
[19:19:23] BenJacks1n is now known as BenJackson
[19:36:19] -!- odogono has quit [Read error: Connection reset by peer]
[19:40:21] -!- ktchk has quit [Read error: Connection reset by peer]
[19:44:42] -!- micges [micges!~micges@exa128.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:48:07] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[19:53:15] -!- DaViruz_ has quit [Client Quit]
[19:53:41] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[19:53:43] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[19:56:23] -!- jthornton has quit [Read error: Connection reset by peer]
[19:56:23] -!- JT-Shop has quit [Read error: Connection reset by peer]
[19:57:43] -!- karavanjoW_ has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
[20:01:06] -!- Fabian_ has quit [Quit: Page closed]
[20:01:07] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:01:09] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:02:51] -!- JT-Shop has quit [Read error: Connection reset by peer]
[20:02:51] -!- jthornton has quit [Read error: Connection reset by peer]
[20:09:03] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[20:10:35] <skunkworks> logger[psha],
[20:17:08] -!- trewq has quit [Ping timeout: 245 seconds]
[20:30:15] -!- rizo has quit [Quit: Leaving]
[20:38:06] -!- mattions has quit [Ping timeout: 272 seconds]
[20:46:23] <linuxcnc-build_> build #798 of precise-amd64-sim is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/798 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:47:53] <seb_kuzminsky> that's awesome, the push that was supposed to demonstrate the test failure passed, and the push with the fix failed
[20:48:05] <seb_kuzminsky> my commits rock
[20:49:08] <seb_kuzminsky> i did know that the fix i had pushed only made the race window smaller, it didn't completely close it
[20:50:47] <seb_kuzminsky> in v2.5_branch, a new MDI command any time while draining the mdi queue triggers the bug, in the 2.5-mdi-queue-test branch only incoming MDI commands while interp is doing the last of the queued commands triggers the bug :-/
[20:51:26] <seb_kuzminsky> i bet there's a global flag variable somewhere that has the state i want for the proper fix
[21:01:16] -!- odogono has quit [Read error: Connection reset by peer]
[21:03:30] -!- Tecan has quit [Read error: Connection reset by peer]
[21:05:44] -!- cjd_ has quit [Client Quit]
[21:09:57] -!- Tecan has quit [Changing host]
[21:11:10] <seb_kuzminsky> awesome, mdi_execute_hook() is recursive
[21:11:22] * seb_kuzminsky 's head explodes
[21:16:57] <kwallace> I hate when that happens, then I have to clean the keyboard and monitor, ... again.
[21:19:05] <linuxcnc-build_> build #793 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/793 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[21:28:15] -!- bedah has quit [Quit: Ex-Chat]
[21:28:19] -!- tmcw has quit [Remote host closed the connection]
[21:32:31] -!- odogono has quit [Quit: odogono]
[21:35:00] -!- vladimirek has quit [Remote host closed the connection]
[21:53:50] -!- mephux has quit [Excess Flood]
[21:57:45] -!- mackerski has quit [Quit: mackerski]
[21:59:06] -!- wboykinm has quit [Remote host closed the connection]
[22:05:06] -!- Tom_L has quit []
[22:10:48] -!- FinboySlick has quit [Quit: Leaving.]
[22:21:50] -!- DJ9DJ has quit [Quit: bye]
[22:24:22] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[22:28:40] -!- skunkworks has quit [Read error: Connection reset by peer]
[22:29:51] -!- micges has quit [Quit: Leaving]
[22:36:48] -!- L33TG33KG34R has quit [Ping timeout: 252 seconds]
[22:37:34] -!- vladimirek has quit [Remote host closed the connection]
[22:58:01] -!- racycle has quit [Quit: racycle]
[23:00:16] -!- micges [micges!~micges@exa128.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[23:04:33] -!- cevad has quit [Ping timeout: 248 seconds]
[23:05:28] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[23:18:18] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[23:19:46] -!- sumpfralle has quit [Quit: Leaving.]
[23:21:49] -!- Brandonian has quit [Quit: Brandonian]
[23:35:50] -!- chopper79 has quit [Quit: Leaving.]
[23:37:10] -!- gene77 has quit [Read error: Operation timed out]
[23:37:33] -!- gene77 [gene77!~gene@204.111.64.149] has joined #linuxcnc-devel
[23:39:15] -!- WolfieZero has quit [Quit: WolfieZero]
[23:40:33] -!- ravenlock has quit [Ping timeout: 240 seconds]
[23:42:51] nevyn_ is now known as nevyn
[23:42:56] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[23:48:44] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[23:49:50] -!- mackerski has quit [Client Quit]