Back
[00:59:36] <fjungclaus_> Good night ...
[00:59:41] <fjungclaus_> fjungclaus_ is now known as fjungclaus-away
[01:35:08] <jmkasunich> hi guys
[01:35:27] <jmkasunich> alex_joni is going for a commit message record I think
[01:53:50] <cradek> hi
[01:55:28] <jmkasunich> hi
[01:55:54] <cradek> I'm excited about (maybe) releasing this weekend
[01:56:11] <jmkasunich> there will still be some missing manpages
[01:57:13] <cradek> the drivers?
[01:57:22] <jmkasunich> yeah
[01:57:26] <jmkasunich> and the biggie - motmod
[01:57:49] <jmkasunich> I probably should have forced myself to work on manpages instead of encoder
[01:58:21] <cradek> we have a lot of useful help that we didn't have before. it doesn't have to be perfect.
[02:13:42] <jmkasunich> darn, a bug....
[02:13:52] <cradek> what is it?
[02:14:00] <jmkasunich> in the encoder
[02:14:13] <cradek> an old one?
[02:14:21] <jmkasunich> no
[02:14:24] <jmkasunich> my new stuff
[02:14:36] <jmkasunich> the double buffering isn't doing what its supposed to
[02:16:10] <jmkasunich> ah, I see the problem
[02:23:54] <jmkasunich> works quite nicely
[02:25:41] <jmkasunich> at a speed of 0.01 revs/sec (= 10 counts/sec), the new velocity indicates 0.01, the old one indicates 0 most of the time, with a spike to 1.0 each time the encoder counts
[02:25:49] <cradek> slick!
[02:26:12] <jmkasunich> also is well behaved when the speed changes, either dropping or rising
[02:29:29] <jmkasunich> gotta try slewing the speed instead of stepping it...
[02:30:13] <SWPadnos> hmmm. I'd leave that to an external limit block
[02:30:19] <jmkasunich> hih?
[02:30:24] <jmkasunich> huh even?
[02:30:25] <SWPadnos> heh
[02:30:44] <SWPadnos> once you have a new speed reading, slewing only delays outputting it to HAL
[02:30:57] <jmkasunich> oh - failure to communicate
[02:31:06] <SWPadnos> ah - nevermind :)
[02:31:13] <SWPadnos> slewing while testing ...
[02:31:19] <jmkasunich> slewing means "test the encoder counter with a simulated encoder whose speed is slewing not stepping
[02:31:28] <SWPadnos> right - got it :)
[02:31:47] <SWPadnos> of course, you can do that with a limit block as well ;)
[02:31:55] <jmkasunich> yeah
[02:32:30] <cradek> http://timeguy.com/cradek-files/emc/tortscope.png
[02:32:36] <jmkasunich> I think I'll just use a siggen tho
[02:32:40] <cradek> haven't run this for a long time - but it still looks good
[02:32:41] <SWPadnos> kewl :)
[02:32:59] <jmkasunich> thats the TP output?
[02:33:36] <cradek> yes all six vel/acc plus a "constraints ok" hal bit I get by or-ing a bunch of comparisons
[02:34:49] <jmkasunich> somebody committed something didn't they....
[02:36:05] <SWPadnos> interesting. only channels 2 and 4 seem to have any very sharp cusps - the others all look nice and smooth
[02:36:28] <cradek> 246 are the accels
[02:36:45] <cradek> so there's no limit on their "pointyness"
[02:36:52] <SWPadnos> ok. I probably can't see 6 due to the color being similar to 3
[02:37:00] <jmkasunich> * jmkasunich contemplates creating a interesting signal....
[02:37:05] <SWPadnos> ok - I thought it was ll positions
[02:37:21] <jmkasunich> two or three siggens driving the inputs of another siggen
[02:37:21] <cradek> ?
[02:37:34] <jmkasunich> amplitude and frequency modulation of a carrier anyone?
[02:37:35] <SWPadnos> did (whoever it was) ever commit the random component?
[02:38:06] <SWPadnos> err - random number generator component ;)
[02:38:25] <jmkasunich> I don't recall seeing it
[02:38:32] <cradek> jepler did that to test adaptive feed - I don't think he committed it
[02:38:42] <SWPadnos> ok
[02:39:23] <cradek> http://timeguy.com/cradek-files/emc/tortscope2.png
[02:41:57] <cradek> as an added bonus, I can see it stays on the path too
[02:42:47] <SWPadnos> that's helpful
[02:47:19] <jmkasunich> wth?
[02:47:26] <jmkasunich> siggen's control pins should not be I/O
[02:48:40] <SWPadnos> oops
[02:49:23] <jmkasunich> hmm, thats a minor bug in the API
[02:49:37] <jmkasunich> when awallin changed them from params to pins, he left the dir as HAL_RW
[02:49:42] <cradek> does anyone know if mini is supposed to highlight the running line somehow? it scrolls the program but I can't tell which line is running
[02:50:00] <jmkasunich> we should make the pin dir codes illegal for params, and vice versa, to catch that at compile time
[02:50:31] <SWPadnos> * SWPadnos would mention C++, but thinks it's the wrong time
[02:50:52] <cradek> yeah I was just thinking - I don't think you can do that in C
[02:51:07] <jmkasunich> SWPadnos _did_ just mention C++, which earns him a slap with a dead fish
[02:51:36] <SWPadnos> nope. typedefs and enums are just ints in C, so the only way to do it is to use different sets of constants and compile-time / run-time bounds checks
[02:51:39] <jmkasunich> cradek: oops, you're right, it would be detected at runtime
[02:51:41] <SWPadnos> ouch :)
[02:52:24] <jmkasunich> (I was thinking about the "non-overlapping sets of constants" approach, but it would be runtime only
[02:52:40] <cradek> um, now it started highlighting the top line
[02:52:56] <jepler> it was just some python program -- I don't think I committed it
[02:52:58] <SWPadnos> dunno much about mini
[02:53:06] <cradek> it comes and goes
[02:53:22] <cradek> I suspect it's highlighting the line that's off the top of the box
[02:53:48] <cradek> well, it runs, that's about all I know how to test
[02:53:54] <SWPadnos> it may have a problem with currently executing vs. currently interpreting ...
[02:56:21] <jepler> I think this is it:
http://pastebin.ca/329875
[02:56:54] <SWPadnos> looks good to me
[03:08:30] <cradek> http://pastebin.ca/329884
[03:08:58] <cradek> ^^ while starting calib running sim/servo_sim
[03:09:31] <jepler> I'll look for the problem
[03:09:35] <jmkasunich> what is calib?
[03:09:54] <cradek> jmkasunich: the gui thing that lets you change the pid values and then save them
[03:09:58] <jmkasunich> oh
[03:10:43] <jmkasunich> dang.. has my webserver died or is it just the compile farm sucking up cycles....
[03:11:12] <jepler> halcmd -s show param scale.0.gain
[03:11:24] <jepler> there is no scale.0.gain, but for some reason calib is trying to query its value
[03:12:04] <jmkasunich> is there a scale.0 loaded?
[03:12:07] <jepler> yes
[03:12:20] <jmkasunich> its supposed to have a gain
[03:12:22] <jepler> but gain was changed from a param to a pin
[03:12:27] <jmkasunich> if you trust the manpage
[03:12:29] <jmkasunich> op
[03:12:33] <jmkasunich> oh
[03:14:22] <jepler> gain and offset were params in blocks, but not in the .comp version
[03:16:08] <jmkasunich> http://jmkasunich.dyndns.org/pics/new-encoder.png
[03:16:32] <jmkasunich> chan 3 (green) is the commanded velocity to the sim-encoder (offset down by one division)
[03:16:53] <jmkasunich> chan 1 (red) is the old approach to velocity (I'm using a ddt to do the same thing)
[03:17:06] <jmkasunich> chan 2 (blue) is the velocity output of the new encoder block
[03:17:06] <cradek> wow that's quite a difference
[03:17:15] <cradek> what's the discontinuity at zero?
[03:17:43] <jmkasunich> when the velocity is near zero, you go for a while without getting any pulses
[03:17:55] <jmkasunich> so it hold the previous value for a while
[03:18:45] <jmkasunich> once the time since last pulse is longer than it would have been if the previous velocity persisted, it starts lowering the output (since no pulse has arrived, it must be lower than "1count/time since last"
[03:19:57] <cradek> sure looks like a huge improvement
[03:20:54] <jmkasunich> the next step (not now) is to come up with a PID loop that can use the velocoity feedback
[03:21:18] <jmkasunich> the D term should use the velocity (from a new pin) instead of computing its own ddt using the position
[03:21:35] <jmkasunich> that should make Dgain more usefull
[03:21:42] <cradek> cool
[03:21:45] <jmkasunich> because you can have more if it without it going nuts
[03:24:40] <jepler> I think that for now, scale.comp should have the same things be parameters as the block did. that will quickly fix this problem in the calibration script.
[03:24:57] <jmkasunich> thats ok by me
[03:25:04] <cradek> that was an unintentional change I guess?
[03:26:12] <jmkasunich> looks that way
[03:26:21] <jmkasunich> scale.comp is still at 1.1
[03:26:40] <jepler> in HEAD we should make 'halcmd getp' work like 'halcmd setp' and work on a pin if the parameter does not exist. this still doesn't fix the calibration script, but it means it could be changed to use the much saner "halcmd getp" instead of parsing 'halcmd show'
[03:27:04] <jmkasunich> agreed
[03:27:24] <cradek> emcsh needs a hal module - any parsing of halcmd output is crazy
[03:27:53] <cradek> (but I agree getp/setp should work the same)
[03:28:06] <jepler> that's another good project to do on HEAD
[03:28:22] <jmkasunich> speaking of head (and 2.1)
[03:28:33] <jepler> nope, just changing scale doesn't fix the calibration script
[03:28:33] <jmkasunich> I have mixed feelings about the new encoder block
[03:28:55] <jmkasunich> on one hand its velocity output is much nicer, on the other it has much less testing
[03:29:03] <jmkasunich> perhaps it should stay in trunk?
[03:29:20] <cradek> what uses the velocity output?
[03:29:22] <jmkasunich> jepler: it just barfs a few lines later on some other param?
[03:29:34] <jmkasunich> cradek: nothing, that I know of
[03:29:46] <jmkasunich> but I also did serious hacking on the rest of it
[03:29:55] <cradek> then I don't think it should go in
[03:30:00] <jmkasunich> because of the potential index pulse race conditions we discoverd the other day
[03:30:17] <cradek> oh a bugfix? hmm
[03:30:19] <jepler> jmkasunich: yes, some other item is a pin
[03:30:19] <jmkasunich> which reminds me, I should test the index behavior
[03:30:44] <jepler> there's another strategy available: remove the 'velocity' feature from 2.1. It was not in a released version yet.
[03:30:55] <jepler> thugh the lathe-sim confguration relies on it to get the spindle speed readout, and that's neat
[03:31:02] <jmkasunich> jepler: thats not a strategy
[03:31:09] <jepler> it fixes the bug
[03:31:16] <jmkasunich> not really
[03:31:28] <jmkasunich> I don't consider the quantization noise on velocity a bug
[03:31:36] <jmkasunich> the new algorithm is just an improvement
[03:31:55] <jmkasunich> the bug (if you want to call it that) is the potential (but extremely rare) risk of a race on the index pulse
[03:32:04] <jmkasunich> dropping velocity won't fix that
[03:32:10] <jepler> oh wait -- this is a separate race from the one I introduced?
[03:32:32] <jmkasunich> I dunno who introduced it
[03:32:39] <jmkasunich> it might have been there from the beginning
[03:32:58] <jmkasunich> I don't remember how the original index implementation worked
[03:33:24] <jmkasunich> maybe you did introduce it - you totally rewired index to avoid a huge velocity spike, right?
[03:34:11] <jmkasunich> anyway that doesn't matter
[03:34:34] <jmkasunich> the point is, I once again totally rewired it, to transfer data from the fast function to the slow one atomically
[03:34:43] <jmkasunich> so it has very limited testing
[03:34:52] <jmkasunich> I'm gonna keep it in head
[03:35:18] <jmkasunich> if we want to put it in 2.1.1 after we have more experience with it, we can stretch the definition of bugfix a little
[03:35:31] <cradek> I think that sounds wise
[03:35:54] <jmkasunich> btw, how did you avoid jitter on the spindle speed readout? lowpass filter it?
[03:36:12] <jepler> yes sim-lathe had a lowpass filter
[03:36:13] <cradek> it jitters at low speeds
[03:36:16] <jmkasunich> ok
[03:36:27] <jmkasunich> thats the "bug" this will fix in 2.1.1 ;-)
[03:36:35] <cradek> haha
[03:37:13] <jmkasunich> I gotta test indexing and reset before I commit to head
[03:37:19] <jmkasunich> less talking more testing
[03:37:19] <jmkasunich> ;-)
[03:42:20] <jmkasunich> do you have some automated thing that hits my website (and lots of others I bet) every 20 mins?
[03:42:35] <jmkasunich> (that was for jepler)
[03:44:00] <jepler> jmkasunich: yes, I do -- is 20 minutes too often?
[03:44:30] <jmkasunich> I dunno - if its fetching the whole page (with all my not-so-tiny thumbnails) it seems a bit much
[03:44:31] <jepler> unfortunately I use an inflexible program, so I configure it according to the website that updates most frequently
[03:44:49] <jepler> no it just fetches the text of the most recent entries
[03:44:56] <jepler> the "rss feed"
[03:45:04] <jmkasunich> I don't know squat about rss, the rss feed link on my page is cut-and-pasted from a sample
[03:45:29] <jmkasunich> do you _know_ thats what it does on my site? or is that just what an rss feed is supposed to do?
[03:46:38] <jmkasunich> (IOW, I wouldn't be surprised if its tossing the entire thing at you)
[03:46:39] <jepler> yes, I know only one URL (and none of the items it links to or has as an <IMG>) is fetched by my program
[03:46:53] <jmkasunich> ok
[03:52:00] <cradek> jepler: that fixes emccalib! thank you (but you left in a debug puts)
[03:52:09] <jepler> cradek: oops -- did you fix it for me?
[03:52:16] <cradek> no but I will
[03:52:49] <cradek> hmm, it shows 1e-04 for deadband - if it writes that, I bet hal will puke
[03:53:00] <cradek> is that a bug? that we care about?
[03:53:13] <jepler> hal won't accept the same value it prints?
[03:53:39] <cradek> ok, maybe it does, I figured it was a tcl thing
[03:54:37] <cradek> it's fine, forget it
[03:54:59] <jmkasunich> hal uses atod, I think that deals fine with e notation
[03:55:12] <cradek> I tried it, it's fine
[03:57:11] <jmkasunich> jepler: I think my rss link is messed up - it sends the entire page, in XML format, not just the most recent posting
[03:57:33] <jmkasunich> most recent 10 to be precise
[03:57:59] <jmkasunich> each as an <item>
[03:58:34] <jepler> that's typical
[03:58:49] <jmkasunich> oh, ok
[03:59:11] <jmkasunich> * jmkasunich gets back to work
[03:59:11] <jepler> often you can configure the number of days or posts to show in the rss feed, just like you can for the main blog page
[04:01:40] <jepler> I plan to be around a computer for a good chunk of tomorrow, and I'll try to fix anything that turns up in testing
[04:02:51] <cradek> me too
[04:04:19] <jmkasunich> me three (starting in the afternoon - I sleep late on the weekend)
[13:15:30] <alex_joni> morning all.. anyone around?
[14:08:38] <jepler> alex_joni: just got up
[14:09:45] <alex_joni> hi jeff
[14:09:54] <alex_joni> I have a diff I need some help with (mostly wording)
[14:10:07] <jepler> ok -- pastebin it or something?
[14:12:03] <alex_joni> yeah, coming up
[14:15:29] <alex_joni> http://www.pastebin.ca/330119
[14:21:30] <jepler> looking
[14:22:44] <jepler> I think the words are fine
[14:23:29] <jepler> will it warn when going from 2.1.0~alpha2 to another 2.1.0 version as well? I don't see anything to prevent it from doing so.
[14:23:47] <alex_joni> we simply remove it from emc.postinstall after 2.1.0
[14:24:09] <alex_joni> the alpha versions are not for the public
[14:24:23] <alex_joni> I hope that only 2.1.0 will be in the repo
[14:25:12] <jepler> so a user who goes from 2.0.5 -> 2.1.1 will never see the warning?
[14:25:28] <alex_joni> hmm.. you have a point there
[14:47:04] <A-L-P-H-A> who said emc isn't fully GPL? the myNC guy?
[14:47:16] <alex_joni> Paul does
[14:47:25] <A-L-P-H-A> paulc?
[14:47:32] <A-L-P-H-A> wtf?
[14:47:33] <A-L-P-H-A> that'
[14:47:36] <alex_joni> yes, on his tuxcnc.org website
[14:47:37] <A-L-P-H-A> that's FUD though. right?
[14:47:43] <alex_joni> right
[14:47:50] <A-L-P-H-A> w t h .
[14:48:03] <A-L-P-H-A> that's petty.
[14:48:12] <alex_joni> we decided to move on
[14:49:12] <A-L-P-H-A> 'ight
[15:24:33] <alex_joni> jepler: any idea how to properly check for the installed version?
[15:25:14] <alex_joni> (except dpkg -l emc2 | grep emc2 | awk '{print $3}')
[15:26:59] <jepler> a little bit easier: dpkg-query -W emc2 | awk '{print $2}'
[15:27:10] <jepler> but I don't know what version number that will show during a postinst script...
[15:27:23] <alex_joni> preinst ?
[15:29:31] <jepler> 6.5 Summary of ways maintainer scripts are called: ... #
[15:29:31] <jepler> 6.5 Summary of ways maintainer scripts are called: ... new-preinst upgrade old-version
[15:29:55] <jepler> it looks like preinst gets told the old version
[15:30:00] <jepler> (excuse the poor paste)
[15:30:10] <alex_joni> right.. but passing that to postinst is messy
[15:30:14] <jepler> http://www.us.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact
[15:30:20] <alex_joni> and putting the info in preisnt is not a good solution either
[15:30:25] <alex_joni> as the installing might fail
[15:30:59] <jepler> in #
[15:30:59] <jepler> in postinst configure most-recently-configured-version
[15:31:14] <jepler> is most-recently-configured-version the prior version or this version?
[15:31:27] <alex_joni> your guess is as good as mine
[15:31:36] <alex_joni> but POSTinst would seem after the install
[15:31:40] <alex_joni> so the version is the one already installed
[15:32:55] <alex_joni> s/already/recently aka last/
[15:37:04] <alex_joni> hmm .. it seems the old version is passed
[15:37:35] <alex_joni> http://pastebin.ca/330158
[15:38:58] <jepler> good -- then I suggest basing it on that number being of the form 1:2.0.*
[15:39:15] <alex_joni> yeah, that's what I'm planning now
[15:39:16] <jepler> case $1 in 1:2.0.*) issue the warning ;; esac
[15:39:22] <jepler> er, $2
[15:39:42] <alex_joni> yeah, thanks
[15:52:47] <cradek> ~$ dpkg-query -W --showformat='${Version}\n' emc2-sim
[15:52:48] <cradek> 1:2.1.0~beta2
[15:53:50] <alex_joni> thanks chris.. but as jeff pointed out $2 is the way to go, dpkg-query will report the fresh installed package
[15:54:19] <cradek> ah
[15:55:00] <alex_joni> did you look at the initial pastebin?
[15:56:21] <alex_joni> http://pastebin.ca/330169
[15:56:51] <cradek> yes, the notice is nice
[15:57:07] <alex_joni> does the wording need improvement?
[15:58:50] <alex_joni> testing it now
[16:00:03] <cradek> the message is fine
[16:02:50] <alex_joni> hi
[16:02:57] <alex_joni> err..
[16:20:20] <alex_joni> I commited the stuff, CIA won't show it.is there any chance someone else can test it too?
[16:24:07] <cradek> I can in a few hours
[16:32:20] <alex_joni> that's ok
[19:21:03] <cradek> alex_joni: it didn't work for me
[19:21:55] <cradek> hmm do I have to use the update manager for that to work?
[19:22:12] <cradek> dpkg: yes, will remove emc2-axis in favour of emc2.
[19:22:21] <cradek> Preparing to replace emc2 1:2.0.5 (using emc2_2.1.0~beta2_i386.deb) ...
[19:22:21] <cradek> Unpacking replacement emc2 ...
[19:22:21] <cradek> Setting up emc2 (2.1.0~beta2) ...
[19:22:32] <cradek> this should have done it right?
[19:24:18] <alex_joni> I think so
[19:24:34] <alex_joni> but it sometimes takes a while for the update thingy to pop up the message
[19:24:54] <cradek> there's a firefox update to install too - maybe that will kick it
[19:25:33] <cradek> yeah, it did
[19:25:34] <alex_joni> yeah, the firefox will also have a message
[19:25:54] <cradek> too bad that's not a link
[19:26:09] <alex_joni> yeah, didn't find any info on this update-notifier
[19:26:11] <cradek> wonder if we should put UPDATING prominently on the front page, and then just point them to the wiki front page
[19:26:15] <alex_joni> dunno if it can use links or not
[19:32:53] <alex_joni> cradek: thanks for testing
[19:33:10] <cradek> sure
[19:33:32] <alex_joni> so.. what do you think?
[19:33:43] <alex_joni> should we put an alpha/beta package in the repo?
[19:33:45] <cradek> I think it's going to be a help
[19:33:50] <alex_joni> or start with the 2.1.0 directly?
[19:34:00] <cradek> no I think we should put 2.1.0 there when it's ready
[19:34:21] <cradek> I'm checking the gcode quickref now, it was missing g76
[19:34:41] <alex_joni> I think 2.1.0 is a nice package
[19:34:50] <alex_joni> LOTS of new things and especially docs
[19:35:18] <cradek> yes
[19:36:00] <awallin> do we have a changelog with the new features?
[19:36:09] <cradek> we need one
[19:36:16] <awallin> * awallin is rebooting...
[19:36:17] <alex_joni> I put some things in docs/NEWS
[19:36:25] <cradek> I think we should start with the 2.0 changelog and add 2.1.0
[19:36:47] <cradek> the unreleased alpha packages are of no interest - we should show all the new features since 2.0.x
[19:36:55] <alex_joni> right
[19:49:40] <alex_joni> cradek: you're working on the changelog? or should I?
[19:50:37] <cradek> alex_joni: I'm not (I'm still recovering from proofreading all those manpages)
[19:50:51] <cradek> alex_joni: I'll happily proofread it when you're done though
[19:50:52] <alex_joni> heh, I bet
[19:51:09] <alex_joni> ok.. will try to get it done
[19:51:57] <cradek> thank you
[19:56:49] <awallin> cradek: AXIS feature request: in the orthographic views, along X/Y/Z axes, could we have a regularly spaced grid displayed? That, in addition to the extents dimensions shown would allow checking G-code for correctness
[19:57:57] <cradek> I agree that would be nice
[19:58:12] <cradek> the axis arrows are 1" long and I sometimes judge stuff based on that
[19:58:30] <cradek> the problem is figuring out what's a good scale
[19:59:20] <awallin> the scale needs to change as zoom is changed. perhaps with a maximum of 10 major lines across the display and a maximum of 100 minor lines
[19:59:52] <alex_joni> cradek: I see that at some point (just before 2.0.0 you changed from testing to unstable) any reason for that?
[20:00:17] <cradek> alex_joni: no idea
[20:00:41] <alex_joni> mmkay
[20:01:30] <SWPadnos> hmmm. the scale can be taken from the INI - only place a grid on the XY plane from MIN to MAX in each direction, and use inches/mils or mm/cm/dm depending on UNITS
[20:02:42] <cradek> true it can stop at the limits
[20:02:46] <awallin> SWPadnos: yes, but it would also be nice to get more gridlines as you zoom in. no good displaying the whole work envelope at 0.01 accuracy, but 0.01 accuracy could be useful when zooming on details
[20:02:55] <cradek> yes
[20:03:09] <SWPadnos> sure, you choose the grids to display depending on how much distance a pixel is at the current scale
[20:03:21] <cradek> I like the way qcad does it (just about the only good thing about qcad that I saw)
[20:04:03] <cradek> I'd give extra credit for drawing the actual coordinates on the grid (at the edge of the view)
[20:04:26] <cradek> the number drawing infrastructure is all there already
[20:05:45] <alex_joni> sounds like a "patches gladly accepted"
[20:06:11] <cradek> yeah I think it would be nice
[20:09:43] <cradek> awallin: if you don't want to do it, you might file a feature request on the sf tracker
[20:10:00] <cradek> then it won't be forgotten
[20:10:04] <awallin> cradek: ok, I'll do that later...
[20:13:13] <SWPadnos> bbl. hopefully I'll get a chance to do some work on the stepper quickstart, and maybe even start a servo quickstart
[20:52:37] <cradek> alex_joni: how's the changelog drudgery?
[20:53:12] <alex_joni> just wanted to commit it
[20:53:15] <alex_joni> can you look?
[20:53:21] <cradek> sure
[21:06:27] <jepler> ooh ooh
[21:06:57] <cradek> I'm adding lots of things
[21:07:44] <alex_joni> lots?
[21:09:21] <jepler> I have an idea about how to implement the "advance program with jogwheel" feature someone showed me in another cnc software back at fest
[21:10:01] <jepler> hook this to the feedhold pin: if (in > count) { out = TRUE; count ++; } else { out = FALSE; }
[21:10:08] <jepler> and hook your jogwheel to 'in'
[21:11:04] <cradek> sounds easy :-)
[21:11:19] <alex_joni> heh.. yeah
[21:21:22] <alex_joni> jepler: it seems I might have been wrong earlier
[21:21:39] <alex_joni> the [TRAJ] HOME seems to be unused even for nontrivkins
[21:44:35] <jmkasunich> sorry I'm so late today - we got new drapes for the family room, so I was mounting curtain rods and such
[21:45:15] <jmkasunich> what is most needed for the release?
[21:46:30] <cradek> do you have a rt breezy still?
[21:57:36] <jepler> I've got one downstairs
[21:58:13] <jmkasunich> I have one on a vm
[21:58:19] <jmkasunich> (farm slot)
[21:58:38] <jmkasunich> oh, I have a real one too - forgot about that
[21:58:44] <jmkasunich> lappy running xubuntu
[21:58:59] <alex_joni> xubuntu breezy?
[21:59:02] <jmkasunich> yes
[22:00:10] <cradek> oh hey, I do too, if I reboot
[22:00:11] <cradek> duh
[22:00:17] <cradek> (that's how I build the packages)
[22:00:24] <alex_joni> heh
[22:01:09] <jmkasunich> so, again I ask: what is most needed for the release?
[22:01:24] <alex_joni> testing I'd say
[22:01:30] <alex_joni> install a deb and see how it runs :)
[22:01:30] <cradek> I could make packages - we could all try them
[22:02:26] <jmkasunich> are we declaring the actual content pretty much done?
[22:02:42] <cradek> I am
[22:02:52] <alex_joni> me too
[22:02:54] <jmkasunich> ok
[22:03:06] <jmkasunich> my desire to write manpages petered out a couple days ago
[22:03:17] <jmkasunich> I still want ones for motmod and the drivers, but maybe they can go in 2.1.1
[22:03:33] <alex_joni> jmkasunich: confucius always says: you need to leave room to improve a thing later
[22:03:38] <cradek> sure, a missing manpage is a bug
[22:03:49] <jmkasunich> I like that philosophy
[22:04:00] <alex_joni> cradek: LOL
[22:04:16] <alex_joni> jmkasunich: bet it wasn't confucius.. but it shouldn't matter
[22:06:18] <cradek> building a dapper "beta1"
[22:06:30] <alex_joni> I can build dapper here
[22:06:36] <alex_joni> no breezy though
[22:07:08] <cradek> I have to eventually build them anyway...
[22:07:18] <alex_joni> ok
[22:14:40] <cradek> arg
[22:14:48] <alex_joni> forgot to dettach ?
[22:15:20] <cradek> no, a network problem I guess
[22:16:44] <cradek> http://timeguy.com/cradek-files/emc/emc2_2.1.0~beta1_i386.deb
[22:16:58] <cradek> it's probably gonna be slow if all of you try to get it at the same time
[22:17:09] <cradek> this is the dapper rt package
[22:17:26] <alex_joni> anything different from the 2.1 branch?
[22:17:42] <alex_joni> * alex_joni asks before downloading :)
[22:17:59] <cradek> just the version number in the changelog
[22:18:22] <alex_joni> ok, then I already have it installed I guess
[22:19:54] <cradek> did you try some of the stepper configs? I've only tried sim so far
[22:22:01] <alex_joni> yeah, I ran most of the configs
[22:22:19] <alex_joni> sim, stepper, halui, CL, genhexkins, etc
[22:27:01] <cradek> ok, maybe this is dumb, since we can all build and test the package
[22:27:56] <cradek> the only thing that still concerns me: are we sure we want to push this update to everyone, breaking their configs?
[22:28:12] <cradek> I still say no, but I think everyone else says yes
[22:30:51] <alex_joni> cradek: what's the alternative?
[22:31:04] <alex_joni> name the package something else, have them do something to install it?
[22:31:22] <cradek> deb
http://www.linuxcnc.org/emc2/ dapper emc2.1
[22:32:32] <cradek> I think people should be able to decide to keep using 2.0. if we find a bug, we can still fix it for them without causing disruption
[22:33:19] <alex_joni> I guess I'm not sure what would be best
[22:34:34] <cradek> skunkworks: ?
[22:35:23] <cradek> alex_joni: (I think nobody else is here)
[22:37:20] <jepler> I don't like the idea of breaking a bunch of users' installs when they are just trying to get a patch for the latest firefox vulnerability
[22:37:49] <jepler> so I'd rather see these packages go into a different location
[22:38:07] <alex_joni> * alex_joni bets emc users don't know much about firefox vulnerabilities :)
[22:38:23] <cradek> I bet they all are going to click on "go ahead and upgrade that stuff"
[22:38:35] <cradek> breaking their configs when they do it seems like a dirty trick
[22:49:18] <jepler> I always upgrade all the packages I'm offered
[22:49:42] <alex_joni> same here..
[22:52:44] <alex_joni> I think it keeps bugging until you install them all
[22:52:49] <cradek> yes it does
[22:52:51] <alex_joni> or you'll have to uncheck it every time
[22:53:21] <fjungclaus_> fjungclaus_ is now known as fjungclaus
[22:53:38] <cradek> maybe the basic question is do we want people to be able to choose to continue using 2.0
[22:53:42] <cradek> hi frank
[22:55:03] <alex_joni> as in "do we want to continue supporting it" _
[22:55:04] <alex_joni> ?
[22:55:43] <cradek> well if someone has troubles that are fixed in 2.1, we can suggest they upgrade
[23:02:43] <jepler> I don't see any reason to make it hard for a user to stay at 2.0 if they like
[23:03:40] <jepler> unlike 2.0.x->2.0.5 it's not a transparent upgrade
[23:30:41] <jmkasunich> back
[23:31:04] <jmkasunich> my thoughts - I'm gonna be rather testy when people ask about 2.0.x problems that are fixed in 2.1
[23:31:15] <jmkasunich> and my answer is gonna be "get 2.1, or get lost"
[23:33:24] <jmkasunich> the truth is that 90% of people rely on the update manager
[23:33:42] <jmkasunich> if we _don't_ auto-update people, we'll still be dealing with 2.0 users two years from now
[23:34:12] <jmkasunich> otoh, breaking peoples configs isn't nice either
[23:34:35] <jmkasunich> * jmkasunich shuts up, monologues are boring
