Как проверить, что предкомпилированные заголовки действительно используются при сборке?
Согласно документации https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html имеется возможность иметь несколько вариантов одного предкомпилированного заголовка. Для этого надо создать каталог с именем типа all.h.gch и указать на него компилятору, после чего он автоматически выберет подходящий.
Я, с помощью отдельных makefile, создаю в каталоге all.h.gch несколько заголовков тпа all1.h.gch, all2.h.gch, и т.д.
После этого, в makefile проекта, который должен использовать заголовок, я указываю путь до этого каталога: -I/path/to/all.h.gch.
Согласно документации, это должно привести к использованию предкомпилированного заголовка, но, судя по тому, что время компиляции изменяется в пределах статистической погрешности, этого не происходит.
Каким способом можно гарантированно проверить, компилируется ли заголовок каждый раз заново, либо же используется предкомпилированный, не измеряя время компиляции?

>>27373
Ладно, вы правы, 150% - это ещё не полный просир.

>>27376
Был бы у Хуавея рост до хотя бы до 50% за несколько - тогда можно было бы говорить о просере. Но доли рынка не меняются много лет. Тут уместнее говорить о том, что каждый занял свою нишу.

Чиочан, а зачем нужен mutable? В чем смысл делать метод константным, а потом все равно в нем что-то менять? Это же не логично?

>>27383

• Какой-нибудь кэш элементарный:

private:

  mutable std::map<int, int> cache_;

public:

  int get(int key) const

  { 

    auto it = cache_.find(key);

    if (it != cache_.end()) {

      return it->second;

    }   

    return cache_[key] = get_value_for_key_costly_(key);

  } 

• Существуют структуры данных, в которых поиск модифицирует данные: splay-дерево (https://neerc.ifmo.ru/wiki/index.php?title=Splay-дерево#find.28tree.2C_x.29 — после find нужно сделать splay, которое вносит изменения) и дерево отрезков с «несогласованными поддеревьями» (https://neerc.ifmo.ru/wiki/index.php?title=Несогласованные_поддеревья._Реализация_массового_обновления#query).

Стив, привет! Что почитать / посмотреть / порешать по сетям и протоколам вонаби go бэкенду?

Чиочан, такая ситуация. Собирается экзешник X, который зависит от самосборной статической библиотеки L1, которая зависит от самосборной статической библиотеки L2. Возможно ли так собрать L1, чтобы в нее включилась L2, и при сборке X надо было подключать только L1, не указывая L2?

>>27388
ar r libL1.a l1.o l2.o

Объектник из libL2.a можно вытащить так, если надо:
ar x libL2.a

Здесь кто-нибудь на ruby пишет?
У меня такой (нубский) вопрос:

Имеется, допустим, класс A, в нем метод foo. Имеется класс B, с классом A никак (кроме общих предков) не связанный. Задача — добавить в B точно такой же foo.

Ограничения.
1. Мы не можем редактировать исходный код классов A и B, только менять их динамически в результате выполнения нашего кода.
2. Более того, нам вообще неизвестен исходный код метода foo, поскольку на момент исполнения нашего кода он может быть произвольным образом изменен другим сторонним кодом.
3. Код метода foo никак не связан с другими методами и полями класса A. И вообще ему там не место, но рефакторить мы ничего не можем, см. п1. Вероятностью, что такая связь будет добавлена сторонним кодом, можно пренебречь.
4. Версия ruby — 1.9.2 (и нет, мы не можем поменять ее на более новую)

Пока что идеи такие:
1. Kак-то (как?) переместить текущее содержимое foo в отдельный модуль, после чего добавить его обоим классам в качестве миксина. Ну или вообще напрямую скопировать метод из одного класса в другой, как-то манипулируя с их внутренним устройством.
2. Kак-то подменить контекст вызова (скажем, в lua мы можем из B:foo вызвать A:foo как A.foo(self) — и контекст поменяется). В ruby есть UnboundMethod, но он требует близкородственных связей между классами, которых нет. (Их хваленая "утиная типология" не работает)
3. Как-то преобразовать содержимое A.foo в блок, который затем вызвать из B.foo. Есть Method.to_proc, но он жестко привязан к объекту (а нам объект класса A не нужен).

Поиск по stackoverlow не радует:
https://stackoverflow.com/questions/33708250/what-is-the-point-of-rubys-method-unbinding-mechanism
https://stackoverflow.com/questions/14132782/assign-a-method-from-one-class-to-an-instance-of-another
Возможно ли это вообще, или я слишком много хочу от этого языка?

>>27400

> а нам объект класса A не нужен

Насколько это критично? Класс А настолько тяжелый?

Выглядит так, что совсем без аллокации объекта A не получится вытащить метод. Но можно избежать вызова A#initialize хотя бы:

A.allocate.method(:foo)

> (Их хваленая "утиная типология" не работает)

Иначе можно было бы взять нативный метод, типо Array#push, забиндить его на произвольный объект, и все, аварийный останов! Не типобезопасно... Думаю, это компромисс между утиной типизацией и строгой.

>>27403
>Но можно избежать вызова A#initialize хотя бы:
>A.allocate.method(:foo)
О, похоже, то что нужно. Вызов цепочки конструкторов был бы катастрофой, а всего лишь бессмысленное выделение памяти под фальшивый объект... некрасиво конечно (внутренний слаанешит плачет кровавыми слезами), но пережить можно.

Собственно, при таком подходе никакой перенос методов не нужен, хватит простого вызова

A.allocate.foo

Спасибо!
О, и пикрелейтед на капче

И снова я, снова то же ruby 1.9.2 (RPGmaker VX ACE)

Наткнулся на странное поведение Exception.backtrace в случае наличия eval в цепочке вызовов. Имеем такой пример кода:

def foo

    raise "shit"

end

def bar

    foo

end

def baz

    eval('bar')

end

Перехватываем исключение, смотрим этот самый backtrace и видим такую хрень:

• test.rb:10:in 'eval'
• test.rb:6:in 'bar'
• (eval):1:in 'baz'
• test.rb:10:in 'eval'
• test.rb:10:in 'baz'

Вместо верхней строчки стека — тот самый eval.
Если убрать eval и вызывать bar напрямую, то всё работает корректно:

• test.rb:2:in 'foo'
• test.rb:6:in 'bar'
• test.rb:10:in 'baz'

Понимаю, что скорее всего это баг древней версии, с которым мне никто не поможет, но всё-таки... Может есть какой-нибудь известный способ вытащить верхнюю (и самую важную) строчку стека, которую этот eval собой затирает?

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

>>27407 UPD
Костыльное решение (вполне очевидное, но весьма кривое): перехватывать исключения до того, как они прошли через в eval.

В листинге выше это можно сделать, например, в bar. Или даже внутри эвала, которой в baz.
Если обернуть передаваемый ему код в begin/rescue, то внутри этого rescue стек, пока еще, будет в порядке. И можно его где-нибудь сохранить или записать в лог.

А как исключение пройдет через eval, то всё, в стеке мусор.

>>27407
А если

eval 'bar'

заменить на

instance_eval { bar }

то все равно поломанный бектрейс будет?

>>27409
Не, с instance_eval, тьфу-тьфу, всё нормально.
Но, к сожалению, не всегда одно можно так просто заменить на другое.

По крайней мере я таких способов не вижу. Хотя может я просто не в курсе, язык пока знаю плохо.
Если нам пришел код в виде строки, то можно ли как-то сделать его блоком и запихать в этот instance_eval?

>>27410

> Если нам пришел код в виде строки, то можно ли как-то сделать его блоком и запихать в этот instance_eval?

Так-то instance_eval принимает строку тоже. Еще мне пришли в голову две вещи:

1) Сделать процедуру из строки (чтоб отложить выкидывание исключения до исполнения процедуры) каким-нибудь таким образом:

block = &eval("proc {#{str}}")

instance_eval &block

2) Если у тебя там MRI руби, то поэксперементирвать с этим:

RubyVM::InstructionSequence.compile(str).eval

>Но, к сожалению, не всегда одно можно так просто заменить на другое.

А что за задача? Вообще, я очень редко пользовался eval, единственное место, где я его нашел у нас, так это в самодельном обфускаторе для руби.

>>27411
Фикс:

block = eval("proc {#{str}}")

instance_eval &block

>>27411
>Так-то instance_eval принимает строку тоже.
И в случае со строкой его поведение ничем не отличается от eval, т.е. имеем ту же проблему.
Что вообще-то логично, потому что код обе эти функции скорее всего используют один и тот же.

Пока что я использую вот такую вот затычку: https://pastebin.com/Fy5Uc82L
И соответственно, буду подключать этот EvalFixer во все места, где такая неоходиость возникнет. Их там не так много, вроде. Помимо этого Game_Interpreter еще 2-3.
Сперва хотел вообще глобальный eval переопределить, но полезли какие-то странные ошибки и я решил не связываться.
Кстати, на пастебине тоже фейлится подсветка синтаксиса. Сколько я бился, чтобы поправить ее у себя в редакторе, так до конца и не. Хотя сейчас уже гораздо реже, чем вначале.

>block = eval("proc {#{str}}")
Э... но какой в этом смысл, если мы всё равно вызываем тот самый эвал?

>RubyVM
Посмотрю, но кажется там такого нет.

>А что за задача?
Копаюсь в RPGmaker, если кратко.
Эвенты. Всё хрантся у него в базе, а потом обрабатывается этим самым Game_Interpreter (и еще в нескольких местах), если там код, то вызывается через этот самый эвал.
Привожу это всё к такому виду, чтобы можно было с ним нормально работать внешними средствами, потому что его внутренняя среда это тихий ужас. Соответственно, возникла задача логирования и обработки ошибок, в процессе которой это всё и вылезло.
Движок сильно недооценен, между прочем. Среда позволяет его использовать где-то на 10%. И абсолютное большинство игрушек на этом и останавлвается.

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

>>27413
>>block = eval("proc {#{str}}")
>Э... но какой в этом смысл, если мы всё равно вызываем тот самый эвал?

Хм... Смысл, похоже, есть. Потому что в таком исполнении оно, внезапно, работает правильно.

(немного подумав)
А, ну да. Мы же в эвале лишь создаём блок. Наши эксепшены через эвал не проходят. Всё понял, был неправ.
Это решение лучше, чем то, что я там нагромоздил.
Пошел переписывать EvalFixer.

>>27413

Понятно.

>И соответственно, буду подключать этот EvalFixer во все места, где такая неоходиость возникнет. Их там не так много, вроде. Помимо этого Game_Interpreter еще 2-3. Сперва хотел вообще глобальный eval переопределить, но полезли какие-то странные ошибки и я решил не связываться.

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

До фикса, как я понимаю, исполнение скрипта 'def f; end' определяло метод Game_Interpreter#f. Однако же instance_eval создаст "собственный" метод f для инстанса Game_Interpreter. Разница проявится, если в RPGMaker создается несколько инстансов Game_Interpreter. В первом случае метод f будет доступен для всех инстансов, во втором - только для того конкретного инстанса, который выполнял скрипт с определением f.

Наверное, проблему можно будет решить созданием глобального объекта ctx, и исполнением ctx.instance_eval { ... } вместо просто instance_eval.

>>27414

>Мы же в эвале лишь создаём блок. Наши эксепшены через эвал не проходят.

Ага. Я еще пытался придумать такой str, чтобы "proc { #{str} }" сломанный код произвело, но не придумал.

В чем принципиальная разница между std::thread и std:: async? Кроме того, что из асинка проще вытащить возвращаемое значение.

>>27433
>что из асинка проще вытащить возвращаемое значение
Принципиальная - разные уровни абстракции: проще вытащить результат/ошибку и не надо думать о жизненном цикле потока.

std::async возвращает future, дальше клиент, когда понадобится получить результат/выкинуть исключение вызовет get(), не задумываясь что там с потоками происходит.

std::thread создаст поток, и надо будет явно обрабатывать результаты/ошибки (например, через ассоциированный с потоком promise, если хочется сложить результат в future, как это делает async), явно вызывать detach()/join().

Есть еще различия, типо что async может использовать потоки из пула (зависит от имплементации), что тоже является дополнительной абстракцией над обычными системными потоками. Если короткоживущее вычисление надо сделать, то из пула будет меньше времени на создание/деструкцию тратиться.

>>27438
Спасибо.
А где можно поподробней про это почитать?

>>27439
https://eli.thegreenplace.net/2016/the-promises-and-challenges-of-stdasync-task-based-parallelism-in-c11/

На русском например это выглядит норм
https://education.yandex.ru/knowledge/asinhronnost-v-s++20.-doklad-v-yandekse

Пытаюсь запустить десктопную консольную JavaSE-программу на Android.

Вот по этим инструкциям
https://billauer.co.il/blog/2022/10/android-java-dalvikvm-command-line/
https://raccoon.onyxbits.de/blog/run-java-app-android/

Сначала jar дексируется с помощью dx или d8 с указанием API level телефона (это часть штатного пайплайна сборки андроид-приложений, в перспективе можно сам dx дексировать и на прямо на телефоне запускать), а потом запускается через

`

sh
dalvikvm -verbose:class -classpath /sdcard/hello.jar hello

`

Получаю ошибку:

`

java.lang.NoClassDefFoundError: hello
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: Didn't find class "hello" on path: DexPathList[[zip file "/sdcard/hello.jar"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]

`

ЧЯДНТ?

И ещё

Suppressed: java.io.IOException: unable to open DEX file

>>27444
>>27445
Что-то на жабском

Существуют ли движки для борд на питоне? Интересно.

>>27491
Я думаю на любом популярном языке есть.

Что-то древнее:
https://github.com/mantycore/orphereus

Что-то посвежее:
https://github.com/floens/uchan

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

Ни у кого нет на примете случайно какого-нибудь примера приложения, используюшего QLocalServer и QLocalSocket для обмена сообщениями?

Пытался написать что-то работающее с QLocalServer и QLocalSocket. Ничего не работает в итоге.
Вот пример кода - https://codebeautify.org/alleditor/y245d89ea
Клиент успешно судя по всему успешно отправляет сообщение, потому что write возвращает значение > 0. А вот сервер почему-то не видит входящее сообщение, hasPendingConnections всегда возвращает false.
Есть тут Стивы, работающие с Qt, может кто поймет, что я делаю не так?

>>27512
Покажь хедеры и мейн.

PS. если сунуть QCoreApplication::processEvents() в 59 строчку (ветка где hasPendingConnections() == false) то помогает это?

>>27492
Видать самому на джанге пилить, эх.

>>27519
Кстати один Стив на джанге пилил движок прямо здесь >>/dev/18554
Вообще движок имиджборды такой примитивный программный продукт, что даже удивительно что существует всего пару-тройку состоявшихся движков, и все они ведут родословную еще с начала нулевых. И еще удивительней, как часто разработка бордодвижка с нуля вообще не доводится до конца. Go figure.

Гитхаб сообщает что у него аж 17 imageboard engine на питоне разной степени готовности, ты просматривал их? Например вот такой: https://github.com/gnstaxo/imageboard

>>27520
Про 17 не понял...

У того Стива в гитхабе только вроде hexchan один.

>>27520
>Вообще движок имиджборды такой примитивный программный продукт, что даже удивительно что существует всего пару-тройку состоявшихся движков
Ну вот каждый маменькин разработчик сначала так думает, а потом обнаруживает, что всё не так уж просто. Если мы не говорим про базовую «Вакабу», в которой почти ничего нет (и она нахѣръ никому не нужна).

>>27520
> один Стив на джанге пилил движок прямо здесь

Да, я когда-то читал, но тогда ничего не понял. Сейчас вижу что он асинхронность так и не поборол и фишки свои не реализовал. Зато, судя по гитхабу стал успешным человеком.

>>27523
>Ну вот каждый маменькин разработчик сначала так думает, а потом обнаруживает, что всё не так уж просто

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

>>27519
Напиши на чем-нибудь веселом, хаскелле там или кложуре.

>>27526
Оживить вот это?
https://github.com/LoLi-Lang/LoLi

>>27521
Имелись в виду результаты вот этого поиска:
https://github.com/search?q=imageboard+engine+language%3APython&type=repositories&l=Python

>>27523
В целом удваиваю >>27525
Добавлю только что писать это все лучше для кого-то кто будет этим непосредственно пользоваться и знает чего хочет.

>>27527
Главное маскота забабахать как известно, ага.

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

>>27529
Ногами и пистолетом вы можете добиться гораздо большего, чем одними только ногами.

>>27529
> Не, я предлагаю взять что-нибудь менее унылое чем джанго

Хотелось бы сделать это в какое-то вменяемое время, т.е. достаточно быстро. На базе джанги это как мне представляется возможно.

>>27530
>пистолетом вы можете добиться гораздо большего
Хах, я не сразу понял что ты имеешь ввиду - с джанго действительно выстрелить себе в ногу будет намного проще.

>>27516
Дело оказалось в том, что я не использовал ивент луп. Как мне сказали, hasPendingConnections работает только с ним.

>>27533
Ну вот QCoreApplication::processEvents() передала бы контроль чтоб обработать события, я поэтому спросил.

>>27491
Ханабира вроде на нём работала. Где-то даже помню её исходники видел.

>>27491
Бнвач, например https://github.com/stiletto/bnw - twisted+tornado+mongodb

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

>>27583
>Copyright (c) 2012, Kagami Hiiragi <kagami@genshiken.org>
Лол, тот самый? У него ведь реально какие-то наработки с ХМПП были.