Wednesday, October 17, 2012

VSPTree is alive!

I've been using Windows 8 for the last couple of months and have been having a great time with it. It's Windows 7 with a nice flat UI, much faster I/O. Stability is the same, and pretty much have never opened a metro app. I'm not even sure how to use those correctly. The new Start Menu is just a very big start menu to me.

Anyway I digress, I needed to profile something and went with the usual suspects. CodeAnalyst, Got no data. AQTime, failed to launch the exe. Very Sleepy, worked but no hierarchical call graph. Tried to resurrect VSPTree with the VS2010 profiler and I got a driver not allowed error.

Oh well. Some digging around and I found Remote Tools for Visual Studio 2012.

So I took a little time and updated VSPTree to work with it, and added some minor usability updates. It's not the best application in the world, but sometimes it's handy just to have it.

VSPTree 0.5 : Now with Windows 8 64 bit support. Here.

Friday, October 12, 2012

Conditionals in Property Sheets

I've since moved to using property sheets exclusively instead of wfMake and it's been going well. A bit more more typing but I like the fact that I can edit a bunch of includes and not have to regenerate the vcproj/vcxproj. The most time consuming part was going through all the projects and setting the right macros everywhere. But you only have to do it once.

It's one place to update everything and can be syntax highlighted and formatted quite neatly.

You end up with something like this. This is only an excerpt, the whole thing is quite huge. You can then string your macros any way you like. The fanciest bit of this is the conditionals at the top that I use because some sln's that include these projects are sometimes in different places, and there was no other way I could think of to correctly set the path.







Wednesday, March 28, 2012

Pre-commit goodness

This solution was used to solve programmers frequently accidentally committing debug executables into SVN. On developer machines you rarely see this issue because all the debug libs exist, but a level designer or artist will frequently run into the problem and will have no idea what the problem is, and someone will have to take a look at it and figure out what in the world is going on. Then the doh! moment happens and someone has to recompile and commit that.

The precommit hook also show an example of how to deny committing certain files like .argb and thumb.db

The solution is simple enough. Add a precommit hook that scans all the exe's for debug libs. This method uses Dependency Walker by Steve Miller.

So far I've tested it on rather large commits with 20 exe's and it doesn't take more than 20 - 30 seconds to complete. Server is running a i7-960 for reference.

cd /d %~dp0

SET PATH=E:\svn;E:\bin;E:\depends

svnlook changed %REPOS% -t %TXN% > E:\temp\svnlook%TXN%

grep -E "A.+(.argb)" E:\temp\svnlook%TXN%

if "%ERRORLEVEL%"=="0" (
 echo Do not commit ARGB files! >&2
 goto :error

grep -E "A.+(thumbs.db)" E:\temp\svnlook%TXN%

if "%ERRORLEVEL%"=="0" (
 echo Do not commit thumbs.db! >&2
 goto :error

grep -P -o "(?<=\w\s\s\s).+\.exe" E:\temp\svnlook%TXN% > E:\temp\svnlook%TXN%_exegrep

for /f "tokens=1 delims=¶" %%f IN (E:\temp\svnlook%TXN%_exegrep) DO (
 svnlook cat %REPOS% -t %TXN% "%%f" > E:\temp\temp
 depends.exe /c /of:E:\temp\dep.txt E:\temp\temp
 grep -E "QT.+D4.DLL" E:\temp\dep.txt
 if "!ERRORLEVEL!"=="0" (
  echo Do not commit Debug executables! %%f is in debug>&2
  goto :error

del E:\temp\svnlook%TXN%
del E:\temp\svnlook%TXN%_exegrep
exit 0

del E:\temp\svnlook%TXN%
del E:\temp\svnlook%TXN%_exegrep
exit 1

Wednesday, February 15, 2012

Saving tortoiseGit password

Took me a little while to find this, so I thought I would immortalize it here.

Apparently you need to save a file called _netrc in %USERPROFILE%

So a quick little batch file :

@echo off
SET /P HOST=What is the hostname i.e
SET /P USERNAME=What is your username?
SET /P PASSWORD=What is your password?

echo machine %HOST% login %USERNAME% password %PASSWORD% > "%USERPROFILE%\_netrc"

Thursday, February 9, 2012

Crappy documentation? Internet to the rescue

So through some amazing series of events, I broke the TeamCity installation.

Things weren't building. I thought it might be a bug, so maybe I'll try a newer version. The newer version needed an upgrade to the database so I said OK, but I made sure to back up first of course.

Lo and behold the new version did solve the old problem, but it presented a host of new ones! Basically made it unusable. Of course this was a beta build, but hey beta is the new GMC nowadays right? WRONG!

Oh well, time to uninstall and go back to the backup. Cue the 30 minutes I spend trying to figure out how in the world do I restore this backup!

The manual says :

Just do this!

maintainDB[cmd|sh] restore -F <TeamCity backup file name>

Error : config is not empty. Ok I'll delete that then.
run again
Error : system is not empty. Ok I'll empty that too!
run again.
Needs a target!

Wuh? That's the "Restoring Data from Backup to Another Database" instruction not the standard restore.

But no. It doesn't work. Ok, scrounge around a bit more....


Turns out you need to copy the out of the config directory in your backup zip first. Give that as the -T

And then everything gets restored. Then it gives you some instruction that says, you have to copy that file into system\
Did I? Nope. Did the restore work? Yes.

Bad documentation is bad.