Back
[00:04:15] <seb_kuzminsky> cradek: you're using SVST8_4IM2.BIT, right? Can you see if SVST8_4.BIT displays the same /enable problem?
[00:04:24] <seb_kuzminsky> cradek: you're using SVST8_4IM2.BIT, right? Can you see if SVST8_4.BIT displays the same //enable problem?
[00:04:37] <seb_kuzminsky> cradek: you're using SVST8_4IM2.BIT, right? Can you see if SVST8_4.BIT displays the same enable problem?
[00:04:48] <seb_kuzminsky> oops
[00:04:52] <seb_kuzminsky> or just check it once
[00:04:59] <seb_kuzminsky> i'll be back later tonight
[00:11:18] <BigJohnT> SWEET! I got chapter auto numbering to work in my xsl :)
[00:13:55] <BigJohnT> and section numbering an subsection numbering... I love it when a plan comes together :)
[00:20:13] <BigJohnT> I think I'll quit while I'm ahead
[00:56:48] <cradek> what are you working on BigJohnT ?
[00:57:25] <BigJohnT> not much at the moment
[00:57:58] <BigJohnT> oh do you mean the yea thing about chapter numbers
[00:58:07] <cradek> yes
[00:58:35] <BigJohnT> asciidoc to docbook xml then to html and pdf
[00:59:04] <BigJohnT> I'm playing with the xsl to get the desired output
[00:59:25] <cradek> is this related to your docs work?
[00:59:53] <BigJohnT> yes, I've been looking into other ways to do the docs
[01:00:16] <BigJohnT> from the message on the dev mailing list
[01:00:36] <BigJohnT> asciidoc is text based markup like wiki
[01:01:05] <BigJohnT> asciidoc will output a docbook book
[01:01:49] <cradek> neat
[01:01:54] <BigJohnT> with the correct xsl (i forget the converstion pgm I'm upstairs) you get html
[01:02:09] <BigJohnT> and with hmm dblatex you get the pdfs
[01:02:46] <BigJohnT> it's starting to come together and if you write your own stylesheet you have full control over the output
[01:03:50] <BigJohnT> once the xsl stylesheets are done the rest is easy
[01:04:15] <BigJohnT> I even made a Makefile to do all the work :) with some help
[01:05:53] <BigJohnT> this makes all the document editing with any text editor...
[01:05:59] <cradek> I think it would be neat to use asciidoc - but some don't agree I think
[01:06:04] <cradek> oop bbl
[01:06:19] <BigJohnT> ok
[01:06:53] <BigJohnT> * BigJohnT wonders why asciidoc is not liked
[01:33:05] <jmkasunich2_> * jmkasunich2_ likes asciidoc
[01:33:23] <jmkasunich> * jmkasunich too!
[01:33:31] <SWPadnos> cheater :)
[01:33:45] <BigJohnT> I'm liking it now that is is getting easy
[01:33:47] <jmkasunich2_> cradek: good to hear the lathe is working on hm2
[02:06:18] <cradek> jmkasunich2_: yep, very nice
[02:06:36] <cradek> jmkasunich2_: a couple things just worked that took a rebuild with the old driver: index mask and watchdog
[02:07:07] <cradek> the velocity encoder output will be nice for spindle speed - I will try that next
[02:07:54] <SWPadnos> I didn't notice timestamp stuff in the encoder block when I was perusing the VHDL
[02:08:26] <SWPadnos> doesn't mean it's not there, but I didn't see it (though I was looking for a split of a single 32-bit register - it may be that there are separate count and timestamp registers)
[02:10:41] <cradek> oh maybe that's not there yet - I thought I heard it was
[02:11:52] <cradek> ok I see there is not a velocity pin - darn.
[02:13:24] <SWPadnos> lemme check the VHDL again - it may be a driver issue
[02:14:37] <SWPadnos> well, there's a timestamp input port, presumably fed from a single counter
[02:15:06] <SWPadnos> it looks like the count is 16 bits and the timestamp is too
[02:15:23] <cradek> I wonder why I wasted a 7i37 output for amp enables. I am out of outputs and that could come from the servo card.
[02:15:35] <SWPadnos> polarity? :)
[02:15:47] <cradek> oh, isolation I bet
[02:16:04] <cradek> iirc, the amps say they want a contact closure
[02:16:11] <SWPadnos> ah ok - the timestamp is the top 16 bits and the count is the bottom, so the data is already there for the driver to use
[02:16:21] <cradek> oh excellent
[02:16:32] <cradek> I would really like to have that
[02:16:36] <SWPadnos> yep. easier to find when I'm actually looking for that :)
[02:16:49] <cradek> I'm using a ddt in a .1 sec thread now - my spindle encoder is coarse
[02:17:10] <cradek> so it craps out any period when there's an index reset
[02:17:18] <SWPadnos> I'm not sure what counter the timestamp is fed with, it could be the same as the PWM clock
[02:17:22] <SWPadnos> yep
[02:17:49] <SWPadnos> I guess that would give a max of ~16 ms per read
[02:17:56] <cradek> I wonder what it would take to rename a hal pin
[02:18:06] <SWPadnos> change a string??
[02:18:11] <cradek> that could give you 'personalities' without having to do it in the driver
[02:18:48] <cradek> hm2_.....gpio.P3.071 => io-board.0.screw-3
[02:18:58] <SWPadnos> heh
[02:19:06] <cradek> I'm actually serious
[02:19:11] <SWPadnos> I believe you
[02:19:30] <SWPadnos> one way to do it would be to have the format strings available as insmod parameters
[02:19:34] <cradek> fully-generic names are just awful to keep track of
[02:19:46] <cradek> no, you can't change numberings then
[02:19:52] <SWPadnos> true
[02:20:18] <cradek> halcmd rename pin oldname newname
[02:20:49] <SWPadnos> actually, there's no reason why you couldn't write a userspace utility to change HAL pin names
[02:20:52] <cradek> halcmd source mesa-olddriver-compat.hal
[02:21:01] <cradek> oh?
[02:21:25] <SWPadnos> the name is used for lookup (and printing) only - it has nothing to do with anything else
[02:21:57] <SWPadnos> if you changed the name of something in the HAL data, the change would show up the next time you did a show <something>
[02:22:13] <SWPadnos> AFAIK
[02:22:13] <cradek> huh
[02:22:28] <SWPadnos> the links are jus tpointers, and the names are used to find where to link
[02:22:41] <SWPadnos> once the pointers are set (for signals ...), the names are irrelevant
[02:22:47] <SWPadnos> (to HAL and the RT system)
[02:23:16] <SWPadnos> still important if you want to connect other things, but still :)
[02:24:40] <cradek> oh, for a brief moment of insanity, I thought it would be simple to throw that in halcmd and see if it works
[02:24:48] <jmkasunich> SWPadnos is right, to an extent
[02:25:12] <cradek> aside from whether it's possible, is it a good idea?
[02:25:21] <jmkasunich> the metadata is stored in linked lists, in sorted order, so you'd probably want to relink when you rename
[02:25:41] <cradek> that's just remove and reinsert right?
[02:25:47] <cradek> ("insertion sort")
[02:25:52] <jmkasunich> yeah
[02:26:01] <jmkasunich> not using the existing remove code tho, that de-allocates stuff
[02:26:41] <cradek> aside from whether it's possible, is it a good idea?
[02:26:45] <jmkasunich> you want: start from front of list, find item, unlink the struct, change the name string, start from front again, find insertion point, insert
[02:27:03] <jmkasunich> I don't think its a bad idea
[02:27:21] <jmkasunich> when you first mentioned it, something like alias popped into my head
[02:27:41] <cradek> true you could add to the namespace instead of changing it
[02:27:49] <jmkasunich> but that would just make the already long lists longer
[02:27:53] <cradek> right
[02:28:23] <jmkasunich> rename pin/param/signal actually might be a nice extension
[02:28:41] <jmkasunich> signal isn't relevant here, but symmetry makes me happy
[02:28:44] <SWPadnos> does any RT code use the names?
[02:28:49] <jmkasunich> nope
[02:28:53] <SWPadnos> ok, that's what I thought
[02:29:06] <SWPadnos> and I had some evil thoughts in that direction too :)
[02:29:10] <SWPadnos> (HAL2 thoughts)
[02:29:13] <cradek> is it the most straightforward way to get what I keep calling 'personalities'?
[02:29:15] <jmkasunich> the more I think about it, the more I like it
[02:29:35] <jmkasunich> source hostmot2-7i37-on-P4.hal
[02:29:36] <SWPadnos> so the names don't even have to be in shared memory, except that the names are created by RT code
[02:29:48] <cradek> jmkasunich2_: exactly
[02:29:56] <jmkasunich> well, many processes need to access the names and other metadata
[02:30:01] <SWPadnos> err - the pins / params are created by RT code, I meant to say
[02:30:10] <jmkasunich> any halcmd instance, halscope, halmeter
[02:30:22] <SWPadnos> ok, so shared but not necessarily between kernel and userspace
[02:30:39] <SWPadnos> then again, you don't want that to swap out, so no need to change how the memory is allocated :)
[02:30:40] <jmkasunich> but it is true that the metadata doesn't need to be in the same space as the pin/param/signal data
[02:31:03] <jmkasunich> yeah, I don't see any reason to go from the relatively simple "add rename" to "restructure tons of stuff"
[02:31:14] <cradek> ha
[02:31:39] <jmkasunich> does halcmd have a "source" command?
[02:31:50] <cradek> yes
[02:31:55] <jmkasunich> cool
[02:32:00] <cradek> (whee!)
[02:32:03] <SWPadnos> I was thinking that at some point, the pin/param creation could be done by userspace, and the RT code would just get pointed to a block of data
[02:32:16] <jmkasunich> some day
[02:32:19] <jmkasunich> maybe
[02:32:24] <jmkasunich> if we get really ambitious
[02:32:34] <SWPadnos> which might make it possible to do a userspace-only simulator and/or configurator
[02:32:52] <SWPadnos> but yes, that is a large undertaking
[02:33:06] <jmkasunich> cradek: would you like to implement rename, or should I?
[02:33:41] <cradek> I've been looking at the code and I'm afraid the best I would do is put it on my "some day" list
[02:33:58] <cradek> so if you feel like it, that would be super
[02:34:08] <jmkasunich> I bet I can do it in a day or two - if the completion code doesn't get me too confused
[02:34:41] <jmkasunich> syntax: rename sig|param|pin old-name new-name ?
[02:34:59] <cradek> seems reasonable
[02:35:09] <jmkasunich> or do we want to put the pin/param/sig selection as part of the command name
[02:35:24] <jmkasunich> resig, repin, reparam ? ;-)
[02:36:05] <cradek> show has them separate
[02:36:10] <jmkasunich> rename blah is more typing, but clearer, and I don't know how often this feature will be used interactively
[02:36:25] <cradek> very rarely I bet
[02:36:54] <jmkasunich> yeah, rename it will be
[02:37:00] <jmkasunich> who understands the completion stuff?
[02:37:11] <cradek> jeff, if anybody
[02:37:11] <SWPadnos> jeff does!
[02:37:25] <cradek> I propose that my answer is more accurate
[02:37:25] <jmkasunich> so where is Mr. jepler ?
[02:37:33] <cradek> he's been away a lot lately
[02:37:48] <jmkasunich> seb_kuzminsky: you missed something that will be nice once it's implemented
[02:38:44] <jmkasunich> halcmd rename pin hostmot2.some.complex.and.generic.name hostmot2.7i33.terminal-4
[02:39:13] <jmkasunich> leading to "halcmd source hm2-7i33-on-P4.hal"
[02:39:42] <jmkasunich> which will let you name things to match the actual screw terminals
[02:40:24] <cradek> then you don't have to crap up the driver with different personalities - it can be totally generic
[02:41:33] <jmkasunich> {"show", FUNCT(do_show_cmd), A_ONE | A_OPTIONAL | A_PLUS},
[02:41:41] <jmkasunich> hopefully rename is like show
[02:41:53] <jmkasunich> actually, its not - the old and new names aren't optional
[02:42:21] <jmkasunich> and it is the only one that takes three args
[02:42:33] <jmkasunich> damn, I'll have to think instead of copy-pasting
[02:43:09] <SWPadnos> you may need additional checks as well - show can use regexps, and you don't want that for rename
[02:44:12] <jmkasunich> probably want the completion code from setp
[02:44:24] <jmkasunich> and/or sets, depending on the type
[02:45:04] <jmkasunich> no completion on the new name I guess
[02:45:23] <cradek> yeah I guess not
[02:46:15] <seb_kuzminsky> sounds like a good feature, guys
[02:46:32] <seb_kuzminsky> about encoder velocity, that's next on my list
[02:46:39] <SWPadnos> completion is OK, but the string passed to the rename function has to check for wildcards and refuse them
[02:46:41] <seb_kuzminsky> hope to have that and tram done by newtonmas
[02:46:54] <cradek> did you see what peter w said on #emc earlier?
[02:48:41] <seb_kuzminsky> cradek: missed it, but i'll go read the logs
[02:48:46] <seb_kuzminsky> sounds like it was good :-)
[02:49:08] <cradek> he said the inverse problem is a firmware or doc bug
[02:49:33] <seb_kuzminsky> fw *or* doc? wierd, but ok
[02:49:42] <seb_kuzminsky> so new firmwares are forthcoming?
[02:50:00] <cradek> no, I think he's going to change the docs
[02:50:26] <cradek> you should go read it - don't trust my summary :-)
[02:50:52] <seb_kuzminsky> hm ok
[02:51:30] <seb_kuzminsky> that makes no sense
[02:52:07] <seb_kuzminsky> why does my 7i30 work if the enables are not inverted?
[02:52:14] <seb_kuzminsky> maybe it's a recently introduced bug
[02:52:24] <cradek> he said it was all the servo firmwares
[02:52:37] <jmkasunich> he's in your timezone, call him ;-)
[02:53:06] <jmkasunich> for replace, I'm thinking wildcards might be handy (dunno how nasty they'll be to implement)
[02:53:20] <seb_kuzminsky> cradek: can you try an older firmware? maybe SVST8_4.BIT from our current TRUNK
[02:53:23] <cradek> jmkasunich: madnesssssss
[02:53:32] <jmkasunich> for a gpio, there are about 4-5 pins
[02:53:53] <cradek> seb_kuzminsky: sure, let me head out there
[02:54:15] <jmkasunich> if you could change hm2.5i20.blah.pin-034.* to 7i33.* it would reduce the size of the files by 5x
[02:54:27] <seb_kuzminsky> i'll be out in my garage in about 30 minutes or so
[02:54:33] <seb_kuzminsky> got to go now, bbiab
[02:54:47] <jmkasunich> oops, not 7i33.*, more like 7i33.term.02.*
[02:55:50] <SWPadnos> what would be really useful for the hm2 driver would be to have "connector presets"
[02:56:00] <SWPadnos> like P2=7i33
[02:56:16] <SWPadnos> maybe at insmod time
[02:56:33] <jmkasunich> the rename will let you define such presets, using userspace code, instead of embedding it in kernel space
[02:56:40] <jmkasunich> much better solution IMO
[02:56:47] <SWPadnos> I'm talking about setting up the pins and functions too
[02:57:06] <jmkasunich> you could do that in a source
[02:57:19] <jmkasunich> source'ed hal file
[02:57:19] <SWPadnos> sure
[02:57:23] <SWPadnos> sort of :)
[02:57:41] <jmkasunich> honestly, I think rename is the perfect way to do this - it can be applied to _any_ driver, without touching any driver code
[02:57:49] <SWPadnos> as long as it can rename things first, and it can take an instance number (in case I have 2x7i33)
[02:57:49] <SWPadnos> sure
[02:57:59] <SWPadnos> I was thinking of an additional feature for HM2 specifically
[02:58:24] <SWPadnos> nothing else is as generic/versatile, so it wouldn't really be needed elsewhere
[02:59:53] <jmkasunich> see lines 34-79 of
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/configs/demo_mazak/demo_mazak.hal?annotate=1.20
[03:00:17] <SWPadnos> yep
[03:00:56] <cradek> seb_kuzminsky: you are right. the non-IM2 firmware does not have the problem
[03:01:03] <SWPadnos> are there instance numbers in the HAL data (like the comp number, but another tag)?
[03:01:13] <jmkasunich> so on that case, peter should fix the fw, not the docs
[03:01:14] <cradek> I have to take out the P2.010,011,022,023 inverts for it to work properly
[03:01:38] <jmkasunich> SWPadnos: nothing other than what is embedded in the name
[03:01:44] <SWPadnos> ok
[03:01:45] <cradek> this is firmware SVST8_4.BIT I just tested
[03:02:31] <cradek> (and it homes wrong, as expected, which means index mask on IM2 is working)
[03:02:40] <SWPadnos> it may be a good idea to add an instance number to pins/parame then, since the name will now be mutable
[03:03:08] <jmkasunich> SWPadnos: lines 207-216 are the hal metadata for a pin
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/hal_priv.h?annotate=1.31
[03:03:17] <SWPadnos> one could always fix a screwed up rename by looking up a pin by component/ID, and setting the name directly
[03:03:22] <jmkasunich> there is currently no such concept as an instance
[03:03:45] <SWPadnos> understood, but until now, there was no concept of the "globally unique identifier" changing
[03:03:49] <SWPadnos> ie, the name
[03:04:01] <jmkasunich> the rename command will require that the new name be globally unique
[03:04:11] <SWPadnos> yes, but not the same as before
[03:04:20] <jmkasunich> so?
[03:04:40] <SWPadnos> I'm thinking of recovering from things like screwed up scripts that bork the names
[03:04:52] <jmkasunich> halcmd quit ;-)
[03:04:55] <SWPadnos> heh
[03:05:09] <SWPadnos> more like /etc/init.d/realtime stop
[03:05:28] <jmkasunich> unloadrt <comp-with-screwed-up-names>
[03:06:18] <jmkasunich> what you are saying is that we should think thru the implications of this change a tiny bit more
[03:06:29] <SWPadnos> well, I gues sI am saying that
[03:06:43] <cradek> that's just not our style
[03:06:48] <jmkasunich> 210: int owner_ptr; /* component that owns this pin */
[03:06:49] <SWPadnos> oh, sorry :)
[03:07:00] <jmkasunich> that is what is used to remove the pin when the component is removed
[03:07:17] <SWPadnos> it makes me nervous that the only thing that can identify a pin will be mutable
[03:07:28] <jmkasunich> so you can change the "hostmot2." part of the name to anything you want, it will still belong to the hostmot driver
[03:07:41] <SWPadnos> and there may be some that you don't want to allow renaming for, such as (e)stop pins in motion
[03:07:45] <SWPadnos> sure
[03:08:11] <seb_kuzminsky> maybe use a symlink model rather than a rename model?
[03:08:11] <SWPadnos> (then again, letting me rename estop-in to "pleast stop, the machine is off now" might be good :) )
[03:08:12] <jmkasunich> I agree that it probably isn't a good idea to rename the estop pins
[03:08:22] <jmkasunich> but I don't see a need for us to enforce common sense with code
[03:08:52] <jmkasunich> seb_kuzminsky: we thought about something like that (I used the word alias)
[03:09:01] <SWPadnos> that's why I would want to have a unique identifier (jus a short or int) that tells what number pin this is for this component
[03:09:08] <jmkasunich> but that just makes the pin list even longer
[03:09:13] <seb_kuzminsky> i should read back before opening my face ;-)
[03:09:54] <jmkasunich> SWPadnos: the idea of a number that identifies "what pin it is for the comp" or even for the instance, is totally new
[03:09:55] <SWPadnos> one thing that was sort of touched on was a separate name space - just change the name to a pointer (or index)
[03:10:02] <SWPadnos> I know
[03:10:15] <SWPadnos> and it's in response to the also new concept of a name that can change
[03:10:31] <SWPadnos> since that was the only way for anything to find a pin/param before
[03:10:41] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/pins.c: Added a fixme.
[03:10:57] <jmkasunich> it will still be the only way to find things - you just have to look using the new name
[03:11:20] <jmkasunich> I agree that you could do truly perverse things with this
[03:11:44] <SWPadnos> you can also prevent useful things like pyvcp diagnostic panels from working
[03:11:52] <jmkasunich> rename pin.001 tmp; rename pin.002 pin.001; rename tmp pin.002
[03:12:05] <SWPadnos> yep
[03:12:48] <jmkasunich> we can debate whether to do the change or not
[03:13:01] <SWPadnos> I'm not opposed to adding rename right now
[03:13:33] <SWPadnos> I'd just like to keep in mind that we will lose the 1:1 mapping of names to specific pins, and that we may want to add that back in some other form
[03:13:45] <jmkasunich> I strongly believe that halcmd should not be implementing policy - if rename is a powerfull tool, it is up to users to use it properly
[03:14:09] <SWPadnos> hmmm. that's not the reason I'd like an ID
[03:14:30] <jmkasunich> ok, lets step back a second
[03:14:45] <jmkasunich> ID is not the problem, it is ONE possible solution to the problem
[03:14:56] <jmkasunich> the problem is loss of the original name/pin mapping
[03:15:10] <SWPadnos> yes, it's the loss of a constant identifier for a given pin
[03:15:26] <jmkasunich> IMO, ID is not a viable solution, short of a major HAL redo - every single driver and component would need to be touched
[03:15:49] <jmkasunich> we could make aliases, that would preserve the original name
[03:15:54] <SWPadnos> the ID can be assigned per component or globally, it doesn't need driver changes
[03:16:16] <SWPadnos> (ie, start counting and assign increasing numbers to consecutive pins)
[03:16:21] <jmkasunich> if the ID is a number, it won't mean anything to the user
[03:16:35] <jmkasunich> unless you retain the old name and attach it to the number somehow
[03:16:48] <jmkasunich> manpages refer to names, not IDs
[03:17:27] <jmkasunich> if the ID is simply a handle to connect you to the old name, then why not just store the old name
[03:18:41] <SWPadnos> well, having one name in HAL shared data is bad enough, two seems like it's too much :)
[03:19:06] <jmkasunich> again, the ID alone means nothing to the user
[03:19:15] <jmkasunich> so how do you map ID number to something meaningful?
[03:19:30] <SWPadnos> ok, here's my use case
[03:19:38] <jmkasunich> if you have ID/oldname pairs stored somewhere, that will be in hal memory anyway
[03:19:48] <jepler> I won't be staying, but I'd just like to note that I did a weak version of this in comp: you can 'loadrt and2 names=bob,tom'
[03:20:06] <jmkasunich> jepler: interesting
[03:20:29] <SWPadnos> I (a third party from the driver writer or the driver user) write a utility that works with some pins from some driver
[03:20:34] <jmkasunich> not quite the same, you are changing the first part: bob.in1, bob.out
[03:20:39] <jepler> halcmd: loadrt and2 names=bob,tom
[03:20:39] <jepler> halcmd: list pin
[03:20:39] <jepler> bob.in0 bob.in1 bob.out tom.in0 tom.in1 tom.out
[03:20:50] <SWPadnos> say a parallel port monitor
[03:20:52] <jepler> jmkasunich: yes exactly .. maybe calling it a "weak version" is wrong, it's a related thing
[03:21:04] <SWPadnos> heh - and very useful and nice IMO
[03:21:56] <jmkasunich> SWPadnos: ok, continue with use case
[03:21:59] <SWPadnos> ok
[03:22:41] <SWPadnos> so I, realizing that some users will rename the pins, use the new "get_pin_by_ID" function in hal_lib (and/or halcmd)
[03:23:14] <SWPadnos> and I can even look up the new name they've assigned, so I can display it in my monitor app
[03:23:41] <SWPadnos> the only time I have to change my app is when the pins change in the parport driver
[03:23:57] <jmkasunich> that means the ID numbers are assigned on a per-component basis
[03:23:59] <SWPadnos> more often than now, since it might be pin creation order dependent
[03:24:02] <jmkasunich> or per-instance even
[03:24:04] <SWPadnos> sure
[03:24:31] <jmkasunich> IMO, relying on pin creation order is just plain wrong
[03:24:36] <SWPadnos> per component would be the best that way, but an additional library function could look up a base number and use offsets
[03:24:41] <SWPadnos> I agree, it's not ideal
[03:24:56] <jmkasunich> and on the halcmd side it is completely meaninless
[03:25:07] <SWPadnos> ?
[03:25:15] <jmkasunich> it is one thing for a program to assume that the creation order of pins in parport hasn't changed since it was compiled
[03:25:32] <jmkasunich> it is another thing completely to expect the user to have any idea at all what that order is
[03:25:44] <jmkasunich> unless you are going to put that info into the driver and its manpage
[03:26:01] <jmkasunich> which implies the "touch everything" issue that I raised in the first place
[03:26:03] <SWPadnos> what user are you referring to?
[03:26:21] <jmkasunich> the guy who is typing into halcmd, or into a hal file that will be executed by halcmd
[03:26:52] <SWPadnos> ah, ok. halcmd operates on names, so IDs wouldn't be important
[03:27:15] <SWPadnos> except for the case where one wants to look up a name based on ID, or set a name based on ID
[03:27:18] <jmkasunich> a pyvcp parport test panel also operates on names
[03:27:48] <jmkasunich> I still think the ID thing is something that should be added during a major rewrite, when it can be integrated with instances and such
[03:28:20] <jmkasunich> I can see the benefit of retaining the old names though, for pyvcp and other utilities
[03:28:54] <SWPadnos> liek I said - I'm not worried about it enough to prevent the addition of a renaming feature, it's something to think about though
[03:29:15] <jmkasunich> your use case is an argument against rename though
[03:29:18] <SWPadnos> an alias field would also be fine with me
[03:29:22] <jmkasunich> (and in favor of symlink or alias)
[03:29:59] <SWPadnos> it's true that it would be harder to maintain a list of pin numbers if they're automatically assigned
[03:30:11] <SWPadnos> so symlinks/aliases would be easier to deal with there
[03:30:34] <jmkasunich> in the someday hal, I'd like to treat the names more formally
[03:30:47] <jmkasunich> they sort of look like paths today, except with . instead of /
[03:30:52] <jmkasunich> but that is strictly a convention
[03:31:07] <SWPadnos> I'd love to have hierarchical names as well
[03:31:15] <jmkasunich> but that is a future thing
[03:31:20] <SWPadnos> especially if parameters are kept
[03:31:48] <SWPadnos> yes, future
[03:31:48] <jmkasunich> so, lets reign ourselves in, and talk about the task at hand only
[03:31:55] <jmkasunich> rename vs alias
[03:31:59] <jmkasunich> and if alias, how
[03:32:23] <SWPadnos> well, for alias, I'd just add a field and make the HAL data bigger
[03:32:27] <jmkasunich> one approach to alias would be like a symlink - a completely new entry in the list, that one way or another connects to the first entry
[03:32:38] <SWPadnos> then make the find_*_by_name functions look at names first, then aliases
[03:33:31] <jmkasunich> I'm gonna call what I described symlink, and what you described alias
[03:33:44] <SWPadnos> ok
[03:33:53] <jmkasunich> with symlink, show pin would show two lines for the pin, one with the original name, one with the symlink name
[03:34:06] <jmkasunich> the current value, signal linked to, etc, info would appear in both
[03:34:30] <SWPadnos> ewww
[03:34:34] <jmkasunich> with alias, show would only show one line, with the ailas in parens or something
[03:35:37] <SWPadnos> I don't like the idea of things showing up twice
[03:35:43] <jmkasunich> I think I agree
[03:35:54] <jmkasunich> remember, I said "one approach would be symlink-like"
[03:35:56] <SWPadnos> it would get confusing when you apparently have two writers, for example
[03:36:00] <SWPadnos> heh, yep :)
[03:36:04] <jmkasunich> you brought up the other before I could type it
[03:36:16] <SWPadnos> sure, no problem
[03:36:37] <jmkasunich> to save space, I wouldn't add two name fields to every pin struct, just a pointer
[03:36:44] <SWPadnos> what I might do is have show use the alias if it exists or the name if not
[03:37:07] <SWPadnos> and add a new show type (show alias or something) that would show more or less a was-is list
[03:37:31] <jmkasunich> I _really_ wish I hadn't designed HAL with three namespaces
[03:37:43] <SWPadnos> the rationale being that if you rename something, you would expect to see the thing with the new name only
[03:37:46] <jmkasunich> if pins, params, and signals were guaranteed to have unique names, this would be simpler
[03:38:06] <SWPadnos> well, for one thing you could stick all the names in a separate block of memory and just have pointers in the structs
[03:38:24] <jmkasunich> huh?
[03:38:41] <SWPadnos> actually, that can be done anyway - nevermind :)
[03:38:46] <jmkasunich> ;-)
[03:38:51] <SWPadnos> but we're digressing ;)
[03:38:57] <SWPadnos> we do it so well
[03:39:05] <jmkasunich> the existing approach avoids memory fragmentation
[03:39:19] <jmkasunich> but as you say, digression
[03:39:32] <SWPadnos> I think I'd favor the alias approach for now
[03:39:39] <SWPadnos> 1) it retains the old name
[03:39:46] <jmkasunich> if the names were unique, then it would be "alias old-name new-name"
[03:39:50] <SWPadnos> 2) it doesn't make extraneous structs that only hold a name
[03:40:03] <jmkasunich> no pin/param/sig argument, no extra complexity doing completion from one list or another, etc
[03:40:17] <SWPadnos> it dosen't matter if the names are unique, as long as the "important" names, ie the original names, are
[03:40:22] <SWPadnos> sure
[03:40:46] <SWPadnos> alial motion fred
[03:40:48] <SWPadnos> alias
[03:40:58] <jmkasunich> carefull there
[03:41:00] <SWPadnos> alias pid voodoo_controller :)
[03:41:16] <SWPadnos> which is where hierarchical naming could pay off:
[03:41:19] <jmkasunich> would that change the name of motion.<everything> to fred.<everything>?
[03:41:27] <SWPadnos> setp voodoo_controller.0.Pgain 100 ;)
[03:41:38] <jmkasunich> not gonna happen
[03:41:41] <SWPadnos> heh :)
[03:41:50] <jmkasunich> * jmkasunich slaps SWPadnos with a trout
[03:41:52] <SWPadnos> list comp: voodoo_controller
[03:41:58] <SWPadnos> anyway
[03:42:28] <jmkasunich> back to the syntax of the command
[03:42:37] <jmkasunich> I'm tempted to call it alias, not rename
[03:42:46] <jmkasunich> since the original name will be retained, even if hidden
[03:42:55] <SWPadnos> yep, and I'd do it with a second name field in the pin struct
[03:43:10] <jmkasunich> alias pin|param original-name alias-name
[03:43:13] <SWPadnos> I don't know if it's necessary for params, but let's assume it is
[03:43:15] <SWPadnos> yep
[03:43:34] <SWPadnos> and maybe unalias pin|param name
[03:44:00] <SWPadnos> (I don't think halcmd deals well with "nothing" strings)
[03:44:02] <jmkasunich> if someone wants to change an alias, I'm torn between "alias old-alias new-alias" and "alias orig-name new-alias"
[03:44:22] <SWPadnos> hmmm
[03:44:24] <jmkasunich> I think I prefer the latter
[03:44:37] <jmkasunich> but new-alias is what they'll see in a regular show
[03:45:00] <SWPadnos> ah, ok. pin name matching should look for aliases first, then original names
[03:45:18] <SWPadnos> which does bring up a problem - what if I alias pin-name-2 to pin-name-1
[03:45:27] <SWPadnos> ah, I can't since it's not unique
[03:45:44] <jmkasunich> newalias will be tested against both pin names and existing aliases
[03:45:49] <SWPadnos> yes
[03:46:16] <SWPadnos> this would make pin searches less efficient, unless a second linked list is maintained which includes both names and aliases (PITA IMO)
[03:46:34] <jmkasunich> what would?
[03:46:54] <SWPadnos> you'd have to traverse the entire pin list looking for aliases
[03:47:07] <SWPadnos> unless you find a matching name first
[03:47:14] <jmkasunich> the existing searches are linear anyway, even though they lists are sorted
[03:47:15] <jmkasunich> so it
[03:47:21] <jmkasunich> it's still O(n)
[03:47:39] <jmkasunich> the constant goes from 0.5 on average, to 1.0
[03:47:43] <SWPadnos> oh - I thought it short-circuited if it found (name > search_term)
[03:47:52] <SWPadnos> right
[03:48:19] <jmkasunich> at one point I was considering AVL trees for the metadata, but that too is something for a major rewrite
[03:48:24] <SWPadnos> yep
[03:48:35] <SWPadnos> do we have a list? (other than IRC logs :) )
[03:48:55] <jmkasunich> I don't think anybody has ever complained about halcmd speed, even on the longest hal files
[03:49:12] <SWPadnos> heh
[03:49:38] <SWPadnos> it has been annoying in halshow, but that may have been early on in the development cycle (and was more likely a tcl problem)
[03:50:02] <jmkasunich> at one point, halshow was shelling out to halcmd for everything
[03:50:07] <jmkasunich> inside a loop, IIRC
[03:50:14] <jmkasunich> that is just so wrong
[03:50:18] <SWPadnos> yes, and then doing some weird sorting or something
[03:50:39] <jmkasunich> anyway... I hate the idea of two name fields in every struct
[03:50:40] <SWPadnos> something to do with that was why I added script mode
[03:50:48] <jmkasunich> the name is by far the biggest part of the structure already
[03:51:00] <SWPadnos> yes
[03:51:08] <jmkasunich> however, two fields make things simple
[03:51:20] <jmkasunich> on creation, write the original name into both
[03:51:33] <jmkasunich> on unalias, copy the original name into the alias
[03:51:55] <jmkasunich> search exact tests both, exits when either matches
[03:52:12] <jmkasunich> search wildcard is a bit more interesting, or maybe not
[03:52:41] <SWPadnos> I think I'd set the first byte to 0 to signify that there is no alias
[03:52:54] <jmkasunich> search exact will still be 0.5*O(n) on a hit, only misses will go all the way
[03:53:18] <SWPadnos> no, since I can set the first pin in the list to ZebraFur
[03:53:31] <SWPadnos> and the last to AlphaMale
[03:53:35] <jmkasunich> _on a hit_
[03:54:02] <SWPadnos> an alias hit or a name hit?
[03:54:13] <jmkasunich> the early out only works on a miss - if you are in an alphabetical list looking for P and you find a Q, you can exit, if its not sorted you have to keep going
[03:54:16] <jmkasunich> either
[03:54:37] <jmkasunich> remember, proposed aliases will be tested against both existing aliases _and_ original names
[03:54:40] <SWPadnos> ah, ok
[03:55:03] <jmkasunich> there is no reason to search for one before the other
[03:55:31] <SWPadnos> I'm thinking of any search that turns up a name as a hit, but I think you were talking about name hits (not aliases), which are the only thing that can early-out
[03:55:52] <jmkasunich> I'm talking about any hit
[03:56:14] <jmkasunich> a hit will early out as soon as you hit - since every name is unique, once you fine a hit on either name _OR_ alias,you are done
[03:56:18] <SWPadnos> oh, of course
[03:56:29] <SWPadnos> assuming you search for all things in an evenly distributed way
[03:56:41] <jmkasunich> the old code could also early out on misses, the new code will have to keep going on misses
[03:56:46] <SWPadnos> rigth
[03:56:48] <SWPadnos> ht
[03:57:11] <jmkasunich> anyway, these things only affect the constant, not the big-O order
[03:57:46] <SWPadnos> sure
[03:57:53] <jmkasunich> I'm trying to remember why I liked the "copy name to alias field" approach
[03:58:30] <jmkasunich> find_foo_by_name() will go thru the list testing against name, and against alias if non-zero
[03:58:47] <jmkasunich> exit if either matches
[03:59:11] <jmkasunich> I have no idea how completion/wildcard code works
[03:59:44] <SWPadnos> I think it always goes through the whole list, since it has to find all matches
[03:59:47] <jmkasunich> but again, I suspect it will be testing its wildcard containing string against both name and non-zero alias fields
[04:00:03] <SWPadnos> it usees regexps, and I believe the strings to match are passed to a regexp function
[04:00:21] <SWPadnos> so the search code just has to pass both the aliases and the names to the regexp function (AFAIK)
[04:00:30] <jmkasunich> sounds reasonable
[04:00:43] <SWPadnos> hmmm. yeah it does - it must not work that way
[04:00:46] <SWPadnos> :)
[04:01:08] <jmkasunich> if we're gonna play some game with zeroing the alias field when the pin has no alias, then I don't think the alias field should be a string bugger
[04:01:13] <jmkasunich> buffer
[04:01:16] <jmkasunich> make it a pointer
[04:01:28] <jmkasunich> we can have another list, of alias structs
[04:01:54] <jmkasunich> struct alias { int next, int owner_pin, char name[big]}
[04:01:57] <SWPadnos> I don't think it's significantly harder to use if (halpin->alias[0] == '\0') than it is to use if (halpin->alias == NULL)
[04:02:14] <SWPadnos> you don't even need the [0]
[04:02:25] <jmkasunich> but we will only have to allocate alias entries for the small fraction of pins that actually have aliases
[04:02:42] <SWPadnos> and you eliminate all memory management issues, except for the one where you need more overall memory for he hugely bloated pin structs :)
[04:02:54] <jmkasunich> memory management is easy
[04:03:24] <jmkasunich> believe me, compared to the completion crap, the list and memory management issues are trivlal (at least for me)
[04:03:27] <SWPadnos> well, either way works, it's unimportant how it's stored, what's important is how it's used
[04:03:31] <jmkasunich> right
[04:03:44] <SWPadnos> so NULL pointer (or string) for no alias
[04:04:15] <jmkasunich> it looks like "unalias" can accept either the orig name or the alias
[04:04:25] <SWPadnos> all commands except alias match aliases first, then names (though that's not strictly necesasry if aliases ahd names have to all be unique)
[04:04:27] <SWPadnos> sure
[04:04:28] <jmkasunich> ditto for changing an alias
[04:04:50] <jmkasunich> I am going to insist that aliases be unique
[04:05:05] <SWPadnos> unique in the same name space as names
[04:05:19] <jmkasunich> both because it makes the code simpler (first match is _the_ match) and because it avoids user frustration when two things are named the same
[04:05:26] <SWPadnos> yeah
[04:05:33] <jmkasunich> yes, names and aliases are in the same space
[04:05:55] <jmkasunich> otherwise you could have orig name foo.01, and then orig name foo.02 aliased to foo.01
[04:06:02] <jmkasunich> show would show two foo.01's
[04:06:07] <SWPadnos> ok, so when printing things (show), you use the alias if there is one, and the name if there isn't
[04:06:13] <SWPadnos> right
[04:06:13] <jmkasunich> right
[04:06:29] <SWPadnos> there should be a new show and save type, allias
[04:06:31] <jmkasunich> show alias would show only the orig-name/alias pairs
[04:06:35] <SWPadnos> alias that is
[04:06:38] <SWPadnos> right
[04:06:49] <SWPadnos> and save should only output pins that have aliases (of course)
[04:06:54] <SWPadnos> hmmm
[04:07:08] <jmkasunich> one minor advantage of storing the alias strings separately - that list can be kept sorted as well
[04:07:17] <jmkasunich> so show-alias would be sorted by alias name
[04:07:26] <SWPadnos> hmmm - ok, sure
[04:08:03] <jmkasunich> show and save alias wouldn't have to traverse the main list either, they'd just traverse the alias list
[04:08:23] <SWPadnos> oh, good point
[04:09:07] <jmkasunich> damn I wish pins/params were in the same namespace
[04:09:13] <SWPadnos> shhh
[04:09:29] <jmkasunich> I bet there are no duplicates right now
[04:09:35] <SWPadnos> that's where completion would be really nice though
[04:09:43] <SWPadnos> or wildcards anyway
[04:09:55] <jmkasunich> someday
[04:10:10] <SWPadnos> alias parport.0.pin-01* parport.0.enable.*
[04:10:21] <jmkasunich> yeah
[04:10:22] <SWPadnos> which also does the invert parameter
[04:10:43] <jmkasunich> for the 5i20 its even more usefull - a gpio pin has 4-5 pins/params
[04:10:47] <SWPadnos> yep
[04:10:54] <SWPadnos> and encoders/PWMs too
[04:11:15] <jmkasunich> I bet it wouldn't be too terrible
[04:11:31] <jmkasunich> we have code that finds all matches of a wildcarded name
[04:11:48] <jmkasunich> oh, it would be hard
[04:11:50] <SWPadnos> it probably is actually. you need regexp to keep track of what matched the wildcard
[04:12:20] <jmkasunich> alias "foo.*.bar.* blat.*.baz.*"
[04:12:24] <SWPadnos> and put it back wherever it was, with the changed stuff around it
[04:12:31] <SWPadnos> yep
[04:12:49] <SWPadnos> hmmm. or use sed ;)
[04:12:56] <jmkasunich> that might be in incremental enhancement after the base function is working
[04:13:21] <jmkasunich> the hard part is gonna be the bleeping parsing
[04:13:27] <SWPadnos> in regexp-speak, that's something like alias foo.*.bar.* blat.\1.baz.\2
[04:13:47] <SWPadnos> but there's something more needed to specify the matched hunks, which I don't remember
[04:13:58] <jmkasunich> not gonna worry about that right now
[04:14:15] <SWPadnos> parsing in general or only for wildcards?
[04:14:26] <jmkasunich> parsing in general (which includes completion, etc)
[04:14:28] <cradek> regexps sounds like enough feature creep to kill the project
[04:14:56] <jmkasunich> I'm not doing wildcards in the first pass - that is decided already
[04:14:57] <SWPadnos> completion isn't an issue at the moment - the only thing that can be completed is the pin name, and there's already code to do that
[04:15:06] <jmkasunich> it _is_ an issue
[04:15:15] <jmkasunich> because I don't have the foggiest idea how to invoke that code
[04:15:34] <SWPadnos> oh - well it should be easy :)
[04:15:46] <SWPadnos> there are some tables. let me look at that
[04:15:53] <jmkasunich> the commands will be "alias pin <invoke-pin-completion>" and "alias param <invoke-param-completion>"
[04:16:16] <jmkasunich> do I do those as two table entries? (seems lame)
[04:16:29] <jmkasunich> I was looking at the tables an hour ago
[04:16:35] <cradek> oh did you decide on alias, not rename?
[04:16:39] <jmkasunich> yes
[04:16:50] <jmkasunich> because we are gonna retain the original name
[04:16:58] <cradek> ok
[04:17:00] <SWPadnos> actually it's (tab completion of command names) (tab completion of type names (pin/param...)) (tab completion of that type) (no more tab completion)
[04:17:38] <jmkasunich> SWPadnos: it is some complex scheme that is far from self evident to me
[04:18:03] <SWPadnos> are you going to finish tonight?
[04:18:07] <jmkasunich> fsck no
[04:18:10] <SWPadnos> heh
[04:18:15] <SWPadnos> ok, then I can do the completion part :)
[04:18:20] <jmkasunich> I'd be thrilled to get the parsing done
[04:18:33] <jmkasunich> I'd be even more thrilled if you did the parsing ;-)
[04:19:09] <SWPadnos> ok, the completer looks straightforward at the moment
[04:19:12] <SWPadnos> heh
[04:20:03] <jmkasunich> * jmkasunich starts changes to structs and hal_lib
[04:20:29] <SWPadnos> for now, leave the halcmd part to me. I'll see what the parsing is like
[04:22:30] <SWPadnos> now which computer can I actually run Linux on to do this editing?
[04:22:38] <SWPadnos> ah - the laptop
[04:39:05] <CIA-38> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/utils/halcmd_completion.c: add completion for alias command
[04:39:15] <jmkasunich> that was fast
[04:39:46] <SWPadnos> it turned out to be easy :)
[04:40:25] <SWPadnos> I haven't modified the pin name generator to put aliases in yet, but that should be pretty easy once you write the hal_lib functions to retrieve aliases :)
[04:40:34] <SWPadnos> pasring isn't there either
[04:41:02] <jmkasunich> I'm working on the structs and memory management, thats probably as far as I'll get tonight
[04:41:10] <SWPadnos> no problemo
[04:41:31] <SWPadnos> I'll look at parsing, maybe get it done tonight (probably not)
[04:48:59] <cradek> oh look, a commit of alias stuff already
[04:49:04] <cradek> yay
[04:49:12] <SWPadnos> heh
[04:55:34] <jmkasunich> have you ever noticed that if you see the same word many times, it suddely looks strange
[04:55:49] <cradek> definitely
[04:55:59] <jmkasunich> I've read and typed alias about 100 times this evening, and now I suddenly have to recheck the spelling
[05:05:12] <jmkasunich> I can't imagine a reason to alias a signal
[05:05:20] <jmkasunich> signal names are selected by the user in the first place
[05:05:46] <SWPadnos> too confusing - don't do it
[05:06:11] <jmkasunich> not gonna - pins and params only
[05:07:26] <SWPadnos> hmmmm - well, there is one sort-of reason, but it needs more than just an extra name
[05:07:37] <jmkasunich> ?
[05:07:38] <SWPadnos> having the ability to tie two sinals together could be useful
[05:07:46] <jmkasunich> not gonna happen
[05:07:57] <SWPadnos> right - needs a lot more than an extra name :)
[05:08:03] <jmkasunich> the way that signals are implemented won't allow that
[05:08:19] <SWPadnos> right - you'd need pins to be **type
[05:08:25] <SWPadnos> rather than *type
[05:08:33] <jmkasunich> ewwwwww
[05:08:34] <SWPadnos> or is it *** instead of **
[05:08:36] <SWPadnos> heh
[05:09:06] <jmkasunich> HAL is based around the netlist metaphore
[05:09:25] <jmkasunich> you can't have join two nets (and have them remain distinct entities)
[05:09:46] <SWPadnos> the reason for doing it would be so you could put several components and their connections into a single hal file, then connect an existing signal to an input to the "macromodule", where that input may connect to several things (ie, it's already a signal)
[05:10:10] <SWPadnos> right - you ususally use a special component to do that
[05:10:21] <jmkasunich> which could be done in hal
[05:10:30] <jmkasunich> thread ordering would get complex tho
[05:10:41] <jmkasunich> in fact,. thread ordering would make macrocomponents tricky anyway
[05:10:43] <SWPadnos> sure, a buffer, out=in
[05:10:55] <jmkasunich> someday I want to consider auto-thread-ordering
[05:11:06] <jmkasunich> that is almost as blue-sky as some of the other stuff we're discussing
[05:11:13] <SWPadnos> but typing is a pain there (there has to be a buffer for each data type)
[05:11:16] <SWPadnos> yep :)
[05:11:56] <jmkasunich> ok, I have an allocator, a free-er, and aliases connected to pins and params are freed when the pin/param is freed
[05:12:04] <SWPadnos> nice
[05:12:13] <jmkasunich> totally untested, but it compiles nice
[05:12:17] <SWPadnos> I almost have a parser, but I stopped for a snack
[05:12:38] <jmkasunich> since no code invokes the allocator, and nothing attaches aliases to pins or params, most of the code won't get executed
[05:12:51] <jmkasunich> only a couple lines of init
[05:12:55] <SWPadnos> I'm noticing that other functions don't check for wildcards in their input strings - they just assume those chars are meant to be part of the string
[05:12:59] <SWPadnos> at least net is that way
[05:13:19] <SWPadnos> so you can make a net called fred*wilma
[05:13:36] <SWPadnos> since * and ? and the like are valid HAL characters
[05:15:21] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/ (hal_lib.c hal_priv.h): structs and memory management for alias
[05:18:43] <SWPadnos> hmmm. making lists of pin aliases (vs. parameter aliases) doesn't look too easy with that scheme
[05:18:55] <SWPadnos> since there's no good way to tell what type the owner is
[05:19:05] <jmkasunich> no
[05:19:13] <SWPadnos> separate lists?
[05:19:23] <jmkasunich> it bugs me, if I need to I can add an owner-type field to the alias struct
[05:19:24] <jmkasunich> I'
[05:19:38] <jmkasunich> I'm gonna hope it goes away when all the params turn into pins
[05:19:41] <jmkasunich> ;-)
[05:19:55] <SWPadnos> well, it'll be impossible to complete unless there's something
[05:20:17] <jmkasunich> ok, I'll do that tomorrow
[05:20:18] <SWPadnos> oh, there should be an unalias command, shouldn't there
[05:20:23] <jmkasunich> yeah
[05:20:27] <SWPadnos> ok, I'll add that
[05:20:30] <jmkasunich> this pin/param thing is a real pita
[05:20:47] <SWPadnos> just make two lists, using the same functions to manipulate them
[05:21:13] <jmkasunich> yeah, I suppose that is more efficient
[05:21:17] <jmkasunich> * jmkasunich fixes
[05:21:19] <SWPadnos> heh
[05:22:06] <jmkasunich> I think I can get away with not incrementing the version code again ;-)
[05:22:25] <SWPadnos> oh noes, what if someone downloaded it already? :)
[05:24:55] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/ (hal_lib.c hal_priv.h): separate lists for pin and parameter aliases
[05:26:06] <jmkasunich> if I made the lists doubly-linked, then removal would be O(1) instead of O(n), but I'm finding it hard to care
[05:26:28] <SWPadnos> very hard
[05:27:20] <jmkasunich> removal of a single alias (unalias) will take negligable time either way
[05:27:31] <jmkasunich> bulk removal happens at shutdown only
[05:27:36] <SWPadnos> yeah, even with 1000 aliases loaded
[05:28:31] <cradek> thalcmd: alias pin abs.0.sign thebit
[05:28:31] <cradek> <stdin>:2: Unknown command 'alias'
[05:28:44] <cradek> -t
[05:28:47] <jmkasunich> the parsing isn't done yet, just the completion code
[05:28:50] <SWPadnos> well sure, it doesn't do anything, you can just complete it :)
[05:28:52] <cradek> ah
[05:29:02] <cradek> it does complete nicely
[05:29:07] <SWPadnos> thank you :)
[05:29:29] <cradek> I sure do like completion in halcmd
[05:29:52] <SWPadnos> I should probably make it return without trying completion if it's on the third token
[05:30:13] <SWPadnos> it seems to pause for a little bit if you tab after the pin/param name
[05:32:28] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: add alias memory usage to status report
[05:32:47] <jmkasunich> goodnight
[05:32:51] <SWPadnos> night
[05:33:30] <cradek> me too, goodnight
[05:33:39] <SWPadnos> night. me three
[05:50:28] <fenn_> fenn_ is now known as fenn
[06:04:06] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/hal_lib.c: forgot some initialization
[06:04:19] <jmkasunich> I realized I forgot that while walking the dog....
[06:23:06] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: more to do
[06:26:32] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (14 files): better logging: let users actually see what they need to see, without setting the debug level
[06:29:02] <fenn> hardware unit tests makes a lot of sense for emc, they don't even need to be automated
[06:30:33] <fenn> would be a little more reliable than just "well, looks like its working"
[06:34:21] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: (log message trimmed)
[06:34:21] <CIA-38> EMC: This commit contains a GPIO rename that breaks configs!!
[06:34:21] <CIA-38> EMC: Only configs that monkey with the GPIOs are affected (that's you, cradek);
[06:34:21] <CIA-38> EMC: all other configs will work without change.
[06:34:21] <CIA-38> EMC: Before this, GPIOs had names like "hm2_5i22.0.gpio.P5.095", with
[06:34:23] <CIA-38> EMC: the connector name and the IO number. Now, GPIOs have names like
[06:34:25] <CIA-38> EMC: "hm2_5i22.0.gpio.095" (ie, without the connector name, with just the
[06:34:27] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (ioport.c pins.c): (log message trimmed)
[06:34:30] <CIA-38> EMC: This commit contains a GPIO rename that breaks configs!!
[06:34:32] <CIA-38> EMC: Only configs that monkey with the GPIOs are affected (that's you, cradek);
[06:34:34] <CIA-38> EMC: all other configs will work without change.
[06:34:36] <CIA-38> EMC: Before this, GPIOs had names like "hm2_5i22.0.gpio.P5.095", with
[06:34:38] <CIA-38> EMC: the connector name and the IO number. Now, GPIOs have names like
[06:34:40] <CIA-38> EMC: "hm2_5i22.0.gpio.095" (ie, without the connector name, with just the
[15:01:16] <cradek> heh, seb broke my config, two hours after it was done
[15:50:18] <seb_kuzminsky> good morning
[16:01:49] <cradek> hi seb
[16:05:11] <seb_kuzminsky> no smoke in your workshop yet i hope
[16:05:17] <cradek> nope, it works great
[16:05:36] <seb_kuzminsky> it'll work even better when we get the fixed firmware from peter (hopefully later today)
[16:05:49] <SWPadnos> hmmm. that's kind of the opposite of cradek's last statement :)
[16:05:56] <SWPadnos> [10:01:38]<cradek>heh, seb broke my config, two hours after it was done
[16:06:05] <cradek> I fixed it already - it was simple
[16:06:06] <seb_kuzminsky> it was a small break ;-)
[16:06:16] <SWPadnos> yeah, I figured it was jus tthe inverts on the enables
[16:06:19] <seb_kuzminsky> and really, it was broken *before*, i just fixed it
[16:06:20] <SWPadnos> just the
[16:06:24] <SWPadnos> heh
[16:07:14] <seb_kuzminsky> SWPadnos: the thing i fixed that broke cradek's config was the naming of the gpios in hal that you and jmk and i talked abotu the other night
[16:07:22] <SWPadnos> oh, ok
[16:07:40] <seb_kuzminsky> cradek had to use the gpio invert_output params to work around a bug in the SVST8_4_IM2 firmware
[16:07:45] <SWPadnos> soon, there will be an alias command, so it may be a moot point
[16:07:51] <SWPadnos> right
[16:07:58] <seb_kuzminsky> i saw you and jmk talking about that last night
[16:08:01] <seb_kuzminsky> what did you decide?
[16:08:12] <SWPadnos> it's about half done and committed
[16:08:30] <SWPadnos> there will be a command (alias) to create a second name for a pin
[16:08:47] <SWPadnos> the original name will always be there, the alias will just be a synonym for it
[16:08:59] <SWPadnos> for pins and params only
[16:09:23] <SWPadnos> there will be an unalias command as well: unalias <original pin name> will remove an alias from a pin
[16:09:38] <seb_kuzminsky> each pin has zero or one aliases?
[16:09:41] <SWPadnos> yes
[16:10:03] <SWPadnos> it'll be confusing enough to be able to refer to a pin with two names. more would be insane IMO
[16:10:39] <seb_kuzminsky> well emc2 config is all about how much insanity and confusion you can endure :-)
[16:10:47] <SWPadnos> actually, I'd prefer to not use the original name at all for anything that has an alias (other than unalias of course), but there are good reasons to allow it
[16:10:49] <SWPadnos> heh
[16:11:17] <SWPadnos> there will of course be additional information and types for show and save, so you can save aliases
[16:11:27] <SWPadnos> yadda yadda :)
[16:12:01] <SWPadnos> ok, time for breakfast so I can work on the halcmd code
[16:12:04] <SWPadnos> bbiab
[17:58:57] <alex_joni> hello
[17:59:54] <SWPadnos> hi
[18:00:26] <alex_joni> too bad I wasn't around last night ;)
[18:00:44] <SWPadnos> for the alias conversation or the hostmot2 conversation?
[18:00:51] <SWPadnos> (or something else)
[18:00:54] <alex_joni> the talk about alias was very exciting/interesting
[18:01:06] <SWPadnos> well, it's not done yet - you can still comment :)
[18:01:15] <alex_joni> it's pretty frustrating reading the logs and just wanting to scream something :D
[18:01:26] <alex_joni> but in the end you got to the same conclusion, so I'm good ;D
[18:01:31] <SWPadnos> heh, ok :)
[18:02:23] <SWPadnos> hmmm. didn't somebody add a D term input to the PID component?
[18:02:39] <SWPadnos> so we could use the higher resolution velocity output from encoder (or hardware)
[18:03:22] <SWPadnos> hmmm. maybe we just talked about it
[18:03:58] <jepler> I spent about an hour at it once but got lost driving around
[18:04:05] <SWPadnos> heh
[20:03:40] <CIA-38> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/machining_center.lyx: add info for lathe tool table
[20:16:18] <CIA-38> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/machining_center.lyx: add info on lathe tool table and fix a few floaties
[20:18:18] <CIA-38> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/Master_User.lyx: add section headers to lathe chapter
[20:18:19] <CIA-38> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/lathe/lathe-user.lyx: add section headers to lathe chapter
[20:22:23] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[20:24:03] <CIA-38> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/lathe/lathe-user.lyx: add section titles to lathe chapter
[20:24:35] <jepler> I am so pleased to have someone else taking charge of the documentation
[20:24:45] <jepler> BigJohnT: thanks once again
[20:24:47] <jepler> I can't say it too much
[20:25:01] <BigJohnT> :) leaves you more time to program neat things for EMC
[20:44:13] <seb_kuzminsky> cradek: i just got the new firmware image & source from peter
[20:44:58] <cradek> neat. I can try it late tonight.
[20:45:48] <seb_kuzminsky> * seb_kuzminsky kicks CIA-38
[20:45:48] <CIA-38> ow
[20:46:19] <seb_kuzminsky> * seb_kuzminsky shrugs
[20:47:45] <cradek> heh, I saw the email though
[20:47:51] <cradek> thanks again