I've also got one one at livejournal.com (look for djberg96). I haven't decided which one I like best.
So long, and thanks for all the fish.
True or false?
I say "true", but I seem to be in the minority. Most folks seem not to be able to conceptually separate the *name* from the physical node on the disk.
The problem I have with our politicians, especially the Republicans, is they're always claiming there's not enough proof, or that we're in a natural warming cycle. BULLSHIT. In addition to numerous studies, there are the things we can SEE WITH OUR OWN EYES, as in the article above.
The problem with this "let's wait until there's more proof" mentality is this - by the time there's absolute proof, it will be too late. It means we're already fucked.
HOW ABOUT SOME FUCKING PREVENTATIVE MEASURES YOU ASSHOLES? STOP CATERING TO COAL AND BIG OIL.
Let's also keep in the mind, my non-US friends, that while we're the worst offenders overall, we're not the only offenders. Russia is not far behind and China is working its way up.
Just sign the frickin Kyoto Protocol and deal with it.
This is a pain now for extension writers on Win32, and will become crucial later, when 64 bit Windows becomes more popular. We *could* all just write a simple WIN32::API script within our Makefiles to get the major and minor version of Windows and set the value accordingly. The *better* option would be to have MakeMaker automatically set this value for me so I don't have to.
I haven't checked for certain, but I don't *think* Perl's ExtUtils::MakeMaker does this (nor does Ruby's mkmf). Time to submit a patch.
Hmm...Matz wasn't there, though. Travel may have been problematic.
$SIG{INT} = sub{ die "Caught signal\n" };
print "PID: $$\n";
while(1){
print "Looping\n";
sleep(5);
}
If you run this in a terminal, and hit Ctrl-C, the sig handler will (eventually) pick it up and terminate. But, if you were to run that and then, in a separate program, try to do "kill(2,$pid) or die $!" it won't work. It's going to return "invalid parameter". What's going on?
The problem is in the way the GenerateConsoleCtrlEvent() works. In short, you can't kill a remote console process like that. So, I've been researching the hell out of this trying to figure out how it can be done. I'm pretty sure it CAN be done, but it's been rough going so far.
My research leads me to believe that this can be accomplished with something along the lines of this abbreviated code:
GetModuleHandle("Kernel32.dll")
OpenProcess(pid)
VirtualAllocEx()
WriteProces sMemory()
CreateRemoteThread()
WaitForSingleObject()
But, so far all I've been able to do is kill the process, while causing an Application Error in perl.exe itself. So, I'm doing something wrong but I don't know what. I've posted my problem on one of the windows newsgroups. We'll see what happens.
PS - I have no idea why there's a space showing up in "WriteProcessMemory" above. It's not that way in my text.
update: I have been told that the latter approach still won't work. It *might* be possible with AttachConsole(), but that would XP or later only. We shall see.
Update: It looks like John McCain is getting involved. Man, if only McCain would have won the 2000 primary. Him and Feingold are my two favorite senators.
This one has some nice ideas. I especially like the idea of optional static typing, a good way to get (potential) compiler optimization and shut up both sides of the "static vs dynamic" war forever. There are some ideas borrowed from Ruby, Lisp and Smalltalk it looks like. I also like the fact that he uses a leading underscore (as opposed to Ruby's '@') for instance attributes. It's the little things that count.
Some things I'm not sure what to make of yet, such as an actual "duck" type, or syntactic macros.
The biggest problem I have with it is the syntax (including SSW). It's the bastard child of Python and C#, and looks downright ugly in some places, especially the syntactic attributes. Then there's the whole CLI tie-in...