00:02:25 04FichteFoll made 2 commit(s) to 03package_control_channel on branch 10master: '02Add FindDoc, remove old Search in Browser', '02Merge pull request #2765 from zckrs/masterAdd FindDoc plugin and delete old 'Search in Browser' plugin' (https://github.com/wbond/package_control_channel/compare/d770202d85...12cc2e3ff1) 00:20:23 *** mama (me@1C9CAA1E.E1E4ACB3.150578F1.IP) has joined #crytocc 00:32:49 04FichteFoll made 2 commit(s) to 03package_control_channel on branch 10master: '02Update r.json', '02Merge pull request #2779 from FedeAmdan/masterUpdate r.json' (https://github.com/wbond/package_control_channel/compare/12cc2e3ff1...3b1b1438e3) 00:35:21 04FichteFoll made 2 commit(s) to 03package_control_channel on branch 10master: '02Activate Pane Resizer for ST3.', '02Merge pull request #2780 from markalfred/masterActivate Pane Resizer for ST3.' (https://github.com/wbond/package_control_channel/compare/3b1b1438e3...49a18c379c) 01:49:38 huh, when you get over into the funky corners of things like email marketing corps, websites stop sucking 01:49:55 fancy that 04:11:29 *** gesichtskirmes (kirmes@gesichtskirmes.users.cryto) has joined #crytocc 04:11:37 morning 04:14:45 *** pzuraq (pzuraq@cryto-BAE76FBA.hsd1.ca.comcast.net) has joined #crytocc 04:35:48 *** mama has quit (Ping timeout) 04:48:51 mawnin! 05:08:43 sup dorotea :> 05:16:04 not much 05:16:17 just found out it's basically impossible to use a facebook like button if you have csp defined 05:16:40 their scripts use eval, which is almost impossible to unblock when it comes from an outside domain 05:17:03 or, well, almost impossible to allow 05:17:10 it blocks any and all kind of eval very very well 05:17:10 lol 05:17:15 that sucks 05:17:41 I think it's hilarious, but it kills my idea of having a whole page of fb like buttons for news sources 05:18:13 then again, I suppose I shouldn't be surprised that the like button code is shit 05:18:28 twitter's even tests for csp and warns you if you've misconfigured it 05:18:31 it's great 05:18:47 twitter is awesome 05:18:53 I know :D 05:19:06 their embeds are permanant 05:19:17 the script just does progressive enhancement on them 05:19:37 so if the author deletes the tweet or takes their account private, it's still on your page just fine 05:19:43 with all the metadata and permalinks 05:20:14 there is a beta version of css for broken tweets, too 05:20:29 so you can throw it into your css file, so that if someone deletes it doesn't look TOO horrible 05:20:59 same for timelines (before they load, in case you have a shitty connection) 05:21:59 I'm rather impressed 05:22:13 (css is of course already in my stylesheet heh) 05:22:26 (plus modifications because theirs uses px and fuck that 05:24:02 you sound really happy about that 05:24:29 yes 05:24:46 twitter is my wife, of course I'm happy when her product team doesn't screw the pooch 05:25:01 sorry, platform team 05:25:02 wrong p 05:45:15 hahahaha 05:45:37 I love that this was a thing https://github.com/twbs/bootstrap/issues/3057 06:05:03 *** T0R_till (T0R_till@cryto-E6127135.us-west-1.compute.amazonaws.com) has joined #crytocc 06:06:25 *** T0R_till has quit (User quit: Connection closed) 06:10:06 Lol @ douglascrockford: That is insanely stupid code. I am not going to dumb down JSMin for this case. 06:17:01 After reading a bit of that thread, I think it's sad that this was a thing ;( 06:29:38 *** Wasp (Wasp@D8804853.1C1FC404.B1FAC4AB.IP) has joined #crytocc 06:30:17 *** Wasp has quit (User quit: Page closed) 07:12:27 *** gesichtskirmes has quit (User quit: Leaving) 07:27:34 *** Moh1 (Happax@7BF9CD5A.50E2978F.459DB6C6.IP) has joined #crytocc 07:28:34 *** Moh has quit (Ping timeout) 09:57:12 morning 09:57:16 hai dorotea and MK_FG 09:59:55 dorotea: jesus, what 10:00:42 *** stanone (Grep@stanone.users.cryto) has joined #crytocc 10:02:57 *** LapAnon has quit (Ping timeout) 10:13:58 *** GHOSTnew (GHOSTnew@GHOSTnew.users.cryto) has joined #crytocc 10:57:05 when I was digging for CDs yesterday, I found my Kanen MD-52s 10:57:09 and goddamn, I forgot how good they sound 10:57:09 :o 10:59:23 I'll just stick to my HD25 IIs 10:59:34 Granted, they are about 30 times more expensive or so 11:02:54 Xeross; have you ever listened to MD-52s? :P 11:03:16 (also, that's a headphone, not earbuds) 11:06:36 joepie91: (Details, hmph) and no I haven't, but considering I can't stand in-ear earbuds, yeah :P 11:10:19 lol 11:10:46 Xeross: guess that MD-52's wouldn't be an option if you don't like in-ears... 11:10:50 but seriously, they sound amazing :o 11:17:19 *nods* 11:18:02 joepie91: For that price even sounding decent is impressive 11:35:01 Xeross: yeah, don't ask me how they managed to sell earbuds this good for a price that low, and still make a profit 11:35:07 but apparently they managed 11:35:08 lol 11:36:11 joepie91: well considering the margin a lot of stuff has. Can't imagine that Sennheiser earbuds cost 30EUR to produce 11:36:18 "NAT can also prevent hacker attacks by mapping local addresses to public addresses for key services such as the Web or FTP." 11:36:53 Xeross: ofc, but I bought them for, what, 4 euro? 11:37:03 and they sound seriously impressive 11:37:06 not just decent 11:37:09 genuinely impressive 11:37:23 I find it hard to see where the profit margins for all the middle men fit in there... 11:37:49 "The Device provides extensive firewall protection by restricting connection parameters to limit the risk of hacker attack, and defending against a wide array of common attacks." 11:37:58 what's with all this pseudo-marketing-copy in my modem panel 11:38:55 Phrases I hate: enterprise-ready, award-winning, etc. 11:47:42 Xeross: ~cloud~ 11:48:27 joepie91: butt? 12:14:48 *** mama (me@cryto-CF95923E.torservers.net) has joined #crytocc 12:20:09 *** burn0ut (tor@cryto-81F8C060.digicube.fr) has joined #crytocc 13:32:42 lol 14:06:16 *** Moh1 has quit (User quit: Leaving.) 14:33:56 *** Moh (Happax@FC4291B6.E33CEB64.57D2FD60.IP) has joined #crytocc 14:43:39 04musalbas made 2 commit(s) to 03musicalpackets on branch 10master: '02prototype', '02Merge branch 'master' of https://github.com/musalbas/musicalpackets' (https://github.com/musalbas/musicalpackets/compare/dbd9549aa4...864bd2e65f) 14:56:28 04FichteFoll made 2 commit(s) to 03package_control_channel on branch 10master: '02Adds “SQL (simple-db-migrate)” package', '02Merge pull request #2782 from caiogondim/masterAdds “SQL (Good Migrations)” package' (https://github.com/wbond/package_control_channel/compare/49a18c379c...36b0a2c635) 14:56:31 *** lblissett has quit (Ping timeout) 15:00:34 *** lblissett (lblissett@lblissett.users.cryto) has joined #crytocc 15:03:21 *** Moh1 (Happax@FC4291B6.E33CEB64.57D2FD60.IP) has joined #crytocc 15:05:14 if any python/regex wizards, around 15:05:23 https://github.com/joepie91/python-whois/issues/2 15:05:24 very weird bug 15:05:26 *** Moh has quit (Ping timeout) 15:05:57 not... entirely sure what's going on there 15:25:56 joepie91, Sounds like exactly the issue described in http://swtch.com/~rsc/regexp/regexp1.html under "Performance" header 15:26:09 "Examples include using (.*) (.*) (.*) (.*) (.*)" 15:32:22 joepie91, Tried re2 on the same thing out of curiosity - works instantly ;) 15:32:41 (while re from stdlib hangs here as well) 15:33:26 No matches though... not sure if I maybe copy-pasted the thing wrong 15:41:24 *** GHOSTnew has quit (Ping timeout) 15:42:03 MK_FG: it's not -supposed- to match 15:42:04 lol 15:42:13 \o/ 15:42:28 Then my copy-pasting skills are still top-notch! ;) 15:42:37 hehe 15:42:55 and um, MK_FG 15:43:04 any ideas on why this would succeed for all WHOIS stuff 15:43:07 except for wa.us 15:43:54 Hmm, maybe just longer input? 15:44:01 *** GHOSTnew (GHOSTnew@GHOSTnew.users.cryto) has joined #crytocc 15:44:04 Or some of the groups do match 15:44:44 *** Moh1 has quit (User quit: Leaving.) 15:46:13 (public service announcement: a brief netsplit will occur this weekend due to hub maintenance) 15:46:25 (it should pull back together in at most an hour) 15:46:34 MK_FG: some of the groups do definitely match 15:46:42 but it should fail at some point 15:46:48 and I just can't fathom why it would get stuck 15:47:01 MK_FG: in the bug ticket, I've included the offending regex, as well as the raw WHOIS data 15:47:11 also look at test/data/whois.us in the repo; that test data works fine 15:47:14 Yeah, I've used these to test 15:47:16 and doesn't get stuck 15:47:19 (re vs re2) 15:47:37 the only difference I can see is the facsimile number, and I can't see how that would fuck stuff up 15:47:42 The link above shows fairly sharp cutoff when regexp vm does more than 25 backtracks 15:47:49 especially since I'm -explicitly- defining newlines after the .+ (exactly for this reason) 15:48:00 But I'm not sure what that all means myself, need to re-read the thing, lazy 15:48:17 lol 15:48:42 That article is written by google-code-search and re2 lib author 15:48:44 (iirc) 15:49:03 So it'd make sense that re2 works ;) 15:49:15 (on that exact "pathological" case) 15:49:39 anyway, MK_FG, I'm fairly sure that I've read the article you linked before 15:49:49 and I can't think of any way how that would apply to my current situation 15:49:53 Also, I think follow-ups describe vm approach 15:51:15 I can't see why it wouldn't - "less pathological but bad" example he has there look like yours 15:51:25 Bunch of (.*) with separators 15:53:46 MK_FG: the thing is, there are no multiple-choice elements in my regex 15:54:11 \n is not included in . 15:54:17 since no dotall 15:54:37 MK_FG: I don't have such a pattern 15:54:39 that's the thing 15:55:13 my pattern is quite simple; static string, followed by spaces until there are no more, followed by anything that isn't a newline, followed by a newline 15:55:20 there's no... what to call it? 15:55:40 idk the word 15:55:44 I hope you get what I mean :P 15:55:46 Hm, yeah, guess greedy .+ should go to line-ends always 15:55:52 yes 15:56:07 that's why I can't understand how it gets stuck - this is pretty much a single track regex 15:56:09 everything is greedy 15:56:21 with early cut-off 15:56:24 (theoretically anyway) 16:03:36 Mysterious indeed 16:05:05 *** T0R_till (T0R_till@cryto-F4754358.us-west-1.compute.amazonaws.com) has joined #crytocc 16:05:08 Also, with re.DOTALL it works fast 16:06:26 *** T0R_till has quit (User quit: Connection closed) 16:09:57 *** GHOSTnew has quit (Input/output error) 16:17:31 MK_FG: re.DOTALL is going to cause mysterious problems 16:17:41 so that's not an option 16:17:42 :P 16:18:50 Yeah, it should totally break matching, just a bit weird that it makes things better, not worse 16:19:22 I'd think simple fix would be just split that huge regexp into smaller ones by \n and match each individually 16:19:44 04musalbas made 1 commit(s) to 03musicalpackets on branch 10master: '02prototype 2' (https://github.com/musalbas/musicalpackets/compare/864bd2e65f...6ae0f61cf3) 16:19:52 (or whatever other non-regexp processing, given the nature of data there) 16:22:38 joepie91:) fucking dicks man 16:25:38 Phrasing! 16:26:11 tone! 16:26:47 04musalbas made 1 commit(s) to 03musicalpackets on branch 10master: '02add soundfound' (https://github.com/musalbas/musicalpackets/compare/6ae0f61cf3...2ab86873a6) 16:29:11 * dorotea sings "everybody wing-chun tonight!" 16:33:10 MK_FG: that's not really a possibility, it'd either break the functionality or completely fuck up the code structure 16:33:14 this is just one of many regexes 16:33:22 and not all of them use nice field prefixes 16:33:34 dorotea: dicks indeed 16:33:47 Require something like re2 maybe? 16:33:57 *** FichteFoll (Fichte@cryto-9EE9A3E8.unitymediagroup.de) has joined #crytocc 16:34:13 joepie91:) it's like I've been playing irc tag with you for days 16:34:17 joepie91:) oh wait... :D 16:34:20 hi 16:34:25 FichteFoll:) MORNING! 16:35:00 FichteFoll:) I have awaited your arrival! Now that you are here, I am content. 16:37:15 lol 16:37:15 I'll try to find a corelation between number of spaces, number of \s matches and required time to fail with matching 16:37:17 hai FichteFoll 16:37:22 MK_FG, context: http://hastebin.com/quveqinere.py 16:37:31 FichteFoll has been looking at it a bit 16:37:35 and has found some very weird behaviour 16:37:42 and I found even more weird behaviour 16:37:50 removing a single line will make it work 16:37:59 compressing two lines into one will sometimes work and sometimes not 16:38:11 -which- line you remove has an effect on how much of a performance improvement happens 16:38:34 MK_FG: now, the strangest thing is that it is also fixed when you remove the line that -doesn't- have a .+... 16:38:54 and 16:38:54 joepie91:) it's like I've been playing irc tag with you for days 16:38:57 pretty much :P 16:39:21 Gosh 16:41:30 I think "fragile" is what sort of regex that is 16:42:03 I have strong suspicion that understanding the bug here might require explaining long sequence of states and optimizations gone wrong ;) 16:43:11 dorotea: it's WHOIS parsing, of course it's going to be messy and fragile :P 16:43:42 ahhhh 16:44:18 *** monod (~pmpf@monod.users.cryto) has joined #crytocc 16:44:28 herro! 16:44:31 i guess there is some kind of exponential performance drop depending on how many matches you specified and how long these matches are 16:44:38 might or might not be specific to \s 16:44:40 MK_FG: ooookaaaay.... 16:44:47 MK_FG: so, go ahead :P 16:45:06 No no, I mean "for me to understand, once someone finds the bug" 16:45:21 ahh 16:45:28 not \s specific, also appears if I use " *" in the regex 16:45:35 FichteFoll: the thing is... this doesn't happen for other long regexes and other whois data 16:45:54 what boggles me in particular is -why- the facsimile number screws up that particular regex 16:45:57 rather than just aborting 16:46:10 I just can't find even a complex explanation as to how that could possibly happen 16:46:30 hai monod 16:46:49 here is what I am currently working with: http://hastebin.com/puhuwelago.py 16:46:53 time for me is 2.2s 16:48:55 time to test on py3.3 16:49:45 same problem there 16:50:25 I guess it's time to search the python bugtracker for similar issues and report it if none exists 16:52:37 *** pzuraq has quit (User quit: Leaving...) 16:55:30 *** lblissett has quit (Input/output error) 16:57:46 FichteFoll; yeah.. :/ 16:58:00 FichteFoll: could you do a quick write-up of your findings that I can copy-paste into a ticket? 16:58:14 doesn't have to be all well-written or whatever, I can fix that when making a ticket 16:58:15 currently searching for similar issues 16:58:19 just an overview of the findings themselves 16:58:22 alright :P 16:58:42 I found that there is a regex module on pypi what is supposed to replace the re module at some point 17:02:17 I should point out that switching to a diff regex module is not an option here 17:02:21 ... that is in the works for like 3 years already though 17:02:35 pythonwhois is dependency-less and I'd like to keep it that way 17:02:36 :) 17:02:52 sure, I was not recommending to add a dependency 17:28:56 joepie91: the same thing applies to the regex module btw 17:29:21 it could be that the regular expression and match string itself is just very suboptimal 17:29:33 but I don't really understand why 17:31:48 *** gesichtskirmes (kirmes@gesichtskirmes.users.cryto) has joined #crytocc 17:38:50 joepie91: the same thing applies to the regex module btw 17:38:52 ? 17:39:00 it also has poor performance 17:39:12 https://pypi.python.org/pypi/regex 17:41:36 ah 17:49:49 joepie91: I just now realized that the problem is likely because of "\s*.+" 17:50:25 FichteFoll: ? 17:50:26 you should test the first example which was reported on github with a "\s*(\S.*)\n" regex 17:50:53 that isn't the same regex 17:50:54 and doesn't do what I want 17:50:55 :P 17:51:02 this is because the re engine will test every possible lenght of the \s* match because the following is .+ 17:51:10 I know it's not the same, but it serves the same purpose 17:51:19 no, it doesn't 17:51:30 \S is non-whitespace 17:51:34 it will break on any value that contains whitespace 17:51:42 no, it wouldnt 17:51:59 because I only require one non-whitespace char in the match - the first 17:52:10 also, why does this break on wa.us but not on whois.us? 17:52:15 or anything else? 17:52:32 OH 17:52:35 since you were matching .+ (>+<) anyway you are expecting at least one character anyway 17:52:37 I was reading \S* 17:52:37 lol 17:52:52 it doesn't break on the other results because the match actually matches there 17:53:05 but uh 17:53:14 this is because the re engine will test every possible lenght of the \s* match because the following is .+ 17:53:16 it shouldn't do that 17:53:21 because \s* is greedy 17:53:25 it doesn't break on the other results because the match actually matches there 17:53:26 no 17:53:29 and it does so with the first try too becausethe re engine would try to match with the most characters with \s+ 17:53:33 there are lots of regexes like this in the pythonwhois code 17:53:36 even longer ones 17:53:37 with \s* I mean 17:53:44 including with \s* 17:53:51 most regexes will always fail 17:53:54 for any raw data 17:53:57 that's how the parser works 17:54:14 if the whole regex then doesn't match, it will try to match \s* with one less character 17:54:27 but since you specified a .+ match afterwards, this will work 17:54:36 and it has to test the whole string again 17:54:40 so.. why doesn't this happen for any of the other regexes that A. do not match and B. contain \s*? 17:54:50 because it's a partial match or something? 17:55:14 now, there is not only one \s but multiple and it creates a kind of exponential iteration 17:55:35 even though you already know that the expression won't match, the engine itself doesn't 17:55:55 joepie91: it's because of the \s*.+ combination 17:56:31 oh god, why didn't I realize this earlier 17:58:35 here is the example with the fixed expression: http://hastebin.com/lolevojice.py 17:59:53 you can add "(?:Registrant Facsimile Number:.*)?" after the phone number to make it match 18:01:21 and this is my current write-up that I'm not going to finish now: http://hastebin.com/gurupafaso.txt 18:06:09 joepie91: it's because of the \s*.+ combination 18:06:10 as I said 18:06:19 as far as I am aware there are multiple regexes like that 18:06:28 not to mention that a LOT of whois data isn't going to match this particular problematic regex 18:06:34 so why isn't it -always- happening? 18:06:56 FichteFoll, Maybe use "drops execution time" instead of "drops speed"? 18:07:29 could you please file me an example of when some whois data is not matching but the expression completes quickly? 18:07:40 because otherwise I won't believe it 18:07:59 MK_FG: yeah, that is probably a better term 18:08:36 I'll post some logs on the github issue where this arose because I'm to lazy to write yet another write-up, any objections? 18:08:42 FichteFoll: sure, just a sec 18:09:22 FichteFoll: test/data/2x4.ru 18:09:39 FichteFoll: go ahead, this channel is publicly logged :P 18:09:59 i suppose i should feed the tool with that? 18:11:52 FichteFoll: ./pwhois -f test/data/2x4.ru . 18:13:09 FichteFoll: the .ru regexes are at the very end 18:13:15 so it will fall through all the other regexes before getting thre 18:13:16 there * 18:13:19 including the problematic .co 18:13:54 could you point me to the code where the regular expression is defined? 18:15:59 hm, please consider using """ strings or "a" <\n> "b" for readability 18:16:21 also you should definitely prefix all your expressions with r"" 18:17:16 FichteFoll: for the record, I'm having horrible internet again... so there might be a multi-minute delay in me responding 18:17:17 :P 18:17:32 FichteFoll: but yeah, I presume you found the regexes? 18:17:54 FYI, you can catch multiple exceptions in one except blog (re lines 344-363) 18:18:20 well, I found *some* regexps but I have no idea when they are run 18:18:48 however, I assume that the following happends: 18:19:11 You test a lot of regular expressions, but everyone of them (except for the one matching) will fail very early 18:19:33 and by very early I mean probably on the first line because the key is not found in the response 18:20:01 this means that the engine will never process any \s*.+ matches because it already failed beforehand 18:20:21 oh, and did I mention tab indents are evil? 18:20:47 especially if you plan on aligning code on multiple lines and using mixed indents (!) 18:20:54 FichteFoll: not going to have an argument about tab indents right now 18:21:19 this means that the engine will never process any \s*.+ matches because it already failed beforehand 18:21:26 so, basically what I suggested re: partial matches 18:21:42 what did you suggest? 18:21:56 FYI, you can catch multiple exceptions in one except blog (re lines 344-363) 18:22:03 there was a version requirement issue with that 18:22:06 ? 18:24:26 can't find any information on when this was added 18:24:32 but it should have been before 2.5 18:24:45 definitely not 18:24:56 fairly sure it was 2.6 18:24:57 from memory 18:26:54 there are so many places where this is referenced but nothing mentions when it was added 18:27:20 not even the python docs, even though they usually do 18:27:33 so I assume it was added way before 2.6 18:30:31 *** burn0ut has quit (Ping timeout) 18:33:47 04FichteFoll made 2 commit(s) to 03package_control_channel on branch 10master: '02find non ascii st3 compatibility', '02Merge pull request #2783 from madeingnecca/masterfind non ascii st3 compatibility' (https://github.com/wbond/package_control_channel/compare/36b0a2c635...80434605c5) 18:33:55 wat is this 18:34:10 you still watch me with your bot? 18:36:10 haha 18:36:17 well you're still in the watchlist 18:36:18 :p 18:36:49 must be pretty spammy, I merge several PRs a day 18:36:49 04FichteFoll made 3 commit(s) to 03package_control_channel on branch 10master: '02Added sublimall', '02Added sublime_text selector', '02Merge pull request #2784 from socketubs/masterAdded sublimall in g.json' (https://github.com/wbond/package_control_channel/compare/80434605c5...22f98a6c33) 18:37:43 *** burn0ut (tor@cryto-96ABCC15.torproxy-readme-arachnide-fr-35.fr) has joined #crytocc 18:42:43 FichteFoll: it's not terrible 18:43:11 at least you don't get highlighted ;o 18:43:30 I could ignore botpie91 if it mentioned me but whatever 18:44:02 time for some excel magic 18:45:05 * joepie91 does get highlighted when it's his commits being announced 18:45:07 :P 18:45:40 anyway, FichteFoll, want me to rm it from the watchlist? 18:45:51 idc 18:46:09 I don't think I'll visit this channel in the future anyway 18:46:15 I don't even know what it's about 18:48:19 :( 18:49:43 *** monod has quit (User quit: movie time!) 19:31:29 *** FichteFoll has quit (User quit: 0x90) 19:33:25 04musalbas made 1 commit(s) to 03musicalpackets on branch 10master: '02refactor' (https://github.com/musalbas/musicalpackets/compare/2ab86873a6...2db00811aa) 19:53:01 04musalbas made 1 commit(s) to 03musicalpackets on branch 10master: '02integration with mongodb' (https://github.com/musalbas/musicalpackets/compare/bb1eb409c4...a836a8be66) 20:15:25 *** gesichtskirmes has quit (User quit: Leaving) 20:17:32 * joepie91 twitches a little at 'mongodb' 20:18:05 YoloDB you mean? 20:18:28 more like YORO 20:18:32 you only read once 20:18:34 after that it's GONE 20:31:18 https://twitter.com/search?q=%23yoloDB&src=hash 20:31:52 http://www.youtube.com/watch?v=GaSjwAu3yrI dafuq xD 20:35:56 *** iceTwy (iceTwy@iceTwy.users.cryto) has joined #crytocc 21:35:23 godfuckingdamnit 21:35:30 another of those fucking infinite regexes 21:35:38 * joepie91 kills something in close range 21:42:08 04FichteFoll made 2 commit(s) to 03package_control_channel on branch 10master: '02remove raw subdomain from url', '02Merge pull request #2785 from unknownuser88/masterremove raw subdomain from url' (https://github.com/wbond/package_control_channel/compare/22f98a6c33...95516da861) 21:42:38 04FichteFoll made 2 commit(s) to 03package_control_channel on branch 10master: '02Update r.jsonCorrecting link', '02Merge pull request #2786 from FedeAmdan/masterUpdate r.json' (https://github.com/wbond/package_control_channel/compare/95516da861...3a26c89aa4) 22:09:59 04FichteFoll made 3 commit(s) to 03package_control_channel on branch 10master: '02Add SublimeAVR', '02SublimeAVR, define sublime_text version', '02Merge pull request #2787 from kblomqvist/SublimeAVRAdd SublimeAVR' (https://github.com/wbond/package_control_channel/compare/3a26c89aa4...cb3edcf8cb) 22:14:57 jesus what the fuck is it with pythonwhois today 22:14:59 bug after bug after bug 22:40:03 WHOOO 22:40:19 04joepie91 made 3 commit(s) to 03python-whois on branch 10develop: '02Docs fix', '02Fix regular expression corner case that led to long parsing times', '02Support for separated first and last name, NetworkSolutions support, SIDN support, iedr.ie support, .am support, GAL Communication support, Fabulous.com support, added optional 'Facsimile Number' and 'Organization' fields for .US (Neustar) domains, fixed false positive (interpreting 22:40:57 lol monster commit 22:44:33 *** complex (litehode@complex.users.cryto) has joined #crytocc 22:44:35 hey guys 22:44:50 GUESS who got a date with the coolest girl ever? 22:47:20 complex: I'm guessing that it isn't Will Smith 22:47:27 :P 22:47:46 will what 22:48:02 im sorry, im not that cultural 22:48:15 i know will smith, but i probably didnt get your joke 22:48:44 ah, and fuck will smith, he probably got a nice looking girl, but i got a fucking cool girl 22:48:50 this girl is just badass 22:52:35 *** SNiFER (Heelium@A77B1385.E31F60B1.E7F16F08.IP) has joined #crytocc 22:52:48 *** SNiFER has quit (User quit: ) 22:54:34 *** lblissett (lblissett@lblissett.users.cryto) has joined #crytocc 22:59:56 04joepie91 made 1 commit(s) to 03python-whois on branch 10develop: '02Bump' (https://github.com/joepie91/python-whois/compare/f2ce1d7b8a...6cd09c219a) 23:00:06 04joepie91 made 6 commit(s) to 03python-whois on branch 10master: '02Update instructions', '02Docs fix', '02Fix regular expression corner case that led to long parsing times', '02Support for separated first and last name, NetworkSolutions support, SIDN support, iedr.ie support, .am support, GAL Communication support, Fabulous.com support, added optional 'Facsimile Number' and 'Organization' fields for .US (Neustar) domains, fixed fal 23:01:53 *** burn0ut has quit (User quit: leaving) 23:43:00 sadface when most of the visits on your site (250k!) 23:43:08 come from a DDoS attack from Belarus 23:43:23 271,417 views / 103,620 threats 23:43:44 167,769 regular traffic (probably unfiltered spam/DDoS) 23:43:50 8unique threats 23:56:07 *** Thor (numz@cryto-BBDC76E6.tor.uwaterloo.ca) has joined #crytocc