Back
[00:45:54] <fenn> please dont require gnome for emc
[00:56:35] <fenn> or X
[01:00:28] <SWPadnos> right now, X is a dependency of the EMC .deb
[01:00:49] <SWPadnos> neither X nor gnome should ever be required for a compiled version
[01:00:54] <SWPadnos> IMO
[01:01:01] <fenn> actually, i dont think it is (or at least it wasnt two years ago)
[01:02:53] <SWPadnos> oh - could be
[01:03:25] <SWPadnos> I don't see X in the immediate depends, though I'd think that some of the tk items would pull in X for you
[01:03:30] <fenn> tk requires libx11 which requires x11-common which appears to be just some filesystem stuff
[01:04:54] <fenn> is there some tool for examining package dependencies that's better than synaptic or debconf?
[01:05:08] <SWPadnos> probably, but I don't know what it is
[01:05:10] <fenn> right now i'm looking at 'apt-cache show'
[01:05:46] <SWPadnos> jmkasunich - first run of the poke program hard-locked the PC :)
[01:05:50] <SWPadnos> woohoo!
[01:06:03] <fenn> that's how you know it's working
[01:06:21] <SWPadnos> but some of the LEDs did shut off, which is a good-ish thing
[01:08:00] <jepler> fenn: at this point I think configure requires some X devel stuff to be present, as does the runscript. nothing that somebody capable of putting together an xless distro couldn't handle, and if he sends patches I'd likely want to see them incorporated
[01:09:15] <jepler> this business about gnome is for a particular GUI tool, but because we make the emc package monolithic it'll be a requirement for anyone who installs the official .deb package -- but if you want an xless distro you are probably not starting with ubuntu, "server install CD" notwithstanding
[01:10:48] <fenn> right, but the .deb is still useful for other situations
[01:11:04] <fenn> like that guy in brazil for example
[01:12:11] <fenn> what's the main advantage to using the wizard widget?
[01:12:28] <jepler> it automatically does .. stuff
[01:13:01] <jepler> it does the right layout of the screen so that it looks like other gnome wizards -- so user experience is better
[01:13:24] <fenn> better eh
[01:15:00] <jepler> bbl
[01:27:07] <fenn> i can't even get glade to tell me why it's crashing because i dont have gnome-desktop properly installed for bug-buddy argh
[02:16:55] <jepler> fenn: visualize deb dependencies with graphviz:
http://netthink.com/archives/date/2007/04
[02:17:12] <jepler> "To start, I wrote a simple script in Ruby (my first Ruby program) to recursively call "apt-cache depends" beginning with the debian package of our choice. The script results are a recursive list of package dependencies output in DOT graph format, which you can then enter into Graphviz to create your graphs."
[02:17:34] <SWPadnos> heh - that's cool :)
[02:18:51] <jepler> looks like his example .svg files are served with the wrong doctype or something, but they display in eog after download (I tried the gnome one)
[02:21:47] <SWPadnos> I did figure out what I did wrong to cause the hardlock - it helps to write to one of the regions that goes to the FPGA instead of writing to the PLX9054 control area
[02:41:26] <jepler> any method to choosing FERROR / MIN_FERROR values for stepper systems?
[02:42:25] <cradek> some small number of steps maybe?
[02:42:32] <SWPadnos> more than one step
[02:43:08] <SWPadnos> there may be a way of calculating it based on the ratio of BASE to SERVO periods plus accel and maxvel
[02:43:26] <jepler> is there some harm in making the values too large?
[02:43:27] <SWPadnos> but I really don't want to think about that right now :)
[02:44:05] <SWPadnos> I bet there isn't
[02:44:07] <jepler> truly huge (e.g., 1") and obviously you'll start to hide insufficient step rate
[02:44:16] <SWPadnos> as long as - right
[02:44:40] <jepler> right now stepconf simply has hardcoded values, not even dependent on machine units
[02:44:45] <jepler> print >>file, "FERROR = 0.050"
[02:44:45] <jepler> print >>file, "MIN_FERROR = 0.010"
[02:44:48] <SWPadnos> there still needs to be some way of telling the user that they can't do what they want if they configure a speed that the base period cn't manage
[02:45:04] <cradek> jepler: those might be a bit small for mm
[02:45:20] <SWPadnos> I'd just take 5 or 10 steps and round up to the nearest "round" number
[02:46:17] <jepler> for now I'll put 1 / .25 for mm
[02:46:51] <SWPadnos> ferror is checked before outputting a new position, right?
[02:47:48] <jepler> I have to read the source every time I want to know the details
[02:47:51] <SWPadnos> heh
[02:48:07] <SWPadnos> I'd have to figure out how to read it, so you're at least one ahead of me there
[02:49:52] <SWPadnos> cradek:
http://www.wikihow.com/Convert-a-Computer-ATX-Power-Supply-to-a-Lab-Power-Supply
[02:50:28] <fenn> but then what are you going to use all those AT supplies for?
[02:50:40] <jepler> Note that in the GIT newspeak, the operation being performed by cg-update is now called pull, even though in the past, pull was the name for the operation being now done by cg-fetch, which is even still aliased to cg-pull. Please do not let this confuse you. (Cogito won't call this update operation pull, since about everyone but GIT and BK users uses it in the fetch meaning.)
[02:50:46] <jepler> </documentation>
[02:50:48] <jepler> well *now* I am enlightened
[02:50:57] <SWPadnos> heh
[02:51:29] <SWPadnos> obviously you're not a BK user
[02:52:31] <jepler> It's been about 6 years since I ate there
[02:52:35] <jepler> maybe more
[02:52:41] <SWPadnos> he
[02:52:43] <SWPadnos> h
[02:55:42] <jepler> http://git.unpy.net/view?p=stepconf.git;a=commitdiff;h=313fe88353356ae87c3125882181b24e65038686;hp=c5dff0d5569c3fe987ef7e7aee4de548ea2ac530#patch2
[02:55:56] <jepler> ^^^ git even properly represents the change in file modes when I decided to make stepconf.py executable
[02:56:51] <SWPadnos> nice
[02:56:54] <cradek> cool
[02:57:04] <cradek> you can do that with cvs - just change the permissions on the rcs file
[02:57:10] <cradek> (*ahem*)
[02:57:35] <SWPadnos> but will CVS notice that and log the change?
[02:57:41] <cradek> uh
[02:57:49] <cradek> not even close, no
[02:57:55] <SWPadnos> didn't think so :)
[02:57:55] <cradek> I was kind of joking
[02:57:59] <jepler> the permissions beome different through all of time
[02:58:03] <jepler> become
[02:58:16] <fenn> just curious, why didnt you switch to svn when moving away from sourceforge?
[02:58:23] <SWPadnos> because
[02:58:34] <cradek> jepler: will you check in stepconf soon?
[02:58:46] <jepler> cradek: yes, soon
[02:58:57] <cradek> fenn: please read the archives if you're curious about historical arguments
[03:14:20] <jepler> 'night all
[03:14:49] <SWPadnos> see you. it is getting late, isn't it?
[04:37:12] <fenn> the dependency visualizer doesnt actually draw all the dependencies...
[12:18:37] <jepler> I'm torn about using "spinbuttons" (those entry fields with up/down arrows at the right-hand side) in stepconf
[12:18:46] <jepler> on the one hand, that seems to be the gtk way of restricting a field to contain a number
[12:19:06] <jepler> on the other hand, it means I have to choose minimum and maximum acceptable values for each field
[12:20:00] <jepler> on the third hand, I should go to the office
[12:20:17] <Guest222> heh
[12:20:33] <Guest222> Guest222 is now known as skunkworks__
[12:20:35] <SWPadnos> on the gripping hand, well, I don't know
[12:24:21] <skunkworks__> skunkworks__ is now known as skunkworks_
[12:33:11] <SWPadnos> so, does anyone have an opinion on whether I shuold commit this PCI utility that lets you hardlock your machine pretty easily?
[12:33:31] <skunkworks_> normally - that is called a virus..
[12:33:33] <SWPadnos> though it does require a MESA card
[12:34:01] <skunkworks_> a very specific virus..
[12:34:10] <SWPadnos> viruses don't generally have rights to hardlock Linux computers :)
[12:34:18] <skunkworks_> heh
[12:34:24] <SWPadnos> but this gets setuid, so it's easier ;)
[12:35:11] <skunkworks_> any ideas on why it is doing it?
[12:35:32] <SWPadnos> yes - it works as designed (worked first time, I think)
[12:35:51] <SWPadnos> but if you tell it to write the wrong thing to the wrong place, the machine can lock
[12:35:54] <SWPadnos> completely
[12:36:05] <skunkworks_> ah - cool - I think ;)
[12:36:15] <SWPadnos> I discovered this by writing the wrong thing to the wrong place the first time I used it :)
[12:39:36] <jepler> SWPadnos: is it useful when you aren't running it with the wrong arguments?
[12:40:55] <SWPadnos> yes
[12:41:26] <alex_joni> then I guess you should stop writing the wrong things :P
[12:41:34] <SWPadnos> I can probably restrict it to only write to RAM and user regions, which should make it less likely to hardlock the PC
[12:42:19] <SWPadnos> though it could be more useful the way it is - it could be used to change PCI bridge options
[12:51:36] <jepler> I am sure there are already plenty of ways you can lock your system up if you have the power to run setuid binaries that come with emc2
[12:51:56] <jepler> (halcmd loadrt threads period1=1000 and so on)
[12:52:06] <SWPadnos> true
[12:52:15] <SWPadnos> I'll add some comments and commit it then
[12:52:35] <SWPadnos> in a sense, it forms the backend for a generic PCI card tester
[12:52:45] <SWPadnos> except that you can't read from the card ;)
[13:00:17] <SWPadnos> so, this program is primarily of use to developers (of FPGA configs), any preference as to where it should go?
[13:01:06] <cradek> jepler: what values are you considering putting in spinbuttons?
[13:01:19] <SWPadnos> the source is currently in hal/utils (along with bfload), and I currently have the executable going to the bin dir
[13:04:59] <jepler> cradek: all the numeric ones with the exception of parport address because spinbuttons can't seem to show numbers in hex
[13:05:39] <SWPadnos> heh
[13:06:05] <SWPadnos> I found that scanf "%u" also doesn't seem to like hex
[13:06:13] <cradek> don't spinbuttons just take integers?
[13:06:34] <SWPadnos> 0x378 is an integer
[13:06:51] <cradek> right but scale isn't
[13:06:57] <SWPadnos> true
[13:07:04] <jepler> no, these can contain floating-point numbers
[13:08:36] <jepler> dargh, I also have to choose the number of digits to display
[13:09:05] <SWPadnos> use another spinbutton for that
[13:09:07] <cradek> just use text entry widgets?
[13:09:09] <SWPadnos> * SWPadnos ducks
[13:09:24] <jepler> cradek: well, that's where I started
[13:09:27] <cradek> can't you just validate them when the user hits next?
[13:10:03] <cradek> nobody is going to enter Input Scale: PANTS
[13:10:15] <alex_joni> you sure?
[13:10:21] <SWPadnos> robin would
[13:10:26] <cradek> if they do, you should tell them they screwed up
[13:10:27] <jepler> I would, just to see what happens
[13:10:32] <cradek> sure
[13:10:52] <jepler> naive me, I figured that using the gtk widget specifically for the purpose of accepting a numeric value would be the easiest way to "validate" these fields
[13:11:10] <SWPadnos> just because of this discussion, PANTS should now be a special keyword in stepconf, which means ... 42
[13:11:50] <SWPadnos> or e or pi or something
[13:11:59] <jepler> so-o-o -- how many digits after the decimal point should I allow for "Motor steps per revolution"?
[13:12:14] <SWPadnos> 4
[13:12:23] <cradek> 0?
[13:12:36] <SWPadnos> no, it's got to be float
[13:12:46] <cradek> ?
[13:12:47] <SWPadnos> is the backend python?
[13:12:56] <SWPadnos> err - nevermind
[13:12:58] <SWPadnos> 0 is fine
[13:12:58] <cradek> what motor has a non-integer number of steps?
[13:13:06] <cradek> * cradek squints at SWPadnos
[13:13:19] <SWPadnos> I was thinking UNITS, forgetting that this app calculates that for you ...
[13:13:28] <SWPadnos> err INPUT_SCALE
[13:13:43] <SWPadnos> by the way, can we please change INPUT_SCALE to OUTPUT_SCALE for stepper systems???
[13:14:29] <SWPadnos> especially with all the questions about steppers+encoders lately, it's likely to be a point of confusion
[13:15:35] <jepler> as far as I can tell from a bit of grepping, INPUT_SCALE isn't actually used in "the core" anymore, it's just used in hal files
[13:15:52] <SWPadnos> right - hal and ini
[13:16:06] <alex_joni> how about SCALE ?
[13:16:12] <cradek> I thought one or more guis read that value for some debatable reason
[13:17:04] <jepler> they can be fixed to follow the new standard with fallback
[13:17:06] <alex_joni> for jogging something
[13:17:12] <jepler> at least the ones that are actively maintained and live in the source tree
[13:17:29] <SWPadnos> xemc uses it to set the smallest jog increment
[13:17:39] <cradek> ok, simple to fix
[13:18:00] <jepler> I think axis uses it to decide the lowest useful jog speed
[13:18:05] <SWPadnos> the lintini.py script checks it
[13:18:14] <jepler> you're supposed to be able to get 1 step per second
[13:18:58] <SWPadnos> iniaxis.cc still refers to it, but I think that line is in a comment
[13:23:59] <SWPadnos> hmmm. any idea what went wrong if I have a zillion .o and .mod.[co] files in my emc/src directory?
[13:24:11] <alex_joni> nothing ?
[13:24:38] <SWPadnos> shouldn't those be in objects/ or something?
[13:24:45] <alex_joni> can't help that
[13:25:05] <alex_joni> they get created in the dir from where the build invokes the build in the kernel dir
[13:25:13] <SWPadnos> ok - I just don't remember seeing that stuff in src/
[13:25:13] <alex_joni> and you have to use relative paths to that dir
[13:25:21] <alex_joni> try make clean :P
[13:25:29] <SWPadnos> heh
[13:43:26] <jepler> SWPadnos: kbuild shits those in working directory and I don't know how to fix it
[13:43:27] <cradek> yeah that's a "feature" of kbuild
[13:43:44] <jepler> (or alongside the source file as the case may be)
[13:43:46] <SWPadnos> ok - no problem. I just didn't remember seeing that before
[13:56:25] <alex_joni> seems you didn't compile emc2 in a long time :P
[13:59:27] <skunkworks_> cradek:
http://www.cnczone.com/forums/showpost.php?p=340975&postcount=13
[13:59:44] <skunkworks_> maybe PM him and see how much he wants.
[14:01:02] <jepler> prime minister him?
[14:01:11] <jepler> is that some kind of slang or double-entendre?
[14:01:16] <skunkworks_> heh
[14:01:21] <skunkworks_> private message
[14:02:09] <skunkworks_> any updates on the bot?
[14:02:52] <cradek> if I do, he'll think I'm trying to steal them from you
[14:03:56] <jepler> I got a dial indicator and measured that the table varies by 0-10 on X and 0-5 on Y (mils, I think) .. then I broke the dial indicator mounting trying to reposition it and didn't touch the machine the rest of the weekend
[14:04:30] <skunkworks_> heh - I could private message him and tell him to look for you PM
[14:04:39] <skunkworks_> if you are interested
[14:05:02] <skunkworks_> jepler: ouch. I know how you feel.
[14:05:27] <cradek> what part did you break?
[14:06:17] <cradek> "Hi, it's my mill that Sam is asking about. He pointed me to your message. ... "
[14:06:38] <jepler> cradek: I bent out the claws that hold the ball in
[14:07:47] <skunkworks_> cradek: sure - If he has any doubts - He can always pm me and ask..
[14:07:57] <cradek> skunkworks_: I sent it, thanks
[14:08:41] <cradek> wouldn't kill me to have his spare amps too
[14:09:12] <skunkworks_> right
[14:39:21] <SWPadnos> strange - no commit message / cia message from my earlier commit
[14:39:41] <SWPadnos> but the files are in CVS
[14:40:04] <cradek> /var/spool/mqueue is empty
[14:40:04] <cradek> Total requests: 0
[14:40:14] <cradek> it'll come I bet
[14:40:49] <cradek> was it 08:36?
[14:41:02] <cradek> 1+ hour ago
[14:41:03] <SWPadnos> ok - cia works from a mail also (?), so upstream mail server problems would affect both
[14:41:06] <SWPadnos> yes, sounds right
[14:41:41] <cradek> I don't see any sign of problem on our end
[14:41:59] <SWPadnos> have you gotten the message?
[14:42:15] <SWPadnos> err - received the commit message :)
[14:42:57] <cradek> no
[14:43:00] <cradek> brb
[14:43:54] <SWPadnos> ok
[16:24:33] <skunkworks_> hmm - must have lost internet at home..
[16:31:10] <alex_joni> wonder where it went
[16:33:38] <skunkworks_> more likely - the wife unplugged the laptop ;)
[16:34:19] <alex_joni> they seem to do that, don't they
[16:35:20] <skunkworks_> alex_joni: vacation was good?
[16:35:47] <alex_joni> yeah, but after the day I had today, it's long forgotten :D
[16:35:58] <skunkworks_> yeck
[16:36:28] <alex_joni> yeah :D
[16:36:30] <skunkworks_> or was the day so good that it made your vacation look like work? ;)
[16:36:37] <alex_joni> haha, I wish
[16:43:01] <rayh> Is there a handy way to tell EMC that an axis is not homed any more?
[16:43:34] <cradek> nope
[16:43:47] <rayh> Didn't think so.
[16:44:09] <tomp2> Is there a any way to tell EMC that an axis is not homed any more?
[16:44:31] <rayh> start homing then estop
[16:45:03] <cradek> heh, I wouldn't have thought of that, but I bet it works
[16:45:05] <rayh> I don't think abort even works on homing these days.
[16:45:16] <cradek> yes it does
[16:45:38] <rayh> I thought I hit abort during a home and nothing happened.
[16:46:23] <cradek> how sure are you? I'm pretty sure it works.
[16:46:37] <rayh> Okay. I believe you...
[16:46:59] <rayh> I thought both it and feed override were locked out during home
[16:47:35] <cradek> I tested abort and it works fine
[16:47:45] <rayh> Thanks
[16:47:51] <cradek> welcome
[16:50:20] <alex_joni> heh, that's a crazy idea :)
[16:50:22] <alex_joni> * alex_joni likes it
[16:53:34] <rayh> Hi alex
[16:54:00] <rayh> The question was why does an estop not cause the loss of home position.
[16:54:55] <skunkworks_> I would think that would only be a problem on a non closed loop system
[16:54:59] <cradek> my bridgeport makes me rehome after estop, but I don't know why it should
[16:55:12] <cradek> as long as the encoders have power I don't see why position would be lost
[16:55:24] <jepler> because some machines can keep position over estop? (i understand that many can't, either because they're open loop or the encoders are among the things that lose power in an estop)
[16:55:46] <rayh> I think most machine tools require home after estop.
[16:56:08] <cradek> that aside, can you say why? I don't see why it's always necessary
[16:56:46] <rayh> Um, no.
[16:57:13] <rayh> With steppers I'd guess that they don't ramp down and can loose steps.
[16:57:31] <cradek> yes steppers will definitely lose position if you turn off the drivers
[16:57:34] <rayh> But that is one of those things that should be configurable by parameter so such.
[16:58:01] <rayh> or such integrator configuration variable
[16:58:06] <jepler> maybe there should be a 'position lost' input to axis.N; then an integrator would have the freedom to make estop (or other things) unhome an axis
[16:58:10] <skunkworks_> Estop_resethome
[16:58:21] <cradek> I think I agree with jepler
[16:58:33] <skunkworks_> sweet
[16:58:42] <cradek> for instance you could hook /amp-enable to it
[16:59:09] <cradek> because for my stepper mill, it's NOT estop that causes (potential) loss of position, it's amp-enable off
[16:59:29] <rayh> Right
[17:00:18] <cradek> lunchtime!
[17:00:19] <jepler> yay!
[17:00:26] <alex_joni> heh
[17:00:28] <alex_joni> hi ray
[17:00:37] <rayh> How you doing Alex
[17:01:00] <alex_joni> pretty nice, just finished vacation
[17:01:15] <rayh> Sounds great.
[17:01:25] <rayh> How is the family?
[17:01:26] <alex_joni> weeell.. vacation was nicer
[17:01:36] <alex_joni> all is well, thanks for asking
[17:01:54] <alex_joni> I hope the same on your end?
[17:02:09] <rayh> rather vacation then end-of-vacation 'eh.
[17:02:13] <rayh> Doing well.
[17:02:46] <rayh> Only one kid in crisis and that's her own making... job change.
[17:03:16] <skunkworks_> rayh: you have kids? I didn't know that.
[17:05:46] <rayh> 4
[17:05:57] <rayh> grown and mostly gone.
[17:08:23] <skunkworks_> its the ones that keep coming back you have to worry about ;)
[17:09:05] <SWPadnos> and their friends ;)
[17:09:19] <rayh> I still like em a lot even most of the friends.
[17:09:45] <SWPadnos> heh
[17:09:53] <skunkworks_> are any of them into cnc?
[17:10:02] <rayh> Hi Steven.
[17:10:07] <SWPadnos> Sharon was very happy with the way you interacted with your granddaughter, FWIW :)
[17:10:08] <SWPadnos> hi Rau
[17:10:12] <SWPadnos> Ray
[17:10:47] <rayh> I answer to most any name.
[17:11:09] <skunkworks_> My father was a totally different person after the grand-kids. Hi dad ;)
[17:11:18] <rayh> Hey granddaughter is taking horse riding lessons.
[17:11:30] <SWPadnos> cool. one of my nieces is very into horses as well
[17:11:49] <rayh> Tell Sharon hi and thanks.
[17:12:00] <SWPadnos> she's taking horse acrobatics classes - the kind you'd need to join a circus
[17:12:02] <SWPadnos> will do
[17:25:28] <rayh> I'm trying to remove my admin status at sf. It says, " Project administrators are not permitted to remove their own admin status. Please have another administrator on your project remove your admin status,"
[17:25:39] <SWPadnos> heh
[17:25:45] <SWPadnos> it's a race condition
[17:25:55] <rayh> Don't everyone trip over each other helping me.
[17:27:03] <rayh> I would appreciate it if one with the ability would do that for me.
[17:27:30] <SWPadnos> hopefully one of those who's used to adminstering SF stuff can do that :)
[17:29:27] <rayh> If you are logged in you can administer members. click on my name and tick the admin box.
[17:31:14] <alex_joni> I can do that ray
[17:31:31] <alex_joni> any reason for it?
[17:39:37] <alex_joni> brb
[17:39:41] <alex_joni> rayh: done
[17:40:51] <rayh> Hey thanks. Now I can rag on the rest of the "dead" admins to get themselves conformed to the current state of the project at SF.
[19:21:52] <jepler> After it knows which pins an axis are on, seems like a SMOP to let the user test an axis while varying the accel and vel constraints:
http://emergent.unpy.net/files/sandbox/stepconf-test-axis.png
[19:23:28] <jepler> when you press "Go" it will begin commanding a trapezoidal-profile move around the current position according to these limits and the scale specified elsewhere
[19:25:30] <alex_joni> any reason for trapezoidal?
[19:26:13] <alex_joni> I suppose you use siggen for the signal
[19:27:13] <jepler> well, maybe I can do it with a combination of existing components
[19:27:48] <jepler> but at the larger level I need something that takes as inputs "Go", "Jog-", "Jog+", "Accel", "Vel", "Test Area" and gives as outputs "Step" and "Direction"
[19:28:29] <alex_joni> it sounds like siggen to me
[19:28:34] <alex_joni> test area = amplitude
[19:28:52] <jepler> yes, a square wave from siggen plus accel/vel limiting in limit3 or stepgen is not far off
[19:28:53] <alex_joni> but I'd use sine (much smoother profile)
[19:29:10] <alex_joni> or that
[19:29:35] <jepler> in some sense I don't want a smooth profile -- I want a profile similar to the one emc will throw at it
[19:32:28] <alex_joni> a sine position corresponds to what emc outputs imo
[19:32:46] <alex_joni> or is that better than limited accel?
[19:33:16] <alex_joni> limited accel = triangle velocity profile = sine position profile
[19:33:19] <alex_joni> bbl
[19:38:29] <jepler> I mean trapezoidal velocity profile
[19:38:36] <jepler> but I don't think that's sine position profile
[19:38:39] <jepler> it's .. something else
[19:39:11] <jepler> a section of a parabola, followed by a constant-slope line, followed by some other more different section of parabola
[20:14:53] <cradek> SWPadnos: you saw those compile problems right?
[20:49:11] <alex_joni> jepler: if it's small enough you can use a sine instead
[20:49:33] <alex_joni> I mean, that's what I use when I first try to spin a stepper
[21:02:30] <cradek> skunkworks_: that guy wants $50 to copy the manual!
[21:03:47] <skunkworks_> ew
[21:03:52] <skunkworks_> ewww
[21:03:53] <cradek> skunkworks_: he also implies in his message that the drives are worth $350 or more, each
[21:04:06] <skunkworks_> well - it takes all kinds I guess
[21:05:55] <SWPadnos> sorry - back now
[21:06:23] <SWPadnos> crap
[21:06:39] <cradek> forgot to add a file maybe?
[21:07:33] <SWPadnos> no, I was going to split some common info into a header, and I forgot to remove the include when I decided against it
[21:12:14] <SWPadnos> well, CIA seems to be working again
[21:16:05] <cradek> the farm will have to make clean, or someone will need to remove the bogus .d file
[21:16:09] <jepler> curse that stupid build system deficiency
[21:16:18] <SWPadnos> I guess we'll see what happens :)
[21:16:18] <cradek> seems like it sometimes cleans, I don't know what causes it
[21:16:36] <jepler> I think some builds are done with "clean" first and others aren't ..
[21:16:41] <alex_joni> wasn't it a build fail that makes it clean?
[21:16:48] <SWPadnos> I thought that was added
[21:17:07] <SWPadnos> it probably should make clean on the build after a failure
[21:17:13] <SWPadnos> (if it doesn't already)
[21:17:17] <cradek> maybe it does
[21:17:46] <jepler> if so it would have cleaned after the earlier failed build
[21:17:53] <SWPadnos> that was my thought
[21:22:50] <jepler> git is soooo nice to use. since everything but push & pull is local, it's all very fast.
[21:23:01] <jepler> I'm not sure how it works when multiple developers all "push" to the same master
[21:23:34] <SWPadnos> hmmm. that's a good question
[21:23:36] <jepler> another shortcoming is that unlike cvs it's not an essentially monolithic binary -- in fact a lot of it is shell scripts, with some python and/or perl thrown in for good measure.
[21:23:52] <SWPadnos> the Linux kernels have a gatekeeper for each version I think
[21:24:36] <SWPadnos> last I knew (a while ago), the maintainer for each branch would either merge patches or pull changesets from developers
[21:25:02] <SWPadnos> I don't think it operates the same way as CVS regarding multiple developers "checking in" changes
[21:25:20] <jepler> but since the anonymous server can be a dumb HTTP server over the filesystem, you can give anonymous access without giving a shell equivalent
[21:25:48] <jepler> any developer already gets a lot of trust (I could put a line in Makefile and root a bunch of developer systems before it was noticed, not just cvs.linuxcnc.org)
[21:26:15] <SWPadnos> that would be annoying
[21:29:07] <jepler> looks like it works pretty similar
[21:29:10] <alex_joni> in 12 hours there will be an automatic full build
[21:29:41] <jepler> if I 'push' but someone else did since I last 'pull'ed, I get an error:
[21:29:49] <SWPadnos> ah, ok
[21:29:49] <jepler> error: remote 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'. maybe you are not up-to-date and need to pull first?
[21:30:24] <jepler> I then did 'git pull && git push origin' which merged the other change and then the push succeeded
[21:31:00] <jepler> so that leaves the question of whether two simultaneous 'git push' operations are locked against each other, otherwise it acts a lot like CVS
[21:31:07] <SWPadnos> did you have changes to a single file in both changesets?
[21:31:20] <jepler> yes, I had changed the same file
[21:31:52] <SWPadnos> hmmm. I wonder where the changes were merged - at pull or push stage (or both, solving the 3-way problem by making it two 2-way problems)
[21:32:32] <jepler> I think 'pull' does it
[21:33:27] <jepler> 'pull' knows the common ancestor so it can do a 3-way merge with (ancestor, new1, new2)
[21:33:57] <jepler> http://emergent.unpy.net/files/sandbox/git-merge.png
[21:34:25] <jepler> some of the hostnames are funny because I didn't have my environment set up right..
[21:34:27] <SWPadnos> cool
[21:34:38] <SWPadnos> I like jepler@sofa :)
[21:34:53] <jepler> yeah if only @india were literal to
[21:34:53] <jepler> o
[21:35:01] <SWPadnos> heh
[21:37:19] <jepler> so just like CVS, resolving files that have been changed by two people is the responsibility of the second person who finalized the change ("commit" in CVS, "push" in git)
[21:39:12] <alex_joni> * alex_joni heads to bed
[21:39:15] <alex_joni> good night guys
[21:39:22] <jepler> good night alex
[21:41:19] <jepler> I'm convinced that anybody who knows CVS could adapt to git pretty easily .. two cases: CVS is known by rote? learn git by rote. CVS is known by deep understanding? git is understood soon enough.
[21:41:58] <SWPadnos> see you Alex
[21:42:39] <SWPadnos> other case: CVS is known by consulting the manpage|web|other developers every time: GIT is already known to that level of proficiency :)
[21:43:00] <jepler> hah
[21:43:37] <jepler> I also like the gitweb.cgi interface better than viewcvs-style, since it's centered on revisions and not files ..
http://git.unpy.net/view?p=stepconf.git;a=summary
[21:44:05] <SWPadnos> yeah - it doesn't seem all that easy to look at "what changed recently" in CVS
[21:44:30] <jepler> though history of an individual file is still available
http://git.unpy.net/view?p=stepconf.git;a=history;f=stepconf.glade;h=a38d35c804df6e4d814809a195dffca24665999b;hb=14763e96a3be1b9ab93823b9c8f6ba8953e9e7cb
[21:46:03] <jepler> one big downside is that the initial checkout takes much longer.. you effectively download every revision of every file ever, even those now removed from the tree
[21:46:09] <jepler> (and the attendant disk usage)
[21:46:54] <SWPadnos> did you import the CVS repo into git when you started fiddling with it?
[21:47:38] <jepler> I have imported emc2's CVS into git, but in this case I have a repo with just stepconf in it
[21:48:06] <SWPadnos> ok. just wondering about the actual HD (and therefore bandwidth) usage of the whole EMC history in git
[21:48:35] <jepler> looks like it was about 27 megs on 9/6
[21:48:38] <jepler> that's september 6
[21:48:46] <SWPadnos> ok, that's not much
[21:49:09] <SWPadnos> I know Linus basically didn't care about disk usage when writing git
[21:49:38] <SWPadnos> his argument was more or less "buy a 1G larger hard drive for $0.50 more"
[21:49:45] <SWPadnos> and mow it's only $0.20
[21:49:53] <jepler> ~10 minutes to download on cvs.linuxcnc.org's pipe (384kbps) though, and that's if you're not competing with anything else
[21:50:10] <SWPadnos> sure
[21:50:34] <SWPadnos> I'd love to set it up on DH, but there's the problem of no root access and that kind of thing
[21:50:39] <jepler> hum, I wonder if that 27 meg figure is right
[21:50:52] <jepler> I have several versions and one of them is 65 megs
[21:51:08] <SWPadnos> du . -hs ;)
[21:54:59] <jepler> I updated and put it on git.unpy.net for fun:
http://git.unpy.net/view?p=emc2.git;a=summary
[21:57:41] <jepler> however, it may be damaged -- I can't "git clone" from it
[21:57:59] <SWPadnos> hmmm
[21:58:08] <jepler> * jepler removes and imports from CVS again
[21:58:26] <jepler> SWPadnos: but you shouldn't be expressing interest in this now.. you should be working on your proyec
[21:58:29] <jepler> t
[21:58:30] <jepler> project
[21:58:31] <SWPadnos> I get 403 forbidded trying to look at the diff from that last commit
[21:58:39] <jepler> probably because I removed it
[21:58:39] <SWPadnos> oh yeah. thanks
[21:58:49] <jepler> I figure you must have forgotten
[21:58:50] <SWPadnos> oh, that could be
[21:58:52] <SWPadnos> heh
[21:58:55] <SWPadnos> not bloody likely ;)
[22:01:06] <jepler> Committed patch 239 (origin +0000 2004-06-12 17:00:21)
[22:01:08] <jepler> the import takes awhile
[22:02:10] <SWPadnos> are you doing that locally or over the intarweb?
[22:02:15] <jepler> locally
[22:02:23] <jepler> Committed patch 307 (origin +0000 2004-09-05 14:13:48)
[22:02:26] <SWPadnos> ok - I imagine it's a lot slower remotely :)
[22:02:51] <jepler> I'm sure; if anyone but me were to do this, he should start with a copy of the CVS repository on local disk
[22:03:09] <SWPadnos> luckily that's downloadable from DH
[22:06:34] <jepler> supposedly you can keep a git repository updated from CVS, not be forced to redo it from scratch every time
[22:09:25] <jepler> Committed patch 1201 (origin +0000 2005-11-06 22:16:20)
[22:41:31] <jepler> it's done, and the new number is even smaller: 16832kb
[22:43:03] <jepler> (size on client after 'git clone', it's a bit bigger on the server and I am not sure why)
[22:45:18] <jepler> time to clone (equivalent to 'cvs co') on local network: 30 seconds 'real'
[22:45:30] <jepler> time to pull (equivalent to 'cvs up') on local network: 7 seconds 'real
[22:45:30] <jepler> '
[22:48:38] <jepler> hm, then I broke it
[22:48:54] <jepler> apparently the dapper version of git doesn't know about whatever 'git-pack-refs' does on the server
[22:50:38] <jepler> haha
[22:50:37] <jepler> I'd call whoever made that decision a complete crack-addict and total
[22:50:37] <jepler> idiot, but it might be me, so I'll just tread carefully and call the
[22:50:39] <jepler> choice "interesting".
[22:50:41] <jepler> </linus>
[23:21:17] <SWPadnos> so jmkasunich, you got the loader working, and I got the tester working (though the compile farm may lie and say it doesn't)
[23:21:50] <SWPadnos> we now have the ability to program and operate 5i22-1.5 cards
[23:21:56] <jmkasunich> cool
[23:22:11] <jmkasunich> * jmkasunich is still reading back
[23:22:18] <SWPadnos> I haven't tried to load a bitfile generated with your UCF file yet though
[23:22:38] <jmkasunich> damn you guys talk a lot
[23:22:44] <SWPadnos> heh
[23:22:59] <SWPadnos> mostly drivel - you can probably ignore it
[23:23:04] <SWPadnos> (at least when I was here)
[23:24:48] <jepler> yeah I don't remember anything of substance...
[23:26:25] <SWPadnos> oh - rehome after abort/estop
[23:26:34] <SWPadnos> that's possibly of interest
[23:30:31] <jmkasunich> finally caught up
[23:35:37] <jmkasunich> I just kicked off complete builds on the compile farm
[23:35:52] <SWPadnos> ok. that would have been automatic at midnight though, right?
[23:35:56] <jmkasunich> no
[23:35:59] <SWPadnos> (or sometime)
[23:36:02] <SWPadnos> oh
[23:36:15] <jmkasunich> it would be automatic on the first commit that is 12 hours or more after the last complete build
[23:36:21] <SWPadnos> ah
[23:36:24] <jmkasunich> I think
[23:36:58] <SWPadnos> I thought we had discussed doing complete builds after failed ones, but maybe there was some problem with that idea
[23:36:58] <jmkasunich> I really like this new box
[23:37:10] <SWPadnos> a wee bit faster?
[23:37:38] <jmkasunich> the main downside of that is that 95% of failed builds don't need a make clean, and when you are trying to fix a problem is when you appreciate the speed of incremental builds the most
[23:38:09] <jmkasunich> although maybe with this new box that doesn't matter
[23:38:14] <SWPadnos> heh
[23:38:15] <jmkasunich> all three complete builds are done
[23:38:18] <SWPadnos> that was at least 30 seconds
[23:38:20] <jmkasunich> all green now
[23:38:44] <SWPadnos> do you have a -j in there, or are the VMs uniprocessor?
[23:38:50] <jmkasunich> longer than that, I said that I kicked them off after doing the last one, each one takes a few lines of typing
[23:39:04] <SWPadnos> actually, you could probably use -j 2 or -j 3 on UP as well
[23:39:05] <jmkasunich> the VMs are uni, since I simply copied them over from my older box
[23:39:41] <jmkasunich> its fast enough that I'm not gonna spend any time tweaking it
[23:40:35] <SWPadnos> heh
[23:44:27] <jmkasunich> I just realized that with the VMs on my new machine, the dapper build is massively out of date
[23:44:34] <jmkasunich> (since I didn't use a VM for that)
[23:44:49] <SWPadnos> oh. oops
[23:44:49] <jmkasunich> I haven't run the farm scripts on my dapper RT box in a while
[23:49:42] <SWPadnos> how big are the farm VMs?
[23:50:11] <SWPadnos> in disk space, that is
[23:50:52] <jmkasunich> 8G I think
[23:50:59] <SWPadnos> hmmm
[23:51:07] <jmkasunich> probably about half full
[23:51:29] <SWPadnos> are the disk images full size or sparse mode?
[23:51:33] <jmkasunich> full size
[23:51:39] <SWPadnos> ok
[23:51:47] <jmkasunich> my understanding is that full size is either more robust or faster or both
[23:52:13] <SWPadnos> yes - certainly more robust if the host disk ever gets close to full
[23:52:14] <jmkasunich> it takes a while to move a VM from one machine to another, even over 100M ethernet
[23:52:30] <SWPadnos> do you know how well they compress?
[23:52:36] <jmkasunich> haven't tried
[23:52:50] <SWPadnos> I'm wondering if it's feasible to stick copies on linuxcnc somewhere
[23:52:55] <jmkasunich> I'm sure its gonna be at least the better part of 1 gig each
[23:53:06] <jmkasunich> they are complete ubuntu installs, plus other stuff
[23:53:06] <SWPadnos> yeah, I'd imagine
[23:53:09] <SWPadnos> right
[23:53:58] <jmkasunich> the VMs themselves aren't irreplacable - you can always do a fresh install on a fresh VM
[23:54:07] <jmkasunich> the farm scripts are in CVS
[23:54:28] <SWPadnos> yeah - that's true
[23:55:17] <jmkasunich> it would be kind of nice if the CVS server was in a VM
[23:57:31] <SWPadnos> it is
[23:57:37] <SWPadnos> there's a copy of it somewhere
[23:57:38] <jmkasunich> oh
[23:57:44] <jmkasunich> thats good to know
[23:57:46] <SWPadnos> I think that's how it is anyway
[23:58:01] <jmkasunich> I think you are right - ISTR cradek telling me about that
[23:58:09] <SWPadnos> you should know - you have cvs2 ;)
[23:59:37] <jmkasunich> had
[23:59:43] <SWPadnos> ah
[23:59:47] <jmkasunich> CVS2 was a slot in the old cubix rack
[23:59:58] <jmkasunich> which went bye-bye in December
[23:59:58] <SWPadnos> righto. I wonder if I shuold remove it fom DNS
