RccHD

Есть у твоей системы какое-то официальное название?

А то работа идёт бурными темпами, а тема всё ещё называется "пишу новую OS". =)

Да черт с ним с названием. У меня сейчас другие проблемы: лень и недостаток идей

Если не удастся придумать годное название, назову операционку вот так:

'Gw suka. Manis didepan dibelakang busuk. '

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

Когда приложение находится на другом рабочем столе, все операции с gpu просто ничего не делают. Все остальное работает нормально(например OpenNet-сервер не зависнет будучи на другом рабочем столе)

Однако из-за этого бывают графические артефакты

Если у кого-то есть идея другого концепта для работы окон в разных рабочих столах, то предлагайте. Учитывайте, что ОЗУ очень ограничена

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

Так реализован стандартный терминал openos.

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

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

Код выглядит примерно так: 

while true do
    -- ...
    --
    e = event.pull()
    if e then blinkCursor() end
end

Попробую сделать так, чтобы терминал мигал курсором только будучи в фокусе ( с красной рамкой )

Переключение рабочих столов теперь работает!

Делается это командой workspace
Переключение занимает определенное время(0.5 сек), потому что в этот момент происходит считывание файла-скриншота с диска и восстановление той картинки, которая была отображена на рабочем столе


 

@@ECS Как ты сделал смену иконки курсора при ресайзе?

Стоит ли вводить ограничение на 10 окон на одном рабочем столе?

Можете представить ситуацию, когда станут использовать 11 окон? (хотя не факт, что еще и оперативки хватит )

Ну это же настоящая IDE собранная из подручных средств(lua-shell, терминал, стандартный редактор edit)!

Если еще подсветку кода прикрутить, вообще топово будет

Теперь дебажить программы намного удобнее:

Можно в цикле пройти по всем шести сторонам  и проверить наличие сундука на каждой стороне.
 

Сейчас допиливаю оконный менеджер.
Добавил возможность делить окно на 2 части командой split

 

Уууу, скоро дэдлайн, а я уже 4 дня ничего не кодил

Немного перемудрил с переменными, смотрите как сразу перекосило ее   

Все пофиксил и потестил. Работает стабильно ( вроде бы )

Для привлечения внимания и новых юзеров конечно лучше употреблять словосочетание 'моя операционная система', тут я спорить не стану

На факт остается фактом, это можно назвать ОС с оочень большой натяжкой

Затем, что я очень люблю заниматься казуистикой, а также затем, что от дефолтной OpenOS тут осталось крайне мало - большинство библиотек переписаны с нуля и "отдеговнокожены" с целью повышения производительности. Аналогичность названий методов библиотек OpenOS и MineOS вовсе не означает тождественность их выполнения, это абсолютно разные скрипты с различной механикой, я реализовал схожие названия всего лишь для обеспечения обратной совместимости. Из стандартных остались нетронутыми лишь io/fs/term/package/process/buffer и аналогичные, ибо написаны они вполне неплохо. Я могу также без проблем переписать под свои нужды и их, сделав MineOS независимой от OpenOS, отвоевав тем самым фиктивное право называть ее самостоятельно ОСью. Но это звучит уж слишком наивно, не находишь?

Ну можно сказать, что ты написал графическую среду + доработал библиотеки OpenOS

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

Поэтому мне больше хочется называть твое творение 'графическая оболочка OpenOS'

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

Пока не спешите использовать эту либу в каком-то серьезном проекте. Эта либа будет считаться 'проверенной' после того, как часть операционки я напишу на UniDataArray. Пока что нестабильно работает

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

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

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

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

Вот и получается, что включая игровой комп, игрок запускает не 'операционную систему авторства ECS', а 'графонистую оболочку над OpenOS авторства ECS'

Если нечто выглядит как

OpenOS, плавает как OpenOS и крякает как OpenOS, то это ,вероятно, и есть OpenOS.

https://ru.m.wikipedia.org/wiki/Утиный_тест

Сколько бы графики и GUI не добавилось, это все равно будет OpenOS

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

И вообще.

Разве 'графическая оболочка OpenOS с кучей GUI и двойной буферизацией' звучит не достаточно круто?

Все ведь только и мечтают об этих GUI

Ключевые особенности:

• Многозадачность

Многозадачность не совсем "полноценная" и распространяется в основном только на программы, которые работают под управлением системы

Интересно, работает ли либа на Lua 5.2? Возможный диапазон целых чисел на прошлой версии отличается от 5.3:

 

 

Если что-то перестанет работать, изменю в коде либы число '64' на '32' или добавлю проверку на версию Lua

Я писал эту чертову программу весь день, но зато узнал много нового

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

Никто ведь не будет отказываться от 20-кратного уменьшения потребления оперативной памяти игрушечного компа

Совсем недавно я выложил свою библиотеку, которая позволяет экономить оперативную память при хранении бинарных данных.
Из фатальных недостатков той старой библиотеки можно выделить:
1) Колоссальная нагрузка на CPU и сборщик мусора
2) Работа со иммутабельными строками

Получив порцию критики, я переписал библиотеку и добился офигенных результатов.
Новая библиотека экономит ровно столько же оперативки ( экономия до 80-90% ) и при этом не имеет перечисленных недостатков старой.

 

UniDataArray.lua

Примечание: для работы с этой библиотекой необходимо наличие следующий библиотек:
1) num_transform.lua
2) class.lua (доработанная версия)

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

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

Работа библиотеки основана как раз на этой возможности умещать данные в больших числах.

Вот пример использования библиотеки UniDataArray.lua

-- ФУНКЦИЯ КРАСИВОЙ ОТРИСОВКИ
-- К библиотеке отношения не имеет
local pprint = function(v, t)
    print("\27[32m"..tostring(v or "").."\27[37m")
    io.write("-> ")
    if type(t) == "table"
    then for k, v in pairs(t) do io.write(tostring(v).." ") end
    else io.write(tostring(t)) end
    print("\n------------------------------------")
end
local UniDataArray = require("UniDataArray")
-- создание массива размером 20 с разрядностью = 256. (массив байт)
-- т.е. 20 байтlocal
array = UniDataArray(20, 256)
-- числа...
local numbers = {1,0,234,22,12,99,44,3,121,200}
-- позиция курсора
local position = 0
-- запись чисел numbers в массив array начиная с позиции position
position = array.write(position, numbers)
--- ВЫВОД ИНФОРМАЦИИ НА ЭКРАН :
-----------------------------------------
print("\n\n")----------------------------
-----------------------------------------
pprint("Кусок из 5 байт (с 2 по 6)"
	   ,array.read(1, 5)			          )
pprint("Исходные данные (каждое число -- это отдельный блок) "
	   ,array.data					  )
pprint("Количество блоков"
	   ,array.length				  )
pprint("Размер блока "
	   ,array.block_len				  )
pprint("Общее кол-во отдельных элементов"
	   ,array.block_len * array.length                )
pprint("Позиция курсора"
	   ,position					  )
pprint("Первый блок "	   ,array.internal.getBlock(1)	  )
pprint("Второй блок "	   ,array.internal.getBlock(2)	  )
-----------------------------------------
print("\n\n")----------------------------
-----------------------------------------

Абзац с неинтересным описанием некоторых интересных моментов:
При создании массива данных в кодировке base размера N программа создаст ровно столько блоков, сколько необходимо для хранения N чисел.
Чем больше значение кодировки, тем меньше чисел этой кодировки может поместиться в блок.
При создании массива байт каждый блок будет вмещать 6-7 ячеек.

local arr = UniDataArray(100000, 256) -- кодировка 256, значит это байты
print(arr.block_len) -- длина блока = 6 ячеек
print(arr.length) -- всего создано 16667 блоков

Но вот при создании массива бит, каждый блок будет иметь аж 62 ячейки:

local arr = UniDataArray(100000, 2) -- кодировка 2, значит это биты
print(arr.block_len) -- длина блока равна 62 ячейкам
print(arr.length) -- всего создано 1613 блоков

Также есть возможность создания массивов в кодировках 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, но кому оно надо, я не знаю
Реализовал "чтобы было". Лично я пользуюсь только кодировками 2 и 256.

Каждый блок занимает примерно 64 бита вне зависимости от количества ячеек в нем

Краткая документация библиотеки

Чтобы создать UniData-массив нужно вызвать функцию-конструктор передав в нее два аргумента:
1) необходимое количество ячеек
и
2)допустимую кодировку этих ячеек. Пример:

local UniDataArray = require("UniDataArray")
local array = UniDataArray(100000, 4) -- создание массива из 100000 'четырехразрядных' чисел

У класса UniDataArray есть следующие методы:
write = function(pos, bytes) -- записывает числа bytes(table) начиная с позиции pos(number). Возвращает позицию последней записанной ячейки
read = function(pos, count) -- считывает count(number) чисел начиная с позиции pos(number). Возвращает позицию последней прочитанной ячейки
fill = function(elem) -- устанавливает значение elem(number) всем ячейкам в массиве

Пример использования UniDataArray как массива битов

Ну, в этом нет ничего сложного:

local UniDataArray = require("UniDataArray")
local array = UniDataArray(20, 2) -- массив из 20 битов
array.write(0, {0, 1, 0, 1, 1, 1, 0}) -- записать биты 0101110 в ячейки после нулевой. 0
array.write(5, {1, 1, 1, 1, 0, 1, 1}) -- записать биты 1111011 в ячейки после пятой.  5
local someData = array.read(2, 5) -- прочитать 5 битов начиная с позиции 2
print(table.unpack( someData )) -- выведет на экран 01111

Ну и на сладкое у нас тест производительности!
Table VS UniDataArray

Запускал на тех же тестах, что и в прошлый раз.

local bytearray = require("UniDataArray")
local computer = require("computer")
local freeMem = function() -- возвращает усредненное значение computer.freeMemory()
    local m = 0
    for i = 1, 20 do m = m + computer.freeMemory() os.sleep(0.2) end
    return m / 20
end
-- ТЕСТ 1 (UniDataArray)
local mem1 = freeMem()
local array = UniDataArray(100000, 256) -- массив 100000 байт
array.write(3, {1, 2, 3, 4, 5, 6, 7, 8, 9})
local mem2 = freeMem()
print("Потрачено оперативки массивом байт(UniDataArray): "..tostring(mem1 - mem2))

print("\n\n\n")

-- ТЕСТ 2 (table)
local mem1 = freeMem()
local array = {}; for i = 1, 100000 do array[i] = 0 end -- массив 100000 байт
for i = 1, 9 do array[i + 3] = i end
local mem2 = freeMem()
print("Потрачено оперативки таблицой(table): "..tostring(mem1 - mem2))

Результат теста:




Плюсы библиотеки: описаны выше( потребление оперативки сокращается в 20, мать его, раз! )
Минусы: библиотека пока еще очень сырая, но это поправимо. Я ее еще успею отполировать

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

Очень хорошая идея, реализую сегодня(и наверное выложу на форум).

 

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

Переписал библиотеку классов на метатаблицы, чтобы претензий не было

сборщик мусора будет орать как лютый негр. Я тестил.

Давно ждал, чтобы кто-то реализовал таблицу символов, так как самому было лень такое писать!
Очень полезная программа