Back
[01:33:46] <linuxcnc-build> build #4 of wheezy-armhf-sim is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/4
[01:33:46] <linuxcnc-build> build #1822 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1822
[01:54:01] <zultron> A friend at Dell said they're about to start selling MakerBots.
[08:10:40] <KGB-linuxcnc> 03Jeff Epler 05master 90984a0 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc interp: don't close log file if it's stderr * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=90984a0
[08:17:35] <linuxcnc-build> build #5 of wheezy-armhf-sim is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/5 blamelist: Jeff Epler <jepler@unpythonic.net>
[08:58:56] <linuxcnc-build> build #1823 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1823 blamelist: Jeff Epler <jepler@unpythonic.net>
[09:34:55] -card.freenode.net:#linuxcnc-devel- [freenode-info] please register your nickname...don't forget to auto-identify!
http://freenode.net/faq.shtml#nicksetup
[11:18:42] <seb_kuzminsky> this looks like the best bang/buck for arm build systems:
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G138733896281
[11:19:07] <seb_kuzminsky> quad Cortex-A9 at 1.7 GHz, 2 GB RAM, $60
[11:19:27] <seb_kuzminsky> it's useless as a cnc controller because it has no IO pins, but it'd be fine for a build system
[11:19:37] <seb_kuzminsky> the manufacturer provides debian images
[11:22:21] <pcw_home> USB hard drive?
[11:22:50] <seb_kuzminsky> microSD
[11:22:56] <seb_kuzminsky> and it's got a couple of usb ports
[11:25:56] <pcw_home> micro sd will crawl and wear out fast
[11:27:43] <cradek> maybe you could do the whole git clone and build in ramdisk
[11:30:28] <seb_kuzminsky> ramdisk might work
[11:30:51] <seb_kuzminsky> the wheezy-rtpreempt-amd64 buildslave does its rip build & test in a 2 GB ramdisk, and that works fine
[11:30:59] <seb_kuzminsky> 1 GB was too small
[11:31:01] <cradek> you might be able to come up with a split of 2GB into ram and disk that lets you build
[11:31:06] <cradek> hmm
[11:31:14] <cradek> then maybe not
[11:31:34] <seb_kuzminsky> swap over 100 Mbps ethernet! wooo!
[11:32:07] <seb_kuzminsky> swap to hdd via usb-to-sata adapter maybe
[11:33:04] <cradek> at my office we used to do software development on diskless machines that did all filesystem and swap over 10Mbit.
[11:33:18] <seb_kuzminsky> i just threw up in my mouth a little
[11:33:27] <cradek> it was another age
[11:34:11] <cradek> I suppose they had low tens of megabytes of ram, don't remember for sure
[11:34:53] <seb_kuzminsky> i ran X on a 386 with 4 MB RAM back in 92 or 93
[11:35:00] <seb_kuzminsky> it had a local disk though
[11:35:22] <cradek> yeah my first linux machine was just like that too
[11:35:31] <seb_kuzminsky> now i'm all, 'waah, this machine only has 2 gigs of ram, how am i expected to get anything done on it?!'
[11:35:35] <cradek> eventually I had a 386-40 with a math coprocessor
[11:35:54] <seb_kuzminsky> i had the 40 mhz one with the built-in 387! that thing was awesome :-)
[11:36:22] <seb_kuzminsky> my motherboard had 8(!) simm slots, and when i populated the other 4 with 256 KB sticks (bringing it up to 5 MB ram) X really started flying
[11:36:39] * seb_kuzminsky sniffs and wipes back a tear
[11:36:49] <cradek> it's weird that people are so excited about moving to underpowered hardware now (I guess because it's small?)
[11:37:23] <seb_kuzminsky> you can get small x86 systems too, i think it's something else
[11:39:33] <seb_kuzminsky> maybe the folks coming up from the embedded microcontroller world see the tiny arm systems as big embedded systems, rather than as shrunken PCs, and so it feels like a more natural evolution for them?
[11:40:07] <cradek> that sure could be
[11:41:55] <seb_kuzminsky> ARM seems to be here to stay, because: telephones
[11:43:11] <pcw_home> It looks like the fastest ARMs (other then exotic server chips) will be cell phone/tablet chips
[11:48:09] <seb_kuzminsky> Those hardkernel folks i linked above also sell a bigger system with the Cortex-A15, which has hardware virtualization support
[11:48:47] <seb_kuzminsky> http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137510300620
[11:49:12] <pcw_home> Those may have a more stable "platform" aspect than cell phone chips
[11:49:49] <pcw_home> Oops that is a cell phone chip....
[11:51:14] <pcw_home> by server chips I guess I am thinking A57
[11:52:25] <seb_kuzminsky> that's the 64 bit one?
[11:53:29] <pcw_home> Yes:
[11:53:30] <pcw_home> http://www.anandtech.com/show/7724/it-begins-amd-announces-its-first-arm-based-server-soc-64bit8core-opteron-a1100
[12:27:32] <seb_kuzminsky> pcw_home: i saw that announcement - that looks just right for a buildserver
[12:29:41] <pcw_home> I wonder when you can actually get MBs
[12:30:04] <pcw_home> (cant be too cheap with dual 10GBE)
[12:33:30] <seb_kuzminsky> samples in march 2014, shipping maybe in q4?
[12:33:36] <seb_kuzminsky> i can't wait that long :-/
[12:33:50] <seb_kuzminsky> i guess i'll buy that Odroid U3
[12:39:42] <pcw_home> can you do parallel makes across multiple Ethernet connected CPUs?
[12:41:13] <cradek> with distcc you can to some extent
[12:42:49] <brianmorel99> Are there any other kernels besides 3.4 RTAI being served on the linuxcnc repository?
[12:43:05] <cradek> the old lucid one is
[12:43:51] <cradek> s/old/venerable/g
[12:44:37] <brianmorel99> I'm testing a UB3 branch i built on Wheezy and thought I might throw some at it besides what I've built.
[12:45:41] <cradek> I wouldn't bet on 2.6.x being new enough to boot/run wheezy, but who knows, maybe it is
[12:56:54] <seb_kuzminsky> zultron: i think there's something wrong with ubc3 on arm, the threads.1 test always fails for me (it passes on amd64)
[12:57:22] <seb_kuzminsky> the thread time reported is always 0 on arm, but a sensible number on amd64
[12:57:23] <seb_kuzminsky> this is with posix threads
[12:57:49] <seb_kuzminsky> for example:
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/4/steps/runtests/logs/stdio
[13:04:19] <seb_kuzminsky> it's not just threads.1, any 'halcmd show thread' reports 0 times, even though the threads are obviously running
[13:06:25] <skunkworks_> it always suprises me how pretty things render in axis..
http://imagebin.org/296169
[13:06:55] <seb_kuzminsky> wow!
[13:07:12] <seb_kuzminsky> using linuxcnc to mint cash, i see
[13:08:09] <skunkworks_> how else do I make money!
[13:20:05] <mhaberler> seb: your problem is likely a missing make setuid:
https://github.com/mhaberler/linuxcnc/commit/30301356cab8bb17122de6a59bcc65a28b5981a5
[15:13:07] <seb_kuzminsky> mhaberler: i dont think so... 'sudo make setuid' runs without complaining, and all the other tests pass
[15:16:11] <seb_kuzminsky> i think the probem is rtapi_time.c line 49
[15:19:54] <seb_kuzminsky> did no one run the tests on the machinekit beaglebone black image?
[15:20:17] <mhaberler> of course we did
[15:20:29] <seb_kuzminsky> does threads.1 pass on arm for you?
[15:20:50] <mhaberler> I can try if you want
[15:20:58] <mhaberler> the glo ubc3 branch?
[15:21:02] <seb_kuzminsky> yep
[15:21:07] <mhaberler> ok
[15:22:43] <seb_kuzminsky> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0274b/index.html
[15:22:46] <seb_kuzminsky> section 4.6
[15:25:30] <mhaberler> so it aint threads.0, its threads.1, correct
[15:27:57] <seb_kuzminsky> correct
[15:28:17] <seb_kuzminsky> all tests pass for me, except threads.1
[15:29:03] <mhaberler> ok
[15:29:23] <mhaberler> will take a while, as you already noticed ;)
[15:29:51] <seb_kuzminsky> yeah that's a slow platform... this is no rush, thanks for looking at it
[15:30:11] <seb_kuzminsky> rtapi_get_clocks() is explicitly only implemented for x86 in the file i pointed to above
[15:30:20] <mhaberler> yeah, that could be
[15:30:32] <mhaberler> another thing I'd want to talk about:
[15:30:45] <seb_kuzminsky> maybe that #warning should be a #error
[15:31:00] <mhaberler> yes, I will change that, it should
[15:32:06] <mhaberler> happy to keep glo/ubc3 and github/ubc3 in sync, but I would ask you to reconsider 0dc9a7d9 and 673b7ae
[15:32:08] <mhaberler> this is why:
[15:32:47] <seb_kuzminsky> this might be an ARMv6+ alternative for rdtsc:
http://google-perftools.googlecode.com/svn/trunk/src/base/cycleclock.h
[15:33:38] <mhaberler> I know its not easy to pick dirs for .so's, but the reason why I want to avoid rt .so's and userland .so's in diffferent dirs is: they are completely disjoint library namespaces, and it was hard to disentangle them; Jeff knows
[15:33:56] <mhaberler> putting them in the same dir sends the wrong message
[15:34:37] <mhaberler> what about /usr/lib/linuxcnc and and /etc/ld.so.conf.d entry?
[15:35:21] <mhaberler> it would also help wiping lcnc .so's completely from an install: wipe /usr/lib/linuxcnc and there is no chance you mess up a rip with .so mixups
[15:37:02] <mhaberler> 0dc9a7d9: I think that should be handled through a /etc/ld.so.conf.d/linuxcnc.conf entry
[15:39:11] <mhaberler> re threads.1 - could well be I overlooked that because threads.0 was broken on non-setuid posix for a long time, so quite likely you are right
[15:44:21] <mhaberler> re dlopen paths: the distinction I made was: everything userland goes through whatever LD_LIBRARY_PATH etc contains; everything RT in rtapi_app goes through a computed path because that one is not subject to standard library resolution; in fact you could have an RT module executing say foo() which is in library a, and rtapi_app proper executing foo() which is somewhere else
[15:44:42] <mhaberler> this was a real bich to completely pull apart for good
[15:46:04] <mhaberler> sorry, text above should read 'I want to avoid rt .so's and userland .so's in the same dir'
[15:58:07] <seb_kuzminsky> i'll revisit those commits
[15:58:14] <mhaberler> thanks - I appreciate it
[15:58:45] <seb_kuzminsky> we should stay withing the fhs as far as possible
[15:59:01] <mhaberler> fhs stands for=
[15:59:04] <mhaberler> ?
[15:59:18] <seb_kuzminsky> filesystem hierarchy standard
[15:59:27] <seb_kuzminsky> http://www.pathname.com/fhs/
[15:59:39] <seb_kuzminsky> it's where files are supposed to be installed on a linux system
[16:00:31] <seb_kuzminsky> currently the .sos go in /usr/lib/linuxcnc/$FLAVOR/
[16:01:17] <mhaberler> you mean the rt .so's?
[16:01:23] <seb_kuzminsky> and .kos go in /lib/modules/$UNAME/linuxcnc/
[16:01:35] <seb_kuzminsky> all .sos go there
[16:01:43] <seb_kuzminsky> all .kos go in /lib/modules
[16:01:58] <seb_kuzminsky> that's for the packaged stuff
[16:02:07] <seb_kuzminsky> things might be different for rip
[16:02:21] <seb_kuzminsky> see debian/linuxcnc-$FLAVOR.files
[16:02:45] <mhaberler> you mean 'currently' as per glo/ubc3?
[16:03:04] <seb_kuzminsky> yes
[16:03:32] <mhaberler> was that the case beforehand as well?
[16:03:58] <seb_kuzminsky> before i fixed deb packaging in ubc3, things did not get installed at all
[16:04:26] <seb_kuzminsky> maybe i misunderstood your question
[16:04:48] <mhaberler> no, I'm referring to say 2.5 or master - I didnt look, but do these use /usr/lib/linuxcnc already?
[16:05:25] <seb_kuzminsky> oh, i see
[16:05:31] <seb_kuzminsky> uhm, i'm not sure
[16:06:05] <seb_kuzminsky> /usr/lib/linuxcnc/modules/*.so
[16:06:22] <seb_kuzminsky> that's for 2.5, and i bet master too
[16:06:56] <cradek> my master buildbot rtai deb install doesn't have /usr/lib/linuxcnc
[16:07:09] <cradek> err are you talking about sim?
[16:07:18] <seb_kuzminsky> yeah, .sos for sim
[16:07:29] <seb_kuzminsky> your rtai deb has .kos, they're probably in /usr/realtime-$UNAME?
[16:07:34] <seb_kuzminsky> (which is totally bogus btw)
[16:08:04] <cradek> /usr/realtime-3.4.55-rtai-2/modules/linuxcnc/motmod.ko
[16:08:12] * seb_kuzminsky blushes
[16:08:13] <mhaberler> Seb and I are talking about installation locations for linuxcnc specific userland .so's which is libraries proper and ulap* as well
[16:09:02] <mhaberler> well whatever the past, I think that would be the place to use in the future; it is within the fhs:
[16:10:26] <seb_kuzminsky> are you suggesting /usr/lib/linuxcnc/*.so for actual shared libraries, and /usr/lib/linuxcnc/$FLAVOR/*.so for userspace-thread hal components (since they're more like plugins than like shared libraries)?
[16:14:41] <zultron> ld.so-loaded libs should just be in /usr/lib.
[16:14:56] <zultron> or $(libdir), actually.
[16:14:57] <mhaberler> yes, I think that would make sense
[16:15:18] <mhaberler> fhs sez:
[16:15:20] <mhaberler> Purpose
[16:15:21] <mhaberler> Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. [23]
[16:15:43] <mhaberler> I vote for the subdir under /usr/lib - it makes removing an install easy
[16:15:44] <zultron> The plugins opened with dlopen() should be in /usr/lib/linuxcnc.
[16:15:44] <seb_kuzminsky> right, i remember talking with zultron about that back when we were working on those two commits
[16:16:22] <seb_kuzminsky> my understanding of the fhs is that what we do now matches that
[16:16:41] <zultron> whether or not ULAPI and RTAPI plugins should be further separated under that directory, I don't have an opinion right now.
[16:17:08] <zultron> Yes, this matches fhs, and Fedora and Debian guidelines.
[16:17:22] <seb_kuzminsky> we put all "internal" libraries and .sos in /usr/lib/linuxcnc/ (sometimes in deeper subdirs), and all "public" shared libs go in /usr/lib
[16:18:01] <zultron> There is the question about $(prefix)/lib vs. $(libdir), though.
[16:18:13] <mhaberler> why? this still messes up /usr/lib
[16:18:42] <zultron> ld.so libs belong in $(libdir) (which isn't always /usr/lib).
[16:19:20] <mhaberler> I would be fine with say liblinuxcnchal.so etc reside in /usr/lib/linuxcnc - it gets us around this /usr/lib tainting issue which is just a support problem generator
[16:19:50] <mhaberler> so $(libdir) is /usr/lib/linuxcnc ?
[16:19:52] <seb_kuzminsky> putting public libs in /usr/lib doesnt seem tainty to me
[16:20:03] <seb_kuzminsky> it seems like the normal thing to do
[16:20:29] <zultron> No, $(libdir) is /usr/lib on Debian.
[16:20:31] <mhaberler> not once you put them there, but once you get mixed setups or want to uninstall manually it becomes hard
[16:21:36] <zultron> We don't want to uninstall manually, do we?
[16:21:42] <seb_kuzminsky> i sure don't!
[16:21:42] <cradek> y'all are talking about what goes in a .deb, right?
[16:21:55] <seb_kuzminsky> i think that's what we're talking about
[16:22:01] <mhaberler> you: sure; Joe Chipcutter: unknown
[16:22:42] <zultron> Anyone building and installing by hand shouldn't be using prefix=/usr.
[16:23:01] <zultron> If they do, they should accept the consequences.
[16:23:22] <mhaberler> well but that wasnt the question, was it?
[16:23:43] <cradek> maybe you could spell out what you think the question is
[16:24:01] <mhaberler> I think we're on the same page still
[16:24:08] <zultron> The question I was answering was, should dl.so-opened shared libs be installed in $(libdir) or $(libdir)/linuxcnc?
[16:24:26] <zultron> (by default)
[16:24:40] <cradek> by the deb?
[16:24:54] <cradek> or by make install (which is used to build the deb)
[16:25:06] <zultron> By make install
[16:25:17] <mhaberler> zultron: liblinuxcnchal.so is also opened by dlopen() eventually - do you mean that example as well?
[16:25:30] <zultron> It is?
[16:25:35] <mhaberler> or just explicit dlopen() calls in linuxcnc code?
[16:25:38] <mhaberler> sure it is
[16:25:56] <zultron> I thought it was opened by dl.so.
[16:25:58] <mhaberler> but not by code under linuxcnc/src
[16:26:02] <zultron> blagh ld.so.
[16:26:07] <mhaberler> well right, but via dlopen()
[16:26:11] <zultron> Right.
[16:26:22] <mhaberler> oh I see. My fault, sorry
[16:26:26] <zultron> I guess that was ambiguous.
[16:27:19] <mhaberler> no you are right, that was the right question
[16:27:22] <zultron> The correct distinction might be opened by ld.so or not.
[16:27:33] <mhaberler> yes it is
[16:28:13] <zultron> Those opened by ld.so are considered system shared libs, and normally go directly into $(libdir).
[16:28:25] <mhaberler> if we have the option as per rules - and I think we have - I suggest $(libdir)/linuxcnc - standard compartmentalisation
[16:29:09] <mhaberler> so you distinguish 'loaded by dl.so' and 'loaded by ld.so'
[16:29:27] <seb_kuzminsky> i think we have three kinds of .sos: "public shared libraries" (linked to by normal applications, like liblinuxcnchal.so), "internal shared libraries" (used behind the scenes, like ulapi-$FLAVOR.so, these are new in ubc), and "userspace components" (like stepgen.so, used by userspace threads)
[16:29:28] <zultron> Sorry, everywhere I wrote 'dl.so', change to 'ld.so'.
[16:29:51] <mhaberler> yes, that is the zoo at hand
[16:30:09] <seb_kuzminsky> public libs should be findable by ld.so, the other two should not be (or at least dont need to be)
[16:30:15] <mhaberler> (dl.so was new! locate dl.so ..)
[16:30:17] <zultron> The last two are conceptually the same.
[16:30:43] <seb_kuzminsky> zultron: yeah, i can see how that makes sense
[16:31:27] <zultron> At least in the sense that one doesn't run 'ldconfig -a' after their installation, and they're opened from within the program by an explicit dlopen().
[16:31:39] <seb_kuzminsky> we currently (glo/ubc) put "public .sos" in /usr/lib, and everything else in /usr/lib/linuxcnc/
[16:31:52] <zultron> Right.
[16:31:56] <seb_kuzminsky> i *think* michael is suggesting moving everything to /usr/lib/linuxcnc
[16:32:10] <seb_kuzminsky> mhaberler, is that what you're suggesting?
[16:32:16] <mhaberler> yes, but it may not be possible
[16:32:20] <zultron> I think he might be. I don't see that that's standard anywhere, though.
[16:32:24] <mhaberler> I wish it could,
[16:32:49] <zultron> It's possible. You'd also have to install a /etc/ld.so.conf.d/linuxcnc.conf file with the location to search.
[16:33:09] <seb_kuzminsky> i think it's possible, but i dont think it buys us anything
[16:33:11] <mhaberler> well it isnt key; it just eases this manual uninstall thing but that isnt a showstopper for me
[16:33:38] <mhaberler> ok, let me summarize then:
[16:33:59] <zultron> Very few programs do that. I'm not sure why they do.
[16:34:16] <mhaberler> $(libdir) (standard /usr/lib) = iblinuxcnchal.so and friends
[16:34:35] <cradek> the only ones on my normalish system that have messed with ld.so.conf.d are related to the terrible nvidia driver stuff
[16:35:07] <zultron> mhaberler, yes.
[16:35:10] <mhaberler> $(libdir)/linuxcnc/$FLAVOR/ - rt .so's
[16:35:17] <mhaberler> (userland rt that is)
[16:35:20] <zultron> yes.
[16:35:41] <mhaberler> ulapi-$FLAVOR: where ;-?
[16:35:56] <zultron> I thought that was the original debate, and I don't know the answer.
[16:36:01] <seb_kuzminsky> it's currently in $(libdir)/linuxcnc, and they're disambiguated by filename (which includes FLAVOR)
[16:36:10] <zultron> Yes, that was originally my doing.
[16:36:11] <seb_kuzminsky> so i think what we have now is fine
[16:36:30] <mhaberler> I see that rt/non-rt mixing argument doesnt hold water unless you fudge a userland.so under $FLAVOR where the rt.sos are
[16:36:32] <zultron> Or maybe if I failed to do it, it was my intent, anyway.
[16:37:47] <seb_kuzminsky> ok, so we're all good on that topic? everyone happy?
[16:37:48] <zultron> Which argument? Is it for or against mixing?
[16:38:04] <mhaberler> let me turn it the other way: a clear error would be to place a .so which is opened by ld.so, or dlopen() in userland code, under $(libdir)/linuxcnc/$FLAVOR
[16:38:15] <zultron> Yes, that's an error.
[16:38:23] <zultron> No.
[16:38:25] <zultron> Wait.
[16:38:29] <mhaberler> let me have a look at Seb's patch
[16:39:15] <seb_kuzminsky> all the .sos in /usr/lib/linuxcnc/$FLAVOR/*.so are dlopened() by userspace
[16:39:31] <zultron> .so libs are opened either by ld.so (before the program even begins execution), or else by an explicit call from within the program by dlopen().
[16:39:38] <seb_kuzminsky> right
[16:39:56] <zultron> Those opened by ld.so belong in $(libdir), which is /usr/lib by default on Debian.
[16:40:50] * seb_kuzminsky is nodding
[16:40:52] <zultron> Those opened by dlopen() belong in either $(libdir)/linuxcnc or $(prefix)/lib/linuxcnc, I'm non sure which, but on Debian, that will end up being the same by default.
[16:41:07] <seb_kuzminsky> yep, that's my understanding as well
[16:41:12] <mhaberler> Seb - 0dc9a7d makes sense afterall, sorry
[16:41:33] <seb_kuzminsky> ok good! :-)
[16:41:53] <mhaberler> lets have a look at the other one:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blobdiff;f=src/rtapi/Submakefile;h=bad2775903e5005ec7a808b4f5bfd09a36bfd81e;hp=211a70c1fc2c282364680cdcdd5d8b2e3efc39d1;hb=673b7aef03d4cdeab0638d3de2bdc0c350a0a657;hpb=0dc9a7d9ff074250cfcef6f4921e5b95dfbc3d2e
[16:42:46] <seb_kuzminsky> right, that one...
[16:42:53] <zultron> Ah, that one looks like the opposite of what we were just saying.
[16:43:06] <seb_kuzminsky> i think it's not
[16:43:30] <zultron> RIP rtlib is $(libdir)/linuxcnc in system installs.
[16:43:44] <seb_kuzminsky> "rtlib" here means stuff that's dlopened
[16:43:51] <seb_kuzminsky> zultron: right
[16:43:55] <zultron> liblinuxcncshm.so is a system shared lib, no?
[16:44:14] <seb_kuzminsky> err...
[16:44:21] <mhaberler> it is a 'ld.so loadable lib'
[16:44:37] <zultron> Right, which means it should go into $(libdir).
[16:44:47] <zultron> For RIP installs, in ../lib.
[16:45:18] <seb_kuzminsky> and it does
[16:45:19] <mhaberler> as should ulapi-$FLAVOR.so
[16:45:38] <seb_kuzminsky> no, ulapi-*.so is dlopened "by hand"
[16:45:52] <zultron> Oh, oops, I'm misreading the file
[16:46:02] <mhaberler> relative to the path ld.so gives you
[16:46:08] <zultron> ulapi-*.so is dlopen()ed.
[16:46:10] <zultron> Sorry.
[16:46:36] <seb_kuzminsky> my mkdir for $(ULAPISO): is wrong, but the file ends up in the right place
[16:46:36] <zultron> So that belongs in ../rtdir, or $(libdir)/linuxcnc
[16:46:44] <mhaberler> ah.
[16:47:49] <seb_kuzminsky> oh wait, no, my patch is right
[16:47:51] <zultron> Yes it is.
[16:47:53] <seb_kuzminsky> heh
[16:48:13] <seb_kuzminsky> "i've only been wrong once, and that time was when i thought i was wrong about something but i was actually right"
[16:48:14] <zultron> I probably made the original mistake.
[16:48:38] <zultron> Who's that? Twain? Yogi Berra?
[16:49:10] <seb_kuzminsky> heh, i dont know
[16:49:20] <seb_kuzminsky> anyway
[16:49:54] <seb_kuzminsky> who wants to talk about rtapi_get_clocks() on arm? :-)
[16:50:19] <mhaberler> I'm just checking if that google replacement is plausible
[16:51:04] <mhaberler> I am still confused on the second patch. Why is ../rtlib a warm place for a userland non-rt .so?
[16:51:29] <seb_kuzminsky> rtlib is a bad name for that variable in ubc (it was less wrong in master & before)
[16:51:45] <seb_kuzminsky> it used to mean "things that act like realtime components"
[16:51:58] <seb_kuzminsky> but now it also means "things that help deal with the flavor switch in rtapi"
[16:52:10] <seb_kuzminsky> maybe that's the source of the confusion here?
[16:52:54] <mhaberler> could be
[16:53:23] <mhaberler> (did we really make up rtlib? it's so long...)
[16:53:44] <seb_kuzminsky> a better name for that variable might be "internal_lib" or something? it's stuff we dlopen(), as opposed to stuff that apps have loaded for them by ld.so
[16:54:02] <seb_kuzminsky> ok, back to $DAYJOB for me
[16:54:02] <cradek> you guys were calling them plugins earlier
[16:54:03] <zultron> We didn't make up rtlib. It used to be for kernel modules.
[16:54:27] <zultron> the pth simulator probably mixed up that distinction first.
[16:54:51] <seb_kuzminsky> it's kernel modules on kernel-thread builds, and userspace "plugins" on userspace thread builds in ubc
[16:55:10] <seb_kuzminsky> later folks!
[16:55:14] <mhaberler> cu
[16:55:28] <mhaberler> ok - so we leave glo/ubc3 as is - right?
[16:55:45] <zultron> Yeah, that was following the pth 'sim' example. I should've fixed it when redoing everything else. :P
[16:55:57] <zultron> Yes, as far as that question.
[16:56:10] <mhaberler> ah. Anyway, that is good to have ticked. next..
[16:57:00] <zultron> The best thing to do would be install under ../lib/linuxcnc, as though $(prefix) were ../.
[16:58:11] <mhaberler> right, that would make the most sense
[16:58:24] <zultron> Then we're one step closer to removing the strange RIP build, and replacing it with $(prefix)=$(pwd)/..
[16:59:02] <mhaberler> right, there is no good reason for different pathnames
[16:59:15] <mhaberler> path segments
[17:00:25] <zultron> Except the fun extra challenge we get when developing on our desktops with RIP builds, and then getting to redo a bunch of stuff when we find system installs broke.
[17:48:53] <skunkworks> there are situations where the current TP goes over by quite a bit. over 39in/s^2 when set to 30..
[17:51:19] <skunkworks> I think mostly non-colinear line-arc transitions
[17:58:36] <cradek> during the blend, or during a whole move (arc?)
[17:59:02] <cradek> I'm shocked you're still finding problems after we tested with various tort.ngc runs
[18:20:46] <skunkworks> heh
[18:21:00] <skunkworks> I can log some more - but the bug tracker has a few samples
[18:21:19] <skunkworks> unless something else is happening
[18:21:28] <seb_kuzminsky> i'd love to see these torture gcodes added to our test suite, somehow
[18:21:34] <seb_kuzminsky> by someone who's not seb_kuzminsky
[18:21:49] <skunkworks> http://www.linuxcnc.org/media/kunena/attachments/343/Screenshotfrom2014-02-24130048.png
[18:21:56] <skunkworks> that is master
[18:22:40] <skunkworks> I have a program now that pushes it around 39
[18:23:09] <skunkworks> seb_kuzminsky: I think rob has a test suite of gcode programs..
[18:23:49] <seb_kuzminsky> cool! is it integrated with our runtests, or something that needs separate, manual operation?
[18:25:14] <skunkworks> I am not sure ( have not looked at it ) I don't know how that works
[18:25:51] <seb_kuzminsky> you've got some hal circuitry that works in sim, that detects constraint violations, right?
[18:26:23] <skunkworks> yes - it is mostly in the sim config.. I think chris made it
[18:27:32] <skunkworks> I just added halness to log the peak
[18:29:59] <skunkworks> I think though (again - just from what rob has mentioned (and reading the change logs)..) that he has a testing mechanism..
[18:30:38] <skunkworks> https://github.com/robEllenberg/linuxcnc-mirror/compare/feature;arc-cases-experimental
[21:51:18] <skunkworks> cradek:
http://imagebin.org/296250
[21:51:20] <skunkworks> http://pastebin.ca/2648104
[21:58:37] <skunkworks> (and because I don't seem to comunicate very well.. That is the x acceleration of the pastebins program. The axis acceleration is set to 30 and it is peaking at about 38in/s^2
[23:09:20] <linuxcnc-build> build #6 of wheezy-armhf-sim is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/6 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>, ArcEye <arceye@mgware.co.uk>
[23:50:13] <linuxcnc-build> build #1824 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1824 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>, ArcEye <arceye@mgware.co.uk>
