Reaction: r315
Sergey Schetinin
Я как-то не понял логики вот этого изменения:
http://code.google.com/p/trellis-fork/source/diff?spec=svn315&r=315&format=side&path=/trunk/mext/reaction/wx_utils.py
Если таймер сработал идеально вовремя мы зачем-то его не обрабатываем
а откладываем. Причем на tick_no это никак не влияет. Если это не так,
то в любом случае нужен тест-кейс.
(Заодно просмотри-примени code-review
http://code.google.com/p/trellis-fork/source/detail?r=310 пжлст)
--
Best Regards,
Sergey Schetinin
http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter
Andrew Svetlov
On Oct 31, 6:54 pm, Sergey Schetinin <mal...@gmail.com> wrote:
> Андрей,
> Я как-то не понял логики вот этого изменения:http://code.google.com/p/trellis-fork/source/diff?spec=svn315&r=315&f...
>
> Если таймер сработал идеально вовремя мы зачем-то его не обрабатываем
> а откладываем. Причем на tick_no это никак не влияет. Если это не так,
> то в любом случае нужен тест-кейс.
Буду делать. Похоже, на Висте таймер опять работает чуть-чуть не так,
как на XP.
А Clock имеет слишком строгие ожидания.
В любом случае - попробую сделать тест, а потом использовать твое
предложение из камментов к ревизии.
>
> (Заодно просмотри-примени code-reviewhttp://code.google.com/p/trellis-fork/source/detail?r=310пжлст)
>
Посмотрел, кое-что добавил/убрал.
Кэш для QComponent есть, и он не захватывает lock при импорте. Все
остальные случаи могут быть сколь угодно медленными - это должно очень
редко происходить.
Думаю, "на сейчас" можно оставить как есть.
callbacks нужен для правильной отписки - поправил. Тестов нет, на
самом деле в disconnect должен быть assertion. Как и в connect. Введу,
наверное, немного позже. Я только-только PyQt начал изучать, опасаюсь
сделать слишком строгие предположения.
Именование - спорный вопрос. В Qt все классы начинаются с Q, а не с
Qt. Стоит ли придерживаться этого правила - не знаю. Сейчас
непринципиально и можно быстро поменять.
Высвечивать QtCore в __all__ не имеет смысла - обычно нужен QtGui или
еще что более специфическое. Импортировать все - тоже глупо. Пусть
будет как есть. Судя по коду, который видел - нет общего правила вроде
"делай import wx" - каждый крутит как ему нравится.
Еще вопросы/предложения есть?
Sergey Schetinin
>
>
> On Oct 31, 6:54 pm, Sergey Schetinin <mal...@gmail.com> wrote:
>> Андрей,
>> Я как-то не понял логики вот этого изменения:http://code.google.com/p/trellis-fork/source/diff?spec=svn315&r=315&f...
>>
>> Если таймер сработал идеально вовремя мы зачем-то его не обрабатываем
>> а откладываем. Причем на tick_no это никак не влияет. Если это не так,
>> то в любом случае нужен тест-кейс.
> Буду делать. Похоже, на Висте таймер опять работает чуть-чуть не так,
> как на XP.
> А Clock имеет слишком строгие ожидания.
> В любом случае - попробую сделать тест, а потом использовать твое
> предложение из камментов к ревизии.
Там проблема была в невезучем округлении float, таймеры и eloopы не при делах.
>>
>> (Заодно просмотри-примени code-reviewhttp://code.google.com/p/trellis-fork/source/detail?r=310пжлст)
>>
> Посмотрел, кое-что добавил/убрал.
> Кэш для QComponent есть, и он не захватывает lock при импорте. Все
> остальные случаи могут быть сколь угодно медленными - это должно очень
> редко происходить.
> Думаю, "на сейчас" можно оставить как есть.
Мне qt в целом без разницы, поэтому мне и qt_utils без разницы
выходит, но как-то много кода там ненужного с этими локами. В смысле
что локи то не нужны вовсе если сделать setdefault, там строчек десять
сразу уйдет и по скорости натурально быстрее будет -- никто не будет
смотреть на локи и всё такое.
> callbacks нужен для правильной отписки - поправил. Тестов нет, на
> самом деле в disconnect должен быть assertion. Как и в connect. Введу,
> наверное, немного позже. Я только-только PyQt начал изучать, опасаюсь
> сделать слишком строгие предположения.
>
> Именование - спорный вопрос. В Qt все классы начинаются с Q, а не с
> Qt. Стоит ли придерживаться этого правила - не знаю. Сейчас
> непринципиально и можно быстро поменять.
> Высвечивать QtCore в __all__ не имеет смысла - обычно нужен QtGui или
> еще что более специфическое. Импортировать все - тоже глупо. Пусть
> будет как есть. Судя по коду, который видел - нет общего правила вроде
> "делай import wx" - каждый крутит как ему нравится.
Ок, понял.
> Еще вопросы/предложения есть?
Есть просьба быть аккуратнее с коммитами, фиксы делать аккуратней и не
пропускать файлы при коммите. Мне чего-то кажется что это привычка к
dvcs так влияет, но в общем за коммитами надо следить внимательней. А
так выходит что мне надо тщательно каждый коммит просматривать потому
что у меня же не Реакции софт крутится и расхлябанность недопустима. А
вот эти просматривания опять таки приходятся на произвольные моменты в
работе которые иногда оказываются очень неудачными. В общем я не
уверен как быть. То есть в итоге то изменения выруливают в хорошую
сторону, но вот этот их эффект мне не нравится. С бранчами и их мержем
в svn некоторый гемор так что я уже подумываю насчет dvcs (mercurial
просто потому что мне с ним пришлось освоиться для продолжения работы
над webob).
И насчет вопросов в комментариях в исходниках -- лучше задавать их в
рассылке. Я иногда пишу вопросы в исходнике но это не вопрос "почему я
сделал тут так?" а вопрос нерешенный. В смысле что я на некоторые
такие вопросы смотрю и не понимаю что с ними делать -- отвечать там
же? Так исходники разрастутся. В общем такого рода координацию надо
искать другие способы делать я так думаю.