Перейти к содержимому

ECS

Гуру
  • Публикации

    533
  • Зарегистрирован

  • Посещение

  • Победитель дней

    203

Сообщения, опубликованные пользователем ECS


  1. 2 часа назад, ov3rwrite сказал:

    Это толи internet api чета крутит либо что то еще из OC.

    О, это уже интересно. Наверняка json-либа при конвертации в луа-таблицу автоматом эскейпит символы, либо как-то по-своему обрезает экранированный результат от API. Если дело в ней, то сменить либу не будет проблемой. К примеру, с этой проблем не возникало


  2. 1 час назад, Avevad сказал:

    Банальный вопрос - а если придет сообщение без кириллицы, но с сочетанием буквы u и цифр? Кажется, должно приходить что-то еще, или же такие сочетания должны быть экранированы, так что не все так просто.

    В том и проблема. Обычно подобные вещи экранируются редко встречающимися в повседневном общении комбинациями символов (по типу эмодзи 😀 у ВК). Тут вообще жесть какая-то. Мб у дискорда есть иные опции по экранированию юникода - эт уже вопрос к топикстартеру, ибо у него по ТЗ идет только uКод. Ну и ответ я дал соответственный


  3. В 18.11.2020 в 20:49, ov3rwrite сказал:

    Также возникла проблема с русскими символами, вместо них оно выводит Unicode Escape Sequence в виде "u0422u0435"

    Так а чо, пройдись регуляркой по этой стринге, и всё:

    str = "Meow u0422u0435"
    
    str = str:gsub("u(%d+)", function(code)
        return utf8.char(tonumber(code, 16))
    end)
    
    -- Meow Te

    Если дискордыч всегда выдаёт 4 знака после "u", то разумнее будет воспользоваться паттерном "u(%d%d%d%d)" для более корректного декодирования ситуаций, когда после экранируемой последовательности следует обычная цифра, не входящая в неё. Например, "Meow u042215" (где 15 - просто текст)

    • Нравится 3

  4. О, забавно. Видимо, этой копией была локальная папка с именем в виде адреса дискеты на загрузочном диске в папке Mounts. И, видимо, поэтому система её как-то неадекватно обрабатывала


  5. Вполне возможно, что проявился бажок оськи. Хотя я без проблем записал файл на дискету по адресу следующим образом:

    local fs = require("Filesystem")
    
    for proxy, path in fs.mounts() do
      -- В моем случае адрес компонента дискеты стартует с "1c5e3"
      if proxy.address:sub(1, 5) == "1c5e3" then
        fs.write(path .. "test.lua", "Hehe")
        break
      end
    end
    
    -- Либо если известен полный адрес компонента, то
    local paths = require("Paths")
    fs.write(paths.system.mounts .. address .. "test.lua", "Hehe")

    При этом никаких дубликатов компонента в проводнике при копипастинге этого же файла, при удалении и редактировании не наблюдаю. Можно лишь гадать на кофейной гуще, что идёт не так. Может быть, дискета была сдублирована в креативе?

    • Нравится 1

  6. @FireAid если всё так, как заметил @hohserg, то это вряд ли осуществимо: майноська имеет свой набор тараканов в API, хоть и схожих, но всё же отличных от опеносовских. Само терминальное приложение сделать проблем не составит, накидать набор базовых шелл-скриптов по типу ls/rm/mkdir тоже. Однако запускать опеносовские скрипты, использующие специфичные либы по типу term/tty/thread это не позволит, ибо майноська банально  имеет иную архитектуру.

     

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


  7. Отлично пашет, за полчаса ковыряния нашёл всего лишь два явных бага:

    • Нет реакции на скроллинг мышью. В списке ивентов через dmesg не высвечивается
    • Некорректно работает computer.maxEnergy(), возвращая math.huge вместо фикисированного числа. В нативных опенкомпах при отключенном поглощении энергии в конфиге (или при отсутствии энерго-модов) функция всегда возвращала 500

    Еще было бы крайне приятно, если бы окошечки экранов можно было ресайзить, т.к. более 2х виртуальных экранов даже на WQHD-монитор не влезет. В идеале - вообще группировать их с изменением масштаба в автоматическом режиме плитками а-ля Snap Assist. Но это жир

    • Нравится 3

  8. В 22.04.2020 в 22:16, Xottabich сказал:

    MineOs посылает на дальние земли Русские символы в имени Профиля и вызывает ошибку.

    В каком приложении или при каких условиях? Клиент на винде, линуксе? Поставил оську с юзером "Тест", добавил ещё одного "Мяу-мяу", и всё в порядке:

     

    Скрытый текст

    HQEXjzg.png

     


  9. 26 минут назад, Asummonster сказал:

    Может стоит сделать некий "режим совместимости" с OpenOS программами

    Для некоммерческого проекта, имхо, овчинка не стоит выделки. В сурвайвале на сервере я обычно упираюсь в потребность в репрезентативных гуишных приложениях для мониторинга/управления реакторами/фабриками, либо удалённого управления роботами-шахтёрами с отображением графической статистики на экране, и даже не припомню, чтобы пользовался какой-либо консольно-ориентированной программой (разве что на старте игры или для быстрого просмотра возможностей компонентов). Всё так или иначе упиралось в GPU'шный мазохизм с графикой и тоннами setBackground/setForeground: поэтому, собственно, я и стал писать майнось как более-менее удобный конструктор для гуишных приложений с возможностью запуска приложух за пару кликов. Лично для себя я не вижу ни удобства, ни выгоды в написании приложения-враппера, имитирующего опеносовские либы tty/term/shell/thread, которым даже пользоваться не буду. Ну серьёзно, какие конкретно опеносовские скрипты настолько жизненно важны и настолько сложны в написании, что их нельзя реализовать в майноське и выложить в маркет? Уже в третий раз спрашиваю, а ответа всё нет...


  10. Увы, это всё же разные ОС, и имеют хоть и схожие, но различные API. Простые скрипты по типу установки уровня редстоун-сигнала от I/O-блока вряд ли будут отличаться, а вот отображение или чтение пользовательских данных уже могут сильно разниться, т.к. опенось имеет консольную систему ввода-вывода, а майнось - графическую. Я всё же повторю свой вопрос, ибо ответа не узрел: какого функционала опеноси тебе не хватает в майноси? Какого рода программы/API ты считаешь нужным перенести? И в чем заключается сложность изучения API майноси?


  11. 8 часов назад, hohserg сказал:

    Есть возможность добавить в MineOS стандартные либы OpenOS?

    Хотелось бы serialization

    А какого функционала либ из опеноси (помимо сериализации) по твоему мнению не хватает? Сериализация/десериализация и так доступна из коробки, на вики вся инфа: https://github.com/IgorTimofeev/MineOS/wiki/Text-API

     

     


  12. 6 часов назад, MrAbad сказал:

    Однако соглашусь, что некоторые сходства с ООП есть

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

     

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

    • Одобряю 2

  13. Если нужно прям самому и с нуля написать, то в качестве вспомогательного материала можешь чекнуть исходник майносевского упаковщика файлов, он крайне прост. Там используются некоторые специфичные методы filesystem типа writeBytes/readBytes, но реализовать ихи или стыбзить не составит труда:

     

    https://github.com/IgorTimofeev/MineOS/blob/master/Libraries/Compressor.lua

    https://github.com/IgorTimofeev/MineOS/blob/master/Libraries/Filesystem.lua

     

    А если нужно сжатие данных, то поверх этой конструкции придется прикрутить какой-нибудь deflate


  14. Поправьте меня, если я ошибаюсь, но, насколько я помню, компонент интернет-платы не позволяет провернуть операцию, аналогичную seek - поэтому приходится загружать контент целиком, "скипая" содержимое до интересующего места. А логи в примерах довольно жирные для опенкомпов, файлы > 500 кб всегда грузятся ощутимо долго.

     

    Если есть доступ к директории сервака, то можно накатать простенький php-скрипт, выдающий содержимое файла с конца:

    https://stackoverflow.com/questions/2961618/how-to-read-only-5-last-line-of-the-text-file-in-php

     

    Или же при наличии сокет-сервера пушить в него каждую отправляемую в лог строку, а затем читать на опенкомпах через internet.connect. Если же доступа к хосту нет, но есть собственная VPS'ка - можно накатать аналогичный скрипт с небольшими модификациями для файлов по удалёнке.

    • Нравится 2

  15. 43 минуты назад, Zer0Galaxy сказал:

    К стати, ссылка уже недоступна :unsure:

    О, сколько ж лет в обед этой теме! Спасибо, ссылку поправил на старый коммит, хоть проблемы с зависимостями всё равно останутся - в той же ветке гита можно найти и их, если надо. Легаси, что ж поделать. Однако общий принцип работы понять не составит труда

    • Нравится 1

  16. 1 час назад, Hay сказал:

    Только не понятно, зачем это сделали, теряется смысл использовать эту IDE, если не можешь даже вывести результат.

    Это сделали из-за банального отсутствия стандартного текстового вывода, т.к., как уже сказали выше, ось заточена под графическое отображение данных, а не текстовое. При потребности отображения текста я обычно добавляю в оконное приложение элемент интерфейса GUI.text(), а затем меняю его параметр .text в процессе. Если требуется непрерывный вывод информации с историей, то альтернативой может послужить GUI.textBox().

     

    Если всё же требуется вывести отладочную инфу "по-быстрому", то имеется функция GUI.alert(...), принимающая аргументы любого типа по аналогии с print(...) и вызывающая диалоговое окно с переданными данными.

     

    А смысл использовать эту IDE всегда лишь один - отсутствие более комфортных средств разработки (к примеру, во время игры на удалённом сервере без доступа к файловой системе). Да и банальную подсветку синтаксиса никто не отменял, эта IDE существует чисто для удобства по той же причине, по которой существует edit.lua в OpenOS.

    • Нравится 2
×
×
  • Создать...