Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Hey Xarn, apply this patch!

Name: Anonymous 2010-07-27 6:37

--- progscrape.py    2010-07-26 13:42:46.000000000 +0200
+++ /tmp/progscrape.py    2010-07-27 11:00:18.991885078 +0200
@@ -299,8 +299,14 @@
 
 
         if verify_trips and len(tripv) > 0:
+            # We get 403 with long URLs
+            # if too many trips to check, fetch the whole thread
+            tripv_url = read_url + thread[0] + '/'
+            if len(tripv) < 200:
+                tripv_url += ','.join(tripv)
             try:
-                hp = urlopen(read_url + thread[0] + '/' + ','.join(tripv))
+                hp = urlopen(tripv_url)
 
             except:
                 print "Couldn't access HTML interface to verify tripcodes.",\


This will solve the 403 errors.

Name: Anonymous 2010-08-03 16:54

It's slower because they both use OpenSSL's DES_crypt, but Xarn doesn't wrap his in superfluous crap, doesn't unnecessarily generate a completely random string (with associated function calls; the attempt at inlining doesn't actually inline those functions) for every iteration, and doesn't use regexes by default.
there are very good reasons for generating a random string. this has been discussed extensively on other boards. the fact that your compiler is shit doesn't mean that every compiler is.

It's not as easy to distribute over a cluster because processes are just easier to distribute than threads. That's a fact of life.
you obviously didn't look at it:
Usage: %s [-c] [-p processes] [-t threads] [regex]

It doesn't compile because it inexplicably doesn't use POSIX regexes.
pcre is faster and more useful than any free implementation of posix regexes.

As far as NIH syndrome goes, random number generation is one thing C has a plenty of options for, but he still chose to implement a silly knock-off.
name one that's as fast as that and has a period at least as long.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List