Back
[06:57:00] <micges1> micges1 is now known as micges_plasma
[13:07:43] <CIA-1> EMC: 03jepler 07v2_3_branch * rb93eb5901bdb 10/lib/python/nf.py.in: fix a lockup bug
[13:07:43] <CIA-1> EMC: 03jepler 07v2_3_branch * r58fee058e090 10/debian/changelog: note new fix
[13:07:52] <CIA-1> EMC: 03jepler 07v2_3_branch * r283ab05d3489 10/debian/changelog: note new fixes
[13:07:53] <CIA-1> EMC: 03jepler 07master * rd51be1e96537 10/share/axis/tcl/cb.tcl: a less sledgehammer fix for the "open file" checkbox lockup bug
[13:52:21] <jepler> ugh -- buildbot starts with an empty git repository every time!?
[13:56:42] <cradek> that simply can't be a good idea
[13:57:18] <jepler> I noticed this in the log of a build: Initialized empty Git repository in /var/lib/buildbot/emc2-hardy-rtai-amd64/hardy-amd64-2.3-sim/source/.git/
[13:57:50] <jepler> it was noted as still a shortcoming of buildbot not fixed by a proposed patch "20 months ago"
http://buildbot.net/trac/ticket/130
[13:58:15] <cradek> lovely.
[14:00:35] <jepler> and the buildbot people even use git
[14:02:19] <cradek> so for every commit, all ten buildbot machines get entire new git clones?
[14:03:17] <jepler> yes, I think so
[14:07:50] <jepler> hmmm I may be wrong
[14:08:02] <jepler> it may be only after a build that "failed git"
[14:08:17] <cradek> that makes sense
[14:08:48] <cradek> I disabled the buildbot trigger until the connectivity is more reliable
[14:42:52] <CIA-1> EMC: 03jepler 07master * rd905e4fe4a4d 10/share/axis/tcl/ (cb.tcl rb.tcl): don't enable radiobutton / checkbutton appearance hacks on tk8.5
[14:46:25] <CIA-1> EMC: 03jepler 07master * r313f7046e982 10/src/emc/ (20 files in 3 dirs): split the interpreter class into its own header file
[14:59:08] <jepler> oops! taht last should have been two commits
[14:59:18] <jepler> (it also made LAZY_CLOSE the (unchangeable) default)
[16:01:17] <micges> logger_dev: bookmark
[16:01:17] <micges> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-06-30.txt
[16:03:30] <micges> if someone is interested: coverity analyze of emc2 source output:
http://www.pastebin.ca/1479659
[19:27:53] <micges> I would like to ask some specific question about emc2 design
[19:31:44] <micges> 1. emcmot reports error as strings, is there any reason to not create error struct between motion<=>task and create error reports in user space? advantages: more universal motion, translatable error messages
[19:33:04] <jepler> Numbered tables of errors don't work well. Printf-style formats do. I just got done removing all the numbered errors from the interpreter, and replacing hal- and rtapi-specific numbered errors with unix errnos. I don't want to go the opposite direction on that.
[19:33:32] <jepler> I'd rather see a clever design where the printf-style arguments can be transferred from RT to userspace for gettext-style translation and final formatting
[19:34:01] <jepler> on the other hand, I'm not about to actually spend my time *implementing* that, so whoever does so probably gets to win the technical debate
[19:37:44] <micges> I'm not talking about error tables, rather generating printf error from status struct in task, in some simmilar way that is done now with minSoftLimit
[19:38:26] <jepler> perhaps I don't understand the design you are proposing
[19:38:47] <micges> motion take care about set emc to proper state, but task take care to generate proper error message
[19:38:52] <jepler> If you have a struct, then the fields in that struct impose a very limited idea of what an error message can be
[19:40:43] <micges> jepler: about your clever design: do you have some lines of code?
[19:40:58] <jepler> no, it's not an easy thing to do.
[19:41:32] <micges> ok
[19:42:31] <jepler> by the way, the minSoftLimit error is not right
[19:42:52] <jepler> there's no guarantee that task sees every single value that is ever encountered in the realtime motion handler
[19:43:15] <jepler> suppose the position briefly goes outside the limit and then back inside, but during that time task doesn't happen to execute
[19:43:20] <jepler> no operator message will be produced
[19:43:57] <jepler> error messages won't be reliable if they are produced by non-realtime code inspecting emcStatus and are due to external conditions that can be transient
[19:44:30] <micges> jepler: no, motion take care to catch outside limit, abort motion and reports appropiate bits to task
[19:46:02] <micges> task normally have about 90% time spent in timer->wait() so there is time to check some additional stuff
[19:47:30] <jepler> there are 75 calls to reportError in src/emc. Is that 75 different fields to check in emcStatus? If tomorrow there's another error condition, is that a 76th?
[19:47:49] <jepler> reportError is very nice, because it keeps detecting the error condition right with the operator message
[19:49:28] <micges> ok I understand approach
[19:54:34] <jepler> http://pastebin.ca/1479922
[19:55:10] <jepler> unfortunately "magic_sprintf_like_function" really requires magic :-P or at least it's a lot of work
[19:55:25] <jepler> and for(each %-format in fmt) is a gross over-simplification
[19:56:46] <micges> jepler: it's something to start from
[20:00:39] <micges> next question: 2. motion params are set in the same way that commands are, maybe some simpler (/proc, ioctl() some else)?
[20:01:04] <jepler> neither /proc nor ioctl() can work for --enable-simulator.
[20:01:20] <SWPadnos> or on a remote conputer
[20:02:22] <micges> ok
[20:03:03] <jepler> SWPadnos: if micges is talking about communication between task and motion, that's not true (task and motion already have to be on the same machine and communicate via shared memory)
[20:03:16] <SWPadnos> ah, ok
[20:03:35] <SWPadnos> though that communication should be NML, no?
[20:03:56] <SWPadnos> task issues CANON calls to motion ??
[20:04:01] <micges> NML is for GUI <=> task
[20:04:11] <SWPadnos> NML is for several things :)
[20:04:35] <SWPadnos> the original design had the motion controller on a separate piece of hardware
[20:07:08] <micges> --enable-simulator makes motion executes like any other normal task right?
[20:07:38] <jepler> that's one way to say it
[20:08:14] <jepler> it's an implementation of rtapi that does makes all "realtime components" a part of a single userspace process that doesn't require any non-user permissions
[20:09:09] <micges> I see
[20:23:42] <CIA-1> EMC: 03jepler 07master * r7fbe202ebbc5 10/src/emc/rs274ngc/rs274ngc_pre.cc: lazy close is now the (unchangeable) default
[20:23:44] <CIA-1> EMC: 03jepler 07master * r4129eb61ab22 10/src/emc/usr_intf/ (Submakefile emcsh.cc): add a way to query the configuration of multiple montiors
[20:23:44] <CIA-1> EMC: 03jepler 07master * re655c7cab8a8 10/tcl/bin/popimage: center the splash screen on the primary monitor
[20:25:04] <CIA-1> EMC: 03jepler 07master * rff7fb59c5d9b 10/tcl/bin/popimage: slightly more bulletproof way of referring to the image
[21:03:23] <skunkworks_> Can't bring myself to send..
http://pastebin.ca/1479998 Maybe I just needed to write it down ;)
[21:04:15] <cradek> will you be able to face yourself in the morning?
[21:04:31] <skunkworks_> That is the question.
[21:04:45] <skunkworks_> and really - it would just instigate.
[21:05:21] <cradek> you misspelled "proceeded"
[21:05:25] <cradek> :-)
[21:05:28] <jepler> bbl
[21:05:30] <skunkworks_> heh
[21:05:41] <skunkworks_> Thanks
[21:06:27] <skunkworks_> (picked the wrong correct spelling) ;)
[21:20:32] <alex_joni> skunkworks_: not worth it
[21:22:04] <skunkworks_> alex_joni: yah - not sending it.
[21:22:28] <alex_joni> smart
[21:22:35] <skunkworks_> oh well - time to mow the lawn - bbl
[21:55:52] <jmkasunich_> skunkworks: heh
[21:58:01] <jmkasunich_> jmkasunich_ is now known as jmkasunich