RccHD

я ждал это джва года.

А я взял и сделал за 3 дня :P

Как определить "графическую" ширину пикселя? Например "х" имеет ширину 1, а какой-нибудь иероглиф -- ширину 2

 

Реализовал часть функций оконного менеджера. Реализовал переключение окон

Кто-то ещё помнит про мои змейки

Эти змейки почти идеально подходят для тестирования моего оконного менеджера.

Так как в них использованы самые разные функции (gpu, term, event)

есть программы, которые не выполняют sleep/listen, а длительно работать без TLWY им позволяют обращения к периф

Есть третий принципиально отличающийся вариант: обработка нескольких приложений-окон в общем потоке-контейнере

Вот именно, зачем изобретать новый велосипед, когда можно лучше взять и доработать уже что-то существующее и работоспособное (как в общем в 99% случаев с опенсоур проектами и бывает).

Не нравится стандартная OpenOC, так Plan9 есть. Если хочется графического, то пожалуйста Ось от @ECS. Думаю Игорь не против новых предложений и идей 

 

Вот я как раз этим и занимаюсь. Я для грандиозности утверждаю что 'пишу новую офигенную операционку', на самом деле это называется 'дорабатываю/переписываю OpenOS'

Отсюда и полная совместимость программ на OpenOS с моей операционкой

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

Вот еще интересный, красочный пример. Запустил две змейки на одном компе:



Проблема только в том, что обе змейки реагируют на нажатия клавиш, но эта проблема легко решаемая

P.S. Программу "змейка" я скачал с форума и запустил в своей ОС без каких-либо доработок

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

Приведи пример такой коллизии. Я пока не придумал ни одного

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

Реализована возможность запуска нескольких программ одновременно!!!
В этом примере каждая программа запущена в отдельном окне 10х10 символов.



Это 2 одинаковых программы. Эта программа будучи запущенной в "одиночном" режиме занимает все окно:



Примечание: в скиншоты попал мой терминал(фиолетовая область). Я криворукий и мне лень переделывать

Программы запущены в эмуляторе, так что они работают намного быстрее. Пока еще не тестил в майне

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

Всегда считал, что переменные(они же указатели на объекты) не могут занимать много памяти...

Хотя бы потому что исходники библиотек OpenOS прямо-таки напичканы переменными. Может дело все-таки не в таких мелочных деталях как переменные, а в самой реализации?

function buffer:readLine(chop, timeout)
  self.timeout = timeout or (computer.uptime() + self.readTimeout)
  local start = 1
  while true do
    local buf = self.bufferRead
    local i = buf:find("[\r\n]", start)
    local c = i and buf:sub(i,i)
    local is_cr = c == "\r"
    if i and (not is_cr or i < #buf) then
      local n = buf:sub(i+1,i+1)
      if is_cr and n == "\n" then
        c = c .. n
      end
      local result = buf:sub(1, i - 1) .. (chop and "" or c)
      self.bufferRead = buf:sub(i + #c)
      return result
    else
      start = #self.bufferRead - (is_cr and 1 or 0)
      local result, reason = readChunk(self)
      if not result then
        if reason then
          return nil, reason
        else -- eof
          result = #self.bufferRead > 0 and self.bufferRead or nil
          self.bufferRead = ""
          return result
        end
      end
    end
  end
end

Ну блин, стараешься тут, стараешься, разбивая код на суб-сегменты по классическим идиомам проектирования, минимизируя нагрузку на оперативку и ЦПУ, а потом его "корявым" называют. Обидно 

 

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

По поводу моей субъективной оценки твоего кода:

Я вот такие вещи вообще видеть не могу, это вообще не по-человечески так писать:

changes[buffer.currentFrame[index]] = changes[buffer.currentFrame[index]] or {}
changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] = changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] or {}
				
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], x)
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], y)
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], table.concat(sameCharArray))
				

Когда я вижу подобный код, я начинаю думать:

1) У автора этого кода паническая боязнь переменных(или он проспорил кому-то)

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

3) У автора Крутой Продвинутый Текстовый Редактор ™, который позволяет написать "buffer.currentFrame[index]" сразу в трех местах

Так как я не фанат различных навороченных редакторов текстовых редакторов и не боюсь переменных и знака "=", я бы написал этот код вот так:

local el0 = buffer.currentFrame[index],
      el1 = buffer.currentFrame[indexPlus1]

changes[el0] = changes[el0] or {}
changes[el0][el1] = changes[el0][el1] or {}
				
table.insert(changes[el0][el1], x)
table.insert(changes[el0][el1], y)
table.insert(changes[el0][el1], table.concat(sameCharArray))
				

По поводу нагрузки на ЦПУ:

писать "buffer.currentFrame[index]" плохо так как система будет каждый раз выполняет следующие действия:

1) получает значение переменной "buffer"

2) получает поле "currentFrame" объекта "buffer"

3) получает поле "index" объекта "buffer.currentFrame"

А если хранить это значение в переменной, то будет одно действие:

1) получает значение переменной "el0"

«Все» программы придется сначала адаптировать к новой OS, а это уже заметный недостаток.

Во, первых это ты сам решил что "все программы придется адаптировать", я такого не писал

Я постараюсь написать такую ОС, на которой можно будет запустить большинство программ без доработки

Надеюсь, что мне не надоест разрабатывать эту OC, иначе будет еще одна R.I.P операционка

Планирую закончить разработку максимум через месяц. По истечении этого времени, я либо выложу готовый результат/альфа-версию, либо забью на разработку

 
P.S. я школьнег и мне кроме написания OC еще учиться надо

Чтобы бы там не говорил Fingercomp по поводу написания своих ОС, я таки пишу свою ОС

Планы такие:
1) разработать операционку с многозадачностью на основе OpenOS с полной совместимостью
2) запуск нескольких программ одновременно(в том числе графических)
3) возможность разбивки экрана на прямоугольные зоны для предоставления программам доступа к этим зонам(программы не будут рисовать графику вне предоставленной зоны)
4) буферизация графики с ускорением отрисовки (как у ECS). Я не стал брать либу от ECS потому что она использует другие либы того же автора и потому что реализована эта библиотека довольно коряво в плане стиля написания кода(мое личное мнение). В общем, я переписал либу ECS с нуля под нужды операционки, кол-во кода сократилось в 5 раз. Все программы написанные на моей OC будут иметь "графическое ускорение" по умолчанию.

Пункты 2 и 3 фактически уже закончены(по-крайней мере мне так кажется)
Буферизация(пункт 4) работает прекрасно, отрисовка графики в некоторых случаях может быть в 3-15 раз быстрее(относительно gpu api)

Также планируется написать несколько очень простых программ для демонстрации возможностей ОС
В частности, хочу реализовать ОЧЕНЬ сильно урезанную реализацию моего любимого оконного менеджера xmonad


Важно: все OpenOS-программы можно будет запустить на моей OC

Хочу предложить вариант серверной

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

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

Главное правило пользования серверной: в ней можно ставить только компы и декор. блоки

Чтобы никто не ставил там лагучие механизмы-печки.

Я считаю, что такая серверная способствовала бы появлению разных публичных сетей и онлайн-сервисов на сервере

Почему просто не купить чанклоадер? Ну потому, что на него игроку придется копить довольно долго(> недели, вроде бы)

А вторая причина -- это возможная нагрузка на сервер. Ведь если 10 игроков держат свои онлайн-сервисы, то они в сумме грузят аж 10 чанков

В случае с серверной все проще, грузится 1 чанк

Это вы рассказываете где нужно наследование, а не о том где не нужно наследовать все методы.

каждый понимает по-своему

Вы считаете, что нужно все методы наследовать, а я считаю что не обязательно наследовать именно все методы. Лучше выборочно

Предлагаю расширить цитату до:

 

"ООП в Луа не нужно."

 

:P

Я имел в виду, что реализовывать singleton в Lua не нужно

Ничего себе: "не нужно". Очень даже нужно было мне, например.

Ну и как вы бы реализовали singleton?

Чем вам не понравилось стандартное исполнение классов в lua?

С чего вы взяли что мне оно не нравится? Оно скорее вам не нравится, так как там нет public static protected friendly

Можно ли в runtime узнать является ли объект чьим-либо наследником или нет?

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

Создание приватных полей и методов похоже на один огромный костыль.

Чего ж вы так не любите Lua, что стандартные области видимости языка вам кажутся костылями?

Почему если вы не понимаете зачем нужны те или иные фишки языка, то человек который их использует -- извращенец? Мне кажется вы никогда и ничего не писали на c++ или java. Основное приимущество слов private, public, protected и тп. это статическая или очень ранняя динамическая проверка наличия ошибок в программе. static нужен для создания общей памяти для всех классов. Также эти маркеры помогают размечать память объекта, но для луа это не актуально.

Те, кто пишут на C++ и Java пусть используют private и protected и т.п. В таком языке как Lua private и protected выглядят просто по-извращенски

Насчёт извращенцев, когда вам потребуется наследовать не все методы из родительского класса?

Представьте себе, что есть объекты Rect, Triangle и Line. У всех этих объектов может быть общий метод Rotate(x, y, z, angle), который будет унаследован у Figure_prototype.Rotate

Знаете что такое singleton? Как его создать используя вашу библиотеку? Как создать несколько singleton'ов в одном пакете?

 В Lua это не нужно. 

Есть класс MyClass. Нужно создать метод класса, который создаёт новый объект класса MyClass и что-то с ним делает. Как это сделать?

Если коротко, то вот так

local myClass = Class({
    __init__ = function(self, x) self.x = x end,
    
    strange_method = function(self, y)
        local myObj = self.__new__(y)
        myObj.desc = "Объект типа myClass"
        return myObj
    end
})

И довольно быстро упёрся в разные проблемы с этим: например, я хочу, не создавая инстанс класса, создать кастомный класс, чтобы заменить какую-то константу в исходном классе. Надо унаследоваться и заменить. У меня надо было таскать мета-таблицу, у тебя — прототип. А в той вкусной либе, которую я описывал, достаточно вот такого кода:

local CustomClass = newClass(BaseClass)
CustomClass.SOME_CONSTANT = 42

И затем можно юзать кастомный класс с переопределённым атрибутом.

 

А в чем собственно проблема? Вот так это делается:

local customClass = function(...)
    local obj = BaseClass(...)
    obj.SOME_CONSTANT = 42
    return obj
end

Получается, если у класса-родителя двести пятьдесят методов и класс-наследник хочет их всех унаследовать, все двести пятьдесят нужно перечислить в объявлении наследника? А нельзя это как-то автоматизировать? Например, передавать прототип родителя в функцию Class() вторым параметром, чтобы она занималась наследованием методов.

Хорошая идея. Наверное так и сделаю

АХ, ДА, СОВСЕМ ЗАБЫЛ

Если вдруг у кого-то возник вопрос "а где private? а где public? а где local private protected?", то вот вам реализация ваших любимых private и public
 
1. public (публичные параметры, которые доступны другим классам) указываются в функции __init__ . То есть в конструкторе класса(все очень просто)

2. private (в моей библиотеке не реализованы области видимости для "приватных" параметров, но зато такие области видимости реализованы в Lua)
Это намек на то, что не нужно усложнять код, а вместо этого стоит использовать уже реализованные области видимости языка Lua
Для этого нужно обернуть код класса в do..end, таким образом создав для этого класса изолированную область видимости
Пример:

local Class = require("class")

local myObject do
    local secretString = "это приватная меременная без всяких заморочек"

    myObject = Class({
        -- класс без конструктора
        publicString = "а это публичная переменная!!!"
    })
end

-- Создание экземпляра класса myObject
local obj = myObject()

print(obj.publicString) -- Выведет "а это публичная переменная!!!"

print(obj.secretString) -- выведет "nil", так как это приватная переменная класса 

3. А любителям всяких там "local private protected friendly" и прочих извращенских протектед-статиков (привет Java и C++) я ничего не могу предложить.   
Так как я не решился реализовывать настолько извращенские вещи, хотя бы потому что я не мазохист и никогда не стану это использовать на практике

Лично мне простых public и private хватает
Надеюсь я не задел ни чьи религиозные чувства!