#emc-devel | Logs for 2009-06-17

[00:07:20] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/html/gcode.html: add missing r to list of words for g10 l2
[08:04:05] <CIA-2> EMC: 03micges 07TRUNK * 10emc2/src/emc/nml_intf/emcglb.h: Move EMC_TASK_INTERP_MAX_LEN global variable to right place
[08:04:06] <CIA-2> EMC: 03micges 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: Move EMC_TASK_INTERP_MAX_LEN global variable to right place
[09:40:54] <christel> [Global Notice] Hi all! This is shameless network spam I'm afraid, freenode are currently looking to expand our volunteer team. Please check out http://announce.freenode.net/ if you're interested in helping out! Thanks for your consideration and for using freenode.
[10:36:13] <micges> cradek: can you look at this when you can: http://www.pastebin.ca/1463235
[11:47:22] <jepler> micges: to copy a pose field-by-field, use =: + tp->goalPos = tp->currentPos;
[11:49:31] <micges> oh ok, thanks
[11:52:23] <jepler> since EMC_TASK_INTERP_MAX_LEN was formerly only used in emctaskmain.cc I'd rather get rid of its declarations in emcglb.h
[11:52:30] <jepler> unless you have a reason in mind that other files will use it
[11:56:39] <micges> jepler: the second, I'll remove it from emcglb.h later if possible
[12:16:39] <CIA-2> EMC: 03micges 07TRUNK * 10emc2/src/emc/task/taskintf.cc: Cleanup Nan checking code before sending commands
[12:34:25] <CIA-2> EMC: 03micges 07TRUNK * 10emc2/src/emc/task/taskintf.cc: Use whole EmcPose structure copy instead of field by field
[13:08:18] <jepler> those checks for nans should probably be enabled unconditionally
[13:08:37] <jepler> they are not in performance-critical code, and if there are nans there it'll lead to non-working systems anyway
[13:09:30] <jepler> so the two choices are: they're useful (enable them always) or they're not really useful (remove them)
[13:09:41] <SWPadnos> where is EMC_TASK_INTERP_MAX_LEN actually declared now?
[13:09:58] <jepler> SWPadnos: I was also wondering that, but haven't gotten compile errors from the buildbot soi tmu stb eO K
[13:09:58] <SWPadnos> i twent from static (allocates space) to extern (doesn't allocate space)
[13:10:05] <jepler> wow that was pretty special
[13:10:07] <SWPadnos> heh
[13:10:18] <SWPadnos> interleave error
[13:10:31] <cradek> what do you think about enabling the fp traps in trunk?
[13:10:45] <cradek> jepler: your thumb isn't awake yet
[13:11:34] <jepler> cradek: I guess by my own logic, they should be enabled
[13:12:18] <cradek> I'm not abusing you about a potentional inconsistency - I'm genuinely wondering whether it's a good idea
[13:12:51] <SWPadnos> is there a downside to enabling FP traps?
[13:13:03] <SWPadnos> I guess a tiny performance hit
[13:13:04] <jepler> SWPadnos: when it fires, emc crashes
[13:13:05] <cradek> the application crashes where it may have stumbled along before
[13:13:11] <SWPadnos> ah
[13:13:19] <SWPadnos> then I'd say not yet
[13:13:54] <SWPadnos> I was going to say the next possible downside would be uncaught exceptions or the equivalent :)
[13:21:46] <jepler> the fp trap is mostly useful running under the debugger
[13:22:13] <jepler> I can't find a simple way to determine "am I running under gdb"; it seems likely that there isn't an intentional way to tell
[13:24:28] <SWPadnos> a command-line switch could help
[13:25:37] <jepler> nah, it's hard to pass commandline options to task or rtapi_app
[13:25:48] <SWPadnos> ah, ok then
[13:26:43] <SWPadnos> is this a compile-time option or something that can be turned on and off at runtime?
[13:29:37] <jepler> right now, it's an "insert some code to enable"
[13:30:15] <SWPadnos> ok, so it doesn't cause linking to a different math library or anything like that
[13:31:07] <jepler> no
[13:31:26] <jepler> cradek: do you have the snippet handy? is it somewhere but commented out?
[13:31:44] <jepler> ah, here it is
[13:31:45] <jepler> src/emc/task/emctaskmain.cc:66:fpu_control_t __fpu_control = _FPU_IEEE & ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM);
[13:31:59] <jepler> you initialize a global to a specific value according to the traps you want unmasked
[13:32:30] <jepler> refer to the x87 instruction set reference you keep by your desk if you're unsure what those bits mean
[13:32:49] <SWPadnos> ok, so it seems that traps could be a debug option similar to other DEBUG flags
[13:33:05] <jepler> kkno, because it's set before main() starts by assigning a value to a global
[13:33:14] <jepler> and because it's useful in rtapi_app which currently doesn't look at DEBUG or indeed anything from an inifile
[13:33:23] <SWPadnos> ok, nevermind :)
[13:33:24] <jepler> the two main places we've found it useful are task and rtapi_app
[13:33:29] <jepler> s/kkno/no
[13:35:44] <jepler> mmm LD_PRELOAD
[13:36:46] <CIA-2> EMC: 03micges 07TRUNK * 10emc2/src/emc/kinematics/tp.c:
[13:36:46] <CIA-2> EMC: Initialise all TC field on adding to queue
[13:36:46] <CIA-2> EMC: Fix initialisation in tpClear()
[13:59:54] <micges> bbl
[14:38:37] <jepler> pickaxe
[14:38:37] <jepler> All commits that caused the string to appear or disappear from any file (changes that
[14:38:41] <jepler> added, removed or "modified" the string) will be listed. This search can take a while and
[14:38:43] <jepler> takes a lot of strain on the server, so please use it wisely. Note that since you may be
[14:38:46] <jepler> interested even in changes just changing the case as well, this search is case sensitive.
[18:25:46] <jepler> cradek: aha, there is a contributed script 'git-new-workdir' which does what you want
[18:26:01] <jepler> mmmmmaybe
[18:26:46] <jepler> it looks like it's the kind of copy that is useless without the original
[19:38:20] <CIA-2> EMC: 03cradek 07v2_3_branch: * r734f1aeab687 10/README: This is another commit on a branch in the git sandbox.
[19:38:42] <cradek> yay
[19:39:04] <jepler> looks good
[19:39:24] <SWPadnos> yay
[19:39:27] <cradek> yay
[19:39:27] <cradek> yay
[19:39:34] <cradek> * cradek makes a gesture at sendmail
[19:40:55] <cradek> I went ahead and left even "master:" in the subject.
[19:47:48] <cradek> I think the patch emails will be arbitrarily long. I wonder whether that is bad.
[19:48:52] <jepler> hardly anybody has small mailboxes anymore
[19:49:07] <SWPadnos> me, me!
[19:49:26] <SWPadnos> my main mailbox has a 10M limit, strangely enough
[19:49:32] <cradek> haha
[19:49:35] <cradek> * cradek points at SWPadnos
[19:51:14] <cradek> I could limit their size with a simple pipe through head
[19:51:32] <cradek> size in bytes or lines
[19:51:42] <cradek> it would be nicer if the summary would get smarter though in that case, instead of just being cut off.
[19:54:56] <SWPadnos> if wc -l (diff) > 50 head -50 + echo "truncated"
[19:55:00] <SWPadnos> suitably spelled
[19:56:42] <cradek> I meant some summary of the change other than a [truncated] diff
[19:57:22] <SWPadnos> oh
[19:57:32] <SWPadnos> well that's what the commit message is for :)
[19:57:56] <SWPadnos> these diffs are likely to contain changed from several (many) files, right?
[19:57:59] <SWPadnos> changes
[20:08:06] <alex_joni> right
[20:08:40] <jepler> maybe you should show the diffstat output, or something else likely to be not-too-long
[20:09:09] <alex_joni> and link to the gitweb commitdiff
[20:09:13] <alex_joni> like this: http://git.linuxcnc.org/gitweb?p=emc2-sandbox.git;a=commitdiff;h=d06a2bc487cec5db689645312a0c0e3118e97bb7
[20:09:41] <cradek> git show --pretty=format doesn't have a diffstat option
[20:19:15] <jepler> too bad
[20:20:45] <cradek> I was surprised that there wasn't a boilerplate solution for this emailing of diffs - seems like everyone would want what we're used to. (that's a fallacy, I'm sure)
[20:23:21] <jepler> cradek: hm, 'git show --pretty=format:... --stat' dumps the stat info after the format created by --pretty
[20:23:25] <jepler> or you could invoke git show twice?
[20:23:56] <cradek> oh, so "This manual page describes only the most frequently used options" bit me already
[20:24:10] <cradek> do you know where exactly the full documentation is?
[20:24:23] <jepler> no
[20:27:46] <micges> good night all
[20:27:54] <jepler> good night micges