Menu
▾
▴
openpref-devel
|
From: Konstantin T. <an...@ya...> - 2010-09-14 17:21:50
|
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 |
|
From: dodikk.reg <dod...@gm...> - 2010-09-14 18:05:49
|
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. |
|
From: Konstantin T. <an...@ya...> - 2010-09-14 18:21:46
|
>
>
> Заранее извините за возможную резкость дальнейших ответов. Я понимаю что я для проекта человек чужой и не должен лезть со своим уставом.
> Однако проект мне весьма понравился. И я не хочу дабы его постигла печальная участь.
>
>
> > > Также это упростит написание Unit tests, коим я собираюсь заняться.
> > Это дело я одобряю, самому влом пока :) Думаю, следует сосредоточится на интерфейсах DeskView, PrefModel и Player
> И как вы себе видите написание оных тестов без разделения на библиотеки? (не вполне привык ещё на "ты". скоро исправлю)
> Включением соответствующих *.h; *.cpp в другой прожект? Да ведь это костыль.
>
> Скорее всего именно поэтому тестов у тебя и нет. Ведь их трудно добавлять.
Верно. Просто не хотелось бы перед выпуском 0.1.4 заморачиваться с разбиением, но если хочешь, можешь помочь.
По-хорошему, бибилотек должно быть больше: 1)модель 2)представление 3)AI в плагинах, каждый - отдельная либа
>
> > 3. Я не думаю, что разделение проекта на части актуально на данном этапе
> Лучше дождаться когда он станет большим, страшным и непонятным? Если и разделять, то как можно раньше. Согласен, структура каталогов - вещь хорошая. Но ведь библиотеки куда лучше. Я даже с CMake готов пообщаться (хотя лучше бы меня избавили от сей участи).
Думаю, он в обозримом будущем станет только проще и понятнее - я работаю над этим
>
> P.S. ну да. новые фичи (баги? ) писать куда веселее.
> =======================================================
>
>
>
>
>
>
> > > Настройки проекта заточил под QT Creator (ибо с CMake пока не владах).
> > В данный момент основная система сборки OpenPref - qmake, CMake поддерживается для удобства мейнтейнеров пакетов в дистрибутивах Linux (ибо более распространен)
> Насколько я помню, QT Creator с помощью qmake и собирает.
Ага, им самым.
> Я на досуге проверю свои изменения просто из консоли (без IDE). Возможно, пару ключей в *.pro не учёл.
Параметры для qmake есть на сайте, хотя для Windows нет ничего ценного
> Вот с CMake у меня дела обстоят хуже (да, я об этом уже писал).
О cmake я позабочусь :)
> >
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 (без указателя)? Или снова боязнь замедления всего сущего?
Разгадка проще: не копал я еще этот код. Значительная часть кода - дремучее legacy из 2000 и 2004 годов
--
Regards,
Konstantin
|
|
From: Konstantin T. <an...@ya...> - 2010-09-14 18:25:59
|
<BLOCKQUOTE style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" mce_style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" ><br />
<PRE wrap="" >А может, дождёмся показаний профайлера? Код должен быть понятен. И только потом быстр. Чёрт, да ты же и без меня это прекрасно знаешь !!!
Тем более что создание этих интерфейсов будет выполнено в самом начале игры (там где у тебя нынче выбор между alphabeta и другим ботом). Сами вызовы будут те же. Просто будет разделена ответственнность класса Player. Не вижу никаких причин для тормозов (кроме, возможно, своих кривых рук).
Опять же удобства для добавления сети и новых типов ботов.
</PRE></BLOCKQUOTE><br />Или моих :)<br />Мое отношение к этому коду такое: <br />а) оно не очень понятно<br />б) оно работает (значит не трожь)<br />в) оно не мешает развитию<br />г) оно содержит компоненты, которые должны быть в классе делегата игрока, но не в самом игроке<br /><br /><META http-equiv="content-type" content="text/html; charset=utf-8" style="" id="" ></META><BLOCKQUOTE mce_style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" style="" id="" ><PRE wrap="" style="" >=======================================================
</PRE><BLOCKQUOTE type="cite" style="" ><PRE wrap="" style="" >Card<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >*</SPAN>CardList<SPAN mce_style="color: #000000;" style="" >::</SPAN>exists<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >(</SPAN><SPAN mce_style="color: #808000;" style="" >int</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>aFace<SPAN mce_style="color: #000000;" style="" >,</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #808000;" style="" >int</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>aSuit<SPAN mce_style="color: #000000;" style="" >)</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #808000;" style="" >const</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >{</SPAN>
<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>Card<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >*</SPAN>c<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >=</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>newCard<SPAN mce_style="color: #000000;" style="" >(</SPAN>aFace<SPAN mce_style="color: #000000;" style="" >,</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>aSuit<SPAN mce_style="color: #000000;" style="" >);</SPAN>
<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>Card<SPAN mce_style="color: #000000;" style="" >*</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>ret<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #000000;" style="" >=</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>exists<SPAN mce_style="color: #000000;" style="" >(</SPAN>c<SPAN mce_style="color: #000000;" style="" >);</SPAN>
<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >//</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >delete</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >c;</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >//</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >TODO</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >:</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >memory</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #008000;" style="" >leak.</SPAN>
<SPAN mce_style="color: #c0c0c0;" style="" > </SPAN><SPAN mce_style="color: #808000;" style="" >return</SPAN><SPAN mce_style="color: #c0c0c0;" style="" > </SPAN>ret<SPAN mce_style="color: #000000;" style="" >;</SPAN>
<SPAN mce_style="color: #000000;" style="" >}</SPAN></PRE></BLOCKQUOTE><PRE wrap="" style="" >Напоминает memory leak. Поглядел потом внутрь exists и понял что ошибся. Однако не стоит ли перейти на QSharedPointer<SPAN mce_style="color: #000000;" style="" > или хранить структуры просто как ValueType (без указателя)? Или снова боязнь замедления всего сущего?
</SPAN>=======================================================
Кроме того, вместо CardUtils, по-моему, имеет смысл сразу при сдаче делить карты на 4 масти и работать уже с этими мастями. А не делать по линейному массиву карт постоянные выборки типа minInSuit(1..4).
Вот это как раз и будет замедлять программу, а не ООП.
=======================================================
P.S. Ещё раз прошу извинений за возможные обиды.
P.P.S. Так где можно на roadmap проекта глянуть?
</PRE></BLOCKQUOTE><br />На сайте, <A href="http://openpref.sourceforge.net/ru/development/" style="" id="" >openpref.sourceforge.net/ru/development/</A><br /><META http-equiv="content-type" content="text/html; charset=utf-8" style="" id="" ></META>-- <br />Regards,<br />Konstantin<br />
|
|
From: Konstantin T. <an...@ya...> - 2010-09-17 12:15:54
|
<BLOCKQUOTE style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" mce_style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" ><BLOCKQUOTE type="cite" ><PRE wrap="" ><br />Card<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >*</SPAN>CardList<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >::</SPAN>exists<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >(</SPAN><SPAN style="color: rgb(128, 128, 0);" mce_style="color: #808000;" >int</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>aFace<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >,</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(128, 128, 0);" mce_style="color: #808000;" >int</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>aSuit<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >)</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(128, 128, 0);" mce_style="color: #808000;" >const</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >{</SPAN>
<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>Card<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >*</SPAN>c<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >=</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>newCard<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >(</SPAN>aFace<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >,</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>aSuit<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >);</SPAN>
<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>Card<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >*</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>ret<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >=</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>exists<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >(</SPAN>c<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >);</SPAN>
<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >//</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >delete</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >c;</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >//</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >TODO</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >:</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >memory</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >leak.</SPAN>
<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(128, 128, 0);" mce_style="color: #808000;" >return</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>ret<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >;</SPAN>
<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >}</SPAN></PRE>
</BLOCKQUOTE>
<PRE wrap="" >Напоминает memory leak. Поглядел потом внутрь exists и понял что ошибся. Однако не стоит ли перейти на QSharedPointer<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" > или хранить структуры просто как ValueType (без указателя)? Или снова боязнь замедления всего сущего?
</SPAN>=======================================================
</PRE></BLOCKQUOTE><br /><br />Все карты создаются один раз и используются до завершения работы программы (если где-то это не так - значит утечка). Перед каждой сдачей колода на самом деле тасуется (а не заново создает случайные карты). Поэтому сомневаюсь, что здесь нужен shared pointer<br /><br />Еще одно обстоятельство: если где-то в программе объявлена "стремная" функция, это еще не означает, что она где-то используется (или ее нельзя заменить на вызов другой функции)<br /><br /><br /><BLOCKQUOTE mce_style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" style="" id="" ><PRE wrap="" style="" ><br />
Кроме того, вместо CardUtils, по-моему, имеет смысл сразу при сдаче делить карты на 4 масти и работать уже с этими мастями. А не делать по линейному массиву карт постоянные выборки типа minInSuit(1..4).
Вот это как раз и будет замедлять программу, а не ООП.
=======================================================
</PRE></BLOCKQUOTE><br />Можно изменить устройство CardList - сделать четыре независимых списка, а когда требуется получить QList со всеми картами, объединять эти списки<br /><br /><br />Если у кого-то есть желание порефакторить Card, CardList, ScoreBoard с сохранением их публичного API - вперед! Я сейчас с ними не работаю и они мало изменились с 0.1.3, так что у нас вряд ли возникнут конфликтующие правки.<br /><br />-- <br />Regards,<br />Konstantin<br /> |
|
From: Antony D. <to...@da...> - 2010-09-14 18:53:44
|
On 09/14/2010 09:21 PM, Konstantin Tokarev wrote: > 14.09.10, 20:55, "dodikk.reg" <dod...@gm...>: > >> Hello, Konstantin. Покрутил немного Ваш проектик. Попытался распилить его на GUI и библиотеки, собственно, с логикой. Это облегчило бы портирование надругие платформы (которое свелось бы к только главного проекта целиком,не затрагивая логики). > > > 1. Давай на ты > > 2. С момента 0.1.3 проект претерпел достаточно серьезные изменения в > расположении/наименованиях файлов и символов, так что работать нужно > с текущей гитовой версией (если гит не работает, можно скачать .tar.gz > из Гиториуса) > > 3. Я не думаю, что разделение проекта на части актуально на данном > этапе Мне кажется, это как раз одна из первоочередных задач. Во-первых, там много бардака. Во-вторых, отделение зерен от плевел - вообще хорошее дело. И да, это должно облегчить разработку сетевой версии. Ну и с помощью разделения на части можно заинтересовать людей с других платформ (PDA, интернет-таблетки и т.п.) и, таким образом, увеличить базу юзеров-тестеров. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP |
|
From: dodikk.reg <dod...@gm...> - 2010-09-14 19:09:51
|
Hello, Antony. Hello, Konstantin. > Мне кажется, это как раз одна из первоочередных задач. > Во-первых, там много бардака. Во-вторых, отделение зерен от плевел - вообще хорошее дело. > И да, это должно облегчить разработку сетевой версии. > Ну и с помощью разделения на части можно заинтересовать людей с других платформ > (PDA, интернет-таблетки и т.п.) и, таким образом, увеличить базу юзеров-тестеров. > Да. Об этом и я вёл речь. Только не очень умело. Итак, вопрос к Константину. Не совсем понял фразу "про CMake я позабочусь". Мне можно уже начинать merge с вашим trunk (в смысле, скачать trunk и раскидать эти исходники)? Или этим займется Константин на основании присланного мной (возможно, немного поломанного для чистого консольного qmake) tarball? -------------------------------------- Best Regards, Alexander Dodatko. |
|
From: Konstantin T. <an...@ya...> - 2010-09-17 16:48:24
|
> Я это вижу себе примерно так (см. диаграммы в приложении к сему > письму - потом перерисую в любимом векторном редакторе). Изучаю диаграммы. Фотографии да еще и с рукописного текста воспринимаются ужасно :) Рекомендую вот этот сервис: http://www.drawanywhere.com/ Я там даже начинал строить диаграмму игрового процесса http://www.drawanywhere.com/live/2dd649721cbe3.aspx По поводу разделения логики на стратегии: возможно, этот подход будет эффективен, если мы захотим строить "комбинированных" ботов. Однако, модель на мой взгляд не должна знать внутреннего устройства игрока, так как все, то от него требуется - это сообщать решения по поводу хода или заказанной игры, для чего вполне достаочен набор методов makeMove, makeBid, makeFinalBid, drop... (эти два должны быть объединены), chooseClosedWhist, которые внутри конкретного бота могут реализовываться, например, как обращение к экзепляру какой-то стратегии. Насчет остального мне трудно что-либо сказать, так как качество схем неважное и не хватает пояснений что есть что. Думаю, drawanywhere легко решит эту проблему -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-17 17:46:45
Attachments:
diagrams.zip
|
Hello, Konstantin.
Перерисовал схемы в dia (экспортнул в png). Присылаю их с сим
письмом. Перерисовывать ещё в чём-либо желания нет. Однако на будущее
буду иметь в виду предложенный тобой сервис.
> Однако, модель на мой взгляд не
> должна знать внутреннего устройства игрока, так как все, то от него
> требуется - это
> сообщать решения по поводу хода или заказанной игры
А я не вижу нарушения данного требования в своих диаграммах. Параметры,
передающиеся интерфейсу в реальной игре и так известны всем игрокам.
Это :
* текущее состояние пули (и история изменений)
* история торга игры.
* торг "пас/вист/полвиста".
* карты, лежащие на столе.
* карты из отбоя.
> makeMove, makeBid, makeFinalBid, drop... (эти два должны быть
> объединены),
> chooseClosedWhist, которые внутри конкретного бота могут
> реализовываться, например,
> как обращение к экзепляру какой-то стратегии.
В этом-то и идея. Что игрок будет содержать просто набор стратегий и в
нужный момент подсовывать GameEngine нужную.
Я бы лучше рассмотрел архитектуру, основанную на API стратегий, а не API
игрока.
Ведь, по сути, в каждой из фаз игры нужны не все методы, перечисленные
тобой, а только один.
Под фазами игры я понимаю :
* торговля за прикуп (сюда же наверно заказ игры, сброс карт)
* торговля за вист (не помню как правильно завётся. надеюсь поймёшь)
* собственно, игра (какую карту бросить следующей)
-------------------------------------
Best regards,
Dodatko Alexander.
|
|
From: Konstantin T. <an...@ya...> - 2010-09-17 18:26:01
|
> В этом-то и идея. Что игрок будет содержать просто набор стратегий и в > нужный момент подсовывать GameEngine нужную. > Я бы лучше рассмотрел архитектуру, основанную на API стратегий, а не API > игрока. > > Ведь, по сути, в каждой из фаз игры нужны не все методы, перечисленные > тобой, а только один. > Под фазами игры я понимаю : > * торговля за прикуп (сюда же наверно заказ игры, сброс карт) > * торговля за вист (не помню как правильно завётся. надеюсь поймёшь) > * собственно, игра (какую карту бросить следующей) Но логика этих действий в общем случае связана между собой, поэтому обрамляющий класс Player, с котороым взаимодействует модель, все равно нужен -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-17 20:34:18
|
Обсудили с Константином архитектуру сего дела.
Высылаю результаты нашей беседы.
=================================================================
(23:04:38) Konstantin Tokarev: привет!
(23:04:43) dodikk.reg: привет
(23:04:50) dodikk.reg: пишу письмо тебе :)
(23:04:55) Konstantin Tokarev: ок
(23:05:07) dodikk.reg: щас сюда кину
(23:05:16) dodikk.reg: Я предлагаю чтобы модель взаимодействовала со
стратегиями. Точнее, стратегия получает текущее состояние (возможно, лог
предыдущих состояний игры) и на их основании выдаёт решение.
(23:06:20) dodikk.reg: а клиентскому коду, на мой взгляд, будет глубоко
всё равно, укого требовать следующей карты или заказа игры
(23:06:27) Konstantin Tokarev: сейчас Player может получить любую нужную
информацию из модели
(23:06:31) dodikk.reg: у стратегии или у класса "Player"
(23:06:36) Konstantin Tokarev: в принципе да
(23:06:48) Konstantin Tokarev: но ботов будет труднее писать
(23:07:11) dodikk.reg: не совсем понимаю почему.
(23:08:02) dodikk.reg: наоборот, у тебя будет вместо одного бота целая
команда.
один торгуется, другой играет игру, третий играет мизер, четвёртый -
вист, пятый - распасы
(23:08:03) dodikk.reg: итд
(23:08:23) Konstantin Tokarev: а как они буду связаны между собой?
(23:08:39) dodikk.reg: смотри. игра разделена на фазы.
так?
(23:08:48) Konstantin Tokarev: ага
(23:08:58) dodikk.reg: фазы в принципе независимы
(23:09:26) dodikk.reg: то есть к примеру, бот, выдающий следующую карту
не должен ничего знать о том боте, который заказывал игру.
(23:10:01) dodikk.reg: зачем им взаимодействовать?
(23:10:12) Konstantin Tokarev: но выбирать то хочется конкретного противника
(23:10:34) Konstantin Tokarev: а зачем знать - легко объяснить
(23:10:45) Konstantin Tokarev: это они в существующих ботах не связаны
(23:10:57) Konstantin Tokarev: когда играет человек, связано все
(23:10:59) dodikk.reg: ну так сделаем фабрику, которая будет создавать
нам такие команды ботов.
1 фабрика - 1 конкретный противник
(23:12:00) dodikk.reg: вообще-то чем меньше параметров у моделируемого
процесса, тем систему легче обучить
(23:12:06) Konstantin Tokarev: мб. все ранво не понимаю, чем Player мешает
(23:12:40) dodikk.reg: да особо ничем. просто лишние перенаправления
вызовов писать прийдётся
(23:13:38) dodikk.reg: CardPtr Player::GetNextCard()
{
activeCardStrategy_->GetNextCard();
}
(23:13:43) dodikk.reg: наподобие этого
(23:13:48) Konstantin Tokarev: замечательно же)
(23:14:23) Konstantin Tokarev: и все это живет внутри плагина или
скриптового модуля
(23:15:48) dodikk.reg: почему бы этому всему не жить внутри каждой
стратегии?
(23:16:42) Konstantin Tokarev: ну мб
(23:16:59) dodikk.reg: ладно. а вдруг новичёк вроде меня вздумает
вызвать GetNextCard() во время заказа игры?
(23:17:25) dodikk.reg: в случае стратегий этого нельзя сделать будет в
принципе.
в случае Player - запросто
(23:17:41) dodikk.reg: короче, я о том что инкапсуляция рулит :)
(23:18:19) Konstantin Tokarev: согласен
(23:18:23) dodikk.reg: тем более, ботов можно будет писать по частям
(23:19:04) dodikk.reg: берёшь готового бота.
пишешь свой гениальнейший модуль, допустим, торговли за прикуп.
а остальные пока не придумал, пользуешь чужие
(23:19:14) Konstantin Tokarev: ок, убедил. думай над API, в 0.2 включим
(23:21:06) dodikk.reg: по сути, то, что ты называешь Player, я называю
Factory
(23:21:46) dodikk.reg: но Factory будет без методов вроде GetNextCard().
(23:21:53) Konstantin Tokarev: а где будут данные игрока храниться? в
модели?
(23:22:00) dodikk.reg: Он просто будет выдавать нужную стратегию по
требованию
(23:22:31) dodikk.reg: что есть данные игрока, по-твоему?
Кроме набора сданых карт?
(23:24:51) Konstantin Tokarev: имя, тип, очки
(23:25:18) dodikk.reg: должно быть состояние игры - карты на столе,
карты в отбое, текущие очки в пуле итд.
(23:25:31) dodikk.reg: то, что знают остальные игроки, должно храниться
в этом состоянии
(23:25:41) dodikk.reg: в том числе имя и очки.
(23:26:20) Konstantin Tokarev: для очков я думал сделать общий
ScoreBoard. Сейчас ScoreBoard у каждого игрока свой)
(23:27:10) dodikk.reg: по хорошему, согласен, он должен быть общий.
(23:28:30) dodikk.reg: по идее, любая стратегия описывается так
typedef <class Decision>
class IStrategy
{
public:
virtual Decision Decide(const GameState& gState) const;
};
(23:28:37) Konstantin Tokarev: тогда надо сначала модель отрефакторить,
затем игроков
(23:29:36) dodikk.reg: ага.
только у меня ещё не дошли руки по-серьёзному в исходниках разобраться.
проектик небольшой, но разбираться всё равно нужно.
(23:29:41) dodikk.reg: короче, дело поправимое
(23:29:57) dodikk.reg: скоро дожди, слякоть, а там и зима.
(23:30:29) dodikk.reg: ** должно будет когда-нибудь найтись это самое время
(23:30:34) dodikk.reg: однако я отвлёкся.
(23:31:12) dodikk.reg: Ладно. давай на сегодня завершать.
На досуге ещё диаграмки порисую :)
(23:31:33) dodikk.reg: Разговор этот сейчас перешлю на общую рассылку, с
твоего позволения
=================================================================
------------------------------------------------------------
Best regards,
Alexander Dodatko.
|
|
From: dodikk.reg <dod...@gm...> - 2010-09-21 19:01:34
Attachments:
2010_09_21__StrategyBasedAPI.zip
|
Нарисовал то, что мы обсуждали с Константином в jabber. Смотрим, обсуждаем далее. P.S. Я пока не разобрался со своим GIT. Константин, положи сие куда-нибудь в свой репозиторий. |
|
From: Konstantin T. <an...@ya...> - 2010-09-22 06:57:17
|
21.09.2010, 23:01, "dodikk.reg" <dod...@gm...>: > Нарисовал то, что мы обсуждали с Константином в jabber. > Смотрим, обсуждаем далее. Я все-таки не согласен с таким детальным разделением типов игровых стратегий Например, для альфабеты сейчас нет разницы между игрой и вистом, между распасами и мизером (в первом случае число возможных взяток максимизируется, во втором - минимизируется) Насколько я понимаю, ты предлагаешь лишить игровые стратегии доступа к информации о типе игры? Не уверен, что это было бы правильно (хотя конечно знание о том, сколько взяток не добираешь, вряд ли поможет взять больше :) > > P.S. Я пока не разобрался со своим GIT. Константин, положи сие > куда-нибудь в свой репозиторий. Это же не код. Выложу на сайте в "Разработке" -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-22 07:16:49
|
> Насколько я понимаю, ты предлагаешь лишить игровые стратегии доступа к
> информации о типе игры? Не уверен, что это было бы правильно (хотя конечно
> знание о том, сколько взяток не добираешь, вряд ли поможет взять больше
Да. И "подсовывать" классу, следящему за ходом игры и соблюдением правил
(назовём его GameController) нужную стратегию в зависимости от
заказанной игры. От стратегии же не будет требоваться ничего кроме как
выдавать следующий заказ на торге или карту в игре.
Если ухитримся подсунуть на мизере стратегию для виста или обычной игры
(набора взяток), то соответственно и получим полное фиаско.
> Я все-таки не согласен с таким детальным разделением типов игровых стратегий
> Например, для альфабеты сейчас нет разницы между игрой и вистом, между
> распасами и мизером (в первом случае число возможных взяток максимизируется,
> во втором - минимизируется)
Используй те же 2 стратегии как раньше. Только теперь не будет
конструкций типа
>> if (gameType == GAME_MISERE)
>> {
>> .......
Помнится, при беглом осмотре видел такое. Файл сейчас точно не скажу ибо
немного недосуг.
Короче, тип игры определяется сразу как игра заказана. В соответствии с
этим типом фабрика (или "игрок" как ты это называешь) отдаёт в
GameController нужную стратегию.
И дальше GameController уже крутит ходы и опрашивает нужную стратегию. А
как взять больше будет решать уже сама стратегия исходя из поданной ей
на вход ситуации. Из тех же данных что получаем мы с тобой когда играем
в эту прекрасную игру.
Схему с GameController я потом отдельно нарисую.
Посмотри еще классы "xxxEnvironment". Не забыл ли я туда включить
чего-нибудь важного.
|
|
From: Dmitry M. <mik...@gm...> - 2010-09-22 08:10:53
|
День добрый! Хоть я в программировании AI и не смыслю, но всё же выскажусь. В сообщении от 22 сентября 2010 10:57:09 автор Konstantin Tokarev написал: > Я все-таки не согласен с таким детальным разделением типов игровых > стратегий Например, для альфабеты сейчас нет разницы между игрой и вистом, > между распасами и мизером (в первом случае число возможных взяток > максимизируется, во втором - минимизируется) ИМХО это не есть правильно. Стратегии при игре и висте, а также при мизере и распасах должны различаться. Максимизация количества взяток нужна при игре, а при висте добавляется ещё попытка посадить играющего. Минимизация числа взяток соответствует распасам, при этом допустимо взять несколько взяток в самом начале, чтобы сбросить крупные карты. При мизере в начале игры имеет смысл больший риск, если есть вероятность не взять ни одной взятки. -- С уважением, Дмитрий Михирев |
|
From: Konstantin T. <an...@ya...> - 2010-09-22 09:31:17
|
22.09.2010, 12:10, "Dmitry Mikhirev" <mik...@gm...>: > Максимизация количества взяток нужна при игре, а > при висте добавляется ещё попытка посадить играющего. Спасибо за комментарий! Похоже, что AlphaBeta при висте сейчас действитльно максимизирует только свои взятки, тогда как нужно максимизировать взятки на руках у обоих партнеров. Этот код писал не я, буду разбираться. -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-22 07:38:59
|
> Это же не код. Выложу на сайте в "Разработке" А в чём проблема завести отдельную директорию типа "doc/API_drafts"? На мой взгляд, документация должна храниться вместе с самим проектом. Пусть народ будет исправлять и присылать наравне с кодом. При желании можно будет и changelog просматривать в последствии. То, что они бинарные, можно, в принципе, решить с помощью сего замечательного языка для описания UML (будет сильно нужно - переведу). http://yuml.me/diagram/scruffy/class/samples |
|
From: Konstantin T. <an...@ya...> - 2010-09-22 07:47:02
|
22.09.2010, 11:37, "dodikk.reg" <dod...@gm...>: >> Это же не код. Выложу на сайте в "Разработке" > > А в чём проблема завести отдельную директорию типа "doc/API_drafts"? > На мой взгляд, документация должна храниться вместе с самим проектом. > Пусть народ будет исправлять и присылать наравне с кодом. При желании > можно будет и changelog просматривать в последствии. ок, сделаю > > То, что они бинарные, можно, в принципе, решить с помощью сего > замечательного языка для описания UML (будет сильно нужно - переведу). Диа вроде умеет экспортировать в UML Лично я с UML раньше не работал (хотя в общих чертах представляю себе) Если код уже написан, отличные диаграммы взаимодействия рисуются Doxygen'ом безо всякого UML -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-22 07:50:10
|
> Если код уже написан, отличные диаграммы взаимодействия рисуются Doxygen'ом > безо всякого UML Поясню: достаточно написать заголовки с документацией, работающий код не обязателен -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-22 17:37:44
|
Обсудили с Александром возможности будущего устройства OpenPref [2010-09-22 20:36] Oleksandr Dodatko: я вот обнаружил что не учёл такие вещи как информация о закрытых картах соперника. [2010-09-22 20:37] Oleksandr Dodatko: ну, мол, закончился у товарища козырь [2010-09-22 20:37] Konstantin Tokarev: через вышедшие карты [2010-09-22 20:37] Konstantin Tokarev: которые у всех одни и должны браться из модели [2010-09-22 20:38] Oleksandr Dodatko: вообще, да. но высчитывать это каждый раз утомительно [2010-09-22 20:38] Konstantin Tokarev: неэффективно [2010-09-22 20:38] Oleksandr Dodatko: лучше каждому игроку дать по listener, который будет при случае данную инфу запоминать [2010-09-22 20:39] Konstantin Tokarev: хм, тогда уж внутри накапливать инфу [2010-09-22 20:39] Oleksandr Dodatko: то есть, я к тебе зашёл в бубну. у тебя бубны нет, ты выбросил козырь. мой listener это увидел и себе тихонько записал. [2010-09-22 20:39] Oleksandr Dodatko: то есть, сброс общий. а вот такие вещи лучше чтобы каждый при себе хранил. [2010-09-22 20:39] Oleksandr Dodatko: подскажи ещё подобные вещи в тот же thread на рассылке если вспомнишь. [2010-09-22 20:40] Konstantin Tokarev: согласен. получается, что класс Player таки нужен:) [2010-09-22 20:40] Konstantin Tokarev: а что именно подсказать? [2010-09-22 20:40] Oleksandr Dodatko: подобную косвенную инфу по игрокам. [2010-09-22 20:40] Oleksandr Dodatko: ну, типа отсутствия определённой масти. [2010-09-22 20:41] Konstantin Tokarev: вышедшие крупные карты [2010-09-22 20:41] Oleksandr Dodatko: ну, у нас будет полный лог вышедших карт [2010-09-22 20:41] Konstantin Tokarev: он и сейчас есть, просто публично метода в PrefModel нет:) [2010-09-22 20:42] Konstantin Tokarev: есть внутренняя проверка на туз в рукаве:) [2010-09-22 20:42] Konstantin Tokarev: чтобы при игре по сетке два раза ону карту не передали [2010-09-22 20:44] Oleksandr Dodatko: похоже, больше ничего таки не нужно. [2010-09-22 20:44] Oleksandr Dodatko: ок. спасибо. [2010-09-22 20:45] Konstantin Tokarev: ну можно анализировтаь как соперники торговался, правда это только против человека поможет [2010-09-22 20:45] Konstantin Tokarev: или сделать специально стратегию с "дыркой" [2010-09-22 20:46] Konstantin Tokarev: типа компу надоело и он резко поднял до восьми [2010-09-22 20:46] Oleksandr Dodatko: не. это не то. [2010-09-22 20:46] Konstantin Tokarev: или начал не с 6 пик [2010-09-22 20:46] Oleksandr Dodatko: я про вспомогательные элементы окружающей среды [2010-09-22 20:47] Konstantin Tokarev: какое пиво пьет противник? :) [2010-09-22 20:47] Oleksandr Dodatko: то есть, явно у нас нигде не написано что у него бубна закончилась. но мы проанализировали его выброс и всё узнали. [2010-09-22 20:48] Konstantin Tokarev: ну это уже обсудили [2010-09-22 20:48] Konstantin Tokarev: это можно в модели хранить для проверки на чит (ренонс) [2010-09-22 20:49] Oleksandr Dodatko: а потом отдавать всем кто попросит? можно и так :) [2010-09-22 20:49] Konstantin Tokarev: хм, может отдавать не стоит. по правилам можно смотерть последнюю взятку :) [2010-09-22 20:50] Oleksandr Dodatko: ну, типа компы у нас таааакие умные что помнят прям всё что вышло и чего у кого нет [2010-09-22 20:50] Oleksandr Dodatko: :) [2010-09-22 20:52] Konstantin Tokarev: не, скрывать не надо. в модифицированном клиенте эту инфу все равно легко вытащить, в немодифицированном она не будет видна человеку, а вообще все легко записать на бумажке [2010-09-22 20:54] Oleksandr Dodatko: та можно даже отдельную фичу завести. мол, покажи мне чё вышло итп. типа "режим обучения" [2010-09-22 20:54] Konstantin Tokarev: ага [2010-09-22 20:54] Oleksandr Dodatko: или давать подобную подсказку, скажем, 2 раза в сдачу [2010-09-22 20:55] Konstantin Tokarev: тогда уж как в кдеешных играх - "подскажи как ходить дальше" :) [2010-09-22 20:57] Konstantin Tokarev: сбоку показывать справку на тему что сейчас происходить и что надо делать ( в зависимости от текущего состояния) [2010-09-22 20:58] Oleksandr Dodatko: ну, кто знает толк, тот эту хрень отрубает [2010-09-22 20:59] Konstantin Tokarev: наоборот, по-умолчанию выключить надо, кто не знает - включит [2010-09-22 20:59] Oleksandr Dodatko: да и вообще, найдутся features помажорнее [2010-09-22 20:59] Konstantin Tokarev: мб иностранцы какие-нибудь начнут учиться:) [2010-09-22 20:59] Konstantin Tokarev: расширить круг пользователей [2010-09-22 21:00] Oleksandr Dodatko: ну, это да. [2010-09-22 21:00] Konstantin Tokarev: в принципе качают не только в Росси и Украине [2010-09-22 21:00] Oleksandr Dodatko: к стати, глянь потом на класс ITradeStrategy повнимательней. Может, его слегка распилить стоит? У меня были некоторые сомнения когда я его рисовал :) [2010-09-22 21:02] Konstantin Tokarev: а что там пилить? там же один метод всего :) [2010-09-22 21:02] Konstantin Tokarev: а [2010-09-22 21:02] Konstantin Tokarev: не туда посмотрел:) [2010-09-22 21:02] Konstantin Tokarev: ну да, можно пополам [2010-09-22 21:03] Oleksandr Dodatko: там 3 метода :) [2010-09-22 21:03] Oleksandr Dodatko: или ты хочешь сброс отдельно? [2010-09-22 21:03] Konstantin Tokarev: нет, я хочу сброс и FinalBid вместе [2010-09-22 21:03] Oleksandr Dodatko: и как мы сие назовём? [2010-09-22 21:04] Konstantin Tokarev: имхо trade неправильное слово, мы не продаем товары [2010-09-22 21:05] Oleksandr Dodatko: ок. учту. [2010-09-22 21:05] Konstantin Tokarev: bid лучше подходит [2010-09-22 21:05] Oleksandr Dodatko: я про тип стратегии. со сбросом и финальным заказом [2010-09-22 21:05] Konstantin Tokarev: я понимаю, что если трудно назвать, это неправильно:) [2010-09-22 21:06] Oleksandr Dodatko: а может так втроём их и оставить? [2010-09-22 21:06] Konstantin Tokarev: можно, но стадии игры разные [2010-09-22 21:07] Konstantin Tokarev: это все будет в qstatemachine, и после двух пасов будет переключение [2010-09-22 21:08] Konstantin Tokarev: по-идее надо уже другую стратегию вызывать [2010-09-22 21:08] Konstantin Tokarev: хотя у них будет общий код [2010-09-22 21:09] Oleksandr Dodatko: как стадия эта называется? [2010-09-22 21:10] Oleksandr Dodatko: ладно. назовём IBidStrategy и IFinalBidStrategy [2010-09-22 21:10] Konstantin Tokarev: ок [2010-09-22 21:12] Konstantin Tokarev: еще такое соображение: наверно надо убрать коннекты между моделью и представлением - чтобы проще было не кутэшный гуй прикрутить [2010-09-22 21:13] Konstantin Tokarev: с главным окном пусть коннектится - никто не обработает и пофиг [2010-09-22 21:15] Oleksandr Dodatko: я попробую учесть. но я ещё дотуда не дошёл. [2010-09-22 21:18] Konstantin Tokarev: логика такая: коннект нужен там где заранее неизвестно какую функцию надо вызвать. например, DeskView сейчас - самодостаточный виджет, который необязательно должен сидеть в MainWindow. А в случае PrefModel и DeskView участники известны (или их базовые классы, если выделить абстрактные) [2010-09-22 21:18] Konstantin Tokarev: со стратегиями то же самое [2010-09-22 21:20] Konstantin Tokarev: если мы хотим добавить скриптовую обертку для С-подобного интерфейса это одно. а если нужно поддерживать коннекты, маленькие скриптовые движки вроде lua превращаютсяв монстров -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-22 18:04:05
|
Перерисовал в yEd редакторе. Положил в SVN. Константин, погляди и переложи в GIT. *.dia можно грохнуть. Если нужно, могу доложить сконвертированные *.png (хотя считаю это неправильным). Предлагаю диаграммы для ненаписанного кода фигачить именно в нём. Константин, как насчёт Coding Standart? Не хочешь ли завести для этого проекта, раз уж мы к тебе примкнуть решили? Если решишь что это целесообразно, могу выслать черновичёк в *.odt (OpenOffice.org). Готовил для своего предыдущего места работы, да не сложилось. |
|
From: Konstantin T. <an...@ya...> - 2010-09-22 18:14:35
|
22.09.2010, 22:03, "dodikk.reg" <dod...@gm...>: > Перерисовал в yEd редакторе. > Положил в SVN. Константин, погляди и переложи в GIT. *.dia можно грохнуть. > Если нужно, могу доложить сконвертированные *.png (хотя считаю это > неправильным). Файл не пришел > > Предлагаю диаграммы для ненаписанного кода фигачить именно в нём. > > Константин, как насчёт Coding Standart? Не хочешь ли завести для этого > проекта, раз уж мы к тебе примкнуть решили? > Если решишь что это целесообразно, могу выслать черновичёк в *.odt > (OpenOffice.org). Готовил для своего предыдущего места работы, да не > сложилось. Вот такой подойдет: http://qt.gitorious.org/qt/pages/QtCodingStyle за исключением того, что я сейчас использую отступ в два пробела -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-23 06:27:09
|
>> Перерисовал в yEd редакторе. >> Положил в SVN. Константин, погляди и переложи в GIT. *.dia можно грохнуть. >> Если нужно, могу доложить сконвертированные *.png (хотя считаю это >> неправильным). > Файл не пришел Да ну? А это что? https://openpref.svn.sourceforge.net/svnroot/openpref/API_draft/ Хотя да. в почту тебе не отправлял. > Вот такой подойдет: > http://qt.gitorious.org/qt/pages/QtCodingStyle > за исключением того, что я сейчас использую отступ в два пробела Напиши об этом где-нибудь у себя на сайте. P.S. стиль расстановки скобочек у QT-шников конечно уродский (на мой вкус, разумеется). Как насчёт BSD Allman style? (http://en.wikipedia.org/wiki/Indent_style#Allman_style_.28bsd_in_Emacs.29 ). |
|
From: Konstantin T. <an...@ya...> - 2010-09-23 06:38:44
|
> https://openpref.svn.sourceforge.net/svnroot/openpref/API_draft/ Закоммитил -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-23 06:34:37
|
23.09.2010, 10:25, "dodikk.reg" <dod...@gm...>: >>> Перерисовал в yEd редакторе. >>> Положил в SVN. Константин, погляди и переложи в GIT. *.dia можно грохнуть. >>> Если нужно, могу доложить сконвертированные *.png (хотя считаю это >>> неправильным). >> Файл не пришел > > Да ну? А это что? > https://openpref.svn.sourceforge.net/svnroot/openpref/API_draft/ > Хотя да. в почту тебе не отправлял. Извини, забыл проверить свн > >> Вот такой подойдет: >> http://qt.gitorious.org/qt/pages/QtCodingStyle >> за исключением того, что я сейчас использую отступ в два пробела > > Напиши об этом где-нибудь у себя на сайте. > P.S. стиль расстановки скобочек у QT-шников конечно уродский (на мой > вкус, разумеется). Как насчёт BSD Allman style? > (http://en.wikipedia.org/wiki/Indent_style#Allman_style_.28bsd_in_Emacs.29 > ). На самом деле этот стиль используют практически все qt-шные и kde-шные проекты Я сначала тоже скобки расставлял по Олману, т.к. этот стиль был в первой книжке по крестам, которую я изучал. Но получается очень много пустых строк, это раздражает. И вообще, K&R - это классика -- Regards, Konstantin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X