RccHD

Да черт с ним с названием. У меня сейчас другие проблемы: лень и недостаток идей Если не удастся придумать годное название, назову операционку вот так: '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 Чтобы называть систему операционкой отличной от опенос, эта система должна предоставлять какие-то особые способы взаимодействия с компонентами компа. Пока что есть особые способы взаимодействия только с одной компонентой -- gpu Поэтому мне больше хочется называть твое творение 'графическая оболочка OpenOS'

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

Зачем так отстаивать право называть крутую графическую оболочку операционной системой. Если по факту -- это OpenOS? Ведь любую OpenOS программу можно запустить используя твою графическую оболочку, можно использовать всё те же библиотеки, что и раньше. В систему ты почти не добавил библиотек, не работающих с графикой, и при этом затрагивающих важные компоненты компа. Если бы ты добавил очень много сетевых библиотек, упрощающих работу с сетью, эта система была бы сетевой оболочкой, например. А конкретно в данной ситуации -- это графическая оболочка, в чистом виде. Работа самой операционки практически не изменилась, разве что при запуске открывается не стд. терминал, а твой(графический) терминал. Вот и получается, что включая игровой комп, игрок запускает не 'операционную систему авторства ECS', а 'графонистую оболочку над OpenOS авторства ECS' Если нечто выглядит как OpenOS, плавает как OpenOS и крякает как OpenOS, то это ,вероятно, и есть OpenOS. https://ru.m.wikipedia.org/wiki/Утиный_тест Сколько бы графики и GUI не добавилось, это все равно будет OpenOS ------------ И вообще. Разве 'графическая оболочка OpenOS с кучей GUI и двойной буферизацией' звучит не достаточно круто? Все ведь только и мечтают об этих GUI

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

Если что-то перестанет работать, изменю в коде либы число '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 Абзац с неинтересным описанием некоторых интересных моментов: При создании массива данных в кодировке 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 Запускал на тех же тестах, что и в прошлый раз. Результат теста: Плюсы библиотеки: описаны выше( потребление оперативки сокращается в 20, мать его, раз! ) Минусы: библиотека пока еще очень сырая, но это поправимо. Я ее еще успею отполировать

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

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

Я попробую использовать bytearray вместо table в моей библиотеке двойной буфферизации и посмотрю, что получится. Думаю, такие массивы байт могут быть незаменимы при умелом использовании

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