#linuxcnc-devel | Logs for 2015-07-23

[06:26:55] <jthornton> seb_kuzminsky, I took a quick look at po4a this morning and it is a bit of a learning curve involved at least for me
[07:08:17] <jthornton> is there a way to make sudo make setuid print out "run cd .. and . ./scripts/rip-environment" after it runs?
[08:10:08] <jepler> yes, though there'd be no way for it to *avoid* printing the message if it had already been run in that shell
[08:13:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/advise-user-rip-environment d7ef237 06linuxcnc 10src/Makefile build: advise user to use rip-environment * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d7ef237
[08:13:27] <jepler> ^^ for your consideration
[08:14:48] <jepler> the message will actually be printed at the end of a regular build if it is actually necessary (yay), and after 'sudo make setuid' whether or not it's necessary (boo)
[08:14:57] <jepler> afk
[10:00:28] <JT-Shop> yea!
[10:06:58] <seb_kuzminsky> jthornton: thanks for looking at it
[10:07:49] <seb_kuzminsky> i like it because it would get us away from the bad situation we have now, where the content (not just the language) of our translated docs can drift from each other over time
[10:17:49] <jthornton> I'll look at it again and try to understand how it works when I'm done with my current tasks
[10:18:06] <seb_kuzminsky> the overview is this:
[10:18:37] <seb_kuzminsky> there's one master .txt document (the english, because MURCA)
[10:18:52] <seb_kuzminsky> each translation language gets a .po file for each english .txt file
[10:19:10] <seb_kuzminsky> the .po file maps a paragraph in the english .txt to the translated paragraph in that language
[10:19:51] <seb_kuzminsky> the .po files are maintained by the translators just like the translations for the strings in the software
[10:20:24] <seb_kuzminsky> the build system makes translated .txt files from the english .txt and the translated .po using the po4a tools, automatically, at build time
[10:20:38] <seb_kuzminsky> the translated .txt files are then built by asciidoc into .html and .pdf just like now
[10:20:50] <jepler> our .po files are seriously unloved so it's hard to be bullish at the documentation being maintained too
[10:21:12] <seb_kuzminsky> are they more or less loved than our *_$LANG.txt files?
[10:21:42] <seb_kuzminsky> for any given level of love, .po > .txt imo
[10:21:55] <jepler> $ git log -1 origin/master -- fr.po
[10:21:58] <jepler> Date: Mon Jul 14 21:33:16 2014 +0200
[10:22:35] <seb_kuzminsky> the fr is by far in the best shape
[10:24:03] <cradek> with this system, if a translation is lagging, the fr docs show up-to-date english paragraphs, instead of very old translated french, or missing, paragraphs?
[10:25:01] <seb_kuzminsky> cradek: the public-facing french docs would show untranslated up-to-date english paragraphs, interspersed with translated french paragraphs where there's a valid translation
[10:25:43] <cradek> that is a big benefit
[10:26:25] <jthornton> jepler, this is neat "To set up the shell environment so that commands like 'linuxcnc' refer to this run-in-place directory, exceute . /home/john/emc-dev/scripts/rip-environment
[10:26:26] <cradek> then the translator doesn't have to constantly do the merging step
[10:26:42] <jthornton> that would make it easier for them
[10:27:17] <cradek> yeah, they only have to look at their one document
[10:27:36] <cradek> the manual merge seems like it would be really hard
[10:27:37] <seb_kuzminsky> cradek: there are po4a tools that will show the translator any paragraphs in the master language that are not translated, and let them edit their .po file right there
[10:28:23] <jthornton> cool
[10:29:08] <KGB-linuxcnc> 03John Thornton 052.7 bfd1d80 06linuxcnc 10docs/src/gui/gladevcp.txt Docs: add link * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bfd1d80
[10:29:31] <jthornton> gotta run
[10:31:41] <seb_kuzminsky> seeya
[10:32:56] <seb_kuzminsky> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=docs/README;h=4a23d05c289ba157c53079a0bfd3b20af224653d;hb=refs/heads/seb/master/po4a#l120
[10:33:25] <seb_kuzminsky> apparently seb from the past said to use poedit or gtranslator to edit the .po files
[10:42:56] <seb_kuzminsky> hm, some of our images show screenshots of localized applications, i wonder if po4a lets you specify alternate image names in the .po files
[11:23:09] <cradek> andypugh: is remotes/origin/andypugh/carousel_demo your new branch that shows the remap bug?
[11:23:31] <andypugh> Yes
[11:24:12] <andypugh> But note that the bug only appears on the second toolchange after restarting the config.
[11:24:29] <cradek> ok, building it to try now
[11:25:43] <seb_kuzminsky> ooh yay, po4a lets you localize image names
[11:25:44] <cradek> which config do I run?
[11:26:01] <cradek> I see graycode and index
[11:26:08] <seb_kuzminsky> cradek: i ran the index one
[11:26:12] <seb_kuzminsky> and it did the bad thing
[11:26:13] <andypugh> Either
[11:26:30] <cradek> oooh vismach is neat
[11:26:40] <andypugh> All that differs is the carousel indexing, the rest of the config is the same.
[11:26:52] <seb_kuzminsky> vismach is super neat
[11:26:56] <andypugh> It has a spinning and orienting spindle too :-)
[11:27:40] <cradek> it has dovetails!
[11:29:09] <cradek> emc/task/emctask.cc 389: interp_error: 9: duplicate O-word label - already defined in line 29: 'O200 IF [#<selected_tool> GT 0]'
[11:30:01] <andypugh> That’s the error. But only once. And I am pretty sure that there isn’t any such duplicate label.
[11:30:11] <cradek> here be dragons
[11:32:09] <cradek> 9 and 29 are supposed to be line numbers
[11:34:59] <cradek> but 9 is a blank line; 29 is correct for O200
[11:35:31] <andypugh> I did a quick and obvius test and got “emc/task/emctask.cc 389: interp_error: 9: duplicate O-word label - already defined in line 29: 'O202 IF [#<selected_tool> GT 0]’”
[11:35:54] <cradek> you just change 200 to 202?
[11:35:56] <cradek> changed
[11:35:59] <andypugh> Yes :-)
[11:36:05] <andypugh> Seemed worth trying
[11:36:08] <cradek> yeah
[11:39:00] <andypugh> If you comment out the O100 if and endif the problem seems to go away. (just about to repeat that).
[11:39:38] <andypugh> But the problem there is that it would cause a tool-crash in the case of a real machine, as it is trying to unload no tool into a full pocket.
[11:43:06] <cradek> filename = "/home/cradek/emc/configs/sim/axis/vismach/VMC_toolchange/toolchange.ngc", ... sequence_number = 9
[11:43:07] <skunkworks> get rid of the blank line?
[11:43:17] <cradek> the interp does think it's reading that file still, on line 9
[11:44:11] <andypugh> It’s not a line ending thing, surely?
[11:45:42] <cradek> wow, http://paste.ubuntu.com/11925877/
[11:46:29] <mozmck> optimized out?
[11:46:47] * seb_kuzminsky hands cradek a -g
[11:46:52] <cradek> 316 status = execute(); // special handling for mdi errors
[11:47:09] <seb_kuzminsky> heh
[11:47:13] <cradek> frame 3 is special
[11:49:09] <cradek> I'll try -O0
[11:49:46] <mozmck> maybe it needs volatile somewhere.
[11:50:10] <jepler> this is not interprocess or multithread stuff, so volatile is an unlikely theory
[11:52:14] <skunkworks_> it is probably just a bug.
[11:54:55] <mozmck> Ok. I don't think that was enough of a well-formed or informed statement to be honored with the title theory though :)
[11:58:22] <cradek> I can't figure out the right place for my -O0
[11:59:29] <seb_kuzminsky> cradek: src/Makefile's OPT, i think
[11:59:44] <seb_kuzminsky> instead of -Os
[12:00:02] <cradek> aha, I added it to DEBUG
[12:00:13] <cradek> maybe I ended up with both in some order
[12:00:31] <andypugh> I am glad you guys understand this stuff, as I am baffled even by your debugging steps
[12:00:48] <cradek> understand is a pretty strong accusation :-)
[12:01:40] <andypugh> Maybe I should do somethign that I do know how to do, like document the use_serial_numbers modparam, which I intrduced and didn’t docuement rather more than a year ago
[12:03:24] <jepler> how do I tell linuxcnc a tool is in the spindle ?
[12:03:45] <seb_kuzminsky> m61
[12:05:00] <cradek> http://paste.ubuntu.com/11925976/
[12:05:14] <cradek> not much of a block
[12:05:49] <cradek> all the flags are false (line 9 is a blank line)
[12:06:10] <cradek> o_name of toolchange#200 is interesting
[12:06:28] <cradek> I wonder if that's a name-number mapping and it's bogus
[12:08:34] <seb_kuzminsky> cradek: i'm surprised block->executing_remap is false, we're in M6
[12:08:46] <seb_kuzminsky> maybe it doesnt mean what it looks like it means
[12:09:34] <jepler> emc/task/emctask.cc 389: interp_error: 29: duplicate O-word label - already defined in line 9: 'O200 IF [#<selected_tool> GT 0]'
[12:09:40] <jepler> interestingly, in one run I got this
[12:09:47] <jepler> notice that 29 and 9 are transposed
[12:09:48] <cradek> ooh, the other direction
[12:10:07] <jepler> I *think* that's the one where I "loaded" a tool first with M61 Q1, then did T2 M6 / T1 M6 or something like that
[12:10:35] <jepler> so it has "something" to do with whether the O100 block executes
[12:11:19] <jepler> the call to Interp::control_find_oword can end up with sequence_number 8 or 28
[12:18:48] <cradek> sequence_number = 9, blocktext = "o200if[#<selected_tool>gt0]\000, remap_level = 1,
[12:19:42] <cradek> _setup just seems bogus. that isn't the text from line 9. _setup.block is correctly empty, though
[12:22:47] <jepler> I tried converting it to run as a standalone program but did not provoke the problem. the carousel seems to move and stuff. http://paste.ubuntu.com/11926036/
[12:22:53] <jepler> bbl
[12:23:29] <jepler> oh and I ran valgrind on task and nothing popped up
[12:23:40] <cradek> darn
[12:31:13] <andypugh> Oh for crying out loud, I can’t even manage simple stuff. How on earth have I managed to end up with a local git branch called “—track” ?
[12:31:31] <andypugh> For extra fun, it seems to be impossible to delete
[12:40:51] <KGB-linuxcnc> 03andypugh 052.6 fcc3b0c 06linuxcnc 10docs/man/man9/hostmot2.9 Smart-serial boards can have HAL pins identified by board serial numbers. Document this. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fcc3b0c
[15:12:34] <skunksleep> zlog
[17:16:32] <jepler> Tom_itx: (why port 81 anyway?)
[17:25:15] <Tom_itx> my isp blocks 80
[17:25:46] <Tom_itx> it's a home server
[18:02:01] <jepler> ah they're idiots
[18:06:26] <Tom_itx> true that
[18:38:32] <jepler> it's sure too bad idiots are in charge of home internet service
[18:43:17] <micges> idiots are in charge in way too many places
[19:14:23] <CaptHindsight> ATT started charging an $10 for each 50GB/mo over 150GB/mo, and it's as unstable as hell
[20:05:24] <KGB-linuxcnc> 03Chris Morley 052.7 b63e9d0 06linuxcnc 10src/emc/usr_intf/stepconf/Submakefile 03src/emc/usr_intf/stepconf/import_mach.py stepconf -add import-mach file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b63e9d0
[20:05:24] <KGB-linuxcnc> 03Chris Morley 052.7 4e72ba6 06linuxcnc 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/start.glade stepconf -add code to utilize mach convert program * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4e72ba6
[20:05:24] <KGB-linuxcnc> 03Chris Morley 052.7 8e307e8 06linuxcnc 10src/emc/usr_intf/stepconf/stepconf.py stepconf -add error highlighting to axis page * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8e307e8
[20:05:27] <KGB-linuxcnc> 03Chris Morley 052.7 56dc0a5 06linuxcnc 10docs/src/getting-started/images/stepconf-config.png 10docs/src/getting-started/stepconf.txt docs -update stepconf docs to include 'import mach' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=56dc0a5
[20:05:31] <KGB-linuxcnc> 03Chris Morley 052.7 9290054 06linuxcnc 10src/emc/usr_intf/stepconf/import_mach.py stepconf -fix up some errors in 'import_mach' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9290054
[21:00:20] <skunkworks> cool
[22:13:15] <KGB-linuxcnc> 05stepconf-mach-import 6eb283b 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6eb283b
[22:20:38] <mozmck> Are string values in the INI case sensitive?
[22:21:16] <mozmck> I see LINEAR_UNITS = inch, and TYPE = LINEAR
[22:21:31] <mozmck> can inch be INCH and LINEAR be linear?
[22:38:00] <kwallace> I think it depends on the code that checks a particular parameter. I seem to recall seeing "if 'inch' or 'INCH' then blah". Which I suppose doesn't cover "Inch". I would tend to grep the source for the parameter name to find the affecting code.
[22:38:17] <mozmck> yuck
[22:38:30] <mozmck> but thanks. I'll do some grepping
[22:40:01] <kwallace> Happy hunting.
[22:44:20] <kwallace> Fun Fact (Maybe). I Googled "largest cnc manufacturer" and got: http://www.statista.com/statistics/270234/largest-machine-tool-manufacturers-based-on-revenue/ . I was unaware of the top five.
[23:22:27] <seb_kuzminsky> mozmck: our IniFile library (in src/libnml/inifile) is case *sensitive*, so if you ask for "inch" it will *not* find "INCH" for you
[23:24:14] <mozmck> ok, thanks. I just took the lazy way and made my program use values I know work.
[23:24:29] <mozmck> Instead of digging through that stuff right now
[23:27:09] <seb_kuzminsky> i guess that's why all our ini files and ini file accesses use upper case, it's as good a standard as any
[23:27:59] <mozmck> The keys are upper, but values vary.
[23:28:26] <mozmck> LINEAR for TYPE, but inch for LINEAR_UNITS
[23:28:37] <mozmck> etc.
[23:31:00] <mozmck> It makes sense though that values could vary. Filenames need to be case sensitive, but other values don't.