After changing Python installations on Windows, you may find that Python is ignoring the commandline parameters passed to a Python script.
To fix this, open regedit.exe, head over to
HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command and make sure the value field is
"C:\PYTHON_PATH\python.exe" "%1" %*. If the
%* is missing, then the Python script will not have access to the commandline parameters passed to it.
convert.exe from the installation of
ImageMagick-6.6.3-3-Q16-windows-x64-dll.exe gives this error:
The program can’t start because CORE_RL_wand_.dll is missing from your computer. Try reinstalling the program to fix this problem.
The packagers have forgotten this DLL. The solution is to install the statically linked
ImageMagick-6.6.3-4-Q16-windows-x64-static.exe or try a x64-dll.exe installer of an older version.
You might feel the need to publish Mercurial repositories in a central location and collaborate using that. This is really useful when:
- You are working from 2 or more workstations or laptops.
- You are in a small team and there are 2 or more people working on the project.
Publishing a Mercurial repository in a central location enables different people or computers to push and pull from it. There are a few common ways to do this:
- hg serve: Real easy and quick to setup with simple features.
- SSH: Not as easy on Windows as on Linux. OpenSSH server is the most common option, but it comes with Cygwin and all its problems.
- HTTP: Requires quite a lot of configuration on Windows.
- SMB: If you are on a Windows network, your computers or team is small in number and your needs are simple, then using a Windows share is very compelling!
You can start publishing Mercurial repositories using Windows shares in just a few minutes:
- Designate one computer as the central repository server. Let us call it A. It can be the workstation of the one of the team members, it does not really matter. Other computers, B and C, should be in the same Windows network as A.
- Create a directory on A, say
D:\HgReps and move all your current repositories to it. New repositories in the future should also be created here.
- Share the directory on A, so it becomes
\\A\HgReps. Give only the team members who use A, B and C access to read and write to this share. You could also give read access to other users who you wish only pull from A. These access permissions should be very easy to configure if you are in a well set up Windows domain.
- Point all the current working directories on A, B and C to push and pull from
\\A\HgReps. To do this, open the
.hg/hgrc file in each working directory and edit it so it points to A. For a project named Foobar, the
.hg/hgrc file looks like:
default = \\A\HgReps\Foobar
All this setup is ridiculously easy to do for a small team and everything just works without much configuration. Another nice side-effect is that you can backup the
D:\HgReps on computer A easily and grab all the team’s commits.
Mercurial users keep insisting that you do not really need to create actual branches to work. But, if you are one of the few who likes to do this, merging branches is just as easy too. I use TortoiseHg, but the equivalent command-line options are just as obvious.
- Consider branches A and B. You wish to merge B to A, so that work on A can continue. Typically, A might be the default branch and B can be a feature branch.
- Finish, test and commit all the files on both branches A and B.
- Open Repository Explorer. Update the working directory to branch A. This can be done by choosing the head of branch A, right-click and choose Update.
- Choose the head of branch B, right-click and choose Merge with. Tip of branch A will automatically be chosen as the target for the merge. Click Merge.
- Mercurial will try to merge the files automatically as much as possible. For the files with merge conflicts, it will pop up KDiff3 windows so you can pick the changes you want merged. The conflict windows are displayed sequentially, finish one and the next one is displayed.
- Settle all the conflicts and your merge is done! Branch B should be connected to branch A nicely in the graph displayed in Repository Explorer now.
I got this error from the CUDA C compiler (
nvcc.exe) when compiling a .cu file:
Visual Studio configuration file ‘(null)’ could not be found for installation at ‘C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/../..’
The error gives very little clue on how to fix it. I checked the Cuda.rules file and the CUDA toolkit files and found no problems.
It turns out that this is one more icky problem when transitioning to 64-bit computers. I was on a 64-bit machine and using a 32-bit Visual C++ compiler. I had installed the 64-bit versions of the CUDA Toolkit and GPU Computing SDK. The above error was caused by this mismatch.
It went away after I installed the 32-bit versions of the CUDA Toolkit and GPU Computing SDK. Do remember to manually change the
CUDA_LIB_PATH to the
lib directories of the CUDA Toolkit installation. The 64-bit toolkit installer sets this to the
lib64 directories, but the uninstaller does not remove them. And when the 32-bit toolkit is installed, the installer does not update the variables if they already exist (with their wrong paths).
You may also need to add the
bin directory to the
PATH environment variable, replacing the
bin64 path that might be there. Executables compiled with CUDA need this to load the CUDA DLLs they need.
After many years of using Cygwin, I am saying a final goodbye to it thanks to GnuWin32. Much like Cygwin, GnuWin32 is also a port of common Linux command-line tools to Windows. However, it does not have any of the icky problems of Cygwin. There are no DLL problems (like with
cygwin.dll), no special command windows, or directory naming conventions.
- The structure of GnuWin32 is very simple. Most of the command-line tools are provided individually as easy-to-install setup packages. You can download and install only the packages you need. For example, when you feel the need for grep, just download the grep package.
- When there are a lot of small tools that are related, they are provided as a single package. For example, ls is in coreutils package.
- Do remember to add the bin directory of GnuWin32 to the
%PATH% environment variable. Typically this is
C:\Program Files (x86)\GnuWin32\bin This is where all GnuWin32 packages put their binaries.
MetalScroll is a much-needed update to the old RockScroll addon for Visual Studio. Unlike its predecessor, MetalScroll is open source.
- The one improvement that I liked in MetalScroll is that I can split the code window by dragging the top right corner. This Visual Studio feature was hidden earlier by RockScroll.
- MetalScroll has changed the keybinding required to highlight words to Alt+double-click. I prefer directly double-clicking and thankfully this can be changed back.
- MetalScroll also offers settings to change the colors and dimensions, all of these can be accessed by double-clicking the scrollbar.
- To change the color of the highlighted word, go to Tools → Options → Fonts and Colors. Here choose MetalScroll in the Display items section.
- Sadly, MetalScroll works only with Visual Studio 2008 and 2005. It would have been great if it worked with Visual Studio 2010.
I recently ditched my dual display setup and moved back to a single widescreen display. The second display definitely helped while debugging code in Visual Studio. However, most of the time it was turning out to be a distraction, staying in my peripheral vision, while I was trying to focus on the primary display. The move to a single display felt right, thanks to virtual desktops.
Ubuntu comes with virtual desktops built in and it works beautifully. But, Windows 7 does not have built-in support for virtual desktops. I am using VirtuaWin, an excellent open source virtual desktop manager for Windows.
VirtuaWin is chock-a-block full of bells and whistles! I turn off all of them and just do the following:
- Reduce the number of desktops to 2. One for work, other for fun. The default is 4, which is too many to be useful.
- Start it with Windows and turn off the splash screen.
- Bind some intuitive key combinations to switch between desktops. I like Ctrl+Shift+→ and Ctrl+Shift+← to move to the next and previous desktop. Ctrl+Shift at the left corner of the keyboard, and the arrow keys at the right, perfect to use!
- VirtuaWin ships with some cool plugins. I use Dexcube, which has the 3D cube effect, very nice for folks using 4 or more desktops. But, since 2 desktops are enough for me, I use the Filmstrip effect inside Dexcube.
BoostPro Computing offers pre-compiled Boost library binaries for Windows here. This is the easiest way to install Boost on Windows, since compiling Boost source code can be quite painful. As of version 1.42.0, BoostPro only offers 32-bit binaries. It is important to note this since the BoostPro installer does not mention that it is 32-bit anywhere. Other 64-bit libraries and code compiled along with this Boost flavor will give strange linker errors like this:
Foobar.obj : error LNK2019: unresolved external symbol __imp____gmpq_clear referenced in function “public: __thiscall CGAL::Gmpq_rep::~Gmpq_rep(void)”
If you have to stick to BoostPro, then you might be forced to switch your other libraries or code to 32-bit mode.
Trying to compile CGAL 3.6.1 with Boost 1.42 on Windows generated a lot of errors of this form:
CGAL-3.6.1\auxiliary\gmp\include\mpfr.h(280) : error C2061: syntax error : identifier ‘intmax_t’
CGAL-3.6.1\auxiliary\gmp\include\mpfr.h(283) : error C2061: syntax error : identifier ‘uintmax_t’
The errors are related to the (missing) declaration of
uintmax_t. According to this thread on the MPFR mailing list, these errors are caused due to changes in Boost 1.42 and later. So, until MPFR is updated to handle these Boost versions, the solution is to use older versions of Boost. I used Boost 1.41 and CGAL compiled successfully!