Лидеры

Напомню, что есть /dev/eeprom и /dev/eeprom-data. С тех пор, как эти файлы реализовали в OpenOS, надобность в утилите flash отпала совершенно. # cat bios.lua > /dev/eeprom # echo > /dev/eeprom-data # cat /dev/eeprom > bios.lua

# echo "Some Label" >/dev/components/by-type/eeprom/0/label ######################################################### # # весь интерфейс EEPROM # ls /dev/components/by-type/eeprom/0/label address contents dataSize label size type checksum data device makeReadonly slot

Проблема: мы с друзьями носим квантовый набор брони, из полезных функций которого мы используем автоматическое пожирание консервных банок, но в какой-то момент у нас кончаются баночки, ускорение при беге пропадает, мы вынуждены отвлечься от своих влажных дел чтобы заменить баночки (поиск в сундуках или же поиск в МЭ терминале). Решение: замена пустых баночек на полные с помощью машины и PIM из аддона OpenPeripheral. Установив нехитрую конструкцию из двух сундуков и PIM (под PIM спрятан адаптер подключенный к машине), мы получаем такую вот кормушку для сильных и зависимых, которая ворует у них пустые банки (а может и не только баночки?) и всучивает полные банки говядины. Настройка программы сделана в виде констант в начале файла local CHEST_SIDE = "west" local FILLED_CHEST_SIDE = "north" local chestSlotLimit = 3*9 local usingME = true Нажимаете F3, смотрите в сторону где у вас сундучок, вводите. В usingME ставите true или false в зависимости от того, поставили ли вы МЭ шины импорта-экспорта на сундуки. В случае если вы не используете МЭ, программа держит в памяти счётчик следующего слота из которого брать баночки и обновляет его при обмене банок. В chestSlotLimit указывается количество слотов сундучка из которого забирать консервы. Программу можно скачать отсюда: https://raw.githubusercontent.com/rasongame/OpenComputersProgs/master/vending.lua

Что такое RemoteOS RemoteOS - это мост для связи OpenComputers с внешним миром, написанный на языке C# (.NET 6.0). В чём отличие RemoteOS от уже существующих решений Начнём с самого очевидного и главного - на сервере имеется (почти) точная копия API OpenComputers. Это позволяет не только использовать подсказки в коде при работе с мостом в IDE но и проверять данные подаваемые в методы ещё до отправки их на компьютер OpenComputers(далее машина). Так-же такой подход позволяет реализовать кэширование, которое даёт возможность в некоторых местах не дёргать постоянно машину для опроса актуальных значений... Из-за того что на сервере наклёпано столько архитектуры он не такой легковесный как остальные мосты... Мой мост работает не из под OpenOS а прямо с EEPROM'а, что позволяет значительно снизить минимальные системные требования для работы этого моста но при этом это же отличие значительно его ограничивает - будут недоступны все те удобненькие библиотеки из опенос, то-есть нельзя работать ни с чем кроме того что предоставляет lua и клиентская ос моста... Не нужно запрашивать сигналы с машины, она сама их шлёт серверу... Какие у RemoteOS системные требования Для машины - интернет карта и EEPROM прошитый на клиентскую ос RemoteOS Для сервера - 1 открытый сетевой порт чтобы иметь связь с машиной и достаточная вычислительная мощность чтобы суметь запуститься а затем отсылать пакеты машинам, получать от них ответ и обрабатывать этот ответ... Как же всё таки пользоваться RemoteOS Начнём с того что C# - не самый удачный выбор для связки с LUA ибо C# это строго типизированный яп а луа не очень...и подгонять сервер под все причуды луа кода было тем ещё приключением...но у меня вроде как вышло, так что посмотрим как всем этим добром пользоваться... Ловля подключений: Компоненты: Сигналы: Выполнение произвольного кода: Директивы предпроцессора: Веб сервер: Какие у меня планы на RemoteOS [+] Планирую добавить документацию в код, чтобы можно было прямо в IDE зачитать что конкретный метод делает... [+] Хочу сделать веб-интерфейс для управления машинами Хочу довести кэширование до ума, чтобы надо было дёргать машины ещё меньше Может быть добавлю поддержку локальной(внутриигровой) сети на сетевых картах/ретрансляторах чтобы ещё больше снизить минимальные требования для клиентской ос Ссылки Репозиторий проекта: Тык (Github) Клиентская ОС: Тык (Github) Демо-видео: Тык (Яндекс диск)

Думаю авторы, чьи программы состоят более чем из одного файла, задумываются о том, как все эти файлы грузить конечному пользователю. Этой проблемой задался и я, а потому изначально воспользовался слегка модифицированным установщиком Игоря. Однако данный инсталлятор. в силу своей простоты, не очень удобен и малофункционален. Поэтому возникло желание сделать свой. Сегодня я представляю вашему вниманию универсальный, удобный и легко конфигурируемый установщик WebWyse. Основной функционал: Возможность встроить лицензионное соглашение (не приняв его пользователь не установит софт) Проверка компьютерного оборудования на соответствие системным требованиям Возможность устанавливать (или не устанавливать) дополнительные компоненты Выбор папки, куда будет установлена программа Интерфейс, адаптированный под все три тира видеосистем Заготовки можно найти в Репозитории GitHub. В качестве примера также можно использовать конфигурации установщиков для других моих продуктов вроде Mempisto, TapFAT, ВычВыжПром и MC Plus.

Всем привет! Увидел я у одного человека очки, которые показывали кол-во EU/t в молекулярке и другие данные, решил повторить. НЕ много перестарался, добавил бесполезные функции(они отключаются, путём отключения компонента :D) В итоге что может эта программа: Настройка программы: Возможность отключать не нужные функции, по типу отображения игроков около МЭ, для этого достаточно отключить компонент, которые за это отвечает: Кол-во предметов в МЭ = МЭ контроллер, Чат-бокс, Список игроков - Радар, Кол-во ЕУ/т - Cчётчик Так-же подключить компонент можно и во время работы программы, компонент подключится автоматически и информация будет обновленна. Сама программа: https://pastebin.com/uey3RdbF pastebin get uey3RdbF glasses.lua За код строго не судите, написал минут за 20-ть, да и первая адекватная программа.

Теперь делаем консервы на наковальне

Я вообще думал, что ты создал эту тему ради шутки. Как-то слишком удачно тут совпало отсутствие ссылки на программу с отсутствием потребности в ней. А фраза "идея подобной утилиты напрашивалась давно" ещё более усилила атмосферу абсурда. Хейтом принято называть открытое эмоциональное выражение ненависти, враждебности, злости. Собственно, английское слово хейт и означает ненависть. А что называешь хейтом ты? Но раз тема не шуточная, можно обсудить её по существу: Мне не приходилось сталкиваться с подобным. Приведи примеры программ, работающих некорректно из-за сохранения старых данных в EEPROM. И каким программам требуются данные по умолчанию?

Да, примерно так. Возможно, не 5 секунд, если изменить значение в файле конфигурации. И реальность времени там очень условна. Сколько времени займёт выполнение того или иного кода, спрогнозировать сложно. Но именно os.clock даёт точное понимание того, сколько этого времени осталось. Процесс не убивается, но генерируется исключение. Его можно перехватить, запустив код через pcall. Вместе с ошибкой TLWY ты получишь ещё 0.5 секунд времени на то, чтобы уступить время, например, вызвав computer.pullSignal, но успеешь ли ты это сделать, тоже никто не обещает. И новый слой оборачивания вызова кода в pcall уже точно не поможет. Рассматривай доступное тебе время как потребительский кредит. Возвращать его или платить по нему проценты не требуется, т.к. уступка времени закрывает предшествующий ей кредит. Главное, не превышать отпущенный лимит, значение которого всегда заранее известно. Проблема в том, что ты получаешь этот кредит всегда реальным товаром, стоимость которого узнаёшь лишь после совершения сделки. Пока не купишь, стоимость не узнаешь. А стоимость может меняться в значительных пределах, на несколько порядков. Закрытие кредита также имеет цену, заранее неизвестную. И если ты не страхуешься: не сохраняешь результаты предыдущих сделок и не резервируешь часть кредита на его гарантированное закрытие, то потеряешь всё. Выполнение тяжёлого фрагмента кода может оказаться неподъёмным, поэтому его следует дробить на куски помельче, проверяя оставшийся лимит после выполнения каждого из них. Но дробить код на совсем крохотные куски тоже не имеет смысла, т.к. проверка оставшегося лимита хотя и дешева, но тоже не бесплатна. Какую часть кредита использовать на выполнение целевого кода, какую потратить на проверку текущего баланса и фиксацию промежуточных результатов, а какую оставить в резерве на непредвиденное повышение стоимости финальных операций — зависит от характера задачи и конкретного сервера. Но если программисту приходится регулярно задумываться над этим вопросом, то что-то не так либо с сервером, либо его задачами, потому как сервер Майнкрафта не предназначен для тяжёлых вычислений. В первую очередь от тяжёлых вычислений надо постараться избавиться. Во вторую очередь тяжелые вычисления должны быть оптимизированы. И лишь в третью очередь следует подумать, как побороть TLWY.

Вариант для дальнейшего улучшения - автоматизировать наполнение консервов. Любой предмет с названием "Tin Can". Ну, может, ещё имя игрока записывает. Бекдоров пока не видно.

Единственно верным ориентиром для оценки приближения TLWY является значение os.clock(). Более-менее устойчиво работающий код может выглядеть, например, так: computer.pullSignal(0) c0 = os.clock()+4 while os.clock()<c0 do -- вычисления -- ... end На устойчивость влияют: Доступный резерв времени. В данном случае 1 секунда из 5 доступных секунд (по умолчанию). Тяжесть кода, производящего вычисления. Быстродействие сервера, то есть, его способность обработать вычислительную часть кода. Текущая загрузка сервера другими процессами, никак не связанными с выполняемым кодом. Приведённый код способен устойчиво работать в течение длительного времени, но полной гарантии, что его выполнение не закончится ошибкой, конечно же, нет. Точное прогнозирование TLWY возможно на слабонагруженных серверах. Но на реальных серверах внезапно появившаяся нагрузка может сломать любой прогноз. Выше я упоминал, что пачку из 10 вызовов computer.pullSignal(0) желательно распределять во времени. Такой подход кроме прочих его преимуществ позволяет снизить вероятность получить TLWY. Полагаю, этот момент не требует объяснений.

Вариант крупного шрифта с поддержкой русской и английской раскладки набор символов https://pastebin.com/XNLGNrj9 letter.lua пример использования local letter = require("letter") local unicode = require("unicode") local com = require ("component") local gpu = com.gpu local function print_letters(x,y,txt,color) gpu.setForeground(color) for i = 1, unicode.len(txt) do local sym = unicode.upper(unicode.sub(txt,i,i)) gpu.set(x,y,letter[sym][1]) gpu.set(x,y+1,letter[sym][2]) gpu.set(x,y+2,letter[sym][3]) x = x + letter[sym][4] end end os.execute("cls") print_letters(10,10,"привет мир",0x00FF00)

Приветствую вас. Этот пост я пишу, чтобы рассказать вам о своей разработке для мода OpenComputers: BetterBIOS Это специальная прошивка BIOS для EEPROM, позволяющая выбирать любое из подключенных устройств для загрузки. Для этого используется пользовательский псевдографический интерфейс, который поддерживается на всех уровнях видеокарт и экранов. Так же, в этой прошивке есть своя система отображения ошибок, показывающая весь "traceback" за исключением не нужных пунктов внутри самой прошивки. Это будет очень полезно для разработчиков собственных операционных систем, ведь данная прошивка подскажет места, в которых возникла ошибка, в то время как стандартная прошивка молчит как партизан. UPD. Начиная с версии 4, код ошибок можно пролистывать: Если доступных для загрузки устройств больше, чем одно - то при включении компьютера, пользователю предлагается выбрать одно из них. Если такое устройство только одно - загрузка начнётся незамедлительно. Подключение устройств для загрузки происходит динамически, "на лету", прямо во время выбора устройства. Так же, данная прошивка имеет приоритеты на выбор экрана: первым делом она пытается подключить тот экран, у которого есть клавиатуры поблизости. Если таковых не имеется - использует любой другой. Видеокарту прошивка использует максимального уровня. Прошивка защищена от критических сбоев при резком извлечении устройств, пока программа работает с файлами на них. Это делает данную прошивку практически не убиваемой, и позволяет избегать любых несчастных случаев при работе с компьютером. Я просто параноик, иначе сделать не мог... Данная прошивка поддерживает большое количество разных операционных систем, использующих разные файлы для загрузки: OpenOS Plank9 MineOS Работает это за счёт списка файлов, которые ищет прошивка. Вы можете добавить свои файлы, вписав их в переменную в начале файла. Ну или можете оставить комментарий под этой темой, с просьбой, какой файл стоит ещё добавить. Забавный факт: Если таких файлов будет очень много, то посмотрев их список нажатием клавиши F8 при выборе устройства - вы можете пролистывать список. Так же, если вы хотите, чтобы прошивка при запуске не перезаписывала данные EEPROM (setData), и не мусорила в оперативной памяти рудиментарными функциями типа "computer.getBootAdress", которые нужны для OpenOS - вы можете отключить всё это дело в меню через клавиши. А если вам не хочется каждый раз их нажимать - то просто измените комментарий в конце кода с 11 на 10 или 00. Несмотря на весь этот функционал и продуманность, в минимизированном виде данная прошивка помещается на EEPROM, стандартная ёмкость которого - 4096 символов. К сожалению, код не очень хорошо читаемый, но это обусловлено тем, что я писал заранее с расчётом на то, что подробный код будет минимизирован, а для них нужно ещё и грамотно написать код, который, увы - сложно читается. Исходный код данной прошивки вы можете посмотреть здесь. Спасибо за внимание. Если у вас есть какие-то идеи, как можно улучшить или ухудшить данную прошивку - пишите здесь, или как-нибудь вычислите меня, постараюсь подумать, и может быть, даже обновлю код, сделав его лучше для вас.

Сделал набросок проги По просьбе заказчика добавил поддержку нескольких сенсоров Также кнопку выхода Ctrl Обернул функцию в pcall чтоб защитить прогу от падения Для безопасности после запуска в публичном месте, советую снять клавиатуру !

Ссылка на программу отсутствует, но это не страшно. Ведь полное копирование EEPROM вместе с меткой, данными и флагом ReadOnly можно выполнить на верстаке.