VladG24_YT

Для OpenComputers из внутриигровых редакторов есть:

• ShEdit от LoganDark - тот же edit.lua, но с подсветкой синтаксиса, автоматическим отступом при переходе на новую строку, нумерацией строк и возможностью прыгать к нужной строке. (Ссылка: https://oc.cil.li/topic/1495-shedit-editlua-but-with-syntax-highlighting/)
  Скрытый текст

  

   

• NIDE от niki0710 - редактор кода с подсветкой синтаксиса, нумерацией строк и деревом файлов. (Ссылка: https://www.reddit.com/r/OpenComputers/comments/les6vr/nide_update_syntax_highlighting/)
  Скрытый текст

  

   

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

Многозначащий вопрос, кто корпит над документацией?

¯\_(ツ)_/¯

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

Пока у развивающегося Ocelot Brain ведётся работа над полноценной документацией, я решил что было бы неплохо, если бы демо Оцелота было бы доступно не только на Scala, но и на во многом совместимом со Scala языке программирования Java. Тогда бы возросла доступность Оцелота для тех разработчиков, которым уж совсем не даётся Scala, а попробовать Оцелот хочется.

Поэтому я создал гист на ГитХабе, в котором приведён абсолютно тот же (по функционалу) код что и в оригинальном Demo.scala, но уже для Java 8: https://gist.github.com/Vladg24YT/dcbb1ed68658122f21e8edcf32f0db6d

Лог PowerShell'а, доказывающий работоспособность демо, прилагается:

https://pastebin.com/U6NCg97Y

Содержимое Ocelot.log:

2021-02-08 23:58:04.752 [main] INFO  Ocelot - Brain initialization...
2021-02-08 23:58:04.754 [main] INFO  Ocelot - Version: 0.6.5
2021-02-08 23:58:04.754 [main] INFO  Ocelot - Loading configuration...
2021-02-08 23:58:04.949 [main] INFO  Ocelot - Registering available machine architectures...
2021-02-08 23:58:04.989 [main] INFO  Ocelot - Found a compatible native library: 'Ocelot-0.6.5-lua52-native.64.dll'.
2021-02-08 23:58:05.030 [main] INFO  Ocelot - Found a compatible native library: 'Ocelot-0.6.5-lua53-native.64.dll'.
2021-02-08 23:58:05.032 [main] INFO  Ocelot - Registering loot (floppies and EEPROMs with standard OpenComputers software)...
2021-02-08 23:58:05.035 [main] INFO  Ocelot - Registering entity constructors (for persistence purposes)...
2021-02-08 23:58:05.058 [main] INFO  Ocelot - Initializing unicode wcwidth.
2021-02-08 23:58:05.068 [main] INFO  Ocelot - Initializing font glyph widths.
2021-02-08 23:58:05.086 [main] WARN  Ocelot - Invalid glyph char code detected in font.hex. Expected 0<= charCode <10000, got: 1D300
2021-02-08 23:58:05.087 [main] WARN  Ocelot - 87 total invalid glyph char codes detected in font.hex
2021-02-08 23:58:05.087 [main] INFO  Ocelot - glyph width ready.
2021-02-08 23:58:05.091 [main] INFO  Ocelot - Initialization finished.
2021-02-08 23:58:11.636 [main] INFO  Ocelot - Preparing for Ocelot shutdown...
2021-02-08 23:58:11.637 [main] INFO  Ocelot - Ocelot is shut down.

21 минуту назад, OpenReactor сказал:

Хочу зделать запрос через консоль как так зделать?

io.write("Install OpenOS? [Y/n] ")

Далее, если нужна проверка на Y, то

if ((io.read() or "n") .. "y"):match("^%s*[Yy]") then
  --код, если пользователь ввёл y или Y
end

А если нужна проверка на N, то

if not ((io.read() or "n") .. "y"):match("^%s*[Yy]") then
  --код, если пользователь ввёл n или N
end

Оригинал

Отличный эмулятор, но у меня возникли проблемы при работе с событиями Brain'а из Java-кода.

При использовании EventBus.listenTo() и передаче (в качестве второго параметра) анонимного обработчика любого события кроме стандартного Event (например BeepEvent), линтер выдаёт ошибку о "несовместимости типов", вида

incompatible types: <anonymous Main.BeepEventFunction> cannot be converted to Function1<Event,BoxedUnit>

где BeepEventFunction - это абстрактный класс:

abstract class BeepEventFunction implements Function1<BeepEvent, BoxedUnit> {}

Пробовал передавать разные обработчики, но ошибка как была, так и осталась. Свой код и попытки решения расписал в соответствующем issue на GitLab.

Нашёл решение проблемы, надо просто в теле метода apply() привести Event к BeepEvent.

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

Кое-кто говорил мне, что оцелот десктоп жрет ресурсы компа как обычный майн с ОС. Я эту инфу не проверял, понятия не имею, правда ли это. Если она истинная, то в чем может быть причина? Само ядро эмулятора много жрет или оцелот-десктоп?

Не знаю, у меня Ocelot Desktop ест почти в 6 раз меньше оперативной памяти, чем майн. По остальным показателям - одинково.

1 час назад, Totoro сказал:

Если тебе нужна интеграция в IDE, может быть больше подойдёт не Ocelot Brain, а Ocelot Desktop?
Это уже на основе Brain готовый эмуль, с графикой и прочим.

Знаю его, продуманный и удобный эмулятор. Но я уже готовый эмуль использую - OCEmu от Zen1th.

Ocelot-Brain я выбрал чтоб сделать эмулятор, который был бы частью OCLIDE, по UI напоминал бы OCEmu или первые сборки OCEmulator, а из фич в нём было бы умеренное логирование состояния машины (а не спам событий как у debug-mode в OCEmu) и какой-нить вывод при взаимодействии с Component API (например отслеживание/симуляция сигналов component.redstone).

Всё что меня остановило в попытках создать такой эмулятор - непонимание двух вещей: как реализовать терминало-подобный интерфейс (спасибо NEO за наводку на Canvas) и где у Ocelot-Brain писать логику к обработчикам событий.

P.S. Блин, пока писал это сообщение, уже сам со scala.Function1 разобрался

Новое обновление: PAT Pre-release 0.0.7

- Добавлена панель вывода, куда был перенаправлен System.out (java.util.logging.Logger всё ещё выводится в консоль/терминал)

- Добавлена GUI-заготовка для навигатора по переменным

- Заранее собранные версии OCEmu для Windows (собрана на 10 Pro 64-bit версии 19042.746) и Ubuntu (собрана на 20.04.2 LTS) можно скачать с https://github.com/OCLIDE-Modules/OCLIDE-OCEmu
- Слегка изменён интерфейс конфигуратора

- Фикс бага с запуском OCEmu (ошибка с read-only файловой системой)
- Фикс бага с заданием неверной папки при создании проекта
- OCEmu был пересобран с использованием переписанного скрипта misiuji для MSYS2, библиотека SDL обновлена до 2.0.5
- Проведена тотальная реорганизация кода, часть методов и элементов интерфейса вынесено в отдельные классы

Скачать: https://github.com/Vladg24YT/OCLIDE/releases/tag/v0.0.7

Скриншот с новой версии:

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

он пытается создать его в системной папке

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

Пытался открыть файл, хоть какой-нибудь. Фиг там.

Исправил. Выпущу в 0.0.7 (в ближайшие выходные).

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

его толи переписали, толи еще че сделали.

Эмулятор не был модифицирован. Это та же версия, что лежит сейчас на GitHub у Zen1th: https://github.com/zenith391/OCEmu

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

Базовый старт, и сразу непонятное пищание.

Проверил, есть такая неприятность. Это проблема скрипта сборки на Windows, так как такое же пищание есть и на отдельно собранной версии. К 0.0.7 пересоберу со скриптом от misiuji, там есть необходимый фикс для SDL 2.0.5.

Новое обновление: PAT Pre-release 0.0.6

- OCEmu сменён на форк от Zen1th, коммит ad6da27ff5acce0a9778a7052e06cc4acfdb6ade. OpenOS соответственно обновлён до 1.7.5.
- Добавлена поддержка Lua 5.3
- Удалены бинарники Lua 5.2 для Windows
- OCEmu вынесен в отдельный поток
- Фикс проблемы с предустановкой OpenOS на файловую систему машины
- Фикс нерабочего алгоритма копирования проектов на файловую систему машины
- Убрана необходимость ввода абсолютного пути к файлу при создании

Скачать:

https://github.com/Vladg24YT/Oclide/releases/tag/v0.0.6

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

И на нем лучше и писать ибо там ось новой версии

Приму к сведению.

Новое обновление: PAT Pre-release 0.0.5

- Добавлен алгоритм запуска OCEmu для Ubuntu и Arch Linux (требует предустановленного интерпретатора Lua 5.2 и библиотек luaffib, luafilesystem, luautf8 и SDL2)
- Обновлены библиотеки
- Фиксы запуска OCEmu
- Фикс отображения неверной версии в заголовке основного окна IDE
- Фикс невозможности создать проект на дистрибутивах Linux
- Фикс критической ошибки при запуске OCEmu
- Удалена библиотека LuaJ, код переделан на работу с репаком OC-LuaJ от MightyPirates через Ocelot Brain

Скачать:
https://github.com/Vladg24YT/Oclide/releases/tag/v0.0.5

Набросок окон автодополнения кода:

16 минут назад, NEO сказал:

Что думаешь про Canvas?

Если вы имеете ввиду java.awt.Canvas, то выглядит похоже на то, что нужно. Спасибо за наводку)

18 минут назад, NEO сказал:

Swing а в нём если не ошибаюсь был холст для рисования символами.

Изначально я изучал туториалы Oracle по отрисовке именно в Swing, где вся отрисовка ведётся через paint(java.awt.Graphics) и paintComponent(java.awt.Graphics), а обновлённая статья Oracle по отрисовке и в AWT и в Swing не упоминает Canvas совсем, поэтому мне придётся сначала поэкспериментировать с этим классом, прежде чем я смогу точно сказать, то ли это, чего мне не хватало.

16 минут назад, NEO сказал:

Зачем пиксели?

В данном случае под "пикселями" я имел в виду не обычные пиксели, а единицы измерения разрешения экрана OC.

16 минут назад, NEO сказал:

для ОС можно использовать символьную графику

Если речь идёт об отрисовке через ASCII, то я не совсем пониманию, как с помощью такой отрисовки возможно реализовать изменение цвета заднего фона индивидуального символа.

1 час назад, hohserg сказал:

добавить поддержку других эмуляторов сред выполнения, например, Оцелота

Об этом думал, некоторые наработки даже оставил в коде. Благодаря совместимости Scala и Java, интегрирование Ocelot Brain довольно лёгкая задача, но перед её реализацией меня остановила нехватка собственных знаний для создания окна вывода (а-ля интерфейс экрана из OC), так как простой терминал ввода/вывода невозможно использовать для работы с растровой графикой. Создать двумерный массив из 8000 одинаковых компонентов и использовать каждый отдельный как пиксель конечно можно, но делать такое, тем более на Java - это всё равно что отправить оперативную память прямиком в ад, а писать собственный GUI-фреймворк для работы с классом Graphics из AWT ради одного простецкого окошка как-то нелогично. Тем не менее полностью от этой задумки я пока не отказываюсь.

1 час назад, hohserg сказал:

или самого майна

Да, это легко сделать, но моя первостепенная задача была создать именно standalone-среду. Так что, если поддержка майна и будет сделана, то не раньше релиза.

Новое обновление: PAT Pre-release v0.0.4

- Добавлен алгоритм предустановки OpenOS в файловую систему машины
- Фикс обновления списка компонентов в конфигураторе
- Фикс парсинга конфига OCEmu
- Добавлена поддержка любых UUID файловой системы помимо той, что стоит по умолчанию (34eb7b28-14d3-4757-b326-dd1609b0a92e)
- Ряд фиксов в коде редактора, конфигуратора и вспомогательных классов
- Начата работа над автодополнением кода Lua стандарта 5.3

Ссылка: 
https://github.com/Vladg24YT/Oclide/releases/tag/v0.0.4

Скриншот обновлённого конфигуратора:

1 час назад, eu_tomat сказал:

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

Хм... Тогда получается, что в принципе такое версионирование по SemVer'у вполне может существовать, окей. Но тем не менее я не смогу применить SymVer к "релизам" OCLIDE по двум причинам:

1. Я не считаю, что текущее состояние программы можно выводить на релиз. Слишком много мелких косяков.
2. Меня не устраивает "максимальная свобода" нулевой мажорной версии, ибо мне хочется всё-таки связать себя обязательствами доведения продукта до относительной завершённости с целью недопущения повторения истории со всякими долгостроями, которые потом просто закрываются.

1 час назад, eu_tomat сказал:

Кстати, какой API предоставляет твоя OCLIDE и с какими версиями API эмуляторов совместима?

Касательно эмуляторов - версия 0.0.3 точно совместима с OCEmu от gamax92, коммит bcb7a1ad6a370e3254afa9f7d483307e811ee5c6. Тесты с другими билдами не проводил.

У OCLIDE нет чётко сформулированного API. Но в принципе версию 0.0.3 можно представить как набор следующих интерфейсов:

• Графический интерфейс, созданный через библиотеку Swing из пакета AdoptOpenJDK 8.0.265.01.
• Редактор кода на Java 8 с применением RSyntaxTextArea 3.1.1, AutoComplete 3.1.0 и SpellChecker 3.1.0 за авторством bobbylight.
• Конфигуратор для OCEmu (без спецификации версии, так как он не поставляется вне OCLIDE), совместимый с вышеупомянутым билдом OCEmu.
• Вспомогательная утилита UUIDGenerator, использующая библиотеку "uuid" OpenOS 1.7 для генерации UUID компонентов для машин OCEmu.
• Набор классов в пакете ru.VladTheMountain.oclide.configurator.ocemu.component, обеспечивающих взаимодействие конфигуратора и редактора.

1 час назад, eu_tomat сказал:

А какому пункту спецификации это противоречит?

Второму пункту.

Согласно абзацу перед пунктами спецификации:

Цитата

Слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT), «ОБЯЗАТЕЛЬНО» (REQUIRED), «СЛЕДУЕТ» (SHOULD), «НЕ СЛЕДУЕТ» (SHOULD NOT), «РЕКОМЕНДОВАННЫЙ» (RECOMMENDED), «МОЖЕТ» (MAY) и «НЕОБЯЗАТЕЛЬНЫЙ» (OPTIONAL) в этом документе должны быть интерпретированы в соответствии с RFC 2119.

Тем временем RFC 2119 гласит:

Цитата

1. MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
...
4. SHOULD NOT

This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Во втором пункте спецификации использован термин MUST, а в четвёртом пункте используется SHOULD NOT:

Цитата

 

2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

...

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

 

Так как в данном случае способ версионирования с нулевой мажорной версией можно назвать полезным лишь субъективно, а объективного взвешивания всех "за" и "против" использования такого способа не проводилось, то можно смело заявить что четвёртый пункт спецификации SemVer не переопределяет и не опровергает второй.

Единственным возможным верным (с точки зрения RFC 2119) использованием нулевой мажорной версии SemVer в данном проекте (OCLIDE) я вижу лишь вариант, при котором в публичный доступ так же выкладывались бы INDEV-версии за период с Марта 2020 (коммит 9894b7a) до Января 2021 (коммит 3dc00f0, включительно).

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

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

Поддерживаю.

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

Немного оффтопа, но по спецификации semver, версия 0.0.3 имеет право на существование?

По спецификации 2.0.0 семантического версионирования, ни одна из версий 0.0.1, 0.0.2 или 0.0.3 не имеют право на существование. По данной спецификации версии следовало бы именовать 1.0.0, 1.0.1 и 1.0.2

Но я узнал о стандарте semver уже после выпуска 0.0.2, потому решил не переписывать номера версий, ибо это потребовало бы модификации исходников уже "выпущенных" версий (для соответствия тега релиза и текста в самой программе) и их последующего перевыпуска с удалением неверных тегов.

Как итог: я собираюсь продолжить именовать ПАТ-релизы 0.0.X, ПБТ-релизы - 0.X.Y, а пост-релизные версии OCLIDE можно уже будет именовать по semver'у.

9 часов назад, Bs0Dd сказал:

А кстати, что за "проекты" такие, и как они работают?

Чисто косметическая вещь, чтобы визуально разграничивать все файлы/скрипты на группы. В ИСР они отображаются через дерево файлов в левой части интерфейса.

Принцип работы пока очень простой и банальный:

1. При создании проекта создаётся директория
2. Все файлы, созданные в рамках этого проекта, хранятся в ней
3. Перед запуском OCEmu, директория проекта копируется на файловую систему машины в папку /home

@vford в эмуляторе старая версия OpenOS вследствие того, что взят билд OCEmu датированный где-то 2016 годом. Обновление конечно же будет, но мне сначала надо научиться ладить с MSYS2 и Luarocks чтобы скомпилировать наиболее свежие исходники.

@eu_tomat заточка под OpenComputers в данный момент заключается только в нестабильной интеграции с эмулятором.

Под "интеграцией" я подразумевал созданный с нуля конфигуратор для машины OCEmu и запуск самого эмулятора из кода ИСР.

У многих новичков возникает вопрос - где писать код для OpenComputers? Кто-то советует VS, кто-то сторонник IDEA, кому-то по душе Atom, а кто-то вообще пишет код сразу в игре. Я решил пополнить этот список вариантов собственным решением.

Вашему вниманию представляется интегрированная среда разработки (ИСР) под OpenComputers - OCLIDE. Проект находится на стадии публичного альфа-тестирования, поэтому критика приветствуется.

На данный момент в ИСР присутствуют:
- Подсветка Lua-синтаксиса
- Система проектов
- Интеграция с OCEmu (OpenOS 1.7.5)
- Поддержка Windows 10 и Ubuntu 20.04

В планах на будущее:
- Автодополнение кода
- Добавление эмулятора на базе Ocelot Brain
- Адаптация кода для работы на Mac

- Опции настройки цветовой палитры редактора и используемого стандарта Lua

- Поддержка сторонних переводов приложения

Ссылка на проект: https://github.com/Vladg24YT/Oclide/ (ветка master - стабильная, ветка oclide-rc1 - indev сборки)

Прога весит ~25 Мб, потребляет 167 Мб ОЗУ.

Скриншот:

Доброго времени суток.

Я решил попробовать себя в написании игр на Lua и воссоздать клеточный автомат "Жизнь" Джона Конвеея для OpenComputers 1.7.5.

Описание:

В игре существуют два типа клеток - живая и мёртвая. Суть игры в том, чтобы расставить живые клетки и затем наблюдать за их "поведением". Правила автомата очень просты:

• Если вокруг мёртвой клетки ровно 3 живых - клетка оживает
• Если вокруг живой клетки меньше 2 или больше 3 живых - клетка умирает
• В остальных случаях клетки сохраняют своё состояние

Известные недочёты:

• Вычисление каждого следующего поколения может занимать до полуминуты
• При контакте с краями поля, любая фигура постепенно погибает в соответствии с правилами автомата
• При запуске симуляции, её можно остановить только перезагрузкой в shell

Скачать:

Репозиторий на GitHub: https://github.com/Vladg24YT/Game-Of-Life

Последняя версия (1.0.0): https://github.com/Vladg24YT/Game-Of-Life/releases/tag/1.0.0

Скриншот: