Back
[10:12:04] <CIA-22> EMC: 03fenn 07TRUNK * 10emc2/src/emc/usr_intf/axis/etc/axis_big_dro: for easy enlargement just take this supplement
[10:12:04] <CIA-22> EMC: 03fenn 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: split the DRO font into its own x resource so it can be modified separately
[10:19:34] <CIA-22> EMC: 03fenn 07TRUNK * 10emc2/docs/src/gui/axis.lyx: xrdb blurb, axis_big_dro
[10:20:28] <fenn> yeah it's ugly
[16:57:19] <cradek> while ( joint->pos_cmd < comp->entry->nominal ) {
[16:57:19] <cradek> comp->entry--;
[16:57:19] <cradek> }
[16:58:14] <jmkasunich> /* the compensation code has -HUGE_VAL at one end of the table
[16:58:14] <jmkasunich> and +HUGE_VAL at the other so _all_ commanded positions are
[16:58:14] <jmkasunich> guaranteed to be covered by the table */
[16:58:14] <jmkasunich> joint->comp.array[0].nominal = -HUGE_VAL;
[17:00:18] <alex_joni> hrmm
[17:03:37] <cradek> for ( n = 1 ; n < EMCMOT_COMP_SIZE+2 ; n++ ) {
[17:03:51] <cradek> I still haven't read this loop enough times to be confident it's right
[17:04:28] <jmkasunich> the idea is that the table is COMP_SIZE+2 entries long, with the first and last entries guaranteed to contain hugeval
[17:04:45] <jmkasunich> the user supplied entries go in slots 1 thru COMP_SIZE+1
[17:05:02] <jmkasunich> I mean 1 thru COMP_SIZE
[17:05:17] <jmkasunich> the table runs from 0 thru COMP_SIZE+1
[17:06:18] <cradek> tmp1 = comp_entry[1].nominal - comp_entry[0].nominal;
[17:06:18] <cradek> comp_entry[0].fwd_slope =
[17:06:18] <cradek> (comp_entry[1].fwd_trim - comp_entry[0].fwd_trim) / tmp1;
[17:06:31] <cradek> maybe two entries the same will do it?
[17:07:19] <jmkasunich> would, but should be checked for:
[17:07:20] <jmkasunich> /* point to last entry */
[17:07:20] <jmkasunich> comp_entry = &(joint->comp.array[joint->comp.entries]);
[17:07:20] <jmkasunich> if (emcmotCommand->comp_nominal <= comp_entry[0].nominal) {
[17:07:20] <jmkasunich> reportError("joint %d: compensation values must increase", joint_num);
[17:07:22] <jmkasunich> break;
[17:07:24] <jmkasunich> }
[17:07:30] <cradek> sorry I can't compile or run here, so I just paste things
[17:07:38] <cradek> I'll go have breakfast and get a real computer
[17:07:43] <jmkasunich> (that's in command.c, where entries are being passed in from userspace)
[17:07:57] <jmkasunich> I should be less lazy, and build a config that demonstrates the problem
[17:08:07] <cradek> if you run sim you can easily dump the table
[17:29:52] <jmkasunich> strange:
[17:29:59] <jmkasunich> can't open compensation file "/home/jmkasunich/emcdev/emc2head/configs/sim/axis0.comp"
[17:30:08] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head$ ls /home/jmkasunich/emcdev/emc2head/configs/sim/axis0.comp
[17:30:09] <jmkasunich> /home/jmkasunich/emcdev/emc2head/configs/sim/axis0.comp
[17:34:19] <jmkasunich> duh
[17:34:51] <jmkasunich> quotes are not only not needed around the filename in the inifile, they are a bad thing ;-)
[17:35:31] <jmkasunich> damn - why am I not surprized that I don't get the nans
[18:18:46] <jmkasunich> "emc/task/emctask.cc 313: interp_error: Unable to open file" <--- useless error message
[18:19:13] <jmkasunich> line 313 is a generic "print error from buffer" routine
[18:19:25] <jmkasunich> no clue what code put it in the buffer, no clue what file it can't open
[18:21:19] <alex_joni> jmkasunich: what did you try to do?
[18:21:25] <jmkasunich> run his config
[18:21:32] <jmkasunich> I'm chasing possibilities
[18:21:37] <jmkasunich> like his nc_files path
[18:25:20] <jmkasunich> thats not it
[18:25:48] <jmkasunich> not the tool table
[18:26:39] <jmkasunich> frickin var file
[18:27:00] <alex_joni> no way.. really?
[18:27:16] <jmkasunich> yeah, the name in his ini refers to a file I don't have here
[18:27:37] <alex_joni> ahh.. I thought that's what causes the nan
[18:27:46] <alex_joni> and I went.. htf is that possible
[18:27:51] <jmkasunich> and instead of getting "can't open <hisname>.var", I get that stupid useless message "can't open <you need to guess which one> file"
[18:28:06] <alex_joni> jmkasunich: I agree we need to change that
[18:28:09] <alex_joni> * alex_joni goes at it
[18:28:17] <jmkasunich> I still haven't gotten the nan to happen, cause I can't get EMC to start with his config
[18:28:28] <jmkasunich> gotta jumper out this, and fix that, and rename the other thing, etc
[18:28:45] <alex_joni> yeah
[18:39:14] <jmkasunich> arrrrgh
[18:39:24] <alex_joni> ??
[18:39:26] <alex_joni> no nan?
[18:40:02] <jmkasunich> can't get nan error to happen, when I try homing it apparently needs switches which I don't have, when I try a sets to pretend there is a switch it gets a following error
[18:40:21] <jmkasunich> just one thing after another, none of which have ANYTHING to do with the bug I'm trying to find
[18:42:23] <jmkasunich> changed the home vels to zero in the ini file so it won't go hunting for non-existant switches
[18:42:27] <jmkasunich> now it homes
[18:42:33] <jmkasunich> mdi X moves, still no NAN
[18:46:33] <alex_joni> jmkasunich: can you paste the error you got earlier when the var file wasn't there?
[18:47:24] <jmkasunich> emc/task/emctask.cc 313: interp_error: Unable to open file
[18:47:24] <jmkasunich> Unable to open file
[18:48:00] <alex_joni> ok, thanks
[18:54:02] <alex_joni> Starting EMC2...
[18:54:02] <alex_joni> emc/task/emctask.cc 313: interp_error: Unable to open parameter file sim_mm2.var
[18:54:30] <jmkasunich> thats more better, thanks
[18:54:46] <alex_joni> emc/task/emctask.cc 313: interp_error: Unable to open parameter file: 'sim_mm2.var'
[18:54:49] <alex_joni> Unable to open parameter file: 'sim_mm2.var'
[18:54:58] <alex_joni> I'll leave it like that
[18:58:21] <CIA-21> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/rs274ngc/rs274ngc_pre.cc: improve error message
[18:58:42] <alex_joni> * alex_joni hugs CIA-21
[18:58:43] <CIA-21> * CIA-21 hugs alex_joni
[19:09:48] <jmkasunich2_> cvs up loads 300 files......
[19:11:25] <alex_joni> jmkasunich2_: I figure out when it happens
[19:11:36] <jmkasunich2_> when?
[19:11:36] <alex_joni> if I put the minimal value in the comp file to -2
[19:11:46] <alex_joni> if I jog between -2 and 0 it's ok
[19:11:59] <alex_joni> as soon as I jog further away from 0 then -2 it nan's
[19:12:27] <jmkasunich2_> hmm
[19:12:28] <alex_joni> (doesn't matter if I'm homed or not)
[19:12:41] <jmkasunich2_> so its something about going below the bottom of the comp file
[19:12:56] <jmkasunich2_> that _should_ be handled - there is code specifically to deal with that case
[19:13:03] <alex_joni> same happens hit g0x-3
[19:13:04] <jmkasunich2_> I'm still building here
[19:13:11] <alex_joni> with
[19:16:07] <alex_joni> jmkasunich2_: I think I see the issue
[19:16:13] <alex_joni> you set the nominal to HUGE_VAL
[19:16:20] <alex_joni> but forward and reverse are 0
[19:16:45] <jmkasunich2_> forward and reverse slopes and corrections are zero
[19:17:01] <jmkasunich2_> I don't store "actuals", everything in the RT code deals with corrections to nominal
[19:17:54] <jmkasunich2_> still building - gawd this is slow
[19:18:24] <alex_joni> hmm.. you're right
[19:24:50] <jmkasunich2_> yay! replicated the problem
[19:25:10] <alex_joni> cool
[19:27:15] <alex_joni> I'm not sure I follow your command.c EMCMOT_SET_JOINT_COMP code
[19:28:01] <jmkasunich2_> I'm in there right now
[19:28:10] <alex_joni> shouldn't comp.entries default to 1?
[19:28:14] <jmkasunich2_> added a print, but forgot that you can't print floats from kernel space
[19:28:25] <alex_joni> in motion.c when initializing the array
[19:28:34] <jmkasunich2_> I don't think so
[19:28:46] <jmkasunich2_> entries is the count of user supplied entries
[19:28:53] <alex_joni> ok
[19:28:57] <jmkasunich2_> doesn't count the dummy entry at the start, or the many dummies at the end
[19:29:05] <alex_joni> so wht is comp_entry[0] then?
[19:29:10] <jmkasunich2_> a dummy
[19:29:13] <jmkasunich2_> -HUGEVAL
[19:29:54] <alex_joni> ah, and the next time comp_entry[0] will actually be [1] ?
[19:30:23] <jmkasunich2_> hang on
[19:30:28] <jmkasunich2_> I can't follow two things at once
[19:30:45] <jmkasunich2_> that code mixes array and pointer syntax
[19:31:02] <alex_joni> * alex_joni hangs back
[19:31:05] <jmkasunich2_> comp_entry is a pointer to the previous last entry
[19:31:33] <jmkasunich2_> so comp_entry[0] is that last entry
[19:31:44] <jmkasunich2_> and comp_entry[1] is the space for the new entry
[19:31:54] <jmkasunich2_> and yes, later comp_entry will point to a differnet place
[19:32:17] <jmkasunich2_> I was confusing comp_entry[0] with comp_array[0]
[19:32:29] <jmkasunich2_> comp_array is the actual array, it always points to the same place
[19:32:36] <alex_joni> right
[19:32:47] <jmkasunich2_> comp_array[0] is the -HUGEVAL dummy, comp_array[1] is the first users supplied entry, etc
[19:34:32] <alex_joni> hmmm..
[19:34:41] <alex_joni> some systems define HUGE_VAL as 1.0/0.0
[19:34:57] <jmkasunich2_> so HUGEVAL is a NAN?
[19:35:00] <jmkasunich2_> thats stupid
[19:35:22] <jmkasunich2_> INF could be defined that way, but HUGEVAL is supposed to be the biggest "normal" number
[19:35:53] <alex_joni> The macros HUGE_VAL, HUGE_VALF, HUGE_VALL expand to constants of types double, float and long double, respectively, that represent a large positive value, possibly plus infinity.
[19:36:31] <jmkasunich2_> bastids
[19:37:31] <alex_joni> what's the printf for doubles again? %g ?
[19:37:52] <jmkasunich2_> in kernel space there isn't one
[19:39:46] <alex_joni> HUGE_VAL = inf
[19:40:14] <alex_joni> I get that from emctaskmain.cc:main() : printf("HUGE_VAL = %g\n", HUGE_VAL);
[19:40:30] <alex_joni> now when you do math with inf, it most likely results in nan
[19:40:36] <jmkasunich2_> crap
[19:40:51] <alex_joni> we'll need a smaller HUGE_VAL :)
[19:41:41] <alex_joni> maybe MAXDOUBLE ?
[19:41:49] <alex_joni> #define MAXDOUBLE 1.79769313486231570e+308
[19:42:08] <jmkasunich2_> I didn't know there were such things as MAX_
[19:42:12] <jmkasunich2_> are there mins too?
[19:42:37] <alex_joni> I got a hit on google
[19:42:42] <alex_joni> but it was a win header file
[19:42:57] <alex_joni> http://graphics.ethz.ch/pointshop3d/sourcedoc/html/win32__values_8h.html
[19:42:59] <alex_joni> maybe we can just use them
[19:43:09] <jmkasunich2_> hang on
[19:43:22] <jmkasunich2_> I can't think and talk and test at the same time
[19:43:35] <alex_joni> ok, no issues
[19:44:35] <jmkasunich2_> first things first, I need to dump the table to the kernel log so I can see what is in there
[19:44:47] <jmkasunich2_> then I'll look at the math that happens in RT when you move
[19:46:36] <jmkasunich2_> ok, the table data is fine - including zero slopes on both ends
[19:48:17] <jmkasunich2_> dpos = pos_cmd - entry->nominal
[19:48:30] <jmkasunich2_> so if nominal is -INF, dpos will be INF
[19:48:32] <jmkasunich2_> then:
[19:48:56] <jmkasunich2_> correction = entry->trim + entry->slope * dpos
[19:49:05] <alex_joni> 0 * inf = nan?
[19:49:29] <jmkasunich2_> even though slope is zero, if dpos is INF, it must make an NAN
[19:49:46] <jmkasunich2_> * jmkasunich2_ is very very annoyed at the morons who defined HUGEVAL as an INF
[19:50:02] <jmkasunich2_> if I wanted INF I'd ask for one dammit, HUGEVAL is supposed to be a real number
[19:50:15] <alex_joni> it's HUGE_VAL
[19:50:20] <jmkasunich2_> whatever
[19:51:09] <alex_joni> right :)
[19:51:12] <LawrenceG> ok I guess HUGEVAL needs to be = INF - ittybittyNUM
[19:51:35] <LawrenceG> not helping.... sorry
[19:51:44] <jmkasunich2_> heh, except that won't work either INF +/- anything still is INF I bet
[19:52:09] <alex_joni> inf-inf is still inf
[19:52:11] <alex_joni> or nan?
[19:52:21] <jmkasunich2_> doesn't matter - its not a real number
[19:52:59] <jmkasunich2_> http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_17.html
[19:53:09] <jmkasunich2_> "In particular, the macro DBL_MAX might be more appropriate than HUGE_VAL for many uses other than testing for an error in a mathematical function."
[19:54:08] <jmkasunich2_> no idea if our kernel space subset of FP math defines DBL_MAX, I guess I'll try it and see
[19:54:24] <jepler> I think the only one you get at present is HUGE_VAL
[19:54:40] <jepler> src/rtapi/rtapi_math.h
[19:54:46] <jmkasunich2_> yep
[19:55:10] <jepler> if you know which ones you want/need I'm happy to add them
[19:55:39] <jmkasunich2_> DBL_MAX and DBL_MIN (if gnu defines the latter)
[19:55:58] <jmkasunich2_> if not I'll use -DBL_MAX, but I'm not sure the range is symmetrical
[19:56:46] <alex_joni> you don't want to use DBL_MIN
[19:56:52] <alex_joni> that's the smallest double value
[19:56:55] <alex_joni> but it's positive
[19:57:14] <jmkasunich2_> smallest as in "closest to zero", not "most negative"
[19:57:22] <alex_joni> (smallest in magnitude as defined by IEEE-754)
[19:57:25] <jmkasunich2_> also stupid
[19:57:46] <jmkasunich2_> if DBL_MIN > -1, then it isn't very MIN, IMNSHO
[19:57:49] <alex_joni> jmkasunich2_: you wouldn't want to hear what threads I just read about these things
[19:58:11] <alex_joni> did you know that pow(nan, 0) on some systems is 1 ?
[19:59:53] <jepler> jmkasunich2_: my test indicates that the header file <float.h> is available for both sim and realtime, and it provides DBL_MAX and related defines (but not the HUGE_VAL familyT)
[20:00:13] <jmkasunich2_> interesting
[20:00:32] <jmkasunich2_> should we include it from rtapi_math.h, or directly in the code that needs those defines?
[20:01:33] <jmkasunich2_> grepping the entire /src tree shows the compensation code as the ONLY code using HUGEVAL
[20:01:38] <jepler> jmkasunich2_: I dunno, I'm comfortable either way
[20:01:44] <jmkasunich2_> HUGE_VAL
[20:01:49] <alex_joni> heh
[20:02:16] <jmkasunich2_> so I suggest that we lose the copy/pasted definition of hugeval in rtapi_math, and include float.h from there instead
[20:02:24] <jepler> -HUGE_VAL should be finite. IEEE doubles are sign-magnitude.
[20:02:39] <jmkasunich2_> jepler: sane people would think so
[20:02:43] <jmkasunich2_> but apparently its not
[20:02:48] <jepler> errrrr
[20:02:52] <jepler> -DBL_MAX shold be finite
[20:03:01] <jmkasunich2_> oh
[20:03:09] <jepler> I dunno about HUGE_VAL, some of these comments in headers seem to indicate it's supposed to be 'inf'
[20:03:11] <jmkasunich2_> agreed
[20:03:13] <jepler> sorry for the confusion
[20:03:40] <jmkasunich2_> glibc manual: "Macro: double HUGE_VAL
[20:03:40] <jmkasunich2_> An expression representing a particular very large number. On machines that use IEEE floating point format, the value is "infinity". On other machines, it's typically the largest positive number that can be represented. "
[20:04:07] <jepler> removing HUGE_VAL from rtapi_math.h in TRUNK is fine by me as well
[20:04:18] <jmkasunich2_> a couple lines later it suggests that DBL_MAX might be more appropriate for some things (like what the comp code is doing)
[20:04:45] <jepler> but I'd leave it in for 2.2.x just in case someone else is using it in a component and getting the desired result
[20:05:06] <jmkasunich2_> I'm gonna look at float.h first to make sure it doesn't drag in anything else we might not want
[20:05:13] <alex_joni> jepler: the only issue is with comp tables
[20:05:27] <jmkasunich2_> if its OK, I'll remove HUGE_VAL and replace with DBL_MAX and -DBL_MAX
[20:05:28] <alex_joni> and that is easily fixed in 2.2.x by including a value for the minimal travel
[20:05:37] <jmkasunich2_> alex_joni: he means private comps that aren't in CVS
[20:05:40] <alex_joni> jmkasunich2_: you keep looking, I'll make a patch
[20:05:59] <jmkasunich2_> awwww, /me wants to make the patch
[20:06:08] <alex_joni> jmkasunich2_: I KNOW.. I just said that the only issue we have in CVS is with comp, and there's a workaround users can use
[20:06:23] <jepler> jmkasunich2_: on my system, <float.h> is /usr/lib/gcc/i486-linux-gnu/4.1/include/float.h and doesn't indirectly include anything.
[20:06:23] <alex_joni> ok, you do the patch, I'll look at float.h
[20:07:08] <alex_joni> it's 4.0.3/.. on dapper
[20:07:28] <jepler> it defines various things, none of which send up red flags for me
[20:07:48] <alex_joni> and it also undef's a couple of things (redefining them)
[20:08:12] <jmkasunich2_> yeah
[20:08:18] <jmkasunich2_> looks fairly safe to me
[20:08:30] <alex_joni> so where do the __DBL_MAX__ come from?
[20:08:40] <jepler> they are built in
[20:08:52] <jepler> # 1 "<built-in>"
[20:08:52] <jepler> #define __DBL_MAX__ 1.7976931348623157e+308
[20:08:59] <jepler> (from gcc -dD -E - < /usr/lib/gcc/i486-linux-gnu/4.1/include/float.h)
[20:09:06] <jmkasunich2_> would it be impolite to just use the built-ins?
[20:09:27] <jepler> DBL_MAX is specified in a standard, __DBL_MAX__ is simply the way gcc implements it
[20:09:37] <jmkasunich2_> ok
[20:09:38] <jepler> so it matters how portable you want to believe hal/rtapi code is
[20:09:43] <jmkasunich2_> DBL_MAX it will be
[20:10:05] <jepler> ISO C Standard: 5.2.4.2.2 Characteristics of floating types <float.h>
[20:12:06] <alex_joni> seems the DBL_MAX is fairly standard
[20:13:49] <alex_joni> jmkasunich2_: so it works?
[20:13:51] <jmkasunich2_> yay, no nans
[20:13:52] <jmkasunich2_> yes
[20:13:56] <alex_joni> great
[20:18:45] <CIA-21> EMC: 03jmkasunich 07TRUNK * 10emc2/src/rtapi/rtapi_math.h: change from HUGE_VAL to DBL_MAX to fix NAN that appears when you move below the lower extent of a screw comp file
[20:18:45] <CIA-21> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/motion/ (command.c motion.c): change from HUGE_VAL to DBL_MAX to fix NAN that appears when you move below the lower extent of a screw comp file
[20:19:04] <jmkasunich2_> jepler: do you want to backport, or should I?
[20:19:37] <jmkasunich2_> I removed the copied definition of HUGE_VAL on trunk, we could leave it and just add the #include <float.h> for 2.2
[20:19:59] <jmkasunich2_> the change to control.c and motion.c would be the same either way
[20:21:28] <jepler> jmkasunich2_: sorry, got distracted
[20:21:38] <jepler> jmkasunich2_: I can back port it if you like
[20:23:02] <jmkasunich> if you don't mind I'd appreciate it
[20:23:15] <jmkasunich> my 2.2 checkout isn't up to date at the moment
[20:28:05] <CIA-21> EMC: 03jepler 07v2_2_branch * 10emc2/src/hal/drivers/ (pluto_common.h pluto_step.comp): fix a problem going beyond +-2^20 counts
[20:32:26] <CIA-21> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/motion/ (command.c motion.c): from TRUNK: fix NAN that appears when you move below the lower extent of a screw comp file
[20:33:20] <jmkasunich> jepler: I think you forgot to include float.h in command.c
[20:33:22] <CIA-21> EMC: 03jepler 07v2_2_branch * 10emc2/src/hal/drivers/pluto_servo.comp: from TRUNK: fix reversed order of parameters to PWM function
[20:33:39] <alex_joni> it's there
[20:33:51] <alex_joni> oh.. I only looked at one
[20:33:51] <CIA-21> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note new fixes
[20:34:09] <jepler> huh -- it built
[20:34:14] <jepler> and runs
[20:34:18] <jmkasunich> both command.c and motion.c use DBL_MAX now
[20:34:21] <jepler> I agree I only included it in one file though
[20:35:53] <jepler> 1.37 (paul_c 23-May-05): #include <float.h>
[20:35:53] <jepler> I guess it was already there
[20:35:59] <jepler> 1.1 (mshaver 01-Feb-04): #include <float.h>
[20:36:02] <jepler> I guess it was *always* there
[20:36:06] <jmkasunich> huh
[20:36:50] <alex_joni> #ifdef COMPING
[20:36:50] <alex_joni> #include <float.h>/* DBL_MIN */
[20:36:50] <alex_joni> #endif /* COMPING */
[20:36:59] <alex_joni> from emcmot.c (emc1)
[20:37:12] <jmkasunich> lol - it was even being used for the same thing I bet
[20:37:37] <alex_joni> yes, except that DBL_MIN was used, not DBL_MAX
[20:37:48] <jmkasunich> oh, never mind
[20:37:51] <alex_joni> and they looked at the correction or difference
[20:39:23] <alex_joni> http://cvs.linuxcnc.org/cvs/emc/src/emcmot/emcmot.c.diff?r1=1.7;r2=1.8
[20:39:34] <alex_joni> Fri Aug 11 18:02:26 2000 UTC (7 years, 5 months ago) by proctor
[20:39:40] <alex_joni> (just for giggles :)
[20:43:28] <jepler> some days I wonder how long it would take to make a "fresh" cnc system, throwing out everything in emc but hal+rtapi
[20:43:57] <jmkasunich> a very long time
[20:44:10] <alex_joni> jepler: it depends what you expect of it
[20:44:32] <alex_joni> if you expect it to be sane? or work somehow predefined by some standard .. it might be a long time
[20:44:51] <alex_joni> if you expect it to run like a commercial machine, or like emc2 does now.. a really long time :)
[20:45:00] <jepler> oh, I dunno. After implementing both G0 and M2, I'd declare success
[20:45:13] <alex_joni> G1 instead of G0 :)
[20:45:19] <jepler> then I have to implement F
[20:45:25] <alex_joni> yup
[20:45:36] <jepler> guess there's no such thing as simple cnc
[20:45:36] <jmkasunich> "Mission Accomplished"
[20:45:45] <alex_joni> bet people would have to run their g-code through yapps first :P
[20:45:51] <jepler> no doubt
[20:46:18] <alex_joni> jepler: maybe we should ponder about replacing task
[20:46:41] <alex_joni> I can do the documentation work (what happens now, when, etc..)
[20:46:53] <alex_joni> so we can replicate the behaviour
[20:47:50] <jepler> my happy place doesn't involve making anything that is too much like 'task'
[20:48:03] <jepler> don't take my suggestion too seriously anyway
[20:48:12] <alex_joni> my happy place doesn't involve coding :)
[20:48:30] <jepler> bah, what would you do with your time?
[20:48:40] <alex_joni> well.. even at the moment it's like that
[20:48:51] <alex_joni> I keep throwing a bug between me and my happy place
[20:49:09] <alex_joni> when I finished coding and it even works.. I'm happy :)
[20:49:26] <alex_joni> I admit I get bored in my happy place sometimes :P
[20:52:44] <CIA-21> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/pluto_step.comp: from branch: fix 2^20 counts bug
[20:53:17] <CIA-21> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/mesa_5i2x/firmware/Makefile: this makefile rule uses bashisms, but make uses /bin/sh which is not bash on gutsy
[20:53:34] <jmkasunich> what is bin/sh on gutsy?
[20:53:40] <alex_joni> dash
[20:53:50] <alex_joni> (moronic imho)
[20:54:05] <jepler> "dash" is a POSIX compliant shell that is much smaller than "bash".
[20:54:31] <alex_joni> still.. I would understand that for the server version
[20:54:46] <jepler> more dash-related problems will get fixed when they subject everybody to it :-P
[20:54:48] <alex_joni> but for a Gnome install .. I don't think you feel the difference.. do you?
[20:54:56] <alex_joni> haha
[20:56:13] <jmkasunich> is it change for the sake of change, or what?
[20:57:05] <alex_joni> we kinda did the same with emc2.0.0
[20:57:58] <jmkasunich> change for the sake of change? I don't think so
[20:58:21] <jmkasunich> we could never have taken emc1 where emc2 is now - the codebase was too complex
[20:58:22] <alex_joni> no.. but throw it at people to get feedback and stuff fixed
[20:58:30] <jmkasunich> oh, I understand
[20:58:30] <alex_joni> I agree
[20:58:36] <jepler> booting runs a *lot* of separate bash procesess. I would not be surprised if improved boot time was measured when they switched to dash
[20:58:50] <jepler> er, a lot of sh processes
[20:59:08] <alex_joni> and changing those calls to dash would have been uglier?
[20:59:17] <alex_joni> or maybe setting sh for the users to bash..
[20:59:36] <alex_joni> * alex_joni knows to little to have a *real* oppinion
[21:03:28] <jepler> https://wiki.ubuntu.com/DashAsBinSh in case you want to read more about why
[21:20:30] <jepler> bbl
[23:42:35] <Roguish> yoohoo, SWPadnos, you there?
[23:43:08] <Roguish> i just put the 2nd 5i20 board in my test setup. how does emc know which one is 1 and which one is 2?
[23:43:16] <Roguish> anyone else also?
[23:43:39] <Roguish> something in the order of the pci slots?
[23:44:51] <jepler> Roguish: emc depends on the order that the kernel API pci_find_device enumerates the devices
[23:45:50] <jepler> I don't see an order specifically documented (
http://people.nl.linux.org/ftp/pub/anoncvs/kernelnewbies/documents/kdoc/kernel-api/r7868.html) but I assume it's deterministic for any given kernel and hardware setup
[23:46:01] <jepler> (they're probably numbered 0 and 1 anyway :-P)
[23:46:17] <Roguish> ok, looking at the manual for the mb, i don't see any listing of which slot is which.
[23:47:50] <Roguish> the board has 3 slots. right now my boards are backwards. jogging axis 0 jogged a motor on the new board. guess i'll swich the cabbles.
[23:48:23] <Roguish> brb. gotta shut down to switch cables.
[23:58:45] <jepler> http://graphics.pixar.com/DinoInputDevice/paper.pdf