Snusmumriken
А вот тут смежный вопрос - прочитал я жсон в табличку. Чем красиво эту табличку в файл записать, чтобы потом реквайр ея?
Вот ета фигня прям позволяет реквайрить бывшие жсоны. https://github.com/pkulchenko/serpent Inspect это про печать содержимого, с зацикленными ссылками и всякой фигнёй, но всё таки отладочный вывод.
mva
Вот ета фигня прям позволяет реквайрить бывшие жсоны. https://github.com/pkulchenko/serpent Inspect это про печать содержимого, с зацикленными ссылками и всякой фигнёй, но всё таки отладочный вывод.
не, ну если очень упороться, то сериализовать инспектом тоже можно, но да долбанафтненько. Серпент для сериализации топ за свои деньги
mva
Чтобы визуально структура подтаблиц сохранялась. Есть такое?
на самом деле, если пишешь какую-то мелкую фигню, то хоть руками А в чём-то сколько-нибудь серьёзном - лучше серпент, как посоветовал Снус
Snusmumriken
Вообще, идеальный сериализатор для больших объёмов, должен генерить примерно следующую строчку: [[ local s = { -- string cache "foobar", "foo", "baz" } local o = { -- object cache {foo = s[3]}, {[s[1]] = s[2]}, {[s[1]] = s[2], foo = "b"}, ... } -- inner links block o[2][s[2]] = o[2] o[2][s[4]] = o[3] return { s[1] = o[1], s[3] = o[2] } ]] Примерно такую ерунду, чтобы происходило сжатие однотипных объектов. Если есть требование сериализовать функции, то ещё желательна отдельная секция для функций и их upvalue. Совершенно человеконечитаемо, но позволяет экономить байтики на объёмных данных, не дублируя миллиард одинаковых ключей-значений. Оно как бы должно учитывать длину ключей, и если те больше чем извлечение их из строкового кеша, то можно добавлять их в строковый кеш. Бонусом, подобные строчки отлично сжимаются deflet'ом до ещё меньших объёмов, или их можно частично переводить в бинарный вид, после чего дополнительно сжимать.
179090
Привет, изучаю lua такой вопрос как мне получить вывод из терминала (linux) и дать его в виде значения переменной
179090
уже не нужно , понял как по другому сделать
Пют
Ребят помогите пж
Пют
А не понял что такое elseif?
Aqendo
А не понял что такое elseif?
ещё одно условие, если предыдущее не сработало
Пют
Я чаще не понял
UtoECat
что это за побитое условие? почему когда а равен 1 ты пишешь что а меньше 4 и так далее?
UtoECat
это какая-то сверхлогическая задачка?
UtoECat
if a < 4 then print("а меньше 4") elseif a ~= 3 then print("а не равно 3") elseif a == 1 then print(" а равно 1") else print("чёрт его знает :)") end
UtoECat
А не понял что такое elseif?
if *УСЛОВИЕ* then *ДЕЙСТВИЯ* -- если условие верно else *ДЕЙСТВИЯ* -- если условие неверно end
UtoECat
а вообще ответы на большинство твоих будущих возможных вопросов есть туть http://lua.org.ru/contents_ru.html (проскипать C API (4), оно тебе не нужно)
Aqendo
это уже бизнес-логика пошла
UtoECat
что это опять такое? зачем писать, что a == 1 когда это не так?
UtoECat
elseif - условие если не выполнилось условие до. Это, по факту, синтаксический сахарок, т.к без него приходилось-бы городить ТАКОЕ if a == 1 then print(1) else if a == 2 then print(2) else if a == 3 then ... end end end
UtoECat
для выполнения нескольких условий используй логические операторы. О них ты можешь тоже почитать в мануале по ссылке выше :)
UtoECat
т.е тебе нужно отобразить окошко, в котором при нажатии на кнопочки будут выполняться какие-то действия в системе?
UtoECat
а, или это про игру?
UtoECat
ох... Ну это будет посложнее... Вообще сначала крайне советую разобраться со всеми фичами и функционалом луа, потому, что многие библиотеки для создания гуёв будут так или иначе задействовать очень много аспектов языка.
UtoECat
а конкретно по гуям, сказать чего-то отдельного не могу. Есть список самых популярных и известных либ и их биндингов для луа, но их наверняка придётся собирать... Поэтому как выучишь язык поищешь в этом списке что-то под свою ОС и что есть уже скомпилированной библиотекой :) http://lua-users.org/wiki/GraphicalUserInterfaceToolkits
Пют
a = 4 if a == 8 then print("А") if a ~= 4 then print("A") then if a < 8 then print("Правильно") else print("Хз что написать") end
Пют
Спасибо еще раз
Пют
Я знаю чела который в 13 лет делают крутые скрипты
Пют
Вот и мне захотелось выучить луа
Snusmumriken
Я знаю чела который в 13 лет делают крутые скрипты
Чел, учить скрипты "потому что крутые учат скрипты" это плохой вариант. Норм — это когда у тебя есть какая-то цель и задача и ты под неё учишь фигню.
UtoECat
Спасибо еще раз
угу. Хотя... ещё для луа есть пакетный менеджер, который позволит одной командой поставить любую либу... но это отдельная история уже, на будущее : https://github.com/luarocks/luarocks/wiki/Installation-instructions-for-Windows пока этим голову можешь не забивать
UtoECat
a = 4 if a == 8 then print("А") if a ~= 4 then print("A") then if a < 8 then print("Правильно") else print("Хз что написать") end
кстати, этот код не корректен. Ты лучше сразу проверяй правильно ли ты написал(а) код или нет, пытаясь его выполнить интерпретатором. он укажет на возможные ошибки
🌗
и правильно пишет
Igor
Потому что интерпретирует он не так, кау ты думаешь
Igor
Почитай пожалуйста про основы программирования и логики
Пют
🌗
а вопрос то где
Highly Likely
rawequal, lol
Aydar
Я не знаю где вы это читаете но качество этого текста очень сомнительное, лучше сразу взять книгу "Программирование на языке Lua"
Aydar
Было бы неплохо если бы кто-нибудь сделал список курсов/уроков/туториалов не таких объемных как книга но при этом отсмотренных на предмет качества без явных косяков вроде того же rawequal
Aydar
Именно книгу найти не проблема, но какой-нибудь курс желательно доступный и на русском и на английском и с интерактивными задачками между темами новичкам бы гораздо сильнее понравился, я книгу двум-трем людям советовал, они говорят длинно, нудно (хотя она вообще тонкая, относительно например того же трёхтомника про perl)
Aydar
То есть если человек отказался читать книгу то сразу консервирование? :) Я ее советовал естественно тем кто про луа спрашивал.
Luсky
То есть если человек отказался читать книгу то сразу консервирование? :) Я ее советовал естественно тем кто про луа спрашивал.
Забей. Кому надо, тот сам рыбу пойдёт ловить. Кому не надо - будет перебирать - эта без икры, та - тиной воняет. И т.д.
Luсky
Максимум полезного, что ты можешь сделать - показать где клюёт
Mediator
Luсky
Её ФБР прикрыло.
Фбр только адреса отжало. Открой для себя tor и адреса .onion
Mediator
Фбр только адреса отжало. Открой для себя tor и адреса .onion
Дома будешь тыкать и рассказывать, что кому открыть. А по делу: никто не будет это всё устанавливать ради одной книжки.
Aqendo
вы продаете рыбов?
Snusmumriken
Не продаёт ((
Aqendo
😢
fgntfg
Игру про подажу рыбов котам
Lucky
Денис
Господа и, если таковые присутствуют, дамы! С новым годом всех! Полез я тут, значится, почитать про оптимизацию кода в Lua и наткнулся на сайт ComputerCraft. В частности, на вот эту статью. Увидел про упоминание тернарных операторов и пошел читать. Как говорится, век живи, век учись! До сегодняшнего момента я, честно говоря, не совсем понимал как это работает, а ларчик-то простой и гибкий, оказывается! Из всех приколов я использовал только or при переборе значений и реализацию опциональных параметров. Но, знаете ли, там можно пойти еще глубже! И это охренеть как круто! Про оптимизацию, я подозреваю, что сказано не все.
Highly Likely
Злоупотреблять тернарниками в целом вредно
Highly Likely
Код быстрее не становится, зато читаемость страдает
Highly Likely
Я просто увидел там проверку типа и ужаснулся
Денис
советы действительно сомнительные
Да, в этой статье я ничего нового, кроме тернарных операторов, не открыл. Все и так ясно. Может быть только таблица размеров интересная еще.
Денис
Код быстрее не становится, зато читаемость страдает
Ну, порой правда бывает лучше одной строкой обойтись. Мне тоже говорили, что регексы читать невозможно в принципе. А если регексы стандартные, не вы**истые, то их таки прочитать можно! Раза с пятого, но можно.
Денис
Еще вот такую статью нашел: http://mydc.ru/ptopic1018.html
Snusmumriken
Господа и, если таковые присутствуют, дамы! С новым годом всех! Полез я тут, значится, почитать про оптимизацию кода в Lua и наткнулся на сайт ComputerCraft. В частности, на вот эту статью. Увидел про упоминание тернарных операторов и пошел читать. Как говорится, век живи, век учись! До сегодняшнего момента я, честно говоря, не совсем понимал как это работает, а ларчик-то простой и гибкий, оказывается! Из всех приколов я использовал только or при переборе значений и реализацию опциональных параметров. Но, знаете ли, там можно пойти еще глубже! И это охренеть как круто! Про оптимизацию, я подозреваю, что сказано не все.
1. Место в памяти под таблицы — оно зависит от версии Lua (32/64), и все указатели (на числа-функции-строки) тоже сворачиваются в число разрядности системы, но вычислять объёмы таблицы — довольно напряжное занятие, лучше заниматься этим в сишке. 2. Сборка мусора относится только к опенкомпам. 3. Заменять всякие 1/4 на 1 * 0.25 — прирост действительно будет, но на очень объёмных операциях. Деление действительно немного медленнее. 4. Менять значения переменных без буфера — фигня, луа на каждое присваивание создаёт новый буфер. 5. Рекурсия относительно быстрая, но там проблема в её глубине, нельзя уходить в 100-200 рекурсивных вызовов, в зависимости от настроек луёв. В целом луа умеет в хвостовую оптимизацию, но не всего. А вот реальные варианты оптимизации: — Не размечать память без необходимости. Минимум операций со строками, минимум созданий мусорных табличек которые нужны на один раз внутри часто вызываемой функции, минимум генераций функций-лямбд, если что-то нужно много раз — можно закешировать; — Переиспользование. Тебе надо плодить и удалять тысячи объектов в секунду? Заведи под них буфер, пихай в него то, что в данный момент не нужно, извлекай из буфера когда понадобилось и реинициализируй. — Выделяй в сишку тяжёлые операции. Тернарные операторы — это великое благо и великая печаль, когда ты тернаришь булеаны.
Денис
1. Место в памяти под таблицы — оно зависит от версии Lua (32/64), и все указатели (на числа-функции-строки) тоже сворачиваются в число разрядности системы, но вычислять объёмы таблицы — довольно напряжное занятие, лучше заниматься этим в сишке. 2. Сборка мусора относится только к опенкомпам. 3. Заменять всякие 1/4 на 1 * 0.25 — прирост действительно будет, но на очень объёмных операциях. Деление действительно немного медленнее. 4. Менять значения переменных без буфера — фигня, луа на каждое присваивание создаёт новый буфер. 5. Рекурсия относительно быстрая, но там проблема в её глубине, нельзя уходить в 100-200 рекурсивных вызовов, в зависимости от настроек луёв. В целом луа умеет в хвостовую оптимизацию, но не всего. А вот реальные варианты оптимизации: — Не размечать память без необходимости. Минимум операций со строками, минимум созданий мусорных табличек которые нужны на один раз внутри часто вызываемой функции, минимум генераций функций-лямбд, если что-то нужно много раз — можно закешировать; — Переиспользование. Тебе надо плодить и удалять тысячи объектов в секунду? Заведи под них буфер, пихай в него то, что в данный момент не нужно, извлекай из буфера когда понадобилось и реинициализируй. — Выделяй в сишку тяжёлые операции. Тернарные операторы — это великое благо и великая печаль, когда ты тернаришь булеаны.
Про сборщик мусора я, касаемо первой статьи, поржал. Веселые ребята: отрубить сборщик мусора и вызывать некий os.sleep() чем больше, тем лучше. Муахахахах! Скажите мне пожалуйста что такое опенкомпы, я их обходить стороной буду!
Денис
1. Место в памяти под таблицы — оно зависит от версии Lua (32/64), и все указатели (на числа-функции-строки) тоже сворачиваются в число разрядности системы, но вычислять объёмы таблицы — довольно напряжное занятие, лучше заниматься этим в сишке. 2. Сборка мусора относится только к опенкомпам. 3. Заменять всякие 1/4 на 1 * 0.25 — прирост действительно будет, но на очень объёмных операциях. Деление действительно немного медленнее. 4. Менять значения переменных без буфера — фигня, луа на каждое присваивание создаёт новый буфер. 5. Рекурсия относительно быстрая, но там проблема в её глубине, нельзя уходить в 100-200 рекурсивных вызовов, в зависимости от настроек луёв. В целом луа умеет в хвостовую оптимизацию, но не всего. А вот реальные варианты оптимизации: — Не размечать память без необходимости. Минимум операций со строками, минимум созданий мусорных табличек которые нужны на один раз внутри часто вызываемой функции, минимум генераций функций-лямбд, если что-то нужно много раз — можно закешировать; — Переиспользование. Тебе надо плодить и удалять тысячи объектов в секунду? Заведи под них буфер, пихай в него то, что в данный момент не нужно, извлекай из буфера когда понадобилось и реинициализируй. — Выделяй в сишку тяжёлые операции. Тернарные операторы — это великое благо и великая печаль, когда ты тернаришь булеаны.
А про размеры - я сами цифры не запоминал. Я просто запомнил абстрактно кто и что занимает. Понятно, что там весьма много разных "но".
Денис
А тернарить булеаны - это да! Но если нам нужно положиться на истину, должно как-то даже и работать.
Денис
Кстати, у себя в тулзах сделал функции, которые конкатенатят строки через table.concat. Если мне нужно в оптимизацию, лучше все же так не делать?
Денис
Функция выглядит вот так: function string.joinsep(orig, sep, ...) sep = sep or "" local result = {} table.insert(result, orig) for _, field in ipairs(table.pack(...)) do table.insert(result, field) end return table.concat(result, sep) end
Snusmumriken
Функция выглядит вот так: function string.joinsep(orig, sep, ...) sep = sep or "" local result = {} table.insert(result, orig) for _, field in ipairs(table.pack(...)) do table.insert(result, field) end return table.concat(result, sep) end
Тут довольно интересное дело, потому что создаются сразу две таблицы — от table.pack и result. Я бы делал что-то такое: function string.joinsep(orig, sep, ...) sep = sep or "" local count = select("#", ...) if count < 10 then local result = orig for i = 1, count do result = result .. sep .. select(i, ...) end return result end return table.concat(table.pack(orig, ...), sep) end