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