Лидеры

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

@ProgramCrafter в основном были заменены функции на операции, а работающие трюки не были затронуты. За фикс спасибо, поправил.

Я вроде как уже выложил код либы на гитхаб(круги не работают, переписываю их активно) Я не думаю что она будет кому-либо интересна и полезна в использовании т.к. я ее полностью под себя писал Вот репо с либой, текстуркой и объектом текстурки, в папке Python есть скрипты для преобразования картинки в текстурку(надо запустить palettePaster, дабы преобразовать палитру цветов для CC, а потом imageTabler) https://github.com/4x4x8/my_stuff_for_computercraft/tree/main/Drawify

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

Пролистал RFC7230. Как ни странно, не нашёл там указаний на то, что после отправки сообщения сервер не может по тому же соединению отправлять ещё бессмысленный мусор. А если Content-Length меньше длины полученных данных, то не указано, корректный это заголовок или нет. А вообще, получается так: если сервер, например, решит "а я не буду закрывать соединение после отправки сообщения", то программа будет висеть, пока это соединение не разорвётся чем-нибудь посередине. Плюс сервер (доверять которому обычно не надо бы) может заставить программу на Lua использовать произвольное количество памяти. Не совсем best practices, по-моему

Потрясающее замечание. Отвечу развёрнуто с удовольствием. Если посмотреть на код, то можно заметить, что я эту проблему опознал и в случае несоответствия в меньшую сторону я решил хедер игнорировать (собственно, поэтому в сравнении там оператор >=). К сожалению, когда код я стал комментировать, про это совершенно забыл — и без этого коммента бы, наверное, и не вспомнил. Претензия имеет силу, если мы обратимся к стандарту. Юзер-агент должен в случае получения невалидного хедера 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

Все ошибки, которые есть в логе: 1. LuckPerms не может подключиться к БД, говоря, что слишком много соединений. [04:53:40] [Server thread/ERROR]: [LuckPerms] Failed to init storage implementation java.sql.SQLTransientConnectionException: luckperms-hikari - Connection is not available, request timed out after 5000ms. 2. AuthMe тоже не может подключиться к БД. [04:54:06] [Server thread/WARN]: java.sql.SQLNonTransientConnectionException: Too many connections 3. У CombatLogX неверный конфиг. [04:54:07] [Server thread/WARN]: [CombatLogX] An I/O exception occurred while loading a configuration file: org.bukkit.configuration.InvalidConfigurationException: while parsing a block mapping in 'string', line 16, column 1: tag-command-list: ^ expected <block end>, but found '<block sequence start>' in 'string', line 18, column 4: - "[ИГРОК] говорит, что я в бою!" ^ 4. PinPrompt не может подключиться к БД. [04:54:10] [Server thread/WARN]: [Server thread] INFO me.hexedhero.ppt.shaded.hikari.HikariDataSource - HikariPool-1 - Starting... [04:54:11] [Server thread/WARN]: java.sql.SQLNonTransientConnectionException: Too many connections 5. UTitleAuth не загрузился. [04:54:11] [Server thread/ERROR]: Error occurred while enabling UTitleAuth v4.2 (Is it up to date?) java.lang.IllegalStateException: zip file closed 6. SCore не загрузился. [04:54:11] [Server thread/ERROR]: Error occurred while enabling SCore v3.2.0 (Is it up to date?) java.lang.NoClassDefFoundError: com/mysql/jdbc/jdbc2/optional/MysqlDataSource 7. ExecutableItems не загрузился. [04:54:11] [Server thread/ERROR]: Error occurred while enabling ExecutableItems v5.2.0 (Is it up to date?) java.lang.NoClassDefFoundError: com/ssomar/score/sobject/NewSObject А после всего этого сервер корректно завершился.

Можно ждать клика нулевое время. Тогда pull_e вернёт либо nil, либо событие клика. Вот пример: ... local tEvent = {pull_e(0, 'touch')} if tEvent[1] then for i = 1, #tButtons do if tButtons.visible then if tEvent[3] >= tButtons.X and tEvent[3] <= tButtons.X+tButtons.W and tEvent[4] >= tButtons.Y and tEvent[4] <= tButtons.Y+tButtons.H then blink(i) tButtons.action() break end end end end ...

Программа умеет получать картинки по ссылке и отрисовывать их в OpenComputers. Поддерживается примитивный даунскейлинг. wget -fq https://raw.githubusercontent.com/ProgramCrafter/lua-utils/main/images-drawer/draw-random-img.lua Работа всё ещё в процессе. На данный момент: 1. Проверяю на работу только GIF. 2. Некоторые GIF некорректно парсятся по вине библиотеки. 3. К библиотеке GIF нужен патч, чтобы хоть какие-то гифки показывались. wget -fq https://gist.githubusercontent.com/ProgramCrafter/d1b279aec9e473794df115d1301dcb27/raw/8166f23ee3daba8ca8ec305589b3d9a258f6674f/gif.lua /usr/lib/gif.lua 4. Даунскейлинг примитивный: если картинку надо уменьшить, то из каждого квадрата 2x2 пикселя выбирается левый верхний. 5. Требования: тир3 GPU и монитор, интернет-карта, 6 планок тир3,5 памяти. Используемые библиотеки: Зато результат неплохой:

Я течении 5-6 дней писал библиотеку для отрисовки пикселей. И щас я тут. Моя библиотека использует символы, так что каждый пиксель размером (1,1), а не (2,3) если писать пробелы с цветным фоном. Это также увеличивает разрешение по X в 2 раза, и 3 раза в Y Текстурки я могу загружать через ссылки: local texture = drw.fromURL("https://raw.githubusercontent.com/4x4x8/my_stuff_for_computercraft/main/Drawify/drw_texture_test.lua") Canvas:drawImage(texture, 1, 1) Canvas:updatePixels() Очень просто и легко загружается в код, формат текстурки виден по ссылке :/ Всем спасибо, всем пока.

В тот момент, когда я писал сообщение, то именно библиотеку я не смог найти в репозитории. Теперь вижу. Это уже второй вопрос. Без кода эта тема была бы ещё менее интересной и менее полезной. Конечно, программы для ComputerCraft сейчас не пользуются большой популярностью, т.к. этому моду тяжело конкурировать с OpenComputers, но иногда люди ищут программы именно для ComputerCraft. Например, в этой теме просили переписать старую программу. Кстати, в ней почти весь код задействован для отрисовки графики. Может быть, твоя библиотека кого-нибудь вдохновит переписать эту штуку. Благодарю. Так уже веселее.

@Fingercomp Спасибо большое! Уже всё исправил, всё работает.

Уменьшаем счётчик на единицу. Претензия к пункту 3.3. Программа читает столько данных, сколько может - если сервер укажет маленький Content-Length и отправит гигабайт данных, программа всё это будет читать.

Вообще, из наличия в статье пятого пункта уже следует, что с обёртками я знаком и в путешествии к докам не нуждаюсь. Поэтому буду считать, что этот комментарий не ко мне обращён. Тем не менее, обе функции бесполезны, кроме примитивных случаев. internet.request не ждёт соединения с сервером. Хотя она прокидывает ошибки через error, этого недостаточно. См. 3.2–3.4 про то, как правильно послать запрос и получить ответ. А с таким кодом смысла в использовании обёртки ноль. internet.open кладёт оригинальный сокет в приватные свойства. Заставляет программиста постоянно и без причины дёргать :read() и не даёт воспользоваться сигналом internet_ready. Поэтому не только бесполезен, но и вреден. Нужно вызывать internet.socket, чтобы можно было получить id сокета и вызвать finishConnect, и вручную класть стрим в буфер. См. 4.5–4.8 про то, как правильно создать и использовать сокет. Таким образом, действительно полезна только одна функция — internet.socket. И очень зря она не удостоилась такой характеризации цитируемым комментарием.