Back
[01:01:50] <SWPadnos> SWPadnos is now known as SWP_Away
[03:21:25] <SWP_Away> SWP_Away is now known as SWPadnos
[06:07:22] <SWPadnos> SWPadnos is now known as SWP_Away
[16:24:18] <SWP_Away> SWP_Away is now known as SWPadnos
[17:08:47] <rayh> Got a few minutes for a quandary?
[17:09:02] <rayh> Tcl open question.
[17:09:36] <SWPadnos> I'm all ears
[17:09:56] <SWPadnos> not that that will be helpful
[17:10:06] <rayh> We send a command to halcmd say "list pin"
[17:10:44] <rayh> and the answer is collected with gets xxx varname
[17:11:12] <rayh> so the command and reply are not connected like they are with exec
[17:12:07] <SWPadnos> the trick would be to flush the read channel before issuing the command
[17:12:19] <rayh> with exec I could write "set tmp [exec /bin/halcmd list pin]
[17:12:52] <rayh> and tmp would hold the reply.
[17:12:58] <SWPadnos> you can make a tcl proc that takes a command, and then flushes, writes the command, and reads the response
[17:13:08] <SWPadnos> that would operate the same as the exec
[17:13:43] <rayh> but the read is triggered many times for lines
[17:14:08] <rayh> so the read must be repeated
[17:14:10] <SWPadnos> also, this might be a place to use the eofchar {%} - then you can use read instead of many gets
[17:14:37] <rayh> Okay. let me try that.
[17:14:41] <SWPadnos> no - I'm saying that the tcl "command" proc would do the gets loop until it finds the % line
[17:14:52] <SWPadnos> and return the concatenated result
[17:15:06] <rayh> Otherwise my gets becomes a very complicated thing with a switch.
[17:15:39] <rayh> the problem is that it doesn't know where to return
[17:16:33] <rayh> I suppose I could return everything to the same global variable
[17:16:50] <rayh> and let the various receivers sort out what to do with what
[17:16:51] <SWPadnos> it shouldn't be too complicated. something like {set tmp "" while {done = 0} { gets $fil $thisline if {thisline == "%" done = 1} else {tmp = $tmp + $thisline}}}} (insert curly braces as appropriate)
[17:16:54] <rayh> 's there.
[17:17:28] <SWPadnos> then you return $tmp
[17:17:40] <rayh> But I send stuff to puts $fid xxx from a dozen places.
[17:18:02] <rayh> One sets up the nodes, one the leaves.
[17:18:16] <rayh> One displays the reply, like show
[17:18:20] <SWPadnos> those would change to the exec-like format
[17:18:58] <SWPadnos> ie, set leafvalue {command "show pin $name"}
[17:19:51] <rayh> but the command to show the pin is in a different proc than the reply.
[17:20:09] <rayh> I need a fancy router to handle where the return has to go.
[17:20:18] <rayh> Unless I brain locked.
[17:20:26] <SWPadnos> are these commands sent simultaneously?
[17:20:38] <rayh> sequentially
[17:21:01] <SWPadnos> ok - that should work
[17:21:10] <SWPadnos> you could always do pseudo-locking anyway
[17:21:50] <rayh> But I still don't understand how you get the return from a gets or read to go where you sent the command from.
[17:21:52] <SWPadnos> so, you have a hundred places where you do something like puts $fid "blahblah" / while {gets yadda yadda}
[17:22:01] <SWPadnos> right?
[17:22:02] <rayh> Yes.
[17:22:33] <rayh> No beause the gets command is controlled by fileevent not by the sending process.
[17:22:45] <SWPadnos> those would change to "set result sendcommand $fid "blahblah""
[17:23:10] <SWPadnos> yes - but the file will only be readable if there's an error (an unexpected input), or you send a command
[17:23:29] <SWPadnos> you can also get rid of the fileevent thing - that may not be useful here
[17:23:49] <SWPadnos> I think we were both trying it because it wasn't working reliably
[17:23:58] <SWPadnos> (getting anything back from halcmd)
[17:24:06] <rayh> Yes.
[17:24:21] <SWPadnos> the "sencommand" proc can just do a gets loop before returning
[17:24:38] <SWPadnos> or, the fileevent proc can set a flag, which the sendcommand proc waits for
[17:24:47] <rayh> I don't think a script ever recovers from puts $fid xxx if fileevent isn't running in the background.
[17:25:11] <SWPadnos> I haven't tried it with the inline gets - maybe I should do that today
[17:25:23] <rayh> but let me try.
[17:25:32] <SWPadnos> but I think I'll be in the garage milling motor mounts - it's over 50 degrees right now
[17:25:51] <rayh> Really. I don't think that's right.
[17:26:07] <rayh> the weather that is.
[17:26:20] <SWPadnos> indeed - it's supposed to get "seasonal" later today ;)
[17:26:22] <rayh> sunshine here but about 20
[17:26:40] <SWPadnos> I want to get something done before my fingers would freeze off
[17:26:42] <rayh> better make "mounts" while the sun shines.
[17:26:46] <SWPadnos> heh - yep
[17:27:05] <rayh> Thanks for the clarification.
[17:27:26] <SWPadnos> so - I think you have two easy choices. one, make a global "result" var and a global "resultReady" var, and make the fileevent proc set those
[17:27:36] <SWPadnos> two, make the sendcommand proc do the gets loop
[17:27:39] <SWPadnos> sure - no problem
[17:27:59] <rayh> Will try both probably.
[17:28:07] <SWPadnos> heh
[17:28:20] <SWPadnos> ok. I should be back later, when it starts to get cold :)
[17:28:56] <SWPadnos> SWPadnos is now known as SWP_Away
[21:00:19] <alex_joni> hi pete
[21:03:23] <petev> hi
[21:06:45] <petev> alex_joni, what is the algorithm for the new TP code I see you started?
[21:06:54] <alex_joni> cradek did that
[21:07:06] <alex_joni> and the code is very explanatory
[21:07:16] <alex_joni> you should be able to get it by only reading the code
[21:07:20] <alex_joni> if not.. ask ;)
[21:07:23] <petev> I saw a tc.c file that looked like a work in progress
[21:07:34] <alex_joni> no, it's actually working
[21:07:41] <alex_joni> but it's a new clean exact stop TP
[21:07:46] <petev> this is the one cradek did?
[21:07:47] <alex_joni> aka NO BLENDING
[21:07:50] <alex_joni> yes
[21:08:02] <alex_joni> it's in the simple_tp branch of emc2
[21:08:13] <alex_joni> it's very basic and simple, but it seems to be working
[21:08:17] <petev> ok, becuase there are a lot of comments in there about blending, but I didn't see any, which is why I thought it wasn't done yet
[21:08:33] <petev> I checked out the head and got both tc.c and tc.h
[21:08:41] <alex_joni> oh.. that's the old code
[21:08:50] <petev> which old code?
[21:08:57] <alex_joni> tp.c, tp.h and tc.c, tc.h from HEAD is the old TP code
[21:09:04] <alex_joni> all 4 files
[21:09:16] <petev> oh, I hadn't noticed the tc files before
[21:09:20] <alex_joni> the new code by cradek is in the simple_tp branch
[21:09:25] <petev> right
[21:09:33] <alex_joni> well, they are there since the beginning ;)
[21:09:52] <petev> yeah, I haven't looked at the tp code much so no surprise there
[21:10:45] <alex_joni> ;-)
[21:20:33] <petev> alex, have you used the debian make-kpkg script?
[21:20:55] <alex_joni> not yet, but I think chris has
[21:21:06] <alex_joni> I plan to some time in the near future
[21:21:12] <petev> it works very well and builds a nice deb for the kernel
[21:21:28] <petev> maybe that with an emc2 deb is all that would be needed
[21:21:44] <petev> then people could install the linux of choice and then a few packages
[21:21:47] <alex_joni> also a rtai deb is needed
[21:21:49] <alex_joni> right
[21:21:54] <alex_joni> that's also my thinking