А у симейка их дофига

Симейк генерит мсбилд проект, там чёрт ногу сломит. Я так много в чём разобрался в работе компиляторов и линкеров собирая руками.

если это с целью изучения - тогда одобряем)

если это с целью изучения - тогда одобряем)

Я и дальше не планирую билд системами пользоватся.

А у симейка их дофига

cmake пытается впихнуть невпихуемое в системы в которые он генерирует. Говорю про make тот-же. Понятно что от части там совместимость, отчасти обход багов отдельных имплементаций, но всё же, читать это трудновато.

Я и дальше не планирую билд системами пользоватся.

А вот это уже не очень одобряем

Я и дальше не планирую билд системами пользоватся.

а это зря. В них есть польза, просто ты её ещё не понял)

Я скорее понял что в них пользы нет

Я скорее понял что в них пользы нет

но но но... Не спеши с выводами) Представь что твой проектик разростётся до либ внешних... этак сотни. И представь что у каждой либы свои скриптики такие сборки. И каждой либе свои зависимости нужны. И ты хочешь давать возможность другим проект той собрать. Желательно ещё и на несколько платформ и компиляторов, а не один msvc и windows. Вот там и начинается боль такого подхода

но но но... Не спеши с выводами) Представь что твой проектик разростётся до либ внешних... этак сотни. И представь что у каждой либы свои скриптики такие сборки. И каждой либе свои зависимости нужны. И ты хочешь давать возможность другим проект той собрать. Желательно ещё и на несколько платформ и компиляторов, а не один msvc и windows. Вот там и начинается боль такого подхода

Всё может быть, но кажется что там боль от билд систем только усиливается. Я помню у меня сосед на работе сидел и 2 недели "дебажил" симейк сборку средних размеров.

Я скорее понял что в них пользы нет

Где-то лет так 5 назад я думал так же

Делал для нескольких платформ скрипты

И очень сильно удивился, когда узнал, что CMake делает за 2 команды то, что я делал за 100 строк кода скриптового

И на настройку билдинга у меня стало уходить гораздо меньше времени, чем раньше

И сэкономленное время ты спокойно можешь потратить на написание кода, а не на интимные действия по отношению к скриптам сборки)

CMake позволяет тебе очень удобно структуризировать проект, раскидать всё по папкам, а главное - инкрементальная сборка. Что очень важно в проектах больше 10 cpp файлов.

CMake позволяет тебе очень удобно структуризировать проект, раскидать всё по папкам, а главное - инкрементальная сборка. Что очень важно в проектах больше 10 cpp файлов.

мне кажется инкрементальная сборка и так в почти любой системе сборке есть. Есть исключения, но её необходимость очевидна давно вроде

мне кажется инкрементальная сборка и так в почти любой системе сборке есть. Есть исключения, но её необходимость очевидна давно вроде

Ага

Но когда пишешь свой скрипт, настроить инкрементальную сборку - это жопоболь

Компилятор сам не умеет определять файлы изменённые

И компилит всё под ряд

А ведь ещё могут хедеры измениться, CMake это тоже отслеживает успешно

Крутой конкурс: https://habr.com/ru/companies/yandex/articles/839612/ Восхищаюсь что люди там вытворяют. За предыдущие года можно много чего интересного нарыть, но проходит довольно тихо.

Программистам, привет! А в частности линуксоидам! Если ли в чате люди, которые используют / использовали NixOS? Как в целом с программированием там? Насколько сложно настройка окружения идет? В целом хотелось бы просто услышать норм дистр под разработку или нет? Под разработку для: Python, Lua (Love2d), Frontend (node js)?

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

Но сама система привлекает интересным подходом к установки пакетов внутри ос

Программистам, привет! А в частности линуксоидам! Если ли в чате люди, которые используют / использовали NixOS? Как в целом с программированием там? Насколько сложно настройка окружения идет? В целом хотелось бы просто услышать норм дистр под разработку или нет? Под разработку для: Python, Lua (Love2d), Frontend (node js)?

https://youtu.be/pmQMTfSABhw 56:25

https://youtu.be/pmQMTfSABhw 56:25

на ноуте не стоит vpn

позже гляну

I regret doing this...

на ноуте не стоит vpn

/

Ок, щас

https://youtu.be/pmQMTfSABhw 56:25

Хм, ну я думаю, что не будет проблем с установкой ПО, т.к всё что нужно мне +- ставится без проблем через файл конфигурации и отдельные пакеты / библиотеки / фреймворки уже ставятся через pip3, npm и т.д без особых проблем

Я себе уже поставил nixos + оставил debian как основную ос

Попытаюсь чаще nixos попользоватся (перенести прям все нужны программы) и посмотреть насколько удобно будет

@Snusmumriken тут в чатах какая-то движуха начинается насчет многопоточности в луа, можешь объяснить, зачем в луа "истинная" многопоточность? если выполнять вычисления на луа в 8 потоков (8 lua state именно параллельно выполняющихся), это не будет так же полезно, как вызвать те же 8 функций, написанных на си, и выполнить их так же параллельно и вернуть в луа. Есть хоть возможность из корутин вызывать сишные функции и, самое главное - переключаться с одной корутины на другую, пока первая ждет возврата сишной функции? я читал о чем-то подобном в Coco (корутинах в luajit), это оно?

и, что самое прикольное - никто не мешает загрузить posix/winapi вместе с Lua API через FFI, и через него создать тред и запустить там еще один луастейт)))

https://coco.luajit.org/

@Snusmumriken тут в чатах какая-то движуха начинается насчет многопоточности в луа, можешь объяснить, зачем в луа "истинная" многопоточность? если выполнять вычисления на луа в 8 потоков (8 lua state именно параллельно выполняющихся), это не будет так же полезно, как вызвать те же 8 функций, написанных на си, и выполнить их так же параллельно и вернуть в луа. Есть хоть возможность из корутин вызывать сишные функции и, самое главное - переключаться с одной корутины на другую, пока первая ждет возврата сишной функции? я читал о чем-то подобном в Coco (корутинах в luajit), это оно?

в каких чатах? 🤷‍♂️ Многопоточность есть разная : реальная и корутины. Реальная многопоточность в луа невозможна в пределах одного стейта, нужен канал для коммуникации сериализованными данными. Это МОЖЕТ быть полезно, когда логика давно на луашке написана, и будет меняться и дорабатываться. Ты на си всё переписывать соберёшься чтоль?) Корутины - в одном реальном потоке крутятся, переключаясь с одной на другую. И нет, нельзя вызвать си функцию и переключиться на корутину сразу. Вызов си функции передаёт управление этой самой си функции, вместо другой корутины. Пока си функция не вернёт управление - стейт в потоке не сможет что-либо делать от слова вообще. А если попытаешься стейт насильно в другом потоке крутить - скорраптишь луа стейт и стек последней активной корутины

в каких чатах? 🤷‍♂️ Многопоточность есть разная : реальная и корутины. Реальная многопоточность в луа невозможна в пределах одного стейта, нужен канал для коммуникации сериализованными данными. Это МОЖЕТ быть полезно, когда логика давно на луашке написана, и будет меняться и дорабатываться. Ты на си всё переписывать соберёшься чтоль?) Корутины - в одном реальном потоке крутятся, переключаясь с одной на другую. И нет, нельзя вызвать си функцию и переключиться на корутину сразу. Вызов си функции передаёт управление этой самой си функции, вместо другой корутины. Пока си функция не вернёт управление - стейт в потоке не сможет что-либо делать от слова вообще. А если попытаешься стейт насильно в другом потоке крутить - скорраптишь луа стейт и стек последней активной корутины

про графон флудилка, Lua англоязычный

@Snusmumriken тут в чатах какая-то движуха начинается насчет многопоточности в луа, можешь объяснить, зачем в луа "истинная" многопоточность? если выполнять вычисления на луа в 8 потоков (8 lua state именно параллельно выполняющихся), это не будет так же полезно, как вызвать те же 8 функций, написанных на си, и выполнить их так же параллельно и вернуть в луа. Есть хоть возможность из корутин вызывать сишные функции и, самое главное - переключаться с одной корутины на другую, пока первая ждет возврата сишной функции? я читал о чем-то подобном в Coco (корутинах в luajit), это оно?

> зачем в луа "истинная" многопоточность? Для ряда причин. 1. Блокирующие вызовы, которые нельзя сделать неблокирующими. Например, ты такой пилишь консольную приложульку, которая непрерывно делает работу, но принимает команды с клавиатуры. И сделать неблокирующий io.read например физически нельзя — только сидеть и только ждать пока юзер не введёт команду. Открываешь соседний поток с работой, посылаешь ему сообщеньки из потока с ожиданием команд. 2. Реальное время. Например, ты делаешь подсистему вывода звука. Чтобы звук не лагал при лагах основного приложения, и на звуковуху ВСЕГДА был подсунут нужный чанк звуковой волны вовремя, ты такой берёшь, и выделяешь звуковую подсистему в соседний поток. Или ты пилишь сетевое взаимодействие на UDP. Чтобы чётко и точно контролировать скорость приёмо-передачи, чтобы точно не было никаких переполнений буферов, ты выделяешь их в соседний поток, и они там точно и чотко отрабатывают, пока в основной части приложения может всё тупить и тормозить. 3. Использование возможностей множества процессоров. Запускаешь в одном потоке тяжёлую задачу, и в другом потоке тяжёлую задачу. А в третьем потоке — интерфейс. И этот интерфейс прекрасно себя чувствует, а параллельные задачи прекрасно работают на своих процессорах, ускоряя выполнение за счёт настоящей одновременности.

Корутины — это хорошо и прекрасно. И асинхронно. И вообще. Но они ничего не могут сделать блокирующим вызовам, точному выполнению в срок в нечётких условиях, и необходимости использовать несколько процессоров.

в каких чатах? 🤷‍♂️ Многопоточность есть разная : реальная и корутины. Реальная многопоточность в луа невозможна в пределах одного стейта, нужен канал для коммуникации сериализованными данными. Это МОЖЕТ быть полезно, когда логика давно на луашке написана, и будет меняться и дорабатываться. Ты на си всё переписывать соберёшься чтоль?) Корутины - в одном реальном потоке крутятся, переключаясь с одной на другую. И нет, нельзя вызвать си функцию и переключиться на корутину сразу. Вызов си функции передаёт управление этой самой си функции, вместо другой корутины. Пока си функция не вернёт управление - стейт в потоке не сможет что-либо делать от слова вообще. А если попытаешься стейт насильно в другом потоке крутить - скорраптишь луа стейт и стек последней активной корутины

Вообще, можно замутить шаред стате, но на луёвой стороне это будет скорее просто как блок "общей" памяти, на котором разные потоки с запущенной луашкой вписывают свои кусочки строчек, или юзердата-объекты ":getValue() :setValue()" с минимальным копированием. Шарить луашные объекты между стейтами (строчки, таблички) довольно проблематично. Хотя можно попробовать запилить общий строковый буфер, должно быть мемно, хотя гц на их фоне тоже надо будет объединять.

Вообще, можно замутить шаред стате, но на луёвой стороне это будет скорее просто как блок "общей" памяти, на котором разные потоки с запущенной луашкой вписывают свои кусочки строчек, или юзердата-объекты ":getValue() :setValue()" с минимальным копированием. Шарить луашные объекты между стейтами (строчки, таблички) довольно проблематично. Хотя можно попробовать запилить общий строковый буфер, должно быть мемно, хотя гц на их фоне тоже надо будет объединять.

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

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

Можно делать много маленьких шаред-стейтов, а ля очереди со слотами, и блокировать отдельно.

Вообще, можно замутить шаред стате, но на луёвой стороне это будет скорее просто как блок "общей" памяти, на котором разные потоки с запущенной луашкой вписывают свои кусочки строчек, или юзердата-объекты ":getValue() :setValue()" с минимальным копированием. Шарить луашные объекты между стейтами (строчки, таблички) довольно проблематично. Хотя можно попробовать запилить общий строковый буфер, должно быть мемно, хотя гц на их фоне тоже надо будет объединять.

в luajit есть string.buffer который довольно эффективно сериализует объектики. Без перекрёстных ссылок, конечно, и userdata/thread/function, но всё-же лучше чем ничего

Можно делать много маленьких шаред-стейтов, а ля очереди со слотами, и блокировать отдельно.

Ммм... Ну да, так тоже можно

в luajit есть string.buffer который довольно эффективно сериализует объектики. Без перекрёстных ссылок, конечно, и userdata/thread/function, но всё-же лучше чем ничего

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

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

ну да, в отдельных ситуациях разные варианты будут более предпочтительны.

Например, давай представим, что мы хотим обрабатывать большой объём данных в соседних потоках. У нас есть например пикча, и мы делим её на чанки и отправляем в соседние потоки на обработку. Мы можем: - Скопировать пикчу в N буферов-чанков, сериализовать, переслать потокам, дождаться обработки, потом собрать обратно. - Закинуть пикчу в шаред-стейт, и скинуть потокам указатель на этот стейт + диапазоны в которых они должны работать. И даже блокировать не надо, лол.

Вообще, можно замутить шаред стате, но на луёвой стороне это будет скорее просто как блок "общей" памяти, на котором разные потоки с запущенной луашкой вписывают свои кусочки строчек, или юзердата-объекты ":getValue() :setValue()" с минимальным копированием. Шарить луашные объекты между стейтами (строчки, таблички) довольно проблематично. Хотя можно попробовать запилить общий строковый буфер, должно быть мемно, хотя гц на их фоне тоже надо будет объединять.

https://github.com/effil/effil

говно с message passing

были патчи на 5.0 интерпретатор с общей кучей

были патчи на 5.0 интерпретатор с общей кучей

вот то хорошее дело было

Например, давай представим, что мы хотим обрабатывать большой объём данных в соседних потоках. У нас есть например пикча, и мы делим её на чанки и отправляем в соседние потоки на обработку. Мы можем: - Скопировать пикчу в N буферов-чанков, сериализовать, переслать потокам, дождаться обработки, потом собрать обратно. - Закинуть пикчу в шаред-стейт, и скинуть потокам указатель на этот стейт + диапазоны в которых они должны работать. И даже блокировать не надо, лол.

В буфер никто не мешает поместить FFI указатель) Как и в стейт. А так полностью согласен, лишний раз копировать не стоит.

говно с message passing

У ловки есть очень забавная ерунда. Луашные типы, ловка сериализует при передаче между тредами. Но свои типы — передаёт по ссылке. В результате, можно сделать например один огромный меш, обработать его физику в одном потоке, другую физику в другом потоке, какую-нибудь инверсную кинематику в третьем, а потом взять, и тупо отрисовать в главном потоке. Вообще ни о чём не думая. Мутексы там в наличии, поэтому на ожидании потоки могут поблокировать, но это уже к реализации. Если сделать двойную буферизацию меша то даже не заблокируется.

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

были патчи на 5.0 интерпретатор с общей кучей

вангую, что как в питоне - много потоков, а работают хуже чем 1, потому что GIL) А иначе нет идей как они "общей кучи" добились

и, что самое прикольное - никто не мешает загрузить posix/winapi вместе с Lua API через FFI, и через него создать тред и запустить там еще один луастейт)))

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

это всё один и тот же луашный код

https://hastebin.com/share/riwakasequ.lua

может он криво обращается к FFI

https://hastebin.com/share/ukopicanuh.cpp

на самом деле это сишный файл, ну ниче

в общем это багованая библиотека для асинхронности

НО она работает

вот два результата от того же кода Michael@hpv15:/s/source/snippets/coro> luajit lmain.lua started coro 1 started coro 2 async 1 Segmentation fault (core dumped) Michael@hpv15:/s/source/snippets/coro> luajit lmain.lua started coro 1 started coro 2 async 1 async 1 async 2 async 2 async 3 async 3 async 4 async 4 async 5async 5 async 6 async 6 async 7 async 7 async 8 async 8 async 9 async 9 async 10 async 10 async 11 async 11 async 12 async 12 async 13 async 13 async 14 async 14 async 15 async 15 async 16 async 16 async 17 async 17 async 18 async 18 async 19 async 19 async 20 async 20 finished coro 1 finished coro 2 ^C

сегфолт обычно в lj_gc при gc_sweepstr

lmain.lua require("lasync") function coroutine1() print("started coro 1") async_dofile("lsub1.lua") print("finished coro 1") end function coroutine2() print("started coro 2") async_dofile("lsub1.lua") print("finished coro 2") end co1 = coroutine.create(coroutine1) co2 = coroutine.create(coroutine2) coroutine.resume(co1) coroutine.resume(co2) while coroutine.status(co1) ~= "dead" or coroutine.status(co2) ~= "dead" do os.execute("sleep 0.1") end lsub1.lua for i = 1, 20 do print("async " .. i) os.execute("sleep 0.1") end

os.exec sleep 0.1 неинтересно, щас посмотрим что будет если луашный код будет все время выполняться

сегфолтит сразу

но есть идея как это все говно в кучу собрать

lmain.lua require("lasync") function coroutine1() print("started coro 1") async_dofile("lsub1.lua") print("finished coro 1") end function coroutine2() print("started coro 2") async_dofile("lsub1.lua") print("finished coro 2") end co1 = coroutine.create(coroutine1) co2 = coroutine.create(coroutine2) coroutine.resume(co1) coroutine.resume(co2) while coroutine.status(co1) ~= "dead" or coroutine.status(co2) ~= "dead" do os.execute("sleep 0.1") end lsub1.lua for i = 1, 20 do print("async " .. i) os.execute("sleep 0.1") end

У меня вопрос. Почему строго две корутины? Две таски это же шляпа на постном масле.

У меня вопрос. Почему строго две корутины? Две таски это же шляпа на постном масле.

так и при них все падает

я уже нашел что можно соорудить из этого, хоть сколько-нибудь полезного

либу-обертку для птредов

только она скоро не сможет опираться на чистый lua api, и это хорошо....

я добавлю ее в свой форк луажита (наверно)