Back
[00:04:37] theorb is now known as
theorbtwo
[00:10:35] <CIA-99> tissf v2.5_branch * rcad417c45d07 /docs/src/ (common/Linux_FAQ_fr.txt gui/gladevcp_fr.txt index_fr.tmpl): docs: fix broken link - re-branding
[00:10:36] <CIA-99> tissf v2.5_branch * rc39f41b91fc0 / (3 files in 3 dirs): docs: re-branding
[00:26:59] -!-
skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-425.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:28:05] -!-
skunkworks has quit [Client Quit]
[00:28:19] -!-
skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-425.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:29:49] -!-
skunkworks has quit [Client Quit]
[00:30:10] -!-
skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-425.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:35:07] -!-
tissf_ has quit [Quit: Page closed]
[00:46:47] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[00:56:01] <jthornton> jepler: OK, just trying to see what else to change in the documents
[01:19:17] -!-
cmorley has quit [Quit: Leaving.]
[01:20:02] -!-
cmorley [cmorley!~chris@154.5.119.100] has joined #linuxcnc-devel
[01:26:56] -!-
rob_h has quit [Ping timeout: 240 seconds]
[01:31:49] -!-
GoSebGo has quit [Quit: Bye]
[01:32:20] -!-
GoSebGo [GoSebGo!~Seb@184-222-69-111.pools.spcsdns.net] has joined #linuxcnc-devel
[01:32:45] -!-
toastydeath has quit [Read error: Connection reset by peer]
[02:06:50] -!-
clytle374 [clytle374!~clytle374@75.105.212.57] has joined #linuxcnc-devel
[02:19:49] -!-
cevad has quit [Quit: Leaving]
[02:45:43] <jepler> docs: I've updated the pages
http://linuxcnc.org/docs/devel/ and
http://linuxcnc.org/docs/2.5/ to refer to LinuxCNC PDFs while preserving the old URLs with the deprecated names in case of direct links
[02:53:07] <clytle374> jepler, I started working on the wiki, but don't know how I should handle pages with names including emc
[03:01:47] -!-
LawrenceSeattle has quit [Ping timeout: 255 seconds]
[03:01:47] LawrenceSeattle_ is now known as
LawrenceSeattle
[03:03:03] <jepler> clytle374: I've determined that there is a rename facility on the wiki, and it handles fixing pages on the wiki that link to that page
[03:03:43] <jepler> clytle374: in light of this, I would say to use the rename facility since that fixes on-site links
[03:04:00] <jepler> it may still be worth it to prepare a page under the old name which simply links to the new page
[03:04:37] <jepler> clytle374: if you promise you'll use it responsibly, I'll give you a password to enter on the preferences page that will give you additional editor permissions including renaming pages.
[03:05:09] <clytle374> I promise I'll be careful.
[03:05:14] <jepler> OK
[03:05:30] <clytle374> Just change refrences to EMC to LinuxCNC, right?
[03:05:48] <jepler> right
[03:06:21] <jepler> particularly in places where the text refers to a product or service, whatever that means :-P
[03:06:55] <jepler> one thing that means is that if it refers to an item you select from a list or a thing that you type, so that changing it would make the example not work, then don't change it
[03:07:11] <jepler> it's complicated and nebulous and a pain in everyone's a--
[03:07:21] <clytle374> Sounds like usually legalize disservice to me.
[03:07:57] <clytle374> yeah, I figured not to change it where it talks about using git. Have to change it later tho
[03:08:34] <jepler> it sounds like you have as good a handle on it as anyone
[03:09:16] <jepler> any more questions or needed clarifications before I wander off?
[03:09:49] <clytle374> So no problem creating pages with the old name linking to the new page? Be nice to not break offsite links and bookmarks
[03:09:49] <clytle374> Other than that, sounds good
[03:10:07] <seb_kuzminsky> jepler: thanks for all your work, legal and technical... sounds like it must have been a stressful pain in the ass
[03:10:29] <jepler> clytle374: yes it should be OK to create a page with that name that simply directs to the new location
[03:11:08] <clytle374> thanks
[03:12:52] <seb_kuzminsky> i realize my timing may not be very good here... but i noticed some old cruft the other day
[03:13:04] <jepler> seb_kuzminsky: it wasn't until the time that we decided the best course was to rename that I realized how much of a factor "the issue" had been in my continued low level of public involvement ..
[03:13:06] <seb_kuzminsky> we have our own implementation of the sincos() function, and we never use it
[03:13:40] <cradek> jepler: we're glad you're back
[03:13:43] <seb_kuzminsky> how long has the BoD been worrying about "the issue"?
[03:14:10] <cradek> Mar 22
[03:14:26] <seb_kuzminsky> scheisse!
[03:14:58] <seb_kuzminsky> thanks for insulating the rest of us from that!
[03:14:59] <jepler> seb_kuzminsky: interesting you should raise that issue. we have this report about sincos from one of our few brave 64-bit user/developers:
http://mid.gmane.org/20111222160214.3d930896@milhouse
[03:15:19] <jepler> so apparently (A) an implementation is needed for somebody but (B) he's not getting it when it is needed
[03:16:03] <seb_kuzminsky> huh
[03:16:03] <jepler> i swear I have another mail here somewhere, possibly from the same person, where we determined that the compiler managed to make the body of *our* sincos a call to sincos .. but maybe that is just a fever dream
[03:18:07] <seb_kuzminsky> he's on 64-bit realtime? on hardy, or with a custom kernel of his own?
[03:18:53] <jepler> I believe with a kernel of his own
[03:18:56] <jepler> yes, 64-bit and realtime
[03:19:19] -!-
toastydeath has quit [Read error: Connection reset by peer]
[03:19:47] <jepler> hah, it's true. a straightforward implementation of sincos is compiled by gcc into a call to sincos()!
http://pastebin.com/yj9zec8P
[03:19:57] <jepler> line 28 for the money shot
[03:21:20] <seb_kuzminsky> try it with gcc -fno-builtin-sincos
[03:22:20] <jepler> actually that still emits a call to sincos
[03:22:30] <jepler> -ffreestanding emits calls to sin and cos as expected
[03:22:44] <jepler> -fno-builtin-sin emits calls to sin and cos
[03:23:28] <seb_kuzminsky> wait, do builtins act like compiler-supplied inline functions? if you make your sincos() do something sille, like printf() something, does the output include your silliness?
[03:23:40] -!-
LawrenceSeattle has quit [Quit: LawrenceSeattle]
[03:25:44] <jepler> this program has the property that it crashes for me when built with -O3:
http://emergent.unpythonic.net/files/sandbox/sincos.c
[03:25:49] <jepler> because it runs out of stack space recursing into sincos
[03:26:02] <seb_kuzminsky> oh gcc, what shall we do with you?
[03:26:20] <jepler> built with -O0 or with -O3 -fno-builtin-sin it works
[03:27:31] <seb_kuzminsky> ok i take back what i said
[03:27:48] <seb_kuzminsky> we *do* need to supply sincos, because rtai lacks it
[03:28:33] <cradek> we have about 11 calls to sincos in the whole system. why not just replace them and remove the problem?
[03:28:44] <jepler> cradek: because there's the danger that gcc will add calls to sincos if you calculate sin(th) and cos(th) too close together
[03:28:56] <cradek> oh
[03:29:01] <jepler> which is .. insane
[03:30:21] <seb_kuzminsky> rtai lacks sin and cos too, rtapi supplies them
[03:31:34] <seb_kuzminsky> at least for i386, apparently not for amd64
[03:31:49] <seb_kuzminsky> by calling the fsin/fcos asm instructions
[03:32:35] <seb_kuzminsky> i wonder how any trig works on amd64/rtai... does it use src/rtapi/rtapi_math_i386.h?
[03:32:39] <seb_kuzminsky> i'm confused
[03:34:07] <jepler> on this system (I think this was the hardy 64-bit rtai kernel?) rtai_math.ko *does* have an implementation of some trig functions such as sin
[03:34:10] <jepler> jepler@lamp:/usr/realtime-2.6.24-16-rtai/modules$ nm rtai_math.ko | grep -w sin
[03:34:13] <jepler> 0000000000003d20 T sin
[03:34:50] <seb_kuzminsky> ah, i just checked the rtai header files, they lack trig
[03:35:02] <jepler> hence the declarations in rtapi_math.h regardless
[03:35:49] <seb_kuzminsky> sounds like cradek's got the right answer then
[03:36:09] <seb_kuzminsky> if sin and cos are available, gcc's sincos should work, right?
[03:36:16] <jepler> if we can find a compiler flag that reliably inhibits the transformation of other code into sincos calls
[03:37:58] <jepler> er, I think we're not agreeing somewhere here
[03:38:15] <jepler> what I am saying is that some versions of gcc sometimes *emit* calls to an extern sincos function when they encounter sequences like
[03:38:18] <jepler> *s = sin(theta);
[03:38:21] <jepler> *c = cos(theta);
[03:38:32] <seb_kuzminsky> oh, right
[03:38:48] <seb_kuzminsky> that's crazy
[03:38:57] <jepler> which it's fair to do because sin, cos, and sincos all have fixed meanings in the C standard
[03:39:04] <seb_kuzminsky> so what does it mean when gcc has a "builtin" function?
[03:39:56] <jepler> that means that cos is synonymous with __builtin_cos and any optimization opportunity that arises when __builtin_cos is used can be applied
[03:40:41] <jepler> one of those optimizations applies to the situation where a call to __builtin_sin and __builtin_cos occur with the same argument
[03:41:03] <jepler> that optimization is "replace two calls with one call"
[03:41:25] <jepler> and that optimization makes sense because some implementations of sincos are more efficent than a call to sin + a call to cos (e.g., if the implementation is the fsincos x87 instruction)
[03:41:38] <jepler> sooooo .. -fno-builtin-sin is enough to inhibit the transformation, I think
[03:41:48] <jepler> (or -fno-builtin-cos)
[03:42:22] <seb_kuzminsky> at the cost of slower sin/cos functions (because now it's a library call instead of gcc-supplied inline assembly)?
[03:44:02] <jepler> I am not sure which sets of flags allow the transformation of __builtin_cos to an inline fcos instruction. -O -ffast-math -mno-ieee-fp is sufficient, though.
[03:44:21] <jepler> (and the sin+cos into a fsincos instruction inline, actually)
[03:45:56] <jepler> on x86_64 kernel space is using sse(2?) exclusively for FP, so I think there is no inline expansion of sin, cos or sincos
[03:48:29] <jepler> so in summary, I really don't know what to do, only that it's complicated and that the situation is unfortunate for our possibly lone 64-bit user
[03:49:47] <seb_kuzminsky> there's hardy-rtai-amd64 machine in the buildbot, it passes all the tests, all the time
[03:50:31] <jepler> is there any test that exercises siggen, even just to see if it loads?
[03:51:14] -!-
mshaver [mshaver!~mshaver@c-68-50-233-206.hsd1.md.comcast.net] has parted #linuxcnc-devel
[03:51:25] <jepler> the last reported problems on 64-bit were a crash when doing a g3 circular motion and inability to load siggen at all
[03:51:31] <jepler> I don't think the runtests cover either of those
[03:52:54] <seb_kuzminsky> i've got the 64-bit rt buildslave down for monkey business right now, i'll check when it comes back up
[03:54:17] <jepler> I'm about to pack it in for the night
[03:54:28] <seb_kuzminsky> goodnight jeff!
[03:55:28] <jepler> we value your attention to detail
[04:31:06] -!-
ve7it has quit [Remote host closed the connection]
[04:33:44] -!-
pfred1 has quit [Quit: bye]
[04:42:57] -!-
clytle374 has quit [Quit: Leaving]
[05:00:57] -!-
cstop has quit [Quit: Leaving]
[05:04:23] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[05:16:23] -!-
Jymmm has quit [Remote host closed the connection]
[05:53:13] -!-
psha[work] has quit [Ping timeout: 240 seconds]
[05:53:26] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel