Fingercomp

Ну, я надеюсь, осознание имеется, что линукс — это несколько необычная программа, правильно? Она общается с девайсами более-менее напрямую. Можем ли из луа мы взять и отключить прерывания, сбросить флаги из-под floating-point-операций? Если мы говорим про OC*, то я что-то сомневаюсь. Единственный реальный вариант — это собрать полноценный эмулятор какого-то SoC: проц, серийка, память, таймеры, остальные девайсы. Тогда можно потенциально написать для этой системы драйверы, собрать их вместе с ядром для процессора и радоваться жизни. * Отдельные наркоманы, впрочем, делают мини-ядра вроде eLua, где есть низкоуровневый доступ к железу.

Вот полное решение. local function processEscapes(str) return (str:gsub("\\u{(%x+)}", function(hex) return utf8.char(tonumber(hex, 16)) end) :gsub("\\(%d%d?%d?)", function(dec) return string.char(tonumber(dec, 10)) end) :gsub("\\x(%x%x)", function(hex) return string.char(tonumber(hex, 16)) end) :gsub("\\z%s*", "") -- skip whitespace :gsub("\\\n", "\n") :gsub("\\([abfnrtv\\\"'])", { a = "\a", b = "\b", f = "\f", n = "\n", r = "\r", t = "\t", v = "\v", ["\\"] = "\\", ['"'] = '"', ["'"] = "'", })) :gsub("\\(.)", function(c) error("invalid escape sequence: \\" .. c) end) end P. S. Форум убивает форматирование, не спрашивая меня.

Я задал 4 вопроса и ни на один не получил вразумительного ответа. А они мне нужны, потому что без них совершенно неясно, "как это пофиксить". За других говорить не могу и не буду. Но я не атакую встречными вопросами из-за вредности, злости (ну, если немного только) или чувства собственного величия. Наоборот, иногда пытаюсь угадать по неполной информации ответ, что, вообще говоря, не надо делать. Здесь я бессилен. Что творится, никто не понимает. Задаю вопросы — прояснения не получаю. К слову. Для оформления кода есть кнопка . Просьба ею пользоваться. Можно даже выбрать подсветку Lua, если настроение очень щедрое.

Это весь код? motd — это глобалка? Исходя из чего было установлено, что оно работает? И как оно в принципе работать может, когда в либе internet функции write подавно нету и не было никогда? Когда вместо ответа приходится задать кучу встречных вопросов, должно настораживать.

https://fingercomp.gitbooks.io/oc-cookbook/content/lua/real-time.html В коде time как раз есть unix timestamp.

@LeshaInc эту фичу выкинул. Багу считаем пофикшенной.

Только байты интересуют? С сокетами проблем нету? У меня сомнения, потому что вопрос элементарный. Тем не менее. В питоне строка str хранит последовательность символов (codepoint) юникода каким-то абстрактным образом, потому что закодировать их можно по-разному: utf-8, utf-1, utf-16, utf-32, ucs-2 или какая-то другая, самопальная кодировка. bytes же — это набор байтов, как можно догадаться, а не символов. Если мы хотим из str сделать bytes, нужно абстрактный набор юникод-символов превратить в конкретную последовательность байтов — этим и занимается кодировка. Здесь bytes("PING", encoding="utf8") вернёт то же, что и литерал b'PING' в utf8-кодированном исходнике, например: последовательность из 4 байтов с номерами 90, 73, 78, 71. Теперь про Луа. В Луа никакого абстрактного набора символов нет. Строка в Луа — это не набор символов юникода, как str, а конкретная последовательность из произвольных байтов. То есть такая же вещь, как и bytes в Питоне. Поэтому аналог bytes("PING", encoding="utf8"), или же b'PING' (если исходник в кодировке utf-8), — просто "PING" (впрочем, опять-таки, в utf8-кодированном коде) sock:write("PING")

Второй вариант.

Вернее, 65536. Там по умолчанию частота дискретизации — 32768.

DFPWM сам по себе уже есть довольно шумный кодек, вообще говоря. (Зато 1 бит на сэмпл — пожато добротно.) Если проигрывать намерение на версиях MC 1.8 и выше, то нужно конвертировать в формат DFPWM1a: в конвертере галочка для этого есть. На 1.7.10, обратно, галку проставлять не надо. Можно увеличить частоту дискретизации в 1/4 ≤ n ≤ 2 раз (на новом кодеке, например, 96000 выставить); на плеере потом нужно скорость соответственно установить. Будет не сильно, но лучше. Но и места больше займёт. Проигрываемое там через LP filter прогоняется, поэтому высокочастотное послушать не удастся.

Программу в общем следует писать так, чтобы она в любой ситуации выстояла. Программе никогда никто не рад. Её все будут тестировать, потрошить, разрывать на части, ругать и пытаться взорвать. Поэтому ошибки нужно обработать, отрапортовать, ввод отвалидировать; надеяться, что у проги всё будет прекрасно, нельзя. Как здесь: кто-то не узнал, что файл не открылся, потому что ошибка съелась. Проблема не его.

Если лень человечески ошибки обрабатывать, файлы советую открывать так: local f = assert(io.open(path, mode)) Просто обернуть опен в ассёрт. Творит чудеса.

Так и есть, насколько могу понять. Можно не рисовать сразу на полсекунды задержку, а каждый тик синхронизироваться, например. Но с задержкой в 50 ms адекватно играть на пианинке (ну, лично мне) невозможно. Если сделать интерфейс вроде трекера, то можно посылать на звуковую карточку уже готовые аудиокуски, а с миди-клавиатуры ввод принимать, чтобы сориентироваться, какую ноту дальше написать или понять, норм аккорд подобрал или не очень. Тогда можно смириться с задержкой. У меня на синезубых наушниках примерно такая же ситуация и получается, поэтому мелодию мышкой накликиваю просто. Или таки ставить несколько звуковых карт, да.

hpm сломан в OC 1.7.5. Починен в последних дев-билдах. Хпм сам устарел, все репозитории заморожены, и чинить там никто уже не будет. Путь вперёд лежит через революцию — переписывание всего по-новой и с нуля.

Обижаешь. Я слова в правильном порядке б выставил. И артикли б расставил везде.

С такими запросами я могу предложить поиграть в SHENZHEN I/O. Там уже есть всё из перечисленного, только не редстоуном зовётся.

Я хочу сразу извиниться за то, что буду дальше писать. Потому что это будет критика и не по коду. Тема оформлена странно. По описанию в первом посте я решительно ничего не понял. Как будто я какую-то книжку начал читать, которая 4 тома неспешно длиться будет. Это меня огорчает: я же вижу, что это какая-то крутая программа. Всё становится логичным, если признать, что истинная цель — это "продать" программу. Заинтересовать читателей. Принципы: всё главное — вверх; что можно делать пикчей — сделать пикчей, не текстом; а текст же делать последовательным и легкодоступным. Дальше я перечислю, что конкретно можно исправить, чтобы офигенной проге сопутствовал офигенный пост. 1. Описание Нет ни одного абзаца, который бы сказал, что делает программа. Абзац это должен быть первый и прямо под картинкой: Идея — это, конечно, интересно, но уже второстепенно. Это не главный контент, потому что ни на какой вопрос читателя не отвечает: автору просто не терпится высказаться, хотя его никто не просил. Умные люди это называют лирическим отступлением. Начинать с него пост не нужно. 2. Список фич Есть пункт "Преимущества". Я скажу прямо: у этой программы конкурентов нет. Соответственно, преимуществ перед кем-то нет тоже. Можно или перечислить фичи, или сказать зачем. В оригинальном посте ближе второй вариант. Тогда назвать пункт своим именем: "Зачем", — и переписать список. Схема каждого пункта: что за фича, запятая (или тире, или двоеточие), комментарий (какая проблема решается). Кратко и ёмко — подробнее можно дальше написать. Пример: Список дополнить, разумеется. 4 пункта не предел. 3. Минимальные требования Пункт можно переименовать в "Железо". Это короче и удобоваримее. И ради кода, делайте требования картинкой. Это в пятьсот раз нагляднее, чем список. Уже ведь даже майнкрафт не нужен для пикч: в десктопном оцелоте можно склеить пикчи. У форума уродские инструменты форматирования, но таблицы вставлять он умеет. Откроем редактор HTML, пропишем: <html> <head> <meta charset="utf-8"> </head> <body> <table> <thead> <tr> <th>Клиент</th> <th>Сервер</th> </tr> </thead> <tbody> <tr> <td><img src="..." alt="Клиентская сборка"></td> <td><img src="..." alt="Серверная сборка"></td> </tr> </tbody> </table> </body> </html> Копипастим, вставляем в адресную строку, в начало добавляем data:text/html,, жмём Enter. Ctrl-A, Ctrl-C и копируем сюда. В разы же лучше. Под таблицей написать, что вместо сетевых карт можно юзать туннельные. 4. Команды Команды надо выделять. Или курсивом, или в блок кода, или вот так, но не плейнтекстом. Особенно команды с кучей аргументов. 5. Использование Это же не просто библиотека. Инструкция по использованию — это полезно, но опять второстепенно. Нужен новый пункт, назвать "Практика". Здесь можно сделать короткое и ёмкое видео (скорее всего, придётся кадрировать, снимать в несколько дублей). План сценария: Надпись "Установка". Запускаем сервер, ставим программу. Собираем биос. Открываем гуи ассемблера, в котором уже выложен рецепт дрона. Пихаем биос. Жмём по кнопке, получаем результат (делать в креативе, чтоб не ждать). Включаем дрона и запускаем что-нибудь цветастое. Например, мерцанием лампой дрона под такт музяке. Или что-нибудь ещё. По тому же принципу продемонстрировать фичи. Звук, в том числе голос, необязателен. Если видео не хочется делать, то переписать инструкции. Вернее, дополнить их примерами. Разберём один пункт. Не знаю, как вам, а я ничего так и не понял. А теперь следите за руками: У меня вопросов больше не осталось. В том же духе переделать остальные пункты инструкций и сделать их полезными для людей. 6. Слишком мелкие придирки, чтобы выделять на каждую по пункту По-русски logging лучше назвать логированием. Или просто логами. Перед открывающей скобкой ставить пробел (вот так). Сделать форматирование команд однородным. Сейчас там где-то цвет особый, где-то курсив, а где-то ни того, ни другого. Хотя семантически элементы не отличаются. Причастие прошедшего времени глагола read пишется так же. @Fingercomp reads manuals. — Yesterday I read manuals. — The manual was read. 7. Что в топике хорошо Чтобы закончить пост, укажу, что в топике сделано добротно. Пикча в начале. Самое главное — странная пикча в начале. Это интереснее. Принцип работы умещён в информативную картинку. Дополнительный текст не потребовался. Есть ссылка на код. Во многих постах авторы ограничиваются командой загрузки. Мне интересно почитать и сырцы. Охрененная идея, которая побудила меня писать это. 8. Живой пример Я писал этот пост для Cyan на oc.cil.li: https://oc.cil.li/topic/2350-cyan-bios/. Там люди очень скупы на лайки, а здесь их целых 3. Оформление оказалось очень важным. 9. Почему я написал пост здесь, а не стукнул автору в ЛС Принципы здесь применимы не только к HoverHelm. На форуме программки страдают от ужасной подачи материала. Но здесь я не смог сдержать чувство справедливости: не должна отличная программа быть преподнесена так, чтобы отпугивать читателя. Если же этот пост покажется оффтопом, прошу модераторов перетащить пост в мой блог. Я дальше сам поправлю контекст.

А зачем нужен собранный ocelot-brain? Это же тупо либа. Её надо подключать в другую прогу, которую так и так придётся компилировать. Но смысла тогда готовый брейн собирать поразительно мало, особенно с учётом малого объёма кода.

В OC встроен TLS только для HTTPS-запросов. Если надо кастомный TCP-сокет, обёрнутый в TLS, то надо самому имплементить TLS-протокол. Без дата-карты 3 уровня будет сложно: придётся делать криптографические примитивы на Lua.

Внутри песочницы coroutine.yield переопределён: yield = function(...) -- custom yield part for bubbling sysyields return coroutine.yield(nil, ...) end Также переопределён и coroutine.resume. resume = function(co, ...) -- custom resume part for bubbling sysyields checkArg(1, co, "thread") local args = table.pack(...) while true do -- for consecutive sysyields debug.sethook(co, checkDeadline, "", hookInterval) local result = table.pack( coroutine.resume(co, table.unpack(args, 1, args.n))) debug.sethook(co) -- avoid gc issues checkDeadline() if result[1] then -- success: (true, sysval?, ...?) if coroutine.status(co) == "dead" then -- return: (true, ...) return true, table.unpack(result, 2, result.n) elseif result[2] ~= nil then -- yield: (true, sysval) args = table.pack(coroutine.yield(result[2])) else -- yield: (true, nil, ...) return true, table.unpack(result, 3, result.n) end else -- error: result = (false, string) return false, result[2] end end end Работает это так: Если корутина вернула true, nil, ... — отдать true, ... (поэтому внутри песочницы разница между обычными и переопределёнными функциями не видна). Если корутина йелднулась без нила в начале, то это "системный вызов". Потому что доступ к непереопределённой функции coroutine.yield есть только внутри machine.lua. В таком случае йелдится и текущая корутина вверх по цепочке. EEPROM запускается в корутине. Если корутина эта йелдится, случается следующее: yield(false) — это выключить компьютер; yield(true) — ребутнуть его; yield(n), где type(n) == "number", — спать n секунд; yield(f), где type(f) == "function", — это вызвать непрямую функцию. yield с любым другим аргументом — спать до скончания века. Дополнительно обрабатывается умирание корутины: return посреди еепрома — это error("computer halted", 0); другие ошибки прокидываются. А теперь смотрим на наш вызов. В EEPROM вызвана coroutine.yield(0). Эта функция переопределена, чтобы вызвать нативный coroutine.yield(nil, 0). Корутина тогда йелдится и отдаёт nil, 0. В списке выше это пункт 3.5. Компьютер уйдёт в вечный сон. Ну, конечно, я преувеличиваю. Компьютер спит до момента получения сигнала и, получив, продолжит работу. Но вообще, незачем звать coroutine.yield напрямую. Есть computer.pullSignal, computer.shutdown, component.invoke(addr, nonDirectMethod, ...).

Опечатка. Поправил. Спасибо.

Каждый метод компонента в 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 занимается именно этим.

Как раз об этом я и пишу: Код видел, приходилось.

registerListeners() repeat until event.pull("interrupted") disableListeners() Этот кусок кода кладём в конец программки. Вуаля. Если этот кусок кода ровно от начала и прямо до конца обернуть в поток, а затем сделать ему :join(), то disableListeners даже не потребуется. Всё само выключится при завершении потока. Жутко удобно, словами не передать. Программа закрываться будет по ^C. Если не нравится, репит заменить на это: while true do os.sleep(math.huge) end

Наконец-то мы смогли одолеть эту проказу демоническую! Сто лет не мог поставить: чуть что — ось меня посылала. Хоть теперь покойнее будет. Предлагаю не останавливаться на этом. Мир ждёт: переписанной без матов истории коммитов; переименования всех переменных с непристойными выражениями; замены значков об ошибке рисунком бодрого розового единорога; редакции вики в дореволюционной орфографии для истинных джентльменов; перевода MineOS с Lua на китайский вариант Scratch; кастомизации количества пробелов в отступах (и заменой на них табов); патча OpenComputers, чтобы мониторы работали в кодировке KOI-8.