zumm Cyapa

Авиамодельный пульт больше похож по своему функциональному назначению на геймпад, поэтому в дальнейшем я иногда буду использовать термин «геймпад».

И дальше по тексту почти везде написано «джойстик». :)

Согласен, технология дорогая. Но за удобство абстракций всегда приходится платить, верно?

А вот накладку в реализации стандартной библиотеке сложно относить к минусам именно самой технологии. Кстати, спасибо что поделились этой информацией, не находил упоминаний об этом ранее.

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

P.S.: Забавно, что этот автор тоже ссылается на переведенный здесь цикл.

Читая комментарии, часто натыкаюсь на хвалебные оды фентропилу. Потому хочу поделиться своим негативным опытом его применения.

Предыстория такая:
Еще в детстве мне поставили диагноз «Внутренняя открытая гидроцефалия». Ну и ВСД потом.
В связи с этим меня частенько мучили головные боли, характерной чертой которых был очаг в районе правой стороны переносицы. Со временем почти сошло на нет. Боли такого характера стали крайне редкими.

И вот, в мои 20 лет, Родина решила, что мне пора отдать ей свой долг. Мне этого делать не хотелось, и вспомнив про свою болячку я пошел к неврологу, чтобы он мне там понаписал всякого для военкомата. В ходе этого процесса, невролог мне выписал фенотропил. Говорит с твоей болезнью его нужно периодически курсами принимать. Да и вообще для мозга полезно.

Я стал принимать его по рецепту. Никаких улучшений я не заметил. А к середине курса у меня и вовсе возобновились эти характерные головные боли. Я не придал значения этому и допил курс до конца.
Почти сразу после окончания курса боли отступили. Со временем я начал замечать незначительные ухудшения памяти.

Пришло время следующего курса. Я снова начал пить фенотропил. И снова к середине курса у меня возобновились головные боли. Поняв что к чему, я не стал пить его дальше.

Со временем я понял, что память у меня серьезно ухудшилась. Ухудшились так же концентрация и быстрота мышления. Ни с чем другим, кроме как с приемом фентропила я это связать не могу.

Сейчас мне 23 года, каких-то подвижек к восстановлению или дальнейшему ухудшению перечисленных когнитивных функций не вижу.

Я понимаю, что мой опыт довольно специфический, но все же к приму этого препарата стоит отнестись с осторожностью.

P.S.: Спустя какое-то время мой друг решил пропить фенотропил для стимуляции мозговой деятельности. Я отдал ему остатки своего препарата. Никаких ощутимых положительных или отрицательных эффектов он не заметил. Но и пил его не долго.

P.P.S.: Если кому вдруг интересно, от долга перед Родиной моя болячка меня не избавила. :)

8…

Да, ровно так сейчас и вышло. У операций уже до этого были ID, так что с этим проблем не возникло.

Видимо, я хочу от встроенного механизма конечных автоматов слишком многого. :) Ну или моя задача не особо на них (на конечные автоматы, в смысле) ложится и я пытаюсь притянуть ее за уши.

По мере разработки таки наступила ситуация, где без дополнительного сообщения пока не получается выкрутиться.

Стало нужным добавить таймаут для команд. И тут бы идеально подошел time_limit для состояния st_wait_perform. Но так как после таймаута нужно начать выполнять следующую команду из очереди (если она есть), а соответственно и менять состояние обратно на st_wait_perform, то в методах on_enter/on_exit не выйдет обработать событие таймаута. Потому придется слать отложенное сообщение, судя по всему.

Ну да, ситуация не простая. Варианты, конечно, все еще есть. Но они, наверное, сделают ситуацию только еще более запутанной.

Хотя и если реакция зависит от состояния агента, то, вопрос, конечно становится несколько более сложным. Возможно, лучше использовать реакцию кооперации.

Да, это понятно, что возникают проблемы с исключениями при смене состояний.
Просто логично было бы предположить, что SO будет действовать согласно so_exception_reaction, а не просто вызовет std::terminate. Тот же самый рестарт агента может быть логичным поведением программы в подобных случаях.

Выходит, его нельзя использовать *

А расскажите, пожалуйста, про ваш случай подробнее.

У меня есть некий агент, который может выполнять внешние команды. Выполнение команды связано с IO операциями и занимает время. Параллельно выполнять команды нельзя.

Агент принимает команды и складывает их в очередь. В числе прочих, агент имеет такие статусы как st_wait_command и st_wait_perform. Пока выполняется команда агент находится в состоянии st_wait_perform. После выполнения команды нужно начать выполнять следующую команду из очереди, если она не пуста. Или же вернутся в состояние st_wait_command.

И вот код по началу выполнения следующей команды было бы удобно разместить в on_enter состояния st_wait_comman. Тогда оставалось бы просто перейти в состояние st_wait_command после выполнения команды.

Сейчас я уже нашел более-менее подходящее решение — вместо перехода в статус st_wait_command вызывать отдельный метод, который решит нужно ли менять состояние или же начать выполнять новую команду. Это работает, но эстетически смущает. Ведь этот метод занимается как раз тем, чем должен бы заниматься on_enter.

Не noexcept, send может бросать исключения.

Выходит, если нельзя использовать внутри on_enter/on_exit без try/catch (как вы делаете у себя в примере).

Как мне кажется, за зацикливанием должен следить все таки пользователь библиотеки. А то ведь при желании зацикливание можно и другими средствами организовать.

А при таких раскладах приходится слать дополнительное, совершенно не нужное, сообщение для смены состояния.

Кстати, на счет noexept, so_5::send ведь не noexept?

Хм, довольно неожиданно, что из on_enter одного состояния нельзя перейти в другое состояние.
Было бы не плохо этот момент хотя бы немного осветить в этой статье.

Тема stage-агентов оказалась гораздо глубже, чем можно было подумать на первый взгляд. :) Кстати, это довольно не плохая тема для статьи — плюсы и минусы, практика использования, предпосылки к применению, особенности реализации поверх SObjectizer.

Наоборот, статьи довольно интересные. Затрагиваются реальные проблемы, доходчиво объясняются их причины и решения на итерационных примерах улучшения кода. Это очень круто и почитать статьи интересно даже в отрыве от SObjectizer. Хочется надеяться, что комментариев нет только потому, что людям нечего добавить, а просто писать «спасибо за статью» на хабре не принято. :)

Итого, выходит что разница между обычным агентом и stage-агентам только во времени жизни. Эдакий синглтон.
Теперь стало понятнее. Спасибо за пояснение!

Странно, что к вашим статьям так мало комментариев.
Во многих их нет вообще. Пожалуй, оживлю немного ситуацию, хоть это и некрофильство.

В ходе прочтения вашего цикла статей у меня возник вопрос: вы говорите, что IO-агент из предыдущих статей является stage-агентом, потому как он занимается только IO операциями. Следуя этой логике можно было бы заметить, что остальные агенты, для обработки частей email'а тоже занимаются только своим делом. Но почему же тогда они не являются stage-агентами?

Ну что ж, буду надеяться на продолжение! Очень подробные статьи у вас — одни из лучших по Rust. Жаль будет, если все прервется.

Прошло больше года, а продолжения все нет. :(

Домен угнали, а комментарий теперь никак не изменить. :(

http://sms-area.org/ теперь ведет туда, куда раньше вел домен в комментарии выше.

Эпопея с Novec тянется с 2004 года, ровно как и потребительский интерес к ней. И все же, за 12 лет дальше баллончика для очистки потребительский уровень не продвинулся. А ведь много кто хочет себе домашний ПК с погружным охлаждением.

Прецеденты были, к примеру Zotac Vapor Phase в 2012 году. Но дальше тестового стенда дело не пошло.

В теории, что мешает организовать аквариум с этой жидкостью, закрытый алюминиевой или медной крышкой в качестве радиатора? Novec 1230 разрушается под действием ультрафиолета, насколько я понял. Но с той жидкостью, что использована в посте (что-то из серии Novec 7XXX?), явно нет таких проблем, ведь так?

Я бы сам с радостью попробовал, изготовить аквариум и крышку — не проблема. Проблема в том, чтобы купить эту жидкость. На сайте все цены «уточняйте по телефону», что как бы намекает на то, что купить придется не меньше 1000 литров по цене Over9000. А нужно то не больше 20.

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

До коли 3M будет обходить простых смертных стороной?

Почему нет? Их и сейчас то тысячами регистрируют, а когда телефон не нужен был так и подавно.

Похоже на то. Выходит, он вполне себе может концентрироваться на каком-нибудь деле хоть весь день. А «обнуление» происходит ночью потому, что во сне ничего не происходит (нет никаких мыслей) дольше 90 минут.

Очень надеюсь на скорейшее решение проблем с форматированием макросов. Как только выйдет — сразу приобрету такую замечательную IDE. :)

В «Wrapping & Braces | Function call arguments» я копался, особо положение дел не меняется. А вот установка «continuation indent» в ноль более-менее помогла, спасибо. Теперь просто аргументы вручную отбиваю. Но, все же, хотелось бы иметь отдельные настройки отступов для аргументов и скобок.

А почему бы не сделать отключение форматирования во всем проекте, кстати? Думаю, иногда это было бы полезно. Особенно, если бы можно было отключать не все форматирование, а только какую-нибудь особо докучающую часть, настроек для которой пока нету/не планируется.

Ишью завел. Но в силу моих скудных знаний английского, описание кривое и короткое. :)

Я не нашел настроек для форматирования тех случаев, что я указал.
Смотрел тут: File -> Settings -> Editor -> Code Style -> C/C++

Друзья, подскажите, а можно ли как-то отключить автоформатирование кода? Все излазил — не нашел.

Я, наверное, извращенец, но мне удобнее оформлять инструкции препроцессора отступами (особенно в кроссплатформенных проектах это чувствуется). Например:

#ifdef OS_POSIX
    #define POSIX_THREAD
    //тут обычный код
#else
    //тут тоже код
#endif

А IDE постоянно съедает эти отступы.

Так же очень докучает навязчивое форматирование аргументов при вызове функций. При вот таком написании:

SomeVar = SomeFunction
(
    LongLongArgument1,
    LongLongArgument2,
    LongLongArgument3
);

Творится сущий ад. А уж если вдруг нужно написать вот так:

if
(
    SOME_CONST == SomeFunction
    (
        LongLongArgument1,
        LongLongArgument2,
        LongLongArgument3
    )
)
{
    //тут код
}

То все, пиши пропало. Не работает ни таб, ни shift-tab, ни space. ни enter. При нажатии на любой из них код, простите за выражение, распидорашивает по самое не балуйся.

Все это сильно тормозит работу и сводит на нет плюсы IDE.

P.S.: А еще этот косяк с CMake: путь вида D:\ProgramFiles(x86)\JetBrains\CLion\bin\cmake\bin\cmake.exe нужно брать в двойные апострофы при генерации make файлов, но этого не происходит. В итоге ничего не собирается. Благо это легко решается символьной ссылкой.

Лурк уже и без этой цитаты заблокирован.

Этот пример с JS.

Все тоже самое, что и в примере, только label'ы будут внутри li. :) Ну и селекторы немного подправить.

В том то и дело, что имитация без использования JS. С JS любой дурак может. :)

По поводу кастомизации checkbox/radio — единственный адекватный вариант это сделать, все так же через label и :checked.
Возможности кастомизировать select до сих пор не появилось. Добавился appearance: none, который позволяет кастомизировать нераскрытый select, но стилизация пунктов стоит на месте.

Можно добавить пустой пункт.

Почему же IE не оценит? IE очень даже оценил. В 9 все работает, в младших версиях проверить не было возможности, но, если там работает for для label, то все будет работать.

Багов не так уж и много. Из ощутимых только то, что не сворачивается select при клике мимо него.

Добавил этот пункт в пост. Спасибо.

Пораскинул мозгом и таки удалось исправить этот момент — вот.

Отредактировал пост.

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

Например, если переопределить размеры select из статьи через rem, а сам размер шрифта задавать в зависимости от разрешения экрана через @meadia запросы, то должно получиться вполне сносно.

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

У меня, к сожалению, нет сафари. Быть может, проблема в этом?

Да, я это упомянул в минусах. Возможно, у кого-то есть решение этой проблемы?

Кстати, это можно рассматривать как фичу: не закрывается для того, что бы не сбиться случайно :)