Умеет генерировать код на C и C#.
Детальных сравнений скорости пока не проводил. JSON (в ASCII) парсится со скоростью ~80 мб/сек. Наверно можно и лучше, я оптимизацией еще не занимался как следует.
Кому-нибудь это интересно?
Здравствуйте, WolfHound, Вы писали:
WH>Вот только у меня самый быстрый ПЕГ парсер. WH>А 4 метра в секунду это с построением АСТ. Скорость без построения АСТ никого не волнует. Вообще.
Ты что-то периодически зазнаешься. Во-первых, бабашка на двое сказала что нет реализации быстрее.
Во вторых ты что-то везде себя любимого превозносишь. Хотя как минимум быстрыми или медленными являются конечные парсеры. А в них (по крайней мере для PEG) важную роль играют авторы парсеров. Тот же парсер C# Хардкейсом оптимизировался не раз. Он и спрофайлером сидел, и грамматику факторизировал, и даже TDOP в урезанном виде туда засунул (что, кстати, дално ощутимый прирост скорости, хотя делал он это для упрощения разбора операторов).
Давай все же будем по скромнее. Не будем якать и уж тем более бросаться непроверенными заявлениями типа "самый быстрый".
Да, на Nemerle.Peg можно делать быстрые парсеры. Это факт. Да, в огромной мере — это твоя заслуга. Но то что они самые быстрые и то что это целиком только твое достижение — это, как минимум, преувеличение.
И вообще, к твоим словам зачастую докапываются даже те кто с ними в общем-то согласен. И знаешь почему? Потому что в них какой-то радикально-экстримистский максимализм. Ну, нельзя делить мир только на черные и белые цвета. Есть еще оттенки. И это не только оттенки серого.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tmp4857, Вы писали:
WH>>АСТ строишь или просто матчишь? T>И то, и другое.
АСТ со скоростью 80 метров в секунду?
Что-то слабо верится.
WH>>Об ошибках сообщать умеешь? T>Пока только в очень простой форме.
В какой? Как отличаешь штатный откат от ошибки?
WH>>А восстановление после ошибок есть? T>Что ты имеешь в виду?
Нормальные парсеры должны уметь, встретив ошибку пропустить некоторое количество мусора и продолжить разбор, чтобы можно было сообщить о других ошибках и построить хоть и битое, но АСТ.
Ибо в условиях IDE, когда код перманентно не дописан без этого вообще жить нельзя.
И АСТ хоть какой-нибудь критически важен для автодоплнения, навигации и подсветки кода.
И еще вопрос: С юникодом у тебя как? Ибо если никак, то твой парсер вообще никому не нужен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, hardcase, Вы писали:
H>>Вы знатный извращенец, если хотите JSON парсить регулярками
T>Зачем JSON регулярками? На более простых примерах, конечно. Я пока сравнил только с .NET Regex, и мой парсер порвал его в клочья. Даже если генерить код для .NET
Можешь выложить бинарники, обработанные обфускатором и при каждом запуске выкидывать NagScreen cо списком твоих прав и ограничений + тайм бомбу прикрутить.
ЗЫ. Пока разговор ниочем получается. У нас например Ветренко обещала каждому жителю по вечному двигателю, но так как ее еще не избрали то мы и дальше мучаемся без сего чуда.
Здравствуйте, VladD2, Вы писали:
VD>>>Я вот перечитал и не понял в чем он подставился. V>>В пальцах веером. Очередная попытка кого-то принизить не разобрамшись.
VD>В вопросе обнаружения ошибок ты явно не шаришь. Тут нужно понимать не общие приципы, и тем более GLR, а то какой код генерируется нашим генератором.
А что первично? Яйцо или курица? Не, ну представсьте, что у вас не добровольное товарищество, а работаете за деньги, и вам поставили такую задачу. Вы бы решение подгоняли под задачу или задачу под имеющееся решение, как ты пытаешься делать?
VD>Ты исходишь из своих домыслов. Вот и сейчас ты несешь какой-то бред про восходящий разбор в то время как даже ребенку очевидно, что PEG парсится нисходящим (top-down) разбором.
Ох, ну ты и красавец. А что происходит, когда вы правила инлайните, не судьба была сообразить? Ну просто на бумаге распиши, что произойдет, если по некоему правилу полностью всё заинлайнить (чтобы легче было увидеть). А потом построй кусок ДКА по этому правилу, а потом сравни с построением НКА/ДКА GLR, и посмотри, наконец, почему же там не теряется информация о нетерминалах, хотя всё "заинлайнено" по самое нихочу, т.е. непосредственно до НКА/ДКА.
VD>Соответственно проблем "диагностики в восходящем разборе" у нас нет.
Да все ясно, можно сворачивать. Я поторопился предположить, что вы понимаете проблематику. Думал, оно же очевидно, и стоит только намекнуть на такую вещь как "свертка". Тогда еще один намек: "сдвиг" в LR — это и есть собсно накопление цепочки терминалов, как делает ДКА сканер по мере движения по входному потоку.
VD>У нас есть проблема выявления правила которое обломалось в момент когда текущий индекс имел максимальное значение. Если не делать инлайнинг, то этой проблемы нет. Но если делать, то некоторые "терминальные" правила сливаются и перемешиваются, что мешает диагностики.
Боже, Влад, ну детский сад. Завязывай. Понятное дело, что если сливать все цепочки правил до уровня "плинтуса", т.е. ДКА (как у вас), то исходные правила теряются, если ничего специально не предпринимать. Ты всерьез считаешь, что мы тут уже 10-й раз это обсуждаем и собеседник не может в это воткнуть? Ну и как с вами дальше общаться? Бесконечно отсылать к первому посту в ветке?
VD>Кроме того код сохраняющий эту самую позицию облома тоже кое что стоит. И пихать его в "терминальные" правила дороговато, так как они занимаются "числодроблением".
Тут речь идет об одном if, для отделения "конечного" состояния (состояния на границе корректно разобранной цепочки терминалов/нетерминалов) от промежуточного. Обычный же лексер тоже на каждом шаге проверяет — является ли состояние конечным? Иначе бы парсил бесконечно.
VD>Я не понимаю почему ты в десятый раз несешь какую-то пургу на основании своих домыслов. Попробуй просто понять, что у нас другие алгоритмы и другие подходы, а соответственно и другие проблемы.
Эх, "работники передового края"... Извини, но продолжаю склоняться к тому, что это первый ваш парсер в истории, который с "0-ля" (в отличии от твоего R#). И вы там делаете кое-какие преобразования грамматики, но не способны оказались понять, что же это за преобразования такие у вас получаются.
Все ясно, можно взять паузу, потом вернемся, коль желание будет. Хотя уверен, теперь справитесь и так, бо теперь даже мне понятно, что именно тебе было не понятно.
VD>Уважаемый! Проблема в том, что ты пытаешься в наших алгоритмах видеть свои!
Логично. Только не свои, а общеизвестные. Достучаться вот не могу.
VD>но и с точки зрения осмысленности сообщений об ошибках. Ведь мало толку от информации, что в точке облома ожидался юникодная буква или число (при разборе идентификатора, например).
Иногда доастаточно. Но ты абсолютно прав, что ориентироваться тут можно только на "положительные" возможные ветки от места ошибки. И очеловечивать тут можно через разъяснение "типовых" ошибок как-нить через в ручную подготовленные таблицы соответствий типовых ситуаций. Только для этого надо вернуться к самому началу, и протянуть информацию о нетерминалах.
Я себе вообще плохо представляю автоматизацию генерации сообщений об ошибках при парсинге по ДКА/НКА. Все, что у нас есть — это возможные положительные ветки. Для примера, у нас же грамматики ЯП не полные парсятся, бо они КЗ по своей природе, а парсим мы КС-подмножество. Т.е. мы парсим синтаксис, а сообщение об ошибке должно опираться на семантику. Отсюда пляски с кастомизацией сообщений об ошибках — обязательная часть балета.
V>>У меня хранилось в итоге в узлах/состояниях автомата (список списков правил-родителей). Потеряться ничего не могло. Сами целевые нетерминалы — статические данные. Сослаться на них откуда угодно несложно.
VD>Блин. Ну, нет там никаких узлов. Нету! Там код.
Это понятно. Непонятно, почему нельзя нагенерить статических данных, описывающих таги нетерминалов, и ссылаться на них из кода? Можно завести некий контекст парсинга, где по каждому псевдо-конечному состоянию (по "свертке" или ее аналогу, когда вы ее наконец сделаете) можно выставлять текущий контекст. Дополнительная стоимость — одно присвоение ссылки на статические данные раз в несколько символов исходного потока.
VD>Конечно, конечно. Но ни одного шустрого пока свету не предявлено. Наверно их скрывают в закромах противопригарных решений .
Дык, не пользовался бы народ. Или все дураки? Реально, техника откатов во многих сценариях наихудшая. А ее лечение, мемоизация, с таким требованиями к памяти как в Пакрате — не катит для длинных входных цепочек, по нескольку мег. Там нужны т.н. "оперативные" парсеры, которые однократно проходят по цепочке данных произвольной длины.
V>>В одном из применений мне парсеры с откатами не подходили вообще. Представь, несколькомегабайтный документ имеет неоднозначность, которая ресолвится лишь на последних его символах, угу.
VD>Ага. Если не знаешь про мемоизацию, то можно кормить себя и такими сказками.
Влад, ну как не знать с такой рекламой от тебя?
Ты мне память прикинь хотя бы для цепочки в 1 мег. А потом представь, что это серверное приложение, и оно многие десятки запросов одновременно обслуживает. Ну и плюс, мы и так для данной грамматики имеем O(n) по быстродействию, нафига тратить лишнюю память?
И потом, ты не правильно понял. Не правила в конце различаются, а цепочки. Правила асболютно разные, уникальные, т.е. твоей мемоизацией можно подтереться. Полностью деление всего потока на нетерминалы переиначивается в зависимости от участка, ближе к концу. В GLR общие части правил, которые можно мемоизировать, просто сливаются в один вариант на данном участке, и эта общая часть протягивается одним экземпляром ДКА. Потрать 5 мин хотя бы на Вики: http://ru.wikipedia.org/wiki/GLR-%D0%BF%D0%B0%D1%80%D1%81%D0%B5%D1%80
VD>Не малая стоимость, в общем-то. В прочем, теоретических рассуждений можно построить много. Ты тут уже не раз хвалил свой парсер. Давай проведем простой эксперемент. Воссоздай парсер шарпаа который на выход выдаст АСТ. Сделаем тест в котором сравним полученное АСТ (чтобы видеть, что никто не врет) и сравним скорость разбора.
Нет, мы сделаем что-то попроще для начала. Моя реализация не является генератором парсеров общего назначения, а была заточена под специфику, которую описал. Можно было бы взять какой-нить другой GLR, например DParser, но это будет непонятно, что мы меряем, бо от реализации много чего зависит, не только от алгоритмов.
V>>Теоретически. А фактически — выборка по одной и той же таблице, один и тот же входной поток в кеше, и т.д., а на всё это тратится грубо 90% работы ДКА, и 10% — собственно переход. Т.е. там каждый параллельный вариант грубо требует +10% затрат.
VD>Вот это и есть — теоретически. А практически — тормоза .
Да нет, по замерам два паралельных ДКА, работающих по одной и той же цепочке, не сильно добавляют в сравнении с одним ДКА. Т.к. основная работа не по состояниям ходить, а данные подавать. К тому же, у меня идет преобразование алфавита (рядом описал), и оно однократное (общее) для всех параллельных ДКА.
V>>А если же использовать откат на начало — то это чистое удвоение. А если откатов больше — вообще хана.
VD>Этот вывод тоже от теоретизирования. На практике похожие грамматики имеющие разницу где-то в хвосте обычно состоят из общих подправил. А результат их разбора кэшируется. Так что когда пойдет повторный разбор, то его не будет, а результаты будут взяты из кэша.
Коэффициент размера памяти для кеширования от длины цепочки какой?
VD>Любой КА плохо расширяем. Даже то что у тебя отдельный лексер — это уже усложнение расширяемости.
Есть безлексерные и именно они расширяемые. НКА расширяемы таки без малейших проблем, на то они и НКА. Не зря его строят по регулярным выражениям, например, бо там кажде новое распаршенное выражение именно что расширяет "накопленный" на каждый текущий момент НКА.
VD>Вот тебе задачка из реальной жизни. Есть язык — Nemerle. Он парсит входной поток и если обнаруживает открытие пространства имен, то импортирует новые правила (описанные в виде макросов). Ну, и что на ходу будешь перестраивать свои НКА? А что если экспонента получится?
НКА не перестраиваются, а достраиваются. И та же версионность, что в AB-дереве, вполне организуема. НКА — это же модульность. Каждый отдельный переход может вести в свой модуль.
VD>А НКА — это еще и приговор производительности. И я тогда вообще не понимаю о каких таблицах ты там говоришь, если у тебя НКА.
Дык, НКА тоже имеют табличную технику реализации. Там всей разницы, что по каждому нетерминалу у нас может быть не одно следующее состояние, а более одного. Т.е. происходит fork. При этом, что характерно, обычно идет "динамическое" равновесие. Новые ветки создаются, старые отмирают. На 99% участков в реальных данных вообще идет одна ветка, т.е. эти участки пробегаются как ДКА. Тормоза в рассматриваемых мною GLR исключительно были в постоянном динамическом выделении/освобождении памяти для каждого узла дерева разбора. Даже, если оно на GC. Я лишь только за счет стека переиспользуемых объектов ускорил начальный вариант более чем в два раза для дотнета. Там же смешные затраты на каждый шаг (переход по каждому из ДКА, их обычно 1-3 идет в параллель, по крайней мере в моих сценариях), и вся механика вокруг единичного шага начинает влиять на общую производительность.
VD>Весь кайф PEG-а заключается в том, что он идеологически очень хорошо расширяется. Каждое правило по сути отдельный парсер. Для динамического расширения нам всего лишь надо сделать правило приоритетного выбора массивом и тупо дергать подправила из него.
Ну? А массив переходов в НКА должен быть не расширяем, что ли? Я уже говорил, что мне не нравится в ПЕГ. Невозможно по правилам, содержащим приоритетность, вывести св-в грамматики.
Ну и опять же, я вас не призывал сменить технику своего парсера, а обратил на вполне конкретный маленький такой сценарий инлайна. И сказал, на что он похож. И как с этим борются.
V>>Для начала было бы неплохо на чем-нить попроще.
VD>По проще тебе же не выгодно будет.
Мне выгода нужна по как можно меньшим временным затратам на наши игры. Это же все интереса ради, более не для чего. В конкретном применения я взял максимально подходящую технику. Сейчас всего лишь любопытно пройтись по более-менее общим задачам.
VD>Да и неинтересно это. Реальные применения — это же языки программирования. VD>Именно для них писать парсеры вручную тяжело. И именно при их создании получаются весьма неприятные эффекты в грамматиках (просто потому, что сложность велика и разложить все по полочкам создатель грамматики не может).
Дык, я от того и привел GLR, что ему пох какая грамматика. И не обязательно воспроизводить всю грамматику для тестов, что за максимализм? Можно взять конкретный небольшой кусок, который не приводится, скажем в LL(1), и гонять на нем.
VD>В прочем, можешь для начала тот же Джейсон повторить.
Я тоже уже подумал, в выходные покумекаю, как его прикрутить.
V>>Сколько времени заняла разработка у вас этой грамматики до текущего варианта?
VD>Неделю времени неподготовленного человека.
Вот, дофига, если честно. Больше, чем пока могу себе позволить. Мне же ее перелопачивать для своего парсера придется, бо там по минимуму и со спецификой.
V>>И вообще, смысл предлагать тягаться на эксперименте, стоимостью в несколько рабочих дней оппонента? Чтобы заранее получить отказ? Надо брать что-то более реальное. А потом смотреть, есть ли смысл тягаться дальше.
VD>Нет смысла тягаться на синтетике. Такие тесты ничего не покажут. Мы сделали парсер C# в основном с целью отладки технологий PegGrammar.
VD>Если ты считаешь свой генератор парсеров коммерческим продуктом высокого качества, то тебе самому будет не лишним иметь хороший демонстрационный пример этого самого качества.
Заказной. Качество понравилось. С задачей ускорения разбора и линковки EDI док-тов справился. В среднем прирост был в 3-10 раз от их "самописного" варианта. Правда, как всегда без NDA не обошлось.
VD>Плюс ты сможешь не на словах, а на деле доказать применимость GLR, что будет несомненно интересно в научных кругах.
Да он обжеван тысячекратно. Где он плох, а где хорошо — известно и так. Любые его обсуждения начинаются с примерно таких слов "на большинстве грамматик он имеет быстродействие O(n)". Но засада в том, что на худшем случае у него быстродейтсвие, как у Эрли. В общем, ничего нового тут не откроешь. Он специфичный и ОЧЕНЬ хорош для одних сценариев и крайне плох для других. Бесплатного сыра не бывает.
VD>Твои же некомпетентные советы только раздражают (или веселят). Мы же те советуем тебе как оптимизировать или развивать твой GLR-парсер?
Чего там развивать? Две недели на разработку, две недели на профайлинг, и проект закрыт.
VD>А то ты говоришь о том, что Вольфхаунд гнет пальцы, а сам со стороны выглядишь не лучше.
Ну, в отличие от, я не делаю мину непонятной сакральности исследователя неведомого. И даю ссылки на открытые вещи. А то, что меня порой раздражает ваше непонимание, да еще усугубляемое тем, что это непонимание имеет природу снисходительного отношения к техническим предложениям оппонентов — это ожидаемо. То, что среди коллег требует одной итерации, здесь жуется по 10-му кругу. Лишь потому, что у тебя и твоего напарника все окружающие априори ламеры. Конечно, начинает доставлять.
Почитал я сие "произведение". Впечатление тягостное, угу. Ни малейшего понятия о предмете. Я понимаю, что ты к программированию малость боком, и постоянно делаю на это скидку, но в упор не понимаю, откуда такое желание месить оппонентов с г-ном, размахивать лозунгами и стараться всех перекричать? Лучше бы аккуратно сходил по ссылкам, а подкрепившись, внимательней посмотрел бы на ваш собственный код. Потому как на сегодня ты не до конца понимаешь, как этот ваш код работает. И даже после неоднократных тыканий носом в очевидные вещи, так и не понял, какие преобразования кустов графов вы совершаете при вашем т.н. "инлайнинге".
Ты ошибся в каждом предложении в этом огромном посте. Пока мне не надоест, я на кое-что отвечу. Не на всё, извини, т.к. много повторений, флуда, ухода от темы и откровенной истерики.
VD>ДКА Вольфхаунд генерирует исключительно для оптимизации листовых правил (в твоем лексиконе называемых "терминалами") и исключительно когда в них нет рекурсии.
Ты ошибся. Не только листовых. Да, оно начинается с листовых, но может "свернуться" на несколько уровней вверх. Смотря как карты лягут.
И кстати, рекурсивность грамматики не означает, что она не регулярная. Регулярная грамматика — это такая КС грамматика, которая растет за счет терминалов либо только вправо, либо только влево, потому и называется регулярной, в отличие от растущей в любую сторону КС. Так что, рекурсия вполне допустима, но только одного вида. Кстати, этот момент тоже можно доработать в коде, тем более, что праворекурсивные регулярные правила имеют однозначное отображение на леворекурсивные. Да, оптимизатор заметно распухнет. Собственно, именно это и критиковалось в продемонстрированном коде — смешение диспетчеризации и несвязанных алгоритмов оптимизации. Каждый из которых по мере развития может усложняться, меняться, вы может захотите в месте диспетчеризации выбрать разные в зависимости от условной компиляции для сравнения, и т.д., в общем, тела этих алгоритмов вовсе необязательно было сливать в "общую кучу".
VD>Так что получается там конечный автомат.
Конечные автоматы разные бывают. Я не зря обращал твое внимание на отличие автомата для LL(1) и автомата для сканера или LR. Но еще вернемся.
VD>PEG при этом нарушается не сильно.
Изюминка PEG на этом конкретном "заинлайненом" узле испаряется. Не нужна. Регулярную грамматику могут разбирать любые парсеры, потому как эта грамматика находится на самом нижнем уровне иерархии грамматик. Тут разумно взять самый простой и самый эффективный алгоритм парсинга, способный восстановить исходную топологию "заинлайненного" куста правил.
VD>GLR не получается вовсе.
Ну и каша в голове... GLR — это не разновидность грамматики, это способ парсинга. А характеристики грамматики "даны сверху". Если по-существу, то GLR полностю покрывает класс КС-грамматик, поэтому про него можно сказать, что он "получается всегда", в отличие от LL(1), PEG и прочих алгоритмов, работающих на ограниченных подклассах КС-грамматик. Но не суть, просто твой способ изложения мыслей доставляет.
VD>Твой GLR даже не начинает работать там где у нас работают ДКА.
ДКА в чистом виде сами по себе не работают в парсинге. Они нужны для управления исполнительными устройствами, разбирающими входную цепочку. Потому что это самый эффективный в программной реализации способ управления. Саму ДКА обслуживает "внешний" по отношению к нему код, который его запускает, ловит выходные сигналы (т.е. ловит факт попадания в конечные состояния, если это автомат Мура), сбрасывает, возвращает лишние символы обратно во входной буфер (в жадном алгоритме, например), потом запускает снова, и т.д. и т.п. Обрати внимание, по одному и тому же ДКА может работать как жадный алгоритм лексера (всегда используемый для ЯП), так и обычный.
Конкретно ваш ДКА при инлайнинге строится как ДКА для управления лексером, только поэтому теряются промежуточные нетерминалы, т.е. вместо иерархии оных он принципиально способен дать лишь самый верхний "незаинлайненнный" нетерминал. Поэтому и предлагается, строить ДКА, но чуть другой, для управления другой схемой. По регулярной грамматике та, другая схема, работает с эффективностью сканера. Тормоза только на конфликтах, но у вас их не будет априори.
VD>Если инлайнинг совпадает с построением ДКА, то все становится еще сложнее, так как тут уже отследить что-то практически невозможно.
Эту задачу решили очень много десятилетий назад. Для заведомо регулярной грамматики покатит LR(0).
VD>С кем? С тобой? Ну, в общем-то с человеком говорящем о восходящем анализе при разборе PEG-грамматик действительно все ясно.
Уффф, зануда.
Заинлайнив целый куст с некоей иерархией и "склеив" несколько ДКА, ты теряешь исходную структуру графа. Напомню, что нисходящий разбор — это разбор, совпадающий с нисходящим обходом дерева правил (parser tree), т.е. движение от вершины с рекурсивным перебором узлов дерева вниз и откатами из неудачных попыток. Сам перебор нисходящих узлов происходит на нетерминалах, т.к. в нелистовых узлах этого дерева по-определению могут находиться только нетерминалы. Т.е. если у вас, после преобразования некоего куста исходного дерева, теряются нетерминалы и вместо дерева остается пространственный граф на терминалах (граф ДКА), то какой там может быть в ж-пу нисходящий разбор? В общем, мы теперь можем лишь поглощать терминалы и продуцировать из них нетерминалы. Чтобы восстановить кусок дерева обратно, нужно добавить лишь одну операцию из восходящего разбора, которая выполняется в состояниях, эквивалентным конечным в ДКА от лексера.
Сорри за ликбез, но если гора не идет к Магомету, надо что-то делать.
Итак, задача:
— в результате подстановок обнаруживается, что некий куст правил из parser tree представляет из себя регулярное подмножество (повторю: вы пока находите неполное подмножество, туда можно включать рекурсивные и взаимно-рекурсивные правила, растущие в одном направлении за счет терминалов. Облом опять смотреть тот код, но насколько я помню, сейчас включаются только растущие вправо).
— принимается решение всё это подмножество реализовать в "отдельном парсере" регулярной грамматики.
— найти решение восстановить иерархию исходного куста в процессе работы этого "отдельного парсера".
Ответ:
Упрощенный LR-анализ. По мере хождения по ДКА он восстановит исходный граф. Суть упрощения — в откидывании веток алгоритма, обыгрывающих конфликты свертка-свертка и сдвиг-свертка. Почему так? — парсер будет строиться по заведомо безконфликтной грамматике (она регулярная). Вот тут наши коллеги когда-то парой слов об похожем случае перекидывались: http://www.rsdn.ru/forum/alg/2855264.aspx
Я также набрел на похожесть в процессе реализации GLR, т.к. он реализуется как парсер по НКА (т.е. как семейство ДКА), и позволяет по той же самой причине каждый из этих парсеров по ДКА выполнять по упрощенной схеме.
Хотя, чтобы не забивать себе сразу голову — фиг с ней с упрощенной реализацией!!! Берите как пример любую реализацию, просто несколько веток алгоритма никогда не будут вызываться.
Справедливости ради, если бы сохранили направляющие символы, то можно было бы упорядочить разбор как нисходящий LL(*), но... он тут overdesign, усложнение процесса парсинга на ровном месте (хоть его легче построить), худшее из решений и т.д., ибо регулярная грамматика этого не требует.
VD>Ты поторопился предположить, что ты понимаешь то о чем говоришь. Более того ты тут все время упрекаешь Вольфхаунда в том, что он слишком резок в высказываниях и задевает других (что в общем-то не далеко от истины), но сам сейчас делаешь тоже самое.
Только в общении с тобой. Ибо ты мастер провокаций. Твой слог полон "изяществ", однако. Да, с общечеловеческих позиций это меня не оправдывает, понятное дело, ибо никогда не стоит уподобляться...но в нашем "междусобойчике" мне твой стиль почему-то развязывает руки...
VD>Ты мало того что по полной программе облажался и назвал белое черным, так еще имеешь наглость беспардонного хамить в стиле выше процитированного предложения.
А как ты вообще хотел вести технические споры? Тебе дают ссылки, обсуждают похожие случаи, делятся опытом. Но тебе в одно ухо влетает, в другое вылетает. Я не вижу желания понять собеседника. Мы уже 4-й пост не можем продраться сквозь уровень 0 — где тут восходящий, а где нисходящий разбор, что из себя представляет парсинг по графам КА, и какие разновидности этого парсинга бывают. Мы топчемся на месте. И ты периодически срываешься на ликбез такого же 0-го уровня, хотя никто не заказывал. Это откровенно ламерский, позорный уровень обсуждения, дискредитирующий всех в него вовлеченных. Я не вижу динамики, присущей нормальному техническому обсуждению. В каждой итерации, после очередного дележа информацией и взятия таймаута на обдумывание, собеседники должны возвращаться все более и более подкованными. По крайней мере, хотя бы освежить материал в памяти, бо голова не мусорный ящик, подробности могут забываться. Но фиг там, мы топчемся на месте, исключительно из-за тебя. И профанируем тем самым цели обсуждения. Хотя, с Вольфхаундом любезностями тоже не забываем обмениваться (неплохой у тебя "ученик" вышел), но там хоть какое-то поступательное движение. Он то сообщит что-то полезное из подробностей (хоть и на понтах), то отреагирует на информацию оппонента. Хотя бы в стиле "посмотрю" или "не интересует", т.е. хотя бы видно понимание. А ты уперся не пойми во что. Я прочитал пост дважды, так и не смог выделить, с чем именно ты споришь. Бо ровно 0 аргументов. Вся писанина отдает каким-то банальным раздражением студента, которому препод "плохо объясняет". Но я выдал вообще всю информацию, которую было можно выдать. Следующим шагом будет копирование сюда глав из книг по всему упомянутому, но я этого делать не буду.
VD>А ты не думай. Ты спрашивай. Тогда не будешь выглядеть полным ламером, как сейчас. Никаких "сверток" там нет. ДКА используется по прямому назначению, чтобы ускорять парсинг вот таких вот фрагментов:
Тю, блин. Чем интересен класс регулярных грамматик написано в первых строчках любого учебника по грамматикам. И я знаю, что никаких сверток у вас там нет. Я спрашиваю — почему у вас там нет сверток или других аналогичных действий? Вам не нужно исходное дерево грамматики? Из примерно десятка твоих постов вокруг этой темы выходит, что оно "нужно, но не всегда". Сорри, это очередной детский сад. Нельзя быть чуть-чуть беременным. Или алгоритм умеет восстанавливать исходный parser-tree, и ты пользуешься результатом "когда нужно", либо алгоритм не умеет, и ты не пользуешься этим никогда (как обстоят дела на сегодня).
V>>Тогда еще один намек: "сдвиг" в LR — это и есть собсно накопление цепочки терминалов, как делает ДКА сканер по мере движения по входному потоку.
VD>Эй, умник! Остынь. Нет никаких накоплений цепочек терминалов. Нет даже самих цепочек. Есть тупой рекурсивный спуск и много разных оптимизаций. ДКА используются только там где они способны обогнать перебор.
Ну и где мне взять эпитеты для описания глубины демонстрируемого невежества?
Нельзя изучать какую-то область "кусками". Если ты уже так давно увлекся темой парсеров, то эту область надо рыть сплошняком. Хотя бы для того, чтобы не изобретать велосипедов в различных сценариях, и понимать терминологию собеседника. "Нет накоплений цепочек терминалов" — это шедевр однако. Накопление — это необязательно "копирование/складирование". Почти всегда оно сводится к оперированию метками начала и конца текущей разбираемой цепочки в буфере, но этот целевой диапазон символов именно что накапливается по мере разбора.
VD>И это далеко не частый случай. Вот на приведенном выше фрагменте ДКА рулит.
ДКА вообще рулит, не только на этом примере. Максимальное избавление от рекурсивного обхода рулит само по себе, бо рекурсивный обход дорогой, даже который без откатов.
VD>При этом даже семантика PEG нарушается, так как начинает работать правило, что кто длиннее тот и прав. "строки" тупо разворачиваются в дерево if-ов и goto.\
Пффф... Правило "само по себе" не начинает работать. Ты лишь упомянул один из алгоритмов сканера по ДКА. Да, для ЯП используют именно самую длинную цепочку, поэтому там есть еще откат на последнее обнаруженное конечное состояние. А упомянутое тобой "дерево" switch/case/goto — вообще к теме отношения не имеет. Это всего-навсего один из способов эмуляции работы ДКА. Попроси Вольфхаунда, он тебе покажет еще минимум 3-4 способа. Все эти техники выполнения ДКА равноправны и ортогональны обсуждаемому.
VD>А вот для чего-то большего ДКА не применяются, ибо это не гибко и не дает реального ускорения.
"Реальное ускорение" дает оптимальный выбор техники парсинга, соответствующий св-вам обрабатываемых данных. Надо просто понимать, какой алгоримт куда лезет. GLR хорош для грамматик с малой неоднозначностью и особенно хорош, когда при такой грамматике сами данные имеют относительно большую длину, но малую глубину. Применять в таких случаях LL-техники — это нубство, хотя они хорошо работают на современных ЯП (временно). Твои выкрики, типа "GLR/LALR никому не нужны" от невежества. На GNU Bison за десятилетия сделаны просто миллионы парсеров и парсерочков в мире. И далеко не только под ЯП. Для парсера всяких кастомных конфигов GLR идеален. Для систем электронного документооборота — идеален. Для языков декларации, навроде IDL — идеален. Для парсинга нетривиальных логов — идеальнее не бывает. Для парсинга смешанных языков играмматик, например некий ЯП общего назначения с инлайными всявками из других грамматик, типа SQL, либо же такие "смеси" как AspectJ — идеален, и на его уровне справляются только алгоритма типа Эрли, но они хуже работают и требуют слишком много памяти, что еще 5-7 лет назад программисты не могли себе позволить. Повторю, все сильные и слабые места GLR многократно обжеваны. Надо понимать, где он катит, а где будут наихудшим вариантом. Поэтому замеры на грамматике C# — это одно, а на каком-нить электронном док-те или объемном конфиг-файле — совсем другое.
И вообще, быстродействие алгоримов парсерсинга измеряется в кол-ве посещений узлов внутренних структур на единицу длины входной цепочки + учитывается размер требуемой динамической памяти. Почему так? Потому что абсолютное быстродействие конкретных реализаций одного и того же алгоритма, в зависимости от степени их "вылизанности" и способа управления динамической памятью, может легко отличаться на порядок.
VD>Да пора. Разговаривать с невеждой возомнившей себя гением и правда бесполезно. Разбираться в вопросах реализации ты даже не собираешся, а любой разговор без этого просто бессмысленнен, так как ты рассуждаешь не о том, что есть, а о чем-то придуманном тобой. По сему нужно завязывать. Все равно никто вменяемый и не ангажированный этот сообщение уже не прочтет. А объяснять тебе что-либо бесполезно.
Ты же не объясняешь ничего.
"Там все перемешивается и информация о нетерминалах теряется". Это такое объяснение? Того, как у вас сейчас работает? Я видел. Дык, исправьте. В чем именно ты обнаружил невежество оппонента? Что предложил вам одно из решений? Если тебе не нравится конкретно мое решение — обоснуй. Разложи по полкам. Предложи альтернативы. Но для начала тебе таки придется разобраться в чем состоит мое решение (хотя оно не мое, разумеется, ему уже лет 50). А до тех пор твои злопыхания беспочвенны.
VD>Умник, блин. В листовых правилах (которые у тебя в лексерах торчат) лишний if может преговорить к чертям всю производительность. Это же не лишний if на грамматику, а лишний if почти на любую букву.
Очередная демонстрация невладения темой. В регулярных выражениях или расширенной БНФ (PEG как их разновидность) нетерминалы "крупногранулированы", т.е. конечные состояния ДКА идут далеко не на каждую входную букву. Ну и с той же целью полезно различать в системе правил целевые и промежуточные нетерминалы, чтобы парсер не давал калбеки по промежуточным, и вы могли делать полную подстановку промежуточных нетерминалов в процессе оптимизации системы правил. А не только вот ту эмпирическую по "весу" сложности.
VD>Надо же соображать, что для PEG-а терминалами являются отдельные символы (символы строки). Плюс втыкая этот if ты рушишь другие оптимизации. В 99% случаев всем плевать, что терминальные правила сливаются. Всем важнее скорость их разбора. Но из-за какого-то "одного if-а" это слияние будет невозможно! И в итоге мы получим тормозное говнище вроде GLR, Эрли или Пакрата.
Похоже, ты не понимаешь, на чем именно тормозят эти алгоритмы.
V>>Эх, "работники передового края"... Извини, но продолжаю склоняться к тому, что это первый ваш парсер в истории, который с "0-ля" (в отличии от твоего R#). И вы там делаете кое-какие преобразования грамматики, но не способны оказались понять, что же это за преобразования такие у вас получаются.
VD>Ну, уже достаточно выставил себя полным ламером и от того подобные слова не взывают у окружающих ничего кроме смеха.
Что-то мне подсказывает, что ты заблуждаешься насчет "окружающих". Ты так и не понял смысла PEG, который соотносится с Пакратом не больше, чем соотносится язык программирования и конкретный его компилятор. PEG — это лишь способ задания грамматики и соответствующий их класс. Это не есть ограничения на реализацию, тем более, что за счет отсечений по приоритетности обобщенный парсер PEG — модульный, не накладывающий ограничений на способ реализации каждого "модуля".
VD>Пойми разница между нами с тобой не большая. Мы просто не обсуждаем твою работу, так как не видели ее. Я подозреваю, что то что ты делаешь — это полное очковтирательство и лажа, так как серьезную работу могут делать только серьезные люди, а серьезные люди не несут такой пурги как ты и не высказываются так по хамски о чужом труде даже не разобравшись в деталях. Но утверждать я подобного не буду, так как косвенные улики не могут являются основанием для серьезных суждений. Всегда может быть что и полный трепач способен чего-то добиться.
Ну понятно, т.к. аргументов по предмету спора у нас не было и не ожидается, можно переходить к непосредственному плеванию г-ном. Поздравляю.
Ладно, и так несколько последних постов были лишние. Было бы тебе действительно интересно решить задачу, тебе хватило бы одного намека на возможное решение. И ты бы сказал коллеге спасибо за подсказку. А т.к. очевидная твоя задача — повыступать на форумах, то мы сталкиваемся с классической в IT проблемой останова. Пожалуй, я тут произведу простой abort.
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, adontz, Вы писали:
A>>Я за BSD 3-clause.
T>С аргументацией, пожалуйста Я не очень в курсе, в чем там разница.
Она самая либеральная. Если хочешь денег — тебе не подойдет.
Здравствуйте, tmp4857, Вы писали:
T>Какие? Я слышал только про Trolltech, но у них все не очень весело закончилось
Не волнуйся. У тебя даже не начнётся.
Ибо:
1)Очень маленький рынок.
2)Тонны бесплатных генераторов.
Ты озвереешь даже бесплатную версию сделать хоть сколь-нибудь популярной.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Ты как всегда преувеличиваешь. Он не просто работает, а разбирает реальные исходники. Хардкейс несколько проектов скомпилировал им.
То что на реальных исходниках не проявился соответствующий баг ни о чем не говорит.
Тесты не являются доказательством работоспособности.
VD>Простейший пример разрешение неоднозначности с if/else и if (без else). В одном случае надо выбирать ближний else, в другом — нет. Если ты поставишь if до if/else то if/else у тебя никогда не сматчиться.
Учи правила ПЕГ.
Это кстати еще одно доказательство того что приоритетный выбор ты не понимаешь.
Он вообще крайне не интуитивный.
VD>Их масса. Первая — нет прав на комит. Я могу разве что-ли локальный клон сделать.
И правильно. Нехрен лить в основной репозиторий что попало.
VD>Вторая — разные репозитории. Если мне требуется за одно поправить компилятор, то нужно делать два комита. Это же создает проблему вынимания исходинков и сборки в один клик.
А меня это бесит.
Втянули прототип парсера в сборку и теперь блин не поломай
Даже локально поломать нельзя, ибо компилятор обновлять не получается.
VD>Следующая проблема — дополнительное обучение. минут за 10-20 разобрался с тем, что к чему.
VD>Видимо ты неверную терминологию используешь. Вилка (fork) это, как я понимаю, полное дублирование проекта.
И замечательно.
VD>Искользуется когда кто-то хочет создать свое ответвление. А когда речь идет о совместной работе, то делают ветку (как я понимаю это у них называется брэнч). А для этого нужны права на репозиторий.
Это ты нихрена не понял.
Это представление у тебя сложилось по тому что гуглокод толком не умеет работать с клонами.
Правильный метод это именно работа в своем клоне.
А дальше pull request https://github.com/IgorTkachev/bltoolkit/pulls
Посмотри сколько ИТ уже закрыл...
Если тебе так хочется работать толпой, то можно и толпой.
Добавляешь в свой репозиторий collaborators и все.
Причем в форк (в отличии от гуглокода) тоже можно добавить.
VD>Я в курсе. Только это не очень удобно для реальной работы.
Как видишь кучу народа с этим прекрасно работает.
Более того это очень удобно для "одноразовых" коммитеров.
Они ни кого не спрашивая делают свой форк.
Потом правят что хотят.
А потом в пару кликов отправляют запрос на интеграцию в основной код.
VD>Многие просто не будут начинать что-то делать, если их работу будут выбрасывать.
Если это правки по делу, то никто ничего выбрасывать не будет.
Если правка по делу, но кривая то будут высказаны пожелания по исправлению. И после исправления правка будет принята.
А если там мусор то извините.
VD>А та проблема о которой ты говоришь исходила из того что Ziaw неверно истолковал предназначение личных клонов которые поддерживает гуглькод.
Нет. Это ты не понял.
См выше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Я в курсе приципов работы git, так пользовался Меркури, а у них все примерно одинаково. VD>Но чтобы делать push все равно нужно иметь права на репозиторий. Или это будут два совершенно разных проекта. Потому когда люди работают над одним проектом, то используют бранчи. Или просто комитят по очереди и сливают изменения. Чем чаще сливаются изменения, тем проще их сливать в будущем.
Бранч и форк в DVCS по сути одно и то же, и там и там делаются разные ветки разработки и там и там их потом можно слить. На гитхабе есть штатные механизмы сделать пулреквест в проект из форка. Хозяин проекта пулит к себе в репо изменения из пулреквеста.
Здравствуйте, Klatu, Вы писали:
V>>В динамике парсеры строятся по описаниям, да еще кое-что захардкожено, с целью исключения виртуальных вызовов в калбэках.
K>Вроде все слова знакомые, а в осмысленное предложение никак не связываются
Перевожу на русский — у него все в теории. Он решал похожие задачи и знаком с теорией LR-парсеров. От того делает далеко идущие выводы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Поэтому с подачей данных тоже бороться пришлось.
Достаточно обычного упреждающего чтения. Не вижу особой проблемы.
V>А "захардкожено" потому, что стоимость обработки результата заметно влияет на общую производительность, поэтому я избавлялся от виртуальных вызовов где только можно, т.е. интерфейс парсера вышел не абстрактным, а завязанным на конкретные прикладные типы — клиенты.
Виртуальные вызовы? OMG
V>Блин, сюда в день час потратишь, и то дофига. А это работа на несколько дней. Сначала надо узнать на чем-то несложном, будет ли смысл, после всех операций по убиранию хардкода.
За "несколько дней" можно написать парсер C вообще с нуля и полностью вручную.
PS В общем, очень хотелось бы посмотреть на реальный пример и его производительность в реальной задаче. Иначе это всё выглядит чистейшим пустозвонством.
Здравствуйте, Klatu, Вы писали:
V>>Какие именно цифры смутили?.. чтобы я знал, каковы ожидания.
K>Просто ты много и с большим апломбом критикуешь остальных, а свой код показывать не желаешь.
Я уж подумал, что не понравилась сотня мег/сек на ДКА-лексере. Это проверить самому 20 мин.
K>Некрасиво выглядит.
Хм. Никто не просил тыкать нам в лицо некий код из открытого проекта, как доказательство собственной "крутости". Мне думается, что среди коллег сие не принято. По крайней мере, везде , где я работал. Вышел типичный epic fail. Да, не у всех в реальных проектах всегда код идеален, тем более, что идеальность кода далеко не на первом месте по приоритетам. Но мы его никому и не тыкаем.
Что касается моего кода, то в избранном полно всяческих сниппетов за разные годы (в "файлах" тоже). Давал коллегам как подсказки/решения.
Ну и пропагандируемую галиматью про размер кода в Немерле я тоже всерьез воспринимать не могу, извини. Понимаешь, иногда размер кода может быть еще на порядки меньше, а результат куда как заметнее: http://www.contextfreeart.org/gallery/view.php?id=2496 Потыкай там еще примеры и соотнеси размер кода с результатом, если любопытно. Чудес не бывает, вопрос в специализации. А способов достижения специализации тоже больше одного, это я к тому, что макросы — лишь один из вариантов. Причем, один из худших, как и все eDSL. Короче, вопрос размера кода не такой однозначный, чтобы обсуждать его на каких-то нелепых понтах, да еще попуская при этом коллег и преподавателей. Кто-то должен был сказать что-то в ответ на все эти наезды.
Здравствуйте, vdimas, Вы писали:
V>Хм. Никто не просил тыкать нам в лицо некий код из открытого проекта, как доказательство собственной "крутости". Мне думается, что среди коллег сие не принято. По крайней мере, везде , где я работал. Вышел типичный epic fail. Да, не у всех в реальных проектах всегда код идеален, тем более, что идеальность кода далеко не на первом месте по приоритетам. Но мы его никому и не тыкаем.
Ты не понял ничего.
Совсем.
Ни моих притензий к преподам.
Ни зачем я показал тот кусок кода.
Ни то что там происходит.
Ни то какие там действительно есть проблемы.
Причем по ходу обсуждения ты крутился как уж на сковородке. Несколько раз сменил тему. Сделал несколько просто эпичных заявлений...
Так что epic fail демонстрируешь здесь ты.
V>Ну и пропагандируемую галиматью про размер кода в Немерле я тоже всерьез воспринимать не могу, извини. Понимаешь, иногда размер кода может быть еще на порядки меньше, а результат куда как заметнее: http://www.contextfreeart.org/gallery/view.php?id=2496
Вот это дествительно галиматья.
Эта игрулька бесполезна чуть более чем полностью.
V>Причем, один из худших, как и все eDSL.
Ох лол. Эпичность данного фейла сложно переоценить.
Я на макросах этот твой contextfreeart могу повторить один в один.
Те код можно будет тупо копипастить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ты не понял ничего. WH>Совсем. WH>Ни моих притензий к преподам. WH>Ни зачем я показал тот кусок кода. WH>Ни то что там происходит.
Что-то написали, но аналитическую модель кода вывести не в состоянии.
WH>Ни то какие там действительно есть проблемы.
Да помню я твои реплики в ответ на то, что вы выбираете регулярное подмножество не полностью, потому что оно типа в вашей реализации не особо-то и влияет. Ну так не делайте этого вообще. Всё-равно никогда не понимал такого подхода на "отъе#ись". Если решили реализовать какую-то задачу — её надо сделать полностью, или не делать вообще, если она ни на что не влияет. Да и заключение насчет "не влияет" — умозрительное. Вы же не пробовали. Некая система правил может быть на 90% регулярной, но твоя реализация этого никак не обнаружит и не позволит выяснить "степень влияния". Так и будет нисходящим перебором шпарить праворекурсивные правила.
WH>Несколько раз сменил тему.
Разве я задавал тему? Я лишь отвечаю на комменты. Иногда возвращаюсь к какой-то теме и разъясняю, если с первого раза непонятно. Лень конечно, но хз с чего ведусь на откровенное хамство.
V>>Ну и пропагандируемую галиматью про размер кода в Немерле я тоже всерьез воспринимать не могу, извини. Понимаешь, иногда размер кода может быть еще на порядки меньше, а результат куда как заметнее: http://www.contextfreeart.org/gallery/view.php?id=2496 WH>Вот это дествительно галиматья. WH>Эта игрулька бесполезна чуть более чем полностью.
Для Немерле?
Народ вовсю пользует для генерации битмапов. Но вопрос был не в прикладной области. Он вообще пох в этом обсуждении.
V>>Причем, один из худших, как и все eDSL. WH>Ох лол. Эпичность данного фейла сложно переоценить. WH>Я на макросах этот твой contextfreeart могу повторить один в один. WH>Те код можно будет тупо копипастить.
Ну клиника же. Варка в собственном соку... Не нужны для этой задачи никакие макросы внутри никакой IDE. Какой-нить прикладной спец в этом случае будет иметь возможность "наломать дров", что всегда и происходит. По ссылке в downloads лежит простейшее, заточенное под конкретную задачу IDE ("блокнот" + 3 кнопки). Там не автокомплит нужен, а мгновенный предпросмотр результата работы. Из опыта складов/бухгалтерий такая же точно история. Никогда не будут популярны склады-бухгалтерии на основе универсального языка и универсальной IDE.
Ты и Влад не понимаете сути подобных аргументов от коллег (а вам их накидали за эти годы просто тонны). Это не против Немерле аргументы, это аргменты против рекламируемого мнения, что универсальный тул заменит все остальные. Никто не отрицает, что у Немерле есть ниша. Даже многие согласны, что она может быть достаточно широка. Но вас же послушать — Немерле должен поглотить все остальные ниши. Вот на скидку и привел примеры, которые никогда не стали бы популярны, будь они завязаны на программирование в макросах на Немерле. И на вижуал-студию тоже, даже экспресс. Не веришь — попробуй пропихнуть тоже самое на Немерле. Удачи.
Здравствуйте, vdimas, Вы писали:
V>Я уж подумал, что не понравилась сотня мег/сек на ДКА-лексере. Это проверить самому 20 мин.
Для лексера это крайне посредственный результат. RE2 выдает порядка гига в секунду.
V>Что касается моего кода, то в избранном полно всяческих сниппетов за разные годы (в "файлах" тоже). Давал коллегам как подсказки/решения.
Меня интересует тема, которая обсуждается конкретно сейчас — парсеры. Ты вдребезги раскритиковал чужое решение, но показать свое упорно отказываешься
V>Кто-то должен был сказать что-то в ответ на все эти наезды.
Пока что ты не сказал ничего, кроме похвальбы и пустозвонства.
Здравствуйте, vdimas, Вы писали:
K>>Некрасиво выглядит.
V>Хм. Никто не просил тыкать нам в лицо некий код из открытого проекта, как доказательство собственной "крутости". Мне думается, что среди коллег сие не принято. По крайней мере, везде , где я работал. Вышел типичный epic fail. Да, не у всех в реальных проектах всегда код идеален, тем более, что идеальность кода далеко не на первом месте по приоритетам. Но мы его никому и не тыкаем...
Такой фонтан в ответ на два слова! Супер!!!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
V>>Хм. Никто не просил тыкать нам в лицо некий код из открытого проекта, как доказательство собственной "крутости". Мне думается, что среди коллег сие не принято. По крайней мере, везде , где я работал. Вышел типичный epic fail. Да, не у всех в реальных проектах всегда код идеален, тем более, что идеальность кода далеко не на первом месте по приоритетам. Но мы его никому и не тыкаем. WH>Ты не понял ничего. WH>Совсем. WH>Ни моих притензий к преподам. WH>Ни зачем я показал тот кусок кода. WH>Ни то что там происходит. WH>Ни то какие там действительно есть проблемы.
Сдается он просто большой и толстый тролль. Его не слушать, а банить надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Почитал я сие "произведение"...
Этот GLR головного мозга и агония ужа на сковородке, хотя и изрядно веселит, но совершенно бесплодна. Разговор с совершенно не компетентным человеком вроде тебя цель которого сделать "хорошую мину при плохой игре" за счет оскорблений оппонентов и несения псевдонаучного бреда вроде "объяснения что алгоритм рекурсивного спуска (который мы используем) — это якобы на самом деле это восходящий анализ" мне не интересен. По сему лично я его прекращаю. Тебе тоже советую. Любое продолжение в том же духе будет воспринято мной как тролление, с твоей стороны, и будет караться соответствующим образом. Так же будет караться любые попытки унизить, оппонента с твой стороны. Так что советую остановиться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>Умеет генерировать код на C и C#. T>Детальных сравнений скорости пока не проводил. JSON (в ASCII) парсится со скоростью ~80 мб/сек. Наверно можно и лучше, я оптимизацией еще не занимался как следует. T>Кому-нибудь это интересно?
Тогда спрашивайте Сам парсер и статья будут в открытом доступе через пару недель.
Заодно приветствуются советы — с чем его лучше сравнить по скорости?
Есть идеи, какую модель лицензирования лучше использовать?
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, alvas, Вы писали:
A>>Интересно.
T>Тогда спрашивайте Сам парсер и статья будут в открытом доступе через пару недель. T>Заодно приветствуются советы — с чем его лучше сравнить по скорости? T>Есть идеи, какую модель лицензирования лучше использовать?
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, alvas, Вы писали:
A>>Интересно.
T>Тогда спрашивайте Сам парсер и статья будут в открытом доступе через пару недель.
Вопрос один. Где исходники?
T>Заодно приветствуются советы — с чем его лучше сравнить по скорости? T>Есть идеи, какую модель лицензирования лучше использовать?
Здравствуйте, ilnar, Вы писали:
I>ну и множество реализаций приведенные тут: http://www.json.org/ в разделах С, С++, С#
Вообще-то я имел в виду генераторы парсеров, а не специализированные ручные парсеры
Сравнение производительности с регулярными выражениями кому-нибудь интересно?
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, alvas, Вы писали:
A>>Вопрос один. Где исходники?
T>Будет, всё будет
Вот когда будут тогда и вопросы появятся
A>>Microsoft Public License (Ms-PL) или BSD License
T>Почему именно эти?
Мое дело предложить. Что вы хотите чтобы ваша лицензия позволяла/не позволяла?
Тогда можно будет возможно и лицензию посоветовать.
В правильно составленном вопросе, как говорится, 50% ответа.
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, ilnar, Вы писали:
I>>ну и множество реализаций приведенные тут: http://www.json.org/ в разделах С, С++, С#
T>Вообще-то я имел в виду генераторы парсеров, а не специализированные ручные парсеры
Можно с Nemerle.Peg сравнить, JSON парсер с построением AST у нас есть.
С рукопашными тоже стоит сравнивать. Иной раз генератор может порвать в клочья рукописные (так как для рукопашной реализации не доступна куча оптимизаций).
T>Сравнение производительности с регулярными выражениями кому-нибудь интересно?
Вы знатный извращенец, если хотите JSON парсить регулярками
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, ilnar, Вы писали:
I>>ну и множество реализаций приведенные тут: http://www.json.org/ в разделах С, С++, С#
T>Вообще-то я имел в виду генераторы парсеров, а не специализированные ручные парсеры
Здравствуйте, tmp4857, Вы писали:
I>>ну и множество реализаций приведенные тут: http://www.json.org/ в разделах С, С++, С# T>Вообще-то я имел в виду генераторы парсеров, а не специализированные ручные парсеры T>Сравнение производительности с регулярными выражениями кому-нибудь интересно?
Здравствуйте, alvas, Вы писали:
A>Вот когда будут тогда и вопросы появятся
Сначала надо решить вопрос с лицензией
A>Мое дело предложить. Что вы хотите чтобы ваша лицензия позволяла/не позволяла? A>Тогда можно будет возможно и лицензию посоветовать. A>В правильно составленном вопросе, как говорится, 50% ответа.
Мое основное пожелание — чтобы для некоммерческих проектов позволять использовать бесплатно, а с коммерческих можно было запросить деньги. Да-да, я знаю, я ужасно корыстен... се ля ви
Здравствуйте, hardcase, Вы писали:
H>Вы знатный извращенец, если хотите JSON парсить регулярками
Зачем JSON регулярками? На более простых примерах, конечно. Я пока сравнил только с .NET Regex, и мой парсер порвал его в клочья. Даже если генерить код для .NET
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, alvas, Вы писали:
A>>Вот когда будут тогда и вопросы появятся
T>Сначала надо решить вопрос с лицензией
A>>Мое дело предложить. Что вы хотите чтобы ваша лицензия позволяла/не позволяла? A>>Тогда можно будет возможно и лицензию посоветовать. A>>В правильно составленном вопросе, как говорится, 50% ответа.
T>Мое основное пожелание — чтобы для некоммерческих проектов позволять использовать бесплатно, а с коммерческих можно было запросить деньги. Да-да, я знаю, я ужасно корыстен... се ля ви
Тогда можно под двойной лицензией. Примеров в интернете куча.
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, hardcase, Вы писали:
H>>Вы знатный извращенец, если хотите JSON парсить регулярками
T>Зачем JSON регулярками? На более простых примерах, конечно. Я пока сравнил только с .NET Regex, и мой парсер порвал его в клочья. Даже если генерить код для .NET
1. Вот и гуд. Тогда и сравнивай с .NET Regex из джейсоном, например.
2. Что есть "порвал его в клочья"? 10% или 10000%?
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, alvas, Вы писали:
A>>Тогда можно под двойной лицензией. Примеров в интернете куча.
T>Какие? Я слышал только про Trolltech, но у них все не очень весело закончилось
Здравствуйте, tmp4857, Вы писали:
T>Здравствуйте, alvas, Вы писали:
A>>1. Вот и гуд. Тогда и сравнивай с .NET Regex из джейсоном, например.
T>Наверняка этот движок не самый лучший.
Ну и гуд. Я как-то с помощью .NET Regex парсил подсветку для RichTextEdit в реалтайме. Понял что это не оптимальный вариант, скажем так. А если твой парсер можно будет использовать для таких целей, то почему бы нет?
A>>2. Что есть "порвал его в клочья"? 10% или 10000%?
T>В разы. Зависит от сложности примера. В целом, чем сложнее паттерн, тем сильнее сливаются регэксы.
Здравствуйте, tmp4857, Вы писали:
A>>2. Что есть "порвал его в клочья"? 10% или 10000%?
T>В разы. Зависит от сложности примера. В целом, чем сложнее паттерн, тем сильнее сливаются регэксы.
Регулярные выражения в .NET никогда не отличались проворностью — НКА всегда сольёт хорошему ДКА.
Здравствуйте, alvas, Вы писали:
T>>С аргументацией, пожалуйста Я не очень в курсе, в чем там разница.
A>Она самая либеральная. Если хочешь денег — тебе не подойдет.
Хм. Брать деньги за генератор парсеров в наше время моветон.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, alvas, Вы писали:
T>>>С аргументацией, пожалуйста Я не очень в курсе, в чем там разница.
A>>Она самая либеральная. Если хочешь денег — тебе не подойдет.
H>Хм. Брать деньги за генератор парсеров в наше время моветон.
Здравствуйте, adontz, Вы писали:
A>Меня интересует скорость работы самого компилятора. Достаточно ли он быстр для интерактивного редактирвоания грамматики?
Зависит от размера грамматики Если она не слишком большая, то должно компилироваться за доли секунды.
Здравствуйте, tmp4857, Вы писали:
T>Детальных сравнений скорости пока не проводил. JSON (в ASCII) парсится со скоростью ~80 мб/сек. Наверно можно и лучше, я оптимизацией еще не занимался как следует.
АСТ строишь или просто матчишь?
Об ошибках сообщать умеешь?
А восстановление после ошибок есть?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Что-то слабо верится.
Есть одна маленькая хитрость
А какая скорость типична, на твой взгляд?
WH>В какой? Как отличаешь штатный откат от ошибки?
Я использовал предельно примитивный способ, но он на удивление хорошо работает Просто запоминаю последнюю достигнутую позицию в потоке, и если разбор в целом фейлится — показываю ее. Примерно так:
К этому надо еще добавить точки отсечки, но у меня пока руки не дошли.
WH>Нормальные парсеры должны уметь, встретив ошибку пропустить некоторое количество мусора и продолжить разбор, чтобы можно было сообщить о других ошибках и построить хоть и битое, но АСТ.
Запланировано, но пока не реализовано.
WH>И еще вопрос: С юникодом у тебя как?
Здравствуйте, tmp4857, Вы писали:
T>Есть одна маленькая хитрость
И что это за хитрость?
Нолик дописал?
Или измерял на примитивной грамматике?
T>Я использовал предельно примитивный способ, но он на удивление хорошо работает Просто запоминаю последнюю достигнутую позицию в потоке, и если разбор в целом фейлится — показываю ее. Примерно так:
Тут еще было бы мягко говоря не плохо сказать что за правила обломились.
Их может быть больше одного...
T>Запланировано, но пока не реализовано.
Это _очень_ веселая задачка... я бы сказал она посложнее всего остального. Причем на много.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, tmp4857, Вы писали:
T>Тогда спрашивайте Сам парсер и статья будут в открытом доступе через пару недель. T>Заодно приветствуются советы — с чем его лучше сравнить по скорости? T>Есть идеи, какую модель лицензирования лучше использовать?
. Только джейсон — это очень простая грамматика. Лучше конечно на C#-грамматике мериться.
Кроме того сравнивать конечно же нужно что-то осязаемое. Просто сматчить грамматику с текстом можно очень быстро. Нужно сравнивать реальную работу. Например построение АСТ. Скажем парсим текст и подсчитываем в нем некоторые элементы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tmp4857, Вы писали:
T>Просто избавился от кое-какой ненужной работы T>Но это надо показывать на конкретном примере. Доделаю альфу — покажу.
Ну а на словах сказать не можешь?
T>Смотря как реализовывать. Если не ударяться в переусложнение, то всё не так страшно.
Ну да... правда работать не будет (или будут ТОРМОЗА). А так да. Ничего страшного.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну а на словах сказать не можешь?
Заниматься домыслами все равно бесполезно. Надо смотреть на реальных примерах.
Пока что меня интересуют только два вопроса — с чем сравнивать в бенче, и под какой лицензией лучше выпустить.
Это если задавить пессимизм и допустить — чисто теоретически — что проект пробьется и будет кому-то нужен.
WH>Ну да... правда работать не будет (или будут ТОРМОЗА). А так да. Ничего страшного.
Будет, и даже быстро. Просто у меня есть еще одна хорошая идея
Здравствуйте, tmp4857, Вы писали:
T>Мое основное пожелание — чтобы для некоммерческих проектов позволять использовать бесплатно, а с коммерческих можно было запросить деньги. Да-да, я знаю, я ужасно корыстен... се ля ви
А кому это интересно если есть бесплатные аналоги?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tmp4857, Вы писали:
A>>Тогда можно под двойной лицензией. Примеров в интернете куча.
T>Какие? Я слышал только про Trolltech, но у них все не очень весело закончилось
GPL. Это и есть то что ты хочешь. Точнее код можно будет использовать и коммерчески, но при этом придется его выкладывать открыто. А если захотят использовать закрыто, то будут покупать отдельную лицензию. Вот только вряд ли кто-то купит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tmp4857, Вы писали:
WH>>Не волнуйся. У тебя даже не начнётся.
T>Ну спасибо на добром слове
Я понимаю, что звучит грустно. Но так оно и есть. Тут масса факторов которые будут препятствовать.
WH>>2)Тонны бесплатных генераторов.
T>Тонны, да все кривые. Я бы не стал делать велосипед, который хуже существующих
Думаю, что ты и половины не видел.
Что за оптимизации ты делаешь? Что за алгоритм используешь? Есть ли мемоизация?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tmp4857, Вы писали:
T>Есть одна маленькая хитрость T>А какая скорость типична, на твой взгляд?
Все зависит от грамматики, качества обработки результата и оптимизаций.
Короче, парсеры ждейсона у нас тоже имеются. Можешь создать аналогичный по функциональности тест и сравнить на реальных данных.
Кстати, джейсоновская грамматика очень проста. Она и на лобовом парсере может быстро работать. Лучше мериться на грамматиках по сложнее. Например, на грамматке C# 4.0. Вот здесь лежит такой парсер в формате пег. Он строит АСТ. Воссоздай его (благо грамматика уже готовая есть). Только так, чтобы он АСТ создавал аналогичное (с тем же количеством веток и той же детализацией). На нем и протестируешь. У нас на нем 80 м/сек. не получается. Только 4. Но это и грамматика сильно более сложная.
T>Я использовал предельно примитивный способ, но он на удивление хорошо работает Просто запоминаю последнюю достигнутую позицию в потоке, и если разбор в целом фейлится — показываю ее. Примерно так: T>
Здравствуйте, tmp4857, Вы писали:
WH>>Или измерял на примитивной грамматике?
T>Я писал, на какой грамматике
А что за странная реакция? Джейсон — это очень примитивная грамматика. Ее без откатов можно парсить.
WH>>Тут еще было бы мягко говоря не плохо сказать что за правила обломились.
T>Да, правило надо тоже запоминать. Спасибо за идею
Не правило, а правила. Одна из проблем заключается в том, что для оптимизации правила надо инлайнить. Но для обработки ошибок это плохо (информация о правилах теряется).
WH>>Это _очень_ веселая задачка... я бы сказал она посложнее всего остального. Причем на много.
T>Смотря как реализовывать. Если не ударяться в переусложнение, то всё не так страшно.
Я тоже не сказал бы что это рокет-сайнс, но все же поработать придется.
ЗЫ
Ты в начале пути. Тебе еще пилить и пилить. Можно очень быстро получить прототип. Но от прототипа до продукта пропасть.
Кстати, а как ты предлагаешь обрабатывать разобранную грамматику? Ну, как то же АСТ построить на базе твоего парсера. Лучше всего приведи маленький но полный пример на C#.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Он весьма шустр.
T>и под какой лицензией лучше выпустить.
На этот вопрос тоже уже отвечали не раз. Всем было бы приятно получить продукт под свободной лицензией вроде BSD. Но ты же хочешь продвать что-то (хотя явно нечего и некому).
Лицензию ты можешь сменить когда угодно и на что угодно. Все равно пользоваться альфами никому не интересно.
T>Это если задавить пессимизм и допустить — чисто теоретически — что проект пробьется и будет кому-то нужен.
Под BSD наверняка кому-то пригодится, если доведешь до ума. Но работы тут еще прорва, судя по твоим словам.
WH>>Ну да... правда работать не будет (или будут ТОРМОЗА). А так да. Ничего страшного.
T>Будет, и даже быстро. Просто у меня есть еще одна хорошая идея
У меня этих идей на 20 лет вперед. Что с того толку? Идеи реализовывать надо. Кропотливо и дотошно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Abidos, Вы писали:
T>>Сделал свой генератор PEG-парсеров, просто для саморазвития
A>Попробуйте сравнить с pegsharp. Я недавно использовал этот генератор для достаточно примитивного языка поисковых запросов и, в общем, остался доволен.
Это быстрым быть не может никак. На каждый чих создание делегатов и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не правило, а правила. Одна из проблем заключается в том, что для оптимизации правила надо инлайнить. Но для обработки ошибок это плохо (информация о правилах теряется).
Это оно в вашей реализации теряется, потому что Wolfhound не сохраняет к каждому оптимизированному правилу (т.е. к каждому вхождению элементов choice/sequence) всю цепочку подстановки исходных. Это легко исправить.
Здравствуйте, VladD2, Вы писали:
VD>GPL. Это и есть то что ты хочешь. Точнее код можно будет использовать и коммерчески, но при этом придется его выкладывать открыто.
С этим есть проблема.. GCC например GPL, но сгенеренный им код GPL не является. Так же и здесь. Сам генератор парсеров в конечный продукт не будет входить.
VD>Вот только вряд ли кто-то купит.
Вполне возможно. Но глупо самому перекрывать себе такую возможность
Здравствуйте, VladD2, Вы писали:
VD>Брать деньги за работу — это во все времена было и будет очень даже здорово. Главное чтобы их дали. Вот во втором я сильно сомневаюсь .
Вот в том и проблема Деньги на развитие никто давать не хочет, а потом жалуются что все программы кривые и тормозные
Здравствуйте, vdimas, Вы писали:
V>Это оно в вашей реализации теряется, потому что Wolfhound не сохраняет к каждому оптимизированному правилу (т.е. к каждому вхождению элементов choice/sequence) всю цепочку подстановки исходных. Это легко исправить.
Ты опять ни слова не понял из того что написано, а делаешь глобальные выводы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Это оно в вашей реализации теряется, потому что Wolfhound не сохраняет к каждому оптимизированному правилу (т.е. к каждому вхождению элементов choice/sequence) всю цепочку подстановки исходных. Это легко исправить.
Не уверен, что ты прав. Дело в том, что список правил вычисляется динамически (если не ошибаюсь).
В общем, тут нужно или код смотреть, или Wolfhound-а спросить.
Wolfhound! Ау!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
V>>Это оно в вашей реализации теряется, потому что Wolfhound не сохраняет к каждому оптимизированному правилу (т.е. к каждому вхождению элементов choice/sequence) всю цепочку подстановки исходных. Это легко исправить. WH>Ты опять ни слова не понял из того что написано, а делаешь глобальные выводы.
Ты лучше по существу ответь. Распиши ситуацию. А то ты, как всегда, экстремально краток в своих высказываниях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
V>>Это оно в вашей реализации теряется, потому что Wolfhound не сохраняет к каждому оптимизированному правилу (т.е. к каждому вхождению элементов choice/sequence) всю цепочку подстановки исходных. Это легко исправить. WH>Ты опять ни слова не понял из того что написано, а делаешь глобальные выводы.
Ды ну тебя, ты от темы постоянно уходишь на обсуждение собеседника. У вас реально так и есть — теряется полная история подстановок. И называть эту банальщину "глабальными выводами"..? Да еще Влад заостряет на этом внимание? Постеснялись бы. Это такой фактически стандартный косяк человека, первый раз берущего эти шашки в руки. А лечится легко, заметь. Дольше обсуждать.
Странные вы ребята, вообще. Сначала ведете речь о том, что у вас "научный край", а когда оппонент именно что "на бумаге" для начала хочет разобраться, о каком "научном крае" идет речь, и чем несколько ваших сугубо практических решений отличаются от того, что он десятки раз делал последние двадцать лет, дык в ответ ссылка на частности, и отмазки, типа "теоретик". ИМХО, ваш текущий код выглядит так, будто кол-во технических экспериментов было минимальным, или он еще на некоей начальной стадии. Ну тогда рано было столь много и столь громко утверждать.
Ну и плюс замечания типа этого:
Только так, чтобы он АСТ создавал аналогичное (с тем же количеством веток и той же детализацией). На нем и протестируешь.
Показывают наглухо непонимание тематики. Конкретно того, где заканчивается ответственность парсера, и начинается прикладная обработка его сигналов. Парсер, который будет выдавать данные лишь в виде своей собственной реализации AST, не особо интересен. Вернее, не интересен вообще на целом классе применений, где ни о каких черепашьих 4MB/сек не может быть и речи, так же как не может быть речи о построении некоей "промежуточной" модели, бо само построение модели отнимает до половины эффективности. Я догадываюсь, что к PEG это вряд ли относится, судя по твоим реакциям, т.е. построение AST на фоне остального происходящего не видно и под микроскопом. Ну тоды скромнее надо быть, в другой раз-то, насчет "переднего края"... PEG хорош своей гибкостью и расширяемостью прямо в рантайм, но вовсе не показателями эффективности. Т.е., его имеет смысл применять в довольно узких областях — где требуется гибкость и не нужна эффективность. Или лень делать факторизацию грамматики, например, а хочется использовать имеющуюся "в лоб".
Здравствуйте, vdimas, Вы писали:
V>Ды ну тебя, ты от темы постоянно уходишь на обсуждение собеседника.
Какой темы? Ты вообще не понял о чем речь.
Речь о сообщения об ошибках генерируемых парсером.
А ты опять про оптимизацию грамматики.
V>У вас реально так и есть — теряется полная история подстановок. И называть эту банальщину "глабальными выводами"..? Да еще Влад заостряет на этом внимание? Постеснялись бы. Это такой фактически стандартный косяк человека, первый раз берущего эти шашки в руки. А лечится легко, заметь. Дольше обсуждать.
При оптимизации она неизбежно теряется.
Всегда!
Я еще не видел ни одного оптимизирующего компилятора который бы ее не терял. Ни одного!
V>что он десятки раз делал последние двадцать лет,
Ой напугал.
Десятки раз...
Двадцать лет...
А несешь пургу.
Асимптотику алгоритмов считать не умеешь. Насчитать N^6 в линейном алгоритме это жесть! Запомни шесть проходов это 6*O(N) оно же O(N), а не O(N^6).
Алгоритмы работы с конечными автоматами не знаешь. Чего стоят твои двадцать лет когда ты не знаешь алгоритмы придуманные 40 лет назад и описанные в куче книг.
Чего стоят твои десятки, раз, когда ты предлагаешь на ровном месте создать кучу геморроя ради ни пойми чего. Нахрена мне что-то делать при оптимизации, если я могу просто оставить исходный АСТ в котором все есть.
Я уж не говорю о том что те оптимизации что я делаю нельзя делать без полного предварительного разбора.
Хоть ты тут пускал пальцы веером что можно но так и не сказал как.
V>ИМХО, ваш текущий код выглядит так, будто кол-во технических экспериментов было минимальным, или он еще на некоей начальной стадии. Ну тогда рано было столь много и столь громко утверждать.
Ну давай. Покажи класс!
Образцово показательный код в студию!
V>Показывают наглухо непонимание тематики. Конкретно того, где заканчивается ответственность парсера, и начинается прикладная обработка его сигналов. Парсер, который будет выдавать данные лишь в виде своей собственной реализации AST, не особо интересен.
Ой лол.
Ты вообще нихрена не понял.
Ты бы хоть посмотрел на реализацию Nemerle.Peg. И как там AST создается.
V>Вернее, не интересен вообще на целом классе применений, где ни о каких черепашьих 4MB/сек не может быть и речи,
Ну во первых покажи мне парсер который на грамматике C#4 хотябы столько дает.
Ну, хоть один.
Только не забудь про АСТ. Без АСТ парсер никому не нужен.
V>так же как не может быть речи о построении некоей "промежуточной" модели, бо само построение модели отнимает до половины эффективности.
Кому нахрен нужен парсер без АСТ?
V>Я догадываюсь, что к PEG это вряд ли относится, судя по твоим реакциям, т.е. построение AST на фоне остального происходящего не видно и под микроскопом.
Ну да... то-то мой парсер всякие там ANTLR'ы рвет как тузик грелку.
V>Или лень делать факторизацию грамматики, например, а хочется использовать имеющуюся "в лоб".
Ну давай. Засунь грамматику C#4 в LL(1)...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
T>>Вполне возможно. Но глупо самому перекрывать себе такую возможность VD>Ты волен менять лицензии хоть сто раз на дню.
Лицензия на уже опубликованный код от этого не поменяется.
Здравствуйте, tmp4857, Вы писали:
VD>>Что за оптимизации ты делаешь? Что за алгоритм используешь? Есть ли мемоизация?
T>Пока практически никаких. T>Пока нет
Чтобы создать работающий генератор без оптимизаций у Вольфхаунда ушла где-то неделе или две (и это при том, что он в макросах не особо разбирался на то время). А на оптимизации еще год. В прочем, он не особо торопился.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tmp4857, Вы писали:
VD>>Под BSD наверняка кому-то пригодится, если доведешь до ума.
T>Почему именно BSD? Чем она отличается от упомянутой MS-PL и других лицензий?
Она (новая версия, трехстроковая) проще. В прочем MS-PL тоже пойдет. По смыслу они очень похожи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Его код пока что ни куда не годен.
Ну это ты зря Парсеры вполне работоспособные. Парсер PEG и парсер шаблонов уже давно бутятся.
Надо только допилить сишную версию до полного функционала и причесать некоторые вещи.
Здравствуйте, tmp4857, Вы писали:
T>Ну это ты зря Парсеры вполне работоспособные. Парсер PEG и парсер шаблонов уже давно бутятся.
Если у тебя там нет оптимизаций, то первая нетривиальная грамматика поставит твой парсер на колени.
T>Надо только допилить сишную версию до полного функционала и причесать некоторые вещи.
Ну, ну. Сишность тебе алгоритмическую сложность не устранит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Какой темы? Ты вообще не понял о чем речь. WH>Речь о сообщения об ошибках генерируемых парсером. WH>А ты опять про оптимизацию грамматики.
Ну, ну, в общем-то вещи связанные. Ты же инлайнишь правила и от того проблема и просходит. Может правда информацию можно как-то протащить?
Потом проблема ведь есть. И она серьезна. Когда правило инлайнится сообщение об ошибке получается полным бредом. Я забыл поставить ";", а мне вываливается 99 правил которые могли бы быть. Это ведь неверное поведение.
WH>При оптимизации она неизбежно теряется. WH>Всегда! WH>Я еще не видел ни одного оптимизирующего компилятора который бы ее не терял. WH>Ни одного!
Дык хорошо бы было подумать как все же обеспечить качественный вывод сообщений и при этом не убить оптимизацию. Может что-то и придумали бы.
WH>Чего стоят твои десятки, раз, когда ты предлагаешь на ровном месте создать кучу геморроя ради ни пойми чего. Нахрена мне что-то делать при оптимизации, если я могу просто оставить исходный АСТ в котором все есть.
Если не ошибаюсь нам с этого мало толку, так как нам надо знать какое правило обломалось. Заинлайненое правило тупо не имеет кода отмечающего их облом. Потому мы и теряем информацию.
Вопрос в том нельзя ли сделать "легкий" код пометки и для инланеных правил?
Ну, или сгенерировать две версии. Одну с инлайнингом, а другую без. Тогда при обнаружении облома в неком более большом правиле его моно было бы запустить еще раз, но уже в неинлайненном виде для сбора точной информации об обломах.
V>>ИМХО, ваш текущий код выглядит так, будто кол-во технических экспериментов было минимальным, или он еще на некоей начальной стадии. Ну тогда рано было столь много и столь громко утверждать. WH>Ну давай. Покажи класс! WH>Образцово показательный код в студию!
+1
Да уж. Теоретиков-трепачей у нас очень много.
V>>Вернее, не интересен вообще на целом классе применений, где ни о каких черепашьих 4MB/сек не может быть и речи, WH>Ну во первых покажи мне парсер который на грамматике C#4 хотябы столько дает. WH>Ну, хоть один.
Ну, плюсовый, рукописный парсер Майкрософта дает явно не меньше .
V>>Или лень делать факторизацию грамматики, например, а хочется использовать имеющуюся "в лоб". WH>Ну давай. Засунь грамматику C#4 в LL(1)...
Она на 99% и есть LL(1). Проблема в том, что оставшийся процент требует некислой логики разрешения неоднозначностей которая в LL(х) никак не вписывается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, tmp4857, Вы писали:
VD>>Если у тебя там нет оптимизаций, то первая нетривиальная грамматика поставит твой парсер на колени.
T>Какая, например?
Например, вот эта. И эта еще ничего. Там многие правила подвергнуты левой факторизации. А если этого не делать, то твой парсер просто ляжет, а наш будет вполне шустренько там работать.
А вообще, достаточно одного правила экспоненциального. Поищи, в этом форуме было обсуждение по этому поводу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Например, вот эта. И эта еще ничего. Там многие правила подвергнуты левой факторизации. А если этого не делать, то твой парсер просто ляжет, а наш будет вполне шустренько там работать.
Посмотрим
VD>А вообще, достаточно одного правила экспоненциального. Поищи, в этом форуме было обсуждение по этому поводу.
Ну это чистая патология. Надо еще очень постараться, чтобы этого добиться.
Здравствуйте, VladD2, Вы писали:
VD>Ну, ну, в общем-то вещи связанные. Ты же инлайнишь правила и от того проблема и просходит. Может правда информацию можно как-то протащить?
Он вообще не о том говорит.
Он предлагает:
Оптимизировать саму грамматику по мере ее разбора! Слить с парсером и построением АСТ!
При этом городить какие-то дополнительные структуры данных для того чтобы сохранять информацию о том где какие правила описаны в исходнике.
Короче бред полнейший.
VD>Ну, плюсовый, рукописный парсер Майкрософта дает явно не меньше .
Если бы у меня был хороший бекенд в котором я бы смог гибко настраивать генерируемый код, то парсер разогнался бы очень сильно.
К сожалению .НЕТ унылое говно.
А все остальное еще хуже.
VD>Она на 99% и есть LL(1). Проблема в том, что оставшийся процент требует некислой логики разрешения неоднозначностей которая в LL(х) никак не вписывается.
А теперь попробуй объяснить это пациенту.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, tmp4857, Вы писали:
VD>>А вообще, достаточно одного правила экспоненциального. Поищи, в этом форуме было обсуждение по этому поводу.
T>Ну это чистая патология. Надо еще очень постараться, чтобы этого добиться.
Этого элементарно добьется первый же не очень искушенный в грамматиках и парсерах пользователь. Ну, или искушенный когда начнет создавать сложный парсер.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>Ну, ну, в общем-то вещи связанные. Ты же инлайнишь правила и от того проблема и просходит. Может правда информацию можно как-то протащить? WH>Он вообще не о том говорит. WH>Он предлагает: WH>Оптимизировать саму грамматику по мере ее разбора! Слить с парсером и построением АСТ! WH>При этом городить какие-то дополнительные структуры данных для того чтобы сохранять информацию о том где какие правила описаны в исходнике.
Я его иначе понял. Как я понял он думает, что информация берется из дерева грамматики (что не верно).
VD>>Ну, плюсовый, рукописный парсер Майкрософта дает явно не меньше . WH>Если бы у меня был хороший бекенд в котором я бы смог гибко настраивать генерируемый код, то парсер разогнался бы очень сильно.
Это уже из серии полохого тонцора и сам знаешь чего.
WH>К сожалению .НЕТ унылое говно.
Ага. Внешний враг найден...
На самом деле и в дотнете есть ансэйф. На крайням можно перйти на указатели. Но это даст линейное ускорение и оно принципиально не будет сильным.
Потенциально грамматику шарпа можно разбирать очень быстро, так как она близка к LL(1). Но боюсь, что для этого придется генерить ДКА вместо приоритетного выбора, а это приговор расширяемости и гибкости.
VD>>Она на 99% и есть LL(1). Проблема в том, что оставшийся процент требует некислой логики разрешения неоднозначностей которая в LL(х) никак не вписывается. WH>А теперь попробуй объяснить это пациенту.
Мне этого делать не интересно. Мне хорошо бы расширяеомость получить и если получится еще немного генерируемые парсеры ускорить, так чтобы для реалтаймного редактирования мегабайтных файлов с запасом хватало.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Этого элементарно добьется первый же не очень искушенный в грамматиках и парсерах пользователь. Ну, или искушенный когда начнет создавать сложный парсер.
Здравствуйте, VladD2, Вы писали:
WH>>Если бы у меня был хороший бекенд в котором я бы смог гибко настраивать генерируемый код, то парсер разогнался бы очень сильно. VD>Это уже из серии полохого тонцора и сам знаешь чего.
Это блин объективная реальность.
Я знаю кучу мест где генерируется откровенно кривой код и с этим в рамках .НЕТ ничего не сделать.
VD>Мне этого делать не интересно. Мне хорошо бы расширяеомость получить и если получится еще немного генерируемые парсеры ускорить, так чтобы для реалтаймного редактирования мегабайтных файлов с запасом хватало.
Я работаю над этим.
Но я форкнул проект, ибо чтобы сделать действительно хорошо придется поломать обратную совместимость.
Причем совсем.
В частности избавиться от приоритетного выбора и перейти на принцип максимальной длинны разбора, сделать нормальную поддержку левой рекурсии и еще много чего.
Здравствуйте, WolfHound, Вы писали:
WH>Но я форкнул проект, ибо чтобы сделать действительно хорошо придется поломать обратную совместимость. WH>Причем совсем. WH>В частности избавиться от приоритетного выбора и перейти на принцип максимальной длинны разбора, сделать нормальную поддержку левой рекурсии и еще много чего.
Тебе конечно виднее. Я бы пережил со старыми подходами. К рому же приоритетный выбор иногда просто необходим для построения логики разбора. Так что в каком-то виде его надо оставить. Можно просто ввести | и /.
WH>Вот сам проект: https://github.com/rampelstinskin/ParserGenerator/commits/master WH>На github ибо меня достал SVN своими тормозами и я хочу посмотреть на git.
Ну, а почему не разместить его в рамках тог же Н2? Там Меркури. Он по быстрее гитхаба будет.
А так у нас код начинает расползаться. Плюс нужно тонну тулов иметь, чтобы его скомпилировать.
WH>Ну и хочется контролировать то что помощники делают. Чтобы вот такого ахтунга больше не было.
А что там такого? Не всем нравится когда рядом с проектом появляются сгенерированные файлы
WH>Использую GitExtensions. Пока всем доволен.
Молодец конечно, но вот помочь тебе уже не удастся, так как лично у меня там никаких прав нет. Плюс чтобы просто скачать код мне нужно еще одну тулу ставить. И изучать все что связано с гитхабом. А ведь только-только к Меркури приспособился.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если уж ты переписываешь все, то логично было бы заменить парсер основанный на токенах, на парсер на базе старого варианта Nemerle.Peg. Код упростился бы в разы. И в нем было бы меньше ошибок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>В частности избавиться от приоритетного выбора и перейти на принцип максимальной длинны разбора,
А ты не боишся, что это приведет к замедлению парсера?
Тогда надо уходить от идеи перебора с откатами и брать идею LL(*) из АНТЛР-а. Но это она основана на генерации ДКА. А они как-то с совместимостью не вяжутся.
И что тогда будет с TDOP? Ты его тоже выкидываешь, или твоя новая идея интегрирует этот алгоритм?
WH>сделать нормальную поддержку левой рекурсии и еще много чего.
Не нужно это. Точнее нужно только для "операторов". Именно для них нужна левая рекурсия. Все остальное само собой описывается в праворекурсивной форме.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
V>>Ды ну тебя, ты от темы постоянно уходишь на обсуждение собеседника. WH>Какой темы? Ты вообще не понял о чем речь. WH>Речь о сообщения об ошибках генерируемых парсером. WH>А ты опять про оптимизацию грамматики. WH>
Ну вот ты и подставился. Перечитай еще раз замечания Влада и потом моё. Только на этот раз не по диагонали.
V>>У вас реально так и есть — теряется полная история подстановок. И называть эту банальщину "глабальными выводами"..? Да еще Влад заостряет на этом внимание? Постеснялись бы. Это такой фактически стандартный косяк человека, первый раз берущего эти шашки в руки. А лечится легко, заметь. Дольше обсуждать. WH>При оптимизации она неизбежно теряется. WH>Всегда! WH>Я еще не видел ни одного оптимизирующего компилятора который бы ее не терял. WH>Ни одного!
Смелое утверждение, однако. Ваше rule.Location — это разве не ссылка на исходное правило? И разве сложно сохранить всю историю подстановок?
Я скажу, откуда у меня столько, скажем так, уверенности в этом деле. Я довольно много возился с разновидностями семейств GLR-парсеров. Они прикольны тем, что на 99% реальных входных данных работают как конечные автоматы. Т.е. да, разветвления там есть, и порой ширина охвата доходит до 20-ти и более, но обычно на очень коротких участках (тупиковые ветви быстро отмирают). Примерно 99% там идет не больше 1-3-х параллельных веток, каждая из которых работает, однако, быстрее даже среднестатистического лексера, который по ДКА (из-за особенностей таблицы переходов низлежащего GLR НКА — из-за сильной разряженности таблицы переходов). Да, обкатывал там оптимизацию нешуточно. Делал автоматом перевод правил из БНФ в НКА. Ты примерно представляешь среднее число подстановок и оптимизаций правил, для полного построения НКА из БНФ? А потом ведь еще идет последующая минимизация НКА (угу, не оговорился!), где тоже протаскивается вся история преобразований исходных правил. А иначе что там парсер будет выдавать в кач-ве своих сигналов и как давать ошибку?
Еще харатерная особенность такая, что в "разогретом" режиме, если использовать буфера под цепочки выводов, то динамическая память не расходуется. А "разогреть" можно и непосредственно перед запуском, то бишь сразу предвыделить буфера (там не много, NlogN в среднем от глубины вложенности реальных выражений, т.е. сотня-другая максимум для ЯВУ, например, или несколько десятков для моего случая с EDI-стандартами)
Единственная динамически выделяемая память была уже за пределами парсера — это непосредственное построение электронного док-та. Т.е., заметь, на каком уже уровне идет борьба за эффективность. На уровне оптимизации выделения памяти из кучи GC, гы-гы. Как сказал, упирался уже непосредственно в эффективность символьного буфера (эти тормозные массивы дотнета!!!), в избавление от лишних копирований, в использовании файлового АПИ ОС напрямую для зачитки в unmanaged буффер и в лексере этого unsafe тоже хватало уже, бо уже играет рояль. Понятное дело, что на 4MB/c лезть в эту оптимизацию смысла нет вообще, это еще не тот порядок цифр.
WH>А несешь пургу. WH>Асимптотику алгоритмов считать не умеешь. Насчитать N^6 в линейном алгоритме это жесть!
Ну не посмотрел на код когда писал это, а в памяти почему-то отложилось, что там тоже запускается рекурсия, т.е. многократно от каждой ячейки вниз по графу.
После твоего замечания посмотрел опять на код, и бодаться не стал, ибо конкретно тут было не с чем, я его ошибочно в памяти "сфотографировал". Ты же почему-то откопал то, с чем я не спорил, но игнорируешь вопросы по существу.
WH>Запомни шесть проходов это 6*O(N) оно же O(N), а не O(N^6).
Да понятно. Если оппонентов считать за идиотов, то и получаются казусы как в первом абзаце.
WH>Алгоритмы работы с конечными автоматами не знаешь. Чего стоят твои двадцать лет когда ты не знаешь алгоритмы придуманные 40 лет назад и описанные в куче книг.
В куче книг ссылка на один тот алгоритм. Учитывая, что отличия "наивного" от "ненаивного" алгоритма минимизации несущественны по эффективности... более того, реально минимизация либо идет как build-step, т.е. ее стоимость не принципиальна, либо в рантайм не делается эта оптимизация вообще, т.к. неминимизированный ДКА работает до 10-20% шустрее минимизированного (проверь, кстати, я уже не первый раз это говорю, по состояниям — неминимизированный, но обязательно минимизированный по входному алфавиту), то мог один из алгоритмов упустить. Причем, зависимость повторяется как в нейтиве, так и в дотнете.
Да, сейчас освежил насчет этого алгоритма. Но я его никогда не программировал, потому не помню. Уверен, лет через 5-7 опять эта подробность забудется, фигли с того? Т.н. "наивный" алгоритм (который Мура) — он в десяток-другой строк. Ну не запоминаю я "формулы", я их вывожу при надобности за минуту. И если что-то не получается — тогда лезу за подсказкой.
GLR я тоже "изобрел" в 97-м и только в 2000-м нарыл в интернете, когда у меня появился нормальный интернет. И то был польщен, что для целого класса грамматик умудрился оптимизировать оригинальный (тоже достаточно "наивный") алгоритм до случая, когда операци "свертка" не нужна, что тоже дает приличный буст быстродействия. До сих пор руки не доходят качественно прошерстить интернет на этот счет — есть ли публикации на эту тему, или все-таки опубликовать под своим именем. Несколько раз искал — пока этой разновидности не видел...
WH>Чего стоят твои десятки, раз, когда ты предлагаешь на ровном месте создать кучу геморроя ради ни пойми чего. Нахрена мне что-то делать при оптимизации, если я могу просто оставить исходный АСТ в котором все есть.
Не думаю, что вместо ссылки на элемент сохранить ссылку на список оных — это rocket science. Да и оптимизация у тебя... громко сказано, между нами девочками. Да, я помню, что ты говорил, что полное раскрытие правил в инлайн уже не дает прироста быстродействия. Скажи, тебя сие не насторожило? Я так считал, что ПЕГ, как и GLR большую часть цепочки "жует" в режиме ДКА, а там лишняя косвенность или пару лишних if в реализации уже заметны. ИМХО, где-то серьезный затык сам по себе, что низкоуровневая механика у вас практически не влияет на быстродействие. Значит, быстродействие вышло не того порядка от требуемого. ДКА даже в дотнете бегает по символам быстрее, чем они способны быть считаны с диска (если только не угробить всё через виртуальные методы IEnumerable). Надо разбираться. Не много-ли откатов, например? Cобираете ли вы статистику по откатам при профилировании парсера и в каком виде? Я собирал статистику по "широте охвата" для GLR (т.к. это паралельный парсер без откатов), по требованиям к памяти и т.д. Добивался фактически нулевых дополнительных издержек, т.е. чтобы вероятность запросить динамическую память была минимальной (в 99% цепочек парсер не требует динамическую память). Может, я бегло смотрел на ваш код, но не увидел кучи профилирующего кода. Ткни, если не прав.
WH>Я уж не говорю о том что те оптимизации что я делаю нельзя делать без полного предварительного разбора. WH>Хоть ты тут пускал пальцы веером что можно но так и не сказал как.
Я тебе намекнул на т.н. forward reference, которые ресолвятся аналогично. Но спорил там лениво, т.к. я ошибся с асимптотикой из-за своей невнимательности (сложно свою работу делать и на бегу чужую просматривать), т.е. вопрос стал НЕПРИНЦИПИАЛЕН. И бодание уже шло только ради бодания. Ну да, грешен. Кстати, можно и продолжить пободаться, если есть желание. Там решение в итоге будет состоять в способе роутинга сигналов вашего парсера грамматики (в макросе который работает) и организации пула forward reference.
V>>ИМХО, ваш текущий код выглядит так, будто кол-во технических экспериментов было минимальным, или он еще на некоей начальной стадии. Ну тогда рано было столь много и столь громко утверждать. WH>Ну давай. Покажи класс! WH>Образцово показательный код в студию!
Дык, тебя форматирование интересует или что? Код я тебе вряд ли покажу, но на отзывы заказчиков ссылку могу дать. Не во внешнем виде дело-то. У меня размер своих утилит для профилирования и всяких тестов-измерений в несколько раз был больше целевого кода. И плюс много веток под #ifdef-ами для различных профилирующих сценариев. Вот что имелось ввиду. А ваш код, извини, выглядит, как буд-то над парсером толком еще не начинали работать. Ну типа пока добились работоспособности "основной ветки" и всё. Тоже результат, согласен. Сначала надо отладить функциональность. Но разве это повод пальцы веером и чморить других коллег? Я, собсно, на эти чморения и среагировал, если ты обратил внимание, куда я вклинился. Да, мне стало любопытно, что же там такого сверхестественного происходит, чего я в этой жизни упускаю-то, что ты позволяешь чебе так по-хамски чморить преподов, хотя эти форумы вполне доступны и их студентам?
Фиг с ним, оставим это на твоей совести, но мне хотелось бы увидеть решения, выходящие за рамки инженерных, которые дали права столь собой гордиться. (хотя такие манеры это не оправдывает всё-равно)
Т.е. да, в первую очередь меня интересовала "бумажная" часть, хоть ты и ругаешься, типа "теоретик". Вроде после первых обменов любезностями я там вопросы вполне адекватные задавал. Но твои ответы, что типа "так, потому что по-другому и быть не может"... Извини, но я там прокоментировал подобный уровень. Несерьезно, в общем. У вас же фактически автоматный парсер, где каждая мелочь видна в быстродействии. Поэтому интересует эта каждая мелочь. А если эти мелочи не влияют на быстродействие, то становится интересно вдвойне. Ведь это не совпадает с тем, что говорилось о ПЕГ-парсерах.
V>>Вернее, не интересен вообще на целом классе применений, где ни о каких черепашьих 4MB/сек не может быть и речи, WH>Ну во первых покажи мне парсер который на грамматике C#4 хотябы столько дает. WH>Ну, хоть один. WH>Только не забудь про АСТ. Без АСТ парсер никому не нужен.
Вот еще один любопытный закидон. Да понимаешь, АСТ бывают разные. В моих случаях строить документ по сигналам парсера было заметно дороже, чем просто парсить. И некий "промежуточный" АСТ был не нужен, нужна была сразу семантическая модель док-та. Но, согласись, трудоемкость создания модели зависит от прикладной области, поэтому непонятно, что же мы будем мерять, если замерять связку: сам парсер, или построитель док-та? Для пример, я одновременно с парсингом проводил линковку всех ссылок документа. Для C# будет аналогично ресолвить все идентификаторы и выводить типы. Это же гораздо более трудоемко, чем просто выдавать иерархию нетерминалов (вот тут острый момент, правда? в каком виде? ). Почему так делал? Потому что для парсера скорость считывания с диска или получения из сети уже была как ограничение, и чтобы процессорное время не простаивало, делал всё сразу. Тоже кое-какой был профит.
V>>так же как не может быть речи о построении некоей "промежуточной" модели, бо само построение модели отнимает до половины эффективности. WH>Кому нахрен нужен парсер без АСТ?
Ну дык, узлы модели док-та могут быть гораздо сложнее, чем примитивные узлы ACT-дерева. Фишка в том, что лишние выделения даже из хипа GC весьма заметны на многомегабайтных док-тах, поэтому зачем выделять в 2 раза больше объектов во время парсинга, если можно выделить ровно столько, сколько нужно? Да и сами эти "узлы" тоже весьма агрессивно в памяти размечены на value-типах.
Ладно, уже много текста по банальной такой вещи: быстродействие парсера надо профилировать отдельно от быстродействия построителя док-та. Я же не против, чтобы вы в поставку вложили свой построитель AST, даже пример привел — это взаимоотношение XmlReader и XmlDocument. Первый SUX, второй ловит его сигналы и строит DOM. И на практике многие пользуют XmlReader без XML-DOM, сразу переводя распаршенные данные в граф прикладных объектов. Почему так? Исключительно из соображений эффективности.
V>>Я догадываюсь, что к PEG это вряд ли относится, судя по твоим реакциям, т.е. построение AST на фоне остального происходящего не видно и под микроскопом. WH>Ну да... то-то мой парсер всякие там ANTLR'ы рвет как тузик грелку.
Да ты знаешь... Я как-то накачал дотнетных библиотек для ИИ (заинтересовался как-то этой темой) и был в шоке. Написав свою либу с 0-ля, получал на тех же тестовых данных от 3-х до 10-ти раз ускорение. Т.е., вот прикольная штука — берем абслютно идентичные алгоритмы, но только за счет реорганизации структур данных получаем 300%-1000% буст. Что уж говорить о случае разных алгоритмов?
Ну да, как писать быстрый код на дотнете народ обычно не в курсе, достаточно пройтись по любому опен-сорсу. ИМХО, из-за большого кол-ва устойчивых мифов относительно GC и недооценки влияния косвенности на быстродействие. Я уже молчу о лишних абстракциях, виртуальности, и вложенных yield return. Тут вообще туши свет, кидай гранату. На питоне быстрее работает.
V>>Или лень делать факторизацию грамматики, например, а хочется использовать имеющуюся "в лоб". WH>Ну давай. Засунь грамматику C#4 в LL(1)...
Ооо, это отдельная тема. Я экспериментировал где-то в 2004-м с не LL(1)-грамматиками и автоматным разбором для них. Так вот, если сейчас для классического LL(1)-парсера отдельно выделяет лексер и отдельно парсер, и всего этих звеньев два (нетерминалы предыдущего звена являются терминалами следующего), то этих звеньев можно больше. Например, 3 звена (лексер->LL(1)->LL(1)) справлялись с "отрывком" синтаксиса C# 1.0, который не разбирался классическим лексер->LL(1) без перехвата сигналов и коррекции состояния (т.е. не разбирался без костылей). Это был когда-то эпический спор с Владом насчет того, какая грамматика сложнее — C++ или C#, этот спор и подвиг на сии эксперименты. Там правда другие сложности начинаются — это та самая диагностика (даже не думал над ней тогда, просто экспериментировал с разбираемостью). Но подход сам по себе работоспособный. При том что скорость у LL(1) — такая же автоматная. Но в любом случае LL(1) — это заведомо ограниченная грамматика, хотя и самая "вкусная" в плане эффективности из всех имеющихся контекстно-свободных.
Ну и напоследок, GLR-парсер, как и Эрли, парсит любые классы грамматик, даже неоднозначные. Т.е. там, где решения надо принимать согласно семантике данных (значениям данных), GLR покатит, а PEG постоит в сторонке.
Здравствуйте, VladD2, Вы писали:
VD>Тебе конечно виднее. Я бы пережил со старыми подходами.
Ты уже все ошибки связанные с приоритетным выбором в парсере C# нашол?
И хардкейс еще далеко не все нашёл. А он явно сильнее, чем среднестатистический программист.
VD>К рому же приоритетный выбор иногда просто необходим для построения логики разбора. Так что в каком-то виде его надо оставить. Можно просто ввести | и /.
Зачем?
VD>А что там такого? Не всем нравится когда рядом с проектом появляются сгенерированные файлы
Я написал в коментах.
А сгенерированные файлы рядом с проектом это ошибка компилятора. И нужно фиксить компилятор чтобы он все это валил только в папку с сгенерированными файлами.
VD>Молодец конечно, но вот помочь тебе уже не удастся, так как лично у меня там никаких прав нет.
И не будет.
Ибо проект нужно форкуть и править в форке.
VD> Плюс чтобы просто скачать код мне нужно еще одну тулу ставить. И изучать все что связано с гитхабом. А ведь только-только к Меркури приспособился.
Тут я с ИТом согласен. Тулзы для меркури УГ.
Да и гугл код с меркури похоже толком работать не умеет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
WH>>В частности избавиться от приоритетного выбора и перейти на принцип максимальной длинны разбора, VD>А ты не боишся, что это приведет к замедлению парсера?
1)Копейки.
2)Понятность нужнее.
VD>Тогда надо уходить от идеи перебора с откатами и брать идею LL(*) из АНТЛР-а. Но это она основана на генерации ДКА. А они как-то с совместимостью не вяжутся.
Ты сам ответил на свой наезд.
VD>И что тогда будет с TDOP? Ты его тоже выкидываешь, или твоя новая идея интегрирует этот алгоритм?
Интегрирует. Или точнее вокруг него по большей части и построена.
VD>Не нужно это. Точнее нужно только для "операторов". Именно для них нужна левая рекурсия. Все остальное само собой описывается в праворекурсивной форме.
Ох. Никто левую рекурсию убирать не будет. Просто пошлют все к чертовой бабушке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>Тебе конечно виднее. Я бы пережил со старыми подходами. WH>Ты уже все ошибки связанные с приоритетным выбором в парсере C# нашол?
Да я их и искать не собираюсь. Оно работает и этого достаточно.
Если надо мы можем сделать их автоматизированный поиск.
WH>И хардкейс еще далеко не все нашёл. А он явно сильнее, чем среднестатистический программист.
Если добавлять по правилу, а не описывать сразу огромную грамматику и пом ее рефакторить, то проблем не будет. В прочем я не против если будет лучше. Но только если при этом не будет хуже и если хоть что-то будет.
VD>>К рому же приоритетный выбор иногда просто необходим для построения логики разбора. Так что в каком-то виде его надо оставить. Можно просто ввести | и /. WH>Зачем?
Для разруливания неоднозначностей. Мне не всегда нужно "самый длинный".
VD>>А что там такого? Не всем нравится когда рядом с проектом появляются сгенерированные файлы WH>Я написал в коментах.
Это ты про статическую свойство? Ну, ламер товарищ. Не трудно ему подсказать.
WH>А сгенерированные файлы рядом с проектом это ошибка компилятора. И нужно фиксить компилятор чтобы он все это валил только в папку с сгенерированными файлами.
Это да.
Но человеку может просто не хотеться чтобы генерировались какие-то многомегобайтные файлы. Так что сама опция то по делу. Тем более что он перед этим у меня спросил. Так что это санкционированная инициатива.
VD>>Молодец конечно, но вот помочь тебе уже не удастся, так как лично у меня там никаких прав нет. WH>И не будет. WH>Ибо проект нужно форкуть и править в форке.
А зачем мне его форкать? Ну, вот скажем найдется очередной баг в парсере грамматик. Или захочу я его переписать по человечески без использования ручного разбора (на старой версии Пега). И что мне форкать проект?
В гите для этого есть брэнчи. Там тупо можно вести параллельные ветки и потом сливать их.
Можно конечно патчи слать и ждать пока ты их применишь и закомитешь, но это неудобно.
VD>> Плюс чтобы просто скачать код мне нужно еще одну тулу ставить. И изучать все что связано с гитхабом. А ведь только-только к Меркури приспособился. WH>Тут я с ИТом согласен. Тулзы для меркури УГ.
А ты скачал бы последнюю версию. Она практически доросла до тулзов к гиту.
WH>Да и гугл код с меркури похоже толком работать не умеет.
С чего ты это взял?
По любому растаскивать части идущие в составе компилятора по разным репозиториям — плохая идея. Автоматизировать их сборку в таких условиях будет не реально.
Тогда нужно было уж переводить на меркури или гит (хотя эта идея мне не нравится) весь Н1.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
WH>>>В частности избавиться от приоритетного выбора и перейти на принцип максимальной длинны разбора, VD>>А ты не боишся, что это приведет к замедлению парсера? WH>1)Копейки.
Это предположения или тесты?
WH>2)Понятность нужнее.
Понятность конечно дело хорошее. Но если ты уменьшишь производительность или гибкость, то для Н2 твое решение может просто не подойти. Ты же это дело не для развлечения делаешь?
VD>>Тогда надо уходить от идеи перебора с откатами и брать идею LL(*) из АНТЛР-а. Но это она основана на генерации ДКА. А они как-то с совместимостью не вяжутся. WH>Ты сам ответил на свой наезд.
Я вопросы только задаю. Пока что я чувствую что ты хочешь создать некий аналог GLR только для LL, т.е. GLL. И как я понимаю платой за это дело будет тупой парсинг всех альтернатив. А это может резко замедлить парсер.
Разве что ли попробовать это дело распараллелить.
VD>>И что тогда будет с TDOP? Ты его тоже выкидываешь, или твоя новая идея интегрирует этот алгоритм? WH>Интегрирует. Или точнее вокруг него по большей части и построена.
Хоть это радует. Потому как для операторов TDOP — то что нужно. Плюс он отлично расширяется.
VD>>Не нужно это. Точнее нужно только для "операторов". Именно для них нужна левая рекурсия. Все остальное само собой описывается в праворекурсивной форме. WH>Ох. Никто левую рекурсию убирать не будет. Просто пошлют все к чертовой бабушке.
Что? Можно отвечать развернуто?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Ну вот ты и подставился. Перечитай еще раз замечания Влада и потом моё. Только на этот раз не по диагонали.
Это не я подставился, а ты в очередной раз нихрена не понял.
V>Смелое утверждение, однако.
Но правда.
Покажи хоть один.
V>В куче книг ссылка на один тот алгоритм. Учитывая, что отличия "наивного" от "ненаивного" алгоритма минимизации несущественны по эффективности... более того, реально минимизация либо идет как build-step, т.е. ее стоимость не принципиальна, либо в рантайм не делается эта оптимизация вообще, т.к. неминимизированный ДКА работает до 10-20% шустрее минимизированного (проверь, кстати, я уже не первый раз это говорю, по состояниям — неминимизированный, но обязательно минимизированный по входному алфавиту), то мог один из алгоритмов упустить. Причем, зависимость повторяется как в нейтиве, так и в дотнете.
Ну что за бред то? Как минимизированный может работать медленней?
Это просто с физической точки зрения бред.
В худшем случае не будет ускорения.
А как ты собрался минимизировать входной алфавит мне вообще не ясно.
Алфавит тут юникодные символы. Куда ты их минимизировать собрался то?
V>Я тебе намекнул на т.н. forward reference, которые ресолвятся аналогично. Но спорил там лениво, т.к. я ошибся с асимптотикой из-за своей невнимательности (сложно свою работу делать и на бегу чужую просматривать), т.е. вопрос стал НЕПРИНЦИПИАЛЕН. И бодание уже шло только ради бодания. Ну да, грешен. Кстати, можно и продолжить пободаться, если есть желание. Там решение в итоге будет состоять в способе роутинга сигналов вашего парсера грамматики (в макросе который работает) и организации пула forward reference.
Чего? Каких сигналов? Куда роутинга? Какого пула?
V>Да, мне стало любопытно, что же там такого сверхестественного происходит, чего я в этой жизни упускаю-то, что ты позволяешь чебе так по-хамски чморить преподов, хотя эти форумы вполне доступны и их студентам?
Ох блин.
С преподами там разговор шел вообще на другую тему.
Они учится не хотят. Совсем.
Застряли в 60х и гордятся этим.
V>Ведь это не совпадает с тем, что говорилось о ПЕГ-парсерах.
Вот только у меня самый быстрый ПЕГ парсер.
А 4 метра в секунду это с построением АСТ. Скорость без построения АСТ никого не волнует. Вообще.
V>Вот еще один любопытный закидон. Да понимаешь, АСТ бывают разные. В моих случаях строить документ по сигналам парсера было заметно дороже, чем просто парсить.
Ты вообще смотрел, как мой парсер работает?
Похоже, что нет.
Там на каждое правило задается метод, который делает что нужно.
Он может строить АСТ.
А может и сразу вычислять, если это скажем калькулятор.
V>Ладно, уже много текста по банальной такой вещи: быстродействие парсера надо профилировать отдельно от быстродействия построителя док-та.
1)Еще раз: посмотри как это документ строится.
2)Быстродействее парсера без построения документа меня не волнует. Вообще. Ни разу.
V>Ну да, как писать быстрый код на дотнете народ обычно не в курсе, достаточно пройтись по любому опен-сорсу. ИМХО, из-за большого кол-ва устойчивых мифов относительно GC и недооценки влияния косвенности на быстродействие. Я уже молчу о лишних абстракциях, виртуальности, и вложенных yield return. Тут вообще туши свет, кидай гранату. На питоне быстрее работает.
Вот только к моему коду это все не относится.
Там почти все завязано на один инт.
V>>>Или лень делать факторизацию грамматики, например, а хочется использовать имеющуюся "в лоб". WH>>Ну давай. Засунь грамматику C#4 в LL(1)... V>Ооо, это отдельная тема.
Это тема про лень... и на реальных грамматиках ты охренеешь делать факторизацию просто по тому что она не делается.
V>Ну и напоследок, GLR-парсер, как и Эрли, парсит любые классы грамматик, даже неоднозначные. Т.е. там, где решения надо принимать согласно семантике данных (значениям данных), GLR покатит, а PEG постоит в сторонке.
1)Не знаю как ГЛР но Эрли это тормоз что звездец. И не лечится.
2)Нахрена мне неоднозначные грамматики? Я делаю парсер для разбора языков программирования. А они однозначны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Да я их и искать не собираюсь. Оно работает и этого достаточно.
В том то и дело что оно только вид делает что работает.
VD>Если надо мы можем сделать их автоматизированный поиск.
Не сможем.
VD>Если добавлять по правилу, а не описывать сразу огромную грамматику и пом ее рефакторить, то проблем не будет. В прочем я не против если будет лучше. Но только если при этом не будет хуже и если хоть что-то будет.
Вот только хардкейс грамматику шарпа так и писал. Но ему это не помогло.
Люди просто плохо его воспринимают.
VD>Для разруливания неоднозначностей. Мне не всегда нужно "самый длинный".
Например?
VD>А зачем мне его форкать? Ну, вот скажем найдется очередной баг в парсере грамматик. Или захочу я его переписать по человечески без использования ручного разбора (на старой версии Пега). И что мне форкать проект?
А в чем проблема?
VD>В гите для этого есть брэнчи. Там тупо можно вести параллельные ветки и потом сливать их.
Ну так и форки без проблем можно сливать.
VD>Можно конечно патчи слать и ждать пока ты их применишь и закомитешь, но это неудобно.
На гитхабе есть такая кнопочка "Pull Request" называется.
Жмешь ее и мне приходит сообщение о том, что ты что-то сделал.
А я уже буду думать слить то, что ты сделал или нет.
WH>>Да и гугл код с меркури похоже толком работать не умеет. VD>С чего ты это взял?
Так вроде там была куча проблем с клонированием репозиториев из-за чего все в одну кучу переползли.
VD>Тогда нужно было уж переводить на меркури или гит (хотя эта идея мне не нравится) весь Н1.
Думаю что таки нужно это сделать.
SVN совсем достал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>>>Ды ну тебя, ты от темы постоянно уходишь на обсуждение собеседника. WH>>Какой темы? Ты вообще не понял о чем речь. WH>>Речь о сообщения об ошибках генерируемых парсером. WH>>А ты опять про оптимизацию грамматики. WH>>
V>Ну вот ты и подставился. Перечитай еще раз замечания Влада и потом моё. Только на этот раз не по диагонали.
Я вот перечитал и не понял в чем он подставился.
Пойми, он действительно в вопросе сечет.
V>Смелое утверждение, однако. Ваше rule.Location — это разве не ссылка на исходное правило? И разве сложно сохранить всю историю подстановок?
Ты не понимаешь суть вопроса. Попробуй понять его по глубже.
Пробелема в том, что надо понять какое из правил обломалось при зазборе. Вычислить список правил которые могут идти после него не сложно и по исходной грамматике. Но вот отловить то правило что обломалось можно только если правило не заинлайнено. У нас при обломе правила его индекс пишется в специальную переменную. Потом производится анализ и выводится нужная информация. Но если правило заинлайнено и слито с другими, то понять что обломалось именно оно невозможно, так как прямой код правило уже не порождает.
V>Я скажу, откуда у меня столько, скажем так, уверенности в этом деле. Я довольно много возился с разновидностями семейств GLR-парсеров.
Молодец. Только ни все как один дикие тормоза. Если мы не будем делать оптимизаций, то у нас тоже будет все кошерно. Только так же медленно.
V> Они прикольны тем, что на 99% реальных входных данных работают как конечные автоматы. Т.е. да, разветвления там есть, и порой ширина охвата доходит до 20-ти и более, но обычно на очень коротких участках (тупиковые ветви быстро отмирают). Примерно 99% там идет не больше 1-3-х параллельных веток, каждая из которых работает, однако, быстрее даже среднестатистического лексера, который по ДКА (из-за особенностей таблицы переходов низлежащего GLR НКА — из-за сильной разряженности таблицы переходов).
Последнее заявление гнусный п...ж. Пока что нет ни одного GLR-а дающего приемлемую скорость разбора. Они все как один тормоза. Плюс еще сообщения об ошибках формируют ужасные (как все LR-ы).
V> Да, обкатывал там оптимизацию нешуточно. Делал автоматом перевод правил из БНФ в НКА. Ты примерно представляешь среднее число подстановок и оптимизаций правил, для полного построения НКА из БНФ? А потом ведь еще идет последующая минимизация НКА (угу, не оговорился!), где тоже протаскивается вся история преобразований исходных правил. А иначе что там парсер будет выдавать в кач-ве своих сигналов и как давать ошибку?
V>Еще харатерная особенность такая, что в "разогретом" режиме, если использовать буфера под цепочки выводов, то динамическая память не расходуется. А "разогреть" можно и непосредственно перед запуском, то бишь сразу предвыделить буфера (там не много, NlogN в среднем от глубины вложенности реальных выражений, т.е. сотня-другая максимум для ЯВУ, например, или несколько десятков для моего случая с EDI-стандартами)
Ну, нам GLR никак не поможет. Нам нужна динамическая расширяемость. А GLR-ы все как одни на ДКА. Что с динамикой не вяжется. Плюс они лексерные. А это тоже приговор расширяемости.
V>Единственная динамически выделяемая память была уже за пределами парсера — это непосредственное построение электронного док-та. Т.е., заметь, на каком уже уровне идет борьба за эффективность.
Заметь уровень высокий, а выхлоп нулевой.
V> На уровне оптимизации выделения памяти из кучи GC, гы-гы.
А ты думаешь мы лаптем щи хлебаем? Ты создай парсер C# 4 и попробуй с нами потягаться. Уверен на 99% что все GLR-ы сольют и позорно.
V>Как сказал, упирался уже непосредственно в эффективность символьного буфера (эти тормозные массивы дотнета!!!), в избавление от лишних копирований, в использовании файлового АПИ ОС напрямую для зачитки в unmanaged буффер и в лексере этого unsafe тоже хватало уже, бо уже играет рояль. Понятное дело, что на 4MB/c лезть в эту оптимизацию смысла нет вообще, это еще не тот порядок цифр.
Когда ты обеспечишь 4 метра на грамматике C# 4, тогда мы с тобой что-то обсудим. А пока я склонен считать тебя трепачем. Без обид.
WH>>Чего стоят твои десятки, раз, когда ты предлагаешь на ровном месте создать кучу геморроя ради ни пойми чего. Нахрена мне что-то делать при оптимизации, если я могу просто оставить исходный АСТ в котором все есть.
V>Не думаю, что вместо ссылки на элемент сохранить ссылку на список оных — это rocket science.
Блин! Да нет там никокого АСТ в тот момент что нужно. Нееет! Там код сгенерированный. И в нем ссылку не положишь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Понятность конечно дело хорошее. Но если ты уменьшишь производительность или гибкость, то для Н2 твое решение может просто не подойти. Ты же это дело не для развлечения делаешь?
Если не будет понятности то оно тем более не подойдет.
Ты пойми мы систему для людей, а не для роботов делаем.
VD>Что? Можно отвечать развернуто?
Н2 конечно же.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alvas, Вы писали:
A>Я так понял что ты планируешь у PegParser'a только внутренности менять, a снаружи он останется таким же. A>Я прав или стоит волноваться?
1)Пег парсер я менять не планирую вообще. Он останется таким как есть. Я делаю другой проект. Просто взял код парсера за основу.
2)Я меняю внутренности настолько, что внешнее сходство потеряет значение. Да и внешне он будет выглядеть несколько иначе.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, alvas, Вы писали:
A>>Я так понял что ты планируешь у PegParser'a только внутренности менять, a снаружи он останется таким же. A>>Я прав или стоит волноваться? WH>1)Пег парсер я менять не планирую вообще. Он останется таким как есть. Я делаю другой проект. Просто взял код парсера за основу. WH>2)Я меняю внутренности настолько, что внешнее сходство потеряет значение. Да и внешне он будет выглядеть несколько иначе.
Какое у нового проекта назначение? Цель? Опиши, пожалуйста, общий смысл
Здравствуйте, alvas, Вы писали:
A>Какое у нового проекта назначение? Цель? Опиши, пожалуйста, общий смысл
Название я пока не придумал. С ними вегда такая морока.
А цель проста: Сделать понятный, удобный и динамически расширяемый парсер для языков программирования.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Да я их и искать не собираюсь. Оно работает и этого достаточно. WH>В том то и дело что оно только вид делает что работает.
Ты как всегда преувеличиваешь. Он не просто работает, а разбирает реальные исходники. Хардкейс несколько проектов скомпилировал им.
VD>>Если надо мы можем сделать их автоматизированный поиск. WH>Не сможем.
Выявлять то полное перекрытие? Почему же? Сможем. Возможно не во всех случаях, но во многих сможем.
VD>>Для разруливания неоднозначностей. Мне не всегда нужно "самый длинный". WH>Например?
Простейший пример разрешение неоднозначности с if/else и if (без else). В одном случае надо выбирать ближний else, в другом — нет.
VD>>А зачем мне его форкать? Ну, вот скажем найдется очередной баг в парсере грамматик. Или захочу я его переписать по человечески без использования ручного разбора (на старой версии Пега). И что мне форкать проект? WH>А в чем проблема?
Их масса. Первая — нет прав на комит. Я могу разве что-ли локальный клон сделать.
Вторая — разные репозитории. Если мне требуется за одно поправить компилятор, то нужно делать два комита. Это же создает проблему вынимания исходинков и сборки в один клик.
Следующая проблема — дополнительное обучение.
VD>>В гите для этого есть брэнчи. Там тупо можно вести параллельные ветки и потом сливать их. WH>Ну так и форки без проблем можно сливать.
Видимо ты неверную терминологию используешь. Вилка (fork) это, как я понимаю, полное дублирование проекта. Искользуется когда кто-то хочет создать свое ответвление. А когда речь идет о совместной работе, то делают ветку (как я понимаю это у них называется брэнч). А для этого нужны права на репозиторий.
VD>>Можно конечно патчи слать и ждать пока ты их применишь и закомитешь, но это неудобно. WH>На гитхабе есть такая кнопочка "Pull Request" называется.
Я в курсе. Только это не очень удобно для реальной работы.
WH>Жмешь ее и мне приходит сообщение о том, что ты что-то сделал. WH>А я уже буду думать слить то, что ты сделал или нет.
Многие просто не будут начинать что-то делать, если их работу будут выбрасывать.
WH>>>Да и гугл код с меркури похоже толком работать не умеет. VD>>С чего ты это взял? WH>Так вроде там была куча проблем с клонированием репозиториев из-за чего все в одну кучу переползли.
Там была одна проблема — недоведенный до ума клиент. Сейчас его подтянули.
А та проблема о которой ты говоришь исходила из того что Ziaw неверно истолковал предназначение личных клонов которые поддерживает гуглькод. Как и в Гите в Меркури для совместной работы используются брэнчи и патчи. Клоном тоже можно пользоваться, но это будет просто клон репозитория. А клоны на гуглакоде — это просто частные копии в которых нельзя дать права другим.
VD>>Тогда нужно было уж переводить на меркури или гит (хотя эта идея мне не нравится) весь Н1. WH>Думаю что таки нужно это сделать. WH>SVN совсем достал.
Ну, достал или нет это отдельный вопрос. Разведение анархии это не оправдывает. От локальных удобств может пострадать все дело.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
V>>Ну вот ты и подставился. Перечитай еще раз замечания Влада и потом моё. Только на этот раз не по диагонали. WH>Это не я подставился, а ты в очередной раз нихрена не понял.
Гм...
Одна из проблем заключается в том, что для оптимизации правила надо инлайнить. Но для обработки ошибок это плохо (информация о правилах теряется).
Это оно в вашей реализации теряется, потому что Wolfhound не сохраняет к каждому оптимизированному правилу (т.е. к каждому вхождению элементов choice/sequence) всю цепочку подстановки исходных.
Я НЕ смотрел как у вас организована диагностика ошибок. Сам я делал таблицы соответствий наборов конфликтующих нетерминалов и текстов сообщений об ошибках. Эта фишка, кстати, плохо обобщается, потому как просто выдать все возможные положительные варианты на данном символе/лексеме — это не сильно помогает. Надо человеческий текст писать. А чтобы эта таблица соответствий работала, мне нужно на каждое состояние протянуть исходный нетерминал через все инлайн-подстановки. Итого, у меня их на каждом состоянии НКА получается обычно больше одного. И вот на "самые типичные" комбинации из них, эмпирически составляется таблица, где ключом является набор нетерминалов из всех "положительных" направлений возможного разбора (случай одного направления тоже туда вписывается).
Почему я вообще тут упомянул GLR? — потому как тоже восходящий разбор, похожая специфика, т.е. вся диагностика строится вокруг набора "положительных" вариантов продолжения парсинга из точки, в которой по текущему терминалу нет перехода. Когда вариантов продолжения больше одного, и это сочетание не выделено в таблице сообщений, я просто давал "Invalid syntax in position X,Y". Вот эти наиболее "популярные" invalid syntax и покрывал эмпирически вменяемыми сообщениями.
WH>Ну что за бред то? Как минимизированный может работать медленней?
Мы же имеем одинаковое число переходов для любых разбираемых лексем в обоих случаях. Но! За счет схлопывания (collapse) так же состояний, не являющимися конечными (в модели Мура), эти промежуточные состояния могут иметь больше ветвлений. Вот он, момент истины. Итого, по технологии кодогенеренного switch/case на каждом шаге у нас больше мощность перебора для вычисления следующего состояния в случае минимизированного автомата, хоть и меньше кода. Но переходов столько же. Но больше проверок на каждом шаге...
И я заранее оговаривался, что если делать в табличном виде, то практически идентично по скорости работают, совсем чуть-чуть минимизированный может оказаться быстрее лишь из-за размеров таблицы в памяти и всяких эффектов кешей.
Если на этот раз все-равно не согласен и не захочешь попробовать... то давай этот пункт тупо свернем. Уже по 10-му кругу одно и тоже во всех ветках...
WH>А как ты собрался минимизировать входной алфавит мне вообще не ясно. WH>Алфавит тут юникодные символы. Куда ты их минимизировать собрался то?
А я вообще не понимаю, как парсить по юникоду без минимизации алфавита?
Суть минимизации по алфавиту такова (на пальцах): берем символы, скажем '0'-'9', по всем ним идут идентичные переходы, т.е. все дуги в графе переходов по этому набору полностью параллельны. Заменяем через таблицу подстановки терминалы T0..T9 на один терминал T'. Затем, при работе, вместо десяти ветвлений из каждого состояния получаем одно. Либо, вместо проверки диапазона (2 сравнения) имеем одно сравнение. Латинские символы и прочие "общеюникодные" схлопываются еще лучше. "Наивный" алгоритм такого разбиения исходного алфавита на эквивалентные множества прост как три копейки, возможно, что существуют "продвинутые", я не интересовался. Хотя, ты можешь покумекать. Даю затравку — наивный алгоритм минимизации алфавита идентичен наивному алгоритму (Мура) минимизации по состояниям с точностью до разворота таблицы переходов. Я имею ввиду, что минимизация состояний — это минимизация по столбцам, а минимизация алфавита — это минимизация по строкам. И там и там суть алгоритма в разбиении исходного мн-ва на классы эквивалентности. Наивный алгоритм делает это за счет попарного перебора. Возможно, за счет этой изоморфности в сути алгоритмов, получится приспособить тот оптимальный алгоритм минимизации по столбцам (по твоей ссылке) к минимизации по строкам. Но сие не принципиально.
Продолжаем.
В итоге, у меня никогда не получалось подстановочных терминалов T' более 255 штук (3-4 десятка в среднем), т.е. это уже кодирование в байт, т.е. таблица преобразований из юникода ровно в 64к байт. Правда, я там делал две таблицы преобразования — одну до кода 127 (как самую частую), другую — общую до 64к. На эффектах линий кешей еще кое-какие копейки в итоге выжимаются на ACII-ориентированном потоке, но не принципиальные.
Кроме того, коды T' надо отсортировать по частоте использования в дугах. Чем чаще используется, тем меньший код надо присвоить. Тоже кое-какие копейки прироста дает.
Далее, когда требовался safe и всё происходило динамически (т.е. без кодогенерации, по табличному варианту), после преобразования алфавита есть возможность поступать крайне цинично (в случае лексера): для каждого состояния находится максимальный код терминала T' в исходящей дуге, и просто выделяется массив длиной T'+1 для переходов. Потом, во время работы ДКА, я выбираю следующее состояние БЕЗ проверки на выход за границы массива. Среда и так проверяет, а если мимо и я поймал эксепшен — то там скорость уже не особо нужна, ведь затык лексера — это откат на начало неудачной лексемы, сдвиг (иногда ручной) и новый разбор. Сортировка по частоте делает средний размер таких массивов в единицы элементов. В случае null в таблице переходов так же цинично ничего не проверяю, просто ловлю эксепшен. Итого 2 сэкономленных if тоже кое-какие копейки дают. В общем, по мелочам в 2 раза и больше от начальной эффективность набегала.
WH>2)Нахрена мне неоднозначные грамматики? Я делаю парсер для разбора языков программирования. А они однозначны.
GLR на однозначных еще лучше работает. А парсеры не только для ЯП используют.
И вообще, низкоуровневую "механику" как раз лучше профилировать на несложных грамматиках, где откатов будет меньше всего (или не будет вообще). А уж сами откаты после профилирования механики оптимизировать независимо. Это я насчет того, что в случае парсера по грамматике C# там много чего сидит и друг на друга влияет. Для конечного сравнительного тестирования оно может и хорошо, но для профилирования — наихудший вариант.
Здравствуйте, VladD2, Вы писали:
VD>Я вот перечитал и не понял в чем он подставился.
В пальцах веером. Очередная попытка кого-то принизить не разобрамшись. Я ему ответил максимально подробно, хоть это и стоило мне некоторого времени. Скорее, для читателей, ибо личный спор с удивительной повторяемостью заканчивается в манере "дурак"/"сам дурак"..
VD>Пробелема в том, что надо понять какое из правил обломалось при зазборе. Вычислить список правил которые могут идти после него не сложно и по исходной грамматике. Но вот отловить то правило что обломалось можно только если правило не заинлайнено.
Ну я там чуть подробней ответил, чем ты сейчас объясняешь. Просто я исхожу из того, что вы знаете, о чем речь, а вы не исходите из того же о собеседнике. Поверь, не вы придумали восходящий разбор. Да, проблема диагности в восходящем разборе — это классическая головная боль парсерописателей.
VD>У нас при обломе правила его индекс пишется в специальную переменную.
В общем случае происходит "облом" сразу нескольких возможных правил. Я же продолжаю спраишивать: в чем проблема протянуть подстановочные нетерминалы вплоть даже до узла генерируемого ДКА? Да, их там целый список получится в случае нескольких подстановок. И что?
VD>Но если правило заинлайнено и слито с другими, то понять что обломалось именно оно невозможно, так как прямой код правило уже не порождает.
А разве вариант, когда у нас идет выбор (choice) не та же проблема мн-ва обломанных вариантов? У меня хранилось в итоге в узлах/состояниях автомата (список списков правил-родителей). Потеряться ничего не могло. Сами целевые нетерминалы — статические данные. Сослаться на них откуда угодно несложно.
VD>Молодец. Только ни все как один дикие тормоза.
Исключительно от грамматики и данных зависит. В одном из применений мне парсеры с откатами не подходили вообще. Представь, несколькомегабайтный документ имеет неоднозначность, которая ресолвится лишь на последних его символах, угу. Так вот, он парсится себе GLR-парсером, который протягивает два варианта разбора сквозь весь документ, и на последних символах один из них отбрасывает. Это стоимость двух паралельных ДКА. Теоретически. А фактически — выборка по одной и той же таблице, один и тот же входной поток в кеше, и т.д., а на всё это тратится грубо 90% работы ДКА, и 10% — собственно переход. Т.е. там каждый параллельный вариант грубо требует +10% затрат. А если же использовать откат на начало — то это чистое удвоение. А если откатов больше — вообще хана.
VD>Последнее заявление гнусный п...ж. Пока что нет ни одного GLR-а дающего приемлемую скорость разбора. Они все как один тормоза.
Тормозом может быть конкретная реализация.
VD>Плюс еще сообщения об ошибках формируют ужасные (как все LR-ы).
Проблематика сообщений об ошибках у вас такая же.
VD>Ну, нам GLR никак не поможет. Нам нужна динамическая расширяемость. А GLR-ы все как одни на ДКА. Что с динамикой не вяжется.
На НКА, вообще-то. И эти НКА, по природе своей легко расширяемы.
VD>Плюс они лексерные. А это тоже приговор расширяемости.
Ну ты в курсе, что вы с Wolfhound в таких случаях говорите? http://en.wikipedia.org/wiki/ASF%2BSDF_Meta_Environment
Еще смотреть DParser или абревиатуру SGLR (scannerless GLR).
V>>Единственная динамически выделяемая память была уже за пределами парсера — это непосредственное построение электронного док-та. Т.е., заметь, на каком уже уровне идет борьба за эффективность.
VD>Заметь уровень высокий, а выхлоп нулевой.
Заметь, парсер парсит со скоростью лексера.
VD>А ты думаешь мы лаптем щи хлебаем? Ты создай парсер C# 4 и попробуй с нами потягаться. Уверен на 99% что все GLR-ы сольют и позорно.
Для начала было бы неплохо на чем-нить попроще.
V>>Как сказал, упирался уже непосредственно в эффективность символьного буфера (эти тормозные массивы дотнета!!!), в избавление от лишних копирований, в использовании файлового АПИ ОС напрямую для зачитки в unmanaged буффер и в лексере этого unsafe тоже хватало уже, бо уже играет рояль. Понятное дело, что на 4MB/c лезть в эту оптимизацию смысла нет вообще, это еще не тот порядок цифр.
VD>Когда ты обеспечишь 4 метра на грамматике C# 4, тогда мы с тобой что-то обсудим. А пока я склонен считать тебя трепачем. Без обид.
Сколько времени заняла разработка у вас этой грамматики до текущего варианта? И где гарантии, что она не содержит ошибок? И вообще, смысл предлагать тягаться на эксперименте, стоимостью в несколько рабочих дней оппонента? Чтобы заранее получить отказ? Надо брать что-то более реальное. А потом смотреть, есть ли смысл тягаться дальше.
VD>Блин! Да нет там никокого АСТ в тот момент что нужно. Нееет! Там код сгенерированный. И в нем ссылку не положишь.
Мде. А как ты думаешь, сколько здесь может быть вариантов, разрулить ситуацию? 5/10/20? Что-то вы за свою конкретику реализации уцепились, не оторвать. Я же не спорю, что в некий ваш текущий внутренний АПИ не положишь. Ну не предусмотрели пока, ну и что? Будете с диагностикой бодаться — предусмотрите. Либо выкинете нафиг в мусорку всю затею, делов-то.
Здравствуйте, alvas, Вы писали:
A>Я так понял что ты планируешь у PegParser'a только внутренности менять, a снаружи он останется таким же. A>Я прав или стоит волноваться?
По идее, если убрать оператор приоритета, а оставить только оператор равнозначного выбора, то "снаружи" очень даже неплохой интерфейс выходит для задания модульной грамматики. А что там внутри — какая фиг разница. Народ и комбинаторы GLL делает, и SGLR и всё в этом духе.
В текущем виде с приоритетами PEG смущает меня этим:
PEG advocates use the fact that PEGs can never be ambiguous as a selling point. I think it's harmful, because it means that you never know where the ambiguity actually is. In a PEG, if you write:
a: b / c;
... you don't know if there could be situations where "b" and "c" could both match. Imagine that b is "if/then/else" and c is "if/then" (the classic case of ambiguity). With PEGs you are explicitly resolving this ambiguity to say that else's always bound to the most recent "if", but you don't realize you've done this because you PEG tool will never warn you that an ambiguity ever existed! Remember that this ambiguity is a user-facing issue that needs to exist in the documentation for your language ("else's always bind to the most recent if"), but with PEGs you're flying blind about where these user-facing ambiguities actually lie.
With a PEG, you never know if changing "a: b / c" to "a: c / b" changes your language or not.
Т.е. по его входной грамматике нельзя узнать св-ва этой грамматики. Из-за проблемы останова. На разных данных разные св-ва.
Вот интересное что-то нарыл. http://www.reverberate.org/gazelle/
Автор периодически хорошо припечатывает PEG за его "расхлябанность", и обещает избавление от всех проблем за такое же или лучшее время.
Здравствуйте, vdimas, Вы писали:
V>И то был польщен, что для целого класса грамматик умудрился оптимизировать оригинальный (тоже достаточно "наивный") алгоритм до случая, когда операци "свертка" не нужна, что тоже дает приличный буст быстродействия. До сих пор руки не доходят качественно прошерстить интернет на этот счет — есть ли публикации на эту тему, или все-таки опубликовать под своим именем. Несколько раз искал — пока этой разновидности не видел...
Trace based parsing extends a parsing scheme that is known since Ken Thompsons work [1] of the late 60s about parsing regular expressions using nondeterministic finite atutomata (NFAs). It is used in Trail to parse languages using general context free grammars in EBNF format.
А почему свертка иногда не нужна, гы:
For LL(1) grammars trace based parsing collapses to NFA driven LL(1) parsing with O(n) complexity on the length of the input token stream.
Прикол в том, что на этих участках при разборе НКА превращается в ДКА. Еще прикол в том, что парсятся любые грамматики, но агрессивная оптимизация EBNF.
V>Ооо, это отдельная тема. Я экспериментировал где-то в 2004-м с не LL(1)-грамматиками и автоматным разбором для них. Так вот, если сейчас для классического LL(1)-парсера отдельно выделяет лексер и отдельно парсер, и всего этих звеньев два (нетерминалы предыдущего звена являются терминалами следующего), то этих звеньев можно больше. Например, 3 звена (лексер->LL(1)->LL(1)) справлялись с "отрывком" синтаксиса C# 1.0, который не разбирался классическим лексер->LL(1) без перехвата сигналов и коррекции состояния (т.е. не разбирался без костылей).
Этот гаденыш украл у меня всё! По миру пустил:
For non left factored grammar rules Trail modifies LL(1) parsing by carefully embedding NFA transition tables into each other. This step is called NFA expansion.
Наверняка RSDN через google translate читает, упырь.
Здравствуйте, WolfHound, Вы писали:
WH>Это тема про лень... и на реальных грамматиках ты охренеешь делать факторизацию просто по тому что она не делается.
VD>>>В гите для этого есть брэнчи. Там тупо можно вести параллельные ветки и потом сливать их. WH>>Ну так и форки без проблем можно сливать.
VD>Видимо ты неверную терминологию используешь. Вилка (fork) это, как я понимаю, полное дублирование проекта. Искользуется когда кто-то хочет создать свое ответвление. А когда речь идет о совместной работе, то делают ветку (как я понимаю это у них называется брэнч). А для этого нужны права на репозиторий.
Да, форк — это будлирование проекта. В этом — весь цимес распределенных VCS. Когд аты делаешь git clone (грубо говоря аналог svn checkout), То ты получаешь полную самостоятельную копию проекта. При чем ты ее можешь колбасить, как хочешь, а потом просто заливать изменения через pull requrests в основной/главный. Причем твоя копия может спокойно выместить главную, если в ней развитие быстрее идет
Pull requests позволяют контролировать, что, кто и когда именно вливает изменения в проект.
Бранчи там тоже есть, и работают сверхмегашустро (как и все остальное в git'е (и mercurial'е тоже)) по сравнению с svn. По бранчингу в git'е самая лучшая статья вот: http://nvie.com/posts/a-successful-git-branching-model/ Там же коротенько и про pull, push и т.п.
Здравствуйте, tmp4857, Вы писали:
VD>>Он уже был выше.
T>Не вижу
И кто виноват? Я тебе раз пять уже давал ссылку на грамматику C# 4. Это реальная, не тривиальная грамматика. Причем без особых сложностей. Думаю, что уже на ней ты получишь ощутимые проблемы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
M>Да, форк — это будлирование проекта. В этом — весь цимес распределенных VCS. Когд аты делаешь git clone (грубо говоря аналог svn checkout), То ты получаешь полную самостоятельную копию проекта. При чем ты ее можешь колбасить, как хочешь, а потом просто заливать изменения через pull requrests в основной/главный. Причем твоя копия может спокойно выместить главную, если в ней развитие быстрее идет
Я в курсе приципов работы git, так пользовался Меркури, а у них все примерно одинаково.
Но чтобы делать push все равно нужно иметь права на репозиторий. Или это будут два совершенно разных проекта. Потому когда люди работают над одним проектом, то используют бранчи. Или просто комитят по очереди и сливают изменения. Чем чаще сливаются изменения, тем проще их сливать в будущем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>Я вот перечитал и не понял в чем он подставился. V>В пальцах веером. Очередная попытка кого-то принизить не разобрамшись.
В вопросе обнаружения ошибок ты явно не шаришь. Тут нужно понимать не общие приципы, и тем более GLR, а то какой код генерируется нашим генератором.
V>Я ему ответил максимально подробно, хоть это и стоило мне некоторого времени. Скорее, для читателей, ибо личный спор с удивительной повторяемостью заканчивается в манере "дурак"/"сам дурак"..
Твой ответ только доказал, что ты отвечаешь не шарая в вопросе.
VD>>Пробелема в том, что надо понять какое из правил обломалось при зазборе. Вычислить список правил которые могут идти после него не сложно и по исходной грамматике. Но вот отловить то правило что обломалось можно только если правило не заинлайнено.
V>Ну я там чуть подробней ответил, чем ты сейчас объясняешь. Просто я исхожу из того, что вы знаете, о чем речь, а вы не исходите из того же о собеседнике. Поверь, не вы придумали восходящий разбор. Да, проблема диагности в восходящем разборе — это классическая головная боль парсерописателей.
Ты исходишь из своих домыслов. Вот и сейчас ты несешь какой-то бред про восходящий разбор в то время как даже ребенку очевидно, что PEG парсится нисходящим (top-down) разбором. Соответственно проблем "диагностики в восходящем разборе" у нас нет. У нас есть проблема выявления правила которое обломалось в момент когда текущий индекс имел максимальное значение. Если не делать инлайнинг, то этой проблемы нет. Но если делать, то некоторые "терминальные" правила сливаются и перемешиваются, что мешает диагностики. Кроме того код сохраняющий эту самую позицию облома тоже кое что стоит. И пихать его в "терминальные" правила дороговато, так как они занимаются "числодроблением".
Я не понимаю почему ты в десятый раз несешь какую-то пургу на основании своих домыслов. Попробуй просто понять, что у нас другие алгоритмы и другие подходы, а соответственно и другие проблемы.
VD>>У нас при обломе правила его индекс пишется в специальную переменную.
V>В общем случае происходит "облом" сразу нескольких возможных правил.
Ну, ты еще мне расскажи как у нас что работает. Парсинг мы не параллелим. Так что одного за раз.
V>Я же продолжаю спраишивать: в чем проблема протянуть подстановочные нетерминалы вплоть даже до узла генерируемого ДКА? Да, их там целый список получится в случае нескольких подстановок. И что?
Уважаемый! Проблема в том, что ты пытаешься в наших алгоритмах видеть свои!
В момент когда работает парсер никаких нетерминалов нет. Есть рекурсивные функции производящие нисходящий разбор. Так вот когда речь идет о код генерируемом для правил идущих не на самых листовых ветках грамматики (напомню, что у нас нет лексера и его правила как бы смешаны с основными, а стало быть именно они являются листовыми), то мы имеем информацию о том для какого правила генерировался код и "по else" (т.е. при обломе правила) можем запомнить текущую позицию разбора в переменную ассоциированную с этим правилом. Но когда речь идет об оптимизированных правилах, код которых встраивается в код других правил и при этом еще и переставляется по много раз, определить что же за правило реально обломалось не выходит. Классический пример такого правила — это разбор ";" в грамматике C#. Правило слишком мелкое, не имеет обработчика и тупо инлайнится в другие. Приходится в парсере вставлять никому не нужный обработчик чтобы правило не инлайнилось и получалось четкое сообщение об ошибке. Но это негативно влияет на производительность.
В принципе можно было бы тупо забить на инлайнинг и генерить одинаковый код для любого правила. Но это привело бы к генерации моря лишних проверок и присвоений в "терминальных" правилах. Ведь надо не забывать, что у нас код "лексера" размазан по всему парсеру. И даже простейшие проверки литералов будут запоминать информацию об обломе. А это уже плохо не только с точки зрения производительности, но и с точки зрения осмысленности сообщений об ошибках. Ведь мало толку от информации, что в точке облома ожидался юникодная буква или число (при разборе идентификатора, например).
VD>>Но если правило заинлайнено и слито с другими, то понять что обломалось именно оно невозможно, так как прямой код правило уже не порождает.
V>А разве вариант, когда у нас идет выбор (choice) не та же проблема мн-ва обломанных вариантов?
Нет там никакой проблемы. Читай выше. С приоритетным выбором как раз все ОК. В конце ставится один else в котором и запоминается позиция облома. Только она почти наверняка не интересна.
V>У меня хранилось в итоге в узлах/состояниях автомата (список списков правил-родителей). Потеряться ничего не могло. Сами целевые нетерминалы — статические данные. Сослаться на них откуда угодно несложно.
Блин. Ну, нет там никаких узлов. Нету! Там код. Код запоминания позиции облома встраивается только в правила которые имеют обработчики (семантические действия).
VD>>Молодец. Только ни все как один дикие тормоза.
V>Исключительно от грамматики и данных зависит.
Конечно, конечно. Но ни одного шустрого пока свету не предявлено. Наверно их скрывают в закромах противопригарных решений .
V>В одном из применений мне парсеры с откатами не подходили вообще. Представь, несколькомегабайтный документ имеет неоднозначность, которая ресолвится лишь на последних его символах, угу.
Ага. Если не знаешь про мемоизацию, то можно кормить себя и такими сказками.
V>Так вот, он парсится себе GLR-парсером, который протягивает два варианта разбора сквозь весь документ, и на последних символах один из них отбрасывает. Это стоимость двух паралельных ДКА.
Не малая стоимость, в общем-то. В прочем, теоретических рассуждений можно построить много. Ты тут уже не раз хвалил свой парсер. Давай проведем простой эксперемент. Воссоздай парсер шарпаа который на выход выдаст АСТ. Сделаем тест в котором сравним полученное АСТ (чтобы видеть, что никто не врет) и сравним скорость разбора.
V>Теоретически. А фактически — выборка по одной и той же таблице, один и тот же входной поток в кеше, и т.д., а на всё это тратится грубо 90% работы ДКА, и 10% — собственно переход. Т.е. там каждый параллельный вариант грубо требует +10% затрат.
Вот это и есть — теоретически. А практически — тормоза .
V>А если же использовать откат на начало — то это чистое удвоение. А если откатов больше — вообще хана.
Этот вывод тоже от теоретизирования. На практике похожие грамматики имеющие разницу где-то в хвосте обычно состоят из общих подправил. А результат их разбора кэшируется. Так что когда пойдет повторный разбор, то его не будет, а результаты будут взяты из кэша.
VD>>Последнее заявление гнусный п...ж. Пока что нет ни одного GLR-а дающего приемлемую скорость разбора. Они все как один тормоза.
V>Тормозом может быть конкретная реализация.
Твоя достаточно крута? Ну, так докажи нам всем свою правоту. Предъяви парсер реального языка чтобы мы могли оценить его быстродействия.
VD>>Плюс еще сообщения об ошибках формируют ужасные (как все LR-ы).
V>Проблематика сообщений об ошибках у вас такая же.
У нас ее нет. У нас низходящий парсер мало отличающийся от рукописного. И сообщения получаются очень даже внятные. Плюс естественная стратегия восстановления после обнаружения ошибки. Наши проблемы в деталях оптимизации. И они не глобальны.
VD>>Ну, нам GLR никак не поможет. Нам нужна динамическая расширяемость. А GLR-ы все как одни на ДКА. Что с динамикой не вяжется.
V>На НКА, вообще-то. И эти НКА, по природе своей легко расширяемы.
Любой КА плохо расширяем. Даже то что у тебя отдельный лексер — это уже усложнение расширяемости.
Вот тебе задачка из реальной жизни. Есть язык — Nemerle. Он парсит входной поток и если обнаруживает открытие пространства имен, то импортирует новые правила (описанные в виде макросов). Ну, и что на ходу будешь перестраивать свои НКА? А что если экспонента получится?
А НКА — это еще и приговор производительности. И я тогда вообще не понимаю о каких таблицах ты там говоришь, если у тебя НКА.
Весь кайф PEG-а заключается в том, что он идеологически очень хорошо расширяется. Каждое правило по сути отдельный парсер. Для динамического расширения нам всего лишь надо сделать правило приоритетного выбора массивом и тупо дергать подправила из него.
VD>>Плюс они лексерные. А это тоже приговор расширяемости.
V>Ну ты в курсе, что вы с Wolfhound в таких случаях говорите?
Я в курсе всего этого. Все делится на два класса. Плохо расширяемые реализации и тормозные. SGLR — это не просто тормоза, а дикие тормоза.
Назови хотя бы одну реализацию GLR которая может расширяться динамически. Нет таких? А почему?
V>>>Единственная динамически выделяемая память была уже за пределами парсера — это непосредственное построение электронного док-та. Т.е., заметь, на каком уже уровне идет борьба за эффективность.
VD>>Заметь уровень высокий, а выхлоп нулевой.
V>Заметь, парсер парсит со скоростью лексера.
Докажи это. Тогда поговорим. В прочем, это чушь даже с точки зрения теории. Парсер рекурсивных грамматик не может работать со скорость парсера нерекурсивных.
VD>>А ты думаешь мы лаптем щи хлебаем? Ты создай парсер C# 4 и попробуй с нами потягаться. Уверен на 99% что все GLR-ы сольют и позорно.
V>Для начала было бы неплохо на чем-нить попроще.
По проще тебе же не выгодно будет. Да и неинтересно это. Реальные применения — это же языки программирования. Именно для них писать парсеры вручную тяжело. И именно при их создании получаются весьма неприятные эффекты в грамматиках (просто потому, что сложность велика и разложить все по полочкам создатель грамматики не может).
В прочем, можешь для начала тот же Джейсон повторить.
V>Сколько времени заняла разработка у вас этой грамматики до текущего варианта?
Неделю времени неподготовленного человека.
V>И где гарантии, что она не содержит ошибок?
Прогоны на массе реального кода. Это конечно не 100%-я гарантия, но все же.
Потом нет проблем сравнить полученное АСТ. Этот код мы напишем. От тебя потребуется только сгенерировать это АСТ. Можно тупо взять наше АСТ. Тогда вообще тесты будут 1 в 1.
V>И вообще, смысл предлагать тягаться на эксперименте, стоимостью в несколько рабочих дней оппонента? Чтобы заранее получить отказ? Надо брать что-то более реальное. А потом смотреть, есть ли смысл тягаться дальше.
Нет смысла тягаться на синтетике. Такие тесты ничего не покажут. Мы сделали парсер C# в основном с целью отладки технологий PegGrammar.
Если ты считаешь свой генератор парсеров коммерческим продуктом высокого качества, то тебе самому будет не лишним иметь хороший демонстрационный пример этого самого качества. Плюс ты сможешь не на словах, а на деле доказать применимость GLR, что будет несомненно интересно в научных кругах.
VD>>Блин! Да нет там никокого АСТ в тот момент что нужно. Нееет! Там код сгенерированный. И в нем ссылку не положишь.
V>Мде. А как ты думаешь, сколько здесь может быть вариантов, разрулить ситуацию? 5/10/20? Что-то вы за свою конкретику реализации уцепились, не оторвать.
Потому что на интересует только она.
V>Я же не спорю, что в некий ваш текущий внутренний АПИ не положишь. Ну не предусмотрели пока, ну и что? Будете с диагностикой бодаться — предусмотрите. Либо выкинете нафиг в мусорку всю затею, делов-то.
Ты лезешь учить других не разобравшись в их задачах. Мы, несомненно, поборем эту проблему. Но для того чтобы при этом не получить других (например, проблем производительности) нужно делать это с умом.
Твои же некомпетентные советы только раздражают (или веселят). Мы же те советуем тебе как оптимизировать или развивать твой GLR-парсер? Это потому что мы не знаем деталей и не хотим кидаться пустыми словами. Вот и ты попробуй так же.
А то ты говоришь о том, что Вольфхаунд гнет пальцы, а сам со стороны выглядишь не лучше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И кто виноват? Я тебе раз пять уже давал ссылку на грамматику C# 4. Это реальная, не тривиальная грамматика. Причем без особых сложностей. Думаю, что уже на ней ты получишь ощутимые проблемы.
Ты явно забыл, о чем шла речь
VD>>А вообще, достаточно одного правила экспоненциального. Поищи, в этом форуме было обсуждение по этому поводу. T>Ну это чистая патология. Надо еще очень постараться, чтобы этого добиться. VD>Этого элементарно добьется первый же не очень искушенный в грамматиках и парсерах пользователь. Ну, или искушенный когда начнет создавать сложный парсер. T>Дай какой-нибудь реальный пример
Здравствуйте, vdimas, Вы писали:
V>Почему я вообще тут упомянул GLR? — потому как тоже восходящий разбор, похожая специфика, т.е.
Ой звездец. ПЕГ это нисходящей анализ.
V>Если на этот раз все-равно не согласен и не захочешь попробовать... то давай этот пункт тупо свернем. Уже по 10-му кругу одно и тоже во всех ветках...
Так я попробовал. Разницы не заметил.
V>Суть минимизации по алфавиту такова (на пальцах): берем символы, скажем '0'-'9', по всем ним идут идентичные переходы, т.е. все дуги в графе переходов по этому набору полностью параллельны. Заменяем через таблицу подстановки терминалы T0..T9 на один терминал T'. Затем, при работе, вместо десяти ветвлений из каждого состояния получаем одно. Либо, вместо проверки диапазона (2 сравнения) имеем одно сравнение.
А превращение T0..T9 в T' у нас бесплатно и делается святым духом?
V>В итоге, у меня никогда не получалось подстановочных терминалов T' более 255 штук (3-4 десятка в среднем), т.е. это уже кодирование в байт, т.е. таблица преобразований из юникода ровно в 64к байт. Правда, я там делал две таблицы преобразования — одну до кода 127 (как самую частую), другую — общую до 64к. На эффектах линий кешей еще кое-какие копейки в итоге выжимаются на ACII-ориентированном потоке, но не принципиальные.
Ты главное не забывай про одно маленькое, но противное функциональное требование к моему алгоритму: Динамическое изменение грамматики.
V>GLR на однозначных еще лучше работает. А парсеры не только для ЯП используют.
Нут вот пусть они что-то другое и используют.
Я делаю разбор для ЯП.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ziaw, Вы писали:
Z>Бранч и форк в DVCS по сути одно и то же, и там и там делаются разные ветки разработки и там и там их потом можно слить. На гитхабе есть штатные механизмы сделать пулреквест в проект из форка. Хозяин проекта пулит к себе в репо изменения из пулреквеста.
Ну, вот это гимор. Совместной разработки при этом уже не будет. Не уж то вы не понимаете, что чем дольше не делается слияние, тем сложнее это слияние сделать потом.
Такой подход может и оправдан когда когда кто-то обкатывает новые идеи. Или когда кто-то со стороны хочет помочь проекту и при этом этому кому-то доверия мало. При этом этот подход заменяет брэнчи в SVN. Но для реальной работы нескольких человек над одним проектом он не пригоден.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
V>>Почему я вообще тут упомянул GLR? — потому как тоже восходящий разбор, похожая специфика, т.е. WH>Ой звездец. ПЕГ это нисходящей анализ.
V>>Суть минимизации по алфавиту такова (на пальцах): берем символы, скажем '0'-'9', по всем ним идут идентичные переходы, т.е. все дуги в графе переходов по этому набору полностью параллельны. Заменяем через таблицу подстановки терминалы T0..T9 на один терминал T'. Затем, при работе, вместо десяти ветвлений из каждого состояния получаем одно. Либо, вместо проверки диапазона (2 сравнения) имеем одно сравнение. WH>А превращение T0..T9 в T' у нас бесплатно и делается святым духом?
Как делается — уже описал. Тебя стоимость табличной конвертации интересует (с указанными подробностями)? Мой комп превращает T в T' со скоростью гиг в секунду (936 MB, если быть точным). Проверь на своем компе, интереса ради. И сравни с порядком быстродействия всего остального.
V>>В итоге, у меня никогда не получалось подстановочных терминалов T' более 255 штук (3-4 десятка в среднем), т.е. это уже кодирование в байт, т.е. таблица преобразований из юникода ровно в 64к байт. Правда, я там делал две таблицы преобразования — одну до кода 127 (как самую частую), другую — общую до 64к. На эффектах линий кешей еще кое-какие копейки в итоге выжимаются на ACII-ориентированном потоке, но не принципиальные. WH>Ты главное не забывай про одно маленькое, но противное функциональное требование к моему алгоритму: Динамическое изменение грамматики.
Я так понял, что конкретный макрос генерит готовый парсер (модуль). Дык, модуль он и в Африке модуль, внутри может быть реализован как угодно. Т.е. иметь свой алфавит T'. И что-то мне подсказывает, что в случае модульности он будет вообще малюсеньким в каждом отдельном парсере.
WH>Нут вот пусть они что-то другое и используют. WH>Я делаю разбор для ЯП.
Ну ок, я вообще-то привел GLR лишь из-за ваших проблем с инлайновостью.
Здравствуйте, vdimas, Вы писали:
V>Ну, в отличие от, я не делаю мину непонятной сакральности исследователя неведомого. И даю ссылки на открытые вещи. А то, что меня порой раздражает ваше непонимание, да еще усугубляемое тем, что это непонимание имеет природу снисходительного отношения к техническим предложениям оппонентов — это ожидаемо. То, что среди коллег требует одной итерации, здесь жуется по 10-му кругу. Лишь потому, что у тебя и твоего напарника все окружающие априори ламеры. Конечно, начинает доставлять.
Я вообще не вижу смысла во всем этом бодании по переписке.
Ты можешь показать свой код на примере?
Здравствуйте, Klatu, Вы писали:
V>>Ну, в отличие от, я не делаю мину непонятной сакральности исследователя неведомого. И даю ссылки на открытые вещи. А то, что меня порой раздражает ваше непонимание, да еще усугубляемое тем, что это непонимание имеет природу снисходительного отношения к техническим предложениям оппонентов — это ожидаемо. То, что среди коллег требует одной итерации, здесь жуется по 10-му кругу. Лишь потому, что у тебя и твоего напарника все окружающие априори ламеры. Конечно, начинает доставлять.
K>Я вообще не вижу смысла во всем этом бодании по переписке. K>Ты можешь показать свой код на примере?
Здравствуйте, WolfHound, Вы писали:
VD>>Понятность конечно дело хорошее. Но если ты уменьшишь производительность или гибкость, то для Н2 твое решение может просто не подойти. Ты же это дело не для развлечения делаешь? WH>Если не будет понятности то оно тем более не подойдет. WH>Ты пойми мы систему для людей, а не для роботов делаем.
Тут ты заблуждаешься. Вот если скорости будет не хватать, то вся работа насмарку. А понятность это критерий переменный. Больше несомненно лучше, но снижение или увеличение этого критерия не приведет к серьезным изменениям.
В общем, я хочу донести до тебя две главных мысли.
1. Скорость критична. Текущая реализация немного превышает минимально допустимый порог скорости. Ниже уже опускаться нельзя.
2. Важны сроки. Я уж не говорю, что мы не вечны. Но рынок такая вещь... сегодня он примет наше решение, а завтра уже может и не принять, так как будет другое решение, возможно по хуже, но рынок уже к нему приспособится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Klatu, Вы писали:
K>Сгенерить и выложить рабочий парсер для реального примера, типа грамматики C. Или на самый худой конец JSON.
Дык, я же написал, что у меня не генератор парсеров общего назначения. В динамике парсеры строятся по описаниям, да еще кое-что захардкожено, с целью исключения виртуальных вызовов в калбэках. Почистить надо. Но пока что есть небольшой интерес погоняться, вот попробую переиначить и подать JSON на досуге.
Здравствуйте, vdimas, Вы писали:
V>По идее, если убрать оператор приоритета, а оставить только оператор равнозначного выбора, то "снаружи" очень даже неплохой интерфейс выходит для задания модульной грамматики.
Он хочет трактовать оператор выбора иначе. Он хочет придать ему семантику "побеждает самый длинный". Алгоритм тупейший и в чем-то похожий на GLR. Парсим все правила. Если сматчилось более одного, то используем тот результат что дал наибольшую длину разбора (сместил позицию разбора дальше).
Вот только это приведет к постоянному перебору всех вхождений перечисления правил. Боюсь, что это может просадить производительность.
Вольфхаунд считает, что так как случае реального совпадения будут редки, а их подправила будут мемоизировать, то большая часть правил будут обламываться на первых же символах, а в случаях пересечений будет помогать мемоизация.
Но что-то, лично мне, как-то не верится, что полный перебор не даст заметного замедления. Но тут только тесты могут показать кто прав.
V>А что там внутри — какая фиг разница. Народ и комбинаторы GLL делает, и SGLR и всё в этом духе.
Народ может делать все что угодно. У нас конкретная задача. Нам нужен быстрый и одновременно динамически расширяемый парсер для ЯП. Конечна цель создать новую реализацию макросов Немерле (или языка-наследника).
V>В текущем виде с приоритетами PEG смущает меня этим: V>
V>PEG advocates use the fact that PEGs can never be ambiguous as a selling point. I think it's harmful, because it means that you never know where the ambiguity actually is. In a PEG, if you write:
V>a: b / c;
V>... you don't know if there could be situations where "b" and "c" could both match. Imagine that b is "if/then/else" and c is "if/then" (the classic case of ambiguity). With PEGs you are explicitly resolving this ambiguity to say that else's always bound to the most recent "if", but you don't realize you've done this because you PEG tool will never warn you that an ambiguity ever existed! Remember that this ambiguity is a user-facing issue that needs to exist in the documentation for your language ("else's always bind to the most recent if"), but with PEGs you're flying blind about where these user-facing ambiguities actually lie.
V>With a PEG, you never know if changing "a: b / c" to "a: c / b" changes your language or not.
V>Т.е. по его входной грамматике нельзя узнать св-ва этой грамматики. Из-за проблемы останова. На разных данных разные св-ва.
Это — да. Но зачатую как раз можно. Вольфхаунд как раз и хочет побороть эту проблему. Вот только не ясно как это скажется на производительности.
V>Вот интересное что-то нарыл. http://www.reverberate.org/gazelle/ V>Автор периодически хорошо припечатывает PEG за его "расхлябанность", и обещает избавление от всех проблем за такое же или лучшее время.
Автор может гнать что хочет. У нас есть практика. На ПЕГ-е народ клепает парсеры со скороть поросячьего визга. И при этом у многих из них нет никакого опыта или опыт был мелким и давно. Так что проблема неопределенности вызываемая приоритетным выбором несомненно существует, но на практике она не так уж и страшна.
Вот Вольфхаунд тут сетует на то, что в парсера C# сделанном Хардкейсом есть "мертвые вхождения". Наверно так оно и есть, но это не мешает парсеру корректно работать. Это скорее грязь, а не реальная проблема. А проблема в том, что эту грязь не так то просто обнаружить. Но в общем подход прекрасно работает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>В динамике парсеры строятся по описаниям, да еще кое-что захардкожено, с целью исключения виртуальных вызовов в калбэках.
Вроде все слова знакомые, а в осмысленное предложение никак не связываются
V>Почистить надо. Но пока что есть небольшой интерес погоняться, вот попробую переиначить и подать JSON на досуге.
JSON — это на самый худой конец. Желательно что-то более близкое к реальным задачам, типа C.
Здравствуйте, Klatu, Вы писали:
V>>В динамике парсеры строятся по описаниям, да еще кое-что захардкожено, с целью исключения виртуальных вызовов в калбэках.
K>Вроде все слова знакомые, а в осмысленное предложение никак не связываются
Динамическое построение — это значит НЕ кодогенерация. И это диктует технику исполнения: графы переходов не в виде switch/case/goto в коде, а в некотором закодированном виде в памяти. Т.е. происходит как бы интерпретация графа переходов автомата. В приципе, даже такая техника работает достаточно быстро. Единичный лексер на таком "интерпретирующем" ДКА разбирает сотни мег данных в секунду на моем компе. Главное — успевать эти данные подавать, потому как стандартные файловые ср-ва С++ или дотнета, прямо скажем, не очень. Поэтому с подачей данных тоже бороться пришлось.
Более того, интерпретирующая техника — это единственно-возможная техника для случая параллельного парсинга.
А "захардкожено" потому, что стоимость обработки результата заметно влияет на общую производительность, поэтому я избавлялся от виртуальных вызовов где только можно, т.е. интерфейс парсера вышел не абстрактным, а завязанным на конкретные прикладные типы — клиенты.
Это все надо развязать друг от друга для тестирования произвольной грамматики.
K>JSON — это на самый худой конец. Желательно что-то более близкое к реальным задачам, типа C.
Блин, сюда в день час потратишь, и то дофига. А это работа на несколько дней. Сначала надо узнать на чем-то несложном, будет ли смысл, после всех операций по убиранию хардкода.
Здравствуйте, VladD2, Вы писали:
VD>Он хочет трактовать оператор выбора иначе. Он хочет придать ему семантику "побеждает самый длинный". Алгоритм тупейший и в чем-то похожий на GLR. Парсим все правила. Если сматчилось более одного, то используем тот результат что дал наибольшую длину разбора (сместил позицию разбора дальше).
А что значит "самый длинный"? Я понимаю как оно работает для цепочки терминалов по жадному алгориму лексера. Но какой физический смысл имеет "длина" двух взаимно-рекурсивных правил, например? Да еще, которые не содержат терминалов, а описаны через промежуточные нетерминалы?
Ведь по классике, это же не лексер, который разбивает входную цепочку символов. Парсер распознает поданную цепочку целиком или не распознает. А если у нас несколько вариантов удачного распознавания одной и той же цепочки (т.е. несколько вариантов AST), какой из них самый длинный?
(Просьба без эмоций плиз, мне действительно интересно)
VD>Вольфхаунд считает, что так как случае реального совпадения будут редки, а их подправила будут мемоизировать, то большая часть правил будут обламываться на первых же символах, а в случаях пересечений будет помогать мемоизация.
VD>Но что-то, лично мне, как-то не верится, что полный перебор не даст заметного замедления. Но тут только тесты могут показать кто прав.
Ну так и есть. Но это от характера данных зависит, бо самый худший вариант вырождается в Эрли в своей наивной реализации (немного оптимизировано дерево вывода в сравнении с Эрли, но не сильно спасает). Попыток парсить параллельными парсерами ЯП было полно, и народ вовсю копает именно в этом направлении. Ведь параллельные парсеры жуют любые грамматики без ограничений. Им не нужна факторизация, они не боятся рекурсии. А главное — поддаются нехилой автоматической оптимизации.
И направления исследований в этой области — это улучшение того самого "worst case", т.е. для сильно-неоднозначных языков. К примеру, есть SRNGLR, он парсит SASL в 8-10 раз быстрее, чем просто SGLR (для которого SASL — хорошая демонстрация имеющихся проблем в GLR). По более "привычным" языкам: Питон, например, парсится в 3-5 раз быстрее. Тоже нехилый такой буст.
Опять же, отказ от AST, и использование вместо него в сигналах Parser Tree заметно поднимает производительность. Только опять без эмоций!
Это не я придумываю. Реально модно стало уходить от построения АСТ прямо в парсерах. Зачем выделять в куче лишние объекты, если можно переиспользовать Parser Tree? Вся информация о взаимоотношениях разобранных правил там сохраняется — бери, пользуйся. Только вот из кучи ничего лишнего не выделяется.
VD>Народ может делать все что угодно. У нас конкретная задача. Нам нужен быстрый и одновременно динамически расширяемый парсер для ЯП. Конечна цель создать новую реализацию макросов Немерле (или языка-наследника).
А у вас одна и та же кодовая база для рассмотренного PEG-макроса и для динамического расширения будущего парсера Nemerle? Там же разная техника исполнения парсера должна быть, как мне видится.
Здравствуйте, vdimas, Вы писали:
VD>>Ты исходишь из своих домыслов. Вот и сейчас ты несешь какой-то бред про восходящий разбор в то время как даже ребенку очевидно, что PEG парсится нисходящим (top-down) разбором.
V>Ох, ну ты и красавец.
Да, я красавец. Хочешь это обсудить?
V>А что происходит, когда вы правила инлайните, не судьба была сообразить? Ну просто на бумаге распиши, что произойдет, если по некоему правилу полностью всё заинлайнить (чтобы легче было увидеть). А потом построй кусок ДКА по этому правилу, а потом сравни с построением НКА/ДКА GLR, и посмотри, наконец, почему же там не теряется информация о нетерминалах, хотя всё "заинлайнено" по самое нихочу, т.е. непосредственно до НКА/ДКА.
Ну, ты бы хоть спросил нас что ли, а то снова пошел нести какую-то ахинею.
ДКА Вольфхаунд генерирует исключительно для оптимизации листовых правил (в твоем лексиконе называемых "терминалами") и исключительно когда в них нет рекурсии. Так что получается там конечный автомат. PEG при этом нарушается не сильно. GLR не получается вовсе. Твой GLR даже не начинает работать там где у нас работают ДКА.
Инлайнинг — это уже немного другое дело. По умолчанию правило разворачивается в метод. На основании некоторых эвристик это может не делаться, а код парсинга правила тупо помещается в то место где "вызывалось" правило.
Если инлайнинг совпадает с построением ДКА, то все становится еще сложнее, так как тут уже отследить что-то практически невозможно.
VD>>Соответственно проблем "диагностики в восходящем разборе" у нас нет.
V>Да все ясно, можно сворачивать.
С кем? С тобой? Ну, в общем-то с человеком говорящем о восходящем анализе при разборе PEG-грамматик действительно все ясно.
V>Я поторопился предположить, что вы понимаете проблематику.
Ты поторопился предположить, что ты понимаешь то о чем говоришь. Более того ты тут все время упрекаешь Вольфхаунда в том, что он слишком резок в высказываниях и задевает других (что в общем-то не далеко от истины), но сам сейчас делаешь тоже самое.
Ты мало того что по полной программе облажался и назвал белое черным, так еще имеешь наглость беспардонного хамить в стиле выше процитированного предложения.
V>Думал, оно же очевидно, и стоит только намекнуть на такую вещь как "свертка".
А ты не думай. Ты спрашивай. Тогда не будешь выглядеть полным ламером, как сейчас. Никаких "сверток" там нет. ДКА используется по прямому назначению, чтобы ускорять парсинг вот таких вот фрагментов: Parser.n
V>Тогда еще один намек: "сдвиг" в LR — это и есть собсно накопление цепочки терминалов, как делает ДКА сканер по мере движения по входному потоку.
Эй, умник! Остынь. Нет никаких накоплений цепочек терминалов. Нет даже самих цепочек. Есть тупой рекурсивный спуск и много разных оптимизаций. ДКА используются только там где они способны обогнать перебор. И это далеко не частый случай. Вот на приведенном выше фрагменте ДКА рулит. При этом даже семантика PEG нарушается, так как начинает работать правило, что кто длиннее тот и прав. "строки" тупо разворачиваются в дерево if-ов и goto.\
А вот для чего-то большего ДКА не применяются, ибо это не гибко и не дает реального ускорения.
VD>>У нас есть проблема выявления правила которое обломалось в момент когда текущий индекс имел максимальное значение. Если не делать инлайнинг, то этой проблемы нет. Но если делать, то некоторые "терминальные" правила сливаются и перемешиваются, что мешает диагностики.
V>Боже, Влад, ну детский сад. Завязывай.
Да пора. Разговаривать с невеждой возомнившей себя гением и правда бесполезно. Разбираться в вопросах реализации ты даже не собираешся, а любой разговор без этого просто бессмысленнен, так как ты рассуждаешь не о том, что есть, а о чем-то придуманном тобой. По сему нужно завязывать. Все равно никто вменяемый и не ангажированный этот сообщение уже не прочтет. А объяснять тебе что-либо бесполезно.
V>Понятное дело, что если сливать все цепочки правил до уровня "плинтуса", т.е. ДКА (как у вас), то исходные правила теряются, если ничего специально не предпринимать. Ты всерьез считаешь, что мы тут уже 10-й раз это обсуждаем и собеседник не может в это воткнуть?
Чем дальше, тем более укрепляется это мнение. По началу сомневался. Сейчас уже очевидно, что это так.
V> Ну и как с вами дальше общаться? Бесконечно отсылать к первому посту в ветке?
Разве что ли предварительно разобравшись в существе вопроса. Иначе никак. Но похоже ждать от тебя такого не стоит.
VD>>Кроме того код сохраняющий эту самую позицию облома тоже кое что стоит. И пихать его в "терминальные" правила дороговато, так как они занимаются "числодроблением".
V>Тут речь идет об одном if,
Умник, блин. В листовых правилах (которые у тебя в лексерах торчат) лишний if может преговорить к чертям всю производительность. Это же не лишний if на грамматику, а лишний if почти на любую букву. Надо же соображать, что для PEG-а терминалами являются отдельные символы (символы строки). Плюс втыкая этот if ты рушишь другие оптимизации. В 99% случаев всем плевать, что терминальные правила сливаются. Всем важнее скорость их разбора. Но из-за какого-то "одного if-а" это слияние будет невозможно! И в итоге мы получим тормозное говнище вроде GLR, Эрли или Пакрата.
Ты же сам, блин, тут про линейки кэша процессора рассказывал. Так с какого рожна "один if" вдруг стал мелочью?
VD>>Я не понимаю почему ты в десятый раз несешь какую-то пургу на основании своих домыслов. Попробуй просто понять, что у нас другие алгоритмы и другие подходы, а соответственно и другие проблемы.
V>Эх, "работники передового края"... Извини, но продолжаю склоняться к тому, что это первый ваш парсер в истории, который с "0-ля" (в отличии от твоего R#). И вы там делаете кое-какие преобразования грамматики, но не способны оказались понять, что же это за преобразования такие у вас получаются.
Ну, уже достаточно выставил себя полным ламером и от того подобные слова не взывают у окружающих ничего кроме смеха.
Не останавливайся на этом, домысливай глубже и смелее.
Пойми разница между нами с тобой не большая. Мы просто не обсуждаем твою работу, так как не видели ее. Я подозреваю, что то что ты делаешь — это полное очковтирательство и лажа, так как серьезную работу могут делать только серьезные люди, а серьезные люди не несут такой пурги как ты и не высказываются так по хамски о чужом труде даже не разобравшись в деталях. Но утверждать я подобного не буду, так как косвенные улики не могут являются основанием для серьезных суждений. Всегда может быть что и полный трепач способен чего-то добиться.
Посему и предлагаю вместо того чтобы выпендриваться тут и поучать окружающих жизни продемонстрировать если не код, то хотя бы плоды своего труда. Конечно не очень корректно сравнивать расширяемые парсер с не расширяемым, но все же сравнение хоть чем-то интересно. А твои поучения и развешивания тут на окружающих ярлыков никому ровным счетомо не интересно.
V>Все ясно, можно взять паузу, потом вернемся, коль желание будет. Хотя уверен, теперь справитесь и так, бо теперь даже мне понятно, что именно тебе было не понятно.
Не. Беседовать с наглыми выскочками несущих полную пургу и не предваряющих никаких доказательств своих слов мне не интересно. Сделаешь тесты — будет что обсудить. А до тех пор лично для меня это пустая трата времени.
VD>>Уважаемый! Проблема в том, что ты пытаешься в наших алгоритмах видеть свои!
V>Логично. Только не свои, а общеизвестные. Достучаться вот не могу.
Да по фигу. Главное не те что есть на самом деле.
VD>>но и с точки зрения осмысленности сообщений об ошибках. Ведь мало толку от информации, что в точке облома ожидался юникодная буква или число (при разборе идентификатора, например).
V>Иногда доастаточно.
Очередное доказательство пустоты твоих слов.
V>Но ты абсолютно прав, что ориентироваться тут можно только на возможные ветки от места ошибки.
Вот эти "положительные" — это очередной твой домысле, которые скорее всего проистекает из того, что ты пытаешся видеть вместо наших алгоритмов, те что тебе известны.
V>И очеловечивать тут можно через разъяснение "типовых" ошибок как-нить через в ручную подготовленные таблицы соответствий типовых ситуаций. Только для этого надо вернуться к самому началу, и протянуть информацию о нетерминалах.
Очередной раз мимо.
V>Я себе вообще плохо представляю автоматизацию генерации сообщений об ошибках при парсинге по ДКА/НКА.
А кто-то говорил о парсинге по ДКА? Это твои домыслы.
V>Все, что у нас есть — это возможные положительные ветки.
У вас. У нас нет ни веток, ни положительных, ни ДКА. У нас есть рекурсивный спуск с оптимизациями не сильно ему мешающими. Мы спокойно находим место ошибки и можем вычислить те конструкции которые могли бы быть описаны в этом месте. Имена правил уже о многом говорят человеку. Конечно можно и их очеловечит заменив на развернутые строки, но это вообще прямое отображение.
Для отлова более сложных случаев можно использовать средства восстановления после ошибок и правила-ловушки ошибок (последнее доступно и в LR-ах).
Тут же используется автоматика на общий случай. Нет спец обработки, будет выведено сообщение типа "Expected fieldInitializer or propertyBody.
V>Для примера, у нас же грамматики ЯП не полные парсятся, бо они КЗ по своей природе, а парсим мы КС-подмножество.
Это пошла какая-то голимая философия. При разборе всех вменяемых языков процесс парсинга отделяется от остальных процессов обработки и делается теми или иными путями контекстно-свободным. Даже при разборе С/С++ все сводится к хранению и поддержанию на лету таблицы символов по которой типы отделяются от идентифкаторов. А сам разбор остается контекстно свободным (за исключением сказанного выше). По сему разговоры о КЗ-парсинге — это просто треп.
У нас есть средства разбора грамматик вроде С++ — это регионы которые позволяют организовать транзакции для символьных таблиц и т.п. Так что концептуально разбор остается контекстно свободным не смотря на имеющиеся КЗ-слоности.
V>Т.е. мы парсим синтаксис, а сообщение об ошибке должно опираться на семантику. Отсюда пляски с кастомизацией сообщений об ошибках — обязательная часть балета.
Есть ошибки парсинга, есть семантики. Иногда обобщив парсер и усложнив семантику можно добиться более понятных сообщений об ошибках. Но от ошибок парсинга никуда не уйти. Если челвоек написал неверно выражение, то зачастую ничего умнее чем сказать, что у у вас тут бяка, а ожилалось ХХХ, ничего не удается. И этого более чем достаточно для программиста.
V>Это понятно. Непонятно, почему нельзя нагенерить статических данных,
Потому что это сделает невозможным те оптимизации которые делаются. В прочем, мы конечно же будем думать над этим и постараемся найти приемлемый выход (компромисс).
V>описывающих таги нетерминалов,
Нет никаких нетерминалов. Сколько раз повторять? В ПЕГ нетерминал — это буква во входной строке. Остальное — эвристики.
V>и ссылаться на них из кода? Можно завести некий контекст парсинга, где по каждому псевдо-конечному состоянию (по "свертке" или ее аналогу, когда вы ее наконец сделаете) можно выставлять текущий контекст. Дополнительная стоимость — одно присвоение ссылки на статические данные раз в несколько символов исходного потока.
Хочешь ответ на свой вопрос? Разберись в алгоритмах.
VD>>Конечно, конечно. Но ни одного шустрого пока свету не предявлено. Наверно их скрывают в закромах противопригарных решений .
V>Дык, не пользовался бы народ.
Дык и не пользуется никто. Точнее пользуются разный научный мир которому по барабану с какой скоростью работают парсеры. Но все отчеты что я читал показывают крайне низкую производительность.
Потому на практике чаще всего применяют рукописные парсеры.
V> Или все дураки? Реально, техника откатов во многих сценариях наихудшая. А ее лечение, мемоизация, с таким требованиями к памяти как в Пакрате — не катит для длинных входных цепочек, по нескольку мег.
Ну, вот Вольфхаунд и изобрел свою технику мемоизации которая стоит по одному if-у на правило. В итоге в 90% получаем линейное время почти за бесплатно. Но это только одна из множества оптимизаций. Каждая дает по чуть-чуть, но в итоге разница между скоростью работы конечного парсера в дебаге (где нет большей части оптимизаций) и в релизе составляет где-то 10 раз. А в начале пути было где-то 5% (за счет лучшей оптимизации кода джитом).
V>Там нужны т.н. "оперативные" парсеры, которые однократно проходят по цепочке данных произвольной длины.
О еще один базворд придумал!
V>>>В одном из применений мне парсеры с откатами не подходили вообще. Представь, несколькомегабайтный документ имеет неоднозначность, которая ресолвится лишь на последних его символах, угу.
VD>>Ага. Если не знаешь про мемоизацию, то можно кормить себя и такими сказками.
V>Влад, ну как не знать с такой рекламой от тебя?
Хрен тебя знает. Вот про Пакрата какую-то пургу несешь. К тому же если бы знал, то чушь про откаты не нес бы.
V>Ты мне память прикинь хотя бы для цепочки в 1 мег.
Да хоть для 100 мег. Размер памяти будет всегда фиксирован количеством правил в грамматике. Мы же не Пакрат реализовали. Вольфхаунд реализовал мемоизацию для последней позиции разбора правила. Как показала практика на реальных грамматиках это почти наверняка устраняет экспоненциальный рост откатов и делает асимптоматику близкой к линейной (но не гарантированно линейной).
V>А потом представь, что это серверное приложение, и оно многие десятки запросов одновременно обслуживает. Ну и плюс, мы и так для данной грамматики имеем O(n) по быстродействию, нафига тратить лишнюю память?
Если грамматика LL(1), откатов не будет в принципе. Только это частный случай. А для ПЕГ без мемоизации O(n) достижимо только для LL(1). А это задолабашся левой факторизацией заниматься. Даже реально грамматики близкие к LL(1) трудно в чистую свести к ней.
V>И потом, ты не правильно понял. Не правила в конце различаются, а цепочки. Правила асболютно разные, уникальные, т.е. твоей мемоизацией можно подтереться.
Это какие-то очередные выдумки. Если грамматики схожи, то описание подчастей разными правилами — это банальное дублирование (копипаст).
V> Полностью деление всего потока на нетерминалы переиначивается в зависимости от участка, ближе к концу. В GLR общие части правил, которые можно мемоизировать, просто сливаются в один вариант на данном участке, и эта общая часть протягивается одним экземпляром ДКА. Потрать 5 мин хотя бы на Вики: http://ru.wikipedia.org/wiki/GLR-%D0%BF%D0%B0%D1%80%D1%81%D0%B5%D1%80
Ну, ты прямо всех окружающих школотой считаешь. Пойми мы все это знаем не хуже тебя. Но даже чтобы "протягивать" что-то тебе нужно строить каую-то структуру в памяти которую потом интерпретировать по разному в зависимости от встеченых "цепочек". Ну, так и в случае ПЕГ тебе никто не запрещает делать так же. Только вместо неявных структур придется создать явные.
VD>>Не малая стоимость, в общем-то. В прочем, теоретических рассуждений можно построить много. Ты тут уже не раз хвалил свой парсер. Давай проведем простой эксперемент. Воссоздай парсер шарпаа который на выход выдаст АСТ. Сделаем тест в котором сравним полученное АСТ (чтобы видеть, что никто не врет) и сравним скорость разбора.
V>Нет, мы сделаем что-то попроще для начала. Моя реализация не является генератором парсеров общего назначения, а была заточена под специфику, которую описал.
Ну, специфику ты не описывал. Похоже что у тебя просто ничего нет, а ты банально трепишся на основании своих теоретических знаний.
V> Можно было бы взять какой-нить другой GLR, например DParser, но это будет непонятно, что мы меряем, бо от реализации много чего зависит, не только от алгоритмов.
Главное что это будет не чесно, так как ты трепался о своем супер-пупер-парсере, а по факту его нет во все.
В прочем, сравнение с любым GLR на одном железе и одной задаче будет интересно. Особенно интересно сравнение с SGLR. И уж совсем интересно с SGLR генерирующем парсеры под дотнет.
В общем, любое реальное сравнение интересно.
V>>>Теоретически. А фактически — выборка по одной и той же таблице, один и тот же входной поток в кеше, и т.д., а на всё это тратится грубо 90% работы ДКА, и 10% — собственно переход. Т.е. там каждый параллельный вариант грубо требует +10% затрат.
VD>>Вот это и есть — теоретически. А практически — тормоза .
V>Да нет, по замерам два паралельных ДКА, работающих по одной и той же цепочке, не сильно добавляют в сравнении с одним ДКА. Т.к. основная работа не по состояниям ходить, а данные подавать. К тому же, у меня идет преобразование алфавита (рядом описал), и оно однократное (общее) для всех параллельных ДКА.
Это все треп. Как только начинаются измерения, то получаются тормоза.
В общем — prove it!
V>Коэффициент размера памяти для кеширования от длины цепочки какой?
4 байта * на количество правил имеющих обработчики. Это что касается нашего решения.
VD>>Любой КА плохо расширяем. Даже то что у тебя отдельный лексер — это уже усложнение расширяемости.
V>Есть безлексерные и именно они расширяемые.
Динамически? Ой врешь! Можно ссылку на подобное чудо?
V>НКА расширяемы таки без малейших проблем, на то они и НКА.
НКА — это приговор производительности. Подозреваю, что SGLR — это не просто тормоза, а дикие тормоза.
V>Не зря его строят по регулярным выражениям, например, бо там кажде новое распаршенное выражение именно что расширяет "накопленный" на каждый текущий момент НКА.
Не зря, конечно! Нет средств построения ДКА по регуляркам, вот и строят НКА. Если потом его в ДКА преобразовать, то можно добиться высокой скорости. Если нет, то будут тормоза как в дотнетных регексах, котоыре даже в скомпилированном виде рвутся в клочья не оптимизированным ПЕГ-ом (как утверждает создатель темы).
VD>>Вот тебе задачка из реальной жизни. Есть язык — Nemerle. Он парсит входной поток и если обнаруживает открытие пространства имен, то импортирует новые правила (описанные в виде макросов). Ну, и что на ходу будешь перестраивать свои НКА? А что если экспонента получится?
V>НКА не перестраиваются, а достраиваются.
Что в лоб, что по лбу.
V>И та же версионность, что в AB-дереве, вполне организуема. НКА — это же модульность. Каждый отдельный переход может вести в свой модуль.
Ну, да. Вот только НКА — это возможная экспонента и тормоза в общем случае.
VD>>А НКА — это еще и приговор производительности. И я тогда вообще не понимаю о каких таблицах ты там говоришь, если у тебя НКА.
V>Дык, НКА тоже имеют табличную технику реализации.
Ой, как интересно! Многомерные таблицы? А потом что толку с таблиц если асимптоматика алгоритма уходит в экспоненту в некоторых случаях?
V>Там всей разницы, что по каждому нетерминалу у нас может быть не одно следующее состояние, а более одного. Т.е.
Ну, и что тогда эти таблицы дают? Или ты хочешь поспорить с наукой?
V> происходит fork. При этом, что характерно, обычно идет "динамическое" равновесие. Новые ветки создаются, старые отмирают. На 99% участков в реальных данных вообще идет одна ветка, т.е. эти участки пробегаются как ДКА.
А те что нет, иногда пробегаются за время жизни вселенной?
V>Тормоза в рассматриваемых мною GLR исключительно были в постоянном динамическом выделении/освобождении памяти для каждого узла дерева разбора.
Ты очередной раз гонишь! Ели там НКА, то память будет интересовать очень редко. Потом если память надо занимать, то это так же проблема алгоритма. В нашем алгоритме память динамически занимается только (сюрприз!) для AST!
V> Даже, если оно на GC.
Ой, а где же она тогда занимается? Не в стеке ли? Сколько же памяти надо занимать в стеке чтобы добиться тормозов?
V>Я лишь только за счет стека переиспользуемых объектов ускорил начальный вариант более чем в два раза для дотнета.
Ну, и о чем это говорит? Да ни о чем! Где цифры то?
V>Там же смешные затраты на каждый шаг (переход по каждому из ДКА, их обычно 1-3 идет в параллель, по крайней мере в моих сценариях), и вся механика вокруг единичного шага начинает влиять на общую производительность.
Опа! А тут у тебя в расуждениях попер ДКА. Ты уж давай как определись! Или у нас динамическая расширяемость и НКА, или у нас ДКА с параллельными переходами.
VD>>Весь кайф PEG-а заключается в том, что он идеологически очень хорошо расширяется. Каждое правило по сути отдельный парсер. Для динамического расширения нам всего лишь надо сделать правило приоритетного выбора массивом и тупо дергать подправила из него.
V>Ну? А массив переходов в НКА должен быть не расширяем, что ли?
Опа! А вот у нас снова НКА по пер! Супер! Демагогия на марше!
Потом какие на фиг массивы? Ты прикинь, открылось пространство имен... нам надо считать список расширений и для каждой точки расширений перестроить эти самые таблицы? Да это же и есть динамическое занятие памяти. Остается только уповать на то, что будет не много вложенных пространств имен где могут открываться пространства имен, и что в языке будет нельзя открывать пространства имен внутри классов и методов.
V>Я уже говорил, что мне не нравится в ПЕГ. Невозможно по правилам, содержащим приоритетность, вывести св-в грамматики.
Да мы слышали это. И нам это тоже не нравится. Вот Вольфхаунд хочет с этим побороться. Хочет вместо приоритетного выбора сделать выбор самого длинного правила (победителя). Может у него это и удастся (без серьезного снижения производительности).
Тогда туда, потенциально, можно будет и LL(1)-автомат прикрутить. Только вот эта идея опять таки несрастается с расширяемостью.
А вот у ПЕГ-а с расширяемостью все просто замечательно. Даже если преобразовать оператор приоритетного выбора в оператор выбора самой длинной последовательности все равно с расширяемостью будет все ОК. Ведь каждое правило все равно будет отдельным парсером. И все что нам надо будет сделать для расширения парсера — это запихать альтернативый в массив. Это элементарно!
V>Ну и опять же, я вас не призывал сменить технику своего парсера, а обратил на вполне конкретный маленький такой сценарий инлайна. И сказал, на что он похож. И как с этим борются.
Ты просто вдрызг не понимаешь что там под копотном. Потому твои слова просто бессмысленны.
V>>>Для начала было бы неплохо на чем-нить попроще. VD>>По проще тебе же не выгодно будет.
V>Мне выгода нужна по как можно меньшим временным затратам на наши игры. Это же все интереса ради, более не для чего. В конкретном применения я взял максимально подходящую технику. Сейчас всего лишь любопытно пройтись по более-менее общим задачам.
Дык просто не надо делать утверждения которые ты не проверял, и тратить время на их доказательства не придется. А раз уж сделал, то было бы логично хотя бы проверить их.
V>Дык, я от того и привел GLR, что ему пох какая грамматика. И не обязательно воспроизводить всю грамматику для тестов, что за максимализм? Можно взять конкретный небольшой кусок, который не приводится, скажем в LL(1), и гонять на нем.
GLR красив в теории. Вот только на практике у него своих проблем хватает. От того пока что ни одной действительно быстрой реализации сделано не было. Ну, или их результаты не обнародованы.
Плюс, как тебе уже неоднократно сказали, GLR плохо расширяется. Танцы с бубном творимые при его расширении приводят к тому, что теряется эффективность.
VD>>В прочем, можешь для начала тот же Джейсон повторить.
V>Я тоже уже подумал, в выходные покумекаю, как его прикрутить.
Да там работы на вечер. По крайней мере на нашем генераторе Ziaw создал его именно за вечер.
V>>>Сколько времени заняла разработка у вас этой грамматики до текущего варианта?
VD>>Неделю времени неподготовленного человека.
V>Вот, дофига, если честно. Больше, чем пока могу себе позволить. Мне же ее перелопачивать для своего парсера придется, бо там по минимуму и со спецификой.
Ты в этом форуме куда больше времени проводишь. А от этого какая ни какая, а польза будет.
V>Заказной. Качество понравилось.
Тут где-то рядом давали ссылку на явно тормозную реализацию ПЕГ-а на Шарпе. И тот кто довал тоже сказал, что ему и скорость, и качество очень понравились. Это не критерий. Критерий — это Мб./сек. на конкретной грамматике и конкретных входных данных.
V>С задачей ускорения разбора и линковки EDI док-тов справился. В среднем прирост был в 3-10 раз от их "самописного" варианта. Правда, как всегда без NDA не обошлось.
Это все сравнение цифр. В 10 раз больше чего? А может можно было в 200 раз?
NDA у тебя на прикладной код. Кстати, по нашим законам автором всегда остается тот кто что-то написал или сделал. А контора может иметь только права на распространиние. Ну, и результат работы генератора парсеров уж никак под NDA попадать не может. Ты же не генератор на сторону отдаешь?
VD>>Плюс ты сможешь не на словах, а на деле доказать применимость GLR, что будет несомненно интересно в научных кругах.
V>Да он обжеван тысячекратно.
Да ну? И где замеры производительности на которых GLR не сливали бы?
V>Где он плох, а где хорошо — известно и так. Любые его обсуждения начинаются с примерно таких слов "на большинстве грамматик он имеет быстродействие O(n)".
Это пустобехство которым любят заниматься в научных и околонаучных кругах.
У Пакрата тоже быстродействие O(n). Причем не на большинстве грамматик, а на всех! Только вот это же асиптоматика. А на практике результат плачевный. Скорость линейно низкая.
Потом "на большинстве грамматик" — это тоже треп. На джейсонах — возможно. А на грамматиках современных ЯП да еще и не фактаризованных, да с построением АСТ все выглядит совсем по другому.
V>Но засада в том, что на худшем случае у него быстродейтсвие, как у Эрли. В общем, ничего нового тут не откроешь. Он специфичный и ОЧЕНЬ хорош для одних сценариев и крайне плох для других. Бесплатного сыра не бывает.
Эрли тоже линеен для простых грамматик. Вот только у него те же пролемы что у Пакрата, только еще хуже.
VD>>Твои же некомпетентные советы только раздражают (или веселят). Мы же те советуем тебе как оптимизировать или развивать твой GLR-парсер?
V>Чего там развивать? Две недели на разработку, две недели на профайлинг, и проект закрыт.
Языком оно всегда так. Продай свой парсер МС. А то они что-то по старинке парсеры вручную пишут.
VD>>А то ты говоришь о том, что Вольфхаунд гнет пальцы, а сам со стороны выглядишь не лучше.
V>Ну, в отличие от, я не делаю мину непонятной сакральности исследователя неведомого.
Да более чем. Твои слова в адрес нашей работы сильно переплевывают слова Вольфхаунда. Он то просто максималист...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>А что значит "самый длинный"?
Элементарно. Берем два правила. Пускаем их по очереди (или параллельно) и смотрим кто из них съел большее количество входной строки. Кто съел больше, тот и папа.
V>Я понимаю как оно работает для цепочки терминалов по жадному алгориму лексера. Но какой физический смысл имеет "длина" двух взаимно-рекурсивных правил, например? Да еще, которые не содержат терминалов, а описаны через промежуточные нетерминалы?
Если правила не зацикливаются (т.е. грамматика корректна) то по окончании разбора позиция разбора сдвинется на х и у. Далее сравниваем х и у и вычисляем победителя.
Предположим, что правило Х разбирает 10 символов входной строки, а правило У 20. В этом случаем победителем будет У.
Если у нас PEG и мы поставим правила так: Х / У, то У с огромной вероятностью (а иногда на 100%) никогда не сможет сопоставиться. Оно просто будет всегда затенено. По сему скорее всего это ошибка в грамматике. Ошибка не страшная, так как и при ней все может работать верно. Но все же. Накопление такой байды приведет к тому, что грамматика превратится в грязь.
V>Ведь по классике, это же не лексер, который разбивает входную цепочку символов. Парсер распознает поданную цепочку целиком или не распознает. А если у нас несколько вариантов удачного распознавания одной и той же цепочки (т.е. несколько вариантов AST), какой из них самый длинный?
Классика тупо не работает как надо. Она только на словах работает. А люди много десятилетий пишут парсеры языков вручную.
VD>>Но что-то, лично мне, как-то не верится, что полный перебор не даст заметного замедления. Но тут только тесты могут показать кто прав.
V>Ну так и есть. Но это от характера данных зависит, бо самый худший вариант вырождается в Эрли в своей наивной реализации
Не вырождается, так как есть мемоизация и ДКА на листьях (где перебора вариантов уже не будет). Ну, а характер данных известен — это грамматики реально существующих языков программирования. Они очень близки друг к другу.
V>(немного оптимизировано дерево вывода в сравнении с Эрли, но не сильно спасает).
Эрли требует создания кучи динамических данных. Это не приминимый на практике алгоритм. Наш же алгоритм может жить вообще без динамического заема памяти. На практике мы занимаем память для циклических правил, чтобы накапливать результаты разбора. Но это не сильно влияет на производительность, так как там применяются динамические массивы. Да и на фоне создания АСТ это не такие уж и большие затраты.
V>Попыток парсить параллельными парсерами ЯП было полно, и народ вовсю копает именно в этом направлении. Ведь параллельные парсеры жуют любые грамматики без ограничений. Им не нужна факторизация, они не боятся рекурсии. А главное — поддаются нехилой автоматической оптимизации.
Народ копает в разных направлениях. Если бы был явный лидер в желтой майке, то этих раскопок не было бы.
GLR имеет ряд минусов. Возможно и на его базе путем кучи оптимизаций можно добиться хороших результатов, но пока что оных не видно. Все отчеты о скорости разбора нетривиальных грамматик плачевны. Динамическая расширяемость для GLR вообще камень преткновения. Тут или тормоза, или отсутствие расширяемости.
V>И направления исследований в этой области — это улучшение того самого "worst case", т.е. для сильно-неоднозначных языков.
Ну, это же ученые! Им же реальная жизнь не интересна. Они имеют тормозную реализацию и улучшают у нее асимптоматику для случаев которые в природе могут и не встречаться. А меж тем сам парсер полное дерьмо. Но им на это плевать.
V>К примеру, есть SRNGLR, он парсит SASL в 8-10 раз быстрее, чем просто SGLR (для которого SASL — хорошая демонстрация имеющихся проблем в GLR). По более "привычным" языкам: Питон, например, парсится в 3-5 раз быстрее. Тоже нехилый такой буст.
Быстрее чем что? Это все общие слова. Есть хоть какие-то измерения?
И опять же SRNGLR ведь скорее всего расширяемость динамическую не поддерживает. Так?
V>Опять же, отказ от AST, и использование вместо него в сигналах Parser Tree заметно поднимает производительность. Только опять без эмоций!
The output of a succesfull parse is a parse tree in one of the following
formats: AsFix1, AsFix2 or AsFix2me. Libraries and descriptions for these three
formats are available from http://www.cwi.nl/projects/MetaEnv in the
PT support package.
Из чего делаем вывод, что у них не только генерируется АСТ, но и генерируется только в одном из возможных форматов.
V>Это не я придумываю.
Как видишь, ты.
V> Реально модно стало уходить от построения АСТ прямо в парсерах.
Ты реально гонишь. Просто у самого подхода GLR есть трудности. На самом деле почти все языки что ими парсят являются однозначными. А GLR не умеет сразу создавать однозначных деревьев. У него есть тупиковые ветви, а есть неоднозначное ветвление. Вот им и приходится вводить самопальные промежуточные структуры. А на это ведь уходит и память и время.
У нас все просто. Строится всегда одно дерево. Если в результате отката его часть теряется, ну и фиг бы с ним. Все равно мы всегда создаем дерево сверху вниз и имеем оду его копию.
V>Зачем выделять в куче лишние объекты, если можно переиспользовать Parser Tree?
Дык Parser Tree и есть лишний объект. Это и есть АСТ причем специфичное для парсера.
V>Вся информация о взаимоотношениях разобранных правил там сохраняется — бери, пользуйся. Только вот из кучи ничего лишнего не выделяется.
Вот на это все и уходит время.
VD>>Народ может делать все что угодно. У нас конкретная задача. Нам нужен быстрый и одновременно динамически расширяемый парсер для ЯП. Конечна цель создать новую реализацию макросов Немерле (или языка-наследника).
V>А у вас одна и та же кодовая база для рассмотренного PEG-макроса и для динамического расширения будущего парсера Nemerle? Там же разная техника исполнения парсера должна быть, как мне видится.
Я не понял что за кодовую базу ты имеешь в виду. PEG-макроса читают грамматику из атрибута, преобразует ее в дерево состоящее из варинтных типов (АСТ грамматики), а далее начинает с ним играться. В итоке генерируется код парсера. Примерно тоже самое будут делать новые макросы. Только АСТ грамматики они будут брать из другого места (из описания макросов).
Так что код будет повтоно использоваться. Но не на 100%.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Корневое правило JSON должно выглядеть так:
CS>
CS>File = Sp Value Sp;
CS>
Скажу больше. Для ПЕГ-а это тоже не верно. Такая грамматика распознает корректный префикс и тупо пропустит некорректный суфикс. Чтобы эта грамматика работала как надо еще нужно отсечение некорректного суфикса сделать. Что-то типа:
File = Sp Value Sp !Any;
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>Бранч и форк в DVCS по сути одно и то же, и там и там делаются разные ветки разработки и там и там их потом можно слить. На гитхабе есть штатные механизмы сделать пулреквест в проект из форка. Хозяин проекта пулит к себе в репо изменения из пулреквеста.
VD>Ну, вот это гимор. Совместной разработки при этом уже не будет. Не уж то вы не понимаете, что чем дольше не делается слияние, тем сложнее это слияние сделать потом.
Это нормальный подход для ситуации — 1 разрабатывает, другие помогают. Если активно разрабатывает несколько человек одновременно им лучше просто дать права на репо.
VD>Такой подход может и оправдан когда когда кто-то обкатывает новые идеи. Или когда кто-то со стороны хочет помочь проекту и при этом этому кому-то доверия мало. При этом этот подход заменяет брэнчи в SVN. Но для реальной работы нескольких человек над одним проектом он не пригоден.
Здравствуйте, WolfHound, Вы писали:
WH>Тут я с ИТом согласен. Тулзы для меркури УГ.
У меня абсолютно та же оценка, но про гитовские IT рекомендует Git extensions.
1. Как там сделать то, что я делаю чаще всего: глянуть то, что незакомичено.
2. Как ревертнуть файлы?
3. Как сделать pull/update с одновременным merge рабочей копии?
Все эти вещи делаются в один-два клика в ртутном.
4. Это уже не к тулзам, это к гиту, никак не могу понять, на кой ляд там бранчей столько: master, origin/master, origin/HEAD?
WH>Да и гугл код с меркури похоже толком работать не умеет.
Здравствуйте, WolfHound, Вы писали:
WH>То что на реальных исходниках не проявился соответствующий баг ни о чем не говорит. WH>Тесты не являются доказательством работоспособности.
Я толстый член клал на всех теоретиков. Тесты и реальное использование это единственно что показывает пригодность продукта. А ваши доказательства — это треп на форумах.
Я видел много парсеров которые строились на технологиях которые вроде как не допускают подобные ошибки, но все они почему-то падали на реальных файлах. А вот рукописные парсеры которые вообще нельзя хоть как-то проверять кроме как тестами, работают приемлемо. А ведь в реальных продуктах на сегодня в основном рукописные парсеры и используются.
VD>>Простейший пример разрешение неоднозначности с if/else и if (без else). В одном случае надо выбирать ближний else, в другом — нет. WH> Если ты поставишь if до if/else то if/else у тебя никогда не сматчиться.
А про предикаты и откаты ты уже забыл? Грамматика вполне может выглядеть как-то так:
Будь любезен быть по увежительнее.
WH>Это кстати еще одно доказательство того что приоритетный выбор ты не понимаешь.
Ты сам себе доказательства придумываешь и сам же в них веришь.
WH>Он вообще крайне не интуитивный.
Его надо понимать. Это да. Ошибку сделать тоже не сложно. Но это с любым построителем парсеров так всегда было.
VD>>Их масса. Первая — нет прав на комит. Я могу разве что-ли локальный клон сделать. WH>И правильно. Нехрен лить в основной репозиторий что попало.
А кто будет решать что попало, а что нет?
VD>>Вторая — разные репозитории. Если мне требуется за одно поправить компилятор, то нужно делать два комита. Это же создает проблему вынимания исходинков и сборки в один клик. WH>А меня это бесит. WH>Втянули прототип парсера в сборку и теперь блин не поломай WH>Даже локально поломать нельзя, ибо компилятор обновлять не получается.
Да ломай сколько влезет. Только брэнч создай. Пока что в твоем репозитории вообще никаких существенных изменений нет. Там один рефакторинг. И это за 4 месяца.
VD>>Следующая проблема — дополнительное обучение. WH> минут за 10-20 разобрался с тем, что к чему.
Тебе может 20. Мне или кому-то неделю убить. В прочем, на фоне других проблем это мелочь. Одно то что проект нельзя собрать в один клик уже, как ты выражаешься, бесит.
VD>>Видимо ты неверную терминологию используешь. Вилка (fork) это, как я понимаю, полное дублирование проекта. WH>И замечательно.
Ну, то есть ты хочешь работать над этом проектом в гордом одиночестве и не хочешь чтобы им кто-то пользовался до релиза (который неизвестно будет ли вообще, ведь новые идеи могут появиться)?
VD>>Искользуется когда кто-то хочет создать свое ответвление. А когда речь идет о совместной работе, то делают ветку (как я понимаю это у них называется брэнч). А для этого нужны права на репозиторий. WH>Это ты нихрена не понял.
Опять хамишь. Тебя от этого прет?
WH>Это представление у тебя сложилось по тому что гуглокод толком не умеет работать с клонами. WH>Правильный метод это именно работа в своем клоне.
Посмотрел. 1 открытый 0 закрытых.
Опять же у ИТ контрибьютеры по мелочи дописвают. Если же делать что-то большое, то без постоянных слияний остальные будут с тобой конфликтовать. И их жизнь привратится в постоянные обновления по твоей ветки и постоянные же разрешения конфлитов. Если работа ведется, то брэнчи самое то. Сливай по мере законченности и все будет ОК.
Иначе ты будешь писать один. Примерно как ИТ.
Ты вон за работу уже 4 месяца никак взяться не можешь. Плюс еще к тому же гонор свой показываешь по каждому поводу. Потому нет никакой гарантии, что ты будешь мерджить все вовремя и без выкрутасов.
Я тоже не очень то хочу брать на себя работу по слиянию. Потому как на это нужно ой сколько времени тратить и делать это постоянно. Куда проще проводить ревизию слияний тех же веток. Если что всегда можно откатить эти изменения.
Ну, и главное это же ведь теперь надо за двумя проектами следить и оба синхронизировать. А если еще кто-то тдельный репозиторий заведет? Повеситься можно будет.
WH>Если тебе так хочется работать толпой, то можно и толпой. WH>Добавляешь в свой репозиторий collaborators и все. WH>Причем в форк (в отличии от гуглокода) тоже можно добавить.
Это конечно хорошо. Но боюсь через некоторое время будет не ясно что за репозиторий главный.
VD>>Я в курсе. Только это не очень удобно для реальной работы. WH>Как видишь кучу народа с этим прекрасно работает.
Не вижу кучи.
WH>Более того это очень удобно для "одноразовых" коммитеров.
Ага. Именно для них и удобно. А для членов команды все же удобнее брэнчи и просто комиты, если делается мелкая фича.
Жить на идеях полного недоверия всем себе же дороже.
WH>Они ни кого не спрашивая делают свой форк. WH>Потом правят что хотят. WH>А потом в пару кликов отправляют запрос на интеграцию в основной код.
Согласен — это здорово. Не хочется повторяться. Я уже все сказал. Кроме этой вкусности появляется и ряд проблем. И на них ты почему-то закрываешь глаза.
VD>>Многие просто не будут начинать что-то делать, если их работу будут выбрасывать. WH>Если это правки по делу, то никто ничего выбрасывать не будет.
Ты погляди как ты иной раз в форумах людям отвечаешь. Если ты так же будешь судить о чужой работе, то отобьешь желание почти у всех. Я вот куда мягче был, но, все же, желание отбил у многих.
Короче для одноразовых комитеров, для людей к которым мало доверия и перед релизами такая политика оправдана. Но для командной работы над проектом это перебор. Постоянным участникам проекта к которым есть доверие надо давать больше прав. Лучше объяснить ответственность и если что сделать замечание. Опять же все будет проще, так как замечание будет устранять кто-то другой, а не тот кто будет обязан слияния делать.
WH>Если правка по делу, но кривая то будут высказаны пожелания по исправлению. И после исправления правка будет принята. WH>А если там мусор то извините.
Это само собой.
Вот только если изменений будет много, что характерно для постоянных комитеров, ты все равно не сможешь найти все ошибки и они будут вылезать уже после твоего же слияния. А слияния усложнятся, так как их объемы увеличатся.
По уму надо посмотреть как делают в командах того же Линукса. Там ведь есть и море контрибьюторов и центральная команда.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Это нормальный подход для ситуации — 1 разрабатывает, другие помогают.
+1
Z>Если активно разрабатывает несколько человек одновременно им лучше просто дать права на репо.
+1
И я о том же.
VD>>Такой подход может и оправдан когда когда кто-то обкатывает новые идеи. Или когда кто-то со стороны хочет помочь проекту и при этом этому кому-то доверия мало. При этом этот подход заменяет брэнчи в SVN. Но для реальной работы нескольких человек над одним проектом он не пригоден.
Z>+1
Ну, так и не надо ссать против ветра.
А главное, что уж если переходить, то надо все проекты на одну платформу переносить.
Кстати, у меня к тебе вопрос один. Мы тянем за собой другие проекты через SVN-свойства. Как быть с ними в Гите и Меркури?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>АФАИК оба умеют работать с SVN как с родным. HG точно (сам пользуюсь). VD>Т.е. я могу автоматом при пуле обновлять и связанные репозитории, например, с кодплекса?
Ну именно в таком сценарии я не использовал. Просто чтобы не ставить зоопарк клиентов подключаюсь к SVN через hg/TortoiseHG. Думаю как ты описал должно рабтать без проблем.
Здравствуйте, Ziaw, Вы писали:
Z>1. Как там сделать то, что я делаю чаще всего: глянуть то, что незакомичено. Z>2. Как ревертнуть файлы?
Из окошка коммита.
Один раз его открыл, а дальше только кнопочку обновить жмешь.
Z>3. Как сделать pull/update с одновременным merge рабочей копии?
В окошке pull нужно поставить галочку "Merge remote branch to current branch"
Галочку он запоминает.
Z>4. Это уже не к тулзам, это к гиту, никак не могу понять, на кой ляд там бранчей столько: master, origin/master, origin/HEAD?
Ну кабе master это твой локальный главный бранч.
origin/master это главный бранч репозитория с которого ты стянул код.
Кто такой origin/HEAD я не знаю. У меня его нет.
Вроде все логично.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Ну и что ты написал?
Следи за руками:
Парсим if.
Проверяем есть ли далее else
Если есть то откатываемся парсим if/else
Проще говоря выбираем ближний else.
Что полностью равнозначно стратегии побеждает длиннейший.
VD>Ты сам себе доказательства придумываешь и сам же в них веришь.
Пока что ты только тем и занимаешься что подтверждиешь мои выводы.
VD>А кто будет решать что попало, а что нет?
Я. Если кому-то не понравлюсь я, то он может завести свой репозиторий и мержить туда все что захочет.
VD>Да ломай сколько влезет. Только брэнч создай.
Вот я и создал бранч куда никто без моего разрешения не влезет.
VD>Пока что в твоем репозитории вообще никаких существенных изменений нет. Там один рефакторинг. И это за 4 месяца.
Я его только два дня назад создал. Смотри на даты ради разнообразия.
А начинать переделку нужно с выноса мусора.
VD>Тебе может 20. Мне или кому-то неделю убить. В прочем, на фоне других проблем это мелочь. Одно то что проект нельзя собрать в один клик уже, как ты выражаешься, бесит.
Проект парсера можно.
И это отдельный проект.
Никакого отношения к немерле не имеющий.
VD>Ну, то есть ты хочешь работать над этом проектом в гордом одиночестве и не хочешь чтобы им кто-то пользовался до релиза (который неизвестно будет ли вообще, ведь новые идеи могут появиться)?
Я не хочу чтобы в проекте появлялся непонятный код который не ясно что и как делает.
Я просто хочу порядок.
Я что так много хочу?
VD>Посмотрел. 1 открытый 0 закрытых.
А ты фильтр зактрытых отключи.
VD>Опять же у ИТ контрибьютеры по мелочи дописвают. Если же делать что-то большое, то без постоянных слияний остальные будут с тобой конфликтовать. И их жизнь привратится в постоянные обновления по твоей ветки и постоянные же разрешения конфлитов. Если работа ведется, то брэнчи самое то. Сливай по мере законченности и все будет ОК.
Форк это бренч. Просто чуть более изолированный.
VD>Иначе ты будешь писать один. Примерно как ИТ.
Да я и так один пишу.
Серьезные правки что вносили в парсер мне приходилось переделывать чуть менее чем полностью.
VD>Это конечно хорошо. Но боюсь через некоторое время будет не ясно что за репозиторий главный.
Вот только реальные проекты от этого почемуто не страдают.
VD>Не вижу кучи.
Ну как минимум на этом принципе живет ядро линуха.
Причем там иерархия репозиториев на верхушке которой сидит Линус.
VD>Ага. Именно для них и удобно. А для членов команды все же удобнее брэнчи и просто комиты, если делается мелкая фича. VD>Жить на идеях полного недоверия всем себе же дороже.
Ты так говоришь просто по тому что тебя испугал кривущий гуглокод и ты думаешь что форки это что-то страшное.
VD>По уму надо посмотреть как делают в командах того же Линукса. Там ведь есть и море контрибьюторов и центральная команда.
Вот только они живут по схеме что описал я, а не ты.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD> то мы имеем информацию о том для какого правила генерировался код и "по else" (т.е. при обломе правила) можем запомнить текущую позицию разбора в переменную ассоциированную с этим правилом. Но когда речь идет об оптимизированных правилах, код которых встраивается в код других правил и при этом еще и переставляется по много раз, определить что же за правило реально обломалось не выходит. Классический пример такого правила — это разбор ";" в грамматике C#. ...
А можно чуть поподробнее, не совсем понятно в чем проблема.
При инлайнинге ничего не теряется, а даже дублируется, размножается. Поэтому каждая ";" знает откуда она появилась — была с самого начала, или из какого правила оригинального варианта(до переделки) грамматики ее вставили. Эта информация статическая, часть парсера разбирающая input не должна ничего об этом знать. Когда правило обломилось, эта часть парсера возвращает для обломившегося правила ID его родительского правила, и индекс обломавшегося элемента. Потом другая часть парсера смотрит какое правило по индексу лежит и из какого правила исходного описания грамматики оно появилось.
В модифицированном варианте грамматики для каждого элемента внутри правила прописано откуда он появился.
Или я что-то не так понимаю?
Правда гитхаб более раскручен, подозреваю, что не зря. Но у меня к гиту предвзятое ощущение, он вводит лишние сложности на ровном месте. С другой стороны у IT ест опыт синхронизации репо на гитхабе и svn на google code.
Здравствуйте, Silver_S, Вы писали:
S_S>А можно чуть поподробнее, не совсем понятно в чем проблема. S_S>При инлайнинге ничего не теряется, а даже дублируется, размножается. Поэтому каждая ";" знает откуда она появилась — была с самого начала, или из какого правила оригинального варианта(до переделки) грамматики ее вставили. Эта информация статическая, часть парсера разбирающая input не должна ничего об этом знать. Когда правило обломилось, эта часть парсера возвращает для обломившегося правила ID его родительского правила, и индекс обломавшегося элемента. Потом другая часть парсера смотрит какое правило по индексу лежит и из какого правила исходного описания грамматики оно появилось. S_S> В модифицированном варианте грамматики для каждого элемента внутри правила прописано откуда он появился. S_S>Или я что-то не так понимаю?
Та посмотри в исходник, они строят ДКА как для лексера. Самиздат, короче. Но даже тут можно восстановить один уровень иерархии.
Здравствуйте, VladD2, Вы писали:
VD>С кем? С тобой? Ну, в общем-то с человеком говорящем о восходящем анализе при разборе PEG-грамматик действительно все ясно.
Для тех, кто начнет читать с середины.
Предыстория. Из грамматики, заданной в стиле PEG выделяются "куски", являющиеся регулярными подмножествами исходной грамматики. Проблема начинается в процессе подставновки вместо некоторых нетерминалов их тел в процессе оптимизации и склейки этих подмножеств в одно более мощное. В результате теряются промежуточные нетерминалы, которые были заинлайнены.
Осталось заметить, что данные подмн-ва правил обрабатываются не как PEG, т.е. никакого перебора не происходит, другими словами, внутри этих выделенных "модулей" используется алгоритм, который не-PEG. Хотя, использование таких алгоритмов внутри PEG — неотъемлимая его часть. Надо проникнуться спецификой. Итак, там алгоритм лексического разбора по ДКА. Осталось проанализировать, что сие значит. Если представить себе parser tree лексера, то оно будет ровно уровня 1: на верху будет нетерминал S0, а внизу будут все остальные целевые нетерминалы — "черные ящики", не разбиваемые на составляющие, т.к. промежуточные состояния ДКА не интересуют. И тут два очевидных наблюдения: 1 — восстановить можно только один уровень вложенности исходного куста, 2 — отображая технику разбора на parser tree, мы наблюдаем восходящий обход, т.к. идет не перебор вариантов, а непосредственное продуцирование нетерминалов по входной цепочке. Учитывая глубину parser tree, любой удачно-разобранный нетерминал ведет к успешности разбора, что и происходит при лексическом анализе.
В момент предложения применить другой восходящий алгоритм парсинга по ДКА, который сможет восстановить всю иерархию parser tree выделенного куста, как у быка на красную тряпку идет реакция "о ужас, какой еще восходящий алгоритм, если PEG — нисходящий". Напомню, речь идет о реализации участка, который и так уже парсится не-PEG парсером, и который и так работает аналогично восходящему разбору.
Здравствуйте, Klatu, Вы писали:
K>Достаточно обычного упреждающего чтения. Не вижу особой проблемы.
Что тебе позволило считать, что проблемы "особые"? Речь лишь о том, что подход "в лоб" на стандартных файловых ср-вах не так хорош, т.е. становится заметен.
V>>А "захардкожено" потому, что стоимость обработки результата заметно влияет на общую производительность, поэтому я избавлялся от виртуальных вызовов где только можно, т.е. интерфейс парсера вышел не абстрактным, а завязанным на конкретные прикладные типы — клиенты.
K>Виртуальные вызовы? OMG
Ну дык, калбеки в прикладной код надо же как-то подавать. Полностью динамически строящийся парсер должен иметь некое универсальное АПИ. В любом случае, вызов виртуальных методов не так критичен, как выделение памяти из кучи, даже если это куча GC.
В этом плане в дотнете всё очень печально, особенно когда надо делить входной поток на строки, требуемые для прикладной обработки. GC начинает все тормозить. Для него несколько сотен тысяч выделений в секунду — многовато. Поэтому на дотнете не так просто замерить производительность парсера в чистом виде. Тест должен быть относительно короткий, хоть на коротких текстах большая погрешность.
Вот тут и понимаешь, как удобно все-таки в С++ сделан строковый шаблонный интерфейс, что можно сделать любую его специализацию, например для того, чтобы класс строки ссылался на данные из чужого буфера. Т.е., чтобы обойтись без копирований и лишних выделений/освобождений памяти.
V>>Блин, сюда в день час потратишь, и то дофига. А это работа на несколько дней. Сначала надо узнать на чем-то несложном, будет ли смысл, после всех операций по убиранию хардкода.
K>За "несколько дней" можно написать парсер C вообще с нуля и полностью вручную.
Разумеется. Особенно, если "несколько", это неделя минимум, а не пара дней. Но вряд ли можно за это время сделать парсер, работающий по произвольному описанию.
K>PS В общем, очень хотелось бы посмотреть на реальный пример и его производительность в реальной задаче. Иначе это всё выглядит чистейшим пустозвонством.
О, дурной пример заразителен.
Смотри, привыкнешь.
Какие именно цифры смутили?.. чтобы я знал, каковы ожидания. Ну и тут
стоит пройтись предварительно, начиная от слов "Реальное ускорение" дает оптимальный выбор техники парсинга,. Чтобы не уподобляться Владу. И не цепляться так за C/C#, если мне вдруг захочется потягаться на чем-то другом.
Здравствуйте, VladD2, Вы писали:
VD>Элементарно. Берем два правила. Пускаем их по очереди (или параллельно) и смотрим кто из них съел большее количество входной строки. Кто съел больше, тот и папа.
Блин, всё время упускаю из виду эту "модульность".
Понятно.
VD>Если у нас PEG и мы поставим правила так: Х / У, то У с огромной вероятностью (а иногда на 100%) никогда не сможет сопоставиться. Оно просто будет всегда затенено.
Ну, это первое, за что ругают ПЕГ. Но как я понял из "ихних" форумов, такую ситуацию несложно валидировать автоматически еще на этапе построения парсера и выдавать ошибку.
Проскакивало еще мнение, близкое к обсуждаемому: задавать все правила как ИЛИ (т.е. как равнозначный выбор), затем выделять общие части после приведения, сортировать вхождения ИЛИ таким образом, чтобы самые длинные (поглощающие) подправила шли первыми, и заменять потом ИЛИ на приоритетное ИЛИ в стиле ПЕГ. Итого, самое длинное правило попытается быть разобранным самым первым, т.е. будут достоверно сохранены св-ва исходной грамматики, хотя будет использоваться техники разбора ПЕГ.
Но самое длинное правило не означает самую длинную цепочку.
V>>Ведь по классике, это же не лексер, который разбивает входную цепочку символов. Парсер распознает поданную цепочку целиком или не распознает. А если у нас несколько вариантов удачного распознавания одной и той же цепочки (т.е. несколько вариантов AST), какой из них самый длинный?
VD>Классика тупо не работает как надо. Она только на словах работает. А люди много десятилетий пишут парсеры языков вручную.
Только те, кто может себе позволить такие ресурсы. А так пишут на яках, бизонах, кокорах и прочих, коих много.
V>>(немного оптимизировано дерево вывода в сравнении с Эрли, но не сильно спасает).
VD>Эрли требует создания кучи динамических данных. VD>Это не приминимый на практике алгоритм.
Применяют, с доработками. Не все грамматики укладываются в ограничения популярных техник парсинга.
VD>Наш же алгоритм может жить вообще без динамического заема памяти. На практике мы занимаем память для циклических правил, чтобы накапливать результаты разбора. Но это не сильно влияет на производительность, так как там применяются динамические массивы. Да и на фоне создания АСТ это не такие уж и большие затраты.
Динамическое создание AST вообще не позволяет замерить собственную производительность парсера. GC не может некоторое долгое время агрессивно выделять память, начинает заметно тормозить. У меня недавно дошли руки погонять 4-й дотнет на предмет ускорения GC. Не особо. Результаты таковы: на коротком тесте простейший токенайзер, переводящий цепочки символов в String (без всяких вычислений) упирается в GC на уровне 100 МБ/сек. А ведь машинка у меня довольно серьезная. Через 2 секунды первоначальный показатель падает вдвое, а еще через три секунды — втрое от первоначального, оставаясь потом на уровне ниже 28-29 МБ/сек. Простое создание затем узлов АСТ на бинарных узлах попускает всё на уровень 8-12 МБ/сек. И это при том, что вообще никаких вычислений не происходит и подготовленные данные гоняются по кругу в памяти. Кол-во сохраняемых промежуточных токенов — не более 300к. Итого, дотнет позволяет на моей машинке работать примитивному токенайзеру со скоростью 250-300 МБ/с (если реультат не переводить в String и прочие АСТ), но при задействовании GC скорость падает до 8-12 МБ/с.
Вот почему я пользую пулы объектов даже в дотнете. И когда я в ответ на 4 MB/c с некоей иронией спрашивал, что же вы там замеряете, я имел ввиду не C#, а вопрос стоял так: измеряете работу GC, или вам таки интересно было померить собственные алгоритмы? Похоже, что быстродействие собственных алгоритмов вы пока не мерили. Это тоже причина не доверять Вольфхаунду в его типичных резолюциях "это ни на что не влияет". Я делился только теми приемами, которые у меня реально влияли. Просто у вас они влияют в рамках погрешности измерений производительности GC.
И вот диллема: в моей задаче, связанной с документооборотом, токены были по нескольку десятков символов, поэтому показатели в MB/c были относительно неплохие (50-80MB/c). Если перейти на тест с токенами длиной 1-8 байт (на примере среднестатистического JSON), то мерить я уже буду исключительно работу GC. Пока еще думаю, что с этим всем делать, и не попробовать ли переписать на нейтив, хотя бы соревнований ради.
V>>К примеру, есть SRNGLR, он парсит SASL в 8-10 раз быстрее, чем просто SGLR (для которого SASL — хорошая демонстрация имеющихся проблем в GLR). По более "привычным" языкам: Питон, например, парсится в 3-5 раз быстрее. Тоже нехилый такой буст.
VD>Быстрее чем что? Это все общие слова. Есть хоть какие-то измерения?
Быстрее в колв-ах операций на единичный входной символ. Теперь понимаешь, почему так? Как ты говоришь "учОные"... они не такие уж дураки. Вылизывать реализацию по имеющейся асимптотике — это работа для нас, чернорабочих.
VD>И опять же SRNGLR ведь скорее всего расширяемость динамическую не поддерживает. Так?
Поддерживает исходный SGLR, этот уже нет. Кроме комбинаторных парсеров всерьез никто не поддерживает расширение. ПЕГ недалеко от последних ушел.
VD>Ты опять что-то гонишь. Вот я сделал поиск по SRNGLR и нашел вот это: VD>Из чего делаем вывод, что у них не только генерируется АСТ, но и генерируется только в одном из возможных форматов.
Во-первых, это уже другая тема. Во-вторых, Parser tree не сильно от AST отличается. Только тем, что Parser tree не содержит прикладных вещей, а исключительно описывает структуру правил. Но основное отличие тут в используемой динамической памяти. Если AST строят целиком по мере разбора и запоминают, то узлы ParserTree статичны, динамичен только путь к текущему правилу (вся "динамика" лежит обычно в массиве, длина которого равна мксимальной глубине дерева правил). Понятно, что для сохранения чего-то куда-то в файл надо сохранять именно целиком, но для прикладного кода, работающего в оперативном режиме — нет.
VD>Ты реально гонишь. Просто у самого подхода GLR есть трудности. На самом деле почти все языки что ими парсят являются однозначными. А GLR не умеет сразу создавать однозначных деревьев. У него есть тупиковые ветви, а есть неоднозначное ветвление. Вот им и приходится вводить самопальные промежуточные структуры. А на это ведь уходит и память и время.
Ну, некий коэф неоднозначности грамматики можно прикинуть по коэф неоднозначности переходов эквивалентного НКА. В моих случаях он был ~1.05. Промежуточных "самопальных" структур никаких. Есть пул ДКА (каждый — это value-type с двумя полями), есть граф ссылок на parser tree, почему граф — потому что разветвления на неоднозначностях. На однозначной грамматике выживает в конце одна ветка. В процессе разбора узлы тупиковых веток возвращаются в пул, что позволяет ограничить требования к динамической памяти для построения версионных цепочек вывода Parser Tree. А если известен характер данных и коэф неоднозначности — то практически исключить.
VD>У нас все просто. Строится всегда одно дерево. Если в результате отката его часть теряется, ну и фиг бы с ним. Все равно мы всегда создаем дерево сверху вниз и имеем оду его копию.
В GLR тоже самое.
VD>Дык Parser Tree и есть лишний объект. Это и есть АСТ причем специфичное для парсера.
Это как бы АСТ исходной грамматики парсера.
V>>А у вас одна и та же кодовая база для рассмотренного PEG-макроса и для динамического расширения будущего парсера Nemerle? Там же разная техника исполнения парсера должна быть, как мне видится.
VD>Я не понял что за кодовую базу ты имеешь в виду. PEG-макроса читают грамматику из атрибута, преобразует ее в дерево состоящее из варинтных типов (АСТ грамматики), а далее начинает с ним играться. В итоке генерируется код парсера. Примерно тоже самое будут делать новые макросы. Только АСТ грамматики они будут брать из другого места (из описания макросов).
VD>Так что код будет повтоно использоваться. Но не на 100%.
Мне показалось, что это "независимый" генератор парсеров по грамматике ПЕГ.
Ну попробуйте. Посмотреть будет любопытно. Если у Лиспа макросами перехватывался выход парсера, а у Форта — входной поток символов, то здесь нечто третье.
Здравствуйте, vdimas, Вы писали:
V>Только те, кто может себе позволить такие ресурсы. А так пишут на яках, бизонах, кокорах и прочих, коих много.
Так по чему люди тратят тонны ресурсов на ручной парсер?
А я скажу: По тому, что бизоны, коки итп УГ!
А те, кто их использует, работают с примитивными грамматиками при этом получают кривущее решение с жуткой диагностикой ошибок.
V>Это тоже причина не доверять Вольфхаунду в его типичных резолюциях "это ни на что не влияет". Я делился только теми приемами, которые у меня реально влияли. Просто у вас они влияют в рамках погрешности измерений производительности GC.
Клиника. У меня задача создать АСТ.
Если усложнение парсера приводит к ускорению в приделах погрешности измерения, то это усложнение идет в сад.
V>Во-первых, это уже другая тема. Во-вторых, Parser tree не сильно от AST отличается.
1)Отличается и сильно.
2)А зачем Parser tree вообще нужен? У меня его нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Так по чему люди тратят тонны ресурсов на ручной парсер? WH>А я скажу: По тому, что бизоны, коки итп УГ!
Ты же прекрасно знаешь в чем причина. Любая солидная контора всегда будет пытаться разработать компилятор ЯП с парсером по LL(1). Почему именно так, надеюсь известно? И почему не катят автогенерилки для LL(1) надеюсь тоже?
Опять же, это не значит, что ничего не автоматизируют при проектировании своего парсера. Системы, типа ASF+SDF, ANTLR и т.д. неимоверно популярны. Да и захардокить любой парсер по отлаженной грамматике — дело нехитрое. Просто далеко не все программисты владеют темой и не все сценарии требуют бороться за миллисекунды, вот и пользуются автогенерилками.
WH>Клиника. У меня задача создать АСТ. WH>Если усложнение парсера приводит к ускорению в приделах погрешности измерения, то это усложнение идет в сад.
Отсюда вывод — возиться с доработкой вашего парсера вообще нет смысла, пока вы упираетесь в GC. Но твои понты в тех постах, типа "ты ничего не угадал, это ни на что не влияют, нифига ты в парсерах не шаришь" таки показательны. Ты понятие не имел, что именно у вас влияет больше всего. Хотя я не раз пытался спросить, как и что именно вы замеряете — но ты не проникся ситуацией. К проблематике парсеростроения конкретно ваша причина не имеет никакого отношения. В общем, очередной epic fail.
WH>2)А зачем Parser tree вообще нужен? У меня его нет.
Он нужен там, где и даром не нужно AST. Т.е. фактически везде, кроме узкой области компиляторостроения под ЯВУ. Для сравнения, компиляторов ЯВУ в активной разработке вряд ли больше нескольких сотен по всему миру (ну или единиц тысяч), а только лишь среду ANTLR качают по 5тыщ экземпляров в месяц.
Для нейтива скорость порядка гига символов в секунду получается на аналогичный тестах, если входной алфавит имеет буквально единицы символов (как оно бывает на простых регулярных выражениях). Полноценный же лексер, который побъет на токены входной юникодный поток для ЯП, не дает более 400-500 символов/с. Никак. По крайней мере на современной машинке с 4ГГЦ тактовой. Это скорость ровно двух табличных переходов в цикле и одного if. Хотя, в MB/c по прежнему около гига, это же юникод. Но не интересуют реально MB/c, интересно именно символов/с.
V>>Что касается моего кода, то в избранном полно всяческих сниппетов за разные годы (в "файлах" тоже). Давал коллегам как подсказки/решения.
K>Меня интересует тема, которая обсуждается конкретно сейчас — парсеры. Ты вдребезги раскритиковал чужое решение, но показать свое упорно отказываешься
Ну кидай сюда коммерчесский код фирмы, на которой работаешь. Причем целиком, чтобы компиллировалось и запускалось. А я на него посмотрю, сугубо для удовлетворения собственного любопытства.
V>>Кто-то должен был сказать что-то в ответ на все эти наезды.
K>Пока что ты не сказал ничего, кроме похвальбы и пустозвонства.
Считай как хочешь. В технических спорах принято обсуждать технические моменты. А т.к. опоненты, вместо обсуждения технической стороны вопроса скатываются исключительно на понты, то и всё т.н. "обсуждение" прошло в этом ключе. А началось оно вот тут: http://rsdn.ru/forum/philosophy/4247637.1.aspx
Здравствуйте, vdimas, Вы писали:
V> Ну кидай сюда коммерчесский код фирмы, на которой работаешь. Причем целиком, чтобы компиллировалось и запускалось. А я на него посмотрю, сугубо для удовлетворения собственного любопытства.
Интересный у тебя код, если ты не можешь сделать простенький парсер без всего остального кода твоей фирмы
V>Считай как хочешь. В технических спорах принято обсуждать технические моменты. А т.к. опоненты, вместо обсуждения технической стороны вопроса скатываются исключительно на понты
Обсуждение технических моментов на словах ни к чему кроме понтов и не может привести. Я полагаю, здесь все не раз встречались с мастерами почесать языком.
Здравствуйте, VladD2, Вы писали:
VD>Это просто пример. Понятно, что предикат может быть намного сложнее и в добавок не один (да и в разных местах).
Я вообще не уверен что ПЕГом это можно сделать... PEG vs "прыгающий" else
VD>Почему не может случиться так, что в одном месте грамматики автору захочется сматчить более короткий вариант, в другом более длинный?
Для людей это более интуитивно. Да и сам ПЕГ тут похоже тоже не поможет. Хотя строго доказывать мне лень.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Ты же прекрасно знаешь в чем причина. Любая солидная контора всегда будет пытаться разработать компилятор ЯП с парсером по LL(1). Почему именно так, надеюсь известно?
Не ЛЛ(1), а top-down.
Ибо у bottom-up сообщения об ошибках никакие.
V>И почему не катят автогенерилки для LL(1) надеюсь тоже?
По тому что LL(1) убог что звездец.
V>Отсюда вывод — возиться с доработкой вашего парсера вообще нет смысла, пока вы упираетесь в GC. Но твои понты в тех постах, типа "ты ничего не угадал, это ни на что не влияют, нифига ты в парсерах не шаришь" таки показательны.
Ну что поделать если оно так и есть.
Пальци ты тут гнешь круто, а ничего показать не можешь.
V>Ты понятие не имел, что именно у вас влияет больше всего. Хотя я не раз пытался спросить, как и что именно вы замеряете — но ты не проникся ситуацией.
Я тебе сразу сказал и что и как.
V>Он нужен там, где и даром не нужно AST. Т.е. фактически везде, кроме узкой области компиляторостроения под ЯВУ. Для сравнения, компиляторов ЯВУ в активной разработке вряд ли больше нескольких сотен по всему миру (ну или единиц тысяч), а только лишь среду ANTLR качают по 5тыщ экземпляров в месяц.
Ну покажи мне что может это твое Parser tree чего не может мой парсер.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Сдается он просто большой и толстый тролль. Его не слушать, а банить надо.
Собственно, ЧТД. Стоило ответить вам в вашем же стиле. Только насчет тролля ты ошибся, ибо всё по делу, с аргументами и цифрами. Ты как думал, легко было абстрагироваться от понтов и хамства, пытаясь уловить столь редкие фразы по существу? Потренируйся на досуге, побудь в нашей шкуре.
ИМХО, тебя давно бы пожизненно забанили, будь это третьесторонний по отношению к тебе сайт. Чтобы другим не повадно было.
Здравствуйте, Klatu, Вы писали: V>> Ну кидай сюда коммерчесский код фирмы, на которой работаешь. Причем целиком, чтобы компиллировалось и запускалось. А я на него посмотрю, сугубо для удовлетворения собственного любопытства. K>Интересный у тебя код, если ты не можешь сделать простенький парсер без всего остального кода твоей фирмы
using System;
using System.Collections.Generic;
namespace EDILib.X12
{
internal class X12Linker
{
private class State
{
public readonly State PrevState;
public readonly LinkerNode Node;
public State(State prevState, LinkerNode node)
{
PrevState = prevState;
Node = node;
}
}
private readonly X12Transaction _transaction;
private readonly Stack<string[]> _nonResolvedSegments = new Stack<string[]>(16);
private List<State> _variants = new List<State>(16);
private List<State> _buff = new List<State>(16);
public X12Linker(X12Transaction transaction)
{
_transaction = transaction;
LinkerNode root = transaction.Descriptor.LinkerTree;
_variants.Add(new State(null, root));
}
public void ProcessNext(List<string> segData)
{
_buff.Clear();
string segName = segData[0];
foreach (State state in _variants)
{
LinkerNode node = state.Node;
LinkerNode[] next = node.GetTransition(segName);
switch (next.Length)
{
case 0:
break;
case 1:
_buff.Add(new State(state, next[0]));
break;
default:
foreach (LinkerNode nextNode in next)
_buff.Add(new State(state, nextNode));
break;
}
}
List<State> tmp = _variants;
_variants = _buff;
_buff = tmp;
if (_variants.Count == 0)
throw new ApplicationException("Unexpected segment: " + segName);
if (_variants.Count == 1)
ResolveQueue(_variants[0], segData);
else
_nonResolvedSegments.Push(segData.ToArray());
}
// _currentState.Count==1 or end of dataprivate void ResolveQueue(State state, IList<string> seg)
{
int[] path = state.Node.Descriptor.Path;
SegmentOrContainer e = _transaction[path];
if (e is IParseSegment)
{
(e as IParseSegment).Parse(seg);
}
else// impossible but just for a casethrow new InvalidOperationException(
"Internal linker error during resolve symbol: " + e);
if (_nonResolvedSegments.Count != 0)
ResolveQueue(state.PrevState, _nonResolvedSegments.Pop());
}
public void NotifyFinish()
{
// check for finish stateforeach (State variant in _variants)
{
if (variant.Node.IsFinishNode)
{
if (_nonResolvedSegments.Count != 0)
ResolveQueue(variant, _nonResolvedSegments.Pop());
return;
}
}
// linker is not in finish statethrow new ApplicationException("Unexpected end of transaction set segments");
}
}
}
В районе 3-6 мег в секунду как раз и дает, в зависимости от данных. Это из экспериментов и в продакшн не пошло. Входом имеет выход лексера, парсит дерево док-та, и одновременно линкует данные на его поля. Обрати внимание, что узлы графа вариантов GLR создается по new. Для макета покатит, для релиза нет. В продакшн варианте происходит все тоже самое, только в несколько раз больше кода, обыгрывающего низкоуровневую механику.
Так же обрати внимание, что алгоритм "оперативный", как только на некоем текущем участке if (_variants.Count == 1), т.е. все неоднозначности отмерли и осталась одна ветка, происходит линковка обработанной на данный момент части документа, и в самом док-те тоже совершаются прикладные всякие валидации. Оперативность позволяет немного уменьшить негативное влияние агрессивного использования GC на производительность. Сие влияние я расписывал по ссылке в пред. посте.
Фактически ~90% любого док-та парсится по одной ветке, т.е. вышеприведенный код на этих участках работает как ДКА, и его тормозит в основном дотнетный GC. Ну и самое главное, парсер завязан на прикладную специфику чуть менее чем полностью, только так затраты на парсинг удается свести к минимуму (после всей борьбы с GC, с применением тяжелой артиллерии в виде unsafe). K>Обсуждение технических моментов на словах ни к чему кроме понтов и не может привести. Я полагаю, здесь все не раз встречались с мастерами почесать языком.
Дудки, аналитику необходимо вывести "на кончике карандаша". Меня и почти всех моих знакомых коллег подробности чьей-то низкоуровневой механики не интересуют вообще, ибо сами с усами. Интересна исключительно суть алгоритма/алгоритмов. Не зря быстродействие парсеров измеряют в кол-ве посещений внутренних узлов на единицу длины входной цепочки. В реальной жизни запросто можно взять худший алгоритм, но за счет нивелилования выделения памяти из кучи получить лучший результат, чем хороший алгоритм, но реализованный на динамической памяти. Поэтому меня не столько интересовали их цифры, сколько подробности происходящего.
Здравствуйте, VladD2, Вы писали:
VD>Этот GLR головного мозга и агония ужа на сковородке, хотя и изрядно веселит, но совершенно бесплодна. Разговор с совершенно не компетентным человеком вроде тебя цель которого сделать "хорошую мину при плохой игре" за счет оскорблений оппонентов и несения псевдонаучного бреда вроде "объяснения что алгоритм рекурсивного спуска (который мы используем) — это якобы на самом деле это восходящий анализ" мне не интересен. По сему лично я его прекращаю. Тебе тоже советую. Любое продолжение в том же духе будет воспринято мной как тролление, с твоей стороны, и будет караться соответствующим образом. Так же будет караться любые попытки унизить, оппонента с твой стороны. Так что советую остановиться.
Я не понял юмора. Ты решил в обмене любезностями оставить последнее слово за собой? Изволь сделать это без вот этих своих "изящностей" в слоге или через модераторскую вставку.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Элементарно. Берем два правила. Пускаем их по очереди (или параллельно) и смотрим кто из них съел большее количество входной строки. Кто съел больше, тот и папа.
V>Блин, всё время упускаю из виду эту "модульность". V>Понятно.
Это "модульность", а нисходящий анализ (рекурсивным спуском). Именно это дает возможность сделать каждое отдельное правило отдельным парсером. Модульность — это только один из следствий которые не сложно добиться. Для нас же важно не только то что мы можем добиться модульности, а то что мы можем относительно легко добиться динамической расширяемости. Динамическая расширяемость — означает, что мы можем менять грамматику на лету. При этом мы можем обеспечить весьма высокую скорость разбора для грамматик присущих современным языкам программирования. Никакие GLR-ы рядом не валялись. И, естественно, что подходы используемые в них для нас не применимы.
VD>>Если у нас PEG и мы поставим правила так: Х / У, то У с огромной вероятностью (а иногда на 100%) никогда не сможет сопоставиться. Оно просто будет всегда затенено.
V>Ну, это первое, за что ругают ПЕГ. Но как я понял из "ихних" форумов, такую ситуацию несложно валидировать автоматически еще на этапе построения парсера и выдавать ошибку.
Проверять затенение в общем случае невозможно (или слишком сложно для реальной жизни). Вольфхаунд, сейчас, хочет попробовать тупо заменить оператор приоритетного выбора на оператор предпочтения самого "длинного" правила (т.е. правила которое смогло распарсить большую по длине последовательность символов). Не уверен, что это хорошая идея. Но если он будет тормозить, то возможно, скоро мы сможем проверить его идею на практике.
V>Проскакивало еще мнение, близкое к обсуждаемому: задавать все правила как ИЛИ (т.е. как равнозначный выбор), затем выделять общие части после приведения, сортировать вхождения ИЛИ таким образом, чтобы самые длинные (поглощающие) подправила шли первыми, и заменять потом ИЛИ на приоритетное ИЛИ в стиле ПЕГ.
Я не понял зачем там что-то сортировать. И что значит "самые длинные (поглощающие) подправила". Правила тупо запускаются последовательно (или параллельно). При этом производится попытка разобрать все перечисленные по "|" правила (те что ранее были по "/").
V> Итого, самое длинное правило попытается быть разобранным самым первым, т.е. будут достоверно сохранены св-ва исходной грамматики, хотя будет использоваться техники разбора ПЕГ.
Это я понять не могу.
Что касается выделения "общих частей", то опять же напоминаю, что важное свойство создаваемого решния — динамическая расширяемость. Когда правила подгружаются во время разбора заниматься какими-то там вычислениями на грамматках и тем более генерировать код слишком дорого. Мы просто берем скомпилированные правила (которые являются подпарсерами) и помещаем их в массив.
Кроме того на этой же основе должен быть интегрирован алгоритм TDOP, который нужен для борьбы с левой рекурсией (а значит естественному описанию грамматики операторов) и ускорению разбора операторов в ЯП.
Вот, кстати, интеграция идей рекурсивного разбора с откатами и TDOP — это наше ноу-хау. По крайней мере я такого еще нигде не видел.
V>Но самое длинное правило не означает самую длинную цепочку.
Да вообще бессмысленно сортировать правила по длине грамматики. Вот в победе самого обжорливого правила смысл есть. По крайней мере это на 100% работает при выявлении ошибок. Скорее всего будет работать и для разрешения конфликтов.
По сути это очень похоже на GLR где идут параллельные разборы восходящим способом. Только вместо восходящего анализа используется нисходящий. По суются параллельные деревья разбора (если конечно грамматики неоднозначные), а выбор из них решается с помощью эвристики — выбор того при разборе которого парсер продвинулся дальше всего по строки. Расчет тут на то, что в 99% случаев альтернативы будут обламываться. Причем большая часть будет обламываться на первых символах. Так что реальный "выбор" (т.е. применение эвристики) будет происходить очень редко.
Тут есть огромное преимущество перед GLR. Мы строим дерево разбора в естественном для человека порядке. Это позволяет проще уложить ситуацию в мозг человека. Это приводит к тому, что фантомов (отбрасываемых правил) будет не так много.
VD>>Классика тупо не работает как надо. Она только на словах работает. А люди много десятилетий пишут парсеры языков вручную.
V>Только те, кто может себе позволить такие ресурсы. А так пишут на яках, бизонах, кокорах и прочих, коих много.
И получают непотребный результат. А те кто хочет получить качественный, и у кого (действительно) есть деньги или время, те паяют рукопашный парсер.
Вот мы и хотим положить этому конец. Наш генератор уже сейчас лучше рукопашных решений. А если идея Вольфхаунда окажется работоспособной, то возможно мы создадим прецедент и потомки будут смеяться над теми кто пишет парсеры вручную, так же как сейчас смеются над теми кто разбирает вручную то что можно разобрать регексами.
VD>>Эрли требует создания кучи динамических данных. VD>>Это не приминимый на практике алгоритм.
V>Применяют, с доработками. Не все грамматики укладываются в ограничения популярных техник парсинга.
Ламеры и неудачники его применяют. Ну, или исследователи которым просто плевать на скорость. Для реального разбора ЯП такие решения практически не применимы.
Ты тут много раз говорил про то что кто-то там "практически" не использует динамическую память. Вот Эрли ее требует.
VD>>Наш же алгоритм может жить вообще без динамического заема памяти. На практике мы занимаем память для циклических правил, чтобы накапливать результаты разбора. Но это не сильно влияет на производительность, так как там применяются динамические массивы. Да и на фоне создания АСТ это не такие уж и большие затраты.
V>Динамическое создание AST вообще не позволяет замерить собственную производительность парсера.
Сразу видно, что от практики ты далек. На практике создание АСТ занимает очень не много. Уж точно не основное время разбора. Так что если нет огромного количества откатов "больших" правил (т.е. правил которые формируют АСТ), то фактически время в пустую не тратится.
V>GC не может некоторое долгое время агрессивно выделять память, начинает заметно тормозить.
Может. Он на это и рассчитан. Надо только понимать, что у нас нет какого-то непроизводительного создания объектов. Все что создается надо на практике. Современные компиляторы всегда строят АСТ. А мы только на его создание память и тратим.
V>У меня недавно дошли руки погонять 4-й дотнет на предмет ускорения GC. Не особо. Результаты таковы: на коротком тесте простейший токенайзер, переводящий цепочки символов в String (без всяких вычислений) упирается в GC на уровне 100 МБ/сек.
К чему это зубопротезирование? 100 М/сек — это заоблачные цифры для парсеров. Если у нас будет разбираться C# или C++ со скоростью 50 метров в секунду, то это будет просто феерично и достаточно для риалтаймной работы с огромными проектами. На практике скорость выше 3 м/сек. уже достаточно для работы IDE.
V>А ведь машинка у меня довольно серьезная. Через 2 секунды первоначальный показатель падает вдвое, а еще через три секунды — втрое от первоначального, оставаясь потом на уровне ниже 28-29 МБ/сек.
Потому что это глупые синтетические тесты. На практике не надо молотить сотни метров за раз. Проекты разбиты на файлы. Файлы обычно не превышают сотни килобайт. Отдельные (обычно генерированные) доходят до 1-2 метров. Их АСТ несущественнен для GC.
В нашем парсере нет нужды материализовывать (превращать в строки) все "токены". Для "текстовых" правил, т.е. для правил не возвращающих АСТ мы отдаем только позицию начала и позицию конца. Можно или игнорировать их, или запоминать только их позиции. Большое же АСТ нужно по любому. Трата времени и памяти на него — это неизбежные затраты. Их просто глупо обсуждать.
V>Простое создание затем узлов АСТ на бинарных узлах попускает всё на уровень 8-12 МБ/сек. И это при том, что вообще никаких вычислений не происходит и подготовленные данные гоняются по кругу в памяти.
Очевидно ты тупо посадил GC на своп, так как тест совершенно не реальный. Реально компилятор того же немерла или шарпа трат на парсинг и создание АСТ меньше одного процента времени.
В современной интеграции Немерла при нажатии каждого символа запускается процесс парсинга с построением списка токенов, дерева токенов (свернутого по скобкам) и АСТ. И все это даже не заметно. А человек ведь может жать на кнопки довольно шустро. На таких объемах GC даже не замечает нагрузки.
V>Кол-во сохраняемых промежуточных токенов — не более 300к. Итого, дотнет позволяет на моей машинке работать примитивному токенайзеру со скоростью 250-300 МБ/с (если реультат не переводить в String и прочие АСТ), но при задействовании GC скорость падает до 8-12 МБ/с.
Код в студию, поглядим. Думаю что ты там что-то лажаешь. Скорее всего это голимая синтетика.
V>Вот почему я пользую пулы объектов даже в дотнете.
А какая разница занимать их перед разбором или во время? Или ты их переиспользуешь по сто раз?
V> И когда я в ответ на 4 MB/c с некоей иронией спрашивал, что же вы там замеряете, я имел ввиду не C#,
А ты прежде чем иронизировать попробовал бы найти другие парсеры которые обеспечивает такую же скорость способность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не удержался. Можешь банить.
VD>несения псевдонаучного бреда вроде "объяснения что алгоритм рекурсивного спуска (который мы используем) — это якобы на самом деле это восходящий анализ" мне не интересен.
Ваш парсер модульный. Кое-какой тип "модуля" — это аналог лексера на ДКА. В процессе оптимизации в один такой ДКА может попасть более одного исходного правила, и даже целый иерархический куст оных из исходного дерева (из-за инлайна). И вот внутри этого ДКА-модуля никакого рекурсивного спуска при разборе соответствующего куста правил вы не используете. Это 100%, спроси у напарника. Мое предложение сводится к тому, чтобы этот выделенный модуль всего-навсего реализовать по другому алгоритму. Не зачем смущаться от того, что в этом относительно независимом модуле был предложен восходящий разбор, ибо парсинг регулярной грамматики по ДКА лексера — это тоже восходящий разбор. Сие тоже 100%, хоть режь, хоть бань. Да и пофиг в любом случае, какой он был до этого, коль модуль независимый и не вызывает в процессе работы другие модули.
Здравствуйте, WolfHound, Вы писали:
V>>Он нужен там, где и даром не нужно AST. Т.е. фактически везде, кроме узкой области компиляторостроения под ЯВУ. Для сравнения, компиляторов ЯВУ в активной разработке вряд ли больше нескольких сотен по всему миру (ну или единиц тысяч), а только лишь среду ANTLR качают по 5тыщ экземпляров в месяц. WH>Ну покажи мне что может это твое Parser tree чего не может мой парсер.
Parser Tree — это суть AST исходной грамматики, никакого rocket science. Я еще в самом начале "беседы" привел похожий сценарий, когда некие прикладные объекты читают свое состояние из XML. Популярны два сценария: чтение из "тяжеловесного" DOM или из легковесного SUX. Конкретно мой приведенный рядом сценарий очень похож с точностью до формата данных (вместо XML идут X12/EDIFACT/т.д.) Аналогично, как вместо DOM SUX-парсер выдает серии XML-path, по которым ходит в процессе разбора XML, так я имею цепочку ссылок на узлы исходного parser tree, т.е. цепочку применений правил. Конкретно в моей реализации, после серий упрощений "в уме", остались непосредственные ссылки на узлы НКА, по которым ходит автомат. Это просто такой бонус -1 на косвенность.
В общем, если нужен целевой объект AST (как у вас), то пусть AST. Если же AST у нас не целевой объект (а мне показалось, что этот макрос претендует служить как обобщенная парсерогенерилка, не только для расширения синтаксиса Немерле), то дополнительное промежуточное представление лишь нагружает GC.
Здравствуйте, vdimas, Вы писали:
V>В общем, если нужен целевой объект AST (как у вас), то пусть AST. Если же AST у нас не целевой объект (а мне показалось, что этот макрос претендует служить как обобщенная парсерогенерилка, не только для расширения синтаксиса Немерле), то дополнительное промежуточное представление лишь нагружает GC.
Остается выяснить где ты взял дополнительное промежуточное представление.
У меня его нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>В районе 3-6 мег в секунду как раз и дает, в зависимости от данных.
Это какая-то хрень полная, а не пример. О чем говорит пример, который даже запустить нельзя?
Из него не ясно вообще ничего. Ни какая грамматика, ни какие данные, ни как строится автомат.
Скорость опять же очень посредственная. Я уверен, Nemerle.Peg вполне способен выдать в разы больше на грамматике уровня сложности JSON.
V>Дудки, аналитику необходимо вывести "на кончике карандаша"
Бесполезная глупость.
V> В реальной жизни запросто можно взять худший алгоритм, но за счет нивелилования выделения памяти из кучи получить лучший результат, чем хороший алгоритм, но реализованный на динамической памяти.
Я даже больше скажу — "теоретически хороший" алгоритм в реальных условиях, на реальных данных и реальной компьютерной архитектуре может отсосать у "теоретически плохого".
Здравствуйте, Mamut, Вы писали:
M>Читаемость. Eof читаемее и понятнее, чем !Any. Учитывая отсутсвтие какой-либо стандартизованности предопределенных терминалов в PEG.
!Any это очень даже стандартно для ПЕГ.
А что такое eof не понятно. Особенно не понятно причем тут фаил если разбирается строка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Читаемость. Eof читаемее и понятнее, чем !Any. Учитывая отсутсвтие какой-либо стандартизованности предопределенных терминалов в PEG. WH>!Any это очень даже стандартно для ПЕГ.
Да ну? Где это оно стандартно? То, что оно вручную записывается и определяется обычно по типу Any = . не делает его стандартным
WH>А что такое eof не понятно. Особенно не понятно причем тут фаил если разбирается строка.
Какая разница? Никакой.
Кстати, что такое Any — тоже непонятно, потому что Any может зависеть от левой задней пятки автора грамматики и вообще неналичествовать в грамматике, потому что "." (Any) — это гораздо менее полезное правило, чем "!." (Eof)
Здравствуйте, Mamut, Вы писали:
M>Читаемость. Eof читаемее и понятнее, чем !Any. Учитывая отсутсвтие какой-либо стандартизованности предопределенных терминалов в PEG.
О чем ты? Это мелкий элемент даже микроскопических грамматик. Если тете так хочется, можешь создать правило с именем EOF:
any = ['\u0000'..'\uFFFF'];
eof = !any;
...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>>Читаемость. Eof читаемее и понятнее, чем !Any. Учитывая отсутсвтие какой-либо стандартизованности предопределенных терминалов в PEG.
VD>О чем ты? Это мелкий элемент даже микроскопических грамматик. Если тете так хочется, можешь создать правило с именем EOF:
VD>
Синтаксис выглядит примерно так (на примере JSON):
.
минут за 10-20 разобрался с тем, что к чему.
IT рекомендует Git extensions.
