Back
[14:33:24] <jepler> cradek: can you cast your critical eye at
http://emergent.unpythonic.net/files/sandbox/pre-receive when you have a chance?
[14:38:16] <cradek> does the printed test work?
[14:38:28] <jepler> seems to
[14:39:13] <jepler> $ x=1; f () { x=2; }; f; echo $x
[14:39:13] <jepler> 2
[14:39:30] <jepler> $ x=1; f () { local x=0; }; f; echo $x
[14:39:31] <jepler> 1
[14:39:37] <jepler> and local works too; I'm not sure I knew about local
[14:39:46] <jepler> tested on the oldest freebsd machine I could find, with /bin/sh
[14:39:49] <cradek> sh will never stop surprising me
[14:40:29] <cradek> $ x=1; f () { x=2; }; true|f; echo $x
[14:40:29] <cradek> 1
[14:40:56] <jepler> yeah, that's why I have to do a for `git` instead of a git | while read
[14:41:12] <jepler> in check ()
[14:42:06] <jepler> this is my "test":
http://paste.ubuntu.com/8405445/
[14:42:11] <cradek> it looks good to me
[14:42:41] <cradek> as long as the rev-list will fit on the command line, and it oughta
[14:43:20] <cradek> why didn't it complain about 53d0?
[14:43:25] <cradek> oh, the date
[14:43:47] <cradek> did you try pusing several branches at the same time?
[14:44:03] <cradek> or pushing
[14:44:15] <jepler> no
[14:44:51] <jepler> as for the commandline length of the 'for `git`' line, this succeeds in executing in both /bin/sh I tested: for i in `yes aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | head -999999`; do :; done
[14:45:15] <jepler> if it didn't, it would be due to a limit internal to sh, not the exec argv size limit
[14:46:35] <jepler> remote: fatal: Invalid revision range 0000000000000000000000000000000000000000..9bc7121131976abaeb230af80f16b50032d931d1
[14:46:53] <jepler> pushing a new branch makes for an error, so thanks for telling me to try pushing other branches
[14:51:41] <jepler> http://emergent.unpythonic.net/files/sandbox/pre-receive-v2
[14:52:03] <jepler> OK, now pushing a new branch doesn't fail; instead, every commit from master to the tip of the new branch is checked
[14:52:15] <cradek> that sounds right
[14:52:48] <jepler> the whole push is declined if any commit in any pushed branch is in violation of the sob polic
[14:52:51] <jepler> y
[14:52:58] <cradek> good
[14:53:00] <jepler> remote: [on branch refs/heads/master]
[14:53:01] <jepler> remote: 282abc0 foo
[14:53:01] <jepler> remote: 1436d89 foo
[14:53:01] <jepler> remote: [on branch refs/heads/what]
[14:53:01] <jepler> remote: 81e90de bar
[14:53:05] <jepler> and you're told what commit is on what branch
[14:53:12] <jepler> commits on multiple branches would be listed once for each branch
[14:53:27] <jepler> (for instance, if you made a non-sob commit on 2.6, merged it to master, and pushed both in one go)
[18:04:45] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve3 f54c340 06linuxcnc 10(15 files in 5 dirs) First part of limited jerk support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f54c340
[18:04:45] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve3 86eb5fa 06linuxcnc 10src/emc/kinematics/tc.h 10src/emc/kinematics/tp.c Limited jerk support: implement the S-Curve Acceleration with FSM in trajectory planner * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=86eb5fa
[18:04:45] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve3 f74b182 06linuxcnc 10src/emc/task/emccanon.cc canon: calculate jerk for each move using per axis max values from inifile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f74b182
[18:04:49] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve3 827187b 06linuxcnc 10configs/sim/axis/axis_mm.ini config: add jerk parameter to sim/axis_mm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=827187b
[18:04:53] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve3 4ff91a3 06linuxcnc 10src/emc/task/emccanon.cc canon: fix calculating jerk for arc moves * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4ff91a3
[18:05:26] <skunkworks_> logger[psha]:
[18:05:26] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-09-22.html
[18:06:05] <skunkworks_> micges: how is that going?
[18:06:48] <micges> finally back to testing
[18:08:01] <skunkworks_> neat!
[18:08:28] <micges> it's working, there is a spike on acc to locate and remove and to add scurve to jog motion
[18:09:24] <micges> and add and enable blending to tp, it's totally disabled atm, G64 Pn doesn't work
[18:09:38] <skunkworks_> heh - I was just going to ask that.
[18:10:26] <micges> (code is out there, just locate and extract it from 100k lines diff file ;))
[18:10:44] <skunkworks_> 2 segment blending?
[18:10:53] <skunkworks_> (like the original tp?)
[18:10:59] <micges> skunkworks_: pretty good results even on badly tuned servos
[18:11:17] <skunkworks_> cool
[18:11:47] <micges> I think so
[18:12:48] <skunkworks_> I am sure that would help a lot of people.. it would be cool to have 3 planners (orignal parabolic blending, robs and scurve.)
[18:13:53] <micges> I needed to base changes on to of 2.6 branch becouse new tp is too complicated to develop this code, Rob offered help to try port changes when scurve will be complete
[18:14:36] <micges> yes indeed, switchable planners without recompiling would be even better ;)
[18:20:16] <micges> skunkworks_: my old employer built about 10 pick'n'place machines with max speed 96m/min and acc 3500mm/s2, for 24/7 work
[18:21:31] <micges> skunkworks_: they heavly damage one of their mechanic system every 2-3 month due to lack of scurve
[20:57:40] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master d7b876f 06linuxcnc 03docs/man/man3/rtapi_byteorder.3rtapi rtapi_byteorder: add byte reordering macros, document * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d7b876f
[20:59:03] <jepler> just in case anyone ever ports hostomt2 to ppc, mipseb or armeb this'll come in handy
[21:01:45] <jepler> (probably easier to rebuild hostmot2 firmwares for them)
[21:10:34] <ju_emb> I have a strange behaviour on the following Inkscape gcodetools created G-code
[21:11:03] <ju_emb> the g-code
[21:11:06] <ju_emb> http://pastebin.com/wFYYUJRa
[21:12:14] <ju_emb> not sure if it is on start or end of arcs
[21:12:16] <ju_emb> the y axis has a hickup
[21:13:12] <ju_emb> ends up that I get a 3mm offset in Y
[21:13:55] <ju_emb> I use 2.6.3 from tghe last install ISO
[21:14:32] <ju_emb> actually is a -3mm offset
[21:16:25] <ju_emb> I have tested my stepper drivers and machine with
[21:16:27] <ju_emb> g-code running several axis together results in positioning is OK
[21:17:02] <ju_emb> Anyone has a hint what I can test to find where the hick-up comes from
[21:34:48] <jepler> well that doesn't usually happen.
[21:35:00] <jepler> I was getting a weird tcl traceback, and when I added debugging prints to diagnose it, I ended up with a segfault
[21:35:14] <jepler> in master branch, anybody else seeing axis print a warning on the terminal after pressing F1 F2 ?
[21:38:01] <ju_emb> Jeff: is that for me or a response of something else before I connected ?
[21:38:21] <jepler> ju_emb: for your problem, no idea
[21:38:26] <jepler> I'm just talking to myself
[21:39:06] <jepler> I'm a worse troubleshooter of hardware problems than software problems, so you probably wouldn't benefit from my help
[21:40:04] <ju_emb> looks like Monday 9:20 EST is TV time
[21:45:08] <jepler> tcl/tk packages updated on 9/16 on this machine
[21:45:23] <jepler> problem doesn't happen on the other machine I have handy, but it's not debian jessie
[21:46:21] <jepler> problem happens on the jessie machine in 2.6 and master, so it's not likely to be new because of a change in linuxcnc
[22:06:54] <cradek> master is w-ing fm
[22:08:18] <jepler> cradek: thanks
[22:08:33] <cradek> Linux magneto 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u1 i686 GNU/Linux
[22:08:43] <jepler> whether our fault or not, it sure looks like it's exposed by some package in jessie (or maybe by 64 bits but I run 64 bits all the time)
[22:40:20] <skunkworks_> no warnings in 14.04 posix non-realtime
[22:42:30] <NTU> what is jessie?
[22:42:54] <NTU> the next wheezy?
[22:44:37] <jepler> NTU: jessie is the codename for debian 8.0. It's in the testing / stabilization phase of its development cycle.
[22:51:28] <NTU> oh ok