Back
[01:07:41] <memleak> gabewillen, you won't believe it...
[01:07:57] <memleak> I GOT RTAI 3.X KERNELS WORKING IN 64-BIT!
[01:08:01] <memleak> w/ LINUXCNC
[01:08:28] <memleak> victorious!!!!!!!!
[01:10:31] <memleak> demo sim and latency-test work, it
[01:10:40] <memleak> s a bit worse than 32-bit but still starts.
[10:14:06] <pcw_home> Yay memleak!
[10:14:07] <pcw_home> (though I'll bet this exposes a lot of bugs in drivers/hal if actually used)
[10:57:47] <andypugh> W: Failed to fetch http:/deb.machinekit.net/precise/dists/precise/Release.gpg Unable to connect to :http:
[10:58:13] <andypugh> which seems odd, as www.machinekit.net is up.
[10:58:39] <andypugh> zultron: ?
[11:43:41] <andypugh> My fault! I had a
http:/// in the sources.list
[11:47:41] <mhaberler> andy: if you're going for an ubc build, use this:
https://github.com/mhaberler/linuxcnc/commits/unified-build-candidate-2
[11:47:46] <mhaberler> note -2
[11:48:05] <mhaberler> master should merge without issues into this branch
[11:52:37] <andypugh> I am trying to buid the 7i80 driver. That is a patch on rtos-master-v0
[11:53:13] <andypugh> I might see if I can force it into patching ubc
[11:55:43] <mhaberler> where was that patch again?
[12:08:13] <andypugh> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mesa7i80_Driver_For_Linuxcnc_On_Xenomai
[12:08:51] <andypugh> I am not entirely sure why it is stil a loose patch rather than something pushed (if broken)
[12:13:09] <skunkworks> I know there needs to be some though at how it initalizes the rtnet. as of right now - when you start linuxcnc with 7i80 - you have to give the sudo password
[12:15:01] <skunkworks> thought
[12:15:25] <andypugh> That sounds like a missing entry in the sudo make setuid script
[12:16:13] <skunkworks> there was some talk about that not too long ago... I seem to remember it not being that easy
[12:17:19] <mhaberler> do you want the 7i80 rtnet driver in ubc? if so, I'll look into it (just driver build)
[12:17:42] <andypugh> micges is the guy to ask, he wrote the driver.
[12:18:02] <mhaberler> I know, but you tried ;)
[12:19:30] <andypugh> I seem to have an unmet dependency on "linux-image-3.5.7-xenomai-2.6.2.1" which I am sure I fixed previously with an "Ah, silly me, missed a step" fix
[12:20:29] <andypugh> No, sorry, wrong paste contents
[12:20:46] <andypugh> the missing thing is linux-modules-3.5.7-.....
[12:23:36] <andypugh> No, silly me, what I lack is rtai-modules-2.6.32-122-rtai
[12:24:01] <andypugh> And it is installing now
[12:40:42] <andypugh> memleak: The RTNet menuconfig allows one to build for RTAI / Xenomai 2.0 XOR Xenomai 2.1+
[13:32:32] <psha> mhaberler: around?
[13:32:38] <mhaberler> yes
[13:32:57] <mhaberler> whazzup?
[13:40:56] <mhaberler> samovar explosion?
[13:53:28] <psha> mhaberler: hm, not today :)
[13:53:38] <mhaberler> ah
[13:53:42] <psha> take a look on cython
[13:53:45] <psha> looks very nice for me
[13:54:05] <psha> and gives extensions with very limited library deps
[13:54:09] <mhaberler> there are several ways to do this, cffi for instances
[13:54:20] <psha> $ ldd pyring.so linux-vdso.so.1 (0x00007fffe8dfe000) libring.so => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff108327000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff107f79000) /lib64/ld-linux-x86-64.so.2 (0x00007ff108770000)
[13:54:28] <psha> oops
[13:54:33] <psha> $ ldd pyring.so linux-vdso.so.1 (0x00007fffe8dfe000) libring.so => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff108327000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff107f79000) /lib64/ld-linux-x86-64.so.2 (0x00007ff108770000)
[13:54:36] <psha> again )
[13:54:38] <mhaberler> yeah I've played a bit with cython
[13:55:36] <mhaberler> for getting a C API's it's fine; for C++ code boost::python is a lot easier
[13:55:43] <psha> cffi is worse - i see only swig/boost and cython
[13:55:53] <psha> as real alternatives
[13:55:58] <psha> but - that's not for today )
[13:56:00] <psha> bad time
[13:56:01] <psha> bed
[13:56:03] <psha> !!
[13:56:05] <mhaberler> ha!
[13:56:06] <psha> good time
[13:56:07] <psha> for bed :)
[13:56:16] <psha> bb
[13:56:20] <mhaberler> cu
[14:17:21] <CaptHindsight> anyone know about there being and fast-math issues or problems with 64bit?
[14:22:20] <mozmck> did you see Michael Busch's email to the dev list?
[14:23:34] <mozmck> I don't know anything myself.
[14:23:35] <CaptHindsight> mozmck: yes, the one without much detail
[14:23:47] <mozmck> yes, that one :)
[14:23:52] <CaptHindsight> why I thought I'd start asking
[15:15:20] <andypugh> Does this mean anything to anybody?:
[15:15:21] <andypugh> compilation terminated.
[15:15:32] <andypugh> Let me try again: /home/andypugh/linuxcnc-dev/src/objects/xenomai-kernel/3.5.7-xenomai-2.6.2.1/hal/drivers/mesa-hostmot2/hm2_eth.c:2:24: fatal error: sys/socket.h: No such file or directory
[15:15:32] <andypugh> compilation terminated.
[15:21:48] <memleak> -ffast-math causes problems in RTAI but I don't think it's because it depends on IEEE or ISO rules, I haven't looked into it all that much, code is incredibly sloppy..
[15:22:26] <skunkworks> I have not had that error in my testing
[15:23:16] <memleak> https://github.com/ShabbyX/RTAI/blob/master/base/math/s_scalbn.c
[15:23:40] * memleak has trouble reading that...
[15:27:04] <memleak> scalbn gets redefined apparently with -ffast-math and causes a compilation error (obviously you can't define something twice)
[15:29:26] <memleak> unless it's magic of course...
https://github.com/ShabbyX/RTAI/blob/master/base/arch/x86/hal/hal_x86.c#L1258 (line 1258)
[15:29:52] <memleak> quite a few devs have looked at that and wonder what in the world is going on..
[15:32:26] <memleak> note that scalbn comes from mathP.h but simply removing the header doesn't fix it either, and removing the definitions for scalbn that are supposedly being redefined causes GCC to tell me to put a ( before the { but that still doesn't fix anything.
[15:33:30] <pcw_home> well 1257 is dead code other than wasting a ns or so
[15:34:14] <memleak> how did you figure that out???
[15:34:59] <pcw_home> well if the variable is hardware, all bets are off
[15:35:54] <memleak> btw after reviewing mathP.h i don't see any definitions for scalbn. I wonder if -ffast-math just confuses GCC because the code is so messy that it can't read it?.. >_>
[15:36:41] <pcw_home> its awfully clever...
[15:37:20] <memleak> i honestly can't find a better conclusion..
[15:37:25] <andypugh> pcw_home: apic_read might be a function with side effects, but even in that case the multiplication by Hz is definitely dead code.
[15:38:45] <pcw_home> its just a long
[15:40:12] <pcw_home> I wonder if tricks like scalbin use are even appropriate now
[16:00:02] <memleak> pcw_home, you think RTAI could do without scalbn?
[16:00:08] <memleak> just removing it?
[16:01:38] <pcw_home> I have no idea what RTAI needs but I would leave optimizations to the compiler
[16:02:11] <memleak> linuxcnc doesn't compile on 64-bit without -ffast-math i know that part
[16:02:16] <memleak> at least not with RTAI
[16:03:41] <pcw_home> I dont really know enough to comment but including that kind of code seems like a mistake to me
[16:04:47] <andypugh> So what _does_ line 1257 achieve then?
[16:05:20] <pcw_home> maybe someone was afraid to remove it (high magic)
[16:06:00] <memleak> i have no problem removing it, will do :)
[16:07:54] <memleak> heh i just got an email from paolo saying he was boggled on how i unified the 32/64-bit code
[16:08:52] <memleak> i figured he'd be making way more progress than i considering he knows the code better..
[16:12:30] <pcw_home> what does linuxcnc need from -ffast-math ?
[16:14:30] <memleak> apparently sincos which i know makes no sense.
[16:14:54] <memleak> it just works.. so much magic going on here i feel like a black mage
[16:16:06] <pcw_home> I've heard of the sincos thing before
[16:17:04] <memleak> most likely from me, i've been complaining a lot about it
[16:17:31] <pcw_home> where in the linuxcnc source is it used?
[16:17:48] <memleak> 5kinematics and several other drivers
[16:18:02] <memleak> git grep sincos look in hal/drivers i think...
[16:19:21] <memleak> i also had to hard-code -msse as opposed to making it a conditional for x86_64
[16:20:53] <pcw_home> is this used because there's some real time issue with math.h?
[16:21:05] <memleak> completely unrelated
[16:21:43] <pcw_home> but sincos is a normal math.h function
[16:22:01] <memleak> without those flags I get SSE return value without register.. something like that
[16:22:17] <memleak> SSE register return with SSE disabled
[16:22:22] <memleak> i was close..
[16:22:23] <pcw_home> yuck
[16:23:25] <memleak> yep and i'm not sure how stable it is to use -ffast-math
[16:28:41] <andypugh> I am puzzled as to why we seem to have multiple copies of the source tree now.
[16:28:52] <pcw_home> someone left some ifdef/ifndef sse's out
[16:30:34] <andypugh> It seems deliberate.
[16:30:50] <andypugh> Part of the "unified build" I suspect
[16:32:19] <pcw_home> Ha!
[16:35:20] <memleak> i'm on master branch.. should have mentioned that
[16:39:02] <andypugh> Doh! make[1]: *** No rule to make target `hm2_eth.0', needed by `modules'. Stop.
[16:39:16] <andypugh> It has taken me hours to spot that.
[16:40:04] <mozmck> heh! I've done that kind of thing plenty at times.
[16:41:57] <pcw_home> andypugh: (should you ever get it working) I find the 7I80 is really handy for testing since it can be anywhere
[16:42:56] <andypugh> it works through routers?
[16:45:14] <pcw_home> sure
[16:47:36] <pcw_home> I used to have one at fpga.mesanet.com but I changed the IPaddress to the default private one when I was testing the Fanuc stuff
[16:49:00] <andypugh> I guess that realtime performance suffers in that scenario? :-)
[16:49:11] <pcw_home> a bit...
[16:52:00] <pcw_home> also someone could download a bit file with 5000 ring oscillators and burn mesa down...
[16:53:52] <andypugh> And the insurance co would never believe that it wasn't you
[16:54:13] <pcw_home> Thats probably true :-)
[16:54:18] <andypugh> You can really do HCF with an FPGA?
[16:54:41] <pcw_home> Absolutely
[16:55:13] <mozmck> what is HCF?
[16:55:34] <pcw_home> Halt and Catch Fire
[16:55:56] <mozmck> haven't heard of that! halt what?
[16:56:34] <pcw_home> I think it was a 6800? undocumented instruction
[16:57:09] <andypugh> http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
[16:59:19] <andypugh> I think that "lp0 on fire" is still in the Linux kernel.
[16:59:51] <pcw_home> 1000s of ring oscillators or bogus bitfiles that short out 1000's of internal nodes are known ways of doing it with FPGAs
[17:00:59] <mozmck> interesting.
[17:01:16] <pcw_home> I think the original IBM monochrome monitor could be killed by setting a bad horizontal refresh rate in the CRTC
[17:01:40] <andypugh> I read somewhere of someone creating a genetic algorthithm for FPGA code, and got a really interesting and effective solution. But it had an area of unconnected nodes. But when he removed that section, it stopped working...
[17:03:18] <andypugh> pcw_home: Are you thinking of the Commodoer PET "killer poke" ?
[17:04:46] <pcw_home> This was for IBM but there could certainly be similar things for monitors that used horizontal drive
[17:05:02] <pcw_home> (vs horizontal sync)
[17:05:45] <pcw_home> since with horizontal drive you have pretty direct control of the horizontal output transistor
[17:22:11] <pcw_home> I noticed that RTNet was first developed on RTAI
[17:22:52] <andypugh> RTAI is an option in the build config. I am not sure why micges decided on Xenomai-only.
[17:22:54] <skunkworks> I remember being told to be careful with all monitors as far as setting the refresh rate...
[17:23:32] <skunkworks> I wonder if it was a hold over fromt he ibm monochrome
[17:23:46] <skunkworks> andypugh: thanks for playing with the 7i80
[17:24:02] <andypugh> skunkworks: Have you made it work?
[17:24:28] <andypugh> I am struggling with the #includes
[17:24:44] <skunkworks> I have been able to flip a gpio on 10.04 32bit..
[17:24:54] <andypugh> Hmm
[17:25:31] <skunkworks> On 12.04 - I get a missing symbol when I try to load the hm ethernet module
[17:25:42] <andypugh> Which flavour of LinuxCNC?
[17:26:00] <andypugh> I can't even get linuxcnc to compile
[17:26:47] <skunkworks> I just followed these directions - (added some comments)
[17:26:49] <skunkworks> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mesa7i80_Driver_For_Linuxcnc_On_Xenomai
[17:30:27] <andypugh> Which flavour of LinuxCNC?
[17:32:12] <andypugh> I suspect that I have exceeded my competence in trying to integrate it with the unified-build-candidate-2 branch.
[17:36:51] <skunkworks> $ git clone git://git.linuxcnc.org/git/linuxcnc.git linuxcnc-rtnet
[17:36:52] <skunkworks> $ cd linuxcnc-rtnet
[17:36:54] <skunkworks> switch to linuxcnc under xenomai development branch
[17:36:55] <skunkworks> $ git branch --track rtos-master-v0 origin/rtos-master-v0
[17:36:57] <skunkworks> $ git checkout rtos-master-v0
[17:38:36] <andypugh> I am not using rtos-master as I don't know where that is heading.
[17:39:01] <andypugh> Though that shouldn't be the problem, as my issue is with #include resolution.
[17:39:28] <skunkworks> I don't remember having any of those low level issues
[17:39:32] <andypugh> hm2_eth.c:174:5: error: implicit declaration of function ‘inet_aton’
[17:39:56] <skunkworks> did you get rtnet to install?
[17:40:06] <andypugh> Yes, no trouble there at all
[17:40:22] <skunkworks> did you try rtpinging the card?
[17:40:37] <andypugh> The problem is with #include <sys/socket.h>
[17:40:38] <andypugh> #include <netinet/in.h>
[17:40:39] <skunkworks> (loading all the rtmodules)
[17:40:39] <andypugh> #include <arpa/inet.h>
[17:40:54] <skunkworks> (that is above my pay grade)
[17:41:27] <andypugh> None of those exist in the Xenomai headers. They all have a </inux...> version, but the contents appear to differ.
[17:41:50] <skunkworks> what kernel - I have only used xenomi..
[17:41:55] <andypugh> The solution _might_ be symlinks to the places that do exist
[17:42:28] <andypugh> 3.5.7-xenomai-2.6.2.1
[17:42:57] <skunkworks> I could not get rtnet to build without the build symlink in the xenomai directory
[17:43:01] <skunkworks> As of 07/01/2013 to build rtnet the kernel headers need to be installed
[17:43:03] <skunkworks> $ sudo apt-get install linux-headers-3.5.7-xenomai-2.6.2.1
[17:43:04] <skunkworks> and a symlink pointing to them in a 'build' directory
[17:43:06] <skunkworks> $ sudo ln -s /usr/src/linux-headers-3.5.7-xenomai-2.6.2.1/ /lib/modules/3.5.7-xenomai-2.6.2.1/build
[17:43:17] <andypugh> Yes, I have all that
[17:43:20] <skunkworks> ok
[17:43:35] <skunkworks> (sorry if I am capt-obvious)
[17:43:53] <andypugh> This is a problem with LinuxCNC not being able to find (for example) <sys/sicket.h>
[17:44:09] <andypugh> Or, for that matter <sys/socket.h>
[17:52:25] <andypugh> Then the problem is <arpa/inet.h>. There is a /usr/include/arpa/inet.h and an absolute path to that gets a bit further, bit then that file #includes "features.h" and that isnt
[17:52:29] <andypugh> found either.
[17:52:45] <andypugh> I have no idea what the process is for untangling this sort of mess.
[17:53:46] <andypugh> memleak: Do you understand this sort of thing?
[18:01:10] <andypugh> It isn't that the files don't exist even, I have several off all of them:
http://pastebin.com/uhB81DA1
[20:01:24] <KimK_3> memleak: Hey, belated congratulations on your RTAI victory, great news!
[20:02:41] <KimK_3> Let me know if and when you have something you'd like me to try on an E350N.
[20:03:59] <KimK_3> Oops, should have done this first:
[20:04:12] <KimK_2> There we go
[20:38:32] <memleak> andypugh, understand what? sorry i just got back from a load road trip.
[20:38:44] <memleak> *long (and tired)
[20:39:17] <andypugh> I am not sure how to sort out the fact that hm2_eth can't find some #includes
[20:39:25] <andypugh> http://pastebin.com/uhB81DA1
[20:39:45] <andypugh> Shows that all the files exist in various (and very different) versions
[20:41:45] <andypugh> I can change the hm2_eth.c source file to point to a version of inet.h that _does_ contain the function protoype for inet_aton but then it falls over because _that_ file has a reference to features.h
[20:42:43] <andypugh> linux/inet.h is a very short file (mainly credits..) compared to arpa/inet.h
[20:42:48] <andypugh> (for example)
[20:43:20] <andypugh> So, the question is how you sort out this sort of tangle.
[20:44:01] <memleak> make sure the directories that the files are being included from are in the makefile
[20:44:42] <andypugh> I am not at all sure how I am meant to know which one I want...
[20:44:48] <memleak> for example if john_doe.h is in /johndoe you do something like -I/johndoe
[20:45:55] <memleak> and then in the file you put #include <john_doe.h> and it will find it because -I/johndoe is in the makefile.
[20:46:15] <andypugh> There are about 50 versions of socket.h (and with the original include line of #include <sys/socket.h> the compiler finds none of them)
[20:47:27] <andypugh> None of this is my code. It all ought to just compile (I should point out)
[20:47:43] <memleak> what are you trying to compile?
[20:48:12] <andypugh> LinuxCNC
[20:48:26] <memleak> maybe sys/socket.h isn't listed in a directory as specified in the -I part of the makefile
[20:49:01] <memleak> gcc can only find things with -I or -lm if it's a math library
[20:49:43] <andypugh> If you look at the pastebin, there are almost no versions of socket.h in a /sys/ directory
[20:50:27] <memleak> sys/socket.h is a glibc header IIRC.. let me check
[20:50:41] <memleak> yep.
[20:51:32] <memleak> i'd have to see the makefile to make sure the include directories are correct
[20:51:55] <andypugh> I am trying to compile the 7i80 support as detailed here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mesa7i80_Driver_For_Linuxcnc_On_Xenomai which (possibly unfortunately) is wedded to Xenomia.
[20:52:18] <memleak> gcc doesn't use find -name "<file>" to locate the #include files :P
[20:52:30] <memleak> it has to be told where it is. be cool though if it didn't.
[20:52:50] <andypugh> Well, given how many there are, it wouldn't know which one to choose.
[20:53:01] <andypugh> I was just trying to figure out how to help it find one.
[20:53:27] <andypugh> But _none_ of those look like the one that the author of hm2_eth had in mind.
[20:53:38] <memleak> no? how do you figure?
[20:54:02] <memleak> unless in the linuxcnc source there is a sys/socket.h file... which seems to be insane.
[20:54:24] <andypugh> Because the code says #include <sys/socket.h> and none of the ones I found with fine -name is in a sys folder
[20:54:28] <memleak> sys/socket.h should be somewhere in /usr/include as provided b glibc
[20:54:30] <memleak> *by
[20:55:05] <andypugh> The only one I have is /usr/include/i386-linux-gnu/sys/socket.h
[20:55:08] <memleak> /usr/include/xenomai/posix/sys/socket.h /usr/include/i386-linux-gnu/sys/socket.h
[20:55:25] <memleak> it's one of those two i would assume.
[20:56:03] <andypugh> Neither seem to make any sense to me.
[20:56:07] <andypugh> Why "posix"?
[20:56:49] <memleak> because socket.h is part of the POSIX library... i think..
[20:57:19] <memleak> yes it is!
[20:57:40] <andypugh> arpa/inet.h is more of a problem.
[20:57:55] <memleak> http://www.unix.com/man-page/posix/7posix/socket.h/
[20:59:01] <andypugh> linux.inet.h is basically empty. arpa/inet.h #includes features.h, and the compiler fallls over at that point.
[21:00:57] <andypugh> So,I need to mess with the makefile? That doesn't make much sense to me, as this was pretty much all just meant to work..
[21:00:59] <memleak> this all seems like a really simple makefile mistake. including headers should be easy as pie, let alone ones built into linux
[21:01:15] <memleak> linux meaning glibc or the kernel
[21:01:25] <memleak> does it compile for anyone else? i dont think it would..
[21:01:43] <andypugh> Apparently it did for Skunkworks
[21:02:24] <andypugh> But he applied the 7i80 patch on to a different branch
[21:02:31] <memleak> oh..
[21:02:37] <memleak> maybe thats why!
[21:02:51] <andypugh> Maybe, but why would it be that diffferent?
[21:03:12] <andypugh> We are both working with the same kernel and kernel headers
[21:04:22] <memleak> without seeing the makefile differences between his branch and yours, i can't help.. i'm really in the dark here.
[21:04:39] <memleak> diff -u and post output and i'll be more able to assist in debugging the issues.
[21:05:31] <memleak> maybe some other makefile is aggravating the 7i80 code in your branch but not in his? there could be a lot of different possibilities.
[21:06:20] <andypugh> Well, he was using rtos-master-vo:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/Makefile;h=976bb16a6c608ea71479cbc0d9c4f909be5521b2;hb=refs/heads/rtos-master-v0 and I am working in the rather newer unified-build-candidate-2:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/Makefile;h=28a8e596e4bbeffac50a71a41ee90cfabe407674;hb=refs/heads/unified-build-candidate-2
[21:07:47] <andypugh> And I don't see any -l of a "posix" path in the rtos-master-v0 Makefile.
[21:08:24] <andypugh> (And it isn't_my_ branch, I pulled it from the git server!)
[21:08:53] <andypugh> To be fair, it compiles perfectly until I patch it to add the 7i80 support
[21:10:55] <memleak> i'd run a git diff after applying the patch and pay close attention to the differences
[21:11:21] <memleak> git add -A && git diff HEAD
[21:12:00] <andypugh> The main difference is that it adds a new file called hm2_eth.c that contians three #include lines at the top that don't resolve.
[21:13:52] <andypugh> The patch file is here.
http://wiki.linuxcnc.org/uploads/hm2_7i80_support_on_rtos_merged_to_master.patch
[21:14:26] <andypugh> I suppose I should just try the patch on the branch it was meant for.
[21:14:34] <memleak> i'll try it here on unified-build-candidate one moment
[21:16:40] <andypugh> I doubt you will have much luck. You do need to do some stuff by hand, as the layout of the Hostmot2 section of the makefile has changed, and I doubt it will build at all without rtnet installed.
[21:17:11] <memleak> nevermind then.. heh
[21:17:44] <memleak> rtnet will be a bit of a project for me
[21:18:09] <andypugh> But I don't see anything in the patch that looks like it would help the makefile find the headers it is not finding.
[21:18:45] <andypugh> And a different LinuxCNC branch is not going to change the layout of the kernel headers
[21:19:17] <andypugh> But what the heck, I ought to try on the intended branch, I suppose.
[21:20:35] <memleak> if it works for him and not for you maybe your /usr/include dir got messed up or something, not sure.
[21:20:50] <memleak> that is, if it still doesnt work after applying it to the intended branch
[21:21:36] <andypugh> I was kind of hoping that there was a well-known process to sort this sort of thing out, that I was simply unaware of.
[21:22:07] <andypugh> It seems stupid to me that a single PC could have 50 versions of the same header file, all different.
[21:22:27] <memleak> most of the time its just copies
[21:22:59] <memleak> or so i thought.. i dont know
[21:23:23] <memleak> im not really in a work mode right now, RTAI has killed my brain atm.
[21:26:46] <andypugh> when it says The next patch would create the file scripts/start_net.sh, // which already exists! Assume -R? [n] is it meant to be obvious what -R does?
[21:28:08] <memleak> git reset --hard HEAD before patch or git apply
[21:28:35] <andypugh> I did, but the files in question are not tracked...
[21:29:03] <memleak> ah, rm -rf * && git reset --hard HEAD
[21:29:26] <andypugh> git clean might have been the right thing to do
[21:29:29] <memleak> -R = --reverse
[21:29:35] <memleak> there is a git clean!?!?!
[21:29:40] <andypugh> Yes
[21:29:57] <memleak> oh..
[21:30:03] <andypugh> http://linux.die.net/man/1/git-clean
[21:30:17] <memleak> thanks! i always use rm and reset xD
[21:30:57] <andypugh> Your way sounds more dangerous
[21:31:06] <memleak> it always is :P
[21:33:31] <andypugh> If this does compile I will be utterly baffled
[21:42:40] <andypugh> And, bizarrely, it _did_ compile without errors.
[21:42:48] <andypugh> <bsh>
[21:43:02] <memleak> i expected it, heh
[21:43:26] <memleak> you gotta look over the changes more closely and see what's wrong if you want to fix it.
[21:43:33] <memleak> a very careful inspection of the diff.
[21:43:47] <andypugh> I don't even know how to do a diff between branches
[21:44:24] <andypugh> And the unified build makefile is (I think) very different in lots of unrelated ways
[21:46:01] <andypugh> There is also no point at all in the 7i80 driver only working in a dead-end branch
[21:50:10] <memleak> what i would do is something like cp -pr git_tree1 git_tree2 && cd git_tree1 && git checkout <branch1> && apply patch command here && git add -A && git diff HEAD &> patched_7i80_1.diff && cd ../git_tree2 && git checkout <branch2> && apply patch command here && git add -A && git diff HEAD &> ../patched_7i80_2.diff
[21:50:18] <memleak> holy smokes that line..
[21:51:52] <memleak> then maybe a diff -u patched_7i80_1.diff patched_7i80_2.diff &> diff_7i80.diff and then opening diff_7180.diff with gedit or kate or something
[21:52:31] <memleak> it's hideous yes but i've used it to get the job done before
[21:53:11] <andypugh> I think I would rather just give up
[21:53:59] <memleak> well i can at least run a diff for you but i wont be able to test compilation
[21:54:22] <memleak> maybe if i took a look at it i could figure out the changes
[21:54:52] <andypugh> Well, as it is heading for 0400 I think my immediate plans revolve around sleeping
[21:55:12] <memleak> i wouldnt want to work on that tonight anyway but i could tomorrow
[21:56:07] <KimK_2> Andy, would cherry-pick help you at all?
[21:56:21] <pcw_home> If nothing more than RTNet worked with RTAI the rest should be standard
[21:56:31] <andypugh> The questions I now need to answer are things like, which is the correct rtnet module for my ethernet harware (no idea how to tell) and what is the IP address of my 7i80 (no idea how to tell)
[21:56:38] <andypugh> So I am going to give up.
[21:56:53] <andypugh> Goodnight all.
[21:57:04] <KimK_2> Goodnight , Andy
[21:57:36] <pcw_home> (the ipaddress is 192.168.1.121)
[21:57:46] <skunkworks> heh - I started typing that
[21:58:15] <pcw_home> or whatever you set it its EEPROM
[21:59:06] <skunkworks> I remember there being 3 options..
[21:59:24] <pcw_home> mode0 = 192.168.1.121
[21:59:26] <pcw_home> mode1=EEPROM
[21:59:27] <pcw_home> mode2=bootp
[21:59:29] <pcw_home> mode3=DHCP eventually
[21:59:31] <skunkworks> bootp...
[22:00:20] <pcw_home> I just doubled the ROM space so I have a luxurious 4K instructions now
[22:00:48] <skunkworks> on the new boards? or a config thing
[22:01:03] <pcw_home> just a config thing
[22:01:14] <skunkworks> nice
[22:01:28] <memleak> pcw_home, does rtnet not work with RTAI??
[22:02:05] <pcw_home> micges had trouble and it worked easier on xenomai so he went that way
[22:02:13] <skunkworks> I think the only reason why rtnet for mesa wasn't tried was there was no rtnet for 12.04...
[22:02:29] <skunkworks> *rtai
[22:02:43] <pcw_home> RTnet was originally written for RTAI
[22:46:23] <memleak> thats what i thought..
[22:46:32] <memleak> hard to imagine it'd be broken now.
[22:46:56] <memleak> unless xenomai took it over..
[22:56:42] <pcw_home> the 7I80 only uses a minor subset of RTnet anyway just the RT aspect (no TDM/live config/etc)
[22:57:28] <pcw_home> its just straight UDP but needs it to be real time
[23:04:53] <pcw_home> I should note that theres an alternate sserial naming mode that allows you to swap cable s with no bad side effects
[23:41:07] <pcw_home> oops
[23:49:43] <memleak> hello mhaberler, do you know what happened to xenomai-user.{c,h} ?
[23:50:02] <mhaberler> what are you referring to?
[23:50:32] <memleak> is xenomai.c for example just xenomai-user.c that was renamed?
[23:50:55] <memleak> i recall xenomai having two separate thread systems in linuxcnc
[23:51:55] <mhaberler> the comments on the top of src/rtapi/xenomai.c tell it
[23:52:16] <mhaberler> xenomai-kernel.c is xenomai kernel threads support
[23:53:11] <memleak> xenomai.c is userland then, thanks
[23:54:02] <memleak> is a rt-preempt-kernel set up possible?
[23:55:28] <memleak> if so would it be meaningful at all or no?
[23:56:00] <mhaberler> rt-preempt is hardened userland threads, so that doesnt make sense
[23:56:25] <memleak> I was wondering why it wasn't implemented, thanks.