Здравствуйте, 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.
Здравствуйте, WolfHound, Вы писали:
WH>Вот только у меня самый быстрый ПЕГ парсер. WH>А 4 метра в секунду это с построением АСТ. Скорость без построения АСТ никого не волнует. Вообще.
Ты что-то периодически зазнаешься. Во-первых, бабашка на двое сказала что нет реализации быстрее.
Во вторых ты что-то везде себя любимого превозносишь. Хотя как минимум быстрыми или медленными являются конечные парсеры. А в них (по крайней мере для PEG) важную роль играют авторы парсеров. Тот же парсер C# Хардкейсом оптимизировался не раз. Он и спрофайлером сидел, и грамматику факторизировал, и даже TDOP в урезанном виде туда засунул (что, кстати, дално ощутимый прирост скорости, хотя делал он это для упрощения разбора операторов).
Давай все же будем по скромнее. Не будем якать и уж тем более бросаться непроверенными заявлениями типа "самый быстрый".
Да, на Nemerle.Peg можно делать быстрые парсеры. Это факт. Да, в огромной мере — это твоя заслуга. Но то что они самые быстрые и то что это целиком только твое достижение — это, как минимум, преувеличение.
И вообще, к твоим словам зачастую докапываются даже те кто с ними в общем-то согласен. И знаешь почему? Потому что в них какой-то радикально-экстримистский максимализм. Ну, нельзя делить мир только на черные и белые цвета. Есть еще оттенки. И это не только оттенки серого.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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%.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Klatu, Вы писали:
V>>В динамике парсеры строятся по описаниям, да еще кое-что захардкожено, с целью исключения виртуальных вызовов в калбэках.
K>Вроде все слова знакомые, а в осмысленное предложение никак не связываются
Перевожу на русский — у него все в теории. Он решал похожие задачи и знаком с теорией LR-парсеров. От того делает далеко идущие выводы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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-свойства. Как быть с ними в Гите и Меркури?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
.
IT рекомендует Git extensions.
минут за 10-20 разобрался с тем, что к чему.
