CVCS мертв?

Было время, когда никто не слышал про бранчи. Собственно и система контроля была одна - cvs. Нет две, еще был rcs, но это помоему совсем уж дедушка систем контроля версий.

Но времена меняются очень быстро. Subversion за считанные годы просто похоронил cvs. Да и его скоро отправят на свалку истории...

Несколько дней назад упал savannah.gnu.org. Вследствии отказа RAID-массива содержимое проектных баз было безвозвратно утеряно. Последний нормальный бекап - месячной давности (sic!). Какой же у них рейд, если всеравно все рухнуло?

И вот, бедные владельцы проектов, которых угораздило хранить свои проекты в cvs/svn вынуждены по крохам восстанавливать содержимое баз (буквально с помощью сообщества).

И вот после этого подумаешь - всетаки умные люди не зря придумали DVCS? Скорее бы уже google code поднял меркуриал, я мигрирую.

Собственно для меня история проекта имеет достаточно незначительную ценность. Я просто не знаю зачем она мне может понадобиться. Но прикольно то, что с 2002 года sourceforge бережно хранит мою базу. И только.

В корпоративном плане история несомненно нужна. Хотя бы для того, чтобы выяснить - какой же идиот написал этот код?

Ценность бранчей пока еще ясна не всем, возможно по причине использования устаревших средств, которые с этими самыми бранчами не особо дружат. Я вот точно не знаю, последние версии SourceSafe научились делать бранчи? Perforce например делает вид что умеет это делать, но при этом историю теряет. То есть новый бранч - новая история. И на вопрос из предыдущего абзаца ответить уже не удается.

Кроме того не знаю как остальным - а мне кажется крайне неприличным выкладывать в базу изменения, которые точно не собираются. При этом если я переименовываю файл в Perforce, я категорически не могу больше никакое изменение в него внести, хотя собираемость проекта при этом явно нарушается.

Собственно смысл этого понятен, при переименовании файла перфорсу хочется сэкономить место в базе и связать новый файл со старым (по идентичности содержимого). Только мне то какое до этого дело? Кроме того я явно говорю ему что этот файл я синтегрировал из этого - отслеживай елыпалы.

Кроме того я привык вносить изменения понемногу, мне просто жизненно необходима собственная база, из которой я мог бы одним чейнджсетом все перенести в базу perforce. Очень хочется такую систему контроля (конечно распределенную), которая умела бы оперировать с чужеродными репозиториями, как со своими. Многого хочу?

А savannah.gnu.org конечно круто опозорился. Все срочно переходят на hg/git на других площадках.

Показать полностью...

Свернуть...

Оптимизация в gcc, факты

При обновлении своей системы наткнулся на неприятный момент, сборка любых KDE компонент начала вдруг запарываться с руганью:

checking if UIC has KDE plugins available... no

Я далек от мысли что у всех все плохо в течении двух недель (где то так у меня впервые не собралась kopete), а Gentoo мантайнеры не чешутся. Поэтому стал разбираться откуда растут ноги.

Стандартной рекоммендацией в такой ситуации считается - пересобрать qt и kde, но легче от этого не стало. Первым делом я конечно заподозрил, что возможно нестабильную kde-3.5.10 сломали, снял все маски - жужжит (c). Потом я подумал, что, возможно, мешается qt:4, снес его, благо он был мне нужен только для perforce gui, можно потерпеть чуток, но счастья опять не наступило. Не наступило счастье и после полной пересборки системы, что уже совсем непонятно, уж полная пересборка должна помочь?

Долго гуглил... Не помню уже где, увидел упоминание про оптимизацию и gcc-4.3.2, а у меня вся система собрана на -Os. Решил поставить стандартный -O2, ради эксперимента. И, о чудо, компиляция компонентов kde прошла. На этом можно было бы остановиться, но кроме осознания факта неработоспособности qt3+kde3 собранных gcc-4.3.2 с опцией -Os, я узнал много нового про gcc, чем не могу не поделится.

Многие наверное будут удивлены, но опция -march=core2 не включает оптимизацию с применением sse*, как принято считать, а всего лишь допускает использование соответствующих встроенных функций. Как убедились, да очень просто:

void test()
{
        // sse2 builtin
        __builtin_ia32_movnti(0, 0);
}

$ gcc -march=pentium -c test.cpp
test.cpp: In function ‘void test()’:
test.cpp:3: ошибка: нет декларации ‘__builtin_ia32_movnti’ в этой области видимости
$ gcc -march=core2 -c test.cpp
$

Но в то же время использование правильной архитектуры вовсе не стимулирует компилятор к оптимизации кода с применением расширений. Как определили это? да очень просто:

$ gcc -march=core2 -Q --help=target
  ...
  -msse                                 [выключено]
  -msse2                                [выключено]
  -msse3                                [выключено]
  -msse4                                [выключено]
  ...

Для того чтобы эта оптимизация выполнялась - необходимо явно задавать -mssse3 -mmmx или другие, необходимые для вашей архитектуры.

Надо сказать, что конструкция gcc -Q --help=CLASS очень полезна во всех отношениях. Я раньше этого не знал. В качестве CLASS можно подставлять в частности target, optimisers, warnings тем самым анализируя настройки компилятора с используемыми в вашем проекте опциями.

PS: Одного я только не понимаю, как -Os может столь фатально влиять на связь приложения с библиотекой?

Показать полностью...

Свернуть...

Ошибка в стандартном инклюде

Интересную ошибку словил на днях...

$ c++ ... -c file.cpp -o file.o
In file included from /usr/include/c++/4.2/bits/basic_ios.h:44,
                 from /usr/include/c++/4.2/ios:50,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iostream:45,
                 from configuration.h:4,
                 from wrap.h:15,
                 from file.cpp:15:
/usr/include/c++/4.2/bits/locale_facets.h:4576: error: template-id 'do_get<>' for 'std::string std::messages::do_get(int, int, int, const std::string&) const' does not match any template declaration
$

Всякие совпадения с реальными файлами являются случайными :)

Причем выяснилось, что если поменять инклюды местами - становится легче. В этом надо разобраться...

Проблема возникает с темплейтами в locale_facets.h.

Для начала прогоню две версии через препроцессор. После долгого сравнения выясняется, что в правильной версии проблемная строка (locale_facets.h:)выглядит так:

 template<>
    wstring
    messages::do_get(catalog, int, int, const wstring&) const;

А в неправильной:

  template<>
    string
    messages::do_get(catalog, int, int, const string&) const;

Очень странно, с какого праздника препроцессор в исходном тексте:

  template<>
    wstring
    messages::do_get(catalog, int, int, const wstring&) const;

заменил wstring на string?

Да очень просто. В одном из инклюдов проекта кто-то очень умный поставил:

#define wstring string

Если все стандартное инклюдится заранее - проблем нету. В противном случае стандартные инклюды тянутся из проектных инклюдов, и в результате ошибка компиляции. И как это называется?

Вообще я раньше наивно полагал что не стоит выносить сор из избы, то бишь каждый инклюд должен сам инклюдить все, что нужно ему для успешной компиляции.

Но последнее время я серьезно увлекся TDD, и изменил свое мнение на полностью противоположное. Инклюды, включенные в другие инклюды - это жесткая связанность. Исходный файл превращается в объектный, инклюды в этом процессе играют вспомогательную роль. И на полученный объектный файл мы уже не можем особо повлиять, все зависимости там уже есть. Но что касается описания класса - это достаточно абстрактное понятие. И в некоторых случаях описания классов можно даже полностью подменять для тестирования, но только в том случае если они не включены в самом инклюде.

Вот, как говориться КСCЗБ. Ну и кто написал эту ерунду (это я про define), пойду искать...

Показать полностью...

Свернуть...

kde4: впечатления

Прошол уже наверное почти месяц, как я решил попробовать kde4. В gentoo оно пока замаскировано но не очень жестко, так, слегка - под ~x86.

Эксперимент я провожу на домашнем компьютере. На рабочем - я работаю, и не могу надолго выводить его из строя. Что в процессе экспериментов случалось уже неоднократно.

Вся система у меня живет под "x86", И все пакеты я размаскирую индивидуально через /etc/portage/package.keywords. После установки kde файл /etc/portage/package.keywords/kde4 насчитывает около 125 строк. Но помимо этого мне пришлось размаскировать xorg-x11, который тоже состоит из весьма большого количества мелких пакетиков.

Раньше я спокойно всю систему держал на ~x86, но потом надоело ходить по краю и я перешел на стабильные версии. Иногда только хочется экстрима, вот как щас. :)

Что-то я уже запамятовал, какая версия kde встала первой, возможно что kde-4.1, но помню точно, что kdm4 сразу не заработал. Он запускался, но экран на седьмой консоли оставался пустым. Первое время приходилось пользоваться kdm3

Кстати про kde3. Обязательно используйте USE="kdeprefix". Без него kde3 сразу же перестал нормально работать, перемешались ресурсы обоих кед. kde3 необходимо обновить до 3.5.10, котороый, в свою очередь, тоже замаскирован (читай - еще 60 строк в /etc/portage/package.keywords/kde3 :) ).

После первого обновления заработал kdm4. Но куда-то делись все иконки из таскбара. Благо у меня их там не очень много, и я легко находил их на ощупь.

Второе обновление захотело новый xorg-server. Удовлетворив все зависимости получил полностью неработающую систему.

Сперва драйвер radeon отказывался запускаться по причине устаревшего abi, полегчало после перекомпиляции.

После этого kdm запустился, но клавиатура с мышью почему-то не оказывают видимого влияния на систему. И сидишь как дурак, перед экраном kdm, не в состоянии ничего сделать. Только reset.

Проанализировав логи сервера обнаружил загадочное сообщение: "AllowEmptyInput default to "yes", keyboard and mouse are disabled", ну что-то около того. Установил переменную в no, клавиатура вернулась на место.

Мышки опять нет, и опять что-то на тему abi... это мы уже проходили.

После этого все стало почти замечательно. Только вот в kde-4.2.1 в правом верхнем углу экрана постоянно крутится измеритель производительности какой-то. В принципе работает исправно, на голом десктопе показывает зеленый, сейчас, в konqueror (я теперь могу писать сообщения в blogger в конкуероре!) - красный. Окошки растягиваются, когда их дергаешь... компизовский чтоль изврат? правда компьютер у меня слабоватый, и в эти моменты индикатор чернеет... Можно конечно со стилями побаловатьcя, эффекты поотключать, но мне не столь важно, kate не тормозит. :)

Дочка один раз что-то нажала, и вокруг курсора появились крутящиеся звездочки. Три веселых крутящихся звездочки. Как она это сделала?

Вот. А в практическим плане можно отметить вот konqueror, который на движке webkit теперь медленно, но верно показывает 85/100 пунктов в acid3 (firefox 3.0.6 показывает 71/100). И пожалуй все. Остальные приложения как были так и остались.

Очень много еще всяких глюков, перечислять не буду.

Похоже, что все новшества kde4 сконцентрированы в основном вокруг графики. Я бы сидел бы на kde3, но с одной стороны интересно что же нас ждет, а с другой стороны в kde3 вряд ли что-то изменится, там своих проблем хватает, которые никто исправлять уже не будет.

Показать полностью...

Свернуть...

Эффективная работа с унаследованным кодом

Вышла в свет русская версия книги Майкла К. Физерса (Michael Feathers) - "Эффективная работа с унаследованным кодом" (Working Effectively with Legacy Code). Какой я блин шустрый, успел заказать ее на озоне за 854 рубля, хотя сейчас она стоит уже 909...

Не пропустите.



PS: Только что-то Озон не торопится мне её доставлять. Уже два дня как должен был доставить.

PPS: Что-то я совсем расслабился, в блог писать некогда. :)

Показать полностью...

Свернуть...