Cross compilation and string issues

Trying to keep the program I am currently working on up-to-date both on my WinXP box and on a Mac, I run into some cross-compilation pitfalls. While the project builds without warnings in vs2005, it seems that gcc on Mac has a lot to complain about.

First of all some deprecated headers apparently used by the macports VTK I'm using:

In file included from /usr/include/c++/4.0.0/backward/strstream:51,
             from
../../../../opt/local/var/macports/software/vtk-devel/5.4.0_3+boost+cocoa+darwin_9+data+doc+examples+java+py26+shared+tcl+testing+wrap/opt/local/include/vtk-5.4/vtkIOStream.h:112,
             from
../../../../opt/local/var/macports/software/vtk-devel/5.4.0_3+boost+cocoa+darwin_9+data+doc+examples+java+py26+shared+tcl+testing+wrap/opt/local/include/vtk-5.4/vtkSystemIncludes.h:40,
             from
../../../../opt/local/var/macports/software/vtk-devel/5.4.0_3+boost+cocoa+darwin_9+data+doc+examples+java+py26+shared+tcl+testing+wrap/opt/local/include/vtk-5.4/vtkIndent.h:24,
             from
../../../../opt/local/var/macports/software/vtk-devel/5.4.0_3+boost+cocoa+darwin_9+data+doc+examples+java+py26+shared+tcl+testing+wrap/opt/local/include/vtk-5.4/vtkObjectBase.h:43,
             from
../../../../opt/local/var/macports/software/vtk-devel/5.4.0_3+boost+cocoa+darwin_9+data+doc+examples+java+py26+shared+tcl+testing+wrap/opt/local/include/vtk-5.4/vtkObject.h:41,
             from
../../../../opt/local/var/macports/software/vtk-devel/5.4.0_3+boost+cocoa+darwin_9+data+doc+examples+java+py26+shared+tcl+testing+wrap/opt/local/include/vtk-5.4/vtkAlgorithm.h:32,
             from
../../../../opt/local/var/macports/software/vtk-devel/5.4.0_3+boost+cocoa+darwin_9+data+doc+examples+java+py26+shared+tcl+testing+wrap/opt/local/include/vtk-5.4/vtkPolyDataAlgorithm.h:37,
             from
../../../../opt/local/var/macports/software/vtk-devel/5.4.0_3+boost+cocoa+darwin_9+data+doc+examples+java+py26+shared+tcl+testing+wrap/opt/local/include/vtk-5.4/vtkCubeSource.h:24,
             from CamVtkView.h:14,
/usr/include/c++/4.0.0/backward/backward_warning.h:32:2: warning:
#warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section
17.4.1.2 of the C++ standard. Examples include substituting the 
header for the  header for C++ includes, or  instead of
the deprecated header . To disable this warning use
-Wno-deprecated.

But other warnings allowed me to spot some bug of my own producing:

CamFrame.cpp:927: warning: cannot pass objects of non-POD type 'class
wxString' through '...'; call will abort at runtime

the line was :

curImg.sprintf("%s%04u.vtk", _vtkRecPrefix, m_nFrmRead);

while what I intended to do was:

curImg.Printf(wxT("%s%04u.vtk"), _vtkRecPrefix, m_nFrmRead);

And I found a link which summarizes well wxString usage:
http://wiki.wxwidgets.org/Converting_everything_to_and_from_wxString

Easy rotation with Eigen quaternions

Currently working on improving an alignment software for time-of-flight depth maps, I have to say I find the functions offered by Eigen quite useful.
Considering the two points clouds below (rendered with VTK), the first step to align them is to rotate them correctly.
















For this task, I use a simple RANSAC to find the largest plane in the point cloud. Then, having the plane normal vector nVec3, finding the rotation matrix mat that will align this plane with the Z-axis is 2 Eigen calls away :

Eigen::Vector3d nVecZ; nVecZ.UnitZ();
Eigen::Quaterniond qz; qz.setFromTwoVectors(nVec3, nVecZ);
Eigen::Matrix3d mat = qz.toRotationMatrix();

And here is the result for the dataset above:



That's 2 rotation DoF taken care of. Imposing the matched planes to have the same distance to origin takes care of one translation DoF. One rotation and 2 translations to go ;-)

wxEventHandler function do not support overloading

After some refactoring of some code I wrote to set the visibility and color of VTK objects with GUI controls from wxWidgets, I had two overloaded functions :

/* acting on visVTK checkbox*/
void MainWnd::SetVisVtk(wxCommandEvent& event)
{
SetVisVtk(_visVtk, m_camFrm,0);
SetVisVtk(_visBGVtk, m_camFrm,1);
SetVisVtk(_visFGVtk, m_camFrm,2);
SetVisVtk(_visSegmVtk, m_camFrm,3);
_vtkWin->Render();
}
/* acting on visVTK checkbox*/
void MainWnd::SetVisVtk(std::vector visChkBox, std::vector camFrm, int idx)
{
int i = 0;
std::vector::iterator itCtrl;
std::vector::iterator itCam;
for ( itCtrl = visChkBox.begin(), itCam = camFrm.begin();
itCtrl != visChkBox.end() , itCam != camFrm.end();
itCtrl++, itCam++, i++ )
{
if(!_vtkWin){return;};
(*itCam)->hideDataActVtk( !((*itCtrl)->IsChecked()) , idx);
}
}

The code compiled and ran fine on my windows box, but trying to compile on Mac revealed the error. Renaming the worker function to avoid overloading allowed a succesful compilation.

/* acting on visVTK checkbox*/
void MainWnd::SetVisVtk(wxCommandEvent& event)
{
SetVisVtkIdx(_visVtk, m_camFrm,0);
SetVisVtkIdx(_visBGVtk, m_camFrm,1);
SetVisVtkIdx(_visFGVtk, m_camFrm,2);
SetVisVtkIdx(_visSegmVtk, m_camFrm,3);
_vtkWin->Render();
}
/* acting on visVTK checkbox*/
void MainWnd::SetVisVtkIdx(std::vector visChkBox, std::vector camFrm, int idx)
{
int i = 0;
std::vector::iterator itCtrl;
std::vector::iterator itCam;
for ( itCtrl = visChkBox.begin(), itCam = camFrm.begin();
itCtrl != visChkBox.end() , itCam != camFrm.end();
itCtrl++, itCam++, i++ )
{
if(!_vtkWin){return;};
(*itCam)->hideDataActVtk( !((*itCtrl)->IsChecked()) , idx);
}
}

Of course this should have been obvious from the start, but this is why testing on multiple platform is such a pain. The faulty code compiled flawlessly in vs2005.

Mercurial on Mac - UTF-8 locale problems

The Eigen project recently switched to Mercurial. After installing the Macports version of mercurial, it wouldn't work apparently due to locale problems. The solution from this blog post worked for me :

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Thanks Lothar. It's really good when the first hit from a google search is spot on. Now I should get back to my own code and build problems.

SVN checkout from local repository

Since my personal repository is hosted on a win server at my university, I use rsync to copy the repository locally on macs. This avoids the hassle of trying to figure out how to use a smb URL with svn.

During the process of moving to a new machine, I copied the repository on this machine, and tried to checkout :

muredubo$ svn co /Users/muredubo/rsynRep/ /Users/muredubo/svnSandBox/

svn: '/Users/muredubo/rsynRep' does not appear to be a URL

What I had just forgotten is that even a local repository must be accessed as a URL. This means using file:/// with the critical triple slash (I had searched for it long ago, and can't remenber now who I am to thank for this trick). The command:

muredubo$ svn co file:///Users/muredubo/rsynRep/ /Users/muredubo/svnSandBox/

created my sandbox without a glitch.

New install on MBP

Since I inherited an orphan MacBookPro in our lab, I decided to use it to test my cross platform builds. But this is not so straightforward. Prior to testing, I need to put some software / libraries on it.

So far :

• apple system updates
• xmarks for safari
• firefox 3.0.10
• quick locale switcher
  
• dowload statusbar
  
• flagfox
  
• xcode 3.1
• macports 1.7.1
• qt4-mac-devel from macports (took 4 hours to build (counting dependencies ^^))
• cisco AnyConnect ( EPFL VPN )
• mactex 2008
• smultron
• wxWidgets 2.8.10 from macports
• macports python25
• macports python26
• VTK from macports with boost and wrap variants (shared, examples and data variants are default)
• premake

Todo:

• Enthought Python
• code-blocks
• many more that I forget

Edit:

found a similar blog posting with nice list of apps: http://blog.hyperjeff.net/?p=148. I'll have to take a look at the python distros used here.

Opening multiple TexnicCenter instances

On windows, I like the Texniccenter LaTeX frontend. In my opinion, it is a very good tool for handling large Latex projects. One feature I really appreciate is the document structure tree which makes navigation in the LaTeX source much easier. One issue I had is that if you open a new project, it replaces the project in the open instance (at least in the version I use: 1.0 RC1).
Fortunately, there is a trick : if you open the main tex file, with same name as the project, Texniccenter loads a new instance, and then asks if it should load the project. This allows to have multiple instances of Texniccenter. I use this a lot when writing my thesis, to copy/paste the code for figures / tables that were published in articles I wrote.