#linuxcnc-devel | Logs for 2016-05-19

[11:23:11] <pcw_home> jepler:
[11:23:13] <pcw_home> looks like the sserial remote error bug with eth-packet-loss is fixed, thanks!
[11:23:14] <pcw_home> Hmm "packet-read-timeout" works on one machine and not another
[11:23:16] <pcw_home> (works on 1.6 GHz 4 core N3150, but not on core-duo 3.16 GHz)
[11:24:05] <pcw_home> I'll have to try on the G3258
[13:26:23] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja14-abshome 57e98e5 06linuxcnc 10src/emc/motion/homing.c homing:handle neg home_seq for absolute encoder JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=57e98e5
[15:56:53] <jepler> https://lwn.net/SubscriberLink/687600/e8299a301cb45470/ "Old projects and the free-software community" https://lwn.net/SubscriberLink/687736/fdee2604b16b8369/ "The open-source generation cap"
[15:56:57] <jepler> er, "gap"
[16:13:27] <mozmck> I like the idea of the company that had new hires walk through developing a system to handle all of the company's services.
[16:36:13] <cradek> those were both interesting reads
[17:01:02] <jepler> wow, this is unexpected: with the eth-packet-loss branch I have run it for seconds and seconds at 4kHz on a USB ethernet adapter
[17:01:20] <jepler> it gets occasional packet errors because of USB being a festering pile, but of course it recovers and goes on with life
[17:01:24] <jepler> sssshhhh don't tell anyone
[17:02:50] <skunkworks> uh - sorry - already posted that linuxcnc runs on usb...
[17:05:08] <jepler> mozmck: I remember being that kid who believed everything should be simple, and the world got AXIS for it so I guess that turned out OK
[17:05:52] <jepler> but now I can't handle it when kids show up and say everything should be easy
[17:06:00] <mozmck> :-) simple is not bad, but not everything can be simple I don't believe.
[17:08:11] <mozmck> not just easy, but should be re-written in javascript and be a cloud-based web app running from their smart phone.
[17:52:43] <malcom2073> jepler: you're getting old :)
[18:01:54] <malcom2073> Hehe, they call out sourceforge mailing lists for being "old" :-P
[18:38:40] <skunkworks> didn't someone create a hal component that saved/loaded a value?
[18:43:45] <skunkworks> ah -
[18:43:47] <skunkworks> http://thread.gmane.org/gmane.linux.distributions.emc.user/55402/focus=55405
[18:45:16] <skunkworks> ah - no
[18:49:35] <skunkworks> ah - http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ContributedComponents#Parameter_Saver
[18:49:37] <skunkworks> maybe
[20:22:36] <mozmck> interesting piece: https://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/
[20:23:58] <jepler> > Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times
[20:24:04] <jepler> wow absolutely disagree
[20:24:22] <jepler> having all the history local enables a lot of things
[20:24:44] <mozmck> yeah, I don't agree with that point, but he has some good points.
[20:25:48] <jepler> and obviously I haven't worked on a project that has a history with many many binary blobs, but yeah you should not use vanilla git for that.
[20:26:16] <mozmck> I'm probably going to switch to svn for my kicad projects at some point. We really need the ability to have a "checkout" that locks the project or files.
[20:29:38] <mozmck> But I like git for source code projects.
[21:34:27] <seb_kuzminsky> i'd always pick git for all project tracking things that look like source code
[21:35:47] <seb_kuzminsky> jepler: thanks for looking at zultron's bug report, is it in the gui or in emcStat do you think?
[21:36:10] <seb_kuzminsky> oh, i see his comments, look like at least part of the problem is in interp
[21:38:26] <jepler> if you have "things that can't be diffed or merged, or where even an inconsequential change changes most of the bits", you need to work on that problem before you use a standard VCS to store revisions of the file over time.
[21:39:56] <jepler> seb_kuzminsky: I don't know where the problem lies, but it's clearly one of these things where we have a task state, an interpreter state, and maybe a third state related to read ahead
[21:40:37] <andypugh> “If we were doing it again, we wouldn;t start here”
[22:10:38] <jepler> and therein lies the lure of starting over
[22:13:12] <seb_kuzminsky> axis doesnt handle high-dpi screens well - the text is illegibly small
[22:13:52] <cradek> ahh, someone should get me one to "test" with
[22:14:05] <cradek> (I'm surprised it doesn't use the system dpi setting)
[22:14:18] <cradek> are you sure your X dpi is configured right?
[22:14:21] <seb_kuzminsky> i'd show you a screenshot, but it wouldn't do the experience justice
[22:14:35] <seb_kuzminsky> everything else looks right
[22:14:50] <cradek> that doesn't really answer my question...
[22:15:00] <cradek> I bet 7 generations of CADTs have invented their own way to manage dpi
[22:15:17] <seb_kuzminsky> i see nothing about dpi in xdpyinfo
[22:15:20] <cradek> so if all your apps are a toolkit from generation CADT6...
[22:15:38] <seb_kuzminsky> oh, no, there it is
[22:15:48] <seb_kuzminsky> resolution: 96x96 dots per inch
[22:15:52] <seb_kuzminsky> that doesnt seem right
[22:15:59] <seb_kuzminsky> dimensions: 3840x2160 pixels (1016x571 millimeters)
[22:16:32] <seb_kuzminsky> should be more like 250 dpi
[22:16:35] <cradek> it's *possible* fixing that will fix it
[22:16:44] <seb_kuzminsky> i'll look into it
[22:16:47] <cradek> yeah try it first anyway
[22:16:51] <seb_kuzminsky> sorry i accused axis
[22:17:07] <cradek> oh it'll probably still look weird in some way IF the text changes size
[22:17:16] <cradek> the icons sure won't scale
[22:19:50] <cradek> I still use rcs where I'm working alone and my VC problems are simple and single-file based
[22:20:17] <cradek> using git for my server's firewall config file would be much worse than rcs
[22:20:49] <cradek> same for something like .procmailrc or .bashrc
[22:21:16] <seb_kuzminsky> ooh i love having my .bashrc in git
[22:21:25] <cradek> what would you do, have your whole home directory be a git repo and the history for those two files that have nothing to do with one another be mingled together?
[22:21:31] <seb_kuzminsky> first thing i do on a new machine is clone my dot-files.git
[22:21:40] <cradek> huh
[22:21:53] <cradek> so your ~ is a git checkout of dot-files.git?
[22:21:59] <seb_kuzminsky> dot-files.git includes a script named install-symlinks, that links dot-files/.bashrc to $HOME (etc)
[22:22:11] <seb_kuzminsky> no, $HOME is just a regular directory
[22:22:12] <cradek> oh, that's sounding stupid now, sorry :-)
[22:22:57] <seb_kuzminsky> but it's nice having my bashrc, screenrc, vimrc, gitconfig, etc consistent across all my machines
[22:23:09] <cradek> that's the least bad poison though, I bet, compared to ~ being git and almost all the files showing up stupidly in git status etc
[22:23:32] <seb_kuzminsky> yeah managing that .gitignore would be a pain
[22:23:42] <cradek> you'd need .gitdontignore
[22:23:52] <seb_kuzminsky> *
[22:24:02] <seb_kuzminsky> !.bashrc
[22:24:03] <seb_kuzminsky> etc
[22:24:19] <cradek> does that work?
[22:24:25] <seb_kuzminsky> yeah
[22:24:27] <seb_kuzminsky> :-)
[22:24:30] <cradek> that's pretty cool
[22:24:41] <seb_kuzminsky> but i prefer the symlink way
[22:25:09] <cradek> but it still feels like a file-based system would be better, because if the files are independent, everything about git works wrong
[22:25:44] <seb_kuzminsky> it's version tracking for your working environment, not for several unrelated files
[22:26:11] <seb_kuzminsky> and it's crucially got to have good clone-across-the-network and sync multiple machines together
[22:26:37] <cradek> you're right
[22:27:15] <cradek> do you have a bunch of portability hackery to support different versions of dotfile-using things?
[22:27:48] <seb_kuzminsky> just in my .vimrc, everything else is a single file for all versions of the things they configure
[22:27:52] <cradek> I know I've had trouble with .muttrc, .screenrc, especially .emacs when there is version skew (could probably think of more if I try for a minute)
[22:28:29] <cradek> interesting
[22:28:44] <seb_kuzminsky> err, no, i think i took that out when i realized all my machines had vim 7.something
[22:28:48] <cradek> (emacs is just terrible for that and you probably just don't use it)
[22:28:55] <seb_kuzminsky> ... yeah
[22:29:16] <seb_kuzminsky> isnt the config file a lisp script? so what's the problem? :-P
[22:29:24] <cradek> CADT
[22:30:15] <seb_kuzminsky> certificate of ancestral domain title?
[22:32:15] <cradek> https://www.jwz.org/doc/cadt.html
[22:32:28] <cradek> jeez I hate to quote jwz nowadays
[22:32:43] <cradek> I guess one can be right about some things and wrong about others
[22:33:24] <seb_kuzminsky> i see
[22:33:43] <seb_kuzminsky> i dont know if blaming it on teenagers is accurate here
[22:33:59] <seb_kuzminsky> CAD-Old-Hackers
[22:34:08] <cradek> probably
[22:34:58] <cradek> yeah it's not like they have any young people doing unnecessary rewrites
[22:35:03] <seb_kuzminsky> i certainly see that in myself - usually at the end of the day i want to do something fun and relaxing, and squishing bugs that dont bite me doesn't always satisfy
[22:35:05] <cradek> just churn
[22:48:05] <cradek> I think I want that dpi, but in reality it'd just make my old favorite 75ish dpi fonts unreadable, and I'd be sad about that