A week ago, I started my cycling to work chronicles. Then Peter reminded me about RunKeeper. So, I have moved my cycling logs to my profile at RunKeeper: http://runkeeper.com/user/mloskot/. It is much more convenient than posting it here.
Update: Cycling to work moved to RunKeeper
By the way of trying to figure out how to make tests building faster? (I will post about it later), I have learned some interesting practices regarding Boost testing in general. Especially, Robert Ramey shared his best practices, worth to look at really. New release of Boost will be released next week, so I’m testing Boost.Geometry library and it is a good opportunity to apply some of Robert’s rules.
I’m testing against “known good” components – the next release branch.
How to run tests of current development line of a library (a Boost library, e.g. Boost.Geometry) against Boost release branch? Assuming all the library development happens in Boost trunk, let’s say in ${DEV}/boost/_svn/trunk where ${DEV} is your base workshop location, do this:
mkdir -p ${DEV}/boost/_svn/branches/release
cd ${DEV}/boost/_svn/branches/release
svn co https://svn.boost.org/svn/boost/branches/release/ .
${DEV}/boost/_svn/branches/release
cd tools/build/v2
# On Windows, run bootstrap.bat
./bootstrap.sh
# On Windows, I use C:\usr as prefix for my Boost installation
./b2 --prefix=/usr/local install
# Note, this command will also install b2 utility in ${prefix}/bin
svn switch https://svn.boost.org/svn/boost/trunk/boost/geometry boost/geometry svn switch https://svn.boost.org/svn/boost/trunk/libs/geometry libs/geometry
export BGLOG=boost-geometry-test.log date > $BGLOG & b2 >> $BGLOG 2<&1 & date >> $BGLOG # On Windows, I run this with logging this way: set BGLOG=%CD%\boost-geometry-test.log dateu.exe > %BGLOG% & b2 >> %BGLOG% 2<&1 & dateu.exe >> %BGLOG%
Note, the dateu.exe is renamed Unix utility date.exe installed from GnuWin32 packages. I just like it.
Inspect the log file for test failures, for example by quick check of number of passed tests:
$ grep "\*passed\*" boost-geometry-test.log | wc -l 111
That’s it.
Try this out – it will help a lot.
Update: Cycling to work moved to RunKeeper
New year, new challenges, new ideas. My new idea is to start logging cycling commuter chronicles and perhaps similar log for climbing, and running too if my weak strong will allows. Apparently, I have too much time up on my sleeves. Anyway, I’m going to post rather short log messages than detailed blog posts (if Twitter allowed ~300 characters, I’d probably use Twitter).
I have been cycling to work since I got my first bicycle here in London. A lazy weekend during spring 2010, I made a trip to Brick Lane where I spent 90 quid, and a lot more hopes I hadn’t been buying from a thieve, to get my very first fixi. (If anyone in London used to have bright green fixi (though I bought it as black) with white handlebars and black saddle (photo) and it was stolen, then let me know :-) .) I got my bicycle and started regular commute from N1 to WC2R.
Long story short, whenever I have to struggle through the crowds to get into the lifts in Covent Garden Underground Station, I honestly suffer. Cycling is simply great. The only disadvantage is that I no longer have 40 minutes per day to read a book.
Kudos to folks from CycleStreets for the great service useful in optimising cycling routes.
Tip: every time you approach a minicab, imagine you are cycling on streets of one of the large cities in the far east and apply no trust rule whatsoever.
I have moved mailing list of the Boost.Geometry library from server at OSGeo to Boost mailing list server. All existing subscribers and archives have been moved to the new server.
The new list is available at geometry at lists dot boost dot org. It is also mirrored at Nabble as Boost.Geometry.
The old ggl at lists dot osgeo dot org will be wiped out soon.
If anyone experiences any problems with the new geometry at lists.boost.org, please contact me directly.
Big thanks to the OSGeo Foundation for hosting the ggl mailing list and thanks to Boost admins for help with the new server.
A few days ago I submitted patch with small fixes for Boost.Build to support Visual Studio 11 toolset. The patch has been accepted and committed to the current trunk in Boost repo. Thanks to Volodya for reviewing the patch.
I have been looking for easy and quick solution to mirror Subversion repositories in Git at GitHub. With bit of reading and testing, I came up with some quite usable workflow. But, most likely due to my lack of Git fu, I wasn’t happy with it. Especially, could not find how to update Git mirrors from various locations and computers, also to allow others to do that.
Lately, I have found a tool written in Ruby by Eloy Durán. It is git-svn-mirror – a command-line tool that automates the task of creating a Git mirror for a SVN repository, and keeping it up-to-date. I installed Eloy’s tool from Ruby gems and played with it for a while. I really liked it.
I skimmed the Ruby code of git-svn-mirror and found out it makes use of bare repositories in Git. A Git bare repository stores just the contents of the .git directory, without any files checked out around it. Long story short, this script does almost exactly what I need and if there is something it does not do, then I can add it.
I have never written a single line of code in Ruby and I don’t feel like I need to learn it now. So, I decided to port git-svn-mirror to Python. I have just pushed pygit-svn-mirror 0.1 based on git-svn-mirror 0.1 to the repository at GitHub. I have tried to follow command line interface and overall code structure of the original version in Ruby. I have also preserved the original license and Eloy’s copyright.
There is README.md file included with detailed guide on how to use the pygit-svn-mirror. Basically, there are two commands: init and update. For each command, --help option will display required and supported arguments.
For example, creating mirror of Subversion repository of PROJ.4 project at GitHub involves the following commands:
mkdir /path/to/proj4/mirror cd /path/to/proj4/mirror git-svn-mirror.py init \ --from=https://svn.osgeo.org/metacrs/proj/ \ --to=git@github.com:<USRNAME>/proj.4.git
and to update the mirror from its workbench directory:
cd /path/to/proj4/mirror git-svn-mirror.py update
or from any folder but with workbench location pointed explicitly:
git-svn-mirror.py update -w /path/to/proj4/mirror
Feedback, bug reports and patches highly appreciated.
Finally, big thanks to Eloy Durán for the original git-svn-mirror written in Ruby.