Jakowlew

Я, конечно, ни на что не намекаю, но за 23 дня дальше лицензии ничего не продвинулось :))

Для С++ использовал прекрасную библиотеку sol. Это очень удобная и функциональная обертка над сишной либой

Ничего в Майнкрафте не востребовано. Всё ради фана. Многие вообще без роботов обходятся.Вопрос же был об экстремальных задачах для OpenComputers, но чтобы без самой игры.

Пожалуй это и сделаю

Одно время я увлёкся темой компрессора Lua-кода, но написал только SFX-модуль, да поиск сжимаемых участков, благодаря чему смог оценить степень сжатия, и на этом успокоился. Вполне экстремальная задача, когда весь код должен помещаться в 4096 байт и более-менее быстро распаковываться.

 

Если интересно, Задачка (алгоритм: ASCII-компрессор)

Это решается кодированием Хаффмана. Можно реализовать, если это востребовано

 

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

 

 

Кстати, кто-то изучил более-менее досконально Minitel? Просто интересно, может это и есть "сеть будущего"?

Как писал выше, можно сделать урезанный аналог ворда с урезанным .rtf, ну или своим форматом. Но ценность сомнительна, да и у того же ECS есть редактор с подсветкой Lua кода. Вот это можно доработать и будет прикольно

@@Jakowlew Большинство из тех, кто пишет, не мучают себя поисками задачи. Играют, пишут какую-то автоматизацию для удобства. Если получается чем-то лучше, чем у других, выкладывают. А если не получается, так хотя бы в игре развлекаются.

Так играть то не интересно. Я вообще сам майнкрафт как игру не люблю, как бы странно это не звучало. Мне очень нравится хардкорное программирование. Тут есть кривой язык (Lua, конечно, крутой скриптовый язык сценариев для игр, но полноценный софт на нем писать не надо), ограничения по памяти, дравколлам, процессору. И сообществу по факту предлагается написать свою инфраструктуру, свой софт, который является пародией на реальные аналоги. Это интересно как отдых, развлечение, не больше. Никакой практической ценности, чистый фан. И мне автоматизировать робота скучно. Это ближе к игре, чем к чистому программированию. А вот решать сложные задачи в таких спартанских условиях действительно весело.

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

Да ну, уже столько сетей написали. Даже на этом форуме видел несколько реализаций.

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

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

Браузер делали-делали, да не доделали, к сожалению. Да и, думаю, это малореализуемо - обработка и отображение HTML-страниц на мониторе разрешением 160x100

Ну почему, можно сделать полосы прокрутки, это не критично

Картинки ужимать. Самое сложное - реализовать DOM и прикрутить JS. Вроде есть компилятор JS в Lua, но сколько это все памяти будет кушать - неизвестно, но явно больше 4мб

@Krutoy, помнится, "Арбузер" писал.

Да что такое :с

Все уже написано. Даже для мода на майнкрафт. Я разочаровался :с

И что, нет никаких нереализованных проблем? Серьезно?

Там группируются в команды для GPU конвертером. Как бы.

 

Стримы через ice2 как-то делаются. Твитч на сервере BTM смотрели же. И звук был.

Да? Ну, ладно. За 40 секунд просмотра кода я этого не понял. Печально. Хотел крутую новую фичу запилить, а ее до меня сделали :с

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

З.Ы. Браузер тоже сделали?

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

Я вообще на C# планировал, питон не знаю. А какие проблемы с аудиодорожкой возникают? Так же команды для звуковой карты отсылать, и сойдет. Хотя из-за фризов звук может отставать или вперед убегать

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

 

Вот, спасибо. Я забыл. nil выкидывает ошибку, я имел в виду NaN.

Мммм! И ещё кто-то пилит то же самое даже.

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

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

Но все таки хочется стримы сделать.

Мммм! И ещё кто-то пилит то же самое даже.

Писал же, что знаком с модом месяц, и практически ничего не знаю о наличии внешних библиотек. Но все же, как обстоит дело со стримами и SLI?

Привет, месяц назад случайно наткнулся на OC, очень доставляет возможность изобретения велосипедов и экстремальной оптимизации. Не знаю, насколько актуальна тема, но все же.
Как вы относитесь к воспроизведению видео в OC? Я хочу написать веб-сервис/десктопную утилиту, которая будет перекодировать видео в последовательность вызовов для GPU. Т.е. на вход подается гифка, или видео с ютуба, на выходе - максимально оптимизированная последовательность вызовов отрисовки GPU. Можно сделать кучу настроек, типа цветности, набора символов, разрешения, вывода команд для GPU в SLI/нескольких компах, подключенных к одному экрану, и т.д. А в случае веб-сервиса можно это на лету делать, организовывая своеобразный "стрим".
Под все это могу и плеер на Lua под опенось написать.
Можно будет на серверах проигрывать видосики, мб даже со звуком, если руки дойдут. Но это требует достаточно больших усилий, а в случае веб-сервиса еще и материальных вложений.

Насколько это востребовано? Будете ли вы лично пользоваться этим? Если много человек нуждается в подобном, то это придаст мотивации, и заставит реализовать задуманное, иначе в этом смысла нет.

Чисто технически - там есть четвёртый вариант.

Это когда errorCode содержит не число, а какой-нибудь boolean или вообще nil.

Но в ветку "Unknown error" этот случай всё равно не попадёт, потому что Lua выбросит ошибку на попытке сравнить переменную с нулём.

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

А теперь сделай JIT-компилятор.

Можно сделать транслятор в Си код, который потом компилируется, вопрос в том, насколько это надо. Код все же для опенкомпов писался

Надо теперь расширить до NetFuck. =)

Ой как не хочется мучаться с сетью и параллельным выполнением. Я по фану написал за 20 минут интерпретатор brainfuck, чтобы запустить на нем интерпретатор brainfuck, написанный на brainfuck, а в нем еще один, и еще, и еще. А потом посмотрел, как это все работает, сказал себе "малаца" и запостил сюда

Brainfuck? Почему бы нет?

Если вы не знаете, что это, то вот ссыль: https://ru.wikipedia.org/wiki/Brainfuck

А вот и сам интерпретатор: https://pastebin.com/DVNbB7Rf

Текущая версия: 1.0

Документация:

-- Создать экземпляр интерпретатора
-- Входной параметр - строка с brainfuck кодом
b = bf:new("++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.")
-- Запустить код
-- Вовзращает строку с ошибкой, если она произошла
b:run()
-- Проверить код на валидность. Код валиден, если вовзращенное значение == 0
valid = b:validate()
-- Получить строку с ошибкой, код которой вовзращает bf:validate()
str = b:getError(valid)
-- bf:run вызывает bf:validate() и bf:getError() внутри себя
-- Поэтому не надо проверять код на валидность самостоятельно 

@eu_tomat@ECS
Упаковал минифайером, чтобы скрипт меньше места занимал. Залил полную версию.

Судя по тестам, при кол-ве элементов около 1000 все происходит буквально мнгновенно, при кол-ве около 10000 - за сотые доли секунды. Тестил все не в опенкомпах, а на своем стареньком ноутбуке, Pentium dual-core, 1.3Ггц на ядро. Но в целом, упаковка/распаковка происходят в ~20-25 раз медленнее, чем при работе с обычными таблицами, причем время вроде как должно линейно расти при увеличении элементов чанка. Но, думаю, даже опенкомпы разницы при размере в 1000-2000 не заметят.

Касаемо памяти, тут все не однозначно. В пиковом потреблении памяти тратится больше примерно в 2-3 раза при небольшой длине массива. При n = 100000 память даже в пике тратится в 2.2 раза меньше, при n = 23000-24000 затраты одинаковы. В нормальном состоянии при записи 8-битных данных выигрыш начинается уже при n = 20-25

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

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

Основная цель - сэкономить память при хранении данных в небольшом диапазоне. Как известно, в Lua целое число занимает 64 бита и может принимать значения от -2^32 до 2^32-1. Такой огромный диапазон практически никогда не нужен и память расходуется впустую. Что если мы попробуем упаковать несколько маленьких чисел в одно большое?

Скачать библиотеку можно здесь: https://pastebin.com/WLmJ19QJ

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

Текущая версия: 1.1
1.0: Первая версия, добавлены все основные методы

1.1: Добавлены методы barr:writeArray(array:table) и barr:readArray(pos:number, n:number):number
 

Пример:

-- Каждое число занимает в памяти 64 бита, т.е. 8 байт
-- Хотя наши значения лежат в диапазоне 0..255 и занимают 1 байт
-- Таким образом, в каждом числе 7 байт простаивают впустую!
local pixel = {
  x = 3,
  y = 4,
  bgColor = 42,
  fgColor = 0,
  char = 18
}

-- 8 - кол-во бит под одну порцию данных
arr = barr:new(8)
-- Записываем наши данные в barr
for i = 1, #pixel do
  arr:write(pixel[i])
end

-- Получаем первый байт, в нашем случае pixel.x
print(arr:read(0)[0]) -- 3
-- Занимаемая память
print(#arr.data * 8) -- 8 байт 

Пример 2:

-- Занимает 24 байта, хотя может всего 1
local struct = {
  flag = 1, -- 0..1, 1 бит
  mode = 3, -- 0..3, 2 бита
  data = 32, -- 0..32, 5 бит
}

arr = barr:new({1, 2, 5})
arr:write(struct) -- 1 байт
arr:write({0, 2, 18}) -- еще 1 байт

local t = arr:read(0)
print(t[1], " ", t[2], " ", t[3]) -- 1, 3, 32
print(#arr.data * 8) -- 8 байт, из них 6 - пустые

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

-- Здесь и дальше arr - экземпляр barr

-- Количество ячеек (cell)
#arr.data
-- Структура порции (chunk)
-- Каждый элемент таблицы - кол-во бит, отведенных под данные
arr.chunk
-- Количество бит, занимемых порцией
-- Является суммой элементов arr.chunk
arr.chunkSize
-- Максимальный размер порции.
--Попытка создать порцию больше данного значения является ошибкой
arr.maxChunkSize
-- Количество порций в массиве
arr.size
-- Максимальное оличество порций в одной ячейке
arr.cellCapacity

-- Создание нового массива.
-- Входной параметр - таблица с данными о структуре порции
arr = barr:new({1, 2, 3, 4, 5})
-- Может быть числом, если порция состоит из одного элемента
arr = barr:new(8)
-- Если входной параметр не число или таблица, то arr == nil
-- Если входной параметр таблица, но ее элементы не числа,
-- или их сумма больше maxChunkSize, то arr == nil
arr = barr:new({1, {}, 3}) -- ошибка, не все элементы таблицы числа
arr = barr:new("2") -- все в порядке, "2" преобразуется в 2
arr = barr:new({10500, 10500}) -- ошибка, размер порции больше maxChunkSize

-- Запись порции в массив
-- Дописывает биты порции в ячейку
-- Если ячейки не хватает, то создается новая, и порция сохраняется в ней
-- Поэтому при однородных данных
-- barr:new(8) лучше, чем barr:new({8, 8, 8})
-- Входной параметр - таблица с данными порции
-- Если значение поля табилцы больше диапазона соответсвующего поля чанка,
-- то оно переполнятся в соответстви с правилами переполнения и ошибка не возникает
-- Если входной параметр == nil, то вовзращется nil
arr = barr:new({1, 3, 5})
arr:write({1, 3, 18})

arr = barr:new(8)
arr:write({257}) -- 257 станет 1, т.к. 257 % 2^8 == 1

-- Чтение порции из массива
-- Входной параметр - порядковый номер порции, нумерация начинается с 0
-- Если входной параметр == nil, < 0 или > size, то вовзращется nil
-- Вовзращает таблицу с данными порции
arr = barr:new(8)
arr:write(42)
t = arr:read(0) -- читает первую порцию, t = {42}
print(t[1]) -- 42
print(arr:read(0)[1]) -- 42, так тоже можно

-- Запись массива порций
chunks = {3, 14, 15, 92, 65, 35, 89}
arr:write(chunks)

-- Чтение в массив порций
-- Читает n порций с позиции pos (нумерация от 0)
-- Возвращает массив с порциями 
chunks = {}
pos, n = 0, 3
arr:read(pos, n)
print("Pi = ", chunks[1], ".", chunks[2]) -- Pi = 3.14

-- Вспомогательные ф-ии
-- Возведение целого числа x в степень y, где y целое и y >= 0
arr:pow(3, 3) -- 27
-- Возведение 2 в степень y, где y целое и y >= 0
arr:pow2(10) -- 1024
-- Возведение в степень работает с целыми числами
-- Необходимость в низ появилась тогда, когда
-- math.pow(2, 55) == math.pow(2, 55) - 1
-- оказалось true из-за погрешности в операциях с плавающей точкой

Когда использовать barr? Каждый пустой экземпляр barr занимает как минимум 48 байт и 544 как максимум (если порция состоит из 64 1-битовых полей, в таком случае лучше использовать порцию из 1 1-битового поля, тогда размер barr будет 48 байт).

Таким образом barr помогает при достаточно большом объеме данных, выигрыш от экономии которых нивелирует затраты на размер пустого экземпляра и 8 байт на каждую новую порцию. Как и писалось выше, можно максимальная экономия памяти составляет практически 64 раза.

Если это кому-то понадобится, то библиотека будет развиваться и обновляться. Все изменения буду дописывать сюда. Актуальная версия библиотеки тоже будет отображаться

Тесты:

Тесты проводились на чистом Lua 5.3

Код самого теста:

local b = require("barr")

local lim = 100000
print("Элементов таблицы: ", lim)

collectgarbage(collect)
mem1 = collectgarbage("count")
time1 = os.clock()
local t1 = {}
for i = 1, lim do
  t1[i] = 42
end
time2 = os.clock()
mem2 = collectgarbage("count")
tpic = (mem2 - mem1) * 1024
print("Пиковая память таблицы: ", tpic)

collectgarbage(collect)
mem2 = collectgarbage("count")
tnorm = (mem2 - mem1) * 1024
print("Нормальная память таблицы: ", tnorm)
ttable = time2 - time1
print("Время таблицы: ", ttable)
print("======")

collectgarbage(collect)
mem1 = collectgarbage("count")
time1 = os.clock()
t2 = b:new(8)
for i = 1, lim do
  t2:write({1})
end
time2 = os.clock()
mem2 = collectgarbage("count")
bpic = (mem2 - mem1) * 1024
print("Пиковая память barr: ", bpic)

collectgarbage(collect)
mem2 = collectgarbage("count")
bnorm = (mem2 - mem1) * 1024
print("Нормальная память barr: ", bnorm)
tbarr = time2 - time1
print("Время barr: ", tbarr)
print("======")

if tpic > bpic then print("Выигрыш в пиковом потреблении, раз: ", tpic / bpic)
else print("Проигрыш в пиковом потреблении, раз: ", bpic / tpic) end

if tnorm > bnorm then print("Выигрыш в нормальном потреблении, раз: ", tnorm / bnorm)
else print("Проигрыш в нормальном потреблении, раз: ", bnorm / tnorm) end

if ttable > tbarr then print("Выигрыш во времени, раз: ", ttable / tbarr)
else print("Проигрыш во времени, раз: ", tbarr / ttable) end

Результаты тестов:

Объясните дураку, как скачать библиотеку? Я потратил 15 минут и не нашел в четырежды просмотренном посте ссылку на саму либу, только на зависимости. И такое почти во всех темах с библиотеками. ГДЕ ОНИ ХРАНЯТСЯ? ОТКУДА ИХ КАЧАТЬ?

 

Также можно разделить один экран пополам и выделить каждой видеокарте свою половинку монитора - по идее сработать должно, а-ля VSync

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

 

 

А две видеокарты к одному монитору подключить НЕВОЗМОЖНО, это даже в документации написано: http://ocdoc.cil.li/component:gpu (метод bind)

"A GPU can only be bound to one screen at time" - Одна гпушка может быть привязана только к одному экрану. Про привязывание нескольких гпу к тому же экрану ничего не сказано. Собственно отсюда мой вопрос и вытекал, вроде можно, а вроде и нет. А черная магия непонятно что делает

gpu[1].bind(screen.address)
gpu[1].set(1, 1, tostring("GPU ", 1))
 
-- WTF??? --
print("")
 
gpu[2].bind(screen.address)
gpu[2].set(1, 2, tostring("GPU ", 2))

Это на самом деле хороший вопрос.

В ранних версиях OpenComputers такой фокус прокатывал, и кто-то даже пилил себе этакий псевдо-SLI на парных видюхах для ускорения графики.

Но затем, в какой-то момент Сангар переработал систему лимитов по производительности, и больше это не работает.

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

(Хотя я это лично не проверял, и можно таки затестить.)

На самом деле вопрос производительности вторичен. В крайнем случае можно с двух разных компьютеров рисовать в один экран. Проблема остается такая же: как несколько видеокарт / разных компьютеров подключить к одному экрану?

Привет. Два дня назад я наткнулся на чей-то гайд по OpenComputers. Я майнкрафт не очень люблю и последние лет пять в него не заходил, но я люблю программировать, а полноценные компьютеры в игре мне очень понравились Но перейдем к делу: как заставить две видеокарты работать с одним экраном? Я храню компоненты в массиве и это не работает:

for i = 1, #gpu do
    gpu[i].bind(screen.address)
    gpu[i].set(1, i, tostring("GPU ", i))
end

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

gpu[1].bind(screen.address)
gpu[1].set(1, 1, tostring("GPU ", 1))

-- WTF??? --
print("")

gpu[2].bind(screen.address)
gpu[2].set(1, 2, tostring("GPU ", 2))

Что за черная магия здесь происходит? И вообще, есть ли смысл привязки нескольких видеокарт к одному экрану ради обхода ограничения на отрисовку?