Back
[00:42:50] <jmkasunich> my $0.02 - M3/43 doesn't extend to 3 or more gears very well at all
[03:10:23] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[03:12:51] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[05:38:43] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/configs/hostmot2/ (hm2-2-boards.hal hm2.hal): This switches to in-kernel firmware loading.
[05:38:43] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/debian/emc2.files.in: This switches to in-kernel firmware loading.
[05:38:44] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/ (hm2_5i20.9 hm2_7i43.9 hostmot2.9): This switches to in-kernel firmware loading.
[05:38:44] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/src/Makefile: This switches to in-kernel firmware loading.
[05:38:46] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (12 files): This switches to in-kernel firmware loading.
[05:38:49] <CIA-35> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/doc/firmware-loading-debacle: This switches to in-kernel firmware loading.
[13:08:37] <cradek> jmkasunich: I agree
[13:10:53] <skunkworks> morning
[13:14:04] <cradek> hi
[13:14:32] <cradek> M3.1, M3.2, M3.3, ...
[13:14:53] <cradek> that scheme would limit us to ten gears
[13:15:57] <cradek> on a machine with more than ten gears it seems less likely that you would want to pick them manually
[13:16:49] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/oooh.PNG
[13:16:52] <jepler> constant surface speed includes the maximum speed. In the case of automatic gear changing, you'd just set the gear based on the max speed
[13:17:43] <cradek> skunkworks: wow!
[13:18:06] <skunkworks> messy huh :)
[13:18:06] <cradek> jepler: I don't understand what you're saying
[13:18:26] <cradek> skunkworks: did you autoroute that? hahahaha
[13:18:47] <skunkworks> heh. that was - ok - It is possible. Now I need to tweek it..
[13:19:16] <skunkworks> only 3 via's
[13:29:43] <skunkworks> I should have tried autoroute for s/g's
[13:33:01] <skunkworks> all unused inputs are tied to either ground or vcc
[13:41:23] <jepler> cradek: G96 D- S- selects constant surface speed of S- per minute subject to a maximum of D- revolutions per minute.
[13:41:40] <jepler> cradek: so when turning on the spindle in css mode, the gear would be selected based on the D-number
[13:42:28] <SWPadnos> is there an output from the motion controller that tells HAL it's in some spindle-synched mode?
[13:49:14] <cradek> skunkworks: let me know when the kit is ready...
[13:49:52] <jepler> SWPadnos: no; what I'm talking about would require hal changes. there would be a new pin that holds a "RPM value to select spindle gear", and in the case of G96 it would get the D- number; in the case of M3 S100 it would get the S-number.
[13:50:17] <cradek> jepler: you can switch in and out of G96 with the spindle on, right?
[13:50:23] <jepler> cradek: nfc
[13:50:26] <jepler> probably
[13:51:21] <cradek> I'm trying to picture how it would work, considering that (usually?) the spindle has to be stopped to change gears
[13:52:52] <jepler> forget I said anything, then
[13:56:58] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[13:59:01] <SWPadnos> I was thinking of using HAL also, but basically telling it "don't change gears in this mode"
[13:59:04] <cradek> well I agree that D number is part of the answer if you want to pick a gear automatically
[14:00:12] <SWPadnos> actually, what you'd want is an output that ways the motion controller wants a continuous speed function
[14:00:17] <SWPadnos> (more or less :) )
[14:00:23] <SWPadnos> s/ways/says/
[14:01:00] <cradek> I think on some machines you want to pick a gear automatically (at M3 time maybe?) and on some machines you want to specify a gear.
[14:01:10] <SWPadnos> yep, that'll be true also
[14:01:10] <cradek> in the auto case, jepler is right, G96D is the relevant one
[14:01:36] <SWPadnos> with D though, you may want to pick the lowest gear that can reach the D speed
[14:01:46] <cradek> yes quite likely
[14:01:48] <SWPadnos> rather than the closest gear
[14:01:56] <SWPadnos> (that can reach that speed)
[14:02:10] <cradek> but that doesn't change the info presented to hal (iiuc)
[14:02:37] <SWPadnos> no, if it's deciding whether to use S or D, it can also decide which gear to use differently
[14:02:52] <cradek> right now I'm more interested in the manual case, but it would be nice to handle both
[17:17:41] <alex_joni> skunkworks: forgot to route something there
[17:17:52] <alex_joni> Q4 to R3
[17:19:36] <LawrenceG> good eyes alex
[17:20:28] <skunkworks> alex_joni: fixed. I am tweeking a bunch of stuff. Tanks
[17:20:30] <skunkworks> thanks
[17:20:34] <alex_joni> np
[17:21:10] <alex_joni> I don't suspect you'll do a silkscreen
[17:21:13] <alex_joni> right?
[17:22:34] <skunkworks> right.
[17:22:49] <skunkworks> although I have thought about it..
[17:23:14] <SWPadnos> don't you work at a silkscreening shop?
[17:23:24] <skunkworks> :) I have done some here at work for myself.. but I don't want to work that hard.. :)
[17:23:28] <SWPadnos> hrh
[17:23:30] <SWPadnos> heh
[17:23:31] <skunkworks> that was a few years ago
[17:23:35] <SWPadnos> ah
[17:23:49] <skunkworks> we don't do that here for customers.
[17:23:52] <skunkworks> customers.
[17:23:57] <skunkworks> oh - that was right
[17:25:40] <skunkworks> isn't 222 underlined on a cap 222 pf?
[17:25:52] <SWPadnos> I don't think so
[17:25:57] <skunkworks> huh
[17:25:57] <SWPadnos> it should be 2200pf
[17:26:09] <SWPadnos> 22 + two zeroes
[17:27:22] <skunkworks> odd. so - I have some that I know are 22pf and they are underlined.. (22)
[17:27:33] <skunkworks> is that 2 digits are pf?
[17:27:45] <SWPadnos> that seems likely, but I'm not sure
[17:28:02] <SWPadnos> it wouldn't make sense to have one significant digit then an exponent
[17:28:18] <skunkworks> ok - maybe I am not all cracked out then..
[17:28:29] <SWPadnos> 29 would be 2000000000pf, but with terrible uncertainty :)
[17:29:35] <skunkworks> heh
[17:29:44] <CIA-35> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/integrator_intro.lyx: minor layout change
[17:29:52] <CIA-35> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_Integrator.lyx: minor layout change
[17:29:59] <alex_joni> bbl
[17:31:20] <CIA-35> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/Master_Integrator.lyx: minor layout change
[17:41:13] <skunkworks> wow - hit and run. :)
[20:09:31] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/papercirc.jpg
[20:10:01] <jepler> skunkworks: that's a terrible photo
[20:10:02] <alex_joni> skunkworks: getting there :D
[20:10:10] <alex_joni> * alex_joni agrees with jepler
[20:10:58] <skunkworks> sorry.. flash was too washed out.. no flash - I shake too much..
[20:14:37] <cradek> I like how it's red on top and blue on the bottom
[20:14:59] <cradek> oh, I was looking at the previous one
[20:15:37] <cradek> is that monster thing the sense resistor?
[20:15:53] <jepler> must be
[20:16:04] <jepler> it's marked 7W .015 on the silkscreen
[20:16:11] <skunkworks> yes.
[20:25:54] <skunkworks> (gives me a max of 20w to play with)
[20:26:26] <cradek> 20w what?
[20:26:40] <SWPadnos> 20A maybe
[20:26:51] <SWPadnos> hmmm. no
[20:26:57] <skunkworks> jeeze - 20A
[20:27:03] <cradek> 20V?
[20:27:06] <cradek> 20C
[20:27:09] <skunkworks> heh
[20:27:13] <jepler> sqrt(7W / .015 ohm) = 21.6A
[20:27:16] <skunkworks> yes
[20:27:33] <SWPadnos> oh duh. here's me looking up what "square" means again ;)
[20:27:46] <jepler> yeah I dunno what a square amp is
[20:28:04] <SWPadnos> it's not writable with my non-unicode IRC client :)
[20:30:27] <jepler> hi seb
[20:47:54] <seb_kuzminsky> hi jeff
[20:48:31] <seb_kuzminsky> i think i've finally put that firmware/pci issue behind me... hope jmk's not too disappointed
[20:48:38] <SWPadnos> heh
[20:48:55] <alex_joni> I'm sure he's glad it's over
[20:48:56] <alex_joni> :P
[20:49:02] <seb_kuzminsky> heh
[20:49:10] <SWPadnos> the only gotcha there is that run-in-place must change files outside the RIP tree
[20:49:23] <seb_kuzminsky> but it already does that, so i dont feel too bad about it
[20:49:30] <SWPadnos> RIP?
[20:49:35] <seb_kuzminsky> indeed sir
[20:49:42] <SWPadnos> what files are changed for RIP?
[20:49:48] <SWPadnos> (outside hte RIP tree)
[20:49:51] <SWPadnos> the
[20:50:18] <seb_kuzminsky> /etc/udev/rules.d/emc2 for one (change permissions on rtai fifos)
[20:50:26] <SWPadnos> (if there was a discussion about this, I missed it - sorry to ask you to repeat)
[20:51:01] <SWPadnos> hmm. ok. is that file different between EMC2 versions?
[20:51:05] <seb_kuzminsky> i'm looking up the others
[20:51:06] <SWPadnos> (I don't think it is)
[20:51:07] <SWPadnos> heh
[20:51:35] <SWPadnos> no big deal - that was one of the issues I remember with request_firmware - if it turns out to be moot, that's OK with me
[20:51:46] <seb_kuzminsky> yeah i think not either, and jmk shrugged it off saying it's rtai that needs that non-rip tweak
[20:51:55] <SWPadnos> I was more or less out of the discussion for a couple of weeks, I figure the world may have moved on :)
[20:52:01] <seb_kuzminsky> it's definately an issue, and i wish it weren't so
[20:52:06] <SWPadnos> yeah
[20:52:18] <SWPadnos> on another topic - have you tested a 5i23?
[20:52:21] <seb_kuzminsky> if the udev guys had accepted my patch to allow absolute paths in request_firmware() it would not have needed the symlink
[20:52:29] <seb_kuzminsky> i haven't played with the 5i23 yes
[20:52:32] <seb_kuzminsky> *yet
[20:52:36] <seb_kuzminsky> 5i22 is next for me
[20:52:51] <SWPadnos> I figure they have a good reason or three (security, security, security)
[20:53:02] <SWPadnos> do you have a 5i23?
[20:53:14] <seb_kuzminsky> they said it was a conceptual thing, not security
[20:53:20] <SWPadnos> hmmm - interesting
[20:53:28] <SWPadnos> "keep it all in the system tree" or something
[20:53:35] <seb_kuzminsky> if the adversary can load modules with arbitrary config strings we've already lost :-/
[20:54:06] <SWPadnos> if that's so, then the config string parser needs to be a little better ;)
[20:54:08] <seb_kuzminsky> their argument (which doesnt ring true to me) is that the string you pass to request_firmware() is not a filename, it's a key into a database
[20:54:31] <seb_kuzminsky> udev just *happens* to use /lib/firmware as the database, and the key is the filename... <rolls eyes>
[20:54:34] <SWPadnos> sure - the database just happens to reside under the VFS, usually on a disk somewhere ;)
[20:54:43] <seb_kuzminsky> heh
[20:54:49] <seb_kuzminsky> anyway...
[20:55:03] <SWPadnos> you have a 5i22-1.0, right?
[20:55:23] <seb_kuzminsky> yes i have a 5i22-1.0 and a 5i23 - peter sent me one of each board as part of the contract to develop the hostmot2 for all their boards
[20:55:43] <SWPadnos> ah, ok. I have the complementary set - 5i20 and 5i22-1.5 :)
[20:55:56] <seb_kuzminsky> have you tried the 5i20 with hostmot2 by any chance?
[20:56:05] <SWPadnos> not yet
[20:56:13] <SWPadnos> dunno when I'll have the chance, but I'll try to do it
[20:56:21] <seb_kuzminsky> i was just curious
[20:56:36] <seb_kuzminsky> it's probably too early for it to be useful, but the feedback would help me
[20:57:13] <seb_kuzminsky> other files changed outside the RIP sandbox:
[20:57:15] <SWPadnos> "real soon now" ;)
[20:57:28] <seb_kuzminsky> /etc/security/limits.conf
[20:57:30] <SWPadnos> I can also test multiple boards, of different or the same type
[20:57:45] <SWPadnos> I think I have 3x 5i20 and 2x 5i22-1.5
[20:57:56] <seb_kuzminsky> /etc/modutils/emc2
[20:58:08] <SWPadnos> wrong window :)
[20:58:19] <SWPadnos> oh - the list
[20:58:37] <seb_kuzminsky> there's a handful of little tweaks here and there
[20:59:30] <seb_kuzminsky> RIP is sort of a polite fiction. very useful mind you, but not quite strictly contained in the sandbox
[21:00:11] <SWPadnos> I don't see anything in my RIP tree that says anything about limits.conf
[21:00:34] <seb_kuzminsky> i got that from
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Lenny_Compile_RTAI
[21:01:54] <SWPadnos> ok. a lot of that has to do with setting up a system to be able to run any version of EMC
[21:02:22] <SWPadnos> once the system can run any EMC2, a RIP version doesn't need to change anything I know of
[21:02:29] <seb_kuzminsky> yes - it's stuff that needs to be done outside your sandbox before you can use it
[21:02:38] <seb_kuzminsky> same with hostmot2, basically
[21:03:19] <SWPadnos> no, if you have 6 different RIP dirs, you need 6 extra things in /lib/firmware
[21:03:28] <seb_kuzminsky> why?
[21:03:40] <SWPadnos> if the firmware is different between your RIPs
[21:04:01] <SWPadnos> which it should be, if they're e.g. 2.0, 2.1, 2.2, 2.3, and TRUNK
[21:04:22] <SWPadnos> which should be independent of an installed version (in case you actually have a machine that you use)
[21:05:20] <seb_kuzminsky> i think most of the time the firmware *interface* will not change, so the latest and greatest firmware will serve all sandboxes
[21:05:31] <seb_kuzminsky> one symlink for all 2.2 RIPs should suffice
[21:05:45] <SWPadnos> *should* ;)
[21:05:56] <SWPadnos> if I have a sandbox because I'm making FPGA changes, that breaks though ;)
[21:06:18] <seb_kuzminsky> if you're hacking on fpga firmware, you're certainly able to manage a few symlinks...
[21:06:33] <SWPadnos> sorry - I don't want to sound like I'm beating you up here. I appreciate the work, and I think there's no ideal solution
[21:07:40] <seb_kuzminsky> i understanda and i dont feel beat up :-)
[21:07:48] <SWPadnos> heh :)
[21:08:41] <seb_kuzminsky> i think this is the "least worst" option
[21:08:45] <SWPadnos> heh
[21:08:53] <SWPadnos> lesser of multiple weevils
[21:09:08] <jepler> if it makes things better for average users and harder for a few developers -- that is a pretty good choice.
[21:09:27] <seb_kuzminsky> i think users won't know or care which solution it is
[21:09:28] <SWPadnos> or at this point one developer ;)
[21:09:31] <jepler> heh
[21:09:36] <seb_kuzminsky> heh
[21:09:44] <jepler> seb_kuzminsky: do you (re)build the fpga firmwares?
[21:10:04] <seb_kuzminsky> users have to make a symlink when they start to RIP, but they dont need to use bfload.. maybe we call it a wash :-)
[21:10:12] <seb_kuzminsky> i have not compiled any fpga firmware ever
[21:10:15] <jepler> ok
[21:10:16] <seb_kuzminsky> i'm a vhdl virgin
[21:10:27] <seb_kuzminsky> i saw your page on compiling hostmot2 though
[21:10:37] <jepler> I've done the tiniest bit of work in the xilinx ide
[21:10:47] <jepler> but I haven't ever tested a self-compiled mesa firmware, so who knows..
[21:10:53] <seb_kuzminsky> you wrote all the firmware for pluto, right?
[21:10:55] <jepler> yes
[21:11:00] <seb_kuzminsky> cool
[21:11:23] <seb_kuzminsky> peter just cleaned up the hm2 sources a bunch, he said. i'll commit the new source rsn
[21:11:33] <SWPadnos> oh, cool
[21:13:11] <seb_kuzminsky> is there a date for 2.2.6?
[21:14:52] <seb_kuzminsky> jepler: even a rough date would be useful for me
[21:15:06] <SWPadnos> oh, I think I can answer that one: relatively soonish
[21:15:31] <seb_kuzminsky> right, i got that ;-)
[21:15:53] <jepler> well -- I tried to set a date during july but that went galloping past
[21:16:06] <jepler> I think alex and I both wanted to work on anything but emc that weekend :-P
[21:16:33] <jepler> I don't know if alex will be around this weekend, but if he is I'd sure like to give it another try
[21:16:39] <jepler> lots of good bugfixes in there after all
[21:16:44] <seb_kuzminsky> i think i'm about ready to try to merge hm2 into 2.2
[21:17:08] <seb_kuzminsky> see what i can break just before your release ;-)
[21:17:26] <jepler> as long as you only break hm2 -- promise?
[21:17:39] <seb_kuzminsky> i'll try
[21:20:27] <alex_joni> jepler: I think I'll be around
[21:21:54] <jepler> alex_joni: great, it's a date :-P
[21:23:03] <alex_joni> sounds like it
[21:23:41] <SWPadnos> was there ever a consensus on how to arrange vendor-specific configs?
[21:23:55] <SWPadnos> I can check in the PCNC-1100 config as soon as I know where to put it
[21:26:29] <jepler> SWPadnos: right now I think all we can do is configs/<something without whitespace or slash>/<ditto>.ini
[21:26:36] <jepler> SWPadnos: i.e., we don't have multiple levels
[21:26:57] <jepler> configs/<vendorname>/<model>.ini is one thing to consider if we think we'll have many different models from one vendor
[21:27:05] <SWPadnos> right. I looked at that a littel, and I think it may be pretty simple to make the directory list recurse
[21:27:09] <SWPadnos> little
[21:27:14] <jepler> for 2.3 knock yourself out
[21:27:17] <SWPadnos> heh
[21:27:36] <jepler> for 2.2 .. well, we can decide that after seeing how simple or complex the change is
[21:28:06] <SWPadnos> tcl question for you: if you do a foreach on a list, and you add to the list inside the loop, does the loop continue to iterate over the new list members?
[21:28:38] <SWPadnos> I guess I could test that myself, but I'm too lazy or something
[21:29:22] <jepler> I think the answer must be "no"
[21:29:46] <jepler> when you execute 'foreach i $l { ... }', tcl first expands $l to its present value, then passes those 3 args to the implementation of foreach
[21:30:01] <SWPadnos> ah, ok
[21:30:15] <jepler> in this case, foreach sets i to each value expanded from $l in turn, and executes { ... }
[21:30:24] <SWPadnos> hmmm
[21:30:33] <SWPadnos> ok, so the simplest "fix" won't work
[21:34:13] <jepler> using for with indexes instead of foreach, you can mutate a list as you perform an action on the items in it.
http://pastebin.ca/1092867
[21:34:47] <jepler> tcl's for is similar to C's for(initializer;test;incrementer) {body}, it's for {initializer} {test} {incrementer} { loop body }
[21:34:56] <SWPadnos> ok, that's another possibility
[21:35:45] <SWPadnos> I had thought about maintaining a list of dirs to process, and manually add (with glob -d) and remove them
[21:35:54] <SWPadnos> then loop with while (size > 0)
[21:36:14] <alex_joni> good night all
[21:36:15] <SWPadnos> which is what you said
[21:36:19] <SWPadnos> see you alex
[21:36:21] <jepler> see you alex_joni
[21:36:37] <alex_joni> have fun with tcl :P
[21:36:46] <SWPadnos> yah, right
[21:37:13] <alex_joni> jepler: one of these days I'll bug you about vismach and stl's
[21:37:31] <alex_joni> like how to load the models, and how to define rotation/translations points, etc
[21:37:39] <alex_joni> but right now I'm off to bed ..
[21:42:08] <rayh> SWPadnos, You could 'set tmpstring $dirlist"
[21:42:28] <rayh> Then run the foreach on tmpstring
[21:42:53] <SWPadnos> well, the dirlist grows as you recurse, and you want to not process dirs that have already been seen (in case of links)
[21:42:58] <SWPadnos> the seen logic already exists
[21:43:45] <SWPadnos> I wasn't sure of the best way to remove a single item from a list, and I think that's too basic to find easily ;)
[21:43:47] <rayh> I didn't imagine changing tmpstring.
[21:44:12] <SWPadnos> you need some way of adding to the list of dirs on the fly
[21:44:32] <SWPadnos> whether it's during an initial build of the list, or while processing the ini files in the dir list
[21:44:39] <rayh> I guess I was thinking you had a list of dirs that you wanted to work from.
[21:44:55] <rayh> so make it temp, work from tem and fix dirlist.
[21:44:58] <SWPadnos> yes - a lit of top-level dirs is provided, but I want to expand the entire tree below
[21:45:16] <SWPadnos> rather than going only one level down
[21:46:43] <rayh> So what you want when you get done is a flat listing of all the directories below the initial list
[21:47:07] <SWPadnos> nope - the context for this is that I want to have subdirectories in the config picker
[21:47:38] <SWPadnos> so you could have sim/mill and sim/lathe, and each of those might have stepper and servo ini files in it (or whetever)
[21:47:43] <rayh> Oh. That would be the same as the tree code in halshow.
[21:48:14] <rayh> same sort of logic that is -- convoluted -- cause I wrote it.
[21:48:28] <SWPadnos> this is prompted by me wanting to add a Tormach config, but I'd prefer to have tormach/lathe and tormach/mill, with the files in separate dirs (rather than 2 inis and associagted hal files in one dir)
[21:48:30] <SWPadnos> heh
[21:48:39] <rayh> sure.
[21:49:12] <rayh> I have a time reading JMK's brand to tcl but I'll look.
[21:50:06] <SWPadnos> ah - I just found a way to delete a list element (lreplace index index <nothing>)
[21:50:37] <SWPadnos> so if I want to remove the first element each time through the list, I use `lreplace 0 0`
[21:50:51] <SWPadnos> err - `lreplace dirlist 0 0`
[21:52:00] <SWPadnos> ok, it should be relatively easy. I'll mess with it tomorrow while I'm waiting for my mother
[21:52:14] <SWPadnos> hopefully I'll have internet access so I can look up the answers to my stupid tcl questions :)
[21:53:44] <rayh> Don't you really want it to use "tormach" only expand it to include the directories under that.
[21:54:09] <SWPadnos> I want the config tree to allow for more than one level deep directory nesting
[21:54:17] <rayh> Sure.
[21:54:36] <SWPadnos> that would be useful for a number of things, including mesa and pico-systems
[22:00:15] <rayh> We just need to sense directories under the top directory.
[22:00:39] <rayh> If there is a directory there then add the name of the parent as a note
[22:03:04] <SWPadnos> I have the loop converted to a for loop now (but not recursing yet)
[22:03:18] <SWPadnos> it should be one more line or maybe 2 to get the recursion working
[22:28:25] <SWPadnos> or not
[22:41:12] <rayh> sorry phone.
[22:41:34] <rayh> SWPadnos, you up for a bit of a look with me.
[22:41:50] <SWPadnos> at pickdonfig?
[22:41:55] <SWPadnos> err - you know
[22:43:09] <SWPadnos> I have it recursing, but I need to make the tree look nicer
[22:43:45] <SWPadnos> it doesn't sort the way I expected (subdirs need to be added as their basename only, while top-level dirs need to be added as the full path)
[22:44:11] <SWPadnos> but the way I'm handling the list doesn't make a distinction, so I need to put in some way of tracking that
[22:44:55] <rayh_> okay
[22:55:41] <SWPadnos> well, at least it's showing the subdirs :)
[22:56:00] <SWPadnos> even if it is ugly
[22:56:37] <rayh_> So it's showing the entire path to the subdir?
[22:57:42] <SWPadnos> yep - the way I thought I'd do it was to look at whether seen(the parent dir) existed, but I guess that didn't seem to work.
[22:58:08] <rayh_> You might try something like -- set thisname file tail dirname.
[22:58:08] <SWPadnos> hold on - lemme pastebin the changes to pickconfig - they're only in the foreach dir $configs_dir_list area (I think)
[22:58:23] <rayh_> k
[22:58:31] <SWPadnos> oh, and describe
[22:59:18] <SWPadnos> http://pastebin.ca/1092920
[22:59:44] <SWPadnos> some dirs randomly end up at the bottom of the list, with the full path as their parent
[23:00:59] <rayh_> I see.
[23:02:20] <SWPadnos> I'm sure I need to take out some of the stuff that was there, since subdirs should now be added by sticking them at the end of the list
[23:02:55] <SWPadnos> the thing is, there are some decisions to be made about dir nodes that can't be known when they're first encountered, like whether any subdir will have a valid ini file
[23:03:15] <SWPadnos> so maybe it's not as simple as I had thought
[23:05:26] <rayh_> Can't we assume that any sub directories would be a valid config
[23:05:31] <SWPadnos> nope
[23:05:38] <SWPadnos> think of CVS/ for example :)
[23:06:26] <rayh_> Oh we aren't throwing out extraneous stuff.
[23:07:02] <rayh_> or we are throwing it out but because it does not contain an ini?
[23:07:29] <SWPadnos> yes, they get tossed because there are no ini files
[23:07:59] <SWPadnos> remember, the original loop looked at subdirs explicitly, using foreach on a list of top-level dirs
[23:08:03] <rayh_> So we can not distinguish between a CVS dir and a sub dir of a config.
[23:08:14] <SWPadnos> well yes, that's a problem
[23:09:07] <SWPadnos> I'm not positive how the current loop keeps track of visited dirs - it's in the seen() list, but I haven't delved into exactly what seen maps to
[23:10:05] <SWPadnos> maybe the thing to do is make the whole thing hierarchical - make top-level nodes for each dir passed in, then use the tail for each level after that
[23:10:19] <SWPadnos> that would be more similar to the way halshow does it, I think (splitting on / instead of .)
[23:11:43] <seb_kuzminsky> bye y'all
[23:11:49] <SWPadnos> bye
[23:11:53] <rayh_> IMO between 26 and 27 of the pastebin is where you need to do the test for dirs in each subdir.
[23:12:19] <SWPadnos> well yes - that shouldn't be a loop any more
[23:12:51] <SWPadnos> lines 16 and 20 maintain a list of to-be-processed dirs
[23:13:04] <rayh_> I don't see it being a problem as a loop. It just needs to test right there for directories below each sub.
[23:13:26] <SWPadnos> no, it can't be a loop there, since any dir could have more subdirs in it, which will need to be processed
[23:13:39] <SWPadnos> I had removed that loop, but then added it back for some other reason
[23:14:47] <SWPadnos> ok, yeah - the logic is wrong for a dir node that you can't tell for sure has a config under it (somewhere)
[23:15:13] <SWPadnos> the old code can tell immediately if the dir name has to be added to the tree, and whether it needs multiple children
[23:15:17] <rayh_> but why not set subsubdir_list [ glob -nocomplain $xxxxxxx/*/ ]
[23:15:33] <SWPadnos> what if there's a subsubsubsubdir?
[23:15:57] <SWPadnos> we still need to process the subdirs as though they were top or top+1 level dirs, to find all their children
[23:16:04] <rayh_> I didn't use glob it get directory contents so I don't know exactly what it returns.
[23:16:14] <rayh_> Yes.
[23:16:26] <SWPadnos> glob -type d gives you dirs anyway, you don't need the /*/ construct
[23:16:28] <rayh_> But I think we can do that for each subdir.
[23:16:50] <rayh_> I guess I learned the file command in tcl.
[23:17:05] <SWPadnos> sure, if we use actual recursion :)
[23:17:21] <SWPadnos> I was making it into a flat list that gets extended as necessary - maybe that's my problem :)
[23:23:52] <rayh_> How about if $inifile_list == "" { look for subsubdir_list }
[23:24:22] <rayh_> Nah that gets you CVS again.
[23:24:54] <rayh_> You may have to trap CVS.
[23:26:29] <SWPadnos> phone - brb
[23:40:49] <jmkasunich> hi guys
[23:41:12] <jmkasunich> coming in late, and not really knowing what I'm talking about, but gonna thro a suggestion anyway
[23:41:23] <jmkasunich> any merit to making it a two-past problem
[23:41:40] <jmkasunich> pass 1: recurse all dirs, looking only for subdirs, and build a tree
[23:41:55] <jmkasunich> pass 2: go thru the tree and discard any dirs that don't have inis
[23:42:19] <rayh_> Hi John
[23:42:23] <jmkasunich> hi rayh
[23:43:30] <rayh_> Seems like that would work as long as we trap CVS.
[23:44:08] <rayh_> It would mean that someone could screw up their copy and show subsubdirs that are empty.
[23:44:10] <jmkasunich> no need to trap it - it would get discarded in pass 2, as not containing a .ini file
[23:44:14] <rayh_> or without an ini.
[23:45:18] <rayh_> yea could be done.
[23:48:20] <rayh_> Does that throw away the Tormach dir if it has two subdirs under it and they have ini's
[23:51:21] <jmkasunich> depends on how you code it, but I'd think so
[23:51:33] <jmkasunich> the list would look like:
[23:51:34] <jmkasunich> foo
[23:51:35] <jmkasunich> bar
[23:51:39] <jmkasunich> tormach/lathe
[23:51:42] <jmkasunich> tormach/mill
[23:51:51] <jmkasunich> without a plain "tormach"
[23:51:56] <jmkasunich> since you don't want to select that one
[23:54:25] <rayh_> Oh. I guess I'm seeing a tormach with a little + box in front.
[23:54:42] <rayh_> and mill and lathe as leaves under it.
[23:55:24] <rayh_> Your way sounds like the "flat" that SWP was talking about.
[23:55:34] <rayh_> Maybe that's better.
[23:56:46] <jmkasunich> dunno what is better (and don't really have an opinion)
[23:57:02] <jmkasunich> was just wondering if the two pass approach would make the code cleaner
