Oberon space
General Category => Общий раздел => Тема начата: ilovb от Март 16, 2012, 06:52:56 pm
-
Долго искал инструмент поддерживающий следующие возможности:
1. Возможность настроить под структуру конкретного языка программирования.
2. Поддержка регулярных выражений. (сравнение только блоков заданных регуляркой)
3. Поддержка сравнения трех файлов (исходный и два потомка)
4. Поддержка пакетного режима (сравнение двух папок)
Существуют ли такие в природе?
Единственное более менее приличное из найденного это DiffMerge (http://www.sourcegear.com/diffmerge/)
Но из перечисленных пунктов он обеспечивает только 2 и 4, и не очень корректно работает с UTF8.
Плюс интерфейс не самый удобный.
По первому пункту программ вообще не нашел. Регулярные выражения только DiffMerge поддерживает. По третьему пункту нашел только KDiff3 (http://kdiff3.sourceforge.net/), но у него с юникодами совсем беда была (возможно уже исправили)
-
Конечно. emacs :-)
-
Я думал это редактор :)
-
А что вы имеете ввиду под "Возможность настроить под структуру конкретного языка программирования."
-
Сравнение текстов, имеющих структуру, (как в языках программирования в том числе) имеет свои особенности в применяемых алгоритмах.
-
Сравнение текстов, имеющих структуру, (как в языках программирования в том числе) имеет свои особенности в применяемых алгоритмах.
У меня ваши пункты вызывают ощущение , что вы ищете SDK для создания IDE уровнем ниже сайнтиллы?
-
Есть конечно программы, которые поддерживают структурное сравнение для конкретных языков. Но это в них прошито изначально. И если вашего язычка в списке нету, то качественный результат вы не получите
-
Сравнение текстов, имеющих структуру, (как в языках программирования в том числе) имеет свои особенности в применяемых алгоритмах.
У меня ваши пункты вызывают ощущение , что вы ищете SDK для создания IDE уровнем ниже сайнтиллы?
Ниче не понял ;D Можно уточнить каким боком тут SDK, IDE и сайнтилла?
-
Сравнение текстов, имеющих структуру, (как в языках программирования в том числе) имеет свои особенности в применяемых алгоритмах.
У меня ваши пункты вызывают ощущение , что вы ищете SDK для создания IDE уровнем ниже сайнтиллы?
Ниче не понял ;D Можно уточнить каким боком тут SDK, IDE и сайнтилла?
Можно. В основе сайнтиллы лежит компонента - полноценный редактор. с подсветкой для РАЗЛИЧНЫХ ЯП, можно использовать как компоненту так и сам редактор (допускаются плагины)-причем ЯП задается внешними лексическими правилами. А. Ильин, например -делал для него свой плагин ObIde для XDS. Но вас (если я правильно понял) интересует более полный контроль над действиями лексера... либо просто набор инструментов позволяющих реализовать вышеперечисленные пункты... если так, то ссылку я вам давал...
-
Конкретная задача следующая:
Мы кодим на 1С. В основном пишем дополнительные подсистемы и/или дорабатываем типовые механизмы в конфигурации "Управление производственным предприятием".
1С регулярно выпускает обновления, и нам соответственно приходится объединять наши и их разработки.
Задача очень нетривиальная. УПП - это 250 мб. исходников. В платформе есть специальный механизм но он в некоторых моментах довольно неудобен. Вот и хоца хороший инструмент :)
-
2 DIzer.
Вы наверно название ветки не прочитали ;)
Или вы имеете ввиду взять из сайнтиллы конкретные механизмы и написать свой инструмент сравнения?
-
Конкретная задача следующая:
Мы кодим на 1С. В основном пишем дополнительные подсистемы и/или дорабатываем типовые механизмы в конфигурации "Управление производственным предприятием".
1С регулярно выпускает обновления, и нам соответственно приходится объединять наши и их разработки.
Задача очень нетривиальная. УПП - это 250 мб. исходников. В платформе есть специальный механизм но он в некоторых моментах довольно неудобен. Вот и хоца хороший инструмент :)
Тогда ОДНОЗНАЧНО смотреть на SDK от Econtrol -не очень дешево, но сердито (если у вас еще есть ограничение по времени , либо по людским ресурсам - смотреть однозначно).
-
2 DIzer.
Вы наверно название ветки не прочитали ;)
Или вы имеете ввиду взять из сайнтиллы конкретные механизмы и написать свой инструмент сравнения?
Я прочитал - механизмы суть алгоритмы... я говорю про готовые компоненты...
-
Econtrol -не очень дешево, но сердито (если у вас еще есть ограничение по времени , либо по людским ресурсам - смотреть однозначно).
А там разве есть алгоритмы/механизмы сравнения?
-
Econtrol -не очень дешево, но сердито (если у вас еще есть ограничение по времени , либо по людским ресурсам - смотреть однозначно).
А там разве есть алгоритмы/механизмы сравнения?
Просто посмотрите... я утверждаю что это возможно самый быстрый и дешевый способ получить по топику то что вам нужно - заодно и разберетесь со стандартными техниками решающими класс подобных задач...
-
Единственная проблема - такой подход противоречит тому, о чем бздят вам в коровнике.
-
ОК. Посмотрю. Спасибо :)
-
Но вообще, по моему, это все делается в человеческих ОС стандартными средствами: http://en.wikipedia.org/wiki/Diff3
Пакетный режим прикручивается двумя строчками шелл-скрипта.
-
Эта утилита и в нечеловеческие ОС портирована ;)
О поддержке в ней первых трех пунктов я не слыхал
-
Но вообще, по моему, это все делается в человеческих ОС стандартными средствами: http://en.wikipedia.org/wiki/Diff3
Пакетный режим прикручивается двумя строчками шелл-скрипта.
Судя по задаче речь идет об ИНТЕЛЛИГЕНТНОМ диффе в дружественной для конечного пользователя реализации с некоторым дополнительным функционалом.
-
То есть - то что можно продать, без особых усилий.
-
Эта утилита и в нечеловеческие ОС портирована ;)
О поддержке в ней первых трех пунктов я не слыхал
Хотя 3 пункт вроде есть... Надо с ней поближе познакомиться :)
-
Судя по задаче речь идет об ИНТЕЛЛИГЕНТНОМ диффе в дружественной для конечного пользователя реализации с некоторым дополнительным функционалом.
Ну в общем да. Довольно точно сформулировано
-
Эта утилита и в нечеловеческие ОС портирована ;)
О поддержке в ней первых трех пунктов я не слыхал
Оно реализует ровно третий пункт. (это ж не Diff, a Diff3).
Регулярки в самой этой утилите не нужны, ибо достаточно сделать какой-нибудь "grep -E" с нужной регуляркой а выход его направить на вход diff3. То есть "grep -E что-то там | diff3 что-то-там". Ну то есть базовые возможности человеческой оси же :-)
Так что по факту получается поддержка пунктов 2,3,4. И я не очень уверен что пункт 1 сильно что-то улучшит. Чтобы он реально улучшил, нужно ведь полноценный разборщик грамматики делать, а не как в большенстве например текстовых редакторов (там обычно только лексер).
-
И я не очень уверен что пункт 1 сильно что-то улучшит. Чтобы он реально улучшил, нужно ведь полноценный разборщик грамматики делать, а не как в большенстве например текстовых редакторов (там обычно только лексер).
По этому я про диффы не говорю... Насчет полноты анализатора реализованного в вышеупомянутом SDK - судить трудно - но у меня есть 90 процентная уверенность, что на представленную задачу его возможностей хватит с избытком.
-
То есть "grep -E что-то там | diff3 что-то-там". Ну то есть базовые возможности человеческой оси же :-)
Это мне в голову не приходило. Спасибо.
Я то все в нечеловеческих осях... и часть мозга соображающая в контексте Unix философии просто отсутствует ;D
А первый пункт нужен например для того чтобы не сравнивались процедуры с разными названиями (пусть даже код в них на 90% совпадает)
-
И я не очень уверен что пункт 1 сильно что-то улучшит. Чтобы он реально улучшил, нужно ведь полноценный разборщик грамматики делать, а не как в большенстве например текстовых редакторов (там обычно только лексер).
По этому я про диффы не говорю... Насчет полноты анализатора реализованного в вышеупомянутом SDK - судить трудно - но у меня есть 90 процентная уверенность, что на представленную задачу его возможностей хватит с избытком.
А оно конкретно про язык 1С знает? Просто если нет, то самое сложное (писать кошерный парсер) придется самим.
-
А оно конкретно про язык 1С знает? Просто если нет, то самое сложное (писать кошерный парсер) придется самим.
Точно не помню = но при желание анализатор можно НАСТРОИТЬ на получение дерева , даже в случае когда в исходном тексте используются несколько языков (HTML,JS,PHP) Уточнил - для версии 2.5 набор правил для языка 1С в поставку не входит
-
Звучит вкусно, но.. Из чего-то готового я у них вижу только пачку лексеров для разных языков. То есть парсеров не вижу. Ну, плюс контролы для рисования уже деревьев.
-
Звучит вкусно, но.. Из чего-то готового я у них вижу только пачку лексеров для разных языков. То есть парсеров не вижу. Ну, плюс контролы для рисования уже деревьев.
Вы смотрите на демо(пример редактора) или сами компоненты?
-
Звучит вкусно, но.. Из чего-то готового я у них вижу только пачку лексеров для разных языков. То есть парсеров не вижу. Ну, плюс контролы для рисования уже деревьев.
Вы смотрите на демо(пример редактора) или сами компоненты?
Я смотрю конкретно на текст:
As an example you can view default Lexer Library. This library contains lexers for file types: C++, Pascal, Basic, SQL, Delphi Resources, HTML, XML, Style sheets, Ini files, Help Contents, Batch files, Assembler, Java, PL SQL, ...
Ну и вообще, я не верю в легкий способ написания парсеров (особенно методом настройки чего-то там), ибо даже грамматика Оберона EBNF-правилами полностью не описывается. А уж C++...
Хотя, для данной задачи в принципе можно обойтись без полного парсера наверно. Ведь по сути нам нужно вычленить конктрукции верхнего уровня (функции, структуры, или что там в 1С еще бывает), выцепить их имена и сравнивать уже их (запускать diff3 для конкретно этих "файликов").
-
Ведь по сути нам нужно вычленить конктрукции верхнего уровня (функции, структуры, или что там в 1С еще бывает)
Именно так
-
Я смотрю конкретно на текст:
As an example you can view default Lexer Library. This library contains lexers for file types: C++, Pascal, Basic, SQL, Delphi Resources, HTML, XML, Style sheets, Ini files, Help Contents, Batch files, Assembler, Java, PL SQL, ...
И что там можно увидеть - по определению Lexer Library это набор правил лексического анализа текста записанных по пределенным правилам - я говорю про невизуальные классы позволяющие по этим правилам построить дерево и обеспечивающие доступ к произвольному его элементу - смотреть нужно нормальную документацию по классам = компонентам. А есть там такая штука как TSyntAnalyser- угадайте что она делает... ;)
-
Существуют ли такие в природе?
http://scootersoftware.com/
Насчет пункта 3 - не уверен.
-
Существуют ли такие в природе?
http://scootersoftware.com/
Насчет пункта 3 - не уверен.
Боюсь что быть реселером scootersoftware совсем не то что нужно этой конторе... :D
-
Существуют ли такие в природе?
http://scootersoftware.com/
Насчет пункта 3 - не уверен.
Умеет же:
BC3 means 3-way merge
-
Существуют ли такие в природе?
http://scootersoftware.com/
Насчет пункта 3 - не уверен.
Красивая штучка = с одним изьяном для true - проггера ;) ;) ;) ;) ;) написано на презренном быдлокодеро (интересно какие СТОРОННИЕ компоненты использовались), так что true- проггерам , смотреть не рекомендуется (дабы не ранить психику)
-
http://scootersoftware.com/
Да... Любопытная штука. Попробую. Спасибо
-
http://scootersoftware.com/
Да... Любопытная штука. Попробую. Спасибо
Смотреть нужно, хотя бы на особенности реализации конечнопользовательского интерфейса
-
Красивая штучка = с одним изьяном для true - проггера ;) ;) ;) ;) ;) написано на презренном быдлокодеро (интересно какие СТОРОННИЕ компоненты использовались), так что true- проггерам , смотреть не рекомендуется (дабы не ранить психику)
Нормально оно написано. Не знаю, что такое "быдлокодеро", но на чем-паскальном. Дельфя, наверное.
-
http://scootersoftware.com/
Да... Любопытная штука. Попробую. Спасибо
Поковырялся и сразу наткнулся на проблему. Оно три файла то умеет, но пакетный режим при этом не поддерживается. То есть три папки сравнить нельзя. А это губит всю прелесть трехпутевого слияния.
Почитал тамошний форум и совсем грустно стало. Они там народ уже с 2007 года обещаниями кормят. :(
http://www.scootersoftware.com/vbulletin/showthread.php?t=4924&page=4 (http://www.scootersoftware.com/vbulletin/showthread.php?t=4924&page=4)
-
Надо еще Araxis (http://www.araxis.com/merge/topic_threeway_folder_comparisons.html) посмотреть. Я его уже пробовал год назад. Но тогда он мне совсем не понравился (не помню почему).
-
Поковырялся и сразу наткнулся на проблему.
Кстати та же проблема у DiffMerge. Отдельно три файла он тоже позволяет сравнить, но толку от этого на большом объеме исходников нет.
-
Одна из популярных программ сравнения - KDiff3 (открытый). Насчёт 1-го пункта- не знаю.
Ещё один коммерческий проект: IBM Rational ClearCase (http://www-01.ibm.com/software/awdtools/clearcase/features/index.html?S_CMP=rnav), который, среди прочего, позволяет работать с ветками исходников. Сам не пользовался.
-
Поковырялся и сразу наткнулся на проблему. Оно три файла то умеет, но пакетный режим при этом не поддерживается. То есть три папки сравнить нельзя. А это губит всю прелесть трехпутевого слияния.
ИМХО тебе нужен другой инструмент - что-то типа вменяемой VCS ;)
-
Надо еще Araxis (http://www.araxis.com/merge/topic_threeway_folder_comparisons.html) посмотреть. Я его уже пробовал год назад. Но тогда он мне совсем не понравился (не помню почему).
Мне он тоже не понравился (в сравнении с beyond comapre).
-
А смысл сравнивать 3 файла? Откуда берётся третий файл?
-
Ну вот допустим есть некий модуль версии 1.0. В модуле две процедуры А() и В()
Два человека независимо друг от друга вносят изменения в свои копии этого модуля, т.е. появляются два потомка.
Сравнивая три файла (исходный и два потомка) мы обнаружим что каждая процедура:
1) Не изменялась ни у первого, ни у второго потомка
2) Изменялась только у первого
3) Изменялась только у второго
4) Изменялась у обоих
Понятно, что в первых трех случаях слияние можно сделать автоматически. А четвертый конфликтный вариант придется делать вручную.
Ну вот как то так. :)
-
Вот тут описано:
http://en.wikipedia.org/wiki/3-way_merge#Three-way_merge (http://en.wikipedia.org/wiki/3-way_merge#Three-way_merge)
-
Понятно, что в первых трех случаях слияние можно сделать автоматически.
Со 2/3 не все однозначно. Допустим в версии 1.0 обнаружился баг. Алена правит его, изменяя процедуру А. Независимо Вася делает то же, но изменяет процедуру В. Автоматически сливая два исправления, получаем баг на новом уровне.
-
На самом деле такой сценарий маловероятен. Ошибка о которой вы говорите - это скорее ошибка логики уровнем выше чем поведение внутри этих двух процедур. Мне например трудно себе представить, что за ошибка, которую можно исправить, внося изменения либо в одну либо в другую процедуру...
В таких случаях обычно добавляются/удаляются процедуры. И соответственно правится код их вызывающий. А это уже 4 случай, и система предложит выполнить слияние вручную.
Бывают конечно исключительные ситуации. Но тут уж ничего не поделаешь. Такие косяки нужно выявлять тестированием после сборки проекта.
Все современные системы контроля версий базируются на 3-way merge. И вроде как успешно.
Тут еще дело в том, что если отказаться от автоматического слияния, то все будет делаться вручную и ошибок при этом будет больше.
Теория вероятности короче ;D
-
Еще один няшный дифф: http://ru.wikipedia.org/wiki/Meld
Умеет 3-way merge на папках.
Красиво показывает отличия:
(http://i53.fastpic.ru/thumb/2013/0304/53/f1a2efd311d5c346c2dfd4bcfb21f753.jpeg) (http://fastpic.ru/view/53/2013/0304/f1a2efd311d5c346c2dfd4bcfb21f753.png.html)
Правда работает не очень быстро.