← All posts tagged говно

Drino

Сегодня, часов этак в 6 (официально. На практике первые люди подошли к половине), мы собрались для того, чтобы поиграть таки в Battlestar Galactica. После двух часов ожидания милых девушек с коробкой (а точнее сразу тремя — оригинал и два дополнения) и получаса раскладывания компонент по полю (да, если хранить карточки в беспорядке, то время на подготовку игры резко возрастает), мы всё-таки начали играть вшестером. Партия с двумя сайлонами и сайлонским лидером вышла на редкость унылой с чисто игровой точки зрения — за столом было два человека, читавших правила, и один из них (имхо) понимал половину правил неверно, плюс неадекватно читал надписи на скиллкартах. В итоге — активное шерстение в поисках пруфов в рулбуках, неумолимо высокий даунтайм и скука. Как обычно, наличие в игре половины игроков, играющих за сайлонов, обеспечило победу этой стороне (впрочем, до последнего "суда" мы игру дотянули, где я честно слил одного из сайлонов (и себя), а лидер не осилил выполнить свою цель). Правила Exodus'а показались излишне запутанными, а единтвенный смысл, который я в них видел — не дать играть стратегией "все сидят в бриге, не получая кризисов, а Вася бегает по кораблю и проходит их". Ну и дать играть способности не участвующих в игре ролей. Имхо — третье дополнение делает из игры сущий рандом и какой-то буддистский круг перерождений с "кармой" и прочая-прочая. Вывод — играть лучше в ванильный BSG с Пегасом.
К концу партии подрулил ещё один кун, но в итоге от нас свалили две тян, и третья саботировала уход от нас себя и ещё одного куна. Итог — последний подъехавший человек просто принёс Дрино вкусняшки и мы сыграли одну (откровенно паршивую) партию. EPIC FAIL.

Drino

Итак, конкурс "наверни говна^W костылей 2012" продолжается. Сегодня задумался над такой проблемой — есть у меня класс вида
class myClass {
<...>
myClass operator + (const myClass&);
<...>
};
от которого я наследую класс inhClass:
class inhClass : public myClass { <...> };
Проблема в том, что operator+ я inhClass'у переопределять не хочу, да и вообще inhClass это такой myClass только с ещё парой-другой методов. А operator+ применённый к двум inhClass'ам вовзращает мне myClass, у которого этой самой пары методов нет. Вызывать inhClass(myClass) — нехорошо, ибо конструктор повлечёт за собой копирование довольно толстых внутренних данных.
Пока что решение проблемы выглядит так:
template < class T > myClass {
<...>
T operator+ (const T&);
<...>
};

class inhClass : public myClass <inhClass> {<...>};
А this в методах myClass приводится к T* reinterpret_cast'ом, угу.

Drino

Нашёл два относительно красивых костыля для решения проблемы из #1773614. Думаю они вообще говоря боянисты, но на изобретение их в качестве велосипедов пришлось изрыть полгугла (видимо не то искал, но бесполезно) и потратить полдня.
Объясню, зачем мне хотелось получить всякие стандартные операторы — есть у меня функция вида
template < class A, class B, class Func >
void joinMap ( map < A, B >* result, const map < A, B >& other, Func join);
И этот joinMap, например, берёт и применяет join ко всем ((*result)[it->first], it->second). Возвращаясь к проблеме — на получение operator-= придётся забить, ибо невозможно. Поэтому пишется темплейтная функция T& SubEq < T > (T&, const T&) и подобные ей (естественно они пихаются в личный неймспейс для костылей). Дальнейшее решение проблемы зависит от любви пользователя к извращениям.
Вариант 1 — пилим шаблонную функцию, которая принимает какой-либо шаблонный класс и другую шаблонную функцию, и возвращает эту функцию с уже использованным шаблоном. Нечто вроде
template < class T >
T& () ( T&, const T&) getEqOperator(vector < T >, T& () ( T&, const T&) oper) { return oper; }
Конечно не помешают темплейтные тайпдефы, дабы всё это выглядело получше (а они сами по себе уже большой костыль, который реализуется через struct).
Минусы — надо напилить по функции на каждую сигнатуру. С другой стороны альтернатива мне кажется несколько более кривой.
Вариант 2 — уточняем тип параметра-функции для нашего абстрактного joinMap.
template < class A, class B >
void joinMap ( map < A, B >* result, const map < A, B >& other, B& (*join) (B&, const B&));
Работает, но ровно до тех пор, пока нам не вздумается послать в качестве join что-нибудь, не влияющее на суть, но отличное от шаблона. И к величайшему несчастью
template < class A, class B, class C >
void joinMap ( map < A, B >* result, const map < A, B >& other, C (*join) (B&, const B&));
ппочему-то мешает g++ нормально определить типы.

Drino

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

Drino

Жужик, научи меня как исправить себе почерк? Прописи не помогают, а выглядит он, увы, как говно. Слышал о каком-то извратном методе занятий с метрономом, но ничего толком не гуглится. Интереснота, словом. Желаю историй успеха/неудач.

Drino

Вычистил всё DE-зависимое говно из xdg-open'а. Заставил его работать. Теперь проблема в том, что мой файловый менеджер (как и любой другой) не хочет открывать .jpg-файлы в просмотрщике картинок. Пичаль-пичаль.

Drino

Сраный xdg-open не хотеть сделать мне хорошо и открывать тупые файловые ссылки в файловом менеджере, а не в говнобраузере.Гуглю битый час, все костыли не работают. Сам не понимаю уже, почему... >.<

Drino

Pidgin 2.7.0 были с ошибками сегментации и попытались просмотреть файл ядра.
Это глюк в программе и вы тут не виноваты.

Если вы можете повторить возникновение ошибки, пожалуйста уведомите
разработчиков, создав отчёт об ошибке на:
developer.pidgin.im карточка/

Пожалуйста, будьте готовы описать как всё произошло в тот момент
и представить вывод командной строки файла ядра. Если вы не знаете
как его вывести, пожалуйста, прочитайте инструкцию на
developer.pidgin.im
Аварийный останов

Pidgin 2.7 точно переводили 13тилетние школьницы. Впрочем, учитывая основное нововведение (X-статусы) это вполне логично.