Back
[00:24:48] <seb_kuzminsky> at least part of the merge difficulty is because JT-Shop reindented it in 2.7's 299eacb3f707d0f2d2dc6058512000c963bc7b68
[00:27:28] <seb_kuzminsky> so after trying to resolve the conflict, i can't see the diff i actually saved, because it's lost in 1443 lines of reflow changes
[00:28:24] <seb_kuzminsky> i will try building the html before and after the merge and diffing the html, that might subtract out the paragraph reflow
[00:47:35] <seb_kuzminsky> lolnope!
[00:47:57] * seb_kuzminsky flips the table and goes to bed
[05:52:05] <jthornton> actually I did quite a bit of work on gmoccapy but I don't understand why it won't merge cleanly, nothing has been changed in master
[05:52:22] <jthornton> since the last merge
[07:46:29] <KGB-linuxcnc> 03John Thornton 052.6 04d03cf 06linuxcnc 10docs/src/gcode/gcode.txt Docs: specify that g92.1 and g92.2 only affect the g92 offsets. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=04d03cf
[07:46:57] <jthornton> I hope this doesn't mess up your merging seb_kuzminsky
[08:37:59] <cradek> that looks like a good change
[08:38:17] <cradek> seb had already tagged and mergeupped 2.6 so this won't affect the immediate release work
[08:38:33] <cradek> also, yay for 2.6.9, wheee
[08:39:58] <cradek> I sure like how kgb gives the corresponding gitweb url
[08:52:11] <jthornton> was 2.6.9 the last release?
[08:52:39] <skunkworks_> no - it tis the next release of 2.6
[08:54:48] <jthornton> I guess I meant to say will my last commit get merged into 2.7 and up?
[09:23:22] <cradek> yes it will, but possibly not for this first 2.7 release
[09:34:32] <seb_kuzminsky> jthornton: i'll merge it for 2.7.0~pre7
[09:34:46] <cradek> yay!
[09:34:58] <cradek> heh I was half-expecting 2.7.0
[09:35:55] <skunkworks_> seb_kuzminsky, I think the violations are rare and can be fixed in the 2.7.0~pre7. (with rob being so busy)
[09:36:13] <skunkworks_> and is as good as 2.6 with lots of improvemnts
[09:45:02] <mozmck> How bad are the violations?
[09:46:03] <skunkworks_> I have found one that was around 20% over so far.
[09:46:33] <mozmck> bummer!
[09:47:19] <skunkworks_> eh - the current TP has violations aproacihing that in some situations.
[09:47:33] <mozmck> I see.
[09:47:56] <skunkworks_> still way less than mach ;)
[09:48:03] <mozmck> :0
[09:48:05] <skunkworks_> and usually for a few servo cycles.
[09:48:18] <skunkworks_> probably why they where never noticed.
[09:48:37] <dgarr> pcw_home: it is ok to post gwatch demo, updated the tar file to rename pin to axisui.heartbeat
[09:50:45] <pcw_home> Thanks, should help diagnosing emcPTs problem
[09:58:18] <seb_kuzminsky> 2.6.9 is uploading to wlo now :-)
[09:58:48] <skunkworks_> Yay!
[09:59:56] <seb_kuzminsky> i should write an email
[10:01:47] <jepler> seb_kuzminsky: thank you!
[10:02:03] <jepler> I don't know how many drinks I owe you by now, but it's more than you should have in one sitting
[10:02:34] <jepler> 22:25:37 <seb_kuzminsky> then "git push 2.6 v2.6.9"
[10:02:34] <seb_kuzminsky> heh, i feel the opposite way
[10:02:38] <jepler> should be git push origin 2.6 v.2.6.9
[10:02:43] <jepler> seb_kuzminsky: you feel like you could have them in one sitting?
[10:02:57] <seb_kuzminsky> you guys do all the work, i just push the releases out
[10:04:06] <seb_kuzminsky> you're right, i goofed the commandline i told mozmck
[10:04:29] <seb_kuzminsky> it's right on the webpage,
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList
[10:04:57] <seb_kuzminsky> we should have a linuxcnc combined hackfest and drinking party
[10:05:15] <seb_kuzminsky> maybe we can call it a 2.7 release party? this fall some time?
[10:05:19] <skunkworks_> That sounds like a bug writing party..
[10:05:23] <seb_kuzminsky> heh
[10:05:26] <jepler> skunkworks_: a rule would have to be "no commits"
[10:05:38] <seb_kuzminsky> we'll temporarily revoke our commit access after the first round
[10:05:40] <jepler> seb_kuzminsky: is this a virtual party or a real party?
[10:05:49] <seb_kuzminsky> real
[10:06:08] <jepler> I wouldn't rule it out, I have been wanting to take a trip to Denver for ages
[10:06:14] <jepler> er, Boulder
[10:06:15] <jepler> well both really
[10:06:17] <seb_kuzminsky> heh
[10:06:29] <jepler> (Ingrid's going to Denver thursday and I'm jealous)
[10:06:40] <jepler> (a conference being held at the botanic gardens there)
[10:06:40] <seb_kuzminsky> we could hang out at the hackspace
[10:06:51] <seb_kuzminsky> there's power & wifi & some wonky machine tools
[10:06:58] <seb_kuzminsky> and couches that only smell a little funky
[10:07:07] <jepler> Make it after 9/18 and I'll attend
[10:07:16] <seb_kuzminsky> ok!
[10:08:13] <cradek> I'm absolutely in
[10:08:19] <seb_kuzminsky> sweet!
[10:08:44] <cradek> where?
[10:08:47] <seb_kuzminsky> Boulder's close to the geographic center of the US, so it's a good place to meet
[10:08:59] <cradek> I think the center of the US is the hub bar in north platte
[10:09:09] <seb_kuzminsky> otoh it's not close to the geometric center of linuxcnc people
[10:09:16] <cradek> but I don't recommend meeting there
[10:09:25] <seb_kuzminsky> there's a little town between lincoln and boulder called haxtun, which seems prophetic
[10:09:38] <seb_kuzminsky> dont know what their hackspace is like
[10:11:40] <cradek> we need to convince skunkworks to come so the center of people is near lincoln :-)
[10:12:43] <cradek> we could boldly update all my machines to 2.7
[10:15:25] <seb_kuzminsky> i would come to lincoln
[10:18:22] <seb_kuzminsky> when i try to change the topic, chanserv says "#linuxcnc-dev is not registered"
[10:18:30] <cradek> the vmc really should get updated some time - it's getting old enough I'm getting wary of changing it
[10:18:34] <cradek> it's spelled -devel
[10:18:55] <seb_kuzminsky> heh
[10:19:26] ChanServ changed topic of
#linuxcnc-devel to:
http://linuxcnc.org | Latest release: 2.6.9 | (this channel is logged by the zlog robot)
[10:19:27] <cradek> YAY!
[10:19:36] <seb_kuzminsky> i did it!
[10:21:15] <cradek> seb_kuzminsky: I really appreciate your release-manager work.
[10:24:21] <skunkworks_> So do we (dad and I)
[10:25:04] <Roguish> seb_kuzminsky: EVERYONE appreciates the incredible effort by all dev's.
[10:25:19] <Roguish> and cradek.
[10:26:40] <seb_kuzminsky> :-)
[10:26:49] <seb_kuzminsky> ok the websites are updated
[10:26:57] <seb_kuzminsky> i'm off to work! see you all later!
[10:57:22] <JT-Shop> <seb_kuzminsky> we should have a linuxcnc combined hackfest and drinking party
[10:57:33] <JT-Shop> be a good excuse to brew up some beer
[10:57:38] <archivist> I'll drink to that :)
[10:57:54] <skunkworks_> everytime someone asks about JWP - take a drink!
[10:58:34] <skunkworks_> everytime someone asks why usb isn't used as an interface - take a drink!
[10:58:45] <archivist> just had to throw most of my dads homebrew away, leaking circa 1974
[10:58:48] <JT-Shop> I better brin
[10:58:52] <JT-Shop> g a lot
[10:59:12] <JT-Shop> that's pretty aged
[11:00:10] <JT-Shop> I didn't have a clue that my bike parts would come from Ballclare
[11:00:23] <JT-Shop> opps Ballyclare
[11:18:07] <seb_kuzminsky> where do you live, JT-Shop ?
[11:19:02] <JT-Shop> swamp east Missouri, 3hrs from St. Louis, Memphis, and Little Rock
[11:24:54] <seb_kuzminsky> debian's kernel packaging is now in git: git://git.debian.org/git/kernel/linux.git
[12:29:27] <jepler> we should call the next one version 3.0 and change the command to start it to 3mc
[12:30:19] <mozmck> heh!
[12:31:41] <JT-Shop> how about mc
[12:31:48] <mozmck> already used
[12:31:49] <jepler> JT-Shop: that's taken
[12:31:59] <mozmck> Midnight Commander, which I use a good bit
[12:32:07] <JT-Shop> lmc
[12:32:09] <JT-Shop> ?
[12:32:53] <jepler> (I don't really want to change the name of the software)
[12:33:27] <skunkworks_> what would designate a version change? 2->3?
[12:36:14] <skunkworks> mozmck: 2.6 maybe a 3rd of the way through this program -
http://imgur.com/6MTeDxo,Hu9PHOJ#1
[12:36:29] <skunkworks> robs branch run all the way through
http://imgur.com/6MTeDxo,Hu9PHOJ#0
[12:37:58] <skunkworks_> X should be 30.
[12:38:25] <seb_kuzminsky> ouch
[12:39:20] <seb_kuzminsky> http://edushyster.com/wp-content/uploads/2012/09/barbie1.jpg
[12:39:55] <skunkworks_> it is. and mach is going to have a 3rd order planner when they get the time...
[12:40:09] <seb_kuzminsky> that would be awesome
[12:40:47] <seb_kuzminsky> i wonder what would make us renumber frmo 2.x to 3.0
[12:41:10] <skunkworks_> after seeing what it takes to get a decent working N-lookahead planner in linuxcnc - TP'ing is hard
[12:41:10] <seb_kuzminsky> i wonder if we should just drop the leading number
[12:42:03] <skunkworks_> 2.0 -> 3.0... JWP... ;)
[12:42:10] * seb_kuzminsky takes a drink
[12:42:20] <skunkworks_> Awesome!
[12:42:27] <archivist> ACD all can do
[12:42:56] <archivist> actually that is a stolen acronym :)
[12:52:12] <mozmck> re: what would make us renumber from 2.x to 3.0? That's easy, 3.0 comes after 2.9!
[12:52:39] <jepler> skunkworks_: I don't understand what I'm looking at in those two screenshots, can you explain?
[12:53:14] <skunkworks_> The X axis peak acceleration values on the right side. It should not go over 30in/s^2
[12:53:39] <jepler> skunkworks_: ah
[12:53:50] <seb_kuzminsky> skunkworks_: but 2.6 finishes it, right? with not worse violations than your first screenshot shows?
[12:53:52] <cradek> so both planners do it with about the same wrongness?
[12:53:57] <cradek> that's surprising
[12:54:17] <jepler> "both parties do it"
[12:54:24] <jepler> oops, sorry, I got politics in your cnc
[12:54:42] <skunkworks_> cradek, I have a feeling they are not in the same place..
[12:54:55] <skunkworks_> But I could surely check
[12:55:29] <jepler> what's the program, is it something real or something designed to frustrate TPs?
[12:55:29] <skunkworks_> seb_kuzminsky, I will let you know - but I have never seen the classic planner much over that in overages
[12:55:44] <seb_kuzminsky> thx
[12:55:54] <skunkworks_> jepler, it is tuxcnc that someone made - rotated and scaled.
[12:56:05] <skunkworks_> and moved
[12:56:14] <jepler> skunkworks_: ah I can sorta see tux hiding in there
[12:56:21] <cradek> tux doesn't even have arcs does it?
[12:56:29] <skunkworks_> this one does.
[12:56:32] <cradek> ah
[12:57:04] <skunkworks_> both - strait line segment paths + arcs
[12:57:11] <cradek> wonder what's special about X that makes them both get it wrong
[12:57:21] <cradek> with it rotated you'd think it'd be symmetric
[12:57:40] <jepler> .. because Yacc is higher?
[12:57:50] <jepler> maybe if you swap Xacc and Yacc you'd get the overage on Y
[12:57:53] <cradek> oh sure, it's the low one
[12:57:54] <skunkworks_> It is the lower acceleration axis. (I had changed it to Y and the violations followed)
[12:57:57] <cradek> ok
[12:58:02] <skunkworks_> right
[12:58:51] <skunkworks_> Rob knows about it - I gave him some examples. Unless someone else wants a stab at it.
[12:59:13] <skunkworks_> I guess I should have made a bug report.
[12:59:57] <cradek> were you able to isolate a little chunk of gcode?
[13:00:20] <skunkworks_> let me see how small it is.
[13:00:53] <skunkworks_> is robs stuff merged into 2.7?
[13:00:55] <jepler> it would be dandy if you could add "latch gcode line number on new worst violation"
[13:01:21] <cradek> oooh
[13:03:52] <skunkworks_> well - I kinda do that with halscope manually.
[13:04:12] <skunkworks_> run program once to get the worse - then run again with trigger set just under worse
[13:04:26] <skunkworks_> loggging program line
[13:04:53] <cradek> you could ddt the worst and trigger on >0
[13:04:53] <jepler> It looks like that program involves subroutines so just the line number doesn't capture everything
[13:05:00] <cradek> eww
[13:05:20] <jepler> I'm only assuming that, maybe it has the main body of tux repeated over and over again
[13:06:24] <skunkworks_> I also display the debug the degrees of rotations so I can figure out where in the code and what angle
[13:14:27] <seb_kuzminsky> skunkworks_: yes, rob's feature/tangent-improvement-2.7-rebase is in 2.7
[13:14:52] <seb_kuzminsky> along with a ton of other bug fixes - it's been a good couple of days for linuxcnc improvements
[13:15:21] <skunkworks_> Ah - I missed that commit
[13:16:20] <skunkworks> cradek:
http://pastebin.ca/3099544
[13:17:21] <skunkworks> x=40in/s^2, y= 30in/s^2 Z=400in/s^2. all axis 8.333 (500in/s)
[13:22:06] <skunkworks> it doesn't violate on every iteration - but you can see the violations ramp up to a peak and then back down both positive and negative. The interesting thing is the y movements are only for fixture movements...
[13:22:34] <skunkworks> but I guess they are not during the normal gcode run.. that gcode snipit is in the middle of the gcode
[13:25:12] <cradek> ok, I see them
[13:25:39] <skunkworks> violations?
[13:25:44] <cradek> yeah
[13:26:25] <skunkworks> I am sure it could be just a little smaller..
[13:27:25] <cradek> ooh it's not at a blend
[13:28:17] <skunkworks_> ooh!
[13:28:20] <cradek> it's the g18g2 arc when rotated 282? degrees
[13:28:51] <cradek> line 21
[13:29:38] <skunkworks_> the viloationi starts negative at 60.6 iirc
[13:29:58] <skunkworks_> and peaks negative then at around the 282 mark it goes positive..
[13:30:18] <cradek> http://timeguy.com/cradek-files/emc/bug428.png
[13:30:33] <cradek> ah I was only triggering positive
[13:31:36] <skunkworks_> YEp - I get the same positive.
[13:33:04] <skunkworks_> god linuxcnc is awesome.
[13:34:14] <KGB-linuxcnc> 03Chris Radek 05sam/bug428 62924f0 06linuxcnc 03configs/sim/axis/autosave.halscope 10configs/sim/axis/axis.ini 03nc_files/bug428.ngc bug428: accel violations in rotated g18g2 arc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62924f0
[13:34:52] <cradek> you can point your bug report to this branch for easy reproduction
[13:41:35] <seb_kuzminsky> bug 428?
http://sourceforge.net/p/emc/bugs/428/
[13:42:00] <cradek> crap
[13:43:17] <skunkworks> was I too slow - I was writing it up.
[13:43:37] <cradek> no I just guessed the number wrong
[13:43:42] <cradek> I will fix it so you can say sam/bug430
[13:44:53] <KGB-linuxcnc> 03Chris Radek 05sam/bug430 9ec41b5 06linuxcnc 03configs/sim/axis/autosave.halscope 10configs/sim/axis/axis.ini 03nc_files/bug430.ngc bug430: accel violations in rotated g18g2 arc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9ec41b5
[13:45:07] <KGB-linuxcnc> 05sam/bug428 62924f0 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62924f0
[13:45:40] <cradek> fwiw, I bet this is an emccanon bug, not a tp bug
[13:45:46] <cradek> because have you seen that code?
[13:47:12] <skunkworks_> Heh - the formating and wording of of the bug report sucks
[13:47:16] <cradek> sourceforge: you're drunk, go home
[13:47:23] <cradek> good grief
[13:47:30] <skunkworks_> (some if not all my fault)
[13:48:15] <skunkworks_> crap - I forgot to rename the branch
[13:48:16] <cradek> I think I can edit it, hang on
[13:50:23] <cradek> there!
[13:50:42] <cradek> I hit it with a stick until it looked better
[13:51:13] <skunkworks_> wow - thanks
[13:51:41] <skunkworks_> gcode is gone?
[13:51:55] <cradek> it's in the branch, so I just nuked it
[13:51:56] <skunkworks_> oh = never mind
[13:51:59] <skunkworks_> thanks
[13:52:05] <cradek> copypaste out of sourceforge never works right anyway
[13:52:16] <cradek> it's not the greatest bugtracker I've seen...
[13:56:05] <skunkworks_> we started goofing around with osticket and it seems like it will do everything we need here.
[13:56:33] <cradek> I have a bit of experience with bugzilla
[13:59:10] <cradek> seb_kuzminsky: I'm getting debug output from task
[13:59:11] <cradek> task: main loop took 0.011780 seconds
[13:59:16] <cradek> is itintended?
[13:59:31] <skunkworks_> heh - look at that
[14:00:12] <skunkworks_> not very often.
[14:00:53] <skunkworks_> oh maybe when it is running a program
[14:02:24] <cradek> why the hell can't I middle click and paste into the bug report??
[14:03:08] <skunkworks_> I have an interesting issue.. Why don't my cursor keys work in the mdi window?
[14:03:35] <skunkworks_> Up/down works left/right don't
[14:04:28] <skunkworks_> must be maybe my laptop. let me try another computer
[14:05:13] <skunkworks_> hmm - just this laptop.
[14:05:21] <cradek> weeeeird
[14:07:48] <skunkworks_> I think it has been this way for a long time. I remember wondering about it before.
[14:08:19] <skunkworks_> cradek, can you test something while you have linuxcnc up.
[14:09:10] <cradek> bet we'd see a velocity violation too, if they were different
[14:09:14] <cradek> sure what?
[14:09:34] <skunkworks_> run a program - > estop. then hit the reload button
[14:10:17] <cradek> ick
[14:10:33] <skunkworks_> ok - I can put a bug report for that too.
[14:10:47] <cradek> it eventually comes back!
[14:10:48] <cradek> weird
[14:10:54] <skunkworks_> yes - it just hangs for a while
[14:10:55] <cradek> I hate software
[14:12:48] <skunkworks_> I like getting updates to a bug tracker
[14:15:20] <skunkworks_> you get the same delay if you try to then open a 'recent' gcode file
[14:16:01] <skunkworks_> or open a file.. - you can select the file but you get the same timeout
[14:20:07] <skunkworks_> cradek, rob emailed me back and said - yes cannon may be sending bad commands but tp should still handle them without violations.
[14:22:42] <cradek> heh, one of us doesn't understand how it works then :-)
[14:22:47] <cradek> and I bet I know which
[14:30:36] <cradek> http://paste.ubuntu.com/12057344/
[14:35:30] <skunkworks_> oh - let me run it through the pases
[14:35:34] <skunkworks_> paces
[14:37:43] <skunkworks_> wait - was that a bug from your coordinate rotation work? ;)
[14:37:49] <cradek> shhhh
[14:37:53] <skunkworks_> :)
[14:38:16] <cradek> real answer: I don't know, all this code has changed since then
[14:38:45] <skunkworks_> It is funny that I cannot run this exact program on 2.6 because of arc end errors
[14:38:53] <skunkworks_> (a good thing I think)
[14:39:04] <cradek> you test the wildest things
[14:39:06] <cradek> it's great
[14:47:59] <skunkworks_> those that can't - test
[14:49:48] <mozmck> heh, if you can't fix it, at least you can try and break it!
[14:50:22] <skunkworks_> exactly!
[14:50:42] <skunkworks_> I have found lots of bugs.. :)
[14:50:52] <mozmck> Sounds like a t-shirt idea...
[14:51:06] <skunkworks_> The K&T brought a bunch of stuff to light.
[14:51:17] <mozmck> Ah, yes.
[14:51:52] <skunkworks_> even before I broke the new TP
[14:52:38] <mozmck> They say testing is often better done by someone other than the developer.
[14:52:56] <cradek> oh absolutely
[14:53:34] <cradek> if a developer thinks of a certain problem, it's already probably coded correctly
[14:53:54] <cradek> testing just what you already thought of when you wrote it is not the best test
[14:54:33] <jepler> https://imgflip.com/i/pehh7
[14:54:57] <mozmck> maybe :)
http://www.candcnc.net/supportforum/viewtopic.php?f=3&t=893#p4157
[14:55:16] <cradek> The board requires you to be registered and logged in to view this forum.
[14:55:21] <mozmck> oh, bummer.
[14:55:35] <mozmck> Don't know why Tom did that.
[14:55:44] <jepler> skunkworks_: thanks for finding a pretty minimal test case for that one.
[14:55:52] <cradek> it's obnoxious and everyone seems to do it
[14:56:23] <mozmck> I have some checks on values sent to firmware in a board, and I reset to defaults if the values are out of bounds.
[14:56:51] <mozmck> Only problem was I reset one value to an out-of-bounds value accidentally.
[14:57:05] <cradek> oops!
[14:57:18] <skunkworks_> jepler, it is usually pretty easy to narrow it down to a few lines of gcode. Halscope tells me the line - I just whittle away until I can't anymore.
[14:57:24] <mozmck> User put in a value to low and it caused odd looking problems - until I looked at my firmware again.
[15:01:05] <skunkworks_> oh - that is why the error seemed to show up in 2.6 also...
[15:01:31] <skunkworks_> (almost identical violation)
[15:02:19] <cradek> seb will be sad if I fix a 2.6 bug the day of the release
[15:03:11] <skunkworks_> heh
[15:03:25] <skunkworks_> again - no one noticed....
[15:03:51] <skunkworks_> (that we know of)
[15:14:40] <KGB-linuxcnc> 03Chris Radek 05cradek/2.6/bug430-fix 9eeb266 06linuxcnc 10src/emc/task/emccanon.cc fix bug430: constraint violations with rotated g18/g19 arcs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9eeb266
[15:15:01] <cradek> skunkworks_: if you're curious enough, I'm thinking this should fix it in 2.6
[15:15:14] <jepler> geez time for 2.6.10
[15:16:58] <skunkworks_> If I get the time I will apply the patch to 2.6 and test
[15:17:25] <cradek> the patch won't work at all - code's completely different - try this cradek/2.6/bug430-fix branch
[15:17:34] <skunkworks_> duh
[15:17:35] <skunkworks_> yes
[15:17:50] <skunkworks_> when I saw that - I thought it was the same patch.
[15:21:14] <cradek> actually by looking at 2.6 I found a bug in my 2.7 patch
[15:22:11] <cradek> what if you only have X and Z axes and you rotate around Z
[15:22:17] <cradek> I imagine it shouldn't let you do that
[15:22:23] <cradek> I bet it does let you do that
[15:45:33] <seb_kuzminsky> cradek: i'd love it if you fixed a bug in a < 12 hours old release :-)
[15:46:24] <lerman> jepler... I saw your note about the dup o-word bug. It is doing exactly what I expect to do when it rereads a file. That's because the code "remembers" the addresses (file and line number) of all of the o-words it has seen.
[15:47:52] <lerman> It was originally written that way so that you wouldn't have to scan an entire file to find the subroutines in it. (Originally, you could have multiple subroutines in a single file.) The code should probably be changed to "forget" all owords in a file when the file is reread.
[15:50:31] <jepler> lerman: thanks for the background
[15:53:58] <lerman> I do prefer the original way it worked. When a subroutine was called, first it looked to see if it had already been seen. If not, it found the file with the appropriate name and scanned the entire file looking for subroutines. So I could have a probing library in a single file. Call o<safe_probe_init> to initialize it. After scanning safe_probe_init.ngc, it would then know about all of the subroutines in the lib
[15:53:58] <lerman> rary. The way it works today, I put all of the routines in the same library, but then have to have a symbolic link for each of the routines in the library. Just more stuff to do with no value (to me, at least).
[15:55:29] <cradek> I don't know how, why, or when that changed
[16:00:13] <lerman> Every time you call a subroutine, the file is "seeked" to the memorized location of the subroutine. So editing the file can have nasty results (unless someone has added code to avoid that). It can wind up seeking to the middle of a line. In some ways it would be cleaner if it just didn't bother remembering anything in subroutine files. That would be less optimized, but conceptually cleaner. And it would work the
[16:00:13] <lerman> way people might expect it to work.
[16:00:46] <cradek> would it seek from the beginning each time?
[16:01:05] <lerman> The alternative is to put in the optimization, but add code to forget the contents of the file. Then each time a routine is called, a check could be made to see if the file had changed.
[16:02:38] <lerman> Right now, it does a seek each time. Remember that files are not stored in memory. Only the locations of the owords (filename and linenumber) are stored. {Note: I'm describing the way it was originally written -- who knows what the last hands on the code did to it.}
[16:03:12] <cradek> certainly noted
[16:03:28] <lerman> Of course, the file actually is stored in memory -- by the operating system to the degree that there is plenty of memory to store recent files.
[16:24:56] <seb_kuzminsky> uh oh
[16:25:14] <seb_kuzminsky> when both cradek and KGB-linuxcnc disconnect at the same time, you know things are getting serious
[16:27:28] <jepler> hm, I haven't paid much attention to the route from office to my house vs cradek's...
[16:27:59] <jepler> but right now, packets for timeguy are going to chicago and getting lost while packets to my house are going via tx
[16:28:44] <jepler> wer're both 76.79.x.y, which whois says is allocated as a /17
[16:31:19] <seb_kuzminsky> how about a nice big cup of CIDR?
[16:45:54] <seb_kuzminsky> welcome back
[16:57:41] <seb_kuzminsky> cradek: i made task emit that warning the first 10 times it takes 10x longer than expected to run through its loop
[16:59:36] <linuxcnc-build> build #3341 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3341 blamelist: Chris Radek <chris@timeguy.com>
[17:04:06] <seb_kuzminsky> that failed because task went out to lunch:
[17:04:06] <seb_kuzminsky> task: 3887 cycles, min=0.000015, max=6.020792, avg=0.002691, 3 latency excursions (> 10x expected cycle time of 0.001000s)
[17:04:48] <JT-Shop> pass task a beer so it can relax and get ready to work
[17:05:05] <seb_kuzminsky> or a cup of coffee to get it off the couch
[17:05:29] <seb_kuzminsky> this is probably a much bigger problem on the buildslave VMs than it is in the real world
[17:05:35] <seb_kuzminsky> but it's a problem in the real world too
[17:05:42] <seb_kuzminsky> i mean it can happen in the Real
[17:09:07] <seb_kuzminsky> that test failure just now squicks me out - the test took its finger off the jog button, but the machine kept jogging for seconds and seconds
[17:37:38] <linuxcnc-build> build #3351 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3351 blamelist: Chris Radek <chris@timeguy.com>
[17:56:52] <andypugh> Will it be 2.6.10 or 2.6.A ?
[18:09:30] <JT-Shop> I like Hexadecimal too
[18:29:25] <seb_kuzminsky> oh god the mailing list threads about that are already making my hair hurt
[18:38:16] <Tom_itx> octal ftw
[20:24:58] <cradek> seb_kuzminsky: that can't have been a mode switch causing a sync then, could it?
[20:30:28] <seb_kuzminsky> yeah i think you're right
[20:31:26] <seb_kuzminsky> the log shows there's just one sync, at startup, and no syncs while the test jogs around
[20:31:40] <seb_kuzminsky> just shitty scheduling, i'd guess, in the hypervisor most likely
[20:33:18] <cradek> huh wonder if I got kicked off the MLs
[20:34:27] <cradek> nope
[20:39:59] <seb_kuzminsky> i get 2 copies of all commit emails
[20:49:22] <seb_kuzminsky> sf is full of surprises
[20:49:50] <seb_kuzminsky> cradek: is that canon fix ready to push to 2.6? if so i'll merge it up to 2.7 before the next (and hopefully final) prerelease
[20:53:43] <cradek> skunkworks was going to perhaps try to test it
[20:53:51] <cradek> I'm pretty sure it's right
[20:54:17] <cradek> the merge will utterly fail, so you'll have to fake it - the 2.7 patch is very different
[20:55:04] <cradek> I actually tested the first 2.7 patch, but not the revised one
[20:55:13] <seb_kuzminsky> ah
[20:55:17] <seb_kuzminsky> will you do the merge?
[20:55:25] <cradek> sure
[20:55:25] <seb_kuzminsky> "merge"
[20:55:37] <cradek> massarge
[20:55:45] <seb_kuzminsky> i'll hold off on ~pre7 until you're done
[20:56:21] <cradek> I'd like to hear rob's thoughts about the 2.7 patch
[20:56:27] <seb_kuzminsky> i'm having existential angst about task's latency
[20:56:30] <cradek> there's no hurry for a 2.6 patch
[20:56:39] <seb_kuzminsky> i wish rob shared his thoughts with us more
[20:57:12] <cradek> yeah I wish he could be here, but I understand if he can't
[20:57:24] <seb_kuzminsky> yeah
[21:01:25] <seb_kuzminsky> yay, it's tuesday night! that's hackspace night!
[21:02:33] <cradek> yay!
[21:31:41] <cradek> oh look
[21:32:58] <skunkworks> I have not tested 2.6 yet
[21:33:57] <skunkworks> 2.7 is still running
http://i.imgur.com/qaBBfcl.png
[21:34:01] <skunkworks> only a slight overage
[21:34:23] <cradek> is that with the first or second patch? (sorrY)
[21:34:33] <cradek> 6 hours, wow
[21:34:50] <cradek> I think 262 is where it was failing
[21:35:35] <skunkworks> first
[21:36:02] <skunkworks> it was failing all over the place..
[21:36:14] <cradek> ah
[21:36:24] <cradek> I only ran the tiny one!
[21:38:06] <skunkworks> the second patch should not effect this too much - should it?
[21:40:06] <cradek> really should be the same, except it won't freak out in a weird situation of someone rotating on a machine missing X or Y, like a lathe
[22:02:04] <Tom_itx> skunkworks, what desktop is that?
[22:38:49] <seb_kuzminsky> Tom_itx: looks like ubuntu precise (12.04)
[22:40:51] <Tom_itx> hmm haven't loaded 12
