[Openpref-devel] Open pref project structure patch.

[dodikk.reg <dod...@gm...>]

14.09.10, 20:55, "dodikk.reg" <dod...@gm...>:


> >  Hello, Konstantin.    Покрутил немного Ваш проектик. Попытался распилить его на GUI и библиотеки, собственно, с логикой. Это облегчило бы портирование надругие платформы (которое свелось бы к только главного проекта целиком,не затрагивая логики).     
1. Давай на ты

2. С момента 0.1.3 проект претерпел достаточно серьезные изменения в 
расположении/наименованиях файлов и символов, так что работать нужно
с текущей гитовой версией (если гит не работает, можно скачать .tar.gz 
из Гиториуса)

3. Я не думаю, что разделение проекта на части актуально на данном
этапе



> > Также это упростит написание Unit tests, коим я собираюсь заняться.
Это дело я одобряю, самому влом пока :)
Думаю, следует сосредоточится на интерфейсах DeskView, PrefModel и Player



> > Настройки проекта заточил под QT Creator (ибо с CMake пока не владах). 
В данный момент основная система сборки OpenPref - qmake, CMake поддерживается
для удобства мейнтейнеров пакетов в дистрибутивах Linux (ибо более распространен)


> > Подружить GIT со своей виндой у меня не совсем получилось (rtfm практиковал :) ) . 
А вот это: http://help.github.com/win-git-installation/
?


> > Посему высылаю исходник. Надеюсь, это Вас не сильнозатруднит.
Дифф сделать не получится, так как файлы "переехали". Опиши в кратце суть изменений


> > Не получилось вынести классы из logic и desc ввиду их взаимной завязанности друг на друге и на GUI. Однако этим займусь попозже когда(если) руки дойдут.
Я об этом знаю. Можно было написать и спросить, над чем ведется работа и т.п.


> > Также было бы круто распилить функции MiserCatch1, MiserCatch2 итп.на маленькие аккуратные стратегии и не накапливать их в классе Player. Влюбом случае, наличие функций, ответственных за мизер, обычную игру ираспасы в одном классе считаю не совсем правильным.
Дело в том, что этот вариант AI малоперспективен (в лучшем случае, из него получится хороший "рентген"), 
поэтому вкладывать в него много сил не хочется. Я его допиливаю исключительно ради дальнейшего использования 
в тренировке нейронных сетей. "Альфабета" более перспективен, но играет не "человекоподобно"

Мое мнение - пусть будет как есть. Есть универсальный API для всех видов игроков, при разработке новых ботов
можно сделать что-то более высокоорганизованное, модель игры все равно не видит внутреннего устройства игрока
Переусердствовать с ООП и особенно сигнал-слотовыми соединениями внутри игроков мне кажется не стоит - скорость
работы будет уменьшаться

-- Regards, Konstantin

======================================================================================================================

======================================================================================================================

======================================================================================================================




Hello, Konstantin.


Заранее извините за возможную резкость дальнейших ответов. Я понимаю что
я для проекта человек чужой и не должен лезть со своим уставом.
Однако проект мне весьма понравился. И я не хочу дабы его постигла
печальная участь.


>> Также это упростит написание Unit tests, коим я собираюсь заняться.
> Это дело я одобряю, самому влом пока :)
> Думаю, следует сосредоточится на интерфейсах DeskView, PrefModel и Player
И как вы себе видите написание оных тестов без разделения на библиотеки?
(не вполне привык ещё на "ты". скоро исправлю)
Включением соответствующих *.h; *.cpp в другой прожект? Да ведь это
костыль.

Скорее всего именно поэтому тестов у тебя и нет. Ведь их трудно добавлять.




> 3. Я не думаю, что разделение проекта на части актуально на данном
> этапе
Лучше дождаться когда он станет большим, страшным и непонятным? Если и
разделять, то как можно раньше. Согласен, структура каталогов - вещь
хорошая. Но ведь библиотеки куда лучше. Я даже с CMake готов пообщаться
(хотя лучше бы меня избавили от сей участи).

P.S. ну да. новые фичи (баги? ) писать куда веселее.
=======================================================






>> Настройки проекта заточил под QT Creator (ибо с CMake пока не владах). 
> В данный момент основная система сборки OpenPref - qmake, CMake поддерживается
> для удобства мейнтейнеров пакетов в дистрибутивах Linux (ибо более распространен)
Насколько я помню,  QT Creator с помощью qmake и собирает. Я на досуге
проверю свои изменения просто из консоли (без IDE).  Возможно, пару
ключей в *.pro не учёл.
Вот с CMake у меня дела обстоят хуже (да, я об этом уже писал).

=======================================================





>> Подружить GIT со своей виндой у меня не совсем получилось (rtfm практиковал :) ) . 
> А вот это: http://help.github.com/win-git-installation/
Это и ставил. Что самое смешное, по этому же мануалу. Не получается ни с
gitorious, ни с github работать. Проблемы с SSH (подробности опущу).
Короче, разберусь позже. Думаю, данная проблема не стоит обсуждения здесь.

=======================================================





> Дифф сделать не получится, так как файлы "переехали". Опиши в кратце суть изменений
В файлах ничего не трогал. Просто сделал переезд и соответствующие
изменения в *.pro файлах. Я пока только начал разбираться с проектом.

=======================================================






>>  Не получилось вынести классы из logic и desc ввиду их взаимной завязанности друг на друге и на GUI. Однако этим займусь попозже когда(если) руки дойдут.
> Я об этом знаю. Можно было написать и спросить, над чем ведется работа и т.п.
=======================================================




> Мое мнение - пусть будет как есть. Есть универсальный API для всех видов игроков, при разработке новых ботов
> можно сделать что-то более высокоорганизованное, модель игры все равно не видит внутреннего устройства игрока
> Переусердствовать с ООП и особенно сигнал-слотовыми соединениями внутри игроков мне кажется не стоит - скорость
> работы будет уменьшаться
А может, дождёмся показаний профайлера? Код должен быть понятен. И только потом быстр. Чёрт, да ты же и без меня это прекрасно знаешь !!!
Тем более что создание этих интерфейсов будет выполнено в самом начале игры (там где у тебя нынче выбор между alphabeta и другим ботом). Сами вызовы будут те же. Просто будет разделена ответственнность класса Player. Не вижу никаких причин для тормозов (кроме, возможно, своих кривых рук).
Опять же удобства для добавления сети и новых типов ботов.
=======================================================




> Card *CardList::exists (int aFace, int aSuit) const {
>
>   Card *c = newCard(aFace, aSuit);
>   Card* ret = exists(c);
>   // delete c; // TODO : memory leak.
>   return ret;
> }
Напоминает memory leak. Поглядел потом внутрь exists и понял что ошибся. Однако не стоит ли перейти на QSharedPointer или хранить структуры просто как ValueType (без указателя)? Или снова боязнь замедления всего сущего?
=======================================================




Кроме того, вместо CardUtils, по-моему, имеет смысл сразу при сдаче делить карты на 4 масти и работать уже с этими мастями. А не делать по линейному массиву карт постоянные выборки типа minInSuit(1..4).
Вот это как раз и будет замедлять программу, а не ООП.
=======================================================



P.S. Ещё раз прошу извинений за возможные обиды.
P.P.S. Так где можно на roadmap проекта глянуть?


--------------------------------------
Best regards,
Alexander Dodatko.