There are no details, in the New Scientist Tech article, about the interface of the AI program and the video game. I suspect some internal interface to the game console. However, a set-up that actually had an independent and external "player" would be quite an achievement. Besides the internal strategies, this external agent (robot?) would need visual recognition to view and interpret the current status of the game from the screen. Then, there would need to be the computations required to control the arm operating the joystick and buttons based on the visual input and the internal strategy routines. By my count, this is at least three cores' worth of processing.

There are thousands of uses for autonomous agents that can take in visual data, interpret their surrounding environment, and then use learned strategies to navigate and complete assigned tasks. Robotic cars driving around the dessert or through town are flashy demonstrations, but are they biting off too much all at once? Maybe navigating through a smaller, more controlled environment--like a maze inhabited by fruit and pesky ghosts that chase you--might be a more manageable start to unlock the methods for bigger endeavors.

AppStream provides application streaming for efficient distribution of applications to systems in the enterprise. It facilities a centralized process for licensing, managing and updating the deployment of application on demand. Users can use any machine, login, and instantly have access to all the applications that are available to them.

AppStream uses AMT heartbeat detection to identify systems state as well as third party data store to manage and track licensees and data on application availability to user.
With most licensing models it is difficult to know fill license state when some machine are powered down. When the machine is off it is an empty spot on the network.

AppStream's IDF demonstration allows for a console view to read the Third Party Data Store from AMT and gives the user application list on the machine. If a license is unused it can be transferred even if the machine is off. On wake up it reads the client can read the Third Party Data Store and make update to the system based on availability and utilization of licensing. This increases the accountability and efficient utilization of available application licenses.

AppStream can also utilize virtualization to a managed layer that is controlled through a filter driver. Multiple application versions can be run on the same system through virtualization to allow for coexisting multiple versions of the same dll on the same system. Read more about AppStream at http://www.appstream.com/

The Boost installer created Python-related subdirectories on my system, but a search for a boost_python.dll file returned no results. So, there was work to do. First I had to install Python itself, since I didn't yet have it on my quad-core Windows system. That was, as expected, straightforward, using the Windows installer that's available on the Python.org home page. The version I installed is Python 2.5.1.

Boost.Python build and test

The "Boost.Python Build and Test HOWTO" provides instructions for getting Boost.Python up and running. First I had to have bjam, the Boost build driver. This is available in the downloads tab of the Boost project on Sourceforge.net. I selected the prebuilt version 3.1.16 for Windows. However, I soon realized that in my original Boost install included bjam.exe, stored in my c:\Program Files\boost\boost_1_34_1\bin directory, so the download from Sourceforge was unneeded.

The next step is to navigate (using my Visual Studio command prompt) into the

libs\python\example\quickstart

directory beneath the main directory where I installed Boost. Once there, I executed this command:

bjam toolset=msvc --verbose-test test

The result was a very long chain of messages telling me that a lot of code was being compiled, the bulk of it related to Python. In many places the message "No errors detected" appeared, and I saw no indication in the output that anything had failed. So, according to Section 3.3 in the Boost.Python HOWTO document ("3.3 In Case Everything Seemed to Work") it was time for me to:

Rejoice! If you're new to Boost.Python, at this point it might be a good idea to ignore build issues for a while and concentrate on learning the library by going through the tutorial and perhaps some of the reference documentation, trying out what you've learned about the API by modifying the quickstart project.

The resulting files

This sounded fine, but first I wanted to take a look at what all those compile operations produced. The only new file in my current working directory (libs\python\example\quickstart) was test_extending.pyc. I launched a UWIN shell and used the Unix file command to see what kind of file this was:

$ file test_extending.pyc
test_extending.pyc:   Compiled Python File

That makes sense! There was also a new bin subdirectory, which contained the following three directories:

msvc8.0
test_embed.test
test_ext.test

The msvc8.0 directory looks like a Visual C++ build directory: it has a debug subdirectory, which has a threading-multi subdirectory, which includes a large set of embedding.* files of various types (including *.obj, *.pdb, *.lib, *.exp, and more).

The test_embed.test and test_ext.test directories each have their own msvc8.0 subdirectory, and each msvc8.0 subdirectory has a debug subdirectory with a threading-multi subdirectory. But in these cases, the threading-multi directories each have just three files. In the case of the test_ext.test directory tree, the three files in threading-multi are:

test_ext
test_ext.output
test_ext.test

These files are identified by the Unix file command as being "dos command script" files, which means we can look at them in a text editor. When you do this, the files certainly don't look like "dos command script" files. test_ext looks like a log file for some of the testing that occurred when I executed the bjam statement to build Boost.Python. test_ext.output is exactly the same as test_ext. test_ext.test is a single line: passed.

Conclusion

At this point, it looks like I've got a working Boost.Python system. Now I just need to learn how to use what I've got to create the Python/TBB application that is the objective of this exercise. With some programming luck, I'll be able to fully explain how to accomplish that in my next post.

Kevin Farnham, O'Reilly Media, TBB Open Source Community, Freenode IRC #tbb, TBB Mailing Lists

Download TBB