#emc-devel | Logs for 2009-10-19

[01:32:40] <skunkworks> http://imagebin.ca/img/hTQW13.jpg
[01:57:51] <cradek> I've never seen one so empty...
[01:58:23] <cradek> and that's some serious wire
[01:58:31] <cradek> but no 3 phase??
[02:08:04] <jmkasunich> heh, serious wire?
[02:08:23] <cradek> uh-oh, a wire size contest
[02:08:25] <cradek> hi jmkasunich
[02:08:56] <jmkasunich> http://jmkasunich.com/pics/Lafarge_MotorLug.jpg
[02:09:08] <jmkasunich> 3x500MCM, per phase
[02:09:15] <jmkasunich> hi cradek
[02:09:49] <cradek> hm, need something for scale
[02:09:52] <cradek> what's a MCM?
[02:10:13] <jmkasunich> thousand circular mils - one of those archaic american units
[02:10:48] <jmkasunich> 1 circular mill = the cross section of a wire 0.001" in diameter, 1 million circular mills = the cross section of a bar 1" in diameter
[02:10:50] <cradek> how many zeroes in that other silly american scale?
[02:11:03] <jmkasunich> too many
[02:11:11] <jmkasunich> AWG stops at 4/0
[02:11:21] <jmkasunich> the next size up from 4/0 is 250MCM
[02:12:10] <cradek> I see it says 600KCMIL-2
[02:12:20] <cradek> I think
[02:12:25] <jmkasunich> the lug is rated for 600mcm, but the wires are 500
[02:12:35] <jmkasunich> 500 tends to be the largest commonly used
[02:12:58] <jmkasunich> the increase in current rating when you go from 500 to something larger is much less than the increase in cost
[02:13:28] <jmkasunich> I suspect that 2x250 can carry more current than 1x600
[02:14:49] <skunkworks> wow - the 000 that runs from the outside meter to the breaker box went better than I thought it would.. (think it was 000)
[02:15:07] <jmkasunich> what is your service? 200A?
[02:15:11] <skunkworks> made the 1awg to the house seem easy
[02:15:14] <skunkworks> yes
[02:15:46] <skunkworks> house is going to be run by the 100a breaker
[02:15:55] <jmkasunich> http://www.okonite.com/engineering/nec-ampacity-tables.html
[02:16:02] <jmkasunich> 3/0 is good for 200A
[02:16:59] <jmkasunich> wow, the suck of large wires is even worse than I thought - 2x250MCM is better than one 800MCM
[02:19:30] <jmkasunich> * jmkasunich wanders off to finish reading a book
[02:20:22] <cradek> * cradek goes back to ladder editing
[02:20:34] <skunkworks> heh
[02:20:39] <skunkworks> jm
[02:20:48] <skunkworks> jmkasunich: good to see you around :)
[02:20:53] <cradek> yep
[02:45:21] <skunkworks> 3 phase is only 1/2 a block away :)
[02:45:32] <skunkworks> But I don't need it at the moment. ;)
[02:49:32] <skunkworks> the nieghbor that works for the village was wondering why 3 phase was this side of main street. (we are 2 blocks from main street (small town)) we decided it must be load balancing.
[06:24:44] <micges_work> good morning
[07:08:43] <alex_joni> hi
[12:30:52] <skunkworks_> logger_dev: bookmark
[12:30:52] <skunkworks_> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-19.txt
[12:50:18] <jepler> drat, I missed jmk
[12:50:22] <jepler> skunkworks_: how're you?
[12:52:32] <MOGLI> hey jepler do you have 5 mins?
[12:52:56] <jepler> if you have a question, ask it.
[12:53:41] <MOGLI> may be this is not a proper place to ask.. is it possible to use SAI and RTAI which comes with EMC in MONO ??
[12:54:14] <jepler> I don't know anything about mono.
[12:54:35] <MOGLI> ok anything abt any good ide i can use to develop emc??
[12:54:39] <jepler> the rs274ngc interpreter has a C++ API, so you can interface to them with any language that can use a C++ API.
[12:54:54] <jepler> The way we use RTAI, only C programs can run as realtime software.
[12:55:04] <jepler> I use vim, not an "ide". Again, I'm not the person to make recommendations for you.
[12:55:56] <MOGLI> yaa i know.. but you are much more experienced person so thought to ask you nothing else.. i am new to linux..
[12:56:55] <MOGLI> anyways thanks jepler..
[12:57:10] <jepler> have a nice day
[13:00:48] <skunkworks_> jepler: good.. Think I may actually get the needed projects done before winter. How about you?
[13:01:24] <jepler> skunkworks_: I haven't been up to much interesting lately
[13:06:09] <skunkworks_> I soon hope to have some resemblance of a workshop in the garage. Thinking of getting some cabinates from the local re-store.
[13:06:53] <jepler> sounds good
[13:08:11] <cradek> is that one of those places where you can buy stuff people tore out of other houses? I love those places.
[13:19:14] <jepler> cradek has made some good finds there
[13:26:13] <skunkworks_> yes - we have 2 pretty close by..
[13:29:50] <skunkworks_> one is called 'the restore' and the other I think is 'habitat restore'
[15:30:08] <CIA-82> EMC: 03cradek 07v2_3_branch * r87ff9e32fa89 10/src/emc/kinematics/tp.c: Improve initial threading synchronization
[15:30:59] <CIA-82> EMC: 03cradek 07master * r746ae6a2589a 10/src/emc/kinematics/tp.c: Improve initial threading synchronization
[16:38:21] <jepler> cradek: anything I should write in the debian/changelog for that but the git commit summary?
[16:43:10] <cradek> I don't think so (and, sorry)
[16:44:06] <CIA-82> EMC: 03jepler 07v2_3_branch * r7c9182812868 10/debian/changelog: note new fix
[16:44:15] <SWPadnos> does that change use only the number of revs since synchronization started? (I didn't look at the code to see when the sync_accel variable gets zeroed)
[16:44:26] <jepler> with it being so easy to get a list of changes since the last version, I'm tempted to start putting off changelog-writing until just before release
[16:44:30] <jepler> SWPadnos: yes
[16:44:39] <jepler> I had the exact same question, but I asked in meatspace
[16:44:42] <SWPadnos> heh
[16:44:57] <SWPadnos> not vegetarian-space like the web? :)
[16:45:20] <SWPadnos> it seems like that counter should get reset every so often though
[16:45:43] <SWPadnos> since the spindle could be accelerating, the oldest samples would be more wrong than the newest ones
[16:45:44] <jepler> SWPadnos: it's reset to 1 when the index pulse is seen; it's the same time that revs gets set to 0
[16:45:53] <SWPadnos> ah, ok
[16:46:07] <SWPadnos> so it's emulating the position-interpolated counter feature
[16:46:16] <jepler> cradek: hm, is spindle already at speed when starting to look for index?
[16:46:33] <cradek> jepler: mumble mumble
[16:47:38] <cradek> yes
[16:47:49] <SWPadnos> now why can't I find an inexpensive, lightweight, 17" 1920x1280 display, 8-hour battery life notebook computer?
[16:48:06] <SWPadnos> with a fast CPU
[16:49:18] <cradek> and a pony
[16:49:45] <SWPadnos> a lightweight pony
[16:50:01] <SWPadnos> hmmm. with a pony, the laptop can weigh more. good thinking
[16:51:01] <cradek> thinking you will find a lightweight 8-hour battery is funny
[16:51:15] <cradek> thinking you will find an 8-hour battery is funny
[16:51:34] <SWPadnos> I've gotten very close actually, there's an Acer that only falls short on the screen size/resolution spec
[16:51:50] <SWPadnos> it's $500 or $600, so it's not all that cheap either, but that's not too bad
[16:52:18] <SWPadnos> oh, I forgot that all peripherals should have excellent Linux driver support
[16:56:02] <jepler> I could change 'net' to do this when the first argument given is a pin: http://pastebin.ca/1630210
[16:56:32] <SWPadnos> I don't know if it's worth it
[16:56:51] <jepler> 3 files changed, 29 insertions(+), 15 deletions(-)
[16:57:12] <cradek> nah
[16:57:16] <cradek> (imo)
[16:57:29] <SWPadnos> I guess it would be worthwhile if net would also be able to connect pins to the signal containing a pin
[16:57:30] <jepler> I tend to agree with both of you -- it would tend to muddle things
[16:57:49] <SWPadnos> ie, you do this "net pin1 pin2", and later on you do "net pin1 pin3"
[16:58:07] <SWPadnos> and net sees that there's no sig named pin1, so it looks at the signal pin1 is connected to and connects pin3 to that
[16:58:22] <SWPadnos> or creates a new one if pin1 is not connected
[16:58:34] <jepler> SWPadnos: that's an error as I've written it
[16:58:43] <SWPadnos> ok
[16:58:44] <jepler> net and2.0.out => and2.1.in0
[16:58:44] <jepler> net and2.0.out => and2.1.in1
[16:58:46] <jepler> test.hal:3: Pin 'and2.0.out' was already linked to signal 'n$0'
[16:58:57] <jepler> (it's decided it has to create n$1 since the signal name is unspecified)
[16:59:02] <SWPadnos> right
[16:59:44] <SWPadnos> I guess you could add a check to find the signal with this pin connected before creating the new automatic name
[17:00:23] <SWPadnos> (you already have to find the pin to see if it's connected, so instead of throwing the error, act as though the person meant to spell pin1 as "n$1")
[17:00:49] <SWPadnos> and automatic nets should be deleted as soon as they have no pins connected
[17:00:57] <SWPadnos> (assuming it's worhwhile, that is :) )
[17:01:01] <SWPadnos> +t
[17:02:28] <SWPadnos> hmmm. actually, I think this would be a useful addition
[17:02:50] <SWPadnos> it doesn't prevent ann advanced user from naming everything, and it may help a novice user get going faster/easier
[17:02:53] <SWPadnos> -n
[17:03:22] <jepler> it's very convenient in eagle that I don't have to name every net
[17:04:12] <SWPadnos> indeed
[17:05:44] <SWPadnos> I wonder what to do with signals named like that though, when using show or list
[17:05:58] <SWPadnos> I'd almost want them to be hidden, since they're not "important" to the user
[17:06:06] <jepler> I didn't modify anything about 'show'
[17:06:22] <SWPadnos> right - I'm wondering if there should be a modification
[17:06:40] <jepler> you still need to know there's a connection
[17:06:47] <jepler> maybe you could do something special in the case of 2 pin nets
[17:07:00] <jepler> show the other pin name instead of the artificial net name in 'show pin' and show nothing in 'show sig'
[17:07:26] <SWPadnos> yes, there would need to be something like another type (allnets ...), or an option (-a) to show all of them
[17:07:47] <jepler> hm, as long as users didn't depend on the made-up signal name, this lets me make linkpp just delegate to net for a bigger net removal of code
[17:07:52] <SWPadnos> heh, or go back to the linkpp method of using the pin name as the signal name :)
[17:08:03] <SWPadnos> true
[17:08:12] <jepler> http://pastebin.ca/1630232
[17:09:00] <SWPadnos> it should be an error to use linksp/linkps pin n$###
[17:09:15] <SWPadnos> or at least a warning
[17:11:08] <jepler> ugh, I shudder to try explaining these rules
[17:11:16] <SWPadnos> heh
[17:11:18] <jepler> * jepler gives it up as a bad idea
[17:11:51] <SWPadnos> if I get a chance, I'll write an email to the dev list explaining how I think this should work
[17:12:04] <jepler> you want way too much magic for me to be comfortable
[17:12:07] <SWPadnos> heh
[17:12:29] <SWPadnos> I'm not looking at the code, so it doesn't seem like magic to me :)
[19:24:22] <alex_joni> what's the command for coord rotation?
[19:24:51] <micges> G10 L2 Pn R[angle in degrees]
[19:24:52] <cradek> G10 L2 Px Rddd
[19:25:00] <micges> heh
[19:25:28] <alex_joni> this is only in 2.4~pre .. right?
[19:25:28] <SWPadnos> if you specify XY, that becomes the center of rotation?
[19:25:57] <cradek> SWPadnos: no, the system Px rotates around its own origin
[19:26:08] <SWPadnos> ok
[19:26:22] <cradek> each G5x can have its own separate rotation
[19:26:22] <micges> alex_joni: right
[19:28:25] <alex_joni> cool.. so you can translate to rotation point, rotate, translate back
[19:28:33] <alex_joni> if you want another rotation
[19:28:45] <alex_joni> the translate back is in the rotated coord obviously
[19:30:01] <cradek> say you are at 1,1 and you want the system rotated 45 but you want to still be at 1,1
[19:30:19] <cradek> g10 l2 p1 r45; g10 l20 p1 x1 y1
[19:30:45] <cradek> or at least that's what I think you and swp are asking how to do?
[19:31:50] <cradek> [untested, of course :-)]
[19:34:34] <SWPadnos> ok, I guess if you can always say "this is now 0,0 (or somewhere else)", then it doesn't really matter when the offset is applied
[19:34:34] <SWPadnos> or you need two sets of coordinate offsets
[19:34:49] <SWPadnos> one to offset the center of rotation, and the other to offset the controlled point in the rotated system
[19:51:27] <cradek> I don't think I understand what you said
[19:51:39] <SWPadnos> heh
[19:52:29] <SWPadnos> it's an ordering thing. either the coordinate system origin is offset before the rotation is applied, or it's offset after the rotatip is applied
[19:52:32] <SWPadnos> err
[19:52:33] <SWPadnos> rotation
[19:52:43] <SWPadnos> or possibly both
[19:53:16] <cradek> I understand those give different behaviors - but what was the question?
[19:53:26] <SWPadnos> which is implemented now?
[19:53:36] <cradek> in emc the rotation is around the offset origin
[19:53:57] <cradek> g54's 0,0 does not move as you rotate g54
[19:54:25] <cradek> g54's 1,1 rotates around g54's 0,0
[19:55:08] <SWPadnos> is there a G92-style rotation? (ie, something that is additive with the other coordinate offsets)
[19:55:50] <cradek> no
[19:55:54] <SWPadnos> ok
[19:55:58] <SWPadnos> just curious
[19:56:15] <cradek> there is already enough madness without that
[19:56:33] <SWPadnos> yeah, though I can imagine wanting that particular madness
[19:56:38] <cradek> what would it do?
[19:57:23] <SWPadnos> it would let you correct for non-oriented parts, but still use rotation in other coordinate systems (e.g., to simplify some hand-written G-code)
[19:57:47] <SWPadnos> G92 Oor something like it) would then be "this is how to make X and Y align with my part"
[19:58:09] <cradek> you mean if the part has several g5x systems on it?
[19:58:09] <SWPadnos> and the other rotation features are still available for general use
[19:58:17] <SWPadnos> sure, that's one possibility
[19:58:25] <cradek> for a part within one g5x, the current thing is natural
[19:58:43] <cradek> I guess I think of the different g5x as different fixtures/parts
[19:58:52] <SWPadnos> or even one that's used several times
[19:58:54] <cradek> that's why each should have its own separate rotation
[19:59:10] <SWPadnos> sure, and G92 would then be used for "temporary" offsets
[19:59:17] <jepler> cradek: consider your little toy with "EMC2 AXIS" in 8 orientations
[19:59:27] <SWPadnos> right
[19:59:40] <jepler> cradek: what if you'd also used probing + G10 L2 P1 Rddd to get the part alignment?
[19:59:43] <cradek> the toy had the program in g54, so I rotated g54 8 times
[19:59:46] <SWPadnos> a loop that uses the same XY code with different orientations applied
[20:00:05] <SWPadnos> jepler, exactly
[20:00:30] <cradek> I'm rapidly losing my ability to see how they would all interact
[20:01:13] <SWPadnos> I imagine workpiece orientation being more useful for large machines / workpieces. imagine trying to rotate a 1-ton block 0.5 degrees
[20:01:29] <SWPadnos> not necessarily lazy people with little machines
[20:01:50] <jepler> that's why we need opengl-style composition of transformations with a stack
[20:01:54] <cradek> SWPadnos: I guess I don't see how the current system is inadequate
[20:01:58] <jepler> then it's all very easy to understand
[20:02:54] <SWPadnos> well, it would be hard or impossible to orient to a slightly rotated workpiece and also carve four fleur-de-lis patterns using a loop and G5x coordinate system rotation
[20:02:55] <jepler> cradek: it's possible to get all the combinations of a Z rotation and a translation, but if the natural way to build them is by "stacking" then it's not so easy to fit it in
[20:03:16] <SWPadnos> which are "correctly" oriented to the part
[20:04:20] <jepler> or like postscript gsave / grestore / rotate / translate
[20:04:51] <SWPadnos> I bet it would work fine with a predefined "stack", it's just thinking about it that hurts :)
[20:05:34] <jepler> well, there's the zero-one-infinity principle..
[20:06:02] <cradek> with gcode you need the whole stack invertible for things like g53. it's a swirl.
[20:07:11] <jepler> oh that's easy in postscript. gsave matrix setmatrix ... grestore
[20:07:16] <jepler> (I think, anyway)
[20:08:53] <jepler> I should write ungcode
[20:09:17] <jepler> (whatever exactly it is, it's unlike gcode at every turn)
[20:25:32] <skunkworks_> http://cgi.ebay.com/CNC-MILL-MORI-SEIKI-JUNIOR_W0QQitemZ150379237126QQcmdZViewItemQQptZBI_Mills?hash=item23034d0f06
[20:26:43] <jepler> hm, it's damaged enough to get the handicap spot in the parking lot?
[20:26:46] <cradek> uh that's no fanuc
[20:27:09] <cradek> jepler: is "it got damage" like "he got told"?
[20:27:25] <jepler> could be
[20:27:30] <skunkworks_> :)
[20:27:37] <jepler> I'm not hip to the way kids these days speak
[20:29:43] <cradek> I will use my super powers to predict the future: it won't sell at that price
[20:31:44] <skunkworks_> where is LB in the US? feeling a bit dense.
[20:31:52] <SWPadnos> Las Begas
[20:32:14] <SWPadnos> (I wondered the same thing)
[20:32:14] <cradek> louisibana
[20:32:31] <SWPadnos> Lower Brooklyn
[20:32:40] <skunkworks_> ah
[20:32:47] <skunkworks_> sounds good
[20:32:49] <jepler> Did you mean:
[20:32:49] <jepler> L B J, San Antonio, Bexar, TX 78253
[20:32:58] <SWPadnos> Here's one for JMK: http://cgi.ebay.com/Miyano-KSV-35-CNC-Vertical-Machining-Center-20-pos-ATC_W0QQitemZ110447564250QQcmdZViewItemQQptZBI_Mills?hash=item19b73015da
[20:33:05] <SWPadnos> almost next door
[20:33:20] <cradek> skunkworks_: I just saw one go for $2200 - it was working and in daily use (except tool changer was broken)
[20:33:26] <cradek> it was ebay but I can't find the auction now
[20:33:56] <skunkworks_> he keeps whining about how he doesn't have room for stuff like that. I think he could disassemble it and put it in his basement.
[20:34:09] <skunkworks_> cradek: wow
[20:34:11] <skunkworks_> :)
[20:34:13] <SWPadnos> at soem point, it gets easier to lift the house instead
[20:34:16] <SWPadnos> some
[20:34:33] <skunkworks_> good time to buy
[20:34:57] <cradek> yep no kidding
[20:35:28] <cradek> 'in daily use, come see it under power' is sure worth a lot
[20:35:42] <SWPadnos> here's a Stuart-sized machine: http://cgi.ebay.com/Monarch-VMC-150B-3-Axis-CNC-Mill-w-GE-Fanuc-15M-Control_W0QQitemZ400079113577QQcmdZViewItemQQptZBI_Mills?hash=item5d2692cd69
[20:35:58] <SWPadnos> err - Stuart-shop-sized anyway :)
[20:36:06] <cradek> yeah he's not anywhere near that big
[20:36:16] <SWPadnos> not last time I saw him anyway
[20:38:39] <cradek> aha http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=180417160243
[20:39:29] <skunkworks_> unreal.
[20:39:47] <skunkworks_> do you have room for a parts jr?
[20:39:59] <cradek> not if I want the car in the garage
[20:41:01] <cradek> weird. I could have sworn this auction said the tool changer broke (mechanically) so they swiped a circuit board out of it to fix another machine
[20:41:22] <cradek> oh, found it (view all questions)
[20:41:31] <cradek> "The tool changer had mechanical problems, then we stole the circuit board to use in another machine. I think the circuit board cost over $3,000."
[20:42:43] <skunkworks_> cradek: how much did your tool changer board cost ;)
[20:43:02] <cradek> heh
[20:43:28] <cradek> I spent about $600 for all the computery stuff
[20:45:01] <skunkworks_> and it probably turns circles around the original control.
[20:45:15] <cradek> guts of the tool changer: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=200351796226
[20:45:16] <skunkworks_> and tweekable
[20:45:57] <cradek> my tool changer logic is superior to the original. it cannot lose the position of the turret no matter what it does.
[20:46:14] <alex_joni> what irssi version do you guys use?
[20:46:18] <cradek> afaik that may be the only major improvement
[20:46:40] <cradek> 15:46 -!- Irssi: Client: irssi 0.8.12 (20071006 0939)
[20:46:46] <cradek> * cradek shrugs
[20:46:52] <alex_joni> irssi 0.8.12-3ubuntu3.1
[20:46:55] <cradek> I never worried about it - I'm sure they're all fine
[20:47:06] <alex_joni> mine has a serious bug
[20:47:12] <alex_joni> it doesn't properly wrap long links
[20:47:24] <cradek> are you sure it's not your terminal?
[20:47:36] <alex_joni> it's running in screen
[20:47:40] <alex_joni> * alex_joni shrugs
[20:48:54] <alex_joni> on the second line where it should wrap, I get text from another page/channel
[20:49:16] <cradek> an I finally see the damage in that photo - looks like it fell over onto the X motor (!)
[20:51:46] <cradek> the square sticking out under the table on the right side
[20:52:07] <cradek> I'd think it would have snapped the motor off and rolled right over, though
[21:02:04] <CIA-82> EMC: 03mshaver 07master * r6bd4fe3a8fc1 10/configs/smithy/ (622gecko.hal 622gecko.ini): Extend .ini and .hal files for the Geckodrive powered 622 Mill to account for variations in early production wiring
[21:02:04] <CIA-82> EMC: 03mshaver 07master * r27ce60afe325 10/ (18 files in 13 dirs): Merge branch 'master' of ssh://mshaver@git.linuxcnc.org/git/emc2
[21:02:51] <cradek> mshaver: jepler is working on releasing another 2.3 soon... is smithy stuff in v2_3_branch what you want?
[21:03:08] <cradek> oh I forgot - you guys do your own thing - forget it
[21:03:22] <mshaver> no.I mean it's only in TRUNK
[21:03:54] <cradek> do you give a snapshot of trunk to smithy users?
[21:04:03] <mshaver> what did that second report from CIA mean, "Merge branch 'master' ..."
[21:04:31] <mshaver> actually, we make a separate .deb that they install with our configs
[21:04:42] <cradek> that means you made your changes based on an out of date pull of master, and so at that point history branched. your merge brings that split back together.
[21:05:09] <cradek> you can avoid that by using rebase (which means roughly: pretend I made these changes based on the latest master by replaying my changes on top of others')
[21:05:13] <mshaver> that's OK? (good?)
[21:05:33] <mshaver> I did pull first
[21:05:35] <cradek> it's fine - whether it's good is a holy war
[21:05:47] <cradek> 'pull --rebase' probably would have avoided the merge
[21:06:02] <mshaver> OK, I'll do that in the future
[21:07:37] <mshaver> should we put the (now fairly stable) Smithy configs in this update of 2.3? or maybe in 2.4?
[21:08:08] <cradek> I think there's no problem adding configs to 2.3 if that's what you want to do
[21:08:40] <jepler> this is a nice idea assuming that they are actually tested again st.2.3
[21:08:47] <jepler> ow my words
[21:08:55] <mshaver> So, is there an explanation of how to do that in the wiki git page?
[21:09:00] <cradek> well that's a good point
[21:09:25] <mshaver> our customers are hooked up for auto updates & use the stock emc released version
[21:09:41] <cradek> oh ok, so they are using 2.3, good
[21:10:00] <jepler> there's nothing more elegant to do than copy the files into a 2.3 checkout, test package building, add, commit, and push the result.
[21:10:47] <mshaver> I'll look into this...
[21:33:11] <mshaver> when I switch to the 2.3 branch, by config directory disappears. when I go back to master it reappears. where does it go???
[21:33:51] <mshaver> even ls -al doesn't show it as hidden...
[21:35:45] <micges> they are in git database, and they're crated if needed
[21:36:14] <mshaver> it happens fast...
[21:36:23] <cradek> git is surprisingly fast at everything
[21:36:47] <mshaver> Where is the actual database?
[21:36:53] <cradek> .git
[21:37:02] <mshaver> Ah, ok!
[21:37:20] <cradek> you have the entire history of all branches of the project. you can recreate ("checkout") any of them
[21:39:13] <CIA-82> EMC: 03mshaver 07v2_3_branch * rd026f6f7102e 10/configs/smithy/ (30 files): Adding the smithy config files to the version 2.3 branch.
[21:39:36] <mshaver> OK, that should've done it!
[21:39:48] <cradek> sure looks likely
[21:40:14] <mshaver> Ugh, now back to drawing :(
[22:33:16] <jepler> if the buildbot hasn't complained by now, it must be right
[22:38:09] <dgarr> I've written a gui frontend for emc single-file subroutine files which i think is pretty easy to use.
[22:38:22] <dgarr> i would be interested in some feed back from anyone testing (simulator ok)
[22:38:55] <dgarr> description http://www.panix.com/~dgarrett/ngcgui/ngcgui.txt
[22:39:09] <dgarr> screenshot http://www.panix.com/~dgarrett/ngcgui/ngcgui.png