Back
[00:08:07] <dmwaters> {global notice} Good day all, I have a fairly large rotation server that needs to be restarted, about 6000 users. This won't take long, but it will be a bit noisey. I apologize for the inconvenience. Thank you for your patience, and thank you for using freenode!
[00:09:36] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[00:33:11] <skunkworks> so - when the laptop battery gets so hot that it could burn your hand.. Probably something wrong ;)
[00:35:10] <skunkworks> biab
[11:58:53] <CIA-34> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/code/NML_Messages.lyx: Add NML Messages to Developer Manual
[12:02:07] <CIA-34> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Master_Developer.lyx Submakefile): Add link to Stepconf
[12:02:23] <CIA-34> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/stepper.lyx: Add link to Stepconf
[12:03:23] <CIA-34> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/config/stepper.lyx: Added link to Stepconf
[12:05:44] <BigJohnT> * BigJohnT heads off to build machines
[18:04:30] <lerman> cradek: are you around?
[20:58:42] <lerman> jepler: are you around?
[20:59:21] <alex_joni> jepler is on a trip
[20:59:31] <alex_joni> lerman: just ask your question.. they will see it/answer it later
[20:59:54] <micges> hi all
[21:00:12] <lerman> I wanted to ask about an issue regarding Axis. Axis doesn't know when the interpreter starts to interpret a new file.
[21:00:55] <lerman> I added that ability as part of the subroutine stuff. If the sub isn't defined in the current file, the interp looks for a file of that name and starts interpreting there.
[21:01:13] <lerman> It works just fine -- but none of the gui's know about it.
[21:01:49] <lerman> I discovered that problem when I successfully ran my first program containing wizard generated code.
[21:03:50] <lerman> BTW: In the process of working on the wizard, I concluded that it would be easier if I user defined gcodes. After taking a look at it, I've concluded that it should be straight forward.
[21:24:10] <rayh> lerman what would a gui need to "know" to use this ability?
[21:25:05] <lerman> To properly display the current line in the gui, the gui would need to know the name of the current file and the line number in that file.
[21:26:04] <lerman> The problem is that the interpreter can "jump" (via a subroutine call) to another file and there is no way for the gui to know about it.
[21:26:12] <lerman> (as far as I know).
[21:26:35] <rayh> What happens to the program being displayed as running.
[21:26:50] <rayh> Does it only show the line that called the new file?
[21:27:04] <lerman> I'm not sure.
[21:27:46] <lerman> It may see the new line number and think that it is in the old file. It would be interesting to try single stepping through this type of event.
[21:28:38] <lerman> The issue will get worse (if that's possible) when I've implemented user defined gcodes.
[21:29:00] <rayh> I recently read Tom Kramer's report on interpreter version 1. It says "The interpreter does not have the concept of a program. "
[21:29:16] <rayh> IMO this is still true.
[21:29:17] <lerman> It's not clear what will happen when you single step through a user defined gcode subroutine.
[21:29:44] <lerman> What does that statement mean? Does it mean that the interpreter only knows about lines (blocks)?
[21:29:44] <rayh> It is the gui that preserves the program that was loaded.
[21:29:49] <rayh> Notice the was
[21:30:22] <lerman> That is correct. The program is never "loaded". It is read one line at a time.
[21:30:34] <rayh> Once loaded then we read the currently executing line and highlight that in the gui's program.
[21:30:52] <lerman> In the case of a loop, or a subroutine, it goes to another line.
[21:31:36] <lerman> You are correct, I think. There is a variable somewhere that the interpreter updates to show the current line.
[21:31:54] <lerman> Another variable should be added to show the current file name (full path).
[21:31:58] <rayh> My opinion is that someday we will have to fix Tom's work so that an interpreter does know about a program.
[21:32:18] <lerman> That way, the gui could detect the change of file and read the new one.
[21:32:40] <rayh> And knows that it has called another program, inserted it here, and is executing these blocks of code from this location.
[21:32:55] <lerman> What knowledge would the interpreter have? Oops you answered that.
[21:33:29] <lerman> The interpreter NOW knows about the current file and line. Also, how it got there. It maintains a stack of subroutine calls.
[21:33:43] <rayh> It is a travesty of the Unix way that we force the gui to reassemble what code it thinks the interpreter has put onto the execution stack.
[21:34:35] <lerman> Well, the stack to be exposed to the gui. That would be nice in that it would contain the arguments, etc.
[21:34:54] <lerman> The gui could then show stuff that would be useful for debugging.
[21:35:22] <lerman> ^to be exposed^ could be exposed^
[21:35:24] <rayh> You bet. And then it could also expose the modal codes associated with the currently executing line.
[21:35:51] <rayh> regardless of where that line came from.
[21:36:02] <rayh> and it would make restart at any line trivial.
[21:36:12] <rayh> well almost trivial
[21:36:30] <lerman> Well, you can't just pick a line within a subroutine without knowing how it was called and from where.
[21:36:41] <rayh> Right.
[21:37:10] <lerman> But, we could keep a trace of the history that would allow restart at any point in the trace. Also, backwards motion, fast rewind and forward, etc.
[21:37:43] <rayh> But when the interpreter works ahead, it is using a line of code from someplace.
[21:37:56] <lerman> Today's model should be very different than the historic model. We have a lot more machine available.
[21:38:02] <rayh> If that line of code also produces lines of code...
[21:38:28] <rayh> gcode blocks might be a better way of thinking of it.
[21:38:44] <lerman> gcode block == line
[21:38:56] <rayh> yep.
[21:39:39] <lerman> A line of code doesn't 'produce' lines of code, it executes them. Every line of code already exists in a file somewhere.
[21:40:04] <lerman> Even user defined gcodes are contained in a file that could (should?) be displayed by the gui.
[21:40:52] <rayh> If you imagine a SAI running your subroutine that calls another file to run, each line/block creates a set of canonicals.
[21:40:53] <lerman> Unfortunately, there are several guis that should be updated to handle the new (multi-file) features.
[21:41:17] <lerman> Yes. The canonicals are created.
[21:41:30] <rayh> I'm suggesting a change to the interpreter that eases that task.
[21:41:40] <lerman> What change?
[21:42:07] <lerman> ...specifically.
[21:42:11] <rayh> Imagine that I'm watching somewhere near where the task planner hands a canonical to motion.
[21:43:12] <rayh> as it does that, I think it needs to know where in the main program, the subroutines, the other files that it got that canonical from.
[21:44:09] <rayh> And associated with that canonical it needs to know the state of the modal codes in the interpreter at the time that canonical was created.
[21:44:26] <lerman> Well, we could pass the whole subroutine stack. Not all of that is needed to provide a minimal capability.
[21:44:55] <rayh> True.
[21:44:59] <lerman> An issue is how much of that we can impose on the gui developers without pissing them off.
[21:45:18] <lerman> (Of course, they can ignore what they want.)
[21:45:35] <rayh> I guess I'm related to two of four or so.
[21:45:51] <lerman> To be fair, I haven't found them to be unreasonable.
[21:46:06] <lerman> What does related to two of four mean?
[21:46:08] <rayh> There you go.
[21:46:37] <rayh> mini and tkemc are in part my authorship
[21:46:42] <lerman> I stated that somewhat negatively. Actually, I've found them to be very reasonable.
[21:47:16] <lerman> Ah. I didn't know you were to blame ^H^H^H^H^H involved with mini. :-)
[21:47:46] <rayh> I wrote most all of mini and worked with FredP on tkemc.
[21:48:01] <lerman> I've never used mini. I did (actually do) use tkemc on my emc1 system -- a Bridgeport clone.
[21:48:41] <rayh> Mini was written specifically for Joe Martin at Sherline.
[21:48:43] <lerman> (I take that back -- I think I switched to Axis a while back). You can see how recently I've used that system.
[21:48:49] <rayh> In fact it was written on my laptop on his dining table.
[21:49:56] <lerman> So, where in the code to I find how the current line number is passed to Axis (or tkemc...)?
[21:50:16] <rayh> With the current version of the interpreter I look at the currently executing block of code as coming from a tree.
[21:50:26] <lerman> The cheapest fix at my end would be to pass the file path in the same place.
[21:50:44] <lerman> A tree?
[21:51:27] <rayh> Sure. (1) I loaded a program (file name)
[21:51:40] <rayh> (2) it started a subroutine
[21:51:57] <lerman> Ah, gotcha. The "trace" is a tree.
[21:51:58] <rayh> (3)that sub called a file
[21:52:26] <rayh> (4) that file started a sub...
[21:52:44] <lerman> Each file has as children, all of the files invoked from it. Of course, some of the files are the same.
[21:52:49] <rayh> IMO we need a full path to the mothership here.
[21:53:20] <rayh> With the effects on modal codes at each branch.
[21:53:42] <lerman> Well, that would be the current stack. Each requires a full path name (2K or 4K bytes -- I forget).
[21:53:58] <lerman> Why do you want the model codes?
[21:54:04] <rayh> Actually I'd like to see the effects of each branch on the whole status structure within the interpreter.
[21:54:35] <rayh> So I can know where I am when I abort, pause, or restart.
[21:54:39] <lerman> Well, I think you really want that for each block that was interpreted.
[21:54:51] <lerman> For restart...
[21:55:13] <rayh> Exactly. Even if that block is created by a 10th level subroutine reading a fifth file.
[21:55:13] <lerman> Right now, I don't think the interpreter even stores some of that stuff.
[21:55:54] <rayh> No it doesn't. That is why Tom could say that the interpreter does not know the concept of a program.
[21:56:10] <lerman> On my list of required features is complete introspection. A gcode program should be able to read the state of the machine.
[21:56:37] <lerman> Spindle speed, direction, on/off. Current tool info, etc.
[21:57:04] <rayh> at first blush I see that as task's task but interp and task are all twisted up.
[21:58:01] <rayh> And I know of no developer who really likes to write task stuff.
[21:58:04] <lerman> Well, the interp caused it (at some level), and if gcode is to access it, interp can store it for retrieval.
[21:58:46] <rayh> Certainly I like the idea of knowing causality.
[21:59:26] <rayh> In fact if I could know that in the programs that are being run.
[21:59:49] <lerman> That's what introspection is all about.
[22:00:14] <rayh> I'd write the program execution widgets in the tcl/tk guils to indent based on subroutine, and file calls.
[22:01:37] <lerman> It would be hard to show the full path in a single line, but since the directories are searched (in almost) in the same order, a file name identifies the file pretty well.
[22:01:57] <lerman> You could use a tool tip (rollover) to show the full path to the file if anyone cared.
[22:02:34] <rayh> Im my thinking about it, the interp would have to remember all that stuff for each block of code it read.
[22:02:53] <rayh> And would have to remember all that for as long as a program was running.
[22:03:17] <lerman> That's a lot of stuff. -- But big disks are cheap.
[22:03:29] <rayh> Yes it is a lot.
[22:03:50] <rayh> When Tom started, the interpreter had no knowledge of machine.
[22:04:01] <rayh> It was just a line by line interpreter.
[22:04:09] <lerman> That display you are discussing is a "trace" display. It doesn't show the lines of code. That is, an if that skips some lines wouldn't be shown.
[22:04:11] <rayh> I think it's time to change all that.
[22:04:45] <rayh> Exactly. It would show what is being executed.
[22:05:15] <lerman> But sometimes you want to see the lines that were skipped. That's a different type of display.
[22:05:17] <rayh> and the path back through to the program that called it.
[22:05:46] <lerman> Show the current line in the file that is being executed and the lines around it. Scroll forwards or backwards to see the entire file.
[22:06:07] <rayh> So I'll create a "expand" this executing code to show the path not taken.
[22:07:15] <lerman> I believe that Frost would call it "The Road Not Taken"
[22:07:32] <rayh> oh. yea. that to.
[22:08:04] <rayh> Now I have no clue how you are going to make the interpreter do all that.
[22:08:17] <lerman> ou just said, "So I'll create...". Does that means you are committing to this project? :-)
[22:08:35] <rayh> It would certainly ease the tasks of the gui folk.
[22:08:43] <rayh> Sure.
[22:10:12] <lerman> I need to look at where the interp stores the line number etc to get them to the gui.
[22:10:55] <rayh> emcsh.cc lists a command which is used to report which line is currently executing.
[22:12:01] <lerman> Ah. That's the hint I need to get started.
[22:12:12] <lerman> logger: bookmark
[22:12:24] <lerman> That didn't work. How am I supposed to do that?
[22:12:59] <lerman> logger_dev bookmark
[22:14:10] <rayh> logger_dev bookmark;
[22:14:16] <rayh> I don't know that either.
[22:14:57] <lerman> I just asked on #emc
[22:15:09] <rayh> Once I have emcsh running I can issue the command emc_program_line and get what NML knows of the line currently being executed.
[22:16:16] <lerman> Good. So, all I have to do is read the code and find out how emcsh gets the info and then add it to NML.
[22:17:59] <rayh> You'll get some mixed reactions when you start mucking around in NML.
[22:18:04] <lerman> I've got to leave in a few minutes.
[22:18:21] <lerman> Well, for now, I'll just add a file name.
[22:18:29] <rayh> Some will say "throw it all out" and use jjj or zzz or uuu or whatever.
[22:18:50] <rayh> Nice talking with you. Thanks for listening to my rant.
[22:18:54] <lerman> That's a good answer for anyone willing to do the work.
[22:19:17] <lerman> Gee, Ray, I thought it was MY rant. :-) Nice talking to you.
[22:19:27] <rayh> and willing to prove that it works better than what we have.
[22:19:44] <lerman> Start by listing the requirements (and agreeing to them).
[22:20:06] <rayh> yep. We have some things in common here.
[22:20:42] <lerman> (Relative AGE?)
[22:20:57] <lerman> (Wisdom?)
[22:21:09] <rayh> Yea yea yea.
[22:21:43] <rayh> catch you later. Dinner calls.
[22:21:58] <lerman> Me, too.
[23:18:13] <noel> noel is now known as Roguish