Hi,

I have uploaded b5 binaries for MacOSX. They are built against subversion 1.6.6.

The binaries are available at http://subcommander.tigris.org.

Hi,

I have updated the b5 Windows Installer to fix the startup problems with the “The application failed to initialize properly (0xc0150002)” error message.

Unfortunately my binaries were linked against the release AND the debug run time. Which is a really bad idea.

The new installer is online at http://subcommander.tigris.org.

Thanks for reporting the startup issue :-)

Hi,

I have updated the the source archive for b5 to b5 patch 1 (version numbering gets crazy now.. :-). It fixes a couple of build issues for gcc newer than 4.0. I added a few additional #includes and fixed an #include case error.

It is online at http://subcommander.tigris.org.

Thanks to everyone for reporting the build issues :-)

Hi,

the source archive for b5 is now online at http://subcommander.tigris.org.

Hi,

finally a new Subcommander beta (b5) release is available :-) Currently only for Windows built against subversion 1.6.5. The source archive and MacOSX binaries will follow.

Download it from http://subcommander.tigris.org

Surprisingly there is a little bit progress.. :-)

I’m temporarily switching back to Qt 4.4 until I finish my new custom QAbstractItemModel  code. That allows me to create a new beta (5) based on subversion 1.6.5.

It won’t include all things planned for b5 but there are still a few improvements. I will play with it a couple of days at work and hope to release it next week.

I also started to play with the latest mingw. It is not as easy as I would like to build all the libraries Subcommander depends on.  So far I can build apr, apr-util and openssl. openssl worked out of the box. apr & apr-util needed a few libtool tweaks. So there is still some work ahead to build Subcommander on Windows with gcc and friends.

But I think it is worth the effort. My goal is to use the configure/make build on all platforms so I have to maintain only a single build environment.

I can then also drop Visual Studio on Windows and move to QtCreator as IDE on MacOSX and Windows. After playing with it a couple of days on the subversion code I’m quite satisfied with it.

I like it better than XCode or Visual Studio (with the exception of the debugger) although it is still quite simple. It can switch very reliable between declaration and implementation. Something where Visual Studio is really weak… ;)

Hi,

It looks like I’m currently (currently!?) losing a bit track of things in Subcommander development… :-(

I tried to upgrade from Qt 4.4 to Qt 4.5. Bam, a couple of (my few) tests for the custom QAbstractItemModel (which is the base for the working copy display) don’t run anymore. The working copy view now crashes randomly. Great. Unfortunately I have so few test for the model, that I’m sure I will break other things trying to fix the broken tests. I’ve already wasted a lot of time debugging that code in the past with all the QModelIndex objects you can’t look into. I don’t want to waste more time on this….

So I took another step back (moving the proxy model into the TODO list again) and started another round on the QAbstractItemModel stuff. I’m now trying to TDD the model into existence. This is going a bit slow because I ‘m still a beginner at TDD. But I have about 20 tests around the new custom model implementation now and slowly it begins to do something.. :)

So far I always used cppunit to write tests. I think I’m going to drop it in favor of gtest/gmock. Allthough gmock does work together with cppunit, it is simpler and faster for me to create new tests with gtest instead of cppunit. With cppunit I always had a header and a implementation file. With gtest I just need an implementation file. This is a lot easier. Maybe this would work with cppunit too, but since gmock includes gtest anyway I have one dependency less to care for (just gmock instead of cppunit & gmock).

Another big issue that keeps me from making real progress is the maintainability of 3 build environments. Another time waster. I’m considering to move to qmake as the build environment and to drop the hand made configure/XCode/Visual Studio builds.

I also wonder if it wouldn’t be a lot easier to drop Visual Studio completely and use MinGW to build Subcommander on Windows. That way I would more or less use the same build environment (gcc and friends) on all the three platforms (Mac/Linux/Windows). This should improve maintainability as well.

So I’m still working on Subcommander, but I can’t tell when there will be a new release… but maybe I’m the only Subcommander  user anyway… ;)

Part I redone, getting started using Google Mock.

A while ago I started to build a custom QAbstractProxyModel for subcommanders working copy view in creating a custom QAbstractProxyModel.

A few weeks ago I red about Google Mock, a mock framework for C++ and I planned to try it. There is a nice, simple and short introduction: Google Mock for Dummies.

In the last creating a custom QAbstractProxyModel article I created a simple mock from scratch that is simple enough for a first try. So the goal is to simplify that. If it doesn’t simplify that code, why would I want to use a mock framework? :)

Here is the original hand made mock class and test. Constructor and destructor connect and disconnect the signals from src (that is the proxy model) to the slots and verify is used to verify the results.

class SignalTarget : public QObject
{
  Q_OBJECT;

public:
  SignalTarget( QObject* src );
  ~SignalTarget();

  virtual void verify();

public slots:
  void modelAboutToBeReset();
  void modelReset();

private:
  QObject* _src;

protected:
  int  _hitModelAboutToBeReset;
  int  _hitModelReset;
};

To check that the tested class (the proxy model) properly emits the signals, I subclassed SignalTarget to ASSERTS that the slots were called as many times as they should. Here is the test code:

void WcViewItemProxyModelTest::emitsModelResetSignals()
{
  class Target : public SignalTarget {
  public:
    Target( QObject* src ) : SignalTarget(src) {
    }

    void verify() {
      CPPUNIT_ASSERT_EQUAL( 1, _hitModelAboutToBeReset );
      CPPUNIT_ASSERT_EQUAL( 1, _hitModelReset );
    }
  };

  Target target(_proxy);
  _proxy->reset();
  target.verify();
}

Using Google Mock this gets a bit simpler. The basic mock class get a bit shorter because I no longer need the verify method and the int counters. Google Mock will take care of it:

class SignalTarget : public QObject
{
  Q_OBJECT; 

public:
  SignalTarget( QObject* src );
  ~SignalTarget(); 

public slots:
  void modelAboutToBeReset();
  void modelReset(); 

private:
  QObject* _src;
};

To a create the actual mock class I derive a new class from SignalTarget and tell it to mock the ...Reset() methods by using the MOCK_METHODx macro:

class MockSignal : SignalTarget
{
public:
  MockSignal(QObject* target) : SignalTarget(target) {
  }

  MOCK_METHOD0(modelAboutToBeReset, void());
  MOCK_METHOD0(modelReset, void());
};

Finally I create the mock object in the test and set the expectations (the methods should be called 1 time) by using the EXPECT_CALL macro and calling Times with the expected number of calls. This is a lot simpler than creating the mock class in the original code to set up the expectations in the verify() method.

void WcViewItemProxyModelTest::emitsModelResetSignals()
{
  MockSignal mtarget(_proxy);
  EXPECT_CALL(mtarget, modelAboutToBeReset()).Times(1);
  EXPECT_CALL(mtarget, modelReset()).Times(1);

  _model->reset();
}

All in all it was quite easy to get started with Google Mock. Although I used it only on a very simple example I think it is a nice help for writing tests. If it fits the thing you want to test it can reduce the code noise required to set up the test.

If you write tests in c++, check it out.. :-)

Building Qt (4.5.1) on Windows in a Fusion virtual machine with limited disk space is an adventure… :)  The build eats endless Gigabytes. Unfortunately the configure.exe is a bit limited and doesn’t allow to disable building of the demos and the examples.

After getting some hints and ideas by googling I did the following steps:

1. I did run configure.exe with the -fast option. According to configure.exe -help, -fast only creates Makefiles for library and subdirectory targets.
2. Then I entered the src directory (that is the source directory for the libraries) and called nmake. That way qt builds only the libraries without the demos or examples.
3. After  the library build finished, I called nmake clean in the src directory. make clean removes all temporary stuff in the src directory (like the obj files) but NOT the finished libraries and binaries from the top level bin and lib directory.

If you don’t plan to rebuild the libraries the third step frees up about 5 Gigabytes(!) of disk space. I wouldn’t recommend cleaning the src directory if rebuilding is required though. Building the libraries takes several hours…

Hi,

I am still around and plan to work more on Subcommander again. :-)

Today I tried to understand a long standing annoying build issue on MacOSX: msgmerge (for me always) fails on MacOSX with a “no such file or directory” error on a file that definitely exists. msgmerge is part of the gettext package which is used to add multiple language support to Subcommander.

Here is the failing command line:

> msgmerge de.po Subcommander.pot
> msgmerge: `./de.po': No such file or directory
 

The quick fix is to disable backups with --backup=off.

The reason why it fails is that the backup code tries to not simply copy the file but also the file permissions and acl information.

Copying the acl information seems to be the problem. If the po file doesn’t have any acl information, copying the acl information fails. After setting some dummy acl info it works. Interesting enough it seems to work also after removing the acl info again (see man chown to read about setting and deleting acl information).

In copy_acl the following code returns ENOENT if the file has no acl info:

int copy_acl(...):
{
  ...
  acl = acl_get_fd (source_desc);
  ...
 

The man page of ac_get_fd says for ENOENT: The named object does not exist, or the path_p argument points to an empty string.

This doesn’t explain anything, at least to me, so I am not sure if this is a bug in MacOSX or in msgmerges copy code…