Гуглится всякое шушушу (в т.ч. давнишнее, в т.ч. в багтрекере gcc, дескать можно заюзать SSE, в т.ч. с коммитами), но по факту хрен:
__atomic_always_lock_free(16, nullptr) == false
std::atomic<__int128_t>::is_always_lock_free == false
Это и для march=x86-64, и march=native (AMD Ryzen 9 7845HX).
Экспериментально обнаружил, что если вызвать sendto() на UDP-сокете 100500 раз подряд с маленькими сообщениями, то все вызовы вернут успех, но получателю приедет лишь малая доля отправленных сообщений.
For UDP sockets, there are no send buffers, so send() and sendto() never return EWOULDBLOCK
Packets are just silently dropped when a device queue overflows.
Получается, что в случае UDP-сокета, sendto() пишет сразу в буфер адаптера.
Я не стану задавать риторический вопрос, что мешало этим чертям проверять переполнение буфера адаптера и честно возвращать EWOULDBLOCK – чтобы отправитель мог сразу регулировать плотность трафика, а не через ожидание отсутствия подтверждения от получателя по таймауту (в результате чего у отправителя ВСЕГДА устаревшие данные о пропускной способности канала).
Мне интересно более практичное: если UDP-сокет никогда не возвращает EWOULDBLOCK (т.е. не проверяет переполнение буфера адаптера), есть ли смысл добавлять его во writeSet для select(), и как он себя в этом случае поведёт (ведь для срабатывания writeSet таки-нужно проверять наличие свободного места в буфере адаптера)?
Или же тупо писать в него безо всяких select(&writeSet)? Даже если writeSet сработает корректно, один хрен невозможно узнать, сколько можно записать и когда нужно остановиться.
У меня моник 2K (2560x1440), glfwGetMonitorWorkarea() возвращает (0,0,2560,1405), где 1440-1405=35 высоты занимает taskbar:
$ grep panel_size ~/.config/tint2/tint2rc
panel_size = 100% 35
Если я делаю glfwMaximizeWindow(window), то в коллбэки прилетает три события: maximize(true), resize(2560,1381), move(0,24).
Что это за 1381 и 24 (в сумме дающие 1405) и откуда они взялись?
Мигрирую тут своё барахлишко с -std=c++20 на -std=c++23, и всё чистенько, кроме одного затыка:
#include <unordered_map>
class C {};
int main() {
C c;
std::unordered_map<C*, int> m;
m.insert({&c, 0}); // no matching function for call to 'get'
return 0;
}
C++20 компилял это нормально, C++23 ругается на &c. Что поменяли, чего ей надо?
Вот так работает, но это ж как-то длинно и глупо:
m.insert(std::pair{&c, "hello"});
UPD: «Но действительность ещё кошмарней.» (c)
#include <regex>
int main() {
static std::regex rColor {"^#?[0-9A-Fa-f]{6}$"};
return 0;
}
$ clang -std=c++23 -c try.cpp
In file included from try.cpp:1:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/regex:40:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bitset:52:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/string:67:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/memory_resource.h:41:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/uses_allocator_args.h:39:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:956:36: error: no matching function for call to 'get'
956 | return __convertible<decltype(std::get<_Is>(std::declval<_UTuple>()))...>();
| ^~~~~~~~~~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:955:11: note: in instantiation of function template specialization 'std::tuple<const long &>::__convertible_from_tuple_like()::(anonymous class)::operator()<0UL>' requested here
955 | return []<size_t... _Is>(index_sequence<_Is...>) {
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/tuple:1136:22: note: in instantiation of function template specialization 'std::tuple<const long &>::__convertible_from_tuple_like<const long &>' requested here
1136 | constexpr explicit(!__convertible_from_tuple_like<_UTuple>())
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_map.h:514:38: note: while substituting deduced template arguments into function template 'tuple' [with _UTuple = const key_type &]
514 | std::tuple<const key_type&>(__k),
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/regex_automaton.tcc:207:7: note: in instantiation of member function 'std::map<long, long>::operator[]' requested here
207 | __m[__u] = __id;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/regex_compiler.tcc:241:24: note: in instantiation of member function 'std::__detail::_StateSeq<std::regex_traits<char>>::_M_clone' requested here
241 | __e._M_append(__r._M_clone());
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/regex_compiler.tcc:135:17: note: (skipping 2 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
135 | while (this->_M_quantifier())
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/regex_compiler.tcc:91:13: note: in instantiation of member function 'std::__detail::_Compiler<std::regex_traits<char>>::_M_alternative' requested here
91 | this->_M_alternative();
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/regex_compiler.tcc:76:13: note: in instantiation of member function 'std::__detail::_Compiler<std::regex_traits<char>>::_M_disjunction' requested here
76 | this->_M_disjunction();
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/regex.h:809:34: note: in instantiation of member function 'std::__detail::_Compiler<std::regex_traits<char>>::_Compiler' requested here
809 | __detail::_Compiler<_Rx_traits> __c(__first, __last, _M_loc, __f);
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/regex.h:473:9: note: in instantiation of member function 'std::basic_regex<char>::_M_compile' requested here
473 | { _M_compile(__p, __p + _Rx_traits::length(__p), __f); }
| ^
try.cpp:14:26: note: in instantiation of member function 'std::basic_regex<char>::basic_regex' requested here
14 | static const std::regex shmNameRegex {"^/[^/]{1,254}$"};
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:122:5: note: candidate template ignored: could not match 'tuple<_Elements...>' against 'const long'
122 | get(tuple<_Elements...>& __t) noexcept;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:126:5: note: candidate template ignored: could not match 'const tuple<_Elements...>' against 'const long'
126 | get(const tuple<_Elements...>& __t) noexcept;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:130:5: note: candidate template ignored: could not match 'tuple<_Elements...>' against 'const long'
130 | get(tuple<_Elements...>&& __t) noexcept;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:134:5: note: candidate template ignored: could not match 'const tuple<_Elements...>' against 'const long'
134 | get(const tuple<_Elements...>&& __t) noexcept;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:138:5: note: candidate template ignored: could not match 'array<_Tp, _Nm>' against 'const long'
138 | get(array<_Tp, _Nm>&) noexcept;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:142:5: note: candidate template ignored: could not match 'array<_Tp, _Nm>' against 'const long'
142 | get(array<_Tp, _Nm>&&) noexcept;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:146:5: note: candidate template ignored: could not match 'const array<_Tp, _Nm>' against 'const long'
146 | get(const array<_Tp, _Nm>&) noexcept;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:150:5: note: candidate template ignored: could not match 'const array<_Tp, _Nm>' against 'const long'
150 | get(const array<_Tp, _Nm>&&) noexcept;
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1250:5: note: candidate template ignored: could not match 'pair<_Tp1, _Tp2>' against 'const long'
1250 | get(pair<_Tp1, _Tp2>& __in) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1255:5: note: candidate template ignored: could not match 'pair<_Tp1, _Tp2>' against 'const long'
1255 | get(pair<_Tp1, _Tp2>&& __in) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1260:5: note: candidate template ignored: could not match 'const pair<_Tp1, _Tp2>' against 'const long'
1260 | get(const pair<_Tp1, _Tp2>& __in) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1265:5: note: candidate template ignored: could not match 'const pair<_Tp1, _Tp2>' against 'const long'
1265 | get(const pair<_Tp1, _Tp2>&& __in) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/ranges_util.h:444:5: note: candidate template ignored: could not match 'const subrange<_It, _Sent, _Kind>' against 'const long'
444 | get(const subrange<_It, _Sent, _Kind>& __r)
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/ranges_util.h:455:5: note: candidate template ignored: could not match 'subrange<_It, _Sent, _Kind>' against 'const long'
455 | get(subrange<_It, _Sent, _Kind>&& __r)
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1272:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter '_Tp'
1272 | get(pair<_Tp, _Up>& __p) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1277:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter '_Tp'
1277 | get(const pair<_Tp, _Up>& __p) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1282:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter '_Tp'
1282 | get(pair<_Tp, _Up>&& __p) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1287:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter '_Tp'
1287 | get(const pair<_Tp, _Up>&& __p) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1292:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter '_Tp'
1292 | get(pair<_Up, _Tp>& __p) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1297:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter '_Tp'
1297 | get(const pair<_Up, _Tp>& __p) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1302:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter '_Tp'
1302 | get(pair<_Up, _Tp>&& __p) noexcept
| ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.1.1/../../../../include/c++/14.1.1/bits/stl_pair.h:1307:5: note: candidate template ignored: invalid explicitly-specified argument for template parameter '_Tp'
1307 | get(const pair<_Up, _Tp>&& __p) noexcept
| ^
1 error generated.
Сабж.
Шучу (1е апреля всё-таки), всё работает.
Кому делать нечего, зацените презенташку сайта на плюсях (ролик 1 минута):
Я тут подумываю, а не вернуться ли мне на генту. Правда, от этих мыслей меня существенно подташнивает. Тем не менее, не поделитесь ли, товарищи гентушники,
чё у вас там новенького, кроме бинарных пакетов?
Насколько runit юзабелен как полная замена OpenRC? Поддерживается ли он для всех сервисов?
2a. К слову, а почему они вообще до сих пор от этого громоздкого говна мамонта не отказались? (Гы, на всякий случай уточню, что я про OpenRC.)
После обновления mdadm 4.2 —> 4.3, массивы не собираются с вышеуказанной ошибкой. WTF?!
Не из-за двоеточия ли это в начале имени? У меня в заметках записано, это чтобы оно не добавляло homehost. Видимо, чтобы при загрузке с флешки не ругалось, что хост неправильный. Возможно вместо этого можно вписать в /etc/mdadm.conf HOMEHOST=<ignore> (глобально для всех массивов), но прежде чем пердолиться с переименованием массивов и подкручиванием конфигов, мечтается получить подтверждение, что причина действительно в этом. Чёт не гуглится ничего, кроме аналогичного багрепорта без обсуждения.
У меня artix linux на компе и на загрузочном portable ssd, почти идентичные системы. После где-то полугодичного перерыва грузанулся в ssd чтобы его обновить. Обновил, перегрузился – всё работает, но идёт непрерывная запись на ssd на максимальной скорости, почти без остановки: gkrellm показывает, и светодиод на ssd непрерывно моргает. И сдаётся мне, редкие паузы там только потому что SSD отказывается принимать новые данные пока старые не раскидает.
iotop -a показывает с гулькин хрен – только jdb2 немного, несопоставимо по объёмам.
UPD: Вернее, в строке заголовка он показывает большой общий объём записи (Actual DISK WRITE:), а в разбивке по процессам – хрен.
Грузился в runlevel 1 без графики и сети – всё равно моргает непрерывно.
Насколько я себе представляю, если бы только сам SSD внутри себя освежал давно не перезаписывавшиеся данные, он бы сильно грелся, но gkrellm запись не показывал бы.
Думал, может драйвер ядра форсирует освежение, но пока я копировал конфиги с основной системы на ssd, непрерывная запись на него не шла.
Как искать виноватого?
nginx динамически грузит мой .so-модуль, который прилинкован к lucene++.so.
Изредка сегфолтится, и я склонен полагать, что это баг lucene++, но хочется быть уверенным, прежде чем скомпилять и заюзать его последний снапшот, где этот баг пофиксен. И пока я жду очередного сегфолта,
Вопрос: как объяснить gdb -c /tmp/core-xxx, чтобы он подцепил мою .so, или он сам это из дампа увидит?
Моя .so с отладочной инфой, nginx и lucene++ без (лень: они установлены тупо из пакетов).
На этом своём каменте или через-следующем жму – в адресной строке появляется https://www.linux.org.ru/forum/development/17495702?cid=17520734#comment-er=show&cid=17521254 (на втором каменте последнее число другое) и всё, дальше ничего не происходит. В других выборочно проверенных темах всё работает.
UPD. Вот дьявол, а когда открываю второй камент по прямой второй ссылке выше, ссылка «показать ответ» из него работает.
UPD2. Похоже дело в том, что второй камент открывается в режиме «игнорируемые скрыты», а мой камент – в режиме «игнорируемые видны», а там навигация давно известно что подглюкивает, и давно смирился как с платой за возможность пол-ЛОРа игнорить. В общем, ложная тревога.
21:30 - 26:48
В смысле, при перезапуске приложения. Уже с полгода имеет место быть, созрел пожаловаться. У меня окна не maximized, справа ~=200px отступ чтобы кусок десктопа был виден (а точнее gkrellm). А при перезапуске ещё и сверху отступ 5-10px образуется, каждый раз приходится ресайзить. QtCreator, QBitTorrent (этот ещё на 1px вправо сдвигает окно), не помню что ещё.
Никто не сталкивался? Как лечили?
Либа должна:
(при редактировании HTML – WYSIWYG) Генерить diff: минималистичный, но достаточный для восстановления предыдущей версии по текущей, как в VCS.
Применять diff к текущей версии для получения предыдущей.
Выводить diff с раскраской, или лучше подготавливать какие-то структуры для вывода, по которым я сам быстренько-простенько раскрашу.
Загвоздка в том, что у меня HTML, и надо как-то типа как на ЛОРе: если отличие не в тексте, а в HTML тегах/атрибутах, оно должно сохраняться (для восстановления предыдущей версии), но не показываться.
В крайнем случае п.3 попробую сам запилить. Но уж для п.1+2 что-то наверняка да есть.
Несколько лет назад по форумам пробежала ссылка на сабж, где чел плакался, что мол из инженерной дисциплины программирование превратилось в гадание на койфейной гуще: тупо и бессмысленно бродишь-ищешь, где забыл аннотацию воткнуть. Не помнит ли кто?
В моём приложении создаю коннекты и prepared statements по запросу, и в описываемом сценарии считаем что кеширую их вечно. Все обновления базы – внутри транзакций.
Во время работы приложения в консоли запускаю sqlite3 mydb и там что-нибудь модифицирую (create table aaa(id int);, drop table aaa;) в auto-commit режиме. После чего моё приложение естественно начинает ругаться «database is locked» (SQLITE_BUSY). (А может и не естественно, если консоль в auto-commit отпускает лок после каждой команды.)
Проблема в том, что даже после того, как я выйду из sqlite3 в консоли, моё приложение продолжает ругаться.
Причём там непонятная хрень какая-то творится. Prepared statements, которые были созданы ПОСЛЕ того, как я вышел из консоли, работают. Решил убедиться, запустил консоль, сделал create/drop table, а потом, НЕ выходя из консоли, запустил приложение – всё работает. Но стоит ещё раз повторить в этой же консоли create/drop table – начинает ругаться.
SQLite 3.43.2, база на локальной ФС, режим журналирования WAL, по коннекту на поток, sqlite3_open_v2(...SQLITE_OPEN_NOMUTEX...), pragma locking_mode = normal.
Куда копать, кроме постгреса и кладбища? Ну и кроме очевидного, но чересчур грубого pragma locking_mode = exclusive. Что там вообще происходит?
Т.е. независимо от того, сколько между ними разновсяческих открывающих и закрывающих тегов. Надо на голом js, покомпактнее и побыстрее; рекурсивно сканировать DOM я и сам догадаюсь.
Например, в <p><b>Hello</b> <i>world</i>!</p> – следующий текстовый узел после «Hello» – пробел, а после пробела – «world».
И архитектура красивая и минималистичная (не надо подгонять свои высокоуровневые фантазии под – surprise! – совершенно по-другому работающие базовые технологии), и с самого начала тестируешь-дебажишь всю логику настоящую с самого низу (а не заглушки, заменив которые вдруг обнаруживаешь, что работает оно через раз, и тестировать всё надо снова), и писать много лишнего соответственно не приходится, но…
…Но сука пишешь-пишешь, пишешь-пишешь, пишешь-пишешь, ПИШЕШЬ-ПИШЕШЬ – и конца-края мать его не видно!!! Тошнит уже. :(
Хотя тут конечно фактор новизны ещё. Если последние 10 лет сидел на JVM, а плюсы последний раз ещё в яслях видел, то нарабатывать себе тулзы под практически новую для меня платформу – и libtooling изучать (и фасады под свой cake к нему клепать – многопоточность чтобы, и хелперы всякие, в т.ч. обход багов), и nginx (в котором для проксирования до хрена всего, а для бакенда – нихрена), и весь квадриллион граблей пока соберёшь…
Здрасьти.
Имеем сайт, т.е. приложение с очень большим аптаймом. База – SQLite. Нужно чтобы всё работало быстро, и стартовало / завершалось тоже.
Если вызывать pragma optimize при закрытии каждого соединения, как рекомендуют по ссылке выше, то есть шанс, что рано или поздно – и как положено, в самый неподходящий момент – оно задумается. А вместе с ним и админ: с чего это вдруг nginx не хочет завершаться? kill -9 его.
Понятно, что перед pragma optimize я ещё выдам pragma analysis_limit = 1000, чтобы оно совсем уж неприлично не задумывалось. Но внутренний перфекционист всё равно недоволен.
Для долгоиграющих приложений, по первой ссылке рекомендуют запускать pragma optimize раз в несколько часов. Делать это в рабочих коннектах – нехорошо, юзеры также будут время от времени ни с того ни с сего задумываться.
Отсюда вопросы:
Много ли выгоды я потеряю, если буду вызывать optimize из-под отдельного коннекта в фоновом потоке? Не спроста ж они рекомендуют вызывать его перед закрытием коннектов – небось накопленную коннектом статистику используют. Впрочем, бит 8 в MASK я в любом случае буду отключать – ещё блин какая-то сраная железка за меня не решала, какие индексы ей нужны. Но хотя бы тупой analyze-то отработает?
Если я буду запускать optimize в фоновом потоке при старте, и оно решит задуматься, оно не заблокирует DML в других коннектах? Если нет, то это был бы идеальный вариант: шустрая работа сайта с первых секунд, даже если админ кильнул предыдущую оптимизацию, задумавшуюся при завершении. Ну а дальше также фоном раз в несколько часов, а оптимизации при закрытии коннектов тогда с гораздо большей вероятностью отработают мгновенно.
| следующие → |