Fingercomp

К слову, насколько сильно будет тормозить решение, которое перенесёт массивы-буферы из луа в vram, но склеивание операций и рендер будет проводить всё так же в луа, не используя bitblt?

Баги, которые появились в 1.7.6: сломаный брайль, сломаная опенось, сломанная версия — пофиксили в спешном темпе и выпустили 1.7.7.

Думаешь, он магическим своим влиянием шрифт тебе в OC заменил внезапно?

Новая версия OpenComputers. Неожиданно. Из наиболее интересного: Видеобуферы у графической карточки. Помимо основного, нулевого буфера, который отображается на экране, теперь можно аллоцировать дополнительные буферы — 2D-массивы символов с заданным разрешением, с которыми можно проводить те же операции, что и раньше: set, fill, copy и т. д., — но без потребления бюджета вызовов (то бишь халявно). Добавлена операция bitblt (bit blit), которая копирует кусок одного буфера на другой. Копирование на основной буфер потребляет бюджет вызовов пропорционально разрешению исходного буфера (не размеру области копирования). Может занять несколько тиков. Если верить @ECS, последнее преимущества в производительности практически убивает. Впрочем, за несколько лет, пока буферы висели в дев-билдах, люди уже их заиспользовали для игрушек: вот платформер, например. Прямые вызовы методов компонентов (любых, не только GPU), не имеющих явных лимитов или использования бюджета вызовов, теперь абсолютно бесплатны с этой точки зрения. Раньше они потребляли одну тысячную единицы бюджета вызовов. Подробнее о них — в моей статье. Обновлён шрифт: покрытие значительно расширилось путём забития недостающих символов глифами из Unifont. Заблокирован диапазон 0.0.0.0/8 для интернет-карты. Запросы туда делают примерно то же, что запросы на localhost. Примечательно, что эту уязвимость использовали на CTF для обхода файрволла. Советую почитать. Метод media добавили и для дисководов в серверной стойке. Досадное упущение. Пофиксили отключение компов при перезагрузке чанка: в определённых случаях стейт компьютеров вовсе не сохранялся, из-за чего они рестартились при выгрузке и подгрузке чанка. Починили debug.sendToDebugCard (весьма полезная функция). Разобрались в ориентации редстоун-карт. В 1.7.3 карточки в компах и серверах почему-то использовали абсолютные направления (север/юг/запад/восток) вместо относительных. Беспроводные модемы первого уровня снова могут получать сообщения. А раньше не могли. Это была бага. Ретрансляторы потеряли возможность ретранслировать на неограниченно большие расстояния. В коде мода запутались в min и max. В результатах поиска вейпоинтов навигационным апгрейдом теперь пишутся их адреса. Остальные изменения и ссылка на скачивание — на GitHub.

Хм. Действительно, в RFC7230 валидный Content-Length — любое целочисленное неотрицательное значение. Попытался найти, почему я решил, что нельзя слать больше, чем в Content-Length, и обнаружил следующее в устаревшей версии стандарта: — RFC2616: “Hypertext Transfer Protocol -- HTTP/1.1”, §4.4, стр. 34 Что, в принципе, объясняет мою уверенность. В таком случае, действительно, стоит ориентироваться на Content-Length. Статью исправлю соответствующе. Спасибо за замечания.

Это уже несколько оффтоп, конечно, но я считаю это дурным начинанием: на каждом языке есть свои устоявшиеся стилевые конвенции. В Java везде писатьКакВерблюд, в C# методы, как в жаве, но с заглавной буквы, чтобы выпендриться, а на си и питоне snake_case. Для удобства других программистов их следует соблюдать. Ты уже читал код jpg-либы: ощущаемый диссонанс или даже дисфория — прямое следствие написания не как надо. Особенно это я нахожу важным при написании библиотек (не наш случай, то есть): когда код пестрит то_такими, тоТакими, ТоСякими, товообщевоттакими вызовами и переменными (был проект на плюсах такой, со всеми вариантами, кроме разве тотального капса...), и читать неприятно, и писать тоже затруднительно, потому что нужно постоянно вспоминать и чинить регистр каждой конкретной библиотеки. Ну там буфер-то крохотный, порядка кибибайта всего. Причём сначала он исчерпает буфер кибибатным возвратом, следующий вызов отдаст пустую строку и только повторный read следующий кибибайт отдаст. Как минимум при пустой строке спать несколько лениво. local r, g, b = (color >> 16) & 0xff, (color >> 8) & 0xff, color & 0xff Вроде не очень сложно. Если в буферах хранить уже уменьшенные версии картинок (а полноразмерные всё равно не нужны, так что их даже не собирать и на лету ресайзить надо), то конечный буфер можно будет уменьшить до 16 килобайт (160×100). Чтобы не конкатить строки при сборке буфера, можно хранить таблицу из 2000 чисел, где каждое число хранит 8 пикселей по 8 бит: скорость доступа на изменение будет выше, чтение тоже не особо замедлится, и памяти буфер будет стабильно потреблять 32808 байт (которые OC зачтёт как 18227) всё время работы. (Без упаковки будет 256808 байт — для OC 142671. Если использовать вложенные таблицы, результат можно улучшить.)

Потрясающее замечание. Отвечу развёрнуто с удовольствием. Если посмотреть на код, то можно заметить, что я эту проблему опознал и в случае несоответствия в меньшую сторону я решил хедер игнорировать (собственно, поэтому в сравнении там оператор >=). К сожалению, когда код я стал комментировать, про это совершенно забыл — и без этого коммента бы, наверное, и не вспомнил. Претензия имеет силу, если мы обратимся к стандарту. Юзер-агент должен в случае получения невалидного хедера Content-Length просигналить об ошибке и выбросить полученные данные: — RFC7230: “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, §3.3.3, стр. 32–33 Более того, когда писал код, специально стандарт вычитывал именно поэтому. Почему же тогда в статье я решил игнорировать его предписания, притом намеренно? Для простоты. Чтобы не вдаваться в детали HTTP, не рассказывать про Transfer-Encoding и не требовать реализации алгоритма из цитированного стандарта. Чтобы быть предельно педантным, нужно сначала проверить, не стоит ли Transfer-Encoding (потому что иначе длина неизвестна), потом убедиться, что все Content-Length имеют одно и то же значение (это тоже в статье я не освещал, но требуется стандартом), а затем читать данное число байт: если фактически пришло меньше или больше, ответ отбросить и вернуть ошибку. Или же подойти с прагматической стороны, учесть, что по соединению из OC мы можем отправить ровно один HTTP-запрос и забить на эту сложность. Возможно, стоит проверить, что Content-Length все имеют согласованное значение и являются интами, чтобы быть уверенным в ожидаемой длине. Самое главное, что требуется от того кода: убедиться, что соединение не порвалось посередине ответа. Поэтому, хотя всех тонкостей HTTP я действительно не знаю, я бы не спешил декрементить счётчик. :P

Можно заметить, что первая строчка у всех незагруженных плагинов одна и та же, и догадаться, что причину ошибки следует искать ниже. Так и поступим. Проблема номер 5: UTitleAuth Если посмотреть на стэктрейс, то можно заметить упоминания PluginClassLoader, JarFile и ZipFile. И сделать разумный вывод, что жарник плагина какой-то порченый. Разумные действия: попробовать открыть файл в zip-архиваторе; перекачать плагин; сверить чексуммы; пересобрать из исходников. Проблема номер 6: SCore Здесь он пишет, что не может найти класс MysqlDataSource. Он был при компиляции (иначе б плагин не собрался), значит, этот класс поставляется как-то отдельно от плагина. Если ещё знать, что значит JDBC, то становится ясно, что в classpath отсутствует JDBC-драйвер для MySQL. Разумные действия: скачать этот драйвер (нужно брать версию 5.x, потому что 8.x — это некий connector/j с другими классами, а используется не он) и доставить в libs; поменять СУБД; пересобрать плагин. Проблема номер 7: ExecutableItems Он, кажется, хочет класс из плагина SCore, который мы выше не смогли загрузить. Разумные действия: решить проблему номер 6.

Было ли билинейную интерполяцию сделать затруднительным? Значение каждого входного пикселя делить на четыре, прибавлять к выходному значению и после декодирования округлить. Элементарный алгоритм, причём в данном случае можно ещё существенно упростить: просуммировать значения каналов пикселей в блоке 2×2, поделить на 4 и округлить. А лучше обобщить алгоритм для уменьшения пикчи с произвольным масштабом. Алсо: в коде смешан snake_case и camelCase (причём в луа обычно юзают второе, не вижу смысла отходить от этого) busy-loop в ожидании finishConnect: читать пункт 3 и не насиловать процессор неудовлетворительная обработка ошибок (см. выше): на той же строке 75 следует хотя бы в assert обернуть stream.read 127 строка пугает: можно было определить нужную степень двойки и затем иметь готовый и быстрый результат `((x - 1) << scale) + 1` каждый хендлер рисует пикчу, как вздумается: с точки зрения чистоты лучше бы все либы заставить каждый распаршенный блок пикселей отдавать в коллбэк, который бы был единым для всех форматов, выполнял интерполяцию и отдавал на буфер (костыли с жпг непередаваемы) спать один тик на каждый read звучит не очень здорово насколько я могу судить, никакая из либ не требует бэктрекинга, поэтому кэширование выглядит излишне Дальше мне смотреть было лень.

$ diff -U 0 irc.lua irc.1.lua --- irc.lua 1970-01-01 00:00:00.000000000 +0000 +++ irc.1.lua 1970-01-01 00:00:00.000000000 +0000 @@ -1,3 +0,0 @@ --- A (very (very!)) simple IRC client. Reference: --- http://tools.ietf.org/html/rfc2812 - @@ -25 +22 @@ -local host = args[2] or "irc.esper.net:6667" +local host = args[2] or "irc.Esper.net:6667" @@ -374 +371 @@ - print("Welcome to OpenIRC!") + print("Welcome to UnionICE") @@ -455 +452 @@ - local channel = text.trim(line:sub(7)) + local channel = "#cc.ru" @@ -461 +458 @@ - line = "JOIN " .. channel + line = "JOIN " .. "#cc.ru" Ловко.

@eu_tomat можешь, пожалуйста, в статьях пофиксить \n, слетевшие после обновлений форума несколько лет назад? Кинул человеку статью эту почитать, а тут всё слилось в однострочники.

Специально самые древние посты ищешь, чтоб понекропостить?

Напомню, что есть /dev/eeprom и /dev/eeprom-data. С тех пор, как эти файлы реализовали в OpenOS, надобность в утилите flash отпала совершенно. # cat bios.lua > /dev/eeprom # echo > /dev/eeprom-data # cat /dev/eeprom > bios.lua

Здесь заявляется, что пароли хэшируются. Хотя это определённо прогресс по сравнению с плейнтекстом, мне кажется, готовую хэш-функцию в силу религиозных убеждений ты юзать побоялся и сделал свою. Можешь ли тогда выложить не избитую минификатором используемую тобой функцию хэширования? Кроме того, солишь ли ты пароль перед хэшированием?

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

Потому что в кодеке DFPWM сэмплы однобитовые. Вообще, если раздуть каждый бит в файле DFPWM до байта (то есть чтобы были байты либо 255, либо 0), то выход вполне можно будет сыграть, но придётся ещё фильтр низких частот ставить перед FFT. Собственно, три буквы PWM в названии кодека уже описывают принцип работы, а ещё DF говорит, что там параметры фильтра меняются в процессе декодирования.

Советую матчасть покурить, раз уж матметоды такие применять решено. Можно даже мой пост. Там поверхностно рассказывал про всякие параметры. complex к этому всему отношение имеет посредственное, и если понимаешь, что значит eiφ, то и без complex.lua можно всё провернуть.

Всё в Lua сделать можно, я даже статью про это писал. Там про table.pack в основном, но хочу вдобавок напомнить здесь про функцию select, которая умеет как число переданных аргументов возвратить, так и вытащить нужный: select('#', 2, 4, nil, 8, nil, nil, nil, nil) --> 8 select(2, 2, 4, nil, 8, nil, nil, nil, nil) --> 4 nil 8 nil nil nil Никакие nil ему не помеха.

За форумом я в последнее время слежу через RSS-читалку, и недавно мне начали попадаться какие-то настолько огромные стены безграмотного текста, что решил заглянуть, что тут творится. В общем, это были посты @rootmaster: с ошибками в словах, которые третьеклассник не допустит, желанием материться в каждом третьем посте, без форматирования, без точек, запятых, всё сплошняком, зато с излишними самоуверенностью и невежеством. Тут вот заверяется защита от замены биоса изнутри запущенной системы. За фичу эту много людей берётся, но постоянно делают всё не так от незнания. Напомню: достаточно просто подменить component.invoke именно в таблице, которую получает биос в окружении. И мне стало интересно: может, зря я осуждаю непризнанного гения. Вдруг хоть он смог понять и сделать всё по уму и красоте. Тем более, что сам код биоса не читабелен непосредственно, то есть вишней на торте даже до обфускации какой-то автор дошёл. Ещё и функционалы какие-то определил и тут же расширил. ...Ну да, если бы. И саспенса не получилось даже: были б ум да красота, я бы пост этот в принципе не писал. Код напичкан костылями. Было решено скопировать component в отдельную таблицу, в которой покрыть влоб бронёй прокси, отдаваемый методом component.proxy для компонента eeprom. Затем пришлось переопределить поле invoke в копии, чтобы он работал через component.proxy, а не внутренние механизмы machine.lua. И это всё работает на одной сопле в форме локальной переменной со ссылкой на эту прокси: без неё все изменения бы откатились при следующем же collectgarbage, потому что возвращаемые прокси лежат в эфемерной (__mode = "v") табличке-кэше. Хотя я наврал со словом "работает". Если хоть немного вдаться в работу machine.lua, сразу должно стать понятным, что "защита" элементарно обходится. Например, вот так. getmetatable(component.eeprom.getSize).__call({address = component.eeprom.address, name = "set"}, "lol") И без перепрошивки комп больше не запустится. Насчёт третьего пункта выше я даже не особо понял, как так вышло. То ли автор всё-таки под капотом смог разглядеть тонкости кэша проксей, то ли он просто от балды пытался код менять, пока не заработало, то ли досталось счастливым артефактом от прошлых версий проги. Неважно. Осуждаю по всем пунктам обвинения. А ведь стоило бы по-человечески написать, и лайкнул бы, и похвалил. И другие, думаю, сарказмом бы не поливали.

Этой версии OC уже пять лет. Пять. Если не заметили, пять лет этой версии. А, да, забыл сказать, уже 5 лет прошло с релиза 1.6.1. Ну, в заключение отмечу, что версия устарела на пять лет. 5 лет. Five years. 五年. Зачем?

Тогда б с SIGILL падал, по идее. Можно в coredumpctl debug покопаться и посмотреть, отчего SIGSEGV выпал.

LE-церты — вообще не туда, тогда б он про PKIX заваленный писал, и лечить надо было это обновлением Java (до 8u2** какой-то, например), и ни до какого HTTP 403 Forbidden бы дело не то что не дошло, веб-сервер бы запрос прочесть не смог физически. Здесь сам прокси Cloudflare блочит. Скорее всего, его удовлетворит просто выставленный User-Agent какой-нибудь свой при отправке запроса. local request = internet.request(url, nil, {["User-Agent"] = "OpenComputers 1.7.5"})

Если кому лень ждать наколенников, лучше попробовать вот эту вещь: https://github.com/dunstad/roboserver Выглядит роскошнее и шикарнее, но мы её так и не протестили.

Посмотрим на байт-код: $ echo 'local function round(nul) return nul + (2 ^ 52 + 2 ^ 51) - (2 ^ 52 + 2 ^ 51) end' | luac5.3 -l -l - main <stdin:0,0> (2 instructions at 0x55f08348ca20) 0+ params, 2 slots, 1 upvalue, 1 local, 0 constants, 1 function 1 [1] CLOSURE 0 0 ; 0x55f08348cc60 2 [1] RETURN 0 1 constants (0) for 0x55f08348ca20: locals (1) for 0x55f08348ca20: 0 round 2 3 upvalues (1) for 0x55f08348ca20: 0 _ENV 1 0 function <stdin:1,1> (4 instructions at 0x55f08348cc60) 1 param, 2 slots, 0 upvalues, 1 local, 1 constant, 0 functions 1 [1] ADD 1 0 -1 ; - 6.7553994410557e+15 2 [1] SUB 1 1 -1 ; - 6.7553994410557e+15 3 [1] RETURN 1 2 4 [1] RETURN 0 1 constants (1) for 0x55f08348cc60: 1 6.7553994410557e+15 locals (1) for 0x55f08348cc60: 0 nul 1 5 upvalues (0) for 0x55f08348cc60: Видно, что ADD и SUB тут работают с константой. Обращение к константе быстрое, доступное, лёгкое, воздушное. В предложенном варианте появляется upvalue, к которым доступ будет дольше. Так что эффективнее не станет.

Тема мертва! Ура!