Back
[09:52:25] <Guest78658> thanks seb_kuzminsky ill give that a shot
[10:25:12] <KGB-linuxcnc> 05jepler/internaldatatypes f326628 06linuxcnc branch created * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f326628
[10:25:22] <KGB-linuxcnc> 05jepler/proposed-master f326628 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f326628
[10:33:08] <NTU> seb_kuzminsky: when you said you can build .debs with any distro using pbuild how would i go about doing that?
[10:37:00] <seb_kuzminsky> NTU: just a sec
[10:39:41] <seb_kuzminsky> NTU:
https://github.com/SebKuzminsky/linux-rtai-build
[10:40:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 9174efc 06linuxcnc 10(5 files in 3 dirs) rtapi_string: actually export these APIs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9174efc
[10:40:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 812dc71 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2: drop unneeded workaround for old kernels * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=812dc71
[10:40:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master ba15525 06linuxcnc 10src/rtapi/rtapi_math64.h rtapi_math64: drop unneeded workaround for old kernels * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ba15525
[10:40:20] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 79c39a4 06linuxcnc 10src/rtapi/rtai_rtapi.c rtai: drop unneeded workaround for old kernels * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=79c39a4
[10:41:15] <seb_kuzminsky> NTU: it's horribly rickety and complicated, but when stroked just the right way it does the right thing
[10:42:25] <NTU> so i can modify the makefile for 3.14.19 ?
[10:42:44] <NTU> also pull from my rtai repo instead of the other one
[10:43:31] <seb_kuzminsky> to switch to a new kernel version, you update the version number of the tarball in the top-level makefile (easy), then update the linux-deb git branch it uses to one that works with that kernel (harder)
[10:43:45] <seb_kuzminsky> to change which version of rtai to build, just change the rtai branch in the top-level makefile
[10:44:24] <NTU> ok
[10:44:34] <seb_kuzminsky> and cherry-pick my debianizing patches from the old-3.9-debs branch to your new rtai branch
[10:44:45] <seb_kuzminsky> mmm bacon
[10:45:16] <seb_kuzminsky> oh, and the docs are probably all out of date
[10:45:25] <seb_kuzminsky> good luck!
[10:45:30] <NTU> i dont read docs anyway
[10:45:35] <seb_kuzminsky> i'll be around on and off today to answer questions
[10:45:43] <seb_kuzminsky> heh good, mine are not worth reading ;-)
[10:47:03] <NTU> when i built debian kernel packages the first time i spent maybe 2 seconds looking over some doc page
[10:49:25] <seb_kuzminsky> i know of three ways to build kernel debs: "make deb-pkg", make-kpkg", and the "external debian directory" way that the linux-rtai-build system uses
[10:49:37] <seb_kuzminsky> i tried the first two first, they didnt work very well
[10:50:13] <seb_kuzminsky> the "external deb dir" way is what both debian.org and ubuntu.com use, and it works very well (though it's quite complicated and half-assedly documented)
[10:51:58] <NTU> make deb-pkg works fine for me
[10:52:16] <NTU> it even automagically makes an initrd if you have support for it in-kernel
[10:52:35] <NTU> you dont need to apt-get install dracut and all that
[10:53:43] <NTU> i cannot wait for 3.16 IPIPE so i can get my card running
[10:54:18] <NTU> the 3.10 and 3.14 IPIPE patches are difficult to keep maintained so those will be depreciated and removed once 3.16 hits
[11:11:35] <jepler> http://smbc.myshopify.com/collections/frontpage/products/marxist-shirt
[11:16:16] <seb_kuzminsky> jepler: i was expecting you to link this:
http://fc01.deviantart.net/fs22/i/2007/356/0/4/Mao_RTFM_vectorize_by_cmenghi.png
[11:17:30] <NTU> heh!
[11:18:24] <NTU> title of the manual: how to become an almighty ruler
[11:18:36] <NTU> as his followers stand behind him
[13:48:11] <jepler> seb_kuzminsky: nic
[13:48:32] <jepler> e
[15:45:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 6c66c8e 06linuxcnc 10src/Makefile 10src/Makefile.modinc.in build: get rid of unneeded $(cc-option) calls * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6c66c8e
[15:45:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 6dadf3d 06linuxcnc 10src/Makefile build: get rid of unused cc-option variable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6dadf3d
[15:45:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 8151835 06linuxcnc 10src/Makefile.modinc.in build: comment on why unused variable is left here * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8151835
[15:49:52] <linuxcnc-build> build #625 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/625 blamelist: Jeff Epler <jepler@unpythonic.net>
[16:06:09] <jepler> ah, so
[16:06:10] <jepler> cc1: error: unrecognized command line option ‘-mieee-fp’
[16:06:26] <jepler> linuxcnc-build: thanks
[16:08:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master b221529 06linuxcnc 10src/Makefile 10src/Makefile.modinc.in build: get rid of unneeded $(cc-option) calls * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b221529
[16:22:30] <linuxcnc-build> build #2446 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2446 blamelist: Jeff Epler <jepler@unpythonic.net>
[16:48:36] -sendak.freenode.net:#linuxcnc-devel- [freenode-info] channel trolls and no channel staff around to help? please check with freenode support:
http://freenode.net/faq.shtml#gettinghelp
[17:11:29] <NTU> -mieee-fp works here..
[17:11:45] <NTU> its even in the gcc manual.
[17:15:17] <alex_joni> cc1<gcc
[17:15:43] <alex_joni> NTU: might not be true for armhf
[17:20:59] <NTU> oh i didnt think about that
[18:57:25] <jepler_> alex_joni: right, it's because of arm
[18:57:26] <jepler_> $ x86_64-linux-gnu-gcc -mieee-fp -x c -c /dev/null -o /dev/null
[18:57:26] <jepler_> $ arm-linux-gnueabihf-gcc -mieee-fp -x c -c /dev/null -o /dev/null
[18:57:26] <jepler_> arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-mieee-fp’
[18:57:29] <jepler_> $
[19:05:05] <NTU> so how does one compile IEEE complaint code on arm?
[19:39:21] <jepler_> well on reading the help for -mieee-fp / -mno-ieee-fp, you'll see that (just like all -m options) they are target-specific
[19:39:59] <jepler_> here, you can see that in fact gcc produces different code for "x < y" in the two situations .. again, on reading the help, you'll see that -mieee-fp is about ieee-correct comparisons
[19:40:03] <jepler_> http://paste.debian.net/122297/
[19:41:35] <jepler_> I think the key is using "fucompp" rather than "fcompl"
[19:44:25] <jepler_> http://x86.renejeschke.de/html/file_module_x86_id_124.html
[19:44:26] <jepler_> "The FUCOM/FUCOMP/FUCOMPP instructions perform the same operations as the FCOM/FCOMP/FCOMPP instructions. The only difference is that the FUCOM/FUCOMP/FUCOMPP instructions raise the invalid-arithmetic-operand exception (#IA) only when either or both operands are an SNaN or are in an unsupported format; QNaNs cause the condition code flags to be set to unordered, but do not cause an exception to be generated."
[19:45:32] <jepler_> probably in the case of arm there is not this specific distinction
[19:47:11] <jepler_> it's probably a distinction that doesn't matter anyway -- I don't think that we unmask the IA exception. rather, it's a flag that we've tried varying in the past to get math in kernel space to behave, without knowing exactly what difference it made
[19:47:47] <NTU> i understood maybe a quarter of what you just said.. xD
[19:47:51] <jepler_> me too!
[19:48:18] <jepler_> but the point is, it's a specific flag that applies to x86 / amd64 only, and not to arm. And I should have expected that since it it's a -msomething and not a -fsomething
[20:51:06] <jepler> how the heck do hal aliases work?!
[20:51:21] <jepler> I know that a pin (and, I think, param) can have one alias
[20:52:27] <jepler> probably I should forget this project (originally conceived as converting all the hal lists to doubly-linked lists). it's the kind of change for no good reason that cradek would council me against
[20:55:09] <jepler> anyway, I now realize that many of the lists are additionally kept sorted; I think the sensible data structure would therefore be an rb-tree but those are about 24x as complicated as a linked list
[20:55:43] <jepler> all to make hal a few (single digit percentage) LOC shorter, while probably introducing bugs in the process
[21:25:43] <cradek> :-/
[21:26:00] <cradek> aliases were my bad idea
[21:26:16] <cradek> bad = nobody really uses it so it's kruft that we aren't even sure works right
[22:25:01] <skunkworks> isn't latency on this machine bad if the servo thread is huge?
[22:25:03] <skunkworks> https://www.youtube.com/watch?v=AzY3S1SCV3I
[22:28:15] <skunkworks> *huge in a reletive term...
