Перейти к содержимому

Fingercomp

Гуру
 Профиль  Активность

  • Публикации

    1 629

  • Зарегистрирован

  • Посещение

  • Победитель дней

    283

Записи блога, опубликованные пользователем Fingercomp

  1. Fingercomp

    Что такое IRC

    Автор: Fingercomp,

    Сегодня нашему каналу в IRC исполняется один годик, поэтому пришло время рассказать, что это, зачем это и как к нему подключиться.
     
    Начнём с понятий.
    IRC — это протокол обмена мгновенными сообщениями через интернет. Сделанный в далёком 1988 году, и по сей день он всё ещё юзается из-за удобности, простого масштабирования, простоты и доступности буквально отовсюду, где есть подключение к интернету — вплоть до холодильников.
    В общении участвуют клиент и сервер. Клиенты подключаются к серверу и общаются.
    Для разделения тем существуют каналы — на каждом отдельные сообщения, темы, люди и так далее. Так что на одном сервере могут быть сотни каналов, никак друг с другом не связанных.
     
    Главное, что нужно понять: IRC — это не чат в браузере, как здесь на форуме. Здесь отдельные серверы, отдельный протокол, и поэтому просто так через браузер не подключиться, набрав адрес сервера. Для подключения к IRC нужно воспользоваться специальной программой — клиентом. Здесь я покажу несколько клиентов и расскажу, как их настроить.
     


    Веб-клиент Iris IRC
    Для ситуаций, когда надо по-быстрому зайти на канал, но клиента нет под рукой или лень настраивать. Для полноценного сидения использовать проблематично, так как требуется грузить жирный браузер, и стабильность подключения так себе.
    Кроме того, веб-клиенты — поделки очень плохого качества, неконфигурируемые, отсутствуют банальнейшие фичи, например форматирование, или сделаны криво. Тем не менее.  

    Возьмём, например, Iris IRC. Ссылка на него (нацеленный на серверы Esper) находится вверху, в панели навигации (). Штука очень минималистичная.



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



    Что здесь видим?
    Во-первых, кнопка меню . Советую сразу перейти в Menu ‣ Options и поставить галочку напротив "Automatically colour nicknames", чтобы визуально различать людей на канале — по цвету.
    Во-вторых, переключалка каналов . Можно тыкать Alt и цифру от 1 до 9, чтобы быстро переключаться между каналами.
    Строка топика — небольшого сообщения с темой обсуждения или просто полезными ссылками.



    Ниже находится окно чата, в котором будут отображаться ваши сообщения и сообщения других людей, а так же другие оповещения (например, о заходе человека на канал).
    Правее — список ников, подключённых к каналу. Знак "@" перед ником означает операторские привилегии — т.е. админ канала, "+" же ничего не даёт (у нас он является неким знаком отличия для людей, которые часто находятся на канале и чего-то мыслят в программировании, но на других каналах может быть не так).
    И, наконец, поле внизу для набора сообщений и команд.
     

    Чтобы отключиться от сервера, просто закройте вкладку.
    Чтобы зайти на другой канал, пропишите /j #имя-канала. Например, /j #cc.ru-server1.
     


    HexChat
    Десктопный клиент IRC, конфигурируемый, довольно удобный и пригодный для повседневного общения. Однако он уже требует несколько более сложной настройки.  

    Скачав и установив HexChat, после запуска мы увидим вот такое окошко:



    Для начала введите 3 варианта ника (они будут пробоваться использовать поочерёдно в случае, если предыдущий ник занят на сервере). Обычно просто ставят "_" в конец. В поле "User name" введите юзернейм — это общий для всех ник (при этом проверка на занятость юзернейма не производится).
    В списке ниже найдите "EsperNet". Нажмите на кнопку , а затем поставьте галку , чтобы быстрее находить эту сеть. После этого можно нажать на кнопку .
    Произойдёт подключение к серверу. Используйте команду /j #имя-канала, чтобы зайти на нужные каналы. Например, /j #cc.ru. Появится вот такой интерфейс:



    Сверху находится меню. Ниже переключалка каналов. Крестик позволяет закрыть вкладку (и выйти с канала).
    Ещё ниже строка заголовка, режимы каналов. Справа список ников на канале, слева — сам чат, ниже — поле ввода сообщений и команд. Можно кликнуть правой кнопкой мыши по вкладке канала и отметить "Autojoin", чтобы автоматически заходить на канал после подключения к серверу.
    На данный момент HexChat — рекомендуемый нами клиент для Windows и Mac.
     
     
     

    KVIrc
    Объективно: вроде всё по стандарту, использовать можно. Субъективно: куча ненужных кнопок, прокладок, интерфейсов, всё запутано и намешано, выглядит ужасно. Поэтому настоятельно рекомендую не использовать этот клиент. В любом случае, рассказать о нём стоит.  

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




    Нажмите на иконку , введите в поле под списком "EsperNet". Затем нажмите на , в то же поле введите "irc.esper.net". Нажмите "Connect Now" и затем "OK".
    Появится вот такое диалоговое окно:
     




    Введите в верхнее текстовое поле имя канала (например, "#cc.ru") и нажмите "Join", а потом "Close".
    Наконец, можно использовать главное окно:
     




    Сверху меню, ниже ещё всякие кнопки для действий типа подключения к новому серверу. Ниже топик, режимы канала, потом список ников, сам чат и поле ввода. Ниже статусная строка.
     
     
     

    WeeChat
    Очень продвинутый, невероятно удобный клиент для Linux. Запускается и работает в терминале, использует ncurses, поэтому даже иксы не требуются. Для Linux однозначно рекомендую, настроив weechat, как нужно, больше другие клиенты использовать не захочется.  

    После установки и запуска появляется вот такой непримечательный вид:



    Пишем /set irc.server_default.nicks ник,ник_,ник__, чтобы выставить ник. Затем /server add esper irc.esper.net/6697 -ssl.
    После этого можно прописать /connect esper для подключения к серверу. И дальше уже /join #имя-канала.



    Общаться можно уже и так, а за дополнительными фишками обращаться нужно к мануалу.
     

    Для телефонов тоже есть свои клиенты, но тут я ничего посоветовать не могу.
     
    Это были клиенты. Но просто поставив их, особо толка не будет. Поэтому сейчас будет несколько штук IRC, общие для всех клиентов.
     
    Помимо каналов на сервере можно напрямую общаться с каким-либо человеком. Для этого нужно прописать /msg <ник> <сообщение> (например, /msg fingercomp привет). В большинстве клиентов можно открыть вкладку (или буфер) для общения с человеком, как для каналов, с помощью команды /query <ник> (например, /query fingercomp).
     
    Есть ещё команда /me. Если использовать её, то вместо <ник> сообщение будет показано что-то вроде * ник сообщение. Так можно отправить сообщения от третьего лица (вроде "fingercomp написал гайд").
     
    Команда /notice — это та же отправка сообщения. Она немного отличается видом в клиентах, но всё равно видна всем на канале или собеседнику, в зависимости от того, кому направить сообщение. Смысл команды — предотвратить вызов ботом команд других ботов.
     
    Чтобы уйти с канала, можно использовать /part <сообщение выхода>. Сообщение будет показано другим людям в оповещении, например так:
    Можно вообще от всего сервера отключиться с сообщением, как выше. Используйте команду /quit <сообщение выхода>.
     
    Авторизация на EsperNet.
    Зачем нужна авторизация? Прежде всего, чтобы автоматически получать какие-либо права. Например, на канале #cc.ru-server1 (туда транслируется чат с сервера) мы используем это, чтобы автоматически выдавать право отправлять сообщения на сервер.
     
    Чтобы зарегистрироваться, нужно зайти с нужного ника и прописать /msg nickserv register <пароль> <email>, например /msg nickserv register zxcvbnM1 fingercomp@example.com. На ящик придёт сообщение от Esper, в котором будет команда для подтверждения регистрации. Её нужно скопировать и выполнить (то есть написать в строку ввода).
    Чтобы затем залогиниться, используйте команду /msg nickserv identify <пароль>.
     
    А теперь последуют вещи, которые есть только на нашем канале #cc.ru.
    У нас есть правила, которые желательно соблюдать. Ссылочка на них в топике: https://git.io/vwLXq
    Основной бот на канале — brote. У него есть множество команд: от погоды до опросников. Список команд можно получить с помощью команды .help. Брот также обрабатывает команды в ЛС.
    В топике после даты я помещаю всякие интересные события, ссылки и прочее. Так что иногда лучше смотреть на топик.
    Ведётся статистика всего канала — анализируются логи с середины ноября, хотя канал существовал примерно полгода до этого. Вот ссылка: https://stats.fomalhaut.me/. Можно поизучать — достаточно интересная штука.
    Темы обсуждений могут быть абсолютно разными — от размеров очередей в больницах до новых фич в языке Rust. Но в любом случае я постараюсь ответить на все вопросы по программированию на Lua, отправленные на канал. Даже в середине обсуждения — тогда, может, не сразу, но обязательно отвечу.
     
    Кроме того, у нас есть канал #cc.ru-server1. Сюда бот пишет сообщения с чата сервера, сообщения о смерти игроков, а также пишет текущий онлайн в топик. Поэтому для модерирования очень удобная штука.
    Чтобы иметь возможность отправлять сообщения из канала на сервер, нужно иметь войс — знак "+", который выдаётся персонально зарегистрированным людям. Я использую несколько критериев для оценки, например активность и адекватность игрока. За любое нарушение правил сервера через IRC следует вечная блокировка возможности отправить сообщения.
    Но и без войса можно просто сидеть и читать чат.
     
    В целом, это всё, что я хотел сюда написать. Ждём на наших каналах — подключайтесь, у нас есть печеньки.
  2. Fingercomp
    Многие игроки здесь видели или хотя бы слышали про огромный дронодом, который построил @Asior в былые времена на сервере RoboCraft. С тем чтобы прояснить происхождение этой хаты и оставить о ней заметку в этом клубе, специально для «Новостей подполья» @Fingercomp обратился к создателю постройки и попросил рассказать про неё. Редакция представляет обработанную версию истории.
     
    История начинается в начале мая 2016 года, когда запустился сервер RoboCraft, на который сразу же хлынули толпы игроков, хотевшие «поскорее стать топовыми игроками, обладателями гор ресурсов и, конечно же, новых идей и программ». Туда попал и герой нашего рассказа. Развитие было довольно сложным. Поначалу он «хотел, как обычно, отстроить бункер и спокойно, потихоньку наращивать силы», но этому воспрепятствовал случай: система автоматического расселения игроков закинула Asior невесть куда — в середину заражённого биома. Очевидно, что герой этому не обрадовался. Ему потому пришлось бегать в поисках нового места.
     
     
    Конечно, Asior таки организовал себе временное убежище и начал стремительное развитие в игре. Но в чате игроки часто оставляли ссылочки на скриншоты своих невероятно красивых палат с невероятно крутых ракурсов.
     
     
    Он перерыл огромное число чертежей домов, замков, статуй — и решил построить дрона. Дрона из OpenComputers. Ведь сервер специально разрабатывался для этого мода. Asior зашёл в сингл и долго, упорно воздвигал новые варианты постройки и безжалостно крушил старые. Наконец, он определился с тем, как именно должно будет выглядеть его будущее жилище. Оставалось лишь воспроизвести это всё на сервере. Но здесь и возникла основная проблема: как добыть такое огромное количество ресурсов для строительства? Разрешена она была путём не самым чистым:
     
     
    Впрочем, и того, что он раздобыл, сполна хватило на постройку основного корпуса дрона. Это потребовало огромного числа строительных лесов и невероятных акробатических способностей и дополнительно осложнялось тем фактом, что полученные вечные блоки не перемещались из хотбара. Но стиснув зубы и получая подкормку от щедрых игроков Asior таки построил дрона.
     

     
     
    Потому пришлось придумать, как расширить жилище. Некоторые предлагали соорудить какое-нибудь здание, к которому был бы «привязан» дрон, но, увы, это не вписывалось в местность.
     
     
    Далее настала очередь внутренней отделки: ставились перегородки, размещалось оборудование. А монументальное сооружение, памятник роботу и дрону, стал пользовался большой популярностью, чему создатель не противился: «я был не против, чтобы все желающие посмотрели, как я живу, уточнили какие-то вопросы или помогли чем-нибудь».
     
    С тех пор сервер RoboCraft давно закрыт, но память о роботе и дроне жива до сих пор. Редакция присоединяется к пожеланию героя остроить то, что поражало бы воображение и отпечаталось в приятных воспоминаниях десятков игроков.
     
    И мы всё так же мы призываем вас оформить подписку на «Новости подполья». Годноты здесь много было, есть — а то ли ещё будет.
  3. Fingercomp
    Первым делом, сохраняйте панику. Так интереснее.
    У нас есть группа в ВК, которая, в отличие от параллельных — тупиковых веток эволюции — жива и даёт продукт в виде постов. Очень интересных.
    Не любите ВК? Я тоже. Имеем мы канал в IRC: зайти можно даже с телнета. Но лучше с помощью какого-то клиента: HexChat, WeeChat, Quassel.
    Контактные данные для них:
    Сервер: irc.esper.net Порт: 6697 TLSv1.2 Канал: #cc.ru Впрочем, присутствует и веб-клиент для обитателей двумерного денежно-временного мира.
    Надо сказать, у нас даже дискорд-клуб где-то был.
    Однако не только флуждением занимается Хэш cc.ru. Мы завели организации вот тут:
    На GitHub. На GitLab. В Trello. Под кроватью. А ещё подпольные мудрости тщательно и бережно схороняются на свалку нашего цитатника, так что башорг вам больше не нужен.
    Не забудьте, по пути куда-нибудь находясь, записаться в читателей этого элитного клуба. Потому что здесь мы будем писать. Что-то.
    Отлично. Наши цепкие объятия уже ждут-поджидают вас.

  4. Fingercomp

    Ethel

    Автор: Fingercomp,

    Мегапроекты, мегаобсуждения, огромная мотивация... Ну, конец истории вы уже поняли.
    В этом посте посетим могилу Ethel — моей игры, которой было суждено не быть.
    Начать надо с понятий. Ethel — это платформер. Естественно, 2D и скроллинговый.

    На скрине выше:
    Красные — это враги. При контакте с ними персонаж дохнет. Жёлтый прямоугольник — это персонаж. Голубенький квадратик — это точка спаун поинта. Серенький — это каменья. По ним можно ходить. А остальное — небо.
    Затея сделать игру приняла форму действия 30 мая 2017 года и (моими усилиями) стремительно нарастала фичами.
    Из реализованных фич:
    Самые тупейшие враги. Они идут в одну сторону — и в другую при коллизии о стену или своего товарища. Передвижение базовое. Можно прыгать и ходить. Дебаг-экран, отключаемый по F1. Загрузка всех ресурсов из файлов. Карта выше была загружена из файла с данными карты. И спрайты, и тайлы. Физика какая-то. Примитивная, конечно. Как-то коллизии умудряется определять и ускорение рассчитывать. Главное меню. Куда ж без него? 20 FPS на опенкомпе. Вроде бы. Хотя это, скорее, из-за того, что нереализованного дофига. 2D и скроллинг. Для адекватности в скорости использовалась либа doubleBuffering. Все компоненты соединяются посредством либы событий libaevent, которую я тогда достаточно любил, потому что довольно удобная штука она есть.
    Но тут параллельно мы поднимали свой сервачок MC, для которого, очевидно, нужен был свой сайт. Сисайт. Иначе несолидно. А так как 2 любительских проекта параллельно одновременно я вести не умею, выжить должен был один из них за счёт второго. И так получилось, что вторым стал ethel.
    Уже через 3 недели после начала энтузиазм куда-то иссяк — и 27 июня был запушен коммит, который оказался последним. С тех пор обновлений не было.
    Какую мораль я вытащил из этого потонувшего проекта?
    Я не умею делать нормальные архитектуры. Но это я и так знал. То же для физики. Казалось бы, что там сложного-то: радиус-вектор, вектор скорости и вектор ускорения. Но вот я и в них как-то запутался. Там самым запарным было из этих трёх векторов сообразить нормальный интерфейс программный. Во-первых, действующих на спрайты сил было несколько. Как минимум, там есть гравитация. В теории могли бы быть всякие пружинки. Во-вторых, движение врагов, на самом деле, задаваться должно не ускорением, а простой скоростью. Я там как-то накостылял, и оно даже работало, но удовольствия от этого я не получил. И коллизии. Просто так на них прочекать тоже не столь и сложно, но запары все возникали при использовании результата проверки в методах, задающих поведение спрайтов. Костыли — это плохо. Ну, то есть, всё как обычно.
    Посмотреть на останки можно здесь. Можно даже попробовать запустить это — но сначала сделайте git checkout HEAD^^ (в мастере там какие-то блохи). А, ещё надо будет откуда-то достать либу буферную. И lua-objects скопировать в /usr/lib/lua-objects/lua_objects.lua.
    Ethel — это лишь один из множества руин некогда поражавших воображение своей амбициозностью проектов. В этом элитном клубе мы намереваемся продолжить копаться в исторической пыли и вытаскивать на свет из-под неё и другие павшие проекты.
    Поэтому ненастойчиво убеждаем вас подписаться на сей чудесный блог, тыкнув на соответствующую кнопку — ту, что повыше. А можно нажать и на обе. 🍪
  5. Fingercomp
    В звуковой карточке есть дохрена функционала - поэтому она и крутая. В этой части попытаюсь объяснить достаточно сложные штуки, которые используют большие дяди.
    Надеюсь, что вы прочитали и поняли две предыдущие части цикла - это будет довольно важно для последующего повествования.
    [Раньше тут был полноценный пост с эмбедом, но после переезда оно всё, соответственно, сломалось. Текст доступен здесь.]
  6. Fingercomp

    Автозапуск программ

    Автор: Fingercomp,

    Если до версии 1.6 все использовали файл /autorun.lua и были довольны, то теперь ситуация несколько изменилась. Поэтому я опишу все варианты автозапуска программ в этой небольшой заметке.
     
    С версии OpenOS 1.6 файл autorun.lua больше не запускается на rootfs (то есть на файловой системе работающей операционной системы). Вот все пять способов, которые можно использовать для автозапуска программ.
    Модифицировать /init.lua.
    Это самый плохой и ужасный вариант из всех. Во-первых, программа будет запускаться до запуска шелла и инициализации библиотек, поэтому возможны краши системы. Во-вторых, если сделать ошибку в файле, то придётся переустанавливать этот файл, что не очень удобно.
    Добавить скрипт в /boot.
    Это не такой плохой вариант, но здесь также возможны ошибки при использовании стандартных библиотек, так как бутскрипты запускаются не в самом конце загрузки.
    Модифицировать /etc/profile.
    Это файл, каждая строка которого последовательно исполнаяется при запуске программ. Проблема в том, что при переустановке системы этот файл будет перезаписываться. Поэтому не вариант.
    Модифицировать /home/.shrc.
    Это самый оптимальный вариант. Но программа будет запускаться при каждом запуске шелла. Если прописать exit в шелле, то программа запустится ещё раз. Если для графических всяких программ это самый лучший вариант, то для одноразовых демонов, которые регистрируют листнеры на ивенты и выходят, вариант не очень хороший, так как тогда листнеры зарегистрируются дважды.
    Использовать систему rc.
    Подробно о ней рассказывал @LeshaInc: http://computercraft.ru/topic/1679-rc-chto-za-zver-takoi/
    Это система, которая позволяет писать своих "демонов" — программ, исполняемых в фоне — и контролировать их из шелла с помощью команд. Графические утилиты так запускать проблематично, потому что возможны всякие артефакты отображения.

    Поэтому используйте варианты 4 или 5 в зависимости от программы, которую требуется запустить.
  7. Fingercomp
    Он вышел раньше, чем я предполагал — ниже список нового.
    Сила овец и оцелотов в их пушистости. Теперь пушистость можно приложить к делу и питать компы — с помощью ковровых конденсаторов. От обычных конденсаторов они толком не отличаются, но могут генерировать энергию, если по ним ходят минимум 2 пушистых животных: овцы или оцелоты, которые генерируют больше энергии. Все новые процессоры, которые будут скрафчены, будут с Lua 5.3 по умолчанию. Сменить можно так же — шифт-пкм. К беспроводной карточке, которую мы все знали, теперь добавили урезанную версию T1, тоже беспроводную. Она может открывать только 1 порт и стрелять сигналом на 16 блоков, а не 400. Креативная компонентная шина (штука, пихабельная в серверы), которая добавляет 1024 компонента. Логичное дополнение. Роботов можно подключать к компьютерам как компоненты. И менять имя роботов: то, что раньше делалось в наковальне, теперь можно через setName и getName. Робот должен быть выключен, чтобы функции работали. Починены всякие проблемки с рендерингом всяких символов. Блоки-инвентари иногда не сохраняли содержимое при сохранении мира. Дроны с чанклодырями не всегда грузили чанки. Пофикшена интеграция с AE2. computer.addUser неправильно отдавал ошибку как-то. Хитбоксы у кабелей теперь обтягивают их форму. Раньше кабели-пересечения были с хитбоксом на весь блок. Апгрейд крафта не всегда крафтил, когда должен был. Апгрейд крафта крафтил один предмет и ломал рецепт — для всех, в том числе игроков. Весело. Датчик движения как-то коряво работал. Пофикшена работа роботов с предметами-инвентарями вроде жидкостных ячеек IC2. Устранена возможная утечка памяти в сетевом коде. В MC 1.10+: пофикшена getMetadata у дебаг-карты. В MC 1.10+: добавлена getBlockstate для дебаг-карты. В MC 1.12: нельзя было заменить EEPROM дрону. В MC 1.7.10: добавлены getAllStacks и inventoryName для транспозеров с инвентарных апгрейдов. Обновлён французский перевод. В OpenOS: Обновлён install.lua, чтобы работал более предсказуемо. uuid.lua возвращает правильные UUID 4 версии, как в RFC написано. Фиксы всякие поддержки vt100. Утечка памяти при загрузке процессов (есть и такая, даже в Луа). Более конкретные комбинации клавиш: Ctrl+Alt+Delete не будет считаться за Ctrl+Delete, например.



    Вайтлиста измерений для чанклоадера... ну, их пока нет.
     
    Скачать.
  8. Fingercomp

    OpenComputers 1.7.0

    Автор: Fingercomp,

    Окей, новую версию ждать не пришлось год в этот раз. 1.7.0! В наличии много всяких улучшений в OpenOS, баги фиксятся, а не создаются, но каких-либо особых изменений в самом моде нет.
     
    Начнём с новых штучек в моде.
    Версия для 1.11.2 и 1.12.1. Поддержка Forge Energy, интеграция с CC, Project:R3D, WR-CBE, IC2, Hwyla, AE2. Датчик движений можно пихать свободно как апгрейд для роботов. Китайский перевод. Пофикшены фризы монитора у роботов. С 1.12 юзаются ванильные железные наггетсы. Рефакторинг API и кода в целом. Методы getAllStacks и getInventoryName для контроллера инвентаря и транспозера. Наконец-то! Ивент drop посылается и при простом клике (раньше только при таскании). Улучшенная поддержка многожидкостных контейнеров. Вернее, многоконтейнерных блоков. Как-то так. Отсутствующие глифы стали шириною в 1 символ. Бесконечный цикл в мануале. Отличная фича была. Правда, это только со сломанными страницами проявлялось. Роботы не все инструменты адекватно использовали. Теперь все, наверное. Обломали способ загрузить процессор на хостовом компе из игры.

    Ну, мне обманывать смысла не было, да: в осном фиксы всякие. Зато в OpenOS тонны всякого.
    Новая библиотека в OpenOS: thread. Туториал попробую когда-нибудь сообразить. Рефакторинг, чистка и прочие такого рода мероприятия. Фиксы всяких прог и либ (ls, lib/event, lib/keyboard). Вряд ли это интересно. loadfile теперь работает с относительными путями. tty вынесен из lib/term; поддержка кодов vt100. Фиксы окружений в load, bin/lua и шелле. Прога pastebin теперь работает через https. Улучшение производительности всего и вся. Здесь же и либа сериализации. ls использует цвета из переменной окружения LS_COLORS, которая теперь содержит коды vt100. @LeshaInc хотел немного славы, поэтому отдельно упоминаю его — он посоветовал. Лэшань же написал bin/tree, которая включается в стандартную поставку. И, конечно же. Запускается быстрее! Жрёт меньше памяти (140 кБ)! Крутой номер версии!

    Поэтому обновляйтесь. Тем более, что этот релиз имеет наибольшее число поддерживаемых версий. 1.7.10, 1.8.9, 1.9.4, 1.10.2, 1.11.2, 1.12.1. Выбирайте по вкусу на странице релиза.
     
    P. S. Оказывается, я давно не писал сюда что-либо. Тогда тизерну в качестве компенсации. Готовлю потихоньку небольшой кукбук с рецептами по OC, OpenOS и Lua. Думаю скоро выложить. Посмотрим, как оно пойдёт.
  9. Fingercomp

    Обновление OpenComputers 1.7.1

    Автор: Fingercomp,

    Багофиксы, в основном только они. Вот из того, что добавилось:
    У планшетов можно получать полноценное направление взгляда игрока. Количество максимальных частей пакета добавлено в информацию об устройстве (та, что computer.getDeviceInfo(). [1.10.2] Интеграция с ExtraCells и Mekanism. [1.12.2] Интеграция с ComputerCraft.

    Остальное:
    Изменили рецепт алмазных кусков по умолчанию. Пофиксили область видимости датчика движения. Планшетам разрешили отрубать экран. Дроны адекватно заставили воспринимать чанклодырное улучшение. Item conduits из EnderIO чего-то из микроконтроллеров доставали ненужного. Несовместимость с IC2 Classic устранена. В IRC-клиенте с дискеты пофиксили CTCP. [1.11.2] Какая-то бага с добавлением предметов в улучшение-БД. [1.11.2] И ещё бага с доступом к компонентам вроде дисковода в планшетах.

    Обновления в OpenOS:
    Нет необходимости теперь, в кои-то веки, писать = в начале строк в интерпретаторе Lua. Оно автоматически возвращает. Можно в error пихать таблицы, и крашиться не должно. Наконец-то разрешили монтировать системы файловые в существующие директории. Ещё можно примонтировать директорию в другое место. Если вы напишете одну команду и 10 раз другую, то в истории последняя будет только один раз. Не придётся 10 раз тыкать "вверх", чтобы первую команду получить. Фиксили проблемы с загрузкой OpenOS на медленных хостах. Я думаю, это ошибка TLWY, которая при старте кидалась. .shrc может принимать ввод. Пофиксили поиск названия клавиши по коду в либе keyboard. Фикс event.cancel и event.ignore какой-то. Интерпретатор теперь здраво воспринимает ошибки переполнения памяти в сериализаторе. Какой-то TLWY в /bin/tree.lua. Улучшения в vt100 всякие. Код стал ещё уродливее ради уменьшения потребления памяти. Вот такие улучшения.

    Вот как-то так. Отсюда качабельно.
  10. Fingercomp

    OpenOS. Потоки

    Автор: Fingercomp,

    Потоки — очень полезные штуки, позволяющие исполнять несколько кусков кода. Раньше для их использования приходилось скачивать отдельную библиотеку, работающую через костыли. Начиная с OpenOS 1.6.4, они есть в стандартной поставке ОС — в модуле thread. Давайте посмотрим, из чего она состоит — и в чём её преимущество перед любыми другим библиотеками.
     
    Начнём с версий. OpenOS 1.6.4 — версия, включённая в OpenComputers 1.7.0. Если не хотите возиться с обновлением системы вручную, требуется иметь версию выше или равную 1.7.0.
     
    Сразу обращаю внимание на самую важную вещь: потоки не могут исполняться одновременно. В один момент времени только один поток может работать.
     
    В чём тогда красота тредов?
     
    Они автономны, то есть:
    Начинают исполнение сразу же после создания. Передают исполнение в другие потоки в местах, указанных использователем, — при том или ином вызове computer.pullSignal (os.sleep, event.pull и т. д.). Автоматически продолжают своё исполнение без необходимости самостоятельно их стартовать. Потоки можно убить и приостановить.
    Они неблокирующие:
    Вызов computer.pullSignal не блокирует исполнение других потоков.
    Они отцепляемые:
    Процесс, в котором был создан поток, называется родительским. При завершении родительского процесса все потоки останавливаются. Поток может отсоединиться от родительского процесса и работать полностью автономно — например, как слушатели событий. Поток может сменить родителя на другого. Поток сам является процессом и потому может создавать дочерние потоки. Работающий поток не даёт завершиться своему родителю.
    Они независимы при обработке событий:
    Потоки не наследуют и не передают дочерним свой набор слушателей событий. Все слушатели событий и таймеры принадлежат только конкретному потоку. Как следствие, поток не может изменять их набор в другом. Слушатели и таймеры автоматически удаляются при завершении потока, даже если завершение вызвано ошибкой. Приостановленные потоки игнорирует события. Если несколько потоков вызвали event.pull на одно и то же событие, они оба его получат.
    Этот набор фич в таком объёме присутствует только в этой библиотеке, и ни одна другая и не даёт столько простоты в работе с ними.
     
    Пожалуй, приступим к использованию. Потоки создаются функцией thread.create: первым аргументом передаётся функция, дальше идут аргументы к ней.
    local thread = require("thread") local t = thread.create(function(a, b) print("В потоке получены аргументы:", a, b) end, 21, 42)
    Функция возвращает объект потока. Его же может получить сам поток вызовом thread.current() — однако если вызвана не в потоке, то возвращает nil. На всякий случай, основной процесс не является потоком.
     
    Объект потока позволяет чудить различные вещи с потоком.
     
    t:suspend() приостанавливает поток. Как уже сказано, такой поток не будет получать события и обрабатывать тики таймера. Забавно, что если приостановить поток, когда он ждёт события, то неизвестно, что он получит после его возобновления.
     
    t:resume() возобновляет работу ранее приостановленного потока. Так как созданные потоки сразу начинают работу, то обычно этот метод вызывать не придётся.
     
    t:kill() убивает поток, то есть завершает его, удаляя всех слушателей и таймеры. Возобновить работу потока после того, как он убит, нельзя.
     
    t:status() возвращает строку со статусом потока:
    "running" — поток работает или блокирован другим. Такой поток не даёт завершиться своему родителю. "suspended" — поток приостановлен. Его дочерние потоки также будут приостановлены. Когда родительский процесс завершается, такой поток автоматически убивается. "dead" — поток мёртв.  
    t:attach() позволяет сменить родителя у потока. Без аргумента поток будет присоединён к текущему процессу. Переданное как аргумент число позволяет указать, к кому присоединить: 0 — текущий процесс, 1 — родитель текущего и т. д.
     
    t:detach() отцепляет поток от родителя. Такой поток будет работать до его остановки или перезагрузки компьютера.
     
    t:join() останавливает процесс, в котором была вызвана это функция, до завершения потока t.
    local thread = require("thread") local t = thread.create(function() os.sleep(10) end) t:join() -- остановится на 10 секунд
    Можно передать первым аргументом этой функции число, которое будет служит таймаутом (в секундах). Тогда, если не успеет завершиться поток за это время, join завершится досрочно.
     
    t:join ждёт только одного потока. Для групп потоков есть функции thread.waitForAny и thread.waitForAll — обратите внимание, что это функции библиотеки, а не методы объекта потока.
     
    Обе функции первым аргументом требуют таблицу с потоками, а вторым опционально можно задать таймаут.
     
    thread.waitForAll ждёт, пока завершатся все потоки из списка.
    local thread = require("thread") local t1 = thread.create(function() os.sleep(10) end) local t2 = thread.create(function() os.sleep(15) end) thread.waitForAll({t1, t2}) print("Это сообщение будет написано через 15 секунд")   thread.waitForAny ждёт, пока завершится хотя бы один поток из списка.
    local thread = require("thread") local t1 = thread.create(function() os.sleep(10) end) local t2 = thread.create(function() os.sleep(15) end) thread.waitForAny({t1, t2}) print("Это сообщение будет написано через 10 секунд")
    Что будет, если поток бросает ошибку? При ошибке в потоке она не будет проброшена в родительский процесс. Как и со слушателями, она будет записана в файл /tmp/event.log, но родитель не сможет узнать причину ошибки — и, вообще, успешно ли завершился поток.
    local thread = require("thread") local t = thread.create(function() os.sleep(3) error("test") end) print(t:status()) --> running t:join() print(t:status()) --> dead
    Кроме того, событие жёстокого прерывания (Ctrl+Alt+C) не передаётся всем процессам — только одному; причём неизвестно, какому именно: родителю или одному из его потоков. Если вы используете потоки, первым делом сделайте один, который будет ждать события interrupted и подчищать ресурсы.
    local thread = require("thread") local cleanupThread = thread.create(function() event.pull("interrupted") print("Принял ^C, чищу всякие ресурсы") end) local mainThread = thread.create(function() while true do local input = io.read() if input == "exit" then break end end end) thread.waitForAny({cleanupThread, mainThread}) os.exit(0) Обратите внимание, что в конце программы стоит os.exit. Я уже упоминал не раз, что родительский процесс, достигнув конца программы, не завершится до тех пор, пока работает хотя бы один из его дочерних потоков. Вызов os.exit() позволяет выйти из программы, закрыв все дочерние потоки. Что, безусловно, достаточно удобно.

    Есть ещё один момент. Допустим, данная программа запускается в роботе:
    local robot = require("robot") local thread = require("thread") local moveThread = thread.create(function() while true do robot.forward() end end) local inputThread = thread.create(function() while true do local input = io.read() if input == "exit" then break end end end) thread.waitForAny({inputThread, moveThread}) os.exit(0) Если вы запустите эту программу, то должны заметить, что вы ничего не сможете написать в роботе, хотя работает io.read. Дело в том, что функция robot.forward вызывает метод компонента, который блокирует исполнение компьютера. Пока робот двигается, на компьютере не может выполняться ни одна команда.
     
    Чтобы хоть что-то можно было вставить в строку, то поставьте после robot.forward какой-нибудь os.sleep(0) — он позволит соседнему потоку принять и обработать события. Тем не менее, строка ввода всё равно будет работать с тормозами.
     
    В подобном случае задумайтесь над тем, чтобы использовать вместо строки ввода иное средство коммуникации: редстоун, сеть, интернет-сокет.
     
    Несмотря на всё, библиотека действительно облегчает работу с потоками в OpenOS. Кроме того, очень удобно поместить все слушатели событий в один поток, чтобы они все автоматически были удалены после убийства потока.
    local event = require("event") thread = require("thread") local mainThread = thread.create(function() event.listen("key_down", function(evt, addr, key, code, user) print("A key has been pressed!") end) while true do print("do something") os.sleep(0.5) end end) -- событие interrupted не ловится обработчиками local intThread = thread.create(function() event.pull("interrupted") end) thread.waitForAny({mainThread, intThread}) os.exit(0) Не нужно функции сохранять в переменные и помнить, что нужно ставить event.ignore в конце программы; не требуется ребутать компьютер, если программа завершилась с ошибкой, а до отключения слушателей дело не дошло.
     
    В общем, красота.
  11. Fingercomp

    OC Cookbook

    Автор: Fingercomp,

    Решил больше не ждать с этим. Где-то пару месяцев назад решил начать пилить одну штуку — кукбук, или книгу "рецептов". Изначально задумывалось как сборник просто именно рецептов как в кулинарной книге: тонна кода и немного объяснений; получилось наоборот, естественно, — до того, что в некоторых "рецептах" кода нет, — ну это, наверное, потому что я не умею толком через код объяснять.
     
    В любом случае, теперь это сборник полезных туториалов по практическому применению.
     
    Он разделён на 3 раздела.
    Lua — статьи, непосредственно затрагивающие код и написание программ. Сниппеты кода, гайды по функциям. OpenOS — статьи абстракции уровня выше немного. Здесь всё об использовании шелла, стандартных программ и прочих фичах дефолтной оси OC. OC — статьи, не относящиеся непосредственно к разработке программ или фичам OpenOS. Наверное, это in-world штуки всякие, по большей части. Например, инфа о том, как собрать идеальный хрякокоптер или правильно тестировать нанытов. Потом могут быть статьи о всяких блоках, да и прочих фичах самого мода.

    Когда я сейчас пишу эту запись, в кукбуке есть уже 13 рецептов.
     
    Ссылочка на книжку. Заходите, почитайте.
     
    Есть слухи, что на гитбуксе можно отсылать пулл реквесты... Они здесь называются чендж-реквестами, но разницы никакой. Если есть идея для ещё одного рецепта и желание написать статью — присывайте эти реквесты; если желания нет — можно написать идею в комментариях. Я пока не особо понимаю, чего ещё бы добавить в кукбук.
  12. Fingercomp

    OpenComputers 1.6.0 Release

    Автор: Fingercomp,

    Добавлено Версия дисковода гибких дисков (дискет, если что) для серверов. Возможность взаимодействовать с некоторыми хранилищами предметов с помощью контроллера инвентаря (не особо понял, что тут нового. Видимо, новые инвентари или черех адаптер). Поддержка энергии RotaryCraft. Возможность задать границы вывода (я про viewport, да) на GPU, так что теперь можно химичить с производительностью всякими нестандартными путями. Кабели запоминают цвета, в которых их красили, при срубании. Можно их теперь ещё и в сетке крафта красить. Интеграция с IC2 на 1.8.9. Можно переключаться между всеми лут-дискетами, перекрафчивая их с ключом. computer.getDeviceInfo() — метод, который возвращает базовую инфу об устройствах (от планок памяти до всяких шифраторов CX). computer.getProgramLocations() — функция, которая возвращает, на каких лут-дискетах какие лут-программы лежат. Торговый апгрейд для роботов. Торговля с жителями, об этом я уже писал. Можно задать свои HTTP-хедеры вместе с, ммм, HTTP-запросом. debug.playSoundAt, которая, как ни странно, играет звуки. Возможность задать используемый CPU из AE2 при запросе на автокрафт. Интеграция с ThaumicEnergistics. Цветные дронотапки (hover boots). Индикатор сетевой активности на серверах. Перевод на бразильский язык.
    [*]Изменено
    Мажорнейшее и вообще самое основное — серверные стойки. Я о них писал, да. Удалённые терминалы (Remote Terminals) подключаться должны к серверу удалённых терминалов (Remote Terminal Servers), штучке для серверной стойки. Компонент дисководиков. Можно теперь программно выкидывать диски из дисководов. Нёрф геолайзера — учитывается теперь дистанция до блока, а не колонны. Зато область сканирования можно задавать не только в виде колонны, а в виде кубоидов объёмом до 64 блоков. Упрощены рецепты. Новый шрифт поставлен. Можно сменить ещё с помощью ресурспаков. Один солидный книжный том изменений в OpenOS.
    [*]Починено
    Зависания при крафте, возвращающем тот же предмет, что и данный на входе. Всякие проблемы с рецептами режима грега. Обработка userdata в LuaJ. Конвертация энергии некоторых модов. Проблемы производительности из-за слишком усердной компресси данных, передаваемых клиенту. Тоже проблемы производительности, связанные с отправкой пакетов с дескрипторами компьютеров на клиенты. Обновление LuaJ с фиксами багов. Интеграция с Mystcarft. Напомню, категория "починено". Интеграция с ключом BuildCraft. Роботы могли черпать блоки текучих жидкостей, не источников. Генератор поедал нещадно предметы, если они не были вовремя оттуда вынуты. Контейнеры апгрейдов никогда не выпадали из планшетов при разборке. Сломанный код сохранения информации о блоках OC в версиях MC выше 1.8. Микроконтроллеры ловили только сигналы с сетевой карты.



    Вот это всё и есть OC 1.6. Вот чем он так крут по сравнению с прошлой версией. Ченджлог на страницу!
     
    Со времени первого коммита OC 1.6 до текущего момента прошло 465 дней. Это год и 100 дней. И ведь всё это время я ошибочно думал, что вот-вот, немного подождать, и будет 1.6.0, пару изменений ещё только.
     
    Здесь оригинал списка гигантского и ссылки на скачивание.
    У меня есть несколько записей, посвящённых обновлениям в этой версии. Если ещё их не читали, рекомендую ознакомиться.
  13. Fingercomp
    Продолжаю рассказывать про Computronics и, в частности, про офигенную звуковую карточку из этого мода. На очереди модуляция: частотная и амплитудная. Помимо этого восполняю долг по основам.
     
    Юзать будем мою прогу synth, которую я недавно зарелизил. Она здесь невероятно поможет.
     
    Звуковая волна
    Вы же знаете, как выглядит звуковая волна?
     




     

    Вот, например, синусоида. Как видно, здесь есть некоторый фрагмент, который повторяется несколько раз. Частота показывает, сколько раз в секунду этот фрагмент повторяется, и измеряется в герцах (Гц или Hz). Чем выше частота, тем больше волна "сжата", скажем так, с боков. Вот как выглядят три синусоиды с разными частотами: 110 Гц, 220 Гц, 440 Гц - на одинаковом масштабе.
     




     

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




     

    При максимальной громкости у простой синусоиды пиковые значения будут в точках +1 и -1. Они плавно сменяются. Прикольно, да.
     
    Синусоиды - это офигенные штуки, но на них клин светом не сошёлся. Из основных типов волн, помимо синусоид, есть меандр, треугольная волна и пилообразная. Они в таком же порядке изображены на рисунках ниже.
     





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


     

    На самом деле, их можно представить в виде набора бесконечного числа синусоид, о чём когда-то поведал Фурье, но мы с этим заморачиваться не будем: раскладывать на синусоиды в звуковой карте не принято. Поведали об этом для красного словца - и то хорошо.
     
    Теперь, когда рассказал про основы, можно переходить к более весёлым и сложным вещам. То бишь к модуляции.
     
    Модуляция
    Модуляция - это изменение одного сигнала (несущего) другим (модулятором). Изменять можно по-разному - мы будем говорить об амплитудной модуляции и частотной модуляции.
    С модуляцией у нас появляется уникальнейший шанс получить офигенные и красивые звуки, поэтому не будем ждать и сразу перепрыгнем к мясу.
     
    Амплитудная модуляция
    Как я сказал, для модуляции нужны два сигнала: несущий и сам модулятор. Поэтому здесь и далее я привожу на рисунках сразу три графика: несущий сигнал, модулирующий сигнал и результат модуляции.
    Например, выставим две синусоиды с частотой 440 Гц.
     




     

    Итак, амплитудная модуляция - это умножение одного сигнала на другой.
     


    A(t) = C(t) × M(t),


     

    где t - время, C - функция, возвращающая значение несущей волны на моменте времени t, M - то же, но для модулятора.
    Однако не всё так просто. Перед умножением к значениям с модулятора прибавляется единица. Получается, что самая верхняя точка будет на +2, а самая нижняя - на 0. Иными словами, волна перенесена вверх.
     
    На низких частотах - до 20-30 Гц, откуда начинается граница слышимого человеком звука, - графики будут выглядеть как-то так, медленно увеличивая амплитуду от 0 до 4 и обратно.
     




     

    И звучать оно будет как увеличение и уменьшение громкости (количество таких увеличений и уменьшений равно частоте модулятора).
     
    Однако когда частота модулятора становится больше, наблюдаем вот такую картину (частота модулятора равна здесь 330 Гц).
     




     

    Если прислушаться, то станет заметно, что одновременно будто бы проигрываются три звуковых волны. Одна волна имеет такую же амплитуду и частоту, как и несущая. Две другие частоты, задающие боковую полосу частот (диапазон частот, сконцентрированных рядом с какой-либо), находятся так:
     


    f1 = |c - m|,



    f2 = c + m,


     

    где c - частота несущей волны, а m - частота модулятора. Возникающие звуковые волны около этих частот вдвое тише, чем несущая.
     
    В звуковой карте можно поставить амплитудный модулятор следующим образом: sound.setAM(carrierChan: number, modulatorChan: number).
     
    Амплитудная модуляция - забавная вещь, и в то же время тут очень трудно подобрать что-то интересное и красивое. Поэтому переходим к частотной модуляции - там веселья дофига.
     
    Частотная модуляция
    В частотной модуляции модулятор изменяет частоту несущей волны. Как ни странно.
    Почему частотная модуляция уделывает амплитудную? Здесь может быть гораздо больше боковых частот. И потому звучать оно может гораздо круче.
     
    При когда значение на модуляторе увеличивается, повышается и частота на несущей волне.
     
    Звуковая карта поддерживает индекс модуляции. Он задаёт максимальное изменение частоты несущей волны. При индексе, равном 100, частота несущей волны может меняться на 100 Гц вверх и на 100 Гц вниз. Если индекс равен 1000, то частота меняться может на 1000 Гц вверх и на 1000 Гц вниз. Ну и так далее.
    Иными словами, индекс задаёт силу модуляции.
     
    Если частота модулятора будет очень низкой (например, 4 Гц), то получим что-то вроде сирены.
     





    c = 440 Гц; m = 4 Гц; i = 200


     

    С повышением частоты получим вибрирующий звук. И потом услышим дополнительные частоты.
     





    c = 220 Гц; m = 880 Гц; i = 660


     

    Как видно, получившаяся волна получилась довольно сложной.
     
    Установить модулятор в звуковой карте можно с помощью функции sound.setFM(carrierChan: number, modulatorChan: number, index: number).
     
    И не забывайте про ADSR-огибающую: из однообразного тона можно получить довольно интересный звук. Как работает эта штука, я рассказывал.
     

     
    На этом всё. Из всех фич остался неразобранным лишь шум LFSR, но там штука очень и очень странная и непонятная.
     
    Наверняка всё равно остались некоторые вопросы по поводу модуляции. Поэтому за дополнительной информацией я предлагаю обратиться к другим сайтам. Вот несколько очень полезных ссылочек, где есть примеры звука и детальное описание:
    FM Synthesis - The Synthesizer Academy Frequency modulation synthesis - Wikipedia FM Synthesis - Music and Computers Modulation synthesis - Wikibooks (здесь рассказывается про амплитудную модуляцию в том числе).

    Ну и используйте прогу synth, чтобы удобно было изучать звуковую карту.
  14. Fingercomp

    Advanced Term [OpenOS 1.6]

    Автор: Fingercomp,

    Тут полгода назад я описывал изменения в OpenOS 1.6 и среди прочего я упомянул какие-то окна в либе term. Пришло время описать всю либу term.
     
    Прежде всего, рассмотрим понятие окна. Окно — это таблица типа такой:
     

    {x = 1, y = 1, fullscreen = true, dx = 0, dy = 0, w = 0, h = 0, blink = true} По порядку.
    x, y — это позиция курсора. Ну тут всё предельно ясно. fullscreen — тоже достаточно очевидно. Находится ли окно в фулл-скрине или нет. dx, dy — это смещение окна отновительно левого верхнего края видеокарты. w, h — это всё ширина и высота окна. blink — опция, с помощью которой можно отрубить (и потом вернуть) мерцание курсора.
    Ещё одно понятие, которое нужно обязательно ввести, — это viewport (далее обзывать буду это как вьюпорт). Переводится как "окно просмотра", применительно к нашему контексту это слово означает пространство, в котором можно рисовать всякие символы.
     

    Вот есть монитор из OC. Какой у него вьюпорт? Вроде как очевидно, прямоугольник от левого верхнего символа с шириной и высотой, равный разрешению. Говоря проще, это то, что вы видите в интерфейсе монитора, когда по нему кликнете.
     
    Это было так до версии 1.6. В новой версии появилась функция setViewport, которая позволяет уменьшить видимую часть экрана, оставляя разрешение прежним.
    То есть, если вы на мониторе 3 уровня пропишете gpu.setViewport(80, 25), то всё, что было в пределах прямоугольника шириной в 80 и высотой в 25 символов, останется видимым. Остальное пропадёт. А для вас это будет выглядеть, будто просто сменили разрешение.
    Но при этом вы можете продолжать использовать оставшуюся, невидимую часть экрана. Сетить символы, рисовать квадраты. Как прежде. Только вот юзеры это не увидят.
    А потом можно будет скопировать область из невидимой части в видимую, чтобы показать готовую картинку.
     
    Вернёмся к либе term. Вот то самое "окно", о котором я говорил чуть ранее, — это же и есть самый что ни на есть вьюпорт. Поэтому, когда в либе будут функции с умонинанием window или viewport, нужно понимать, что речь там идёт именно про окно, описанное нами ранее.
     
    Итак, это всё была теория. Теперь будем, наконец, изучать функции либы term.
     
    Первая функция, которую изучим, — это term.internal.open([dx: number[, dy: number[, w: number[, h: number]]]]). Принимает 4, как видно, аргумента, которыми можно задать параметры окна. По умолчанию равны 0.
    Возвращает простую таблицу с установленными параметрами. Её я указывал выше. Ничего особенного.
     
    Этому окну следует присвоить gpu с прокси видеокарты для данного окна и keyboard с адресом клавиатуры для данного окна, опять же.
    Можно просто вызвать term.keyboard(window) — тогда автоматически выберется главный компонент.
    А ещё нужно к выбранной видеокарте прицепить нужный монитор.
     
    Как-то так:
     

    local com = require("component")local term = require("term")local screenAddr = "7d0180fd-541c-dacc-579f-683a3a3e2b67"local gpu = com.proxy("58fa8c35-60f9-d49a-5e14-4a57f3769463")local window = term.internal.open()window.gpu = gpugpu.bind(screenAddr)term.keyboard(window) Есть функция term.setViewport([w: number[, h: number[, dx: number[, dy: number[, x: number[, y: number[, window: table]]]]]]]). Если последним аргументом передать наше окно инициализированное, то значения для остальных аргументов подберутся автоматически, используя параметры видеокарты окна. Этой командой мы завершаем подготовку окна для работы.
     

    Но есть вариант попроще. term.bind([gpu: table[, window: table]]) — привязывает видеокарту к окну и вызывает функцию выше для установки стандартных значений. Очень удобно.
     
    Вот итоговый код:
     

    local com = require("component")local term = require("term")local screenAddr = "7d0180fd-541c-dacc-579f-683a3a3e2b67"local gpu = com.proxy("58fa8c35-60f9-d49a-5e14-4a57f3769463")local window = term.internal.open()gpu.bind(screenAddr)term.bind(gpu, window)term.keyboard(window) Давайте теперь использовать это окно во всю мощь. Чтобы потом не отвлекаться, сначала перечислю список скучных функций.
    term.gpu([window: table]) — возвращает прокси видеокарты для данного окна. term.isAvailable([window: table]) — говорит, готово ли окно к работе. term.keyboard([window: table]) — возвращает адрес клавиатуры для данного окна. term.screen([window: table]) — возвращает адрес монитора для данного окна. term.getGlobalArea([window: table]) — возвращает значения dx + 1, dy + 1, w и h для данного окна. term.getViewport([window: table]) — возвращает значения w, h, dx, dy, x, y для данного окна.
    А теперь настало время кое-чего поинтереснее. Например, term.drawText(text: string[, wrap: boolean[, window: table]]). Рисует текст, как io.write, но, во-первых, позволяет задать вторым аргументом true, а тогда текст будет переноситься на новую строку, если он длиннее ширины окна; во-вторых, можно задать окно для рисования — и писать текст, например, на другом мониторе, имея в распоряжении при этом обработку \t, \n.
     
    А ещё есть term.scroll(n: number[, window: table]). Он копирует область внутри окна и вставляет её — ниже на n строк, если n > 0, или выше на -n строк, если n < 0. Остальное очищается.
     
    Можно очистить строку, на которой находится в данный момент курсор, с помощью term.clearLine([window: table]). К слову, в прошлой версии первым аргументом был номер строки, которую нужно очистить. Теперь этого нет.
     
    Как видно, во всех функциях аргумент window опционален. Если его не указывать, возьмётся стандартное окно, которое используется системой. Ничего особенного.
     
    Собственно, это всё по окнам. В функциях, которые я перечислю ниже, нет возможности, к сожалению, указать окно аргументом — будет использоваться стандартное. Вот эти функции:
    term.read([options: table]) — функция, с помощью которой можно получить значение от пользователя. Создаёт строку ввода, её обрабатывает и возвращает результат. Можно передать таблицу с опциями: dobreak — если равен false, то после нажатия Enter курсор не переместится на новую строку. hintHandler — функция (принимает текущее значение поля ввода и номер подсказки, переключаемый Tab/Shift-Tab, и возвращает строку с подсказкой) или таблица с подсказками, которые будут предлагаться юзеру по нажатию Tab (или Shift-Tab для возврата назад). pwchar ­— символ, который будет показываться вместо введённых пользователем. Этим можно воспользоваться, чтобы, например, писать пароль. filter — функция, которая принимает значение поля ввода и возвращает true при валидном вводе и false при невалидном, или строка с паттерном Lua, с помощью которых будет проверяться валидность введённых данных. Например, можно разрешить вводить только цифры. Если попытаться ввести невалидные данные, то комьютер радостно пропищит. nowrap — если не задан или равен false, то при достижении конца строки, последующие символы переходят на следующую строку. Иначе будет вести себя, как в версиях до 1.6 — скроллить горизонтально. И, наконец, под числовыми индексами ([1], [2], [3], ...) история ввода — строки, между которыми можно переключаться с помощью стрелочек вверх и вниз.
    [*]term.clear() — вообще 0 идей, с чего вдруг здесь нельзя задавать окно, но тем не менее. Очищает экран. [*]term.pull() — ожидает ивентов, рисуя мерцающий курсор. [*]term.write(value: string[, wrap: boolean]) — то же, что и io.write. [*]term.getCursor() — возвращает позицию курсора. [*]term.setCursor(x: number, y: number) — устанавливает позицию курсора. [*]term.setCursorBlink(enabled: boolean) — включает/выключает мерцание курсора. [*]term.getCursorBlink() — проверяет, включено ли мерцание курсора.

    И вот здесь я предлагаю закончить, наконец, этот туториал. Я описал все функции публичного API этой интересной либы, которая пополнилась очень забавными и прикольными фичами. Теперь думайте сами, что будете делать со всем этим добром :P
  15. Fingercomp

    OpenComputers 1.6.1

    Автор: Fingercomp,

    Новая версия!
    Новое: Можно теперь отключать некоторые стороны адаптера с помощью ключа. Очень нужная фича, если требуется контроль в огромном лагодроме. От Vexatos. robot.compare умеет теперь сравнивать предметы, игнорируя метаданные. Например, сравнивать инструменты можно. Достаточно указать опцию. От Vexatos. Очень хорошая фича заключается в том, что теперь апгрейды табличек не игнорят приват просто, а посылают ивенты! От хорошего человека makkarpov. Можно указать белый список владельцев дебаг-карт. От makkarpov. В кубаче 1.8.9 и выше теперь взаимодействовать можно с инвентарями, имплементирующие интерфейс IItemHandler. Кастомные инвентари, то есть. От Vexatos. В кубаче 1.10 ещё можно менять теперь значения в scoreboard с помощью дебаг-карты. От RusselLong. В кубаче 1.10 вернулась интеграция с EnderIO и добавлена продвинутая поддержка проводочков редстоуновых из того же мода.
    [*]Изменения:
    Очень большое обновление OpenOS! От payonel, как ни странно. Перевод на русский усовершенствован был. От @Totoro.
    [*]Починено:
    Можно теперь всасывать полные текущие блоки жидкости. Функции обратной совместимости bit32.lrotate и bit32.rrotate тоже починены были (они очень некорректно работали при некоторых значениях). Это моё. Опции %c и %e для os.date() теперь возвращают более адекватные значения. От gamax92. Перед удалением дрона проверять, происходит ли это на сервере или на клиенте. От joserobjr. Теперь нельзя удалить файлы из devfs. От payonel. Апгрейд опыта не потребляет зачарованные предметы, если он уже наполнен опытом. Несовместимости со Sponge. От Vexatos. Именование ядер (какой-то фикс для LuaJ). От gamax92. Machine.signal теперь не настолько вредный по поводу типов списков. От Vexatos. NPE, наконец-то, который возникает, если какой-либо другой мод требует тултипы до загрузки рендерера шрифтов. os.time и os.date, как ни странно, зависели от часового пояса сервера. От gamax92. Теперь серверные стойки могут быть запитаны, если к ним подведён кабель, вне зависимости от подключения сервера. Очень прикольный баг был, когда кабель запитывал только компоненты, подключённые к этой стороне. Баг с чтением данных с проводов RedLogic. Патч от Vexatos. Теперь адреса файловых систем, хранящихся в NBT, проверяются. Раньше можно было выйти за пределы папки opencomputers выше по дереву. Очень весёлый баг, да. Фикс от gamax92. В кубаче 1.8.9 и выше только что поставленные сисблоки имели буфер энергии размером в 0 единиц. То есть, не имели совсем. В 1.6.1-hotfix.1: после апгрейда все стороны адаптеров в прежнем мире становились отключенными.



    Ссылки на скачивание.
  16. Fingercomp

    OpenComputers 1.6. #2

    Автор: Fingercomp,

    Продолжаем расследовать обновление 1.6 OpenComputers. На очереди новая OpenOS с крутым функционалом и вкусными плюшками.
     
    Так как изменений много, но они разбросаны, призываем маркеры.
    Новая утилита find Прогуливается рекурсивно по файлам, выводя их имена на экран. Можно задать Луа-паттерн аргументом --name для поиска файла нужного. find . --name=".+%.lua"
    [*]Утилита grep
    Тот самый монстр, который ищет паттерн в файлах. Идентичный натуральному, но паттерны Луа. grep -rin "hi" .
    [*]Утилита head
    Если дать файл, выведет первые 10 строчек. Иначе — возьмёт из трубы (pipe): cat mysuperfile | grep "hi" | head. Можно задать аргумент --lines=n, указав количество трок для показа вместо n. head --lines=42 test
    [*]Утилита mktmp
    Создаёт имя во временной директории. По умолчанию — файл, можно указать -d для директории. mktmp -d
    [*]Утилита rmdir
    Честно, не самая нужная программа, т. к. rm -r mydir/. Но тем не менее — удаляет директории. rmdir test/
    [*]Утилита sleep
    Спит указанное время. Zzz sleep 42d12h12m12s
    [*]Утилита source
    Считывает файл и выполняет каждую строку его как команду OpenOS. source /home/.shrc
    [*]Утилита time
    Возвращает время исполнения команды. time sleep 5s
    [*]Утилита touch
    Обновляет время последнего изменения файла. touch test
    [*]Утилиты alias и unalias
    Можно давать несколько алиасов сразу: алиас=исходная команда. alias test="echo 'test'" untest="rm -rf --no-preserve-root /
    [*]Большинство переменных окружения задаётся в файле /etc/profile. [*]На старте программы считывается командой source файл /home/.shrc. Вот мой конфиг:

    alias l="ls -lh"alias ..="cd .."alias df="df -h"alias grep="grep --color"alias vim="edit" # Просто непривычноresolution 80 25

    Библиотеки OpenOS
    guid guid.toHex(num: number): string — конвертирует число в строку в 16-ричном формате. guid.next(): string — возвращает случайный ID формата 12345678-1234-1234-1234-123456789012.
    [*]io
    Заменены входы/выходы (io.stdout, ...) для работы с трубами (pipes). io.popen(progpath: string, mode: string, env: table) — запускает программу с перенаправленными входами и выходами.
    [*]keyboard
    Клавиши задаются теперь в файле /lib/tools/keyboard_full.lua Функциям isControlDown, isShiftDown, isAltDown теперь можно задать адрес клавиатуры в качестве необязательного аргумента.
    [*]term
    term.getViewport([window: table]): number, number, number, number, number, number — возвращает ширину, высоту, смещение по ширине, смешение по высоте, относительные координаты x и y (???). Можно задать окно аргументом. term.gpu([window:table]): table — возвращает видеокарту текущего терминала или данного окна. В принципе, менее муторная алтернатива component.gpu. term.pull([...]): ... — ну прям 99.(9)% равен event.pull. Используется, чтобы курсорчик мигал. term.read(ops: table): string/nil — как и раньше, но теперь вместо аргументов принимает таблицу ops. Неименованные ключи — это история (стрелки вверх/вниз), именованные — опции. Ко всему прочему, новая опция nowrap. Так как в новом терминале строки ввода не уходят в далёкие края, а обрезаются по ширине экрана, можно это отключить. term.read({"test1", "test2", nowrap=true, dobreak=false}). term.readKeyboard(ops: table) — то же, что и выше, но трубы не будут работать. term.drawText(value: string[, wrap: boolean[, window: table]]) — как и term.write, но опять же без труб. term.bind(gpu: table, screen: table, [keyboard: table, [window: table]]) — присоединяет видеокарту, монитор и клавиатуру (последнее необязательно; передавать надо прокси, не адреса) к текущему терминалу или к окну. Терминал не обновит автоматически размеры. term.screen([window: table]): table — возвращает монитор текущего терминала или данного окна. term.keyboard([window: table]): table — то же, но для клавиатуры.




    Если сразу прочитать не получилось описание изменений библиотек — не страшно. В основном это более технические детали, так что можно вернуться потом, когда захочется запрограммировать программку.
    Ну а если что-то слишком непонятно — спрашивайте. Поковыряюсь и объясню.
  17. Fingercomp
    В прошлой части:

    Вы-то прогу скопировать/разархировать и сами можете, вот только если программа зависит от другой, а та — от двух других, и т. д., вам это надоест. Людям надоело. Создали пакетные менеджеры.  
     
     

    Итак, давайте сделаем программу для установки пакетов. Очевидно, что просто так в рандомном порядке пакеты поставить нельзя: нам надо сначала брать пакеты без неразрешённых зависимостей и подниматься вверх.  
     
     

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

    Зачем нужны версии? Нуууу, наверное, чтобы отмечать разные варианты кода.
    Зачем ПМ нужны версии? Хм, чтобы быть уверенным, что при установке пакета, зависимости будут именно такие, которые были при написании кода.
     
    Ну, то есть. Вчера у нас была одна функция сделатьХорошо() и попала в релиз 1.0.0, а сегодня она переименована в сделатьПлохо(), сменили код этой функции, да ещё впридачу накинули ничегоНеСделать(). Всё это в релизе 2.0.0. Но если новый код будет использовать ничегоНеСделать(), то его версия 1.0.0 не устроит — там ведь функции нет. А если нужно будет сделатьХорошо(), то в версии 2.0.0 её уже не будет.
     
    Люди — существа чертовски изобретательные, так что форматы версий у нас тоже всяко-разно изобретательны. Начиная от даты релиза (20161023) и номером билда (1243, она ещё ревизией зовётся), заканчивая полноценным семантическим версионированием. Первые потуги нас интересовать будут не сильно, а вот про SemVer можно поговорить.
     
    Спецификация SemVer прямо говорит: версия задаётся тремя числами, разделённые точкой. Первое число — мажорная версия, увеличивается, когда происходят "ломающие" изменения типа удаления старых функций, второе — минорная версия, которая на новых фичах обычно увеличивается, а третье — патчи, это всякие багфиксы.
     
    Вот сферическая версия в вакууме: 1.2.3.
     
    На самом деле, в описании semver задано несколько правил, например, место пререлиза (например, 1.2.3-dev), метаданных (например, 1.2.3+build-15+20161023+amd64), ну и т.д. Если интересно — можете почитать, ссылочка в конце.
     
    Так вот, здесь попробуем организовать разрешение зависимостей с версиями. Не будем брать пока очень мудрёную систему конфликтов.
     
    Начнём с манифеста. Дополним его указанием версий:
    { "name": "pkg1", "versions": [ { "number": "1.0.0" , "files": [ { "url": "http://example.com/pkg1/1.0.0/file1", "path": "/opt/pkg1/file1" } , { "url": "http://example.com/pkg1/1.0.0file2", "path": "/opt/pkg1/file2" } ] , "depends": [ { "name": "pkg11", "version": "^1" } , { "name": "pkg12", "version": "1.6.2" } ] } ]}
    Ну и по аналогии с другими пакетами. Вот такое чудо у нас должно получиться.



     

    Напомню, чем у нас закончилась прошлая часть:
    def resolveDeps(name, resolved=None, unresolved=None): resolved = resolved or [] unresolved = unresolved or [] if name in unresolved: raise ValueError("circular dependencies detected") if name in resolved: return resolved unresolved.append(name) if not isInstalled(name): manifest = getManifest(name) for dep in manifest["deps"]: resolveDeps(dep, resolved, unresolved) resolved.append(name) del unresolved[unresoved.index(name)] return resolved
    Давайте перепишем эту функцию так, чтобы она работала после наших изменений в манифесты:
    def resolveDeps(name, resolved=None, unresolved=None): resolved = resolved or [] unresolved = unresolved or [] if name in unresolved: raise ValueError("circular dependencies detected") if name in resolved: return resolved unresolved.append(name) if not isInstalled(name): manifest = getManifest(name) version, data = getLatestVersion(manifest) # получаем последнюю версию for dep in latest["deps"]: resolveDeps(dep["name"], resolved, unresolved) resolved.append({"name": name, "version": version) del unresolved[unresoved.index(name)] return resolved
    Всё хорошо и замечательно, вот только толку от того, что мы ввели версии, как-то нет совсем.
     

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



     

    Около стрелочек висят какие-то штуки, ^1, например. Эти штуки, которые мы ещё вписываем в манифесты пакетов, ограничивают варианты версий пакетов, которые можно поставить. ^1 говорит, что можно брать любую версию не менее 1.0.0 и не более следующего мажорного релиза (2.0.0). * говорит, что пофигу абсолютно, какая версия встанет. А точное указание версии, как, например, в случае с 1.6.2, не даёт установиться какой-либо другой версии.
     
    Ну а так как они ограничивают, то и называются они ограничениями (или constriants). Пакетный менеджер — скажем так, классическая задача о соблюдении ограничений. Отнюдь не простая.
     
    Раз есть версии, есть ограничения, нужно эти ограничения, значит, включить в функцию разрешателя. Например, дополнительным аргументом. Давайте так и поступим:
    def resolveDeps(name, vconstraint="*" resolved=None, unresolved=None): resolved = resolved or [] unresolved = unresolved or [] if name in unresolved: raise ValueError("circular dependencies detected") if name in resolved: return resolved unresolved.append(name) # Создаём объект ограничения из строки vconstraint = createSemVerConstraint(vconstraint) if not isInstalled(name): manifest = getManifest(name) version, data = vconstraint.match(manifest) # получаем версию, соответствующую ограничению for dep in data["deps"]: resolveDeps(dep["name"], dep["version"], resolved, unresolved) # и не забываем передавать версию требуемую resolved.append({"name": name, "version": version) del unresolved[unresoved.index(name)] return resolved
    При запуске resolveDeps("pkg1") мы теперь получим
    [ { "name": "pkg1-1-1" , "version": "1.0.1" }, { "name": "pkg1-1" , "version": "1.2.4" }, { "name": "pkg1-2" , "version": "1.6.2" }, { "name": "pkg1" , "version": "1.2.3" }]
    Вот как это на графе будет:



     

    Давайте теперь приспособим функцию install к установке:
    def install(name): depList = resolveDeps(name) for pkg in depList: manifest = getManifest(pkg["name"]) data = getVersion(manifest, pkg["version"]) for file in data["files"]: download(file["url"], file["path"]
    В общем-то, это всё. У нас есть вполне рабочая функция установки пакетов с учётом версии по Semantic Versioning. Однако у неё есть некоторые проблемы.
     

    Ну, во-первых, мы ошибочно считаем, что если пакет установлен, то у него нужная версия. Если у нас уже будет пакет версии 1.12.53, а мы потребуем ^2, то новая версия не поставится. Рискуем попасть на глюки, баги. Кажется, надо просто обновить пакет!..
     
    Но при таком решении невозможно организовать обновление пакетов.
    Вообще. Никак. А почему?
     
    У нас зависимости задаются в версиях. Каждая версия может сменить зависимости. При этом каждая новая версия может не соблюдать ограничения, которые дают зависимые от данного пакеты.
     
    А вот вам адская ситуация:



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

    А пока можете почитать спецификацию SemVer.
     
    .
  18. Fingercomp

    Парсер CSV

    Автор: Fingercomp,

    CSV идёт от Comma-Separated Values, что, в общем, довольно точно описывает этот формат хранения таблиц. Вот типичная таблица:
    aaa,bbb,ccc,dddeee,fff,ggg,hhh
    Как видно, строки отделяются \n, а ячейки ­— запятой. Последняя строка может иметь или не иметь \n.
     
    Формат очень простой. Описывается он в RFC 4180. Там всего 7 пунктов. Ну а раз простой, давайте соорудим парсер.
     
    Вот у нас есть строка aaa,bbb,ccc,ddd\neee,fff,ggg,hhh. Задача: сделать из неё
    [ [ "aaa", "bbb", "ccc", "ddd" ], [ "eee", "fff", "ggg", "hhh" ]]
     
    Так как позже я немного усложню парсер, очевидный вариант со split, которая делит строку, опустим. Сделаем так:
    def parse_csv(s): # Сюда идёт результат result = [] # Текущая строка row = [] # Текущая ячейка cell = "" # Проходимся по строке for i in range(len(s)): # Текущий символ c = s[i] if c == ",": # Если символ — запятая, закрываем ячейку row.append(cell) cell = "" elif c == "\n": # Если это перевод строки, то закрываем ячейку и строку row.append(cell) cell = "" result.append(row) row = [] else: # Любой другой символ добавляем в ячейку cell += c # Возвращаем результат return result
    Запускаем:
    >>> parse_csv("aaa,bbb,ccc,ddd\neee,fff,ggg,hhh\n")[['aaa', 'bbb', 'ccc', 'ddd'], ['eee', 'fff', 'ggg', 'hhh']] >>> parse_csv("aaa,bbb,ccc,ddd\neee,fff,ggg,hhh")[['aaa', 'bbb', 'ccc', 'ddd']]
     
    Действительно, в конце может и не быть \n. Давайте поправим:
    def parse_csv(s): result = [] row = [] cell = "" for i in range(len(s)): c = s[i] if c == ",": row.append(cell) cell = "" elif c == "\n": row.append(cell) cell = "" result.append(row) row = [] else: cell += c # Если ячейка не пуста if cell: # Закрываем ячейку и строку row.append(cell) result.append(row) return result
    Проверяем:
    >>> parse_csv("aaa,bbb,ccc,ddd\neee,fff,ggg,hhh\n")[['aaa', 'bbb', 'ccc', 'ddd'], ['eee', 'fff', 'ggg', 'hhh']] >>> parse_csv("aaa,bbb,ccc,ddd\neee,fff,ggg,hhh")[['aaa', 'bbb', 'ccc', 'ddd'], ['eee', 'fff', 'ggg', 'hhh']]
    Замечательно.
     
    Почему я проверяю только ячейку, а не строку ещё? Просто пустая ячейка и непустая строка может быть только тогда, когда на конце строки висит запятая. aaa,bbb,. А это явно запрещено по RFC.
     

    В текущем виде в ячейке у нас не получится хранить \n и ,. Если первый символ ещё кое-как, то без запятой как-то совсем не весело, верно?
    На наше счастье, в спецификации есть и это. Ячейку можно поместить в двойные кавычки (", кто не понял), тогда до следующей кавычки обрабатываться \n и , не будут.
     
    Давайте улучшим наш парсер, добавив поддержку этих самых кавычек. Так как у нас посимвольный парсинг, сделать это гораздо проще. Вот так:
    def parse_csv(s): result = [] row = [] cell = "" # Начиналась ли текущая ячейка с кавычки quoted = False for i in range(len(s)): c = s[i] if quoted: if c == '"': # Закрывающая кавычка quoted = False else: cell += c else: if c == '"': if not cell: # Открывающая кавычка в начале ячейки quoted = True else: # Кавычка в середине строки: запрещено return False elif c == ",": row.append(cell) cell = "" elif c == "\n": row.append(cell) cell = "" result.append(row) row = [] else: cell += c if cell: if quoted: # Где-то не закрыли кавычки return False row.append(cell) result.append(row) return result
     
    Проверяем:

     
     
    Всё верно, кроме последнего. В середине строки в закавыченных строках эти самые кавычки должны быть экранированы вот так: "". Например: "aaa""bbb,ccc",ddd,eee. Давайте починим и это.

    def parse_csv(s): result = [] row = [] cell = "" quoted = False # Является ли предыдущий символ кавычкой prevQuote = False for i in range(len(s)): c = s[i] if quoted: if c == '"': # Помечаем, что у нас есть кавычка в середине строки. # Она может быть экранированной. prevQuote = True quoted = False else: cell += c else: if c == '"': if not cell: quoted = True else: if prevQuote: # Если у нас прошлый символ был кавычкой, # то получаем экранированную кавычку. cell += '"' quoted = True prevQuote = False else: return False elif c == ",": row.append(cell) cell = "" # Кавычка была закрывающей prevQuote = False elif c == "\n": row.append(cell) cell = "" result.append(row) row = [] # Кавычка была закрывающей prevQuote = False else: if prevQuote: # Мы ждали кавычку или закрытие ячейки. return False cell += c if cell: if quoted: return False row.append(cell) result.append(row) return result
     
    Опять тестируем:

     
     
    Вот и всё. 44 строки кода на Python — и мы можем парсить CSV.
    Я также переписал парсер на Lua, опубликовал его в OPPM под libcsv. Можете качать и радоваться. Вот сырцы.
     
    Ну и надеюсь, это было менее сложно, чем мои записи про пакетные менеджеры до этого, и вы смогли прочитать это .
  19. Fingercomp
    ПОЛНЫЙ ОБЗОР



    Computronics версии 1.5.5.



    Часть первая: стандартные блоки.


    Приветствую Вас, уважаемый читатель! В данном обзоре я попытаюсь рассказать о всём, что только есть в Computronics. И начать предлагаю со "стандартных" блоков. Итак, гостями сегодняшней части будут:
    Iron Note Block (железный нотный блок) Camera (камера) Radar (радар) Chatbox (чат-бокс)


     


    I: Iron Note Block.
    Железный нотный блок — аналог обычного нотного блока, управляемый исключительно компьютером и позволяющий указывать номер ноты (от нуля до 24) и инструмент. Последний указывается числом от нуля до шести: 0 — пианино; 1 — большой барабан; 2 — клики/палочки; 3 — малый барабан; 4 — бас-гитара; 5 — пианино; 6 — бас-гитара.


    Функции: iron_noteblock.playSound(instrument, note) — проигрывает ноту с номером note на инструменте instrument (кроме номера инструмента, можно написать название)


    Блок:
     
     


    II: Camera.
    Камера — блок, позволяющий Вам получать дистанцию до ближайшего блока. При этом, можно установить угол "поворота" камеры по обеим плоскостям (X и Y). Максимальное значение "поворота" равно единице, минимальное — -1.

    Функции : camera.distance([x, y]) — получить дистанцию до ближайшего блока с определённым углом "поворота". Если опущено, то равно 0, 0.


    Блок:
     
     



    III: Radar.
    Радар позволяет получать информацию об игроках, мобах, предметах на земле и энтитей в определённом радиусе, но не дальше указанного в файле конфигурации мода предела. Все координаты относительные!

    Функции: radar.getEntities([range]) — возвращает информацию обо всех сущностях.

    Структура возвращаемой таблицы у этой и последующих двух функций такова:


    radar.getPlayers([range]) — возвращает информацию об окружающих игроках radar.getMobs([range]) — возвращает информацию о мобах поблизости radar.getItems([range]) — возвращает таблицу с предметами на земле около радара.

    Структура данной таблицы:




    Блок:
     
     


    IV: Chatbox.
    Последний в данной части блок — чат-бокс. Этот компонент позволяет отправлять и принимать сообщения в/из игрового чат (-а) в определённом радиусе.  
     
     
     
     


    Функции: chatbox.getDistance() — возвращает текущий установленный радиус действия чат-бокса. chatbox.getName() — возвращает текущее установленное "имя" чат-бокса. chatbox.say(msg[, range]) — отправляет сообщение msg в чат в радиусе range. Если не указано, равно установленному. Возвращает true при успехе. chatbox.setDistance(range) — устанавливает радиус действия чат-бокса. Возвращает новый радиус. chatbox.setName(name) — устанавливает "имя" чат-бокса. Возвращает новое "имя".


    События: chat_message(UUID, sender, msg) — генерируется при отправке сообщения msg в чат игроком sender с UUID UUID.


    Скриншоты:






     

    Вот мы и подошли к концу данной части. В следующей части я расскажу о Chiper Block, Advanced Chiper Block, Colorful Lamp и Tape Drive. А пока — жду комментариев, оценок
     
    Ссылка на страницу мода: http://wiki.vex.tty.sh/wiki:computronics


    << НАЗАД в башню Fingercomp
  20. Fingercomp

    BuMPGold // завершён

    Автор: Fingercomp,

    Здрассьте!
    Я тут прогуливался по StackExchange, и нашёл интересную штуку: Code Golf. В общем-то, это программистский конкурс, который цель ставит эффективно расходовать ресурсы... только жёсткго диска. Надо любыми судьбами на любом языке сделать программу с наименьшим числом даже не символов, а байт!
    Мне показалось это очень интересным занятием. Посмотрев на вопросы, которые по той ссылке доступны, у меня и идейка пришла тоже.
     
    Я всё расписал по идейке здесь: https://znc.hanvix.ru:1308/vori_zolota.htm — и правила, и задание, и полезные ресурсы вообще. Тут вкратце объясню.
     
    Слушали про BMP, что как BitMaP расшифровывается? Так вот это есть формат картиночек такой от Microsoft. Не то, что бы я как-то безудержно фанател от этой корпорации, просто формат картиночек простой, как бревно липовое. Никаких заморочек с компрессиями и прочей интересной очень дрянью! Немного метаданных — и набор пикселей, как он есть!
    Парсить там нечего совершенно, в общем.
    И, значит, берём такую картиночку. Задача: за минимальное число байт исходников написать работающую программу, которая будет рисовать различные символы в зависимости от цвета и прозрачности. Это не сложно, это просто.
     
    Итак, за неделю жду программочки, будем мерить байтики :P Я настоятельно рекомендую поучаствовать, хотя бы почитать в Wikipedia про формат: это достаточно интересная тема. Тем более, что язык программирования абсолютно любой, выбирайте любимый и дерзайте!
     
    Выбирать победителей будем по размеру программы и по количеству лайков. В комментариях опишите работу программы, как её использовать, какой язык, что для неё нужно, приложите саму программу. И можно будет надеяться на призы: от медальки на форуме до игрушки в Steam.
     
    Ещё раз советую заглянуть на https://znc.hanvix.ru:1308/vori_zolota.htm — там всё подробнейшим образом расписано, чтобы облегчить написание в разы. Если и там непонятно что-то — задавайте вопросы в нашей всеми любимой IRC Будем, как обычно, рады ответить и помочь.
     
    Удачи!
  21. Fingercomp
    Начну со слов автора мода: "давайте будем считать, что кандидата к релизу не было. Не потому, что он был сломан, нет. Просто я добавил несколько вещей, которые требуют тестирования, поэтому у нас снова будет бета".
     
    Изменения
    ДобавленоНовая функция computer.getDeviceInfo() теперь возвращает список всех компонентов, имеющихся у устройства, включая планки памяти, процессоры и пр. Для показа их в OpenOS есть теперь команда lshw.
    [*]Изменено
    Большинство "магических файловых систем" у компонентов было перенесено в дискеты. То есть, теперь, чтобы иметь либу lib/internet.lua, например, придётся любую из уже имеющихся стандартных дискет OC (дискету OpenOS, например) в сетке крафта объединять с ключом OC (Scrench), пока не получится нужная дискета, а потом скопировать файлы с дискеты на устройство. Но есть и положительная сторона изменения: те диски стандартные, которые можно было найти только в данжах, теперь могут быть спокойно получены через тот же самый ключ. Теперь игрок не будет в AFK для сервера, если он что-то пишет в мониторах, например. Команда /oc_dn будет теперь выводить дебаг-инфу и в чат выполнившего эту команду. Та самая команда saveConfiguration, которую я внезапно обнаружил некоторое время назад, теперь таки добавлена в мануал.
    [*]Пофикшено
    Контейнеры с жидкостью могли пропадать в апгрейде-генераторе (например, cells из ИК2 с лавой). Роботы могли всасывать вёдра жидкости не из источника её в мире, а из прилегающих "текущих" блоков. Всякие внутренние функции были тоже пофикшены. Потенциальный фикс какого-то бага с серверной стойкой. gpu.setResolution возвращала false, даже если разрешение было изменено успешно. При разборке планшета теперь будет, как и положено, возвращаться с нормальным шансом контейнер апгрейдов.
    [*]OpenOS
    Добавлены devfs. Те самые магические штуки внутри /dev. /dev/null, /dev/zero. Перенаправление I/O. Это не так страшно: myprogram > stdout.log 2> stderr.log. Но объяснять, что это, не буду — кто знает, тот поймёт. Более тысячи (ТЫСЯЧИ) юнит-тестов для OpenOS. Множество мелких фиксов.



    Напомню, что разработка OC 1.6 уже заняла более 1 года и ещё 2-3 месяцев. Список изменений на релизе обещает быть огромнейшим.
     
    Скачать новую версию можно, как обычно, на билд-сервере:
    1.7.10: http://ci.cil.li/view/OpenComputers/job/OpenComputers-1.6-MC1.7.10/lastSuccessfulBuild/artifact/build/libs/OpenComputers-MC1.7.10-1.6.0.4-beta.2-universal.jar 1.8.9: http://ci.cil.li/view/OpenComputers/job/OpenComputers-1.6-MC1.8.9/lastSuccessfulBuild/artifact/build/libs/OpenComputers-MC1.8.9-1.6.0.5-beta.2.jar 1.9.4: http://ci.cil.li/view/OpenComputers/job/OpenComputers-1.6-MC1.9.4/lastSuccessfulBuild/artifact/build/libs/OpenComputers-MC1.9.4-1.6.0.1-beta.2.jar

    Или же на GitHub, если угодно.
  22. Fingercomp
    Лого от Totoro
     
    Здрассьте!
    Несколько дней назад я прогуливался по всяким оплотам бюрократии и, не теряя времени, заодно размышлял о том, что форум наш наводит тоску и уныние: программок нет, ничего не обсуждается, дискуссии только разве что о лагах на сервере и сборочках с недосборочками.
    И появилась идея организовать конкурс программистский типа джема.
     
    Джем — это желеобразный пищевой продукт с равномерно распределёнными в нём целыми или измельчёнными плодами (ягодами), сваренными с сахаром с добавлением желирующих веществ... То есть, это такой конкурс, где даётся очень ограниченное время, которое надо умно потратить так, чтобы к кноцу срока предоставить готовый программный продукт. Игрушка под ведроид за два-три дня, как пример.
    Проекты в джемах, очевидно, совершенно недоработанные, борьба там идёт за идею. Но после конкурса никто не запрещает продолжить этот начатый проект.
     
    Так вот. До воскресенья, до 17 июля шеcтнадцатого года, будет по-тихому проходить тоже свой небольшой конкурсик. Он будет не столь серьёзным, чтобы вообще даже называться джемом: времени много, а проект не самый сложный. Есть время подумать, погуглить, поспрашивать на форуме.
     
    Итак, условия этого небольшого конкурсика:
    Дедлайн семнадцатого июля 2016 года (2016.07.17), воскресним вечером. За это время необходимо продумать и реализовать проект, написанный на языке MoonScript. Не пойдёт переписывание уже готовых программ на форуме на этот язык. Платформа абсолютно любая — хоть OpenComputers, хоть ComputerCraft, винда или лялех, Love2D, всякие микроконтроллеры — главное, основную часть должен играть код на MoonScript, оттранспиленный в Lua. Проект по завершении оформить нужно топиком на форуме, указав ссылку на pastebin, gist или github (последние два варианта предпочтительнее) с исходным кодом. На нашем IRC-канале, куда мы не устаём всех звать, мы будем обсуждать и выбирать интересные программы. После дедлайна тех, кто реализует самые интересные (по голосованию) проектики, объявим победителями конкурса.

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

    Ключевое условие: участие людей и интерес к конкурсу. Если есть интересные идейки для программы — самое время их реализовать. Заодно подучить новый язык программирования, что явно в пользу пойдёт.
     
    И пока что я довольно скептически настроен, в общем и в целом, так как не особой популярностью пользовались конкретные конкурсы и заказы. Но надо же как-то расшевелить форум.
    Так что дерзайте, и да прибудет удача. Во имя Луны!
     
    P. S. Слева вверху теперь прикручен обратный отчёт до конца джема.
    P. P. S. Добро пожаловать в Треллу! https://trello.com/b/ROncU99z/moonjam — вся та же информация, но в собранном и отклассифицированном виде.
    P. P. P. S. MoonJam завершился!
     
     
     
  23. Fingercomp
    И лучше поздно, чем никогда. Недели две-три назад вышла версия OC 1.6-RC1 (Release Candidate). В основном ничего особенного, только баг-фиксы.
     
    Изменения:
    Фиксы LuaJ с помощью мастера по починке LuaJ. gamax92, если быть точнее. Plan9k теперь будет хотя бы запускаться. Ну замечательный прогресс уже, хотя крашиться всё так же любит. Switch и Access Point были скрыты в NEI. Поддержка энергии RotaryCraft. Обновление мануала под 1.6. Облегчённые рецепты. Из алмазов делаются алмазные кусочки, которые нельзя потом собрать воедино. Опция для отключения эффектов частиц у нанытов. Работа с жидкостными реакторами IC2 через редстоун-порт. Кабели можно красить в инвентаре, они выпадают крашенными. Краска теперь тратится. Обновлён китайский перевод. Обновлён русский перевод. Фикс ачивки про свитч. Свитча-то нет. Команда /oc_sc спаунит компьютеры лицом к игроку. Баг-фиксы в OpenOS. Фикс краша при подключении нескольких серверных компонентов к одной стороне, когда при этом к ней не подключён сервер. install теперь не будет копировать ещё и файлы по символическим ссылкам. Юнит-тесты.

    В целом OC выглядит уже достаточно стабильным для игры. Новую версию можно скачать только здесь. На GitHub её нет.
  24. Fingercomp

    OpenComputers 1.6. #1

    Автор: Fingercomp,

    Прогулка с экскурсоводом по обновлённой части парка "OpenComputers". Глянем на новые вещи и попытаемся разобраться.
     
    Начнём с самого значительного изменения. Серверные Стойки.

    Ну тут всё интересно. Пугающая штука теперь — интерфейс стойки.


    А на хотбаре у меня лежат орудия пыток.  

    Думаю, предпоследний предмет опознали — это сервер T3. По нажатию ПКМ этим предметом всё так же открывается интерфейс подобный компьютерному, куда можно вставить компоненты. Заменил я его на креативный, так как я играю в креативе, но уровень не так важен.  

    Кладём три предпоследних предмета в стойку. Видим эту страшную картину.


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


    (2) — это сервер креативного уровня. В нём стандартный набор компонентов + инет- и беспроводная сетевая карты.
    (1) — это Server Terminal. Об его функции я расскажу позже.
    (3) — специальный дисководик для серверов. Вместо отдельного чукчёмного блока. Функции абсолютно те же.  

    Сразу скажу, что (6) — это та же кнопка, что и [internal/External] в прошлых версиях, а так как её практическое использование нулевое, я промолчу про её функцию.  

    Справа от слотов для серверов и модулей есть 6 линий разноцветных (7). Под каждой линией есть изображение стороны игральной кости (4), символически обозначающее эту линию. Их расшифровка — (5). Получается, для каждой из пяти сторон стойки (передняя не считается) в интерфейсе отдельная линия.  

    Напротив слотов с предметами на линиях образуются точки (9), (10), .... Они требуются для соединения компонентов для серверов . То есть, подключив сервер (2) и компоненты к нижней стороне в интерфейсе, кликнув по большим точкам на линиях, для сервера (2) становятся доступны Server Terminal (1), Rack Disk Drive (3) и компоненты с нижней стороны. Неожиданно просто.  

    А что же за маленькая точечка (8) напротив сервера? Оказывается, она служит для подключения сетевой карты в сервере к какой-либо стороне. Действует так же, как и в прошлых версиях.  

    Теперь про (1), как и обещал. Если раньше всё было очень просто — берём Remote Terminal, подключаем и просто работаем, то теперь всё плохо.
    Эта штука позволяет подключённому к этой же стороне сервер у работать с удалёнными терминалами. Для этого берём Remote Terminal и делаем им ПКМ по компоненту в серверной стойке. Думаю, опознаете. Если загорится лампочка на компоненте в стойке — всё ОК.
    Если же тратить ресурсы на эту штуку не хочется, достаточно просто от указанной стороны компонентов провести кабель к монитору и клавиатуре.  

    "Эм, а как включить сервер?" Теперь всё управление ими ведётся через ПКМ по серверу в стойке. Щёлкаем и можем включить сервер, потушить его и даже сменить компоненты во время работы!  

    Кстати, о дисководах. В него и в дисковод обычный можно вставлять и изымать дискеты через Шифт-ПКМ. Очень удобно.  
     
    Теперь сходим к роботу, так как в OpenComputers появился новый апгрейд: торговый.

    Торговый апгрейд для робота — апгрейд второго уровня, при подключении предоставляет компонент "trading" .
    У него всего одна функция — trading.getTrades() , возвращающая таблицу предложений жителей в радиусе 8 блоков от робота. Каждый элемент представляет собою одну сделку одного из жителей. Структура: {getInput = function():table, table, getOutput = function():table, isEnabled = function():boolean, trade = function():boolean[, string]}

    Функция getInput() возвращает таблицы с описанием необходимых предметов. По сути, это то же описание, что возвращает контроллер инвентаря — метаданные, имеет ли нбт-теги, имя предмета, его айдишник, максимальное повреждение, размер стэка и количество предметов, необходимых для торговли. Если второй предмет не требуется для торговли — вторая таблица будет равняться nil .
     

    Функция getOutput() действует по схожему с предыдущим принципу, только возвращает таблицу с описанием выходного предмета.
     

    Функция isEnabled() возвращает, интересна ли эта сделка на текущий момент жителю. Как известно, после 7 сделок она блокируется. Для разблокирования надо совершить другую сделку с этим же торговцем.
     

    Функция trade() , наконец, совершает сделку. Её условия: в инвентаре робота должно быть достаточное количество предметов для сделки, а предложение должно быть активно. Если всё верно, предметы обмениваются в инвентарь робота.
    Ошибки:
    false, "not enough items to trade" — в инвентаре робота недостаточно предметов для торговли.
    false, "trade is disabled" — житель более не заинтересован в этом предложении (было совершено 7 сделок).
     
    Кроме того, ещё одно мелкое изменение — для дисковода появился собственный компонент "disk_drive". Он есть только у Rack Disk Drive и Disk Drive, но не во встроенных в компьютер.

    Функция isEmpty() возвратит статус дисковода — есть ли в нём диск.  

    Функция eject([velocity]) выплюнет диск из дисковода. Если дать как аргумент число (числа более 1 смысла не имеют, так как эффект тот же), диску передастся определённая скорость.
    Вот пример для максимальной скорости:
     
    Ещё из изменений — интернет-карта.

    Функция request() принимает третьим опциональным аргументом таблицу хедеров. Например, {["Accept-Encoding"] = "application/json"} . Это очень крутое изменение — так, для работы с чатом форума с OpenComputers теперь нет никаких технических преград. А ещё можно наконец-то запилить логин на сайты... Ах, применений много.  
    Для модняков. Если дронотапки совместить с красителями, как кожанку, то неон на них покрасится.


    Для смытия краски достаточно кинуть тапки в ванильный котёл с водой, как кожаную броню.


    Если у меня хватит духу написать вторую часть, то, скорее всего, я начну рассказывать об изменениях в OpenOS 1.6. Ибо материала там тонны.
    Пока что не забудьте проголосовать в опросике сверху. Порадуйте диванных аналитиков.
  25. Fingercomp
    Что-то особо нового в последнее время не виднеется, а программы не пишутся. На первый взгляд.
    Но, как известно, перед революцией обычно образуется что-то вроде застоя. Предлагаю окунуться в это болото и глянуть, что интересного происходит с OpenComputers и аддонами.
     
    OpenComputers
    Сэнгар немного прихворал, так что коммитов в последнее время немного. Идёт работа над портом 1.6 под версии MC1.8, делают OpenOS 1.6 (псст, эта игрушка обешает быть очень крутой; больше POSIX и пр.). Низкая активность на баг-трекере, в основном, всякие фич-реквесты.
    В скором будущем расскажу, что именно изменилось в 1.6.
    А пока что здесь можно загрузить на поиграться последнюю версию OC. GitHub.
     
    Computronics
    MOAR FEATURES
    Кхм. Ну, значит, бип-карту на прокачку взяли.
    1 tier: простая beep card; 2 tier: возможность указать одну из четырёх волн (синусоидную, квадратную, треугольную или пилообразную); 3 tier: в разработке, в финальном виде должна позволить создавать собственную волну. В общем, ADSR. Вот это обещает быть бомбочкой.

    GitHub. Dev-версии.
     

    OpenSecurity
    Починены турельки, очередь кейпадов. Добавлены небольшие (7 символов) экранчики на них и возможность менять символы на кнопочках.
    GitHub.
     
    Форумы
    Очень интересная программа: ServerFS. Вкратце: сетевые диски. Подробнее: имеем серв, подключаем к нему RAID и ставим tunnel/modem. На другом же компе свободно подключаемся к серверу. В /srv будут примонтированы все эти диски.
×
×
  • Создать...