>Жаль, что перл, а то бы TODO-шка твоя быстро опустела :) Хотя подозреваю, что там не все планы.
Ридми давно не апдейтил, а хелп в самом коде так и подавно =) Запушил

Кстати, решил изучить вопрос по вот этому TODO:

> Store decrypted DB into RAM not in /tmp/

и обнаружил, что ни DBI, ни сам sqlite не поддерживают загрузку бинаря базы данных из RAM.

Единственный быстрый путь решения, который представляется возможным (и который предлагают люди), заключается в том, чтобы создавать пустую базу в памяти и загружать в неё данные из дампа через CREATE TABLE ...

В таком случае БД придётся даже в зашифрованном виде хранить не в виде sqlite-файла, а в виде sql-дампа. Грустно и медленно, но зато 100% безопасно.

Если тебя устроит данный способ взаимодействия, то могу форкнуть и приделать.

Difrex> Вот, например, чем я пользуюсь постоянно - pm https://github.com/Difrex/PM. Консолькный менеджер паролей для X. Писал потому что ничего удобнее(для меня) нет.

Сорри за оффтоп, но чем pass не устроил? https://www.passwordstore.org/

>и обнаружил, что ни DBI, ни сам sqlite не поддерживают загрузку бинаря базы данных из RAM.
Да, я знаю про это. Вообще я думал попробовать так:
* Расшифровать базу в память - тут все норм
* Подсунуть базу драйверу sqlite как файл, т.е. через \$bd

>В таком случае БД придётся даже в зашифрованном виде хранить не в виде sqlite-файла, а в виде sql-дампа. Грустно и медленно, но зато 100% безопасно.
>Если тебя устроит данный способ взаимодействия, то могу форкнуть и приделать.
Если получится, то было бы круто =)

>Сорри за оффтоп, но чем pass не устроил? https://www.passwordstore.org/
Мне он был не удобен. Мне нужен был именно плоский вывод имен, т.к. я часто использую подобное:

pm -sn all | tail -3

Так же мне хотелось xdg-open, чтобы сразу перейти по ссылке. Хотелось комментариев к паролям, и.т.д.

Короче, pass мне был не удобен и я написал свой велосипед. :)

Difrex> * Подсунуть базу драйверу sqlite как файл, т.е. через \$bd

И как бы это примерно выглядело? Непонятно, что под этим ты имеешь в виду.

Вместо хранения дампа можно сделать в том числе и Named Pipe, именно так лучше и попробую.

Итак, Named Pipes эта штука так же не поддерживает. А жаль, потому что в MySQL можно было нормально сделать LOAD DATA INFILE, и всё бы пахало, как часы.

Лучше было бы вообще не sqlite использовать, а json какой-нибудь, с ним бы точно проблем не было.

А как вообще в сабже с безопасностью? В каком виде оно хранится? А то я чёт перловые исходники совсем не разумею, а времени на кемел бук нет пока.

Оно хранится в зашифрованном (через GPG) виде в $HOME. При каждом взаимодействии база расшифровывается, находясь в /tmp, и сразу же удаляется.

Небезопасность заключается в том, что из /tmp расшифрованный файл базы можно позднее восстановить, если этот самый /tmp не примонтирован в виде tmpfs.

// а я тем временем обнаружил, что sqlite-модуль даже текстовые дампы не поддерживает
// надо бы в самом деле на что-то другое переписать

Форкнул сабж и написал туда чуть-чуть:
https://github.com/vit1-irk/PM

Изменения:
* Теперь можно импортировать БД из файла
* При автогенерации пароля можно при желании задать его длину
* Место расшифрованной БД поменял на /dev/shm

Третий пункт сделал из-за того, что /tmp люди не всегда монтируют, как tmpfs (некоторые просто на диске его держат), а /dev/shm всегда автоматически ставится в tmpfs.

Скажи, что ещё хотел бы сделать. Помогу и сделаю пулл-реквест (или сейчас сделаю, если хочешь).

>Помогу и сделаю пулл-реквест (или сейчас сделаю, если хочешь).
Делай пулл-реквест(только в AUTHORS себя не забудь добавить :), я потестю на своей базе из ~150 паролей и смержу в мастер.

>Скажи, что ещё хотел бы сделать.
Да вот красивый вывод в pm -sn all, только хочется. Все руки не дошли до того, чтобы сделать это.

Еще есть проблема в SQL, там нет уникального ключа по имени. Да и вообще, я думаю, что стоит перейти на что-то noSQL, хотябы на perl Storable. + в этом, что избавимся в зависимостях от sqlite.

Difrex> Да вот красивый вывод в pm -sn all, только хочется. Все руки не дошли до того, чтобы сделать это.

Он разве слишком некрасивый? Там даже цвет есть, насколько видно.

Хотя всё-таки есть, чего улучшить. У меня вот в терминале тема оформления светлая, поэтому поле ID не видно совсем.

Difrex> Еще есть проблема в SQL, там нет уникального ключа по имени.

Ну это на раз-два.

Difrex> Да и вообще, я думаю, что стоит перейти на что-то noSQL, хотябы на perl Storable. + в этом, что избавимся в зависимостях от sqlite.

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

>Difrex> Да вот красивый вывод в pm -sn all, только хочется. Все руки не дошли до того, чтобы сделать это.
vit01> Он разве слишком некрасивый? Там даже цвет есть, насколько видно.
Я просто хотел сделать, как в mysql/pgsql - табличка, чтобы рисовалась.

>Попробую почитать что-нибудь на эту тему. А sqlite действительно не очень хорошо здесь смотрится. Скорее, это проблема самой перловой реализации (сделали только самые базовые вещи).
Там делов-то немного. Переписать только функции из DB.pm, я вечерком, может займусь =)

В своём репозитории сабжа сделал ветку testing.

В этой ветке сделал вывод в красивую таблицу и исправил твой костыль с дублированием кода при выводе информации.
Протестируй и выскажи своё мнение.

./pm.pl -s -n all

Очень классно получилось.

Есть только проблема с отображением, если uri в ресурсе очень длинный - табличку корежит: https://cloud.difrex.ru/index.php/s/txaZ77bL1KlJ562

Я, в принципе, знаю как это поправить. Спасибо, смержил в тестинг :)

Difrex> Есть только проблема с отображением, если uri в ресурсе очень длинный - табличку корежит

Difrex> Я, в принципе, знаю как это поправить.

Там таблица строится очень просто - обычным дополнением пробелов справа.

Если получится починить, то очень хорошо. Сам просто не придумал, как такие случаи обрабатывать. Только если обрезать строку, но это не очень правильно.

Итак, в PM вроде всё устоялось с фичами (если появятся ещё какие-нибудь хотелки, то пусть Денис пишет, поломаю голову).

Надо ещё и больше.

Что можете предложить из того, что не связано с нашей сеткой, но интересно было бы сделать вместе?

// могу и сам чего-нибудь предложить, но сначала подожду

>Итак, в PM вроде всё устоялось с фичами (если появятся ещё какие-нибудь хотелки, то пусть Денис пишет, поломаю голову).
Да, большое спасибо за коммиты :)

>Что можете предложить из того, что не связано с нашей сеткой, но интересно было бы сделать вместе?
Не заинтересует такая штука?
https://github.com/Difrex/azot

Difrex> Не заинтересует такая штука? https://github.com/Difrex/azot

Забавная вещь. И каковы планы по её улучшению? Делает своё дело, судя по видео, вполне исправно.

Жрет ресурсы не в себя. Там постоянно опрашивается положение курсора.
Было бы круто использовать что-то типа Inotify, но для X, а не FS.

Difrex> Жрет ресурсы не в себя. Там постоянно опрашивается положение курсора.

Вроде бы, это единственный рабочий способ для иксов.

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

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

Для производительности можно переписать сабж на Си, но вряд ли будет сильный прирост.
// удивило, кстати, что python2, а не python3

Что думаешь?

>Для производительности можно переписать сабж на Си, но вряд ли будет сильный прирост.
Я думал на счет Go :). Но проблема не в этом.

>Что думаешь?
Например, у меня на федоре иксы через примерно час начинают отлупливать соединения от Azot, типа, слишком часто. Скорее всего надо один раз подключаться и работать в пределах этой сессии, но как это сделать - я не знаю.

>удивило, кстати, что python2, а не python3
Привык я ко второму питону, но там под третий совсем немного переписывать.


ЗЫ: Покажи свои проекты, интересно :)

Difrex> Например, у меня на федоре иксы через примерно час начинают отлупливать соединения от Azot, типа, слишком часто. Скорее всего надо один раз подключаться и работать в пределах этой сессии, но как это сделать - я не знаю.

Заглянул в исходники X.py из азота. Там такой интересный кусок кода:

def get_cursor_position():
    while 1:
        try:
            data = display.Display().screen().root.query_pointer()._data

            return {'x': data['root_x'], 'y': data['root_y']}

Смущает очень сильно, что ты инициализируешь объект display через display.Display() каждый запуск этой функции. Если учесть, что это происходит постоянно раз в секунду, я не удивляюсь, что иксам это сильно надоедает ;)

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

У меня уже план есть по сабжу:

1. Переписать на python3
2. Убрать костыли и повысить производительность
3. Сделать опцию для ручного указания задержки в конфиге
4. Сделать автоматическую подгрузку конфига, чтобы в самый первый раз не вручную копировать

Если возражений не будет, то примусь за него.

Difrex> ЗЫ: Покажи свои проекты, интересно :)

Если зайдёшь ко мне на гитхаб, то убедишься в том, что смотреть там особо нечего :)
// за исключением сетевых проектов, только это не в счёт

Хотя есть кое-что: https://github.com/vit1-irk/timeleft
Андроид-приложение для товарищей школьников, которое позволяет отслеживать расписание занятий (уроки/пары, перемены). Появилось после экспериментов в ii://linux.14 по NDK: ii://RZdZbVEHDhzU8UcpWJsF
Простое, как валенок, но зато имеет неплохой UI и поддерживает уведомления.

У меня из проектов на гитхабе самое интересное https://github.com/btimofeev/emuchip

Это была моя попытка написать эмулятор простейшего компьютера, на примере Chip8 и SuperChip. Все игры для этих систем работают (за исключением одной, кажется). Но в эмуляторе есть пара ошибок, которые я так и не решил (одна связана с размером окна Qt, вторая с указателями c++).

// а вообще я всегда хотел написать эмулятор Sega Mega Drive, но думаю не дорос еще))

Сделал в сабже вот что:

* Инициализация дисплея для иксов теперь проходит только один раз
* В конфиге можно задавать самому задержку для проверки курсора
* Конфиг в самом начале не надо копировать вручную, программа сделает это сама
(вариант копирования из /usr/share/doc/ тоже работает)
* Теперь азот работает не на втором питоне, а на третьем

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

Серьёзная вещь, надо бы посмотреть.

btimofeev> Но в эмуляторе есть пара ошибок, которые я так и не решил (одна связана с размером окна Qt, вторая с указателями c++).

Если руки дойдут, то и над этим голову поломать можно. Можно поподробнее, что за ошибки?

btimofeev> // а вообще я всегда хотел написать эмулятор Sega Mega Drive, но думаю не дорос еще))

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

vit01> Если руки дойдут, то и над этим голову поломать можно. Можно поподробнее, что за ошибки?

1. При изменении размера окна внизу появляется пустая полоса в несколько пикселей. Не понимаю откуда она берется.

2. Второе это даже не ошибка, а не очень хорошо написанный код. Внутри эмулятор создает двумерный массив, представляющий экран. Виджет должен отрисовать этот массив на экране. Вот передача этого массива между объектами реализована полным копированием, а не передачей указателя. Все мои попытки передать указатель заканчивались segfault'ом. Здесь наверное сказывается мое плохое знание c++, либо неправильная архитектура.

btimofeev> 2. ..... Вот передача этого массива между объектами реализована полным копированием, а не передачей указателя. Все мои попытки передать указатель заканчивались segfault'ом. Здесь наверное сказывается мое плохое знание c++, либо неправильная архитектура.

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

Над qt-шной пустой полосой пока думаю.

О, а кода там совсем немного. Уже сейчас успел отправить, можно мержить, собирать и проверять.

vit01> О, а кода там совсем немного. Уже сейчас успел отправить, можно мержить, собирать и проверять.

Спасибо, смержил.

Насчет производительности: демки qt отрисовывают тысячи объектов с огромной скоростью, тут же отрисовка сотни квадратов порой тормозит. Особенно заметно на демках типа Climax Slideshow, на высоких разрешениях.

Я тут еще антиалиайсинг отключил, как то упустил его при портировании на qt5.

Хорошо. А я тут наконец-то выяснил, почему появляется та самая белая полоса внизу окна. Это происходит из-за того, что размеры окна становятся больше, чем размер [холста + меню].

У тебя есть функции set1x(), set2x() и так далее. Внутри них есть такой кусок кода:

setFixedSize (512, 256 + menuBar()->height()); // например, так

Так вот, обнаружил, что перед первой отрисовкой окна (то есть при вызове readSettings() из конструктора) функция height() выдаёт одно значение, а после отрисовки - другое. У меня правильным оказывается второе значение, а первое - на 3 пикселя больше, чем надо.

Варианты: либо продолжить разборки и найти в самом Qt причины этого, либо сделать какой-нибудь костыль.

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

vit01> Починил проблему с полосой, установив EventFilter на событие изменения размера меню.

Работает, спасибо. Кстати, добавь себя в файл authors.

Хочется ещё и ещё кода понаписать. ;)

Надо бы какой-нибудь покрупнее проект найти.

// Плюсы, кстати, неплохая вещь, особенно, в связке с Qt. Жаль, что раньше никогда почти дел с ними не имел.

vit01> Надо бы какой-нибудь покрупнее проект найти.

Могу предложить поучаствовать в относительно крупном проекте. Есть очень неплохой консольный музыкальный плеер cmus. У его плагинной системы один недостаток: из плагина нельзя добавить несколько треков в плейлист (это нужно для музыкальных форматов в которых в одном файле может содержаться несколько треков). К примеру в плагинах поддержки cue и cd это сделано хаками: часть кода плагина содержится в коде программы. И это сильно усложняет написание подобных плагинов + при компиляции плагина нужно перекомпилировать и программу. Текущий майнтейнер проекта не против изменений, но никто за реализацию этого так и не взялся.

vit01> // Плюсы, кстати, неплохая вещь, особенно, в связке с Qt. Жаль, что раньше никогда почти дел с ними не имел.

А мне они уже не нравятся, слишком сложный язык, по-моему.

vit01> // Плюсы, кстати, неплохая вещь, особенно, в связке с Qt. Жаль, что раньше никогда почти дел с ними не имел.
btimofeev> А мне они уже не нравятся, слишком сложный язык, по-моему.

Смотря с чем сравнивать. Вот если сравнить C++ & Qt с Java на андроиде, то первая связка гораздо приятнее в работе.
А так на питоне проще всего делать. Вот хорошее отличие от питоновского PyQt в том, что не надо заморачиваться с импортами разных фич (т.е. не надо помнить заранее, какая вещь в каком классе находится).

btimofeev> Могу предложить поучаствовать в относительно крупном проекте. Есть очень неплохой консольный музыкальный плеер cmus.

Спасибо за идею. Вот собрал его только что, потом освою и буду исходники курить.

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

Проталкивать в апстрим пока страшновато (несмотря на то, что моя ветка уже собирается и не сегфолтится).

vit01> Проталкивать в апстрим пока страшновато (несмотря на то, что моя ветка уже собирается и не сегфолтится).

Лучше создай заранее issue с обсуждением изменений или напиши на почту майнтейнеру приложения (его ник flyingmutant, он из России, на почту он нормально отвечает), так как он делает код ревью и отправляет на доработку если ему что-то не нравится (мой простенький vtx плагин со второго или третьего раза принял, точно не помню).

Разработчик мне только сегодня ответил. Пишет, что времени на просмотр кода у него очень мало, но подбадривает и говорит, чтобы я продолжал. Как сделаю большую часть, то пулл-реквест открою.
С кодом cd посложнее будет, потому что там инициализация модуля в самом коде находится. Больше всего вопросов по коду определения типа файла. Но ничего, зато нескучно будет.

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

Можешь еще посмотреть код deadbeef'а, у него внутри плагина доступна функция для добавления нескольких треков.

btimofeev> Можешь еще посмотреть код deadbeef'а, у него внутри плагина доступна функция для добавления нескольких треков.

deadbeef как раз на разные сомнительные штуки имеет функцию плагиноинициализации. Здесь я сделал подобную вещь и тем самым завершил перенос функций добавления плейлиста внутрь плагинов.

Посмотрим, что разработчик ответит: https://github.com/cmus/cmus/pull/460

Корпорация постепенно избавляется от поддержки 32-битных систем в своих инструментах для разработчиков. Так опытным путём я выяснил, что последняя рабочая версия SDK - 24, при этом в ней надо ещё заменить подкаталог build-tools на такой же из 23.0.1.

Последний рабочий вариант NDK - версия 10.

Если попытаться обновить SDK через встроенный конфигуратор, на следующий раз он просто не запустится. И даже не выдаст предупреждения, дескать, "ставится только 64-битная сборка, вы уверены?"

В официальных ChangeLog об изменениях написано вскользь и мелким шрифтом.

Понимаю, конечно, что гуглу просто лень делать сборки, но надо же хоть как-то предупреждать. А то нажал кнопочку "Обновить", и сборочное окружение полностью сломано. Несерьёзно для такой большой корпорации.

И ещё немного упрёков в сторону продуктов сабжа. В системных требованиях для Android Studio указано, что минимальный объём ОЗУ должен быть 2 гига, а рекомендуемый - 8.

На моём ящике с двумя гигами писать для андроида, мягко говоря, проблематично. На нетбуке же (1ГБ) невозможно в принципе (уже пробовал).

Гугл, ты серьёзно? 8 гигов оперативы для мелкого Android-HelloWorld?

Короче, парни, пишите на C++ и Qt. Да, у них тоже есть свои минусы, но зато гораздо ниже системные требования, и оно работает на 32-битных системах. А поддержка Андроида и кроссплатформенности у Qt со временем постоянно улучшается. Кроме этого, можно писать в любимом Vim/Emacs.

> Понимаю, конечно, что гуглу просто лень делать сборки, но надо же хоть как-то предупреждать. А то нажал кнопочку "Обновить", и сборочное окружение полностью сломано. Несерьёзно для такой большой корпорации.

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

Не хочу C++. Правда яву я хочу ещё меньше =)

AL> Не хочу C++. Правда яву я хочу ещё меньше =)

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

Я вон тоже мечтаю, чтобы с комфортом можно было писать GUI и на питоне, и на лиспах, и даже на Lua каком-нибудь. В идеале даже прикручивать собственные shared-libraries с любыми биндингами для языков. А ещё чтобы можно было делать пакетирование для андроида полностью из CLI (в том числе на самом девайсе).

Что ж, видимо, прогресс идёт совсем в другую сторону.

Тоже с этим столкнулся, пришлось ставить
adb и сопутствующие тулзы из репозитория дистрибутива и копировать в папку android studio.

vit01> На моём ящике с двумя гигами писать для андроида, мягко говоря, проблематично. На нетбуке же (1ГБ) невозможно в принципе (уже пробовал).

Я на нетбуке пользовался android studio в течении последних трех лет. Нетбук с 1 гб оперативки и 1.6 Ггц intel atom. Но конечно тормозит оно жестоко.

AL> Не хочу C++. Правда яву я хочу ещё меньше =)

А мне вот наоборот ява нравится больше cpp.

Еще под андроид можно на go писать. И на python'е плюс kivy. Правда сам я это все не пробовал.