Back
[00:00:39] <jmkasunich> any new and interesting projects
[00:00:41] <jmkasunich> ?
[00:00:58] <jepler> none at the day job
[00:01:05] <jepler> there's emc2 stuff I'd like to work on but don't get around to
[00:01:20] <jmkasunich> day job projects are rarely that interesting
[00:01:26] <jmkasunich> (unless you are really lucky)
[00:01:33] <jmkasunich> I was thinking more of the kind of stuff you blog
[00:01:40] <jepler> this year has been way less interesting than most
[00:02:14] <jepler> (except for one project which I poached last fall, and wrote in Python in days instead of the weeks that was on the schedule---that was fun and felt good)
[00:02:37] <jepler> I have some flower and insect macrophotography I should put up on my blog
[00:03:03] <jmkasunich> speaking of quickly written python.. was that lyx depends parser something you already had? or did you write it very quickly?
[00:03:12] <jepler> I wrote it
[00:03:36] <jepler> there's probably stuff it's not aware of, it's so very simplistic
[00:04:07] <jmkasunich> as long as it handles images and multiple levels of includes its good enough
[00:04:22] <jepler> yep, it does both of those
[00:05:02] <jmkasunich> would it make sense to remove the "false" from the build_docs=no side of the if, and add docs to the default target?
[00:05:31] <jmkasunich> or should we leave it as a special purpose target?
[00:06:14] <jepler> I think it depends on two things .. how often we expect docs to change, and how long it takes to build, and how many people will be building it.
[00:06:17] <jepler> three things.
[00:06:36] <jmkasunich> 1) fairly often I hope
[00:06:44] <jmkasunich> 2) 30 seconds or so on my box
[00:06:58] <jepler> many developers will feel their time is wasted if 'make' takes a minute longer after every other 'cvs up'
[00:07:04] <jmkasunich> 3) docs reviewers, and package builders
[00:07:08] <jepler> 45 seconds here
[00:07:20] <jepler> 3) and anyone who just happens to have those packages installed
[00:07:40] <jepler> if we add a --{enable,disable}-docs target (I don't care what the default is) then everyone can be happy
[00:07:59] <jmkasunich> my 3 listed those who needed it, not the ones who would get it whether they want it or not
[00:08:01] <jepler> if you have those tools installed but don't want to wait, just --disable-docs
[00:08:10] <jmkasunich> right
[00:08:34] <jmkasunich> actually, very easy too, just set the initiual value of BUILD_DOCS to no, and none of the tests will even happen
[00:08:38] <jepler> yes
[00:08:55] <jmkasunich> I'd default it to yes
[00:09:09] <jepler> agreed
[00:09:16] <jepler> I'd be happy to do it
[00:09:31] <jmkasunich> that would be great, thanks
[00:11:13] <jmkasunich> have to drill some holes, back in a bit
[00:27:32] <jmkasunich> did you intend the option to be --disable-build-documentation, or --disable-documentation?
[00:35:12] <jepler> oops, I wrote it wrong in the changelog
[00:35:17] <jepler> well, I don't care what it is
[00:35:18] <jmkasunich> no biggie
[00:35:24] <jepler> it's whatever it is
[00:35:40] <jmkasunich> its the -build- one
[00:47:23] <jmkasunich> to make the deb install the docs, I assume I need to add "usr/share/docs/emc2/EMC2_Users_Manual.pdf" and "usr/share/docs/emc2/HAL_Users_Manual.pdf" to debian/emc2.files, right?
[00:47:42] <jmkasunich> something tells me I need to add to "debian/rules" too...
[00:49:22] <jmkasunich> maybe not.. but something has to tell it where to get the pdf's from
[00:50:37] <jepler> that would be the 'make install' target, I guess
[00:51:12] <jepler> looks like you just add it to DOCS= in the src/Makefile
[00:51:17] <jepler> unless we've used that variable twice now
[00:51:20] <jepler> (hope not)
[00:51:32] <jmkasunich> If I remove usr/share/docs/emc2/Hal_Introduction.pdf from the emc2.files list, will that remove any pre-existing (and now obsolete) file by that name? or just no longer install it?
[00:53:38] <jepler> when the next .deb goes out it will remove any old Hal_Introduction.pdf that was there ... I think
[00:53:57] <jmkasunich> cool
[00:54:53] <jmkasunich> DOCS is only used that one place
[01:25:26] <jmkasunich> cradek: does it look like I did the deb/install stuff right?
[01:26:32] <cradek> I think so
[01:26:47] <cradek> I'm sure there will be a few things to fix in the packaging when we branch 2.1
[01:26:53] <jmkasunich> I guess we find out later
[01:26:56] <cradek> not much point in worrying about it before then I think.
[01:27:10] <cradek> but it does look right from here.
[01:27:26] <jmkasunich> * jmkasunich pats himself on the back
[01:27:31] <jmkasunich> (jepler helped)
[01:27:55] <tfmacz> Chris...has there been any discussion about a realtime smp kernel? Would there be any advantage to using a multi processor machine or a a dual-core ???
[01:28:58] <cradek> I think rtai can do some interesting things with dual cores, but it would take a special kernel build, something you would have to do yourself
[01:29:13] <cradek> I think, but am not sure, that it can run realtime on one core and nonrealtime on the other
[01:29:59] <jmkasunich> EMC (rtapi actually) attempts to put all realtime code on the same CPU
[01:30:14] <cradek> oh it does?
[01:30:17] <jmkasunich> the other one hopefully winds up running your user space stuff, and you get better latency
[01:30:22] <jmkasunich> but that is totally untested
[01:30:26] <cradek> how does it control that?
[01:30:47] <cradek> I thought it takes a special rtai build (ISOLCPUS or something like that)
[01:30:48] <jmkasunich> (there is an argument to the rtai "create_task" call that lets you set CPU affiinity
[01:31:00] <jmkasunich> yes, the kernel need to support SMP
[01:31:06] <cradek> right
[01:31:06] <jmkasunich> which is why its untested
[01:31:15] <cradek> tfmacz: as you can see this is new territory
[01:31:26] <tfmacz> I thought so
[01:31:27] <jmkasunich> but _if_ you have an SMP rtai, rtapi will use the first CPU for the realtime tasks
[01:32:02] <cradek> I have a second PIII coming for my mill's machine that may work so I might play with it sometime soonish
[01:32:13] <tfmacz> I have a few multi processor machines kicking around and wondered if there was any point.
[01:32:21] <cradek> however I've tried a few processors in it and not had good luck getting one to work yet
[01:32:26] <cradek> (it's old)
[01:32:56] <jmkasunich> cradek: I have a couple SMP boxes, but I have neither the time or the motivation to compile an SMP kernel
[01:33:06] <cradek> yeah.
[01:33:13] <jmkasunich> maybe I'll bring one to next years CNC workshop
[01:33:29] <cradek> maybe I'll have time to play with mine by then
[01:34:07] <tfmacz> I have a couple Dell PE2300 server boxes with dual 900 mhz PIIIs
[01:34:27] <cradek> cool
[01:34:38] <jmkasunich> mine are dual 600MHz PIIIs, HP boxes
[01:34:43] <cradek> mine is a PIII 667 and I've bought a second processor on ebay ($5)
[01:35:51] <cradek> I think it'll take up to 933s but they cost more than $5...
[01:36:02] <jmkasunich> and then you'd need 2
[01:36:02] <tfmacz> Thanks anyway, I am a user not a programmer and compiling a regular kernel seemd more than I wanted to try so an smp realtime kernal is beyond me.
[01:36:13] <cradek> jmkasunich: yeah
[01:36:44] <cradek> tfmacz: I understand completely
[01:37:46] <tfmacz> But, I will say it agian, Thanks bundles to you guys for all the work. This is a great package.
[01:38:05] <cradek> I appreciate that, thanks
[01:39:13] <jmkasunich> thank you
[13:46:25] <jepler> I wrote this code but haven't been able to test it. It's intended to increase the throughput of trajectory items through 'task' to realtime. halscope suggests there is a modest benefit.
http://emergent.unpy.net/files/sandbox/eager.patch
[15:54:54] <cradek> jepler: looks simple enough, why not check it in?
[17:10:02] <alex_joni> jepler: any reason behind removing the endTime for 2.2. kernels?
[17:53:51] <jepler> alex_joni: I could not find any way that define would actually be #define'd
[17:55:24] <alex_joni> jepler: guess I don't quite get what it was supposed to do anyways