[03:12] so looks like i may find another collection of pdfs to grab [07:13] Jack in the box fast food website. Got a 404. Check it. http://www.jackinthebox.com/menu/product?prod_id=java_cookie_shake&cat_id=8 [07:13] ends with a keanu reeves whoa. I thought it was funny. [07:42] brayden: :P [07:42] * brayden completely ignores the "READ ALL OF THIS, IT'S IMPORTANT" [07:42] lol [07:42] oh by the way [07:43] if you use this monkeypatch from multiple threads in a Python VM without a GIL [07:43] you're probably very, very fucked [07:43] :) [07:43] Pfft threads! [07:44] Never really used them. Was told async was better in basically every way and never bothered! [07:44] brayden: pretty much [07:44] well, to be fair [07:44] there are reasons to use threads [07:44] async isn't *always* the solution :P [07:44] 3er [07:45] er * [07:45] event-based isn't always the solution * [07:45] Well from having to use it sparingly in the past, it certainly is a bit easier in that you don't have to get packages specifically made to be async, or use asyncore to hack it up. [07:46] ugh, asyncore [07:46] I'd love to learn how it works, if there were some readable docs on it [07:46] anyway [07:47] the problem with event-based (not specific to Python) is that you're probably going to be limited to one CPU core [07:47] Depends on what you're doing whether you need a lot of power I suppose! [07:48] I'm just doing single core stuff with Tornado and doing quite a bit of templating and such and pages generate in ~10ms no problems, no bottlenecking. [07:48] Only problem I guess is for games and scientific applications [07:55] brayden: if you have a multicore server and you want to serve up a lot of stuff, then you're probably going to want to use all your cores [07:55] :) [07:55] or any kind of precaching [07:56] It isn't designed with the intention of handling a lot of traffic. Most of the speed issues just come from things that block. [07:56] Like the password hashing. [07:56] had to knock the rounds down from the default of 80,000 to 20,000 for sha1 as it was just too slow otherwise. [07:57] brayden; aside from "you should really not be using sha1" [07:58] this is why I said event-based isn't always the solution :P [07:58] it may be for a lot of things, but not always [07:58] Bcrypt was too slow! [07:59] and if you knew what it used when it was just a proof of concept.. [07:59] SHA512 lol [07:59] no additional rounds or anything. just basically: hashlib.sha512(password).hexdigest() [08:02] so i may have some good news [08:04] i can get the digital planet audio files as flash video [08:05] that's a good thing? [08:05] its very weird [08:05] its a good thing cause there is no mp3 lift [08:05] you can just past the older links from old rss and grab it [08:06] this better then it just being gone [08:16] for what it's worth, archivebot uses both event loops and threads [08:17] the main distinction is whether a process is easier to model as an event loop or with blocking primitives [08:18] so e.g. there's several pubsub receivers and each run in their own event loop [08:18] doing it that way made each module a lot smaller [08:22] that said, there's no reason why that couldn't be done with a single event loop, so [08:22] horses for courses etc [08:26] "Secret NASA documents, how the Illuminati actually plan to kill us!!!!!!" [08:26] * joepie93 sighs [08:26] I'm kind of starting to hate moderation [08:44] o_O [12:01] so i saved what i could of 2009 and 2010 digital planet podcasts at the moment [17:45] Carl Malamud, the man behind many great projects that bring disparate government data into a single, collected, and organized site, has a Kickstarter: http://www.kickstarter.com/projects/publicresource/public-safety-codes-of-the-world-stand-up-for-safe I would recommend you back it