ov3rwrite

2 часа назад, Teen_Romance сказал:

Почему именно в JSON? Тут же больше про саму lua как я понимаю, так как в консоль \ файл \ pastebin результат JSON:encode() выводится нормально.

Я в итоге так и не могу прийти к решению этого всего)) Я понял что символы оно в какой то момент превращает в \uXXXX но я не понимаю в какой и как пофиксить и где. Перед самой отправкой в lua в консоли мне выводит 

а уже на сервере(java Spring boot) у меня
{"field":"������, ���!"}

Ну, JSON:encode не превращает тебе в нормальные символы твою кириллицу. Ты перед отправкой используй Unicode Escape Sequence, тогда при запросе на сервак кодировка не слетит, потому что все символы в ASCII будут.

Либо на самом серваке укажи кодировку принимаемую: Why doesn't Spring Boot force UTF-8 for parameters in a POST request? · Issue #1819 · spring-projects/spring-boot (github.com)

8 минут назад, Teen_Romance сказал:

А можно более прямую наводку в виде ссылки или примера может быть?

 

https://dencode.com/string/unicode-escape

Ниже под декодером описан принцип. TL;DR: Любые Unicode символы в JSON кодируются в формате \uXXXX , где XXXX - шестнадцатеричный код символа.

 

Например, "Привет, мир!" - \u041F\u0440\u0438\u0432\u0435\u0442\u002C\u0020\u043C\u0438\u0440\u0021

См. Unicode Escape Sequence для JSON

В тему от 2015 года

[OC] [CC] Table to string (сериализация) - Библиотеки - ComputerCraft.RU Форум

Написал свой небольшой сериализатор таблиц, который возвращает строку в компактном формате в отличие от аналога из темы выше, сравнение в скриншотах внизу текущей темы.

- прирост производительности при тестах на ~10%

- отсутствие lookup таблицы

Тесты проводились на

- Lua 5.1.5

- процессор i5-9400 2.9 GHz

Объекты, сгенерированные моим сериализатором требуют обычной загрузки через

loadstring(s)()

( load для OC)

Объекты, сгенерированные сериализатором из темы выше, требуют дополнительных операций функции десериализации через дополнительные операции над loadstring.

 

Пример вывода:

Сравнение производительности (модифицированный тест из приведенной темы: таблица на 100 000 записей, но каждая из функций сериализации запущена 250 раз с подсчетом суммы и среднего времени выполнения):

Исходный код функции сериализации и соответствующего теста: Lua serialization test (github.com)

 

А репозиторий в гитхабе будет? Хотелось бы поглядеть :)

Данная тема является началом переводов статей OETF официального форума oc.cil.li.

 

Что такое OETF?

Цитата Negi:

Цитата

OETF (Open Engineering Task Force) является чем-то вроде аналога IETF (Internet Engineering Task Force) из реального мира. Это место по сути нужно для того, чтобы обсуждать протоколы и стандарты, определённые для коммуникации между компьютерами OpenComputers.

 

Если мне не изменяет память, Lizzy (админ) говорил что здесь мы можем добавлять новые стандарты, комментировать и расширять существующие, такие дела.

 

OETF #1: Кросс-Архитектурная Загрузка / Cross-Architecture Booting / CAB (черновик)

 

ЭТО ЧЕРНОВИК. Он может измениться перед тем, как стать "официальным". Не стесняйтесь предлагать значительные изменения.

 

Тезисы

 

Данный документ даёт рекомендации по работе с EEPROM и размещению архитектурно-специфичного кода.

 

Мотивация

 

OpenComputers поддерживает широкий спектр архитектур. Даже больше чем в реальном мире, архитектуры OpenComputers могут значительно отличаться друг от друга. Некоторые архитектуры выполняют программы на определенном языке высокого уровня напрямую, в то время как другие симулируют реальные или фиктивные низкоуровневые ISA. Некоторые архитектуры изначально работают с данными в 8-битных единицах, в то время как другие имеют встроенную продвинутую обращение со строками и возможности векторной обработки.

 

В отличие от такого разнообразия, компоненты OpenComputers имеют единый стандартный интерфейс. EEPROM, содержащий загрузочный код, может легко оказаться использованным на "неправильной" архитектуре, не говоря уже о загрузочных дисках.

 

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

 

Определения

 

Если не указано иное, все ссылки на текст подразумевают 7-битные ASCII-коды. Поведение при встрече байтов с установленным старшим битом не определено.

 

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно/не должен (SHOULD NOT), рекомендуется (RECOMMENDED), возможно/может (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119.

 

Идентификатор архитектуры

 

Каждая архитектура должна предоставлять уникальную, желательно значимый идентификатор, специфичный для данной архитектуры. Это Архитектурный Идентификатор, или АИД (AID). АИД СЛЕДУЕТ быть таким же, как и аннотация Architecture.Name для архитектуры, которая обычно совпадает с названием, используемым во всплывающей подсказке процессора.

 

АИД НЕОБХОДИМО содержать ни одного байта, кроме следующих символов: цифры, буквы в верхнем и нижнем регистрах, точки (.),  дефисы (-), нижние подчёркивания (_), косые черты (/), пробелы. В дополнение, НЕДОПУСТИМО, чтобы АИД начинался с пробела, заканчивался на пробел или содержал в себе последовательность из двух или более пробелов. АИД СЛЕДУЕТ начинаться с заглавной буквы, хотя бы для того, чтобы загрузочный код было легче отличить от других файлов и директорий в листингах.

 

Новый АИД НЕ ДОЛЖЕН содержать пробелов, если это не требуется для совместимости.

 

Архитектуре, имеющей несколько вариантов, которые несовместимы между собой, СЛЕДУЕТ использовать различные АИД для каждого варианта. Резервные схемы, такие как схемы с попыткой использования нескольких АИД специфичны для конкретной архитектуры и не рассматриваются в данном документе.

Образы EEPROM с поддержкой CAB ("CABE-образы")

 

Этот раздел относится к архитектурам, утилитам прошивки EEPROM и любому жёстко запрограммированному загрузочному коду (аналогично machine.lua в "стандартной" архитектуре Lua).

 

Образу EEPROM с поддержкой CAB ("образ CABE") НЕОБХОДИМО начинаться с символов "--[", за которыми следует ноль или более символов "=", а затем "[CABE:" - префиксная строка. CAB-совместимой архитектуре НЕОБХОДИМО быть готовой к работе с любым количеством "=" от 0 до 7, при этом CABE-образ НЕ ДОЛЖЕН использовать более 7.

 

За префиксной строкой следует единственный АИД. Он обозначает "предполагаемую архитектуру" для данного CAB-образа. За ним следует одно из двух значений:

• Двоеточие (:), в случае которого "основное тело" состоит из байтов, следующих за двоеточием, до тех пор, пока не будет встречена корректная суффиксная строка.
• Суффиксная строка, в случае которой "основное тело" состоит из оставшейся части образа, телу НЕОБХОДИМО быть корректным кодом на языке Lua 5.2 И Lua 5.3.

 

"Суффиксная строка" состоит из ASCII "]", за которым следует такое же количество "=", как и в префиксной строке, а затем еще одна "]". Для того чтобы быть корректной суффиксной строкой, ей НЕОБХОДИМО содержать ровно столько же "=", сколько и префиксная строка. В частности, в противном случае допустимая суффиксная строка, содержащая большее количество "=", чем префиксная строка, должна рассматриваться точно так же, как и любая другая последовательность байтов, не являющаяся суффиксной строкой.

 

"Основное тело" содержит фактические данные EEPROM для данной архитектуры. Интерпретация этих данных определяется архитектурой.

 

Если CABE-образ содержит данные после корректной суффиксной строки, то этим данным НЕОБХОДИМО представлять собой код Lua, совместимый с архитектурами Lua 5.2 и 5.3, предоставляемыми OpenComputers. Если архитектура CABE-образа не является таковой, то этому коду СЛЕДУЕТ состоять только из информативного вызова ошибки.

 

Любое отклонение от этого стандарта приводит к появлению не-CABE-образа. Все действия с не-CABE-образами специфичны для конкретной архитектуры, но не-CABE-образ СЛЕДУЕТ обрабатывать так же, как и "основное тело" корректного CABE-образа.

 

Предпочтительным расширением файлов для образов CABE является ".cabe". Предпочтительный тип MIME - "application/x-cabe-image", хотя допустимо использование "application/octet-stream". НЕДОПУСТИМО распространение CABE-образов с использованием любого MIME-типа "text/*", так как это почти наверняка приведет к повреждению бинарных CABE-образов.

 

Приведем пример образа CABE, ориентированного на вымышленную архитектуру "HyperTalk":

--[[CABE:HyperTalk:
ask "What is your name?"
answer "Hello," && it & "!"
]]
error"HyperTalk architecture required"

А вот образ, ориентированный на встроенную архитектуру Lua:

--[[CABE:Lua 5.2]]
for n=1,5 do
  computer.beep(2000, 0.1)
end

Прозрачное переключение архитектуры на основе EEPROM

 

В будущем выпуске OpenComputers может быть добавлена поддержка прозрачного переключения архитектуры с помощью дополнительных данных NBT для EEPROM. Предполагается, что они будут состоять из единственного АИД, идентифицирующего архитектуру, для которой предназначено EEPROM. Данный раздел применяется в случае появления такой поддержки. Для обеспечения согласованности, архитектуры НЕ ДОЛЖНЫ пытаться самостоятельно реализовать такое автоматическое переключение.

Утилите для прошивки EEPROM СЛЕДУЕТ попытаться разобрать все образы как образы CABE. В случае успеха ей СЛЕДУЕТ соответствующим образом пометить EEPROM и записать только "основное тело". В противном случае ей СЛЕДУЕТ удалить из EEPROM все существующие метки архитектуры и записать весь образ.

 

Архитектура, загружающая EEPROM с корректным архитектурным тегом, НЕ ДОЛЖНА также пытаться разобрать его как образ CABE. Архитектуре, загружающей EEPROM без действительной архитектурной метки, СЛЕДУЕТ попытаться разобрать его как образ CABE, и ей НЕДОПУСТИМО самой устанавливать архитектурную метку.

 

Загрузочный код

 

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

 

Загрузчикам СЛЕДУЕТ, если загрузочная EEPROM содержит UUID загрузочного устройства, попытаться сначала загрузиться с этого устройства. Загрузочная EEPROM содержит UUID загрузочного устройства, если eeprom.getData() полностью состоит из ASCII UUID или если она начинается с ASCII UUID, за которым следует нулевой байт.

 

Управляемый режим (файловые системы)

 

Поведение загрузчика на управляемых файловых системах состоит из следующих действий:

• Если "/<AID>" существует и является директорией, загрузить "/<AID>/boot".
• Если "/<AID>" существует и является файлом, загрузить "/<AID>".
• Все дальнейшие случаи специфичны для конкретной архитектуры.

 

Если одно из вышеперечисленных условий выполняется, но попытка загрузки не удалась, процессу загрузки НЕДОПУСТИМО продолжаться автоматически. Например, если "/<AID>" является директорией, но загрузка "/<AID>/boot" не удалась, то загрузчику НЕОБХОДИМО либо выдать ошибку, либо предложить пользователю предпринять дальнейшие действия.

 

Что именно подразумевается под "загрузкой", специфично для конкретной архитектуры. На архитектуре Lua она заключается в загрузке файла в виде кода Lua и его последующем выполнении. На низкоуровневых архитектурах она может заключаться в загрузке содержимого файла по фиксированному адресу в оперативной памяти и переходе (прыжке) на этот адрес. Архитектурам СЛЕДУЕТ предоставлять стандартный способ для загрузчика первого этапа сообщить загружаемому коду UUID файловой системы, из которой он был загружен.

 

Пример: Рассмотрим загрузку на архитектуре OC-ARM. Загрузчик проверяет, существует ли "/OC-ARM". Он существует и является директорией. Затем загрузчик пытается загрузить "/OC-ARM/boot". Это не удается, поскольку "/OC-ARM/boot" не является корректным. Происходит аварийное завершение работы машины с сообщением об ошибке, объясняющим проблему.

 

Неуправляемый режим (диски)

 

Загрузочный диск, совместимый с CAB, начинается с загрузочного сектора. Этому загрузочному сектору НЕОБХОДИМО быть первым или вторым сектором диска. Если и первый, и второй сектор диска содержат корректный загрузочный сектор, то будет использован только первый. Загрузочный сектор начинается с ASCII-строки "CAB", за которой следует ноль или более текстовых загрузочных записей. Этот список текстовых записей завершается восклицательным знаком. Если за этим восклицательным знаком следует определенная последовательность байтов {0x00, 0x1A, 0xCA, 0xBD} (нулевой байт, маркер конца файла CP/M (исторически таковым не является - прим. пер.), двухбайтовое магическое число), то за ней следуют ноль или более бинарных загрузочных записей, завершаемых нулевым байтом.

 

НЕДОПУСТИМО, чтобы загрузочные записи выходили за пределы загрузочного сектора. Архитектуры МОГУТ определять, что загрузочные записи для данной архитектуры должны быть текстовыми или бинарными, и МОГУТ определять, что бинарные загрузочные записи должны иметь определенный порядок байтов и/или должны быть расположены по секторам. Загрузочным устройствам для архитектур, в которых не указано, что загрузочные записи должны быть текстовыми или бинарными, НЕОБХОДИМО поддерживать оба варианта.

 

Текстовая запись соответствует формату ":<AID>=<offset>+<length>". <AID> - это АИД, для которого предназначен код. <offset> - десятичное число, указывающее смещение байтов, с которого следует начинать чтение, ИЛИ "s", за которым следует десятичное число, указывающее номер сектора, с которого следует начинать чтение. <length> - десятичное число, указывающее количество байт для чтения.

 

Бинарная запись описывается следующей структурой C99:

struct {
  uint8_t record_length;
  uint8_t flags;
  uint16_t load_start;
  uint32_t load_length;
  char aid[];
};

record_length - это число, которое необходимо добавить к смещению данной записи, чтобы пропустить ее. Ему НЕОБХОДИМО быть равным 8 + длина АИД + 1.

 

flags представляет собой битовое поле, для которого определены следующие флаги:

• 0x40: Если установлен, load_start это номер сектора. Если нет, load_start это байтовое смещение.
• 0x80: Если установлен, load_start и load_length установлены в порядке little-endian. Если нет, load_start и load_length находятся в сетевом порядке байт (big-endian).

load_start - это номер сектора либо байтовое смещение, с которого начинается процесс загрузки. load_length - это количество байт для чтения. aid - это АИД предполагаемой архитектуры, которому НЕОБХОДИМО быть нуль-терминированным.

 

Как и в случае с управляемым режимом, действия с загруженными данными специфичны для конкретной архитектуры. Загрузчики, поддерживающие только бинарные записи, должны считать сектор правильным загрузочным сектором, если он начинается с символа "CAB", и находить конец текстовых загрузочных записей, не разбирая их, путем поиска первого "!". Загрузчики, поддерживающие только текстовые записи, не должны учитывать байты, следующие за первым нулевым байтом.

 

Пример 1:

CAB:Lua 5.2=s3+17:Lua 5.3=s3+17:HyperTalk=384+5100!
001A CABD (после ! идёт окончание текстовых записей, после {0x00, 0x1A, 0xCA, 0xBD} идёт начало бинарных записей)
0F (длина первой записи)
C0 (flags - 0x40 + 0x80 - little-endian, смещение сектора)
0900 (начать с сектора номер 9)
0000 0100 (загрузить 65536 байт)
5342 3635 3032 00 (нуль-терминированная строка "SB6502")
00 (бинарных записей больше нет)

Этот диск содержит корректный загрузочный код для Lua 5.2, Lua 5.3, HyperTalk и SB6502. Для Lua 5.2 и 5.3 используется один и тот же загрузочный код длиной 17 байт, начинающийся в начале сектора №3. Загрузочный код HyperTalk имеет длину 5100 байт и начинается с 384 байт диска, что при использовании 256-байтных секторов составляет половину второго сектора. Загрузочный код SB6502 имеет длину 65536 байт и начинается в начале сектора номер 9.

 

Пример 2:

CAB!

Это корректный загрузочный сектор, но он не содержит загрузочных записей.  Это самый надежный способ пометить диск как незагружаемый.

 

---

Источники:
Lizzian, What is OETF?

Solra Bizna, OETF #1: Cross-Architecture Booting (draft)

Принимаются предложения по исправлениям перевода/редактированию.
Все ссылки, кроме ссылки на RFC, были оставлены мной, в остальным старался сохранить оригинальное форматирование.

В канал, откуда сообщения ботом читаются.

Только что, Bumer_32 сказал:

отправить куда?

 

 

В 06.12.2020 в 22:25, Asior сказал:

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

https://pastebin.com/hHstwGG0

Думаю что оно просто пытается юникод засунуть в запрос. Надо аналогично дискордовскому ответу Unicode Escape Sequence делать, тогда может чего получится.

А что будет если несколько человек попытаются отправить сообщение с управлением?

8 часов назад, Wolframoviy сказал:

Unity - лень было качать что либо другое.

Кто будет чанки грузить? - Хз, этот вопрос не обдумал. Вообще я делал это лишь для развлечения. Если тебе нужно грузить чанки то загрузчики чанков в помощь, если на сервере они не работают - сам грузи, или другие пусть грузят.

Чанклодыри на большинстве серверов недоступны, а самим грузить - ну вот

В 31.08.2021 в 23:02, Wolframoviy сказал:

Но вы не можете зайти на сервер или вы даже не дома!

Два единственных вопроса: почему юнити и кто будет грузить чанки?

8 минут назад, AndySingularity сказал:

По-моему, я нигде в этом треде не упоминал lua 

Цитата

я принижаю OC в плане пригодности для обучения программированию.

 

основной язык ОС - луа, все инструменты и библиотеки так или иначе схожи с другими языками

2 минуты назад, AndySingularity сказал:

Если вы называете критику высокого порога вхождения принижением, то да: я принижаю OC в плане пригодности для обучения программированию.

По вашему, луа - высокий порог? в корне не соглашусь

13 минуты назад, AndySingularity сказал:

не пытаюсь принизить OpenComputers

Цитата

почему OC хуже

 

Цитата

хоп и окрасить пиксели экрана в розовый

OpenComputers и так удобен во многих аспектах, тебе не дается голый АСМ или Си, тебе дается большое количество билблиотек, готовые решения от игроков и форумы на которых тебе ответят на тупые вопросы. Хочешь быть пользователем - пожалуйста, в интернете очень много готоых решений - от маленьких программ до операционных систем. Хочешь программировать - сотни готовых библиотек. Нельзя говорить про плохость мода и ныть если ты не удосужился изучить базовые инструменты языка и самого мода в целом. Будучи немного сложнее СС, ОС предоставляет очень много возможностей, так что если мод и сложный, не стоит говорить о нем в плохом ключе

В 28.12.2019 в 17:10, hohserg сказал:

А какие фичи безопасности дает SecureOS?

Некропостинг но лол, всего-то стоило найти тему шестилетней давности

24 минуты назад, Bs0Dd сказал:

Кстати в качестве движка для браузера можно взять NyaDraw, по сути тот же Screen из Майноськи, но спокойно работает под OpenOS без зависимостей. Быстро рендерит странички (переносил я его изначально как часть своего браузера), позволяет рисовать фигуры, и (хе-хе) поддерживает картинки, так что браузеру их нужно только распарсить, вытянуть, и скормить движку. Ну и памяти он ест не сильно много))))

 

Картинки же в .pic? Если да, то я могу свой bmp24 в библиотеку перестроить, можно будет и бмп парсить)

4 часа назад, Bs0Dd сказал:

Да, сделать это несложно и пользы от рисования псевдографическими символами больше. Нет растягивания, отрисовка происходит в два раза быстрее (ведь за один раз мы рисуем сразу два пикселя), можно рисовать картинки разрешением до 160х100.

Слева обычная отрисовка от ov3rwrite, справа полупиксельная от меня

  

 

Кстати о картинках в 160х100

 

Код тут: https://pastebin.com/pVr3dkXZ

 

Пы.Сы.: Всплыли неприятные глюки при обработке данных (я за BMP не шарю, так что оставляю это на более опытных)

• Картинка рисуется в отзеркаленном виде Поправил в коде
• Если создать картинку разрешением меньше экранного, то ее перекорежит

 

Оба глюка присутствуют в исходной программе, картинки делал в PS7.0 и Paint-е, разницы никакой

Я к чему и говорю, можно либо обрезать либо сжимать, а так спасибо за поправки)

Всем привет! Решил немного позабавиться и написать отрисовщик bmp, вот что из этого вышло:

Использование:

bmp24 --path=<путь до файла>

Ссылки на гитхаб и пастебин:

https://pastebin.com/7spSwqPG

https://github.com/ov3rwrite/bmp24/tree/main

Прикольно, но существует ряд ограничений которые потом (возможно) буду допиливать:

• только 24-разрядные bmp
• максимальный размер загружаемого изображения 160 на 49 100 пикселей
• растянуто в 2 раза из-за прямоугольного разрешения 1 символа пофикшено Bs0Dd
• медленно выводит

Немногословно, но и сказать больше нечего.

Спасибо за внимание!

 

В 02.12.2020 в 20:16, Asior сказал:

Кстати где можно найти API именно такого способа работы с дискордом? Или это расковыряли браузерный дискорд

Глянь код, это как уже сказал @Taruu самый обычный Discord API.

К слову, идея была частично слизана с https://github.com/saucecode/ripcord-api , оттуда урлы и брал.

8 минут назад, eu_tomat сказал:

Ради чего?

 

Если новая тема будет посвящена очередному этапу разработки, то нет, создавать новую тему не стоит.

Если же в новая тема будет содержать описание готовой программы и ссылку на рабочий код, то это имеет смысл.

 

Предлагаю пока что продолжить обсуждение в этой теме. А новую тему создать, когда уже появится что-то пригодное к использованию.

Да, я уже про готовый продукт.

13 часа назад, ECS сказал:

Пардон, мой косяк. Не указал, что в регулярке нужно юзать шестнадцатеричную систему:

str:gsub("\\u([a-fA-F%d]+)", function(code)
    return unicode.char(tonumber(code, 16))
end)

Проверил в кубаче, всё пашет:

Спасибо, надеюсь скоро возьмусь за проект, стоит ли тему новую создавать ради этого?

2 часа назад, Zer0Galaxy сказал:

Если не ошибаюсь, существует шаблон для шестнадцатеричных символов - %x

Кстати, \u вроде добавили только в Lua 5.3

3 часа назад, ECS сказал:

Проверил raw-ответ через сокет. API дискорда отдаёт сразу экранированные символы, либы опенкомпов тут ни при чём. Видимо, постман (как и ARC, кстати) сам их декодирует в русский эквивалент, из-за чего возникло подозрение на опенкомпы: 

 

 

Значит, решение с регуляркой остаётся верным. Или нужно модифицировать JSON-либу соответственным образом, но всё равно используя ручной декодинг

 

Только я протестил и почему-то оно одну часть слова кодирует верно, а другую нет, хотя на том же Lua Demo оно работало прекрасно.

8 минут назад, ECS сказал:

С чем? Судя по скринам, парсинг абсолютно корректен

Чем-то другим*