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

ECS

Гуру
 Профиль  Активность

  • Публикации

    533

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

  • Посещение

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

    203

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

  1. Опубликовано:

    Если используется OpenOS. Все четыре варианта более-менее схожи: 

    require("shell").execute("/Test.lua")
    os.execute("/Test.lua")
    dofile("/Test.lua")
    -- Более детальное решение с безопасным запуском файла и отлавливанием всех ошибок с подробной информацией
local result, reason = loadfile("/Test.lua")
if result then
  result, reason = xpcall(result, debug.traceback)
  if result then
    -- Все замищательно
  else
    print("Не удалось выполнить файл: ", reason)
  end
else
  print("Не удалось загрузить файл: ", reason)
end

     

    Если используются "чистые" опенкомпы на микроконтроллере или попросту с EEPROM:

      

    local filesystem = component.proxy(component.list("filesystem")())

-- Читаем файл напрямую с диска
local handle = filesystem.open("/Test.lua", "rb")

local data, chunk = ""
repeat
  chunk = filesystem.read(handle, 4096)
  data = data .. (chunk or "")
until not chunk

filesystem.close(handle)

-- Выполняем прочитанный исходный код
local result, reason = load(data)
if result then
  result, reason = xpcall(result, debug.traceback)
  if result then
    -- Усе в порядке, файл выполнен
  else
    -- Ошибка при выполнении загруженного скрипта
  end
else
  -- Ошибка при загрузке текстовых данных в качестве кода
end

     

    • Нравится 4

  2. Опубликовано:

    @SkinnerDE, пардон, я на ходу писал, myImage можно в расчет не брать. Главное принцип, дыа. MyImage в данном случае - это ссылка на объект изображения,  передаваемая в обработчик событий для удобства, называть переменные можно как угодно. Для ясности код приведу: 

    local function myEventHandler(application, objectPointer, e1, e2, e3, ...)
   -- Ох уж эти события
end

-- Переменная object и objectPointer из обработчика событий - это один тот же объект
object.eventHandler = myEventHandler

     

    Аналогичный функционал, кстати, можно запилить и средствами event.timer, однако так куда проще, да и отменять таймеры впоследствии не придется.

  3. Опубликовано:

    @SkinnerDE, юзай eventHandler для пикчи:

      

    -- Загружаем все пикчи из папки в единую таблицу
local path = "/Pictures/"
local currentPicture = 1

local pictures = {}
for file in filesystem.list(path) do
  table.insert(pictures, image.load(path .. file))
end

-- Добавляем объект изображения в контейнер или куда-то еще
local GUIImage = application:addChild(GUI.image(1, 1, pictures[currentPicture]))

-- Как часто пикча будет меняться
local interval = 5
-- Время, когда условие ниже сработает в следующий раз
local deadline = computer.uptime() + interval

-- Обработчик событий вызывается каждый пуллящийся ивент (даже если его не было при нулевом интервале)
kartinka.eventHandler = function(application, myImage)
  if computer.uptime() > deadline then
    -- Отображаем следующую пикчу
    currentPicture = currentPicture + 1
    if currentPicture > #pictures then
      currentPicture = 1 
    end
    
    GUIImage.image = pictures[currentPicture]
    application:draw()
    
    -- Обновляем время следующего срабатывания условия
    deadline = computer.uptime() + interval
  end
end

-- Обязательно с ноликом, чтоб ивенты пуллились с минимальным интервалом
application:start(0)

     

  4. Опубликовано:

    По этой теме уже существует отлаженный софт, успешно используемый многими игроками. Однако на днях я заметил забавную особенность местных видеокарт, позволяющую выставлять разрешение большее, нежели получаемое через gpu.maxResolution(). К примеру, если maxResolution для видеокарты третьего уровня вернет числа 160 и 50, то никто не мешает установить разрешение, скажем, в 20x158 пикселей. При этом при проверке валидности устанавливаемого разрешения соблюдается два правила:

     

    • Результирующее разрешение по числу пикселей не должно превышать результат умножения чисел, возвращаемых maxResolution. То есть для T3 GPU не более 160 * 50 = 8000.
    • Каждый параметр разрешения, будь то ширина или высота, не должен численно превышать значение возвращаемой ширины. То есть для T3 GPU не более 160.

     

    Не знаю, баг это или фича, однако подобное грех не использовать в своих целях. К примеру, старая версия программы при вертикально-удлиненном расположении мониторов позволяла выставить разрешение лишь в 30х50 (1500 пикселей в итоге), заполняя тем самым "черные полосы". В то же время обновленная софтина, учитывающая описанные выше особенности, выдает 69x114 (7866 пикселей), максимально приближаясь к предельной отметке в 8000:

     

    46Q5jB6.png?1   cIp0CPJ.png?1

     

    Согласитесь, лишние пиксели на дороге не валяются, и, думаю, кому-то будет интересно узнать про реализацию подобного софта.

     

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

     

    WKlKAPf.png?1

     

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

    число_блоков_монитора * 16 - 4

    Следовательно, пропорция монитора будет считается следующим образом: 

    local gpu = component.gpu
local screen = component.proxy(gpu.getScreen())

local blockCountByWidth, blockCountByHeight = component.screen.getAspectRatio()
local proportion = (blockCountByWidth * 16 - 4) / (blockCountByHeight * 16 - 4)

    Также не забываем, что высота каждого псевдографического пикселя при отображении в 2 раза больше его ширины, поэтому формула пропорции слегка меняется. Заодно произведем некоторые сокращения, чтобы избавиться от лишних математических операций. Все три варианта эквивалентны: 

    local proportion = 2 * (blockCountByWidth * 16 - 4) / (blockCountByHeight * 16 - 4)
local proportion = (blockCountByWidth * 16 - 4) / (blockCountByHeight * 8 - 2)
local proportion = (blockCountByWidth * 2 - 0.5) / (blockCountByHeight - 0.25)

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

    local maxWidth, maxHeight = gpu.maxResolution()

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

     

    p2A0tJ2.png

     

    Помним также, что ширину мы вполне можем выразить через высоту и пропорцию монитора: 

    width = proportion * height

    Подставим этот вариант в систему:

     

    T3p1lnT.png

     

    Оставим высоту в левой части неравенств:

     

    45y25kQ.png

     

    Подставляем имеющиеся переменные в каждое неравенство, рисуем числовую прямую и выбираем высоту, удовлетворяющую условиям неравенства для конкретного случая. Разумеется, в программировании никаких числовых прямых нет, зато есть любимые math.min() и math.max(): 

    local height = math.min(
  maxWidth / proportion,
  maxWidth,
  math.sqrt(maxWidth * maxHeight / proportion)
)

-- Выражаем ширину через пропорцию
local width = height * proportion

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

    local component = require("component")

-- Получаем масштаб в качестве первого аргумента скрипта и корректируем его значение
local scale = tonumber(select(1, ...) or 1)
if not scale or scale > 1 then
  scale = 1
elseif scale < 0.1 then
  scale = 0.1
end

local gpu = component.gpu
local blockCountByWidth, blockCountByHeight = component.proxy(gpu.getScreen()).getAspectRatio()
local maxWidth, maxHeight = gpu.maxResolution()
local proportion = (blockCountByWidth * 2 - 0.5) / (blockCountByHeight - 0.25)
 
local height = scale * math.min(
  maxWidth / proportion,
  maxWidth,
  math.sqrt(maxWidth * maxHeight / proportion)
)

-- Выставляем полученное разрешение
gpu.setResolution(math.floor(height * proportion), math.floor(height))

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

    • Нравится 10

  5. Опубликовано:

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

    Ага изучать месяц каждый луа файл. В-время


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

    • Нравится 1

  7. Опубликовано:

    @HeroBrine1st,  /tmp/ - это монтированный путь виртуальной файловой системы tmpfs, жестко ограниченной по размеру в конфиге мода: 

    # The size of the /tmp filesystem that each computer gets for free. If
# set to a non-positive value the tmp file system will not be created.
tmpSize=64

    Записывай напрямую на загрузочный хард - и все будет шоколадно. А еще для предотвращения TLWY проще использовать computer.pullSignal(0), что гарантирует разовое прерывание, т.к. OS.sleep() иногда умудряется вызвать pullSignal дважды. А прога клевая, мяу

  8. Опубликовано:

    Чтобы не изобретать велосипедов, проще всего будет хранить конфиг в виде луа-таблицы:

      

    {
  player = "MisterSosister",
  age = 1488
}

     

    Затем загружай его в проге и используй эти данные как угодно. Вчера же писал тебе в чат аналогичный вариант:

      

    local serialization = require("serialization")
local event = require("event")

local file = io.open("/config.txt", "r")
local config = serialization.unserialize(file:read("*a"))
file:close()

while true do
  local eventData = {event.pull("touch")}
  if eventData[6] == config.name then
    --Ник валиден
  end
end

     

    • Нравится 3

  9. Опубликовано:

    57 минут назад, man_cubus сказал:

    У тебя безусловно абсолютно истинные и объективные критерии оценки собеседников в ВК и всегда корректный стиль общения. Всегда.

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

     

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

  10. Опубликовано:

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

    Ну то есть не получится. Потому что в совокупности эти твои модули - это и есть твоя графическая оболочка. А вкупе с прикладным софтом и есть МайнОС. И если, предположим, меня не устраивает предпосылка о необходимости в богатой графике и её следствие - требовательность к ресурсам, то объектный интерфейс отдельно, без графики, мне не получить.

     

    То есть получится. Модулей, отвечающих за графику, всего три из нескольких десятков, при этом каждый модуль самостоятелен и не зависит от системы. За графическую оболочку оси отвечает главный исполняемый файл оси, но никак не модули, ее реализующие. Кто мешает тебе загрузить мою событийную библиотеку? Или, скажем, переписанный файлосистемный враппер? Бери и подключай, хватит придираться к словам.

     

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

     

    1 час назад, man_cubus сказал:
    Цитата

    О чем спор-то вообще?

    О том называть ли технически не-ось осью, разве нет?

     

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

     

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

    Предпосылка тем и отличается от прямого утверждения что она явно не выказывается, но предполагается. Как предполагается графический десктоп с тремя риложениями и нужность именно такого варианта.

     

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

     

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

    Да, но тут не атмега. Тут одна и та же аппаратная часть. И есть случаи когда для одной и той же ситуации невозможно применить именно твоё решение. Для таких ситуаций оно непригодно. И не потому что оно имеет особые требования а потому что оно не настолько универсально. Нет чего-то вроде minimal setup

     

    Нужно быть величайшим гением, чтобы придраться к этой аналогии. Впрочем, не удивительно: когда угасает аргументация, форумчане всегда цепляются к каждому второму слову, чтобы не упасть в грязь лицом. О чем ты споришь? Ты не согласен, что опенкомповский робот банально не обладает достаточным количеством памяти? Если согласен, то почему ты тратишь мое время на разбор подобной ерунды?

     

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

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

     

    А что мне мешает их сравнивать? Существуют какие-то нормативы, кроме придуманных тобой, препятствующие данному сравнению? Почему я не могу этого делать? За время переписки с тобой я не узрел фактических причин. Функционал один, концепция одна, результат работы один. Беру и сравниваю, в чем проблема-то?


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

     

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

    Для того чтобы даже по такому переоцененному (но всё ещё валидному) критерию иметь полноценную ОС

     

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

     

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

    Если использование объектного UI предполагает еще и графические либы и вот такие требования к памяти то не всегда это дело субъективное.

     

    Любое дело, связанное с личным выбором, всегда субъективное. Я бы поспорил на тему невозможности существования объективной действительности, но, боюсь, сам перестану соответствовать своим же требованиям к ведению диалога.

     

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

    Я сказал "почти стандартная". Не уловил, да?

     

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

     

     

     

     

  11. Опубликовано:

    14 минут назад, man_cubus сказал:

    Технически правильно всё же не не называть MineOS полноценной ОС

     

    Технически правильно обосновывать свою точку зрения, какой бы она ни была. Я свою обосновал, приведя в доказательство полностью самостоятельный проект, отвязанный от опеноси. Аргументации с твоей стороны, кроме как "ну я так считаю", я не увидел.

     

    14 минут назад, man_cubus сказал:

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

     

    Подобные фразы представляют собой банальный речевой оборот по аналогии с "все нервы вымотал" или "в печенках сидит".  Разумеется, никто не объявлял ничьи нервы предметом воздыхания, и если воспринимать эти фразы буквально, то и получится, что ты занят казуизмом (кхм).

     

    14 минут назад, man_cubus сказал:

    И мои фразы тоже примерно такие же. Где например прямой переход на личности у меня? Вряд ли ты его найдёшь. Но я веду себя недружелюбно - факт.

     

    В таком случае я вообще не понимаю, что тебя удивило в нашем общении ВК. Каков собеседник - таков и диалог. 

  12. Опубликовано:

     

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

    Тем не менее твоя ОС с её более лучшими модулями на минимальной конфе не запустится. Потому и сравниваю. Я ведь не смогу запустить более лучшие модули отдельно, правда?

     

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

     

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

    [сравнивать] точно нельзя. Потому что они ориентируются на разные вещи и исповедуют разные подходы

     

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

     

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

     

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

    Ну ты же откуда-то взял что ОС - это непременно богатая графика, верно?

     

    Не припомню, чтобы я утверждал нечто подобное. Сочту за слабый троллинг.

     

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

    Удобную для кого? Я ж не исхожу из предпосылки, что могучая графика непременно нужна в однопоточной ОС.

     

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

     

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

    Но тогда как же ты тогда сам сравниваешь готовый продукт под названием OpenOS и твой законсервированный до лучших дней набросок, говоря, что на этот набросок тебе понадобилось намного меньше времени? Ты не видишь тут небольшое противоречие?

     

    Цитата

    Да, потому что если ты его не публикуешь и не афишируешь, то при сравнении с чем-то готовым получишь ожидаемую реакцию в этом вот ключе. Потому что а давай пофантазируем чего бы достигла, скажем, BeOS, если бы... да что угодно. Ведь её сравнивать с тогдашней виндой и линуксом вполне можно как готовые продукты. В отличии от MineOS standalone, которая даже готовой не является, давай? Ощущаешь где именно всё идёт не по плану?

     

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

     

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

    Как я сделаю копипаст внутри своего приложения? Кусок кода для консольного исполнения я для OpenOS привёл. Может приведешь как то же самое делается через особенный, более совершенный механизм в MineOS standalone? Так же? Или как в каком-нибудь win32 API с обязательным указанием хендла на окно приложения?

     

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

      

    filesystem.copy(fromPath: string, toPath: string): boolean or nil, string

     

    К слову, твой пример не универсален и работает медленнее, т.к. незачем затрагивать шелловские парсеры и тратить ресурсы на поиск скрипта.

     

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

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

     

    Вкусовщина. Использовать объектное UI или консоль - дело субъективное. И о каком сокрытом от человечества наброске речь? Майнось уже несколько лет как на рынке, а стенделон версия ничем от нее не отличается. Вы здоровы, батенька?

     

    Цитата

    Не совсем. Я могу и практически стандартную io задействовать. Но зачем?


    Не можешь. Стандартная Lua io вынесена за пределы в опенкомповской песочнице в файле Machine.lua, а лишь затем заоверрайжена опеносовской версией.

     

     

  13. Опубликовано:

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

    Тем не менее, модули из опенос работают на компе первого тира с единственной минимальной планкой памяти и графической карточкой первого тира. Можно ли это сказать о майноси? Очень сомневаюсь.

     

    Тем не менее, ты почему-то сравниваешь модули для оси с осью целиком. Модули, написанные мной, более легковесны, просты и лишены идиотического кода с генерацией тонны таблиц, так что да, они с куда большей охотой будут работать "на компе первого тира с минимальной планкой памяти".

     

    Если же говорить о самих осях, то я напомню, что опенось, имеющая элементарный интерфейс, в принципе не может иметь высоких требований. Откуда им взяться-то? Экранного буфера нет, вся отрисовка идет на прямых обращениях к GPU, объектно-ориентированного интерфейса нет, I/O-буфер жестко ограничен 512 байтами. Я бы удивился, если бы она не запускалась на первой плашке.

     

    Однако подобная простота критически уступает в производительности: при попытке отрисовать десктоп с несколькими приложениями через GPU ты вряд ли получишь больше 1 кадра в 3 секунды. Для серьезных графических систем требуется двойная буферизация графики, и даже при грамотной оптимизации библиотек экранный буфер будет жрать память, словно Скуби-Ду пончики на ярмарке. Сам посуди: экран третьего уровня имеет максимальное разрешение в 8000 псевдографических пикселей. Каждый пиксель - это цвета фона и текста по 3 байта каждый, а также символ в UTF-8, способный жрать вплоть до 4 байт памяти. Даже если взять идеальный случай, когда экран заполнен символами, занимающими в среднем 2 байта, выходит 64000 байт на один фрейм экранного буфера. А у него их два. Вот тебе и плашка памяти первого уровня, заполненная почти целиком. Повторюсь: ты сравниваешь несравнимое.

     

    Цитата

    Ну, тут сложно сказать. Утилита cp - это прикладное ПО? Да. Можно ли без неё и остального элементарного ПО нормально работать с ОпеноОС? Нет.Так что грань несколько размыта


    Я что, утверждал обратное? Наоборот, я поддерживаю ту же точку зрения, контр-аргументируя товарищу нескольким сообщениями выше. 

     

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

    Хотя основной критерий лично для меня вообще примитивен донельзя: насколько легко написать под %ОСнейм% программу для %действиенейм% осложнённую %наборфакторовнейм%? В случае с ОпенОС ответ - "довольно просто". В случае с МайнОС в в non-standalone виде бует "точно сложнее". Просто потому что МайнОС сама съедает немало системных ресурсов и на робота первого уровня её не поставить, к примеру.

     

    Справедливости ради, ты и винду на атмегу не поставишь. Пожалуйста, хватит разводить полемику, сменяя тему на более "удобную". А сложность или простота разработки - понятие крайне относительное: для опеноси и опекомпов имеется OC Wiki, для майноси - документация по GUI. Лично мне не доставляет диких трудов вкратце ознакомиться с обоими источниками, чтобы сделать рабочий софт, ровно как и множеству авторов, выкладывающих свои творения в маркете.

     

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

    Шикарно. И документацию тоже ко всему этому? Потому что вон Фингер тоже свой wonderful написал, а как им пользоваться простому говнокодеру вроде меня
     непонятно. Хотя в отличии от твоего творения у него доки почитать таки завезли.

     

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

     

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

    Опыт личной переписки в вк. Ты действительно хочешь чтобы я принёс это сюда? Или слова "ИМХО" для тебя недостаточно и ты решил что раз ты такой замечательный, то всем без разбора нравишься? У меня для тебя плохие новости в этом плане.

     

    Поверхностно судишь. Напомню о такой штуке, как социальная адаптация: ВК я общаюсь с людьми так, как они того заслуживают, без навязанных сверху ограничений и правил. Если человек адекватен, вежлив, не токсичен, то он получит аналогичную реакцию в ответ. В противном случае от приветов маме никто не застрахован. И если с тобой я вел себя не так, как ты ожидал/рассчитывал/желал - ну что ж. Мяу.

     

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

    Для меня лично заявление о трудозатратах - подтасовка фактов. Потому что помимо реализации низкоуровнего апи для работы с объектами ОС есть еще то самое базовое прикладное ПО, написание документации для всего этого. И этого ты не делал для МайнОС-standalone

     

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

     

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

    И таки базовое ПО по моему мнению является составной частью ОС просто потому что мне куда проще сделать 

    
os.execute(string.format("cp %s %s"), src_file, dst_file)

    чем городить огород с самостоятельным вводом-выводом и буферизацией всей это фигни.

     

    А мне куда проще сделать ПКМ - Копировать, перейти в нужную директорию, ПКМ - Вставить, особенно это актуально для длинных путей, которые вручную вводить вообще не комильфо. Для любителей графического подхода и существует майнось, это уже вкусовщина на самом деле.

     

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

  14. Опубликовано:

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

    Но даже если так, то первый релиз опенкомпов был согласно гитхабу 26-02-2015. И что, вот прям с первого же релиза вы с группой товарищей начали пилить вашу МайнОС?

     

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

     

    ukJwQsj.png

     

    Цитата

    Также сомнительно что можно поставить знак равенства между трудозатратами преобразованиея MineOS в MineOS standalone (с готовыми модулями из опеноси) и написанием OpenOS с нуля.

     

    Во-первых, в MineOS Standalone нет ни одного модуля из OpenOS. Откуда такие сведения вообще? Сомнительно, что можно поставить знак равенства между одинаковыми названиями модулей MineOS и OpenOS и их содержимым - все они были написаны с нуля с учетом собственных нужд.

     

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

     

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

    А с нервами у тебя вообще не всё хорошо. Имхо.

     

    Конкретизируй. Пустословить и оскорблять каждый горазд. 

     

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

    Но не надо передергивать факты

     

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

    Опенось и опенкомпы целиком - сложнее и универсальнее чем майнось

     

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

     

    Тем не менее, продолжая нить беседы о софте для мода, я все равно не соглашусь: опенось крайне проста по концепции, и крайне усложнена в реализации. Система процессов бессмысленна в рамках однопоточной машины и лишь замедляет работу ПО, а для библиотек event/io/shell, не говоря уже о package с ее идеей отложенной подгрузки, идеально подойдет термин "over-engineered". Возможно, авторы слишком много работали с высоконагруженными системами и "взрослыми" языками, перестав видеть простые решения и пытаясь пропихнуть в массы устаревшие концепции из UNIX-систем. А, возможно, им просто по душе челленджи. В любом случае написать консольную операционную систему на чистой GPU и прикладной софт, работающий на крайне удобном API опенкомпов, сумеет каждый, не затратив при этом колоссальных усилий. Это не сложно. Совсем. 

  16. Опубликовано:

    19 минут назад, Fronun сказал:

    как в такое "очко" засунуть layout, а то уже себе окно прорублю себе в мозг.

     

    Ну... наверное, как и в любой другой контейнер?

      

    очко:addChild(GUI.layout(...))

     

    Если требуется своеобразное переключение вкладок, то делай что-то типа этого:

      

    local GUI = require("GUI")
local image = require("image")

--------------------------------------------------------------------------------

local application = GUI.application()
application:addChild(GUI.panel(1, 1, application.width, application.height, 0x0))

-- Окошечко для листа
local window = application:addChild(GUI.filledWindow(40, 12, 80, 25, 0xE1E1E1))

-- Лист, содержащий кнопки-вкладки
local list = window:addChild(GUI.list(1, 4, 22, window.height - 3, 3, 0, 0x2D2D2D, 0x696969, 0x2D2D2D, 0x696969, 0xE1E1E1, 0x2D2D2D))
-- Панель, визуально ограничивающая пространство скроллинга листа
local listCover = window:addChild(GUI.panel(1, 1, list.width, 3, 0x2D2D2D))
-- Лейаут с содержимым вкладок
local layout = window:addChild(GUI.layout(list.width + 1, 1, window.width - list.width, window.height, 1, 1))

-- Кнопки-вкладки
local function addTab(text, doSomething)
  list:addItem(text).onTouch = function()
    layout:removeChildren()
    doSomething()
    application:draw()
  end
end

addTab("Показать пикчу", function()
  layout:addChild(GUI.image(1, 1, image.fromString([[0803D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤185A00⣤185A00⣤185A00⣤185A00⣤185A00⣤185A00⣤185A00⣤185A00⣤]])))
end)

addTab("Показать текст", function()
  layout:addChild(GUI.text(1, 1, 0x696969, "Я есть грут"))
  layout:addChild(GUI.text(1, 1, 0x696969, "И я тоже"))
end)

addTab("Показать кнопку", function()
  layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0x969696, 0xFFFFFF, 0x696969, 0xFFFFFF, "Вдави меня полностью"))
end)

addTab("Ой, все", function()
  -- )))))))000
end)

-- Поддержка скроллинга
list.eventHandler = function(application, list, e1, e2, e3, e4, e5)
  if e1 == "scroll" then
    local horizontalMargin, verticalMargin = list:getMargin()
    list:setMargin(horizontalMargin, math.max(-list.itemSize * (#list.children - 1), math.min(0, verticalMargin + e5)))
    
    application:draw()
  end
end

--------------------------------------------------------------------------------

-- Чтоб кнопочки окна были поверх всех объектов
window.actionButtons:moveToFront()
-- Отображаем сразу первую открытую вкладку
list:getItem(1).onTouch()
-- Запускаем приложуху
application:start()

     

     

  17. Опубликовано:

    51 минуту назад, Fronun сказал:

    Как в ВК клиенте, или в Settings, я так понимаю ты просто добавляешь  GUI.button? Со скроллом?

     

    Почти. Для этого есть заранее заготовленный объект GUI.list, по факту представляющий из себя модифицированный GUI.layout с возможностью добавления кнопок-айтемов. А скролл осуществляется через методы setMargin/getMargin:

      

    local GUI = require("GUI")
local image = require("image")

--------------------------------------------------------------------------------

local application = GUI.application()
application:addChild(GUI.panel(1, 1, application.width, application.height, 0x0))

-- Окошечко для листа
local window = application:addChild(GUI.filledWindow(40, 12, 80, 25, 0xE1E1E1))

-- Лист и крышка, визуально ограничивающая скроллинг
local list = window:addChild(GUI.list(1, 4, 22, window.height - 3, 3, 0, 0x2D2D2D, 0x696969, 0x2D2D2D, 0x696969, 0xE1E1E1, 0x2D2D2D))
local listCover = window:addChild(GUI.panel(1, 1, list.width, 3, 0x2D2D2D))

-- Кнопочки
list:addItem("Я почти кнопка")
list:addItem("И я тоже")
list:addItem("И я того же мнения")

-- Поддержка скроллинга
list.eventHandler = function(application, list, e1, e2, e3, e4, e5)
  if e1 == "scroll" then
    local horizontalMargin, verticalMargin = list:getMargin()
    list:setMargin(horizontalMargin, math.max(-list.itemSize * (#list.children - 1), math.min(0, verticalMargin + e5)))
    
    application:draw()
  end
end

-- Чтоб кнопочки окна были поверх всех объектов
window.actionButtons:moveToFront()

--------------------------------------------------------------------------------

application:draw(true)
application:start()

     

    Результат:

     

    9P4ch3U.png?1

     

    • Нравится 1

  18. Опубликовано:

    @MisterFunny01, мяу, я так и не услышал, какие же фичи "фиг найдешь". Предположу тогда, что все они задокументированы.

     

    14 часов назад, MisterFunny01 сказал:

    А если фон мне делать не надо. И как закрыть "АКОШКО"

     

    Фон - это своеобразная защита от "пустоты", предотвращающая эффект наложения кадров экранного буфера в стиле Windows XP. Если его убрать, то получится следующее:

     

    wEH7e4M.png?1

     

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

     

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

     

    14 часов назад, MisterFunny01 сказал:

    И как закрыть "АКОШКО"

     

    1) Открываем документацию: https://github.com/IgorTimofeev/GUI

    2) Кликаем в содержании на пункт GUI.object

    3) Смотрим, что каждый объект имеет метод :remove()

    4) Profit

     

    Ежели требуется закрывать окно при клике, скажем, на кнопку отмены, то:

      

    layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0xB4B4B4, 0xFFFFFF, 0x969696, 0xB4B4B4, "Отмена")).onTouch = function()
  -- Удаляем объект окна
  window:remove()
  -- Отрисовываем изменения сначала в буфер, а затем уже на экран
  application:draw()
end

     

    • Нравится 1
    • Ха-ха 1

  19. Опубликовано:

    21 час назад, MisterFunny01 сказал:

    Эти фичи фиг найдешь.

     

    Какие именно фичи интересуют? Какие фичи фиг найдешь? Создание окошка с кнопочками - дело пары минут, описанное в деталях в документации:

      

    local GUI = require("GUI")

--------------------------------------------------------------------------------

-- Создаем главный контейнер с черной фоновой палелью
local application = GUI.application()
application:addChild(GUI.panel(1, 1, application.width, application.height, 0x0))

-- Добавляем окошко в главный контейнер
local window = application:addChild(GUI.titledWindow(50, 22, 60, 14, "Акошко", true))

-- Добавляем лейаут размером 1х2 в окошко
local layout = window:addChild(GUI.layout(1, 2, window.width, window.height - 1, 1, 2))

-- Задаем размеры горизонтальных рядов для лейаута
layout:setRowHeight(1, GUI.SIZE_POLICY_RELATIVE, 1)
layout:setRowHeight(2, GUI.SIZE_POLICY_ABSOLUTE, 2)

-- Задаем режим выравнивание объектов для второго ряда по правому нижнему углу
layout:setAlignment(1, 2, GUI.ALIGNMENT_HORIZONTAL_RIGHT, GUI.ALIGNMENT_VERTICAL_BOTTOM)
-- ... направленние
layout:setDirection(1, 2, GUI.DIRECTION_HORIZONTAL)
-- ... расстояние между объектами
layout:setSpacing(1, 2, 3)
-- ... и отступ от правого нижнего угла
layout:setMargin(1, 2, 2, 1)

-- Доавляем текст в первый ряд лейаута
layout:addChild(GUI.text(1, 1, 0x0, "Я оч большой и важный текст"))

-- Меняем дефолтный ряд, в который будут добавляться объекты (можно через layout:setPosition(object), но лень)
layout.defaultRow = 2

-- Добавляем кнопочки
layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0xB4B4B4, 0xFFFFFF, 0x969696, 0xB4B4B4, "Отмена"))
layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0xB4B4B4, 0xFFFFFF, 0x969696, 0xB4B4B4, "Еще тык"))
-- При "тыке" на эту кнопочку комп будет вырубаться
layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0x696969, 0xFFFFFF, 0x969696, 0xB4B4B4, "Тык")).onTouch = function()
  require("computer").shutdown()
end

--------------------------------------------------------------------------------

-- Разово отрисовываем содержимое главного контейнера в принудительном режиме (для полной отрисовки буфера, вдруг опенось чет свое нарисует)
application:draw(true)
-- Начинаем обработку событий
application:start()

     

    Результат:

     

    jaYThVi.png

    • Нравится 1

  20. Опубликовано:

    2 часа назад, Fronun сказал:
    3 часа назад, MisterFunny01 сказал:

     

    во первых, чтобы была конкуретность, а во вторых MineOS это не ось, а граф.оболочка.

     

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

     

    Эксперимента ради я решил отвязать майнось от опеноси, сделав ее полностью независимой. Это заняло несколько часов. Ценой нескольких, мать их, часов, а также нескольких написанных либ суммарным объемом в две сотни строк  майнось стала полностью удовлетворять определению "операционная система", загружаясь с очищенного от скверны жесткого диска и собственного EEPROM. Результат лежит на отдельном репозитории, законсервированный до лучших дней:

     

    https://github.com/IgorTimofeev/MineOSStandalone

     

    А теперь скажи мне, умник, не кажется ли тебе странным, что вся "ось" пишется на коленке за несколько часов, а "граф. оболочка" - пускай и не годами, но в значительно большие сроки? Может быть, термин "ось" переоценен, и основу современной интерфейсной операционной системы составляет все же графическая оболочка c прикладным софтом? Эх, мяу

    • Нравится 4
    • Спасибо 3

  22. Опубликовано: · Изменено пользователем Alex
    Установка спойлера

    @MisterFunny01, меня полностью устраивают текущие иконки, я не собираюсь менять их из-за чьей-либо нетолерантности к мату. Все фиксы грамматических ошибок машинного перевода можно без проблем кинуть пулл реквестом на гит, если есть желание, я только рад буду. Что за установщик? Установщик чего? Установщик модифицированной оси с "православными" иконками без мата что ли? Повторюсь: мне подобные изменения не по нраву, сам кодь что пожелаешь, но меня не впутывай, мяу. Что за расположение ядра? Нет у оськи никакого ядра, либа "MineOSCore" названа так чисто по приколу, для симуляции "научности". Что подразумевается под "непереведенными" штуками? Настройки, да и вообще все локализованные приложения, с самого начала поддерживают все четыре системных языка, в том числе и украинский:

     

    Спойлер

    7bJ0Eft.png?1

     

    Насчет прог для робота/дрона - их нет, я мало с роботами работал. Есть сборная солянка простеньких скриптов, оставшихся после выживания на сервере с поцыками, но никакой работоспособности не гарантируется:

     

    https://github.com/IgorTimofeev/MineOS/tree/master/Applications/Robot

    https://github.com/IgorTimofeev/MineOS/tree/master/Applications/DroneGrief

    https://github.com/IgorTimofeev/MineOS/tree/master/Applications/Drone farmer

  23. Опубликовано:

    Кстати о майноси: тут несколько занятных софтин подъехало. Например, YobaКалькулатрон9000, как его окрестил товарищ-шестиклассник. Умеет почти все: от работы с различными системами счисления и побитового редактирования чисел до базовых бинарно-тригонометрических операций с отображением символа по его коду.

     

    8r3TbEX.png?1

     

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

     

    pqbrwam.png?1

     

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

     

    6b250Lu.png?1

    • Нравится 5

  25. Опубликовано:

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

×
×
  • Создать...