I just noticed that Red Hat over the next year will be migrating from CVS to git; apparently Fedora already has. (Git story starts below screenshot, "In a related news...") http://distrowatch.com/weekly.php?issue=20101101#news
The next story tells of Ubuntu's choice of Unity desktop over Gnome 3.0 shell for 11.04. Some disapprove.
cvs isn't dead until the freebsd project switches...
yeah, you have to be a crazy fringey bsd to be using git http://gitweb.dragonflybsd.org/?p=dragonfly.git;a=summary
ries_ is now known as ries
[13:01:49] <jepler> http://emergent.unpy.net/files/sandbox/0001-rtai_rtapi-give-more-information-when-tasks-fault.patch
good morning :)
jepler: i've added tests/names to hal.pin
and added python wrappers over hal.item
it's as usual at http://psha.org.ru/cgit/psha/emc2.git/log/?h=pyhal-pin
I bet he's driving to work now, considering how he sent us a URL at 8:01
top-level python module allows to create 'pythonic' wrappers
it's hard to aim with 8hrs offset :)
on the contrary, 'good morning' at 8am is very well-timed
drive's done, but now it's time for important stuff like the first cup of coffee.
ooh tests .. I'm tingling!
jepler: some black magick with __new__ is needed to properly wrap hal.item into high-level objects but this allows to hide C-item deep inside
it also may be achieved by redefining all methods but it will be a bit verbose
cradek: I think that the scrolling exceded soft limit error can be triggered by manually moving the machine past it.
at that point - nothing stops the scrolling.
that I know of anyway.
an manually - I mean take ahold of the ball screw and turn it past the soft limits.
* psha tries to count skunkworks's
I like to be counted
I see one with tail!
wanna one too!
psha is now known as psha_
psha_: should this be "const char *"? + char * name;
it seems like the first two commits should probably be squashed .. or at least the part of the second commit that renames pin to item could be squashed to the first
I see you added a try/except/finally construct in the halmodule test. I double-checked and that's in Python 2.5 (2006) so it should be OK for all our platforms
jepler: ok, i'll glue them
i've added except so when test fail traceback is not lost
psha_ is now known as psha
as of const char - you meen pyhalitem struct?
I'm surprised that's necessary. After the finally block executes, it should print the exception like normal
const char creates warning when trying to free it
ok, forget it then
exception is printed into stderr
and you want it in stdout?
when running tests, stderr is captured into the "stderr" file
why? so test suite will show where and what happened
with stderr you get something separate loosely bound to stdout
to be honest i've missed that i've commited traceback part
I don't mind one way or the other
the reason that stderr goes to a separate file is that I wanted to be able to add debugging prints that went to stderr without breaking all tests
if you think it's a good benefit, maybe split it out to a separate commit
i'm not against stderr :) i only was surprised with silently exiting test
unlike a debugging print, if an exception happens in that code it will make the test fail anyway
and so I can see the benefit of putting a traceback in result instead of stderr
maybe somethink like raise in the end of except clause will satisfy all
so we'll get traceback into stdout and standard exception handler dump into stderr
set f 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 fail
* jepler has to read the source to find out what the significance of the number is
1 << 1024
ah, the first n for which float(1<<n) fails
I'd put hal.py directly in lib/python, not in src/
I know we're not entirely consistent about this, but I think the prevaling habit is to put .py files directly in lib/
cradek: welcome back!
[14:34:05] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=pyhal-test
split patch for except clause
yes, good explanation too
[14:44:57] <psha> http://psha.org.ru/cgit/psha/emc2.git/log/?h=pyhal-pin2
first two patches glued, moved hal.py
something broken in tests
I noticed recently that jogwheel and feed override interact badly again - I'm sure we fixed it once
lately it seems like we fix the same things over and over.
cgit has too agressive caching...
i've left 'pass' after module declaration
anybody want to take a look at my patch from earlier this morning before I push it? http://emergent.unpy.net/files/sandbox/0001-rtai_rtapi-give-more-information-when-tasks-fault.patch
it's too bad I couldn't figure out a better way to get from eip to source code line, but it does work
cradek: did you catch what I wrote above. I was going to test here and see if I can make it do it in sim.
skunkworks_: yes it also does it in sim
halcmd: unlinkp axis.0.motor-pos-fb
halcmd: setp axis.0.motor-pos-fb -1000
joint 0 following error
emc/task/taskintf.cc 611: Error on axis 0, command number 126
Exceeded soft limit
I get it only once, though
I get "Exceeded negative soft limit on joint 0" instead, and I get many of them
this is v2.4_branch
ok, master here.
I haven't yet found any reason for it to be worse than before.
I am running master on the k&t
yes, it spews for me on master but not v2.4_branch
oh ... those errors are new
unrelated to the log message
ok I see what you were trying to do here...
EMC: 03cradek 07master * r3adcbcb5dc9b 10/src/emc/motion/control.c: print this message only once per soft-limit violation
* skunkworks_ cheers from the cheap seats
skunkworks_: if you paid for that seat, you got ripped off
psha: which branch should I be looking at now?
i've cherry picked patches there
it has pyhal-test branch merged
cgit is not that fast since i have only 0.5Gb of memory there :) hope there will be 2gb in couple of days
caches are too small now...
* skunkworks cheers from the free seats!
* Jymmm hands skunkworks tissues for the nose bleed.
hm -- there's a problem for upgrading users (like me): if hal.so is not removed (manually) it's apparently used in preference to hal.py, which leads to an error in the test
I'll fix up the pythonclean rule so that at least 'make clean' will solve it.
EMC: 03jepler 07master * raac2e7965813 10/tests/halmodule.0/test.sh: tests: Added except clause in try block for halmodule
EMC: 03jepler 07master * rb9a6a90eda77 10/src/hal/halmodule.cc: pyhal: Added hal.item object
EMC: 03jepler 07master * ra7c08f633c20 10/tests/halmodule.0/ (expected test.sh): pyhal: Added tests for item object
EMC: 03jepler 07master * r81f8f84b1ec1 10/ (lib/python/hal.py src/hal/Submakefile src/hal/halmodule.cc): pyhal: Add python module over C-module
EMC: 03jepler 07master * r34074e07fadd 10/ (docs/rtfaults.txt src/rtapi/rtai_rtapi.c): rtai_rtapi: give more information when tasks fault
EMC: 03jepler 07master * r8a9a9d9af095 10/src/Makefile: build: clean target should remove python .so mods
EMC: 03jepler 07master * r53a8cb2d9d02 10/ (5 files in 3 dirs): Merge remote branch 'psha/pyhal-pin2'
jepler: great, i'll move gladevcp on top of this now
cradek: some time ago cmorley sent mail to the list about gladevcp in touchy
at that point he suggested to modify basic glade files
as i understand with GtkBuilder it's possible to build interface from several files
so maybe same goal may be achieved with additional user-defined ui files with some predefined locations across interface
a bit like xembed but less hacky
during gladevcp rewrite i've added full support for gtkbuilder so it's possible now
is it possible to find when issued jog command is done?
I don't think so.
maybe create local instance of emc.command() and wait_complete() on it?
or many emc.commands() are bad design?
having multiple emc.commands causes problems, because of the design of wait_received/wait_complete
but without anything else sending commands, and as long as the jog is not so long it hits the wait_complete timeout, it seems to work..
>>> c.jog(emc.JOG_INCREMENT, 0, .5, 1); t0 = time.time(); c.wait_complete(); t1 = time.time()
wait_complete on timeout returns -1, subsequent calls returns 1 when it's done
even if it's aborted
so besides any interference with other emc.command()'s everything seems correct
jepler: what is wrong with wait_received/wait_complete?
each emc.command() holds it's own RCS_STAT_CHANNEL
and waits on it
no global vars
jepler: what was final descision about halui-rewrite? it's abandoned?
psha: umm I guess I'd forgotten about it
the problem with wait_received/wait_complete is that while you can have multiple stat buffers, they're really all views onto the same shared memory
so if task receives your command, then another command, and you look for whether your command is received, you see the number of the other command
can you remind me where the halui refactor stands?
was the question whether to use the version that had the templates?
there was brief discussion about usefullness of templates with macros
as macros are already solution
the one advantage that the templates had was that the type in the second structure could have the volatile qualifier remove
I found several "used without being initialized"-type problems when I did that..
of course, testing should turn those up as well
do you have the version which didn't use templates but used the macros to declare both structures and write the "update" function or whatever it was called?
i'm a bit indifferent about templates - they are translated on compile time and don't harm
but it has volatiile
[20:33:18] <psha> http://psha.org.ru/cgit/psha/emc2.git/tree/src/emc/usr_intf/halui.cc?h=halui-jepler3
it's file without templates
[20:33:43] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=halui-jepler3
volatile may be removed with ##ing prefix to hal_bit_t
but this is a bit dirty...
I'd be happier doing it with templates
so let it be templates
I'm going to steal one part from your commit on top of mine -- put the copy right in the macro and get rid of copy_items
whole day of ja3 testing
how did it go?
but about 6 bugs in emctask / emcmot
machine have 45000mm/min with ferror < 0.5 mm
wow - 1771 inches per minute?
or in terms you might be more familiar with, 3.7 earthradius/year
and I've hit machine with gantry axis with 26000mm/min, it was very noise :|
skunkworks: yes it is fast grab and drop machine
there will be videos
skunkworks: and how is it your machine
coming along. getting the b axis straitened out.
might make some chips this weekend.
how big a machine is this?
"numbers should not be confused with centered hexagonal numbers, which model the standard packaging of Vienna sausages"
er, "hexagonal numbers should not be confused ..."
XYZU but will be XYZUW soon
you mean it's programmed XYZU or are you saying that X has two motors?
Y has two motors
rest is 1:1
if you think any of the emctask/emcmot bugs will affect emc2.4 users and are important, please file them on sourceforge.
btw I will probably do an emc2.4 release nov 20/21, presumably the fest will find and fix some bugs.
sure, I've just collected them today, I'll check them tomorrow/day after tomorrow
it should be mentioned to seb to fix bad state after wrong pin file path in hostmot2
hmmm .. I had a fix for that -- where did I put it?
09:09:26 <jepler> micges: let me know if this patch fixes the problem ..
[21:24:55] <jepler> http://emergent.unpy.net/files/sandbox/0001-hm2_pci-fix-unload-after-failed-registration.patch
I dunno if you saw that at the time ^^
it was days ago now, I think
I've missed it
EMC: 03jepler 07master * r34922c1161d3 10/src/emc/usr_intf/halui.cc: halui: quiet warnings
EMC: 03jepler 07master * r449daf1eb687 10/src/emc/usr_intf/halui.cc: halui: reduce duplicated structure definitions
EMC: 03jepler 07master * r7908caf54d71 10/src/emc/usr_intf/halui.cc: halui: cope better when multiple inputs are active
ries_ is now known as ries