Back
[00:10:44] <SWPadnos> man. parameter handling is - odd
[03:18:14] <cradek> hm, some kind of compiler update on hardly
[03:20:04] <jepler> something doesn't work in double precision with pluto-step
[03:20:10] <jepler> the kernel code dies very early
[03:20:11] <jepler> [341533.887029] Default Trap Handler: vector 14: Suspend RT task ed1fe000
[03:20:21] <cradek> hm
[03:20:33] <cradek> you didn't commit yet did you?
[03:21:09] <jepler> no
[03:21:18] <cradek> I was just rebuilding here to smoke-test all the new stuff
[03:22:40] <jepler> debounce !?
[03:22:45] <cradek> ?
[03:22:48] <jepler> when I comment the addf for debounce, it works
[03:23:39] <jepler> that's not even got any floats
[03:23:57] <jepler> hmmmmmm
[03:23:57] <jepler> fix more runaway pointer bugs caused by incorrect param-to-pin conversion
[03:25:41] <cradek> yeah I noticed that too.
[03:25:48] <cradek> maybe I missed something.
[03:26:50] <cradek> yeah, state is bogus
[03:27:37] <cradek> mess with that define or hal_malloc the s32 for it
[03:28:02] <cradek> oh, look: addr->state = 0; near the end
[03:28:34] <jepler> I'm sure this change I'm about to commit won't have any inintended consequences
[03:29:49] <cradek> did you fix debounce or are you waiting for me to do it?
[03:30:23] <jepler> I just reverted to 1.9 and saw that it worked OK
[03:30:26] <jepler> I don't have a "fix"
[03:30:28] <cradek> oh ok
[03:34:04] <CIA-39> EMC: 03cradek 07TRUNK * 10emc2/src/hal/components/debounce.c: revert incomplete param to pin changes - it still had bugs. maybe we'll try again later.
[03:39:37] <cradek> some things, like FO, can be set to a particular value, and the other guis handle this fine. in halui, for these, there is an increase and decrease pin as well as a hookup for an encoder. what halui doesn't let you do is set to a particular value. Does anyone have an idea for a design that would allow this?
[03:40:06] <CIA-39> EMC: 03jepler 07TRUNK * 10emc2/debian/changelog: (log message trimmed)
[03:40:06] <CIA-39> EMC: convert 'hal_float' to a double-precision type.
[03:40:06] <CIA-39> EMC: as discussed at length, pentium-and-above systems can safely write 'double's
[03:40:06] <CIA-39> EMC: with the required atomicitiy guarantee, and 'gcc -Os' appears always to emit
[03:40:06] <CIA-39> EMC: safe instruction sequences (which are also higher performance on post-pentium
[03:40:09] <jepler> cradek: yes. "value" and "strobe"
[03:40:10] <CIA-39> EMC: systems)
[03:40:12] <CIA-39> EMC: For more details,
[03:40:14] <CIA-39> EMC: 03jepler 07TRUNK * 10emc2/src/Makefile: (log message trimmed)
[03:40:16] <CIA-39> EMC: convert 'hal_float' to a double-precision type.
[03:40:18] <CIA-39> EMC: as discussed at length, pentium-and-above systems can safely write 'double's
[03:40:20] <CIA-39> EMC: with the required atomicitiy guarantee, and 'gcc -Os' appears always to emit
[03:40:22] <CIA-39> EMC: safe instruction sequences (which are also higher performance on post-pentium
[03:40:24] <CIA-39> EMC: systems)
[03:40:26] <CIA-39> EMC: For more details,
[03:40:28] <CIA-39> EMC: 03jepler 07TRUNK * 10emc2/src/hal/ (hal.h hal_lib.c hal_priv.h): (log message trimmed)
[03:40:30] <CIA-39> EMC: convert 'hal_float' to a double-precision type.
[03:40:32] <CIA-39> EMC: as discussed at length, pentium-and-above systems can safely write 'double's
[03:40:33] <cradek> wooo
[03:40:34] <CIA-39> EMC: with the required atomicitiy guarantee, and 'gcc -Os' appears always to emit
[03:40:40] <jepler> cradek: (insert obligatory "that's not the nist model" discussion here)
[03:40:42] <CIA-39> EMC: safe instruction sequences (which are also higher performance on post-pentium
[03:40:44] <CIA-39> EMC: systems)
[03:40:46] <CIA-39> EMC: For more details,
[03:40:48] <CIA-39> EMC: 03jepler 07TRUNK * 10emc2/src/hal/components/ (ddt.comp pid.c streamer.h): (log message trimmed)
[03:40:51] <CIA-39> EMC: convert 'hal_float' to a double-precision type.
[03:40:53] <CIA-39> EMC: as discussed at length, pentium-and-above systems can safely write 'double's
[03:40:55] <CIA-39> EMC: with the required atomicitiy guarantee, and 'gcc -Os' appears always to emit
[03:40:57] <CIA-39> EMC: safe instruction sequences (which are also higher performance on post-pentium
[03:40:58] <SWPLinux> hello, my name is cia-39, and I'm an IRCholic
[03:40:59] <CIA-39> EMC: systems)
[03:41:01] <CIA-39> EMC: For more details,
[03:41:01] <jepler> (an integrator can rationally choose that there will only be a single source affecting some setting)
[03:41:03] <CIA-39> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/ (6 files): (log message trimmed)
[03:41:05] <CIA-39> EMC: convert 'hal_float' to a double-precision type.
[03:41:07] <CIA-39> EMC: as discussed at length, pentium-and-above systems can safely write 'double's
[03:41:12] <cradek> jepler: I don't think it's too contrary. multiple points of control work fine.
[03:41:36] <CIA-39> EMC: with the required atomicitiy guarantee, and 'gcc -Os' appears always to emit
[03:41:36] <CIA-39> EMC: safe instruction sequences (which are also higher performance on post-pentium
[03:41:36] <CIA-39> EMC: systems)
[03:41:36] <CIA-39> EMC: For more details,
[03:41:38] <jepler> cradek: well, I guess the problem is when you have a 4-position switch .. this scheme plus an unexpected second setter leaves your switch indicating the wrong thing
[03:41:46] <jepler> (but as I said, an integrator can know that this will not happen in the final system)
[03:41:46] <cradek> true.
[03:42:00] <jepler> CIA-39: you're done now, right?
[03:42:05] <cradek> "go fast" and "go slow" buttons would be ok though.
[03:42:35] <SWPLinux> huh. I don't see any difference in debounce.c from ~2 hours ago
[03:43:12] <cradek> SWPLinux: you are doing something wrong then...?
[03:43:20] <SWPLinux> cvs diff -u debounce.c
[03:43:49] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/components/debounce.c
[03:43:52] <SWPLinux> I just upped an hour ago actually
[03:44:10] <cradek> you don't expect diff to show you the not-yet-updated change do you?
[03:44:40] <cradek> the command you typed asks it for the difference between the version you last updated to, and your local working copy
[03:45:14] <SWPLinux> oh. I thought it diffed the working copy to the current CVS with whatever tag I have
[03:45:45] <cradek> nope
[03:45:57] <cradek> jepler: well let me just see if that runs here...
[03:47:01] <SWPLinux> heh, so it can tell me what I've done, but not committed changes that I don't have
[03:47:11] <cradek> nope
[03:47:33] <cradek> and I don't think there's a way to get a diff showing what you'd get if you were to run update
[03:47:39] <SWPLinux> huh
[03:48:04] <cradek> I recall that a careful reading of the docs says there IS a way to get that, but I'm pretty sure it doesn't work
[03:48:29] <cradek> -rBASE -rHEAD maybe
[03:49:17] <SWPLinux> yes, that works
[03:49:19] <SWPLinux> thanks
[03:49:25] <cradek> it does??
[03:49:31] <SWPLinux> yep
[03:49:35] <cradek> huh.
[03:49:40] <SWPLinux> cvs diff -u -rBASE -rHEAD xxx
[03:50:09] <SWPLinux> I just like -u better :)
[03:53:27] <cradek> jepler: yes, it does
[03:54:38] <jepler> cradek: good, thanks
[03:54:41] <jepler> * jepler heads off for the night
[03:55:22] <cradek> goodnight
[03:57:25] <SWPLinux> night
[03:58:34] <SWPLinux> if halui has an input for feed limit, it should be able to tell if the pin is connected to anything
[03:59:06] <SWPLinux> then again, you could also set the limit with M1xx halcmd scripts, so that may not be useful
[04:00:35] <cradek> maybe I'm just doing it wrong -- I was thinking I'd have a "Go slow" vcp checkbutton
[04:01:51] <SWPLinux> or a knob that selects several numbers, like (someone) suggested
[04:03:01] <SWPLinux> it may make sense to just have an input, and treat it the way a lot of things treat parameters
[04:03:12] <SWPLinux> if (new != old) {send NML message}
[04:03:42] <cradek> that's kind of tempting too.
[04:03:48] <SWPLinux> it's not like it will jitter much - it (probably) won't be a noisy analog input
[04:04:48] <SWPLinux> note that it doesn't change the setting based on if (input != actual), so it still fits the NIST principle - it only makes a change when the user changes something, and it allows other locus of control to do their things
[04:05:03] <jepler> Microsoft Begs Hardware Makers To Take [Windows 7 Driver] Support Seriously </.headline>
[04:05:06] <SWPLinux> loci?
[04:05:12] <SWPLinux> heh
[04:05:34] <jepler> counterpoint: hardware vendors beg microsoft not to fuck up driver compatability again
[04:06:06] <SWPLinux> so Microsoft is as unimportant as Linux users now?
[04:06:14] <SWPLinux> (to hardware vendors)
[04:07:27] <jepler> well, I'm sure that "begs" is slashdot editorializing
[04:07:41] <SWPLinux> they would never do that!
[04:07:48] <SWPLinux> (you insensitive clod)
[04:08:44] <jepler> now that I can't read a 500-comment election flamewar everyday, I am finding myself at a loss for reading on the web
[04:08:49] <jepler> it's quite sad really
[04:10:18] <SWPLinux> you could try staring at xkcd all day
[04:11:03] <jepler> I'm pretty sure I've read all those
[04:11:29] <SWPLinux> hmmm. maybe try reading some of the Fox News blogs
[04:11:34] <SWPLinux> that's got to be entertaining
[04:12:51] <jepler> oh well, if I manage to quit reading web pages and instead spend some time developing software it'd be like christmas for emc
[04:14:02] <cradek> that would be really nice
[04:14:16] <SWPLinux> oh, I hadn't thought of that
[04:14:37] <SWPLinux> I'm actually trying to write something for EMC, but it's hard
[04:14:58] <cradek> if anyone needs ideas, just let me know.
[04:15:20] <jepler> do you have something specific in mind?
[04:15:26] <SWPLinux> I figured it's time to write a variable editor, but I want to centralize var access first
[04:15:46] <jepler> oh very much good luck to you sir
[04:15:51] <jepler> 'night (for a second time)
[04:16:11] <jepler> remember named variables and function-local variables!
[04:16:17] <jepler> symbolic debugger!
[04:16:22] <jepler> nipple rings!
[04:16:35] <SWPLinux> so I need to figure out how they're loaded in the first place
[04:16:50] <cradek> jepler: a certain gui feature is at the top of my list right now...
[04:17:01] <cradek> but that's only because I want to use it, not because I think it's the most important thing.
[04:17:20] <cradek> nipple rings!?
[04:17:27] <SWPLinux> eww!!
[04:17:30] <fenn> all the bells and whistles
[04:19:03] <jmkasunich> whistles and bells!
[04:19:13] <jmkasunich> (whistles are far more important than bells)
[04:19:22] <cradek> I prefer bells myself
[04:19:41] <fenn> nature always presents gifts not according to the book. when you expect bells it's whistles
[04:20:38] <jmkasunich> except when it's gongs
[04:24:02] <cradek> neat, my compressor cycles in about 2.5 minutes
[04:27:15] <SWPLinux> well, it appears that night time has arrived. good night
[04:27:45] <jmkasunich> cradek: you mean ti takes 2.5 mins to fill the tank?
[04:28:17] <jmkasunich> if it is starting every 2.5 mins, you must have a bad leak somewhere
[04:30:42] <cradek> it stays on for 2.5 minutes whenever it gets low enough to come on
[04:31:49] <cradek> to go from 120ish to 170ish I guess
[10:32:45] <tissf> hi all
[12:09:18] <alex_joni> hi tissf
[14:44:13] <BigJohnT> any ideas as why the classicladder menu choice is grayed out in 2.2.6 even if classicladder is loaded?
[14:45:49] <BigJohnT> http://www.cnczone.com/forums/showthread.php?t=62423&page=3
[14:50:48] <cradek> did you verify that? I used 2.2.6 on my lathe for a while, and I used it all the time
[14:51:13] <BigJohnT> no, this is a guy on the zone
[14:51:31] <BigJohnT> just trying to come up with a suggestion for him to try
[14:51:32] <cradek> I just ran demo_sim_cl and the ladder gui loads fine from the gui
[14:51:34] <jepler> it won't activate during a run of emc
[14:51:53] <jepler> it won't activate if you load classicaldder from postgui.hal
[14:51:55] <cradek> vars.has_ladder.set(hal.component_exists('classicladder_rt'))
[14:52:13] <BigJohnT> jepler: that is where he has it in postgui.hal
[14:52:21] <BigJohnT> thanks
[14:52:23] <cradek> aha
[14:55:40] <skunkworks_> nice
[16:05:46] <cradek> jepler: I'm trying to add the maxvel slider. it is new that a logarithmic slider's value can be set externally, so values it gets set to don't necessarily match one of the values it can represent. Then the two values fight. I'm stuck getting this interaction right. Can you help? Or what should I try?
[16:06:12] <jepler> cradek: ugh
[16:06:16] <SWPLinux> heh
[16:06:25] <cradek> that's kind of how I feel too.
[16:07:08] <SWPLinux> damn. I wish I could remember things
[16:07:10] <cradek> I think my copy-and-paste-until-it-works skills are useless here
[16:09:30] <cradek> I have a vcp config that lets me change the value, and displays the value from halui. I can check this in somewhere if it helps, or I could check in everything I've done so far (gui stuff done, some of the interaction working)
[16:09:57] <SWPLinux> is it branch-worthy?
[16:10:56] <cradek> it's only two files changing...
[16:11:32] <SWPLinux> is the logarithmic slider from VCP or some underlying library?
[16:11:38] <SWPLinux> (ie, do we own the changes)
[16:11:48] <cradek> AXIS's jog speed slider, jepler's doing
[16:11:57] <SWPLinux> ah, ok
[16:12:38] <SWPLinux> my plan would be to wait for jepler to perfect the 2-5-10 slider, then use that ;)
[16:13:21] <cradek> well it will have the same interaction problem, but it might be easier to handle the problem
[16:13:37] <SWPLinux> note the word "perfect" in my previous sentence :)
[16:13:48] <cradek> I could set this value to 1.23456 in halui - what should the 1/2/5 slider do?
[16:14:24] <SWPLinux> it might have a setting for snap to closest/round/truncate, but it should pick a value somehow
[16:15:14] <tissf> jepler: Can I add _() to the functions reportError() in /src/emc/motion/control.c?
[16:15:17] <cradek> maybe it should show the closest 1/2/5 value (1.2?), but the real value would still be 1.23456
[16:15:39] <cradek> or is the closest 1/2/5 value 1?
[16:15:45] <SWPLinux> yes, 1
[16:15:56] <SWPLinux> 2 is further away
[16:16:23] <cradek> so on my lathe I would have .1, .2, .5, 1, 2, 5, 10, 20, 50, 100, 200 ipm?
[16:16:31] <SWPLinux> yep
[16:16:40] <SWPLinux> with a 1/2/5 slider anyway
[16:16:48] <cradek> huh, interesting
[16:16:58] <cradek> those seem like pretty decent values
[16:18:58] <SWPLinux> hmmm, so the code that may set the slider value (from status, for example) sees that the slider value isn't correct, so it sets it again. then the code that monitors the slider sees that the slider can't really be set to that number, changes it to a "valid" number, which causes an NML message (or something) to happen again?
[16:19:24] <SWPLinux> or does it just keep bouncing around visually
[16:19:29] <cradek> something like that
[16:19:49] <micges> I just engraving on machine with vel=20 m/min and acc=2000...
[16:19:54] <cradek> well I have various problems, some are the interaction, some are display
[16:20:15] <SWPLinux> sure, hard to drag when something is updating the value 10 times a second
[16:20:22] <micges> emc handle that with no problem
[16:20:45] <SWPLinux> micges: is that a question or a statement? :)
[16:20:58] <micges> I'm so exited :)
[16:21:06] <SWPLinux> must be a statement ;)
[16:25:09] <SWPLinux> ok, so I think I'll commit this VFD modbus module finally
[16:25:46] <SWPLinux> I think we had figured out that the LGPL3 license on the modbus library doesn't negatively impact the rest of the project
[16:26:26] <SWPLinux> the question is, where should I put the modbus library header and source files?
[16:32:21] <cradek> SWPLinux: are you sure about that [license]?
[16:32:28] <SWPLinux> no
[16:33:01] <SWPLinux> that's the main excuse^Wreason why I haven't committed yet
[16:33:56] <SWPLinux> I'm also unsure as to whether modbus is a sufficiently different category of modules to warrant its own subdirectory (along with the relevant library files and headers)
[16:42:17] <SWPLinux> ah, ok. it looks like you have to convert the project to LGPLv3, so nevermind
[16:42:54] <SWPLinux> I do seem to be using an older (LPGPv2) version of the library though, so I'll try to find out what's been added to the later one
[16:43:20] <SWPLinux> (found that requirement here, in the table at the end:
http://www.gnu.org/licenses/gpl-faq.html )
[16:45:05] <SWPLinux> oh wait, I misread the table. I think it is KN
[16:45:07] <SWPLinux> OK
[16:45:27] <SWPLinux> err, no it isn't
[16:45:41] <SWPLinux> gah - it's pretty darned confusing, I say
[16:51:07] <alex_joni> SWPLinux: there was a license engineer which wrote to the list a while ago
[16:51:19] <alex_joni> form FSF iirc, you might want to drop him an email and ask about it
[16:51:26] <SWPLinux> license engineer, huh? ;)
[16:51:42] <SWPLinux> I'm pretty sure we're in the bottom left block in that table
[16:51:54] <SWPLinux> "I want to release my project under GPLV2 only"
[16:52:04] <SWPLinux> and "I want to use a library under LGPL3"
[16:52:17] <SWPLinux> which says "NO"
[16:53:32] <alex_joni> it seems you have 2 choices
[16:53:48] <jepler> tissf: sorry, I didn't see your question until now
[16:53:54] <SWPLinux> "upgrade" to GPLv3 or use the older library version
[16:53:54] <jepler> tissf: no, I think that is realtime code, and _() can't be used there
[16:54:00] <alex_joni> take the LGPLv2.1 (or later) and convert it to GPLv2
[16:54:27] <alex_joni> or take the LGPLv3 and convert it to GPLv3, but then the rest of emc2 _needs_ to be GPLv2 or later
[16:54:49] <SWPLinux> I don't want to convert anything else in EMC2 to "or later" or GPLV3
[16:54:53] <SWPLinux> or LGPLV3
[16:55:03] <tissf> jepler: OK
[16:55:06] <alex_joni> most of it is "or later"
[16:55:21] <alex_joni> but probably not everything
[16:55:35] <SWPLinux> are you sure?
[16:56:29] <alex_joni> nope
[16:56:38] <alex_joni> looking at hal_priv.h it's GPLv2
[16:57:03] <alex_joni> emc/motion/motion.c is also GPLv2
[16:58:05] <SWPLinux> looking in emc/rs274ngc, some files are V2, gcodemodule.cc is v2 or later ...
[17:00:02] <seb_kuzminsky> roberto caminiti on the emc-users mailing list would benefit from something like "nightly builds" of our binary .debs
[17:00:17] <seb_kuzminsky> has there been any thought given to having the compile farm produce that?
[17:00:25] <alex_joni> yes and no :)
[17:00:26] <SWPLinux> no
[17:00:29] <SWPLinux> and yes
[17:00:30] <SWPLinux> :)
[17:00:39] <seb_kuzminsky> oh good, and bad ;-)
[17:00:52] <alex_joni> seb_kuzminsky: it's not that complicated to do
[17:00:57] <seb_kuzminsky> i agree
[17:01:24] <alex_joni> but it probably means (once it's advertised) that it'll be a bit of a problem to support all kind of newbies with things that break
[17:01:41] <cradek> I don't want general users using release-of-the-day. I think it would be harmful.
[17:01:42] <alex_joni> on the other hand, we would benefit from pre-beta quality testing
[17:01:59] <cradek> compiling from cvs is really NOT a high bar
[17:02:11] <seb_kuzminsky> i think "general users" should be using our supported releases
[17:02:19] <cradek> yes
[17:02:22] <seb_kuzminsky> but compiling from CVS *is* too high a bar for lots of folks
[17:02:47] <alex_joni> I think daily (or even periodic) pre-2.x deb's would have 2 outcomes
[17:02:53] <cradek> I don't know if we would get useful help from those folks then.
[17:02:59] <alex_joni> 1. less pressure on us to release regulary new majour versions
[17:03:14] <alex_joni> 2. get easier beta testing from users for pre-2.x packages
[17:03:22] <seb_kuzminsky> cradek: sometimes it'd be good for them, sometimes it'd be good for us
[17:03:39] <alex_joni> and sometimes it's bad for us, and sometimes it's bad for them :)
[17:04:01] <cradek> "ok, try it now" is a big advantage of testers using cvs
[17:04:25] <seb_kuzminsky> cradek: i agree it's good to be able to get fixes to specific users quickly
[17:04:33] <alex_joni> well.. try it in 30 minutes is not that much worse
[17:05:10] <seb_kuzminsky> having .debs in addition to CVS as a way of getting the software to users would just be another way to do it
[17:05:11] <cradek> if someone who has a system that uses our packages [dapper, hardy], but can't manage to compile from cvs using the step-by-step instructions on the wiki, they are only a liability to us if they run 'rotd'
[17:05:25] <alex_joni> but as I said.. I'm at aroung 40..60% in favour and 40..60% against it :)
[17:06:09] <seb_kuzminsky> cradek: wouldnt those folks be *more* of a drain on our resources if we had to teach them how to compile first?
[17:06:27] <cradek> we don't have to - we point them at the wiki. it has step-by-step instructions.
[17:06:28] <alex_joni> who says we would? :P
[17:06:42] <seb_kuzminsky> cradek: i pointed roberto at the wiki, and he didnt get it
[17:07:09] <seb_kuzminsky> 2.2.6 doesnt work for him, and no one knows when 2.2.7 is coming
[17:07:14] <cradek> I hate to talk badly about any user, but I don't think that disproves my point.
[17:07:41] <BigJohnT> was it a language issue or just that he is so new to linux
[17:07:45] <seb_kuzminsky> so his options are: figure out how to compile the 2.2 branch, or wait
[17:08:05] <cradek> seb_kuzminsky: do you know what he didn't "get"? are the instructions bad at a certian point?
[17:08:13] <seb_kuzminsky> BigJohnT: i think some of both, but it looks like he doesnt know his way around a source tree at all
[17:08:20] <cradek> or did he not read them and/or try
[17:08:24] <seb_kuzminsky> cradek: i'm not sure
[17:08:38] <seb_kuzminsky> i think he was overwhelmed by the first step :-/
[17:08:45] <BigJohnT> you don't need to know much to get and run from cvs
[17:08:57] <seb_kuzminsky> BigJohnT: you do, actually...
[17:09:12] <BigJohnT> but I did it :)
[17:09:24] <seb_kuzminsky> :-)
[17:10:03] <BigJohnT> it's step by step on wiki...
[17:10:11] <cradek> seb_kuzminsky: I think the chances of getting meaningful problem reports and/or test data from him are low then. What you will get (in my opinion) is a bunch of people who want to use new (incomplete or buggy) features but are no assistance, only a drain on our limited "support" ability.
[17:11:33] <seb_kuzminsky> cradek: what do you think i should tell this guy?
[17:11:47] <seb_kuzminsky> figure it out or wait for 2.2.7? (that's not unreasonable i guess)
[17:11:47] <SWPLinux> there are also little problems with repository signing and uploading
[17:12:03] <SWPLinux> and adding the "nightly" repo to your sources list
[17:12:11] <BigJohnT> I even went back to the wiki site during my last cvs install and anything that seemed to confuse me a bit I thought I cleared up
[17:13:28] <cradek> seb_kuzminsky: you should tell him to build cvs, using the step-by-step instructions, and if he gets stuck at a certain step, ask for help so we can fix the instructions.
[17:13:47] <SWPLinux> additionally, installing a nightly version would overwrite the "stable" version, so a user would have to be proficient with apt to be able to get specific versions when they need to revert back
[17:14:08] <alex_joni> SWPLinux: that would be handled by using emc2.3 as the install tree
[17:14:14] <SWPLinux> one advantage of compiling is RIP
[17:14:25] <cradek> SWPLinux: yes I agree - "I updated my system and now it doesn't work"
[17:14:33] <alex_joni> simple scripts to change that part in sources.list and reinstall emc2 might work too
[17:14:34] <SWPLinux> well, there's emc2.2.7~pre
[17:14:38] <SWPLinux> (or similar)
[17:14:38] <alex_joni> but it gets messy easy
[17:14:43] <SWPLinux> then 2.3.0~pre
[17:14:59] <alex_joni> SWPLinux: if you put 2.2.7~pre in the repo, everybody would get it as an update
[17:15:07] <SWPLinux> but they'd both provide an executable called emc, no?
[17:15:10] <alex_joni> so that is a no-go
[17:15:23] <alex_joni> SWPLinux: the package name is emc2
[17:15:31] <alex_joni> you can't install more than one with the same name
[17:15:46] <alex_joni> if you install 2.3.0~pre any other version will get uninstalled automatically
[17:15:59] <SWPLinux> the executable would have the same name and location, and/or you'd end up with weird environment conflicts, no?
[17:16:03] <alex_joni> but the main problem would be that they have to change configs for 2.3.x
[17:16:04] <SWPLinux> that's my point
[17:16:20] <alex_joni> and then when they go back to 2.2.x nothing would work anymore
[17:16:46] <seb_kuzminsky> alex_joni: yes, staying within a range of compatible versions would be advisable :-)
[17:16:52] <SWPLinux> you either have to be good at getting a specific version installed with apt/synaptic, or we have to manage all sorts of crazy crap so they're different package names (and executable names)
[17:16:55] <SWPLinux> right ;)
[17:16:59] <seb_kuzminsky> as indicated by the combination of major and minor version numbers
[17:17:15] <alex_joni> seb_kuzminsky: the idea atm is that 2.2.x is compatible
[17:17:21] <seb_kuzminsky> right
[17:17:23] <alex_joni> 2.3.x doesn't need to be
[17:17:27] <SWPLinux> so I think it's best to have people interested in testing do the compiling themselves :)
[17:17:38] <seb_kuzminsky> so it might make sense to provide nightlies of the 2.2 branch
[17:17:45] <alex_joni> all 2.3.x releases will be compatible, just not with older packages
[17:17:58] <SWPLinux> no, because those would be updates to stable packages also
[17:18:04] <alex_joni> seb_kuzminsky: I'm not sure that makes lots of sense
[17:18:14] <alex_joni> SWPLinux: we can have that fixed somehow.. but still
[17:18:17] <SWPLinux> and even if we separated it into another repo, the install would necessarily overwrite the stable part
[17:18:22] <SWPLinux> s/part/program/
[17:18:30] <alex_joni> 2.2.x releases are all stable
[17:18:41] <SWPLinux> but nightly builds wouldn't be
[17:18:45] <SWPLinux> (necessarily)
[17:18:50] <alex_joni> even 2.2.7~pre or whatever the current HEAD of v2_2_branch is called is stable
[17:18:54] <seb_kuzminsky> SWPadnos: they should be! or we should find out about it asap!
[17:19:08] <SWPLinux> sure, they should be :)
[17:19:09] <alex_joni> * alex_joni agrees they should be/are stable
[17:19:19] <SWPLinux> but no guarantees on a minute-by-minute basis
[17:19:19] <alex_joni> we only backport really _safe_ things :D
[17:19:23] <SWPLinux> heh
[17:19:33] <alex_joni> anyways, we digressed
[17:19:40] <alex_joni> * alex_joni had a point somewhere
[17:19:44] <alex_joni> right..
[17:19:45] <seb_kuzminsky> that's the whole point of the stable branch
[17:19:51] <BigJohnT> I can even crash it with the documents :)
[17:20:07] <alex_joni> the changes from 2.2.6 to 2.2.7 are not that massive/intrusive/big to justify daily builds
[17:20:25] <alex_joni> if there is something critical we usually push a new version 1-2 days, max. a week later
[17:20:35] <SWPLinux> if they are, then maybe it's time for a 2.2.7 release
[17:20:35] <seb_kuzminsky> alex_joni: critical to whom?
[17:20:41] <alex_joni> users
[17:20:49] <jepler> is the problem just that I need to make a release?
[17:21:10] <seb_kuzminsky> jepler: i appreciate all the work you do on releases... it's a tedious job
[17:21:24] <alex_joni> so if you think that by staying at 2.2.6 (not releasing 2.2.7) this weekend is a problem for the hostmot2 stuff, then you should bug jepler that we need a new release
[17:21:59] <seb_kuzminsky> hostmot2 has gone from "barely working" to "pretty good" since 2.2.6
[17:22:13] <seb_kuzminsky> i have users on 2.2.6 who are flailing trying to compile our tree
[17:22:40] <seb_kuzminsky> jepler: what can i do to help with a new release?
[17:23:01] <alex_joni> * alex_joni would like to stick the stg change in there too
[17:23:13] <jepler> seb_kuzminsky: well, can you drive to lincoln and upgrade ingrid's office computers to 8.04? that'll free me up to do the release this weekend instead of that
[17:23:20] <alex_joni> seb_kuzminsky: would this weekend be ok for 2.2.7?
[17:23:27] <SWPLinux> what? 8.10 is out!
[17:23:32] <alex_joni> jepler: I'll send you a vmware image :P
[17:23:39] <alex_joni> dd that to /dev/sda1
[17:23:45] <SWPLinux> har
[17:23:58] <seb_kuzminsky> jeff's time is short, just like all our time is
[17:24:03] <alex_joni> at least then you know it won't work at all :D
[17:24:16] <SWPLinux> cradek, maybe you could upgrade Ingird's office computers so jepler can do a new release?? :)
[17:24:27] <alex_joni> ha
[17:24:38] <seb_kuzminsky> do we release 2.2 .debs for hardy and dapper only?
[17:24:45] <seb_kuzminsky> and by "we" i mean "jeff"
[17:24:55] <SWPLinux> I think so
[17:25:01] <alex_joni> jepler: I can commit to sunday afternoon, to build deb's for hardy i386, and do all the tar.gz release
[17:25:17] <SWPLinux> there's no support for 8.10, and breezy was dropped with 2.2 (IIRC)
[17:25:20] <seb_kuzminsky> god this just cries out for a robot army
[17:25:30] <SWPLinux> or robot overlords
[17:25:31] <cradek> SWPLinux: he did that last weekend, I'm sure of it, because he said he was going to.
[17:25:40] <SWPLinux> hmmm
[17:25:40] <BigJohnT> does the menu items get upgraded to show the Getting Started Guide?
[17:25:48] <alex_joni> seb_kuzminsky: I think atm jeff builds 2.2.x for hardy 64, and dapper i386
[17:25:56] <jepler> * jepler parses seb_kuzminsky's words very carefully to check whether he's volunteering to be release manager
[17:26:01] <cradek> BigJohnT: I do not have that on my 2.2.6 menu
[17:26:07] <seb_kuzminsky> * seb_kuzminsky bites his tongue
[17:26:20] <alex_joni> I build the hardy i386, and do some of the updates (linuxcnc.org and SF sites)
[17:26:35] <alex_joni> at least we did it like that the last couple of times
[17:26:37] <BigJohnT> I thought I added it to the... looking
[17:27:06] <alex_joni> BigJohnT: I think you added Getting Started after 2.2.6
[17:27:41] <BigJohnT> yes, I did... I'm guessing that it won't show up when you do a RIP
[17:27:43] <alex_joni> 2.2.6 was 2008-08-10
[17:27:50] <alex_joni> no it won't :)
[17:28:12] <alex_joni> hmm.. close to 3 months, there should really be a 2.2.7 soon
[17:28:23] <seb_kuzminsky> alex_joni: i agree
[17:28:31] <seb_kuzminsky> what's the release process like? what's involved?
[17:28:35] <seb_kuzminsky> what work needs done?
[17:28:44] <alex_joni> checkouts, run some scripts to build the packages
[17:28:47] <seb_kuzminsky> * seb_kuzminsky greps the wiki
[17:28:50] <SWPLinux> bug jepler and alex, then wait
[17:28:52] <alex_joni> install them, and check if everything looks right
[17:29:04] <alex_joni> then rsync the repo locally, put the packages inside
[17:29:18] <alex_joni> rebuild the repo, sign it with the board key, rsync it up again
[17:29:29] <alex_joni> then bust things borken in steps 1..5
[17:29:33] <seb_kuzminsky> there's a ReleaseCheckList
[17:29:40] <BigJohnT> it would go in emc2/debian/extras-sim-Ubuntu-8.04/usr/share/applications right?
[17:29:46] <BigJohnT> and 6.06
[17:29:47] <alex_joni> BigJohnT: for sim
[17:30:00] <alex_joni> for the regular install there are different folders
[17:30:01] <BigJohnT> crud I'm in sim
[17:30:18] <seb_kuzminsky> we release rt packages only, no sim right?
[17:30:26] <SWPLinux> there are sim packages also
[17:30:34] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ReleaseCheckList
[17:30:47] <alex_joni> I don't think there are packages for sim on hardy
[17:31:42] <alex_joni> there are on dapper though.. not sure why we didn't build them on hardy.. but so far no-one asked about it
[17:33:00] <alex_joni> seb_kuzminsky: the whole process could probably take some more automation, but since we only do it once every couple of weeks/months I'm not sure it's worth the trouble atm
[17:36:40] <seb_kuzminsky> alex_joni: right, the reason to do it would be if we wanted to to the build more frequently
[17:37:06] <seb_kuzminsky> sounds like: i do, y'all dont ;-)
[17:37:26] <seb_kuzminsky> never thought *i* would be a maverick
[17:37:30] <SWPLinux> ewww
[17:37:43] <SWPLinux> shall we call you Sarah now?
[17:37:51] <seb_kuzminsky> i'll go get my lipstick
[17:37:55] <SWPLinux> pig
[17:38:01] <SWPLinux> :)
[17:38:15] <seb_kuzminsky> aw shucks, i dont mind ;-)
[17:38:43] <cradek> that word is forever ruined
[17:39:00] <SWPLinux> I'm just sad that TIna Fey won't have another 4 years of doing impressions of Sarah Palin :)
[17:39:15] <seb_kuzminsky> we'll have to watch the reruns on youtube
[17:39:24] <cradek> you mean senator palin, replacement for ted stevens?
[17:39:34] <SWPLinux> heh
[17:39:44] <SWPLinux> did she get appointed (or would she appoint herself?)
[17:39:55] <SWPLinux> maybe he can be a senator from jail?
[17:40:09] <cradek> I understand there would be a special election if stevens wins and is subsequently kicked out
[17:40:17] <SWPLinux> he won, I think
[17:40:39] <cradek> I don't think that's known yet
[17:47:29] <SWPLinux> smartfood is funny. it either smells really good or really bad. there are no in-betweens
[18:06:05] <skunkworks_> smartfood?
[18:06:25] <SWPLinux> cheese covered popcorn in a bag
[18:06:49] <fenn> sounds funny
[18:07:11] <SWPLinux> http://en.wikipedia.org/wiki/Smartfood
[18:07:18] <SWPLinux> (like you haven't seen it)
[18:07:44] <skunkworks_> huh - don't know if I have seen it.
[18:08:01] <SWPLinux> it's in the potato chip/snack department of just about every store
[18:08:20] <skunkworks_> I guess I don't buy popcorn in a bag.
[18:08:24] <SWPLinux> heh
[18:08:37] <SWPLinux> or potato chips/corn chips/pretzels ... ?
[18:08:43] <SWPLinux> pork rinds
[18:09:37] <fenn> how did fried pig's skin end up in the same category as pretzels?
[18:09:43] <skunkworks_> oh - I like chips in a bag.
[18:09:45] <SWPLinux> I have no idea
[18:09:58] <SWPLinux> but they're usually pretty close by in the store
[18:10:03] <skunkworks_> hmm
[18:10:08] <skunkworks_> I will have to look next tim
[18:10:09] <skunkworks_> time
[18:10:40] <SWPLinux> well, it's not that important
[18:10:50] <skunkworks_> heh
[20:41:56] <seb_kuzminsky> bye for now
[20:58:43] <alex_joni> well.. I managed to patch hal_stg, but in the mean time I can only compile test... and it looks ok here
[21:03:21] <cradek> neat, thanks for doing that
[21:03:25] <cradek> I bet it was a big pain :-)
[21:04:32] <alex_joni> well.. my own doings :D
[21:20:53] <alex_joni> CIA-37: emerge
[21:36:20] <alex_joni> that took a while :)
[21:51:38] <BigJohnT> someone needs to kick CIA-37
[21:51:54] <BigJohnT> * BigJohnT kicks CIA-37
[21:51:54] <CIA-37> ow
[22:19:47] <skunkworks_> * skunkworks_ kicks CIA-37
[22:20:11] <SWPLinux> I guess you have to kick harder
[22:20:14] <skunkworks_> heh
[22:20:26] <skunkworks_> Rough day - I wanted to kick him a few times
[22:20:59] <SWPLinux> bummer
[22:23:03] <skunkworks_> oh well.