Back
[00:26:01] <BigJohnT> BigJohnT is now known as jthornton
[08:59:01] <roberth_> roberth_ is now known as robh__
[16:48:52] <SWPadnos> it would be interesting to be able to specify arcs in terms of center, radius, and start and end angle
[16:50:26] <cradek> kinda, but gcode works with endpoints
[16:50:32] <SWPadnos> yeah
[16:50:48] <cradek> perhaps you want endpoint/tangent direction, endpoint/tangent direction, radius
[16:50:51] <SWPadnos> I was trying to think about how to do the "entry" move
[16:50:58] <SWPadnos> maybe
[16:51:23] <SWPadnos> or G2.1 XYR<
[16:51:23] <cradek> that's still not the problem at hand - he doesn't know the tangent directions without calculation
[16:51:42] <SWPadnos> moves in a straight line to the point on circle centered at XY, radius R, angle <
[16:51:49] <cradek> (it's trivial but still...)
[16:51:57] <SWPadnos> sure - I'm not trying to solve his problem :)
[16:52:02] <SWPadnos> but it did make me think of this
[16:52:34] <cradek> heh
[16:52:58] <SWPadnos> actually, it would just become another way of specifying a point, like XY vs. R< - if you specify all of them, you're specifying a point on a circle
[17:47:11] <cradek> yay, another genius. let's see if jmkasunich can handle the second one with as much class.
[17:48:32] <SWPadnos> heh
[17:48:51] <SWPadnos> I almost copied his email in response, but I managed to hold off
[17:49:59] <cradek> both of them top-posted, with the entire quoted digest underneath. this means the unsubscribe instructions were probably showing ON THEIR SCREEN when they droolingly typed "unsubscribe"
[17:50:20] <cradek> amazingly they spelled it right - for a while everyone seemed to say "unscribe"
[17:50:37] <SWPadnos> or unsibscribe
[17:50:47] <cradek> drool drool drool
[17:50:58] <SWPadnos> slurp drool drool
[18:12:36] <cradek> I thought sf (mailman) used to auto-detect administrivia and block it
[18:34:18] <SWPadnos> which administrivia?
[18:34:54] <SWPadnos> the email had "Please " before unsubscribe, so it shouldn't have been treated as a command (if that's what you're thinking of)
[18:59:30] <cradek> well I don't know what metric it uses to try to detect...
[19:02:24] <SWPadnos> I wouldn't want it to scan the whole email or anything
[19:02:57] <SWPadnos> imagine responding to someone and saying "to unsubscribe ...", and getting unsubscribed youerself
[19:36:08] <cradek> but it would make me happy if messages resulting from quoting an entire digest and then adding fewer than ten words, two of which are "unsubscribe" and "BlackBerry", would not be allowed through. Just rejecting it with a pointer to the prefs url would be fine.
[19:36:28] <SWPadnos> heh
[20:15:55] <aystarik> chris, I've bisected NURBS breakage, it appears that your patch c2bc8cf37a7d3a04f73ac6e17581d22dd7e2023c broke it... Do you have any idea how/why?
[20:37:02] <cradek> aystarik: which kind of breakage are you testing?
[20:37:30] <aystarik> batterfly.ngc stops at very beginning
[20:37:33] <cradek> I'm asking because iirc, it went from somewhat broken to totally broken - I wonder which one you're talking about
[20:37:52] <aystarik> "totally broken"
[20:37:55] <cradek> ok the totally broken one :-)
[20:38:21] <cradek> is it issuing moves with line_number zero?
[20:39:25] <aystarik> don't know, I've just found that reverting the patch above makes batterfly run to the end...
[20:39:57] <cradek> I think you should be able to tell by turning on "task issue" debug
[20:40:25] <aystarik> how I do that?
[20:40:53] <cradek> machine / set debug level / task issue
[20:42:05] <cradek> Outgoing motion id is 0.
[20:42:14] <cradek> yeah I think that is the problem
[20:43:09] <cradek> sorry it is "motion time" that you should turn on
[20:43:21] <cradek> any with id=0 are incorrect
[20:43:22] <aystarik> *** buffer overflow detected ***: milltask terminated
[20:44:04] <cradek> ouch
[20:44:13] <aystarik> rcs_print
[20:46:55] <cradek> the canon call NURBS_FEED() does not take a line number - it should
[20:47:07] <cradek> maybe that is the right fix
[20:48:38] <aystarik> may I ?
[20:48:39] <cradek> pretty sure arc() (called deep within NURBS_FEED) should not use interp_list.get_line_number() - the line number should be passed through from the interpreter
[20:48:49] <cradek> please do, by all means
[20:49:45] <cradek> then maybe we can get back to figuring out what made it "somewhat broken"
[20:56:17] <cradek> too bad that although in this implementation nurbs degenerate into arcs, the arcs are at the wrong level for cutter comp to work. or maybe cutter comp is at the wrong level, depending how you look at it.
[20:57:13] <cradek> 4pm, I'm off, bbl
[21:42:56] <CIA-2> EMC: 03cradek 07master * rb0d9d5ffd856 10/ (6 files in 5 dirs): Merge branch 'v2.4_branch'
[21:42:56] <CIA-2> EMC: 03cradek 07master * rcb0d7c80f22c 10/docs/src/common/User_Concepts.lyx: fix thinking in inches error
[21:43:03] <CIA-2> EMC: 03cradek 07master * re628caee9761 10/src/emc/ (5 files in 4 dirs): This makes G5.2/G5.3 work (somehow) again.
[21:43:50] <cradek> aystarik: perfect clean patch, and it works, thank you. did you find what caused that buffer overflow trap?
[21:44:26] <aystarik> I think these are too long debug lines.
[21:46:06] <aystarik> I turned on 'task issue' debug option and it failed.
[21:46:36] <cradek> interesting - it must tickle something in your system but not any of mine
[21:47:00] <cradek> can you get it to segfault there instead of abort, so you can get it in the debugger?
[21:47:43] <cradek> I think I have done that before, but I don't recall how (on glibc malloc traps)
[21:50:37] <aystarik> you had to run batterfly :) just triggered it again.
[21:50:48] <aystarik> axis_mm, batterfly.
[21:50:53] <cradek> ok, lemme try
[21:51:04] <cradek> master?
[21:51:51] <aystarik> yes
[21:52:44] <aystarik> Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+116, +0,-27.623750,-29.864167,18.273633,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000, +2,1.666667,30.480000,508.000000, +0,)
[21:52:45] <aystarik> *** buffer overflow detected ***: milltask terminated
[21:53:15] <cradek> still building here...
[21:55:17] <cradek> nope, I don't get it
[22:07:30] <aystarik> use vsnprintf in rcs_print, helps :)
[22:07:35] <aystarik> see the patch
[22:08:04] <aystarik> line is longer than 256 allocated for buffer.
[22:11:51] <cradek> that is not an adequate fix because you'll end up with an unterminated string, trading one bug for another
[22:12:39] <cradek> enlarge the buffer, use vsnprintf, check the return value correctly and handle it if it still overflows your new larger buffer
[22:12:58] <cradek> (where handle might mean truncate and terminate, not sure)
[22:13:08] <cradek> pretty sure the == EOF test is just wrong
[22:15:23] <cradek> I think the right error check is retval<0 || retval>=bufsize
[22:18:22] <aystarik> vsnprintf will make \0-terminated string
[22:18:47] <aystarik> so, we get trancated string automatically.
[22:19:17] <cradek> pretty sure that is not true - what reference are you using?
[22:20:20] <aystarik> The functions snprintf() and vsnprintf() write at most size bytes (including the trailing null byte ('\0')) to str.
[22:20:31] <aystarik> man page for vsnprintf
[22:20:50] <cradek> yes mine also says that - you are misinterpreting what it says - I'm looking for a better reference
[22:21:51] <cradek> hmmmm maybe I am wrong...?
[22:23:01] <cradek> this manpage is clear as mud
[22:30:58] <cradek> I couldn't find a reference so I tried a test program - and you are right
[22:32:13] <cradek> strncpy() leaves the string unterminated when truncated
[22:32:43] <cradek> some people say windows version of v/snprintf() leaves the string unterminated when truncated
[22:33:29] <cradek> hungry, bbl