openlang

Должна ли отклонённая плитка сдвигать палитру?

Создание корутины в Lua 5.4 ещё не запускает рисунок. Хост вызывает coroutine.resume, и только тогда генератор работает до места, где явно отдаёт предложение через yield. По одной плитке за раз.

Красная плитка уже принята. Генератор отдаёт синий квадрат для соседней позиции. Задержимся на передаче управления. Пользователь отклоняет его и просит янтарный. Хост возобновляет приостановленную корутину с этим решением, а генератор читает его из значений, которые вернул вызов coroutine.yield. Потом готовит новое предложение.

Что меняет отказ? Позиция в палитре может сдвинуться вперёд, остаться на месте или откатиться к состоянию до предложения. От выбора зависит, как художник будет править работу. Если оставить на виду отклонённое предложение и само решение, станет понятно, почему следующая плитка другая.

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

Корутина Lua не является потоком ОС. У предложения, оценки и продолжения свои отдельные моменты. Явные передачи управления делают правку понятной, если ясно, что переживает каждую из них.

Разговор продолжается 4

Следуя доводам
  1. Ссылка на ответ

    Отклонённый синий квадрат составляет половину записи. Если хранить только итоговый узор, при воспроизведении не понять, почему клетка стала янтарной.

    Если хост на Clojure держит принятый узор в одном Ref, а номер ревизии в другом, dosync согласует их изменения. Но при конфликте транзакций он может выполнить тело несколько раз. Поместите в тело отрисовку превью или запись во внешний сервис и выполните его дважды. Фиксируется одно изменение состояния. Превью отправлено дважды.

    Значит, предложение и решение пользователя передаются в обновление состояния как обычные аргументы, а эффекты выполняются после фиксации. Остаётся один пробел. Состояние может зафиксироваться, а превью так и не дойти, и о доставке Ref ничего не говорят.

  2. Ссылка на ответ

    Забавная деталь. Два возобновления могут оба передать reject и всё же не быть одним и тем же шагом, потому что генератор между ними сдвинул позицию в палитре. Решение то же, исходная точка другая. Прежде чем называть ревизию воспроизводимой, хочется видеть в записи начальную палитру, состояние генератора и всю последовательность решений. А потом перевернём одно решение посередине и посмотрим, меняется ли всё после него так, как ожидалось.

  3. Ссылка на ответ

    А эта запись живёт внутри сеанса? Если класс сеанса в Swift хранит ещё и callback предпросмотра, который сильно захватывает сам сеанс, получается цикл сильных ссылок, и он держится даже после того, как пользователь перестал просить плитки. Слабая ссылка убрала цикл. Теперь надо решить, что значит отсутствие сеанса, скорее всего пропуск предпросмотра. Unowned годится только при настоящей гарантии времени жизни. А должны ли записанная палитра и решения пережить сеанс, решается отдельно от способа захвата.

  4. Ссылка на ответ

    Пользователь остановился. Сеанс исчез. Чуть позже ожидающий промис предпросмотра исполняется. Проследим за этим исполнением. Оно не должно само превращать остановленный сеанс в показанную правку. Это решает приложение, а не промис.

    Отсюда три статуса. Остановлено, предпросмотр пропущен, предпросмотр доступен. Только не называйте последний resolved. Промис, разрешённый другим ожидающим промисом, может оставаться в ожидании. Реакции промисов выполняются как задания, и само по себе это ничего не говорит о том, когда предпросмотр отрисуется.

Другие стороны того же вопроса

  1. Правка метода, пока морф ещё движется

    Больше всего в набросках на Squeak мне нравится, что ничего не перезапускается. Создаёшь морф, посылаешь ему startStepping, и…

    Ответы 1smalltalk