01:26:48 <alex_joni_> alex_joni_ has joined #emc-devel
01:40:46 <alex_joni_> alex_joni_ has quit
03:38:44 <ChanServ> ChanServ has quit
03:49:14 <ChanServ> ChanServ has joined #emc-devel
14:51:10 <SWP_Away> SWP_Away is now known as SWPadnos
15:09:31 <rayh> rayh has joined #emc-devel
15:11:59 <SWPadnos> SWPadnos is now known as SWP_Away
16:10:32 <SWP_Away> SWP_Away is now known as SWPadnos
16:26:37 <jmkasunich> jmkasunich has joined #emc-devel
16:55:55 <SWPadnos> jmkasunich, I was pondering how to insure that a HALpin or signal is still valid, in a userspace app
16:56:31 <jmkasunich> valid as in not deleted?
16:56:35 <SWPadnos> yep
16:57:55 <SWPadnos> about the best I could come up with was to keep a list of pointers to the things I want to watch, and run through the HAL pins (or sigs) to be sure my pointers are still in the list
16:58:21 <SWPadnos> then verify some other stuff about them, but I'm not sure how much better than a series of string comparisons that would be
16:59:03 <jmkasunich> sorry, I'm in the middle of another conversation, so if I sound distracted, I am
16:59:11 <SWPadnos> the worse issue than a pin not being valid (easily checked with pin->owner == 0), is if it's been reused by an unrelated component
16:59:20 <SWPadnos> ok - no problem
17:09:38 <jmkasunich> swp: what exactly are you trying to do?  write a user program that accesses pins it didn't create?
17:09:52 <SWPadnos> yes
17:10:04 <SWPadnos> basically a faster method for halconfig to get watch data
17:10:21 <jmkasunich> faster than asking halcmd?
17:10:25 <SWPadnos> yes
17:10:47 <SWPadnos> halcmd does a lot of string work, and can only accept substrings at the beginning of the names
17:11:50 <SWPadnos> obviously, using non-printf and maintaining a pointer would be faster, but it's not as simple as that
17:11:53 <jmkasunich> so you want to read the values of multiple items (pins, sigs)
17:12:16 <SWPadnos> yes - the commands would be "add/del <pinname,signame>"
17:12:25 <SWPadnos> then "refresh (or just CR)
17:12:33 <jmkasunich> add/del from a list?
17:12:35 <SWPadnos> to get the values of everything in the list
17:12:39 <SWPadnos> yep
17:12:46 <SWPadnos> meant for interactive or script use, mostly
17:13:11 <jmkasunich> ok, first the knee jerk answer:  pointers to hal data are only good while you hold the hal mutex
17:13:14 <SWPadnos> but possible to use as a filter as well, like cat <file with list of things to look at> | halwatch
17:13:19 <SWPadnos> heh - yep
17:14:34 <jmkasunich> I would maintain a list of "name/value" structs in your prog, sorted alphabetically
17:14:36 <SWPadnos> the other speedup is in not parsing the command line every time, so I think it would still be a bit faster - I'm just not sure if I can optimize things enough for it to be worthwhile
17:14:39 <jmkasunich> your add/del would work on that list
17:15:01 <jmkasunich> then update would get the mutex, and run down the hal pin list, looking for a match to entries on your list
17:15:32 <jmkasunich> since both lists are sorted, it is order (n), rather than order (n*m)
17:15:42 <SWPadnos> yep - merge sort, essentially
17:15:44 <jmkasunich> n = number of hal pins, m = number you want to look at
17:15:59 <SWPadnos> order (min(n,m))
17:16:20 <jmkasunich> no, n
17:16:52 <SWPadnos> right - order (max(last item in m and n))
17:16:55 <SWPadnos> heh
17:17:01 <jmkasunich> if the hal list has 100, and you want to watch "alpha" and "zed", you will compare alpha to the first couple, then zed to all the rest
17:17:07 <SWPadnos> yep
17:17:29 <SWPadnos> but anyway ;)
17:17:33 <jmkasunich> anyway, as long as you avoid n*m or n^2 or m^2 you should be good
17:17:36 <rayh> What I'm hoping for is a random listing of variables to watch.
17:17:51 <SWPadnos> the output order wouldn't be the same as the HAL search order
17:17:58 <SWPadnos> (doubly-linked list)
17:18:10 <rayh> This does work now but not real well.
17:18:42 <SWPadnos> the main problem you have is that you need to do a "show pin <all>", then have tcl sort it out
17:18:52 <SWPadnos> or you need to issue individual requests to halcmd
17:18:53 <jmkasunich> yeah, that sucks
17:19:10 <jmkasunich> both of those approaches have massive overhead
17:19:25 <jmkasunich> a C loop running the HAL linked lists is much faster
17:19:28 <SWPadnos> yep
17:19:29 <rayh> What I'd like to do is send a list of pins, params, and sigs to halwatch
17:19:43 <SWPadnos> so - I also want to avoid string comparisons as much as possible
17:19:56 <jmkasunich> strcmp isn't too painfull
17:20:02 <rayh> and every "dt" it returns a list of their values.
17:20:27 <SWPadnos> you'll have to ask for that (unless I add a "period" command)
17:20:44 <SWPadnos> at first, you may need to send a <CR> to get a refresh
17:21:07 <rayh> That should work.
17:21:29 <rayh> The channel will be open and the list already sent.
17:21:33 <SWPadnos> I think it's best to leave the pipe in the control of the TCL program
17:21:35 <SWPadnos> right
17:21:44 <rayh> okay
17:21:58 <SWPadnos> ie, request/response, not async
17:22:19 <jmkasunich> SWP: so the list you get from ray may be unsorted, and you need to send the results back in that order
17:22:25 <rayh> then a simple loop with after xxx puts $fid "\n"
17:22:25 <SWPadnos> yes
17:22:50 <SWPadnos> rayh, yep - that should do it, or possibly puts "refresh"
17:22:59 <SWPadnos> no \n, puts already appends that ;)
17:23:08 <rayh> right.
17:23:11 <jmkasunich> heh, in HAL v2.0 (or whatever the "refactor" is gonna be called, I intend to change the lists into AVL trees
17:23:30 <SWPadnos> I'd add in a couple of things to the structs as well
17:23:43 <jmkasunich> so then it would be order (m*log(m))
17:23:46 <jmkasunich> oops
17:23:54 <jmkasunich> (m*log(n))
17:24:02 <SWPadnos> first, a unique ID - just start with a number, and increment any time anything is added to the lists
17:24:10 <SWPadnos> second, don't reuse component IDs
17:24:40 <SWPadnos> that would be a very easy way of testing what I want to test - if ptr->parent != saved_parent, it's invalid
17:26:19 <jmkasunich> I'm very reluctant to bypass the mutex mechanism
17:26:30 <SWPadnos> I don't want to bypass it
17:26:34 <jmkasunich> I know you are read only, so the risk is lower
17:26:43 <SWPadnos> this program gets called from userspace, every X seconds
17:26:58 <SWPadnos> between refreshes, some components may be unloaded, and others loaded
17:27:09 <jmkasunich> suppose you read ptr->parent, and it's ok, then before you read ptr->value, you get suspended by a halcmd instance that removes the component
17:27:21 <SWPadnos> the pins will be reused, so they may be valid, but not what we want to see
17:27:22 <jmkasunich> granted, it is extremely unlikely, but...
17:27:37 <SWPadnos> oh - I'd take the mutex when scanning, but I'd release it between scans
17:27:48 <SWPadnos> and in that time, the HAL configuration can change under me
17:28:19 <jmkasunich> so really all you are doing is looking for an int compare instead of a string compare
17:28:22 <SWPadnos> but I don't want to find everything via string compares every time, for speed purposes
17:28:24 <SWPadnos> yes
17:28:43 <jmkasunich> hem, haw, mmmm
17:28:59 <SWPadnos> I think that a parent ID compare, then possibly a comparison of the first 4 bytes of the anme (as a U32) might work
17:29:03 <SWPadnos> name
17:29:21 <jmkasunich> eww
17:29:24 <SWPadnos> hmm - nope
17:29:43 <SWPadnos> it would have to be the last bytes of the string
17:29:45 <jmkasunich> I'd rather modify HAL to add a unique 32 bit identifier for each object
17:29:51 <SWPadnos> heh - that would work ;)
17:30:02 <SWPadnos> what about not reusing component IDs?
17:30:11 <jmkasunich> thats a hack
17:30:42 <SWPadnos> which - GUIDs or monotonic comp_ids?
17:31:00 <jmkasunich> basically, HAL uses names as unique identifiers... like filenames.  I'd favor adding a unique integer for every object (pin, param, comp, etc), kinda like a file handle
17:31:14 <SWPadnos> ok - that works for me
17:31:18 <jmkasunich> handles are faster than names
17:31:31 <SWPadnos> I had considered adding a hash value as well
17:31:43 <SWPadnos> (instead of unique IDs)
17:32:01 <SWPadnos> because I do want to "reconnect" to a pin if it goes missing, but then comes back
17:32:12 <SWPadnos> just return "N/A" while it's gone
17:33:30 <jmkasunich> eww
17:33:37 <SWPadnos> no -"yum"
17:33:47 <jmkasunich> nice feature, eww implementation
17:33:56 <SWPadnos> hashes?
17:34:00 <jmkasunich> yes
17:34:14 <jmkasunich> you need to be prepared to handle hash collisions
17:34:24 <SWPadnos> no - those are actually better than GUIDs, since they actually have something to do with the unique identifier
17:34:26 <SWPadnos> yes
17:34:40 <SWPadnos> hash once, compare ints many times, then compare strings once or twice
17:34:53 <SWPadnos> should be faster than compare strings many times
17:35:10 <jmkasunich> trading complexity for speed - IMO that is the wrong tradeoff to make
17:35:27 <jmkasunich> have you actually timed a "fine_pin_by_name" call?
17:35:33 <SWPadnos> it depends ;)
17:36:00 <SWPadnos> no - I haven't run the update function in a tight loop
17:36:24 <SWPadnos> it takes 5 seconds to fill out the tree on my emc machine
17:36:35 <SWPadnos> that's with a univpwm setup, no CL
17:36:39 <jmkasunich> as long as you avoid n^2 or n*m, I think the other overheads (piping to/from TCL, and TCL itself) are gonna be so much longer that optimizing the strcmps is a waste
17:36:51 <SWPadnos> could well be
17:40:44 <jmkasunich> is rdtsc() callable from user space?
17:41:12 <SWPadnos> not sure - it probably is, but trapped if necessary
17:41:30 <jmkasunich> if so, try start=rdtsc(); find_pin_by_name(); end=rdtsc(); delta=end-start;
17:41:41 <jmkasunich> long long int start, end; ;-)
17:41:53 <SWPadnos> heh
17:42:06 <jmkasunich> traps aren't needed, the actual instruction isn't privliged
17:42:13 <SWPadnos> ah - OK
17:42:26 <jmkasunich> the question is whether the funct (actually an inline I think) is available when compiling user space progs
17:43:09 <jmkasunich> I bet the call to find is a few to a few tens of microseconds
17:44:03 <SWPadnos> I'll try it, using Axx and Zxxx names
17:44:12 <SWPadnos> luckily, we have both
17:44:16 <jmkasunich> heh
17:44:45 <SWPadnos> looks like ppmc.0.stepgen.03.velocity will be the last pin in the list
17:44:48 <jmkasunich> the naive implementation is
17:45:12 <jmkasunich> for ( entries in rays list ) { find_pin_by_name }
17:45:23 <jmkasunich> that will be m*n tho
17:45:41 <SWPadnos> gives a good average though, since it finds pins at all pisitions in the list
17:45:47 <SWPadnos> positions, too
17:45:51 <jmkasunich> yeah
17:46:00 <jmkasunich> and you might be surprized how fast it actually is
17:46:10 <jmkasunich> after the first find, much of the list will be in cache
17:46:21 <SWPadnos> true
17:46:30 <SWPadnos> actually, not really
17:46:44 <SWPadnos> if I start with Zxxx, that would be true
17:46:57 <SWPadnos> thatwould prime the cache for all the other searches
17:47:21 <alex_joni> I wonder if the following thing I experienced is a bug or not
17:47:31 <alex_joni> I've set up my machine only using X&Y
17:47:52 <jmkasunich> much of the list would be in cache, for some value of "much"
17:48:09 <jmkasunich> much = approx 1/2 if rays list is randomly ordered
17:48:22 <SWPadnos> yes
17:50:11 <jmkasunich> anyway, keep in mind that by writing halwatch, you are using internal hal structs that I will change when the rewrite is done
17:50:20 <alex_joni> and I ran a program that has some Z commands in there
17:50:21 <SWPadnos> yep - that's known
17:50:26 <alex_joni> and it basicly hang
17:50:47 <SWPadnos> that sounds bug-ish, if it's repeatable
17:50:51 <alex_joni> because the interp was commanding a Z movement, but no axis moved to accomplish that move
17:51:01 <jmkasunich> alex: sounds like a bug to me - it should print an error message and let you exit gracefully
17:51:14 <alex_joni> I wonder if interp shouldn't generate an error that such an axis doesn't exist
17:51:20 <alex_joni> right
17:51:25 <jmkasunich> the interp shouldn't command a movement if the corresponding axis doesn't exist
17:51:54 <alex_joni> ok, I'll submit it to the buglist, and assign to it
17:54:10 <alex_joni> as soon as SF is working again :(
17:54:21 <jmkasunich> yeah, that sucks
18:09:40 <SWPadnos> heh - you can't tell how long it takes in userspace, because you get interrupted all the time ;)
18:19:29 <SWPadnos> ok - we can do that ;)
18:19:33 <alex_joni> right
18:19:47 <alex_joni> so.. people who try the run-in-place should bother with CVS & all
18:20:04 <SWPadnos> there's been a lot of stuff done lately to make it easier on users, this is just one more step in that direction
18:20:09 <alex_joni> I think they can follow a message telling them 'now issue scripts/emc to try emc2'
18:20:39 <SWPadnos> sure, but how many people actually reaf the (100 pages or so of) make output?
18:21:02 <jmkasunich> not the 100 pages, just the big honking boxed note at the very end
18:21:07 <SWPadnos> heh
18:21:17 <SWPadnos> the one with the blinking asterisks all around it?
18:21:18 <alex_joni> btw, I think we should have -s by default
18:21:24 <alex_joni> for make
18:21:44 <alex_joni> as in configure --with-make-silent
18:21:52 <SWPadnos> is that the version that just prints "CC filename"  ...
18:22:23 <alex_joni> yup
18:22:37 <alex_joni> Compiling 'foo.c' as realtime C
18:22:39 <alex_joni> etc.
18:23:28 <jmkasunich> it worked a lot nicer before kbuild, it doesn't print "compiling foo.c as realtime" anymore, only prints the user space stuff
18:28:13 <alex_joni> well.. that's it ;)
18:28:22 <alex_joni> but -s is still lots nicer than without
19:23:09 <alex_joni_> alex_joni_ has joined #emc-devel
19:24:51 <rayh> rayh is now known as rayh_away
19:27:30 <jmkasunich> jmkasunich is now known as jmk_away
20:14:28 <alex_joni_> alex_joni_ has quit
20:23:59 <SWPadnos> SWPadnos is now known as SWP_Away
21:13:52 <staggerlytom> staggerlytom has joined #emc-devel
21:14:00 <staggerlytom> afternoon all
21:21:43 <rayh_away> Hey
21:24:29 <rayh_away> rayh_away is now known as rayh
21:57:18 <staggerlytom> ello ray
22:00:02 <rayh> Hi tom
22:00:11 <rayh> I was kidding about the thai-en
22:00:59 <rayh> The next mazak I do will be 2 mesa cards
22:01:26 <rayh> 1 for motion and 48 io including things like handwheel
22:01:50 <rayh> feed and spindle speed override encoders anc such
22:01:59 <rayh> the other for 72 io.
22:02:13 <rayh> the neet thing about it is that a single spare handles both.
22:02:19 <staggerlytom> wanna try one of these? on loan?
22:02:23 <staggerlytom> also found a teeny hdwr plc controller chip, korean, www.comfiletech.com
22:04:59 <rayh> looking
22:05:55 <rayh> dang they need an html writter.
22:06:40 <staggerlytom> I'm almost done with pcb layout fro scott ananians' edm power supply http://cscott.net/
22:07:25 <staggerlytom> the orient has no paricle, thats why it sounds like tonto to use & extar junk to them ( no the a an bits )
22:08:00 <staggerlytom> particle ( i need a seeing eye keyboard )
22:10:23 <rayh> Really.  I've got a slow link
22:10:39 <rayh> darn clicked on starter kit and got a blank page.
22:14:28 <staggerlytom> ray: it's not blank.. it not what you think, use FireFox   http://www.comfiletech.com/index.asp?PageAction=VIEWCATS&Category=29
22:14:39 <staggerlytom> ray: it dont work in konq
22:16:14 <logger_devel> logger_devel has joined #emc-devel
22:16:14 <zelazny.freenode.net> topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !"
22:16:14 <zelazny.freenode.net> Users on #emc-devel: logger_devel staggerlytom jmk_away rayh @ChanServ SWP_Away LawrenceG anonimasu alex_joni cradek jtr_ 
22:17:01 <staggerlytom> ray: kde & permissions... i worked for hours with PCB layout, saving every few minutes as usual
22:17:50 <staggerlytom> ray: but kde's kpginstaller setup the dirs w/o user perms, so when i workde on new library components..
22:18:25 <staggerlytom> ray: PCB didnt complain, just dumped my new elements into the bitbucket and continued
22:19:37 <staggerlytom> ray: hours later I closed, ready to use my new shiny devices, and they were'nt there when i opened PCB for the real layout
22:19:58 <staggerlytom> kpgmanager (mangler)
22:43:38 <rayh> phone sorry.
22:43:44 <rayh> so you lost it all?
22:44:08 <rayh> This PCB is a program
22:52:39 <staggerlytom> yep, the writes to the folders who were rwxr--r-- didnt cause any err. i forced all /usr folder after that, this root only stuff is a problem
22:52:58 <staggerlytom> and the typical user doesnt have a smart action to handle it
22:53:22 <staggerlytom> the typical user wants to get something done and works around the protections
22:54:11 <staggerlytom> the smart user studies forvere and doesnt get anything done today. it's obvious the typical user is wrong
22:54:22 <staggerlytom> but he's accomplished something
22:57:30 <rayh> I know that frustration.
22:57:54 <rayh> The easy approach was to make all of the icon commands sudo
22:59:48 <staggerlytom> well , gung zi fa cai for now, happy new year & bye bye
22:59:52 <staggerlytom> staggerlytom has left #emc-devel