Back
[02:56:26] <c_morley> seb_kuzminsky: clicking 'forum' on the linuxcnc webpage fails to take one to the forum
[02:58:09] <c_morley> oh ok thats because the forum is down.....Could not connect to MySQL
[05:49:35] <jthornton> yep the forum seems to be down
[05:59:11] <skunkworks> zlog
[07:58:46] <R2E4> "Error displaying the error page...." Now that's broke.
[07:59:08] <R2E4> sorry, wrong channel
[08:55:42] <seb_kuzminsky> mysql is not running on flo
[08:57:20] <seb_kuzminsky> there are two suspicious-looikng things in the mysqld logs
[08:57:36] <archivist> show me
[08:57:46] <seb_kuzminsky> 151111 19:39:08 InnoDB: Initializing buffer pool, size = 128.0M
[08:57:46] <seb_kuzminsky> InnoDB: mmap(137363456 bytes) failed; errno 12
[08:57:47] <seb_kuzminsky> 151111 19:39:08 InnoDB: Completed initialization of buffer pool
[08:57:47] <seb_kuzminsky> 151111 19:39:08 InnoDB: Fatal error: cannot allocate memory for the buffer pool
[08:58:01] <archivist> !peeror 12
[08:58:08] <archivist> !perror 12
[08:58:09] <the_wench> OS error code 12: Cannot allocate memory
[08:58:28] <archivist> undersized vm?
[08:58:59] <archivist> 128 M buffer pool is small for a modern system too
[08:59:25] <archivist> by the way my bot started out in #mysql :)
[08:59:52] <seb_kuzminsky> it's got a gig, and withouth mysqld running there's 139 MB in use and 854 MB
[09:00:43] <seb_kuzminsky> bbl
[09:01:22] <archivist> yes but what are other processes like php apache etc using
[09:04:35] <seb_kuzminsky> http://imagesmtv-a.akamaihd.net/uri/mgid:file:http:shared:mtv.com/news/wp-content/uploads/2015/06/tumblr_n91lbyRmTm1s2wio8o1_500-1434065089.gif
[09:04:44] <seb_kuzminsky> jepler: should i try just restarting mysqld?
[09:07:06] <archivist> was it swamped by a googlebot or similar scanning or something
[09:33:56] <jepler> seb_kuzminsky: hello
[09:33:57] <jepler> no idea
[09:34:23] <jepler> [353990.814680] Out of memory: Kill process 18860 (mysqld) score 94 or sacrifice child
[09:34:27] <jepler> ugh several OOMs in dmesg
[09:35:08] <archivist> more memory or reduce max number of connections to system
[09:38:44] <jepler> seb_kuzminsky: now do the *picture* of the dog with the caption 'it's a unix system...'
[09:41:47] <jepler> anyway, I added 2GB of swap space to the system
[09:42:00] <jepler> I'm reluctant to move it to a higher-specced virtual machine because it's a big bump in $$
[09:42:51] <cradek> did it have any swap before?
[09:42:53] <jepler> and unfortunately I need an education to know how to 'reduce max number of connections'. meaning mysql or apache?
[09:42:56] <jepler> cradek: no, none
[09:43:10] <cradek> surely swap will fix it just fine then
[09:43:35] <cradek> no swap is not enough swap
[09:47:40] <archivist> I have my maxconnections set low in mysql at 30 because I am serving off a memory challenged box
[09:47:56] <archivist> often go into swap grrrr
[09:53:24] <mozmck> jepler: I guess you did not use dreamhost for the forum because you didn't have access?
[09:56:06] <seb_kuzminsky> mozmck: i think it was partially that, and partially that jeff wanted a vps instead of a shared host, so we have more control over it
[09:56:20] <jepler> yes both of those are factors
[09:56:22] <mozmck> I see.
[09:56:40] <jepler> but the problems with shared access to the dreamhost setup was certainly a huge factor
[09:58:12] <mozmck> The kicad website had all kinds of issues on a vps, but then they were using confluence (java) for the site, and they could never give it enough memory to not crash.
[09:59:06] <seb_kuzminsky> i'm glad we didn't pick anything java-related for any of the new web thingys we just made
[09:59:46] <cradek> I'm glad we don't do all sorts of stupid things
[10:00:10] <jepler> just some sorts
[10:02:07] <mozmck> :)
[10:04:26] <jepler> I've cut MaxRequestWorkers in half in apache
[10:04:49] <jepler> this should also cut in half the effective max number of mysql connections if I understand right
[10:06:42] <archivist> what about maxclients in apache
[10:07:00] <jepler> > MaxRequestWorkers was called MaxClients before version 2.3.13. The old name is still supported.
[10:07:20] <archivist> silly name changes!
[10:11:10] <jepler> it's amazing how little you can do with 1GB RAM these days
[10:11:39] <jepler> why, we all remember how the time sharing systems could support 131072 users on just 500 bytes of memory
[10:12:27] <jepler> but children today forget how we had to keep pushing the treadle to rotate that drum with 500 bytes of memory on it
[10:13:13] <jepler> and nobody names their children mel
[10:13:27] * seb_kuzminsky pats jepler
[10:13:33] <seb_kuzminsky> there there
[10:14:58] <seb_kuzminsky> there was a thing called swapd, that would add swap files when the system got low and remove them when memory pressure eased
[10:15:05] <seb_kuzminsky> i havent run it in years
[10:15:05] <jepler> yeah that was nuts
[10:16:39] <archivist> I just cannot understand why memory hogging code is regarded as good in any way
[10:17:41] <seb_kuzminsky> memory usage is often in the service of performance enhancement - ram is cheap, human-time is expensive
[10:18:40] <cradek> I don't think it's usually a choice/tradeoff made on purpose. it's just what happens when you don't particularly care about it.
[10:18:51] <jepler> minimizing memory usage requires careful analysis and is often put off until it becomes a critical and deep-seated problem in any software package
[10:18:53] <seb_kuzminsky> that could be too
[10:19:10] <cradek> it's not really considered "good", it's just that it's extra work to be careful about memory footprint
[10:19:17] <jepler> yes
[10:19:44] <seb_kuzminsky> which is why i've decided to add a micron-scale voxel map of world space, with a float in each box for spindle speed, and doing all trajectory planning there
[10:19:53] <cradek> some of it is probably just leaks (bugs) that usually don't bite anyone
[10:20:22] <cradek> and bitey bugs always get fixed first
[10:21:22] <seb_kuzminsky> speaking of bugs, i'm looking forward to fixing
https://sourceforge.net/p/emc/bugs/449/, to wash the taste of html out of my mouth
[10:21:26] <jepler> we knowingly choose technologies with terrible memory properties, just because available RAM is usually big compared to what we imagine our program will require
[10:22:27] <archivist> our old Altos used 256 k per user iirc
[10:23:04] <jepler> consider this Python program to l = [random() for i in range(1024*1024)]
[10:23:19] <archivist> back when terminals were in RS232 around a building
[10:23:25] <cradek> seb_kuzminsky: yay a bug you can fix in one C file
[10:23:25] <jepler> it makes a Python list of 1048576 random floating point numbers
[10:23:33] <jepler> but instead of 1 memory allocation of 8*1048576 bytes
[10:23:46] <jepler> it does about 138MB of allocations
[10:24:46] <seb_kuzminsky> cradek: yeah, and the test is already 95% written
[10:25:00] <seb_kuzminsky> jepler: yikes
[10:25:55] <archivist> it is that sort of story that stops me going OOP and python
[10:26:00] <jepler> each double itself seems to take 24 bytes of storage, but also there are a lot of intermediate allocations that are made
[10:26:09] <jepler> .. plus the 8-byte pointer to it in the list
[10:27:04] <archivist> string processing is a bit funky in php for a similar reason
[10:27:11] <jepler> so besides the 32MB needed to store what would take 8MB in C, an additional 100MB is allocated and freed in the process of doing all that work
[10:27:49] <jepler> .. and that's ignoring the fact that my stats (which come from valgrind) are about calls to malloc() etc, and don't count the allocations Python does (it has a series of pool allocators)
[10:28:05] <jepler> and yet .. I love python
[10:28:14] <jepler> and in summary, that's why I think you can't do anything with 1GB memory anymore
[10:28:57] <seb_kuzminsky> i bet there's some python kung fu to make it more efficient, but i dont know what it is
[10:31:06] <mozmck> OOP != python
[10:32:09] <mozmck> gtk is object-oriented C (and would have probably been 100 times better if they just used C++ instead of re-inventing it all in C)
[10:54:58] <seb_kuzminsky> hi JT-Shop, there are a bunch of broken links in docs/html/gcode.html in 2.7, have you seen this?
[10:55:28] <seb_kuzminsky> i fixed the french, but i wanted to talk with you before messing with the english since you started work on it
[11:34:40] <cradek> https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/29797-upgrading-and-migrating-the-linuxcnc-forum?start=10#65164
[11:35:34] <cradek> irritating
[11:44:20] <seb_kuzminsky> can't you just access the forum via http (not https)?
[11:44:28] <cradek> sure
[11:44:29] <seb_kuzminsky> then it shouldnt care about certs, right?
[11:44:39] <cradek> right
[11:44:48] <cradek> the issue is what the link from the main page does
[11:46:47] <seb_kuzminsky> right
[11:54:13] <seb_kuzminsky> is jepler using EFF Lets Encrypt for the cert?
[11:56:11] <Roguish> cradek: try the forum link you just posted, again.
[11:56:24] <Roguish> I added a short note......
[11:58:54] <seb_kuzminsky> :-)
[11:59:07] <cradek> thanks, I answered the question
[11:59:21] <seb_kuzminsky> having worked with jekyll for a while now, the
https://letsencrypt.org/ site sure looks like it was made with jekyll.. :-)
[11:59:24] <cradek> also I am a bear with a fish
[11:59:35] <cradek> I don't know why I have a fish
[12:01:07] <Roguish> cradek: i know you answered the question, but I really don't care for the helpless and hapless attitude.
[12:01:48] <cradek> I appreciate that
[12:02:26] <Roguish> oh well. off to the project for the day................... ciao.
[12:02:34] <cradek> enjoy
[12:05:23] <cradek> when I go to recent topics and then click on a thread, it shows me the first (oldest) page of messages in that thread. I can't find a setting that changes that. am I missing something?
[12:08:26] <mozmck> I'm sure there is a way to change that - it would be nice though.
[12:09:09] <mozmck> If there are multiple pages there will be numbers below the topic and you can click on the last number to go to the last page.
[12:09:18] <cradek> yeah I did see that
[12:09:35] <cradek> but ... I can't imagine doing the task of reading all new messages that way
[12:10:18] <cradek> I think "recent topics" is sorted the other way, with new on top of page 1
[12:10:22] <cradek> yeah
[12:12:16] <cradek> > Select default message ordering when viewing a topic. This setting can be overridden by user.
[12:12:25] <cradek> this is in the admin page
[12:12:37] <mozmck> interestingly, if I click on a topic that says there are new messages since I looked at the thread, it takes me to the first unread message.
[12:12:52] <cradek> oh, interesting
[12:13:03] <cradek> that would be less horrible
[12:13:56] <mozmck> I wonder where you override that setting?
[12:14:17] <cradek> there are a few preferences under profile / edit / update your profile
[12:14:28] <cradek> which is grossly misnamed
[12:14:31] <cradek> but that's all I've found
[12:14:33] <mozmck> I don't see any on mine
[12:14:45] <cradek> profile / edit / update your profile / contact info
[12:15:10] <mozmck> Frontend Language, Editor, Time Zone
[12:15:16] <cradek> yeah
[12:15:36] <cradek> seems like there must be another place
[12:21:31] <mozmck> Looks like it is set to not allow users to change Topic Layouts - I *think* this would only change the layout for that user.
[12:22:03] <cradek> oh let's try that?
[12:22:43] <mozmck> done
[12:23:07] <cradek> I don't see anything new in "contact info"
[12:24:06] <mozmck> me neither
[12:37:57] <cradek> I give up
[13:00:04] <JT-Shop> seb_kuzminsky, yes I know about them but didn't have time to fix them this morning
[13:59:18] <seb_kuzminsky> no rush or anything
[14:03:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05check-more-links 2748af3 06linuxcnc 10docs/src/Submakefile docs: verify the links in the gcode Quick Reference too * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2748af3
[14:03:38] <seb_kuzminsky> JT-Shop: if you do the link fixes on that branch ^^^ it'll verify for you when you run "make checkref_en"
[14:11:47] <cradek> cool!
[14:12:12] <seb_kuzminsky> oh, also, the buildbot will complain noisily about all the broken links, shortly
[14:15:56] <JT-Shop> ok
[14:16:14] <linuxcnc-build> build #3616 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3616 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:16:29] <linuxcnc-build> build #3618 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3618 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:19:49] <linuxcnc-build> build #1776 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1776 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:19:54] <linuxcnc-build> build #2825 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/2825 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:19:59] <linuxcnc-build> build #1777 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1777 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:20:06] <linuxcnc-build> build #1968 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1968 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:20:11] <linuxcnc-build> build #1287 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1287 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:20:54] <linuxcnc-build> build #1441 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/1441 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:21:14] <linuxcnc-build> build #244 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/244 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:21:22] <linuxcnc-build> build #244 of 1502.rip-jessie-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/244 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:21:38] <linuxcnc-build> build #244 of 1500.rip-jessie-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/244 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:21:50] <linuxcnc-build> build #244 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/244 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:22:12] <linuxcnc-build> build #1805 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1805 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[14:22:43] <jepler> errors ahoy
[14:23:06] <seb_kuzminsky> i guess they're in the parts of the quick ref that people dont click on very often
[14:41:10] <linuxcnc-build> build #3630 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3630 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, John Morris <john@zultron.com>
[16:00:25] <andypugh> cradek: Ever noticed how ideas can get simpler and simpler the longer you carr on not doing them?
[16:00:34] <andypugh> (carry on)
[16:00:37] <cradek> heh
[16:00:55] <andypugh> you know the draw-wire to resolver for absolute saddle position idea?
[16:01:01] <cradek> sure
[16:01:16] <andypugh> It became a 200:1 geardbox on the end of the leadscrew
[16:01:25] <cradek> cool!
[16:01:48] <andypugh> Then, it became a fine-pitched thread cut on the end of the ballscrew, and a worm-wheel on the resolver…
[16:02:09] <cradek> ooh that's even better
[16:02:27] <andypugh> I wonder if it can get any simpler?
[16:02:43] <cradek> so the screw turns
[16:03:01] <cradek> the worm is really clever
[16:03:04] <andypugh> It just counts ballscrew revs, really
[16:03:31] <cradek> wouldn't the worm wheel have to be pretty big diameter?
[16:03:43] <cradek> I assume your screw turns a lot of times over the travel
[16:03:50] <andypugh> About 120 turns
[16:04:00] <cradek> hmm
[16:04:20] <andypugh> If I use a 0.5mm circular pitch, then it’s all adequatelu compact
[16:04:41] <cradek> cutting a fine thread in a case-hardened screw seems hard
[16:04:41] <andypugh> Or 0.25 mod. That keeps it about the same size as the resolver diameter
[16:05:07] <cradek> you could make a sleeve
[16:05:11] <andypugh> I need to machine the ends anyway, and once you are through the hardening they machine quite well
[16:05:18] <andypugh> Or, indeed, a brass sleeve
[16:05:32] <cradek> oh sure, you could cut through and thread just the soft part
[16:05:46] <cradek> who cares what diameter it is
[16:06:20] <andypugh> I anticipate fitting it into the talstock-end support, but it might find a home in the drive-motor end. (less worry about thermal expansion having an effect at the motor end, as that is also the thrust-bearing end)
[16:07:00] <cradek> it sounds a lot like a threading dial
[16:07:24] <cradek> do any clever lathes do clever things for threading dials that could give you ideas?
[16:08:59] <cradek> if you can get to the end of the screw and mount a pin off-center, you could make an awesome 120-sided geneva wheel
[16:09:24] <cradek> then it could advance nicely between indexes and be still around the index
[16:10:48] <andypugh> I wonder how small a 120-tooth geneva could be?
[16:10:58] <cradek> probably not very
[16:11:26] <cradek> hey if you have a geneva wheel with a smaller but prime number of lobes, you'll still get individual discernable positions
[16:11:40] <cradek> I think
[16:12:02] <jepler> I was just thinking you needed two relatively prime ones so that you can discern p*q different positions
[16:12:04] <cradek> make 13 lobes and you'll get 10 turns but 120 positions
[16:12:37] <cradek> this is the coolest idea so far, but not the simplest
[16:13:49] <andypugh> In theory you could do it with just a resolver directly coupled to the screw and prime-ratio gearing to the motor, I think.
[16:15:04] <andypugh> Each motor-index can be made to happen at a different point on the screw
[16:15:14] <andypugh> No need for a geneva as such
[16:15:33] <cradek> yes maybe so
[16:16:11] <andypugh> I have just been trying out the motor and resolver in the core-box for the casting:
https://picasaweb.google.com/lh/photo/peSZLLJIqk5YimEhgYzJmtMTjNZETYmyPJy0liipFm0?feat=directlink
[16:16:49] <cradek> it's huge!
[16:17:18] <andypugh> Yes
[16:17:29] <andypugh> I am heartily sick of making patterns
[16:17:31] <jepler> https://youtu.be/WYcqJ5HdxA4?t=94
[16:17:59] <andypugh> Do you get to scroll back through the photos?
[16:18:06] <cradek> yes
[16:18:31] <andypugh> Back about 6 there is the pattern colection
[16:18:58] <cradek> that looks like a right pain
[16:19:25] <andypugh> All part of the fun.
[16:22:43] <andypugh> Interesting comparison: Original electrics:
https://picasaweb.google.com/lh/photo/yu5GFkcA8Qd5Bd0j0eNRydMTjNZETYmyPJy0liipFm0?feat=directlink
[16:22:59] <andypugh> https://picasaweb.google.com/lh/photo/21Rzb8YEaXx4m_SRPQRlxtMTjNZETYmyPJy0liipFm0?feat=directlink
[16:23:31] <andypugh> You can fit a VFD and a full CNC controller in the space originally taken by a transformer and one rectifier.
[16:24:19] <andypugh> (That’s a DN2800 Mini-ITX, Mesa 7i74, 7i49, 7i44 and 7i84
[16:24:26] <cradek> wow
[16:26:44] <cradek> to be fair, you took out a resistor too
[16:26:51] <andypugh> I am not going to try to fit the DC PSU and 8i20 drives in there, and in fact the VFD is probably better placed somewhere else in the machine base
[16:27:30] <andypugh> The resistor is still mounted in the door
[16:27:34] <cradek> ah
[16:28:36] <andypugh> I could probably get the 8i20s in the door, but I am not sure I want to.
