As a long time user of Subversion, I’ve got used to use of svn info command. Since I started drifting to Git system, I’ve missed this command pretty much until I found git-info script crafted by Duane Johnson
Kudos to Duane! And, I suggest any SVN user who reincarnated as Git user to grab and try it.
I’ve started to experiment with the Intel Threading Building Blocks and hit a wall trying to run a very simple example:
#include <tbb/parallel_sort.h>
#include <cmath>
#include <vector>
using namespace tbb;
int main()
{
const int n = 100000;
std::vector<double> a(n);
for (int i = 0; i< n; i++)
{
a[i] = std::sin(double(i));
}
parallel_sort(a.begin(), a.end());
}$ g++ -O0 -g -DTBB_USE_DEBUG -o sort_vector sort_vector.cpp -ltbb $ gdb ./sort_vector (gdb) run Starting program: /home/mloskot/workshop/tbb/parallel_sort/sort_vector [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. tbb::task_group_context::init (this=0x7ffffff9c4e0) at ../../src/tbb/task.cpp:3124 3124 ../../src/tbb/task.cpp: No such file or directory. in ../../src/tbb/task.cpp (gdb) bt #0 tbb::task_group_context::init (this=0x7ffffff9c4e0) at ../../src/tbb/task.cpp:3124 #1 0x00000000004013ff in task_group_context (this=0x7ffffff9c4e0, relation_with_parent=tbb::task_group_context::bound) at /usr/include/tbb/task.h:284 #2 0x0000000000401be4 in tbb::internal::parallel_quick_sort> (begin=0x7ffffff9c6a0, end=0x7fffffffe120, comp=...) at /usr/include/tbb/parallel_sort.h:155 #3 0x0000000000401b23 in tbb::parallel_sort > (begin=0x7ffffff9c6a0, end=0x7fffffffe120, comp=...) at /usr/include/tbb/parallel_sort.h:203 #4 0x0000000000401ab3 in tbb::parallel_sort (begin=0x7ffffff9c6a0, end=0x7fffffffe120) at /usr/include/tbb/parallel_sort.h:219 #5 0x0000000000401363 in main () at sort_vector.cpp:12
It seems like a failure during initialization of worker threads pool or close to it.
I’m using fairly recent version of TBB 2.1 installed from Ubuntu 9.10 packages, but I’m suspicious this may be a problem with this particular binary version. Let’s see what Intel folks will judge parallel_sort example throws segmentation fault. Pity Microsoft PPL does not provide parallel_sort algorithm.
Update: see parallel_sort problem fixed
A few minutes ago, Bill Hoffman from Kitware posted short message to the CMake project mailing list with an interesting announce:
Kitware launched its first developer blog today with contributions from Company technical and business leaders.
The CMake build system is one of the main category of topics on the Kitware blog, so I presume it may be of interest of OSGeo Community as the CMake build system is slowly winning over more and more folks here :-)
First CMake-related post is about Deploying on Windows with DLL Manifest Issue
Another interesting post on the blog is Will Schroeder’s answer to the question Why Open Source Will Rule Scientific Computing? It’s really worth reading.
It’s an example of b***dy quick attempt to configure CMake-based build of a fairly large library written in C++ programming language. It is GEOS.
Seven. A lucky number. Arnulf’s nickname. Total number of lines (commands) of CMake script to configure build of GEOS C++ core as a static library using sources form SVN trunk:
Create trunk/CMakeLists.txt file:
project(geos)
cmake_minimum_required(VERSION 2.6)
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")
add_subdirectory(src)
Create trunk/src/CMakeLists.txt file:
include_directories(${CMAKE_SOURCE_DIR}/include)
file(GLOB_RECURSE geos_SRC ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp)
add_library(geos STATIC ${geos_SRC})
In fact, only six lines are really required. The third line in file trunk/CMakeLists.txt is optional.
mloskot@dog:~/dev/geos/_svn/trunk$ svn status ? CMakeLists.txt ? src/CMakeLists.txt mloskot@dog:~/dev/geos/_svn/trunk$ mkdir ../build mloskot@dog:~/dev/geos/_svn/trunk$ cd ../build/ mloskot@dog:~/dev/geos/_svn/build$ cmake ../trunk -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/mloskot/dev/geos/_svn/build mloskot@dog:~/dev/geos/_svn/build$ mloskot@dog:~/dev/geos/_svn/build$ make -j5 Scanning dependencies of target geos [ 0%] Building CXX object src/CMakeFiles/geos_lib.dir/operation/valid/RepeatedPointTester.cpp.o ...
and 53 seconds later my Intel Core 2 Duo 2.4GHz box announces:
[100%] Building CXX object src/CMakeFiles/geos.dir/linearref/LengthIndexOfPoint.cpp.o Linking CXX static library libgeos.a [100%] Built target geos
This build configuration is universal and cross platform, thus should work on all platforms supported by CMake.
Simply, you can not afford not use the best cross-platform build system that ever existed :-)
Bill Hoffman from Kitware gives presentation about CMake and a pack of related tools to the happiest easygoing working nation on the Earth:
It’s worth to watch if interested in CMake.
The EfficientPC company, best known as a seller of energy efficient good-looking quietly operating Linux-based laptop and desktop computers, has just announced sad news:
After many happy years of service to the Linux community, EfficientPC Limited is closing down.
The reason of this decision is interesting:
our goal of bringing Linux to the mainstream has succeeded, so we gracefully retire
Happy retirement!
Long time ago, I reported bug to Visual C++ 9.0 (Visual Studio 2008 SP1) complaining that has_trivial_destructor applied to void returns true (ID:458570). I also discussed it with folks on comp.std.c++ where, among quite different voices, Pete Becker writes:
[tr.meta.req]/8 in TR1 requires is_pod
::value to be 1. n2857 is not a standard, and implementations of previous standards are not wrong for not doing what isn’t yet required of them.
and later concludes:
Under the current standard, using the name std::is_pod requires a diagnostic. So if you want to be literal, both compilers are “wrong”. Nevertheless, neither is really “wrong”, they just implement different non-standard versions of is_pod.
So, Visual C++ might actually not be wrong. Fair enough.
Today, I got back to this issue for a while a little extending my test program to use the type traits from both, TR1 and C++0x:
#include <iostream>
#include <tr1/type_traits>
int main()
{
using std::cout; using std::endl;
cout << std::tr1::is_pod<void>::value << endl;
cout << std::tr1::has_trivial_destructor<void>::value << endl;
cout << std::is_pod<void>::value << endl;
cout << std::has_trivial_destructor<void>::value << endl;
}
and compiled it with GCC 4.4.1:
$ g++ -Wall -pedantic -std=c++0x void.cpp $ ./a.out 1 1 0 0
Now, my confusion has been raised to the power of 2. This is clearly a Polnische Wirtschaft or Czech movie or Turkish sermon…
…let’s try to ask libstdc++ folks.
You are currently browsing the archives for the linux category.
