Back
[14:51:10] <SWP_Away> SWP_Away is now known as SWPadnos
[15:11:59] <SWPadnos> SWPadnos is now known as SWP_Away
[16:10:32] <SWP_Away> SWP_Away is now known as SWPadnos
[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:24:51] <rayh> rayh is now known as rayh_away
[19:27:30] <jmkasunich> jmkasunich is now known as jmk_away
[20:23:59] <SWPadnos> SWPadnos is now known as SWP_Away
[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: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