Back
[13:28:43] <bpuk> ok. I'm giving up on putting an o profile after the g71 call. it's not behaving.
[13:29:00] <bpuk> where should an osub be placed in a seperate file?
[13:38:24] <bpuk> nvm, found it. that won't work either
[13:49:40] <andypugh> I don’t doubt that you are correct, but I am curious why.
[13:50:56] <andypugh> An O-sub in a standalone file seems easier, in some ways, as you just need to send the file to the sai and see what comes back (for complicated values of “just”)
[13:51:43] <andypugh> (The statement above describes my assumptions, and should not be confused for a statement of fact)
[13:51:59] <bpuk> apologies - that wont work trivially - P really doesn't want to take a procedure name
[13:52:32] <andypugh> Ah, yes, that won’t work
[13:52:40] <bpuk> and there seems to be a big difference between o<test> call and o123 call.
[13:52:58] <andypugh> But if the file-name is a number containing a numbered subroutine I think it can work
[13:53:21] <bpuk> I'm making notes at the moment. I've got the profile stuff reading from a profile before the g71 call (which I don't think is ideal)
[13:53:34] <andypugh> One of the examples here is a numbered file:
http://linuxcnc.org/docs/html/gcode/o-code.html#ocode:calling-files
[13:53:55] <bpuk> getting it to work as I think it should is likely to take some non-trivial changes to the o-word logic, which implies a refactor
[13:54:28] <bpuk> ooh. that might work then
[13:54:48] <andypugh> “Subroutine bodies may not be nested. They may only be called after they are defined. “
[13:55:28] <cradek> I think currently we can have Osub after the Ocall
[13:55:48] <cradek> ie if it hasn't already seen the sub, it searches forward
[13:55:59] <andypugh> To be honest I don’t see any problem at all in requiring the block that defines the shape to appear above the call. It’s the same in Python and C. (but in BASIC you traditionally put subs at the end)
[13:56:15] <bpuk> cradek: If you've got a sim environment set up, please try it
[13:56:26] <bpuk> the unit tests and docs indicate it shouldn't work
[13:56:32] <cradek> you could sure move on, and deal with this later...
[13:56:42] <cradek> oh really? hm, lemme try
[13:56:51] <bpuk> pffft - I've almost talked myself into rewriting about half the interpreter
[13:57:29] <bpuk> (I'm sorta kidding, but I want to get the G71 stuff done before I go crazy on anything else)
[13:57:52] <cradek> you're right
[13:58:01] <cradek> I get an error that makes no sense if I put the sub after the call
[13:58:21] <bpuk> redefining sub? something like that?
[13:58:25] <cradek> yeah
[13:58:32] <bpuk> yeah - that's the brick wall I hit
[13:58:35] <cradek> building 2.6 to try
[13:59:18] <cradek> same
[13:59:52] <andypugh> It doesn’t make _no_ sense, it is saying that it cant find a file called “100” because it has assumed that the sub is in a separate file.
[14:00:10] <andypugh> I tried 2.8
[14:00:52] <cradek> in 2.5 you get a sensible error "Near line [the call site] of [file]: Unable to open file <1>"
[14:01:11] <cradek> 1 because I did o1 call
[14:01:30] <cradek> so absolutely don't worry that the profile has to be before the g71
[14:01:36] <bpuk> the redefining sub error makes sense from a code perspective - it's just badly worded.
[14:01:38] <cradek> (or in a file)
[14:02:07] <andypugh> That’s exactly what I got in 2.8. What did you get that was nonsensical?
[14:02:35] <cradek> lemme build baster again
[14:02:36] <cradek> master
[14:02:56] <bpuk> File:%s line %d redefining sub: o|%s| already defined in file: %s
[14:04:07] <cradek> [o1 sub site] redefining sub: o|1| already defined in file:[same file]
[14:04:49] <cradek> I think it might search forward to find it like I expected, but then forget to skip over it next time it's encountered? [guessing]
[14:04:57] <andypugh> That actually sounds like it is trying to find the dub and making a bad job of it?
[14:05:00] <jepler> cradek: I wondered if it was something like that
[14:05:14] <cradek> I would've sworn this worked
[14:05:43] <bpuk> nope, when the call is executed, it saves the offset of the call. it then reads forward, finds the definition and checks to see if the offset exists
[14:05:44] <andypugh> I must be using an older 2.8 than you
[14:05:50] <bpuk> when the offset exists, it breaks
[14:06:00] <cradek> 2e52efef6
[14:06:32] <andypugh> e993e7f (though I am not good at turning hashes into dates)
[14:06:40] <cradek> oh the test has the M30 before the Osub
[14:07:07] <cradek> so yeah, it doesn't know to skip over it later
[14:07:40] <bpuk> the problem is that the call offset should be saved, and the definition offset should be saved. just not in the same variable
[14:08:45] <cradek> seems like if it was previously found by searching forward, it should skip over the sub instead of erroring. if it was previously found while NOT skipping forward, it should give the redefinition error
[14:10:21] <cradek> bpuk: but anyway, this is a separate bug, I suggest you don't worry about it - put your profile first, or after m2/m30, and move on
[14:10:51] <bpuk> will do - it's a fairly tricky bug to fix too
[14:11:14] <cradek> :-(
[14:11:18] <cradek> sorry you got distracted
[14:11:30] <bpuk> I'll put a pullrequest up in a few minutes, that should bring the profile side of the code up to date
[14:12:10] <cradek> 2e52efef6 is not the ref I was running - it's the one that fixed? this feature and tests it
[14:12:21] <andypugh> I am messing about with a crank-grinding component for a friend, but intend to write the docs when that is done.
[14:12:26] <cradek> andypugh: you're running an old ja12
[14:12:44] <cradek> from march
[14:13:11] <andypugh> cradek: Doesn’t surprise me. I have a RIP one too, but that has Ben’s G71 in it, which gets in the way of my remappped one :-)
[14:14:13] <andypugh> The crank-grinding think has a fun problem, how to “jump aboard” a nearly-sine-wave
[14:15:00] <cradek> I know: stop it then jump in then start it again
[14:15:11] <bpuk> wait - so it _should_ work? and has had a bugfix? and doesn't work again?
[14:15:11] <andypugh> It’s spindle-synched
[14:15:24] <cradek> bpuk: it works if you put the sub after m2/m30
[14:15:39] <cradek> it = skipping forward to find an o sub after the m2/m30
[14:15:53] <andypugh> It probably wouldn’t even have to be a sub for that to work....
[14:15:55] <bpuk> hmmm... let me finish running tests and I'll retest here - I may have broken it on my local branch again
[14:23:09] <bpuk> ok - that does work with osubs - which is wierd!
[14:26:51] <bpuk> since I couldn't get it to work with oprofile - so tried an osub, and got the error
[14:26:55] <bpuk> *shrug*
[14:51:14] <bpuk> ok, that's pretty close - if I repeat the G71 block, it pulls the profile in the second time. So it must be saving the offset to the end of the block
[14:58:40] <andypugh> I have forgotten why it has to be OProfile and not Osub. (can one CALL an OProfile? I wonder if that is valuable when you can G70 it? )
[14:59:20] <bpuk> OProfile is restricted to G0,1,2,3
[14:59:28] <bpuk> I think that was my reasoning
[14:59:57] <andypugh> Hmm, and I have just remembered:
https://github.com/LinuxCNC/linuxcnc/pull/151
[15:01:26] <andypugh> G72 could choose to error or ignore anything else. Though perhaps they would unavoidably alter machine state?
[15:02:22] <bpuk> never accepted?
[15:02:35] <bpuk> that was my concern - if units/plane changed
[15:04:00] <bpuk> and G70/71/72 don't directly read the g-code, unlike python. they set the appropriate flags, jump to the start of the profile, and it copies the processed blocks into a vector
[15:04:22] <bpuk> G70/71/72 then work on the blocks to do 'stuff'
[15:04:35] <andypugh> I don’t know. I admit to never thinking it is my job to accept pull-requests. And I don’t know if anyone else thinks it is theirs.
[15:06:26] <jepler> I burned out after while
[15:06:29] <andypugh> Which reminds me, I _ought_ to merge your pull request to the branch that I made.
[15:06:32] <cradek> it's sometimes mine
[15:07:23] <andypugh> For the BPG71 branch, should I merge-commit or Rebase and Merge?
[15:07:29] <jepler> andypugh: neither
[15:07:37] <jepler> andypugh: never use the buttons in github to accept a pull request
[15:07:49] <andypugh> Good job I asked
[15:07:50] <jepler> locally merge the pull request, then push to git.linuxcnc.org.
[15:08:09] <jepler> there's a button somewhere in there that will give you only slightly wrong-for-our-workflow instructions on how to do that
[15:09:11] <bpuk> andypugh: that's an old pull request ;) should be a new one Real Soon Now (tm)
[15:09:25] <andypugh> OK. I will wait then
[15:11:11] <andypugh> Alternatively, you could ask for push access to git.linuxcnc. (I am not sure who looks after that)
[15:11:26] <jepler> cradek has to do the technical bits of adding access to glo
[15:11:43] <bpuk> until I've got a few more commits under my belt, I'd prefer the review process
[15:11:47] <cradek> yes that's a thing I can do if you want it, bpuk
[15:11:56] <jepler> the social process for it is fuzzy and about feelings
[15:11:58] <cradek> ok, later then, no problem
[15:12:31] <skunkworks> remember SOB
[15:12:33] <cradek> working on a thing and showing up years later to continue working on it is good enough for me
[15:13:19] <cradek> and bpuk seems to work and play well with others :-)
[15:23:11] <bpuk> usually, if I get wound up I tend to go quiet and do something else for a while ;)
[15:23:19] <bpuk> and _finally_ it works!
[15:23:26] <cradek> ooh!
[15:24:26] <bpuk> works before G71, after G71, after M2/M30
[15:24:30] <bpuk> and brb
[15:24:33] <cradek> yayyy
[16:16:26] <micges> join #emc
[16:24:59] <cradek> bpuk: got your pull request - do you know how to add signed-off-by? I can't update your branch on linuxcnc.org without that
[16:25:47] <cradek> argh, would also be nice if you could fix the ben@localhost.localdomain in the merge
[16:25:54] <bpuk> heh
[16:25:58] <cradek> I'm not sure I'm enough of a gitter to know how to do that
[16:26:38] <cradek> wait, I bet I could just do it here
[16:26:44] <cradek> is it ok if I fix up those two things?
[16:26:52] <bpuk> probably easier for this one
[16:27:07] <bpuk> I'll see if I can fix the ben@localhost.localdomain here
[16:27:18] <bpuk> (is it the updated pull request from 18 minutes ish ago?
[16:27:38] <cradek> yes
[16:29:21] <bpuk> great
[16:29:28] <cradek> I just rebased to get rid of the merge
[16:29:38] <bpuk> ok, I think I've updated my e-mail on my local install
[16:29:53] <bpuk> signed-off-by? is that in the commit message?
[16:29:54] <cradek> weird, there's a hostmot2 absolute encoder change here too
[16:30:02] <cradek> how'd that get there, I wonder
[16:30:36] <bpuk> wierd - I don't think I've rebased or merged from master
[16:30:44] <cradek> bpuk:
http://www.linuxcnc.org/docs/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy
[16:31:32] <cradek> hm yeah, it's in your PR
[16:31:41] <cradek> https://github.com/LinuxCNC/linuxcnc/pull/212/commits
[16:31:43] <cradek> that top one
[16:32:19] <bpuk> hmm...
[16:32:49] <bpuk> looks like they were committed before I cloned
[16:34:39] <bpuk> it looks like I should be able to rebase locally, and resubmit the pull request
[16:35:39] <bpuk> let me withdraw that request and try again ;)
[16:35:59] <cradek> give me a second - I might almost be done with the rebase to master
[16:36:07] <bpuk> oh, ok
[16:37:04] <cradek> yeah, think I got it
[16:37:14] <bpuk> heh, gitfu
[16:37:23] <cradek> a few minor conflicts
[16:37:57] <KGB-linuxcnc> 03andypugh 05BenPotter/G71 00440b7 06linuxcnc 10(10 files in 3 dirs) G71: Ben Potter patch (very) slightly re-worked for 2.8 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=00440b7
[16:37:57] <KGB-linuxcnc> 03Ben Potter 05BenPotter/G71 9554610 06linuxcnc 10(6 files) Update to final patch from 2012 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9554610
[16:37:57] <KGB-linuxcnc> 03Ben Potter 05BenPotter/G71 0786ca6 06linuxcnc 10(10 files) First pass at moving from N-numbers to O-sub for arbitrary profiles. Needs cleanup pass * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0786ca6
[16:37:59] <KGB-linuxcnc> 03Ben Potter 05BenPotter/G71 8fa7298 06linuxcnc 10(7 files in 2 dirs) Moved existing G71 (type1) code from using P/Q to define line numbers to using O Profiles. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8fa7298
[16:38:44] <cradek> buildbot is chewing on it
[16:39:13] <bpuk> buildbot is in addition to travis?
[16:39:16] <linuxcnc-build> build #2800 of 1405.rip-wheezy-armhf is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2800 blamelist: dummy, Tero Kaarlela <tero.kaarlela@eka-sorvaus.fi>, andypugh <andy@bodgesoc.org>, Jeff Epler <jepler@unpythonic.net>, Ben Potter <ben@bpuk.org>, Norbert Schechner
[16:39:16] <linuxcnc-build> <nieson@web.de>
[16:39:16] <cradek> thanks for all your work
[16:39:41] <cradek> yes it's much more complete tests - tests packaging on all our platforms, etc
[16:40:19] <andypugh> Yay! Your first blame Ben.
[16:40:25] <bpuk> you're welcome cradek - theres a lot more to do there, but the o profile stuff seems ok from a few tests
[16:40:28] <bpuk> and yay :P
[16:41:04] <cradek> no idea what's wrong with armhf. ignore.
[16:41:35] <cradek> 10.0.0.3[0: 10.0.0.3]: errno=No route to host
[16:41:37] <cradek> yeah whatevs
[16:41:43] <cradek> fatal: Could not parse object '8fa729863ca142706c65c13e4514dfeeba5159de'.
[16:41:47] <cradek> yeah ok that means a lot thanks
[16:42:03] <andypugh> To be fair, I can’t parse thet either
[16:42:33] <bpuk> it's a hash of some kind? no wonder it can't parse it
[16:42:39] <cradek> probably the arm lollipop caught on fire or something
[16:42:47] <cradek> need to reboot the jolly rancher
[16:45:41] <cradek> I'm off, cheers
[16:45:48] <bpuk> Tally ho
[17:05:22] <bpuk> time to start slowly reading though andypugh's remap code
[17:05:54] <andypugh> Hmm, time to get that right and push the latests
[17:12:38] <bpuk> ok, I can't see anything evil in there ;)
[17:12:57] <andypugh> The evil is well hidden.
[17:13:02] <bpuk> heh
[17:13:30] <bpuk> alternatively, the whole thing is evil, and I can't see past the python
[17:21:47] <linuxcnc-build> build #4651 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4651 blamelist: dummy, Tero Kaarlela <tero.kaarlela@eka-sorvaus.fi>, andypugh <andy@bodgesoc.org>, Jeff Epler <jepler@unpythonic.net>, Ben Potter <ben@bpuk.org>, Norbert Schechner <nieson@web.de>