visual studio

Login Queues

Just got done adding a Login Queue system to the auth host (I have to add it to Playgate too, but it’s the weekend and it’s late and I’m gonna do that later).

The nice thing about working on this particular piece of “sigh” was that I got to work mostly in Visual Studio. I used CMake to rustle up a quick .sln for the host files and the code I was writing was isolated enough that it didn’t run into any cross-platform issues.

I’m going to access the web now…

More experimentation with Managed C++ I mean C++/CLI and running in to an old friend: The Windows Firewall. My code wants to access the Internet, and Windows – properly – wants the user to approve this random piece of code doing that. It’s doing the right thing.

But the problem is until the user clicks approve, my application can’t access the Internet. I wouldn’t mind if it just sat there and waited. But that’s not what happens.

RC4212

.\src\Playgate.rc(286) : error RC4212: Codepage not integer:  utf-8)

That’s right. It should be

#pragma code_page(65001)

And that’s what it was before Visual Studio inexplicably changed it to

#pragma code_page(utf-8)

There doesn’t appear to be any documentation on this error. Just change it to 65001.

Admit when you have no clue.

http://www.microsoft.com/presspass/press/2008/sep08/09-29VS10PR.mspx

Microsoft described the next release through the following five focus areas: riding the next-generation platform wave, inspiring developer delight, powering breakthrough departmental applications, enabling emerging trends such as cloud computing, and democratizing application life-cycle management (ALM).

Well, my delight is certainly inspired :)

Personally, someone deserves kudos for taking the Visual Studio 2010 brief (“make it cool”) and extemporizing a whole paragraph from it.

And so it came to pass…

It Happenethed

I really didn’t think this would happen so quickly. When you’ve been fitting spits and spots of systems together over 6 years towards a goal, you build up an overly active awareness of how much is involved. You’re overly inclined to fill in variables. I knew that the host was easy enough to build, and I’d scripted the mac build for Gophur, so I knew that wasn’t hairy. Recently I’d come to know that now the client and host source is all in one repository I can match source revisions. But, when I tried to put it all together, along with scripting it under Windows … Pop. I think my head just exploded, is that my amygdala on your lapel?

The key to it all was VSoft’s FinalBuilder. There are many build tools, but FinalBuilder is a basically a graphical scripting language / scripting language assembly tool the likes of which you expect from old Amiga tool sets or the Mac. These geniuses of it is delivering the power an old scripting hack like me only images getting from Perl/Python/Ruby/JavaScript/Rexx in a graphical interface.

SVN: 4 weeks in

Generally finding the switch from Visual Source Safe to SVN a boon, but there are definitely some areas where it’s weaker than you’d expect. In particular, we’re running into a few simple ball breakers:

Line Endings. Oh. My. God. When we populated the repository, we didn’t even think about this. Get this, using the Microsoft version control solution it wasn’t an issue. Ha – who’d think the first point for VSS vs Open Source RCS would be a cross-platform issue? (Anyone with coins inserted in their brain meter)

So, none of our files have svn:eol-style native. That’s the fix. But if I svn propset svn:eol-style native */*.cpp */*.h there’s just one minor itty bitty niggle: it changes every line in every file completely destroying history and blame.

Before and After

Before my little weekend spree: Client took upto 10 minutes to build on my various boxes depending on how long before I started multi-tasking and what I was multi-tasking. Probably took around 5-6 minutes on Martini’s machine, and probably 6 minutes for a normal build on my work box if I left it alone. 4 minutes for a non-optimized debug build.

After: For a full, optimized build, the compile takes 55 seconds (61 seconds if you do a full rebuild including our teulKit network library). The link phase takes 2.5 minutes, most of which is “Generating code” (whole program optimization/link time code generation). So, it now takes less time for a complete build than it used to take to build a quick debug build. The debug build takes 125 seconds.

We can probably shave another 20-30 seconds off the debug build and 30-60 seconds off the release build with a little simple reorganization. For instance, one of the header files with the most overhead has a dual-use which makes it unsuitable, but I think I can fix that with a little project configuration.

Precompiled headers

Our project just takes too long to compile. It’s only a few hundred thousand lines of code, but it compiles like there are millions.

I’ve spent most of last night and today reorganizing header files and project files and turning our primary include file set into a single, precompilable header.

Visual Studio, dramatic effect: just over 2 minutes 27 seconds off the time to build the entire project while also adding our network API to the build! Xcode seems about the same or slower (I’ll benchmark that next week) and I got tired of wrestling with autoconf/automake under Linux for the host.