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
06:15:37 <LawrenceG> LawrenceG has quit
06:16:31 <LawrenceG> LawrenceG has joined #emc-devel
16:15:25 <rayh> rayh has joined #emc-devel
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
17:30:00 <rayh> rayh has quit
20:58:33 <petev> petev has joined #emc-devel
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
22:16:18 <logger_devel> logger_devel has joined #emc-devel
22:16:18 <niven.freenode.net> topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !"
22:16:18 <niven.freenode.net> Users on #emc-devel: logger_devel petev LawrenceG SWP_Away cradek anonimasu jtr_ alex_joni @ChanServ 
22:35:32 <petev> petev has quit