RccHD

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

В таком случае, нужно записывать данные в bytearray порциями

Нужно сначала накопить порцию данных, а потом все разом записать

Пример:

 

local a = bytearray(100000)


local data = {} -- буфер
for i = 1, 1000 do
    os.sleep(1/1000)
    data[i] = getSomeDataFromGeoscan() -- скапливаем данные в буфере
end
a.write(2222, data) -- записываем данные в bytearray
data = nil -- очищаем буфер

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

Может как-нибудь доработаю эту библиотеку

Строки иммутабельны в луа

Вот как раз поэтому они и занимают так мало оперативки

 

Пиковое потребление памяти при использовании строк было в несколько раз больше, чем при использовании массива.

Да, если записывать значения в bytearray по 100 раз в секунду, то сборщик мусора может и не справиться

 

Но если правильно использовать bytearray.write записывая сразу несколько байт, а не по одному, то можно сэкономить очень много оперативки

 

И да, я не позиционирую bytearray как замену table, так как они разные и нужны в разных ситуациях

Если нужно хранить МНОГО данных и не очень часто их обновлять, то однозначно нужно использовать bytearray

Хотите ужаснуться!?

Я протестил и сравнил, сколько на самом деле оперативной памяти можно сэкономить, используя эту библиотеку.

Вот, пожалуйста:

 

local bytearray = require("bytearray")
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 (bytearray)
local mem1 = freeMem()
local array = bytearray(100000) -- массив 100000 байт
array.write(3, {1, 2, 3, 4, 5, 6, 7, 8, 9})
local mem2 = freeMem()
print("Потрачено оперативки массивом байт(bytearray): "..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))

И вот результат:

Эта библиотека может пригодиться вам, если вы работаете с массивом байт, и при этом вам необходимо экономить оперативную память. В OpenComputers оперативной памяти иногда катастрофически не хватает, так как установлен лимит на 2МБ у компов и 4МБ у серверов
Примечание: эта библиотека использует библиотеку для создания классов. Скачать с pastebin
Эта библиотека очень проста и ОЧЕНЬ полезна, так как с помощью нее можно занимать до 20 раз меньше оперативки (по сравнению с table-массивами).
Массив байт создается таким образом:

local bytearray = require("bytearray")
local a = bytearray(20) -- 20 байт

bytearray легко записать в файл при необходимости:
 

file:write( bytearray.data )

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

clear = function() -- очищает массив байт ( заполняет нулями )

Вот пример работы:


Может быть кому-нибудь кроме меня эта библиотека пригодится : )

Ответ на вопрос "почему просто не создать таблицу с числами?":
таблица с числами занимает больше памяти

Я немного доработал библиотеку class.lua
Ссылка на скачивание не изменилась:
https://pastebin.com/WVxaHb4Y

Система проверяет, когда программа последний раз вызывала computer.pullSignal
Если более, чем 5 секунд назад, значит программу нужно закрыть с ошибкой "too long without yielding"

Хотя это, на самом деле, работает через раз

если это сделать в мультимониторном - было бы ооочень прикольно)

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

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

 

Все остальные программы продолжат работать как ни в чем не бывало

Гениально!

 

Осталось только добавить возможность ответить роботу через телеграм-бота.

 

Чтобы бот каждую секунду проверял, не пришло ли сообщение.

 

Было бы круто написать боту 'закопай яму обратно' и робот, получив сообщение, закопал бы яму

Давно не было новостей по поводу разработки этой ОС, так что вот вам СВОДКА:

 

Все готово на 80%

Ждите релиза, выложу бета-версию ОС где-то через неделю-две

 

Список того, что уже сделано:

1) фильтрация событий мыши, клавиатуры и других

2) распределение однотипных компонент компьютера между окнами

3) доработана библиотека буфферизации, добавлена возможность делать скриншоты и сохранять их в бинарный файл(формат raw-image)

4) почти доделан оконный менеджер. Особенности оконного менеджера: поддержка нескольких рабочих столов, возможность запустить несколько окон на одном рабочем столе, возможность параллельно рэндерить разные рабочие столы на разных экранах(труднореализуемо, поэтому пока в планах)

5) добавлены новые методы для gpu, обеспечивающие попиксельную отрисовку графики: gpu.setPixel(x, y, color)

6) реализовано разделение глобальных областей видимости программ(кастомные _G и _ENV для каждой программы)

7) реализованы панельки трэя сверху и/или снизу. В них можно будет отображать любую инфу: время, озу, темрературу реактора и т.д.

 

В будущем хочу взять(и частично переписать под нужды ОС) несколько библиотек от ECS и Krutoy. Например, хочу добавить в систему поддержку БОЛЬШИХ букв а также OCIF-формата, отрисовка будет через новую функцию gpu:

gpu.drawImage(x, y, OCIF[6], 'img.pic')

Потому что код UTF-8 преобразуется в код, собственно, символа иным путём.

Мда, зря я все еще на Lua 5.2 сижу

Тут нет встроенной либы uf8

Почему не выводится символ?

x = "▀"
print(x) -- печатает "▀"


-- получаем 3 байта символа "▀"
b1, b2, b3 = x:byte(1, -1)

-- получаем позицию символа по трем байтам
num = b1 * 0x10000 + b2 * 0x100 + b3

print(unicode.char(num)) -- печатает "?", а должно "▀"
-- для большинства других символов все работает правильно

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

 

 

А вот априорно сказать, что кто-то будет намеренно искать баги, невозможно. Так как у всех тут есть учёба, работа или ещё какие-либо дела.
Вроде как написал Объективное мнение.

Я предлагаю так: после 'релиза' все скачают мою ОС и потыкаются в ней. Если будут баги, обязательно нужно кинуть багрепорт сюда или в спец. тему
Никого фулл-тайм не нужно. Просто зараннее договоримся чтобы пофиксить 5-10 багов


Ссылка на репо закреплена в первой записи темы.
Продублирую тут:
https://github.com/RccHD/WinOS/tree/master/WinOS/dd243563-b2e6-4ba8-8c28-28ca278f0402/home/lib

Вот важное сообщение: http://computercraft.ru/topic/2128-pishu-novuiu-os/?p=32217

Все остальные сообщения в этой теме -- пустой треп про nautilus, IPC, про сокеты и про другие термины.

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

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

http://computercraft.ru/topic/2128-pishu-novuiu-os/?p=32217


 

 

Сейчас понимаю, что написать многопоточность в OpenOS не очень сложно, но есть одна проблема: миллионы возможных багов, связанных с компонентами компа, евентами, экранами, вводом-выводом и т.д.

Я намекаю на то, что одному человеку(мне) найти и пофиксить все баги будет физически очень сложно. Все потому что под моей операционкой можно будет запустить почти любую OpenOS-программу

 

Я пытаюсь свести тему к тому, чтобы я выложил 30 сентября то, что успел сделать, а остальные доработали бы, отпалировали, баги пофиксили.

 

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

 

У меня просто сейчас учеба, 11класс. Мне вообще не простительно уделять много времени околоигровым вещам. Могу тратить на фикс багов где-то час-полтора и то не каждый день

 

 

P.S. надеюсь на какую-то адекватность и конструктив, я же для вас эту ОС пишу

На написание ОС я потратил не больше двух часов за последние 3 дня, т.к лень

 

Трудно решить вопрос с io, tty и особенно term. Они реализованы так, что нигде кроме как в самой OpenOS они не будут идеально работать

 

Уже думаю просто написать свою упрощенную версию tty (не больше 10% от кода, написанного автором мода)

@@RccHD, делай полноценную многозадачность с деревом процессов и сигналами.

Уже готово. Дерево процессов встроено в OpenOS(неожиданно)

 

 

Многопоточный способ


Используя еще недописанную операционку xD

Код программы(запущены 10 копий):
 

local c = "Hello world!"
local gpu = require("component").gpu
for i = 1, #c do
    gpu.set(i, 1, c:sub(i, i))
    os.sleep(0.125)
end

Когда будет готов оконный менеджер(в конце недели, я занят :/ ), объявлю начало разработки конфигов к нему

Учасники форума смогут оформить конфиг(API я выложу) и прислать его. Им будет предоставлен ранний доступ к ОС.
Пример рабочего конфига я выложу(с мегатоннами комментов и пояснений). Чтобы было с чего "срисовывать"

Хорошие конфиги я добавлю в систему как дефолтные, один из них можно будет выбрать зайдя в настройки

Что думаете? Будет ли кто-то пилить конфиг оконного менеджера или мне сделать все самому?

P.S. Вы сможете сделать "как в андроиде",  "не как в андроиде", да вообще как захотите

Сейчас я боюсь над тем, чтобы разделять порты ввода-вывода программ(term, tty, sh, io, buffer)

Сейчас есть желание забить на это все и сделать так

io = {
    write = nil
   ,read = nil
}

Графическая составляющая(оконный менеджер, буфферизация, виртуальная gpu) -- ничтожно простая часть ОС, которую я реализовал в первый же день

 

Сейчас я бьюсь над тем, чтобы разделять порты ввода-вывода программ(term, tty, sh, io, buffer)

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

Но, это лишь мое скромное мнение.

Дам тебе(и другим кодерам) возможность реализовать такой оконный менеджер. Будет удобное API для описания того, как распределять пространство на экране. Все можно будет поменять через конфиг

Я имел в виду, что у вас сейчас на разделение тратится 2 пикселя. А можно тратить 1, если сделать рамку общей для соседних окон

Однопиксельные рамки сделать не получится, потому что символ имеет высоту 2 "пикселя" (▀)