export PS1="\n\e[38;5;64m\w\033[0m\nλ " export CLICOLOR=1 export LSCOLORS=gxfxcxdxbxegedabagacad alias ll='ls -lGh $@'Looks like this:
The PainAs a Windows developer coming to the Mac, one of the biggest points of friction I had is how the Mac uses a very different modifier key layout. It's like someone decided to flip the keys around just to be mean. My muscle memory wants to use my pinkie finger to hit Ctrl+C to copy, but it never works.
Until recently, the first thing I'd do on a Mac was open System Preferences and remap the modifier keys to be like Windows:
If you don't care much about Terminal, this is fine. But I need Terminal. A lot. And this setup has issues.
The problem is that Terminal is strangely inconsistent on a Mac; you're stepping out of Apple's world where the modifier keys have all been moved around and back into Unix land where the modifier keys are laid out as you'd expect. Normally I wouldn't complain, but I already did a system-wide remap of my modifier keys and, while everything outside of Terminal is now fine, whenever I drop into Terminal I'm suddenly struggling because Control isn't Control. It's Command. Which means when I hit Ctrl+C it doesn't work. And then I remember everything is wrong, and I struggle, and I finally hit Option-C.
Way too much friction.
Now, I've got a copy of Keyboard Maestro, but it doesn't have a good solution for this "Hey there! I'd really like to just use the Control key for shortcuts for everything, Terminal included" problem. You could map a hotkey for each letter on the keyboard, but that's crazy.
Well, I'm happy to say I found a great solution. And, ah, finally, I can use the Control key everywhere, including Terminal. Enter KeyRemap4MacBook.
The SolutionKeyRemap4MacBook is basically a replacement of the System Preferences dialog for remapping the modifier keys with advanced options that developers care about.
All I did was go into System Preferences and reset the modifier keys to their defaults, then install KeyRemap4MacBook and enable these rules (there are many more options):
Give it a shot. And if you like it, support the developer with a Donation.
So, you’ve got a WinForms app and you expect an exception to be thrown within your Form’s Load handler. Maybe you even deliberately throw one yourself. But when you start debugging, the execution of your Load handler terminates at the point where the exception was thrown, but no exception is reported and your application keeps running!
This issue was baffling me for several hours today when a colleague of mine pointed me to a helpful post at StackOverflow that explains the problem.
If these conditions are met:
- You are running on a 64-bit version of Windows (whether your application is built for 32-bit or 64-bit doesn’t matter; only the bit depth of the OS)
- You are building a WinForms app
- You are debugging the application with Visual Studio (using default options for Exception catching)
- Your main form has a Load event handler
- During the execution of your Load handler, an exception occurs
The exception will be silently swallowed by the system and, while your handler will not continue execution, your application will continue running.If you wrap your handler code in a try/catch block, you can still explicitly catch any thrown exceptions. But if you don’t, you’ll never know anything went wrong.
Note that all of the conditions must be met. If, for instance, you run the application without debugging, then an unhandled exception still be correctly thrown.
According to this Microsoft Connect post, this has been a known issue with 64-bit Windows since 2008:
This is a known issue on 64-bit OS platform. The reason is that the 64bit OS core does not allow user mode exception through kernal mode stacks. The exception is swallowed by OS sliently. That happens in FormLoad handler, because it is called in an OS callback. 32bits OS doesn't do this, so it doesn't repro there.
Paul Betts sheds more technical light on what’s going on, although I believe his post addresses the swallowing of such exceptions even without debugging, something that is supposed to have been resolved for Windows 7 SP1.
If you need the debugger to break during your load method, there are a few things you can do:
Break whenever a CLR Exception is thrown
You can optionally tell Visual Studio to break whenever a CLR exception is thrown, even if it normally would have later been caught (via Debug… Exceptions… or Ctrl+Alt+E).
The downside to this approach is that you may see a lot of “noise” about thrown exceptions that are eventually handled (although in some circumstances this is an invaluable tool to discover exceptions that are being thrown that shouldn’t be).
You can catch exceptions in the other categories as well, but typically it’s the CLR exceptions you’ll be interested in.
Use the Application.ThreadException Handler as a Breakpoint
You can attach a handler to the Application.ThreadException event before running your app, and you can set a breakpoint within it to inspect the original exception that was thrown.
The downside to this approach is that you can get into this handler for all sorts of other things as well. But if you’re just trying to see what’s being thrown during startup, this will do it.
Use a 32-bit Version of Windows
Yeah, it’s drastic, but if you’ve got VMs or other machines available, you can always debug on a 32-bit version of Windows.
There’s no question—when it comes to writing build scripts, I’ll take rake over just about anything. Especially anything that requires defining a script using declarative markup (I’m looking at you, MSBuild and NAnt).
If you want to build .NET projects with Rake, here’s the fastest way to get started with Ruby and Rake on a Windows machine (you can skip to the end for an even shorter list).
Install Ruby 1.9
Download the latest Ruby 1.9 installer:
Run the installer.
I recommend checking the option to add Ruby executables to your PATH.
Ruby libraries are called gems. They can be installed and uninstalled from your system as easily as adding and removing an app from an iPhone. Usually.
Some gems come with source code in a language other than Ruby, such as C or C++, and they assume that they’ll be installed on a Unix or Linux style machine system where tools like make, gcc, and sh are present. Naturally, these gems don’t install so well on Windows. DevKit fixes that.
Download the DevKit self-extracting archive from the same page you downloaded the Ruby installer: http://rubyinstaller.org/downloads/
Run the DevKit executable.
When the dialog asks where to extract to, change the folder to C:\DevKit (just consider this the DevKit installation directory).
Open a command prompt and do the following:
ruby dk.rb init
ruby dk.rb install
Then, to make sure it installed correctly, do:
gem install rdiscount --platform=ruby
If all is well, you should see the following line while rdiscount is being installed:
Temporarily enhancing PATH to include DevKit...
Update the Gem System
At the command prompt:
gem update --system
This will update the gem system to the latest available version.
gem install faster_require
This little gem speeds up the performance of the ruby “require” statement on Windows. In some cases, quite a lot. I always include it on any Windows machine I use.
gem install rake
This is what we’re after, after all.
gem install albacore
Albacore is a gem with a set of rake tasks that help with building .NET projects, including a task for executing msbuild which you can use to easily build a Visual Studio .sln file.
That’s it. You’re ready to start building your .NET projects with rake on Windows.
Recap: The Short List
Here’s the shorter list:
- Download and install the latest Ruby from http://rubyinstaller.org/downloads. Include Ruby executables in PATH.
- Download DevKit from http://rubyinstaller.org/downloads. Extract to C:\DevKit
- Install DevKit
- cd \DevKit
- ruby dk.rb init
- ruby dk.rb install
- Verify DevKit install
- gem install rdiscount --platform=ruby
- Should see: Temporarily enhancing PATH to include DevKit...
- Update gem system
- gem update --system
- Install gems
- gem install faster_require
- gem install rake
- gem install albacore
In technology, once you have bad programmers, you’re doomed. I can’t think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery.
- Paul Graham, What Happened to Yahoo
So, there’s this wonderful “feature” for Windows XP that, when you logoff, the password boxes on the Welcome screen don’t actually accept keyboard input (this was affecting me with a clean install of XP with SP3, 32-bit).
Did you know there’s a backdoor to bypass the Welcome screen and use the Classic logon dialog instead?
Just press Ctrl+Alt+Delete twice, and you’re in business: