Back
[05:24:23] <jthornton> there seems to be some core problems with LinuxMint Xfce menus
http://forums.linuxmint.com/viewtopic.php?f=57&t=172142
[05:30:04] <jthornton> replacing the xfce-applications.menu restored the menu and fixed the missing CNC menu.
[07:40:49] <jepler> jthornton: good sleuthing. too bad it's apparently a problem the mint folks have declined to fix for "three or four releases" :-/
[07:41:47] <jepler> bmwiedemann: incidentally, it seems that someone reported this problem a year ago and we didn't get it patched then :-/
http://psha.org.ru/irc/%23emc-devel/2014-10-21.html
[07:43:50] <KGB-linuxcnc> 03Bernhard M. Wiedemann 052.6 b3d51db 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc interp: it's nonsense to take a boost::cref(this) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b3d51db
[07:46:18] <KGB-linuxcnc> 03Jeff Epler 05master c3ac4f5 06linuxcnc 10src/libnml/inifile/inifile.cc 10src/libnml/inifile/inifile.hh inifile: detect spurious trailing text on numbers in inifiles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c3ac4f5
[07:46:18] <KGB-linuxcnc> 03Jeff Epler 05master f080314 06linuxcnc 10src/emc/rs274ngc/interp_base.hh interp: explicitly make Interp{,Base} noncopyable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f080314
[07:46:18] <KGB-linuxcnc> 03Jeff Epler 052.7 4ec9418 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4ec9418
[07:46:21] <KGB-linuxcnc> 03Jeff Epler 05master b10597e 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b10597e
[07:46:35] <bmwiedemann> jepler: yep, sometimes things get forgotten. good thing current compilers catch it these days
[07:48:14] <jepler> bmwiedemann: thank you for your contribution!
[07:48:20] <jepler> afk
[10:09:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 9d470d4 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt docs: minor update to Updating docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d470d4
[10:09:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 91f4495 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt docs: note new ini variable strictness in Updating/Config Changes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=91f4495
[10:59:37] <seb_kuzminsky> mozmck: one of the responsibilities of the release manager is to watch the to-be-released branch for commits like c3ac4f5b, and update the Updating document, either by poking the author or by making commits like 91f44950 yourself
[11:00:04] <jepler> or get after a developer like me for not doing it himself
[11:02:24] <jepler> seb_kuzminsky: .. it turns out that if you tried to read that same inifile entry via Python (which doesn't present the 'typed' interface to reading inifiles), you would get an error on the old line MAX_VELOCITY = 7.5 #
[11:35:23] <seb_kuzminsky> jepler: three cheers for our newfound consistency!
[11:36:44] <seb_kuzminsky> back in the way-back-when, in the 3.4-9-rtai days, i had this really vivid daydream about forking myself and having the child process leave the linuxcnc project and go join the rtai project, and i'm reminded of that now...
[11:38:40] <jepler> after a transporter accident, seb_kuzminsky is split into seb_good and seb_evil. One of them works on LinuxCNC and the other on RTAI. Which is the good one, and which one is evil?
[11:40:35] <skunkworks> could they both be evil?
[11:40:44] <jepler> oooh now there's a twist
[11:41:07] <seb_kuzminsky> FUSION OF BRUNDLEFLY AND TELEPORTER POD SUCCESSFUL
[11:43:31] <archivist> reminds me of the song, he is the best forking forker in the whole forking land
[11:52:05] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-4.1 43083d0 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ioport.c hm2: fix uninitialized variable warning in ioport * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=43083d0
[11:52:05] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-4.1 10fa788 06linuxcnc 10src/rtapi/rtai_rtapi.c rtapi: teach rtai_rtapi about renamed RTAI constant * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=10fa788
[11:52:37] <seb_kuzminsky> linuxcnc master now builds under rtai vulcano (which i think is the pre-release for the next stable version)
[11:53:01] <seb_kuzminsky> err, not master, the rtai-4.1 branch
[11:53:27] <seb_kuzminsky> but it does not run yet, because rtai 4.1 does not correctly handle its in-kernel math library
[12:00:00] <mozmck> seb - thanks for the note
[12:01:18] <skunkworks> didn't memory leak figure some of that out?
[12:04:04] <jepler> yes, he has a fork of rtai and he spent a lot of time working on math
[12:05:38] <seb_kuzminsky> i saw that
[12:06:27] <jepler> seb_kuzminsky: which variable was reported as uninitialized? (re your recent commit)
[12:06:48] <jepler> this_instance?
[12:07:07] <seb_kuzminsky> i just asked paolo (of rtai.org) if he'd consider a patch that adds in-tree math source to rtai, which is what memleak did, right?
[12:07:24] <jepler> I would hate to say I had a firm grasp of all that memleak did
[12:07:48] <seb_kuzminsky> jepler: the uninitialized variable was called "m" or "n" before that commit, and "num_instances" or "this_instance" after the commit
[12:08:15] <seb_kuzminsky> jepler: yeah, same here, but it sure seems like a saner approach than what upstream rtai is doing right now
[12:08:29] <seb_kuzminsky> if we got a couple more eyeballs on the implementation something good might come out of it
[12:09:27] <jepler> rtai used to *have* a math library in the tree
[12:10:15] <jepler> some of the files were not distributable. I'm not sure whether that spurred the removal of the whole thing from rtai or not
[12:10:32] <seb_kuzminsky> i dont remember cvs well enough to tell how they got where they are today :-(
[12:27:20] <linuxcnc-build> build #1315 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1315 blamelist: Bernhard M. Wiedemann <bwiedemann@suse.de>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[12:28:43] <seb_kuzminsky> that's a dropped mdi bug
[12:28:53] <seb_kuzminsky> in master :-(
[12:34:26] <linuxcnc-build> build #1805 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1805 blamelist: Bernhard M. Wiedemann <bwiedemann@suse.de>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[12:34:51] <linuxcnc-build> build #1996 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1996 blamelist: Bernhard M. Wiedemann <bwiedemann@suse.de>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[13:17:50] <linuxcnc-build> build #3658 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3658 blamelist: Bernhard M. Wiedemann <bwiedemann@suse.de>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[14:47:38] <cradek> the auto filleting that G0G53Z148 wants would be cool
[14:48:13] <cradek> I think my boss8 had that, but I never tried it
[14:50:18] <cradek> the math would only be medium-hard
[14:50:55] <jepler> G0 X0Y0 / G1X1 / G1 Y1 R.5
[14:50:57] <cradek> calculating that fillet arc is exactly what cutter comp already does when going around an outside corner
[14:51:06] <jepler> one thing I immediately see is that you can't issue the move for G1X1 until you examine the next line
[14:51:15] <cradek> yep that's right
[14:51:16] <jepler> because it might go only to X.5 due to the fillet
[14:51:19] <cradek> yep
[14:51:47] <cradek> heck it might not be able to go at all
[14:51:48] <jepler> and I assume G1 Y1 R1.5 as the third line would just be rejected, the fillet cannot be made that large
[14:52:10] <cradek> yep we're thinking about it the same
[14:52:43] <cradek> you might put the R on the first move?
[14:52:54] <jepler> what would that mean?
[14:52:57] <cradek> at least then you can tell when you have to queue it
[14:53:05] <cradek> at the end of this move the fillet will be
[14:53:28] <jepler> I wouldn't write it that way unless you found one other dialect that also had
[14:53:28] <cradek> I meant your example would be instead: G0 X0Y0 / G1X1 R.5 / G1 Y1
[14:53:39] <cradek> did you find documentation?
[14:53:42] <jepler> no
[14:53:51] <cradek> I don't know which way (they) do it
[14:54:34] <jepler> here's a reference card with G22/G23 "circular interpolation, fillet input CW / CCW"
[14:55:00] <cradek> yeah it'd be too bad that in our dialect you couldn't use R for filleting between arcs
[14:56:41] <jepler> not the same thing, but
http://www.marketotomasyon.com/UserFiles/File/LNC_Manual/T600H/LNCLATHE_Programming_Manual_V04.00.003_ENG.pdf starting on page 21 is interesting
[14:56:50] <jepler> pdf page 21, page number 15
[14:56:53] <jepler> "Geometric input function"
[14:57:32] <jepler> e.g., you can program N01 G01 A(a1) / N02 G01 X(x3) Z(z3) A(z2)
[14:57:49] <jepler> so that your first move is at angle A1, your second move is at angle A2, and your endpoint is x3,z3
[14:58:00] <jepler> and it figures out what intermediate point satisfies the given constraints
[14:58:06] <cradek> jeez
[14:59:25] <jepler> in type 2 you can champfer or fillet, which I think is why I ended up finding this reference in my googling
[15:00:20] <jepler> anyway, I notice that in this dialect the chamer/fillet number is on the first line
[15:00:58] <cradek> I can sure see why you'd want that
[15:01:01] <jepler> yeah
[15:01:11] <jepler> then you can immediately output the right move
[15:01:23] <cradek> no you can't
[15:01:31] <cradek> what do you mean?
[15:02:03] <jepler> I wouldn't be surprised if my intuition were wrong
[15:02:05] <cradek> you have to read at least one, possibly several, moves ahead to figure it out
[15:02:20] <jepler> if you have G0 X0Y0 / G1 X1 R.5, can't you just go to X.5 ?
[15:02:29] <cradek> nope
[15:02:47] <cradek> only if you happen to later make a right angle is that correct
[15:03:24] <jepler> OK
[15:03:25] <cradek> g0x0y0z0 / g1x1r.5 / z1 / z0 / x2 / ;haha
[15:04:17] <cradek> oh I wonder if it would fillet in XZ in my silly example
[15:04:26] <jepler> G0 X0Y0 / G1 X1 R.5 / G1 X0 Y.001
[15:04:33] <jepler> was the example I was getting around to visualizing
[15:04:41] <jepler> cradek: depends if G17 is active
[15:04:47] <jepler> in my mental implementation
[15:05:03] <cradek> ooh, interesting mental implementation
[15:05:07] <cradek> I didn't think of that
[15:05:28] <cradek> in your last example it would have to make more than a semicircle?
[15:05:57] <jepler> I think my last example has to be rejected
[15:06:18] <cradek> why?
[15:06:42] <cradek> I guess the final direction of the second line would change
[15:06:53] <cradek> you probably don't want that to happen
[15:07:04] <jepler> right
[15:07:10] <jepler> you want the arc tangent to both the original lines
[15:07:18] <cradek> yeah I agree
[15:07:50] <cradek> so for those two lines, only a very very small R would work
[15:07:56] <jepler> otherwise isn't the problem underconstrained?
[15:08:12] <cradek> because there are two possible arcs?
[15:08:26] <jepler> there are a lot of circles of radius R that touch both lines
[15:08:58] <cradek> I'm not picturing that
[15:12:23] <jepler> https://emergent.unpythonic.net/files/sandbox/circles-touching-lines.svg
[15:12:37] <jepler> all those same-radius circles touch both lines
[15:12:46] <jepler> but the blue one is close to what you mean when you talk about doing a fillet
[15:12:54] <jepler> and it's the tangency requirement that limits you to just that one
[15:13:08] <cradek> oh I misunderstood "touch"
[15:13:47] <jepler> ah you understood "touch" to be tangency, not having an intersection at all
[15:13:54] <cradek> yeah
[15:14:42] <cradek> heh x0 / x1r.5 / x2 could give one of two weird full circles and satisfy tangency with both
[15:15:00] <cradek> trying to think of any other degenerate cases
[15:15:25] <jepler> I think in that case you want the zero-included-angle arc
[15:15:33] <cradek> yeah surely
[15:15:36] <jepler> is there a legitimate case where you want more than a half arc?
[15:15:45] <cradek> not that I've thought of yet
[15:16:03] <cradek> with the requirement that the afterward-line still points in the original direction
[15:16:49] <jepler> g0 x0y0 / g1x1r1 / g1y1 -> you just get an arc, right?
[15:17:36] <cradek> either that, or an error that says you ate up the lines
[18:08:02] <jepler> MESSAGE_TEXT = This is a <span background="#ff0000" foreground="#ffffff">info message</span> test
[18:15:15] <KGB-linuxcnc> 03Jeff Epler 05master e79f435 06linuxcnc 10configs/sim/axis/remap/getting-started/demo.ini 10configs/sim/axis/remap/iocontrol-removed/iocontrol-removed.ini 10configs/sim/axis/remap/manual-toolchange-with-tool-length-switch/manualtoolchange.ini 10configs/sim/axis/remap/stop-lookahead/demo.ini configs: Fix instances of # that were intended to be comments * 14http://git.linuxcnc.org/?p=linuxcnc.gi
[18:50:59] <KimK_laptop> Maybe the above can serve as an error report for our infrastructure experts? It appears as though the gitweb link above was truncated into uselessness because the number of affected files created a string longer than some anticipated maximum?
[18:55:54] <KimK_laptop> gedit says 382 characters above, counting everything, if that helps.
[18:57:49] <KimK_laptop> Jeff Epler master e79f435 linuxcnc configs/sim/axis/remap/getting-started/demo.ini configs/sim/axis/remap/iocontrol-removed/iocontrol-removed.ini configs/sim/axis/remap/manual-toolchange-with-tool-length-switch/manualtoolchange.ini configs/sim/axis/remap/stop-lookahead/demo.ini configs: Fix instances of # that were intended to be comments *
http://git.linuxcnc.org/?p=linuxcnc.giJeff Epler master e79f435 linuxcnc configs/sim/axi
[18:57:49] <KimK_laptop> s/remap/getting-started/demo.ini configs/sim/axis/remap/iocontrol-removed/iocontrol-removed.ini configs/sim/axis/remap/manual-toolchange-with-tool-length-switch/manualtoolchange.ini configs/sim/axis/remap/stop-lookahead/demo.ini configs: Fix instances of # that were intended to be comments *
http://git.linuxcnc.org/?p=linuxcnc.gi
[19:01:06] <KimK_laptop> Trying to send the string twice, gedit says 432 characters, then 332 characters. OK, I'm done playing with it. Sorry for the flood.
[19:23:06] <jepler> irc has a fairly low maximum line limit, and it looks like kgb exceeded it. It's probably not a high priority to fix it, though
[19:45:42] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_updates abca2f1 06linuxcnc 10src/emc/motion/command.c 10src/emc/motion/control.c motion: make sure jogging planners are disabled * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=abca2f1
[19:45:43] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_updates 8af4813 06linuxcnc 10docs/man/man1/halui.1 10docs/src/getting-started/updating-linuxcnc.txt 10src/emc/usr_intf/halui.cc halui support for axis jogging (world,teleop) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8af4813
[19:45:43] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_updates bc38ab3 06linuxcnc 10configs/sim/axis/README 10configs/sim/axis/ldelta_demo.ini 10configs/sim/axis/ldelta_demo.txt ldelta_demo.ini consolidate sim_pin testers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc38ab3
[19:46:54] <jepler> huh and ugh -- looks like the "opengl window floats on top of everything" bug is *STILL* not fixed for some graphics drivers.
https://forum.linuxcnc.org/media/kunena/attachments/18722/mint_with_deb.png stupid stupid stupid
[20:07:48] <seb_kuzminsky> jepler: thanks for paying attention to the #ff0000, i think i would have missed that
[20:07:56] <seb_kuzminsky> this is why we pay you the big bucks
[20:19:32] <jepler> yeah I was told the check was in the mail
[20:20:01] <seb_kuzminsky> you misheard
[20:20:11] <seb_kuzminsky> the czech is in the male
[21:05:43] <jepler> I was commenting the other day about my poor reading comprehension after all
[21:14:46] <cradek> I wouldn't necessarily trust "Oracle VM VirtualBox" to not be the problem in this case...
[21:15:07] <jepler> there's nothing oracle can't poop on, that's true
[21:15:53] <cradek> sweet, dgarr is still working on jogging
[21:16:52] <cradek> wonder if it's time for me to try mint with the gnome2 successor again
[21:17:05] <cradek> last time I tried it (the one based on precise) they had really screwed up the packaging
[21:17:46] <cradek> they installed straight (or modified but wrong?) debian packages and then overwrote some of the files, so when you updated you got a huge mess
[21:18:04] <cradek> it was some seriously amateur hackery
[21:18:16] <cradek> so I noped right out of there
[21:22:39] <seb_kuzminsky> yeah that sounds like a nope
[21:25:43] <seb_kuzminsky> i'm really happy with jessie
[21:26:28] <cradek> I expect they have improved (although I haven't looked)
[21:26:45] <jepler> stuff like "the file manager really works poorly" just doesn't matter to me. It sure does to people who use computers in a different way, though.
[21:26:58] <cradek> I'm happy enough with wheezy but I feel the frustration of xfce (and everything) being worse than gnome2 in 2010
[21:27:02] <cradek> yeah totally
[21:28:09] <cradek> some stuff like printing, that just worked in lucid, was more of a pain for me in wheezy too
[21:28:33] <cradek> but I can usually beat on stuff like that until it works
[21:29:00] <cradek> nis/nfs is better in wheezy than lucid (upstart was newish)
[21:29:13] <cradek> the stupid graphical console being gone is nice
[21:29:17] <jepler> huh odd message from nopaste about a problem GETing "www.hugedomains.example.com" (without .example) when I ran it just now on this mint vm
[21:30:06] <jepler> anyway, debsums' list of files that don't match packaging:
http://paste.debian.net/335462 on mint 17.2 xfce
[21:30:07] <cradek> iiuc, mint has amazon spyware by default too
[21:30:15] <cradek> so forget it
[21:30:50] <cradek> /etc/grub.d/10_linux
[21:30:59] <cradek> I remember now that some of the breakage was grub, like this
[21:31:10] <cradek> so yeah they maybe haven't fixed it
[21:31:25] <cradek> thanks for checking and verifying my nope
[21:33:14] <jepler> there are some indications that maybe there is amazon support in the media player and as a search plugin in firefox, but neither seems to be a default
[21:33:26] <jepler> godawful mint-themed yahoo search page by default
[21:33:39] <jepler> but yahoo is in the sack of shit that mozilla is installing on computers this year, soooo
[21:34:02] <jepler> er, no, default search is yahoo but home page embeds google
[21:36:48] <jepler> anyway, I'll stick with debian for the time being too
[21:37:17] <jepler> debian seems to be alienating its own developers at an alarming rate, though. every month or two somebody loudly resigns from being a debian developer or debian maintainer
[21:38:15] <cradek> siiigh
[22:03:11] <seb_kuzminsky> its the open source meat grinder
[22:06:30] <mozmck> I've had less problems with mint than other distros overall.
[22:06:50] <mozmck> cradek: I've not seen any sign of the amazon stuff in mint - where did you see that?
[22:07:58] <mozmck> imo, google is _far_ worse than amazon anyhow :-/
[22:29:33] <jepler> mozmck: in 2012, Ubuntu added Amazon ads to something called "Dashboard", or at least considered it. see e.g.,
https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-amazon-ads-and-data-leaks
[22:29:43] <jepler> yes, apparently it was in the 12.10 release
[22:30:00] <jepler> but this is a component of Unity and as such may not be in any Mint version
[22:30:26] <jepler> http://superuser.com/questions/619242/does-linux-mint-have-same-advertisement-features-like-ubuntu
[22:30:50] <jepler> I can't understand if this single answer is saying "yes" or "no" :-/
[23:02:01] <seb_kuzminsky> d'aww, gene noticed the Esc fix i did :-)
[23:16:34] <seb_kuzminsky> err, or maybe he's talking about something else
