Back
[00:51:46] <dgarr> cradek: if it helps with naming, i modified so ttt does not appear:
http://filebin.ca/zyccea/modified-truetype-tracer.c
[00:51:47] <dgarr> cradek: and a patch from several months ago for params-to-pins
http://filebin.ca/qugmwy
[00:57:22] <dgarr> that needed to be deferred till 2.3
[01:05:39] <jepler> the hal_input patch looks fine to apply
[01:17:59] <jepler> that reminds me, how does anyone feel about 2.3.1? this weekend or next weekend? either way, I'd like to do it before fest
[01:19:14] <cradek> I'd like to hear jmkasunich's ideas about increasing the hal shmem size for 2.3.1
[01:19:41] <cradek> (or, making it configurable at runtime somehow)
[01:20:08] <jmkasunich> I am unaware of any issues with changing the size
[01:20:13] <cradek> also, yay us for NOT putting the spline/nurbs patch in 2.3
[01:22:18] <cradek> jmkasunich: so you recommend yes?
[01:22:37] <jmkasunich> I guess so
[01:23:05] <jmkasunich> "unaware of problems" is not the same as "there are no problems"
[01:24:11] <jepler> is it on trunk yet?
[01:24:29] <jepler> put it on trunk now, give it a week for somebody to run into problems. I'll plan on 2.3.1 next week (16/17th)
[01:24:31] <cradek> no I haven't done anything except help the user make the change
[01:25:00] <jmkasunich> micges did say he ran a larger size with no problems
[01:25:04] <cradek> yes
[01:25:13] <jmkasunich> I wonder if he was running our kernel?
[01:25:16] <cradek> yes
[01:25:41] <jmkasunich> ISTR some people who built their own kernels didn't have enough shared memory for even the old size
[01:26:00] <cradek> I know nothing about that
[01:26:29] <jmkasunich> some kernel build-time param sets a ceiling on the block of memory that can be used as shared memory
[01:26:37] <jmkasunich> they had a very small value for that param
[01:26:47] <jmkasunich> we obviously have it bigger, but I have no clue how much bigger
[01:26:52] <cradek> if it works with ours, anyone else's is a configuration problem IMO
[01:26:55] <jmkasunich> micges's case is a good test
[01:27:00] <jepler> kernel? rtai?
[01:27:10] <jmkasunich> jepler: NFC
[01:27:11] <jepler> there's the userspace "locked memory" limit
[01:27:22] <jepler> but that's fixable without recompiling anything
[01:28:51] <jmkasunich> I don't remember the problem, or the solution, only that it happened - I probably read it on IRC at some point
[01:29:03] <jmkasunich> doesn't matter - if our kernel works, do it
[01:33:26] <jmkasunich> I think making the size run-time configurable would be best left to 2.4
[01:33:42] <jepler> I agree with that
[01:33:48] <jepler> it won't be a 2-liner change
[01:33:53] <jepler> I'm much happier with a smaller change
[02:10:33] <LawrenceG> what options does one normally use to get readable diff.... diff -r dir1 dir2???
[02:20:00] <jepler> "diff -u" (unified) is the type of diff most often used
[02:21:39] <jepler> if you're using cvs, then use "cvs diff", it takes care of recursion and what to diff against (the version you last checked out, by default)
[02:21:53] <jepler> other nice flags are -N (new files) and -p (show C function)
[02:23:15] <jepler> you can put them in your ~/.cvsrc file. One of the lines in my ~/.cvsrc is: diff -uNp
[02:25:32] <LawrenceG> thanks Jeff, I am comparing two versions of expanded tar projects looking for changes... I have used -Naur before, but the a is bad as it treats all files as ascii
[02:47:18] <jepler> sounds like you know all my tricks
[06:57:32] <micges> logger_dev: bookmark
[06:57:32] <micges> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-05-08.txt
[07:55:45] <Lerman> Lerman is now known as lerman
[11:12:29] <alex_joni> wow, that pkm machine with emc2 looks really great
[11:12:35] <alex_joni> they even did a nice vismach
[11:18:35] <micges> yes indeed its cool
[11:21:19] <micges> maybe we build such prototype, it will be challenge
[11:30:13] <skunkworks405> link?
[11:31:22] <skunkworks405> ah - on the list
[12:36:34] <skunkworks> logger_dev: bookmark
[12:36:34] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-05-08.txt
[12:39:58] <skunkworks> alex_joni: where are are seeing images of the pkm?
[12:43:44] <alex_joni> skunkworks: in the pdf anders sent me
[12:49:31] <skunkworks> ah
[12:54:14] <skunkworks> Good morning
[13:07:40] <cradek> hi all
[13:08:06] <cradek> jepler: did you review and/or commit all dgarr's patches yesterday? I got distracted.
[13:41:14] <jepler> cradek: no, I only committed the emcrsh patch
[13:41:18] <jepler> the hal_input patch I glanced at but didn't apply
[13:55:59] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[14:05:30] <BJT-Work> jepler: do I need to be using 8.04 for trunk documents now?
[14:29:44] <jepler> BJT-Work: yes, basically
[14:30:06] <jepler> BJT-Work: well, you can continue using 6.06 if you want, and as long as the document hasn't been edited in 8.04 yet, but I assumed you were eager to change
[14:31:52] <BJT-Work> not really cause then I have to use two computers for documents
[14:37:26] <jepler> how will we ever change to a newer version of lyx, then?
[14:40:36] <SWPadnos> fire BJT-Work
[14:41:04] <SWPadnos> maybe when 10.04 comes out, we can eliminate support for anything earlier
[14:42:00] <SWPadnos> incidentally, my Jaunty PC has been perfectly stable on the stock kernel, so I'm thinking it's something in the -rt and -rtai kernels that was causing the crashes
[14:42:50] <jepler> might manually running lyx2lyx to get version 221 in v2_3_branch be acceptable?
[14:44:21] <jepler> It seems unlikely that we'll drop support for 8.04 just because 10.04 comes out -- we didn't do that with 6.06
[14:46:03] <BJT-Work> lyx2lyx would change 2.3 to the 8.04 version of lyx?
[14:47:19] <jepler> I was suggesting this workflow: edit both 2.3 and TRUNK on 8.04. Before committing to 2.3, manually run lyx2lyx to get version 221 (6.06-compatible) files. (make will complain if you don't do this, so there's an easy way to check)
[14:52:32] <jepler> here's another alternative: edit 2.3 and TRUNK with 6.06, then when the 2.3 cycle is done, edit 2.4 and TRUNK with 8.04
[14:53:04] <jepler> we'll always be a few years behind on lyx, but maybe that's the best we can do
[14:55:01] <jepler> huh, that's new to me -- sets of 3 matched memory modules. are there systems where this is the best setup for performance?
[15:01:50] <BJT-Work> I'll edit 2.3 and trunk with 6.06 for now
[15:03:39] <jepler> OK, I'll change the configure script back to the way it was, so that 6.06 is OK and it warns about editing with 8.04.
[15:03:48] <BJT-Work> ok, thanks
[15:08:22] <jepler> that should do it ..
[15:08:30] <CIA-67> EMC: 03jepler 07TRUNK * 10emc2/src/ (configure configure.in):
[15:08:30] <CIA-67> EMC: bjt wants to continue editing docs on ubuntu 6.06 for now, so make that OK
[15:08:30] <CIA-67> EMC: the infrastructural changes will remain, so we can revisit this decision later
[15:08:30] <CIA-67> EMC: after we drop dapper support in the stable version
[15:13:17] <BJT-Work> thanks jepler
[15:15:06] <jepler> you're welcome
[15:17:24] <jepler> hi seb
[15:17:27] <seb_kuzminsky> hola
[15:17:45] <seb_kuzminsky> check out this 3d printer - it prints buildings:
[15:17:46] <seb_kuzminsky> http://www.shapeways.com/blog/archives/217-3D-printing-buildings-interview-with-Enrico-Dini-of-D_Shape.html
[15:19:12] <jepler> I need one!
[15:20:23] <seb_kuzminsky> does it sound to you like Frank Tkalcevic has a badly tuned spindle rather than a bug in hm2 encoder velocity?
[15:23:27] <jepler> seb_kuzminsky: I haven't read the thread closely enough to say
[15:23:37] <skunkworks> na - we need to be green.. Shape living plants/trees into the shapes of buildings
[15:25:00] <jepler> seb_kuzminsky: it might be interesting to get a plot from cradek of his hm2 spindle velocity
[15:30:32] <jepler> seb_kuzminsky: if your offer to bring stuff from sparkfun to fest is still open, can you get me a
http://www.sparkfun.com/commerce/product_info.php?products_id=8548 ?
[15:31:05] <cradek> I can help test this weekend - but probably Sunday
[15:33:41] <seb_kuzminsky> thanks cradek
[15:33:57] <SWPadnos> oooh, seb_kuzminsky - can you bring me one of each of these:
http://www.sparkfun.com/commerce/product_info.php?products_id=9140 http://www.sparkfun.com/commerce/product_info.php?products_id=9194
[15:33:58] <seb_kuzminsky> sure jepler, i can bring you one/some of those
[15:34:03] <SWPadnos> I'm easy to please :)
[15:34:06] <jepler> seb_kuzminsky: I only need one, thanks
[15:34:27] <SWPadnos> hmmm. maybe toss a microUSB cable in there for me too :)
[15:34:31] <jepler> hm, this is an unusual construction of a D4:
http://www.dicecollector.com/LOOSE_D4_US_PATENT_1,030,554.jpg
[15:34:42] <jepler> (from
http://www.dicecollector.com/DICEINFO_WHAT_SHAPES_DO_DICE_HAVE.html )
[15:34:48] <SWPadnos> heh
[15:34:57] <seb_kuzminsky> argh dnd flashback
[15:35:26] <seb_kuzminsky> ok so i got orders for two micro-usb cables and one of each of those two jumper cable kits
[15:36:21] <seb_kuzminsky> man ths shipping & handling's gonna kill you guys
[15:36:22] <SWPadnos> yep (so far :) )
[15:36:36] <SWPadnos> hey, I thought it was a flat rate of one beer! :)
[15:36:44] <SWPadnos> per person
[15:36:45] <seb_kuzminsky> per jumper cable ;-)
[15:37:01] <SWPadnos> well, a pint has hundreds of sips in it ;)
[15:37:22] <seb_kuzminsky> sparkfun's right next to my parents house, i'll pick it up next week when i go over there
[15:39:20] <seb_kuzminsky> SWPadnos: the jumper cables are listed as out of stock, but maybe you'll get lucky
[15:39:42] <SWPadnos> ok, no biggie, they're just a pretty good deal there
[15:43:40] <jepler> they have trouble keeping them stocked
[15:43:43] <jepler> must be a popular item
[15:44:18] <jepler> (I thought they had a few hundred just the other day!)
[15:45:05] <SWPadnos> I didn't notice the stock levels when you first pointed them out to me
[16:24:27] <alex_joni> seb_kuzminsky: that pdf is 34$ from springer
[16:25:15] <seb_kuzminsky> hm, maybe it's letting me get it from here at the university because there's some sort of group subscription?
[16:26:01] <cradek> you .edu folks have special powers.
[16:29:44] <seb_kuzminsky> http://highlab.com/~seb/emc2/Desktop-3-Axis-Parallel-Kinematic-Milling-Machine.pdf.torrent
[16:30:20] <seb_kuzminsky> not sure if that'll work or what
[16:30:30] <SWPadnos> I think we should frown on that actually
[16:30:56] <SWPadnos> if it's copyrighted and not allowed to be distributed freely, we shouldn't be talking about it or posting it here
[16:31:19] <SWPadnos> err, talking about posting it, that is (of course we can discuss copyrighted works as much as we want :) )
[16:31:28] <seb_kuzminsky> hm, guess you're right :-(
[16:31:37] <seb_kuzminsky> but... information *wants* to be free!
[16:32:40] <cradek> in the wake of the current post-9/11 economy ...
[16:33:39] <cradek> academic papers seem like they "want" to be free even more than most things. I don't like when I can't see that stuff.
[16:36:28] <steves_logging> steves_logging is now known as steve_stallings
[16:37:21] <steve_stallings> Sounded neat, then I found out it was a 3 DOF mechanism. Still valid to demo kinematics, but not nearly so attractive as a demo machine at trade shows.
[18:53:36] <steve_stallings> steve_stallings is now known as steves_logging
[21:36:53] <alex_joni> good night all
[21:53:53] <jepler> see you alex_joni
[22:57:26] <jepler> I did a little research into rtai allocation limits
[22:58:19] <jepler> the kernel seems to have two main allocation methods: kmalloc and vmalloc. kmalloc allocates memory that is contiguous in physical address space, and is limited and may fail when memory is fragmented. it's limited to 128k in any case.
[22:58:44] <jepler> vmalloc manipulates the kernel address space to give memory that may be physically fragmented but is virtually contiguous. it has no set small limit.
[22:59:11] <jepler> the rtai we ship now defaults to using vmalloc, so we shouldn't encounter limitations of this type
[22:59:28] <jepler> the next limit we know about is the user max locked memory, and we know how to increase it on ubuntu (a file in /etc)
[22:59:36] <jepler> so from that point of view, I feel comfortable about increasing the hal allocation
[23:00:07] <jepler> I still want it put on trunk first, and then to do a release next weekend (5/16-17) with the larger size if no problems turn up
[23:00:14] <jepler> .. and I'm expecting somebody else to be the one who actually checks in the change :-P
[23:00:39] <jepler> http://kerneltrap.org/node/4020
