BigJohnT is now known as jthornton
roberth_ is now known as robh__
it would be interesting to be able to specify arcs in terms of center, radius, and start and end angle
kinda, but gcode works with endpoints
perhaps you want endpoint/tangent direction, endpoint/tangent direction, radius
I was trying to think about how to do the "entry" move
or G2.1 XYR<
that's still not the problem at hand - he doesn't know the tangent directions without calculation
moves in a straight line to the point on circle centered at XY, radius R, angle <
(it's trivial but still...)
sure - I'm not trying to solve his problem :)
but it did make me think of this
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
yay, another genius. let's see if jmkasunich can handle the second one with as much class.
I almost copied his email in response, but I managed to hold off
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"
amazingly they spelled it right - for a while everyone seemed to say "unscribe"
drool drool drool
slurp drool drool
I thought sf (mailman) used to auto-detect administrivia and block it
the email had "Please " before unsubscribe, so it shouldn't have been treated as a command (if that's what you're thinking of)
well I don't know what metric it uses to try to detect...
I wouldn't want it to scan the whole email or anything
imagine responding to someone and saying "to unsubscribe ...", and getting unsubscribed youerself
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.
chris, I've bisected NURBS breakage, it appears that your patch c2bc8cf37a7d3a04f73ac6e17581d22dd7e2023c broke it... Do you have any idea how/why?
aystarik: which kind of breakage are you testing?
batterfly.ngc stops at very beginning
I'm asking because iirc, it went from somewhat broken to totally broken - I wonder which one you're talking about
ok the totally broken one :-)
is it issuing moves with line_number zero?
don't know, I've just found that reverting the patch above makes batterfly run to the end...
I think you should be able to tell by turning on "task issue" debug
how I do that?
machine / set debug level / task issue
Outgoing motion id is 0.
yeah I think that is the problem
sorry it is "motion time" that you should turn on
any with id=0 are incorrect
*** buffer overflow detected ***: milltask terminated
the canon call NURBS_FEED() does not take a line number - it should
maybe that is the right fix
may I ?
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
please do, by all means
then maybe we can get back to figuring out what made it "somewhat broken"
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.
4pm, I'm off, bbl
EMC: 03cradek 07master * rb0d9d5ffd856 10/ (6 files in 5 dirs): Merge branch 'v2.4_branch'
EMC: 03cradek 07master * rcb0d7c80f22c 10/docs/src/common/User_Concepts.lyx: fix thinking in inches error
EMC: 03cradek 07master * re628caee9761 10/src/emc/ (5 files in 4 dirs): This makes G5.2/G5.3 work (somehow) again.
aystarik: perfect clean patch, and it works, thank you. did you find what caused that buffer overflow trap?
I think these are too long debug lines.
I turned on 'task issue' debug option and it failed.
interesting - it must tickle something in your system but not any of mine
can you get it to segfault there instead of abort, so you can get it in the debugger?
I think I have done that before, but I don't recall how (on glibc malloc traps)
you had to run batterfly :) just triggered it again.
ok, lemme try
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,)
*** buffer overflow detected ***: milltask terminated
still building here...
nope, I don't get it
use vsnprintf in rcs_print, helps :)
see the patch
line is longer than 256 allocated for buffer.
that is not an adequate fix because you'll end up with an unterminated string, trading one bug for another
enlarge the buffer, use vsnprintf, check the return value correctly and handle it if it still overflows your new larger buffer
(where handle might mean truncate and terminate, not sure)
pretty sure the == EOF test is just wrong
I think the right error check is retval<0 || retval>=bufsize
vsnprintf will make \0-terminated string
so, we get trancated string automatically.
pretty sure that is not true - what reference are you using?
The functions snprintf() and vsnprintf() write at most size bytes (including the trailing null byte ('\0')) to str.
man page for vsnprintf
yes mine also says that - you are misinterpreting what it says - I'm looking for a better reference
hmmmm maybe I am wrong...?
this manpage is clear as mud
I couldn't find a reference so I tried a test program - and you are right
strncpy() leaves the string unterminated when truncated
some people say windows version of v/snprintf() leaves the string unterminated when truncated