#emc-devel | Logs for 2006-11-10

[01:10:22] <cradek> hi jmk
[01:26:23] <owhite> anybody home?
[01:30:59] <jmkasunich> hi cradek
[01:31:25] <cradek> hi
[02:11:34] <jepler> jmkasunich: is there any documentation written on halvcp yet?
[02:12:29] <jmkasunich> no
[02:12:37] <jmkasunich> I've been planning to do that the last couple days
[02:12:48] <jmkasunich> I just seem to be lacking initiative
[02:20:57] <jmkasunich> jepler: why did you ask? trying to figure something out?
[02:22:49] <jepler> no, I was going to start on it
[02:23:08] <jepler> but now I'm trying to figure something out -- can vcp invert a button output or do I have to do it in hal?
[02:24:29] <jepler> looks like "no"
[02:30:59] <jmkasunich> no
[02:31:19] <jmkasunich> unless you have a burning desire to do that documentation, leave it for me
[02:32:09] <jepler> it's just something to do
[02:38:10] <jmkasunich> which would you rather be doing with vcp: writing doc, or adding new widgets? ;-)
[02:38:59] <jepler> I don't know enough gtk to possibly add more widgets ;-P
[02:39:20] <jmkasunich> damn...
[02:39:30] <jmkasunich> ok, you write doc and I'll _try_ to add widgets
[02:39:45] <jmkasunich> or maybe not
[02:39:53] <jmkasunich> have you already started anything?
[02:39:58] <jepler> not really
[02:40:18] <jmkasunich> ok, I'll write doc... because that will bring me back up to speed
[02:40:19] <jepler> just a chatty little introduction, foiled by the non-invertability of vcp buttons
[02:40:28] <jepler> I guess that means I have to learn gtk now
[02:40:43] <jmkasunich> not unless you really want to
[02:40:54] <jmkasunich> commit the chatty intro
[02:41:34] <jmkasunich> I wonder if halvcp buttons should be like canonical digital inputs (with foo and foo-not HAL pins)?
[02:41:57] <jmkasunich> and halvcp LEDs like canonical digital outs, with -invert params
[02:42:11] <jepler> what I wanted was a momentary vcp estop button, but the sense was backwards for that
[02:42:16] <jmkasunich> ah
[02:42:34] <jmkasunich> there is a not HAL component (at least I think there is)
[02:42:39] <jepler> yes there is
[02:42:39] <jmkasunich> if there isn't, there soon will be
[02:42:52] <jepler> but my "small example" was looking not so small
[02:42:52] <jepler> so I went for a toggle
[02:42:58] <jmkasunich> ah
[02:43:42] <jepler> I could start by adding that
[02:43:49] <jepler> it seems less important for LED because you can set the colors...
[02:43:57] <jmkasunich> true
[02:44:27] <jepler> for some reason I want to write the sense of the button in the vcp file, not the hal file
[02:45:21] <jmkasunich> add a "active_state = 0" attribute to the button object in vcp?
[02:45:41] <jmkasunich> I dunno if you've looked at the vcp code much
[02:45:49] <jepler> not so far
[02:45:53] <jepler> I'm sure I'll pick it up
[02:46:10] <jmkasunich> I'm kind of embarassed about it - its this weird pseudo object oriented thing inplemented in C
[02:46:28] <jmkasunich> I remember someone saying something on IRC about doing the same thing only better with python
[02:46:33] <jmkasunich> and I have to wonder if they are right
[02:47:17] <jepler> was that me?
[02:47:22] <jmkasunich> don't recall
[02:47:42] <jmkasunich> it was a day or two ago, and I was reading back on IRC hours after it was actually said
[02:47:50] <jepler> oh -- I don't think I said that lately
[02:48:08] <cradek> we? said during fest that you were reinventing a subset of tk
[02:48:32] <jmkasunich> there is definitely some reinvention going on
[02:48:58] <jmkasunich> maybe that's why I haven't dove in and tried to finish it... cause I know its not really the right way to attack the problem
[02:49:08] <jmkasunich> (or maybe I've just been lazy)
[02:50:09] <jmkasunich> btw jepler, a _really_ small example would just have a buton and a LED connected to each other
[02:50:16] <jmkasunich> no emc at all
[02:50:23] <jepler> maybe so
[02:50:31] <jepler> uh oh my laptop is about dead
[02:50:51] <jmkasunich> are you at the coffeeshop?
[02:50:56] <jepler> yep
[02:51:24] <jmkasunich> guess its time to listen to poetry instead
[02:51:36] <jepler> they're done, thankfully
[02:51:37] <cradek> no, it's over, which is ok by me
[02:52:37] <cradek> just like music, it would be better if they didn't use amplification to make it overpoweringly loud
[02:52:55] <jmkasunich> thats the "slam" part
[02:53:04] <cradek> oh I didn't understand that
[02:54:12] <jepler> the docs say this:
[02:54:13] <jepler> To add a simple external button you need to replace the line:
[02:54:13] <jepler> linkpp iocontrol.0.user-enable-out \
[02:54:13] <jepler> iocontrol.0.emc-enable-in
[02:54:13] <jepler> with
[02:54:14] <jepler> linkpp parport.0.pin-01-in iocontrol.0.emc-enable-in
[02:54:21] <jepler> does halcmd actually support unix-style continuation lines?
[02:54:39] <jmkasunich> lemme check
[02:54:48] <jepler> I suppose I could have checked as well
[02:54:57] <jepler> looks like "no"
[02:55:13] <jmkasunich> where does it say that?
[02:55:20] <jmkasunich> (the line with the \ )
[02:55:24] <jepler> config/stepper.lyx
[02:55:59] <jmkasunich> oh
[02:56:10] <jmkasunich> (I got confused, thought we were still talking about halvcp)
[02:56:39] <jepler> no no
[02:56:47] <jmkasunich> I think the \ was used because the entire command wouldn't fit on one line in the document
[02:57:43] <jepler> probably but that is confusing
[02:57:46] <jmkasunich> yeah
[02:58:01] <jepler> they seem to fit fine when I do a dvi preview
[02:58:29] <jmkasunich> take it out, export the pdf, and see how it looks - maybe its fine
[03:02:13] <jepler> seems fine
[03:18:36] <jmkasunich> heh - a tiny vcp is really tiny
[03:18:45] <jmkasunich> a button with no text inside, and an led
[03:18:58] <jmkasunich> makes a window so small you can't see any of the title bar buttons
[03:24:55] <jmkasunich> I wonder if halvcp should use <shudder> XML ?
[03:25:57] <jmkasunich> the {} tend to get nested very deeply - I guess thats why XML uses <foo> and </foo> (or something like that) - it helps matching up opening and closing brackets
[03:30:46] <jmkasunich> jepler: still there? I see you used the term "key" for the "name = value" items in vcp
[03:31:03] <jmkasunich> is that a convention? or did you just make it up?
[03:31:24] <jmkasunich> I've called them attributes, but if there is a preferred term I'll use it
[03:58:44] <jepler> jmkasunich: I just made it up
[03:59:24] <jepler> "key" and "value" are a pythonism .. in a dictionary, {'a': 3}, 'a' is a key and 3 is a value
[03:59:52] <jmkasunich> how do you feel about using "attribute" and "value" ?
[04:00:25] <jepler> sounds fine to me
[04:00:44] <jmkasunich> I think thats what I'm gonna do
[04:00:51] <jmkasunich> but I won't get far tonight
[04:01:11] <jmkasunich> I'm putting another very simple sample in there, complete with screenshot
[04:01:17] <jmkasunich> then I think I'm gonna call it a night
[04:01:20] <jepler> 'night
[04:01:21] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/htl2.py
[04:01:30] <jepler> here's a basic vcp-like program in Python
[04:01:52] <jepler> the "short sample" is the last 5 lines after 'if __name__ == '__main__':'
[04:02:08] <jepler> it has 'toggle' and 'led' only
[04:02:36] <jmkasunich> so the first part is the implementation, equivalent to the halvcp binary, and the last part is equivalent to the .vcp file?
[04:02:49] <jepler> yes
[04:03:11] <jmkasunich> is it practical to split the two?
[04:03:38] <jepler> yes
[04:03:57] <jmkasunich> interesting
[04:04:27] <jmkasunich> I wonder how hard it will be to explain to a non-programmer type the syntax used there, vs. the syntax used by halvcp?
[04:04:27] <jepler> if this was saved in 'vcp.py' then the user would write 'import vcp' as the first line, 'a = vcp.PanelApp("panel")' in the second line, and then the last 5 lines would be the same as in the htl2.py file
[04:05:55] <jepler> the vcp syntax is probably easier
[04:06:03] <jmkasunich> thats what I was thinking
[04:06:41] <jmkasunich> some vcp error messages are less than helpfull, but since we control that we can improve them
[04:06:57] <jepler> goodnight
[04:07:01] <jepler> I'm off too
[04:07:07] <jmkasunich> I imagine that python error messages would be very non-helpfull to someone who doesn't know the language
[04:07:10] <jmkasunich> ok, goodnight
[10:24:53] <alex_joni> [dinero]$ uptime
[10:24:53] <alex_joni> 02:24:31 up 6 min, 2 users, load average: 0.67, 0.52, 0.21
[15:31:36] <SWPadnos> heh - yep - it's back
[15:37:32] <skunkworks> ? :)
[15:38:02] <SWPadnos> apparently dinero.dreamhost.com died fora few minutes earlier today
[15:38:11] <SWPadnos> which happens to hose linuxcnc.org
[15:38:12] <SWPadnos> host
[15:38:17] <SWPadnos> well, in this case both ;)
[15:39:11] <skunkworks> funny
[15:46:27] <alex_joni> SWPadnos: dinero came back pretty quick
[15:46:37] <alex_joni> the wiki.linuxcnc.org worked right away
[15:46:45] <alex_joni> but the www. didn't for quite some time (1-2h I think)
[15:48:12] <SWPadnos> strange
[15:48:34] <SWPadnos> since the wiki is a subdir under the www root
[15:49:40] <SWPadnos> a power sag did it. http://www.dreamhoststatus.com/
[15:50:02] <alex_joni> SWPadnos: I know that's why I thought it's strange
[15:50:11] <alex_joni> and they share DNS & everything else too
[15:50:22] <SWPadnos> yeah, and you need CGI/perl to work for the wiki
[15:50:27] <SWPadnos> actually, that's probably it
[15:50:36] <SWPadnos> you need mysql for the root, because of joomla
[15:50:54] <SWPadnos> the database servers probably took longer to bring up
[15:51:33] <alex_joni> right.. might be
[15:51:55] <alex_joni> although I would have expected pages with error messages "can't connect to mysql"..
[15:51:59] <SWPadnos> true
[15:52:10] <alex_joni> http://www.dreamhoststatus.com/2006/11/06/ike-is-dying-slowly/ haha
[15:52:28] <SWPadnos> heh
[16:27:11] <christel> [Global Notice] Hi all, just a quick note to let you know I will be doing some quick rehubbing of our European servers in a moment. It should all be quick and painfree. Please hang in there while we jump and thank you for using freenode!
[21:04:48] <Lerneaen_Hydra__> Lerneaen_Hydra__ is now known as Lerneaen_Hydra
[22:29:54] <SWPadnos> hmmm - is there a way of getting more than one bit out of a conv_<whatever> component?
[22:30:14] <SWPadnos> ie, a conv_u8_bit should be able to export up to 8 output bits
[22:30:31] <jepler> that's a different component than the one I wrote
[22:30:38] <SWPadnos> heh
[22:30:51] <SWPadnos> ok. I guess that's the component I'll write then :)
[22:31:11] <alex_joni> guess jepler
[22:31:11] <alex_joni> guess jepler's is a caster not a converter
[22:31:11] <SWPadnos> yep
[22:31:25] <alex_joni> seems perfectly fine to me ;)
[22:31:36] <alex_joni> although a demux is needed if not present :)
[22:31:38] <SWPadnos> yep
[22:32:14] <SWPadnos> demux is one, but "bit-pattern" is another
[22:32:42] <SWPadnos> I must say - command-line completion of module names really kicks ass
[22:32:48] <SWPadnos> thanks again jepler
[22:33:17] <alex_joni> it sure does
[22:33:43] <alex_joni> but I especially like (and I found out recently) that you can do tab-completion on the ./configure parameters
[22:34:19] <SWPadnos> I couldn't do that - what do you suppose is needed?
[22:34:44] <alex_joni> dapper
[22:34:50] <SWPadnos> well, I have that
[22:35:00] <alex_joni> then I don't know :)
[22:35:03] <SWPadnos> heh
[22:35:07] <alex_joni> try running autoconf
[22:35:13] <alex_joni> maybe it does something funny ;)
[22:35:26] <SWPadnos> just to be sure, if I type ./configure --enable<tab><tab>, I should get a list of enable-able options, right?
[22:35:47] <jepler> I had to type 3 <TAB>s
[22:35:47] <alex_joni> don't think that list works
[22:35:51] <jepler> the first one added "-"
[22:36:00] <SWPadnos> ah, ok.
[22:36:02] <alex_joni> but I put --enable-r<tab><tab> and got run-in-place
[22:36:33] <SWPadnos> well, it certainly doesn't work for me
[22:36:48] <alex_joni> SWPadnos: try autoconf
[22:36:50] <SWPadnos> ./configure --e<many tabs> gives me a bunch of beeps, and nothing else
[22:36:57] <jepler> do you have the "bash-completion" package installed?
[22:37:02] <SWPadnos> I may not
[22:37:07] <jepler> er, I guess it's not a separate package anymore -- it was in breezy
[22:37:10] <alex_joni> jepler: I think that's in by default
[22:37:37] <alex_joni> SWPadnos: humor me.. run autoconf once
[22:37:46] <alex_joni> it only regenerates configure from configure.in
[22:38:16] <SWPadnos> one sec
[22:38:45] <SWPadnos> any specific options for autoconf?
[22:38:48] <alex_joni> no
[22:38:58] <SWPadnos> ok, then it didn't work :)
[22:39:12] <alex_joni> it doesn't say anything.. just returns
[22:39:12] <jepler> do you have the file /etc/bash_completion?
[22:39:15] <SWPadnos> or should I remove ./configure first
[22:39:36] <alex_joni> SWPadnos: you shouldn't remove anything
[22:39:47] <alex_joni> if it doesn't error out, then it's OK
[22:40:18] <SWPadnos> ok - autoconf just returned as expected, I had deleted nothing, completion still didn't work
[22:40:25] <jepler> do you have the file /etc/bash_completion?
[22:40:33] <SWPadnos> yes, I have /etc/bash_completion and /etc/bash_completion.d/
[22:40:38] <jepler> run in the shell: . /etc/bash_completion
[22:40:41] <jepler> and see if it works now
[22:40:46] <SWPadnos> ok
[22:41:03] <SWPadnos> yep -that does it
[22:41:11] <SWPadnos> I'll add it to bash_profile
[22:41:16] <SWPadnos> or whatever :)
[22:42:15] <SWPadnos> interesting. there's a section of /etc/bash.bashrc for loading bash_completion, but it was commented out
[23:06:42] <SWPadnos> so, I was thinking of making a "polymorphic" component for the <int-type>-to-<N-bits or one-of-N> HAL components
[23:07:12] <SWPadnos> do you think it would be too conf\using to specify input types as numbers, and use one less bit to indicate signed numbers?
[23:08:07] <SWPadnos> ie, use a 31 for an S32 input, or 32 for a U32 input
[23:08:44] <SWPadnos> the other option being a config string with s32/u32 ...