Blog
Why I Use Version Control
Date: 21/8/2013
Tags: coding crash
Apart from the replication functionality of version control I got to use the ability to rollback code for real this week. Normally it's a stop gap that you never really need to use, but in this case I came across a problem that had me stumped. Clearly in the past my software has worked fine, and so in the case where you literally have no idea whats wrong, or even what change you made broke things there is version control.

In a nut shell the Mac port of Scribe was broken, it would start and then crash somewhere inside the Carbon library. I tried valgrinding it and that basically led nowhere useful. So I put it off for a bit before deciding to bite the bullet and walk back through my SVN commits and isolate the change that causes the bug. I started by writing a small python script that took a date as a command line parameter, that checks out the source as it was on that date. I started early in the year, and checked the 1st of each month. Compile each checkout and test it for that crash. I worked my way through till the 1/7/2013, where is started crashing... then I went back to 15/6/2013... runs fine. Forward to 23/6/2013, crashes. So some commit between 15/6 and 23/6 was to blame. The revisions in Lgi were 906 to 931 or so.

I began walking the Lgi checkout forward one revision at a time with the command:
svn up -r [revision_number]
Then recompiling after each update and running the software to test for the crash. It didn't take long to figure out that revision 912 was to blame.

Now I was getting somewhere!

So I started looking at all the source code changes in that commit and quickly ruled out all but two. So to test which part of the commit caused the crash I checked out r911 into a temporary location on my Macbook, while having r912 checked out on my PC. Then I proceeded to WinMerge changes one by one over to the r911 checkout on the Mac. That isolated the change to GList.cpp as the cause of the crash.

The final analysis is that a mismatched call to GSurface::ClipRgn(NULL) was doing something bad to the Carbon API and it would all go south from there. Reasonably easy to fix once you know what the issue is.

Yay... for source control! ;-)
(0) Comments | Add Comment

64bit Adventures
Date: 11/6/2011
Tags: coding scribe
I've been playing around with 64bit builds of Scribe on windows. And it's been er... interesting to say the least.
  • By default the Visual Studio 2005 installed doesn't install the x64 compiler and libraries. Nice...
  • When you do get that installed, and then create an x64 profile in your solution you get the option to copy the settings from the 32bit profile. Which for the most part works, but when you try and compile said x64 profile, you discover this delightful error:
    fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
    Which in a nutshell means you are linking 64bit objects into a 32bit binary. However the standard response that people get on the forums is that you have to set your Linker- >Advanced->TargetMachine correctly. And you know what? Well it WAS set correctly to MachineX64. So what gives? Well if you click on Linker->CommandLine and look in "Additional Options" you'll see /MACHINE:I386. Sigh.
  • When running Windows7 64bit and you put additional 32bit DLL's in C:\Windows\System32 you'd think... that since there is a "32" in that folder name that is where they go. Well no... the 64bit DLL's go in System32 and the 32bit DLL's go in "System". Gaaaaahhhhh.
But at the end of the day, there it is... 64bit Scribe:
(2) Comments | Add Comment

Visual Studio 2005 / Win9x support
Date: 31/5/2011
Tags: coding
I'm officially migrating to Visual Studio 2005 as my main compiler on windows, from Visual C++ 6. So all the open source apps I've released will be getting VS2005 projects over the next few weeks. Also on top of that rather obvious change I will be deprecating support for Windows 98 and ME, slowly removing that support from Lgi and migrating to unicode as default across all my apps. I've been using Utf-8 and multi-byte charset for a long time, but now the default compile time option will be Unicode instead of Multi-byte characters.

I'll also be looking at building 64bit versions of my apps on Windows in the near future. Now that I need the address space but I would like all the libraries to support that if at some point I DO need it. Over the last week or so I've been switching on the VS2005 64-bit warnings and resolving most of them.

On the Mac I'm going to be using XCode 3.6.2 for a good while yet. I only recently settled on that as my standard compiler there, and did a lot of work getting the code to a point where it compiles without too many warnings. The Carbon backend is a worry though. I can't create new Carbon apps with that XCode so that sucks. Eventually I'll have to address that by porting the main Lgi core to Cocoa. But that would take a good while *sigh*
(0) Comments | Add Comment