Перейти к публикации
Форум - ComputerCraft

Fingercomp's Playground

  • записей
    85
  • комментария
    323
  • просмотра
    216 782

Об этом блоге

Gnawing the way out

Записи в этом блоге

 

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

Он вышел раньше, чем я предполагал — ниже список нового. Сила овец и оцелотов в их пушистости. Теперь пушистость можно приложить к делу и питать компы — с помощью ковровых конденсаторов. От обычных конденсаторов они толком не отличаются, но могут генерировать энергию, если по ним ходят минимум 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, например.


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

Fingercomp

Fingercomp

 

OpenOS. Потоки

Потоки — очень полезные штуки, позволяющие исполнять несколько кусков кода. Раньше для их использования приходилось скачивать отдельную библиотеку, работающую через костыли. Начиная с 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())--> runningt: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 endend)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() endend)local inputThread = thread.create(function() while true do local input = io.read() if input == "exit" then break end endend)thread.waitForAny({inputThread, moveThread})os.exit(0)
Если вы запустите эту программу, то должны заметить, что вы ничего не сможете написать в роботе, хотя работает io.read. Дело в том, что функция robot.forward вызывает метод компонента, который блокирует исполнение компьютера. Пока робот двигается, на компьютере не может выполняться ни одна команда.   Чтобы хоть что-то можно было вставить в строку, то поставьте после robot.forward какой-нибудь os.sleep(0) — он позволит соседнему потоку принять и обработать события. Тем не менее, строка ввода всё равно будет работать с тормозами.   В подобном случае задумайтесь над тем, чтобы использовать вместо строки ввода иное средство коммуникации: редстоун, сеть, интернет-сокет.   Несмотря на всё, библиотека действительно облегчает работу с потоками в OpenOS. Кроме того, очень удобно поместить все слушатели событий в один поток, чтобы они все автоматически были удалены после убийства потока. local event = require("event")local 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) endend)-- событие interrupted не ловится обработчикамиlocal intThread = thread.create(function() event.pull("interrupted")end)thread.waitForAny({mainThread, intThread})os.exit(0)
Не нужно функции сохранять в переменные и помнить, что нужно ставить event.ignore в конце программы; не требуется ребутать компьютер, если программа завершилась с ошибкой, а до отключения слушателей дело не дошло.   В общем, красота.

Fingercomp

Fingercomp

 

Перевод постов про звуковую карту (Guide to the Sound Card, English version)

tl;dr: https://gist.github.com/Fingercomp/0773bb0714296c0cb00d70a696d39bb3   Понятия не имею, зачем я сюда об этом пишу, ведь если вы можете этот текст понять, и в оригинале можно прочитать.   В любом случае, получил намёк, что три моих статейки про звуковую карту удовлетворительны в какой-то степени, но они на русском. Видите ли, ситуация с документацией спустя полгода после первого поста не улучшилась никак, так что единственный туториал для неё недоступен для понимания тех, кто не говорит по-русски.   Поэтому я потратил выходные на перевод постов на английский язык. Заняло это отчего-то дольше, чем я ожидал. Результат на гисте.   Все три поста в одном месте. Я там подбросил ещё чутка инфы и терминов и подправил фактические неточности. Мне лень было несколько раз перечитывать один и тот же текст, так что где-то могут остаться очепятки и всякие извороты языковые не к месту.
Но если понимаете английский, то всё равно должно быть удобнее, чем бегать по трём статьям здесь, в блоге. Ну а мне редактировать проще.   В общем, ссылку я оставил, больше мне сказать нечего.

Fingercomp

Fingercomp

 

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

Багофиксы, в основном только они. Вот из того, что добавилось: У планшетов можно получать полноценное направление взгляда игрока. Количество максимальных частей пакета добавлено в информацию об устройстве (та, что 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 всякие. Код стал ещё уродливее ради уменьшения потребления памяти. Вот такие улучшения.

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

Fingercomp

Fingercomp

 

OC Cookbook

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

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

Fingercomp

Fingercomp

 

OpenComputers 1.7.0

Окей, новую версию ждать не пришлось год в этот раз. 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. Думаю скоро выложить. Посмотрим, как оно пойдёт.

Fingercomp

Fingercomp

 

Sound Card / спектр, преобразование Фурье, PCM и WAV

В звуковой карточке есть дохрена функционала - поэтому она и крутая. В этой части попытаюсь объяснить достаточно сложные штуки, которые используют большие дяди. Надеюсь, что вы прочитали и поняли две предыдущие части цикла - это будет довольно важно для последующего повествования. [Раньше тут был полноценный пост с эмбедом, но после переезда оно всё, соответственно, сломалось. Текст доступен здесь.]

Fingercomp

Fingercomp

 

Sound card / звуковые волны, модуляция

Продолжаю рассказывать про 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, чтобы удобно было изучать звуковую карту.

Fingercomp

Fingercomp

 

Что изменилось в Computronics с прошлых обзоров

Вкратце проедемся про изменениям с невероятно старой версии 1.5.5 до самой новой, 1.6.3.   1.5.6 / 2015-07-24 Большинство блоков из мода можно покрасить, тыкнув по ним красителем. Интеграция с модом Flamingo (самая нужная фича, конечно): через компы можно заставлять фламинго качаться. Интеграция с Armourer's Workshop. Улучшен улучшенный шифратор. Ключи быстрее генерируются.

1.5.7 / 2015-09-12 Разноцветный апгрейд добавлен, который делает роботов разноцветными. Можно вызвать component.colors.setColor(color: number) и покрасить корпус робота в желаемый цвет. Интересная штука.

1.5.8 / 2015-10-11 Эффект hive_mind для наномашинок. Часть интеграции с Forestry.
Включив, можно тыкнуть пропитанной палкой из Forestry по желаемому улью с пчёлами - пчёлы станут летать над головой.
Палкой же направлять можно пчёл на желаемую цель: пчёлы полетят к ней и станут жалить.
Если отключить эффект, то пчёлы будут жалить игрока.

1.5.9 / 2015-10-22 Чатбоксики креативные стали писать во все измерения.

1.6.0 / 2015-11-28 Аудиокабели добавились. Их можно подключать к кассетным проигрывателям и к динамикам. Динамики будут воспроизводить звук вместо проигрывателя. Убрана поддержка NedoComputers, потому что этот мод сдох.


Спустя год выпускается огромнейший апдейт мода, поэтому дальше расписываю фичи детальнее.   1.6.1 / 2016-11-12 Мод портирован на 1.8.9, 1.9.4 и 1.10. На новых версиях майна используется улучшенный кодек DFPWM1a. Старые записи будут очень тихими, поэтому их нужно переконвертировать с помощью LionRay. С новым кодеком гораздо меньше шума будет. Добавлена шумовая карта. Отключается от пищащей карты тем, что можно для каждого из 8 каналов задать тип волны: синусоида, меандр, треугольная и пилообразная. Допольнительно появляется буфер операций: можно добавить ноты и затем вызвать component.noise.process(), чтобы проиграть. Добавлена звуковая карта. Как работает этот монстр, я описывал в предыдущей записи. Потом опишу функции покруче, а пока можно побикать. Интеграция с TIS-3D, модом от Sangar. Это и новые модули: разноцветный, считыватель дискет, самовыпиливатель - и документация в мануале TIS-3D. Интеграция с OC 1.6.
Добавлены дополнительные штуки для серверов. Плата с лампочками. Ключом можно менять конфигурацию, изменяя положение и количество лампочек. Как компонент предоставляет функции для включения/отключения лампочек и изменения цвета (True color). SSD. Расшифровывается как Server Self-Destructor. Очередная версия самой нужной вещи - самовыпиливателя, но для серверов. Если взорвать через функцию специальную, в серверной стойке пропадут все вещи. Серверный вариант батарейки, которую можно пихнуть в стойку. Можно ещё считывать количество энергии. Плата с переключателями. Можно тыкать по кнопочкам, включая или выключая их. А сервер потом может считывать положение переключателей. По просьбам трудящихся.
[*]Добавлена функция getPosition() в проигрыватель, чтобы узнать текущую позицию на кассете. Именно: её несколько лет не было. Ну что поделать, бывает. [*]Стандартная программка для работы с проигрывателем tape починена для работы с HTTPS. Можно менять размер чанка и таймаут ожидания. И tape wipe добавилась для стирания всей инфы на кассете. [*]1.7.10 Цифровый сигнальный контроллер (интеграция с RailCraft). Надеюсь, когда-нибудь дойдут руки рассказать, как она работает. Но не тут. [*]1.7.10 Цифровый сигнальный приёмник (интеграция с RailCraft). [*]1.7.10 Рецепты для Gregtech 6. [*]1.8+ Больше не требуется устаналивать Asielib: либа встроена в мод.

1.6.2 / 2017-02-25 Фиксы, фиксы и ещё фиксы. Фиксы крашей, фикс тихих звуков в звуковых карточках, дискеты можно теперь получить, наконец, с помощью ключа.

1.6.3 / 2017-04-21 Добавлен синтезатор речи. Так как это охрененная штука, без пинка её так просто не завести. Чтобы она работала, нужно поставить сам синтезатор речи (MaryTTS с поддержкой Forge), файл голоса и файл языка. Женский голос и английский язык, например. К счастью, эти файлы нужны только на сервере. На клиент тянуть их не нужно.
 
Работать так:
speech_box.say(text: string) -- что-то сказать.
speech_box.stop() -- остановить воспроизведение речи.
speech_box.isProcessing():boolean -- проверить, воспроизводится ли сейчас речь.
speech_box.setVolume(volume: number) -- установить громкость (от 0 до 1). Блоки теперь крафтятся не из земли и палок, наконец-то, а из чего-то повеселее. Используются предметы из OpenComputers. Динамики могут смотреть в любую из шести сторон. Директория для кассет перемещена в папку мира. При обновлении нужно перетащить её из папки кубача в папку мира, соответственно. Модуляция из-за глупой ошибки не работала вообще. Ну и ADSR не работал, если время Attack (нарастания) равно было нулю.

Как-то так. За мною остаётся ещё долг в виде продолжения обзора этого интересного модика, но всё как-то лень. Пока можно спрашивать меня, как работают вещи из CX, читать страницы в мануале и документацию к методам. Для большинства вещей этого более чем достаточно.   Have fun :P

Fingercomp

Fingercomp

 

Sound Card / как сгенерировать простой звук

Перед тем, как я начну, хочу сразу обратиться к забугорным ребятам, читающим эту запись.   Hey! If you are reading this, please tell Vexatos to document the sound card. The in-game manual page is a meaningless piece of text that explains nothing.
Documentation is written to help others to get an idea of how something works. The sound card is a complex thing that definitely needs a how-to guide to be used in programs.
So if he wants the sound card to be used in programs, he should write the proper documentation with the detailed description of each concept, feature, and component method.
The following is the result of efforts put to understand how the sound card works. It took me several months until I realized how to make a simple beep. How am I supposed to create more complex waves? >_>   Ну да ладно.  
Хей! Разбирался я недавно, как работает звуковая карта из CX, и поэтому хочу предоставить результаты своих трудов.
Как и написано сверху, доков нет, автор мода бездействует, везде уныние и отчаяние, поэтому пришлось действовать по-хардкорному. То есть чтением исходников и научнейшим тыком.   Итак, есть компьютер со звуковой картой. Нужен звук. Звучит просто, м?     Звуковая карта даёт нам замечательные функции вроде установки ADSR-огибающей, типа волны, шума простого или из LFSR, амплитудной и частотной модуляции. Но мы тут решили заняться простым звуком, поэтому всякие LFSR, AM, FM безжалостно выкидываем. Получаем такой план: Открыть канал. Поставить тип волны. Задать частоту волны. Установить громкость. Обработать.
  1. Открыть канал
Э, извините, а что за каналы?
...
В звуковой карте звук генерируется с помощью инструкций, которые выполняются друг за другом. Почти все работают с определённым каналом. Если бы канал был один, мы бы смогли играть в один момент времени только одну, условно, ноту. Чтобы параллельно шло сразу несколько звуковых волн, нужно использовать несколько каналов. На каждом можно задать свои тип и частоту волны, громкость, ADSR-огибающую. По умолчанию таких каналов в звуковой карте 8 штук.   С каналами всё довольно просто: открытый канал генерирует звук, закрытый канал не генерирует звук (правда, нужно будет здесь кое-что поправить, когда будет изучать ADSR).   Открыть канал можно с помощью функции sound.open(channel: number). Закрыть: sound.close(channel: number).   2. Поставить тип волны
Всего типов звуковая карта поддерживает пять: шум (noise), меандр (square), синусоида (sine), треугольная (triangle) и пилообразная (sawtooth).  

Waveforms ru [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0) или GFDL (http://www.gnu.org/copyleft/fdl.html)], автор Omegatron (original work)
Kirill Borisenko (Russian translation; see File:Waveforms for Cyrillic Segment.png)
Incnis Mrsi (ultimate work), с Викисклада
Очевидно, что разные типы волн звучат по-разному.   Установить тип волны можно с помощью функции sound.setWave(channel: number, type: number). Видно, что тип волны должен быть числом. Соответствующее типу волны число можно получить с помощью таблицы sound.modes. Например, sound.modes.sine или sound.modes.noise.   3. Задать частоту волны
Чем больше частота, тем выше звук. Частота 440 Hz соответствует ноте ля в первой октаве. Другие частоты можно найти по табличке на Википедии.   Используем функцию sound.setFrequency(channel: number, freq: number).   4. Установить громкость
Громкость может быть в пределах от 0 до 1 включительно. Половина максимальной громкости - 0.5. И так далее.   Функция: sound.setVolume(channel: number, volume: number).   5. Обработать
Чтобы обработать все инструкции, нужно вызвать sound.process(). Но если вы просто возьмёте и вызовете функцию, то ничего не услышите. Дело в том, что, достигнув конца инструкций, звуковая карта прекращает генерировать звук.   Поэтому нужно выставить некоторую задержку в конце всех других инструкций, чтобы звуковая карта подождала перед прекращением воспроизведения звука. Для этого служит sound.delay(delay: number). Задержка указывается в миллисекундах. Например, sound.delay(2500). При этом эта функция тоже является инструкцией, поэтому её можно выставить несколько раз. Однако если задержка превышает 5000 (5 секунд), то звуковая карта выдаст ошибку.     Проиграв несколько типов волн, мы всё равно останемся неудовлетворёнными. Ну где это видано, что звук мгновенно нарастает и затухает?
Чтобы как-то это контроллировать, мы воспользуемся ADSR-огибающей. На Википедии довольно хорошо написано, в чём смысл этого.   Скопируем сюда оттуда пикчу:

И вкратце распишем суть.
Если вы хоть когда-либо слышали музыкальные инструменты, вы могли заметить, что громкость звука со временем меняется. У гитары громкость мгновенно нарастает и постепенно затухает, а у флейты нарастает не сразу, например.
Чтобы очень-очень грубо моделировать эти инструменты, мы используем ADSR.
Attack - это время нарастания громкости звука до максимальной (последняя устанавливается через sound.volume).
Decay - время затухания сигнала сразу после достижения максимальной отметки до следующего параметра.
Sustain - отметка громкости, к которой стремится Decay. Значение 1 - это максимальная громкость звука на канале (установленная с помощью sound.setVolume), 0 - отсутствие звука вовсе.
При достижении отметки Sustain звук остаётся на этом уровне до "отпускания клавиши" (т.е. закрытия канала).
Release - время затухания сигнала после закрытия канала, от отметки Sustain до нуля.   Время везде в миллисекундах.   Попробуем? Вызываем функцию sound.setADSR(channel: number, attack: number, decay: number, sustain: number, release: number) до пятого шага. Например sound.setADSR(1, 1000, 500, 0.33, 1000).
И замечаем, что громкость меняется со временем. Yay!     На этом счастливом моменте повествование обрывается. Итоговый код, который можно запустить и послушать примитивный бип: local sound = require("component").soundsound.close(1)sound.close(2)sound.open(1)sound.setWave(1, sound.modes.sine)sound.setFrequency(1, 440)sound.setVolume(1, 1)sound.setADSR(1, 1000, 500, 0.33, 1000)sound.delay(1000)sound.open(2)sound.setWave(2, sound.modes.noise)sound.setFrequency(2, 440)sound.setVolume(2, 0.6)sound.setADSR(2, 1, 250, 0, 1)sound.delay(1500)sound.process()
К остальному, надеюсь, я ещё вернусь в другой записи. Сначала нужно самому понять, как оно работает в версии для CX.
Поэтому наслаждаться пока приходится только бибикалкой.

Fingercomp

Fingercomp

 

Палитры OpenComputers

Немногие знают, как работают палитры в OpenComputers. Расскажу здесь, как избавиться от необходимости прописывать гектары цветов в палитре, покажу, как упаковываются цвета в OpenComputers и дам пару алгоритмов для работы с индексами.   Сразу условимся, что индексы палитр у нас будут начинаться с нуля.   На каждой из трёх уровней видеокарт и мониторов своя поддерживаемая палитра цветов. Будем двигаться снизу вверх.   Первый уровень
Палитра состоит из двух цветов: чёрного и заданного в конфиге (по умолчанию белого). При конвертации цвета в индекс палитры вернётся ближайший к данному цвет из палитры.   Для определения разницы между цветами здесь и далее используется функция delta. Вот как она выглядит (вместе с функций extract, выделяющей из числа вида 0xABCDEF числа 0xAB, 0xCD, 0xEF): local function extract(color) color = color % 0x1000000 local r = math.floor(color / 0x10000) local g = math.floor((color - r * 0x10000) / 0x100) local b = color - r * 0x10000 - g * 0x100 return r, g, bendlocal function delta(color1, color2) local r1, g1, b1 = extract(color1) local r2, g2, b2 = extract(color2) local dr = r1 - r2 local dg = g1 - g2 local db = b1 - b2 return (0.2126 * dr^2 + 0.7152 * dg^2 + 0.0722 * db^2)end
Теперь можно конвертировать цвет в индекс палитры. Суть такова: выбираем из двух цветов ближайший и возвращаем его. local palette = { 0x000000, CONFIG.monochromeColor}local function t1deflate(color) -- Сначала проверяем, совпадает ли данный цвет -- с каким-либо из палитры for idx, v in pairs(palette) do if v == color then return idx end end -- Составляем таблицу разниц между цветами local deltas = {} for idx, v in pairs(palette) do table.append(deltas, {idx, delta(v, color)}) end -- Сортируем по увеличению разницы table.sort(deltas, function(a, b) return a[2] < b[2] end) -- Первый элемент будет с наимешьней разницей, -- то есть искомый. Возвращаем индекс. return deltas[1][1] - 1end
В случае с конвертацией из из индекса в цвет всё просто. local function t1inflate(index) return palette[index + 1]end
Как и говорил.  
Второй уровень
В палитре второго уровня имеется 16 закреплённых цветов: local palette = {0xFFFFFF, 0xFFCC33, 0xCC66CC, 0x6699FF, 0xFFFF33, 0x33CC33, 0xFF6699, 0x333333, 0xCCCCCC, 0x336699, 0x9933CC, 0x333399, 0x663300, 0x336600, 0xFF3333, 0x000000}
В остальном конвертация из иднекса в цвет и из цвета в иднекс аналогична алгоритмам для первого уровня. Так как они были даны в общем виде, код для них тот же самый. local t2deflate = t1deflatelocal t2inflate = t1inflate
Третий уровень
Палитра третьего уровня содержит уже 256 цветов: первые 16 цветов изменяются, а остальные соответствуют цветам палитры RGB-6-8-5. Это означает, что можно смешивать 6 оттенков красного, 8 оттенков зелёного и 5 оттенков синего. В общем-то, довольно очевидна причина такого выбора: человеческий глаз лучше всего различает оттенки зелёного и хуже всего - оттенки синего.  
В любом случае, здесь алгоритмец будет посложнее. Сначала нужно сгенерировать палитру.
Начнём с первых 16 цветов. Они не включаются в палитру RGB-6-8-5, поэтому их заполнять нужно отдельно. В OpenComputers по умолчанию они содержат оттенки серого. Так как чёрный и белый уже включены в основную, зафиксированную палитру, то заново их дублировать смысла нет. local palette = {}-- grayscalefor i = 1, 16, 1 do palette[i] = 0xFF * i / (16 + 1) * 0x10101end
Таким образом в таблице получаются следующие оттенки серого: 0x0F, 0x1E, 0x2D, 0x3C, 0x4B, 0x5A, 0x69, 0x78,0x87, 0x96, 0xA5, 0xB4, 0xC3, 0xD2, 0xE1, 0xF0
Эти цвета мы записываем в индексы от 0 до 15. Теперь нужно сгенерировать остальные цвета - они не изменяются. Здесь будет посложнее.
Посмотрим на картинку с палитрой:

В OpenComputers левая верхняя ячейка палитры (0x000000) имеет индекс 16, а правая нижняя (0xFFFFFF) имеет индекс 255. Индексы распределяются слева направо, сверху вниз. То есть правая верхняя ячейка (0x00FFFF) имеет индекс 55, а вторая сверху и левая (0x330000) - это номер 56. Отсюда вытекает следующий алгоритм нахождения цвета: сначала найти индексы отдельно по R, G, B, затем для каждого из этих трёх индексов найти соответствующий ему оттенок цвета, а затем всё сложить. for idx = 16, 255, 1 do local i = idx - 16 local iB = i % 5 local iG = (i / 5) % 8 local iR = (i / 5 / 8) % 6 local r = math.floor(iR * 0xFF / (6 - 1) + 0.5) local g = math.floor(iG * 0xFF / (8 - 1) + 0.5) local b = math.floor(iB * 0xFF / (5 - 1) + 0.5) palette[idx + 1] = r * 0x10000 + g * 0x100 + bend
К слову сказать, math.floor(x + 0.5) - это округление до ближайшего целого.  
Всё. Палитра есть, теперь можно, наконец-то, конвертировать индексы между цветами.
Из индексов получить цвет довольно просто. Достаточно использовать ту же функцию, что и для предыдущих уровней: t3inflate = t2inflate
С обратной же конвертацией всё в разы сложнее. Функция, используемая в OC, подбирает ближайший цвет очень хитрым алгоритмом, который я привожу ниже. local function t3deflate(color) local paletteIndex = t2deflate(color) -- Если цвет из палитры, то используем значение выше for k, v in pairs(palette) do if v == color then return paletteIndex end end -- Иначе используем хитромудрый код local r, g, b = extract(color) local idxR = math.floor(r * (6 - 1) / 0xFF + 0.5) local idxG = math.floor(g * (8 - 1) / 0xFF + 0.5) local idxB = math.floor(b * (5 - 1) / 0xFF + 0.5) local deflated = 16 + idxR * 8 * 5 + idxG * 5 + idxB if (delta(t3inflate(deflated % 0x100), color) < delta(t3inflate(paletteIndex & 0x100), color)) then return deflated else return paletteIndex endend
В общем-то, это всё. Показал портированный со Scala на Lua код, который используется в OpenComputers. С помощью этого можно оптимизировать операции с экраном, выбирая поддерживаемые монитором цвета. И заодно избавиться от таблиц цветов, которые некоторые буквально берут и копипастят в файл, даже не задумываясь об изменяемых цветах палитры.
Особенно это важно, когда берётся значение цвета через gpu.get, потому что следующий код всегда вернёт false: local gpu = require("component").gpugpu.setForeground(0x20AFFF)gpu.setBackground(0x20AFFF)gpu.set(1, 1, "HI")return select(2, gpu.get(1, 1)) == 0x20AFFF
И всё потому, что gpu.get возвращает уже приведённый к индексу из палитры цвет. А 0x20AFFF в палитре, если не менять первые 16 цветов, не имеется.  
Enjoy :P

Fingercomp

Fingercomp

 

Что такое IRC

Сегодня нашему каналу в 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 следует вечная блокировка возможности отправить сообщения.
Но и без войса можно просто сидеть и читать чат.   В целом, это всё, что я хотел сюда написать. Ждём на наших каналах — подключайтесь, у нас есть печеньки.

Fingercomp

Fingercomp

 

OpenComputers 1.6.2

Вышла новая версия OpenComputers, в основном с самыми разными фиксами. Что изменилось: Моды теперь могут добавлять свои кастомные дискеты, которые можно получить перекрафтом их с ключом. (Vexatos) Две функции дебаг-карты: для отправки сообщения на другую дебаг-карту и отправки текста в буфер обмена какого-либо игрока. Опасная штука. (Vexatos) Когда роботы/дроны выкидывают что-либо в мир, они теперь посылают ивент. (Sangar) Добавлен новый предмет — MFU. Позволяет подключить к адаптеру любой блок, находящийся на удалении нескольких блоков. Это позволяет небольшие билды сделать красивее, а сложные схемы — удобнее. (Vexatos) Обновлён перевод на немецкий. (Vexatos) Обновлены LuaJ и JNLua — заявляется, что теперь всё лучше с UTF-8. (gamax92, Sangar) Обновление OpenOS. Как обычно, много изменений, но здесь опять уменьшение потребление памяти и увеличение производительности. (payonel) Дискета oppm теперь использует современные способы установки в OpenOS. А ещё программу обновили. (Vexatos) Обновление Plan9k. (magik6k) В планшетах не работал слот для карт, если было вставлено улучшение. (Vexatos) Очень труднонаходимый баг с экранами, которые после перезагрузки чанка (причём особенного) зависали, был ликвидирован. (Sangar) Больше не получится много раз потыкать ключом по дрону, чтобы получить большее их количество. (Vexatos) Устранены проблемы с вайлой (очень странная логика у неё) (Sangar) [MC 1.8.9+] При выкидывании предметов роботами или дронами некоторые уничтожались. (Vexatos) [MC 1.8.9+] Краш при использовании функции getName на нанонашинах. (Vexatos) [MC 1.9.4+] Компоненты могли не деинициализироваться, когда чанк с ними выгружался. Это приводило, например, к смене UUID компонентов. (Sangar) [MC 1.9.4+] Починили рендер клавиатуры. (Vexatos) [MC 1.9.4+] Команды ломали /help. (Vexatos) [MC 1.9.4+] В наномашинах не было эффектов зелий. (Vexatos) [MC 1.10.2+] Улучшена интеграция с JEI. (Vexatos)

Релиз на GitHub.

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 в зависимости от программы, которую требуется запустить.

Fingercomp

Fingercomp

 

OpenComputers 1.6.1

Новая версия! Новое: Можно теперь отключать некоторые стороны адаптера с помощью ключа. Очень нужная фича, если требуется контроль в огромном лагодроме. От 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: после апгрейда все стороны адаптеров в прежнем мире становились отключенными.


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

Fingercomp

Fingercomp

 

Advanced Term [OpenOS 1.6]

Тут полгода назад я описывал изменения в 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

Fingercomp

Fingercomp

 

OpenComputers 1.6.0 Release

Добавлено Версия дисковода гибких дисков (дискет, если что) для серверов. Возможность взаимодействовать с некоторыми хранилищами предметов с помощью контроллера инвентаря (не особо понял, что тут нового. Видимо, новые инвентари или черех адаптер). Поддержка энергии 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, пару изменений ещё только.   Здесь оригинал списка гигантского и ссылки на скачивание.
У меня есть несколько записей, посвящённых обновлениям в этой версии. Если ещё их не читали, рекомендую ознакомиться.

Fingercomp

Fingercomp

 

Парсер CSV

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. Можете качать и радоваться. Вот сырцы.   Ну и надеюсь, это было менее сложно, чем мои записи про пакетные менеджеры до этого, и вы смогли прочитать это .

Fingercomp

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.   .

Fingercomp

Fingercomp

 

Разрешение зависимостей в пакетном менеджере

Раз уж я тут пишу понемногу свой крутой пакетный манагёр, расскажу о пакетных менеджерах немного.   Пакетный менеджер — штука сложная. Потому что, хотя задача у него, в общем-то, одна — менеджировать пакеты — сюда включается и установка, и удаление, и обновление, и, вообще, много всякого. Но а так как пока сам не напишешь, ПМ не поймёшь, здесь расскажу об установке пакетов и зависимостей с кодом.   Ещё немного предисловий, о зависимостях. Это ключевая фича ПМ: вы-то прогу скопировать/разархировать и сами можете, вот только если программа зависит от другой, а та — от двух других, и т. д., вам это надоест. Людям надоело. Создали пакетные менеджеры. Теперь программы пакуются в пакеты — а рядом со скомпилированными бинарниками лежит ещё кусок информации: имя пакета, версии, зависимости, авторы, изменения и много-много всяких других полей. При установке данные считываются и далее уже делается, что сказано. Зависимости ли ставятся, ещё ли что-нибудь.   А затем пакетов становится много, появляются репозитории полноценные, ну и так далее.   Итак, давайте сделаем программу для установки пакетов. Ну, почти. Именно полезной нагрузки как таковой не будет, будем использовать такую структуру информации о пакете (назовём это манифестом пакета): { "name": "имя пакета", "files": [ { "url": "http://example.com/bin-1", "path": "/usr/bin/program1" } , { "url": "http://example.com/library-1.so", "path": "/usr/lib/library1.so" } ]}
Пока без зависимостей, всё просто.  
Вот такой код получим: def install(name): # получаем манифест пакета с данным именем manifest = getManifest(name) # проходимся по файлам... for file in manifest["files"]: # ...скачиваем и ставим их в нужные места download(url=file["url"], path=file["path"])
Ничего примечательного, на самом деле. Получаем манифест, скачиваем файлы и пишем "тадаам".  
Давайте сделаем вот такие манифесты: { "name": "pkg1" # имя пакета, "deps": # зависимости [ { "name": "pkg1-1" } , { "name": "pkg1-2" } ], "files": [ { "url": "http://example.com/pkg1/file", "path": "/opt/pkg1/file" } ]} { "name": "pkg1-1", "deps": [ { "name": "pkg1-1-1" } ], "files": [ { "url": "http://example.com/pkg1-1/file1", "path": "/opt/pkg1-1/file1" } , { "url": "http://example.com/pkg1-1/file2", "path": "/opt/pkg1-1/file2" } ]} { "name": "pkg1-1-1", "deps": [], "files": [ { "url": "http://example.com/pkg1-1-1/file", "path": "/opt/pkg1-1-1/file" } ] { "name": "pkg1-2", "deps": [], "files": [ { "url": "http://example.com/pkg1-2/file1", "path": "/opt/pkg1-2/file1" } , { "url": "http://example.com/pkg1-2/file2", "path": "/opt/pkg1-2/file2" } ]}
У нас есть 4 пакета: pkg1, pkg1-1, pkg1-1-1, pkg1-2. Вот граф зависимостей:                    
Очевидно, что просто так теперь тут в рандомном порядке пакеты поставить нельзя. Так как при установке пакета, например, pkg1-1, он совершенно справедливо считает, что его зависимость, pkg1-1-1, уже установлена.   То есть, по-хорошему, нам надо сначала брать пакеты без неразрешённых зависимостей, и подниматься вверх. Однако, есть идея покруче.   Я сейчас наваяю рекурсивную функцию resolveDeps, которая будет, как ни странно, разрешать зависимости: def resolveDeps(name): result = [] # результатирующая последовательность установки пакетов manifest = getManifest(name) for dep in manifest["deps"]: # В Python справедливен код типа `[1, 2, 3] + [4, 5, 6] == [1, 2, 3, 4, 5, 6]`, т.е. склеиваение списков. result = resolveDeps(dep["name"]) + result return result
Если мы дадим ей манифесты, она выдаст вот такой список: ["pkg1-1-1", "pkg1-1", "pkg1-2", "pkg1"] — от менее сложного к более сложному. То, что нужно. Затем мы ставим просто их: for pkg in resolveDeps("pkg1"): install(pkg)
Давайте улучшим алгоритм. Сделаем проверку на установленность: нам ведь не надо повторно скачивать файлы, которые уже есть. def resolveDeps(name): result = [] # Проверяем, установлен ли пакет if not isInstalled(name): manifest = getManifest(name) for dep in manifest["deps"]: result = resolveDeps(dep["name"]) + result return result
Если у нас уже поставлен pkg1-1, то получим всего лишь ["pkg1-2", "pkg1"]. Круто!  
Возьмём другой граф:      

Как видно, от pkg1-1-1 зависят сразу 2 пакета: pkg1-1 и pkg1-2. Проблема в том, что на выходе у нас будет ["pkg1-1-1", "pkg1-1-1", "pkg1-1", "pkg1-2", "pkg1"] — ни разу не то, что мы хотели. Давайте это исправим: def resolveDeps(name, resolved=None): resolved = resolved or [] # список уже разрешённых пакетов if name in resolved: # Пакет уже был разрешён, ничего больше не требуется return resolved if not isInstalled(name): manifest = getManifest(name) for dep in manifest["deps"]: resolveDeps(dep["name"], resolved) # Теперь список один на всю рекурсию resolved.append(name) # Без рекурсии сюда попасть можно, если пакет не имеет неустановленных зависимостей return resolved
Теперь выхлоп у нас ["pkg1-1-1", "pkg1-1", "pkg1-2", "pkg1"] — как и предписывали.  
А вот вам ещё граф:      
 
Какая тут засада? А у нас дерево циркулярное — не руки циркуляркой отрезает, а в бесконечную рекурсию вводит. Вот как можно этого избежать: def resolveDeps(name, resolved=None, unresolved=None): resolved = resolved or [] unresolved = unresolved or [] # список ещё не разрешённых пакетов if name in unresolved: # Мы попали сюда через рекурсию. Когда-то пакет уже был добавлен в список 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["name"], resolved, unresolved) # даём unresolved resolved.append(name) # Не забываем убирать из списка del unresolved[unresoved.index(name)] return resolved
Теперь у нас в данном графе будет сгенерировано исключение, а потому рекурсии бесконечной не произойдёт.  
Итак, у нас есть простая функция, которая составляет список пакетов для последовательной установки без ломаний. Это уже круто, но время шло, и появилось такое явление как версии. Впрочем, об этом поговорим в другой раз. Там есть свои заморочки, с которыми нужно разобраться.   Вот похожая статья, но на английском. Рекомендую ознакомиться.   Лицензия: CreativeCommons Attribution-NonCommercial 4.0 International License

Fingercomp

Fingercomp

 

BuMPGold // завершён

Здрассьте!
Я тут прогуливался по 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 Будем, как обычно, рады ответить и помочь.   Удачи!

Fingercomp

Fingercomp

 

MoonJam — джем с привкусом луны // завершён

Лого от 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 завершился!      

Fingercomp

Fingercomp

 

[Moonscript] Библиотека SemVer

Имеется один проект на Питоне, который потребовал для себя парсер семантического версионирования, семвера, в общем. Ну там такие штуки как парсинг версий человеческий, обработка ввода юзверёв, умение сравнить все эти версии и выбрать из списка по указателю типа ">=1.5.17", ну, думаю, об этом вы слышали.
К слову, вот тута лежит спецификация SemVer: http://semver.org/, можете почитать.   Ну и нашёл я либу интересную, semantic_version зовётся. Подключил и нарадоваться не мог фичам всяким. И там пирожки, и здесь пэнкейки, в общем, использовалась весело и радостно.   В рамках того же проекта ещё умещался репозиторий на мункрипте, который мункриптил очень важные дела, и ему тоже нужен был парсер. Без промедления открыл файлик того парсера, и спустя два вечера этот парсер был успешно портирован на Мункрипт, при всём при этом он даже работал! D:
Ну, как минимум, насколько хватило желания протестить.   Так что вот как-то так у нас всё получилось, я по-быстрому ознакомился с лицензией тех ребят, оформил всё более-менее и пихнул в свою репу на OpenPrograms.   Потому если интересно будет когда-нибудь решить вопрос с версиями, то милости просим использовать либу libsemver, для OC её можно скачать с помощью OPPM: oppm install libsemver.   Документации для либы этой именно я не писал, ибо она работает на 99% так же, как и оригинал. Потому вся инфа здесь: https://python-semanticversion.readthedocs.io/en/latest/   А, ну и мой отзыв по поводу мункрипта: язык этот сумасшедший, но норм, писать можно. Ознакомиться с ним лишним явно не будет, так что осаждайте референс языка.
Удачи!

Fingercomp

Fingercomp

 

[OC Updates] Обновление OpenComputers до версии 1.6.0 Beta 4

Недавно вышло мелкое обновление OC, которое я пропустил из-за некоторых проблем, и в нём: ДобавленоИнтернет-карты посылают событие, когда они получили данные по сокету и можно использовать :read.
[*]Пофикшено Несколько мелких багов.
[*]OpenOS Небольшие фиксы install, /lib/buffer.lua, ls, /lib/package.lua, rc, /lib/sh.lua.


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

Fingercomp

Fingercomp

 

[OC Updates] Обновление OpenComputers до версии 1.6.0 Beta 3

Обновление OpenComputers до третьей беты 1.6. Сегодня в гостях у нас следующие изменения: Добавлено В русский мануал добавлена информация про saveConfiguration (PR #1855 от cyber01). Функция computer.getProgramLocations, которая используется для программы install из OpenOS.
[*]Пофикшено Неожиданный баг с сохранением мира в версиях MC выше 1.8.
[*]OpenOS Команда cat теперь будет читать stdin, если не указан файл. cp: поддержка путей вида /. и более мелкие фиксы. df теперь поддерживает относительные пути. Функция next либы /lib/guid.lua теперь возвращает GUID в корректном формате. head теперь закрывает stdin. install был сильно переработан и теперь с помощью этой программы можно устанавливать файлы с loot-дискет (и не только), мануал в man install. less теперь поддерживает скроллинг, в кои-то веки! Ну и алиас в /etc/profile был, конечно, убран. В mv добавлено несколько проверок: команда будет выдавать теперь ошибку, если путь назначения в режиме только для чтения или путь имени для копирования — точка монтирования. У rm была пофикшена проблема, при которой ссылки на директории не могли быть удалены. Шелл поддерживает экранировку пробелов и может отдавать сигнал SIGPIPE. А ещё позволяет использовать getWorkingDirectory до установки переменной окружения PWD.


На момент писания этого текста в install был уже обнаружен один баг, который даже пофикшен, остаётся ждать принятия PR.   Github

Fingercomp

Fingercomp

×