Snusmumriken
Кстати, а что делает этот интересный бинарь glfw-opengl?
Snusmumriken
Или sciter тоже рендерится опенглом?
Leon174
Дык, о том и речь. Но чот не взлетает опять (возвращаясь к предыдущему разговору).
Ладно, кому захочется подробностей, можно у самого автора почитать. На rsdn он тоже есть. Кстати, приглашенным экспертом в W3C сидел, не хухры-мухры.
https://habr.com/ru/users/csmile/
Snusmumriken
Потому что это уже повод завопить "ууу нинативно" ))
Хотя на самом деле пофигу.
Leon174
А качни, глянь сам. Там примеров навалено, смотреть не пересмотреть. Компилить ничего не надо, там запускач экземплов есть.
https://sciter.com/download/
Anonymous
Нинативно в каком смысле?
Anonymous
Сайтер это же вроде мини браузер
Leon174
Не, не браузер. Почти, но нет. Это Электрон на браузерном движке, с песочницами на каждую ноду. А тут изначально отвязанный от этой лабудени движок, поэтому и размер, эээ, чутка поменьше.
Tom
Snusmumriken
Я уже всё рассказал
Snusmumriken
*ин девелопмент*, я неделю назад засел.
Snusmumriken
Можешь воспользоваться уже существующими луёвыми биндингами, они существуют, но не такие удобные. Всё на оф-сайте
Лепикоршев
В целом, обходы больших файлов (особенно когда нельзя зацепиться за символы типа \n) — это весело.
А разбиение на непересекающиеся множества выигрыш в твоей задаче не даст? Типа, один кусок не проходить дважды, и если нашёл - дальше искать только в остатках?
Snusmumriken
Ну вот это один из вариантов, я его описал.
Snusmumriken
Только это не "непересекающиеся множества" а буферизация и конкатенация с остатками.
Snusmumriken
Типа
local strbuf = ""
while true do
local a, b = strbuf:find("regex")
while a and b do
local block
block, strbuf = strbuf:sub(a, b), strbuf:sub(b + 1)
parse_block(block)
a, b = strbuf:find("regex")
end
local chunk = read(2048 * 100000)
if #chunk == 0 then break end
strbuf = strbuf .. chunk
end
Лепикоршев
Только это не "непересекающиеся множества" а буферизация и конкатенация с остатками.
Нет, я именно о непересекающиеся, на стадии подготовки текста к поиску. Т.е. не просто "не нашёл - добавил ещё блок текста", а "нашёл - добавил остатки к следующему окну поиска, не нашёл - забыл"
Snusmumriken
А, ну вот код глянь
Snusmumriken
Окно поиска — это буфер.
Snusmumriken
Ты просто вводишь кучу "непонятных терминов", которые я уже описал гораздо проще.
Лепикоршев
Типа
local strbuf = ""
while true do
local a, b = strbuf:find("regex")
while a and b do
local block
block, strbuf = strbuf:sub(a, b), strbuf:sub(b + 1)
parse_block(block)
a, b = strbuf:find("regex")
end
local chunk = read(2048 * 100000)
if #chunk == 0 then break end
strbuf = strbuf .. chunk
end
strbuf = strbuf..chunk - такие конструкции стойко не люблю))
Snusmumriken
А что поделать? : )
Лепикоршев
Ты говоришь про поиск по буферу и докидыванию в этот буфер новой порции
Snusmumriken
Так, хорошо, а как нам тогда разбить на непересекающееся множество?
Лепикоршев
Я говорю наоборот, о рассечении исходного текста на тепересекающиеся буферы
Лепикоршев
*непересекающиеся
Лепикоршев
Так, хорошо, а как нам тогда разбить на непересекающееся множество?
Исходные условия какими возьмём? От этого будет зависеть, понадобится ли нам буфер
Лепикоршев
Я о размере исходного текста
Лепикоршев
Размере блока
Лепикоршев
Иерархии блоков типа дерева
Snusmumriken
Вот тут появляется большая-большая проблема, что мы с вероятностью близкой к ста процентам не распилим наш исходный текст на целые блоки. В распилке будут куски блоков:
"<tag long-long content/><tag long-long content/>"
1. "<tag long-long"
2. " content/><tag"
3. " long-long con"
4. "tent/>"
Это проблематично парсить : )
Лепикоршев
Нам достаточно, чтобы внутри одного "распил" гарантированно встретился хотя бы один ьлок
Snusmumriken
И мы его обработаем. А что делать с кусками по бокам? Приклеивать к соседям?
Лепикоршев
Т.е. Если мы можем взять размер входного куска больше 1.5 блока - задача в лоб решается
Лепикоршев
5-7 минут, вернуст
Snusmumriken
Я когда-то чот делал такое, причём ровно на полтора размера блока, уже не помню зачем. Правда, блок обычно недетерминирован и порой весит гиги : )
Лепикоршев
Я когда-то чот делал такое, причём ровно на полтора размера блока, уже не помню зачем. Правда, блок обычно недетерминирован и порой весит гиги : )
В этом и вопрос - если размер блока гиги, то в лоб не получится, нужен будет обходной путь
Snusmumriken
Но таки чаво делать с обрезками?
Допустим мы выдрали "<tag long-long content/><tag lon" и даже вытащили блок. Его хвост нужно приклеить к следующему элементу множества?
Лепикоршев
И мы его обработаем. А что делать с кусками по бокам? Приклеивать к соседям?
Спускаемся на уровень вложенности ниже, и идём по двум цепочка - одна собирается из обрезков "начал" с предыдущим блоком, а вторая - с обрезков "хвостов" с последующим.
Snusmumriken
Так, а что тут по вложенности? У нас условные плоские списки. Деревья не нужны, а если нужны — извлечённый блок просто распарсится отдельно.
Лепикоршев
Так, а что тут по вложенности? У нас условные плоские списки. Деревья не нужны, а если нужны — извлечённый блок просто распарсится отдельно.
Вложеность циклов поиска. Т. Е. Ты следующий блок ищешь только там, где точно нет предыдущего
Лепикоршев
Поэтому и ограничение - чтобы шаблоны поиска не входили в состав друг друга
Snusmumriken
А чем это принципиально отличается от поиска с буфером, который я показал в виде кода? Плюс там нет ограничений.
Лепикоршев
Скоростью
Лепикоршев
O( log n) вместо O( n)
Snusmumriken
Типа не проходим регулярками по одному и тому же куску строки дважды?
Лепикоршев
Точнее, число прохождения уменьшается с числом найденных совпадений
Лепикоршев
Текст без совпадений оба алгоритма пройдут одинаково медленно
Snusmumriken
У меня есть страшное подозрение, что оно работает только если у нас детерминирован конец тега. То есть можно взять пару символов и точно понять что это — именно конец.
Лепикоршев
У меня есть страшное подозрение, что оно работает только если у нас детерминирован конец тега. То есть можно взять пару символов и точно понять что это — именно конец.
Точнее, если можно точно понять, что м жду начало и концом - искомый текст
Лепикоршев
Иначе - хана
Snusmumriken
Прост реальные данные обычно примерно вот такие. Хммм.
<some tags>
<unused stuff blabla/>
<nested bullshit>
<tag WE NEED THIS/> <--
<tag AND THIS/> <--
</nested bullshit>
<unused stuff blabla/>
<nested bullshit2>
<tag WE NEED THIS/> <--
<tag AND THIS/> <--
</nested bullshit2>
</some tags>
Только в одну строку, для пущего комфорта ))
Лепикоршев
Прост реальные данные обычно примерно вот такие. Хммм.
<some tags>
<unused stuff blabla/>
<nested bullshit>
<tag WE NEED THIS/> <--
<tag AND THIS/> <--
</nested bullshit>
<unused stuff blabla/>
<nested bullshit2>
<tag WE NEED THIS/> <--
<tag AND THIS/> <--
</nested bullshit2>
</some tags>
Только в одну строку, для пущего комфорта ))
Не проблема, просто два шаблона поиска - с пустым и не пустым значением тэга
Snusmumriken
Всё равно кажется нужно очень точно подгадывать, чтобы в одном прочитанном чанке было не больше одного блока. Или нет, хм.
Лепикоршев
И везде, где есть значения (пара <>...</>) мы не ищем пустой тэг (<.../>)
Лепикоршев
Лепикоршев
Главное, чтобы памяти входной размер хватило прочитать
Snusmumriken
Ладно, это уже лютые частности, я предпочитаю пусть не самые быстрые но простые и надёжные фиговины, вроде той буферной фигни ))
Благо тут обычно упирается не в скорость обхода регулярками, а скорость чтения этого самого огромного файла, и запись в базу с индексами. Типа оптимизация пяти процентов.
Лепикоршев
Ладно, это уже лютые частности, я предпочитаю пусть не самые быстрые но простые и надёжные фиговины, вроде той буферной фигни ))
Благо тут обычно упирается не в скорость обхода регулярками, а скорость чтения этого самого огромного файла, и запись в базу с индексами. Типа оптимизация пяти процентов.
У кого как)) у меня критична скорость поиска, поэтому в свое время заморочился и написал такой модуль
Snusmumriken
Ага. Ещё я проповедую тупые дедулькины способы без извращений, чтобы это потом можно было прочитать и понять без спецобразования ))
Snusmumriken
А то у меня на работе кто-то фигачил лютый шаблонизатор, работающий с чем-то таким:
[[<html>
<head>...</head>
<body>
<?for i = 1, 100 do?>
<div><?i?></div>
<?end?>
</body>
</html>]]
И в коде этого шаблонизатора без поллитры не разберёшься за неделю, хотя кода там немного, и весь на gsub'ах и одном loadstring'е. Можно было бы гораздо проще, хоть и незначительно медленнее.
Лепикоршев
Ага. Ещё я проповедую тупые дедулькины способы без извращений, чтобы это потом можно было прочитать и понять без спецобразования ))
Хорошо, когда цена за них невысокая.
Но может оказаться, что "дедов кий способ на коленке" просто не справляется с задачей за адекватное время.
Тогда и наступает время всяческих извращений.
Лепикоршев
Snusmumriken
Хорошо, когда цена за них невысокая.
Но может оказаться, что "дедов кий способ на коленке" просто не справляется с задачей за адекватное время.
Тогда и наступает время всяческих извращений.
Разумеется. Но каждый инструмент типа к месту. И да, было бы неплохо если бы ты накатал подробную статью по данной теме, со схемками и образцами кода ))
> Шаблонизатор
Ну тут же всё написано. Данный конкретный, например, генерирует по данному шаблону такую хтмлу:
[[<html>
<head>...</head>
<body>
<div>1</div>
<div>2</div>
<div>3</div>
...
<div>100</div>
</body>
</html>]]
Соответственно, можно подсунуть табличек с данными, распарсить их прямо в шаблоне и запихнуть на свои места. Или генерить вовсе даже не хтмл, а, например, xml или md или yaml с другим шаблоном (хотя на md и yaml часть тегов может сломаться, надо проверить).
Snusmumriken
И любой инструмент в любом языке для аналогичных целей является шаблонизатором. Простейший вариант для подстановки слов уже встроен в луа:
local template = "$foo, the beautiful $bar!"
local data = {foo = "Hello", bar = "world"}
local dummy = template:gsub("%$(%w+)", data)
print(dummy) --> Hello, the beautiful world!
Но он, разумеется, не умеет в инлайн-код : )
fgntfg
Прост реальные данные обычно примерно вот такие. Хммм.
<some tags>
<unused stuff blabla/>
<nested bullshit>
<tag WE NEED THIS/> <--
<tag AND THIS/> <--
</nested bullshit>
<unused stuff blabla/>
<nested bullshit2>
<tag WE NEED THIS/> <--
<tag AND THIS/> <--
</nested bullshit2>
</some tags>
Только в одну строку, для пущего комфорта ))
Я теперь плачу, ты этого хотел добиться?
Snusmumriken
Лепикоршев
Разумеется. Но каждый инструмент типа к месту. И да, было бы неплохо если бы ты накатал подробную статью по данной теме, со схемками и образцами кода ))
> Шаблонизатор
Ну тут же всё написано. Данный конкретный, например, генерирует по данному шаблону такую хтмлу:
[[<html>
<head>...</head>
<body>
<div>1</div>
<div>2</div>
<div>3</div>
...
<div>100</div>
</body>
</html>]]
Соответственно, можно подсунуть табличек с данными, распарсить их прямо в шаблоне и запихнуть на свои места. Или генерить вовсе даже не хтмл, а, например, xml или md или yaml с другим шаблоном (хотя на md и yaml часть тегов может сломаться, надо проверить).
Можно написать, но тут сперва понять надо, для какой аудитории и в каком объёме.
Подумаю на выходных, что можно выкатить)
По поводу шаблонизаторов - ок, понял.
Но код в одну строку не плох сам по себе, если из каждого шага очевидно, какое произошло преобразование.
Когда они похожи, то лучше так не делать. Твой товарищ не внемлет голосу чистого разума?))
P.s. большие статические шаблонизаторы тоже странное решение - много текста и очень малая область накрываемых задач. Но это имхо чуть более, чем полностью.
Snusmumriken
Статистические шаблонизаторы? А это что за звери?
Я вот сейчас пользуюсь статистическим анализатором кода, но не шаблонизатором ))
Ну и у шаблонизаторов есть целое множество применений. Любая рендерилка языков разметки формально является шаблонизатором, так как трансформирует твой шаблон (например, в md или tex) в различные форматы (например, в html/rtf/pdf).
Snusmumriken
Да, на всякий случай уточняю: я давал тот шаблонизатор просто как пример переусложнённой фигни, которая очень быстро и круто работает, но совершенно нечитаема и неподдерживаема.
> Но код в одну строку не плох сам по себе
Ты про какой код? Про инлайн-вставки в шаблоны, или про реализацию какой-нибудь фигни?
Я не всегда понимаю о чём ты говоришь и почему, поэтому давай сначала прояснять терминологию.
Anonymous
Што делает етот кот
Anonymous
Типа
local strbuf = ""
while true do
local a, b = strbuf:find("regex")
while a and b do
local block
block, strbuf = strbuf:sub(a, b), strbuf:sub(b + 1)
parse_block(block)
a, b = strbuf:find("regex")
end
local chunk = read(2048 * 100000)
if #chunk == 0 then break end
strbuf = strbuf .. chunk
end
Anonymous
Я в луа не силен
Anonymous
Вижу что вроде постепенно затирает то что нашел регекспом