mc-dev
mc-dev@conference.jabber.ru
[00:29:13] slavazanko/h вышел из конференции
[04:14:17] monkey зашёл в конференцию
[04:20:41] andrew_b зашёл в конференцию
[05:28:04] smind зашёл в конференцию
[06:10:25] slavazanko/h зашёл в конференцию
[06:29:38] smind вышел из конференции
[06:30:11] smind зашёл в конференцию
[06:54:24] imho2 зашёл в конференцию
[06:55:44] <andrew_b> Давайте поактивнее с тикетами, а то такими темпами релиза на этой недели не будет.
[06:57:32] <smind> andrew_b, Хотел спросить
[07:19:15] <andrew_b> Перехотел?
[07:26:53] <smind> )
[07:26:55] <smind> да
[07:27:13] <smind> у нас тут сдача пенсионного
[07:27:19] <smind> так я того...
[07:29:09] <smind> case KEY_RIGHT:
510 /* enter to the group */
[07:29:15] <smind> обоснуй
[07:30:00] <andrew_b> Для симметрии с KEY_LEFT.
[07:31:24] <smind> а о чувствах олдфагов ты подумал?
[07:31:35] <smind> они же привыкли к
[07:32:04] <andrew_b> Обсуждение в тикете.
[07:33:39] <smind> прочёл, ничего не понял
[07:33:54] <smind> такое поведение было же всегда?
[07:34:36] <andrew_b> Такое поведение только у этого диалога. Не как у всех.
[07:34:48] <andrew_b> Теперь будет как у всех.
[07:41:45] <smind> ты меня не убедил
[07:42:12] <andrew_b> Это не я, а автор тикета. Мне пофиг.
[07:42:17] <smind> но я подпишу - пусть эти жалкие людишки испытают боль
[09:59:01] <smind> eb964d7bf6c65547299333851c5b73d69a548e01 это безпредел
[10:01:59] <andrew_b> why?
[10:06:15] <smind> ну это не клинап
[10:07:41] <andrew_b> А что такое клинап?
[10:08:21] <andrew_b> Ладно, убери. У меня в другом бранче есть.
[10:08:22] <smind> afdebc445bfdc08929eaa096d5a668f52cc32c85
[10:08:35] <smind> да я уже почти проголосовал
[10:09:09] <andrew_b> Убери этот коммит и перепушь.
[10:09:21] <smind> ок
[10:09:29] <andrew_b> Не будем потенциальный баг перед релизом вносить.
[10:09:41] <andrew_b> Хотя бага там нет.
[11:21:25] <andrew_b> smind: http://izvestia.ru/news/554596#ixzz2acziXn7f
[11:43:31] <smind> andrew_b, высурковскаяпропоганда
[11:49:37] <andrew_b> Сурков давно не при делах.
[11:50:59] <smind> но дело его живёт
[12:09:33] <smind> просто они сцать начали
[12:10:39] <andrew_b> Я вот не понял, почему Овальный в выборах участвует, если он осуждён?
[12:16:44] <smind> ))
[12:16:53] <smind> нашист детектед :))
[12:17:18] <smind> имеет право
[12:17:26] <andrew_b> Выкинт свой детектор.
[12:17:30] <andrew_b> Выкинь
[12:17:34] <smind> пока прошел суд первой инстанции
[12:20:19] <smind> после того как апелляции пройдут тогда и финиш
[12:21:20] <andrew_b> Ну где там клинап?
[12:21:45] <andrew_b> Мне самому коммит убрать?
[12:23:10] <smind> постоянно на телефоне я
[12:23:22] <smind> у нас конкурс лучшего по профессии
[12:23:31] <smind> и сдача пенсионного
[12:24:13] <andrew_b> Конкурсы какие-то. Оно тебе надо?
[12:25:12] <smind> ваще не надо
[12:25:32] <smind> не представляешь чтойта
[12:36:02] D-ion вышел из конференции: Replaced by new connection
[12:36:05] D-ion зашёл в конференцию
[12:40:25] <smind> такой кипишь что просто пипец
[12:41:15] <smind> вернёмся к навальному
[12:41:35] <smind> andrew_b, тебе показалось что был суд?
[12:42:03] <andrew_b> Да.
[12:52:58] <smind> а ты видел его?
[12:53:16] <andrew_b> Нет.
[12:53:31] <smind> плохо
[12:54:35] <smind> лучше бы представлял уровень цинизма
[12:55:09] <andrew_b> Формально. Суд был? Был. Приговор был? Был.
[12:58:04] <smind> да
[12:58:24] <smind> просто это был не суд
[12:59:50] <smind> но процедура еще не завершена
[13:02:24] <smind> вообще ужасное зрелище беззаконие транслирующееся в прямом эфире
[13:18:33] andrew_b вышел из конференции
[14:11:52] <smind> Зоська Синицкая, 42
[14:12:09] <smind> тупая курица...
[14:12:27] <slavazanko/h> Зоська Синицкая: тест
[14:12:37] <slavazanko/h> сломалась
[14:13:44] <slavazanko/h> По максимуму заревьювал. Предлагаю завтра релизнуться, если не будет возражений
[14:35:03] <smind> не будет
[14:40:45] smind вышел из конференции: offline
[15:51:56] monkey вышел из конференции
[15:52:30] monkey зашёл в конференцию
[16:13:07] sknaumov зашёл в конференцию
[16:28:06] <sknaumov> Здравствуйте. Насчет тикета https://www.midnight-commander.org/ticket/2290 - патч https://www.midnight-commander.org/changeset/f66b1bac8e56a0cb8843ba9ac110d75124a35f0e показал ухудшение производительности и на нативном железе - на Athlon x2 под Xubuntu 12.10 чистый mc-4.8.9, запущенный под xterm, показывал производительность поиска по исходникам ядра linux-3.10.4 примерно 14.9 сек. С данным патчем - примерно 16,4 сек. Я сделал патч, использующий SIGALERT для предотвращения слишком частых изменений строки состояния. Было подозрение, что он будет улучшать производительность только под VirtualBox, но и на железе получилось улучшение производительности - до 13,9 сек. В тикете я писал, что код очень чувствителен к изменениям. Например, если в search_content на стек поместить переменную для хранения длины строки, возвращаемой get_line_at, и передавать эту переменную в get_line_at по ссылке, то время поиска увеличивалось под виртуалкой на 1,5 секунды. Использования для этой цели глобальной переменной (и избавление от strlen) уменьшало время поиска на 0,5 секунды. Также я пробовал сделать get_line_at как inline функцию, а также задать глобальную структуру, чтобы уменьшить число передаваемых в get_line_at параметров. В обоих случаях время поиска увеличивалось на 1,5 - 2 секунды.
[16:30:52] imho2 вышел из конференции
[16:31:33] <sknaumov> Вообще складывается ощущение, что в функциях поиска нужно попробовать отказаться от использования glib функций, по крайней мере, когда речь идет об обработке отдельных символов.
[16:53:02] andrew_b зашёл в конференцию
[17:20:56] <andrew_b> g_string_append_c ?
[17:21:09] <andrew_b> Она не делает ничего лишнего.
[17:27:47] <sknaumov> Там вроде-бы какие-то проверки при каждом вызове совершаются. Я правильно понимаю, что в случае find в filemanager не используется никакой специальной search_fn? Может имее тсмысл вынести этот случай отдельно и не вызывать mc_get_char? Все-таки есть разница - искать в одном файле в mcview или mcedit, и искать во всех файлах линукса... Я поиграюсь с этим на выходных.
[17:28:49] <andrew_b> Хотя, фактически, она добавляет два символа -- собсно сам символ и завершающий нуль.
[17:30:14] <andrew_b> Можно попробовать откатить f66b1bac8e56a0cb8843ba9ac110d75124a35f0e и в качестве длины из get_line_at возвращать i.
[17:32:15] <andrew_b> Проверки делалются в люблм случае, чтобы увеличить буфер.
Было
969 if (i >= buffer_size - 1)
970 buffer = g_realloc (buffer, buffer_size += 80);
Теперь это делается внутри gstring_append_c.
[17:34:35] <andrew_b> static inline GString*
g_string_append_c_inline (GString *gstring,
gchar c)
{
if (gstring->len + 1 < gstring->allocated_len)
{
gstring->str[gstring->len++] = c;
gstring->str[gstring->len] = 0;
}
else
g_string_insert_c (gstring, -1, c);
return gstring;
}
[17:34:44] <sknaumov> Там же новый буфер возвращается. Кстати, он тоже постоянно требует alloc/free. Правда, когда я попытался вынести его и передавать в get_line_at указатель на указатель на буфер и ссылку на длину, то тоже все замедлилось. Можно попробовать использовать глобальную переменную, но это вряд-ли даст большой выигрыш, так как вроде бы маленькие выделения памяти делаются по принципу стэка (brk/sbrk).
[17:38:15] <andrew_b> glib2 использует свой аллокатор. Но его можно заменить на аллокатор из glibc.
[17:38:16] <andrew_b> http://stackoverflow.com/questions/4041458/glib-memory-allocation-vs-std-alloc-and-free
[17:40:18] <sknaumov> Как оказалось, каждая лишняя вшивая операция имеет значение в данном случае. может даже и разыменование указателей. Я считаю, что патч нужно откатить (он везде показал ухудшение - на 10% на железе и на 16% под виртуалкой), тем более, если у вас завтра релиз, а я на выходных посижу и посмотрю что к чему.
[17:40:59] <andrew_b> Этот патч лежит в отдельном бранче и не на что не влияет.
[17:41:07] <sknaumov> тогда ок.
[17:41:11] <andrew_b> Делалось на посмотреть, что получится.
[17:47:33] <sknaumov> Кстати, елси будет время, гляньте на https://www.midnight-commander.org/ticket/2978 - реально лечатся многие клавиши под tmux на xterm (на -256color не прокатило по аналогии). А судя по тому, что и для всяких rxvt тоже используется copy=xterm, то может и для них будет все хорошо. У вас в команде кто-нибудь использует [u]rxvt?
[17:48:19] <andrew_b> Похоже, что никто.
[17:57:40] <sknaumov> Сайт что-то опять сильно барахлит. Тикет 2660 обозначен как closed, но то решение, к которому пришли в конце, так и не дает желаемого эффекта. Чтобы нормально работать с mc, мне приходится его патчить тем изменением, которое предложено в этом тикете изначально (кстати, я независимо дошел до абсолютно такого же патча, и только потом наткнулся на этот тикет).
[17:59:33] <sknaumov> А желаемое поведение - то которое было, помню, на debian lenny, когда только начинал знакомиться с линуксом... То есть нажимаешь ctrl+ins, и selection снимается. Сейчас, если не ошибаюсь, приходится еще туда-сюда подвигать курсор.
[18:00:23] monkey вышел из конференции
[18:03:07] iliamaslakov зашёл в конференцию
[18:08:49] <iliamaslakov> вот вы мне скажите имеет ли смысл оптимизировать чтобы добиться 3-5 процентов оптимизации?
[18:09:57] <iliamaslakov> sknaumov, а снятие вроде опциональное
[18:10:00] <iliamaslakov> нет?
[18:15:12] <sknaumov> У меня на виртуалке время поиска иногда опускалось с 17,5 до 14 секунд. Тем более, что теперь хотя бы можно разобрать, что в этом status line написано, так как обновления идут раз в секунду (правда я пока не сделал того же для директорий, так что они могут обновляться чаще). Если файл большой, то если секунда закончилась в момент его обработки, то при обработке следующей его строки в статусе появится его имя.
[18:15:40] <sknaumov> 10-25%. А на самом деле - 5% там, 5% здесь, и уже появляется разница.
[18:17:35] <sknaumov> Да, есть опция editor_persistent_selections, или как-то похоже называется. Но сейчас ни во включенном, ни в выключенном состоянии она не дает желаемого результата. Во всяком случае так было в 4.8.7.
[18:19:17] <iliamaslakov> просто ни в одном редакторе нет такого чтобы выделение снималось
[18:19:54] <iliamaslakov> то что нужно можно через макросы реализовать
[18:20:06] <sknaumov> За это и люблю mc, что он удобный =)
[18:20:16] <iliamaslakov> без изменений в коде
[18:21:14] <iliamaslakov> на каких клавишах у тебя копирование в буфер?
[18:21:55] <sknaumov> Проблемы по моему у меня были тогда, когда я копирую строку ctrl-ins-ом, нажимаю enter и вставляю - вставляется в выделенный фрагмент. То есть по движению стрелок выделение сейчас снимается, а по Enter - нет.
[18:22:15] <iliamaslakov> а...
[18:22:36] <iliamaslakov> проблема не в том что выделение по Copy не снимается
[18:23:00] <iliamaslakov> а в том что по enter не снимается?
[18:24:13] <sknaumov> ну я то как раз для себя сделал так, чтобы по copy снималось, так как такое поведение было в mc 4.7.0.1. А так - вроде да. Во всяком случае в памяти всплыл именно этот пример. Может и еще где-то неудобно было, но я пропатчил свой mc, так что уже не помню.
[18:25:25] <iliamaslakov> >ну я то как раз для себя сделал так, чтобы по copy снималось
тут не надо патчить
[18:25:37] <iliamaslakov> можно через макрос
[18:25:58] <sknaumov> я не использую, но можно будет попробовать...
[18:26:23] <sknaumov> есть где-нибудь советы по макросам для mc от гуру? =)
[18:28:16] <iliamaslakov> могу сейчас их написать :)
[18:28:20] <sknaumov> а вообще всегда лучше, когда все работает из коробки, поэтому и предложил рассмотреть возможность добавления copy=xterm для screen терминала в mc.lib - всегда приходится это делать...
[18:28:29] <iliamaslakov> где то на хабре вроде писал...
[18:28:42] <sknaumov> если можно =) Но лучше - на сайте в wiki.
[18:28:57] <iliamaslakov> может и на вики есть
[18:33:03] <iliamaslakov> с макросами всё просто жмём ctrl-r делаем что то жмём ctrl-r, жмём хоткей
[18:34:35] <iliamaslakov> а дальше смотрим что показывает ~/.local/share/mc/mc.macros
[18:34:45] <iliamaslakov> mcedit ~/.local/share/mc/mc.macros
[18:40:27] <andrew_b> iliamaslakov: два тикета осталось.
[18:40:39] <andrew_b> До завтра досмотришь?
[18:40:57] <iliamaslakov> Не дави на меня, человек
[18:41:31] <sknaumov> ок, поиграюсь на досуге. В общем я на выходных посмотрю, что можно сделать с поиском. grep по коду ядра справляетсся с поиском меньше чем за секунду, так что еще есть куда стремиться. Патч с переводом get_line_at на g_string_append_c хоть и привел к ухудшению производительности, но зато наглядно показал, что может являться источником проблем. До свидания.
[18:41:35] <iliamaslakov> до 5 утра постараюсь
[18:42:28] sknaumov вышел из конференции
[18:43:53] <iliamaslakov> andrew_b, если бы не An error...
[18:43:57] andrew_b вышел из конференции
[18:45:38] iliamaslakov вышел из конференции
[18:45:54] iliamaslakov зашёл в конференцию
[19:34:33] iliamaslakov вышел из конференции
[19:37:34] iliamaslakov зашёл в конференцию
[21:01:47] slavazanko/h вышел из конференции
[21:06:34] slavazanko/h зашёл в конференцию
[22:08:19] iliamaslakov вышел из конференции
