ㅤ
ㅤ
Snusmumriken
> for dogs
Даже не пытайся... Если твои собакены не выглядят вот так:
Ну тогда это уже lua for doges.
Snusmumriken
ㅤ
Dogescript.
ㅤ
Wow
ㅤ
Уже есть
https://github.com/dogescript/dogescript
> compile-to-JS
Надо запилить для Lua и назвать doggoscript.
Snusmumriken
Logescript
Lucky
Huskyl
Sven
доброго вечера Программирование на Lua в формате epub нет ни у кого?
Snusmumriken
доброго вечера Программирование на Lua в формате epub нет ни у кого?
Сложна, гугл не находит особо. Мб pdf обернуть?
Sven
спасибо нашел
Sven
Sven
может кому пригодится
vvzvlad
Обращайся
ㅤ
> Вдавайся в след. Раз
> след. Раз
> . Раз
Сейчас бы в интернете учить проверять автоподстановку.
Mark ☢️
Mark ☢️
Он уже поправил
Snusmumriken
Оно может (что сделать?) - пригодиться.
Оно может (что сделает?) - пригодится.
Ох уж эти тонкости русского языка.
Лучше расскажите мне разницу между
"Чай долго остывал" и "Чай долго не остывал".
vvzvlad
Чай долго не остывал в термосе.
В предбаннике было так жарко чай остывал очень долго
vvzvlad
Во втором случае подразумевается, что чай оставался горячим, и совсем не остывал, и это состояние длилось долго.
А в первом — что он всё-таки остывал, но медленно.
Snusmumriken
В моём восприятии, первый вариант это констатация факта длительного процесса остывания чая, а второй - указывает на дополнительный контекст, например "кто-то ждал что чай остынет, но он всё не остывал".
vvzvlad
Ну да, или "чай в термосе долго не остывал, но когда термос открыли, за полчаса он превратился в лёд". Там что-то внешнее должно быть.
Snusmumriken
Ну да, наличие контекста.
Забавное применение для отрицания, правда? : )
vvzvlad
Ну, логичное. Если он не остывал сам по себе, то чтобы он всё-таки остыл, необходимо ещё что-то.
Snusmumriken
Да, для гопников-то уже есть!
Snusmumriken
Ну видеоуроки "Lua/love2d для маленьких гопников".
Dårk
повеселился с ловлей кастомных ошибок (имитация catch), пока не вчитался в документацию:
error (message [, level])
Usually, error adds some information about the error position at the beginning of the message, if the message is a string.
теперь кидаю кастомную ошибку так:
1. local ERR = {"error"}
2. error(ERR)
3. local ok, msg = pcall(...)
if not ok and msg ~= ERR then
error(msg)
end
Maxim
повеселился с ловлей кастомных ошибок (имитация catch), пока не вчитался в документацию:
error (message [, level])
Usually, error adds some information about the error position at the beginning of the message, if the message is a string.
теперь кидаю кастомную ошибку так:
1. local ERR = {"error"}
2. error(ERR)
3. local ok, msg = pcall(...)
if not ok and msg ~= ERR then
error(msg)
end
А обычный способ по каким причинам не радует ?
Maxim
пруф?
local status, err = pcall(function () error({code=121}) end)
print(err.code) --> 121
Вопрос остался прежним "чем обычный способ не радует"?
Dårk
a) RTFM. pcall ловит всё. нет механик указать ему, что ловить, а что — нет.
б) очевидно, чтобы ловить только свои исключения, а остальные пробрасывать дальше.
Maxim
повеселился с ловлей кастомных ошибок (имитация catch), пока не вчитался в документацию:
error (message [, level])
Usually, error adds some information about the error position at the beginning of the message, if the message is a string.
теперь кидаю кастомную ошибку так:
1. local ERR = {"error"}
2. error(ERR)
3. local ok, msg = pcall(...)
if not ok and msg ~= ERR then
error(msg)
end
Подскажите чем отличается ваше решение от решения что в документации?
https://www.lua.org/pil/8.4.html
Dårk
Подскажите чем отличается ваше решение от решения что в документации?
https://www.lua.org/pil/8.4.html
эээ… в чем здесь решение? это же просто менее формальное описание функций error/pcall, не?
Maxim
эээ… в чем здесь решение? это же просто менее формальное описание функций error/pcall, не?
Тогда чем лучше то описание что у вас получилось по отношению к тому что приводится в документации?
Maxim
Почему эти строчки не лишние?
local ERR = {"error"}
error(ERR)
Dårk
повеселился с ловлей кастомных ошибок (имитация catch), пока не вчитался в документацию:
error (message [, level])
Usually, error adds some information about the error position at the beginning of the message, if the message is a string.
теперь кидаю кастомную ошибку так:
1. local ERR = {"error"}
2. error(ERR)
3. local ok, msg = pcall(...)
if not ok and msg ~= ERR then
error(msg)
end
ещё раз, внимательно.
Usually, error adds some information about the error position at the beginning of the message, if the message is a string.
Dårk
== более не работает
Maxim
Может пример есть?
Dårk
не, остальное — домашняя работа 😉
Dårk
-- Generic unique XXX module error.
-- Not a string, so error() does not mess it up with metadata.
local ERR_XXX = {"XXX error"}
Snusmumriken
Карочи, фигня в том, что:
1. Функция всё равно будет прерываться на первом же error'е
2. Всякие фактические ошибки от луёв всё равно будут возвращаться в виде строчки, мало того что это не избавляет от классической конструкции:
local succ, err = bla-bla
if not succ then
log:error(tostring(err))
return
end
Так ещё и вынуждает дополнительно проверять типы
local succ, err = bla-bla
if type(succ) == 'string' then -- упало на луёвой ошибке
log:error(err)
elseif type(succ) == 'table' then -- упало на кастомной
log:error(tostring(err.code))
end
*нормальные люди не самоубийцы, уполторять-удваивать длину написанного, снижать читаемость и ещё делать кучу всего лишнего, хотя кто-то же пишет на жаве, хм*
Snusmumriken
Хотя тема: выделить вот тот вот обработчик ошибок в функцию logsert, типа как assert, но при несрабатывании пишет в лог, и там уже проверяет типы : )
mihacooper [МСК -2]
Вопрос к знатокам: кто-нибудь знает как в Lua устроено хранение/работа с целыми числами в ключах таблиц? По производительно работа с целочисленными ключами значительно быстрее, чем с остальными типами данных.
Yuriy
Вопрос к знатокам: кто-нибудь знает как в Lua устроено хранение/работа с целыми числами в ключах таблиц? По производительно работа с целочисленными ключами значительно быстрее, чем с остальными типами данных.
Ну если говорить о производительности то массивы будут самыми производительными в данном случае, так как ключ получается прямым указателем на смещение от первоначальной ячейки памяти
mihacooper [МСК -2]
Ну если говорить о производительности то массивы будут самыми производительными в данном случае, так как ключ получается прямым указателем на смещение от первоначальной ячейки памяти
Получение позиции элемента по смещению означает в таком случае использования обычного линейного массива, что не эффективно по памяти в общем случае
Yuriy
Ну так вопрос был и не об этом я так понимаю
Yuriy
Получение позиции элемента по смещению означает в таком случае использования обычного линейного массива, что не эффективно по памяти в общем случае
mihacooper [МСК -2]
Мне интересно как целочисленные ключи представлены в памяти интерпретатора
mihacooper [МСК -2]
Если посмотреть на производительность вставки ключей разных типов, то получается, если грубо:
Строки: 0.062
Не целые: 0.018
Целые: 0.003
Видно что вставка целых типов быстрее на порядок, что наводит на мысль о том, что хранятся они как-то иначе.
Anonymous
Если посмотреть на производительность вставки ключей разных типов, то получается, если грубо:
Строки: 0.062
Не целые: 0.018
Целые: 0.003
Видно что вставка целых типов быстрее на порядок, что наводит на мысль о том, что хранятся они как-то иначе.
А не хеш-тайбл ли там? Тогда, вероятно, брать хеш от целого быстрее.
mihacooper [МСК -2]
я думаю, что хэш для остального используется, но не для чисел
mihacooper [МСК -2]
если ВСЕ хранить в хэш таблице, то для чисел вставка получается побыстрее, но не на столько
mihacooper [МСК -2]
что навело на мысли о том, что можно иметь два контейнера:
1) хэш таблицу для всего кроме целых чисел
2) ??? - для целых чисел
=)
Max
что навело на мысли о том, что можно иметь два контейнера:
1) хэш таблицу для всего кроме целых чисел
2) ??? - для целых чисел
=)
??? -- это обычный массив. Неэффективность по памяти решается тем, что большие (не попадающие в память, выделенную для массива) индексы идут в хэш-часть. Можешь попробовать в своем бенчмарке вставлять большие целые, перформанс должен быть таким же, как у нецелых ключей
Anonymous
Прикольно, выходит "хеш от сисла меньше, чем..." это число.
mihacooper [МСК -2]
??? -- это обычный массив. Неэффективность по памяти решается тем, что большие (не попадающие в память, выделенную для массива) индексы идут в хэш-часть. Можешь попробовать в своем бенчмарке вставлять большие целые, перформанс должен быть таким же, как у нецелых ключей
хмм, интересно получается. Действительно есть разница. Тогда вопрос такой, каким образом определяется размер этого линейного массива?
Snusmumriken
хмм, интересно получается. Действительно есть разница. Тогда вопрос такой, каким образом определяется размер этого линейного массива?
Это "динамический" массив, он расширяется/сужается при добавлении/удалении значений, конечно.
Max
но изначальный размер можно задать, например через lua_createtable
Snusmumriken
Ну, это первоначальная разметка, да.
mihacooper [МСК -2]
Но если делать "в лоб" через линейный массив, то у нас опять же возникнет проблема чрезмерной аллокации не используемой памяти. Там не используется чего-то типа deque со связными списками из последовательных участков памяти?
Snusmumriken
Нет.
А ещё, table.remove из начала таблицы - сдвигает все остальные элементы таблицы назад, и получается просадка производительности. Ужас, да?
mihacooper [МСК -2]
ну это да, знакомо
Snusmumriken
Специально для этого где-то писал функцию, обезnil'ивающую таблицы, типа с двумя курсорами: что сдвигаем и куда сдвигаем, в зависимости от количества встреченных пустых элементов. Ибо дёргать table.remove на каждый - слишком затратно. Один раз прошлись и удалили миллиард элементов из рандомных мест присвоением nil'ов, второй раз прошли - и подчистили хвосты. Типа так быстрее.
Snusmumriken
А если серьёзно - таблицы, за счёт своей универсальности, по умолчанию - далеко не самая эффективная структура для всего подряд. Но на их основе можно мутить что-то более эффективное под конкретный случай (типа связных списков/рингбуферов и всякого такого), а если прям совсем pripeklow - написать либу на сишке или выцепить из сишки обычные массивы либой/ffi.
mihacooper [МСК -2]
А если серьёзно - таблицы, за счёт своей универсальности, по умолчанию - далеко не самая эффективная структура для всего подряд. Но на их основе можно мутить что-то более эффективное под конкретный случай (типа связных списков/рингбуферов и всякого такого), а если прям совсем pripeklow - написать либу на сишке или выцепить из сишки обычные массивы либой/ffi.
тут тоже есть свои проблемы. В частности скорость работы userdata + metatable
mihacooper [МСК -2]
если пытаться делать красиво конечно