Back
[09:58:02] <jepler> emc/rs274ngc/gcodemodule.cc: In function ‘PyObject* rs274_arc_to_segments(PyObject*, PyObject*)’:
[09:58:05] <jepler> emc/rs274ngc/gcodemodule.cc:924:12: warning: ‘plane’ may be used uninitialized in this function [-Wmaybe-uninitialized]
[09:58:08] <jepler> } else if(plane == 3) {
[09:58:11] <jepler> huh I don't remember seeing this diagnostic
[09:58:12] <jepler> but surely nobody's been touching that code
[09:59:07] <seb_kuzminsky> new compiler?
[10:01:10] <jepler> I did turn on --coverage
[10:02:15] <jepler> File 'emc/rs274ngc/interp_read.cc'
[10:02:15] <jepler> Lines executed:75.28% of 724
[10:02:15] <jepler> Creating 'interp_read.cc.gcov'
[10:02:27] <jepler> not bad coverage in some of these source files, just from stuff in tests/interp
[10:02:54] <jepler> File 'emc/rs274ngc/interp_remap.cc'
[10:02:54] <jepler> Lines executed:4.15% of 217
[10:02:58] <jepler> not so great elsewhere
[10:12:05] <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
[10:13:05] <mozmck> But I'm not sure. In python is seems that stat.call_level is always 1
[10:14:03] <mozmck> In my notes I say "current subroutine level - 0 if not in a subroutine, > 0 otherwise" - is that true?
[10:14:22] <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)
[10:15:50] <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.
[10:16:31] <jepler> http://media.unpythonic.net/rs274-coverage/index.html
[10:18:37] <cradek> I'm sure fuzzy about how that works too, sorry :-/
[10:19:00] <jepler> I am sure nothing has routinely checked what value stat.call_level actually has
[10:19:18] <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
[10:19:27] <jepler> sometimes I'm not even sure where the text that found its way into the documentation came from
[10:20:01] <cradek> I only remember him briefly mentioning this, but adding source filename seems like a useful and obvious extension to the state-tags model
[10:20:14] <mozmck> jepler: I added stat.call_level in the commit I mentioned above. I could have missed something though when I did it.
[10:20:20] <cradek> (the only problem being that filenames can be long)
[10:20:24] <jepler> oh you added it
[10:21:01] <mozmck> Yeah, because I needed a way to not send a gtk event for a external subroutine getting run.
[10:21:42] <mozmck> It was causing gremlin and the gcodeview widget to reload and was causing problems.
[10:22:27] <jepler> AXIS only ever loads a part program in response to file>load, file>reload, and the axis-remote equivalent
[10:22:44] <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.
[10:22:47] <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
[10:22:56] <mozmck> jepler: yes, that is a much better way to do it IMO
[10:24:10] <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.
[10:24:10] <mozmck> Some of these things are why I would really like to look into a QT gui system for making GUIs
[10:24:29] <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
[10:25:27] <cradek> after toolchangersubroutine.ngc is done, it jumps back to the right spot and continues
[10:25:32] <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
[10:25:34] <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.
[10:26:58] <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.
[10:27:01] <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?
[10:28:06] <cradek> (I haven't examined the grass on the qt side of the fence but I doubt it's really much greener over there)
[10:28:17] <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.
[10:28:50] <mozmck> Well, I have heard from many other devs that qt is far far nicer/cleaner/more sane.
[10:28:52] <cradek> hmm, lots of code jumps backwards...
[10:30:06] <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.
[10:31:07] <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.
[10:31:47] <mozmck> But not ideal, which is why I'm still trying to get a valid current file name or call level to check.
[10:33:10] <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.
[10:38:57] <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
[10:39:23] <cradek> if you want the filename I'm not sure what's a good way to store it
[10:40:26] <cradek> maybe you could add remap level as settings[3]
[10:40:40] <mozmck> where would that be? I added call_level in Stat_members[] in emcmodule.cc right before the motion_line field...
[10:40:42] <cradek> not sure how you'd present it in the active gcodes readout (you wouldn't have to)
[10:41:13] <mozmck> Yeah, I should not need it displayed anywhere, I just need to check it in hal_glib and the codeview widget.
[10:41:49] <mozmck> I use it in hal_glib and it seems to work in one particular case there, but I'm not sure why
[10:42:00] <mozmck> or why not elsewhere anyhow.
[10:43:32] <mozmck> A search for GM_FIELD_LINE_NUMBER showed no results - is that in master? I am still using 2.7.x
[10:43:53] <cradek> mozmck: I sorta figured out how to add a field to all the layers - I hope zultron checks it for me - in 5a7c7d9d
[10:44:00] <cradek> I'm talking about the statetags branch, which is on top of master
[10:44:10] <mozmck> Ah - I see.
[10:44:35] <mozmck> It will be a while before I can switch to master I'm afraid.
[10:44:58] <cradek> I don't think it can work otherwise...? other than line number, aren't you always getting the readahead state?
[11:12:23] <mozmck> That I don't know for sure, but maybe that would explain some of it.
[11:27:12] <cradek> sorry, wish I knew more about this and could give you answers instead of questions
[13:22:13] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tseufl opened issue #204: docs: LinuxCNC_Documentation.pdf - double chapter 02
https://github.com/LinuxCNC/linuxcnc/issues/204
[13:23:23] <andypugh> I failed. I let him get to me.
[13:30:32] <cradek> :-(
[13:34:21] <JT-Shop> rut-row
[13:41:36] <kwallace_ofcb> https://www.youtube.com/watch?v=TvQViPBAvPk
[14:44:45] -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
[17:27:17] -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
[17:33:29] <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
[17:42:24] <seb_kuzminsky> mozmck: i think the answer is statetags
[17:47:47] <mozmck> seb_kuzminsky: I can't switch to master right now though. That will take a good bit of testing and changes.
[17:49:28] <mozmck> where is the statetags stuff? I looked on github and in the two branches I see, the last commit is in Feb 2015
[18:30:52] <cradek> mozmck: git.linuxcnc.org branch statetags
[18:32:07] <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.
[18:32:07] <mozmck> cradek: thanks - I guess I missed that while scrolling through the 239 branches ;-)
[18:32:24] <cradek> haha
[19:00:21] <cradek> I really suspect you could backport it to 2.7
[19:00:55] <cradek> we almost certainly aren't putting it in 2.7, but maybe you could maintain it separately for your customers
[19:02:22] <mozmck> Yeah, I see that there is a branch "features/state-tags-2.7-signed" - but it's probably way behind.
[19:03:10] <mozmck> Is there any docs on state-tags? I'm trying to understand exactly what it is.
[19:05:07] <mozmck> bbl
[21:48:35] <cradek> mozmck: no docs, but the summary is: attach to moves a summary of the interpreter state (like the line number has been attached for a while) and do two things with it: show the active gcodes from those tags as the moves execute, AND in the case of abort, use the latest tag to restore the interp state as if readahead had not happened
[21:49:44] <Tom_L> sounds like a good thing
[21:49:50] <cradek> part 1 is the important one to you: just add the interp stack level to the tags
[21:49:58] <cradek> "just"
[21:50:28] <cradek> yeah it's a super good change
[21:50:46] <Tom_L> will be able to run from line better etc
[21:51:03] <Tom_L> is that the idea?
[21:51:10] <cradek> it sure might help with that
[21:51:37] <cradek> I think the idea was keep users from being baffled by readahead
[21:51:48] <Tom_L> andy's tool table sounds good too
[21:51:53] <cradek> it makes things seem weird in a lot of ways
[21:51:58] <cradek> yes it sure is
[21:52:18] <Tom_L> did he make it to the fest?
[21:52:24] <cradek> wish the bikeshedders would leave him alone
[21:52:38] <cradek> not this time, saw him 2? yrs ago though
[21:52:45] <Tom_L> yeah something like that
[21:53:06] <Tom_L> bikeshedders?
[21:53:15] <Tom_L> someone buggin him on the forum?
[21:53:49] <cradek> google bikeshedding as regards software development, I'm on a phone or I'd do it for you
[21:53:58] <Tom_L> k
[21:54:23] <cradek> teeny tiny keyboard
[21:54:36] <Tom_L> yeah i hate phones for that
[21:54:43] <Tom_L> found it
[21:55:17] <cradek> did you find the original freebsd mailing list post?
[21:55:20] <Tom_L> nit picking
[21:55:48] <Tom_L> to a fault
[21:56:29] <cradek> yeah, having an opinion about unimportant decisions and getting in the way of talking about the important
[21:56:42] <cradek> we all do it :-/
[21:56:55] <Tom_L> some catch it quicker than others
[21:58:54] <cradek> it helped me to learn about the pattern so I can squash it in myself
[21:59:10] <cradek> because it's a very real effect and it's destructive
[21:59:18] <Tom_L> yup
[21:59:39] <Tom_L> i believe it caused the split 2 yrs ago
[21:59:52] <Tom_L> possibly
[22:00:23] <Tom_L> there may have been more to that
[22:00:29] <cradek> I don't really agree with you, but you may be a few % right
[22:00:53] <Tom_L> some saw things differently i guess
[22:01:13] <cradek> I think that split has been good for everyone
[22:01:14] <Tom_L> i really haven't followed the other project at all
[22:01:50] <cradek> I hope it's thriving too
[22:01:56] <Tom_L> so do i
[22:02:05] <Tom_L> it can only help everyone i think
[22:03:06] <cradek> two machinekit guys were at fest, and it was great to see them
[22:03:22] <Tom_L> mharbler one of em?
[22:03:38] <Tom_L> he's really the only one i knew of
[22:03:41] <cradek> nope
[22:42:41] <skunksleep> cradek: I assume you met the guy that goes by dragon?
[22:42:59] <skunksleep> Sounded like he went to the fest
[22:44:38] <skunksleep> He is from around here. We had a mini fest at the shop a few years ago and the local Linux group came. He is a member. (I still need to go to a meeting)
[23:00:47] <cradek> yes I think dragon is todd, who we talked a lot with
[23:01:17] <cradek> he wants to make lathe roughing cycles and I think he's smart enough to do it