Back
[09:29:58] <skunkworks> zlog
[11:42:30] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek commented on issue #134: @zultron @robEllenberg testing glo/statetags some more, I see a new problem. When I abort while deep in subroutines, I get an interpreter error: Unknown oword number... 02
https://github.com/LinuxCNC/linuxcnc/issues/134#issuecomment-257610395
[11:44:20] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #134: Thanks @cradek, I'll take a look. 02
https://github.com/LinuxCNC/linuxcnc/issues/134#issuecomment-257610868
[11:45:23] <KGB-linuxcnc> 03Chris Radek 05cradek/show-call-level eb20466 06linuxcnc 10(8 files in 6 dirs) Add call level to state tags * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eb20466
[11:45:54] <cradek> mozmck: ^^^
[11:46:09] <mozmck> hey - thanks!
[11:46:26] <mozmck> That should prove useful in GUIs
[11:47:15] <cradek> mozmck: I hacked AXIS to show the call level - you can see it if you run calls.ngc
[11:47:26] <cradek> I'm not sure how call level and remap level are different
[11:47:35] <cradek> it still doesn't have the information about whether it's in a different file
[11:47:43] <mozmck> I *think* they are the same.
[11:47:46] <cradek> but looking at this diff you can see how easy those would be to add
[11:48:38] <cradek> I think they are different - calls.ngc doesn't use remap at all but shows >0 call level
[11:48:52] <cradek> flowsnake.ngc shows call level 6 during most of its run
[11:50:01] <mozmck> I'll have to look at it more. I thought the call level was how many subroutines deep you are.
[11:50:12] <cradek> I think that's right
[11:50:21] <mozmck> I don't know about remap level - is that not the same?
[11:50:42] <cradek> I don't think it's the same, although a remap can (or must?) use a call
[11:50:49] * cradek waves his hands
[11:50:50] <mozmck> So where is settings->call_level set?
[11:51:10] <cradek> the O word handling code maintains the call stack
[11:51:32] <jepler> $ git grep 'call_level\s*=[^=]' 'src/**/*.cc'
[11:51:43] <jepler> will find you most of the sites where call_level is set
[11:52:16] <mozmck> Yeah, I'm seeing that now.
[11:53:50] <cradek> src/emc/rs274ngc/interp_o_word.cc:600: settings->call_level++;
[11:54:06] <jepler> ah yeah my grep wouldn't find *that*
[11:54:16] <cradek> enter_context() //prepare a new call frame
[11:54:49] <cradek> leave_context(): settings->call_level--; // drop back
[11:55:20] <mozmck> I use eclipse ;-) I'm not good with regexes.
[12:12:07] <cradek> bool external_sub = strcmp(settings->filename, settings->sub_context[0].filename);
[12:18:22] <linuxcnc-build_> build #1225 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/1225 blamelist: Chris Radek <chris@timeguy.com>
[12:18:27] <linuxcnc-build_> build #4614 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4614 blamelist: Chris Radek <chris@timeguy.com>
[12:19:23] <cradek> weird
[12:20:26] <cradek> oh that's a fragile timing-dependent test
[12:23:40] <tinkerer> jepler: sometimes I've the feeling I'm blind or so:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=159170
[12:24:44] <tinkerer> did you see this?
[13:34:18] <KimK_laptop> Re: testing refactor-debian-configure, I tried building from master on Mint 18, using both "./configure uspace" and "./configure" and both gave "W: Unable to locate package libxenomai-dev<newline>" (twice in a row), even though I have installed libxenomai-dev (and libxenomai1, and xenomai-system-tools).
[13:35:04] <KimK_laptop> uname -a returns: Linux kkirwan-E627a 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[13:37:25] <KimK_laptop> Oops. s/and "./configure" and both gave/and "./configure sim" and both gave/
[13:42:21] <cradek> KimK_laptop: I added your new key just now
[13:49:40] <jepler> KimK_laptop: please pastebin the result of these two commands:
[13:49:41] <jepler> apt-cache search -n libxenomai-dev
[13:49:46] <jepler> apt-cache showsrc libxenomai-dev
[13:52:29] <jepler> tinkerer: I don't follow raspberry pi forums
[13:55:05] <jepler> I really don't take enough interest in those boards to spend time trying to get an RT kernel to work myself.
[13:55:22] <jepler> I've done it a couple of times on other boards with varying degrees of success, and it's always a different frustrating story on each different board
[13:56:00] <tinkerer> I've meant related to kernel rt source...
[13:56:04] <tinkerer> ok :)
[13:56:42] <jepler> I'm flattered you think I'm smart enough to have something to add to the discussion
[13:58:23] <tinkerer> no no, but passing at searching for kernel source :)
[13:58:59] <tinkerer> joke!
[13:59:42] <jepler> I know there are plenty of websites that have different versions of different kernels.
[14:00:03] <jepler> the critical thing for meeting obligations under the GPL is offering the *complete, corresponding* source code
[14:00:29] <jepler> and the best way to do that in the context of Debian-derived systems is to publish the Debian source package and the Debian binary package built from that source package
[14:01:06] <tinkerer> I would say you are much smarter than many of the protagonists there
[14:01:48] <jepler> A lot of hobbyists don't concern themselves with the specifics of free software licenses, and I don't blame them because that part is not fun or rewarding.
[14:02:44] <tinkerer> yes, that's true
[14:03:28] <jepler> (and actually if you offer *just* source code, like a lot of these people do, then the source code alone already satisfies your obligations under almost any free software or open source license)
[14:05:01] <tinkerer> it has the smell of concrete and ground of hudson river...
[14:56:01] <KimK_laptop> jepler: The results are extremely short, so I'll put them here for the convenience of others.
[14:57:11] <KimK_laptop> jepler: $ apt-cache search -n libxenomai-dev gives: libxenomai-dev - Headers and static libs for Xenomai
[14:58:14] <KimK_laptop> jepler: $ apt-cache showsrc libxenomai-dev gives: W: Unable to locate package libxenomai-dev (followed by) N: No packages found
[14:58:31] <jepler> KimK_laptop: Thanks. That helps clarify things.
[14:59:02] <jepler> the linuxcnc debian/configure script expects to be able to retrieve information about source packages
[14:59:30] <jepler> it is normal for Debian systems to be configured so that this information is available (a deb-src line for each deb line in /etc/apt/sources.list and /etc/apt/sources.list.d/*)
[14:59:36] <jepler> clearly your system is not configured in this way
[15:00:41] <jepler> so for instance on a debian stable system, you might have:
[15:00:42] <jepler> deb
http://http.debian.net/debian stable main
[15:00:42] <jepler> deb-src
http://http.debian.net/debian stable main
[15:01:12] <jepler> The information that debian/configure needs about the source package for libxenomai-dev is the list of architectures where libxenomai-dev is available
[15:01:36] <jepler> because the produced source package wants to depend on libxenomai-dev if it is available, and not if it is not available
[15:01:49] <jepler> so that the same source package can be used on multiple debian platforms
[15:12:18] <jepler> I would be happy to see a commit to make debian/configure detect and react to this problem better, but ultimately your mint installation (and possibly mint installations in general?) is misconfigured in a way that will inevitably confuse debian/configure.
[15:20:25] <jepler> yeah this is apparently a factory-misconfiguration of mint
[15:21:10] <jepler> though my system tells me: "E: You must put some 'source' URIs in your sources.list"
[15:21:31] <jepler> possibly if you followed instructions for setting up the linuxcnc.org package repository you added a deb-src line at that time
[15:22:53] <KimK_laptop> Does this help?:
http://pastebin.ca/3735228 And since Debian -> Ubuntu -> Mint, is Ubuntu 16.04 affected by this also, or is this a Mint-only problem? Can I provide any more information?
[15:23:29] <KimK_laptop> Oh, I have not added LinuxCNC as a source, is that it?
[15:23:47] <jepler> libxenomai-dev is a package from mint, not from linuxcnc
[15:23:55] <KimK_laptop> OK
[15:24:00] <cradek> perhaps official-package-repositories.list
[15:24:31] <jepler> yes that one
[15:24:40] <jepler> on my mint VM it has only deb lines, no deb-src lines
[15:24:47] <jepler> I view this as absolute misconfiguration
[15:24:50] <cradek> that's sure stupid
[15:25:08] <mozmck> I have not used mint 18 yet, but in mint17 there is a check box in the "software sources" application to "Enable source code repositories"
[15:25:10] <jepler> Their rationale is probably that information about source packages is something that only a remote minority of users will ever need
[15:25:21] <jepler> probably fewer users than use metered internet
[15:25:58] <mozmck> I have not enabled source repositories - never had a need to.
[15:26:00] <jepler> so in a sense they're not wrong, but it's still not feasible to get the information debian/configure needs in another way.
[15:26:42] <mozmck> The -dev packages have always had what I need - but that is apparently not the case here?
[15:26:53] <jepler> I use apt-cache source, apt-get source, apt-cache showsrc way more than once per month
[15:27:18] <jepler> mozmck: $ apt-cache showsrc libxenomai-dev | grep ^Archite
[15:27:18] <jepler> Architecture: amd64 arm armeb armel i386 powerpc all
[15:27:29] <mozmck> huh. If I ever want the source I go upstream to get it
[15:27:31] <jepler> specifically, debian/configure needs a list of platforms that have libxenomai-dev available as a binary package
[15:27:52] <cradek> the advantage of apt-get source is it gives you the exact corresponding source to what your system is running
[15:28:04] <cradek> so if you're looking for a bug, or documentation, or whatever, it all matches
[15:28:04] <KimK_laptop> cat of my official-package-repositories.list added to the previous pastebin:
http://pastebin.ca/3735229
[15:28:21] <cradek> and you can make a small change and rebuild, and it'll work
[15:28:21] <jepler> .. which it uses in turn to depend on that development package on exactly the architectures that have it available
[15:28:26] <jepler> Build-Depends: ... libxenomai-dev [amd64], libxenomai-dev [arm], libxenomai-dev [armeb], libxenomai-dev [armel], libxenomai-dev [i386], libxenomai-dev [powerpc], libxenomai-dev [powerpcspe] ...
[15:29:02] <mozmck> so why does it do that? can't it just depend on libxenomai-dev?
[15:29:45] <jepler> depending unconditionally on libxenomai-dev makes the linuxcnc source package unbuildable on an architecture that doesn't have libxenomai-dev (such as kfreebsd-amd64)
[15:29:58] <mozmck> oh, hmm.
[15:30:20] <jepler> src/configure will use xenomai if available, but skip building for that rtos otherwise
[15:30:21] <mozmck> I thought the dependency lists were separate for each arch anyhow - has that changed?
[15:30:31] <jepler> but the dependency information has to be right or it doesn't even get to the step of running src/configure
[15:30:52] <jepler> this is the Build-Depends, and the [bracket] syntax is exactly how you make the list be different for each architecture
[15:31:39] <jepler> I can't just hard-code a list, because it varies from distribution to distribution and version to version
[15:31:42] <jepler> e.g., this is wheezy:
[15:31:42] <jepler> Architecture: amd64 arm armeb armel i386 powerpc all
[15:31:43] <mozmck> ok - I guess I have more to learn there!
[15:31:48] <jepler> and this is jessie:
[15:31:48] <jepler> Architecture: amd64 arm armeb armel i386 powerpc powerpcspe all
[15:32:10] <jepler> (from apt-cache showsrc libxenomai-dev)
[15:33:09] <jepler> in the case that the libxenomai-dev source package information is not available, but the libxenomai-dev binary package appears to be available, it may be that debian/configure should depend on libxenomai-dev unconditionally. If somebody wants to implement that change, I'll be happy to review it.
[15:38:56] <KimK_laptop> If the "...source package information is not available...", maybe I should [X]enable sources? I'll try it, brb...
[15:44:32] <KimK_laptop> make-ing now, looks promising.
[15:47:54] <KimK_laptop> I was following the old(?) directions, I just said "./configure", nothing about docs, sim vs. real, anything else. No messages from it.
[15:48:29] <KimK_laptop> ./configure on the make, I mean.
[15:56:49] <jepler> in master branch, uspace is automatically selected by src/configure if no rtai-config script is found. in any case, src/configure will tell you what it is doing. but I recommend still configuring --with-realtime=uspace fwiw
[16:17:16] <jepler> a generic-ish non-realtime firmata hal driver would be an interesting project for someone
https://github.com/firmata/protocol/blob/master/protocol.md
[16:17:36] <jepler> as a possibly more robust alternative to that awful thing I implemented for arduino so many years ago
[16:33:59] <KimK_laptop> Sorry about the network hiccup. I didn't mean to disconnect just then, I don't know what happened.
[16:38:03] <jepler> I've asked my irc client not to show depart/join messages so I didn't know you'd gone
[16:38:06] <jepler> zlog: log
[16:53:20] <KimK_laptop> Thanks for the catch up, it appears I was offline longer than I thought. Last thing I got was your ...=uspace fwiw.
[16:53:51] <KimK_laptop> My turn to catch you up now:
[16:54:05] <KimK_laptop> Looks like linuxcnc (master/2.8.0~pre1) built and seems to be running fine, gents. Sorry if this was a facepalm, my bad. Maybe a message that says "I don't see any sources. Did you enable any?"
[16:54:16] <KimK_laptop> Now this was all sim. I have no idea what this laptop is like on realtime. The (POSIX non-realtime) latency-test results are pretty bad. How would I go on from here and try to install some type of real-time kernel to see what happens next?
[16:54:35] <KimK_laptop> cradek: Thanks very much for the key update! I'll try it later from home.
[16:55:16] <KimK_laptop> OK, all caught up now.
[16:56:02] <JT-Shop> pcw_home: what is the 5i25_7i76x2D.bit file for?
[16:59:05] <pcw_mesa> Its a standard 5I25 7I76X2 bitfile with a DPLL added
[16:59:07] <pcw_mesa> (the DPLL make the stepgens work well with relatively terrible latency, so if you have 500 usec latency for example thats OK)
[16:59:18] <JT-Shop> thanks
[17:00:19] * JT-Shop makes a note of that
[17:01:06] <andypugh> A suggestion for the “Showcase” (my own work, so I am being somewhat immodest) but it does demonstrate the power of parametric G-code and loop structures:
http://bodgesoc.blogspot.co.uk/2016/11/cams.html
[17:01:13] <pcw_mesa> Or you want extremely precise, low jitter step pulse streams
[17:01:14] <pcw_mesa> The DPLL reduces the stepgen position sampling jitter to less than 250 ns
[17:02:56] <pcw_mesa> Also the DPLL is used by Brand M as a periodic interrupt source
[17:03:31] <JT-Shop> Brand M?
[17:04:01] <pcw_mesa> Machinekit
[17:04:07] <JT-Shop> ah ok
[17:04:23] <KimK_laptop> ha
[17:05:34] <JT-Shop> andypugh: wow that is cool
[17:11:59] <pcw_mesa> That is really neat!
[17:12:01] <pcw_mesa> are you going from candle to brass or testing the hardware with PE or some such?
[17:12:03] <pcw_mesa> (I assume the candle would not survive the follower pressure)
[17:14:25] <andypugh> The candle is just to save tools when I get the code wrong. The final think will be brass.
[17:14:45] <andypugh> But I will probably start with delrin to check the mechanisms.
[17:16:42] <andypugh> (I have already decided that I probbaly should offset every second cam by 180 degrees)
[17:19:07] <KimK_laptop> Hi Andy. That is indeed very cool, and a great showcase for LinuxCNC. Can you say what it's all for?
[17:19:21] <andypugh> An over-elaborate clock :-)
[17:21:34] <KimK_laptop> OK. Well, I hereby nominate it for the showcase. Or second it, if Andy nominated it already.
[17:23:22] * KimK_laptop looks for "Robert's Rules of Order"... or maybe not.
[17:25:04] * JT-Shop wonders where the showcase is?
[17:25:14] <JT-Shop> github something
[17:26:35] <jepler> the main website's git is
https://github.com/linuxcnc/wlo
[17:26:47] <jepler> the _showcase directory is where the showcase items live
https://github.com/LinuxCNC/wlo/tree/master/_showcase
[17:27:38] <jepler> so consider following the format of the other showcase .md files, and submit a pull request. In this case, I'd only ask that Andy not submit a pull request for his own work.
[17:28:21] <jepler> the front page / README.md say very tersely how to test the website yourself, locally, before preparing your commit and pull request etc
[17:29:04] <jepler> It would be great if one of you, JT-Shop or KimK_laptop, would make a pull request to add this to the showcase!
[17:29:11] <KimK_laptop> If I were going to submit the pull request, I would have to have forked first, right?
[17:29:27] <jepler> KimK_laptop: yes I think so
[17:29:54] <KimK_laptop> Is there a standard place that we linuxcnc-dev users fork to instead?
[17:30:17] <KimK_laptop> linuxcnc-github maybe?
[17:30:46] <jepler> I don't understand the question.
[17:31:04] <jepler> Unlike the main linuxcnc.git, which still has its primary home on git.linuxcnc.org, the website ("wlo")'s primary home is on github
[17:31:05] <KimK_laptop> Oh, nevermind, I don't need to move it for real.
[17:32:03] <JT-Shop> let me see if I can figure it out
[17:32:43] <KimK_laptop> Do you want to do it JT? That's OK by me if you'd like.
[17:32:58] <JT-Shop> if you know how go ahead
[17:34:03] <KimK_laptop> OK, will do.
[17:54:00] <jepler> the more people who know how to edit the main website, the better.
[17:56:35] <JT-Shop> I agree with that for sure
[22:06:59] <cradek> andy's project is amazing
[22:07:03] <cradek> I'd love to hear about the clock