micges1 is now known as micges_plasma
EMC: 03jepler 07v2_3_branch * rb93eb5901bdb 10/lib/python/nf.py.in: fix a lockup bug
EMC: 03jepler 07v2_3_branch * r58fee058e090 10/debian/changelog: note new fix
EMC: 03jepler 07v2_3_branch * r283ab05d3489 10/debian/changelog: note new fixes
EMC: 03jepler 07master * rd51be1e96537 10/share/axis/tcl/cb.tcl: a less sledgehammer fix for the "open file" checkbox lockup bug
ugh -- buildbot starts with an empty git repository every time!?
that simply can't be a good idea
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/
it was noted as still a shortcoming of buildbot not fixed by a proposed patch "20 months ago" http://buildbot.net/trac/ticket/130
and the buildbot people even use git
so for every commit, all ten buildbot machines get entire new git clones?
yes, I think so
hmmm I may be wrong
it may be only after a build that "failed git"
that makes sense
I disabled the buildbot trigger until the connectivity is more reliable
EMC: 03jepler 07master * rd905e4fe4a4d 10/share/axis/tcl/ (cb.tcl rb.tcl): don't enable radiobutton / checkbutton appearance hacks on tk8.5
EMC: 03jepler 07master * r313f7046e982 10/src/emc/ (20 files in 3 dirs): split the interpreter class into its own header file
oops! taht last should have been two commits
(it also made LAZY_CLOSE the (unchangeable) default)
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-06-30.txt
if someone is interested: coverity analyze of emc2 source output: http://www.pastebin.ca/1479659
I would like to ask some specific question about emc2 design
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
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.
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
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
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
perhaps I don't understand the design you are proposing
motion take care about set emc to proper state, but task take care to generate proper error message
If you have a struct, then the fields in that struct impose a very limited idea of what an error message can be
jepler: about your clever design: do you have some lines of code?
no, it's not an easy thing to do.
by the way, the minSoftLimit error is not right
there's no guarantee that task sees every single value that is ever encountered in the realtime motion handler
suppose the position briefly goes outside the limit and then back inside, but during that time task doesn't happen to execute
no operator message will be produced
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
jepler: no, motion take care to catch outside limit, abort motion and reports appropiate bits to task
task normally have about 90% time spent in timer->wait() so there is time to check some additional stuff
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?
reportError is very nice, because it keeps detecting the error condition right with the operator message
ok I understand approach
[19:54:34] <jepler> http://pastebin.ca/1479922
unfortunately "magic_sprintf_like_function" really requires magic :-P or at least it's a lot of work
and for(each %-format in fmt) is a gross over-simplification
jepler: it's something to start from
next question: 2. motion params are set in the same way that commands are, maybe some simpler (/proc, ioctl() some else)?
neither /proc nor ioctl() can work for --enable-simulator.
or on a remote conputer
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)
though that communication should be NML, no?
task issues CANON calls to motion ??
NML is for GUI <=> task
NML is for several things :)
the original design had the motion controller on a separate piece of hardware
--enable-simulator makes motion executes like any other normal task right?
that's one way to say it
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
EMC: 03jepler 07master * r7fbe202ebbc5 10/src/emc/rs274ngc/rs274ngc_pre.cc: lazy close is now the (unchangeable) default
EMC: 03jepler 07master * r4129eb61ab22 10/src/emc/usr_intf/ (Submakefile emcsh.cc): add a way to query the configuration of multiple montiors
EMC: 03jepler 07master * re655c7cab8a8 10/tcl/bin/popimage: center the splash screen on the primary monitor
EMC: 03jepler 07master * rff7fb59c5d9b 10/tcl/bin/popimage: slightly more bulletproof way of referring to the image
Can't bring myself to send.. http://pastebin.ca/1479998
Maybe I just needed to write it down ;)
will you be able to face yourself in the morning?
That is the question.
and really - it would just instigate.
you misspelled "proceeded"
(picked the wrong correct spelling) ;)
skunkworks_: not worth it
alex_joni: yah - not sending it.
oh well - time to mow the lawn - bbl
jmkasunich_ is now known as jmkasunich