Back
[04:02:37] <jepler> dgarr1: what does EXISTS[#1+1] do?
[04:07:00] <dgarr1> 2
[04:18:18] <dgarr1> maybe this revision is better:
http://www.panix.com/~dgarrett/stuff/0001-interp-add-EXISTS-unary-function.patch
[04:18:36] <dgarr1> would return 1 for exists[#1 + 1]
[04:27:29] <CIA-41> EMC: 03cradek 07master * r24f459a60c87 10/src/emc/rs274ngc/interp_queue.cc: Fix spurious cutter comp error with tiny arcs in metric
[04:27:39] <CIA-41> EMC: 03cradek 07master * racc3e9080ffa 10/docs/src/index.tmpl: fix top-level ULs being too far to the left
[04:27:40] <CIA-41> EMC: 03cradek 07master * re164771d403f 10/ (docs/src/index.tmpl src/emc/rs274ngc/interp_queue.cc): Merge branch 'v2.4_branch'
[04:28:30] <dgarr1> jepler: maybe EXISTs should only apply to named_parameters? what do you suggest?
[04:49:50] <cradek> dgarr1: I bet he's asleep now.
[04:50:21] <cradek> (I get a 404 on your rev 2 url)
[05:02:53] <dgarr1> oops -- it should be there now
[05:06:22] <dgarr1> maybe it would help to call it NAMED_PARAMETER_EXISTS, but that seems kind of verbose
[07:49:24] <dgarr1>
[14:06:17] <jepler> yes, I was gone for the night by then
[14:08:08] <jepler> since I'm not sure of the use cases for EXISTS I'm not sure what it should accept or reject. It seems clear to me that it should reject EXISTS[#1+1] as malformed gcode. On the other hand, it's just a bit plausible that EXISTS[#[#1+1]] should work.
[14:16:17] <jepler> .. and maybe you can achieve that if you structure the code like this?
http://pastebin.ca/raw/2010454
[14:20:22] <jepler> > bzr: ERROR: These branches have diverged. Use the missing command to see how.
[14:29:15] <jepler> (apparently with bzr it's an advanced activity to merge two branches when you don't have immediate network access.
http://feedproxy.google.com/~r/glyph/~3/5zRwKkdKjsA/resolving-diverged-bazaar-branches-on.html )
[14:29:53] <jepler> er, prefer this link if you don't want google to track you:
http://glyph.twistedmatrix.com/2010/12/resolving-diverged-bazaar-branches-on.html
[14:55:50] <jepler> cradek: did you mean that cutter comp fix to go in the v2.4_branch? I think you didn't get what you intended with that push..
[15:04:39] <cradek> yes - I checked it pretty carefully - what's wrong?
[15:05:17] <cradek> it looks right to me
[15:09:10] <SWPadnos> would {TO,FROM}_{PROG_EXT}_LEN work there?
[15:11:02] <cradek> not sure
[15:12:12] <cradek> I don't really like the code or the "fix"; my goal was to be 100% safe in 2.4
[15:12:37] <SWPadnos> yeah
[15:13:42] <cradek> and of course it will still fail if you make the arcs even smaller
[15:14:06] <cradek> in his problem program they were 0.6mm radius arcs
[15:17:11] <SWPadnos> a percentage error (with an upper limit) seems like it might be better
[15:19:44] <cradek> yes, or find the actual problem that causes the loss of precision
[15:20:09] <SWPadnos> heh, well there is that :)
[15:20:45] <cradek> which of those could I get right in one try? probably neither.
[15:21:05] <SWPadnos> hmmm
[15:22:25] <cradek> this is in the handling of the last compensated corner before turning off compensation - it's possible the algorithm is just wrong - stopping and starting are both 'hard parts'
[15:25:32] <cradek> bbl
[16:20:38] <jepler> cradek: maybe cia tricked me. it reported the commit as being on the master branch..
[16:22:52] <jepler> dgarr: do all named parameters become undefined after m2 or at other well-defined times?
[16:23:07] <jepler> cradek: looking at it in gitk I see things are in the right places
[16:28:54] <dgarr> jepler: my understanding is that global named parameters #<_gname> persist from the time of creation, other named parameters are local to their level, so i think that means local named parameters would be undefined after m2 (global named parameters remain defined)
[16:36:41] <jepler> dgarr: so if in one run I #<_dothis> = 1 / O<something> call, and in the next run I want to not dothis, I have to make #<_dothis> undefined. but there isn't a way to do so.
[16:36:44] <jepler> or is there?
[16:37:03] <jepler> .. within the same session, that is
[16:46:49] <dgarr> i guess there is no way to undefine #<_dothis> but the proper test within the subroutine would probably be something like: if exsits[#<_dothis> followed by a test on the value of #<_dothis> -- so changing the value would have the required effect.
[16:50:28] <dgarr> i guess this follows a common tcl idiom: if [info exists varname] && ("$varname" == ...)] ...
[16:51:41] <jepler> .. while I usually approach things from the Python or C++ direction where definedness checks are rare or downright nonsensical..
[16:52:00] <jepler> the current version of the patch is still at this url?
http://www.panix.com/~dgarrett/stuff/0001-interp-add-EXISTS-unary-function.patch
[16:52:25] <dgarr> yes
[16:53:02] <jepler> is this bit just an accidental whitespace change? @@ -2015,8 +2028,8 @@ int Interp::read_named_parameter(
[16:53:28] <jepler> I'll fix that and one typo I spotted and push it to master
[16:53:43] <dgarr> yes accidental, maybe tab damage
[16:56:40] <dgarr> I trust you are convinced of its usefulness:-/
[16:57:06] <CIA-41> EMC: 03jepler 07master * r0b8514fe9b44 10/src/emc/rs274ngc/ (interp_execute.cc interp_internal.hh interp_read.cc): interp: add EXISTS unary function
[17:02:38] <dgarr> thanks!
[17:04:15] <jepler> you're welcome
[20:14:36] <SteveStallings> SteveStallings is now known as steves_logging