ECS

7 часов назад, Oleshe сказал:

Test.app.rar -- оно

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

7 часов назад, Oleshe сказал:

MineCode IDE, с снапшота 1.8.0 оно при стираний последнего символа в строке выкидывает в java.outOfBounds

Ошибка в либе unicode, иссую на гите создал, должны пофиксить. Вообще, если уж играешь на снапшотах, то стабильности ждать не приходится - на то они и снапшоты

7 часов назад, Oleshe сказал:

но я всё же был бы очень* признателен если-бы вы помогли доделать мою программу в прекрасный вид как и задумывается 

Доделать - не, слишком сложно и непонятно, а немного инфы по системе дать могу:

1) При работе с UI и workspace не стоит злоупотреблять слушателями нажатий на клавиши через event.addHandler, т.к. это низкоуровневая фича, предназначенная для обработки событий вне интерфейса. К примеру, для библиотеки keyboard и реализации метода isKeyDown она вполне пригодна, а вот в случае с интерфейсом она дарует лишь попоболь, заставляя вручную вызывать event.removeHandler при любых ошибках или при закрытии приложения.

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

А если ты создаешь полноэкранное приложение с кастомным workspace (существующее вне рабочего стола ОС), проще всего использовать назначить обработчик событий для всего рабочего пространства. После выхода из приложения все обработчики также будут удалены.

2) Юишка в майноси построена по принципу Single Thread Application с 1 общим бесконечным циклом на всё рабочее пространство. При возникновении события каждый визуальный элемент на экране получит возможность как-то отреагировать на него через eventHandler. Если тебе нужно параллельно работать в интерфейсе и делать что-то, скажем, раз в 5 сек, то:

local workspace = GUI.workspace()

local interval = 5
local deadline = uptime + interval

-- Добавляем в рабочее пространство кнопки, картинки и т.п.
...

-- Назначаем глобальный обработчий событий для всего рабочего пространства
workspace.eventHandler = function(_, _, e1)
  if computer.uptime() > deadline then
    -- Осуществляем желаемое действие раз в 5 сек
    	
    deadline = computer.uptime() + interval
  end
end

-- Пуллим события с максимально возможной скоростью и нулевой задержкой
workspace:start(0)

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

3) Если прям уж СИЛЬНО хочется работать с потоковыми библиотеками, то хозяин - барин. Но в этом случае как минимум не следует использовать глобальные переменные типа b, wrk, todraw, которые гарантированно приведут к конфликтам имён и засорят пространство

6 часов назад, Oleshe сказал:

Не, это сторонний список в котором всё подгружается нормально

Понял, пардон

6 часов назад, Oleshe сказал:

if tmparrows.right == true then -- ошибка тут, не видит элемента в списке или списка, не знаю 🥶

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

GUI.alert(b, todraw[b], todraw)

Без исходников со всеми ресурсами или как минимум скрина со стектрейсом больше сказать проблематично

Без полного сырца с ресурсами черт ногу сломит. Стектрейс ошибки хоть приложи или конкретную строку(

С ходу могу лишь сказать, что объекты gui.image создаются некорректно, т.к. 3 аргументом должен идти путь до изображения, а ты прокидываешь булево значение:

-- Неверно
if images.right then
  wrk:addChild(gui.image(34, todraw[b].time, images.right))
end

-- Верно
if images.right then
  wrk:addChild(gui.image(34, todraw[b].time, "/path/to/image.pic"))
end

Также удаление элементов из todraw идет без смещения индексов, из-за чего в таблице остаются пустоты. К ошибке вряд ли приведет, но память все же не резиновая:

local b = 1

while b < #todraw do
  if todraw[b]['time'] == -6 then
    table.remove(todraw, b)
    b = b - 1
  else
    b = b + 1
  end
end

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

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

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

https://github.com/IgorTimofeev/MineOS/blob/master/Applications/Finder.app/Main.lua#L228-L242

https://github.com/IgorTimofeev/MineOS/blob/master/Libraries/Network.lua#L398-L400

5 часов назад, Bumer_32 сказал:

НУ ИГОООРЬ с MineOsEfi всё равно не работает хотя с другими биосами работает как так

Проверил в последней версии оцелота как софтверную установку биоса, так и через ПКМ. Работает и штатный, и Cyan и майносевский. Мб ты качаешь full версию вместо minified?

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

пк (любой) отказался запускаться, и думает что EEPROM-а нету

Спасибо, исправил. Постараюсь внимательнее проверять фичи перед пушем. Или на Тотору спихну, пусть ревьювит))0

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

Переведу на русский: защита от дурака

В этом и заключается вопрос топикстартера: в чем смысл такой защиты, фича ради фичи? Если у дурака имеется доступ к eeprom, то не всё ли равно, вызывать eeprom.makeReadonly() или eeprom.makeReadonly(eeprom.getChecksum())?

15 минут назад, Bumer_32 сказал:

но что будет при Ctrl Alt C?

По идее воркспейс оси должен перезапуститься, убив все рабочие приложения и выполнив своеобразный "soft reboot" без физического перезапуска компьютера. Вообще это сочетание клавиш изначально задумывалась в роли прослойки совместимости с опеносевским софтом (на что был благополучно положен болт), а также для экстренного закрытия полноэкранного приложения, взявшего event.pull в монопольное пользование

14 часа назад, Bumer_32 сказал:

в либе GUI нельзя ограничить поле Input только буквами или только цифрами

Можно, достаточно присоединить функцию validator к объекту input. Например:

local input = GUI.input(2, 2, 30, 3, 0xEEEEEE, 0x555555, 0x999999, 0xFFFFFF, 0x2D2D2D, "Hello world", "Placeholder text"))

-- Дозволяем вводить лишь числа
input.validator = function(text)
  return text:match("%d+")
end

-- Делаем что-то после ввода числа
input.onInputFinished = function()
  
end

14 часа назад, Bumer_32 сказал:

но или я не понимаю или оська не даёт шагу но она сама даёт ошибку тем самым закрывая прогу

xpcall(abc), а не xpcall(abc()), т.к. вместо безопасного вызова abc через xpcall ты просто вызываешь ее

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

но в модифицированной mineOS новые фишки работают только благодаря Lua 5.3

Какие, например? И почему их нельзя реализовать средствами 5.2 через операции в десятичной системе? 

@num_pi, технически realTime хоста можно узнать через создание временного файла в /tmp/ и fs.lastModified(), хотя тут будет вполне достаточно computer.uptime или os.clock

@rootmaster, столкнулся с TLWY, когда требовалось конвертировать жирные 5-мегабайтные картинки из PNG в свой формат. Проблему решил через вызов pullSignal раз в несколько итераций обработки пикселей и несколько секунд работы компьютера. Эти числа подбираются эмпирическим путём, т.к. все зависит от тяжести алгоритма и TPS сервера, хотя, думаю, более умные люди смогут вычислить идеальные значения. Но сам концепт прост как три копейки и работает безотказно:

-- Снимаем нагрузку на индексацию таблиц в основном цикле
local computerUptime, computerPullSignal = computer.uptime, computer.pullSignal

local
    timeLimit,
    iterationsLimit,
    iteration,
    uptime = 2, 200, 0, computerUptime()

local deadline = uptime + timeLimit

while true do
    -- Деляем грязные делишки
  
    iteration = iteration + 1
    
    -- Чекаем, нужно ли вообще что-то предпринимать для текущей итерации
    if iteration > iterationsLimit then
      iteration, newUptime = 0, computer.uptime()
      
      -- Чекаем, нужно ли yieldиться с учётом затраченного времени
      uptime = computerUptime()
      
      if uptime > deadline then
          computerPullSignal(0)
          deadline = uptime + timeLimit
      end
    end
end

Ну дк

local unicode = require("unicode")

local a = "World"
local t = {}

for i = 1, unicode.len(a) do
  t[i] = '"' .. unicode.sub(a, i, i) .. '"'
end

Посимвольно, любой язык:

local unicode = require("unicode")

local a = "World"
local t = {}

for i = 1, unicode.len(a) do
  t[i] = unicode.sub(a, i, i)
end

Побайтово, english-only

local a = "World"
local t = {}

for i = 1, #a do
  t[i] = a:sub(i, i)
end

 Через разложение на таблицу байтов, english-only

local a = "World"
local t = {string.byte(a, 1, #a)}

for i = 1, #t do
  t[i] = string.char(t[i])
end

По регулярке, english-only

local a = "World"
local t = {}

local index = 1
for char in a:gmatch(".") do
  t[index] = char
  index = index + 1
end

По регулярке иным путём, english-only

local a = "World"
local t = {}

local index = 1
a:gsub(".", function(char)
  t[index] = char
  index = index + 1
end)

12 минуты назад, Darkar25 сказал:

Сам список компонентов синхронный потому, что он запрашивается всего один раз при обращении к свойству списка компонентов и его не нужно постоянно по новой запрашивать с машины

Выглядит удобно. А список запрашивается часом не синхронно? Что произойдёт, если, к примеру, я в мгновение обращусь к свойству machine.Components у 50 подключённых машин? Заблокируется ли серверный поток вплоть до получения всех списков? Если да, то было бы неплохо получать компоненты через await machine.GetComponents() без фризов

15 минут назад, Darkar25 сказал:

но учитывая что почти все методы в компонентах асинхронные то можно привыкнуть и Async на концах методов будет только лишним удлиннением имени...да и визуал студия лепит варнинг если асинхронный метод используется без await так что случайно неправильно заюзать асинхронный метод будет довольно трудно

Вообще согласен, особенно если сервер не имеет синхронных методов - в этом случае суффиксы Async бессмысленны. Но тут он имеет!11

@num_pi, ты прав, но прости, брат, не удержался!

Затестил, очень интересная и довольно удобная реализация, особенно понравилась подписка на ивенты компонентов. Хотя есть вопрос, не дающий покоя: почему некоторые методы машины синхронны (components.TryGet), а другие асинхронны (gpu.Bind), если и тот, и другой выполняются на одной синхронной машине? В случае с Bind я асинхронно ожидаю результат привязки, это логично. А почему тогда список компонентов возвращается синхронно? А в целом было бы очень клёво иметь нейминг по конвенциям майков или как минимум текстовые summary с пояснением, что вот этот метод асинхронен, а этот нет:

screen.setPrecise(true), по дефолту false

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

Ой, неправда-неправда...

Упс хд

Ну ничо, wlen решит вопрос

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

Ну а скролл по горизонтали... и как же это его реализовать то можно?

Жиза, текстовые вьюверы - это бич любой юишки, что пишется с нуля. По-хорошему после каждого расчёта координатной сетки нужно выполнять авто-перенос оригинального текста с лимитом по ширине, чтобы не напрягать юзера скроллингом. Кстати, в опенкомпах это относительно просто провернуть, т.к. 1 символ занимает ровно 1 пиксель, чего нельзя сказать о десктопных юишках с их measureString(), учётом междустрочных интервалов и прочего шлака

А для простого скроллинга достаточно вычислить размер самой длинной строки в исходном тексте и выставить его в качестве лимита прокрутки скроллбара

4 минуты назад, alice_fdream сказал:

внешний редактор тем для Windows, macOS

А какой уровень кастомизации системы планируется в теории, где будет проходить верхняя граница? На оттенках дефолтных стилей кнопок или даже на их расположении в окнах?

Годнотища! Визуально напоминает убунту, даже баклажановый фон в наличии, хех. А какие планы на дальнейшую разработку? Какой прикладной софт поставлен в приоритет на реализацию? Будет ли это исключительно десктопная ОС или же намечена поддержка лоу-тир планшетов?

Бтв это хороший пример, когда истинные гигачады молча созидают шедевры, а мелочные нормисы лишь грязнут в полемике на тему "правильности" методов разработки

33 минуты назад, ProgramCrafter сказал:

А разве doubleBuffering не предназначен для минимизации закрашиваний? Можно же пропатчить component.invoke для видеокарты так, чтобы она добавляла запрос в буфер

Предназначен, я как раз это и предложил в последнем абзаце. Хотя разумнее будет пропатчить экранную либу и метод update, чтобы не добавлять оверхед на сверку таймингов при каждом invoke, т.к. фактических вызовов invoke довольно много на каждый update. Ещё было бы неплохо реализовать форсированную отсылку содержимого буфера раз в N сек, чтобы в случае потери пакетов (при выходе за радиус связи, например) синхронизировать изображение - по аналогии с ключевыми кадрами в видео-потоках

35 минут назад, ProgramCrafter сказал:

+ не 3 ведь байта на цвет, у OC палитра маленькая, 256 цветов максимум.

Угу, тоже думал об этом, хотя тут остро встает вопрос о кол-ве используемых оттенков на экране. Аппроксимация цвета по индексированной палитре - тяжелая операция, и если 5-10 оттенков color.to8bit() проглотит без проблем, то полные 256 цветов нехило так нагрузят стриминговый хост перед каждой отправкой пакетов. Впрочем, тут надо смотреть на практике: вдруг профит от уменьшения размера пакетов будет ощутимее, нежели отсутствие компрессионных задержек... кодить надо. Кодить сложна!

7 минут назад, Joxer сказал:

То есть управление либо с планшета или монитора? Комфортное

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

(3 байта на цвет * 2 цвета (фон и текст) + минимум 1 байт на символ в UTF-8) * 80 пикселей по ширине * 25 пикселей по высоте ~= 13.6 кбайт на планшетный экран

Можно было бы совсем запариться и передавать лишь изменившиеся пиксели (а не весь экран целиком), но для этого придется модифицировать библиотеку по работе с экранным буфером. Смотри сам, крч, стоит ли оно того

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

Всем привет, такой вопрос, есть ли возможность сделать управление одновременно и с планшета, и с монитора?

Речь идет о трансляции картинки на планшет в реальном времени, об аналоге удаленного рабочего стола? Если да, то возможность есть - достаточно переслать по модему содержимое экранного буфера, полученного через screen.getNewFrameTables(). Правда, производительность будет за гранью комфорта, т.к. опенкомповские модемы похожи на *пикча*

1) В 85 строке ты заюзал конструкцию discard variable, однако в луа _ является валидным именем для переменных. Следовательно, в каждой итерации цикла в _ записывается ссылка на таблицу дочернего элемента из layout1:

2) Однако в 90 строке ты прокидываешь якобы "пустую" переменную в метод transferItem, которая на самом деле не пуста: 

3) Все это выливается в ошибку транспозера, ожидающего число 3 аргументом, а получающего таблицу виджета гуйки:

Вообще я не особо вкурил, зачем нужно скармливать transferItem "никакую" переменную, но чо имею - то имею, судить не могу. А для итерации по дочерним элементам можно заюзать следующее:

for index, child in pairs(layout.children) do
  child.onTouch = function()
    ...
  end
end

for i = 1, #layout.children do
  layout.children[i].onTouch = function()
    ...
  end
end