eu_tomat

И что игроку даст её использование?

У меня встречный вопрос. Зачем было дублировать своё сообщение в теме про SwiftOS после того, как я перенёс его?

Я перетащил. В теме про SwiftOS эти сообщения не несли никакой смысловой нагрузки. Зачем читателям той темы знать о том, что кто-то кого-то задрал? Здесь же эти сообщения смотрятся более естественно и логично.

А вопрос в чём?

А я тогда удивлялся, как же ты так быстро переписываешь эти луашки. А вот он, оказывается, секрет:

О чём идёт речь в этой фразе? На каком языке она написана? Что в этой фразе значит "только"? Как обрабатывать находящихся в белом списке?

Для реализации кроссплатформености потребуется придумать какой-то стандарт хранения данных и в дальнейшем следовать ему. Данные в EEPROM могут храниться хоть в текстовом, хоть в двоичном виде. Но хранение файла конфигурации в виде текста способно обеспечить высокий уровень кроссплатформенности с минимальными накладными расходами. Игрок может скорректировать файл конфигурации, воспользовавшись любимым текстовым редактором, а затем твоя утилита считает данные из файла, приведёт информацию к более компактному виду и запишет данные в EEPROM. Главное, в каждом конкретном случае дать игроку внятную документацию, объясняющую, что даёт изменение того или иного параметра, и каковы их рабочие пределы. Я знаю два эффективных текстовых формата в среде Lua: это либо формат сериализованной таблицы, либо это обычный код на Lua. Второй формат обеспечивает лучшую производительность и гибкость. Дав пользователю возможность отделить данные от кода в тех случаях, когда они и так фактически разделены, ты можешь сделать свою утилиту более полезной. Она, может, и не станет настолько же универсальной как flash из OpenOS, но хотя бы обеспечит большее удобство решения какого-то круга задач. Это верно. В дальней перспективе имеет смысл разрабатывать удобные универсальные программы, способные заменить кучу других программ. Только нужно иметь в виду, что абсолютно универсальных инструментов не существует, а для достижения подобия универсальности мы по сути придумываем технологию, некий стандарт, в который потом пытаемся втиснуть решаемые задачи. И тогда стандарт может начать работать не только на нас, но и против нас. Например, ты мне прислал файл прошивки вместе с данными, а я эти данные скорректировал под свои нужды. Затем ты исправил ошибку в прошивке и снова выслал мне файл, в котором я вынужден ещё раз корректировать эти данные, хотя я бы предпочёл иметь возможность просто выбрать файл с нужными мне данными во время прошивки. Это пример затруднений для пользователя. Но затруднения от поспешно принятого стандарта возникают и у разработчика. Не знаю, как это работает у тебя, но мне обычно требуется решить хотя бы 5 похожих задач, что начать серьёзно думать над какими-то стандартами их решения. Первые мысли появляются уже при решении второй задачи, но это просто мысли. Максимум, что полезного можно сделать с ними — просто записать на будущее. Но реализовывать их я обычно не спешу. Можно, конечно, поспешить, но тогда при решении очередной задачи старые стандарты потребуется корректировать. А это уже дополнительный объём работы. А если ты ранее смог убедить других программистов использовать свой стандарт, то и они будут вынуждены приложить усилия, чтобы переписать свой код под новые требования. Стандарты призваны облегчать работу, а не затруднять её.

А какие имеются причины для сомнений? Потребление ресурсов на хосте находится в пределах нормы. Я заходил 5 минут назад. Выполнил 3 отдельных крафта. Каждый получился с первой попытки.

Я теперь понял, в чём дело. Я уже несколько раз обратил внимание на то, как надолго система зависает при входе. И когда ты второй раз упомянул про TLWY в этом месте, я предположил, что система застревает в каких-то своих тяжёлых вычислениях, а у тебя недостаточно мощный комп, чтобы успеть их выполнить за разумное время. После этого я смог воспроизвести проблему. Подтверждаю. Иронично, что система, нацеленная на противодействие TLWY, сама не может авторизовать пользователя по причине TLWY. Система, конечно, любопытная, поэкспериментировать с ней интересно, есть что обсудить. Но в текущем виде это всё-таки неоправданный лагодром.

Ранее я дал приблизительную оценку производительности: А теперь решил выполнить реальные замеры производительности. Для получения более полной картины требуется провести длинную серию экспериментов, но для начала достаточно и этого. OpenOS: lua> time=computer.uptime t0=time()for i=1,1e8 do end print(time()-t0) 1.35 lua> time=os.clock t0=time()for i=1,1e8 do end print(time()-t0) 1.307 Цикл под Cynosure создаёт более высокую нагрузку на Cpu и поэтому часто обрывается ошибкой TLWY: lua> time=require"computer".uptime t0=time()for i=1,1e8 do end print(time()-t0) -- две первые попытки оборвались ошибкой TLWY -- 3-я попытка: 200.45 lua> time=os.clock t0=time()for i=1,1e8 do end print(time()-t0) -- 4 первые попытки оборвались ошибкой TLWY -- 5-ая попытка: 85.68 Итоги: Среда Cynosure замедляет выполнение пустого цикла в 148 раз по сравнению со средой OpenOS. Выполнение пустого цикла в среде Cynosure снижает среднюю вычислительную нагрузку примерно в 2.26 раза, что вроде бы должно радовать, но это снижение не компенсирует возросшую длительность выполнения цикла. Среда Cynosure увеличивает итоговую вычислительную нагрузку при выполнении пустого цикла в 65 раз по сравнению со средой OpenOS. Не смотря на принятые меры по противодействию TLWY, они не снимают проблему.

Да, автор темы первой же ссылкой указал именно на этот файл. Я тоже открыл его, но пошёл немного другим путём. Увидел ключевые слова do, repeat, и сразу вспомнил про goto. Обрушил систему этим кодом: ::c::goto c Правда, чтобы упала и система, надо придушить ресурсы процессу Майнкрафта. Собственно, OpenOS ведёт себя похожим образом: программы вылетают с ошибкой TLWY, но сама OS продолжает работать. Но если эти трудные моменты выпадают на рестарт сервера, то падает и сама система, уже с синим экраном.

@ProgramCrafter А тут символ выбирается исключительно по его коду, или есть возможность как-то пролистать страницы с визуализацией самих символов? И ещё: можешь как-то обрезать нижнюю неинформативную часть картинки с чёрным фоном?

Вот прямо сразу после приветствия? Вообще интересно стало. Unix-like, конечно радует, но производительность в простых циклах очень огорчает.

Учитывая твоё стремление к максимальному увеличению функциональности прошивок, я предполагаю, что ты постараешься использовать все доступные возможности для сжатия. И раз ты уже начал использовать область данных, то следующим шагом будет сжатие обоих кусков EEPROM как одного большого куска. Просто потому, что такое сжатие будет более эффективным. Но такое развитие возвращает нас к специализированной утилите, упаковывающей код в EEPROM. Но, предположим, ты всё-таки не будешь сжимать блок данных: Да, существование ПО, параметры которого заданы извне, вполне возможно. Но в таких случаях к самому ПО прилагается и дополнительная утилита, обрабатывающая все необходимые проверки и умолчания. Также эту задачу зачастую перекладывают на документацию, текстовый редактор и голову системного администратора, такой подход тоже может быть удобным. Но применительно к обсуждаемой утилите он как раз неудобен из-за объединения в одном файле блока параметров с блоком кода, что усугубляется двоичным представлением сжатого кода. И это снова возвращает нас к специализированной утилите, написанной под конкретную задачу. Другу потребуется выполнить следующие действия: скачать твою утилиту прошивки, скачать файл прошивки, скопировать строку запуска утилиты. А если всё это делать без твоей утилиты, то потребуется: скачать файл прошивки, скачать файл параметров (если требуется), скопировать строку, заполняющую код и данные EEPROM. В принципе, все эти три действия можно объединить в одну строку. Но в любом случае второй подход создаёт меньший трафик в сети и увеличивает надёжность за счёт исключения лишнего звена. Это я понял. Только я не вижу тут универсального применения в отличие от утилиты flash. Пока я вижу лишь специальные случаи, в которых применение универсальной утилиты не даёт никаких преимуществ. Твоя утилита, конечно, имеет право на существование, но, скорее, как экзотика для гурманов, а не замена стандартной утилите.

Как думаешь, почему так мало шансов на принятие? Ты же понимаешь, что данные на то и данные, что зависят от конкретных условий и могут меняться? А если эти данные могут меняться в процессе работы, то что мешает в процессе же работы их и сформировать? И эти данные никогда не меняются иначе как со сменой прошивки? Вот тут соглашусь, я и сам таким баловался. Правда, в том случае в первую очередь использовалось сжатие кода, т.к именно оно обеспечивало максимальную экономию памяти, поэтому чтение из области данных EEPROM возлагалось на распаковщик, а запись в EEPROM — на упаковщик. Заметной прибавки это решение не давало, порядка 5%, но поиграться с дополнительной памятью было увлекательно. Если сейчас мы с тобой говорим об одном и том же, то речь всё-таки идёт о специализированной утилите под конкретную задачу. Но тогда сравнение со стандартной утилитой flash становится неуместным, потому как она предназначена для широкого круга более-менее стандартных задач, а твою утилиту я бы даже не стал как-то отделять от пакета программ упаковки.

@ProgramCrafter Спасибо. Теперь мне всё ясно. Падает не только сама проблемная программа, но и вся система. Падение по TLWY воспроизводится так: Запускаем программу: local count =0 for i=1,1e8 do count = count+1 end print(count/1e6) Ограничиваем вычислительные ресурсы сервера Дожидаемся синего экрана с надписью TLWY То есть, заявленная задача не решена: падает не только приложение, но и вся система. А самое интересное заключается в том, что решение, о котором я недавно рассказывал, к падению не приводит, и при этом раз в 50 меньше нагружает сервер:

@ProgramCrafter А тебе удалось разобраться, как в этой системе создать новый файл или изменить имеющийся? А то мне эта система при любой попытке записи говорит "device is readonly".

Я даже нашёл свой старый пост, в котором когда-то обсуждал этот способ решения проблемы:

Борьба с ошибкой "too long without yielding" или борьба за параллелизм не являются абсолютными целями. Вопрос всегда в цене этой борьбы. У нас на форуме где-то имеется тема, в которой один из наших товарищей тоже писал многозадачную систему. И одной из идей также было вставлять в разные места программы какой-то сервисный код, который мог бы приостановить выполнение потока. Решение рабочее, но его производительность оставляет желать лучшего. А в реализации с coroutine.yield в каждой итерации цикла и вовсе замедлит выполнение программы раз в 100. То есть, программа будет выполняться в 100 раз дольше, сохраняя ту же нагрузку на игровой сервер. Мне это кажется слишком высокой платой как за параллелизм, так и за возможность забыть об ошибке TLWY. Тем более, TLWY преодолевается и без использования специальной операционной системы.

Данные EEPROM, конечно, полезны. Но зачем хранить их вместе с прошивкой, если они содержат уникальные, практически не повторяющиеся адреса? Тем более, какой смысл переносить данные с уникальными адресами на другой сервер? Достаточно было бы добавить в утилиту прошивки опцию, запрашивающую очистку данных, если очень нужно. Но нужно ли? Ты же совсем недавно пропагандировал следование стандартам. А стандартная прошивка Lua BIOS успешно справляется с некорректными данными в EEPROM. И не просто справляется, а сама корректирует неверные данные. То есть, проблемы нет. Или от следования стандартам ты уже отказался? Опцию защиты от записи, пожалуй, можно было бы и добавить в утилиту прошивки. Но какой смысл хранить это состояние в файле вместе с прошивкой? Решение о защите должен принимать игрок, исходя из его текущих потребностей, а не автор прошивки. Автор может лишь рекомендовать установить защиту, указав соответствующий флаг в строке запуска утилиты. Метку EEPROM можно задать опцией командной строки с помощью стандартной утилиты. А учитывая, что для прошивки всё равно требуется запустить командную строку, то не составляет никакой проблемы добавить метку в неё, а не в файл прошивки. Похожая история однажды приключилась и со мной. Я тоже модифицировал утилиту flash и тоже выдумал свой формат, который, к слову, был полностью совместим со стандартной утилитой. В тот раз я поставил задачу хранить метку в одном файле с прошивкой. Это позволило мне быстро (с интервалом примерно в 2 ммнуты) создавать новые версии прошивок и при этом легко ориентироваться в содержимом инвентаря. Стандартную утилиту я успешно модифицировал, решение работало, но я посчитал его неудачным. Для моей специфической одноразовой цели проще оказалось хранить в одном файле с прошивкой не только метку, но и примитивный прошивальщик. А для широкого применения моя модификация оказалась и вовсе бесполезной, учитывая уже имеющийся функционал стандартной утилиты. Что можно сделать с утилитой из этой темы? В первую очередь я рекомендую обеспечить совместимость формата со стандартной утилитой. Это поднимет шанс того, что её начнёт использовать кто-то кроме автора. Может быть, кому-то и вправду потребуется хранить всё это в одном файле с прошивкой. Интересно будет узнать об этих случаях и потом сравнить удобство стандартной и модифицированной утилиты.

Это как? Что за механика такая?

Интересная возможность. А можно ли с помощью подобного функционала задать метку EEPROM?

Я вообще думал, что ты создал эту тему ради шутки. Как-то слишком удачно тут совпало отсутствие ссылки на программу с отсутствием потребности в ней. А фраза "идея подобной утилиты напрашивалась давно" ещё более усилила атмосферу абсурда. Хейтом принято называть открытое эмоциональное выражение ненависти, враждебности, злости. Собственно, английское слово хейт и означает ненависть. А что называешь хейтом ты? Но раз тема не шуточная, можно обсудить её по существу: Мне не приходилось сталкиваться с подобным. Приведи примеры программ, работающих некорректно из-за сохранения старых данных в EEPROM. И каким программам требуются данные по умолчанию?

Да, примерно так. Возможно, не 5 секунд, если изменить значение в файле конфигурации. И реальность времени там очень условна. Сколько времени займёт выполнение того или иного кода, спрогнозировать сложно. Но именно os.clock даёт точное понимание того, сколько этого времени осталось. Процесс не убивается, но генерируется исключение. Его можно перехватить, запустив код через pcall. Вместе с ошибкой TLWY ты получишь ещё 0.5 секунд времени на то, чтобы уступить время, например, вызвав computer.pullSignal, но успеешь ли ты это сделать, тоже никто не обещает. И новый слой оборачивания вызова кода в pcall уже точно не поможет. Рассматривай доступное тебе время как потребительский кредит. Возвращать его или платить по нему проценты не требуется, т.к. уступка времени закрывает предшествующий ей кредит. Главное, не превышать отпущенный лимит, значение которого всегда заранее известно. Проблема в том, что ты получаешь этот кредит всегда реальным товаром, стоимость которого узнаёшь лишь после совершения сделки. Пока не купишь, стоимость не узнаешь. А стоимость может меняться в значительных пределах, на несколько порядков. Закрытие кредита также имеет цену, заранее неизвестную. И если ты не страхуешься: не сохраняешь результаты предыдущих сделок и не резервируешь часть кредита на его гарантированное закрытие, то потеряешь всё. Выполнение тяжёлого фрагмента кода может оказаться неподъёмным, поэтому его следует дробить на куски помельче, проверяя оставшийся лимит после выполнения каждого из них. Но дробить код на совсем крохотные куски тоже не имеет смысла, т.к. проверка оставшегося лимита хотя и дешева, но тоже не бесплатна. Какую часть кредита использовать на выполнение целевого кода, какую потратить на проверку текущего баланса и фиксацию промежуточных результатов, а какую оставить в резерве на непредвиденное повышение стоимости финальных операций — зависит от характера задачи и конкретного сервера. Но если программисту приходится регулярно задумываться над этим вопросом, то что-то не так либо с сервером, либо его задачами, потому как сервер Майнкрафта не предназначен для тяжёлых вычислений. В первую очередь от тяжёлых вычислений надо постараться избавиться. Во вторую очередь тяжелые вычисления должны быть оптимизированы. И лишь в третью очередь следует подумать, как побороть TLWY.

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