[>]
Re: PM
develop.16
Difrex(mira, 14) — vit01
2016-04-28 15:10:55
>Жаль, что перл, а то бы TODO-шка твоя быстро опустела :) Хотя подозреваю, что там не все планы.
Ридми давно не апдейтил, а хелп в самом коде так и подавно =) Запушил
[>]
Re: PM
develop.16
vit01(mira, 1) — Difrex
2016-04-28 15:39:33
Кстати, решил изучить вопрос по вот этому TODO:
> Store decrypted DB into RAM not in /tmp/
и обнаружил, что ни DBI, ни сам sqlite не поддерживают загрузку бинаря базы данных из RAM.
Единственный быстрый путь решения, который представляется возможным (и который предлагают люди), заключается в том, чтобы создавать пустую базу в памяти и загружать в неё данные из дампа через CREATE TABLE ...
В таком случае БД придётся даже в зашифрованном виде хранить не в виде sqlite-файла, а в виде sql-дампа. Грустно и медленно, но зато 100% безопасно.
Если тебя устроит данный способ взаимодействия, то могу форкнуть и приделать.
[>]
Re: PM
develop.16
Difrex(mira, 14) — vit01
2016-04-29 07:16:01
>и обнаружил, что ни DBI, ни сам sqlite не поддерживают загрузку бинаря базы данных из RAM.
Да, я знаю про это. Вообще я думал попробовать так:
* Расшифровать базу в память - тут все норм
* Подсунуть базу драйверу sqlite как файл, т.е. через \$bd
>В таком случае БД придётся даже в зашифрованном виде хранить не в виде sqlite-файла, а в виде sql-дампа. Грустно и медленно, но зато 100% безопасно.
>Если тебя устроит данный способ взаимодействия, то могу форкнуть и приделать.
Если получится, то было бы круто =)
[>]
Re: Несетевые проекты
develop.16
Difrex(mira, 14) — btimofeev
2016-04-29 07:29:07
>Сорри за оффтоп, но чем pass не устроил? https://www.passwordstore.org/
Мне он был не удобен. Мне нужен был именно плоский вывод имен, т.к. я часто использую подобное:
pm -sn all | tail -3
Так же мне хотелось xdg-open, чтобы сразу перейти по ссылке. Хотелось комментариев к паролям, и.т.д.
Короче, pass мне был не удобен и я написал свой велосипед. :)
[>]
Re: PM
develop.16
vit01(mira, 1) — Difrex
2016-04-29 14:10:21
Difrex> * Подсунуть базу драйверу sqlite как файл, т.е. через \$bd
И как бы это примерно выглядело? Непонятно, что под этим ты имеешь в виду.
Вместо хранения дампа можно сделать в том числе и Named Pipe, именно так лучше и попробую.
[>]
Re: PM
develop.16
vit01(mira, 1) — vit01
2016-04-29 16:12:14
Итак, Named Pipes эта штука так же не поддерживает. А жаль, потому что в MySQL можно было нормально сделать LOAD DATA INFILE, и всё бы пахало, как часы.
Лучше было бы вообще не sqlite использовать, а json какой-нибудь, с ним бы точно проблем не было.
[>]
Re: PM
develop.16
Andrew Lobanov(tavern,1) — All
2016-04-29 17:33:12
А как вообще в сабже с безопасностью? В каком виде оно хранится? А то я чёт перловые исходники совсем не разумею, а времени на кемел бук нет пока.
[>]
Re: PM
develop.16
vit01(mira, 1) — Andrew Lobanov
2016-04-29 17:53:31
Оно хранится в зашифрованном (через GPG) виде в $HOME. При каждом взаимодействии база расшифровывается, находясь в /tmp, и сразу же удаляется.
Небезопасность заключается в том, что из /tmp расшифрованный файл базы можно позднее восстановить, если этот самый /tmp не примонтирован в виде tmpfs.
[>]
Re: PM
develop.16
vit01(mira, 1) — Difrex
2016-05-01 14:38:34
Форкнул сабж и написал туда чуть-чуть:
https://github.com/vit1-irk/PM
Изменения:
* Теперь можно импортировать БД из файла
* При автогенерации пароля можно при желании задать его длину
* Место расшифрованной БД поменял на /dev/shm
Третий пункт сделал из-за того, что /tmp люди не всегда монтируют, как tmpfs (некоторые просто на диске его держат), а /dev/shm всегда автоматически ставится в tmpfs.
Скажи, что ещё хотел бы сделать. Помогу и сделаю пулл-реквест (или сейчас сделаю, если хочешь).
[>]
Re: PM
develop.16
Difrex(mira, 14) — vit01
2016-05-04 07:48:00
>Помогу и сделаю пулл-реквест (или сейчас сделаю, если хочешь).
Делай пулл-реквест(только в AUTHORS себя не забудь добавить :), я потестю на своей базе из ~150 паролей и смержу в мастер.
>Скажи, что ещё хотел бы сделать.
Да вот красивый вывод в pm -sn all, только хочется. Все руки не дошли до того, чтобы сделать это.
Еще есть проблема в SQL, там нет уникального ключа по имени. Да и вообще, я думаю, что стоит перейти на что-то noSQL, хотябы на perl Storable. + в этом, что избавимся в зависимостях от sqlite.
[>]
Re: PM
develop.16
vit01(mira, 1) — Difrex
2016-05-04 11:53:48
Difrex> Да вот красивый вывод в pm -sn all, только хочется. Все руки не дошли до того, чтобы сделать это.
Он разве слишком некрасивый? Там даже цвет есть, насколько видно.
Хотя всё-таки есть, чего улучшить. У меня вот в терминале тема оформления светлая, поэтому поле ID не видно совсем.
Difrex> Еще есть проблема в SQL, там нет уникального ключа по имени.
Ну это на раз-два.
Difrex> Да и вообще, я думаю, что стоит перейти на что-то noSQL, хотябы на perl Storable. + в этом, что избавимся в зависимостях от sqlite.
Попробую почитать что-нибудь на эту тему. А sqlite действительно не очень хорошо здесь смотрится. Скорее, это проблема самой перловой реализации (сделали только самые базовые вещи).
[>]
Re: PM
develop.16
Difrex(mira, 14) — vit01
2016-05-04 12:26:13
>Difrex> Да вот красивый вывод в pm -sn all, только хочется. Все руки не дошли до того, чтобы сделать это.
vit01> Он разве слишком некрасивый? Там даже цвет есть, насколько видно.
Я просто хотел сделать, как в mysql/pgsql - табличка, чтобы рисовалась.
>Попробую почитать что-нибудь на эту тему. А sqlite действительно не очень хорошо здесь смотрится. Скорее, это проблема самой перловой реализации (сделали только самые базовые вещи).
Там делов-то немного. Переписать только функции из DB.pm, я вечерком, может займусь =)
[>]
PM
develop.16
vit01(mira, 1) — Difrex
2016-05-09 10:05:08
В своём репозитории сабжа сделал ветку testing.
В этой ветке сделал вывод в красивую таблицу и исправил твой костыль с дублированием кода при выводе информации.
Протестируй и выскажи своё мнение.
./pm.pl -s -n all
[>]
Re: PM
develop.16
vit01(mira, 1) — Difrex
2016-05-09 12:32:26
Difrex> Есть только проблема с отображением, если uri в ресурсе очень длинный - табличку корежит
Difrex> Я, в принципе, знаю как это поправить.
Там таблица строится очень просто - обычным дополнением пробелов справа.
Если получится починить, то очень хорошо. Сам просто не придумал, как такие случаи обрабатывать. Только если обрезать строку, но это не очень правильно.
[>]
Re: Несетевые проекты
develop.16
vit01(mira, 1) — vit01
2016-05-15 17:27:12
Итак, в PM вроде всё устоялось с фичами (если появятся ещё какие-нибудь хотелки, то пусть Денис пишет, поломаю голову).
Надо ещё и больше.
Что можете предложить из того, что не связано с нашей сеткой, но интересно было бы сделать вместе?
[>]
Re: Несетевые проекты
develop.16
Difrex(mira, 14) — vit01
2016-05-16 09:14:04
>Итак, в PM вроде всё устоялось с фичами (если появятся ещё какие-нибудь хотелки, то пусть Денис пишет, поломаю голову).
Да, большое спасибо за коммиты :)
>Что можете предложить из того, что не связано с нашей сеткой, но интересно было бы сделать вместе?
Не заинтересует такая штука?
https://github.com/Difrex/azot
[>]
Re: Несетевые проекты
develop.16
vit01(mira, 1) — Difrex
2016-05-16 09:20:44
Difrex> Не заинтересует такая штука? https://github.com/Difrex/azot
Забавная вещь. И каковы планы по её улучшению? Делает своё дело, судя по видео, вполне исправно.
[>]
Re: Несетевые проекты
develop.16
Difrex(mira, 14) — vit01
2016-05-16 11:25:26
Жрет ресурсы не в себя. Там постоянно опрашивается положение курсора.
Было бы круто использовать что-то типа Inotify, но для X, а не FS.
[>]
Re: azot
develop.16
vit01(mira, 1) — Difrex
2016-05-16 13:53:21
Difrex> Жрет ресурсы не в себя. Там постоянно опрашивается положение курсора.
Вроде бы, это единственный рабочий способ для иксов.
Решил проверить, как реализуются действия с углами в аналогах сабжа. Откопал программу brightside (есть в дебиановских репах), посмотрел исходники и обнаружил, что там отслеживание тоже делается с помощью своеобразного таймера, который смотрит положение.
На уровне оконных менеджеров это должно делаться так же.
Для производительности можно переписать сабж на Си, но вряд ли будет сильный прирост.
Что думаешь?
[>]
Re: azot
develop.16
Difrex(mira, 14) — vit01
2016-05-18 08:06:13
>Для производительности можно переписать сабж на Си, но вряд ли будет сильный прирост.
Я думал на счет Go :). Но проблема не в этом.
>Что думаешь?
Например, у меня на федоре иксы через примерно час начинают отлупливать соединения от Azot, типа, слишком часто. Скорее всего надо один раз подключаться и работать в пределах этой сессии, но как это сделать - я не знаю.
>удивило, кстати, что python2, а не python3
Привык я ко второму питону, но там под третий совсем немного переписывать.
ЗЫ: Покажи свои проекты, интересно :)
[>]
Re: azot
develop.16
vit01(mira, 1) — Difrex
2016-05-18 09:51:51
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. Сделать автоматическую подгрузку конфига, чтобы в самый первый раз не вручную копировать
Если возражений не будет, то примусь за него.
[>]
Re: Несетевые проекты
develop.16
btimofeev(station13, 13) — All
2016-05-19 13:03:53
У меня из проектов на гитхабе самое интересное
https://github.com/btimofeev/emuchip
Это была моя попытка написать эмулятор простейшего компьютера, на примере Chip8 и SuperChip. Все игры для этих систем работают (за исключением одной, кажется). Но в эмуляторе есть пара ошибок, которые я так и не решил (одна связана с размером окна Qt, вторая с указателями c++).
[>]
Re: azot
develop.16
vit01(mira, 1) — vit01
2016-05-19 13:19:26
Сделал в сабже вот что:
* Инициализация дисплея для иксов теперь проходит только один раз
* В конфиге можно задавать самому задержку для проверки курсора
* Конфиг в самом начале не надо копировать вручную, программа сделает это сама
(вариант копирования из /usr/share/doc/ тоже работает)
* Теперь азот работает не на втором питоне, а на третьем
По первому пункту скажу, что после исправления сабж у меня исправно проработал около двух часов и никаких болезненных симптомов не показывал. Так что, видимо, проблема решена. Но протестировать всё равно надо.
[>]
Re: Несетевые проекты
develop.16
vit01(mira, 1) — btimofeev
2016-05-19 13:33:44
Серьёзная вещь, надо бы посмотреть.
btimofeev> Но в эмуляторе есть пара ошибок, которые я так и не решил (одна связана с размером окна Qt, вторая с указателями c++).
Если руки дойдут, то и над этим голову поломать можно. Можно поподробнее, что за ошибки?
btimofeev> // а вообще я всегда хотел написать эмулятор Sega Mega Drive, но думаю не дорос еще))
Это и вправду сложная задача. Но зато есть и те, кто на эту платформу до сих пор пишет. Вот у меня есть знакомый (который даже в секте появлялся пару раз), регулярно делающий что-нибудь под сегу на ассемблере. Музыку пишет и всякие прикольные графические эффекты.
[>]
Re: Несетевые проекты
develop.16
btimofeev(station13, 13) — vit01
2016-05-19 14:13:57
vit01> Если руки дойдут, то и над этим голову поломать можно. Можно поподробнее, что за ошибки?
1. При изменении размера окна внизу появляется пустая полоса в несколько пикселей. Не понимаю откуда она берется.
2. Второе это даже не ошибка, а не очень хорошо написанный код. Внутри эмулятор создает двумерный массив, представляющий экран. Виджет должен отрисовать этот массив на экране. Вот передача этого массива между объектами реализована полным копированием, а не передачей указателя. Все мои попытки передать указатель заканчивались segfault'ом. Здесь наверное сказывается мое плохое знание c++, либо неправильная архитектура.
[>]
Re: emuchip-qt
develop.16
vit01(mira, 1) — btimofeev
2016-05-21 10:16:41
btimofeev> 2. ..... Вот передача этого массива между объектами реализована полным копированием, а не передачей указателя. Все мои попытки передать указатель заканчивались segfault'ом. Здесь наверное сказывается мое плохое знание c++, либо неправильная архитектура.
У меня получилось решить эту проблему. Вот приду с репетиции вечером, причешу код немного и закину на Гитхаб.
Правда, производительность только чуть-чуть повысилась, но всё же.
Над qt-шной пустой полосой пока думаю.
[>]
Re: emuchip-qt
develop.16
vit01(mira, 1) — vit01
2016-05-21 10:48:40
О, а кода там совсем немного. Уже сейчас успел отправить, можно мержить, собирать и проверять.
[>]
Re: emuchip-qt
develop.16
btimofeev(station13, 13) — vit01
2016-05-21 19:02:09
vit01> О, а кода там совсем немного. Уже сейчас успел отправить, можно мержить, собирать и проверять.
Спасибо, смержил.
Насчет производительности: демки qt отрисовывают тысячи объектов с огромной скоростью, тут же отрисовка сотни квадратов порой тормозит. Особенно заметно на демках типа Climax Slideshow, на высоких разрешениях.
Я тут еще антиалиайсинг отключил, как то упустил его при портировании на qt5.
[>]
Re: emuchip-qt
develop.16
vit01(mira, 1) — btimofeev
2016-05-23 20:43:24
Хорошо. А я тут наконец-то выяснил, почему появляется та самая белая полоса внизу окна. Это происходит из-за того, что размеры окна становятся больше, чем размер [холста + меню].
У тебя есть функции set1x(), set2x() и так далее. Внутри них есть такой кусок кода:
setFixedSize (512, 256 + menuBar()->height()); // например, так
Так вот, обнаружил, что перед первой отрисовкой окна (то есть при вызове readSettings() из конструктора) функция height() выдаёт одно значение, а после отрисовки - другое. У меня правильным оказывается второе значение, а первое - на 3 пикселя больше, чем надо.
Варианты: либо продолжить разборки и найти в самом Qt причины этого, либо сделать какой-нибудь костыль.
[>]
Re: emuchip-qt
develop.16
vit01(mira, 1) — vit01
2016-05-24 06:02:48
Починил проблему с полосой, установив EventFilter на событие изменения размера меню.
Заодно сделал получение объекта menuBar единичным, а то как-то не очень хорошо для каждого раза заново метод вызывать.
[>]
Re: emuchip-qt
develop.16
btimofeev(station13, 13) — vit01
2016-05-24 11:34:30
vit01> Починил проблему с полосой, установив EventFilter на событие изменения размера меню.
Работает, спасибо. Кстати, добавь себя в файл authors.
[>]
Re: emuchip-qt
develop.16
btimofeev(station13, 13) — vit01
2016-05-24 16:30:31
vit01> Надо бы какой-нибудь покрупнее проект найти.
Могу предложить поучаствовать в относительно крупном проекте. Есть очень неплохой консольный музыкальный плеер cmus. У его плагинной системы один недостаток: из плагина нельзя добавить несколько треков в плейлист (это нужно для музыкальных форматов в которых в одном файле может содержаться несколько треков). К примеру в плагинах поддержки cue и cd это сделано хаками: часть кода плагина содержится в коде программы. И это сильно усложняет написание подобных плагинов + при компиляции плагина нужно перекомпилировать и программу. Текущий майнтейнер проекта не против изменений, но никто за реализацию этого так и не взялся.
vit01> // Плюсы, кстати, неплохая вещь, особенно, в связке с Qt. Жаль, что раньше никогда почти дел с ними не имел.
А мне они уже не нравятся, слишком сложный язык, по-моему.
[>]
Re: emuchip-qt
develop.16
vit01(mira, 1) — btimofeev
2016-05-25 02:49:59
vit01> // Плюсы, кстати, неплохая вещь, особенно, в связке с Qt. Жаль, что раньше никогда почти дел с ними не имел.
btimofeev> А мне они уже не нравятся, слишком сложный язык, по-моему.
Смотря с чем сравнивать. Вот если сравнить C++ & Qt с Java на андроиде, то первая связка гораздо приятнее в работе.
А так на питоне проще всего делать. Вот хорошее отличие от питоновского PyQt в том, что не надо заморачиваться с импортами разных фич (т.е. не надо помнить заранее, какая вещь в каком классе находится).
[>]
Re: Несетевые проекты
develop.16
vit01(mira, 1) — btimofeev
2016-05-25 02:49:59
btimofeev> Могу предложить поучаствовать в относительно крупном проекте. Есть очень неплохой консольный музыкальный плеер cmus.
Спасибо за идею. Вот собрал его только что, потом освою и буду исходники курить.
[>]
Re: cmus
develop.16
vit01(mira, 1) — vit01
2016-05-27 16:55:41
Заняться хакингом сабжа таки получилось. Начал с перемещения неуместного кода для cue в отдельное место (благо оно там уже есть) и с написания отдельного обработчика для "особенных" форматов.
Дальше планирую ещё больше убрать из самого плеера плагин-специфичные куски кода, но с таким количеством хаков и костылей это придётся делать постепенно и небыстро.
Проталкивать в апстрим пока страшновато (несмотря на то, что моя ветка уже собирается и не сегфолтится).
[>]
Re: cmus
develop.16
btimofeev(station13, 13) — vit01
2016-05-27 17:33:17
vit01> Проталкивать в апстрим пока страшновато (несмотря на то, что моя ветка уже собирается и не сегфолтится).
Лучше создай заранее issue с обсуждением изменений или напиши на почту майнтейнеру приложения (его ник flyingmutant, он из России, на почту он нормально отвечает), так как он делает код ревью и отправляет на доработку если ему что-то не нравится (мой простенький vtx плагин со второго или третьего раза принял, точно не помню).
[>]
Re: cmus
develop.16
vit01(mira, 1) — btimofeev
2016-06-05 16:46:22
Разработчик мне только сегодня ответил. Пишет, что времени на просмотр кода у него очень мало, но подбадривает и говорит, чтобы я продолжал. Как сделаю большую часть, то пулл-реквест открою.
С кодом cd посложнее будет, потому что там инициализация модуля в самом коде находится. Больше всего вопросов по коду определения типа файла. Но ничего, зато нескучно будет.
Планирую сделать в каждом плагине функцию инициализации, где всякая экзотика сможет регистрировать собственные обработчики плейлистов и других штук.
[>]
Re: cmus
develop.16
btimofeev(station13, 13) — vit01
2016-06-06 05:52:39
Можешь еще посмотреть код deadbeef'а, у него внутри плагина доступна функция для добавления нескольких треков.
[>]
Re: cmus
develop.16
vit01(mira, 1) — btimofeev
2016-06-13 19:02:57
btimofeev> Можешь еще посмотреть код deadbeef'а, у него внутри плагина доступна функция для добавления нескольких треков.
deadbeef как раз на разные сомнительные штуки имеет функцию плагиноинициализации. Здесь я сделал подобную вещь и тем самым завершил перенос функций добавления плейлиста внутрь плагинов.
Посмотрим, что разработчик ответит:
https://github.com/cmus/cmus/pull/460
[>]
Google и x86_32
develop.16
vit01(mira, 1) — All
2016-07-12 05:02:26
Корпорация постепенно избавляется от поддержки 32-битных систем в своих инструментах для разработчиков. Так опытным путём я выяснил, что последняя рабочая версия SDK - 24, при этом в ней надо ещё заменить подкаталог build-tools на такой же из 23.0.1.
Последний рабочий вариант NDK - версия 10.
Если попытаться обновить SDK через встроенный конфигуратор, на следующий раз он просто не запустится. И даже не выдаст предупреждения, дескать, "ставится только 64-битная сборка, вы уверены?"
В официальных ChangeLog об изменениях написано вскользь и мелким шрифтом.
Понимаю, конечно, что гуглу просто лень делать сборки, но надо же хоть как-то предупреждать. А то нажал кнопочку "Обновить", и сборочное окружение полностью сломано. Несерьёзно для такой большой корпорации.
[>]
Re: Google и x86_32
develop.16
vit01(mira, 1) — vit01
2016-07-12 05:14:21
И ещё немного упрёков в сторону продуктов сабжа. В системных требованиях для Android Studio указано, что минимальный объём ОЗУ должен быть 2 гига, а рекомендуемый - 8.
На моём ящике с двумя гигами писать для андроида, мягко говоря, проблематично. На нетбуке же (1ГБ) невозможно в принципе (уже пробовал).
Гугл, ты серьёзно? 8 гигов оперативы для мелкого Android-HelloWorld?
Короче, парни, пишите на C++ и Qt. Да, у них тоже есть свои минусы, но зато гораздо ниже системные требования, и оно работает на 32-битных системах. А поддержка Андроида и кроссплатформенности у Qt со временем постоянно улучшается. Кроме этого, можно писать в любимом Vim/Emacs.
[>]
Re: Google и x86_32
develop.16
Andrew Lobanov(tavern,1) — vit01
2016-07-12 05:20:18
> Понимаю, конечно, что гуглу просто лень делать сборки, но надо же хоть как-то предупреждать. А то нажал кнопочку "Обновить", и сборочное окружение полностью сломано. Несерьёзно для такой большой корпорации.
Эта общая тенденция нынче. 32-разрядные системы постепенно уходят в прошлое, так как с них уходят разработчики и им лень заниматься сборкой. И везде или мелким шрифтом или молча это делают.
[>]
Re: Google и x86_32
develop.16
vit01(mira, 1) — Andrew Lobanov
2016-07-12 05:38:55
AL> Не хочу C++. Правда яву я хочу ещё меньше =)
Пока что, увы, скриптовые языки на мобильных платформах совсем не развиты. Любой подобный эксперимент требует индивидуального подхода и кучи сил/времени.
Я вон тоже мечтаю, чтобы с комфортом можно было писать GUI и на питоне, и на лиспах, и даже на Lua каком-нибудь. В идеале даже прикручивать собственные shared-libraries с любыми биндингами для языков. А ещё чтобы можно было делать пакетирование для андроида полностью из CLI (в том числе на самом девайсе).
Что ж, видимо, прогресс идёт совсем в другую сторону.
[>]
Re: Google и x86_32
develop.16
btimofeev(station13, 13) — vit01
2016-07-12 12:37:45
Тоже с этим столкнулся, пришлось ставить
adb и сопутствующие тулзы из репозитория дистрибутива и копировать в папку android studio.
vit01> На моём ящике с двумя гигами писать для андроида, мягко говоря, проблематично. На нетбуке же (1ГБ) невозможно в принципе (уже пробовал).
Я на нетбуке пользовался android studio в течении последних трех лет. Нетбук с 1 гб оперативки и 1.6 Ггц intel atom. Но конечно тормозит оно жестоко.
[>]
Re: Google и x86_32
develop.16
btimofeev(station13, 13) — Andrew Lobanov
2016-07-12 12:37:46
AL> Не хочу C++. Правда яву я хочу ещё меньше =)
А мне вот наоборот ява нравится больше cpp.
Еще под андроид можно на go писать. И на python'е плюс kivy. Правда сам я это все не пробовал.