На моей практике, куда больше camelCase, причём имена классов начинаются с большой буквы. Ну и константы, по классике, КАПСОМ_С_ПОДЧЁРКИВАНИЕМ.

кстати, в стандартной библиотеке вообще какой-то lowercasewithoutdelimiters, блин)

Разделителем работают точки. table.insert, string.match

А всякие tostring/tonumber это фигня.

Разделителем работают точки. table.insert, string.match

setmetatable

А, ну вот, что страшное.

collectgarbage! (не нужен)

o/ а если я создаю массив таблиц с одинаковыми ключами, эта структура данных как-то называется по особому? или это просто массив таблиц с одинаковыми ключами?

Можно называть как хочешь. Но на твой паттерн есть крутая оптимизация в луа: можно представить массив таблиц с одинаковым множеством ключей как хешмап массивов. Будет в разы меньше табличек, меньше нагрузка на gc

Можно называть как хочешь. Но на твой паттерн есть крутая оптимизация в луа: можно представить массив таблиц с одинаковым множеством ключей как хешмап массивов. Будет в разы меньше табличек, меньше нагрузка на gc

хм, отличная идея, спасибо

хешмап же имеется ввиду таблица?

Да

Можно называть как хочешь. Но на твой паттерн есть крутая оптимизация в луа: можно представить массив таблиц с одинаковым множеством ключей как хешмап массивов. Будет в разы меньше табличек, меньше нагрузка на gc

Это называется "паралельные массивы". Оно занимает меньше памяти, но требует куда больше усилий на удаление/вставку структур, потому что надо сдвинуть все значения во всех массивах после вставляемого (table.insert и table.remove — медленные, а тут оно умножается на количество полей). Комфорт использования — близок к нулевому. Расширяемость новыми полями тоже страдает, если какие-то поля пусты — образуются дырки, от которых ничего хорошего. Такую штуку можно делать только если у тебя совершенно конкретная цель.

Это называется "паралельные массивы". Оно занимает меньше памяти, но требует куда больше усилий на удаление/вставку структур, потому что надо сдвинуть все значения во всех массивах после вставляемого (table.insert и table.remove — медленные, а тут оно умножается на количество полей). Комфорт использования — близок к нулевому. Расширяемость новыми полями тоже страдает, если какие-то поля пусты — образуются дырки, от которых ничего хорошего. Такую штуку можно делать только если у тебя совершенно конкретная цель.

я начал обдумывать это всё, может это можно в какой-нибудь объект завернуть, чтоб он делал всю грязную работу?

Можно, но всё равно медленно.

Плюс размер строковых ключей в луа у однотипных объектов не имеет значения.

Десять тысяч объектов { longlongkey1 = "foo", longlongkey2 = "bar", } Будут иметь объём только собственных значений "foo" и "bar", плюс пары указателей на строки "longlongkey1" и "longlongkey2". Луа использует строковый буфер, так что экономия памяти на параллельных массивах минимальна. Да, одинаковые строки (в т.ч. строковые ключи) существуют в памяти только в единственном экземпляре (и собираются мусорщиком, когда на них заканчиваются ссылки), а по луа-коду гуляют указатели на них. Лайфхак: у луа очень, очень быстрое сравнение строк: просто проверка указателей на одинаковость ))

По этим же причинам, кстати, нельзя менять отдельные части строки, типа str[2] = "f".

ясно, спасибо, теперь я знаю об этом явлении с разных сторон

получается 10000 таких объектов будут занимать места на 160 кбайт больше, чем параллельные массивы, т.е. 8 x 2 x 10000 ?

Примерно так, да. Ещё чуть-чуть на саму табличку, она тоже занимает маленький кусочек памяти.

о, значит 240 кб

Карочи, делай пока как "удобно". Как "круто" — будешь делать когда тебе действительно приспичит.

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

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

Нормально

> Лайфхак: у луа очень, очень быстрое сравнение строк: просто проверка указателей на одинаковость )) То есть перед тем как создать строку, луа сверяет ее содержимое с другими и возвращает ссылку?

Луа хеширует содержимое и сравнивает со списком хешей->указателей на другие строки. Да.

TString **p = G(L)->strcache[i]; for (j = 0; j < STRCACHE_M; j++) { if (strcmp(str, getstr(p[j])) == 0) /* hit? */ return p[j]; /* that is it */ } Мдээ... И стоит оно того?

Ага.

TString **p = G(L)->strcache[i]; for (j = 0; j < STRCACHE_M; j++) { if (strcmp(str, getstr(p[j])) == 0) /* hit? */ return p[j]; /* that is it */ } Мдээ... И стоит оно того?

Это имеет определённые проблемы в luajit'е, там функция хеширования строк затрагивает только четыре(!) символа в них, в результате если у тебя в памяти миллиард почти одинаковых строк, то скорость работы с ними замедляется в тысячи раз. В ванильной луа такого нет. Но в целом, оно очень сильно экономит память. Ну смотри блин, размер десятков тысяч структур с кучей полей — зависит только от количества ключей а не их длины.

Подскажите, как в lua вызывать функции из основной программы (go-lua в моем случаи) что-то не могу понять

За ссылки буду благодарен )

это у меня работает )

мне теперь нужно из lua вызвать гошную функцию

и возврат гошной функции обработать в lua :)

пока я нашел только решение в виде lua модуля, который под капотом .so, но это на си...

и не ужели нету удобного варианта какого-то

видимо так...

но это для gopher-lua, а у меня go-lua

буду пробовать, но если кто сталкивался - буду благодарен за помощь

а SetGlobal разве не то?

есть еще SetFunctions

func SetFunctions(l *State, functions []RegistryFunction, upValueCount uint8)

судя по всему для go-lua это так делается

это как раз и скармливается потом SetFunctions

судя по всему

тут нету случайно желающих помочь с опенсорс проектом по защите от ddos? есть часть на go-lua

оплатим хорошо :) ну и опенсорс для кармы тоже хорошо

уже разбираюсь

Кароч, я объясняю сишную апишку, найдёшь гошные алиасы. Для вызова луашных функций (любых), есть lua_call, lua_pcall и lua_xpcall. Это не самый быстрый процесс, но какой есть. Для проброса функций в луа есть lua_pushcfunction + lua_setglobal (и ещё всякие luaL_register для проброса сразу пачки), луа быстро вызывает внешние функции.

o/ а если мне нужно сделать push_back в массив, лучше использовать table.insert или array[last+1] = ...

Не заморачивайся и делай читабельнее, т.е. table.insert.

Не заморачивайся и делай читабельнее, т.е. table.insert.

спасибо, 🐈

Я делаю arr[#arr + 1] = ..., но мне так больше нравится, ибо короче и отсутствуют оборачивающие скобки, получается читаемей при большом выражении, типа: arr[#arr + 1] = "Foo " .. getStuff() .. " bar" .. getOther() arr[#arr + 1] = {foo = "bar", bar = "baz"} Для сравнения: table.insert(arr, "Foo " .. getStuff() .. " bar" .. getOther()) table.insert(arr, {foo = "bar", bar = "baz"})

Ещё можно взломать систему и сделать local arr = setmetatable({}, {__index = table}) И дальше хачить: arr:insert("foo") arr:insert{foo = "bar", bar = "baz"}

о, прикольно

Ещё можно взломать систему и сделать local arr = setmetatable({}, {__index = table}) И дальше хачить: arr:insert("foo") arr:insert{foo = "bar", bar = "baz"}

А она не станет хэшмапой после присвоения метатаблицы?

Нет

Кароч, я объясняю сишную апишку, найдёшь гошные алиасы. Для вызова луашных функций (любых), есть lua_call, lua_pcall и lua_xpcall. Это не самый быстрый процесс, но какой есть. Для проброса функций в луа есть lua_pushcfunction + lua_setglobal (и ещё всякие luaL_register для проброса сразу пачки), луа быстро вызывает внешние функции.

у меня наоборот было - вызов гошных из лу, разобрались уже @zarif_li помог, спасибо :)

если это про мой вопрос...

ребята, подскажите, хорошая ли едея: луа вызывает функцию на го, она возвращает связанный список, луа бегает for'ом по структуре (связному списоку) или лучше передавать скажем string json и тп ?

какой lua way?

Список.

подозреваю что я правильно мыслю, но не уверен)

Список.

спасибо)

ребята, подскажите, хорошая ли едея: луа вызывает функцию на го, она возвращает связанный список, луа бегает for'ом по структуре (связному списоку) или лучше передавать скажем string json и тп ?

почему это не сделать на стороне go?

почему это не сделать на стороне go?

потомучто это та вещь которую надо программировать без перезапуская ядра на го

она тюнится на живую

это сенсор определяющий ddos, нужно его программировать на лету, не трогая основной код

он ходит в базу в которой лежит sflow статистика по трафику L2/L3 модели OSI, и делает выводы ddos/неddos )

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

Тэкс, а почему он не должен перезапускаться, редактируясь "на лету"? Прост патчинг на лету это хорошо, но есть проблемы того что часть мусора может оставаться в памяти, в результате неизвестно, как оно будет накатываться, как будет откатываться и где косяки. Но это лирика.

Тэкс, а почему он не должен перезапускаться, редактируясь "на лету"? Прост патчинг на лету это хорошо, но есть проблемы того что часть мусора может оставаться в памяти, в результате неизвестно, как оно будет накатываться, как будет откатываться и где косяки. Но это лирика.

ну можно мониторить сколько памяти жрет каждая горутина...

в которой lua запущен

ну а перезапускаться на лету нужно потомучто ddos атаки вещь динамическая и инженер (оператор) должен подстраивать систему

удобнее всего делать это на скриптовом языке

ну по крайней мере я пока так думаю :)

Тэкс, а почему он не должен перезапускаться, редактируясь "на лету"? Прост патчинг на лету это хорошо, но есть проблемы того что часть мусора может оставаться в памяти, в результате неизвестно, как оно будет накатываться, как будет откатываться и где косяки. Но это лирика.

то есть масси userdata получается будет возвращаться в lua?

это lua way, или воркэрунд для го?