make world better

[elfmz]

make world better

[lieff]

Заметил что ls выводится без цветов, когда ls --color=always цветной вывод работает нормально.
Значит надо сделать, чтобы дефолтная детекция, выводить цвета или нет, у ls срабатывала.

[elfmz]

Там внутри запуск идет через /bin/sh а если ls выполнить из sh - он выводит по дефолту без цвета. А вот если выполнить его из bash - по дефолту с цветом
Почему так - хз.. Впрочем сделать детект юзерского шелла и юзать bash вместо sh не помешает, да..

[lieff]

Попробовал изменить в execute.cpp на /bin/bash, но цвета не появились.
Возможно поэтому:

strace ls 2>&1 |grep ioc
ioctl(1, TCGETS, 0x7ffcdfbad360)        = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(1, TIOCGWINSZ, 0x7ffcdfbad420)    = -1 ENOTTY (Inappropriate ioctl for device)

И через strace цветов тоже нет.

[elfmz]

А это у вас такие ошибки со старым кодом или с новым (с сегодняшнего утра?) у меня таких нету. Впрочем bash -c ls не выдает цветного ls даже будучи и так запущенным под башем

[lieff]

Это не в фаре вообще. Я подозреваю что он пытается выполнить ioctl(1, TCGETS) и проваливается потому что stdout не приконнекчен к tty. Дальше он даже никаких getenv() не делает и считает что все, цветов выводить точно не надо.
Похоже нужно приконнектить его в фейковому tty, можно посмортеть как сделано в mc.

[lieff]

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

[elfmz]

Я это уже давно нашел, поковырялся и запостил багу на wxwidgets: http://trac.wxwidgets.org/ticket/17643
В процессе ковыряния придумался только один дичайший воркэраунд - перехватить XNextEvent и обрабатывать события клавы от Х самому. Но ведь это ректальный путь. В принципе можно еще попробовать пофиксить WX или может даже GTK и отправить им.. Но тут и своих проблем хватает.. Ctrl+Insert etc работают кстати всегда нормально, но не всем они привычны

[lieff]

Попробовал wxWidets 3.1, far по прежнему не работает, однако хоткеи вроде Ctrl-Q у сэмплов при включенном русском отрабатывают нормально.

[lieff]

Крашится под valgrind, если открыть любой файл в редакторе. Сообщения от valgrind стоит почистить, есть множество обращений к неинициализированным переменным и ликов.

[elfmz]

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

[elfmz]

по поводу пробелов кавычек etc: я уже насмотрел где и как сделать escaping, осталось только сделать для чего время нужно.. Я к тому что не стоит там делать сейчас костыли на каждый конкретный случай, все равно потом переделаю скорее всего (а может и нет :) )

[lieff]

Ну strong quote по идее позволяет как раз избежать множества случаев, все что надо эскейпить внутри 'test' это сами одинарные кавычки 'te'''st'. Получаем полную поддержку всех файловых имен никсов.

[invy]

Coding style, bugs prevention, static analysis.

• Write code in modern C++ (enforce c++14) and not the 'C with classes', because you are going to shoot yourself in the leg: spending too much time on implementing already implemented things (std::algorithm, boost), introducing bugs, fixing them. I've noticed in some commits, that they are written in the old fashioned with raw pointers, null-terminated strings, usage of C runtime, etc, which is not a good thing to do in 2016.
• Enforce 'warnings as errors' and compile with all warnings enabled with different compilers. (g++ and clang)

[invy]

Finally I've got far building with cmake.
Of course, first what I've did, is tried clang.

Here are some warnings and errors.

/home/igor/projects/test/far/far2l/WinPort/WinCompat.h:141:22: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare]
if (d>=0 && d<=9) *w = d + '0';
~^ ~

/home/igor/projects/test/far/far2l/WinPort/ConsoleBuffer.cpp:26:46: error: non-constant-expression cannot be narrowed from type 'unsigned int' to 'SHORT' (aka 'short') in initializer list [-Wc++11-narrowing]
SMALL_RECT screen_rect = {0, 0, width - 1, height - 1};

/home/igor/projects/test/far/far2l/WinPort/APIRegistry.cpp:44:7: error: case value is not a constant expression
case (ULONG_PTR)HKEY_PERFORMANCE_TEXT: return GetRegistrySubroot("/pt");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[elfmz]

первое - мелкий косяк, последнее - непонятно что ему не нравится? там однозначная константа, более того - там еще 5 такихе же в соседних кейсах

[invy]

В соседних кейсах тоеж ругается, если что. Я не стал весь лог приводить - там много.
Очевидно тайп каст в кейсе его смущает.

[techtonik]

Tightly integrating with upstream is the only True way for a better world. =)

[elfmz]

True way to better world is making world better, but not making better words.

[invy]

There is actually no point in tight integration with upstream, because it's too windows specific. The new cool features can be relatively easy backported from upstream, I think.

[invy]

Меня вот вопрос мучает, что я делаю не правильно в моем cmake, что у меня плагины не загружаются... Вроде как заставил far2l эскпортировать winport, все компилируется. Надо разбираться...

[elfmz]

Мож чего не экспортируют важного?

~/projects/far2l/Build$ nm -g --defined-only Plugins/multiarc/bin/multiarc.far-plug-mb 
00000000002873b0 B __bss_start
0000000000008a50 T ClosePlugin
0000000000008ba0 T Configure
0000000000008ab0 T DeleteFiles
00000000002873b0 D _edata
00000000002a05b0 B _end
0000000000008ae0 T ExitFAR
000000000006eb78 T _fini
0000000000008a90 T FreeFindData
0000000000008ac0 T GetFiles
0000000000008a80 T GetFindData
00000000000081a0 T GetMinFarVersion
0000000000008b70 T GetOpenPluginInfo
0000000000008b10 T GetPluginInfo
00000000000062c0 T _init
0000000000008420 T OpenFilePlugin
00000000000086a0 T OpenPlugin
0000000000008b80 T ProcessHostFile
0000000000008b90 T ProcessKey
0000000000008ad0 T PutFiles
0000000000008aa0 T SetDirectory
00000000000081b0 T SetStartupInfo
0000000000285c28 V _ZTI8RAR_EXIT
0000000000072200 V _ZTS8RAR_EXIT

[invy]

В том то и дело что экспортирует. Когда стартую фар, то colorer вот такое выдает
WINPORT: LoadLibraryEx(/home/igor/projects/test/far/build/install/Plugins/colorer/bin/colorer.far-plug-mb): 0x7fe12c118860
GetProcAddress(0x7fe12c118860, SetStartupInfo) - no such symbol
GetProcAddress(0x7fe12c118860, OpenPlugin) - no such symbol
GetProcAddress(0x7fe12c118860, OpenFilePlugin) - no such symbol
GetProcAddress(0x7fe12c118860, ClosePlugin) - no such symbol
GetProcAddress(0x7fe12c118860, GetPluginInfo) - no such symbol
GetProcAddress(0x7fe12c118860, GetOpenPluginInfo) - no such symbol
GetProcAddress(0x7fe12c118860, GetFindData) - no such symbol
GetProcAddress(0x7fe12c118860, FreeFindData) - no such symbol
GetProcAddress(0x7fe12c118860, GetVirtualFindData) - no such symbol
GetProcAddress(0x7fe12c118860, FreeVirtualFindData) - no such symbol
GetProcAddress(0x7fe12c118860, SetDirectory) - no such symbol
GetProcAddress(0x7fe12c118860, GetFiles) - no such symbol
GetProcAddress(0x7fe12c118860, PutFiles) - no such symbol
GetProcAddress(0x7fe12c118860, DeleteFiles) - no such symbol
GetProcAddress(0x7fe12c118860, MakeDirectory) - no such symbol
GetProcAddress(0x7fe12c118860, ProcessHostFile) - no such symbol
GetProcAddress(0x7fe12c118860, SetFindList) - no such symbol
GetProcAddress(0x7fe12c118860, Configure) - no such symbol
GetProcAddress(0x7fe12c118860, ExitFAR) - no such symbol
GetProcAddress(0x7fe12c118860, ProcessKey) - no such symbol
GetProcAddress(0x7fe12c118860, ProcessEvent) - no such symbol
GetProcAddress(0x7fe12c118860, Compare) - no such symbol
GetProcAddress(0x7fe12c118860, ProcessEditorInput) - no such symbol
GetProcAddress(0x7fe12c118860, ProcessEditorEvent) - no such symbol
GetProcAddress(0x7fe12c118860, ProcessViewerEvent) - no such symbol
GetProcAddress(0x7fe12c118860, ProcessDialogEvent) - no such symbol
GetProcAddress(0x7fe12c118860, GetMinFarVersion) - no such symbol
bad3
bad3
bad3

фар выдает сообщение о том что не может загрузить плагин и потом все вот так примерно падает, когда завершаю фар
*** Error in `./far2l': corrupted double-linked list: 0x00007fe12c118430 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fe13e5da725]
/lib/x86_64-linux-gnu/libc.so.6(+0x7e783)[0x7fe13e5e1783]
/lib/x86_64-linux-gnu/libc.so.6(+0x8155e)[0x7fe13e5e455e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7fe13e5e65a4]
./far2l(xf_malloc+0x20)[0x5262de]
./far2l(_Znwm+0x18)[0x5263e9]
./far2l(_ZN9__gnu_cxx13new_allocatorI10_CHAR_INFOE8allocateEmPKv+0x40)[0x680030]
./far2l(_ZNSt16allocator_traitsISaI10_CHAR_INFOEE8allocateERS1_m+0x28)[0x67ff5d]
./far2l(_ZNSt12_Vector_baseI10_CHAR_INFOSaIS0_EE11_M_allocateEm+0x2a)[0x67fddc]

Хм, хотф colorer не совсем то экспортирует. В общем буду разбираться.

PS: скорость сорки примерно в полтора раза выше ;)

[elfmz]

colorer должен иметь расширение .far-plug-wide а не .far-plug-mb, far-plug-wide - это по-старославянски - UNICODE плагины, а MB - OEM/ANSI плагины. Нынче они по сути все юникодные, просто одни юзают wchar_t * строки, вторые char * (С UTF8)
Скорость сборки лично меня ваще не напрягает. Нужный модулль после своих изменений кодлайт компиляет за пару сек, если не просить ребилд делать. Ну а после обновления с гита можно и несколько мин подождать. Вощем это ветряная мельница ИМХО, а не проблема.
Кстати если вы не кодлайтом собирали, make- у -j 4 (или сколько там ядер у вас) не забывали передавать?

[invy]

У меня нет кодлайта, собираю из консоли, -j12.... (на моих 4х ядрах вполне оптимально получается). С cmake'ом вот темерь могу qtcreator'ом пользоваться (ради него и хочу cmake).

С плагинами явно что-то уменя с экспортами/импортами не так.

[elfmz]

еще раз - бинарник colorer-а должен называться colorer.far-plug-wide, а не colorer.far-plug-mb тогда и проблема с экспортами решится

[invy]

Это-то понятно, но это не решило моей проблемы :)

[elfmz]

Это странно, потому что неправильное имя полностью объясняло проблему. Для другого типа плагина искало другие экспорты

[invy]

При том поведение сейчас у меня весьма странное. Сначала не может загрузить farftp, потом colorer, потом загружает всё, но при попытке использовать любой из плагинов фар зависает намертво. Явно что-то не так делаю.

[elfmz]

Дык это.. gdb в руки.
Кстати а файлы языков и прочие там базы для колорера лежат где положено? Без этого плагины не очень адекватно себя ведут.

[invy]

Та ясное дело, но все лежит как надо. Опять же ругается почему-то на экспорты.

[elfmz]

Кстати, а qtcreator зачем? На qt переводить консоль?

[invy]

Нет, qtcreator просто мощное быстрое и удобное IDE для плюсов. Пока что у меня на первом месте.

[elfmz]

аа
ну насчет экспортов - я бы начал с попытки заюзать старый фар + плагины из-под cmake, и наоборот. Дальше - по обстоятельствам

[invy]

Может я просто чего-то не учел собирая плагины? Как они должны линковаться к фару и другим библиотекам? Динамически к far2l?

[elfmz]

да, far2l экспортирует WINPORT функциональность и плагины таким образом юзают один винпорт на всех. А фар в свою очередь получает символы плагинов динамически через dlopen/dlsym.
Особенности которые вспомнил:

• Перед указанием либы WinPort в опциях линкера far2l нужно указать [-Wl,--whole-archive] - это чтобы линкер целиком втянул весь код WinPort, ну и соответственно все нужные функции будут экспортироватьяс из far2l. Без этой опции экспортироватьяс будет только то, что юзает сам far2l, а юзает он не все, что есть в WinPort (и что юзают другие плагины).
• У всех проектов в настройках компилятора указано -fvisibility=hidden Без этого из модулей экспортируетя ваще все (кроме static'ов) что приводило к косякам, хотя вроде RTLD_LOCAL должно было это вылечить..

[invy]

• -Wl,--whole-archive
  Ну да, я так и делал (посмотрел проекты)
• visibility=hidden тоже есть
• Кстати, а что говорит против того, чтобы сделать winport динамической?.. И пусть плагины, которым он нужен, и сам far, к нему динамически линкуются а не к far2l?

[elfmz]

Не хотелось бы этого делать. Процитируйте плз текст ошибки какой после переименования в colorer.far-plug-wide?

[invy]

Почему? Как бы shared libraries для этого и нужны.

У меня выше описанная проблема не только с colorer'ом.

[lieff]

Данную проблему это не должно решить, по идее это ничего не дает кроме дублирования glibc рантайма еще в один so, а в остальном все тоже самое будет. Дело в чем то другом, это надо отладить просто.

[elfmz]

Не люблю плодить сущности, даже если "так принято".
Ну поскольку компиляет линкует что в кодлайтовском мэйке что в cmake тот же GCC - значит все же гдето чтото не так с командлайном

[invy]

1. Понятно, что это не прямое решение проблемы. (Скорее всего проблема в том что таки у меня far не все экспортирует из winport).
2. Почему дублирование glibc, если к нему линковаться динамически?
3. Почему использование шаред либы - плодить сущности, не совсем понятно. Это скорее из категории separation of concerns и четкой иерархия проекта. winport - уровень совместимости с winapi и логично, что как раз он будет отделен от самого far'a и плагинов. И мой аргумент не "так принято", а использовать инструменты(shared libraries) предназначенные для решения такого рода задач (предоставления API всем страждущим). И в конце концов речь идет об одной библиотеке.

[invy]

Попробовал с shared library - все заработало ;)

[elfmz]

1. попробуйте потереть ~/.far2l. Там какой то мутный PluginCache имеется, который кэширует какуюто инфу о плагинах, не очень понятно зачем и как. Но может это оно вам жизнь портит.
2. ну потому что пока эта библиотека нужно только фару и его плагинам, это самый простой и быстрый в плане запуска процесса способ. Мне очень нравится скорость работы нынешнего фара и мгновенный запуск. Не хотелось бы даже терять 10% ради того чтоб все было "как принято".

[elfmz]

-Wl,--whole-archive - у вас в аргументах было именно перед -lWinPort ?

[invy]

Да, именно перед WinPort было. Не исключаю, что cmake как-то иначе интерпретировал конечно.

А как шаред либа на скорости скажется?... Это скорее из области экономии на спичках, мне кажется. И да, зато размер самого far2l меньше ;) (Тем более, откуда 10% потери скорости вы взяли...)

[elfmz]

Потери перфоманса на стартам - там на релоки всякие (ну это prelink порешает). В рантайме - изза особенностей генерации PIC кода под линухом и ограничений оптимизатора.

[invy]

Хм, вас не смущает что этому тексту 12 лет? (Вечером почитаю, сейчас надо таки дальше идти работу работать...)

[elfmz]

ну что сходу нагуглилось, долго гуглить не хотел, работать и правда надо)
разница за 12 лет разве что в x86-64. Там в самом деле влияние PIC должно стремиться к нулю, и так везде RIP-relative адресация

[elfmz]

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

[lieff]

Да, про то что glibc не статический как то не подумал. Кстати для i386 -fpic вполне себе реальный оверхед, один регистр резервируется. А вот для x64 таких пробелм нет, и релокейшенов там тоже нет, используется RIP Relative адресация. Хотя небольшой оверхед на загрузку конечно все же будет.
Еще в случае вынесения WinPort в so, static inline функции продублируются, которые в противном случае смержатся.
А еще можно использовать -flto, а между so он не сработвет.

[elfmz]

кстати lieff тут напомнил что нужно еще -export-dynamic в настройках линкера far2l

[invy]

Кстати внезапно у меня опять даже с динамический библиотекой поломалось :) В общем, на неделе будет время и желание копну :)
Поскольку предполагается мак версия, clang must have и для удобства соответственно cmake :)

export dynamic конечно же есть (я ридми читал, ага)

[invy]

продолжаю играться с cmake & clang.
на этапе сборки я вызываю farlng, после сборки с address sanitizer'ом начал падать - strcpy такие strcpy

==524==ERROR: AddressSanitizer: strcpy-param-overlap: memory ranges [0x6020000096b0,0x6020000096b8) and [0x6020000096b4, 0x6020000096bc) overlap
#0 0x4a3ea9 in strcpy ??:?
#1 0x4a3ea9 in ?? ??:0
#2 0x50b64a in _Z14main_generatoriPPc /home/igor/projects/test/far/far2l/farlng/src/lng.generator.cpp:563
#3 0x50b64a in ?? ??:0
#4 0x516c30 in main /home/igor/projects/test/far/far2l/farlng/src/farlng.cpp:12
#5 0x516c30 in ?? ??:0
#6 0x7f441b76082f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291
#7 0x7f441b76082f in ?? ??:0
#8 0x4321a8 in _start ??:?
#9 0x4321a8 in ?? ??:0

0x6020000096b0 is located 0 bytes inside of 12-byte region [0x6020000096b0,0x6020000096bc)
allocated by thread T0 here:
#0 0x4d22d8 in __interceptor_malloc ??:?
#1 0x4d22d8 in ?? ??:0
#2 0x50755e in _Z16ReadFromBufferExRPcPS_b /home/igor/projects/test/far/far2l/farlng/src/lng.generator.cpp:133
#3 0x50755e in ?? ??:0
#4 0x50b59d in _Z14main_generatoriPPc /home/igor/projects/test/far/far2l/farlng/src/lng.generator.cpp:557
#5 0x50b59d in ?? ??:0
#6 0x516c30 in main /home/igor/projects/test/far/far2l/farlng/src/farlng.cpp:12
#7 0x516c30 in ?? ??:0
#8 0x7f441b76082f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291
#9 0x7f441b76082f in ?? ??:0

0x6020000096b4 is located 4 bytes inside of 12-byte region [0x6020000096b0,0x6020000096bc)
allocated by thread T0 here:
#0 0x4d22d8 in __interceptor_malloc ??:?
#1 0x4d22d8 in ?? ??:0
#2 0x50755e in _Z16ReadFromBufferExRPcPS_b /home/igor/projects/test/far/far2l/farlng/src/lng.generator.cpp:133
#3 0x50755e in ?? ??:0
#4 0x50b59d in _Z14main_generatoriPPc /home/igor/projects/test/far/far2l/farlng/src/lng.generator.cpp:557
#5 0x50b59d in ?? ??:0
#6 0x516c30 in main /home/igor/projects/test/far/far2l/farlng/src/farlng.cpp:12
#7 0x516c30 in ?? ??:0
#8 0x7f441b76082f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291
#9 0x7f441b76082f in ?? ??:0

SUMMARY: AddressSanitizer: strcpy-param-overlap (/home/igor/projects/test/far/build-far2l-Desktop-Debug/tools/farlng+0x4a3ea9)

[elfmz]

да там можно вообще все strcpy переделать на strlen/memmove во избежание.. это не тот код где нужно беспокоиться за перфоманс

[invy]

Вообще надо писать на современных плюсах несчадно выкидая легаси-велосипеды. Я заменил на memmove, да.

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

[invy]

gcc --version gcc (Raspbian 4.9.2-10) 4.9.2
А pi между прочим - один из самых поддерживаемых девайсов, из длинного-предлинного списка.

Ну вот считаю что хотя бы 4.9.2 минимально поддерживаемым надо сделать. Но лучше не ограничивать себя и пользоваться новыми хорошими фичами языка и не велосипедить. Потому что время идет, через пол года на той же малине уже будет минимум какой-нибудь 5.4 (собственно убунта 16.04 на ней ведь работает), а через полтора c++17 будет что называется везде, а Far останется с legacy-велосипедами внутри.

[invy]

https://github.com/invy/far2l/tree/cmake?files=1

Потыкайте ветку с cmake, если есть желание. Работает с at creator'ом

[lieff]

С qtcreator кстати можно и без cmake, там можно сделать проект который произвольную команду пускает для сборки.

[invy]

Но зачем, когда есть нормальная система сборки.

[lieff]

Все они нормальные, и со всеми бывают проблемы. У cmake узкое место это модули, гдето модуль есть, а где то нет, FindXX может не сработать и починить будет не так просто. Но вообще вещь хорошая, да.

[invy]

У мэйка модулей вообще нету. Мне интересно, codelinte может загрузть cmake проект или нет? Потому что я категорически хочу лишнее выкинуть и cmake'ом генерировать нужное.

[lieff]

У него есть autoXXX тулзы, которые выполняет схожую функцию FindXX, причем пока поддеживают больше чего искать чем https://cmake.org/cmake/help/v3.0/manual/cmake-modules.7.html и платформ.
По идее только сам из своего может сгенерить cmake.

[lieff]

Обнаружил, что по сравнению с gnome-terminal большая разница в производительности.
Если запустить htop и начать елозить загрузка будет 15%, если пойти ниже и начать скролить весь лист на экране, то 50% и больше. То же самое в gnome-terminal не более 10%.
Профайл выглядит примерно так:

   2,13%  far2l    libc-2.23.so                   [.] _int_free
   1,93%  far2l    libc-2.23.so                   [.] malloc
   1,81%  far2l    libc-2.23.so                   [.] _int_malloc
   1,32%  far2l    libpthread-2.23.so             [.] pthread_mutex_unlock
   1,25%  far2l    libpthread-2.23.so             [.] pthread_mutex_lock
   1,24%  far2l    libglib-2.0.so.0.4800.1        [.] g_slice_alloc
   1,13%  far2l    libpango-1.0.so.0.3800.1       [.] pango_default_break
   1,07%  far2l    libgobject-2.0.so.0.4800.1     [.] g_type_check_instance_is_a
   1,01%  far2l    libglib-2.0.so.0.4800.1        [.] g_slice_free1
   0,62%  far2l    libglib-2.0.so.0.4800.1        [.] g_hash_table_lookup
   0,59%  far2l    libc-2.23.so                   [.] free
   0,56%  far2l    libc-2.23.so                   [.] __memcpy_sse2_unaligned
   0,53%  far2l    libc-2.23.so                   [.] __strcmp_sse2_unaligned
   0,50%  far2l    libwx_gtk2u_core-3.0.so.0.2.0  [.] wxWindowDCImpl::DoDrawRotatedText
   0,43%  far2l    [kernel.kallsyms]              [k] perf_pmu_sched_task
   0,43%  far2l    [kernel.kallsyms]              [k] native_queued_spin_lock_slowpath
   0,38%  far2l    libpthread-2.23.so             [.] pthread_getspecific
   0,37%  far2l    libglib-2.0.so.0.4800.1        [.] g_slice_free_chain_with_offset
   0,36%  far2l    libwx_baseu-3.0.so.0.2.0       [.] wxEventHashTable::HandleEvent
   0,36%  far2l    libgdk-x11-2.0.so.0.2400.30    [.] gdk_region_rect_in
   0,36%  far2l    libc-2.23.so                   [.] realloc
   0,34%  far2l    libgobject-2.0.so.0.4800.1     [.] g_type_check_instance_is_fundamentally_a
   0,30%  far2l    libc-2.23.so                   [.] __libc_calloc
   0,30%  far2l    libgtk-x11-2.0.so.0.2400.30    [.] gtk_widget_get_type
   0,29%  far2l    libc-2.23.so                   [.] __memcmp_sse4_1
   0,28%  far2l    libgdk-x11-2.0.so.0.2400.30    [.] gdk_draw_layout_with_colors
   0,27%  far2l    libgdk-x11-2.0.so.0.2400.30    [.] gdk_cairo_region
   0,27%  far2l    libcairo.so.2.11400.6          [.] cairo_surface_reference
   0,24%  far2l    [kernel.kallsyms]              [k] native_write_msr_safe
   0,24%  far2l    far2l                          [.] ConsolePaintContext::OnPaint
   0,24%  far2l    [kernel.kallsyms]              [k] do_sys_poll
   0,23%  far2l    libgobject-2.0.so.0.4800.1     [.] g_signal_emit_valist
   0,23%  far2l    libglib-2.0.so.0.4800.1        [.] g_private_get
   0,23%  far2l    libcairo.so.2.11400.6          [.] cairo_surface_destroy
   0,23%  far2l    libX11.so.6.3.0                [.] XFillRectangle
   0,23%  far2l    libgobject-2.0.so.0.4800.1     [.] g_object_ref
   0,22%  far2l    libgtk-x11-2.0.so.0.2400.30    [.] gtk_widget_get_direction
   0,22%  far2l    libwx_baseu-3.0.so.0.2.0       [.] wxRefCounter::DecRef
   0,22%  far2l    libpango-1.0.so.0.3800.1       [.] pango_glyph_string_extents_range
   0,22%  far2l    libglib-2.0.so.0.4800.1        [.] g_main_context_check
   0,21%  far2l    [kernel.kallsyms]              [k] update_blocked_averages
   0,21%  far2l    libpango-1.0.so.0.3800.1       [.] pango_layout_line_get_extents
   0,21%  far2l    libgobject-2.0.so.0.4800.1     [.] g_object_unref
   0,21%  far2l    far2l                          [.] ConsolePainter::FlushText
   0,21%  far2l    far2l                          [.] ConsoleOutput::ModifySequenceAt
   0,20%  far2l    libwx_baseu-3.0.so.0.2.0       [.] wxEvtHandler::ProcessPendingEvents
   0,20%  far2l    far2l                          [.] ConsolePainter::NextChar
   0,20%  far2l    [kernel.kallsyms]              [k] enqueue_entity
   0,20%  far2l    libwx_gtk2u_core-3.0.so.0.2.0  [.] wxRegion::DoContainsRect

  18,79%  far2l    libcairo.so.2.11400.6
  10,07%  far2l    libc-2.23.so
   9,14%  far2l    libglib-2.0.so.0.4800.1
   8,91%  far2l    libpango-1.0.so.0.3800.1
   7,95%  far2l    [kernel.kallsyms]
   7,28%  far2l    libgdk-x11-2.0.so.0.2400.30
   5,20%  far2l    libharfbuzz.so.0.10000.1
   4,73%  far2l    libwx_gtk2u_core-3.0.so.0.2.0
   3,96%  far2l    far2l
   3,94%  far2l    libgobject-2.0.so.0.4800.1
   3,45%  far2l    libwx_baseu-3.0.so.0.2.0
   3,30%  far2l    libpthread-2.23.so
   1,76%  far2l    libpangoft2-1.0.so.0.3800.1
   1,58%  far2l    libpangocairo-1.0.so.0.3800.1
   1,58%  far2l    libgtk-x11-2.0.so.0.2400.30
   1,54%  gdbus    libglib-2.0.so.0.4800.1
   1,29%  far2l    libX11.so.6.3.0
   0,98%  gdbus    [kernel.kallsyms]
   0,66%  far2l    libxcb.so.1.1.0
   0,60%  far2l    libfreetype.so.6.12.1

Возможно много ест переуничтожение объектов.

[invy]

Far надо нещадно рефакторить. Там внутри такой ужасный код что аж волосы дыбом встают...

Мама... вроди меня обратно, такого лютого говнокода я давно не видел:
StrBuf FindFile((int)(lpSlash-lpFullName)+1+1+1);

[lieff]

Для скоросной отрисовки появилось https://github.com/01org/fastuidraw
Вроде как рвет даже Skia https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw

[elfmz]

Far надо нещадно рефакторить. Там внутри такой ужасный код что аж волосы дыбом встают...

Да ладно, любой достаточно кровавый и достаточно энтерпрайзный проект содержит код и похлеще, к этому просто философски нужно относиться. И вообще вы в исходники ядра давно заглядывали? Советую заглянуть - отлично отрезвляет. Да можно даже в исходники не лазить, а почитать избранные странички документации, типа этой.
Переписать все - это конечно хорошая идея, но нужно понимать что каждый такой кусок кода - это какая то мелочь, делающая фар как инструмент, немножко удобнее. И переписать все сохранив удобство - это охрененный объем работ. Вот WAL/WCM 3 года пилили, даже разругаться успели, а результат таков, что поюзав его немного я пришел к выводу что так жить нельзя и за полтора месяца довел фар до гораздо более приятного в юзании состояния.
Кстати по скорости рендеринга текущий far2l внезапно быстрее чем WAL/WCM, несмотря на то что последние рисуют на голых иксах. Но до xterm не дотягивает, да..

[lieff]

Могу еще пример привести: референсный код h264 и h265
http://iphome.hhi.de/suehring/tml/
https://hevc.hhi.fraunhofer.de/trac/hevc/browser/trunk
Вроде как прогресс, стали писать на плюсах. Однако потеря производительности более 1000% и реально пользоваться этим нельзя. Потом это все переписали и впоследстви вмержили в ffmpeg
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/hevc.c
Там такие конструкции с указателями - обычное дело, но зато можно пользоваться.
Когда с этим кодом возился, выяснил например что компилер для конструкции const int ERROR_BLABLA = 1; return ERROR_BLABLA; генерит больше инструкций чем просто #define ERROR_BLABLA 1, хотя 2016 год, да.
Тут нужен разумный баланс исходя из задач. Вот пример достаточно глубокого юзания С++
http://soci.sourceforge.net/, но в отличии от hevc тут со скоростью для своих задач все хорошо и пользоваться удобно.

[invy]

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

Не знаю на какие вы эентерпрайзные проекты смотрите, но у нас такая жуть никакое ревью не пройдет и потом тебе объяснят что ты не прав и что надо это переписывать. Так код писать неьлзя... почему я полез в это место? Потому что у меня tmppanel падает при strcpy там дальше в одонй из функций...
Но вообще в фаре зоопарк своих велосипедов и костылей просто зашкаливает. Зачем люди пихали "StrBuf", когда есть vector - для меня навсегда останется загадкой.

// зачем люди на плюсах делают T *p = new T[N] тоже останется загадкой, поскольку есть vecotr...

И, да, ядро и сишный код - совсем не образец кода, потому что там си...

[elfmz]

А при каких условиях падает?

[invy]

В штатных: открываю tmp panel, копирую в нее файлы - падает.
Отладчик показывает, что падает тут в lstrcpy
wchar_t* FormNtPath(const wchar_t* path, StrBuf& buf) {
int l = lstrlen(path);
buf.Grow(l + 1);
lstrcpy(buf, path);

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

[lieff]

Я думаю все просто, это код из времен когда еще вектора даже небыло, а вижалстудия была 5-6 версии. Плагины вообще писали разные люди в разное время. Код громадный, переписать его весь сразу невозможно. Вот по чуть-чуть и надо улучшать, увидел место - запилить нормально, но без потери функционала. Если код критичный ко времени - еще и скорость надо проверить.
Код ревью еще ни о чем не говорит. Вот в хроме тоже код ревью, но баги в таких проектах никогда не иссякают, а код в разных местах тоже разного качества, а если в часть webrtc заглянете, то и лапшу с указателями и ассемблером тоже найдете, т.к. это очень ктитичный к скорости код.

[elfmz]

Этот код боюсь писался еще в борланде.
А выше по стеку что? В этом коде нечему падать, разве что path корявый или нулевой..

[invy]

cmake'ом, все указал что в .mk файле было. Падает при сборке clang'ом. С gcc не падает ;)

[invy]

В принципе, cmake уже почти готов к использованию, разве что надо зависимости до ума довести (добавить поиск minizip и libpcre, котоыре я выкинул к чертям из плагинов).

[invy]

Вопрос, farlng всегда так ругается при генерации языков и lang.ini? Или я что-то не так делаю... Локально отрабатывает, на трэвисе- нет.

/home/travis/build/invy/far2l/build/tools/farlng generator -nc -i /home/travis/build/invy/far2l/build/far2l/bootstrap/lang.ini -ol /home/travis/build/invy/far2l/build/far2l/bootstrap

KeyFileHelper(/home/travis/build/invy/far2l/build/far2l/bootstrap/lang.ini, 1) err=0x61500000ee30
lpLNGOutputPath=/home/travis/build/invy/far2l/build/far2l/bootstrap
Failed to remove file: ./lng9283.tmp errno 2
Failed to remove file: ./lng9284.tmp errno 2
Failed to remove file: ./lng9285.tmp errno 2
Failed to remove file: ./lng9286.tmp errno 2
Failed to remove file: ./lng9287.tmp errno 2
Failed to remove file: ./lng9288.tmp errno 2
Failed to remove file: ./lng9289.tmp errno 2
Failed to remove file: ./lng9282.tmp errno 2
~KeyFileHelper(/home/travis/build/invy/far2l/build/far2l/bootstrap/lang.ini) err=(nil)

https://travis-ci.org/invy/far2l/jobs/159092939

[elfmz]

с текущим мэйкфайлом на трэвисе тоже ругается, интересно почему..

[invy]

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

[elfmz]

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

[invy]

Та нет, он все генерирует... я же смотрю, просто почему-то какие-то временные файлы не удаляет.

[lieff]

На маке с перфомансом все очень плохо, при скроле слайдшов и даже фоновая загрузка 17%, когда на линухе 0%.
Тормозит рисование текста:

Я думаю не сделать ли кэширование? Рисовать буквы один раз в атлас большой тескстуры, а потом блитить их X/OpenGL. Тут возникает дилема, если для 16бит wchar_t такой кэш в память поместится, то для 32бит в общем случае нет, кэш придется держать только горячий и перестраивать на ходу.

[elfmz]

а wxwidgets собирался случайно не с --enable-debug? и еще вопрос - фонт продетектился как monospaced stable (Paint.cpp - строка 155) ?

[lieff]

wxwidgets - релиз -O2, там видно что уже системные функции едят, а не он сам.
Детектится monospaced stable.

[elfmz]

если я правильно понимаю в картинке - самый интересный столбец это Self, и самое большое значение там у wxRegion::DoContainsRect и его внутрянок
можно попробовать закоментить строки 253-256, если проверка на попадание в регион в макоси такая дорогая - может дешевле будет рисовать вслепую чем проверять нужно ли рисовать.. если будет заметное лучше - потом можно будет по-опимзировать на эту тему дальше.

[elfmz]

еще неожиданно много ест ConsoleBackground2wxColor, интересно почему? если тупит конструктор wxColor - можно построить таблицу wxColor'ов на все возможные аттрибуты.

[lieff]

Нет, много это не дало. Self это конкретно это фунукция, там еще подфункций много.

[elfmz]

еще вот что придумалось. Сейчас сделано так - любая функция вывода в консоль заканчивается формированием прямоугольника описывающего измененную область и передачей его в WinPortPanel::OnConsoleOutputUpdated, который в свою очередь асинхронно отправляет область в WinPortPanel::OnRefreshSync а та в свою очередь дергает wxWindow::Refresh с этой областью.
Возможно эффективнее будет не посылать асинхронно каждую область, а аккумулировать их, сливая по возможности, а посылать лишь уведомление что дескать тут есть область, ожидающая изменений, и первый дошедший до обработчика OnRefreshSync в результате отрисует все области сразу.
Пожалуй так вечерком и сделаю, думаю это по любому будет правильнее чем то что сейчас, и шустрее даже в линуксе.

[elfmz]

кстати "даже фоновая загрузка 17%" - это интересно от чего? перерисовка курсора раз в полсекунды столько жрет? этож неадекват какойто.. Если закоментить ToggleCursor() - падает до нуля?

[lieff]

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

[elfmz]

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

[elfmz]

еще стоит добавить лог на срабатывание rgn.Contains(...)==wxOutRegion и лог, того что выдает rgn.GetBox() - может в wx под мак схалтурили и на каждый чих весь экран перерисовывается

[lieff]

Много битмапов не будет, битмап один на все окно. В него рисуем изменившиеся символы, сканируя массив флагов, InterlockedCompareExchange сбрасываем флаг, рисуем символ. Если надо проскролить - делаем скролл битмапа, не рисуя символов, и дорисовываем выехвашие символы.

[elfmz]

А почему оно тогда будет быстрее? не думаю что отрисовка символов в битмап будет быстрее чем в экран, а рисовать их все равно придется, даже если скролл оптимизируется, то 17% в простое это никак не улучшит, т.к. это явно не изза скролла.
Кроме того возможны проблемы с color hinting'ом и прочим антияльясингом при отрисовке символов в битмаповый контекст. В смысле, возможно что color hinting при этом вообще отвалится.

[lieff]

Не будет конечно, это просто вариант оптимизации "не рисовать лишних символов". Если система поддерживает скролл окна, то отдельно рисовать в битмап и не надо - окно и есть наш битмап.
По идее это уже достаточно ускорит мак, только pg-down скрол останется слайдшовным.
Кэширование символов при отрисовке дело отдельное, для решения проблемы антиалиаса можно использовать суперсамплинг, т.е. размер в который рендерим символ больше размера на экране.

[elfmz]

Все равно не понимаю как рисование в битмап поможет не рисовать лишние символы?) не рисовать лишние символы поможет только изменение логики формирования обновленной области, так чтоб она не засчитывала неизмененные символы. Но битмап для этого не нужен.
А оптимизация скролла далеко не всегда поможет даже при скролле. Сам фар функцией скролла (ScrollConsoleScreenBuffer) не пользуется, он всегда все сам перерисовывает. Она работает только в эмуляторе терминала.

[lieff]

Ну под битмапом я скорее имел ввиду как раз окно и BitBlt его контента для сдвига, а не доп. pixmap, в чистом X11 проблем с этим нет, просто я не уверен как это в wxWidgets. Основное как раз логика с interlocked флагами.
Вот что перерисовывает это прискорбно, тады мак это не спасет, пока на скрол не переделать или кэширование не реализовать.

[elfmz]

вечером подоптимизирую области перерисовки, глядишь - полегчает
и жду выдержек логингов из rgn.Contains(...)==wxOutRegion и rgn.GetBox()
а конкретнее - бывает ли такое, что rgn.Contains выдает wxOutRegion и что выдает rgn.GetBox() при этих таинственных фоновых перерисовках

[lieff]

rgn.Contains(...)==wxOutRegion вообще не срабатывает, rgn.GetBox() все время полноэкранный.

[elfmz]

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

[lieff]

Кстати это только в фоне так, если начать двигать курсор то не полноэкранный:

box: 0 1079 0 727
box: 0 1079 0 727
box: 0 1079 0 727
box: 0 544 26 689
box: 0 544 39 689
box: 0 1079 0 727
box: 0 544 52 689

[elfmz]

значит нуна к этому логу добавить лог WinPortPanel::OnConsoleOutputUpdated и посмотреть откуда берутся эти полноэкранные перерисовки
интересно что х координата почти всегда 0