Back
[00:36:07] <andypugh> This is wierd
[00:38:21] <andypugh> I messed up my recent git push. I don’t really know how. The push —dry-run said I needed to pull first, I pulled and that brought up pico asking me to edit a merge report, I quit out of that, and to see where I was, did another dry run, that was happy, I looked at the log of the dry run, that looked good, I pushed and ended up pushing a merge.
[00:40:08] <andypugh> The strange thing is that gitweb / glo shows that the extra commit (the merge) did nothing and changed nothing, but github insists that i changed three files.
[00:40:37] <andypugh> Can sombody cofirm or deny that I messed things up?
[07:57:27] <jepler_> andypugh: I think everything is just fine.
[08:36:29] <emcPT> Any special reason (except performance) of not using a larger tool capability? Currently it is defined in #define CANON_POCKETS_MAX 56
[08:36:50] <emcPT> in emctool.h
[08:57:43] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 dcf1672 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py fix cut/paste slider AJOG error JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dcf1672
[09:02:57] <archivist> emcPT, iirc it has to fit in an nml message, one tool at a time would seem more sensible to me in the message
[10:22:23] <cradek_> if you need to enlarge it, just enlarge the tool buffer in the nml file to fit
[11:50:30] <KGB-linuxcnc> 03andypugh 05joints_axes14 608ad22 06linuxcnc 10scripts/update_ini update_ini: Fix a variable that should be a string * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=608ad22
[11:53:23] <seb_kuzminsky> jepler_: readline-license-check looks good for 2.7
[11:53:33] <seb_kuzminsky> thanks for keeping an eye on the lawyerly stuff
[11:54:11] <seb_kuzminsky> i want to make 2.7.5 soon, is anyone working on anything they want in the next 2.7 release?
[12:02:33] <jepler_> seb_kuzminsky: mozmck said he wishes my ethernet packet loss stuff would go in 2.7, but I would not hurry it in for a release.
[12:08:57] <seb_kuzminsky> it does seem like a good bugfix/improvement, but yeah let's let it simmer for a while before releasing
[12:31:22] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 8a3bf49 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py fix loc tst default_jog_anglular_speed JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8a3bf49
[13:59:21] <emcPT> To increase the number of allowed tools, cradek wrote that it should be increased the tool buffer in the nml file.
[13:59:41] <emcPT> Inside src/libnml
[14:00:33] <emcPT> there are a lot of files and grep for tool or table does not output results that I can find where the buffer is created or limited
[14:10:13] <emcPT> got it
[14:10:55] <zeeshan> i really need a bit of guidance on how to find what portions of the source code control what
[14:11:11] <zeeshan> maybe someone can guide me through one example? it'd help a lot!
[14:11:52] <zeeshan> https://github.com/LinuxCNC/linuxcnc
[14:12:02] <zeeshan> when i go here and i want to find the source code for the axis gui
[14:12:14] <zeeshan> do i just search? or is there some master file that lists the locations of files?
[14:14:28] <emcPT> src/emc/usr_intf/ is where the user interfaces are
[14:14:37] <zeeshan> howd you know that?
[14:14:58] <emcPT> usr_intf says it all
[14:15:27] <emcPT> and you have a folder named axis in it
[14:15:42] <zeeshan> okay so most of the source code will be under src
[14:17:04] <zeeshan> i see a folder under share/axis also
[14:17:06] <zeeshan> and some .tcl files
[14:17:10] <emcPT> src = source, so yes. But do not take my word as accurate. I am like a very small fish here.
[14:26:34] <KGB-linuxcnc> 03Jeff Epler 052.7 cbe6517 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cbe6517
[14:39:19] <zeeshan> axis-remote.py what is it used for?
[14:39:39] <zeeshan> i'm trying to track down why the shortcut ctrl+k stops working to clear the live plot
[14:43:29] <seb_kuzminsky> zeeshan: axis-remote is a little command-line utility that you can run to cause axis to perform some of its operations
[14:43:38] <seb_kuzminsky> think of it as a command-line remote-control for the axis-gui
[14:43:43] <zeeshan> ah
[14:44:14] <zeeshan> i see three plates where clear_live_plot command is called, axis-remote.py axis.py and axis.tcl (tcl setting up the key binding)
[14:44:19] <seb_kuzminsky> axis is spread across three or so files:
[14:44:21] <zeeshan> i have no clue why it stops working
[14:44:28] <seb_kuzminsky> src/emc/usr_intf/axis/scripts/axis.py
[14:44:36] <zeeshan> *plates = places
[14:45:01] <seb_kuzminsky> src/emc/usr_intf/axis/extensions/emcmodule.cc
[14:45:56] <seb_kuzminsky> share/axis/tcl/axis.tcl
[14:46:03] <seb_kuzminsky> most of the GUI is in axis.tcl
[14:46:35] <seb_kuzminsky> the interface to linuxcnc is in emcmodule.cc (that's actually a reusable python module for interacting with linuxcnc, several guis use it)
[14:46:45] <seb_kuzminsky> and axis.py is most of the smarts of axis
[14:46:54] <zeeshan> okay
[14:47:50] <seb_kuzminsky> you're right that axis.tcl connects the gui operation of "ctrl-k" to the clear_live_plot function
[14:48:07] <zeeshan> im going to try to use axis-remote and call clear_live_plot
[14:48:10] <zeeshan> and see if it works from there
[14:48:16] <zeeshan> manually clicking on the menu triggers it
[14:48:23] <seb_kuzminsky> and you can see that axis.py implements the function itself
[14:48:25] <zeeshan> the shortcut seems to stop working after running a couple diff programs
[14:48:50] <seb_kuzminsky> by calling the live_plotter.clear() method
[14:49:15] <zeeshan> yes
[14:49:25] <zeeshan> i see it on 2310
[14:49:28] <seb_kuzminsky> which version of linuxcnc are you on?
[14:49:57] <zeeshan> ill need to double check, i think 2.7.3
[14:50:48] <seb_kuzminsky> ok, i'm just starting to work on a new 2.7 release so if this is a real bug in 2.7 it'd be great to fix it first
[14:51:07] <seb_kuzminsky> i appreciate that you're tracking down exactly what works and what doesn't
[14:51:42] <zeeshan> the hard part is trying to replicate it
[14:51:46] <seb_kuzminsky> i assume you have a git clone that you're working with?
[14:51:48] <zeeshan> i was hoping the source would help :)
[14:51:56] <zeeshan> no im using apt-get pkg
[14:52:52] <seb_kuzminsky> do you mean "apt-get source linuxcnc"? or are you looking at the installed axis.py and axis.tcl scripts that came when you ran "apt-get install linuxcnc"?
[14:53:07] <zeeshan> im looking at the github source for the source
[14:53:17] <zeeshan> is that the latest one?
[14:53:34] <seb_kuzminsky> ah, i see, yes, the latest version is available on github
[14:57:56] <andypugh> This has me baffled:
http://codepad.org/oxmIyDYP
[14:58:30] <andypugh> It’s 100% consistent, it always gets all the joint0 and 2 of the joint4, but no others
[14:59:37] <andypugh> Perhaps I should try with a different “unlikely” character?
[14:59:57] <andypugh> (I am trying not to get false positives with hal signals)
[15:00:06] <seb_kuzminsky> andypugh: the %s substitution up in the definition of the subs dict happens when the dict is defined, not when it's evaluated, is that what you had in mind?
[15:00:20] <andypugh> Yes, that’s fine.
[15:00:56] <andypugh> (and even if it wasn’t, we would just see bad sunbsititutions, not missed ones, I think)
[15:04:20] <andypugh> I just changed to &temp and guess what? _different_ flaky behaviour!
[15:06:55] <seb_kuzminsky> andypugh: i just tried your program and input here (python 2.7.11) and it produced the expected output
[15:07:20] <andypugh> Interesting.
[15:09:05] <andypugh> race condition? consequence of being in a VM? Or maybe a consequence of being ipart of a bigger whole?
[15:09:40] <andypugh> Maybe the substitutions are being pipelined/paralelled?
[15:10:07] <andypugh> In my case the @temp subs happen as a second set after some previous subs.
[15:10:31] <andypugh> Let me give you a larger example
[15:10:54] <seb_kuzminsky> if it's a multithreaded program it could be a race, otherwise not
[15:11:13] <seb_kuzminsky> VMs "shouldn't" behave differently than bare-metal for this kind of thing
[15:11:42] <seb_kuzminsky> maybe the previous subs changed the string so the new subs dont match?
[15:12:06] <seb_kuzminsky> i'd be tempted to write the string to temporary files as it goes along the pipeline of subs and see that it's as expected after each step
[15:13:54] <andypugh> http://codepad.org/dnFSDUpX
[15:14:30] <andypugh> seb_kuzminsky: That’s a lot of strings to look at :-)
[15:15:54] <andypugh> I sptted a type, “identitykins”
[15:16:26] <seb_kuzminsky> heh
[15:16:32] <andypugh> (a problem with the sample code, not the real code)
[15:17:50] <andypugh> That mutable list of regexes would be a lot harder in C than it is in Python, wouldn’t it? :-)
[15:17:58] <zeeshan-mill> i lied im running 2.7.2
[15:23:24] <andypugh> seb_kuzminsky: Hang on, I think this is due to me getting mixed up. Looks like I failed to reset the input file at some point. (I have to copy the old config out of the backup before I run the conveter, looks like I forgot at some point)
[15:23:58] <seb_kuzminsky> aha
[15:24:17] <seb_kuzminsky> zeeshan-mill: what you're running on your mill and what you're looking at on github are probably different
[15:24:37] <seb_kuzminsky> zeeshan-mill: if you look at this page:
https://github.com/LinuxCNC/linuxcnc
[15:24:50] <seb_kuzminsky> up near the upper left it says "Branch: master"
[15:25:00] <seb_kuzminsky> so it's showing you the master branch
[15:25:24] <seb_kuzminsky> if you're running 2.7.2 i'd suggest first upgrading to the currentl 2.7 stable release, 2.7.4, and doing your debugging there
[15:25:56] <zeeshan-mill> yes im trying to dl 2.7.4
[15:26:17] <seb_kuzminsky> it should be a simple "sudo apt-get update; sudo apt-get dist-upgrade'
[15:27:17] <zeeshan-mill> master is the work in progress branch right?
[15:27:24] <zeeshan-mill> so its even more newer than 2.7.4
[15:27:36] <andypugh> seb_kuzminsky: No, whilst I did get a bit messed up, that wasnt the issue.
[15:28:03] <andypugh> master is not the most bleeding edge any more :-)
[15:29:03] <jepler_> master bleeds some, ja bleeds lots
[15:29:07] <andypugh> (In fact I am working on a styptic script for that bleeding edge)
[15:31:34] <seb_kuzminsky> zeeshan-mill: master is what will become the next stable version (2.8 or 3 or whatever)
[15:32:00] <seb_kuzminsky> zeeshan-mill: if there's a bug in 2.7.X, we need to fix it in the 27 branch and release a new stable release from that branch
[15:32:14] <seb_kuzminsky> then we merge 2.7 into master so master gets the fix too
[15:32:54] <zeeshan-mill> ah!
[15:45:03] <jepler_> emscripten is cool, too bad the debian package is unusable. I built my old anagram program (C++) to run fully in the browser, rather than going to the server for each search.
https://jepler.github.io/anagram/
[15:55:57] <andypugh> seb_kuzminsky: The writing of intermediate results certainly adds to the confusion :-)
[16:09:53] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 985ae61 06linuxcnc 10src/emc/motion/homing.c homing.c clr joints home flags for rehoming JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=985ae61
[16:11:19] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja14-abshome 2e78fe2 06linuxcnc 10(7 files in 4 dirs) homing: support HOME_ABSOLUTE_ENCODER JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2e78fe2
[16:12:03] <KGB-linuxcnc> 05dgarr/trt_doc_test 4381617 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4381617
[16:12:26] <KGB-linuxcnc> 05dgarr/trt_doc_test_v2 098d5fa 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=098d5fa
[16:20:57] <andypugh> seb_kuzminsky: I have the explanation, but not the answer. The dict is not enumerated in order. Adding a timestamp to the file names makes that clear:
http://codepad.org/Ifh0R2V8
[16:26:06] <andypugh> I don’t know why I assumed that the dict items were stored in sequence. I _could_ use a collections.OrderedDict object, but that seems overkill and requires Py2.7
[16:26:52] <andypugh> The answer is probably a second “phase 2’ dict.
[16:27:12] <jepler_> master branch requires 2.7 anyway
[16:27:39] <jepler_> you could also use a list-of-tuples or a tuple-of-tuples
[16:28:33] <pcw_home> Yay! absolute encoder support in JA14 Thanks dgarr
[16:29:15] <pcw_home> will 2.8 release be based on JAn?
[16:29:23] <jepler_> pcw_home: we hope so but no commitment
[16:29:49] <pcw_home> big change
[16:31:40] <jepler_> fwiw I don't see any reason that patch is tied to JA
[16:31:47] <jepler_> the patch would be different for master than for JA
[16:32:38] <jepler_> but I don't think it would be any more subtle
[16:35:24] <andypugh> jepler_: A “phase2” dict is a very minor mod.
[16:35:53] <jepler_> andypugh: OK then
[17:11:52] <KGB-linuxcnc> 03andypugh 05joints_axes14 f4f5b78 06linuxcnc 10scripts/update_ini update_ini: Add world-mode jog pins for trivial machines * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4f5b78
[17:20:29] <KGB-linuxcnc> 03andypugh 05joints_axes14 c6c315a 06linuxcnc 10scripts/update_ini update_ini: Choose placeholders less likely to collide * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c6c315a
[17:52:20] <seb_kuzminsky> jepler_: i think there are several things like that in ja (ie things that really should have gone into master instead)
[17:52:36] <seb_kuzminsky> that would make ja less daunting, as well as get earlier testing on those features
[18:27:34] <skunkworks> it is a conspiracy to get ja into master..
[19:04:28] <andypugh> Shhh!
[19:04:35] <pcw_home> Thats funny about 1/2 of the pdf docs at
http://linuxcnc.org/docs/2.7/pdf/ are in French
[19:06:17] <andypugh> I think that is to be expected. You can’t see it because the fields are too narrow, but there are _es and _fr versions of most of them.
[19:07:35] <pcw_home> except for example there is only one hal manual and its in French
[19:08:26] <pcw_home> same with the integrators manual
[19:12:52] <pcw_home> not that I have anything against french...
[19:14:09] <KGB-linuxcnc> 03andypugh 05joints_axes14 45ccdfb 06linuxcnc 10scripts/update_ini update_ini: Tidy up the handling of the coordinates= param * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=45ccdfb
[19:16:10] <andypugh> Ah, Oui, ça c’est vraiment un peau wierd
[19:32:00] <andypugh> I wonder if the problem is actually that the english versions failed to get made for some reason?
[19:32:18] <andypugh> Anyway, dinner beckons.
[20:56:53] <jepler_> "un peu". I think "une peau" would be "a skin"
[20:57:44] <seb_kuzminsky> all the pdf docs are current and freshly rebuilt from source
[20:57:56] <seb_kuzminsky> here's the output from the most recent rsync of the 2.7 docs to wlo: :
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/3366/steps/rsync-docs-to-www.linuxcnc.org/logs/stdio
[20:58:35] <seb_kuzminsky> our translations are handled super poorly at the moment - it's like they're a fork of the english docs
[20:59:21] <seb_kuzminsky> francis and i prototyped a saner way to manage translations, in the po4a branch
[21:01:32] <seb_kuzminsky> it shows promise