lua же вроде линкуется с ридлайн? почему ее нельзя сразу и require?

Ридлайн луям нужен только в интерактивном интерпретаторе

Его нельзя использовать за его пределами

а, пон. а биндинги че не написали

удобно же

Ды должны быть

Я лично сам всегда писал

Бибилиотека мелкая

ВОТ полный захват stdin/stdout на стандартной луашке без библиотек. но только на *nix и только для gdb https://github.com/Koekto-code/gdbauto/blob/draft/iocapture.lua

под луажитом работает быстрее чем просто гдб. наверно из-за того что цвета исчезли

FIFO нормальная штука, и диск не засоряет

судя по тому что он создался на NTFS, в винде тоже есть такое

Шанс разбогатеть | Пикабу https://pikabu.ru/story/shans_razbogatet_11207644

Снусмумрик, а ты уже играл в игру про Снусмумрика?

Снусмумрик, а ты уже играл в игру про Снусмумрика?

Пока ньет ))

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

@Bot_for_AI держи

Это идеально

Sony has opensourced the tools framework used by their first party game development studios. : r/gamedev https://www.reddit.com/r/gamedev/comments/204duc/sony_has_opensourced_the_tools_framework_used_by/

Какая прелесть

Какая прелесть

Что это

Это читы

читер

Что это

dsmt = debug.setmetatable

dsmt = debug.setmetatable

аааа

самый серьёзный чит в луях

Мне чот понравилось вешать метатаблички ко всему подряд

Кст всегда забываю спросить, что делает rawset / rawget Вставляют / Получают данные в в таблицу как RAW?)

Кст всегда забываю спросить, что делает rawset / rawget Вставляют / Получают данные в в таблицу как RAW?)

Не вызывает метаметоды index и newindex

Вставляют/получают данные из/в таблицы не дёргая метаметодов вроде __index/__newindex

Благодарю

самый серьёзный чит в луях

А теперь самая серьёзная часть

У меня щяс рофляная задача сделать всратолибу метатабличек на всё подряд, и чтобы она ещё хорошо комбилась с остальным моим барахлом, но без копипасты и зависимостей.

Вот с этим вот, тут не всё мета-либы но table/string/async вполне мета

Когда делаешь мета-мету, жизнь становится интереснее.

Ты случайно не сервер на lua пилишь?)

Ох, я за свою жизнь СТОЛЬКО серверов на луа сделал, ты себе не представляешь. И большая их часть работает в продакшне.

А что за основу брал? Curl?

Основа для сервера?

Ну да

Курл не предоставляет слушающих сокетов. Это чисто клиентская либа, работающая с урлами. Собственно, её название "cURL" намекает. Это она обращается к серверам по урлу и что-то с них хочет.

А так, в качестве основы для типовых луёвых серверов (хттп/тсп/амкп/юдп/фтп/смтп и далее) вполне подходит луасокет обыкновенный. Открываешь такой порт и такой слушаешь, чаво туда придёт.

А так, в качестве основы для типовых луёвых серверов (хттп/тсп/амкп/юдп/фтп/смтп и далее) вполне подходит луасокет обыкновенный. Открываешь такой порт и такой слушаешь, чаво туда придёт.

а во, вспоминал как тот модуль называется. Интересно, можно ли его с корутинами использовать

Конечно можно.

хотя это пол беды, io операции бы с корутинами

Но желательно включать неблокирующие сокеты. А ля: function handle_sock(sock) sock:settimeout(0) -- формат типа [5 символов длины сообщения][тело сообщения] local len = sock:receive(5) while not length do coroutine.yield() len = sock:receive(5) end len = tonumber(len) local data = "" while data <= len do local chunk = sock:receive(2048) if chunk then data = data .. chunk end coroutine.yield() end ... local request = data:sub(1, len) data = data:sub(len + 1) -- тоже неблокирующая фигня с yield'ами local response = PROCESS_MSG(request, sock) sock:send(("%-5d"):format(#response)) for i = 1, math.ceil(#response/2048) do local n = (i - 1) * 2048 sock:send(response:sub(n, n + 2048)) coroutine.yield() end end И вот мы такие радостно получили приёмо-отправитель на луасокете с корутинками в одной функции, без блокировок и конечных автоматов. Пихаем это в корутину и радуемся. Можно обработать примерно миллиард входящих соединений параллельно, принимать огромные объёмы данных без блокировок же, и отправлять тоже огромные объёмы, тоже без особых блокировок. А потом ещё регулировать скорость передачи, скипая отправку пока не придёт время.

Абалдеть

А корутины особо память не кушают? Я просто не особо знаю, как это на низком уровне работает

надо потестить ради интереса

Не особо. Открывать корутину для отдельных соединений это скорее норма.

Корутина это как бы отдельный луа-стейт с пошаренной памятью с основным. Там памяти сжирается на стек. Считай как пара функций по объёму.

Корутина это как бы отдельный луа-стейт с пошаренной памятью с основным. Там памяти сжирается на стек. Считай как пара функций по объёму.

А, можно т.е адреса табличек между корутинами передавать?

Таблички общие.

Корутины это не "потоки". Считай что это просто функции. coroutine.yield фактически делает обычное goto из функции. coroutine.resume фактически делает goto на последний yield из функции.

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

Согласен, спасибо за разъяснение

Если функция в корутине что-то блокирует (долгий приём/передача или что-то такое) — ничего не будет происходить, всё встанет.

Если функция в корутине что-то блокирует (долгий приём/передача или что-то такое) — ничего не будет происходить, всё встанет.

Ну да, поток выполнения один

Ну да, поток выполнения один

Но. Если у нас есть физическая возможность не блокировать (или блокировать, но на незначительное время) — мы можем легко распараллелить всякие штуки. Всего того же самого можно было бы достичь конечным автоматом: local state = { sock = sock, -- неблокирующий length = false, data = "", response = false } -- дёргаем эту функцию каждый тик пока не придёт ОК function process_state(state) if not state.length then state.length = tonumber(state.sock:receive(5)) return end if #state.data <= state.length then local chunk = state.sock:receive(2048) if chunk then state.data = state.data .. chunk end return elseif not state.response local request = state.data:sub(1, state.length) state.response = PROCESS_REQUEST(request, state.sock) return end if state.response and #state.response > 0 then local chunk = state.response:sub(1, 2048) state.response state.response:sub(2049) state.sock:send(chunk) return end return "OK" end Как ты понимаешь, функцию обработки приходится писать учитывающей кучу факторов "а в каком состоянии сейчас находится наше состояние чтобы что-то с ним делать", и даже в линейном сценарии, это довольно муторная фигня. А если это надо модифицировать — ещё приходится постоянно думать, как это отразится на каждом из условий состояния.

Что-то телеграмм прилег, новости последние ужас.

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

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

В тарантуле кст прикольно сделали работу с асинхронщиной, там свои куротины - файберы

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

Мейлру просто делали файберы решая основную проблему ограничения времени выполнения

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

Опа, прикона. Методы работы тоже забавные. То есть завершение файберов по таймауту или другим причинам, таки на плечах файберописателей. С другой стороны, это и неплохо.

Ага, ток эти файберы норм так памяти сжирают

А сколько ты хочешь?

Потому что луашные функции и таблички вон тоже прилично памяти сжирают, особенно если генерить их миллионами в минуту.

Строчки, кстати, тоже

А сколько ты хочешь?

У меня просто был сервер на 1gb ram, и я пихал файберы во все что можно)) В итоге тестовые запросы на условно 10000 запросов, могли сожрать сильно много памяти

по факту у меня нет 10000 запросов, максимум 100, но с тех пор, файберы я использую осторожно))

Я вот на днях прикручивал steamworks к love2d, и тут можно чекнуть потребление памяти при пересоздании кадров из местного модуля HTMLSurface (cef) из строчек (каждый кадр в fullhd rgba = ~8мб). И без пересоздания (ffi.copy производит сырое копирование кадра по указателю в буферчик). https://youtu.be/vZlRokg-nhc

У меня просто был сервер на 1gb ram, и я пихал файберы во все что можно)) В итоге тестовые запросы на условно 10000 запросов, могли сожрать сильно много памяти

А вот тут ВОЗМОЖНО могут немного помочь две вещи — collectgarbage и ограничение на количество файберов. Когда запросов становится многовато, возможно есть способ засуспендить входящие подключения пока со старыми не разберёмся. С другой стороны, возможно тут и не файберы сжирают, а сопутствующая запросам фигня. С третьей стороны, 10к запросов на 1гб памяти это и так весьма жирно. Серверу который серьёзно работает с 10к запросов/сек вполне себе положено выдавать 16-128гб оперативки (в зависимости от серьёзности самих запросов).

Я вот на днях прикручивал steamworks к love2d, и тут можно чекнуть потребление памяти при пересоздании кадров из местного модуля HTMLSurface (cef) из строчек (каждый кадр в fullhd rgba = ~8мб). И без пересоздания (ffi.copy производит сырое копирование кадра по указателю в буферчик). https://youtu.be/vZlRokg-nhc

блин, какйфово, по памяти 8мб это как будто даже мало))

8мб на каждый кадр. Умножаем на 60 и получаем объём аллоков в секунду.

Грубо говоря, за секунду плодится ~500 мб мусора, который сборщику приходится срочно выгребать. Это без прямого копирования по указателю.

8мб на каждый кадр. Умножаем на 60 и получаем объём аллоков в секунду.

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

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