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

[09:28:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 70ed0b5 06linuxcnc 10debian/control.in packaging: depend on mesa-utils * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=70ed0b5
[09:30:13] <seb_kuzminsky> that fixes the latency-histogram/glxgears issue mozmck reported
[09:30:29] <seb_kuzminsky> i dont know what to do about the latency-plot/blt issue pcw_home reported
[09:30:55] <seb_kuzminsky> as noted it works on lucid, and we don't officially support 14.04 Trusty (yet)
[09:31:00] <seb_kuzminsky> also it works on wheezy
[09:32:39] <seb_kuzminsky> ooh, i just noticed i have a trusty machine lying around, i'll test it tonight
[09:50:46] <cradek> looks like the jessie release is coming this weekend
[09:51:13] <jepler> woo-hoo
[09:51:21] <jepler> too bad no -rt kernel is in jessie :-/
[09:51:41] <cradek> that's really unfortunate
[09:52:42] <jepler> yeah
[09:52:52] <jepler> they had their own reasons for settling on 3.16, but there's no rt patch for e.16.
[09:52:55] <jepler> 3.16.
[09:54:03] <jepler> and debian unstable has gone up to 4.0
[09:54:07] <jepler> er, experimental
[09:54:18] <jepler> so unfortunately no debian love for 3.18 which is the current latest and greatest rt
[09:54:49] <jepler> I know a lot of you have built it individually, doing the debian packaging and making sure it runs on a variety of systems is always the other 90% of the work
[09:55:01] <jepler> well, maybe not a lot, but I think at least pcw and mozmck
[10:19:41] <pcw_home> The default 3.18 config seems to run on most everything I've tested it with
[10:22:39] <pcw_home> I think skunkworks found tha Atheros wireless did not work on his laptop but thats fixble in the config
[10:22:40] <pcw_home> (default had Atheros wirelss disabled) The broadcom worelaa in the HP Stream mini doent work either
[10:22:42] <pcw_home> but its problematic with stock kernels and need futzing
[10:23:08] <pcw_home> s/worelaa/wireless/
[10:24:12] <seb_kuzminsky> its looking like the gsoc student who was proposing to work on -rt kernel packaging isnt going to work out
[10:24:36] <seb_kuzminsky> so y'all'll have to live with my flaky packages again
[10:26:59] <pcw_home> Your flaky packages have been used by most linuxcnc'ers with great success :-)
[11:25:29] <seb_kuzminsky> ubuntu just announced they're switching from .debs to their new 'snappy' packaging system
[11:26:45] <cradek> is that the one they invented for phones, and its primary feature is it doesn't do dependencies?
[11:28:14] <cradek> er no maybe that was their previous one called "click"?
[11:30:15] <cradek> http://askubuntu.com/questions/583076/difference-between-snappy-and-click
[11:30:21] <cradek> no idea, and who cares
[11:34:10] <cradek> heh now let's play "earnest or troll": http://www.markshuttleworth.com/archives/1434#comment-406146
[11:40:12] <archivist> I wonder what they are smoking, I cannot see breakages not happening still
[11:40:19] <seb_kuzminsky> who knows what the future will look like
[11:40:43] <seb_kuzminsky> the new containerized stacked filesystem trick is pretty neat actually
[11:40:44] <archivist> consumer grade mobile trash it seems
[12:11:31] <mozmck> pcw_home: I'll like your config for 3.18.11-rt7 if you don't mind.
[12:12:51] <mozmck> I've built a 32 bit kernel now, and latency-histogram gives nearly identical looking results to a 64 bit install.
[12:14:24] <mozmck> I want to try yours and see how it performs on my machine. If it's about the same, my kernel may be good for wider testing if anyone is interested. I'm building *buntu 14.04 .debs the ubuntu way with the ubuntu config modified for rt
[12:56:18] <PCW> freeby.mesanet.com/rtconfig
[14:12:20] <andypugh> I have found a buglet in comp :-)
[14:13:18] <andypugh> modparam dummy config “my special modparam does stuff” works OK to document a modparam, but _only_ if the component DOC is on a single line.
[14:14:55] <Tom_itx> is that a baby bug?
[14:16:07] <andypugh> The reason is here: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/utils/halcompile.g;h=dfbca31091716d23e4370ce31ae72c9ced92ffb0;hb=HEAD#l765
[14:17:01] <andypugh> the “rest” string is non-blank at that point if there is a multi-line component description. I think that this also prevents documentation of a few other things.
[14:21:11] <jepler> http://pastie.org/10110247 I must misunderstand the problem statement, because both lines of my documentation are shown
[14:24:41] <andypugh> The problem is that a multi-line component description kills the wole SYNOPSIS section
[14:25:21] <andypugh> (ie component mycomponent “””this component is so very special that it requires description over several lines”””;
[14:33:06] <andypugh> http://pastie.org/10110279
[14:34:24] <jepler> OK I see what you mean now
[14:34:25] <jepler> don't do that
[14:34:50] <andypugh> The answer does seem to be terse in the description.
[14:35:31] <jepler> I admit I'm not sure why having newlines in the docstring of component changes what happens under synopsis
[14:37:05] <jepler> I get something different than you do though
[14:37:12] <jepler> NAME
[14:37:13] <jepler> whatev - by putting a newline here
[14:37:13] <jepler> SYNOPSIS
[14:37:13] <jepler> I shoot myself in the foot
[14:37:18] <andypugh> I am using an old version in a UI
[14:37:30] <jepler> so it looks like the feature is supposed to be that a multiline documentation of component *replaces* what would otherwise be the synopsis
[14:38:35] <andypugh> Ah, yes, I see I have debugging-changes in my comp.py.
[14:39:22] <jepler> If the docstring for the component is more than one line, then put all but the
[14:39:25] <jepler> first line in the SYNOPSIS section, replacing the default lines. This allows
[14:39:28] <jepler> a driver to document that it uses io= and not count=
[14:39:31] <jepler> commit f21cd188beb84339461e54d4e778aabeeff5cca5
[14:39:33] <jepler> Author: Jeff Epler <jepler@unpythonic.net>
[14:39:36] <jepler> Date: Wed Oct 11 15:00:05 2006 +0000
[14:40:08] <andypugh> Ah, OK.
[14:40:15] <andypugh> Maybe I need to read docs more?
[14:40:29] <jepler> probably was never documented, but who knows
[14:40:38] <jepler> you can add it to the docs now that you know it and you'll even get a cookie
[14:41:36] <andypugh> Hmm. I thought I was just going to dash of a quick component…
[14:44:10] <andypugh> So, the multi-line description actually has much the same effect as modparam dummy, in practice..
[21:39:39] <KGB-linuxcnc> 03Dewey Garrett 052.7 1715b9d 06linuxcnc 10(13 files in 2 dirs) moveoff: add gladevcp demo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1715b9d