#emc-devel | Logs for 2006-05-02

Back
[01:57:38] <jmkasunich> hmm, didn't realize I don't know how to spell sillyscope
[01:59:46] <SWPadnos> heh
[02:01:03] <jmkasunich> dunno whats worse, that I mis-spelled it, or that it took 1-1/2 years for anybody to notice ;-)
[02:01:22] <SWPadnos> well, I noticed a long time ago, but never got around to fixing it :)
[02:01:43] <SWPadnos> it's not exactly the most pressing problem
[02:04:43] <SWPadnos> actually, I had a couple of questions for you earlier, when I was going through Hal_Introduction
[02:05:10] <jmkasunich> shoot
[02:05:16] <jmkasunich> (I'm about to start editing on it)
[02:05:49] <jmkasunich> arg, I guess I had some uncommitted edits, got conflicts now
[02:06:03] <SWPadnos> ok. first, should I change the canonical naming scheme back to module.index.function.index.name, rather than the one with dashes
[02:06:07] <SWPadnos> oops
[02:06:17] <jmkasunich> heh, thats one of the uncommitted edits
[02:06:27] <SWPadnos> ok ;)
[02:06:56] <jmkasunich> lemme see how bad the conflicts are, then commit what I have here
[02:07:34] <SWPadnos> ah - the other one was jus twondering if you had left .tmax and .time out of the siggen example on purpose
[02:07:45] <jmkasunich> yes and no
[02:07:57] <jmkasunich> back when I wrote the example, the time params weren't there
[02:08:01] <SWPadnos> there was a note about thread execution times
[02:08:14] <SWPadnos> right - I figured that was the root cause
[02:08:23] <jmkasunich> now they are, but I figured in a tutorial I didn't want to go into it
[02:08:42] <SWPadnos> no. I added them, so the examples would look the same as a person would see when typing in the code
[02:08:55] <SWPadnos> err - following along. you know
[02:09:02] <jmkasunich> yeah
[02:09:07] <jmkasunich> I was undecided
[02:09:15] <jmkasunich> thats fine
[02:09:34] <SWPadnos> I also noticed a number of places where siggen / freqgen were kind of mixed up
[02:09:54] <SWPadnos> I think I fixed some of those
[02:10:07] <SWPadnos> hopefully they're fixed, not "fixed"
[02:15:52] <jmkasunich> ok, my changes and yours are synced now
[02:16:05] <jmkasunich> (you were right about that -all thing, I deleted the paragraph)
[02:16:25] <SWPadnos> which one?
[02:16:50] <SWPadnos> I don't remember an -all thing
[02:17:00] <jmkasunich> stg drivers, there was a paragraph at the end of the function listing talking about slot specific vs -all functions and not to use both at the same time
[02:17:07] <SWPadnos> ah
[02:18:06] <SWPadnos> I don't know if you noticed, but the halconfig name parsing problem wasn't a name parsing problem after all
[02:18:18] <jmkasunich> what was it?
[02:18:34] <SWPadnos> it boiled down to re-use of ini vars for more than one thing
[02:18:47] <SWPadnos> in ppmc, INPUT_SCALE is used for both encoder and stepgen scaling
[02:19:06] <SWPadnos> but there's a 1:1 mapping between ini vars and hal params in halconfig
[02:19:24] <jmkasunich> ah
[02:19:37] <SWPadnos> there needs to be a list of params to set when a particular ini var is changed
[02:19:55] <jmkasunich> yeah, assuming only 1 is incorrect
[02:20:26] <SWPadnos> yup. what a wild goose chase the name thing was though
[02:20:41] <jmkasunich> was that halconfig or emccalib?
[02:20:48] <SWPadnos> halconfig
[02:20:57] <SWPadnos> ray also changed emccalib to ignore comment lines though
[02:21:00] <jmkasunich> I thought emccalib was the one that tuned hal params then updated the ini to match
[02:21:39] <rayh> calib does but so does halconfig.
[02:21:45] <jmkasunich> so halcomfig is even more emc specific than I thought
[02:21:59] <SWPadnos> that was the other thing I noticed
[02:22:03] <rayh> these days yes.
[02:22:25] <SWPadnos> there are a bunch of things in HAL that have defaults that are suspiciously emc-like, and inconsistent
[02:22:43] <SWPadnos> for instance, stepgen defaults to 3 type 0 stepgens
[02:22:50] <rayh> IMO the only way to make the picker show properly is to use yview.
[02:23:04] <rayh> and make a listing of all lines in the tree.
[02:23:08] <jmkasunich> thats non-trivial isn't it?
[02:23:18] <rayh> then deltax from the top.
[02:23:24] <jmkasunich> gotta count all of them, figure out where the one you want is, and divide
[02:23:33] <rayh> Yep.
[02:23:42] <jmkasunich> seems like thats what see should be doing under the hoot
[02:23:43] <jmkasunich> hood
[02:23:53] <rayh> you'd think so.
[02:23:56] <jmkasunich> but its buggy
[02:24:10] <jmkasunich> it always shows the line immediately following the selected one
[02:29:12] <rayh> a cheap alternative would be to add a label below the tree with he value of inifile.
[02:30:46] <jmkasunich> where does the bwidget code live?
[02:32:04] <rayh> /lib/bwidget/tree
[02:32:43] <rayh> nope
[02:33:25] <jmkasunich> /usr/lib/bwidget-1.7.0/tree.tcl
[02:33:27] <rayh> /usr/lib/bwidget1.7.0
[02:33:30] <SWPadnos> out of curiosity, were [incr tk] and tix eliminated for technical reasons, or was bwidget just the first tree found with the right capabilities?
[02:33:50] <rayh> bwidget was a part of AXIS
[02:34:16] <SWPadnos> ok, so one less dependency
[02:34:25] <SWPadnos> extra dependency, that is
[02:34:59] <rayh> When I started the tree thing bwidget was included in the axis package
[02:35:11] <jmkasunich> the code for tree::see (and tree::_see which it calls) isn't that big
[02:35:12] <rayh> it since became a dependency.
[02:35:40] <jmkasunich> but its greek to me
[02:35:43] <SWPadnos> right - using it eliminates the need for yet another dependency
[02:39:09] <jmkasunich> heh, fixed it ;-)
[02:39:21] <jmkasunich> but had to hack bwidget to do it :-(
[02:39:25] <SWPadnos> what was the problem?
[02:39:29] <SWPadnos> s/was/is/
[02:39:45] <jmkasunich> if { $y < $yv0 } {
[02:39:45] <jmkasunich> $path.c yview scroll [expr {$y-$yv0}] units
[02:39:45] <jmkasunich> } elseif { $y >= $yv1 } {
[02:39:45] <jmkasunich> $path.c yview scroll [expr {$y-$yv1+1}] units
[02:39:45] <jmkasunich> }
[02:39:54] <jmkasunich> lose the +1 in the last line, and it works
[02:40:10] <jmkasunich> at least for the cases I tested
[02:40:58] <jmkasunich> classic off-by-1 error
[02:41:15] <jmkasunich> I wonder if it should be reported to the bwidget folks?
[02:41:30] <jepler> jmkasunich: I think bwidget development is pretty dead
[02:41:33] <jmkasunich> if it needed a +1 and didn't have it, I'd be more inclined to think it was a bug
[02:41:36] <jepler> but then I think that about Tk too
[02:42:14] <jepler> jmkasunich: on their sf project page I recently submitted a patch to improve absymal performance of the ListBox with 1000s of items .. so far it's been ignored.
[02:42:16] <SWPadnos> what happens if you try to scroll 0 units?
[02:43:10] <jmkasunich> SWP: massive explosion? I dunno, I don't know squat about tcl, I just saw a +1 and knew I was looking for an off by 1 error on Y
[02:43:15] <SWPadnos> I suspect that another fix would be to change the >= to >: elseif {$y > $yv1 }
[02:43:15] <jmkasunich> so I tried it ;-)
[02:43:23] <SWPadnos> heh
[02:43:31] <rayh> Well I can fix tree but
[02:43:41] <jmkasunich> but that doesn't help the users
[02:43:53] <jmkasunich> and apparently submitting a patch won't either
[02:44:06] <rayh> Unless we included the code in our distro.
[02:44:29] <jmkasunich> I'll let you tcl guys decide if thats a good idea
[02:44:41] <rayh> line 929 Tree::_see $path [expr $idn -2]
[02:44:42] <jmkasunich> you really could just copy their see and _see code
[02:44:45] <SWPadnos> we can patch bwidget as part of the make
[02:45:04] <jmkasunich> SWP: gets hairy if they don't all have the same version
[02:45:16] <jepler> if you include a copy of bwidget in emc2, please make sure it's complete enough that axis can use it too
[02:45:22] <rayh> IMO we could include the code in pickconfig.
[02:45:23] <SWPadnos> can't you require bwidget=1.7.0 or something like that?
[02:45:30] <rayh> for just that namespace.
[02:45:35] <jepler> SWPadnos: I think that's what it does now (at least, that's what axis does)
[02:45:52] <SWPadnos> is that a >= or an == check?
[02:46:03] <jepler> src/axis-1.3maint/lib/nf.py: r.tk.call("package", "require", "BWidget", "1.7")
[02:46:27] <jepler> you'd have to read the manpage for "package"; it's got lots of words
[02:46:34] <jepler> there's a "require -exact" that I didn't use
[02:46:42] <SWPadnos> ok
[02:50:36] <SWPadnos> jmkasunich, maybe the two contradictory and obsolete footnotes to the halcmd section should be removed
[02:51:07] <cradek> I think we should leave the .emcrc stuff out for now unless there's a simple solution to this
[02:51:27] <jmkasunich> SWP which two?
[02:51:47] <SWPadnos> 4 and 5. the ones about halcmd not being able to load modules, then the update that says it is
[02:51:51] <jmkasunich> duh, found em
[02:52:21] <jmkasunich> actually, _if_ the components were orginally loaded with loadrt, the args are now saved
[02:52:31] <jmkasunich> you're right, both can go away
[02:52:42] <jmkasunich> and the paragraph might want a minor tweak or too
[02:52:43] <SWPadnos> right - the parameters were the reason I didn't rip them out before
[02:53:01] <jmkasunich> feel free to edit in that area, I'm working several chapters up, no risk of conflicts
[02:53:09] <SWPadnos> ok
[02:53:23] <jmkasunich> btw, I appreciate the help
[02:53:29] <SWPadnos> sure
[02:53:42] <SWPadnos> need to get the docs all tidy for release
[02:53:54] <SWPadnos> I did notice some component defaults that are inconsistent with each other
[02:54:10] <SWPadnos> like stepgen defaulting to 3 stepgens, pid defaults to one pid, ...
[02:54:15] <jmkasunich> yeah
[02:54:27] <SWPadnos> it seems to me that everything should default to one "thing"
[02:54:30] <jmkasunich> I think for the release lets not mess with it
[02:54:34] <SWPadnos> makes sense
[02:54:41] <jmkasunich> just in case somebody is relying on the defaults
[02:54:49] <SWPadnos> like all the ini/hal files?
[02:54:50] <jmkasunich> but for 2.1, we definitely want to clean everything up
[02:57:51] <cradek> what about the 2.0 testing release I wanted to make tonight, are we going to wait until tomorrow?
[02:57:56] <jmkasunich> something tells me starting with the ax5214 driver and working my way thru the list isn't the best way to do these edits
[02:58:13] <SWPadnos> heh
[02:58:25] <jmkasunich> I guess I/we need to prioritize
[02:58:32] <jmkasunich> what changes need made for tonight?
[02:58:38] <cradek> I have no idea
[02:58:41] <cradek> my bugfix is done
[02:58:58] <jmkasunich> the module param bugfix is done
[02:58:59] <cradek> I want to get it to dave-e because he's doing real work and testing
[02:59:26] <jmkasunich> I have the ax5214 half done, don't want to ship it that way
[02:59:33] <jmkasunich> let me finish it, maybe 30-45 mins
[02:59:53] <cradek> I can sure do it in the morning
[03:00:11] <cradek> I don't want to be up all night, and you probably shouldn't either after last night :-)
[03:00:18] <jmkasunich> no
[03:00:31] <cradek> maybe we should shoot for tomorrow late
[03:00:46] <jmkasunich> well, after the ax5214 I dunno what is next
[03:00:51] <SWPadnos> shall I add canonical interfaces for analog in / out?
[03:00:53] <jmkasunich> so might as well release at that point
[03:01:00] <jmkasunich> SWP: sure
[03:01:17] <jmkasunich> I'm in chapter 5, so go to town anywhere else
[03:01:17] <SWPadnos> ok. scale / offset params, and in/out pins. anything else?
[03:01:40] <SWPadnos> enable maybe?
[03:01:42] <jmkasunich> don't think so... limits are implicit usually
[03:01:46] <jmkasunich> oh, good point
[03:01:57] <jmkasunich> enable = false, outputs = zero volts
[03:02:19] <rayh> Try pickconfig now.
[03:02:21] <rayh> in head.
[03:02:24] <cradek> trying
[03:04:00] <cradek> can't use empty string as operand of "/"
[03:04:00] <cradek> can't use empty string as operand of "/"
[03:04:00] <cradek> while executing
[03:04:00] <cradek> "expr {int([lindex [$path.c coords $idn] 1]/$dy)}"
[03:04:00] <cradek> (procedure "Tree::_see" line 10)
[03:04:00] <jmkasunich> seems good
[03:04:07] <SWPadnos> enable should be optional, I guess
[03:04:13] <SWPadnos> or at least allowed to be grouped
[03:04:25] <jmkasunich> leave it out for now
[03:04:38] <cradek> rayh: ^^^
[03:04:43] <SWPadnos> ok
[03:04:55] <jmkasunich> the canonicals aren't really gonna be followed until 2.1 anyway (unfortunatley)
[03:04:56] <rayh> Your list of configs is to short.
[03:05:09] <jmkasunich> lol
[03:05:10] <SWPadnos> one sec - I have a big list ;)
[03:05:12] <rayh> let me add a catch.
[03:05:21] <jmkasunich> I have a big list, and it worked here
[03:05:29] <cradek> no that's not it
[03:05:36] <jmkasunich> did vti (last one) sim/axis (near the top) and a couple near the middle
[03:05:43] <cradek> remove your .emcrc, start emc, hit downarrow
[03:05:53] <jmkasunich> ah, didn't try that
[03:06:21] <jmkasunich> * jmkasunich shuts up and types lyx
[03:06:25] <cradek> I think arrowing to a non-config (a directory) is broken
[03:07:38] <cradek> rayh: do you want the whole backtrace?
[03:07:49] <jmkasunich> you made the change in see, not _see?
[03:10:04] <rayh> I don't quite understand what you are saying.
[03:10:16] <cradek> me?
[03:10:33] <jmkasunich> Tree::see calls Tree::_see, and all the x and y math (and the +1 I removed) is in _see
[03:11:08] <jmkasunich> it looks like the only code you copied into pickconfig is Tree::see, so you're still calling the old _see
[03:11:19] <jmkasunich> (unless I'm missing something, which is quite possible)
[03:12:16] <SWPadnos> he subtracts 2 from the $idn value for ::_see
[03:12:37] <jmkasunich> ok
[03:12:40] <jmkasunich> * jmkasunich shuts up and types lyx
[03:12:44] <jmkasunich> ;-)
[03:12:48] <SWPadnos> heh
[03:13:00] <rayh> all I'm trying to do is change the args sent
[03:13:26] <cradek> it seems to work fine now except for the blowup when you arrow to a directory
[03:13:33] <rayh> I added an if $idn < 2 then do it the old way.
[03:13:34] <SWPadnos> hmm - analog inputs should have a "raw counts" parameter/pin
[03:13:40] <rayh> want to try it?
[03:13:44] <jmkasunich> SWP: why?
[03:13:50] <SWPadnos> debugging?
[03:14:04] <jmkasunich> maybe
[03:14:08] <cradek> I don't know what $idn is but I'll test it
[03:14:10] <SWPadnos> actually, a resolution param would make sense
[03:14:11] <jmkasunich> but only when debugging the driver
[03:14:22] <cradek> assuming you're talking to me, I'm so lost
[03:14:24] <SWPadnos> ie, the size of 1 bit
[03:14:28] <jmkasunich> yeah
[03:15:15] <SWPadnos> and probably range parameters as well: min and max
[03:18:06] <rayh> There is an interesting command in this proc to find the index.
[03:18:31] <rayh> wire is darn slow tonight.
[03:19:47] <SWPadnos> *that* was the other question
[03:19:53] <SWPadnos> jmk - what were you thinking?
[03:20:02] <jmkasunich> ?
[03:20:17] <jmkasunich> oh, min and max on dac/adc?
[03:20:24] <SWPadnos> when you removed axis.n.index-pulse-in, and added axis.n.index-enable?
[03:20:32] <SWPadnos> heh ;)
[03:20:40] <jmkasunich> index-enable is bidirectional
[03:20:59] <SWPadnos> in motmod?
[03:21:07] <jmkasunich> thats how motmod tells the encoder "reset on the next index" and the encoder says "ok, index arrived"
[03:21:22] <SWPadnos> ok, so all the configs should be changed to use the new name
[03:21:56] <jmkasunich> well, only configs that either use a spindle encoder for threading or home to an index pulse care about that
[03:21:58] <rayh> cradek, Try the picker again for me.
[03:22:09] <jmkasunich> so "all" is pretty small
[03:22:21] <cradek> ok
[03:22:22] <SWPadnos> univstep has it connected by default
[03:22:31] <SWPadnos> I think m5i20 does as well
[03:22:38] <rayh> m5i20 also has it.
[03:22:42] <jmkasunich> more importantly, as far as I know, only the software encoder driver implements index-enable
[03:22:59] <cradek> rayh: same error
[03:23:08] <jmkasunich> ray doesn't get the error?
[03:23:24] <rayh> How many configs do you show.
[03:23:29] <cradek> you just have to use up/down arrows
[03:23:48] <jmkasunich> and remove emcrc?
[03:23:48] <cradek> all the samples from my cvs head rip
[03:23:49] <SWPadnos> Error: can't use empty string as operand of "/"
[03:23:55] <SWPadnos> that's the one?
[03:23:55] <rayh> you an native american?
[03:24:03] <cradek> no you don't have to rm emcrc
[03:25:59] <jmkasunich> cradek: I can arrow up and down, it errors when I get to the very top
[03:26:18] <cradek> yeah maybe it's because it's the top; I only have one directory
[03:26:34] <jmkasunich> it also doesn't properly display at the bottom
[03:26:53] <SWPadnos> I justq noticed that
[03:27:05] <jmkasunich> I can down arrow three steps below the window before it starts to scroll
[03:27:18] <jmkasunich> this kind of thing is why we use stuff like bwidget
[03:27:24] <jmkasunich> it really sucks to be re-inventing it
[03:28:00] <SWPadnos> I can only get one below, and that one is still partly visible
[03:29:59] <jmkasunich> hey guys, lets back up a minute
[03:30:09] <jmkasunich> here we are trying to fix a bwidget bug
[03:30:33] <jmkasunich> the code we're fixing is non-trivial and testing our fix _completely_ is non-trivial
[03:30:45] <jmkasunich> do we really want to put it in the release?
[03:30:59] <cradek> good point
[03:31:15] <SWPadnos> I'd say that testing isn't that hard. maybe 20 cases max
[03:31:31] <rayh> What a goofy bastard lib that is. Try another fix.
[03:32:08] <SWPadnos> I can fix the key navigation problem, but I think I end up with the original problem, which is that the hilighted config doesn't start visible
[03:33:04] <rayh> fuck yes we want to put it in the release
[03:33:50] <SWPadnos> is it possible to change the border so it doesn't make you think you can resize the window?
[03:34:06] <SWPadnos> or the cursor over the borders
[03:34:50] <rayh> what border. I don't get any resize icons.
[03:35:06] <jmkasunich> what does that have to do with the bug?
[03:35:23] <cradek> goodnight guys
[03:35:26] <SWPadnos> nothing - just tried to resize and thought I'd mention it
[03:35:33] <SWPadnos> this could be an artifact of CygWin
[03:35:38] <SWPadnos> night cradek
[03:35:49] <jmkasunich> goodnight Chris
[03:35:49] <rayh> night all.
[03:36:19] <SWPadnos> night Ray
[03:36:22] <rayh> I believe that pickconfig does not cause arrow problems.
[03:36:49] <jmkasunich> rayh: it happens for me
[03:36:58] <rayh> on the latest.
[03:37:01] <SWPadnos> changing $idn-2 to $idn-1, or the change to if $idn?4 should get rid of the key navigation problems
[03:37:09] <jmkasunich> stand by, let me update
[03:37:31] <cradek> the error is gone now but the cursor still goes off bottom of the list
[03:37:35] <rayh> the second line is numbered 4 in ixx
[03:37:44] <SWPadnos> weird
[03:37:56] <rayh> and that bothers you?
[03:38:17] <jmkasunich> cursor off the bottom? heck yeah
[03:38:30] <jmkasunich> I've highlighted something, but I can't see it
[03:38:31] <cradek> it's broken because it is printing extra numbers now
[03:38:52] <rayh> Okay revert to a previous version in head and I'l not try any more.
[03:38:53] <cradek> Machine configuration directory is '25 28 25 22 19 16 13 10 7 4 2 4 2 4 7 10 13 16 19 22 25 28 30 33 36 39 42 45 51 54 56 59 65 68 71 74 71 68 71 74 71 68 71 74 71 68 71 74 71 68 65 59 56 54 51 45 42 39 36 33 30 28 25 22 19 16 13 10 7 4 2 4 7 10 7 4 2 4 2 4 7 10 13 16 19 22 25 28 30 33 36 39 36 33 /home/chris/src/emc2/configs/sim/'
[03:39:01] <jmkasunich> lol
[03:39:09] <rayh> something about pookie in the alcoli comes to mind.
[03:39:19] <jmkasunich> rayh: there is nothing wrong with trying all you want in head
[03:39:24] <jmkasunich> fsck
[03:39:34] <cradek> I have no idea what that means
[03:39:34] <jmkasunich> grrrr
[03:40:05] <jmkasunich> rayh: there is nothing wrong with trying all you want in head
[03:40:21] <rayh> before we make this release, I'd like to remove all of the references to halconfig as well
[03:40:23] <SWPadnos> that was a short night's sleep ;)
[03:40:44] <rayh> I'll teach my class my way and add my stuff to the systems they use.
[03:41:34] <cradek> are you storming off because we helped you test this code and reported the problems? I don't get it.
[03:43:59] <cradek> goodnight guys, for real, it's late.
[03:44:12] <SWPadnos> nighty night.
[03:44:18] <SWPadnos> damn - it is late
[03:46:36] <rayh> nope just getting rid of some of the stuff I don't like.
[03:47:56] <rayh> Okay that should put v2 in the clear as far as most attempts to tillie it.
[03:56:00] <SWPadnos> SWPadnos is now known as SWP_Away
[13:14:03] <SWP_Away> SWP_Away is now known as SWPadnos
[13:28:19] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[14:05:57] <rayh> rayh@rayu:~/emc/emc2-test-may2$ scripts/emc
[14:05:58] <rayh> EMC2 - Prerelease CVS HEAD
[14:05:58] <rayh> Machine configuration directory is '16 /home/rayh/emc/emc2-test-may2/configs/stepper/'
[14:05:58] <rayh> Machine configuration file is 'stepper_inch.ini'
[14:05:58] <rayh> scripts/emc: line 151: [: 16: binary operator expected
[14:06:17] <rayh> I don't seem to be able to make HEAD work this morning.
[14:06:29] <cradek> that's the extra numbers I mentioned last night, I think it's debug output
[14:06:36] <cradek> see the 16?
[14:07:10] <rayh> okay let me look.
[14:07:39] <SWPadnos> hmmm. I got this one time last night (when cursoring around a lot):
[14:07:42] <SWPadnos> Machine configuration file is '4 7 10 13 16 19 22 25 28 31 33 36 39 42 45 48 54 57 59 62 68 71 74 77 7477 74 77 77 74 71 68 62 59 57 54 48 45 42 39 36 33 31 28 25 22 19 16 13 10 7 4 2 4 2 4 2 4 7 10 13 16 19 22 25 28 31 33 36 39 42 39 36 33 31 33 31 28 25 22 19 16 13 10 7 4 2 4 7 10 13 16 19 22 25 28 31 33 3639 42 45 48 54 57 59 62 68 71 74 77 74 77 74 77 74 77 74 77 74 77 74 77 74 71 68 62...
[14:07:44] <SWPadnos> EMC2 - Prerelease CVS HEAD
[14:07:45] <SWPadnos> sed: -e expression #1, char 3: unterminated `s' command
[14:07:47] <SWPadnos> Machine configuration directory is ''
[14:07:49] <SWPadnos> ...59 57 54 48 45 42 39 36 33 31 28 25 22 19 16 13 10 7 4 2'
[14:07:50] <SWPadnos> scripts/emc: line 151: [: too many arguments
[14:07:52] <SWPadnos> Starting emc...
[14:07:53] <SWPadnos> scripts/emc: line 439: /Project/emc2/bin/: is a directory
[14:07:55] <SWPadnos> scripts/emc: line 494: /Project/emc2/bin/: is a directory
[14:07:56] <SWPadnos> scripts/emc: line 579: /Project/emc2/bin/: is a directory
[14:07:58] <SWPadnos> Shutting down and cleaning up EMC...
[14:07:59] <SWPadnos> Cleanup done
[14:08:03] <cradek> gah
[14:08:12] <jepler> # Command Tree::see modified from bwidget-1.7.0
[14:08:14] <jepler> puts $idn
[14:08:20] <jepler> I bet just removing this line will fix it
[14:08:33] <jepler> talk to cradek sometime about how often I leave debugging prints in axis
[14:09:19] <jepler> somebody else has better check it in, though, I've got a screwed up copy of pickconfig.tcl locally..
[14:10:15] <rayh> yep.
[14:10:25] <rayh> as do I
[14:10:38] <jepler> I'll do it then
[14:10:41] <jepler> I can discard these changes
[14:11:06] <rayh> as far as I'm concerned you can revert to an earlier version.
[14:11:54] <SWPadnos> so the original issue was that the focused selection in the tree isn't alwayss fully visible?
[14:12:45] <rayh> right. if the list is large, the selection can be below
[14:13:02] <rayh> so we added the tree see command but that does not show stuff above.
[14:13:09] <SWPadnos> I'll bet it's a rounding issue in the calculation of how many lines are visible
[14:13:16] <cradek> here's what I saw: if I use the topmost configuration, and it saves it, when I restart the selected one is scrolled off the top
[14:13:42] <cradek> it is selected right (if I hit enter I get my config) but I just can't see it
[14:13:49] <rayh> yep.
[14:14:13] <SWPadnos> ok. with the current version, that doesn't happen to me, but I can select the partially visible bottom item, and it doesn't scroll
[14:14:13] <jepler> I suppose this is the wrong time to say that I think auto-selecting the last config is a great feature, and I'd love to see it in emc before 2.1.
[14:14:24] <rayh> The node numbering in Tree is not an interval thing.
[14:14:39] <SWPadnos> auto as in "if there's a previous selection, bypass the selector"?
[14:15:18] <jepler> no, the preselecting
[14:15:27] <cradek> I like it too
[14:15:27] <SWPadnos> ok. that's there now, isn't it?
[14:15:33] <SWPadnos> I like it as well
[14:15:53] <cradek> it's not in the release branch because we haven't worked out all the bugs
[14:15:59] <SWPadnos> ah
[14:16:23] <rayh> of course that would be a true saying for lots of other things as well.
[14:16:38] <SWPadnos> true enough
[14:17:16] <cradek> I should have said known bugs, I'm sure we'll never get all the bugs
[14:19:13] <jepler> with the current version of pickconfig, it works. If I pick the first item or the last item, it is visible and selected the next time I run pickconfig.
[14:19:16] <jepler> (HEAD)
[14:19:37] <SWPadnos> do you have enough configs to require scrolling?
[14:19:43] <jepler> yes, but only by two or three items
[14:19:49] <SWPadnos> ok - same as mine
[14:20:01] <cradek> last night we saw another problem: if you arrow down it doesn't scroll the bottom element onto the screen
[14:20:10] <cradek> do you get that?
[14:20:23] <jepler> yes
[14:20:38] <rayh> I see that tk8.5 has not added tree or notebook.
[14:20:46] <SWPadnos> that's what I'm getting now. things are correctly selected at startup, but arrowing down doesn't show the bottom item
[14:21:18] <SWPadnos> actaully, I can click on the partially visible bottom entry, and it doesn't get scrolled so it's fully visible
[14:21:19] <jepler> I'll look at it a little bit more and see what I can figure out
[14:21:24] <SWPadnos> it's not a key thing
[14:22:09] <rayh> last time I tried clicking the off the bottom thing it showed a README though.
[14:22:23] <SWPadnos> it's correctly selected, but not correctly shown
[14:22:55] <SWPadnos> what if we just make the window 3 pixels shorter? ;)
[14:23:06] <SWPadnos> * SWPadnos hides
[14:23:24] <rayh> * rayh is 3 pixels short.
[14:23:35] <SWPadnos> of a full deck? :)
[14:26:27] <rayh> I'm not certain I ever had a full deck.
[14:26:33] <SWPadnos> heh
[14:26:44] <rayh> I'll work on emccalib for a bit.
[14:27:15] <SWPadnos> is that in the menus, or does it need to be run manually?
[14:27:34] <rayh> It's in the menus.
[14:28:05] <SWPadnos> ok. I see it. the same ini issue as halconfig. bummer
[14:28:16] <SWPadnos> I think I have a way to fix that
[14:28:25] <SWPadnos> but I don't know how to implement it in tcl
[14:29:22] <SWPadnos> how is the mapping done between ini items and HAL params?
[14:34:53] <rayh> lappend commandarray($j) $thishalcommand
[14:34:53] <rayh> lappend valarray($j) $tmpval
[14:35:39] <rayh> You suggested array(inivarname) cmd
[14:35:46] <SWPadnos> or something like that
[14:36:31] <rayh> it would have to be array($axis $inivarname) {cmd1 cmd2 ...}
[14:36:53] <SWPadnos> essentially use a list (or array) instead of a single value for the hal param names associated with a particular ini var
[14:37:06] <rayh> right.
[14:37:14] <SWPadnos> yeah - something like that
[14:37:29] <SWPadnos> too bad I don't know the difference betwwen an array and a list in tcl :)
[14:38:16] <rayh> I have a difficult time understanding arrays in anything but very old basic.
[14:38:45] <SWPadnos> heh - I can do them in C quite nicely, and sometimes even in assembler
[14:38:55] <SWPadnos> it's these high level languages that get confusing
[14:40:27] <rayh> high level;)
[14:41:20] <SWPadnos> higher than asm at least
[14:42:05] <rayh> Where there was more than one halcmd to be done, the array value would have to be in {}.
[14:42:49] <SWPadnos> I'd just assume that there's more than one every time, and loop over the array in all cases
[14:42:56] <SWPadnos> most of the time, the loop will execute once
[14:43:17] <SWPadnos> is that foreach or some such?
[14:43:19] <rayh> perhaps jepler could help me convert {halcmd1 halcmd2} to a simple list like halcmd1 halcmd2?
[14:43:56] <rayh> The array stuff will return all as a single element rather than a list of elements.
[14:44:08] <SWPadnos> unless it's an array of lists
[14:45:09] <jepler> I think maybe the pickconfig scrolling problems are fixed now
[14:45:29] <rayh> so that the content of an array element is the name of a list?
[14:45:45] <SWPadnos> I think you can have lists of lists, and arrays of arrays in tcl
[14:46:02] <SWPadnos> they should be correctly handled, as long as you always use the correct array / list commands
[14:47:14] <rayh> SWPadnos, lapses into some language I don't understand.
[14:47:26] <SWPadnos> oops
[14:47:32] <SWPadnos> bork bork bork
[14:50:20] <SWPadnos> ok, what may need to be done is to make a list or array called $j-$lowername, and append $thishalcommand to that
[14:51:07] <SWPadnos> then stick that modified list back into the big list of commands
[14:51:24] <SWPadnos> but I'm not sure of the details
[14:51:49] <rayh> okay.
[14:52:25] <SWPadnos> it becomes a two-dimensional array, for the most part. the first dimension is the axis, the second is the inivar name
[14:52:40] <SWPadnos> each element in that 2-d array is a list of hal parameter names
[15:00:50] <rayh> in tcl an array is one dimensional but the arrayname can be as complex as you like.
[15:01:22] <SWPadnos> I think you can have multidimensional arrays
[15:01:34] <SWPadnos> $array(fred,ginger) should be valid
[15:03:59] <rayh> sure it is but that is a single arrayname
[15:04:41] <SWPadnos> hmm. that's not what my book says (tcl/tk in a nutshell)
[15:04:49] <rayh> and any changes from (fred,ginger) to (fred,pepper) is external
[15:05:48] <SWPadnos> though I guess it doesn't matter. either method gives you a unique element in the array
[15:06:16] <SWPadnos> so you can arrange the index names as you like, and use two variables to access them, just as though it was a 2D array
[15:09:09] <rayh> IMO the wall here is being able to get back and forth between a part of the element name and the value for the element.
[15:10:04] <SWPadnos> I think the element can be a list though
[15:10:10] <SWPadnos> ah - one sec
[15:10:13] <rayh> as long as I run the system from inivarname to halname I'm okay.
[15:10:35] <rayh> Sure as long as it is enclosed in {} so that it is a list of one.
[15:10:55] <rayh> Then you strip {} and foreach.
[15:11:06] <rayh> but it only works in the one direction.
[15:11:22] <rayh> there is no getting from halname to ininame.
[15:11:34] <SWPadnos> you should be able to have an array or list as the element in the array($varname-$j)
[15:11:43] <rayh> i guess I shouldn't say no way.
[15:12:31] <SWPadnos> ah - right. you would need another loop level to search for the halname
[15:13:01] <rayh> let me set up an array like you suggest.
[15:13:39] <SWPadnos> ok. sorry if I'm being confusing. I don;t think I quite understand how things are being done now, so it's hard to describe the differences between how it is, and how I think it could be
[15:13:40] <rayh> The steps become
[15:14:01] <rayh> 1 search each hal file for [A
[15:14:23] <rayh> split out the axis number
[15:16:30] <rayh> create the array element ($axis-number,$arrayname) and assign it the "setx yyy" part of the hal file line.
[15:19:38] <SWPadnos> hmmm
[15:20:45] <SWPadnos> how about: create the arary element, and lappend "setx yyy" to it
[15:25:40] <rayh> I don't have an issue with lappend until I try to extract each.
[15:26:35] <jepler> ./tcl/bin/pickconfig.tcl configs.reallylongname/
[15:26:35] <jepler> Error in startup script: .main.f1.f2.f3.tree selection set: Cannot select unknown node "/home/jepler/emc2/configs/univpwm/univpwm.ini".
[15:26:48] <SWPadnos> can't you then loop using llength and lindex?
[15:26:53] <jepler> here's another problem. If the "last ini" isn't in the tree, you get an error when pickconfig runs
[15:27:03] <rayh> it seems to me that we have axis, ininame, halcmd1, halcmd2, halcmdx, inivalue, halvalue
[15:27:32] <SWPadnos> yep
[15:27:57] <rayh> which we shorten with lappend to axis, ininame, halcmds, inivalue, halvalue.
[15:28:24] <SWPadnos> so an array $everything($axis,$ininame) which contains {inivalue halvalue {halcmd1 halcmd2 halcmdx} } should cover it
[15:28:30] <rayh> and construction of the data set is essentially random.
[15:29:07] <SWPadnos> that is annoying
[15:29:08] <rayh> sylopsic is should say. no hal writer is random.
[15:29:20] <SWPadnos> why can't people sort their ini files? ;)
[15:29:44] <rayh> yea right. run that one past jmk.
[15:29:48] <SWPadnos> heh
[15:30:01] <rayh> halcmd can produce a sorted list
[15:30:06] <rayh> but we can't use it.
[15:30:11] <SWPadnos> right
[15:30:27] <rayh> It runs fine since the motmod change
[15:31:35] <rayh> but we would have to find each of the halcmds and insert [AXIS_$axis] $ininame
[15:31:46] <rayh> in place of the value saved there.
[15:32:59] <SWPadnos> all that already works though. it's just manipulating a list of hal "objects" for each ini var that's the issue
[15:33:05] <SWPadnos> I think
[15:34:05] <rayh> the netlist output does not allow ini reads.
[15:34:27] <SWPadnos> ?
[15:34:39] <rayh> it is halcmd, halname, value
[15:34:44] <SWPadnos> you mean "halcmd save" doesn't output the ini vars?
[15:34:59] <SWPadnos> (I know that's true - I'm just wondering if that's what you were saying)
[15:35:09] <rayh> yes
[15:35:11] <SWPadnos> ok
[15:35:28] <rayh> once you create a netlist, you divorce those values from the ini.
[15:35:57] <SWPadnos> you only need the show / save output to get the value to write to the ini file, right?
[15:36:31] <rayh> i thought we were discussing the possibility of writing rational hal files for people.
[15:37:19] <rayh> I'll play with figuring out how to add instances of commands to the data structure in emcconfig.
[15:37:22] <rayh> bbl
[15:37:23] <SWPadnos> err - yes, but there's a problem
[15:37:37] <rayh> ?
[15:37:41] <SWPadnos> how does the user decide on the name of the ini var?
[15:37:56] <SWPadnos> I'm assuming that you're talking about building a HAL config more or less from scratch
[15:38:03] <SWPadnos> and making it "easy" to tune
[15:38:07] <rayh> The user didn't
[15:38:07] <SWPadnos> and human readable
[15:38:58] <SWPadnos> you're reading the ini to fiund .hal files, then reading the .hal files to find ini references, right?
[15:39:09] <rayh> No
[15:39:13] <SWPadnos> oh
[15:39:16] <rayh> reading hal to find ini references
[15:39:23] <rayh> files
[15:39:36] <rayh> cause some have 3 or more hal files.
[15:39:44] <rayh> and the stuff is scattered throughout.
[15:39:46] <SWPadnos> ok. I thought you got the list of hal files from the ini in the first place
[15:39:56] <rayh> oh you do.
[15:39:56] <SWPadnos> the HAL section
[15:39:58] <SWPadnos> ok
[15:39:58] <rayh> oh I do
[15:40:02] <SWPadnos> we do ;)
[15:40:27] <rayh> I do appreciate your help.
[15:40:33] <SWPadnos> so the hal files shouldn't be written by this program, since it's only changing things in the ini
[15:40:49] <SWPadnos> the hal files are already getting their values from the ini
[15:41:09] <rayh> as long as you are able to suffer through the sylopsic nature of hal file writers.
[15:41:32] <rayh> and don't try to add or change anything hal from any helper system.
[15:41:36] <SWPadnos> then there's the issue of "what happens if I put the same thing in the hal file twice?"
[15:42:11] <SWPadnos> I think halconfig is very important for the release, so "normal" users can configure emc2
[15:42:24] <rayh> It ain't gonna be there.
[15:42:41] <rayh> No way we can get around the issues.
[15:42:58] <SWPadnos> we may be able to get something going at fest. it's easier to communicate in person
[15:43:01] <rayh> say for example that someone unloadrt a parport and reloads two
[15:44:12] <rayh> that is not an easy fix to add to whatever set of hal files you are dealing with.
[15:44:24] <cradek> I liked using halconfig to browse the tree and view the status of things (especially the lights for parport bits)
[15:44:35] <cradek> I understand there are big problems with saving changes, but I hate to see it all go
[15:44:39] <SWPadnos> yeah. there are several different problem domains to be addressed
[15:44:49] <SWPadnos> 1) create a hal configuration from scratch
[15:44:55] <rayh> Yea I liked that as well.
[15:44:57] <SWPadnos> 2) "tuning"
[15:45:04] <SWPadnos> 3) debugging
[15:45:09] <SWPadnos> etc
[15:45:43] <cradek> can we keep the viewing parts of it for this release and work out the saving parts afterward?
[15:45:47] <rayh> and halcmd save all is the ideal way to handle save.
[15:46:04] <SWPadnos> I think the first step is to define exactly what we want it to do
[15:46:26] <SWPadnos> then kmake sure the underlying infrastructure (HAL) can support the UI features we need
[15:46:30] <rayh> I've been trying to get folk to think about that for almost 6 months.
[15:46:49] <rayh> jmk is not interested and almost antagonistic at stages.
[15:47:19] <rayh> I've tried working up scripts to demo stuff and you try em.
[15:47:37] <rayh> I'm way past trying to help tillie.
[15:47:55] <SWPadnos> I think it's 98% there
[15:48:03] <SWPadnos> the last 2% is the hard part though
[15:48:09] <rayh> Someone said they thought I might be winning a few weeks ago but I don't see it at all.
[15:48:36] <rayh> IMO I'm less than 30%
[15:48:43] <SWPadnos> well I disagree
[15:49:12] <SWPadnos> in fact, we can massage the ini files to make it work perfectly right now
[15:49:49] <SWPadnos> but it'll be a bit "fragile"
[15:50:49] <rayh> "We have nothing to offer but blood, sweat, toil, and tears."
[15:51:09] <SWPadnos> heh
[15:51:29] <SWPadnos> I've heard of "Blood, Sweat and Tears" before
[15:52:07] <SWPadnos> and "Sniff 'n the Tears"
[15:53:08] <SWPadnos> anyway. if I change the univstep and m5i20 inis to use INPUT_SCALE and OUTPUT_SCALE, then halconfig will work just fine
[15:53:23] <SWPadnos> I'm not sure what else isn't done in it though
[15:53:52] <rayh> There are issues with these variables because they are globals in emc as well as being used in hal
[15:54:18] <rayh> Try running an emc and switching the polarity of input scale in hal and you'll see wht I mean.
[15:54:25] <rayh> the motor runs away.
[15:54:37] <SWPadnos> yes
[15:54:51] <rayh> It should not do that within hal but it does because the variable also has application in emc.
[15:54:51] <SWPadnos> and there's no way to tell the UI that the two should be linked
[15:55:12] <rayh> It isn't ui it is path planning.
[15:55:19] <SWPadnos> and they don't always have the same value. univstep is fairly unique
[15:55:20] <cradek> rayh: if swp can't talk you into keeping everything, what do you think of my idea to keep all the viewing/browsing parts?
[15:55:47] <cradek> I think they really help to see what's going on
[15:56:30] <rayh> sure np
[15:57:01] <cradek> good, I think that would be nice
[15:57:20] <rayh> we'd have to modify tree to satisify folk.
[15:58:05] <cradek> I was using it successfully as-is, is there a problem with some driver I don't use?
[15:58:20] <cradek> I know the naming of things is not very consistent
[15:58:29] <rayh> And there will be NO relationship between the look of tree in 2.0 and 2.1
[15:59:02] <cradek> I'm sure 2.1 may be totally different in lots of ways
[15:59:34] <cradek> I know jmk wants to change/standardize a lot of things in hal
[16:00:01] <rayh> we need to.
[16:00:07] <SWPadnos> yep
[16:00:27] <rayh> I can't even get emccalib to work.
[16:00:38] <SWPadnos> btw - I just used halcconfig to modify my univstep.ini, and it seems to function just fine
[16:00:42] <rayh> and I've got about 4 days left before fest.
[16:00:58] <SWPadnos> there are only two caveats:
[16:01:09] <rayh> as long as you dont try to save any of the work.
[16:01:12] <SWPadnos> 1) you can't use the same ini var for more than one HAL var
[16:01:19] <SWPadnos> no. I saved it as well
[16:01:32] <SWPadnos> 2) you can't duplicate lines in the hal files
[16:01:45] <SWPadnos> (not an error for hal, but it is for halconfig)
[16:01:58] <SWPadnos> these aren't fatal problems in my view
[16:02:00] <rayh> you can't save anything hal except a netlist.
[16:02:24] <rayh> so imo you hve to remove it's ability to change hal things.
[16:02:35] <SWPadnos> that may be true for now
[16:02:44] <SWPadnos> though the ini var tuning works great
[16:03:27] <rayh> so long as there aren't two hal elements looking at the same ini variable
[16:03:31] <SWPadnos> I guess I'd just take out the modify tab, until we can figure out exactly what it needs to do
[16:03:38] <SWPadnos> yes, but that's easy to do
[16:04:02] <SWPadnos> then add an error check to halconfig, so it only tries to use the first one (or the last one, if it's easier)
[16:04:03] <rayh> um no. you have to remove the front stuff as well.
[16:04:21] <SWPadnos> which front stuff?
[16:04:40] <cradek> I'm looking at halconfig now, and it seems like removing save/save as/save and exit and all the tabs except show and watch would give us a good hal viewer/browser
[16:04:42] <rayh> No that will screw tuning. It may look fine during tuning but the next startup will change the other values of tuning variables to match the first.
[16:05:23] <SWPadnos> I don't understand
[16:05:48] <rayh> Let's split it up, put the tuning into emccalib and fix the multiple reads of ini values.
[16:05:57] <rayh> and make a new script names halshow.
[16:06:10] <rayh> cause it ain't config at all.
[16:06:11] <SWPadnos> ok. that's good for me
[16:06:27] <SWPadnos> I think the "generic HAL config tool" is a hard problem
[16:06:41] <cradek> yeah very.
[16:06:47] <SWPadnos> harder than it needs to be, partly due to the totally generic/flexible nature of HAL
[16:07:27] <SWPadnos> is it possible to "embed" a tcl script in a window or tab?
[16:07:46] <SWPadnos> similar to the way the KDE control panel does it
[16:08:00] <rayh> how's that
[16:08:19] <SWPadnos> you get a tree on the left, and the individual config program runs in the window on the right
[16:08:44] <rayh> frames can be defined as containters.
[16:08:53] <jepler> SWPadnos: tk supports -container and -use, but the reality is that it works for crap (keyboard focus and tabbing are the main trouble spots)
[16:08:58] <rayh> containers
[16:09:01] <SWPadnos> ok
[16:09:18] <SWPadnos> it owuld be nice to be able to drop emccalib into a frame/container, so the code only has to exist once
[16:09:20] <SWPadnos> would
[16:09:24] <rayh> and a container frame can be used to hold a different toplevel
[16:09:58] <jepler> I would recommend looking forst at a way to use "source" or "package" to run all the code within a single wish, before looking at -container/-use.
[16:10:14] <rayh> Years ago I wrote a complete library for emc ui construction.
[16:10:19] <SWPadnos> ok. as long as there's a way
[16:10:23] <SWPadnos> hmmm. the tuning problem is actually harder than I thought
[16:10:34] <rayh> You know a lot more about these things than I do.
[16:10:35] <SWPadnos> some things need to be set with NML commands, I think
[16:10:45] <SWPadnos> or is DEADBAND a HAL param now?
[16:10:55] <SWPadnos> I guess that's in the PID
[16:11:39] <rayh> one issue here is that the HAL portion of these things have to reference themselves to HAL
[16:11:58] <rayh> that is they must get their info from hal rather than imposing something on HAL.
[16:12:17] <rayh> so if you try to tune a stepper you see three variables.
[16:12:29] <rayh> if you try to tune sim you get a blank
[16:12:56] <rayh> Then each of the servo systems have very different sets of parameters.
[16:13:14] <rayh> Many of these you can't see by looking for ini variables
[16:13:34] <SWPadnos> we need to define the problem set better
[16:13:51] <SWPadnos> at this point, I'd say that anything that isn't in the ini file isn't tunable
[16:14:00] <SWPadnos> so you don't have to worry about it
[16:14:19] <SWPadnos> by the way - I like the hilighting of applicable entries on the modify page
[16:14:23] <SWPadnos> that's cool
[16:14:31] <rayh> thanks
[16:15:47] <rayh> IMO, if you are building a release, leave out emccalib as well as halshow unless they get done.
[16:16:24] <SWPadnos> I think the tuning part of halconfig (emccalib) is much better for average users than editing ini files
[16:16:37] <SWPadnos> even with the restrictions ithas currently
[16:17:22] <SWPadnos> as far as I know, the only configs that need to drive two things from one ini var are univstep and stepper*
[16:17:40] <SWPadnos> m5i20 shouldn't, because it uses pwm for output, not steps
[16:20:23] <rayh> m5i20 had duplicate reads in two different hal files.
[16:20:57] <SWPadnos> I know they're there, but I think they shouldn't be
[16:21:59] <SWPadnos> dac-gain shouldn't equal input_scale for the m5i20
[16:22:22] <SWPadnos> oops - nevermind
[16:22:24] <rayh> There are a lot of strange things in the configs, and a lot of things that should be there but aren't.
[16:22:52] <SWPadnos> oh yeah - did anyone ever go through and do a sanity check on all the configs?
[16:23:06] <SWPadnos> looking for stuff like soft limits that make sense
[16:23:16] <rayh> That's a lot of reading.
[16:23:32] <SWPadnos> yeah, a fair amount
[16:23:39] <rayh> stepper z limits suck
[16:23:57] <rayh> I changed it once but it got put right back.
[16:24:20] <SWPadnos> any sim config should have limits large enough to run any of the demo gcode files
[16:24:47] <SWPadnos> I think m5i20 was screwed up, in that it had -something to 0 limits on all axes
[16:25:07] <rayh> and are the proper values multiplied for mm setups.
[16:25:23] <rayh> I gotta do something else for a while. bbl
[16:25:41] <SWPadnos> see you later
[16:26:21] <SWPadnos> I suppose I should do some real work as well.
[16:26:55] <SWPadnos> cradek: I don't think I'll get to the analog stuff until evening or later. don;t wait for it for today's packages
[16:27:05] <cradek> ok
[16:28:00] <SWPadnos> I'll back later. see you
[16:28:03] <SWPadnos> SWPadnos is now known as SWP_Away
[16:43:54] <alex_joni> hi
[17:49:00] <SWP_Away> SWP_Away is now known as SWPadnos
[18:16:22] <alex_joni> hi chris
[18:16:37] <cradek> hi
[18:17:06] <alex_joni> seen you're moving testing, so I figured you're around
[18:17:10] <cradek> yep
[18:17:26] <alex_joni> was wondering when we'll start not using TESTING as a name anymore..
[18:17:34] <alex_joni> or maybe add RELEASE
[18:17:41] <alex_joni> maybe you know a bit more about .deb's
[18:17:47] <alex_joni> and how that works out for the user
[18:18:04] <cradek> I keep thinking each one will be the last
[18:18:28] <cradek> I think we agreed a while back that we would make TESTING releases until one seemed good enough, then call it 2.0.0
[18:18:50] <cradek> but it seems like some have changed their minds and want something in between
[18:19:04] <cradek> like "release candidate" etc
[18:19:40] <alex_joni> I must say I like the way AXIS gets released
[18:20:11] <cradek> seems like after 2.0.0 we'll use numbers
[18:20:26] <alex_joni> how do you mean that?
[18:20:41] <cradek> the bugfix release after that will be 2.0.1
[18:20:47] <alex_joni> ahh.. ok
[18:20:51] <cradek> sometime we'll make 2.1.0 off HEAD
[18:20:53] <alex_joni> then why not have it 2.0.0 now
[18:21:00] <alex_joni> and 2.0.1 tomorrow?
[18:21:03] <alex_joni> and so on :)
[18:21:26] <alex_joni> does it work for users to get 2.0.x instead of TESTING automagically ?
[18:21:33] <cradek> because I want 2.0.0 to be special (good enough to use for a while, or give away at fest)
[18:22:13] <cradek> it will, I may have to do a hack that debian provides for changing version number schemes
[18:24:15] <alex_joni> got a question for you..
[18:24:33] <alex_joni> I want to move a file from documents/lyx to documents/lyx/emc2
[18:25:02] <alex_joni> got anything against me removing it in the first place, and adding it to the second ?
[18:25:15] <cradek> no, that's fine
[18:25:28] <alex_joni> no cvs version on it, so it doesn't matter :)
[18:25:53] <SWPadnos> or add it first, so there's no date/time that would be missing the file
[18:26:01] <alex_joni> SWPadnos: it's lyx..
[18:26:05] <Lerneaen_Hydra> cradek: what is left to add before a 2.0.0 release?
[18:26:06] <alex_joni> who do you think will miss it?
[18:26:12] <SWPadnos> heh
[18:26:15] <alex_joni> for a few minutes?
[18:26:22] <cradek> Lerneaen_Hydra: a bit of testing
[18:26:33] <SWPadnos> not like they could find the 3 minute window without a lot of looking
[18:26:34] <Lerneaen_Hydra> cradek: so bugtesting basically?
[18:27:26] <cradek> to my view, the system is in very good shape, but when we call a release 2.0.0 is up to the entire board, not just me
[18:46:27] <cradek> new emc2, emc2-dev packages in the ubuntu emc2 repository
[18:53:29] <alex_joni> cool
[18:59:52] <Lerneaen_Hydra> testing or head?
[19:00:21] <alex_joni> TESTING
[19:00:29] <alex_joni> Head is only available from CVS
[19:00:32] <alex_joni> or tarball
[19:09:27] <Lerneaen_Hydra> ah, ok
[19:11:31] <alex_joni> mainly because it's development (aka mined field)
[19:13:55] <Lerneaen_Hydra> yes, that is understandable
[19:14:22] <Lerneaen_Hydra> * Lerneaen_Hydra really like the apt system (and other systems like it)
[19:15:15] <alex_joni> jepler: any idea how <ul> works in lyx?
[19:15:53] <jepler> alex_joni: no
[19:16:06] <alex_joni> jepler: found it.. it's "Itemize"
[19:16:34] <alex_joni> you select that from the thingie where you select "Section" "Subsection" "standard" ...
[19:19:58] <alex_joni> jepler: I'm learning myself still
[20:14:21] <alex_joni> SWPadnos: around?
[20:14:38] <SWPadnos> yep
[20:15:41] <alex_joni> oh, nm, I remembered (jared & dinero)
[20:15:47] <SWPadnos> heh
[20:51:46] <SWPadnos> hey rayh, I think I may have a solution to the problem with multiple inivar references
[20:52:35] <rayh> I'm all eyes.
[20:52:42] <SWPadnos> ok
[20:52:58] <SWPadnos> I'm not sure that I've covered everything, but - uh - that's what collaboration is for ;)
[20:53:48] <SWPadnos> first, I put the line that was causing the errors into a catch statement (the set thisname [label yadda yadda] statement)
[20:54:26] <SWPadnos> the if {catch ...} part is empty, the else part has the other widget making statements in it
[20:54:57] <SWPadnos> one sec - let me pastebin my version of makeIniTune
[20:55:51] <SWPadnos> it has a bunch of test code in it
[20:55:57] <SWPadnos> http://pastebin.com/695037
[20:57:09] <SWPadnos> let me know when you're ready
[20:58:33] <rayh> okay.
[20:58:44] <SWPadnos> ok, so the catch is on line 45
[20:58:52] <rayh> Saw that.
[20:59:00] <SWPadnos> that prevents the error from generating multiple widgets with the same name
[20:59:26] <SWPadnos> I think the ininamearray and commandarray can be eliminated, btu I'm not positive
[21:00:00] <SWPadnos> if you run with this version, you end up with the ininamearray containing multiple instances of the vars that are referenced more than once
[21:00:16] <SWPadnos> and there's a corresponding hal parameter name in the commandarray
[21:00:29] <SWPadnos> so you still have a 1:1 mapping of vars to params
[21:01:24] <SWPadnos> though that's a PITA, because you have to search for all instances of a particular var in the ininamearray, so you can "setp" all of the params
[21:01:57] <SWPadnos> but, if you look at the extraarray, it's interesting to note that you have the axis number and the ini var name as parts of the array index
[21:02:20] <SWPadnos> and the array element is a list of all of the HAL params associated with the ini var
[21:03:14] <SWPadnos> so that double foreach loop prints a line like "setp hal.param.name [AXIS_n]VARNAME" for each param set from a var
[21:03:26] <SWPadnos> (lines 71-78)
[21:03:58] <SWPadnos> I think the big "ah-ha" moment was when I realized that you can extract the ini section and var names from the array index
[21:04:17] <SWPadnos> does any of this make sense?
[21:04:23] <alex_joni> but where's the big ha-ha moment?
[21:04:30] <SWPadnos> that's coming up
[21:04:35] <SWPadnos> (Fest)
[21:04:37] <alex_joni> ok ;)
[21:04:38] <SWPadnos> :)
[21:04:47] <alex_joni> I see www.linuxcnc.org is quite busy
[21:05:00] <SWPadnos> is it? I thought the stats were removed
[21:05:10] <alex_joni> Visitors=7705, Hits=49462
[21:05:16] <alex_joni> only from the user-interface
[21:05:22] <SWPadnos> not bad
[21:05:24] <alex_joni> they are still doing their thing in background
[21:05:25] <SWPadnos> user or admin?
[21:06:04] <alex_joni> how do you mean that?
[21:06:18] <SWPadnos> what is the "user-interface"?
[21:06:27] <rayh> oh wow my head is heavy trying to see what you see SWPadnos
[21:06:32] <SWPadnos> heh
[21:06:33] <alex_joni> what you see on www.linuxcnc.org
[21:06:49] <SWPadnos> ok. I see no stats. I was wondering where they were
[21:07:07] <SWPadnos> rayh, can you run halconfig or emccalib with that version of makeIniTune?
[21:07:11] <alex_joni> SWPadnos: joomla has 2 parts (called frontend, what visitors see; and backend, what users/admins see when they log in under 'Admin')
[21:07:20] <SWPadnos> or I can paste in some of the output
[21:07:26] <SWPadnos> alex_joni, ok
[21:07:50] <alex_joni> SWPadnos: if you log in under Admin, then under Components->BSQ Sitestats you'll see some stats
[21:07:54] <SWPadnos> ok
[21:08:25] <alex_joni> but I see you don't have an username...
[21:08:47] <SWPadnos> nope
[21:08:53] <SWPadnos> http://pastebin.com/695061
[21:09:03] <alex_joni> SWPadnos: you could register..
[21:09:11] <SWPadnos> that's the output from this version of makeinitune, using my univstep setup
[21:09:14] <SWPadnos> alex_joni, later
[21:09:16] <alex_joni> SWPadnos: then I could change your status to something better ..
[21:09:20] <SWPadnos> heh
[21:09:22] <alex_joni> SWPadnos: no hurries..
[21:09:59] <SWPadnos> rayh, notice the output of the extraarray data
[21:10:13] <SWPadnos> extraarray(0,bias) = pid.0.bias
[21:11:20] <SWPadnos> the array index (0,bias) has the axis number (0), the ini var (bias), and the name of all the params that get their value from this var
[21:11:27] <SWPadnos> (pid.0.bias)
[21:11:50] <SWPadnos> but if you look at input_scale, you see both the input and output scale
[21:12:19] <SWPadnos> err - the (0,input_scale) array element has both the input and output scale params in it
[21:12:29] <SWPadnos> maybe I've solved the easy part ;)
[21:14:17] <SWPadnos> oh, line 73 is the magic that gets the section and var from the array index name
[21:14:45] <rayh> I saw that.
[21:16:36] <SWPadnos> does this help you, or am I confusing the issue more? ;)
[21:17:01] <alex_joni> you certainly confused me.. :D (but then again, tcl always confused me)
[21:17:07] <SWPadnos> me, too ;)
[21:19:12] <rayh> The probles will no doubt become clear when we remodel changeIt to handle the new array.
[21:19:57] <SWPadnos> I think that ChangeIt can use the ininamearray and commandarray as it does now
[21:20:37] <SWPadnos> but it may need to look up the widget names from ininamearray instead of looping through the widgets
[21:20:50] <SWPadnos> (I think that's the one that loops on the widget names)
[21:22:25] <rayh> could regexp the array names from extraarray
[21:22:45] <SWPadnos> just loop on llength ininamearray
[21:22:48] <rayh> toss all that don't match the axis in question.
[21:23:13] <SWPadnos> right - that's what line 70 does
[21:23:20] <lilo> [Global Notice] Hi all. In about 8.5 hours, we'll be rehubbing our European servers ( http://freenode.net/news.shtml ). This will affect all of our users; it'll be pretty noisy. It should be finished very quickly, though.
[21:23:32] <SWPadnos> gets only the indices that match a particular axis name
[21:23:40] <lilo> [Global Notice] Thanks in advance for your patience and support, and thank you for using freenode. Have a great night!
[21:24:20] <SWPadnos> of course, you'd use $j or something, instead of the "0"
[21:26:10] <SWPadnos> actually, if you can get widget values by using the elements of ininamearray (to look up the widget names), then you should just be able to loop on ininamearray($axis)
[21:26:39] <rayh> I see I'm working on the number of ini variables rather than the number of commands.
[21:26:56] <rayh> but if the commands are a foreach
[21:27:30] <rayh> it would change hal values in succession.
[21:27:51] <SWPadnos> yes. it does that now, since halcmd can only change one thing at a time
[21:28:04] <rayh> I mean all of the hal elements that read from the same ini.
[21:28:32] <SWPadnos> yes, it would sequentially update HAL parameters, even if they're from the same ini var
[21:29:36] <rayh> You want to migrate your changes to makeIniTune into head.
[21:29:44] <SWPadnos> I suppose you could issue a halcmd stop before updating, then halcmd start after :)
[21:30:09] <SWPadnos> I can't right now. I've been working in halconfig and I need to leave in a couple of minutes
[21:30:29] <SWPadnos> I think the main change is the catch statement. all the extraarray stuff is probably unnecessary
[21:30:34] <rayh> Oh okay. I'll get it from pastebin.
[21:30:38] <SWPadnos> ok. thanks
[21:30:56] <rayh> thanks
[21:31:04] <SWPadnos> one other thing. I think you had mentioned that you need to go through the ini twice - is that true?
[21:31:13] <SWPadnos> to build these arrays
[21:31:31] <SWPadnos> oops - the hal files, not the ini
[21:32:47] <SWPadnos> argh. gotta run. see you later. I should be back on in a couple of hours
[21:32:53] <SWPadnos> SWPadnos is now known as SWP_Away
[22:06:17] <alex_joni> jepler: still there?
[22:07:13] <alex_joni> jepler: was wondering if you would mind me removing the title & TOC from gcode.lyx
[22:08:02] <alex_joni> I plan to include that file to Master_User.pdf , maybe I can make a RS274.lyx and include gcode.lyx from there too (to keep the title, author & TOC intact)
[22:17:55] <rayh> What do you need to have done with gcode.lyx?
[22:21:08] <alex_joni> I included it along with install & intro
[22:21:18] <alex_joni> and I'm a bit bugged that it's got a TOC in there
[22:21:51] <alex_joni> but that's nothing majour
[22:22:55] <alex_joni> rayh: btw, I moved the emc2 install scripts & instructions to www.linuxcnc.org
[22:23:52] <alex_joni> rayh: http://dsplabs.utt.ro/~juve/blog/index.cgi-files/01146513141/IMG_3306.JPG
[22:23:55] <alex_joni> aaargh
[22:24:03] <alex_joni> here: http://www.linuxcnc.org/index.php?option=com_content&task=view&id=21&Itemid=4
[22:32:20] <alex_joni> ok, I'm off to bed
[22:32:24] <alex_joni> g'night all
[22:36:35] <jepler> alex_joni: do whatever you like to make it consistent with the rest of the documentation.
[22:56:48] <jepler> I'll hold off doing anything until we have a chance to discuss it
[22:57:10] <jepler> (I need to add G33 spindle-synch motion, for instance)
[23:46:32] <jepler> .. I lied. I started fiddling with it again