Python sys.stdout redirection in C++

Lately, I have been embedding Python interpreter and implementing plenty of Python extensions in C++ using plain C API provided by Python 3. One of common challenges at C/C++ level is to intercept output sent to sys.stdout or sys.stderr by Python functions like print. Python Embedding/Extending FAQ suggests common solution based on Python code:

# catcher code
import sys
class StdoutCatcher:
   def __init__(self):
      self.data = ''
   def write(self, stuff):
      self.data = self.data + stuff
catcher = StdoutCatcher()
sys.stdout = catcher

This Python code can be executed by embedded Python interpreter using PyRun_SimpleString, then the output can be accessed by fetching __main__ module attributes:

PyObject* m = PyImport_AddModule("__main__");
char const* code = "... catcher code here...";
PyRun_SimpleString(code);
PyRun_SimpleString("print(3.14)");
PyObject* catcher = PyObject_GetAttrString(m, "catcher");
PyObject* output = PyObject_GetAttrString(catcher, "data");
// get textual data contained in output

Such mix of Python and C code is neither convenient to use nor states a flexible solution. I simply don’t like this prosthesis, especially if I need to frequently switch between number output sinks.

So, I have come up with better solution which allows me to directly bind any callable C++ entity. The syntax I mean looks and feels like this:

int main()
{
    PyImport_AppendInittab("emb", emb::PyInit_emb);
    Py_Initialize();
    PyImport_ImportModule("emb");

    PyRun_SimpleString("print(\'hello to console\')");

    // here comes the ***magic***
    std::string buffer;
    {
        // switch sys.stdout to custom handler
        emb::stdout_write_type write =
            [&buffer] (std::string s) { buffer += s; };

        emb::set_stdout(write);
        PyRun_SimpleString("print(\'hello to buffer\')");
        PyRun_SimpleString("print(3.14)");
        PyRun_SimpleString("print(\'still talking to buffer\')");
        emb::reset_stdout();
    }

    PyRun_SimpleString("print(\'hello to console again\')");
    Py_Finalize();

    // output what was written to buffer object
    std::clog << buffer << std::endl;
}

This allows me to handle sys.stdout.write with C++ free function, class member function, named function objects or even anonymous functions as in the example above where I use C++11 lambda.

Complete implementation of the emb module in C/C++ using plain Python C API is available from my Python workshop at GitHub:

git clone git://github.com/mloskot/workshop.git

The complete code is enclosed in python/emb/emb.cpp file. Note, this is a minimal example to present the essential concept. In production-ready code, it certainly needs more attention around reference counting of PyObject, getting rid of global state, and so one.

Modular visualizers in Visual Studio 11

Previously, I talked about the new debugger visualizers in Visual Studio 11 (Developer Preview) based on XML. By the way, I haven’t any luck trying to figure out where does the file type .NATVIS come from.

In previous versions of the Visual Studio, all templates of debugger visualizers have to be saved in single file: %VSINSTALLDIR%\Common7\Packages\Debugger\autoexp.dat. In case one wants to extend or improve the templates definition, maintaining everything in one system-wide file is neither practical nor safe.

The visualizers in Visual Studio 11 seem to solve the maintenance hassle by allowing more modular approach. First nice feature is that custom templates can be defined without touching any of the installed Visual Studio files and can be put in %USERPROFILE%\Documents\Visual Studio 11\Visualizers. Second nice feature I’ve just discovered is that definitions of visualizers can be split into several separate .natvis files. It is especially useful if one wants to maintain visualizers grouped according to libraries (e.g. Loki, Boost, POCO).

Basically, %USERPROFILE%\Documents\Visual Studio 11\Visualizers works like a package of custom visualizers now:

vs11-user-natvis

Having the visualizers diagnostics enabled, whole process of parsing and loading .natvis files will be traced in Visual Studio 11 output window:

vs11-modular-natvis

No more copying and pasting debugger visualizers for Boost and others into big muddy autoexp.dat.

BTW, who knows where does NATVIS come from, hmm? :-)

Setting EnableNatvisDiagnostics in Visual Studio 11

Previously, I posted about the new XML-style debugger visualizers I discovered in Visual Studio 11. I mentioned that one of reasons the feature has been redesigned is to enable debugging of the visualizers templates defined in default or user-defined .natvis files. So, it looks there is something more to discover: how to actually make use of the diagnostics capability.

Unfortunately, it seems the new debugger visualizers have not been documented anywhere. At the time of writing this blog, Google reports one link about defaultvis.natvis, it is the brief post on Visual C++ forum.

Luckily, there is a short manual included as comment in header of the %ProgramFiles%\Microsoft Visual Studio 11.0\Common7\Packages\Debugger\Visualizers\defaultvis.natvis file. It says:

1) give better diagnostic reporting.
a) Set the name-value entry under the Debugger registry key: EnableNatvisDiagnostics which is a REG_DWORD to a value of 1 this will output each expression string that is evaluated under the native visualizer into the output window and is good for debugging type definition typos in .natvis files.

The first thing is to figure out where to set the EnableNatvisDiagnostics flag. The Visual Studio 11 installer does not put it into the registry. Also, there are several Debugger keys. However, a few experiments proved the flag should be set under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\Debugger:

vs11-visualizers-enable-natvis-diagnostics

Once it is set, every time Visual Studio 11 debugger is launched and use of visualized types is determined, the .natvis files are parsed and evaluated templates validated. The process is reported in the Output window:

vs11-evaluating-visualizer-1

If anything goes wrong, a type definition template is incorrect and its evaluation fails, it is also reported in the Output window:

vs11-evaluating-visualizer-2-validation

It will be a very useful feature especially when defining visualizers of complex types. Previous versions of Visual Studio used old format of templates defined in autoexp.dat file which stated its own DSL based on regular expressions, so the syntax was complex and fragile, and as Andy Pennel has confessed, not documented. (Here kudos to Avery Lee who did great job reverse-engineering the autoexp.dat syntax.)

At least, this time folks get the XML Schema for the Visual Studio debugger visualizers.

Debugger visualizers in Visual Sudio 11 Developer Preview

Visual Studio 11 Developer Preview introduces new style debugger visualizers. The autoexp.dat definition of templates in previous versions of the Visual Studio debugger is being replaced with new style definitions based on XML and stored in defaultvis.natvis file.

Microsoft explains the motivation behind redesigning the native type visualization mechanism is to give better diagnostic reporting (visualizer expressions can be now evaluated and displayed in the output window to help debugging .natvis file), provide XSD schema defining type definition, support of multiple files for type definition: system-wide in %ProgramFiles%\Microsoft Visual Studio 11.0\Common7\Packages\Debugger\Visualizers\defaultvis.natvis and user-defined in %USERPROFILE%\My Documents\Visual Studio Dev11\Visualizers\xxx.natvis.

It sounds really good and has a great usability potential for programmers who uses C++ generative programming capabilities, defines complex C++ types, heavily uses C++ Standard Library and Boost C++ Libraries.

Here is example of new style visualizer defined in XML copied from the defaultvis.natvis:

  <!--std::unique_ptr from <memory>-->
  <Type Name="std::unique_ptr<*>">
    <DisplayString Condition="_Myptr == 0">empty</DisplayString>
    <DisplayString>unique_ptr {*_Myptr}</DisplayString>
    <Expand>
      <Item Name="[ptr]" Condition="_Myptr != 0">_Myptr</Item>
    </Expand>
  </Type>

For most types from C++ Standard Library and Windows SDK, the new visualizers work very well. However, the currently available Visual Studio 11 Developer Preview (Version 11.0.40825.2 PREREL) is shipped with incorrect definitions in the defaultvis.natvis. The C++TR1 definitions introduced in Visual Studio 2008 are only forwarded (aliased) from std:tr1:: to std:: in Visual Studio 2010. In Visual Studio 11, they have completely moved from std::tr1:: to std:: to align with C++11 standard. But, the new visualizers in defaultvis.natvis define templates are still referring to the C++11 types in std::tr1:: namespace.

This prevents the correct visualization for types like std::shared_ptr:

vs11-visualizers-broken-2

There is an easy workaround possible:

  1. Make private copy of defaultvis.natvis in %USERPROFILE%\My Documents\Visual Studio Dev11\Visualizers\xxx.natvis where xxx is your preferred name.
  2. Open xxx.natvis in a text editor.
  3. Find std::tr1:: and replace with std::.
  4. Save the changes and relaunch the Visual Studio 11.
  5. You should see objects of the C++11 types correctly visualized.

vs11-visualizers-fixed-3

I have reported this issue to Microsoft Connect in Incorrect Type Name references in defaultvis.natvis visualizers for standard library ticket.

New SOCI Project Leader needed

Maciej Sobczak, current leader of SOCI project has just announced on soci-users mailing list that he is looking for a volunteer willing to take over the project leadership. For someone, who would like to take over the project management responsibilities and has a good understanding of the subject as well as a solid vision of what to do with the project in the future.

SOCI is a database access library for C++ that makes the illusion of embedding SQL queries in the regular C++ code, staying entirely within the Standard C++.

Building Boost with Visual Studio 11 Developer Preview

Yesterday, I installed Visual Studio 11 Developer Preview. The new release is available for free and is usable for free until June 2012, so it’s a great opportunity to try and learn what Microsoft has to offer for C++ programmers. And, it looks it offers a lot, including SCARY features.

The first test I usually do when it comes to test a new C++ toolset is to build Boost C++ Libraries using mainstream development sources.

The Boost simply builds well. I have even configured build of Boost.Python using Python version 3.2.

There are no hacks required to make the build happen. Simply, follow Boost Getting Started on Windows, section 5.3. Or, Build Binaries From Source. Once the Boost.Build tools bootstrapped, I issued the following command:

b2 --toolset=msvc variant=debug runtime-link=shared threading=multi define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_SCL_SECURE_NO_DEPRECATE stage

Fifteen minutes later, the Boost build was ready and staged.

By the way, some time ago Christian Henning posted a quick cheat sheet of bjam commands for Visual Studio. It’s very handy.

SOCI 3.1.0 Released

It has been a very long journey since version 3.0.0 of SOCI was released. Namely, it’s been nearly three years. The RERO philosophy didn’t quite kick in somehow, but the new SOCI 3.1.0 is finally out.

The latest package can be downloaded from here http://sourceforge.net/projects/soci/ and the complete documentation is part of the package as well as available on-line at http://soci.sourceforge.net/doc/index.html. The project web page reflects the latest changes as well http://soci.sourceforge.net/.

This new release brings all the developments that took place during the last two years and that were up to now somewhat inconveniently available only from our Git repository. At the same time it also defines the snapshot and a basis for subsequent library evolution.

Here extract from the CHANGES file

Version 3.1.0 differs from 3.0.0 in the following ways:

  • Added Ada language binding
  • Migrated build system from GNU Autotools and Visual Studio projects to CMake
  • CMake build tested with Visual Studio, GCC and clang
  • Incorporated a compromise for naming versioned shared libraries
  • Enhanced and improved integration with Boost libraries: Boost.DateTime, Boost.Fusion, Boost.Optional, Boost.Tuple
  • Bug fixes and improvements in core and backends:
    • Added soci::values::get_properties accessor useful for composing soci::type_conversion
    • Export advanced API of backend loader from DLL
    • Added static factory registration functions for backends
    • Added get_affected_rows operation
    • Fixed thread-safety of connection pool under Windows
    • Fixed bug with dropping const qualifiers when binding to std::vector<soci::indicator>
    • Fixed bug in default initialization of an object of const backend_factory which requires user-provided default constructor (see C++03/C++0x)
    • Fixes for 64-bit builds
    • Removed redundant exchange_traits breaking ODR on LP64
    • Better ODBC support
    • Type conversion support for unsigned integer types
    • Bug ID:1971436 – incorrect rowset copy operations
    • Bug ID:2010367 – memory leak (ODBC)
    • Bug ID:2010409 – invalid memory allocation in define by position (ODBC)
    • Bug ID:2021243 – long long type support in Visual C++
    • Patch ID:2483066 – 64bit Linux and 64bit integer submitted
    • Patch ID:2809809 – Fix build with GCC 4.4
    • Patch ID:2809810 – Fix SQLite3 build with GCC 4.3
    • Patch ID:2581206 – Windows Unicode application
    • Patch ID:3058275 – install target for CMake build submitted
    • Patch ID:3069375 – use $(prefix)/lib64 on AMD64 platforms
    • Improved performance while accessing query results (MySQL)
    • Bug fixes for PROCEDURE support (MySQL)
    • Removed throw statements from mysql_rowid_backend and mysql_blob_backend destructors (MySQL)
    • Verify that prepared statements survive session::reconnect() operation (MySQL)
    • Improved support for time and date (MySQL, PostgreSQL)
    • Fixed bug with strings of length exceeding 255 characters (ODBC)
    • Improved interpretation of the connect string (Oracle)
    • Added handling of unsigned long long (Oracle, SQLite3, PostgreSQL)
    • Fixes in integral types support (PostgreSQL)
    • Support for colon-casts (PostgreSQL)
    • Added possibility for use BLOB (PostgreSQL)
    • Added support for connection property “synchronous=on|off” (SQLite3)
    • Improved BLOB data handling (SQLite3)
    • Improved boolean type support (SQLite3)
    • Session timeout support (SQLite3)
    • Improved tests clean-up (SQLite3)
    • Added missing typedef of sqlite3_destructor_type which has been defined in sqlite3.h but since 3.3.10 (see comment for reference to SQLite ticket)
  • Updated tests for various backends and SQL data types
  • Changed naming conventions and style across all the source code
  • Firebird backend removed from official release as not actively maintained. Available in the Git repository
  • Migrated from CVS to Git repository

On behalf of SOCI Team, I’d like to thank all users and contributors who actively helped us to bring the new release to the public. I have tried hard to list everyone in the AUTHORS file. If anyone has been omitted, it happened by mistake and please don’t hesitate to tell me.

Unfortunately, due to lack of active maintenance the Firebird backend has been removed. Also, the ODBC backend needs more love, especially testing. However, we welcome anyone who is interested in taking over the maintenance of the Firebird backend as well as helping us to test and improve the ODBC backend.

As the author of the CMake configuration, I’m strongly interested in any feedback and constructive critique. Please, feel free to post your comments to soci-users. Do you have any ideas for SOCI backends to other databases? Share it!

We are very excited about this release. It allows us to define the directions for future work. There is plenty of ideas to pursue.