LINUX.ORG.RU

Избранные сообщения mtk

mcu-info-util

Форум — Talks

Как уже я здесь немного говорил, я разрабатываю архиполезную (на мой взгляд) утилиту mcu-info-util. Она OpenSource, написана на Python и нативно работает под Linux.

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

  • Находить компиляторы avr-gcc и arm-none-eabi (актуально для Windows, утилита ищет в реестре некоторые ключи, которые туда пишут установщики соответствующих тулчайнов, также производится поиск в PATH, для Linux только поиск PATH).
  • Подсказывать ключи, которые нужно передать компилятору и линковщику, чтобы успешно скомпилировать проект под целевой микроконтроллер (и если для AVR это всего лишь -mmcu=..., то для ARM всевозможные указания версии cortex, наличия модуля аппаратной математики и т. д.).
  • Генерировать скрипт линковки для ARM. Больше не нужно писать свой скрипт или искать готовый - достаточно названия микроконтроллера (например, STM32F103C8T6) и утилита создаст подходящий скрипт линковки.
  • Генерировать заголовочный файл с описанием регистров периферии выбранного микроконтроллера (в настоящий момент только для ARM, используется информация из файлов SVD, включённых в комплект поставки). Не нужно при использовании libopencm3 или CMSIS, но никто и не заставляет использовать.

Например, мы хотим собрать прошивку под микроконтроллер STM32F103C8T6:

$ mcu-info-util --mcu stm32f103c8t6 --find-compiler
/usr/bin/arm-none-eabi-gcc
$ mcu-info-util --mcu stm32f103c8t6 --print-flags
-D_ROM=65536 -D_RAM=20480 -D_ROM_OFF=0x08000000 -D_RAM_OFF=0x20000000 -mcpu=cortex-m3 -mthumb -DSTM32F1 -msoft-float
$ mcu-info-util --mcu stm32f103c8t6 --linker-script script.ld
$ mcu-info-util --mcu stm32f103c8t6 --header mcudefs.h

Разумеется, было бы разумно использовать mcu-info-util не самостоятельно, а внутри скриптов сборки. На этот случай я приготовил пару примеров - для make и для cmake в каталоге misc репозитория проекта.

Таким образом Makefile проекта может выглядеть как-то так (разумеется, проект будет поддерживать инкрементальную компиляцию с отслеживанием зависимостей исходных файлов) - https://github.com/KivApple/mcu-info-util/blob/master/misc/makefile-project/M...

А проект CMake как-то так - https://github.com/KivApple/mcu-info-util/blob/master/misc/cmake-project/CMak....

Выбор используемого микроконтроллера осуществляется всего лишь одной переменной - MCU. Скрипты произведут серию обращений к mcu-info-util, в итоге будет найден (если установлен) необходимый компилятор, флаги компиляции и при необходимости сгенерирован скрипт линковщика и заголовочный файл с описаниями регистров.

Согласитесь, это гораздо удобнее хардкода размеров ОЗУ и ПЗУ, путей к компилятору (в настройках IDE) и т. д. Функционал подобного уровня (выбор МК по названию и автонастройка проекта под него) предоставляют лишь коммерческие IDE, а моё решение не имеет каких-либо привязок. Вы можете использовать в своём проекте любые библиотеки (скажем, подключить исходники какой-нибудь RTOS), писать код в любой IDE (нужна лишь поддержка Makefile или CMake, либо возможность скриптовать систему сборки и прямые руки), данная утилита лишь берёт на себя необходимую рутину по выбору необходимого компилятора и флагов компиляции без которых проект банально не заработает.

В настоящий момент имеется поддержка только микроконтроллеров STM32 и AVR (также теоретически может нормально заработать для ARM от Atmel).

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

 ,

KivApple ()

Open hardware STM32 MP3 player

Форум — Talks

Hello!

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

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

После долгих поисков я остановился на кодеке VS1053. Он был оптимальным по соотношению цена/качество*фичи. После первых тестов я понял, что он офигенен: качество звука на высоте, огромный подробный даташит, множество поддерживаемых форматов и простота работы с ним.

Итак, я начал работы. Собрал макет и стал писать программу.

На макете присутствовал сам кодек на отладочной платке с алиекспресса, MCU - stm32f103cbt6(было достаточно ножек и был в наличии в ближайшем чипдипе)(плату развёл и сделал сам фотки), eeprom(24lc256 - самая дешёвая), уродливый разъём для microsd карточки(внутренний еврей не позволил покупать разъём для макета за 150 рублей. В итоге на макете частоту SDIO пришлось снизить, но на это повлияли больше длинные провода, чем разъём), OLED 0.96" дисплей на контроллере SSD1306(просто обожаю чб олед дисплеи(они няяяшные)) и самодельная 12ти кнопочная клавиатурка.

Фотки макета: https://imgur.com/a/TvJSv

На ютубе можно посмотреть видео с самых первых этапов разработки(тогда даже не была написана система и не был допилен гуй): https://www.youtube.com/channel/UC5pY283jfYVHqjVQ8bXEKBQ

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

В это же время я рисовал схему и разводил плату. В итоге вышло так: фото разводки 1 фото разводки 2 ещё фотки разводки и схема.

Заказать детали для плеера и плату с завода предприятие, где я сейчас подрабатываю. В итоге я получил такую красоту: https://imgur.com/a/w70eH

И всё вместе собрал: https://imgur.com/a/paefn

Нооо... В разводке нашлись ошибки(не принципиальные, но всё же. Это была первая такая сложная плата). Но всё заработало просто великолепно! Даже играло музыку. Почти. Я забыл в схеме сделать фильтр на выходе кодека и допаял его сверху на самой плате. И видимо в результате отладки бедная микросхемка, наверное, сгорела(но лишь наполовину. По SPI она отвечает, говорит и даже, якобы, воспроизводит музыку, хотя на выходе тишина).

Но в итоге я очень расстроился и бросил это дело. Даже не записал ни одно видео работы =с

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

Все исходники: схемы, разводки(KiCad), программа для MCU(в Keil uVizion) и библиотеки лежат тут: https://github.com/SL-RU/sdmplayer

Спасибо за внимание.

 , , ,

SL_RU ()

Пьеса «Тред на ЛОРе», в одно действие.

Форум — Talks

по мотивам Ищу гуру Си программирования

Входит Вопрощающий:

Всем привет.
Есть тут свободные полгода
В которые хотел бы я программы изучать,
Даю вам это знать.
Пока что начал только Java лишь учить
По книге, впрочем, и дошёл до ООП,
Вы подскажите, это правильно, иль надобно тем книгам сгнить?
Хотел бы выбрать я ЯП и направление,
Что позволяло бы работать на фрилансе,
А также, у людей чтоб вызывалось изумление.

Входит ЛОРовец:
Двадцатник баксов в час, или забудь о нас

Входит Новенький:
You're welcome.
Давай свои контакты - отпишу.
Ведь мне не жалко помогать, один чёрт одиночество последнее недели
Так разъедает душу мне, что еле я дышу.

Входит Наркоман:
K&R расскажет, и покажет
Тебе всё милый друг,
Ну а коль что вдруг непонятно станет, то значит в голове недуг.
Ведь суть проста: конструкций мало, новых слов десятка два.
И сей язык освоишь быстро.
Хочу предупредить я, правда, что сам язык не цель твоя,
Ведь цель должна учится на ошибках.
Важнее знать не то, что как вам делать сударь,
Важнее путь тернистый, полный ям, и отроколов
Вам пройти и знать тропинку по которой надобно идти таким путем
Чтобы все ямки обойти.
И к сожаленью, или, может, к счастью, тропинку ту лишь одному тебе дано найти.
Ведь мудрый путник лишь укажет, в какую можно сторону идти.

Входит Зевака:
Внесите царя.

Входит Лавсан:
Я хоть не Царь, но знаю всё про Си, давай, спроси

Вопрощающий:
Жду контакта.

Входит Некто:
Будут вопросы - кастуй, или пиши на мыло.
И мыло можно, если что, найти в LKML и ffmpeg-develop.

Входит Царь:
О Наркоман, а почему нули,
Которые смешать с навозом в три счета,
Так много кукарекают о том, о чем не понимают ничерта?

И ладно, я бы понял, если ты бы что-то мог,
Но тыж не смог, дак почему ж несмогший путник,
Который тонет в луже иль болоте,
Иль где-то на задворках недовуза, тот пыжиться кого-то направлять?
Куда ты их направишь? Ты желаешь, их повернуть развитие всё вспять?
Ведь что ты можешь,
Как кроме повторять приевшиеся шутки,
и предлагать приевшиеся книжки,
Ответь, мальчишка?
И удиви меня своим вопросом.

Вопрощающий:
Увы, нет у меня таких вопросов
(И тут же поникает носом)

Входит Эдди: (лавсану)
Ты царь?

Лавсан:
Кто такой царь?

Новенький (лавсану):
Он твой последователь.
Вон, четырьмя постами выше.
И, потише,
Сейчас начнется развлеченье.

Эдди (лавсану):
А, раз не царь ты, то ведь Си не знаешь!
К тому же, зачем еще и о Царе тут вопрошаешь?

Царь (вопрошающему):
Причем тут удивительные.
Когда хотите вы спросить что-либо, то естественно,
Что на пространные вопросы,
Не менее пространные я буду вынужден вам отвечать ответы,
Поймите ж это.

Поэтому, Царя должны вы право заинтриговать,
Чтобы смог он для себя обосновать
Полезность траты времени на ху**оса.
Вот смысл моего вопроса.
Зачем царю писать куда-то, без причины?
Не есть ли это признак вроде Эдди дурачины?

Входит Аноним:
Какое-то собранье зебр в треде.
И странно, все стихами говорят.
Похоже, что попал я в Ад.

ЗАНАВЕС.

 ,

lovesan ()

Напутствие в трудной жизни.

Форум — Development

Дисклеймер. Этот пост всесторонне вдохновлен каким-то древним видео в интернете, автора которого я благополучно забыл. Если автор сейчас читает это - респект тебе и увага, бро!

Итак.

Помойму программисты сильно перегибают палку.

Засрали всю джаву мусором.

Хотите вы бин, и что-то в нем хранить тупо, сделайте все поля public! Вместо лесов геттеров-сеттеров.

Боитесь, что такой класс (с пабликами) будет не thread-safe и хомяки не смогут писать с ним хороший многопоточный код? Да побойтесь б-га, хомяки вообще не напишут хорошего многопоточного кода, всё это миф. Дайте среднестатистическому человеку треды и локи, и он напишет код в миллион раз более медленный, чем аналогичный на готовом TransferQueue. Вот и пишите свой продюсер-консумер на TransferQueue, не выпендривайтесь.

ООП, и конкретно механизм наследования, очень плохо подходит для увеличения реюзабельности кода. Глупому заказчику можно втирать рекламу ООП=реюзабельность, но мы тут все грамотные люди, линуксоиды, как минимум с 8 классами образования, мы же все понимаем как оно на самом деле. Трейты/миксины и препроцессор и то с этим лучше справляются иногда.

Но сидят сумрачные гении, и ночами напролет пишут какие-то иерархии классов, чтобы одну строчку копипасты сэкономить. Всё это фигня! В такой надуманной иерархии классов еще сложней разобраться, чем отрефакторить копипасту. И уж точно ее сложнее модифицировать. Мой совет: копипастите смело и открыто! Если коллеги будут придираться, спокойным голосом, глядя на правое ухо поциента, говорите: «вот сам и поправь», 90% что коллега посинеет от страха и сдрыснет в ужасе, в остальные 10% можно утешаться тем, что эту лажу писать пришлось хотя бы не тебе.

Никто не заставляет писать Factory которые производят Factory, которые производят Factory! Хочешь посмотреть, откуда берется объект, а там целый стектрейс на 50 этажей, можно блуждать пока не умрешь от голоду. Хотите сделать объект - ставите new и поехали. Сразу понятно - вот тут делается объект. Фактори нужно изничтожать безбожно (только если это не Spring, Spring надо пожалеть).

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

Никаких фреймворков! Ехал фреймворк через фреймворк, и все - говно. Каждый день кто-то еще производит новый фреймворк. Потом набигают ПМы-хипстеры и такие, а что у нас популярно? Ахххаха, гороскоп показывает, что в эту фазу луны популярен Wicket, давайте нафигачим на нем гуй для Международной Космической Станции. Потом где-то там эта чушка не распарсила XML, свалилась в корку обосравшись стектрейсами, и все космонавты сварились. Отлично! Зато фреймворк!

Особенно радуют люди, которые боятся эти фреймворки чинить. Ололо, всё работает через задницу, но трогать не будем. Потому что - потом поддерживать же свой «форк» надо! Лучше нагородим еще костылей вокруг кривого фреймворка! Мотивируется это тем, что «на дальней дистанции» хомякам проще будет писать костыли, чем фиксить фреймворк. Но это ложь, через пару лет развития проекта уже совсем в этих костылях не разобраться. Совет тут такой: не использовать фреймворков, а если использовать - то понимать как они работают, и чистой душой фиксить их, а коммиты стараться засылать в апстрим.

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

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

Самая жуть, это всякие ынтерпрайзные сервера, портлеты, фигеты, шушпанчики. Вот притащил ты себе в проект WebLogic или еще какой-нибудь архитектурно-окаменевший кусок, и что изменилось? Кстати, вы видели чтобы на одном реальном хайлоадном сервере запускалось больше одного приложения? Обычно бывает как раз наоборот - на куче серверов запускается ОДНО приложение! А сколько бед от этой псевдофункциональности по огранизации шаред хостинга! Что ынтерпрайзные сервера лучше делают, чем Jetty запущенная прямо из функции main? Собственно в этом и совет, запускайте джетти откуда-нибудь руками, или из мавена, и не парьте мозг.

Надо писать так, чтобы код отражал СУТЬ. Чтобы деплой отражал СМЫСЛ. Посмотрел на код - и сразу понятно, что там написано. Запустил сервер - и сразу понятно, что и как он обслуживает, где скачать его исходники и пофиксить, если чо.

Если вы последовали перечисленным советам, но вас никто не понимает, скажите что stevejobs с лора разрешил.

В общем, идея понятна, теперь можно приступать к критике :)

Привет.

 

stevejobs ()

Boost что за зверь такой?

Форум — Talks

На самом деле мне всё равно что это за хреновина, которая собирается очень долго и требует много места, в процессе сборки покрайней мере. Как какой-то gcc или firefox.

Удручает, что эту хреновину теперь используют в моих mpd и ncmpcpp, пришлось откатиться до версии 0.18.21 и 0.5.10 соответственно. И это навсегда. Козлячие, загубили своими инновациями самый лучший консольный аудиоплеер!

Перемещено mono из development

 ,

Spoofing ()

reddit что и где читать?

Форум — Talks

Сабж. Поделитесь интересными подреддитами (а заодно и их тематикой).

 

nagibator ()

Sun-ch

Форум — Talks

В общем, друзья. Мне стоит вам сознаться в одной интересной вещи. Видимо, Sun--ch и я - это одно и тоже лицо.

 

pacify ()

Серия тем Pro для Awesome

Галерея — Скриншоты

Панель Awesome можно кастомизировать довольно сильно, вы практически ничем (кроме некоторых багов) не ограничены, любые изображения, виджеты, многое можно интегрировать.

Сейчас серия состоит из 2 тем в двух вариантах, два варианта тёмной (v1 и v2) и два варианта светлой темы v3.

На скриншоте тема v1, также посмотрите другие:

Под «Pro» имеется в виду подражание интерфейсам профессиональных (индустриальных) приложений.

На скриншоте панель, слева направо:

  • Taglist, иконки вместо символов, бирюзовый типа светодиод это активный тег, темные - пустые, светлые - занятые, а также красный urgent.
  • Tasklist, иконки отключены, активная вкладка чуть светлее остальных, так же еле заметный красный оттенок имеет urgent вкладка.
  • Трей, в нём parcellite.
  • Интегрирован MPD плеер, кнопки управления (они же на хоткеях, разумеется), а также отображение текущего трека. При паузе кнопка Play сменяется на паузу, при остановке проигрывания - дисплей статуса трека исчезает вовсе.
  • Виджеты почты (к-во новых входящих Gmail), CPU, RAM, SDD, Down/Up скорость инета.
  • Виджет часы, при клике на который он сменяется на виджет календарь с текущей датой и днем недели.
  • Виджет лейаутов.

Тому, кому возможно тема понравится и рискнет себе запилить, нужно иметь в виду некоторые моменты.

Конфиги здесь.

>>> Просмотр (1680x1050, 1380 Kb)

 , ,

vim ()

RFC HOWTO: автологин в иксовую сессию с помощью systemd

Форум — General

Добрый вечер, господа. Это тред-howto о том, как сделать корректный автологин в иксы «на чистом systemd». В вики мне писать влом, да и никто её не читает, а тут и теги указать можно, и людей скастовать. Собственно, да: border-radius, ecko.

В чём вообще проблема? Проблема в том, что значительное количество людей делают это через банальнейшие костыли, настраивая автологин в текстовую консоль и запуская иксы из bashrc (или, чего хуже, из bash_profile). Это плохо по трём причинам:

  • не залогиниться в другую физическую консоль в текстовом режиме
  • оверхед на проделывание цепочки такого вида:
    systemd
    /bin/agetty
    /bin/login
    PAM
    /bin/bash
    ~/.bashrc
    /bin/startx
    
  • в конце концов, это само по себе костыль.

Я предлагаю написать getty-подобный юнит, который будет запускать иксы от фиксированного пользователя с фиксированным номером дисплея на произвольном VT. (Почему так много хардкода? Потому что systemd — не дисплейный менеджер.)

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

Параграф один. logind, autovt и getty-подобные юниты. Getty могут запускаться двумя способами.

  • Первый — по требованию, через logind. При переключении на ttyN logind запускает юнит autovt@ttyN.service, который засимлинкен на getty@.service. Эта логика работает для tty2-tty6.
  • Второй — статически. Юнит getty@tty1.service включен по умолчанию и втягивается через getty.target. Это даёт нам всегда запущенный getty на tty1.

Соответственно, допустим, у нас есть юнит xorg@.service, который запускает иксы на указанном VT.
Его нужно либо симлинкнуть под именем autovt@ttyN.service, переопределив шаблонный юнит (тогда при переключении на выбранный VT иксы будут запускаться вместо getty — первый способ), либо отключить getty@tty1.service и включить вместо него xorg@tty1.service (тогда мы вместо всегда запущенного getty будем иметь всегда запущенные иксы — второй способ).

Параграф два. Xorg вместо getty. Итак, имеем юнит для иксов, написанный по аналогии с getty@.service: /etc/systemd/system/xorg@.service.

User=<впишитеюзера>
PAMName=login

-- это аналог su.

Conflicts=getty@%i.service
After=getty@%i.service

-- это некоторая защита от одновременного запуска getty на том же терминале.

StandardOutput=tty
StandardInput=tty-fail

-- это указание systemd запускать иксы подсоединёнными напрямую к терминалу, а не к логгеру (нужно для того, чтобы иксы можно было запускать не от рута... ах да, работает только с 1.16 и выше).

ExecStart=/etc/systemd/scripts/startx -D :0

-- это мой велосипед вместо startx с нескучным синтаксисом и exec xinit в конце, что важнее.

Дело в том, что systemd из-за вероятного бага при остановке юнита отправляет SIGTERM/SIGKILL не всем процессам в дереве, начиная с startx, а только самому startx. А поскольку он написан на шелле, то он радостно игнорирует SIGTERM и ждёт завершения xinit, которому никакого сигнала не приходит. Следовательно, проблему решаем переписыванием startx так, чтобы он в конце не запускал xinit подпроцессом, а делал exec xinit, заменяя им собственный процесс. Тогда сигнал приходит xinit'у, а он его корректно ловит и убивает иксы.

Всё остальное скопипащено из getty@.service.

Да, дисплей захардкожен в :0. Пара слов о назначении VT: процесс startx получает номер VT в переменной $XDG_VTNR (её устанавливает pam_systemd), а из startx запускается /etc/X11/xinit/xserverrc, который об этой переменной знает и передаёт X-серверу параметр vt$XDG_VTNR.

Параграф три. Запускаем. Итак, помещаем юнит в /etc/systemd/system/xorg@.service, startx в /etc/systemd/scripts/startx (можно куда угодно) и делаем:

systemctl daemon-reload
systemctl disable getty@tty1
systemctl enable xorg@tty1

После этого можно ребутиться и надеяться, что запустится. Ах да, дисплейный менеджер тоже стоит отключить, потому что он запустит свой X-сервер и произойдёт адъ и израиль.

Как-то так. Сейчас три часа семнадцать минут по московскому времени, поэтому прошу меня извинить за упрт стиль изложения, краткость, неконсистентное использование форматирования и так далее.

 , ,

intelfx ()

Определить, что quickfix window видимо

Форум — Development

Как на vimscript определить, что quickfix window открыто и видимо? Аналогично для location window.

 ,

discordia ()

Через год в Linux ядре будет блокирована работа закрытых модулей

Новости — Ядро Linux
Группа Ядро Linux

В результате дискуссии в списке разработчиков Linux ядра, было принято решение, что Linux ядра выпущенные начиная с января 2008 года перестанут работать с модулями ядра, которые распространяются под лицензиями несовместимыми с GPL. До 2008 года, при попытке загрузки не GPL модуля будет выдаваться предупреждающее сообщение. Большинство Linux драйверов для soft-модемов, беспроводных и видео (ati/nvidia) карт распространяются производителями оборудования в бинарном виде. Главная цель акции - заставить разработчиков закрытых драйверов вынести основную функциональность драйвера в виде пользовательского процесса (userspace), оставив в виде модуля ядра только минимальный код.

Мнение Торвальдса [который считает это решение плохим] - http://groups.google.com/group/fa.lin...

Взято с opennet.ru

[Планы по блокировке по всей видимости отменили]

>>> Подробности

Sectoid ()

Эпические треды

Форум — Talks

Сюда я буду добавлять треды без купюр и IP (UA оставим).

Номер 1 - РФВС: http://linuxhacker.ru/~shaman/rfvs.html

Номер 2 - Однострочник на Perl: http://linuxhacker.ru/~shaman/perl-one.html

Номер 3 - Реестр в Линуксе: http://linuxhacker.ru/~shaman/linux-registry.html

Номер 4 - Экстрасенсы: http://linuxhacker.ru/~shaman/extra-sence.html

Номер 5 - Польский священник и Господ Бог: http://linuxhacker.ru/~shaman/poland-god.html

Номер 6 - Gentoo для девочек: http://linuxhacker.ru/~shaman/gentoo4girls.html

Номер 7 - Одна фраза о Lisp'е: http://linuxhacker.ru/~shaman/lisp1.html

Номер 8 - Microsoft ищет линуксоида: http://linuxhacker.ru/~shaman/MSLinux.html

Номер 9 - Материалистам LOR: http://linuxhacker.ru/~shaman/Material-LOR.html

Номер 10 - GTK3: http://linuxhacker.ru/~shaman/GTK3.html

Номер 11 - Линус начал использовать Gnome: http://linuxhacker.ru/~shaman/Torvalds-Gnome.html

Номер 12 - Правила Talks: http://linuxhacker.ru/~shaman/Talks-Talks.html

Номер 13 - Явление Болгенос: http://linuxhacker.ru/~shaman/Bolgenos.html

Номер 14 - Arch Linux 2010.05: http://linuxhacker.ru/~shaman/arch-2005.html

Номер 15 - Wayland готов для десктопа: http://linuxhacker.ru/~shaman/wayland.html

Номер 16 - Аят, собственно, аля: http://linuxhacker.ru/~shaman/ayat.html

Номер 17 - Лифчик с Убунтой: http://linuxhacker.ru/~shaman/gentoo-bra.html

Важное замечание: «страницы» внизу фиктивные, ведут вникуда. Все, что происходило в треде видно в указанных выше файлах.

Если вы считаете, что список нужно пополнить чем-то интересным или смешным, напишите мне на abondarenko@gmail.com. Однако, я не буду заносить сюда топики-травли или то, что сочту унылым.

Shaman007 ()

Производительность; илитный запил оптимальных реализаций и основы матчасти.

Форум — Development

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

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

Изначально я хотел написать про то: что такое бесплатные вычисления на примере is_range() + сумма елементов массива, но тут выявилась смешная особенность, поэтому пока без is_range().

Начнём с простого - сумма елементов(float) массива. Как написать её быстро? Обычный крестопоц сделает так:

auto summ = accumulate(begin(vec), end(vec), 0.)

Этот код выдаёт 5.6GB/s(мы всё бенчим в л1д 32килобайта массив). Казалось бы, если бы мы слушали всяких «гуру», которые нам говорят: accumulate() - оптимизирован, «ты что умнее создатели stl"а?», «конпелятор умнее тебе - сам всё делает оптимально», «руками что-то делать слишком сложно и не нужно» - то мы бы там и остались с этими 5.6ГБ, но мы пойдём дальше и поймём почему так, и является ли это тем, что намн ужно.

Но посмотрев на код - он не векторизован:

	addq	$4, %rdx
	vcvtss2sd	-4(%rdx), %xmm2, %xmm2
	vaddsd	%xmm2, %xmm1, %xmm1

Почему? Патамучто это основная флоатпроблема: Он не ассоциативен - флоат не имеет в себе точных представлений всех чисел входящих в диапазон его «представления» т.е. порядкопроблемы.

Поэтому конпелятор НЕ ВЕКТОРИЗУЕТ флоат по умолчанию, ну никак. Даже такую банальщину.

Для решения этих проблем - есть ключик -funsafe-math-optimizations, который входит в -ffast-math, который кладёт на точность при вычислениях. Добавив его мы получаем уже 44.9GB/s.

Но теперь мы получаем ещё одну проблему - надо думать: «как бэ сунуть эту ключик не повредив там, где этот ключик не нужен».

Поэтому ноцанам, которые хотят быстро и не хоятт рандомных жоп из-за тупости конпелятора - пишут всё руками. Допустим на той же сишке это пишется так:

double memadd_autovec(buf_t buf) { //5.609465GB/s, либо 44.969652GB/s с ffast-math
  float * it = buf_begin(buf), * end = buf_end(buf), summ = 0.;
  do {
    summ += *it++;
  } while(it != end);
  return summ;
}

double hsumf(__v8sf v) {
  return (v[0] + v[1] + v[2] + v[3] + v[4] + v[5] + v[6] + v[7]);
}

double memadd_vec(buf_t buf) { //45.652002GB/s и класть на ffast-math
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
  do {
    summ += *it++;
  } while(it != end);
  return hsumf(summ);
}

Т.е. разницы никакой нет, кроме нужной нам реализации горизантального сложение вектора. Когда я говорил пацану: «векторную сишку для написания быстрого кода юзать намного проще, чем плюсы» - поцан нипонимэ, да и любые пацаны скажут - ну дак с -ffast-math оба выдают по 45гигов - нахрен эта сишка нужна?

А вот зачем:

double memadd(buf_t buf) { //132.878440GB/s
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
  do {
    summ += *it++;summ += *it++;summ += *it++;summ += *it++;
  } while(it != end);
  return hsumf(summ);
}

Это называется пацанский анролл копипастой, а вот заставить конпелятор нормально что-то разанролить очень сложно.

Если бы мы слушали всяких «гуру», которые нам вещают: «анрол говно и не нужен» - мы бы так и седели с 45-ю гигами, а так мы сидим с 132.878440GB/s. Т.е. анролл нам дал немного не мало ~300%.

Но основная мысль, которую толкают всякие «гуру» - это не надо следить за тактами/считать такты и прочее. Но мы о5 сделаем наоборот и посмотрим что будет.

Т.к. наш юзкейс упирается на 99% в throughput и дёргается одна инструкция, то нам достаточно просто считать теоретическую производительность для моего камня. 4.5(частота камня)*8(т.е. у нас камень с avx, то там вектор 32байта, либо 8флоатов.)*1(throughput нашей инструкции - в данном случае vpaddps из интел мануала). Т.е. 36гигафлопс, либо ~144гига. Т.е. мы сняли овер 90% теоретической производительности - остальные 10% у нас ушли в наши циклы, всякие горизонтальные суммы вектора и прочее, ну и конечно же чтение данных из кеша.

Но самое смешное - на моём хасвеле умножение имеет throughput 0.5 - т.е. на хасвеле умножение быстрее сложения. Это новая забористая трава у интела.

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

Поэтому очень смешно слушать, когда какие-то пацаны говорят: «float point имеет такую же производительность как и инты» - нет, оно имеет такоу же производительность лишь по причине того, что на штеуде инты тормазят так же, как и float.

И чтобы окончательно в этом убедится - мы взглянем на fma(вариации умножения со сложением/вычитанем), которые имеют throughput 0.5 - да, да - на хасвеле умножение+сложение в 2раза быстрее просто сложения. Это уже не просто трава - это что-то принципиально новое.

У целочисленного сложения же throughput 0.5 и казалось бы, если мы поменяем в нашей функции float на int - у нас будет сложение работать в 2раза быстрее, но это не так. Оно выдаёт те же 130гигов, а почему?

Вообще у камня есть такая фича, допустим у нас:

add $1, %reg0//вот тут инструкция add залочит регистр reg0
add $1, %reg0//а эта инструкция уйдёт в лок до особождения предыдущей инструкцией регистра reg0

Чтобы такой жопы небыло - есть специальная фича:

add $1, %reg0//lock reg0
add $1, %reg0//И тут вместо того, чтобы уйти в лок - камень вместо reg0 даёт инструкции любой свободный регистр.

Эта фича называется прееименование регистров, либо как-то так - мне лень гуглить.

Дак вот штука в том, что фича работает через жопу. Мне лень читать мануал и искать почему так, но штука в том, что она ограничивает throughput. На умножении и целочисленном сложении она огранивает throughput c 0.5 до 1.

И вот я решил заюзать сложении через fma:

__v8sf fmaadd(__v8sf a, __v8sf b) {
  return _mm256_fmadd_ps(_mm256_set1_ps(1.), a, b);// a + b * 1. == a + b.
}

double memadd_fma(buf_t buf) {
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
  do {
    summ = fmaadd(summ, *it++);
  } while(it != end);
  return hsumf(summ);
}

Но меня ждала жопа: 27.347290GB/s, причем не анролл и ничего не помогал. Я уж подумал, что мануал наврал, но позже до меня допёрло: у неё latency 5тактов и ((4.5×8)÷5)×4 ~= 29гигов - т.е. я получаю производительность с её latency, но какой жопой оно так?

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

add $1, %reg0
add $1, %reg0
//а не
add $1, %reg0
add $1, %reg1

Т.е. на неё вообще не работает переименовывание регистров - и инструкции постоянно в локе. Я это проверил и оказался прав. Ну и я написал такой мемадд:


__v8sf fmaadd(__v8sf a, __v8sf b) {
  return _mm256_fmadd_ps(_mm256_set1_ps(1.), a, b);
}

inline void fma_10way_finality(__v8sf * cache, __v8sf * it, __v8sf * end) {
  switch(end - it) {
    case 8:
      *(cache + 7) = fmaadd(*(cache + 7), *(it + 7));
      *(cache + 6) = fmaadd(*(cache + 6), *(it + 6));
    case 6:
      *(cache + 5) = fmaadd(*(cache + 5), *(it + 5));
      *(cache + 4) = fmaadd(*(cache + 4), *(it + 4));
    case 4:
      *(cache + 3) = fmaadd(*(cache + 3), *(it + 3));
      *(cache + 2) = fmaadd(*(cache + 2), *(it + 2));
    case 2:
      *(cache + 1) = fmaadd(*(cache + 1), *(it + 1));
      *(cache + 0) = fmaadd(*(cache + 0), *(it + 0));
    case 0:
      break;
    default: error_at_line(-1, 0, __FILE__, __LINE__, "bad_aligned");
  }
}

double memaddfma_10way(buf_t buf) {
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = (__v8sf){};
  __v8sf * cache = (__v8sf[10]){{}};
  uint64_t i = 0;
  while((it += 10) <= end) {
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    i = 0;
  }
  fma_10way_finality(cache, (it - 10), end);
  summ = (*(cache + 0) + *(cache + 1) + *(cache + 2) + *(cache + 3) +
	  *(cache + 4) + *(cache + 5) + *(cache + 6) + *(cache + 7) +
	  *(cache + 8) + *(cache + 9));
  return hsumf(summ);
}

Пришлось хреначить финалити, ибо тут «анролл» на 10, а почему на 10 - для максимального throughput"а - надо, чтобы каждый каждый регистр юзался через 5тактов - т.е. 10регистров.

И вся эта порятнка нужна для борьбы с тупостью конпелятора.

Это уже: 214.167252GB/s(раельно там в районе 250 - просто мой бенч говно). 107 гигафлопс на ведро. Из теоретических 144, но тут уже влияние кеша. Причем 50+ из которых выкидываются и просто бесплатные.

Теперь вопрос к пацанам - что нам дадут эти гагфлопсы, когда у нас будет массив не 32килобайта, а 32мегабайта? Зачем нужно выживать максимум, когда скорость памяти отсилы 20-30гигабайт и нам хватит даже С++ кода с ffast-math?

Ну и призываются упомянутые мною пацаны: mv - этот тот експерт, что вещал про «руками переименовывать регистры не надо» и «анрол ваще ненужен», emulek вещал про ненужность счёта тактов, и не понимал что такое «беслпатно», AIv - не понимал в чем проблема плюсов, ck114 - так же не понимал в чем проблема плюсов.

Бенчи: https://gist.github.com/superhackkiller1997/606be26fa158ef75501d - вроде я там ничего не напутал.

P.S. - не выпиливайте пж, пусть пацаны «нужно» или «не нужно». Мне интеерсно. Ну и там рекомендации пацанов.

 , , ,

Carb_blog ()

Fedora: на пути к 14

Новости — Red Hat
Группа Red Hat

В проекте Fedora сразу три новости, которые наверняка обрадуют всех:

  1. Fedora перевела всю свою инфраструктуру на Git. Ранее для управления версиями RPM-спеков, патчей и исходников использовался cvs.
  2. Systemd интегрирован в Rawhide. Теперь он может использоваться вместо upstart. Осталась временная возможность выбирать при загрузке систему инициализации через параметр init=/bin/systemd или init=/sbin/upstart. В дальнейшем upstart будет убран из системы.
  3. Fedora 14 выделена в отдельную ветку репозитория из Rawhide. Теперь принимаются только улучшения, связанные с повышением стабильности и закрытием багов. Новые возможности приниматься не будут. Релиз назначен на 26 октября.

Переход на Git

Systemd теперь новая система инициализации по умолчанию

>>> Выделена ветка Fedora 14

 , ,

DoctorSinus ()

Разработчик из команды Gentoo выступил с критикой systemd

Новости — Linux General
Группа Linux General

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

Ниже привожу свой перевод его публикации.

( читать дальше... )

>>> Подробности

 ,

ins3y3d ()

Оконная мозаика

Галерея — Скриншоты

С год назад я уже показывал разные нестандартные способы переключения окошек. Но если одно из них очень просто заменяется связкой dmenu+wmctrl, то вот цветастую штуковину за пределами xmonad никто изобретать не собирался. А удобная же штуковина! Но ведь главный принцип опенсорса — если чего-то нужного тебе нет, просто сделай это сам, верно? Поэтому в свободное время были изучены некоторые доки по иксам, и началось пиление велосипеда, названного чуть позже xwinmosaic.

Итого: программа написана на чистом С + GTK+2, а для работы нужен только EWMH-совместимый оконный менеджер (почти любой, некоторых в том списке нет). Идея та же — для каждого класса окна назначается свой цвет, что позвволяет легче находить нужное окно в списке. Окна, использовавшиеся недавно, выстраиваются ближе к центру. Для работы достаточно повесить запуск xwinmosaic на какой-нибудь хоткей средствами WM.

Жизнь была простой и беззаботной, когда тестирование производилось лишь на своей машинке с kwin, openbox и xmonad, однако после показа сей приблуды ограниченному кругу людей было выловлено (и вылавливается) неограниченное количество багов, как-никак: Си (сегфолты), зоопарк WM (куча неработающих или работающих по-другому функций), своё собственное отсутствие опыта, наконец.

Тем не менее, за неделю программу удалось причесать, и теперь она умеет:


  • Собственно, переключение между окнами
  • Чтение списка элементов из stdin и вывод выбранного элемента в stdout (что позволяет реализовывать похожее на dmenu поведение или даже изменять существующие скрипты простой заменой вызова dmenu на xwinmosaic, только аргументы придётся поменять)
  • Emacs (C-n C-p C-f C-b) / vim (hjkl)-подобная навигация для любителей.
  • Более-менее приличный поиск по элементам (а также по классам окон), в чем-то похожий на тот, что в ido-mode (например, «ff» найдёт все окна Firefox) — активизируется сразу при наборе в стандартном режиме и по / в режиме vim
  • окно непрямоугольной формы (на заднем плане не скриншот экрана, как в xmonad, а сами окошки, в которые можно тыкать), хотя поведение со скриншотом тоже пришлось реализовывать, так как оказалось, что не все ещё WM могут обогнать в функциональности TWM и не реализуют корректное поведение с XShape.
  • Для режима переключения окон реализовано обновление имён и самого списка окон в реальном времени, показ номера десктопа, на котором находится окно, и даже их иконки (всего этого в оригинале не было)
  • Возможность появления центра мозаики под курсором мыши (что показано на первом скриншоте, получается весьма прикольно)
  • Попытка уместить все элементы на экране вместо примитивного выстраивания их ромбиком (из-за чего к иксмонадовскому GridSelect были большие претензии)
  • Куда более приятные цвета, благодаря использованию цветовой модели HSL.
  • Ну и ещё что-то, наверное забыл упомянуть.


Ради забавы было реализовано даже подобие dmenu_run — получается очень радостно и эпилептично (спасибо, Artificial_Thought!).

На скриншотах, собственно, можно наблюдать xwinmosaic в режиме переключения окон и в режиме переключения буферов емакса (невероятно удобно, между прочим) — спасибо за идею и оригинальный скрипт для dmenu товарищу lazyklimm!
Шрифты — PT Sans в интерфейсе, Consolas в емаксе, убунтопатчи; всё та же старая обоина с Ктулху (очень мотивирует), а больше там ничего и не видно, вроде.

Надеюсь, кому-нибудь оно приглянется, поэтому ссылки:
Github: https://github.com/soulthreads/xwinmosaic (не забывайте писать в issues в случае обнаружения багов)
Пакеты для дебиана/убунты: https://launchpad.net/~soulthreads/ archive/xwinmosaic/ (могут быть немного неактуальными)
Арч: https://aur.archlinux.org/packages.php?ID=59660
Gentoo: https://github.com/soulthreads/xwinmosaic/blob/master/contrib/gentoo/xwinmosa... (надо будет напроситься к кому-нибудь в оверлей)

Вот как-то так, надеюсь, вам не надоело чтение этих многобуков.

>>> Просмотр (1024x1200, 302 Kb)

 ,

SoulThreads ()

Операционная система GNU Emacs завоевывает десктоп! :)

Галерея — Скриншоты

Операционная система GNU Emacs получила новые возможности! Собрал волю в кулак и написал библиотеку, которая практически полностью реализует протокол X11. Библиотека незамысловато называется x11 и написана на чистом Emacs Lisp, но пока имеет статус technical preview, хотя в принципе уже можно писать что-то реальное. За основу пока взяты описания протокола на XML из проекта XCB, которые разворачиваются в реализацию. В результате имеем практически все расширения. Работа с протоколом осуществляется в асинхронном стиле подобно XCB. Чего пока нет:

  • MIT-SHM. Запросы реализованы, но работать через разделяемую память из операционной системы Emacs мы пока не можем, поэтому Будем через сокет закидывать. Тем более, что разница в скорости, говорят (видел где-то в инете замеры), не такая сумасшедшая.
  • XKB. Просто забыл реализовать пару конструкций XML, используемых для описания этого расширения. Это я скоро реализую, поэтому расширение будет работать в полном объеме.
  • Big-requests. Тоже будет реализовано. Расширение содержит всего один запрос. Он реализован. Но именно для этого расширения надо несколько перелопатить процедуры формирования запросов к серверу X, так как подсчет размеров запросов изменяется с этим расширением.
  • GLX. Огромнейший пласт. За него возьмусь сильно позже. Тут же еще надо полностью сгенерировать протокол GL, а он очень обширный.

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

(размер экрана уменьшил до 1024x768, чтобы скриншот поменьше был)

На скриншоте сверху робкая демонстрашка в стиле LSD основного протокола X11 (Core protocol). Ну с arcs, rectangles и core fonts все и так понятно. А вот как выведены фотографии? Я пока не настолько крут, чтобы писать растеризацию jpg и png на Emacs Lisp. Пораскинув мозгами, пошел смотреть, чем может помочь ImageMagick. Оказалось, есть там возможность получить дамп картинки в нужном формате. Так и сделал: надо отобразить картинку - дергаем stream, она нам отдает дамп в буфер, мы его отсылаем в сервер X. «Привет, Isden» написана мышкой. Демка отслеживает событие motion-notify и рисует маленький квадратик под указателем. По кнопке «q» - выход (отслеживается событие key-press)

На скриншоте снизу робкая и неумелая демонстрашка расширения XRender. Тоже в стиле LSD. На ней мы видим linear gradient, radial gradient, треугольник и отрисовку сглаженных окружностей. Окружности состоят из трапезоидов. Алгоритм рассечения (tessellation) я применил первый, какой мне пришел в голову - горизонтальными трапециями. Какая есть проблема? Сглаженный текст! Что-то мне писать растеризацию TrueType или Type1 на Emacs Lisp не улыбается. Есть идея написать программку на Си с помощью Xft, которую я буду что-то просить растеризовать, а она результат будет отдавать в Emacs. То есть примерно как и с ImageMagick поступить.

Надо хорошенько переобдумать API библиотеки, чтобы его заморозить. При этом надо учесть потенциальные и вероятные будущие новшества в Emacs и в библиотеке, чтобы людям не пришлось переписывать то, что написано ранее. Есть недостатки в Emacs, которые реально мешают и раздражают. Преодолимы, конечно, но это будут костыли. Если интересно, то потом поясню, а то уже и так много воды налил.

Так что есть потенциальная возможность воплотить мечту atoku в жизнь. :)

Традиционная ссылка на обоину: #888888. Старую удалил, так как она надоела, а новую еще не искал. Этот серый цвет реально бесит. :)

>>> Просмотр (1024x1536, 254 Kb)

 , ,

Zubok ()

Литература по электротехнике

Форум — Talks

Доброго времени суток всем,

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

Спасибо!

maxylopes ()

VIM как python IDE

Форум — Development

Знаю тема могла уже много раз поднималась, в том числе и в интернетах. Но из-за большого количества плагинов и как следствие одни плагины приходят на смену другим, засоветуйте оптимальный набор для создания python-IDE:

Нужно:

Удобные сниппеты аля в Geany. Т.е. повесил

Удобная работа с git. Хотя пожалуй еще не придумали лучшую работу с git, чем из терминала.

Автодополнение, документация, рефакторинг и т.д. - это решается rope и вообще python-mode в целом.

Навигация по проекту: дерево файлов, поиск всего и вся по всему проекту. Создание проекта из директории (на сколько я понял нужно rope указать директорию)

Перечень меток навроде «TODO»

Множественное выделение аля емакс - нашел такой плагин: https://github.com/terryma/vim-multiple-cursors

Какими плагинами реализовать вышеперечисленное и что еще удобного посоветуете?

UPD:

А еще что есть для Jinga2/Django темплейтов, и HTML в целом. Например выделить блок текста, тыкнуть комбинацию и блок текста засовывается в <div>...</div>

 , ,

Siado ()

Незаменимые plug-in'ы Vim

Форум — General

Наверное, «незаменимые» слишком резко, но все же, какие, по вашему мнению, действительно полезные (не тривиальные, типа NERDtree, Syntastic или комплитеры) plug-in'ы для Vim вы используете?

Полагаю, эта тема будет интересна для начинающих и остальных пользователей Vim.

Из того, что использую я:

«The missing motion for Vim» полезен тем, что позволяет искать и перейти к искомому, в отличие от изкоробочного f F одного символа - по 2 или 3, также после активации опции может работать как аналог довольно неюзабельного easymotion, но главное преимущество все-таки в изначальном применении.

«simple REPL inside vim» - дико тащусь от этого малоизвестного плагина, проще посмотреть иллюстрацию по ссылке. (вкратце: получить по одному нажатию результат интерпретатора выделенного куска, :read !* отдыхает).

«Yet another rainbow parentheses plugin» - имхо лучшие цветные скобочки из существующих.

аналог имаксовского Narrow Region, когда хочешь сконцентрироваться на небольшом куске кода/текста, выделяешь, он открывается в отдельном буфере, при сохранении синхронизация с остальным.

открывает файловый менеджер или терминал в директории с редактируемым файлом.

предпросмотр :substitute в реальном времени

...

Кроме этого, может кто не знал: о самом удобном манипулировании с окнами, взаимодействии с tmux (например под любой интерпретатор/компилятор), стартовом экране, календаре-планировщике, отображении отступов, а также нескучной цветовой схеме для терминала, получше, чем блевотный solarized.

Что посоветуете?

 

clojure ()