Back
[11:23:18] <skunkworks> sounds scary..
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/149853
[11:51:34] <cradek> it sounds like they've again tried to solve a position problem in the velocity realm - isn't that same mistake the original mach algorithm had?
[11:52:05] <cradek> I thought after a while they fixed it
[11:52:09] <cradek> but what do I know
[11:53:16] <mozmck> I think part of the problem is the non-realtime communication between mach and hardware.
[11:59:15] <pcw_home> They have pushed all the tricky real time spindle sync stuff out to the
[11:59:16] <pcw_home> external hardware so every hardware manufacturer gets to re-implement it themselves
[11:59:18] <pcw_home> (including the long learning curve to get it right)
[12:01:13] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/149857
[12:01:28] <skunkworks> you can't - yet
[12:03:47] <skunkworks> well.. I guess exact stop works.. just no path control
[12:20:28] <malcom2073> Heh, Mach4 "class" at cabin fever expo next weekend, I should sit through that just for grins
[13:32:07] <seb_kuzminsky> i opened a couple of issues on github and heard nothing about it
[13:32:18] <seb_kuzminsky> i bet there's a way to tell github to send an email on issues
[13:32:24] <seb_kuzminsky> and maybe squawk on irc
[13:32:57] <malcom2073> they're called hooks iirc
[13:44:48] <jepler> seb_kuzminsky: try clicking "watch" on the repository
[13:47:39] <seb_kuzminsky> jepler: it already says i'm currently "watching"
[13:48:35] <jepler> seb_kuzminsky: not sure then
[13:48:40] <jepler> maybe you are never notified of your own activity?
[13:49:47] <micges> jepler: yes
[14:00:19] <seb_kuzminsky> did anyone else get notified of my issues?
[14:00:22] <seb_kuzminsky> that sounded strange
[14:01:05] <cradek> [chris@git /git/linuxcnc.git]$ git add remote github ssh://github:LinuxCNC/linuxcnc.git
[14:01:08] <cradek> fatal: This operation must be run in a work tree
[14:01:22] <cradek> jepler: this isn't turning out to be any better than what you already do
[14:01:32] <seb_kuzminsky> cradek: did you mean git remote add?
[14:01:38] <cradek> oh wayt
[14:01:39] <cradek> wait
[14:01:42] <cradek> good grief
[14:01:44] <seb_kuzminsky> wheyt
[14:01:54] <cradek> jeeqz
[14:02:07] <cradek> this is ridonculous
[14:03:25] <cradek> oh hey I got it right in about seven tries
[14:05:16] <seb_kuzminsky> so i conclude that in order to get prodded on irc when github issues happen, we must set up a webserver to receive the github webhook request by HTTP POST
[14:05:28] <cradek> jepler: I'm doing periodic mirrors now; you can disable yours
[14:05:52] <jepler> cradek: OK
[14:05:54] <seb_kuzminsky> that webhook would do something like the wlo hook i already set up, using kgb
[14:06:20] <cradek> seb_kuzminsky: wait, don't half the github users want this already? surely they all haven't set up web servers.
[14:06:38] <jepler> cradek: OK, my script is disabled.
[14:06:41] <jepler> cradek: how often will yours run?
[14:06:56] <seb_kuzminsky> cradek: i would think so too, but i dont see how to do it
[14:07:00] <seb_kuzminsky> maybe i just missed it somewhere
[14:07:09] <seb_kuzminsky> jepler: i got an email about your reply to my issue, so yay for that
[14:08:02] <cradek> I wrote */6 as a first guess
[14:09:20] <jepler> seb_kuzminsky: and as a belated answer to your question, yes, I did get e-mails about the issues you opened
[14:09:48] <seb_kuzminsky> cradek: oh weight, there's something
[14:10:06] <seb_kuzminsky> it's a "service", but not listed in the services directory
[14:13:33] <cradek> it's totally weird how everyone sshes to git@github instead of theirname@github
[14:13:42] <cradek> I wonder what magic they have sprinkled on ssh
[14:14:21] <jepler> debug1: Remote protocol version 2.0, remote software version libssh-0.7.0
[14:14:52] <jepler> I don't know exactly, but one unfortunate consequence of that decision is that you can't have two accounts that share the same ssh key
[14:14:57] <cradek> it says "Hi cradek!" but that's not my local account name
[14:15:18] <cradek> so they must try ALL the ssh pubkeys on all the accounts to see which one works!?
[14:15:35] <malcom2073> Or they have a pubkey/username map
[14:15:59] <cradek> no, I think they can't know my username
[14:16:26] <jepler> I am pretty sure they do it by looking up github username from your public key
[14:16:34] <malcom2073> github username, of course they know it, you added your pubkey to your account :P
[14:16:54] <cradek> I don't understand
[14:17:14] <cradek> I'm not sending the public half when I connect! how do they correlate it?
[14:17:31] <jepler> what do you mean, you're not sending the public half?
[14:17:35] <malcom2073> You can connect without public key?
[14:18:05] <cradek> I gave them the public half. I connect using the private half. how do they know they're connected?
[14:18:25] <malcom2073> Oh, duh
[14:18:50] <jepler> debug1: Offering RSA public key: /home/jepler/.ssh/id_rsa
[14:18:50] <jepler> debug1: Server accepts key: pkalg ssh-rsa blen 279
[14:18:50] <jepler> debug1: read PEM private key done: type RSA
[14:18:50] <jepler> debug1: Authentication succeeded (publickey).
[14:19:11] <cradek> or can you calculate "the fingerprint you're looking for" given the non-.pub file
[14:19:34] <jepler> I may be using the wrong terms, but they are doing something that is just like openssh does to correlate a line in authorized_keys to e.g., apply a restricted commandline
[14:20:20] <jepler> github works similarly to gitolite, which can also use one username and a bunch of distinct public keys to enforce repository access restrictions.
http://gitolite.com/gitolite/overview.html#how-does-it-work
[14:21:25] <cradek> I see
[14:21:55] <cradek> I think the model of ssh authentication in my head was wrong
[14:22:33] <malcom2073> Private and public keys have the same fingerprint
[14:22:38] <malcom2073> so you can calculate a public fingerprint from a private key
[14:22:42] <cradek> which was sort of like "try each of the things in authorized_keys and see if any of them happen to jive"
[14:22:52] <cradek> yeah I think that's the piece I was missing
[14:22:58] <malcom2073> I was googling to find that out :P
[14:22:59] <cradek> if so, then it's a simple mapping
[14:23:26] <cradek> so yeah, the only problem is you can't use the same key for two accounts
[14:23:44] <malcom2073> Why do you have two accounts?
[14:23:47] <cradek> or more generally, you can't use two keys with the same fingerprints
[14:23:48] <malcom2073> Oh, organization account?
[14:24:35] <jepler> I wouldn't use the same github account for my personal activities and my day-job activities
[14:25:18] <cradek> for a variety of reasons I couldn't exhaustively list, I bet
[14:30:22] <jepler> seb_kuzminsky: are you feeling OK?
[14:30:44] <seb_kuzminsky> yeah i'm fine
[14:30:56] <jepler> cradek:
http://gitolite.com/gitolite/how.html#%2811%29
[14:31:16] <jepler> >> one of the things it does is add this key to ~/.ssh/authorized_keys file, but prefixed with a bunch of options, one of which is a "command" option that looks like this:
[14:31:19] <jepler> command="/home/git/bin/gitolite-shell alice"
[14:31:23] <jepler> >>
[14:31:24] <jepler> This is how Gitolite distinguishes users from each other, even though they're all accessing the same (git@host) account.
[14:47:32] <jepler> seb_kuzminsky: what is linuxcnc-github going to do for us?
[14:50:33] <seb_kuzminsky> it'll announce issues, issue comments, and PRs here in #linuxcnc-devel
[14:50:40] <jepler> ah I see
[14:51:33] <seb_kuzminsky> if people think that'd be useful
[14:54:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler created 06jepler/docbook-xsl (+3 new commits): 02
https://github.com/LinuxCNC/linuxcnc/compare/ce79aedcfb3a^...efb01d3a4570
[14:54:42] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06jepler/docbook-xsl 14ce79aed 15Jeff Epler: packaging: build-time dependency on docbook xsl files...
[14:54:42] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06jepler/docbook-xsl 14abecee2 15Jeff Epler: don't permit xsltproc to use the network...
[14:54:42] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06jepler/docbook-xsl 14efb01d3 15Jeff Epler: build: remove attractive nuisance...
[14:54:56] <cradek> neato
[14:54:58] <seb_kuzminsky> oops, and push, i guess
[14:56:04] <seb_kuzminsky> the irc announcements can be turned on/off for each "event"
[14:58:47] <jepler> odd, I pushed that to glo yesterday
[15:00:17] <seb_kuzminsky> hmm
[15:01:07] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #24: test issue, ignore 02
https://github.com/LinuxCNC/linuxcnc/issues/24
[15:01:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #24: Ignore this comment too. 02
https://github.com/LinuxCNC/linuxcnc/issues/24#issuecomment-169454009
[15:02:02] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky closed issue #24: test issue, ignore 02
https://github.com/LinuxCNC/linuxcnc/issues/24
[15:02:27] <seb_kuzminsky> ok...
[15:02:36] <seb_kuzminsky> seems to work about as i had hoped
[15:03:34] <seb_kuzminsky> let's give this a try, if it gets annnoying we can turn it off (just disable the IRC Service in the linuxcnc/linuxcnc repo Settings/Webhooks & Services
[15:04:44] <malcom2073> seb_kuzminsky: Is that using the built in github irc hooks?
[15:07:09] <seb_kuzminsky> malcom2073: yeah
[15:07:38] <seb_kuzminsky> i'm glad cradek set me back on the path after i went chasing off after yet another vm with apache and scripty kludgery
[15:46:33] <skunkworks> and the answer..
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/149858
[15:49:53] <andypugh> I wonder why Mach4 took so long when it mainly seems to be an exercise in taking out all the motion control and offloading it to external hardware?
[15:59:50] <jepler> I assume it takes a fair amount of time to iterate the design of the offload protocol/API itself
[16:00:09] <jepler> to talk any hardware developers into implementing your latest design
[16:07:24] <skunkworks> some of the hardware folk are sounding a bit tired of it.
[16:08:26] <skunkworks> there was a tread that backlash is now done in hardware. The printer port driver from art was done before the final spec came out so it doesn't do backlash. or threading
[16:08:30] <skunkworks> thread
[16:09:18] <Tom_itx> what about wear?
[16:11:40] <skunkworks> wear?
[16:15:59] <Tom_itx> there will always be _some_ backlash
[16:24:19] <skunkworks> ah
[16:24:39] <skunkworks> not with preloaded ball screws...
[16:25:53] <cradek> I've sure seen no measurable backlash (with a .0001 indicator) on more than one machine with good large preloaded ballscrews
[16:29:24] <skunkworks> same here.
[16:30:50] <cradek> iirc, my jr has two nuts with two circuits each on each screw
[16:31:42] <cradek> on a 40mm diameter screw or so? they're huge.
[17:16:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 c86575e 06linuxcnc 10docs/src/hal/comp.txt docs: clarify what "option userspace yes" means to halcompile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c86575e
[17:18:55] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek pushed 1 new commit to 062.7: 02
https://github.com/LinuxCNC/linuxcnc/commit/c86575e0f584595d7cab8b0b2d03a2671c2ede5b
[17:18:55] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/062.7 14c86575e 15Sebastian Kuzminsky: docs: clarify what "option userspace yes" means to halcompile...
[17:25:14] <mozmck> heh, now we get 2 notices for each commit!
[17:25:25] <cradek> I did?
[17:25:55] <cradek> uh, the second one with my name always
[17:26:11] <mozmck> KGB-linuxcnc and linuxcnc-github both noted seb push
[17:26:12] <KGB-linuxcnc> mozmck: My master told me to not respond.
[17:26:20] <mozmck> shut up then!
[17:26:25] <mozmck> ;-)
[17:26:37] <seb_kuzminsky> hrm
[17:26:46] <seb_kuzminsky> maybe i should tell linuxcnc-github to not tell us about commits, hold on
[17:26:48] <cradek> heh seb can turn that one off I bet, no prob
[17:27:00] <cradek> oh look here he is
[17:27:05] <mozmck> oh, looks like the github one sent 2 notices for the same commit.
[17:29:14] <seb_kuzminsky> mozmck: it sent a notice that there was a push, then it sent a notice for each commit in the push (which was just one this time)
[17:29:41] <seb_kuzminsky> i turned off the "push" even on the irc hook, now it should just let us know about pull requests, issues, and issue comments
[17:29:48] <seb_kuzminsky> speaking of issues...
[17:31:50] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #25: halcompile with "option userspace yes" claims to support count= and names= arguments, but does not 02
https://github.com/LinuxCNC/linuxcnc/issues/25
[18:07:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/rt-thermistor e1b6714 06linuxcnc 03src/hal/components/thermistor.comp add a realtime thermistor component * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e1b6714
[18:08:10] <seb_kuzminsky> this is the look of defeat
[18:11:24] <jepler> so basically your review of halcompile in userspace mode is "F"?
[18:11:50] <jepler> like so many things, I meant well when I wrote the first line of "comp"
[18:13:53] <seb_kuzminsky> jepler: i think it works great for realtime components
[18:14:11] <seb_kuzminsky> i was trying to use it for something relatively unusual, and i'm not surprised it didn't work the first time around
[18:15:00] <seb_kuzminsky> but i had set myself the goal of getting my printer up and running this week, so i want to focus on that, and this is the shortest path around this particular obstacle...
[18:17:34] <andypugh> The thermistor comp reminds me of the difference between how we control engines in Europe and how they like to do it in the US. We always use lookup tables (lincurve). They always want to use a polynomial. (thermistor.comp). I wonder which is most computationally expensive?
[18:18:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/docbook-xsl 97acca7 06linuxcnc 10debian/control.in packaging: build-time dependency on docbook xsl files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=97acca7
[18:18:14] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/docbook-xsl b4a7878 06linuxcnc 10docs/src/Submakefile don't permit xsltproc to use the network * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b4a7878
[18:18:14] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/docbook-xsl f7bda07 06linuxcnc 04docs/src/Makefile build: remove attractive nuisance * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f7bda07
[18:24:01] <seb_kuzminsky> surely computing the polynomial every servo cycle is more expensive than a lut
[18:25:58] <seb_kuzminsky> but on the other hand, the computational way just needs one or two easy-to-measure inputs that you get from a data sheet
[18:26:21] <seb_kuzminsky> but on the third hand, it has no way to adjust for discrepancies between theory and reality
[18:34:17] <andypugh> The lut has to search the index, so it’s not that clear-cut. Though a sensible LUT implementation stores the index between calls as most inputs vary slowly.
[18:54:04] <jepler> seb's code is well worse than "a polynomial" though
[18:54:51] <jepler> libm exp and log will turn out not only to be expensive in the usual case, but to have some input values that take 10x or even 100x as long to compute as the average
[18:55:49] <andypugh> But, and this is probably important, folk will be able to understand how to use it. Almost nobody “gets” what lincurve is useful for.
[18:56:23] <jepler> and I wish more people would use lut5 :_
[18:56:24] <jepler> :)
[18:56:53] <andypugh> Lincurve can do anything that LUT5 can do :-)
[18:57:22] <andypugh> I am wondering just how many of the HAL components could be replaced by LUT, if you were feeling really eccentric
[18:57:53] <andypugh> Any unary function, I suppose, or any that can be converted into a unary function.
[18:58:08] <andypugh> bldc is one example
[18:58:55] <andypugh> (To use lincurve as LUT5 you need the weighted sum and a number of type conversions)
[18:58:58] <jepler> enough lut5s can do anything lincurve can do!
[18:59:08] <jepler> .. but the number is probably in the hundreds
[18:59:22] <andypugh> I am giggling at the thought.
[18:59:35] <jepler> .. thousands?
[19:00:47] <andypugh> For any floating point input you need a floating point output, so you need a 4 x 64 array of LUT5
[19:01:10] <andypugh> No, only 2 x 64, isn’t it?
[19:01:31] <seb_kuzminsky> on second thoughts, let's not go to camelot
[19:01:38] <andypugh> That’s worst case. If there are any duplicate values or flat areas in the curve I think you can save some
[19:03:14] <andypugh> No, it’s too late here. You only get 5 input bits per LUT5. If you map every bit of a float to a LUT5 input, and have that many LUT5s for each bit of the output, I think you can do it.
[19:04:47] <andypugh> 832 LUT5 components can perform any mathematical transfomration in finite time. Possibly quite a short time too.
[19:06:50] <andypugh> Or am I wrong? I wouldn’t be surprised as that seems to suggest that a 64-bit x 64 bit LUT is a perfectly reasonable way to do any mathematical function of floats, at a cost that seems reasonable by modern memiry statndards.
[19:09:02] <jepler> my own train of thought made me think that you'd need 64 128-input LUTs, but I didn't figure out how many LUT5s that would be
[19:10:06] <jepler> a 5-input LUT needs 32 bits to specify, an N-input lut needs 2^N bits, so you need 64*2^128 bits to specify this constellation of LUTs. I think that's infeasible.
[19:11:33] <andypugh> Yes.
[19:11:56] <andypugh> I was analysing it pictorially in my head, and starting from a false premise.
[19:12:49] <andypugh> A 64-bit x 64-bit table defines one output bit.
[19:13:01] <andypugh> Youneed 64 of them.
[19:14:24] <andypugh> Even then, 32k for an arctan calculated entirely by bit operations might be reasonable in some situations.
[19:15:04] <andypugh> And, once again, I get it wrong….
[19:15:13] <andypugh> I’ll just shut up
[19:17:15] <andypugh> The count of all possible floating point numbers is the same as the count of all possible long ints, and that _isn’t_ a sensible amount of memory to allocate to a LUT. By definition you couldn’t address it.
[19:18:22] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes10 9477879 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py remove blanks in trajcoordinates * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9477879
[19:18:22] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes10 02a9d30 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py decode ja_rbutton value for joint homing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=02a9d30
[19:18:23] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes10 7722245 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py: fix confused message and comment * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7722245
[19:47:06] <jepler> I wrote a "simple"(?) benchmark program of exp() and ran it on a 64-bit userspace
[19:47:18] <jepler> the majority off exp() calls take around 2^5 cycles
[19:47:33] <jepler> but some outliers, <<1%, take much more, around 2^11 cycles
[19:49:57] <jepler> https://emergent.unpythonic.net/files/sandbox/mathbench.cc
[19:54:43] <andypugh> So, worst case at 2GHz is about 1 uS?
[19:55:40] <jepler> but if there are one-in-a-million outliers, are there also one-in-a-billion outliers? there are a lot of special cases in libc's exp() function!
[19:55:52] <andypugh> Hopefully nobody gas 1000 thermistors :-)
[19:55:53] <jepler> seb_kuzminsky: can you kick the buildbot? Not sure from here what's stuck...
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3855
[19:56:05] <seb_kuzminsky> fine fine, i'll reimplement it as a network of luts and lincurves
[19:56:18] <seb_kuzminsky> jepler: i just noticed that too...
[19:57:04] <seb_kuzminsky> [103463.899271] INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 1, t=21450656 jiffies, g=609207, c=609206, q=8424)
[19:57:07] <seb_kuzminsky> [103463.899271] INFO: rcu_sched self-detected stall on CPU { 1} (t=21440482 jiffies g=-165 c=-166 q=23)
[19:57:43] <seb_kuzminsky> thanks for those quick fixes, dewey
[19:57:47] <seb_kuzminsky> if you're listening
[19:57:54] <andypugh> It is interesting that exp() is so variable.
[19:59:54] <jepler> the implementation of exp is pretty horrifying, particularly if you don't spend much time with math code
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/e_exp.c;h=ad1bc84625a7f779004d144219619387f0021860;hb=d7f914848b7d5e9b11bbffd1fecc4659d4acdc2d
[20:00:41] <jepler> but you'll notice at line 104 it can call __slowexp
[20:00:57] <jepler> .. which is in
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/slowexp.c;h=b6022627837f5b438ac4933674c20f7838fd7f22;hb=d7f914848b7d5e9b11bbffd1fecc4659d4acdc2d
[20:01:06] <jepler> 52
[20:01:06] <jepler> 53 /* Use the multiple precision __MPEXP function to compute the exponential
[20:01:09] <jepler> 54 First at 144 bits and if it is not accurate enough, at 768 bits. */
[20:01:17] <jepler> so there's the good case, the 144-bit slow case, and the 768-bit slow case
[20:04:29] <andypugh> That sort-of hints that there isn’t the one-in-a-billion 1mS version.
[20:04:31] <jepler> there may be room in the world for a "realtime libm" which doesn't have the same accuracy guarantee as glibc's libm (for instance, that exp() is correctly rounded for all arguments in the round-to-nearest mode, but instead a lesser guarantee like that 12 bits are accurate..) but has no worst-case execution time
[20:06:06] <seb_kuzminsky> everything is so broken
[20:06:20] <seb_kuzminsky> the buildmaster now gets wedged when the jessie rtai i386 buildslave hangs
[20:06:53] <andypugh> “An Ultimate exp routine” for a specific value of ultimate (ie, as accurate as possible)
[20:11:15] <jepler> actually if I can believe the debugger, I have hit the 144-bit case but not the 768-bit case
[20:13:04] <jepler> (I set a breakpoint and it was never hit during my million repetitions)
[20:18:44] <jepler> $ python -mtimeit -s 'from math import exp' 'exp(-1)'
[20:18:45] <jepler> 10000000 loops, best of 3: 0.0742 usec per loop
[20:18:45] <jepler> $ python -mtimeit -s 'from math import exp' 'exp(-1.6286668646459018e-08)'
[20:18:47] <jepler> 1000000 loops, best of 3: 0.844 usec per loop
[20:19:10] <jepler> wow the speed difference between the fast case and the 144-bit case is large enough that it's big compared to Python function-call overhead
[20:19:26] <seb_kuzminsky> yikes
[20:20:24] <seb_kuzminsky> you know what
[20:20:28] <seb_kuzminsky> it doesnt matter
[20:20:37] <seb_kuzminsky> since none of our rtai math libs have exp
[20:20:42] * seb_kuzminsky <-- idiot
[20:20:58] <seb_kuzminsky> or log
[20:21:00] <seb_kuzminsky> sigh
[20:32:06] <jepler> $ python -mtimeit -s 'from math import exp; x=7.3149264423210325e-12' 'exp(x)'
[20:32:09] <jepler> 100000 loops, best of 3: 18.5 usec per loop
[20:32:35] <jepler> or 2^16 cycles according to my cycle-counting program
[20:35:02] <jepler> and yes it was about 2 billion iterations to find that one value ..
http://paste.debian.net/361720/
[21:24:40] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes10 0864f3e 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py unhome_joint fix cut/paste mistake * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0864f3e
[21:24:40] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes10 7f68abe 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py: improve conformance of j/a key bindingss * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f68abe
[21:50:13] <linuxcnc-build> build #997 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/997 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:05:34] <linuxcnc-build> build #3054 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3054 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:17:50] <linuxcnc-build> build #3849 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3849 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:25:06] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky closed issue #23: joints _axes: cannot home in Axis GUI 02
https://github.com/LinuxCNC/linuxcnc/issues/23
[22:25:16] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky closed issue #22: joints_axes: hotkeys no longer select joints/axes in Axis GUI 02
https://github.com/LinuxCNC/linuxcnc/issues/22
[22:50:27] <linuxcnc-build> build #1669 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1669 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:02:12] <linuxcnc-build> build #110 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/110 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:09:13] <linuxcnc-build> build #3857 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3857 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:35:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/thermistor a1efd4a 06linuxcnc 03src/hal/user_comps/thermistor.comp add a thermistor component * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a1efd4a
[23:35:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/thermistor ea0ddce 06linuxcnc 10src/Makefile build: add a "make headers" target, to let userspace comps build * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ea0ddce
[23:35:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/thermistor 04304f0 06linuxcnc 10src/hal/user_comps/Submakefile build system: add user_comps .comp support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=04304f0
[23:35:52] <KGB-linuxcnc> 05seb/2.7/thermistor 2c293aa 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2c293aa
[23:35:55] <KGB-linuxcnc> 05seb/rt-thermistor e1b6714 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e1b6714