ProgramCrafter
Пользователи-
Публикации
245 -
Зарегистрирован
-
Посещение
-
Победитель дней
41
Тип публикации
Блоги
Профили
Форум
Багтрекер
Магазин
Все публикации пользователя ProgramCrafter
-
Хотел заказать эту программу у других, но пришлось писать самому. Ничего, награду тоже выдам себе. Моя программа (https://github.com/ProgramCrafter/lua-utils/blob/a22e5e50ad46f130f6a7ec5959cd7282bb8a06df/beealyzer_v1oc.lua) служит компактным интерфейсом для сундука с пчёлами. Её возможности: 1. Сканирование сундука и вывод списка проанализированных пчёл с их характеристиками на экран (при запуске происходит автоматический скан); 2. Выдача любой пчелы кликом левой кнопкой по её описанию; 3. Принудительное обновление списка (если в сундуке что-либо появилось) правой кнопкой мыши; 4. Выход кликом по заголовку. Схема собирается таким образом: к компьютеру надо подключить транспозер, сверху на него поставить сундук с пчёлами, а с восточной стороны (правится в коде) выбрасыватель. Выбрасыватель требуется запитать от генератора импульсов (я использовал таймер из RedLogic из-за его компактности) - программа не подаёт самостоятельно импульс для выкидывания пчелы. Чтобы программа работала, не забудьте поменять в начале программы ник доверенного пользователя на свой. Программа воспринимает нажатия только от доверенного пользователя - то есть, по умолчанию, только от меня. Как выглядит интерфейс:
- 18 ответов
-
- 7
-
-
- транспозер
- forestry
-
(и ещё 2 )
Теги:
-
micro bios, bios с возможностью запустить openOS онлайн
ProgramCrafter ответил в тему logic в eeprom
Is it time to analyze code? -
А разве doubleBuffering не предназначен для минимизации закрашиваний? Можно же пропатчить component.invoke для видеокарты так, чтобы она добавляла запрос в буфер, и чтобы раз в какое-то время этот буфер отправлялся на другой комп. + не 3 ведь байта на цвет, у OC палитра маленькая, 256 цветов максимум.
-
Может быть, из гифки, где показывается установка: Но вообще у меня есть подозрение, что на ютубе много обзоров MineOS, и наверняка показана установка с Pastebin. Инсталлер оттуда удалили не так давно, вот все сейчас и спрашивают - а почему не устанавливается?
-
Да это же MineOS! Новая ссылка и вправду есть: https://raw.githubusercontent.com/IgorTimofeev/MineOS/master/Installer/BIOS.lua Ну и одна команда, чтобы скачать и установить:
-
@lag2016 Если я верно понял, проще всего сделать так: - консольная программа на OC-планшете (turn-on.lua, например) принимает в качестве аргумента номер лампы, которую надо включить/выключить, и пересылает на OC-сервер с помощью беспроводной сетевой карты сообщение; - программа в авторане OC-сервера добавляет слушателя на сообщения беспроводной сетевой карты; этот слушатель и переключает редстоун-блоки. Вот простейший вариант программы: -- программа-клиент -- использовать как <путь к программе> +<номер лампы, чтобы включить> -- либо <путь к программе> -<номер лампы, чтобы выключить> local com = require 'component' local lamp = (...) -- достаём первый аргумент из переданных com.modem.broadcast(8833, lamp) ------------------- -- программа-сервер local com = require 'component' local evt = require 'event' local sid = require 'sides' local redstones = {} for rs_addr in com.list('redstone') do redstones[#redstones + 1] = com.proxy(rs_addr) end com.modem.open(8833) evt.listen('modem_message', function(_, _, _, port, _, data) if port ~= 8833 then return end if data:sub(1, 1) == '+' then redstones[tonumber(data:sub(2, 2))].setOutput(sid.top, 15) elseif data:sub(1, 1) == '-' then redstones[tonumber(data:sub(2, 2))].setOutput(sid.top, 0) end end)
-
Сбрасывать кеш надо перед require('numbers'): package.loaded['numbers'] = nil что-то там = require('numbers')
-
Кстати, раз уж речь про магазин приложений - а можно фичу, чтобы не отрисовывать иконки приложений, а просматривать всё в виде списка? А то лагает просто ужасно.
-
Вроде бы лучше библиотеки складывать в /usr/lib/<name>.lua, но это так, просто для красоты. Новые тоже. Офнуть проблематично, для этого надо (и надо бы, кстати) переписать require. А выбросить библиотеку из кеша можно так: package.loaded[<name>] = nil
-
@Bumer_32 Хорошо, вот 62 строки: https://gist.github.com/ProgramCrafter/3b6a2faa6f4da3f74b0ca52b5aee4dc5 Самый базовый код, без обработки ошибок, но некоторое время может работать.
-
@rootmaster А что насчёт а желательно и возможности посмотреть на код, не устанавливая его никуда?
-
Можно, но есть более интересный метод, его можно здесь посмотреть: Вкратце: добавляемый OC шум может иметь только 256 разных значений. Можно перебрать плотность блока, вычислить, какой шум был добавлен, из этого получить тот байт, который для добавления шума используется. Если этот "байт" не целый или не лежит в интервале [-128; 128), то мы не угадали, и надо проверять какую-то другую плотность. P.S. На мой вкус, стоило бы сделать какой-то ровный фон, вроде угля, глины или чего-то подобного. Но это уже мелочи
- 1 ответ
-
- 2
-
-
-
- карта
- opencomputers
- (и ещё 3 )
-
attempt to index local (a boolean value)
ProgramCrafter ответил в вопрос FADRI в Помогите найти ошибку
В конец библиотеки надо return data. Потом стоит перезагрузить компьютер (или выполнить в интерпретаторе lua package.loaded['data'] = nil), чтобы старая библиотека была удалена из кэша.- 3 ответа
-
- 1
-
-
Так это и не резюме (как минимум, пока что). Посмотрел, увидел, что компилирует только C/C++/что-то в LLVM, закрыл . Хотя, мб, можно линукс перегнать в такой формат. Но надо ещё разбираться, как используемые регистры у x86 соответствуют моим. Вообще, псевдокод, который я транслирую в movasm, по синтаксису питон, а по используемым функциям - странная смесь C++, раста и, конечно, самого питона. Например, аллокатор, который я сейчас пишу (да, здесь могут быть баги и тому подобное): _static_alloc = 1024 def _static_allocate(size): _static_alloc += size return _static_alloc - size def _static_deallocate(p): pass _alloc_cl_first = _static_allocate(4) _alloc_cl_first->first = 1048575 def _list_ins_between(L: *list_node, R: *list_node, u: pair<size_t, size_t>): v = _static_allocate(4) v->first = u.first v->second = u.second v->third = R v->fourth = L if L: L->third = v if R: R->fourth = v return v ...
-
Опс, я понял: если взять в качестве состояния не только текущую вершину, но и набор существующих на данный момент рёбер, то получится не менее конечный автомат, размер которого будет n * 2^(n^2/2). Теперь единственная проблема, что этот граф слишком большой, чтобы с ним по-нормальному работать, но как минимум, он не бесконечный. А значит, с ним можно работать, как с обычным...
-
Например, ОС написать. Или портировать что-нибудь из линуксов, я вообще хочу попробовать написать транслятор x86 в movasm. И будет наконец без помощи VirtualBox в майнкрафте серьёзная ОС.
-
Да, насколько я знаю, теории конечных автоматов с изменяющимися правилами ещё никто не создавал. (Кстати, может, именно поэтому не могут вывести "формулу всего" в физике?)
-
Да, я знаю, надо только записать в документацию поведение при переполнении. Необязательно, можно же так расположить команды, что в большинстве мест можно будет выполнять по два или больше mov одновременно. Например, условные переходы у меня сейчас используют особый регистр atz: он возвращает atz1, если atz0 == 0, иначе atz2. Значит, если я хочу при v == 0 прыгнуть в одно место, а при v != 0 в другое, то я могу одновременно записывать v, положение первого и второго места в atz0, atz1 и atz2. Я говорю вот что: во-первых, mov исполняется никак не медленнее любой инструкции x86 (может быть, медленнее nop, но это не точно); во-вторых, вроде бы, любую из старых инструкций x86 (до появления дополнений с векторизацией и тому подобным) можно превратить не более чем в 8 моих инструкций. Работать будет, конечно, медленно, но будет. Например, чтобы и скалу подучить. Для джавы у меня другой проект, OCTechnics Да какая разница, я могу код и без этого писать... То есть, грейды junior-middle-senior только у нас так называют? Скорее всего, только новую. Через протоеепромы, конечно. Например, просто перекрутить обычный EEPROM гаечным ключом сколько-то раз.
-
Пока единственная идея, которая у меня появлялась - использовать регистры io. io0 - индекс устройства, io - регистр для обмена данными. Протокол обмена данными с разными компонентами надо, конечно, продумывать. Например, с дискетой или жёстким диском такой обмен данными будет очень медленным, по 8 байт за операцию. Но, например, роботу хватит.
-
Что это? Пока разрабатывается OpenComputers II, у меня уже появилась идея для OpenComputers III. Основывается она на далеко не новом принципе: сделать компьютер, в котором все вычисления происходят в памяти/регистрах, а единственная возможная команда - MOV (скопировать значение из одного регистра в другой). Но я не встречал никаких виртуальных машин для такой архитектуры, поэтому решил написать свою. Для чего? Пока что - исключительно ради фана. Потом - может быть, получится развести схему для такого процессора и начать производить его, но это точно не близко. Где потыкать? Текущие реализации (2 штуки, не во всех случаях работают одинаково): https://github.com/ProgramCrafter/python-mov-vm - на Python https://github.com/ProgramCrafter/rust-mov-vm - на Rust У меня была и реализация на Lua, но её я куда-то потерял. Сейчас думаю написать на Scala, как дополнительную архитектуру к OpenComputers. Что умеет? Пока что - печатать текст в консоль и считывать там же нажатия клавиш. Вообще, насколько я посчитал, любая инструкция x86 представляется в виде не более чем 8 MOV-инструкций, так что эта архитектура не должна быть существенно медленнее. Кроме того, каждая инструкция здесь 32-битная, поэтому предсказатель ветвлений и конвейер инструкций (в физическом варианте процессора) будут быстрее работать. Как выглядит какая-нибудь программа? Выводит ╔══════════════════════════════════════════════════════════╗ ║ TigerOS v0.0.1 | not licensed!!! ║ ╚══════════════════════════════════════════════════════════╝ Выход по нажатию пробела в консоли. Байткод: \x80<\x00\x1c\x80\n\x00\x1b\x80\x01\x00\x04\x00\x03\x00\x14\x00\x1d\x00\x15\x80\x07\x00\x16\x00\x17\x00\x1b\x00\x1e\x00\x10\x00\x05\x00\x03\x80\x03\x00\x1b\x00\x10\x00\x03\x80 \x00\x04\x00\x05\x00\x14\x80N\x00\x15\x80\x10\x00\x16\x00\x17\x00\x1b\xa5T\x00\x10\x00\x1c\x00\x03\x80\x02\x00\x04\x00\x05\x00\x03\xa5P\x00\x1e\x80\x17\x00\x1d\x80\x02\x00\x1b\xa5W\x00\x10\x80\n\x00\x10\xa5Q\x00\x10\x80 \x00\x10\x80 \x00\x10\x80T\x00\x10\x80i\x00\x10\x80g\x00\x10\x80e\x00\x10\x80r\x00\x10\x80O\x00\x10\x80S\x00\x10\x80 \x00\x10\x80v\x00\x10\x800\x00\x10\x80.\x00\x10\x800\x00\x10\x80.\x00\x10\x801\x00\x10\x80 \x00\x10\x80|\x00\x10\x80 \x00\x10\x80n\x00\x10\x80o\x00\x10\x80t\x00\x10\x80 \x00\x10\x80l\x00\x10\x80i\x00\x10\x80c\x00\x10\x80e\x00\x10\x80n\x00\x10\x80s\x00\x10\x80e\x00\x10\x80d\x00\x10\x80!\x00\x10\x80!\x00\x10\x80!\x00\x10\x00\x1c\x00\x03\x80$\x00\x04\x00\x05\x00\x03\x80 \x00\x1e\x80B\x00\x1d\x80\x02\x00\x1b\xa5Q\x00\x10\x80\n\x00\x10\xa5Z\x00\x10\x00\x1c\x00\x03\x80\x02\x00\x04\x00\x05\x00\x03\xa5P\x00\x1e\x80K\x00\x1d\x80\x02\x00\x1b\xa5]\x00\x10\x81\x00\x00\x10\x80\n\x00\x1b\x81\x01\x00\x10 Ассемблер (программа для перевода в байткод лежит вместе со всем на Python): Структура команд Каждая команда является 32-битной: первые 16 бит описывают источник, следующие 16 - номер регистра назначения, куда надо записать значение источника. Если первый (старший) бит из 16, задающих источник, равен единице, то оставшиеся 15 бит - это число, которое будет записано в регистр назначения. Иначе эти 15 бит задают номер регистра-источника, из которого будет считано значение. Набор регистров Каждый регистр хранит 64-битное целое число. Всего регистров может быть не более 32768 из-за адресации. Номера регистров: Значение доступных на данный момент регистров: Пока виртуальные машины несовместимы друг с другом только при переполнении чисел в регистрах. Rust упадёт с ошибкой, Python начнёт спокойно использовать длинную арифметику, а Lua начнёт спокойно терять точность, используя double.
-
В OpenComputers есть ограничение по количеству копируемых строк - максимум 256 строк копируется за один раз. (Это происходит из-за того, что ограничен размер очереди событий.) Поэтому придётся скопировать вторую половину кода отдельно.
-
По мотивам Lua? ы серьёзно? Оно же будет запускаться любым компом, к которому будет подключено, то ли дело MovEMU Byte Code, запускаться будет только через виртуальную машину (на Lua, так уж и быть) или новую архитектуру OpenComputers (которая ещё не готова); там не будет TLWY, можно будет использовать sleep, не теряя события, и так далее...
-
И библиотека bigModem, от которой всё это зависит (она занимается, видимо, пересылкой больших сообщений и ретрансляцией сообщения по всем компьютерам в сети, как Zn):
-
Is it time to analyze code? networks.lua (не особо разбирался, что и как работает)
