Лидеры

Решил я сделать простые часы для декора. С реальным временем и с игровым. В итоге недолго почесав репу я сделал небольшую программу для Lua Bios на несколько мониторов (Копипаст но все же ) Получилась вот такая дребедень: Снизу показывается время игры а сверху реальное время. Время я получаю по tmp файлу записанного в оперативку. Требования к компу минимальные. Любая видюха, одна плашка памяти, процессор и сам биос с программой. Вот сам код: Надеюсь кому то как декор зайдут...

До поры до времени я преспокойно себе использовал OpenOS'овскую библиотеку для запросов и горя не знал. Однако вскоре все больше и больше убеждался в необходимости написания более функционального аналога, устав чистить вилочкой множество однотипных "велосипедов". Основные преимущества библиотеки: Рекурсивная сериализация Lua-таблиц в формат URL-кодированной строки Обработка серверных ошибок по принципу "success, reason" без необходимости использовать pcall в каждой программе Возможность прямой загрузки файлов с сервера в указанную директорию Возможность исполнения файла по URL как Lua-программы Поддержка ручной почанковой обработки загружаемых данных Команда для загрузки: wget https://raw.githubusercontent.com/IgorTimofeev/OpenComputers/master/lib/web.lua /lib/web.lua -f web.serialize( string/table data ): string serializedData Преобразует входной аргумент в сериализованную строку, соответствующую спецификации HTTP-запросов. Помимо строк и чисел поддерживаются также таблицы с множеством вложенных таблиц: print( web.serialize({ string = "Hello world", number = 123, array = { arrayString = "Meow", arrayInArray = { arrayInArrayNumber = 456 } } }) ) Результат: web.encode( string data ): string encodedData Экранирует специальные символы, делая строку подходящей для осуществления запросов с множеством специфических данных: print( "http://buttex.ru/test.php?message=" .. web.encode( "Привет, как дела?" ) ) Результат: web.request( string url, [string/table postData, table headers] ): string result, string reason Всем знакомый запрос к указанной URL, возвращающий строковый ответ с сервера. При указании аргумента postData сервер получит соответствующие данные в POST-массив, а при указании headers он получит кастомные заголовки. Для примера я создал PHP-скрипт на домашнем сайте, возвращающий GET/POST-данные запроса, так мы сможем легко отслеживать успешность передачи содержимого: <?php echo("\nСодержимое 'GET':\n"); print_r($_GET); echo("\nСодержимое 'POST':\n"); print_r($_POST); ?> Если требуется осуществить обращение к серверу, принимающему исключительно GET-запросы, используем сериализацию данных для удобства и присоединим результат к исходной URL: local result = web.request( "http://buttex.ru/test.php?" .. web.serialize({ string = "Hello", number = 123 }) ) print(result) В результате сервер вернул переданные данные GET-запроса: Осуществим POST-запрос к скрипту, указав таблицу в качестве аргумента postData: local result = web.request( "http://buttex.ru/test.php", { string = "Hello", number = 123 } ) print(result) Теперь сервер вернул переданные данные POST-запроса: web.download( string url, string path ): boolean result, string reason Метод для загрузки файла по URL в указанную директорию. Возвращает true в случае успеха и false, reason в случае неудачи. К примеру, следующий код загрузит в корень диска программу "матрица": web.download("https://raw.githubusercontent.com/IgorTimofeev/OpenComputers/master/Screensavers/Matrix.lua", "/matrix.lua") web.run( string url, ... ): ... Крайне полезная фича для быстрого запуска файла в виде Lua-программы, в которую передаются все указанные через "..." аргументы. Возвращает данные скрипта в случае успеха и false, reason в случае неудачи. Для примера запустим все ту же "матрицу: print( web.run( "https://raw.githubusercontent.com/IgorTimofeev/OpenComputers/master/Screensavers/Matrix.lua" ) ) Результат: web.rawRequest( string url, string/table postData, table headers, function chunkHandler, [int chunkSize]): boolean result, string reason Напоследок метод, позволяющий осуществить ручную обработку загружаемых данных почанково. Для примера напишем программу, выдающую содержимое страницы vk.com через print() маленькими порциями по 20 символов. Разумеется, никаких postData и headers указывать не требуется: print( web.rawRequest( "https://vk.com/", nil, nil, function(chunk) print(chunk) end, 20 ) ) Результат:

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

Видимо следствие того что потоки для компов низкоприоритетные.

Это вряд ли. Скорее всего, в полном соответствии с тиками. Я могу ошибаться, но склоняюсь к тому, что лагает исполнение кода Lua в OpenComputers. Причём, слово "лагает" я использую в изначальном его смысле, когда ожидаемое событие приходит с задержкой. Боюсь сейчас соврать, результатов экспериментов под рукой нет, но, насколько я помню, обращение к периферии вместо одного тика иногда требует двух тиков, а в моменты сильного снижения TPS задержка доходила и до 5 тиков. И это, возможно, не предел. Все мои эксперименты подтверждали абсолютно детерминированную работу реакторов. Случайности возникают вокруг реактора: случайным образом поджигаются блоки или превращаются в лаву. Блоки обшивки ЖЯР тоже могут выгореть случайным образом. Но компоненты реактора взаимодействуют друг с другом абсолютно предсказуемым образом. Я плохо понял о чём здесь идёт речь. Чем плоха реализация os.sleep, если не вешать на него тяжёлые обработчики событий? Работа os.sleep основана на вызовах computer.pullSignal, другого вменяемого способа для создания задержек нет. Чтобы понять, насколько хорошим будет результат при фиксированных задержках, нужен ряд экспериментов и правильно интерпретация их результатов: Надо всё-таки понять, в каком месте возникает джиттер: на этапе тиков реактора, или на этапе получения ответа от транспозера. Надо как-то определить теоретически максимально возможный размер джиттера. Надо проверить, нет ли дрейфа циклов ректора при выгрузке-загрузке чанков. Пока ответы на эти вопросы не получены, приходится подстраховывать частой проверкой состояния какого-либо из слотов реактора. Необязательно выполнять проверку каждый тик. Время замены очередного отражателя известно с точностью до секунды. Поэтому уменьшаем это время на одну секунду и смело спим. А потом начинаем каждый тик проверять точный момент критического износа отражателя. Как только поймали момент, заменяем отражатель.

Каждый метод компонента в OpenComputers характеризуется его прямотой: есть прямые методы, а есть непрямые. Не раз в ирке разъяснял разницу. Сейчас расскажу и вам. Предположения: Текущая версия мода — 1.7.5. Вы собирали опенкомпьютер. Вы знаете, кто такой компонент, что у него за методы и как их вызвать. С непрямыми вызовами всё просто. Они уводят компьютер в сон на тик. Всегда, при любом условии, даже в случае ошибки, после вызова непрямого метода компьютер до следующего тика работать не будет. Прямые вызовы такого ограничения не имеют. Один такой вызов может занимать произвольное количество времени. Зависит это от бюджета вызовов. У компьютеров OC есть бюджет вызовов. Это скрытая безразмерная величина. Каждый тик она сбрасывается до определённого значения. Определено оно так: Сначала смотрим на процессор в компьютере. Точнее, на уровень: T1 соответствует 0.5, T2 — 1.0, T3 — 1.5. Затем на каждую из планок памяти. T1 или T1.5 — это 0.5, T2 или T2.5 — 1.0, T3 или T3.5 — 1.5. Получаем несколько чисел. Суммируем, делим на количество — находим тем самым среднее арифметическое, которое и будет максимальным бюджетом вызовов. Практикум: T2 процессор → 1.0 Планка T2.5 → 1.0 Планка T3.5 → 1.5 Бюджет вызовов: (1.0 + 1.0 + 1.5) / 3 ≈ 1.167. Пример второй: Т3 процессор → 1.5 Планки T3.5 → 1.5, 1.5, 1.5 Планка T2.5 → 1.0 Бюджет вызовов: (1.5 + 1.5 + 1.5 + 1.5 + 1.0) / 5 = 1.4. Достаточно. Каждый прямой вызов расходует этот бюджет. По умолчанию — ровно одну тысячную его. Самые последние дев-билды мода делают прямые вызовы по умолчанию абсолютно бесплатными. Когда бюджет уходит в минус, компьютер принудительно спит до следующего тика. Определяет прямоту метода разработчик. Для создания метода в коде мода используется аннотация li.cil.oc.api.machine.Callback. Примерно так (метод hologram.get): @Callback(direct = true, doc = """function(x:number, y:number, z:number):number -- Returns the value for the specified voxel.""") def get(context: Context, args: Arguments): Array[AnyRef] = this.synchronized { ... } Если мы видим здесь direct = true, то это абсолютно точно прямой вызов. Если direct = false или отсутствует, то вызов непрямой. У метода может быть кастомная стоимость вызова. Не 0.001. У дата-карточки такое особенно. Пример (data.inflate): @Callback(direct = true, limit = 4, doc = """function(data:string):string -- Applies inflate decompression to the data.""") def inflate(context: Context, args: Arguments): Array[AnyRef] = { ... } limit = 4 читать как "потребляю 1/4 бюджета при вызове". Для сервера выше это 5 вызовов в тик. Недурно. У видеокарты всё сложно. Вообще, она тоже ограничивает ярость использования через бюджет вызовов. Потому на Т3-комплекте работать будет быстрее. Но количество потребляемого бюджета также зависит и от уровня видеокарточки. Для OC 1.7.5 распределение такое: Операция Стоимость T1 GPU T2 GPU T3 GPU setBackground 1/32 1/64 1/128 setForeground 1/32 1/64 1/128 setPaletteColor 1/2 1/8 1/16 set 1/64 1/128 1/256 copy 1/16 1/32 1/64 fill 1/32 1/64 1/128 Поэтому максимально можно вызвать 384 сета в тик. Чтобы программно определить прямоту методов, есть функция component.methods(addr). Отдаём ей полный адрес компонента, получаем таблицу. В ключах имена методов, в значениях их прямота. Или же можно воспользоваться этой таблицей. Она включает все методы всех компонентов, которые есть в OpenComputers. И наконец, размер бюджета можно сменить в конфиге. Опция budgetCosts занимается именно этим.

К слову, computer.tmpAddress() - независимое от озу хранилище. Самое забавное, что если компьютер перезагружается "мягко" - через computer.shutdown(true), то содержимое даже не очищается.