When emitting debug trace information from your application (using OutputDebugString), you can format your output string in such a way that when it is double-clicked in the output window, it jumps your code editor to the spot where it originated. The format which supports this feature is as follows:

%ABSOLUTE_FILE_PATH%(%LINE_NUMBER$): %MESSAGE%

So for example:

“C:/TextureManager.cpp(50): [TextureManager] Texture loaded!”

I often find myself copying a line from the output window and using CTRL+SHIFT+F (Find In File) to locate it’s origin. This is a nice way to get around that long winded process and provide a direct link to the file and line. You can of-course use the __FILE__ and __LINE__ pre-processor macros here to automatically format all your debug traces in this way.

As it turns out Mercurial’s support for subrepos works a treat and is definitely something I wish I had looked into sooner. After following the official mercurial subrepo docs, I found that getting a simple subrepo set up is fairly trivial. This post summarises my experience.

The task was simple. Take repository “repoB” and include it as a remote subrepo in the main repository “repoA”. This can be achieved fairly easily be carrying out the following steps..

1. In your main repository, create a folder (ideally close to the root) to house your subrepository mkdir subrepo
2. Navigate to the root of your main repository and create a file named .hgsub (this will store meta data about the subrepo mappings, similarly to how you might store ignore rules within the .hgignore file) touch .hgsub
3. Use a text editor (or command line) to add a mapping to your .hgsub file. This mapping is very simple and exists as local_subrepo_path = external_repo_path (where local_subrepo_path is relative to the root of your main repository and external_repo_path can be a relative/absolute/url to your external sub repository). Example:echo subrepo = https://me@bitbucket.org/me/subrepo > .hgsub
4. Finally make sure to hg add .hgsub and hg commit your changes

At this stage your subrepository is set up. Navigating to /subrepo and running hg commands will now effect the sub-repository whereas hg commands executed above /subrepo path affect the whole repository (in most cases recursing down into the sub repository). Make sure to run hg pull –update inside the sub repository to carry out the initial pull/update of the sub repository file structure. As hg clone works recursively, anyone who clones your main repository (to tip revision) should also automatically receive the /subrepo files (as they were at the tip of the main repository).

LARGE_INTEGER start, end, freq;
QueryPerformanceFrequency(&freq);

QueryPerformanceCounter(&start);
Sleep(1000);
QueryPerformanceCounter(&end);

double elapsedMilliseconds = (end.QuadPart - start.QuadPart) * 1000.0 / freq.QuadPart;

After using Microsoft’s PIX tool numerous times over the past couple of years, on a number of projects (all Windows/DX9 based), I was surprised to find that many other students weren’t using PIX and would often spend many hours close to submission date, getting to the bottom of the most tedious graphical bugs or rendering artefacts. I’m confident that the bugs in question could often have been identified and fixed in a matter of moments given the right tools . This brings me to “PIX for Windows”, Microsoft’s graphics debugger for DirectX. Don’t get me wrong, PIX isn’t the answer to all your problems, neither will it fix anything for you automatically out of the box. The purpose of this post is to provide a quick run through the essential prerequisites required in order to get up and running with PIX, followed by a brief explanation of some of the most useful features PIX has to offer. I also demonstrate how you can configure your C++ DirectX application to be “PIX aware”, communicating with PIX to make the debugging experience a little simpler and smarter. For further reference, please see PIX for Windows documentation.

Installing PIX

PIX for Windows is a GUI tool distributed with the Microsoft DirectX SDK and can be found in the following location after install;

%DXSDK_DIR%\Utilities\bin\%ARCHITECTURE%\PIXWin.exe

Configuring your system

Before firing up PIX, first head to the DirectX Control Panel, this is a nice GUI utility which allows you to tweak the DirectX runtime by enabling/disabling certain features and components.

The DirectX control panel is also part of the Microsoft DirectX SDK and can be found in the following location after install;

%DXSDK_DIR%\Utilities\bin\%ARCHITECTURE%\dxcpl.exe

Regardless of whether or not you choose to use PIX,  it is handy to know about this utility as it can be used to toggle between the debug/release DirectX DLLs and turn on useful compile/runtime feedback . This feedback ranges from efficiency warnings to runtime memory leak reports.

Figure 1 (click to enlarge)

Figure 1 shows my DirectX Control Panel configuration, which I have tweaked for personal preference. Mirroring this configuration should ensure PIX operates correctly, although not all the options I have enabled are not necessarily fundamental or related to PIX in any way. Play around with this configuration utility and find a configuration you are comfortable with. I often find myself tweaking the “Debug Output Level” slider based on the scenario, and disabling “Break on memory leaks” when I’m looking at someone else’s code and don’t care too much about memory leaks. Also, use “Software Only” mode judiciously, as this disables all hardware acceleration and forces everything to be rendered in software on the CPU (which can be painfully slow!). Note: The “Render” and “Mesh” windows within PIX do not function correctly when “Maximum Validation” is disabled.

Next: Experiment One >>

sudo cp -R /usr/share/themes/Ambiance ~/.themes/
sudo gedit ~/.themes/Ambiance/gtk-2.0/apps/gnome-panel.rc

Then comment out the following line, as below

#bg_pixmap[NORMAL] = "img/panel.png"

A theme switch (from System > Preferences > Appearance) is required for changes to be applied. Now setting the transparency on panels effects all areas

• Backing up the entire root directory
• Restoring from backups
• Backup/Restore to/from remote machine
• Retaining file permissions
• Backup/Restore GRUB configurations

https://help.ubuntu.com/community/BackupYourSystem

A number of backup/restore utilities are mentioned on the above page, my favourite being the simple TAR tool. Details on backing up using TAR can be found here…

https://help.ubuntu.com/community/BackupYourSystem/TAR

Well in my case I was working on a remote web server via ssh, setting up some web aplications on various different ports. The hosting company had yet to open these ports to the outside world. However, this technique allowed me to bind the local ports on the remote machine (running the web applications) to my local machine. This allowed me to test and configure each application as if it was installed on my local machine, simply by accessing localhost:xx in my browser. The port numbers don’t even have to match! I ended up binding remote port 8080 to port 80 on my local machine.

This can be achieved by issuing the following command on the local machine…

ssh $REMOTE_IP -L $REMOTE_PORT:localhost:$LOCAL_PORT

Example binding remote 8080 to local 80:

ssh myhost.com -L 8080:localhost:80

sudo apt-get install giplet

Then choose “Add To Panel” and find giplet in the list of items.

Screenshot