:D

не смешно, кстати

я так и делаю

правда с хмл

Взять готовое на си, написать небольшой c-api враппер, вылить на гитхаб, получить звездочек, profit!

» звездочек на погоны?

local regex = '<'..tag..'.*</'..tag..'>' local regex2 = '</?'..tag..'>' for substring in string.gmatch(str, regex) do local one, two = string.gsub(substring, regex2, '') return one end return nil

хз где взял

https://habrahabr.ru/post/190044/ гуглится очень просто

Компилим в .dll-ку и ебошим ffi-биндинг : )

https://habrahabr.ru/post/190044/ гуглится очень просто

И тут то резко сокращается что нодожопников

Ну вроде как ЖС используется ради возможностей по работе с хтмл, в поле, не? Если нет, то может мне кто-нибудь объяснить, с чего её так хайпят?

...

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

Чем https://github.com/craigbarnes/lua-gumbo не устраивает?

Вроде обновляется, есть FFI версия

Даже документация какая то

А я это специально только что проверил :) [ERR] Main loop reached loop limit (1000). Подробности в личку

ну так вот я залипание и починил: вместо него теперь репорт, что бесконечный цикл.

И на том спасибо. Интересно, что там в структуре страницы не так?

через пару часов погляжу :)

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

В это время - мой отец обнаружил "Бизнес-Процессы" в Битрикс24. И оказывается это тупо визуальный язык программирования. Интересссно. Есть импорт/экспорт в формате сжатого zlib php serialize() массива/объекта. И у меня чешутся руки сделать нормальный "компилятор" для этой фигни.

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

В это время - мой отец обнаружил "Бизнес-Процессы" в Битрикс24. И оказывается это тупо визуальный язык программирования. Интересссно. Есть импорт/экспорт в формате сжатого zlib php serialize() массива/объекта. И у меня чешутся руки сделать нормальный "компилятор" для этой фигни.

го пилить

И на том спасибо. Интересно, что там в структуре страницы не так?

кароч, там всё в порядке с модулем. Просто лимит лупов надо с 1000 поднять до 15000

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

Двачую за тайпскрипт, если тебе нужна статическая типизация в жс (:

Ну вот я про то же. Без оболочек, жс малополезен. А у тайпскрипта, кстати, самый заебатый синтаксис, из всего что я знаю.

Нода чем не устраивает?

тысячи их

например, v8 и spidermonkey

ну и всякие маргинальные а-ля mujs, duktape, rhimo

Смешались в кучу кони, люди.

Blink разве не браузерный движок для отображения веб-страниц?

Электрона, а не ноды.

А нода не на в8?

Точнее на Блинке в котором в8

У меня где-то болтается v8 для луа, кек. Просто выполняем кусок кода: v8 = require'v8' v = v8.eval[[ function foo(){ return args[1] + args[2]; }; return foo(); ]](10, 20) Чот такое. Это только движок, ничего больше.

Тут вроде про браузеры и v8, мое мнение нужно. Браузеры слишком много оперативки кушают! Все, хромиум больше всех, потом фф, потом всякие там. Это действительно несправедливо! Надо было писать на си, не на плюсах, не знаю насколько бы стало лучше, но было бы лучше. И надо было luajit вместо v8! Пусть v8 гордиться оптимизациями, но памяти точно во много раз больше кушает. Вот какого черта браузер самая тяжелая программа

Браузер - двигатель прогресса. Если бы он был лёгким, хомячки бы все равно сидели на нищепеках с 2гб оперативки.

Ну вот я про то же. Без оболочек, жс малополезен. А у тайпскрипта, кстати, самый заебатый синтаксис, из всего что я знаю.

Советую livescript посмотреть, не использовать, просто посмотреть, по-моему, там синтаксис заебатейший-призаебатейший, не считая :=

https://www.lua.org/manual/5.1/manual.html#lua_pushlightuserdata

А что ты на выходе хочешь получить? : ) Поинтер - light userdata. Ты хотел поинтер.

Ох, а как я с ffi делаю так? Это поинтеры, если что.

Передали откуда?

Опачки, а тут же как-то цепляют! Это первая строка на запрос в гугл lua c api metatable. https://stackoverflow.com/questions/3449759/lua-c-api-and-metatable-functions Почему ты это не загуглил? ))

Можно просто обернуть указател в full userdata

и если надо по указателю находить объект, то просто таблицу light userdata => full userdata. Возможно weak

http://lua-users.org/wiki/UserDataExample

Ты давай фигнёй прекращай страдать, потому что ты видимо гуглить не умеешь : ) Ну я тебя научу. Буду кидать ссылками пока не дойдёт : )

Тебе не нужна фулл-юзердата, только поинтер на структуру на сишной стороне, на которую прицеплена метатаблица. Иначе всякие методы типа __gc не прокатят, и появятся всякие утечки памяти с прочим говном.

какие утечки с full userdata? Надо только определится кто отвечает за уничтожение объекта

Ну как тебе сказать. foo = require'dynamic_lib' obj = foo.newObj() -- userdata obj = nil -> вся юзердата в луа идёт поинтерами. Удалили поинтер но не удалили объект? Радуемся спиду.

у тебя есть указатель на память распределенную гдето. далее ты оборачиваешь его в full userdata. далее тебе необходимо определится должна ли эта память освобождатся при уничтожении full userdata или нет

А каким образом, кроме метода __gc?

А каким образом, кроме метода __gc?

Еще раз. у тебя есть указатель на память

Ты на стороне луа что-то удалил, присвоив переменной с указателем на память - nil. Как об этом узнает сишная сторона?

этот указатель может быть получен из некой библиотеки. Это может быть указатель с подсчетом ссылок

Предлагаешь сканировать указатели? С какой частотой? В какое время? Поставить хук на collectgarbage?

Что значит сканировать

Подсчитывать ссылки : )

Ну, их ещё сосчитать надо. А где?

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

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

Реальный пример Есть некий сервер который на каждый запрос создает новый Lua State. Этот сервер имеет пул подключений к БД. При запросе сервер берет подключение из пула и обарачивает его в full userdata. По завершению запроса сервер удаляет Lua state. Естественно удаляется и full userdata. При это ни какого удаления памяти не нужно, Просто вернуть указатель в пул, Про подсчет ссылок. В момент создания full userdata делаем IncremenCounter(ptr) в __gc делаем DecrimentCounter(ptr). ptr это некоторый указатель с подсчетом ссылок.

Ох. Да, это рабочий вариант, но о-о-о-очень узкоспециализированный. Представь что ты делаешь компьютерную игру. Тебе нужна ниибацца огромная куча векторов и матриц, с офигенно быстрыми сишными операциями, с битовыми сдвигами и прочей прелестью. И ты не можешь удалять lua_State. Векторы плодятся и "удаляются" каждый кадр, 60 раз в секунду. Пусть каждый и весит несколько байт, но за пол часа, допустим, успевает создасться и удалиться тридцать миллионов векторов и матриц, что выливается в 50-100мб памяти. А удалять lua_State ты не можешь. И ты знаешь? Твой способ - это всё равно что перезагружать компьютер, чтобы закрыть окошки.

Ну, или закрывать фотошоп чтобы закрыть картинку, которую редактируешь в данный момент, иначе она только покажет что закроется. Да, это ближе. В любом случае, я считаю что библиотеки, которые рассчитаны на такой подход - хуйня.

при чем тут способ как ты создаешь много Lua объектов за которые отвечает сборщик мусора.

А юзердата? За них сборщик мусора не отвечает?

отвечает

А зачем закрывать lua_state, если сборщик всё равно соберёт?

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

я тебя не понимаю. Задача. Есть объект в C и нужно дать к нему доступ из Lua. При любых вариантах необходимо создавать объект в Lua. Будь то full userdata или lighuserdata

Я просто смотрю на бешеные переусложнения, и в голову закрадывается вопрос: "Нахуя так сложно, когда за вас уже всё написали?".

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

Удаление объекта в Lua не означает удаление его в системе в целом. Но да в __gc нужно некоторое освобождение в общем смысле.

__gc это мутаметод => нужна метатаблица => очень желательно использовать full userdata

Если программой рулит луа-код, сишка работает "паровозом" а луа - "машинистом" - удаляя юзердату лучше её удалять из системы финалайзером, попутно, мб, выполняя кучу лишней фигни : ) Ну там, сокеты - лайт-юзердата. Когда ты удаляешь присоединённый сокет - вызываются методы закрывания сокета, изымания аренды у оси и всё такое.

Устанавливать метатаблицы на lightuserdata не очень хорошая идея

Обоснуй фулл-юзердату. Зачем? Почему устанавливать метатаблицу на лайт - плохая? Типа, если закрывать луа-стейт с лайт-юзердатой с метатаблицей - всё упадёт нафиг и ничего не удалится? Если дёрнуть сборщик мусора перед закрытием (а он дёргается автоматом) - удалится.

Обоснуй фулл-юзердату. Зачем? Почему устанавливать метатаблицу на лайт - плохая? Типа, если закрывать луа-стейт с лайт-юзердатой с метатаблицей - всё упадёт нафиг и ничего не удалится? Если дёрнуть сборщик мусора перед закрытием (а он дёргается автоматом) - удалится.

Как ты предлагаешь отличать твои указатели от не твоих в __gc для lightusedata?