A couple of minutes ago, Mr Carl Reed, CTO at the Open Geospatial Consortium, posted the GeoTIFF project mailing list with message that may interest hundreds of thousands of users of geospatial raster data around the world. It is thread titled GeoTIFF and the OGC. Hot!
Archive for October, 2009
OGC GeoTIFF?
Monday, October 26th, 2009como adventures with boost/cstdint.hpp
Sunday, October 25th, 2009While compiling a program that uses boost/cstdint.hpp from Boost Integer Library:
#include <iostream>
#include <boost/cstdint.hpp>
int main()
{
boost::int64_t i64 = -2;
boost::uint64_t ui64 = 2;
boost::uint64_t d = ui64 - i64;
std::cout << d << std::endl;
return 0;
}
front-end of Comeau C/C++ 4.3.10.1 compiler complains:
boost/cstdint.hpp", line 111: error: the
global scope has no "int64_t"
using ::int64_t;
^
However, if I reorder include directives:
#include <boost/cstdint.hpp>
#include <iostream>
then the program compiles well.
I believe that the order of header files should not be relevant here, but seems it is. I’ve submitted a ticket #3548 to Boost.Integer and I’m curious awaiting the diagnosis.
After this issue is fixed, I’m looking forward building the Generic Geometry Library using Comeau C/C++ compiler. This should help us to maintain high quality of standard and yet more portable C++ code.
mloskot @ boost regression tests
Sunday, October 25th, 2009I run Boost C++ Libraries regression tests for the first time today. The test driver is brilliant. It’s a single python script run.py that takes care of all aspects of regression tests run: gets build system, builds bjam (a clever make equivalent) if not available, grabs Boost source tree, builds Boost libraries, runs tests, combines tests reports to single XML files and uploads it to server in secret location. All this by single command:
python run.py --tag="trunk" --runner="mloskot-x86_64" \ --toolsets="gcc" --bjam-toolset="gcc" --bjam-options="-j4"
Then, a scheduled magic on the server crunches all uploaded reports and builds detailed summary of regression tests. My builder is called mloskot-x86_64.
That is really a user friendly infrastructure of running regression tests and it allows an average Boost user to contribute in testing.
Testing libLAS with CMake
Sunday, October 25th, 2009
As a part of CMake configuration for libLAS, I’ve enabled support CTest. It is CMake test driver program that can be used to run automated tests and perform continuous integration. I also registered libLAS at CDash testing server.
CDash aggregates, analyzes and displays the results of software testing processes submitted from clients located around the world
Check libLAS dedicated quality dashboard – registration is required it is public project and available for anonymous visitors to browse the dashboard (thanks to Julien from Kitware for quick fix).
Anyone who is would like to build libLAS using CMake and run tests can find details on the CMake article on the Wiki. I would also encourage interested users to issue make Continuous to submit test results to the dashboard.
Feedback kindly wanted!
osgeo.codepad.org
Saturday, October 24th, 2009Online compilers are another generation of collaborative debugging tools delivered to Open Source communities. The overall idea is great. Actually, I can not imagine online discussions on IRC channel without being able to paste code snippets or compilation logs.
The codepad.org provides feature called private and project pastes. Some time ago I proposed private general purpose paste service dedicated to OSGeo communities. it is hosted at osgeo.pastebin.com and people has found it useful, as I can see. Today, I registered osgeo.codepad.org – a programmers-oriented paste service. Perhaps, people will find it useful too..
Users of the World’s second best programming editor, Vim (first place taken by Emacs), can install codepad.vim plug-in and send Vim buffers as pastes directly to the codepad.org service. Kudos to Nicolas Weber for the plug-in!
I’ve taken the liberty and modified the plug-in to use the private service at osgeo.codepad.org – here is custom codepad.vim plug-in.
Compile-time unit tests
Saturday, October 24th, 2009Boost Build V2 includes testing module that provides nice features for running unit tests. A unit test run means a test builds and can be executed performing checks in run-time, however, a unit test can be also based on compilation or even linking result. Yet more surprisingly, sometimes a test is expected to not to compile and such failure is considered as success. It performs compile-time checking in design by contract.
In Generic Geometry Library, some tests use that feature of testing compilation result. For example, this way it’s possible to test the concepts in practice and to ensure that various constructs are not accepted by the library as expected by design.
For example, custom_linestring.cpp source file can be used to perform compile-time and run-time testing. If TEST_FAIL_APPEND is defined, unacceptable constructs are compiled and the compilation is expected to fail. If compiled without TEST_FAIL_APPEND defined, only acceptable code is enabled and regular run-time test performed.
Configuration of such thing is very easy with Boost Build V2. Here is Jamfile.v2 that performs the test for geometries in Generic Geometry Library using compile-fail rule:
test-suite ggl-geometries
:
[ compile-fail custom_linestring.cpp
: # requirements
<define>TEST_FAIL_APPEND
: # target name
custom_linestring_test_fail_append
]
[ run custom_linestring.cpp ]
There are among others also rules like compile, link-fail and link.
The unit tests execution is simple:
mloskot@dog:~/dev/ggl/_svn/trunk/libs/ggl/test/geometries$ bjam | grep passed **passed** bin/custom_linestring_test_fail_append.test/gcc-4.4.1/debug/custom_linestring_test_fail_append.test **passed** bin/custom_linestring.test/gcc-4.4.1/debug/custom_linestring.test


