Back
[00:21:12] <jmkasunich> sorry, was away eating
[00:24:56] <jmkasunich> strange, it accepted rtl and mbuff, but rejected rtl_time
[00:26:37] <jepler> if it's a typo, I don't see it
[00:26:58] <jepler> move "rtl" after "rtl_time"
[00:27:05] <jepler> there's a bug if one module name is the prefix of another
[00:27:23] <jepler> it finds "rtl" and checks that the following is ".o"
[00:27:29] <jmkasunich> ah
[00:27:39] <jmkasunich> so rtl should be the last of the rtl_ ones
[00:27:51] <jepler> I think so
[00:28:31] <jepler> it worked for me because I wasn't running RIP -- your EMC2_MODULE_DIRECTORY was probably something different
[00:28:44] <jepler> (the entire EMC2_MODULE_DIRECTORY is now whitelisted, so that new hal modules can be added)
[00:28:54] <jmkasunich> right
[00:29:27] <jmkasunich> btw, you asked earlier about the size of the docs
[00:29:30] <jmkasunich> about a half-meg
[00:29:46] <jmkasunich> I bet lyx compresses very well tho
[00:31:07] <jepler> yeah
[00:31:11] <jepler> I see ray has also raised the issue
[00:31:55] <jepler> surely most of the size of the "lyx" files is in the images, which won't get much additional compression
[00:32:18] <jmkasunich> hmm, I didn't look at the images
[00:33:04] <jmkasunich> the png bitmaps are small, many under 10K, all under 20K
[00:33:14] <jmkasunich> the .eps diagrams not so small
[00:33:36] <jmkasunich> oh, I lied, some of the png's are large
[00:34:37] <jepler> I wonder if CVSROOT/modules can be arranged to let everyone have his way
[00:35:40] <jepler> the emc2-obese module would have emc2 plus doc, and you and I would check it out. ray would continue to check out emc2
[00:35:41] <jmkasunich> I wonder what ray means about the connection thing... sure, an initial checkout will take longer, but after that it only copies stuff that changed
[00:36:04] <jmkasunich> that way lies madness I think
[00:36:26] <jmkasunich> IMO, the whole thing only makes sense if make can make the docs
[00:36:46] <jmkasunich> which means that the split between docs and other is deep in the tree
[00:36:58] <jmkasunich> src/doc vs src/foo, src/bar, etc
[00:37:18] <jmkasunich> if the split was at a high level, it wouldn't work
[00:37:21] <jmkasunich> oh, wait...
[00:37:47] <jmkasunich> what if we did the same trick that I do for axis - I have a symlink to my axis checkout in my src dir
[00:38:10] <jmkasunich> nah, that doesn't address the version thing at all
[00:38:36] <jepler> you think it should be emc2/src/doc, not emc2/doc ?
[00:39:11] <jepler> It's easy for me to sit here in the same building as the CVS server and say the bandwidth doesn't matter
[00:40:27] <jmkasunich> heh
[00:40:35] <jmkasunich> yeah, I think it should be src/doc
[00:40:57] <jmkasunich> because the lyx is the source of the docs, and the makefile should build the docs just like it builds the modules and executables
[00:41:27] <jmkasunich> the results (pdf files, etc) should go into emc2/docs
[00:42:03] <fenn> docs is 160k compressed
[00:43:23] <fenn> oops thats without images
[00:47:57] <fenn> is there a way to cvs co -without docs? since that seems to be the major issue
[00:48:32] <jmkasunich> I doubt it
[00:48:57] <jmkasunich> wow, the old days were much simpler:
[00:49:06] <jmkasunich> [John@cubix2 John]$ /sbin/lsmod
[00:49:06] <jmkasunich> Module Size Used by
[00:49:06] <jmkasunich> old_tulip 25600 1 (autoclean)
[00:49:06] <jmkasunich> ncr53c8xx 51552 3
[00:49:12] <jmkasunich> thats it! 2 modules
[00:49:45] <jmkasunich> today:
[00:49:45] <jmkasunich> john@ke-main-ubuntu:~/emcdev/emc2head$ lsmod | wc
[00:49:45] <jmkasunich> 75 264 3128
[00:49:47] <fenn> yeah even as late as redhat 9 i could ps -ef and get less than a page, and the process numbers were in the low hundreds
[00:51:10] <fenn> how is it xemc.png is only 5k and whaty4.png is 52k
[00:52:08] <jepler> whaty4 has been scaled, then jpeg compressed (or vice versa) and then turned back into a png
[00:52:53] <jmkasunich> IOW, the quality has been reduced and the size increased simultaneously.
[00:55:10] <jmkasunich> the eps files compress pretty well
[00:55:25] <jmkasunich> a 202K eps compressed to 25.2K
[00:55:52] <jepler> * jepler is tempted to "pngcrush" all the pngs; it seems to be giving 12% to 25% on the first few images
[00:56:07] <jepler> Best pngcrush method = 113 for new-cfdisk.png (24.84% reduction)
[00:56:12] <jmkasunich> is the result still a png? and is the compression lossless?
[00:56:16] <jepler> jmkasunich: yes, yes
[00:56:25] <jmkasunich> cool
[00:56:53] <jepler> it strips out some "extra" stuff, and then tries a bunch of stupid combinations of zlib tweaks in the hopes of finding a combination that gives better results than whatever was used before
[00:57:41] <jmkasunich> foobar.eps is a good example of how _not_ to use EPS
[00:58:08] <jmkasunich> the whole advantage of eps is scaling without pixelization, yet foobar.eps is pixelated
[00:58:50] <jepler> by default, lyx seems to convert png -> eps -> pdf and gets jpeg artifacts and resampling in the process
[00:59:00] <jepler> big yuck
[00:59:24] <jepler> * jepler wanders off
[01:08:42] <jmkasunich> well, the modules all load now
[01:09:59] <jepler> does it work?
[01:10:17] <jmkasunich> it complains about not being able to write to /dev/mbuff
[01:10:30] <jmkasunich> [John@cubix2 emc2head]$ ls -l /dev/mbuff
[01:10:30] <jmkasunich> crw-r--r-- 1 root root 10, 254 Jun 2 2001 /dev/mbuff
[01:10:59] <jepler> yeah I can see that being a problem
[01:11:01] <jmkasunich> I don't remember any of this rtlinux stuff, I have no idea if that is supposed to be writable or not
[01:11:35] <jmkasunich> I guess I could chmod the dev entry and see if it sticks
[01:11:46] <jepler> on bdi2? I think the odds are pretty good.
[01:11:53] <jepler> udev wasn't even a nightmare way back then
[01:12:40] <jmkasunich> seems to have worked
[01:12:45] <jmkasunich> bin/halcmd now runs
[01:13:13] <jmkasunich> still getting that gripe from bash
[01:13:23] <jmkasunich> [John@cubix2 emc2head]$ scripts/realtime start
[01:13:23] <jmkasunich> scripts/realtime: [: =: unary operator expected
[01:13:33] <jmkasunich> I think there is a prehistoric bash on that system
[01:13:49] <jmkasunich> wish it gave a line number
[01:14:56] <jepler> sh -x scripts/realtime start 2>&1 | grep -4 "unary operator" ?
[01:15:24] <jepler> if [ $RUN_IN_PLACE = yes ]; then
[01:15:34] <jepler> try changing this to if [ "$RUN_IN_PLACE" = yes ] ?
[01:15:50] <jepler> the rest look plausible (the variable argument is quoted)
[01:15:56] <jmkasunich> or "$RUN_IN_PLACE" = "yes"
[01:16:04] <jmkasunich> ?
[01:16:06] <jepler> "yes"
[01:16:21] <jepler> it would only be a problem if $RUN_IN_PLACE is empty
[01:16:25] <jepler> "yes" is never empty
[01:16:47] <jmkasunich> if its empty, isn't it comparing "" to yes?
[01:16:51] <jmkasunich> duh, thats ok
[01:17:04] <jmkasunich> but if its not empty, its comparing "yes" to yes
[01:17:47] <jepler> I agree it's best to quote "yes" but I don't think it's necessary. by the time test has its argv[], it can't tell whether yes was quoted.
[01:18:11] <jepler> but if $RUN_IN_PLACE is empty then it doesn't even create an (empty) position argument in argv[]
[01:18:15] <jmkasunich> well, that didn't fix it
[01:18:16] <jepler> "$RUN_IN_PLACE" does
[01:18:23] <jepler> well forget me trying to school you on shell syntax then
[01:18:45] <jmkasunich> no, I need all the schooling I can get
[01:19:28] <jepler> did you try it with 'sh -x' yet? that'll intersperse the commands and their results, so maybe you can find the line with the problem
[01:19:36] <jmkasunich> looking at the results now
[01:19:36] <cradek> an old trick is if [ x$RUN_IN_PLACE = xyes ]
[01:19:54] <cradek> but isn't RUN_IN_PLACE either yes or no?
[01:20:01] <jmkasunich> ++ MODULE_EXT=.o
[01:20:01] <jmkasunich> ++ DEBUG=3
[01:20:01] <jmkasunich> ++ MODPATH=/lib/modules/2.2.18-rtl3.0/misc
[01:20:01] <jmkasunich> ++ [ = 3 ]
[01:20:01] <jmkasunich> scripts/realtime: [: =: unary operator expected
[01:20:01] <jepler> # List of realtime kernel modules to be loaded
[01:20:01] <jepler> if [ 3 = 3 ] ; then \
[01:20:10] <jepler> hah, I was just finding the same thing
[01:21:34] <jepler> +++ rtapi.conf.in28 May 2006 01:23:58 -0000
[01:21:34] <jepler> @@ -20 +20 @@
[01:21:34] <jepler> -if [ @RTAI@ = 3 ] ; then \
[01:21:34] <jepler> +if [ "@RTAI@" = 3 ] ; then \
[01:21:39] <jepler> maybe this fixes it? (rerun config.status)
[01:26:01] <jmkasunich> that looks like the trick
[01:26:17] <jmkasunich> thanks
[01:26:20] <jepler> you're welcome
[01:26:32] <jepler> I may have been the one who wrote that bug so I'm not sure I deserve the thanks
[01:27:36] <jmkasunich> I don't think that was you
[01:28:20] <jepler> I think I changed rtapi.conf from being generated by a Makefile to being generated by configure
[01:28:29] <jmkasunich> oh, could be
[01:28:31] <cradek> * cradek moves each trace .025 inches...
[01:28:40] <jepler> cradek: I'm glad I'm not the only one
[01:28:42] <jepler> cradek: how complex is the board?
[01:28:50] <cradek> quite complex
[01:28:52] <jmkasunich> btdt
[01:29:05] <cradek> jepler: but almost done
[01:29:11] <jmkasunich> what are you making?
[01:29:16] <cradek> my lathe interface
[01:29:27] <jmkasunich> for your lathe?
[01:29:30] <cradek> two servo drivers and three divide-the-quadrature-by-16 circuits
[01:29:35] <cradek> yes
[01:29:38] <jmkasunich> cool
[01:29:52] <jmkasunich> have you attacked the motor mounting/belts yet?
[01:29:55] <cradek> I'm making one for you too if you want it
[01:30:02] <cradek> no the mechanical parts aren't here yet
[01:30:13] <jmkasunich> you ordered stuff already?
[01:30:19] <cradek> yes
[01:30:26] <cradek> the belts and pulleys will be here Tues.
[01:30:26] <jmkasunich> cool, so you have a plan at least
[01:30:46] <cradek> the motor mounting for X will be a challenge - Z is easy
[01:31:01] <jmkasunich> figured out how to attach the pulleys to the existing screws/handwheels?
[01:31:30] <cradek> yes they need to be turned flat on the end and then they'll just attach with setscrews
[01:32:14] <cradek> the sherline has no bearings - just flats against flats (the handwheel itself is part of the "bearing surface"
[01:32:17] <cradek> )
[01:32:47] <jmkasunich> so the handwheel position on the shaft affects the backlash?
[01:32:56] <cradek> yes
[01:32:59] <jmkasunich> eww
[01:33:07] <jmkasunich> and its held with a setscrew?
[01:33:11] <jmkasunich> eww
[01:33:11] <cradek> yes
[01:33:21] <cradek> backlash on a manual lathe does not matter
[01:33:32] <jmkasunich> bullshit
[01:33:38] <cradek> (I agree it's not ideal) but it makes parts fine
[01:33:57] <jmkasunich> it matters less than on a cnc, but its still sloppy design
[01:34:10] <cradek> sure
[01:34:20] <cradek> I was surprised to see it too
[01:34:22] <jmkasunich> even the chinese shoptask uses a pair of locknuts to adjust things
[01:34:50] <jmkasunich> you know, you might be able to do a fix that shoptask users to do improve the machine
[01:35:12] <jmkasunich> they turn a recess into the handwheel to accept a needle thrust bearing
[01:35:42] <cradek> interesting thought, I might even have some of those
[01:36:29] <cradek> the problem I see is that with a belt, there will be side forces on the bushing (hole really) that weren't there before
[01:36:40] <jmkasunich> mcmaster.com, part number 5909K31 or similar for thrust
[01:36:57] <jmkasunich> costs a whole $2.28
[01:37:34] <cradek> I could maybe even put them on both sides
[01:37:49] <jmkasunich> thats what I did on my shoptask
[01:38:02] <jmkasunich> reduced play at that joint from about 0.010 to 0.002 or so
[01:38:12] <cradek> I'll think about it, thanks for the idea
[01:38:28] <jmkasunich> you might be able to use a radial needle bearing for the belt side load too
[01:38:56] <cradek> as it sits (totally unadjusted) Z has .15mm backlash
[01:39:03] <cradek> it's always been that way and has never bothered me
[01:39:30] <jmkasunich> 1/4" needle bearing, 7/16" od, 5/16" wide, $3.83
[02:08:28] <jmkasunich> drat
[02:08:43] <jmkasunich> [John@cubix2 emc2head]$ bin/halcmd loadrt siggen
[02:08:43] <jmkasunich> /home/John/farm/emc2head/rtlib/siggen.o: unresolved symbol cos
[02:08:43] <jmkasunich> /home/John/farm/emc2head/rtlib/siggen.o: unresolved symbol sin
[02:08:43] <jmkasunich> HAL:0: ERROR: insmod failed, returned 1
[02:10:14] <cradek> what signal?
[02:10:22] <cradek> err symbol
[02:10:22] <jmkasunich> ?
[02:10:30] <jmkasunich> cos and sin
[02:11:25] <jmkasunich> math in the kernel has always been a mess
[02:11:56] <jmkasunich> I dunno if this is related to jepler's recent changes to includes, or if its bitrot since we haven't actually tested the old systems in ages
[02:12:42] <jmkasunich> at one time I even had an implementation of sin and cos written in vanilla C because the math lib wasn't available in kernel space
[02:12:51] <jmkasunich> that was removed long ago tho
[02:15:31] <jmkasunich> heh, the code is actually still there
[02:15:49] <jmkasunich> been #if 0'ed out for two years tho
[02:16:18] <cradek> yay, board is ready to make
[02:16:35] <jmkasunich> did you find fresh tape?
[02:16:46] <cradek> shit
[02:16:51] <jmkasunich> I guess not
[02:16:56] <cradek> I forgot about that detail
[02:17:01] <cradek> and the stores are closed now
[02:17:05] <cradek> I'll find something
[02:18:27] <jmkasunich> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7622031942
[02:19:02] <cradek> I think I could probably find one of those in the barn
[02:19:13] <jmkasunich> you have a barn?
[02:19:19] <cradek> sort of
[02:19:27] <cradek> it's an auxiliary ... place to put things
[02:19:49] <jmkasunich> I have a very similar pump out in the garage
[02:22:29] <jepler> jmkasunich: I tested for rtai that it inlined 'sin' and 'cos' (fsin/fcos instruction calls). but maybe the really old compilers don't do it.
[02:23:20] <jmkasunich> way back when I first wrote siggen I had to make my own versions of sin, cos, and floor
[02:23:30] <jmkasunich> they've been if'ed out for 2 years
[02:23:55] <jmkasunich> don't know if they breakage on bdi-2 happened way back then or more recently
[02:24:20] <jmkasunich> at one time I thought we were linking in a math library provided by rtai
[02:25:18] <jepler> we do load a kernel module called rtai_math but I don't know what it does -- just provides for floating-point to work at all, or provides sin() cos() etc
[02:25:31] <jmkasunich> I think the latter
[02:25:50] <jmkasunich> but of course we don't load rtai_math when running rtlinux :-(
[02:25:57] <jepler> yeah
[02:26:11] <jmkasunich> I'm starting to think this isn't worth the hassle
[02:26:24] <jmkasunich> if its been busted for two years, obviously nobody cares
[02:26:25] <jepler> you could change rtapi_math.h to do the "include, undef, include" approach and see if it fixes rtlinux
[02:27:12] <jmkasunich> what is the include/undef/include approach?
[02:27:50] <jepler> http://cvs.linuxcnc.org/cvs/emc2/src/rtapi/rtapi_math.h?rev=1.1.2.2;content-type=text%2Fplain
[02:30:44] <jmkasunich> just looking at your version of rtapi_math.h
[02:31:06] <jmkasunich> basically you declare the functions, but cross your fingers and hope somebody else implemented them
[02:31:19] <jmkasunich> which is pretty much what the old version did
[02:31:31] <jepler> include "rtapi_math_i386.h"
[02:31:43] <jepler> this is a copy of a relatively modern "mathinlines.h"
[02:31:47] <jmkasunich> oh, thats the inline implementations?
[02:31:49] <jepler> right
[02:32:46] <jepler> sin cos sqrt fabs are all just single x87 instructions so the inline implementation is not subtle
[02:33:08] <jmkasunich> is "# if !__GNUC_PREREQ (3,3)" a GCC version test?
[02:33:13] <jepler> yeah
[02:33:17] <jepler> it's defined at the top of rtapi_math_i386
[02:34:06] <jmkasunich> hmmm: /* GCC 2.97 and up have builtins that actually can be used. */
[02:34:17] <jmkasunich> implying that 2.95 does not
[02:34:49] <jmkasunich> man, that file is ifdef hell
[02:34:49] <jepler> that's for isgreater() etc
[02:34:51] <jepler> yeah it is
[02:35:27] <jepler> it's the kind of macro "wizardry" that I might write
[02:35:36] <jepler> (I didn't)
[02:35:48] <jmkasunich> understood ;-)
[02:36:01] <jepler> if only my day job wasn't commercial software I could show you some doozies
[02:37:02] <jmkasunich> so, given that we're including this beast, shouldn't the math code be working?
[02:37:55] <jepler> well I haven't threaded through the ifdefs yet
[02:38:07] <jmkasunich> nor have I
[02:38:18] <jepler> #ifdef __FAST_MATH__
[02:38:18] <jepler> # if !__GNUC_PREREQ (3, 4)
[02:38:18] <jepler> /* The argument range of this inline version is reduced. */
[02:38:19] <jepler> __inline_mathopNP (sin, "fsin")
[02:38:23] <jepler> do we have __FAST_MATH__ defined?
[02:38:36] <jmkasunich> not to my knowledge
[02:38:51] <jmkasunich> but that don't mean much
[02:39:47] <jmkasunich> hmm, from configure:
[02:39:57] <jmkasunich> checking for kernel math support... no
[02:39:57] <jmkasunich> checking for a suitable libm... configure: WARNING: Using glibc libm with mathstubs.
[02:39:57] <jmkasunich> If unresolved symbols are reported when loading kernel modules
[02:39:57] <jmkasunich> please file a bug report.
[02:40:24] <jmkasunich> mathstubs is part of the older workaround that paul came up with
[02:40:31] <jmkasunich> afraid I never really understood it
[02:40:48] <jmkasunich> but the fact that configure is still invoking it even tho your stuff is inline.....
[02:41:05] <jmkasunich> for ubuntu:
[02:41:15] <jmkasunich> checking for kernel math support... ok, using RTAI's libm kernel module
[02:41:26] <jepler> RTFLAGS = -I. -I/usr/realtime-2.6.12-magma/include -ffast-math -mhard-float -DRTAI=3 # ubuntu
[02:41:40] <jepler> we are getting fast-math on ubuntu, which means the fancy inlines would be used
[02:42:00] <jmkasunich> ok
[02:42:04] <jepler> try making -ffast-math be used for your kernel modules on bdi2
[02:44:27] <jmkasunich> not sure I understand what is going on
[02:44:58] <jmkasunich> does rtapi_math_i386.h completely eliminate the need to link a math lib?
[02:46:19] <jepler> it was intended to provide inline versions of the same things that were inlined before on my ubuntu system -- I checked that sin and cos were inlined, but nothing else.
[02:46:35] <jepler> I am not sure if it inlines all the functions declared in rtapi_math.h on ubuntu or not
[02:46:43] <jepler> and clearly it doesn't on other compilers
[02:47:10] <jmkasunich> I just looked at mathstubs, it provices some dummy functions that might be called by a user space math lib if it is linked to a kernel space app like ours
[02:47:27] <jmkasunich> IOW, a hack to allow using the user space math lib
[02:47:54] <jmkasunich> judging from the configure output, it _is_ using the user space lib, or at least it things it should be
[02:48:04] <jmkasunich> s/things/thinks
[02:49:02] <jmkasunich> I'm starting to understand I think... the i386.h isn't intended to replace a math lib, it is intended to augment it with inline versions of some functions
[02:49:24] <jmkasunich> the writer of the .h didn't worry about _always_ supplying _all_ the functions, because if he didn't the lib would
[02:50:26] <jmkasunich> does that sound right? or am I still confused
[02:50:59] <jepler> the .h now known as rtapi_math_i386.h? Yes.
[02:51:29] <jmkasunich> so right now we have one of those cases where rtapi_math_i386.h doesn't supply an inline
[02:51:38] <jmkasunich> and we have no lib to back it up
[02:52:04] <jmkasunich> how did it work before, when there were no inlines?
[02:53:03] <jepler> on ubuntu (and any other modern glibc system) /usr/include/math.h included /usr/include/bits/mathinline.h .. the latter file is what rtapi_math_i386.h is a close copy of
[02:53:09] <jepler> so there were inlines before too
[02:53:23] <jmkasunich> on ubuntu and modern systems
[02:53:43] <jmkasunich> but before all that, in the days of BDI-2 and BDI-TNG, rtapi could do math
[02:53:57] <jmkasunich> using mathstubs and a real lib, not inlines
[02:54:29] <jepler> it didn't help to make sure -ffast-math was on RTFLAGS?
[02:54:41] <jmkasunich> I didn't try that yet
[02:54:58] <jmkasunich> all that does is attempt to make the inlines work
[02:55:03] <jepler> yes
[02:55:17] <jmkasunich> I'm still concerned about the fact that we have no lib backing up the inlines
[02:59:28] <jepler> it's possible that support for "mathstubs" was lost with my makefile convert, since I had never heard of it
[03:00:22] <jepler> but mathstubs.c doesn't define sin or cos
[03:00:50] <jmkasunich> no, mathstubs defines some stuff that the real math lib (a user space one being misapplied in kernel space) wants to see
[03:01:02] <jmkasunich> (I said it was a hack ;-)
[03:01:38] <jmkasunich> I think there was a -lm used when linking the kernel modules, to force linking of the math lib
[03:02:23] <jepler> yuck
[03:02:33] <jmkasunich> yeah
[03:02:33] <jepler> not that this isn't all a bit yucky
[03:03:32] <jmkasunich> is there a way to tell at compile time if rtapi_math_i386.h inlines a function?
[03:04:07] <jepler> Put a "#error" above the line where you think it's going to define it?
[03:04:33] <jepler> (no, I don't know offhand)
[03:04:37] <jmkasunich> #include <rtapi_math_i386.h>
[03:04:40] <jmkasunich> #ifndef cos
[03:04:48] <jmkasunich> #error cos() undefined
[03:04:49] <jmkasunich> #endif
[03:04:50] <jmkasunich> ?
[03:04:58] <jepler> no, that's not what I meant
[03:05:02] <jepler> #if (something illegible)
[03:05:07] <jepler> #error "the next line defines cos"
[03:05:16] <jepler> INSCRUTABLE_MACRO("cos", "fcos", "gcos", "qcos")
[03:05:45] <jmkasunich> I'm not sure we're trying to accomplish the same thing
[03:06:00] <jmkasunich> all I want to do right now is make it fail at compile time instead of runtime
[03:06:04] <jepler> oh, if it inlines the function
[03:06:09] <jepler> * jepler should learn to read
[03:06:13] <jmkasunich> if it inlines the function we're fine
[03:06:29] <jmkasunich> the problem is that some versions of gcc, etc don't inline it, and there is no library to back it up
[03:06:39] <jmkasunich> we both agree that using a lib intended for userspace is a hack
[03:06:52] <jmkasunich> if the inlines work, no lib is needed at all
[03:06:57] <jmkasunich> they do work for ubuntu
[03:07:15] <jepler> on ubuntu, I looked while emc was running and rtai_math is loaded but does not show as "used"
[03:07:33] <jmkasunich> which makes sense, since all the functions we needed are inlined
[03:07:38] <jmkasunich> that is the best case
[03:07:56] <jmkasunich> next best is if the inlines fail but rtai_math or an equivalent is there to back it up
[03:08:05] <jepler> "-Winline" ?
[03:08:13] <jmkasunich> worst case, the inlines fail and there is no backup, you don't find out until runtime
[03:08:44] <jepler> I can produce (have produced) a much simplified rtapi_math_i386.h without all the ifdefs and stuff
[03:08:55] <jepler> but as usual I only know it works on ubuntu
[03:09:00] <jepler> its other virtue is being much shorter
[03:09:07] <jmkasunich> right - the ifdefs are probably a good thing
[03:09:27] <jmkasunich> without ifdefs, it may generate downright busted code on some compilers
[03:09:36] <jmkasunich> with them, it simply skips things that it can't inline
[03:09:38] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/rtapi_math_i386.h
[03:09:40] <jepler> try it if you like
[03:09:42] <jepler> i'm going to bed
[03:09:51] <jmkasunich> goodnight
[03:10:10] <jepler> it's nice to be back to my usual hours :)
[03:10:13] <jmkasunich> I got to wrap my head around this mess before I know what to do
[03:10:36] <cradek> do you have reason to believe anyone wants to run emc2 on these old platforms?
[03:10:49] <jmkasunich> no
[03:10:59] <jmkasunich> nor do I have reason to believe they don't
[03:11:13] <cradek> I have some reason to believe they don't
[03:11:23] <jmkasunich> if this breakage happened long ago I would treat the lack of complaints as proof that they don't
[03:11:24] <cradek> (it sounds like it doesn't work and nobody has said anything)
[03:11:33] <jmkasunich> but the breakage may have only happened last week
[03:11:33] <cradek> yes that's waht I was thinking too
[03:11:47] <cradek> ok I see
[03:12:16] <jmkasunich> oh...
[03:12:35] <jmkasunich> actually there is a different breakage that happened when module_helper was introduces
[03:12:49] <jmkasunich> it has never had rtlinux modules in its whitelist
[03:12:56] <jmkasunich> how long have we been using module helper?
[03:13:36] <cradek> revision 1.1
[03:13:36] <cradek> date: 2006/01/29 21:25:15; author: cradek; state: Exp;
[03:13:36] <cradek> first shot at eliminating sudo and being smarter about root privs
[03:14:00] <jmkasunich> 4 months then
[03:14:13] <jmkasunich> not a peep from disgruntled BDI-2 users
[03:14:38] <cradek> nope
[03:14:57] <jmkasunich> time to say bye-bye to BDI-2?
[03:15:35] <cradek> if you're spending time on it that's best spent somewhere else, I'd say it's probably time
[03:16:13] <jmkasunich> drat... BDI-TNG is also using glibc libm with mathstubs
[03:16:27] <jmkasunich> BDI-Live is not
[03:16:44] <jmkasunich> nor is BDI-4.20
[03:17:00] <jmkasunich> so we'd have to drop BDI-2 and -TNG
[03:17:20] <cradek> we have a better live cd now
[03:17:52] <jmkasunich> live isn't the issue anyway, BDI-Live should work
[03:18:00] <cradek> oh ok
[03:18:09] <jmkasunich> its the ones that use the glibc libm + mathstubs hack that are broken
[03:18:10] <cradek> I don't know all the names I guess
[03:18:34] <jmkasunich> glibc libm is the user space math lib, never intended for kernel space
[03:18:46] <jmkasunich> mathstubs is a hack that lets it be used in kernel space
[03:19:13] <jmkasunich> configure checks for proper kernel space math support, and only uses the hack if its not found
[03:19:30] <jmkasunich> so our choices are:
[03:19:43] <jmkasunich> 1) remove the hack, make configure fail if there isn't proper kernel math support
[03:20:11] <jmkasunich> 2) repair the hack (I dunno if jepler busted it recently or if its been busted for a while)
[03:20:27] <jmkasunich> 1) is the "right" thing to do
[03:20:51] <jmkasunich> but it implies dropping support for systems without proper kernel math support, ie. BDI-2 and BDI-TNG
[03:24:42] <jmkasunich> you got very quiet....
[03:24:48] <jmkasunich> any thoughts on 1 vs 2?
[03:25:11] <cradek> sorry, working on my pcb
[03:25:24] <cradek> ideally configure would fail if it's not going to work
[03:25:40] <jmkasunich> right
[03:26:03] <jmkasunich> when configure decides to use the hack, it prints a warning
[03:35:55] <cradek> 2.0.1 cuts these circles on my pcb nicely
[03:46:33] <jmkasunich> I'm gonna ask on the users and dev lists if anybody is using the older BDIs with EMC2
[03:46:41] <jmkasunich> see what happens
[03:47:03] <cradek> good idea
[16:52:34] <Evert> Evert is now known as EvertL
[18:20:32] <jepler> alex_joni: did the hexkins files get pulled for the 2.0.1 release?
[18:21:44] <jepler> ok, I see that they did
[18:21:57] <alex_joni> yup
[18:23:23] <jepler> now what's this about there being a cloud over the mesa-related files?
[18:23:36] <alex_joni> only fud
[18:23:44] <alex_joni> I asked peteG
[18:23:53] <jmkasunich> paul shoveling shit again
[18:24:04] <alex_joni> and he said he only placed his copyright over the files he created
[18:24:25] <alex_joni> the rest are copyrighted by Peter Wallace of Mesanet Inc.
[18:25:00] <alex_joni> of course GPL'ed
[18:25:49] <alex_joni> any reason you're asking?
[18:26:08] <jepler> yeah, paul's last e-mail to me mentioned both these "issues"
[18:26:22] <jepler> by the headers it is destined for bdi4emc-help and emc-developers lists
[18:26:27] <jepler> but I haven't seen it there yet
[18:26:44] <cradek> it's good if he finally airs his concerns in the open, then we can deal with them
[18:27:26] <alex_joni> right.. nothing to hide here :)
[18:28:05] <jmkasunich> just approved the message (he's not subscribed, so they get held for moderation)\
[18:47:39] <jmkasunich> I'm tempted to start removing the remains of the glibc math lib hack from configure
[18:48:41] <alex_joni> go ahead
[18:51:01] <jmkasunich> cradek: was it you that had a RTLinux box running emc2?
[18:51:12] <jmkasunich> (modern RTLinux I think, not the BDI-2 stuff)
[18:52:47] <cradek> yes, I did some time ago
[18:53:26] <jmkasunich> does it still work? (do you even still have the box?)
[18:54:09] <cradek> it was this same box - I still have the disk I think - haven't booted it for a long time
[18:54:18] <jmkasunich> just curious
[18:54:27] <jmkasunich> since we're dropping BDI-2, we
[18:54:28] <cradek> I'll boot it if you want
[18:54:38] <jmkasunich> we'll no longer have any RTLinux systems
[18:54:52] <jmkasunich> which means rtl_rtapi.c will probably bitrot
[18:59:05] <jmkasunich> hmm
[18:59:36] <jmkasunich> I just tested the V2.0 branch on the BDI-2 box and it works (after adding the RTLinux modules to the module_helper whitelist)
[18:59:48] <jmkasunich> so as of 2.0.0 the math lib hack was working
[19:03:00] <jmkasunich> am I depraved for wanting to figure out what broke and fix it, instead of abandoning the old stuff?
[19:04:29] <jepler> jmkasunich: if it's important to you, then work on it.
[19:05:39] <jepler> that's the only rule
[19:05:58] <jmkasunich> thats also bullshit
[19:06:01] <jmkasunich> we
[19:06:20] <jmkasunich> we've all done stuff we personally don't care about because it makes EMC a better program for other users
[19:06:34] <alex_joni> but only because it was important to you/us
[19:06:40] <alex_joni> e.g. to have a better software
[19:06:44] <alex_joni> ;-)
[19:08:14] <jepler> jmkasunich: can you see whether in 2.0.0 sin() was inlined, or whether it was coming from libm.a?
[19:08:38] <jmkasunich> I dunno
[19:08:48] <jmkasunich> I'm in a little over my head
[19:09:01] <jmkasunich> how do I check? gdb or something?
[19:09:23] <jepler> I'd do "nm example.o | grep sin"
[19:09:45] <jepler> if any lines show up it was't inlined or wasn't called
[19:10:01] <jmkasunich> ohh, even I can handle that ;-)
[19:10:02] <jmkasunich> stand by
[19:11:09] <jmkasunich> hmm, doesn't show up
[19:11:16] <jmkasunich> (I'm surprised)
[19:11:33] <jmkasunich> cd ..
[19:11:36] <jmkasunich> oops
[19:12:33] <jmkasunich> shows up as undefined in the head version, but unused (inlined) in the 2.0 version
[19:12:56] <jepler> now try my new rtapi_math_i386.h
[19:13:02] <jepler> they'll all inline again and you can pronounce bdi2 fixed
[19:13:20] <jepler> I've tested it on one systems, it must be right.
http://emergent.unpy.net/index.cgi-files/sandbox/rtapi_math_i386.h
[19:13:44] <jmkasunich> hang on, fixing something else
[19:16:38] <jmkasunich> there, at least 2.0.1 will work on the old systems
[19:17:40] <jmkasunich> ok, back to focusing on head
[19:18:57] <jmkasunich> just looked at the new i386
[19:19:01] <jmkasunich> a bit easier to read ;-)
[19:19:10] <jmkasunich> I notice there's no floor()
[19:19:27] <jmkasunich> siggen uses floor()
[19:19:35] <jmkasunich> so where is that coming from?
[19:19:54] <jmkasunich> does the original inline.h contain floor()?
[19:21:39] <jmkasunich> hmm, I thought it used floor
[19:37:41] <jmkasunich> ok, siggen doesn't use floor, it was removed in version 1.10, sept 2004
[19:38:24] <alex_joni> * alex_joni thinks jmk is talking to himself..
[19:38:37] <jmkasunich> I'm starting to wonder about that
[19:38:50] <alex_joni> not that I mind.. it's nice to hear so much nice stuff..
[19:38:56] <alex_joni> ;-)
[19:39:22] <jmkasunich> my problem is that I'm not sure what I'm doing - if I talk about it maybe others will jump in when I say something stupid
[19:40:31] <alex_joni> think anyone knows about this?
[19:40:38] <alex_joni> well.. jepler might ..
[19:40:43] <jmkasunich> jepler sounds like he knows more than me
[19:41:05] <alex_joni> even when he's silent like now..
[19:41:12] <jmkasunich> heh
[19:41:20] <jmkasunich> ok, this is really strange
[19:41:29] <alex_joni> what is?
[19:41:38] <jmkasunich> on ubuntu: emc2head AND emc2.0 both apparently get sin from the lib
[19:41:56] <jmkasunich> because both say " U sin" when I do "nm siggen.ko"
[19:42:08] <jmkasunich> I thought jeplers change would result in sin being inlined
[19:42:09] <alex_joni> isn't U unused?
[19:42:14] <jmkasunich> U is undefined
[19:42:18] <alex_joni> oh
[19:42:22] <jmkasunich> in this case, its defined at insmod time
[19:42:30] <alex_joni> ok.. you probably know more about me :)
[19:42:43] <alex_joni> so rtai_math is taking over?
[19:43:00] <jmkasunich> yeah
[19:43:02] <jmkasunich> which is fine
[19:43:10] <jmkasunich> the inlines would be faster
[19:43:24] <jmkasunich> and if they're not being used, why bother with them at all?
[19:44:41] <alex_joni> that was a retorical question I hope..
[19:44:52] <jmkasunich> on BDI-2: emc2head shows sin as undefined, so it wants to get it from the lib (but there is no lib, so it fails at insmod time)
[19:45:03] <jmkasunich> emc2.0 doesn't show sin at all
[19:45:09] <jmkasunich> yet it works
[19:45:36] <jmkasunich> so its either inlined (math.h maybe) or ?
[20:08:11] <jepler> jmkasunich: I'd swear I found that "sin" was inlined on ubuntu
[20:08:53] <jmkasunich> I expected it to be
[20:08:58] <jmkasunich> can you check now?
[20:09:08] <jepler> $ nm rtlib/siggen.ko | grep sin | wc -l
[20:09:08] <jepler> 0
[20:09:17] <jepler> but this is with my newer rtapi_math_i386.h
[20:09:57] <jmkasunich> john@ke-main-ubuntu:~/emcdev$ nm emc2.0/rtlib/siggen.ko | grep sin
[20:09:57] <jmkasunich> U sin
[20:09:57] <jmkasunich> john@ke-main-ubuntu:~/emcdev$ nm emc2head/rtlib/siggen.ko | grep sin
[20:09:57] <jmkasunich> U sin
[20:10:14] <alex_joni> juve@ubuntu:~/emc2$ nm rtlib/siggen.ko | grep sin | wc -l
[20:10:14] <alex_joni> 1
[20:10:15] <jmkasunich> both up-to-date CVS
[20:10:30] <alex_joni> that's HEAD
[20:11:15] <jmkasunich> [John@cubix2 farm]$ nm v2_0_branch/rtlib/siggen.o | grep sin
[20:11:15] <jmkasunich> 0000003d ? __module_using_checksums
[20:11:15] <jmkasunich> [John@cubix2 farm]$ nm emc2head/rtlib/siggen.o | grep sin
[20:11:15] <jmkasunich> 0000003d ? __module_using_checksums
[20:11:15] <jmkasunich> U sin
[20:11:22] <jmkasunich> thats on the BDI-2 box
[20:12:05] <jepler> another option is to revert all the changes that went in with "rtapi_math.h" and put off supporting gcc 4.1 for another day
[20:12:44] <jmkasunich> I've been working up my nerve to examine all those changes and see what might have affected the BDI-2 box
[20:13:01] <jmkasunich> but I keep letting LH and others distract me
[20:13:27] <Lerneaen_Hydra> * Lerneaen_Hydra ducks and jumps for cover
[20:13:33] <jmkasunich> heh
[20:14:11] <jepler> yes, with the old rtapi_math_i386.h (the CVS version) there is " U sin" in siggen
[20:14:36] <alex_joni> jepler: why not commit?
[20:14:37] <jmkasunich> so the maze of ifdefs means that it wasn't inlining
[20:14:43] <jepler> jmkasunich: yes, I guess so
[20:14:59] <jmkasunich> alex: the new one is simplified, without the maze of ifdefs
[20:15:13] <jmkasunich> net result, it probalby works only with certain compiler versions
[20:15:25] <alex_joni> still better..
[20:15:36] <jmkasunich> I don't think so
[20:15:37] <alex_joni> make it work for now, worry later about other compilers :)
[20:15:43] <alex_joni> you think?
[20:16:03] <jepler> I think the asm is fairly portable among gcc versions
[20:16:08] <jmkasunich> the one with all the ifdefs generates inlines for versions where it knows they'll work, and leaves well enough alone when they might not work
[20:16:10] <alex_joni> it really is madness in there..
[20:16:23] <jmkasunich> the new one generates inlines but has no idea if they will work or not
[20:16:55] <jmkasunich> those ifdefs represent the results of a _lot_ of testing with different versions by the person(s) who wrote that file
[20:17:05] <jmkasunich> I hesitate to just toss them out the window
[20:17:22] <alex_joni> ok....
[20:17:33] <jmkasunich> besides, the inlines are really just a performance thing
[20:18:02] <jmkasunich> the real issue is the lack of a solid library backing up the inlines
[20:18:06] <alex_joni> jepler: is it working with the inline you made with you rlatest foo.h ?
[20:18:26] <jmkasunich> for ubuntu and other recent systems (BDI-Live and BDI-4) there is an rtai_math lib
[20:18:43] <jmkasunich> so if the inlines don't get defined, its OK
[20:19:00] <jmkasunich> for the old ones, there used to be a user space math lib hacked into place, but now there isn't
[20:19:29] <jepler> the constraints I used in the newer rtapi_math_i386.h are documented in the same way in the version of gcc on bdi2
[20:19:45] <jepler> "=t", "0", "u"
[20:20:01] <jepler> hm, not sure about the clobber of 'st(1)'
[20:20:32] <jmkasunich> damn, I'm really in over my head
[20:20:43] <jmkasunich> because I didn't understand a single thing in your last three statements
[20:21:12] <jepler> Consider this code: __asm __volatile__ ("fcos" : "=t" (__result) : "0" (__x));
[20:21:34] <jepler> the syntax is asm( code : outputs : inputs : clobber )
[20:21:55] <jmkasunich> I've never done gcc inline assy
[20:22:18] <jepler> consider "=t" (__result). It means that __result is an output. It has to be put in a register determined by "t", which is both used and written by the asm
[20:22:32] <jepler> "0" (__x) means that __x goes in the same register as __result.
[20:22:39] <jepler> "t" means "the top of the x87 floating-point stack
[20:23:10] <alex_joni> sounds like easily bustable :)
[20:23:24] <jepler> by these "constraints", gcc can make sure the inputs are in the right registers, and the outputs are taken from the right registers, and that anything not marked as disturbed can be assumed unchanged for the purposes of optimization
[20:23:48] <jmkasunich> ok, I'm not really questioning the assembly
[20:24:36] <jepler> the documentation for the gcc on bdi2 documents all the parts of __asm__ syntax that I use in the same way as gcc4
[20:24:50] <jmkasunich> oh, ok
[20:25:11] <jmkasunich> so you were saying "according to the docs, the old gcc should handle this asm code exactly like the new gcc"
[20:25:21] <jepler> right
[20:25:31] <jmkasunich> then why all the ifdefs in the original file?
[20:25:56] <jmkasunich> does that author just like obfscuated code, or does he know something we don't?
[20:26:25] <alex_joni> it might be optimized for processors
[20:26:35] <alex_joni> I see an #ifdef i686 in there
[20:26:52] <jmkasunich> there are a _lot_ of gcc version dependencies in there too
[20:27:11] <jmkasunich> mostly 2.8 and 3.4 are considered breakpoints between two different ways of doing things
[20:27:54] <jepler> 2.8 is older than the one on bdi2 so it doesn't matter
[20:28:12] <jmkasunich> right
[20:28:40] <jmkasunich> although I'd be tempted to put something in there that would error out if they used a really old compiler
[20:29:29] <jepler> #if __GNUC_PREREQ (3, 4)
[20:29:29] <jepler> __inline_mathcodeNP2_ (long double, __atan2l, __y, __x,
[20:29:29] <jepler> return __builtin_atan2l (__y, __x))
[20:29:53] <jepler> I think this one means that for 3.4 and newer, gcc is providing its own builtin atan2 so turn it off
[20:31:33] <jmkasunich> I need to get one simple thing straight: the original .h file that rtapi_math_i386 is based on was intended to _augment_, not replace, a math lib, right?
[20:32:10] <jmkasunich> it doesn't _have_ to implement every function in the math lib, and the inlines that it provides don't _have_ to be used by the compiler
[20:32:13] <jepler> yes. it provides inline versions of some libm functions, particularly where they correspond 1:1 with x87 instructions
[20:32:46] <jmkasunich> so it is strictly an optimization, and you can't count on it alone providing the math functions
[20:33:04] <jepler> what I've done for the second rev of rtapi_math_i386.h is provide inlines for all the functions *THAT WE USE*
[20:33:07] <jepler> it's a small list
[20:33:20] <jmkasunich> you still can't count on the compiler using them
[20:33:44] <jmkasunich> suppose the sin() call is buried deep in a complex expression that fills the x87 stack
[20:34:06] <jmkasunich> the compiler might decide to call a version of the function that saves a stack location or something
[20:34:30] <jmkasunich> I think that one way or another we must provide a backup math lib
[20:35:21] <jepler> or rewrite these macros not as inline functions but using the gcc "compound statement" extension ({...})
[20:36:28] <jepler> or if you want to do it as a library, rtapi_i386_math.c would be just lke rtapi_i386_math.h but with "inline" removed.
[20:36:48] <jmkasunich> not true I don't think
[20:37:19] <jepler> or we could use "static inline", which will cause the function to be included in each object file where it's used but not inlined
[20:37:56] <jmkasunich> because while its perfectly OK for rtapi_math_i386.h to simply not provide anything for function foo() on a certain combination of compiler, source, and phase of the moon, its _not_ ok for a lib to skip foo()
[20:38:45] <jepler> I mean the simplified version, which won't have anything disappear merely due to compiler version or optimization flags
[20:39:33] <jmkasunich> the simpler version is even scarier, that means that _we_ bear the burden of making sure that everything in it is correct over all versions, source files, phase of the moon, etc
[20:39:50] <jmkasunich> IOW, we now get to maintain the math lib... no thanks
[20:39:58] <jepler> we bore the burden already, when someone showed up with a gcc/libc combination where our "-I/usr/include" hack didn't work
[20:40:08] <jmkasunich> you mean 4.1?
[20:40:11] <jepler> yes
[20:40:33] <jmkasunich> but for modern systems, rtai provides its own kernel math lib
[20:40:45] <jepler> does it provide a header?
[20:40:50] <jmkasunich> not sure
[20:41:04] <jepler> I shouldn't phrase it as a question; I looked but couldn't find it
[20:41:07] <jmkasunich> maybe the real problem is that we were using the math.h header even when linking with the rtai_math lib
[20:41:54] <jmkasunich> did the guy with 4.1 ever post his configure output?
[20:42:04] <jepler> no, I don't think so. he said it was suse or something.
[20:42:16] <jepler> $ find /usr/realtime-2.6.12-magma/ -name \*.h | xargs grep atan2 | wc -l
[20:42:17] <jepler> 0
[20:42:31] <jmkasunich> I'd like to see if it said:
[20:42:32] <jmkasunich> checking for kernel math support... no
[20:42:32] <jmkasunich> checking for a suitable libm... configure: WARNING: Using glibc libm with mathstubs.
[20:42:32] <jmkasunich> If unresolved symbols are reported when loading kernel modules
[20:42:32] <jmkasunich> please file a bug report.
[20:42:35] <jmkasunich> or:
[20:42:50] <jmkasunich> checking for kernel math support... ok, using RTAI's libm kernel module
[20:45:14] <jmkasunich> I would certainly hope that he got the latter message
[20:45:20] <jepler> I suspect he did
[20:45:23] <jmkasunich> if not, maybe his rtai is fscked
[20:45:34] <jmkasunich> if he did, then what exactly was his problem?
[20:45:55] <jepler> the problem is that /usr/include/math.h pulls in headers that are incompatible with the kernel headers
[20:46:29] <jmkasunich> so if he's using rtai_libm, then the real problem is that we should be using a matching header
[20:46:43] <jmkasunich> the inlines really have nothing to do with that at all
[20:47:12] <jmkasunich> and the fix for him should not have affected people using the glibc libm at all
[20:47:35] <jmkasunich> if rtai doesn't provide a matching header, that sucks
[20:47:44] <jepler> then what happened on bdi2 so that there was no use of the extern "sin" before my change?
[20:48:23] <jmkasunich> not sure how that worked, paul did it a couple years ago and we never looked back
[20:48:31] <jmkasunich> I think it might statically link the module with glibc libm
[20:48:52] <jmkasunich> would that make the symbol disappear from the nm listing, or just make the U go away?
[20:49:16] <jmkasunich> arrg
[20:49:19] <jmkasunich> I
[20:49:27] <jepler> I'm not sure, but my recent changes didn't remove -lm, just -I/usr/include
[20:49:33] <jmkasunich> I'm not even remotely convinced that what you just did is the fix
[20:51:07] <jepler> there are no hard feelings if we end up reverting it all, but I think this is better than the iteration before.
[20:51:26] <jmkasunich> years of testing went into those ifdefs
[20:52:10] <jmkasunich> they might represent some really obscure special case that may or may not ever happen in our code
[20:52:28] <jmkasunich> I hate to mess with the integrity of something as fundamental as a math lib
[20:56:27] <jmkasunich> /usr/include/math.h is another preprocessor nightmare
[20:56:35] <jepler> then we should take out the inlines and work out why bdi2 doesn't work anymore, or discard it as a platform.
[20:56:56] <jmkasunich> thats what I was thinking
[20:57:23] <jepler> but I fear the answer is "it stopped working when the new math header didn't provide inlines"
[20:57:34] <jepler> (i.e., the one I provided from a far-newer system)
[20:57:46] <jmkasunich> that might be the case
[20:57:52] <Lerneaen_Hydra> basic emc-user question: why even have bdi anymore? installing on ubuntu/other debian base isn't that hard
[20:58:23] <alex_joni> Lerneaen_Hydra: supporting existing users
[20:58:24] <jmkasunich> heh, basically "we" (the emc2 team) _don't_ have BDI anymore
[20:59:23] <Lerneaen_Hydra> so it's just to let the existing users keep on using BDI? if so why not discontinue it and just leave it at the version it is, and concentrate on the "standard" version?
[20:59:41] <jepler> Lerneaen_Hydra: we like to test on a wide range of systems. the easiest ones to set up are ones where the realtime environment was already done -- old BDIs
[21:00:23] <jmkasunich> we currently make sure that EMC2 _compiles_ on five different systems
[21:00:35] <jmkasunich> unfortunately it doesn't _run_ on all those systems
[21:00:45] <jepler> jmkasunich: now you're really splitting hairs
[21:01:46] <jepler> (that was supposed to be a joke)
[21:02:17] <alex_joni> ha ha
[21:03:23] <jmkasunich> ;-)
[21:03:35] <jmkasunich> (I was afk)
[21:09:25] <jmkasunich> jepler but I fear the answer is "it stopped working when the new math header didn't provide inlines"
[21:09:32] <jmkasunich> I fear you may be right
[21:11:57] <jepler> MATHLIB isn't used by the new makefiles
[21:12:09] <jmkasunich> I just discovered that
[21:12:26] <jmkasunich> so the breakage was in two stages
[21:12:32] <jepler> yeah
[21:12:39] <jmkasunich> the new makefiles stopped linking to the libs, but the inlines covered it up
[21:12:48] <jmkasunich> then the new inlines removed the covering\
[21:13:12] <jmkasunich> what a mess
[21:13:39] <jepler> rtlib/%.o: @ld ... $(MATHLIB) ?
[21:14:06] <jepler> except the location given for mathstubs.o will be wrong too
[21:14:30] <jmkasunich> MATHLIB = $(RTTMP_DIR)/mathstubs.o -L/usr/lib -lm
[21:14:38] <jmkasunich> you mean the RTTMP_DIR bit?
[21:14:42] <jmkasunich> that can be fixed
[21:15:12] <jmkasunich> on the new systems MATHLIB is empty
[21:15:16] <jmkasunich> so it should do no harm
[21:15:39] <jmkasunich> ubuntu:
[21:15:41] <jmkasunich> USE_RTLIBM = 1
[21:15:41] <jmkasunich> USE_LIBM =
[21:15:41] <jmkasunich> USE_STUBS =
[21:15:41] <jmkasunich> MATHINC =
[21:15:41] <jmkasunich> MATHLIB =
[21:16:01] <jmkasunich> BDI-2
[21:16:03] <jmkasunich> USE_RTLIBM =
[21:16:03] <jmkasunich> USE_LIBM = 1
[21:16:03] <jmkasunich> USE_STUBS = 1
[21:16:07] <jmkasunich> MATHINC =
[21:16:09] <jmkasunich> MATHLIB = $(RTTMP_DIR)/mathstubs.o -L/usr/lib -lm
[21:17:29] <jepler> I have to get going.
[21:17:35] <jepler> I should be back later, 9PM or so
[21:17:39] <jmkasunich> ok
[21:17:50] <jmkasunich> I might just try adding MATHLIB to the ld line(s)
[21:17:58] <alex_joni> it's already tomorrow here :)
[21:45:04] <jmkasunich> well, its worse than I thought
[21:45:20] <jmkasunich> there is an entire section of the configure script and Makefile.inc that is simply ignored
[21:46:06] <jmkasunich> the configure stuff related to the math lib is used to set vars in Makefiule.inc:
[21:46:12] <cradek> cool, my board works
[21:46:24] <jmkasunich> USE_RTLIBM, USE_LIBM, USE_STUBS, MATHINC, and MATHLIB
[21:46:35] <jmkasunich> and the new makefiles completely ignore all of those vars
[21:46:50] <jmkasunich> yay
[21:46:55] <jmkasunich> (the board works)
[21:47:06] <jmkasunich> glad to hear something is going right for someone
[21:48:57] <cradek> what signals do I look at to try to tune it?
[21:49:11] <jmkasunich> I dunno
[21:49:29] <fenn> still talking about math libs?
[21:49:49] <jmkasunich> yeah
[22:13:18] <jmkasunich> * jmkasunich goes away for a while