Здравствуйте, 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>А теперь попробуй объяснить это пациенту.
Мне этого делать не интересно. Мне хорошо бы расширяеомость получить и если получится еще немного генерируемые парсеры ускорить, так чтобы для реалтаймного редактирования мегабайтных файлов с запасом хватало.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
Деньги на развитие никто давать не хочет, а потом жалуются что все программы кривые и тормозные 
Ну тоды скромнее надо быть, в другой раз-то, насчет "переднего края"... PEG хорош своей гибкостью и расширяемостью прямо в рантайм, но вовсе не показателями эффективности. Т.е., его имеет смысл применять в довольно узких областях — где требуется гибкость и не нужна эффективность. Или лень делать факторизацию грамматики, например, а хочется использовать имеющуюся "в лоб". 
