Cryto! 8 February 2014

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