Back
[00:22:14] <zultron> Who says the DeLorean isn't a time machine? Every time I'm around one, I'm temporarily transported back a few decades to a time of big hair and shoulder pads.
[00:30:38] <zultron> Yuk, yuk:
http://tinyurl.com/m89qdsa If you zoom, the number of DeLoreans in the lot changes.
[03:38:57] <KGB-linuxcnc> 03Chris Morley 05master fd8f0ef 06linuxcnc 10src/emc/usr_intf/stepconf/build_HAL.py 10src/emc/usr_intf/stepconf/build_INI.py 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf -fix input output signal search to include parport 2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fd8f0ef
[03:44:24] <KGB-linuxcnc> 05stepconf-GTK-builder b8675d9 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8675d9
[13:43:54] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 8eafe3c 06linuxcnc 10README remove obsolete Mission Statement from README * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8eafe3c
[14:11:31] <seb_kuzminsky> zultron, CaptHindsight, i'm trying to build master on debian wheezy on arm (beaglebone black), and i'm getting this error:
http://pastebin.ca/2534145
[14:11:55] <seb_kuzminsky> i bet this is something that's been solved in the ubc3 branch, but didn't get pushed back to master? any advise for me?
[14:12:04] <seb_kuzminsky> building sim btw
[14:57:53] <seb_kuzminsky> did you guys switch to gcc built-in functions?
[16:58:39] <cradek> I'm a little sad to see that mission statement go. We actually accomplished the things on it.
[16:58:57] <cradek> (it was a simpler time...)
[17:06:54] <seb_kuzminsky> sad in a wistful reminiscent way or in a "seb made a bad commit" way?
[17:11:40] <andypugh> "LinuxCNC: Making code to make stuff."
[17:12:43] <andypugh> A friend had a company mission sstatement: "XXX Consulting: We do stuff for money"
[17:17:30] <seb_kuzminsky> the old README Mission Statement seems like more of a todo list
[17:17:44] <seb_kuzminsky> a catchy slogan like andypugh's might be a fun idea
[17:19:28] <andypugh> It's only any good if it is done ironically, though. And it is a commonly believed fact that Americans think that "irony" has a similar meaning to "silvery" or "steely"
[17:20:31] <seb_kuzminsky> i can't tell if you're serious or not
[17:20:38] <seb_kuzminsky> you have to steel yourself for andypugh's irony
[17:21:30] <andypugh> Now I find myself wondering if you are double bluffing by ironically acting confused about irony. Argh!
[17:21:58] <seb_kuzminsky> http://static3.wikia.nocookie.net/__cb20110707200453/memoryalpha/en/images/5/5d/Lal_female.jpg
[17:23:25] <andypugh> I borrowed the phrase "commonly believed fact" from a friend who is technically American. I rather like it.
[17:25:48] <andypugh> my wittering here is due to me watching a slow kernel compile scroll by.
[17:30:08] <seb_kuzminsky> your udoo isn't mercurial enough for you?
[17:31:39] <andypugh> Not the number of compiles I am doing. There is a cross-compiler but that just seemed likely to add places to go wrong.
[17:32:16] <andypugh> And it isn't awful. In fact it is a lot faster than the Dual Xeon server that I first compiled RTAI on.
[17:32:25] <andypugh> (Gen 1 Xeons, that is)
[17:33:39] <seb_kuzminsky> i want to stand up an ARM virtual machine for the buildbot, rather than have a shelf full of shitty little embedded computers
[17:34:20] <andypugh> I wonder if Yocto would be any help there?
[17:38:04] <andypugh> Just trying to figure out what the 1U server running my lathe really is. It looks like dual "Prestonia" Xeons, which are P4. There is a warning "Intel Server Board SE7501CW2 is designed to provide up to 65A per processors. Processors with higher current requirements are not supported." I have to say that 65A seems like really quite a lot of current.
[17:40:32] <skunkworks> I wonder if they got W and A mixed up
[17:42:03] <andypugh> They run at 1.5V so the numbers are similar.
[17:43:04] <andypugh> 85W CPUs
[17:45:02] <andypugh> Interesting to look at the Xeon power requirements, they build steadily up to Xeon 7020 "Paxville" at 165W and then start to ramp down again
[17:50:29] <andypugh> Somebody at Freescale like if - else constructions without brackets. I am not sure I like that
[17:51:25] <andypugh> Especially with multi-line conditions and multi-line statements.
[17:52:15] <seb_kuzminsky> linuxcnc-build: force build --branch=master checkin
[17:52:16] <linuxcnc-build> build #1668 forced
[17:52:16] <linuxcnc-build> I'll give a shout when the build finishes
[19:18:23] <linuxcnc-build> Hey! build checkin #1668 is complete: Success [3build successful]
[19:18:23] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1668
[19:41:45] <andypugh> Oh dear. I have a file that is making my compile fail. I suspect that the code I need is masked by an #ifdef. But the file has an awful lot of those. Does anyone know of a way to untangle them?
[19:42:08] <andypugh> My brain is too small to tag them internally
[19:45:15] <alex_joni> andypugh: unfortunately no.. except adding some obvious parse errors in there, and trying to compile
[19:46:25] <andypugh> How about if I just move the code I know i need to after the last #endif ?
[19:46:40] <alex_joni> that should work too :D
[19:47:10] <andypugh> (sadly not really an option as this might want to push upstream, and it is kernel code)
[19:50:28] <andypugh> http://pastebin.com/DMBetBdF I think something is "turning off" dma_alloc_writethrough
[19:51:54] <alex_joni> I don't see any ifdef's around it
[19:52:21] <alex_joni> except the #ifdef __KERNEL__
[19:52:38] <alex_joni> but I assume you compile with -D__KERNEL__
[19:53:06] <andypugh> No.
[19:53:19] <alex_joni> or from the kernel makefile then?
[19:53:42] <andypugh> I am not adding anything other than ARCH=arm
[19:54:32] <andypugh> I have compiled and run this kernel, but then I have run 3 xenomai patches.
[19:54:43] <alex_joni> if you compile a regular kernel and/or module it all does get added automatically
[19:55:00] <andypugh> And those patches might well introduce dependencies
[19:55:01] <alex_joni> can you pastebin them?
[19:55:30] <alex_joni> not that I'll spot anything at 4am.. but worth a shot :D
[19:55:44] <andypugh> I don't really know enough to understand your questions
[19:56:37] <andypugh> But, yes this git checkout compiles and makes a bootable kernel for the board in question.
[19:59:28] <andypugh> Since then I have applied an adeos-ipipe...pre.patch (partly manually as the kernel versions are not an exact match) then the "real" xenomai patch via the (prepare_kernel script) then I habe (partly manually) applied the adeos-ipipe...post.patch to get the kernel back to a compilable state (again, rather manually, as 70% of the changes were already there)
[20:02:00] <andypugh> The error is
[20:02:01] <andypugh> drivers/built-in.o: In function `fec_probe':
[20:02:02] <andypugh> bufp.c:(.devinit.text+0x4b04): undefined reference to `dma_alloc_noncacheable'
[20:03:00] <andypugh> (which doesn't do well on reporting complete paths)
[20:06:25] <Tom_itx> would grep help there?
[20:07:54] <andypugh> Maybe.
[20:08:29] <andypugh> ls -r | grep filename?
[20:09:03] <Tom_itx> you know more about linux than i, sir
[20:09:15] <andypugh> No, really, I don't
[20:09:25] <Tom_itx> umm i'm pretty confident of that
[20:09:46] <andypugh> You knew enough to suggest grep.
[20:10:01] <Tom_itx> i use grep on windows and use -flp alot
[20:10:11] <andypugh> I have no idea if ls even takes a -r switch
[20:10:19] <Tom_itx> recursive
[20:10:23] <Tom_itx> pretty sure
[20:10:26] <Tom_itx> or -R
[20:11:12] <andypugh> IMAC:Kernel_Unico andypugh$ ls -R | grep bufp.c
[20:11:13] <andypugh> bufp.c
[20:11:43] <andypugh> yes, thankyou. I was hoping for rather more of a clue as to where
[20:11:52] <atom1> good luck
[20:12:30] <andypugh> find is probably what I need.
[20:12:51] <andypugh> I hadn't made the mental switch out of Eclipse
[20:13:13] <Tom_itx> grep does good for finding lines in files
[20:16:49] <andypugh> That's a worry, buffp.c is a symlink
[20:18:16] <andypugh> I don't even want to think hoe #includes work through symlinks
[20:18:38] <andypugh> what path do they use? relative to which?
[20:19:50] <Tom_itx> i know little or nothing about simlinks
[20:19:57] <Tom_itx> other than they exhist
[20:20:49] <andypugh> This looks like a puzzle for another day.
[20:21:09] <andypugh> Night all
[20:21:14] <Tom_itx> ls -l will tell you
[20:21:16] <Tom_itx> where it points to
[22:19:18] <skunkworks> I have never seen the issue where axis shows the new program but runs the old...
[22:19:36] <skunkworks> I have seen it where it will run the newly saved program without reloading..
[22:21:57] <Tom_itx> that doesn't sound so good
[22:59:18] <seb_kuzminsky> skunkworks: i've never seen it either, and i often use the 'edit, reload' cycle
[23:00:00] <cradek> I fished for a real bug report
[23:00:03] <cradek> *sigh*
[23:00:58] <cradek> it's sure that if you update the file on disk and don't hit reload, the preview will be out of date
[23:33:08] <seb_kuzminsky> yeah that's unfortunate
[23:34:11] <seb_kuzminsky> when the user hits Run, axis could check if the mtime of the file differs from what it was the last time the file was loaded
[23:34:20] <seb_kuzminsky> and, um, warn or complain or something
[23:34:41] <seb_kuzminsky> or axis could stash away a copy of the file on Load, and pass the stashed file to Interp on Run
[23:37:13] <cradek> I'd rather it complain, I guess
[23:37:23] <cradek> but I wonder if that's what he's talking about.
[23:42:55] <seb_kuzminsky> yeah who know what he's talking about, he's sure not telling us
