for root, dirs, files in os.walk(os.path.abspath('')):
for f in files:
e = os.path.splitext(f)[1]
if (e and e not in [".py",".db"]):
h = md5.new(file(f,'rb').read()).hexdigest()
n = h + e
try:
os.rename(f,n)
except WindowsError:
os.unlink(n)
os.rename(f,n)
print n + " " + f
How do I optimize this, I'm watching SICP right now
Name:
Anonymous2009-01-20 23:36
MD5 IS DEPRECATEED USE HASHLIB INSTEAD BITCH but srsly python is just slow in general and you can't really optimize further
If you're working with files of any significant size, reading them in chunks will speed things up, save memory, and increase your number of lines of code, thus providing job security.
shit = hashlib.md5()
bitch = file(whatever, 'rb')
fuck = 'nigger'
while fuck:
fuck = bitch.read(4096) # whatever. look up the size of your disk blocks, make it a multiple of that
shit.update(fuck)
dick = shit.hexdigest()
But really, the speed of this code is pretty much entirely dependent on the implementation of your hashing algorithm and the speed of your disk, and since an md5 isn't thoroughly processor intensive, the speed of even a modest implementation will surpass typical disk read speeds. You can tell where the major bottleneck lies by comparing the processor load and disk activity graphs in a performance monitoring tool; I'd be almost certain that, for your code, you will be spending more time waiting for I/O than actually computing anything, and only a tiny fraction of that is in the Python interpreter.
... oh, fuck, I just accidentally started writing a serious answer. Sorry.
REWRITE YOUR CODE IN LISP
Name:
Anonymous2009-01-21 10:18
>>6
because the operating system won't implement any form of read caching
>>17
However there is a minor problem with fnop, it takes two bytes as opposed to one ( 0xD9 0xD0 for fnop, and 0x90 for nop), so if you had random piece of code/function which you wanted to nop, you couldn't just memset it to a nop buffer. Yes, that can be solved by just filling it with D9D0 for len/2 and if len%2==1 then fill that byte with a nop. This creates another problem: filler nop buffers you want to jump to: if you jump randomly in the buffer and land on a D0D9 instead of a D9D0, it'll execute a rcr cl,1 ( until the buffer ends ). A similar problem/situation is encountered with int3(CC) alignment buffers for debug builds of apps. You usually have to use int3 since the length is 1, however, a less common choice is to use "int 0CD" (which assembles to 0xCD 0xCD , meaning if you jumped into the buffer, you'll still execute the interrupt which will trigger the exception handler)
>>19
You have clearly no idea what you're talking about. Not that there is much of a topic to talk about, nop has its purposes, and if you just want to skip a large chunk of code you'd just assemble an unconditional long jump.
Yes you can treat it as a nop when using "LEA REG,DWORD PTR:[REG]" and all it will do is reg:=reg which is effectively a no-op.
LEA is similar to a mov instruction, which tends to be used to manipulate offsets oftenly(for example to take the address of an element in an array), thus its name. It is not an instruction for changing the instruction pointer(IP/EIP).
>>31
THE INSTRUCTION LEA DOES NOT CHANGE EIP BY ITSELF( EIP is incremented by instruction size, but so is true for most instructions which don't operate on eip (jumps,return,calls))
In the code you posted, there are 2 instances of using LEA:
lea (EIP+4)(%esp),%eax # don't forget about the return address.
lea 52(%esp),%edx
In the second case it's just assigns edx with an address on the stack, so I'll assume that's not what you're talking about.
In the first case EIP+4 is actually a macro for a variable on the stack
EIP = 0x30
so it's nothing more than lea eax, dword ptr [esp+34h] no changing EIP there. The lea instruction cannot change EIP directly. What that example does is modify the context. The instruction which actually changes eip in that code is iret
Do you realize that iret is an instruction which only works in ring 0 (kernel mode). Anyway, please read your x86 assembly books before talking about this.
Now to get that damn greasemonkey script which fixes /prog/ working on my copy of Opera.