Back
[00:06:43] -!- kingarmadillo has quit [Ping timeout: 245 seconds]
[00:20:00] -!- ssd64 [ssd64!~ssd64@2601:647:ca00:400:751b:b8d:c048:f01e] has joined #linuxcnc-devel
[00:27:10] -!- ssd64 has quit [Quit: Leaving]
[00:53:49] -!- skunkworks_ [skunkworks_!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[04:11:10] -!- zeeshan has quit [Read error: Connection reset by peer]
[04:36:02] -!- Connor has quit [Remote host closed the connection]
[04:43:33] -!- Connor [Connor!~Connor@c-73-19-211-160.hsd1.tn.comcast.net] has joined #linuxcnc-devel
[06:07:33] -!- Connor has quit [Ping timeout: 244 seconds]
[06:14:23] -!- Connor [Connor!~Connor@user-69-1-48-71.knology.net] has joined #linuxcnc-devel
[06:20:14] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has parted #linuxcnc-devel
[07:09:39] -!- SB_ [SB_!~SB@2001:760:2c0c:702:b541:a6b9:67b2:f34c] has joined #linuxcnc-devel
[07:29:00] -!- SB_ has quit [Read error: Connection reset by peer]
[07:41:53] -!- Connor has quit [Ping timeout: 260 seconds]
[07:42:52] -!- Connor [Connor!~Connor@71.203.255.220] has joined #linuxcnc-devel
[10:25:41] -!- beawesomeinstead has quit [Ping timeout: 260 seconds]
[11:19:28] -!- b_b has quit [Changing host]
[11:19:49] -!- pcw_home has quit [Ping timeout: 260 seconds]
[11:27:01] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[13:20:12] -!- steves_logging has quit []
[13:34:58] -!- steves_logging [steves_logging!~Steve@wsip-70-182-2-252.dc.dc.cox.net] has joined #linuxcnc-devel
[13:49:32] -!- pcw_home [pcw_home!~chatzilla@c-50-143-148-115.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[14:03:24] -!- beawesomeinstead has quit [Ping timeout: 244 seconds]
[14:29:45] <jepler> emc/rs274ngc/gcodemodule.cc: In function ‘PyObject* rs274_arc_to_segments(PyObject*, PyObject*)’:
[14:29:48] <jepler> emc/rs274ngc/gcodemodule.cc:924:12: warning: ‘plane’ may be used uninitialized in this function [-Wmaybe-uninitialized]
[14:29:51] <jepler> } else if(plane == 3) {
[14:29:54] <jepler> huh I don't remember seeing this diagnostic
[14:29:55] <jepler> but surely nobody's been touching that code
[14:30:50] <seb_kuzminsky> new compiler?
[14:32:54] <jepler> I did turn on --coverage
[14:33:58] <jepler> File 'emc/rs274ngc/interp_read.cc'
[14:33:58] <jepler> Lines executed:75.28% of 724
[14:33:58] <jepler> Creating 'interp_read.cc.gcov'
[14:34:10] <jepler> not bad coverage in some of these source files, just from stuff in tests/interp
[14:34:37] <jepler> File 'emc/rs274ngc/interp_remap.cc'
[14:34:37] <jepler> Lines executed:4.15% of 217
[14:34:41] <jepler> not so great elsewhere
[14:43:48] <mozmck> I think I had some things wrong in my mind and notes when I added callLevel to EMC_TASK_STAT here:
https://github.com/LinuxCNC/linuxcnc/commit/6b90e145130ef07570acc07dfe6be92bff563d4e
[14:44:48] <mozmck> But I'm not sure. In python is seems that stat.call_level is always 1
[14:45:46] <mozmck> In my notes I say "current subroutine level - 0 if not in a subroutine, > 0 otherwise" - is that true?
[14:46:05] <cradek> mozmck: I think zultron told me that rob might have an enhancement to state tags that also adds the executing file alongside the executing line number (and the lots of other things in the state tag now)
[14:47:33] <mozmck> That will be nice! What I'm seeing is that the file name and call_level seem to almost always be wrong in the python stat object. Trying to figure it out.
[14:48:14] <jepler> http://media.unpythonic.net/rs274-coverage/index.html
[14:50:20] <cradek> I'm sure fuzzy about how that works too, sorry :-/
[14:50:43] <jepler> I am sure nothing has routinely checked what value stat.call_level actually has
[14:51:01] <cradek> I think state-tags will merge soon, so you might want to consider working on top of that, or waiting for zultron and rob to see what they have, or contact them and ask
[14:51:10] <jepler> sometimes I'm not even sure where the text that found its way into the documentation came from
[14:51:44] <cradek> I only remember him briefly mentioning this, but adding source filename seems like a useful and obvious extension to the state-tags model
[14:51:57] <mozmck> jepler: I added stat.call_level in the commit I mentioned above. I could have missed something though when I did it.
[14:52:03] <cradek> (the only problem being that filenames can be long)
[14:52:07] <jepler> oh you added it
[14:52:44] <mozmck> Yeah, because I needed a way to not send a gtk event for a external subroutine getting run.
[14:53:25] <mozmck> It was causing gremlin and the gcodeview widget to reload and was causing problems.
[14:53:33] -!- pozzoni has quit [Ping timeout: 260 seconds]
[14:54:13] <jepler> AXIS only ever loads a part program in response to file>load, file>reload, and the axis-remote equivalent
[14:54:27] <mozmck> The file name though was already there, and it does not seem to be correct at least in the python object. The line number seems correct.
[14:54:32] <jepler> since gremlin/gscreen are made up of a bunch of rando widgets that don't really talk to each other, I see where this kind of problem could occur
[14:54:39] <mozmck> jepler: yes, that is a much better way to do it IMO
[14:55:49] <mozmck> Using events to trigger this is not ideal, but it's a lot more work for me to change all that right now. I did look into it.
[14:55:49] <mozmck> Some of these things are why I would really like to look into a QT gui system for making GUIs
[14:56:12] <cradek> the minor problem I've seen in AXIS is the highlighted line jumps to line 3 in mypartprogram.ngc, when it's actually running line 3 in toolchangersubroutine.ngc
[14:57:10] <cradek> after toolchangersubroutine.ngc is done, it jumps back to the right spot and continues
[14:57:12] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has joined #linuxcnc-devel
[14:57:15] <jepler> on the one hand I see everyone irritated by just how glade works. on the other hand, "just a bunch of rando widgets that don't really talk to each other" is an antipattern you can code in *ANY* toolkit, and is very likely to result anytime you try to make the UI configurable by the integrator or end-user
[14:57:17] <mozmck> cradek: that's exactly the issue I'm trying to fix right now. If someone stops right there they will lose where they actually were, and then run-from-line will be difficult or impossible.
[14:58:41] <mozmck> jepler: that's very true. It is the glade/gtk issues that make me want to use qt, and the random widgets not designed ideally that makes me want to make another system no matter what underlying toolkit is used.
[14:58:44] <cradek> what is your design? do you want it to show the executing toolchangersubroutine.ngc, or just leave the highlighted line on M6 in mypartprogram.ngc until it finishes?
[14:59:57] <cradek> (I haven't examined the grass on the qt side of the fence but I doubt it's really much greener over there)
[14:59:59] <mozmck> I have a subroutine called touchoff.ngc that does a probe, and I want it to stay there until it is done. I'm thinking I may just make my codeview widget ignore any lines that are before the last line executed.
[15:00:33] <mozmck> Well, I have heard from many other devs that qt is far far nicer/cleaner/more sane.
[15:00:35] <cradek> hmm, lots of code jumps backwards...
[15:01:49] <mozmck> There is a presentation by a guy who works with linus torvalds on a scuba diving program explaining all the benefits they had moving to qt from gtk.
[15:02:50] <mozmck> cradek: yes, this would be a hack that should work for us, because most of our customers use SheetCAM with our post and there are no loops in the code.
[15:03:30] <mozmck> But not ideal, which is why I'm still trying to get a valid current file name or call level to check.
[15:04:53] <mozmck> Shoot, the win32 API in windows 95 was better than GTK! I was astounded at how hard it was to do simple things like make and fill a drop down list box in GTK - and many other such things.
[15:10:40] <cradek> looks like if you only want the remap level (an integer) you could add it as a StateField just like GM_FIELD_LINE_NUMBER
[15:11:06] <cradek> if you want the filename I'm not sure what's a good way to store it
[15:12:09] <cradek> maybe you could add remap level as settings[3]
[15:12:23] <mozmck> where would that be? I added call_level in Stat_members[] in emcmodule.cc right before the motion_line field...
[15:12:25] <cradek> not sure how you'd present it in the active gcodes readout (you wouldn't have to)
[15:12:56] <mozmck> Yeah, I should not need it displayed anywhere, I just need to check it in hal_glib and the codeview widget.
[15:13:32] <mozmck> I use it in hal_glib and it seems to work in one particular case there, but I'm not sure why
[15:13:43] <mozmck> or why not elsewhere anyhow.
[15:15:15] <mozmck> A search for GM_FIELD_LINE_NUMBER showed no results - is that in master? I am still using 2.7.x
[15:15:36] <cradek> mozmck: I sorta figured out how to add a field to all the layers - I hope zultron checks it for me - in 5a7c7d9d
[15:15:43] <cradek> I'm talking about the statetags branch, which is on top of master
[15:15:53] <mozmck> Ah - I see.
[15:16:18] <mozmck> It will be a while before I can switch to master I'm afraid.
[15:16:41] <cradek> I don't think it can work otherwise...? other than line number, aren't you always getting the readahead state?
[15:31:28] -!- Daerist has quit [Quit: Leaving]
[15:44:06] <mozmck> That I don't know for sure, but maybe that would explain some of it.
[15:58:55] <cradek> sorry, wish I knew more about this and could give you answers instead of questions
[16:08:49] -!- catbadger has quit [Quit: Konversation terminated!]
[16:16:11] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[16:17:12] -!- b_b has quit [Remote host closed the connection]
[16:29:38] -!- pozzoni has quit [Ping timeout: 245 seconds]
[17:17:10] -!- Daerist has quit [Quit: Leaving]
[17:29:10] -!- skunkworks_ has quit [Ping timeout: 256 seconds]
[17:53:56] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tseufl opened issue #204: docs: LinuxCNC_Documentation.pdf - double chapter 02
https://github.com/LinuxCNC/linuxcnc/issues/204
[17:55:07] <andypugh> I failed. I let him get to me.
[18:02:15] <cradek> :-(
[18:06:04] <JT-Shop> rut-row
[18:10:11] -!- catbadger has quit [Quit: Konversation terminated!]
[18:13:19] <kwallace_ofcb> https://www.youtube.com/watch?v=TvQViPBAvPk
[18:21:44] -!- JT-Shopp [JT-Shopp!~john@198.45.191.246] has joined #linuxcnc-devel
[18:21:44] -!- jthornton- [jthornton-!~john@198.45.191.246] has joined #linuxcnc-devel
[18:21:44] -!- JT-i3- [JT-i3-!~john@198.45.191.246] has joined #linuxcnc-devel
[18:21:45] -!- JT-i3 has quit [Read error: Connection reset by peer]
[18:21:45] -!- JT-Shop has quit [Read error: Connection reset by peer]
[18:21:45] -!- jthornton has quit [Read error: Connection reset by peer]
[18:31:43] -!- kalxas has quit [Ping timeout: 245 seconds]
[18:32:20] amnesicz is now known as amnesic_away
[18:47:34] -!- pragmaticus has quit [Remote host closed the connection]
[19:04:51] -!- skunkworks_ [skunkworks_!~skunkwork@174-124-73-175.dyn.centurytel.net] has joined #linuxcnc-devel
[19:16:28] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tseufl opened pull request #205: Update de.po - joints-axes <-> Achse/Gelenk (06master...06patch-1) 02
https://github.com/LinuxCNC/linuxcnc/pull/205
[19:43:44] amnesic_away is now known as amnesic
[20:03:29] kalxas_ is now known as kalxas
[20:09:46] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[20:18:03] -!- kalxas has quit [Quit: Goodbye]
[20:42:38] amnesic is now known as amnesic_away
[21:58:16] JT-Shopp is now known as JT-Shop
[21:59:00] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tseufl opened issue #206: docs: man9 / hostmod 2.9 - broken/wrong links 02
https://github.com/LinuxCNC/linuxcnc/issues/206
[22:05:12] <mozmck> cradek: I'm thinking you are right that I'm using the call level from task which is the readahead state. What I need to figure out is how to change that to use the call level from motion I think
[22:14:28] <seb_kuzminsky> mozmck: i think the answer is statetags
[22:19:30] <mozmck> seb_kuzminsky: I can't switch to master right now though. That will take a good bit of testing and changes.
[22:21:11] <mozmck> where is the statetags stuff? I looked on github and in the two branches I see, the last commit is in Feb 2015
[22:23:49] -!- andypugh has quit [Quit: andypugh]
[22:27:34] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[22:28:16] JT-i3- is now known as JT-i3
[23:02:35] <cradek> mozmck: git.linuxcnc.org branch statetags
[23:03:50] <cradek> mozmck: when you run AXIS on that branch, you'll see the active gcodes have been moved so they're visible during program execution and they show the state of the active motion. you can add the remap level, and maybe also the running filename, to that.
[23:03:50] <mozmck> cradek: thanks - I guess I missed that while scrolling through the 239 branches ;-)
[23:04:07] <cradek> haha
[23:22:44] -!- skunkworks_ has quit [Ping timeout: 250 seconds]
[23:27:56] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[23:32:04] <cradek> I really suspect you could backport it to 2.7
[23:32:32] <cradek> we almost certainly aren't putting it in 2.7, but maybe you could maintain it separately for your customers
[23:34:05] <mozmck> Yeah, I see that there is a branch "features/state-tags-2.7-signed" - but it's probably way behind.
[23:34:53] <mozmck> Is there any docs on state-tags? I'm trying to understand exactly what it is.
[23:36:08] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:7c82:a996:bf8f:63eb] has joined #linuxcnc-devel
[23:36:50] <mozmck> bbl
[23:37:53] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:7c82:a996:bf8f:63eb] has parted #linuxcnc-devel