роботы робототехника микроконтроллеры


 Страниц (7): « 1 2 [3] 4 5 6 7 »   

> Описание: Холиварные споры.
-dead- Post Id


Президент


Сообщений всего: 966
Дата рег-ции: Февр. 2009  



Admin пишет:
-dead- пишет:
количество вызовов было бы еще ограничено 10 в секунду

Такой подход не дает никаких преимуществ, только неудобства. Чаще всего это бывает необходимо, чтобы избавиться от одной из проблем СОП - дать возможность "перевести дух" машине. В GameLogo таких проблем нет.

Преимущество он даёт вполне конкретное - на любой более производительной машине он будет работать с той же скоростью, что и на исходной, а не будет страдать проблемой DOS-овских игр на P-III, когда начинаешь играть в тетрис и сразу GAME OVER, потому что комп быстрей выполнил заполнение стакана и отрисовку, чем на исходной машине Улыбка

И в СОП нету проблемы "перевести дух", есть проблема генерации большего количества событий, чем система может успеть обработать. При отсутствии такой перегрузки "переводить дух" не нужно.

В общем я вас понял - "это не баг, это фича" Улыбка ну фича, так фича.
 
 Top
Admin Администратор Post Id


Администратор


Сообщений всего: 897
Дата рег-ции: Май 2006  



Программы, написанные в GameLogo выполняются на той же машине, на которой они были написаны. Это учебная среда программирования.
(Добавление)
-dead- пишет:
Преимущество он даёт вполне конкретное - на любой более производительной машине он будет работать с той же скоростью, что и на исходной, а не будет страдать проблемой DOS-овских игр


Мы смотрим на противоположные векторы этой проблемы. Я рассматриваю обратный перенос - с быстрой на медленную. И подход, реализованный в GameLogo, в данном контексте может рассматриваться как наиболее удачное решение.

-dead- пишет:
И в СОП нету проблемы "перевести дух", есть проблема генерации большего количества событий, чем система может успеть обработать. При отсутствии такой перегрузки "переводить дух" не нужно.


Длительное нажатие на клавишу и есть такая проблема.
 
 Top
-dead- Post Id


Президент


Сообщений всего: 966
Дата рег-ции: Февр. 2009  



Admin пишет:
Программы, написанные в GameLogo выполняются на той же машине, на которой они были написаны. Это учебная среда программирования.

Под каждую же ЭВМ вряд ли хорошо заново примеры в учебнике переписывать...

Admin пишет:
Мы смотрим на противоположные векторы этой проблемы. Я рассматриваю обратный перенос - с быстрой на медленную. И подход, реализованный в GameLogo, в данном контексте может рассматриваться как наиболее удачное решение.

Типа не делать очередь события, которая может быть перегружена,, если не успеваем их обработать. Вариант. Но тогда это скорее должно называться State-driven-programming, чем Event-driven-programming. Но можете считать это придирками Улыбка

Admin пишет:
Длительное нажатие на клавишу и есть такая проблема.

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

В общем да, я понял что у вас, зачем и почему, но мне всё равно кажется, что это не события, а состояния Смущение .
 
 Top
Admin Администратор Post Id


Администратор


Сообщений всего: 897
Дата рег-ции: Май 2006  



-dead- пишет:
Под каждую же ЭВМ вряд ли хорошо заново примеры в учебнике переписывать...


Вы видели хоть один пример, для которого это критично? Замешательство

-dead- пишет:
тогда это скорее должно называться State-driven-programming, чем Event-driven-programming


Вы опять пытаетесь подвести под какую-то парадигму. Теперь будем заводить ветку "Почему GameLogo не реализует АОП?". гы-гы!

-dead- пишет:
Если обработчик не успевает обработать все события может быть еще такое решение - выкидывать часть событий из обработки, однотипных или полностью совпадающих. Отчасти это будет похоже на ваш вариант


Именно так и делает селектор в GameLogo.

-dead- пишет:
только тут будет ограничение по количеству обработок исходя из первоначального количестве сгенерированных событий.


да

-dead- пишет:
В общем да, я понял что у вас, зачем и почему, но мне всё равно кажется, что это не события, а состояния .


Ну вот, теперь уже не события и не свойства, а состояния. Поговорим об АОП? Голливудская улыбка
 
 Top
-dead- Post Id


Президент


Сообщений всего: 966
Дата рег-ции: Февр. 2009  



Логично использовать какую-то целостную парадигму, разве нет? Улыбка

Состояния объектов = свойства объектов я имел в виду в данном случае.

PS: И как удалось прицепить еще и АОП сюда?
 
 Top
Admin Администратор Post Id


Администратор


Сообщений всего: 897
Дата рег-ции: Май 2006  



-dead- пишет:
Логично использовать какую-то целостную парадигму, разве нет?


Все зависит от задачи и того, что мы хотим получить.
Следование стандартам какой-либо парадигмы упрощает решение, но далеко не всегда делает его лучше.

-dead- пишет:
Состояния объектов = свойства объектов я имел в виду в данном случае.


Эко Вас понесло. Голливудская улыбка No comments.

-dead- пишет:
PS: И как удалось прицепить еще и АОП сюда?


Это Вы прицепили, заметьте. Улыбка

-dead- пишет:
Но тогда это скорее должно называться State-driven-programming, чем Event-driven-programming.
 
 Top
-dead- Post Id


Президент


Сообщений всего: 966
Дата рег-ции: Февр. 2009  



И как же оказалось связано State-driven programming и Aspect-oriented programming?

PS: Меня не понесло, вы к словам не придирайтесь и из контекста не вырывайте, я с самого начала рассматривал свойство состояния кнопки - нажата или нет.

Дальше обсуждать это смысла не вижу. Вам уже явно не интересна эта тема. А зачем обсуждать что-то с человеком, которому это не интересно? Мне незачем.

(Отредактировано автором: 21 Июня, 2011 - 21:12:31)

 
 Top
Admin Администратор Post Id


Администратор


Сообщений всего: 897
Дата рег-ции: Май 2006  



-dead- пишет:
И как же оказалось связано State-driven programming и Aspect-oriented programming?


Я под "АОП" имел ввиду "Автоматно-ориентированное программирование" (State-driven programming), а не "Аспектно-ориентированное программирование". Извиняюсь, надо было "АП". Смущение, стыд

-dead- пишет:
PS: Меня не понесло, вы к словам не придирайтесь и из контекста не вырывайте, я с самого начала рассматривал свойство состояния кнопки - нажата или нет.


Я не придираюсь. Наоборот, я Вам очень благодарен за поднятую дискуссию. В результате полез в код и поправил некоторые моменты, от которых зависело быстродействие обработки. А так бы руки не дошли. Улыбка

PS' "свойство состояния кнопки" - это потрясающе!

PS'' Большое Вам спасибо. Не обижайтесь на меня, пожалуйста, за мою некоторую некорректность. Смущение Мне доставляет большое удовольствие общение с Вами.
 
 Top
killgur Post Id



Гуру


Сообщений всего: 1189
Дата рег-ции: Февр. 2010  



Нажатие - отжатие это не свойства а события.
 
 Top
-dead- Post Id


Президент


Сообщений всего: 966
Дата рег-ции: Февр. 2009  



Ну значит и я вас не так понял с АОП, потому что по этой аббревиатуре гугл и вики выдали ровно аспектно-ориентированное программирование.

Я под термином State-driven programming имел в виду не аналогию конечным автоматам, а выполнение кода в зависимости от каких-то текущих состояний системы, например основной цикл программы, в котором среди прочего написано "Если сейчас нажата кнопка Х, то сделать Y". А не "если сейчас мы находимся в состоянии Х, то сделать Y и перейти в состояние Z". Видимо зря, термин уже заняли Улыбка

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

Нажатие и отжатие это событие. Не спорю, но речь о том, что код работает столько раз сколько успеет, и вроде как каждый раз как "если в данный момент нажата кнопка Х, то сделать Y". Или я таки не правильно понял? Улыбка если правильно понял, то отличие от классического подхода к событиям в том, что обычно количество сгенерированных событий никак не зависит от количества событий, которые успели обработать. И их обычно генерируется некоторое количество, зависящее от генератора, но не от обработчика.

(Отредактировано автором: 21 Июня, 2011 - 22:06:42)

 
 Top
cjA Post Id



Генерал


Сообщений всего: 3291
Дата рег-ции: Янв. 2010  



-dead-
это слишком. пожалуй, )))))))))
 
 Top
Admin Администратор Post Id


Администратор


Сообщений всего: 897
Дата рег-ции: Май 2006  



-dead- пишет:
код работает столько раз сколько успеет


А где это не так?

-dead- пишет:
вроде как каждый раз как "если в данный момент нажата кнопка Х, то сделать Y". Или я таки не правильно понял?


Нет, не так. Нет никакой проверки в главном цикле. Используются стандартные события KeyDown и KeyUp.

-dead- пишет:
если правильно понял, то отличие от классического подхода к событиям в том, что обычно количество сгенерированных событий никак не зависит от количества событий, которые успели обработать. И их обычно генерируется некоторое количество, зависящее от генератора, но не от обработчика.


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

-dead- пишет:
их обычно генерируется некоторое количество, зависящее от генератора, но не от обработчика.


Да, но вопрос обычно заключается в том, что делать с этой "нагенерированнной" кучей. Еще раз подчеркну, основной вопрос далеко не в регистрации нажатия на клавишу, а в том, что с этой регистрацией делать. А у Вас получается, что главный вопрос - "зависит - не зависит".
 
 Top
-dead- Post Id


Президент


Сообщений всего: 966
Дата рег-ции: Февр. 2009  



Тогда значит есть шанс, что я вас изначально не так понял.

То есть в GameLOGO есть некоторое ограничение на количество событий "нажата клавиша вверх" в единицу времени не связанная напрямую с временем обработки тех или иных событий в программе, правильно?
 
 Top
Admin Администратор Post Id


Администратор


Сообщений всего: 897
Дата рег-ции: Май 2006  



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

Кроме того, не совсем понятны слова "нажата клавиша вверх" и что понимается в данном случае под "количество событий". А также к чему относится "не связанная".
 
 Top
-dead- Post Id


Президент


Сообщений всего: 966
Дата рег-ции: Февр. 2009  



Понятно, KeyPress вы не используете. Поэтому вы сами занимаетесь генерацией этих события на основании того, что было KeyDown, еще не было KeyUp, но обработчик сейчас может обработать, поэтому нате, получите событие и обработайте, так?
 
 Top
Страниц (7): « 1 2 [3] 4 5 6 7 »
« GameLOGO »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 





Powered by Exclusive Bulletin Board
ExBB FM 1.0 RC1 Smiles by Fool from Foolstown
  Яндекс.Метрика   Рейтинг@Mail.ru