нет, не для этого, чтобы когда файл по сети приходил и в таблицу писался - чтобы файлы печатались только в виде названия

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

о, кстати. вот у меня есть скрипт на lua, который хранится в git-е. Хочется, чтобы этот скрипт при включении выдавал текущую свою текущую версию, которую брал бы из гита(то, что получается командой git describe —dirty —always —tags).

заметил hastebin открытый сейчас —однопроходный хардкод кодировшик в джсон хуй пойми что это, но если надо луёй json закодировать вот мой велик: https://hastebin.com/lecopileya.rb — moon https://hastebin.com/akilokisac.lua — скомпиленный луа

Внимание, вопрос: как проще всего запихнуть в луа скрипт изменяемую при каждом коммите версию, учитывая то, что скрипт почти всегда выполняется на машине без гита(т.е. просто выполнять эту команду не получится)

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

Можно сделать version.lua, сделать скриптик, который пишет в version.lua какие там данные нужны и делает пуш, как-то так

да там есть git-hooks, скрипт не обязателен

больше не нравится то, что если забыть скопировать в продакшен файлик с версией, то он покажет старую версию в следующий раз

Тема закрыта. Дальнейшие сообщения будут удаляться.

И ещё мой велосипед json'а https://github.com/Romaboy/rjson гораздо быстрее любой луашной реализации, сегфолты немного мешают иногда, но ниче 👌

И ещё мой велосипед json'а https://github.com/Romaboy/rjson гораздо быстрее любой луашной реализации, сегфолты немного мешают иногда, но ниче 👌

Зацикленные таблицы сериализует? Или хотя бы дропает? : ) Как реагирует на CDATA/USERDATA? Да, сишная версия парсера всегда будет быстрее луашной (медленные неизменяемые строки в луа). Давай бенчмаркни с cjson : )

3 месяца назад писал, не помню когда руки дойдут доделать - зацикленные таблицы можно решать уровнем вложенности максимальным CDATA/USERDATA - да им не место в json'e, что им там делать?

там были бенчмарки, велосипед быстрее!

Бывает что пытаются сериализовать объект с userdata. Я модифицировал cjson чтобы так делать, правда, я туда закинул кучу колбеков, типа "если встречается такая cdata - делать вот это".

и в этом объекте можно разные данные хранить?

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

таблицы как ключи в json?

От этого, как ты понимаешь, теряется совместимость с нормальным json.

так если нет совместимости, то это уже несовместимый диалект выходит

От этого, как ты понимаешь, теряется совместимость с нормальным json.

Я решил вопрос, записью ссылки как строки и вынесение в тело объекта

Ну типа того. bson, вон, тоже несовместим.

С json совместим, но на принимающей стороне нужна поддержка биндинга

Я решил вопрос, записью ссылки как строки и вынесение в тело объекта

Молодец. А я закинул это гиблое дело и уже перешёл на другой уровень совместимости. Методы tostring/fromstring у объектов, которые при сериализации - делают что-то со своей юзердатой, чтобы составлялся нормальный json, а при десериализации - мутят обратную процедуру.

{ "table: 0x06c51d18" : ["some","some2", "table: 0x06c51d18" }

Ну не фонтан конечно

Тихо ты. Зафлудил уже всё.

Тихо ты. Зафлудил уже всё.

Нет, ну вопрос же хороший. Как быть если объект ссылается сам на себя к примеру?

а в моей реализации есть as_json у таблиц, и они уже если что сами решат что вернуть

Нет, ну вопрос же хороший. Как быть если объект ссылается сам на себя к примеру?

Только если ты общаешься между хреновинами, имеющими один яп/набор библиотек сериализации. Если нет - нет.

а в моей реализации есть as_json у таблиц, и они уже если что сами решат что вернуть

Это удобно и практично, если к примеру ты пишешь в объектном стиле, но если ты просто из готового кода хочешь данные выдернуть, это не подойдет.

Только если ты общаешься между хреновинами, имеющими один яп/набор библиотек сериализации. Если нет - нет.

Ну понятно, что на принимаюшей стороне нужна поддержка, просто все юзают json

А знаешь почему?

А знаешь почему?

Вроде как простой и читаемость хорошая, но мне кажутся эти аргументы сомнительными

Потому что стандарт, ёпта.

Потому что стандарт, ёпта.

Ну это понятно, он помойму еще подмножество js, а значит код переводить в js легко. Но это не точно

Да блин, не самый компактный, с гибкостью беда, зато стандарт, ёпта

Да. А ещё, переводить код во что угодно легко. Ты будешь писать реализацию своего формата в ruby/js/python/c/c++/java/c#? Нет? Да? А рекламировать будешь? Чтобы все вдруг перешли с json на твою вариацию. Если нет - пиши себе, для своих узких задач.

Их много разных, форматов, не нужно ничего писать и придумывать

Помойму, это я тут агитировал за стандартизацию. Поэтому и написал велосипед, задачу решает и пофиг

для разных целей, портированы на все основные языки

Помойму, это я тут агитировал за стандартизацию. Поэтому и написал велосипед, задачу решает и пофиг

Что блин? ) Пчёлы против мёда? )) Торчки за отмену легалайза?

Что блин? ) Пчёлы против мёда? )) Торчки за отмену легалайза?

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

Луа = скриптовая сишка. То есть, тут пустая стандартная либа, изобретай чо хошь. Но уже много что написано, поэтому берёшь гугл, ищешь в нём "Хачу Такую Хуйню на Луа", и получаешь.

вот messagepack чем хуже json? да ничем, а используется не так часто потому что json это стандарт в умах

ну да, он нечитаем

ладно, json норм

вот messagepack чем хуже json? да ничем, а используется не так часто потому что json это стандарт в умах

Все знают json, если у тебя весь проект на него завязан, тащить в луа и из луа, что то кроме, смысла нет. Консистентность же

мне одному на работу завтра?

я тут ебанулся совсем, спокойных

Luasocket - настолько распространён, что можно считать стандартом сетевых коммуникаций. Достаточно низкоуровневая и обладает широкими фичами. Даже есть ssl-апгрейд - luasec. Cjson - аналогично стандартная сишная вариация json. Достаточно быстрая. Есть pure-lua вариации, если тебе прям переносимость кода важна, чтобы просто перенёс папку с win x86 на linex arm, и всё сразу заработало. Lfs - аналогичный стандарт работы с файловыми системами (итераторы по директориям, хуё-моё). Lpeg - аналогичный стандарт работы со сложными регулярками (Lrexlib для PCRE). Lanes - аналогичная хуйня для многопоточки. Lua-utf8 - для работы с многобайтными кодировками. И ещё много-много всего того, что хорошо написано и широко распространено. Можешь считать это - стандартной библиотекой.

Так, тоесть когда я изменяю строку, на самом деле я строю новую?

Так, тоесть когда я изменяю строку, на самом деле я строю новую?

Это особенность всех ЯП с неизменяемыми строками. Поэтому вот такая фигня: local s = '' for i = 1, 1000 do s = s..i end Во много раз медленнее чем local s = {} for i = 1, 1000 do s[i] = i end s = table.concat(s)

Зато бешено экономится память на дубликатах строк.

Емае, тоесть я решал задачу а на самом деле создал еше большую проблему

Вот тебе и не знать как работают скриптовые ЯП. В жаве/шарпе, кстати, та же фигня.

Хм, тоесть правильней строить таблицу из значений, а потом tostring() делать

concat.

Кстати, в руби строки изменяемы, что порой создает разрыв шаблона и не мешает быть руби самым слоупочным в мире. Значит, теоритически скриптовым ЯП никто не мешает иметь изменяемые строки. В туториале по производительности от Роберто было написано, что перл со строками намного шустрей работает из-за этой самой изменяемости.

А в руби на самом деле хорошо придумали: есть символы и строки, берешь что нужно под задачу.

Кстати, в руби строки изменяемы, что порой создает разрыв шаблона и не мешает быть руби самым слоупочным в мире. Значит, теоритически скриптовым ЯП никто не мешает иметь изменяемые строки. В туториале по производительности от Роберто было написано, что перл со строками намного шустрей работает из-за этой самой изменяемости.

Руби не слоупочный, это просто у кого-то железо слабое :D

А в руби на самом деле хорошо придумали: есть символы и строки, берешь что нужно под задачу.

А в crystal символы преобразуются в числа на этапе компиляции

У меня вот тоже в руби отделе удивляются, а как это тебе хватает 4 гига оперативки. Мир с ума сошел, 4 гига это мало чтоли?

мне 4ех нехватает для работы. А я даже не кожу, блин

ёбаная ява

А в crystal символы преобразуются в числа на этапе компиляции

А это как это в числа?

:4 == 4?

А это как это в числа?

Ну все символы известны на этапе компиляции. Так же как и сишные enum'ы, например

а если получаем из внешнего мира строку, делаем to_sym?

а если получаем из внешнего мира строку, делаем to_sym?

Так нельзя

Кстати, в руби строки изменяемы, что порой создает разрыв шаблона и не мешает быть руби самым слоупочным в мире. Значит, теоритически скриптовым ЯП никто не мешает иметь изменяемые строки. В туториале по производительности от Роберто было написано, что перл со строками намного шустрей работает из-за этой самой изменяемости.

Я успел замутить класс изменяемых строк на табличках, с перегрузкой метаметодов и всем таким. А потом упоролся на регулярках %)

Правда, ничто особо не должно мешать делать трансформации: табличка > строка + регулярка > табличка.

Интересная идея очередного велосипеда: можно было бы через си апишку сделать функцию cstring например, хранить в сишке в виде динамического массива, прикрутить регулярки из перла и максимально замаскировать под строку, чтобы 'string' == type s

короч, пора форкать джит

короч, пора форкать джит

Нет, потому что можно мутить строки из ffi. Просто библиотечка, оперирующая массивами символов. С другой стороны, эта фигня не будет доступна НЕ в luajit, но где-то кроме luajit не нужна супер-пупер скорость.

Но надо чтобы 'string' == type var, это важно для условий

Если используешь библиотеку - смирись с тем что тебе приходится адаптироваться под неё. Это цена за плюшки. Когда плюшки даются без оплаты - это или бесплатный сыр, или божественная фиговина, дайте две.

Нет, потому что можно мутить строки из ffi. Просто библиотечка, оперирующая массивами символов. С другой стороны, эта фигня не будет доступна НЕ в luajit, но где-то кроме luajit не нужна супер-пупер скорость.

Вполне можно реализовать через си бридж. А вот как можно оттуда проникнуть в структуры, чтобы USERDATA была типа 'string', это уже хз

А я накатал парсер входящей фигни для редиски. Посылает/принимает всякую фигню. Это всё для ORM'а.

Вроде пока без ошибок. Если кому надо что-то такое - гоу. Правда, оно пока рассчитано на "почти лучший исход", мол, редиска всегда отвечает правильно. Надо это дополнительно обработать