Back
[05:14:27] <Balestrino> Hi jepler, can i do another pull request with optimized code as you suggested?
[05:33:14] <smainj> hello
[05:43:47] <c_morley> seb_kuzminsky: I think the changes to tooledit widget are fine. Thanks for bringing it to my attention..odd it doesn't sort properly be default.
[05:45:05] <c_morley> ttyl
[07:06:38] <jthornton> I just got openbox working and so far I like it. I also figured out how to change default search engine in firefox
[08:05:07] <jepler> Balestrino: yes. Please take the opportunity to add your signed-off-by to the commit message as well.
http://linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy
[08:06:17] <Balestrino> ok
[09:02:02] <seb_kuzminsky> c_morley: thanks for the feedback, i'll push it
[09:02:42] <seb_kuzminsky> jepler: err, or are you and balestrino talking about redoing the commit he offered in PR #18?
[09:02:58] <seb_kuzminsky> or are you talking about a different thing and i should go ahead and merge #18?
[09:50:47] <seb_kuzminsky> hi Balestrino
[09:52:55] <Balestrino> Hi Seb
[09:55:50] <seb_kuzminsky> Balestrino: i missed what you and jepler were talking about - was it the tooledit_widget PR you made yesterday, or was it something else?
[09:56:44] <Balestrino> yes was about the code, we can shrink the code a little bit
[09:57:11] <Balestrino> should i make another PR with new code?
[09:59:07] <seb_kuzminsky> yes
[09:59:31] <seb_kuzminsky> and withdraw the earlier PRs that have been superceeded
[09:59:44] <Balestrino> ok
[09:59:51] <seb_kuzminsky> *superseded
[10:35:35] <Balestrino> uhm, i see that c_morley added a "gladevcp -add lathe wear offset display option" on master branch (4 oct)
[10:39:59] <Balestrino> 2.6 and 2.7 are behind master, so i should PR on master?
[10:41:14] <seb_kuzminsky> Balestrino: no, 2.6 is the place
[10:41:22] <seb_kuzminsky> the bug fix should go in the oldest branch that has the bug
[10:41:40] <seb_kuzminsky> http://linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html#_use_of_git_in_the_linuxcnc_project
[10:42:14] <seb_kuzminsky> there may be trouble when the fix is merged from 2.7 into master, but we'll deal with that then
[10:42:23] <Balestrino> ok
[10:45:07] <mozmck> When you set a parameter in a loadrt line like this: servo_period_nsec=[EMCMOT]SERVO_PERIOD Does that set the variable named servo_period_nsec in motion?
[10:49:28] <cradek> static long servo_period_nsec = 1000000; /* servo thread period */
[10:49:31] <cradek> RTAPI_MP_LONG(servo_period_nsec, "servo thread period (nsecs)");
[10:49:46] <cradek> yes; that's what this kind of thing does, in motion.c
[10:50:15] <cradek> sadly there is no man page for RTAPI_MP_LONG
[10:50:31] <mozmck> Ok, so RTAPI_MP_LONG exports the variable somehow I guess.
[10:50:32] <cradek> oh! yes there is!
[10:52:34] <mozmck> thanks - I was looking at the loadrt code in halcmd_commands - not sure I quite follow it yet :-)
[10:54:01] <mozmck> So what I've determined is that you can still set a traj cycle time different than the servo time.
[10:54:20] <cradek> cool
[10:54:32] <mozmck> And if you do the points from traj are still interpolated
[10:54:51] <cradek> now that I'm here, I agree base/servo/traj are all motion parameters
[10:55:01] <cradek> cool, it's good we still have that feature
[10:55:24] <cradek> might be important on these newly-underpowered machines people are using
[10:55:40] <mozmck> Several sample configs still set traj_period_nsec
[10:57:12] <mozmck> heh, could be. It might be nice to shave a little time off by not even calling the interpolator if traj_period_nsec == servo_period_nsec
[11:13:20] <cradek> if you want motion to run faster, I strongly suggest profiling and not guessing what would make it faster
[11:13:52] <cradek> periodically profiling and looking for smoking guns is a great idea, and we don't do it
[11:19:41] <mozmck> I wasn't really looking to make motion run faster, just happened to notice that. Profiling would be a good idea, but I'm not sure how to even start with that.
[11:43:11] <jepler> the easiest way to profile is in a "uspace" system with the "perf" suite of programs installed. You can run "perf record linuxcnc", do the task you want to profile, and then run "perf report". You will see profile information for all the various parts of linuxcnc including gui, task, rtapi_app, etc
[11:43:44] <jepler> as well as accounting of time spent in the kernel, e.g., in syscalls
[11:44:08] <jepler> so looking just at time related to rtapi_app, the top item at 11% is read_hpet, presumably called from gettimeofday()
[11:45:04] <jepler> full report on rtapi_app here:
http://paste.ubuntu.com/13315061/
[11:46:39] <jepler> hm that's 2.6.10 so it may not be representative
[11:48:43] <mozmck> interesting! thanks.
[11:50:36] <jepler> beacuse my linuxcnc session was short, things that occur only once at startup will show up more strongly than you might wish; there are probably ways to run "perf record" that mitigate this
[11:51:58] <jepler> here's one from 2.7, top item is now emcmotController at 15%
http://paste.ubuntu.com/13315138/
[11:52:45] <mozmck> bbl - lunch
[12:00:25] <cradek> wow so many clocky things
[12:00:38] <cradek> do you know what 0xf4240 is?
[12:00:43] <jepler> yeah apparently linuxcnc cares a great deal what time it is
[12:01:06] <jepler> no, perf is not great at reporting the names of callers for some reasons I don't understand
[12:04:23] <micges> maybe it needs some debug info comiled in?
[12:05:51] <mozmck> cubicInterpolate is pretty far down the list at 0.20%
[12:06:31] <mozmck> cubicAddPoint is 0.80%
[12:08:04] <cradek> rtapi_app -> sqrt -> init_tls
[12:08:12] <cradek> is surprising
[12:09:10] <mozmck> 0xf4240 is busy!
[12:10:03] <cradek> and 0x200000000 is a surprising address
[12:10:25] <KGB-linuxcnc> 03Balestrino 052.6 04e0118 06linuxcnc 10lib/python/gladevcp/tooledit_widget.py tooledit_widget.py: tool diameter sorting fix * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=04e0118
[12:10:31] <seb_kuzminsky> thanks Balestrino
[12:10:44] <cradek> sweet
[12:11:50] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 dbf34f6 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dbf34f6
[12:13:30] <Balestrino> my pleasure
[12:14:32] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 4b97025 06linuxcnc 10lib/python/gladevcp/tooledit_widget.py Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4b97025
[12:14:37] <seb_kuzminsky> Balestrino: there was a merge conflict while merging it into master, just like you said there would be, could you take a look and see if i did the merge right?
[12:15:44] <Balestrino> ok
[12:22:55] <seb_kuzminsky> hmm
[12:24:40] <seb_kuzminsky> KGB-wlo: are you feeling all right?
[12:24:40] <KGB-wlo> seb_kuzminsky: My master told me to not respond.
[13:17:49] <skunkworks> PCW: how you are feeling better.
[13:17:53] <skunkworks> hope..
[13:19:23] <pcw_home> A little better every day I expect to back at work on Thursday
[13:19:59] <pcw_home> motion-command-handler.time is a strange one timing wise
[13:20:00] <pcw_home> normally about 100 ns but rarely up to 70 usec on my test system
[13:21:15] * JT-Shop hates being sick, get well soon pcw_home
[13:22:23] <pcw_home> Thanks JT, its not a whole lot of fun ATM
[13:27:11] <Tom_itx> JT-Shop how would you approach drawing a spring in SW like a safety pin?
[13:27:22] <Tom_itx> i can get a coil spring easy
[13:27:27] <Tom_itx> i need wires coming off it
[13:45:11] <JT-Shop> lol sounds like fun
[13:46:27] <JT-Shop> just extrude off the ends of the coil
[14:24:34] <skunkworks> JT-Shop: are you subscribed to the dg2gcode-users google group?
[14:45:04] <JT-Shop> no
[14:46:49] <JT-Shop> why?
[14:52:27] <JT-Shop> dunno what that is about...
[14:53:45] <seb_kuzminsky> pcw_home: motion-command-handler probably does nearly nothing usually, and occasionally gets a command from Task that requires a bunch of effort
[15:12:46] <JT-Shop> skunkworks: there are more than one of me lol
[15:20:18] <skunkworks> JT-Shop: just an email that was odd from another person.
[15:20:41] <skunkworks> Apologize to John Thornton
[15:20:47] <skunkworks> I would like to apologize to Mr John Thornton who allowed me to submit his CamBam drag knife script file to this group to be studied for the development for the drag knife addition to DXF2GODE. This is a long time coming I would like to thank John and apologize for my disrespect. Tim March
[16:01:46] <JT-Shop> yea, I got that too and very strange indeed
[16:01:59] <JT-Shop> he sent you that email too?
[16:09:31] <jepler> haha this circuit board's silkscreen says "Designed with Lead Free Intentions"
http://smg.photobucket.com/user/TheProfosist/media/LinusTechTips/LTT-Mine/IMG_1460.jpg.html
[16:18:28] <Balestrino> seb_kuzminsky i fixed the tooledit_widget.py, now i have to commit it directly to master branch?
[16:19:15] <seb_kuzminsky> jepler laughing at that board makes me think of this:
https://www.youtube.com/watch?v=ahKH19iN2SM
[16:19:21] <seb_kuzminsky> Balestrino: it's already in master
[16:20:11] <jepler> seb_kuzminsky: I've got tears in my eyes
[16:20:33] <seb_kuzminsky> you should fetch from our github and inspect the tooledit_widget.py in the master branch, and see if it looks right to you
[16:21:02] <Balestrino> yes i get it, but never resolved a conflict (apart using --force:)
[16:22:05] <seb_kuzminsky> i'm not sure i understand you now
[16:22:14] <seb_kuzminsky> i resolved the merge conflict when i merged it into master
[16:22:56] <seb_kuzminsky> Balestrino: i must not be understanding what you're asking
[16:23:43] <Balestrino> i'm very poor with git. I just say that i'm used to resolve my git repo conflicts with --force (usually)
[16:24:03] <seb_kuzminsky> ah, heh
[16:26:02] <jepler> Balestrino: either test with master branch or look at the version of the file currently in the master branch and tell us whether it is correct now
[16:26:05] <jepler> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=lib/python/gladevcp/tooledit_widget.py;h=54fe698bcc3faf242ce96d860688b94750cfee20;hb=4b97025#l118
[16:26:17] <jepler> ^^^ master branch version of that file after seb_kuzminsky resolved the merge conflicts
[16:34:53] <Balestrino> current version in master branch is wrong. What i figured out is that Seb forced the merge, is it correct?
[16:35:47] <Balestrino> (i repeat the my knowledge of git is very basic)
[16:36:04] <seb_kuzminsky> Balestrino: oops! sorry if i messed it up, we'll fix it
[16:36:12] <seb_kuzminsky> here's what i did to get where we are now:
[16:36:23] <seb_kuzminsky> 1. i merged your PR #19 (into 2.6)
[16:36:32] <seb_kuzminsky> 2. i merged 2.6 into 2.7 (no conflicts)
[16:36:53] <seb_kuzminsky> 3. i merged 2.7 into master, and got a conflict on tooledit_widget.py
[16:37:13] <seb_kuzminsky> 4. I used "git status" to see that tooledit_widget.py had a conflict and needed manual attention
[16:37:42] <seb_kuzminsky> 5. i edited tooledit_widget.py by hand and arranged things how i thought they should be (and messed it up apparently, sorry)
[16:38:03] <Balestrino> ah ok, it's clear
[16:38:17] <seb_kuzminsky> 6. commit the resolved tooledit_widget.py, completing the merge of 2.7 into master
[16:38:26] <seb_kuzminsky> so that's the story so far.
[16:38:57] <seb_kuzminsky> what's wrong with how i resolved the merge of 2.7 into master?
[16:40:46] <Balestrino> model = self.view2.get_model() should be model = self.view1.get_model()
[16:42:31] <seb_kuzminsky> ok, i'll update it
[16:42:33] <seb_kuzminsky> thanks for the review
[16:43:05] <Balestrino> np, thanks for the explanation seb
[16:45:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master cc2959d 06linuxcnc 10lib/python/gladevcp/tooledit_widget.py gladevcp: fix merge conflict mistake in tooledit widget * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc2959d
[16:53:57] <mozmck> cradek: here is my hack to add a disable pin to joints. It mostly works I think - maybe good enough for what I need, but I need to test it more now.
[16:54:01] <mozmck> https://github.com/mozmck/linuxcnc-mirror/commit/decc049d0f2401a1a621f2b52de6ba6afa4de326
[17:06:55] <JT-Shop> mozmck: if you ever write down how you make a kernel please let me know
[17:07:55] <seb_kuzminsky> JT-Shop: not sure if this is relevant, but here's how i made the 3.4 RTAI kernels we ship for wheezy and precise currently:
https://github.com/SebKuzminsky/linux-rtai-build
[17:08:48] <JT-Shop> seb_kuzminsky: thanks, I'll study that
[17:10:30] <skunkworks> zlog
[17:12:30] <skunkworks> JT-Shop: was on the dxf2gcode google group
[17:12:52] <JT-Shop> I've never been there before
[17:13:53] <mozmck> JT-Shop: I'm only building preempt-rt kernels right now - did you try the ones I posted?
[17:14:06] <skunkworks> JT-Shop:
[17:14:08] <skunkworks> https://groups.google.com/forum/?hl=en#!forum/dxf2gcode-users
[17:14:30] <JT-Shop> not yet, I got a script from someone and I forget who and was trying that
[17:42:01] <seb_kuzminsky> how is dxf2gcode? does it work well?
[17:48:09] <JT-Shop> the time I tried it I could not get it to work, that's why I wrote my own
[17:50:15] <seb_kuzminsky> heh
[17:51:08] <JT-Shop> it was so complicated you could not even follow the code...
[17:51:47] <jepler> spoken like a true software developer
[17:56:13] <Roguish> JT-Shop: looking at someone's code is like looking into their mind. usually pretty scary.
[17:56:48] <JT-Shop> lol, yea that can be scary
[17:57:37] <micges> seb_kuzminsky: it's hard to use but working
[17:57:56] <seb_kuzminsky> micges: sounds like open source software
[17:58:20] <micges> yes it is :)
[17:59:17] <micges> not much intuitive gui but spits suitable gcode, used with 2.6.x
[17:59:22] * JT-Shop calls it a day
[17:59:36] <Roguish> open source looks kinda like Cybel's mind. (recall the woman with like 19 pesonalities...)
[17:59:41] <seb_kuzminsky> seeya JT-Shop
[18:27:37] <mozmck> pcw_home: have you seen this?
http://www.codeproject.com/Articles/275715/Real-time-communications-over-UDP-protocol-UDP-RT
[19:56:55] <skunkworks> the bit I have played with rescapind
[19:57:01] <skunkworks> heh
[19:57:14] <skunkworks> the bit I have played with it - it worked pretty well.
[19:57:22] <skunkworks> (dxf2gcode)
[20:01:10] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2023:05:22.png
[20:01:30] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2023:08:50.png
[20:12:28] <seb_kuzminsky> wow skunksleep, that looks pretty useful
[20:34:05] <skunkworks> I think you can use it as an input filter for linuxcnc also - although I have never tried it
