New license for my SWXBATCH_CEEFIT project

Have you heard that the CeeFIT website is back up and running? Well it came back up a few months ago. Thank Heavens.

But the author kindly pointed out to me that I was not complying with the original license of the CeeFIT website, i.e. the "GNU GENERAL PUBLIC LICENSE Version 2" as mentioned here. So to comply I had to change the license of one my projects, specifically the SWXBATCH_CEEFIT. Unfortunately Google Code (where I host the source code of my projects) doesn't allow me to specify different licenses for individual projects. So I had to change the license associated with all my projects to the GPL v2, though this only really affects the SWXBATCH_CEEFIT project. I have added a note on the home page to inform of the changes, but am hoping repeating this information on my blog will help clarify the issue.

As for my other projects, you are free to do what you want with it since I have not attached any license to the projects themselves.

SO DOES THIS AFFECT YOU?

The SWXBATCH_CEEFIT is primarily intended as a test framework. If you use it as intended and don't distribute your test framework to your clients (i.e. you only use the test framework in house) then the license change from 'New BSD' to 'GPL' doesn't affect you. If you are unable to comply with this requirement, I am afraid I can't help, since the GPL is viral in that way.

My Continuous Integration Build is too fast

We all know of Continuous Integration and the importance of having really fast builds, especially on a central build server. If not read up on http://martinfowler.com/articles/continuousIntegration.html. You may have also heard that a good build time to shoot for is ~10-15 minutes for each regular build (not accounting for nightly builds)  at least for small-medium sized projects. If you are interested there are numerous discussions and posts on this. So like any good build engineer striving for efficiency and speed I attempted to reduce build times for the project I work on, at least till now.

Some details on the project build:

• Our projects are currently in Visual Studio 2005 (we are in the process of upgrading to 2010 but that is another story).
• Almost all our projects are native C++ (i.e. Unmanaged code) with a sprinkling of C# (i.e. Managed code)
• We use CruiseControl.NET but use the Visual Studio Task (which internally executes devenv.com to rebuild the Visual Studio 2005 projects).
• Monitor every minute for a developer's commit to the repository
• Run Unit tests
• Run Functional tests
• Run Integrated tests (nightly builds only)
• Notify developers of build status
• Licensing and Unlocking
• Package (ZIP, installer)
• Deploy (for download by our modelers/testers)

This entire process takes about 12-15 minutes on our build server which is not the newest piece of hardware (in fact was purchased somewhere around 2001/2002). The nightly builds could take more than an hour since we run Integrated tests too, on the same build server. Not too shabby but we could definitely do better. 

The simplest way to speed up the build would be to purchase a new build server and cannibalize the old one or simply re-purpose it. 

Licensing and what now?

But here's the catch. In case you missed it, I highlighted "Licensing and Unlocking" in the steps above for that reason. What is that step you wonder? Well I work with Pro/Toolkit applications, the API for Pro/Engineer. If you want to deliver programs that use Pro/Tookit to your customers (who most likely will not have a license for Pro/Toolkit) then PTC provides a little executable called protk_unlock.exe that simply "unlocks" your Pro/Toolkit application to enable it to run on PC that don't have the license for Pro/Toolkit. If you were not aware of it, "unlocking" your Pro/Toolkit application will cause the PTC License Server to hold your Pro/Toolkit license for 15 minutes (yes, you read that right - FIFTEEN minutes). Of course all this is common knowledge.

'14' is the wrong answer

So what if my average build completes in less than 14 minutes? Well CruiseControl.NET uses a "update before you build" style to build your projects regularly. Which means that if two developers commit to the repository within a minute then there is a good chance that the two commits would be rolled into a single build (this is different from the process that some Continuous Integration tools use where a commit triggers a build - must be nice to own these nicer tools). But the worst case scenario is that "if for some reason the average build time is less than, say, 14 minutes AND the next build starts within the minute, THEN there is a good chance that the second build will not be able to 'unlock' its Pro/Toolkit application, since protk_unlock holds the license for 15 minutes and our build has finished in less than that time."

Now what?

So what is the solution to this problem? Well, if you have the money, you could always add a 2nd Pro/Toolkit license to that single build server, so that you always have one license available every 15 minutes.

Or you could do what I did - YOUR BUILD IS TOO FAST, SLOW IT DOWN.

Almost makes me want to cry. Oh well. What other idiocracies have you encountered in your build scenarios?

Note: I linked to a cached page from Google's server for the following link http://openmakesoftware.com/mavericks/2009/02/17/check-out-code-post-commit-not-pre-build/ since the original didn't show when I posted this article.

Will the real 'PHI' symbol please stand up?

In my last post SolidWorks Hole Size and Extended ASCII codes I had mentioned that I needed to input the 'PHI' symbol when creating a Wizard Simple Hole in SolidWorks using the SolidWorks API for Visual C++.

Well it turns out that while my mind was in the right place, I probably should have taken that left turn at Albuquerque. So lets revisit that topic again. It seems that using Extended ASCII codes for this job was the wrong solution, though it did lead me to find out more about specifying symbols using Unicode, since I figured that I need to specify the PHI symbol using Unicode.

So now the questions are "what is the Unicode character for the PHI symbol?" and "how do we specify that character in C++"?

Lets answer the more difficult of the two questions first, which is what this post is all about.

What is the Unicode character the PHI symbol?
Well turns out that there are numerous ways to express the same symbol (at least they are the same in that they are all called PHI). Here are a few Unicode characters that MS Windows recognizes as PHI symbols:

• U+0278 (http://www.fileformat.info/info/unicode/char/278/index.htm)
• U+03D5 (http://www.fileformat.info/info/unicode/char/3d5/index.htm)
• U+03A6 (http://www.fileformat.info/info/unicode/char/03a6/index.htm)
• U+00D8 (http://www.fileformat.info/info/unicode/char/d8/index.htm)

So which one is the one we need? Well its the last one. Why? Because thats the only one that SolidWorks will accept and create a hole with and the only one that looks like the Mathematical symbol PHI (Ø - see note below). The rest may look like PHI but they are not the Real McCoy.

Now that we have the Unicode character to use, comes the easier question:

How do we specify Unicode characters in C++?
Surprisingly the answer is similar to specifying Extended ASCII codes. Instead of using a "\x" we simply use a "\u". Here is what it looks like:

CComBSTR size(L"\u00D80.15");

Breaking it down:

1. The "L" is to specify that this is Unicode.
2. The "\u" is to specify Unicode characters in literal strings
3. And as we saw as the answer to the first question, the "00D8" (thats ZeroZeroD8) is the PHI symbol
4. The trailing 0.15 is simply a size that SolidWorks Hole could have
5. BUT unlike Extended ASCII we can specify the non-Unicode portions of the string literal, using regular characters i.e. the "0.15" part.

I guess we learn something new everyday.

So do you use Unicode characters in your literal strings often? What method do you use to find the right code? Let me know.

NOTE:
IF YOU CAN'T SEE THE PHI SYMBOL ITSELF AT THE SPECIFIED LOCATION THEN YOUR BROWSER DOESN'T UNDERSTAND UNICODE CHARACTERS. TO FIX THIS PROBLEM GET A BETTER BROWSER.

SolidWorks Hole Size and Extended ASCII codes

If you have tried to create a WizardHole of type "Simple Wizard Hole" using C++ API (not .NET but native C++) then you surely have run into this problem: "How to specify the size of the hole?"

SolidWorks needs the "PHI" symbol in Hole Size

SolidWorks' new FeatureManager::HoleWizard3 API fixes a problem we (colleagues of mine from the company I work for and I) have noticed in previous versions of the WizardHole API (ping me if you want details on that problem, but not relevant to this post, so am not providing details here). But the new API requires you to specify the size of the WizardHole in string literal format (or BSTR or CComBSTR). Typically this is not a problem but for the case of the "Simple Wizard Hole" SolidWorks expects the "diameter symol" to be input as part of the size if the "Standard" selected is "ANSI Metric".

Using Extended ASCII Table
So the API call looks something like this:

featmgr->HoleWizard3(eHoleType, eHoleStd, fastenerType, size, endCond, dRadius*2.0, dDepth, values[0], values[1], values[2], values[3], values[4], values[5], values[6], values[7], values[8], values[9], values[10], values[11], threadclass, FALSE, TRUE, TRUE, TRUE, TRUE, FALSE, &hole);

Ignore the other parameters for now and focus on the highlighted "size" parameter. To specify a size of "0.15mm" for "ANSI Metric" you would need to prepend the "phi" symbol to "0.15mm". How would you do this? Well you use extended ASCII codes, of course. Don't remember your extended ASCII codes? Well you could Google it, but this link (http://www.asciitable.com/) should suffice. The "size" string value should look something like this (for size 0.15):

CComBSTR size(L"\x237\x0\x46\x1\x5");

NOTE:

• I use a CComBSTR so that I don't have to free any BSTR manually.
• To specify an ASCII character in a string literal in C++ you have to prepend the ASCII code with "\x". Once you start specifying an ASCII character in the string literal, specify all characters in ASCII, else you will get compile or worse, runtime errors.
• If you omit the "L" in front of the string literal you will get a C2022 compile error (in Visual C++ 2005 at least).
• The ANSI code of \x237 is the diameter (phi) symbol. The ANSI code \x46 is the "." in 0.15. The rest are the Dec values (from the link provided) for "0", "1" and "5".

Conclusion

So how long has it been since you used the extended ASCII table? Its been so long for me, I don't even remember when I last used them. Glad I remembered how to!

"Google's new look" is actually "Jazz"

If you read my previous post (http://ossandcad.blogspot.com/2010/04/googles-new-look.html) and found it "new" then I guess we both are late to the game. Search Engine Land already reported this new interface back in November. Thanks to the blog "Google Operating System" for the link.

I promise, next time I will only post relevant (to my blog that is) articles.

Google's new look

Sorry if this post is not relevant to my regular topics but I just couldn't resist.

Is this Google's new look? Or is this some experiment that they are running that I am seeing?

On a more related note (to my blog that is) I am currently updating a project for a fixed backend DLL for the Pantheios logger (http://www.pantheios.org) that I will upload to my Google Code project soon (i.e. at http://ossandcad.googlecode.com). Will post about that as soon as possible.

Update April 9 2010: I am currently in New Jersey and don't see the modified Google search page (that I saw from Redmond). So obviously no dramatic changes by Google. Probably just some experiment that they are running that "I" happen to be a "part" of.