Thanks for mentioning us. Just noticing: we are a "hibryd" startup: we have a focus on Desktop market, but we have to pay attention on the "Web side of the force" too. :-)
"First, git's Windows support is the weakest out of the three DVCSs being considered which is unacceptable as Python needs to support development on any platform it runs on."
This is FUD! The support for git on windows is pretty good and there is nothing obstrusive in it. You can use git on Windows fairly well. Sad to see this kind of comment written by smart people.
Git's Windows support is clearly the weakest since it requires either MinGW or Cygwin. The platform itself is unoptimized for native Windows performance. It may not be terrible but it's certainly the weakest of the DVCSs, as they say.
Last time I tried TortoiseGit, adding a file either didn't work or just crashed hard. Mercurial, on the other hand, just got TortoiseHg 2.0, which is a pleasure to work with.
It is true that git works on Windows, but that doesn't mean it works well.
I've been working on a prject last year which involved a few developers using Windows.
It was a nightmare. Myself using Linux, i had no problem.
But git on Windows..
It'd definitely behind other VCS.
Pretty interesting. I also tell my students to imagine a commit like a checkpoint in a videogame.
I try to teach real VCS, starting with simple patches, tarballs and merges and going through git, like it is an "patch/merge automation process". I realize they really like it and I try to improve some techniques to teach real VCS to students.
Glad to hear from people who's passing through same situation as mine :-)
It can, in fact, search pretty much anywhere in vim (from the docs):
- buffers
- files
- directories
- most recently used files
- files around most recently used files
- most recently used command-lines
- bookmarked files
- bookmarked directories
- tags
- files which are included in current tagfiles
- jump list
- change list
- buffer lines
- quickfix
- help
You're going to need to explain further how C is endowed with all the capabilities normally associated with OS-building frameworks (which I've never heard of).
So... do they figured it out how to fix the PHP's white screen of death? This kind of thing is so annoying that I can't even think of using PHP in my future projects.
I'd assume you'd mean segfaults. It's somewhat painful to track down a segfault in PHP, but if you can compile PHP with debug symbols and then invoke a failing scripts under gdb, it's fairly straightforward.
Syntax errors, calls to @nonexistant_name(), and many others will simply return an empty page and log the error to the error log (error is not catchable, so you cannot even return anything sane to the user)
The fun starts when you hit one of the situations where the whole php stacktrace is `in file "" at 0` (or something similar). I've got 4 php programmers around me and I hear about the "white page" almost once a week, so it's not that uncommon :(
That's not a problem with PHP, you just have your environment setup to return nothing on fatal error.
Shutdown functions still run after a fatal error (something I just learned), so you can display the error or redirect to another page:
function shutdown() {
if (($error = error_get_last())) {
ob_clean();
// report the event, send email etc.
// Redirect
header("Location: http://hostname/error");
}
register_shutdown_function('shutdown');
As for the empty stracktrace, I used to encounter those frequently but I don't anymore. Either Zend has been fixing them up, or I'm doing less work inside of various handlers.
There are several ways of catching uncaught errors and returning reasonable output to the client. First look into set_error_handler and set_exception_handler. Also you can register a shutdown function or set an output buffer callback that looks at error_get_last().
Well, you could turn display_errors to 'on' in the php.ini file, but this is generally regarded as a security issue, as the error message will reveal sensitive info.
There are some situations which cause PHP to just die and not log anything, but those are pretty rare.
It's pretty common practice to have display_errors to on for development, and off for production. Are you not doing that already? Or is everyone developing on production systems?
Bluesnowmonkey already gave you some specific solutions but I wanted to point out that error suppression is generally a really bad idea. If your code encounters an error you should want to know about it.
This is one of the reasons I really like working in Rails. An exception blows the page up properly, and kicks into my exception notifier (sends me an email with the environment and stacktrace) and can display an error to the user. PHP's "soft on errors" approach is just a timebomb waiting to go off. "Fail hard, fail fast" is less forgiving, but ultimately, helps me sleep a lot better at night.
I know that it blows up on fatal errors, and I know that you can have it report or not report errors (error_reporting), but how would I, say, make it terminate with a backtrace if I attempt to fopen a file that I don't have permissions to open? The proper behavior in PHP is to check your file descriptors, but I'd much rather it just give up and go home, since behavior after a failure like that is going to be unpredictable in many cases.
I assume you are talking about fopen-type of functions that are nothing more but wrappers around C standard library functionality.
Use SplFileObject (part of SPL that is part of PHP core) for object-oriented way to manipulate files. On a failure (like your permission issue) it throws Exceptions and if not handled this will result in a "hard" error with a backtrace log.
Awesome, thank you. I'm a bit rusty on best practices since I've shifted my focus away from php, but it's nice to know that options to make it behave a bit more high level exist.
