OberonCore
https://forum.oberoncore.ru/

BlackBox Merge tool
https://forum.oberoncore.ru/viewtopic.php?f=127&t=4431
Страница 1 из 4

Автор:  Роман М. [ Среда, 14 Август, 2013 17:36 ]
Заголовок сообщения:  BlackBox Merge tool

Здравствуйте!

Есть ли для Блэкбокса какой-нибудь немуторный способ совершить слияние двух файлов в третий, формата ODC, естественно?

Автор:  Иван Денисов [ Среда, 14 Август, 2013 18:09 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Роман М. писал(а):
Здравствуйте!

Есть ли для Блэкбокса какой-нибудь немуторный способ совершить слияние двух файлов в третий, формата ODC, естественно?

А мне нравится F9. Я так и с соавторами статей работаю, вставляю LaTeX документ в BB и каждую запятую копирую руками :) Любой автомат, не гарантирует безопасные слияния, а тестировать — дольше чем проверить все правки.

Автор:  Иван Кузьмицкий [ Среда, 14 Август, 2013 18:11 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Дело в том, что формат .odc - это не просто "ещё один способ хранения текста". По сути, это объектный репозиторий.

Поэтому в файле .odc может храниться как объект FormModels.Model, так и объект TextModels.Model. И прочие контейнеры. Так что обобщённого объединения в принципе не существует.

Объединять можно только однотипные контейнеры, да и то если они позволяют такое.

Если речь идёт о текстовых контейнерах, то способ тривиален - TextModels.Model.Append

Автор:  Роман М. [ Среда, 14 Август, 2013 19:51 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Допустим, в разных ветках два разработчика выполнили замену некоторого View на другой, причём каждый по-своему.
При слиянии двух веток разработчик должен решить какой вариант оставить. Тут у разработчика появляется головная боль, потому как нужно удостовериться, что выбранный View (необязательно однотипный) является верным решением, причём до подтверждения окончания слияния.
Предположим, разработчик выбирает устраивающий вариант. Значит, с точки зрения составного документа, итогом слияния будет документ с заменённым View. Так что принципиально всё должно быть возможно и при работе с View.

Насколько я понимаю, такого инструмента в ББ нет?

Автор:  Иван Кузьмицкий [ Среда, 14 Август, 2013 20:07 ]
Заголовок сообщения:  Re: BlackBox Merge tool

View может быть тот же самый, только с модифицированным Externalize, внутри которого может развернуться ряд вложенных Externalize. Просто глядя на составной документ, решить, какой ряд правильный, невозможно.

Plain text и odc несколько, кхм, ортогональны. Если говорить только о ядре ББ, то спасает одно - там вложенных View почти что и нету. Тут уже надо принимать решение, что исходники "общественного" ББ будут храниться только в плоском тексте, а чтоб не нарушать примитивным plain-text экосистему самого ББ, придётся наладить процедуры импорта-экспорта.

Раньше я задумывался о том, чтобы наклепать дифф на самом ББ и встроить его в тот же Mercurial, но теперь думаю, что это занятие бесполезное, настолько отличаются природы plain text и odc. Проще всего выбрать что-то одно и не париться.

Я бы выбрал odc. Просто не верю в то, что "массовые диффы" будут реальным явлением. Если ББ и будет развиваться, то постепенно, аккуратно и неторопливо.

Автор:  Пётр Кушнир [ Четверг, 15 Август, 2013 10:49 ]
Заголовок сообщения:  Re: BlackBox Merge tool

В целом, если учитывать, что для двух .odc файлов невозможно найти универсальный способ выделения различий, а для узкой задачи отображения различий в системах CVS достаточно только примитивного plain-text отражения содержимого текстового файла ББ, есть предложение разработать специальный контрол версионности.
По своим функциям он будет представлять мощный аналог контрола StdStamps, и внутри себя сможет содержать отображение текста исходника, например, отдельный детектируемый внешними инструментами непрерывный блок байтов, представляющий текст формате utf8, который смогут читать внешние инструменты, типа diff-плагина и в то же время, такой расширенный Stamp уже внутри ББ сможет предоставлять функции версионности на уровне отдельного документа, с возможностью просмотра диффоф и так далее.

То есть, выделяются две основные функции:
  • Сохранение текущего содержимого документа (в момент сохранения самого документа) в виде плэйн-текст-области внутри файла, аналог предпросмотра
  • Версионность документа на уровне ББ с последующим ростом функциональности
Как решающий фактор, который позволит реализовать такой контрол версионности, выступает тот факт, что внедрённые отображения могут получить доступ к модели контекста, в котором они расположены.
А для желающих принимать участие в разработке базовой сборки ББ, после устаканивания процесса совместной разработки, можно ввести договорённость на обязательное использование подобного контрола версионности.

Автор:  Иван Денисов [ Четверг, 15 Август, 2013 11:50 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Цитата:
В целом, если учитывать, что для двух .odc файлов невозможно найти универсальный способ выделения различий, а для узкой задачи отображения различий в системах CVS достаточно только примитивного plain-text отражения содержимого текстового файла ББ, есть предложение разработать специальный контрол версионности.
По своим функциям он будет представлять мощный аналог контрола StdStamps, и внутри себя сможет содержать отображение текста исходника, например, отдельный детектируемый внешними инструментами непрерывный блок байтов, представляющий текст формате utf8, который смогут читать внешние инструменты, типа diff-плагина и в то же время, такой расширенный Stamp уже внутри ББ сможет предоставлять функции версионности на уровне отдельного документа, с возможностью просмотра диффоф и так далее.

Для сравнения кода, вполне годится найденный способ — хранится все в бинарниках, а сравнивается в виде plain-text.

Роман поставил вопрос о качественном автоматическом слиянии двух полноценных документов. Ведь F9 пропускает отображения, diff их не показывает.

(модератор) Отделена тема "Особенности версионности с составными документами" viewtopic.php?f=23&t=4440 (п. 3.3)

Автор:  Роман М. [ Четверг, 15 Август, 2013 11:50 ]
Заголовок сообщения:  Re: BlackBox Merge tool

О сериализации ODC я уже упоминал на другом форуме: BBCB & hg/git/svn
Выбрал формат XML.

Процитирую себя:
Я писал(а):
Код:
<!-- Oberon eXchange Format (OXF) -->
<?xml version="1.0" encoding="UTF-8" ?>
<content>
  <source>Oberon/F</source>
</content>
<body>Lorem ipsum

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam ac nisl quis arcu condimentum tempus. Nullam consectetur nisl nec arcu convallis non vehicula magna euismod. Aenean vitae nunc nec sapien iaculis vehicula sit amet nec felis. Nullam eget nisi nec lacus euismod consequat. Pellentesque justo dolor, tempus ut aliquam cursus, vehicula sed nulla. Duis mollis lobortis dolor eu ultrices. Phasellus semper convallis venenatis.

In imperdiet, libero ut suscipit rhoncus, velit nunc condimentum nisl, in mollis arcu velit at sem. In ac justo nunc. Praesent arcu sem, pretium quis adipiscing non, accumsan in tellus. Donec molestie blandit leo, a congue risus egestas a. Mauris et urna eu ligula vestibulum molestie. Duis gravida mi at erat volutpat pulvinar. Vestibulum nec orci at diam facilisis egestas. Sed luctus commodo enim, vitae ultrices orci facilisis nec. Donec dignissim, sem nec ultricies venenatis, eros diam hendrerit metus, non faucibus mauris enim id sapien. Vivamus id est orci. Cras in augue ac massa volutpat euismod et vel magna. Nulla pretium semper dolor et pulvinar. Fusce tempus condimentum augue nec ullamcorper. Sed volutpat lacinia mollis.

MyCommand.Do par1 par2 par3

Fold text

Text</body>
<meta>
  <tokenlist>
    <token pos="ADFF" type="text">
       <textstyle fontsize="24" attr="bold" />
    </token>
    <token pos="FBCD" type="text">
       <textstyle fontsize="10" attr="bold,italic" />
    </token>
    <token pos="FBED" type="text">
       <textstyle fontsize="10" attr="default" />
    </token>
    <token pos="FE01" type="text">
       <textstyle fontsize="8" attr="default" />
    </token>
    <token pos="FEC3" type="command">
       <data>MyCommand.Do par1 par2 par3</data>
    </token>
    <token pos="FFC3" type="fold">
       <data>Hidden fold text</data>
    </token>
    <token pos="1B293" type="timestamp">
       <data>21-Jan-2013</data>
    </token>
    <token pos="1CE01" type="text">
       <textstyle fontsize="10" attr="default" />
    </token>
  </tokenlist>
</meta>

Вложенные View можно отобразить в виде дерева объектов. Так что сериализовать это дело в XML не должно представлять непреодолимую проблему.
Сами View можно сериализовать либо с StdCoder, либо Base64 (по RFC, чтобы стороннее ПО тоже могло читать).

Автор:  Пётр Кушнир [ Четверг, 15 Август, 2013 11:54 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Роман, интерфейс Stores.Reader позволяет читать байты оригинального файла, в том числе конвертируя их на лету в значения других базовых типов, а так же предоставляет доступ напрямую к .rider: Files.Reader, который используется, например, в TextModels. Как вы планируете реализовать эту возможность основывая хранилище .odcx (например) на базе xml?

Автор:  Роман М. [ Четверг, 15 Август, 2013 22:19 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Хотел ответить раньше, но в середине дня форум не работал.

Пётр Кушнир писал(а):
конвертируя их на лету в значения других базовых типов
Что значит "на лету"? Поясни, пожалуйста.

Пётр Кушнир писал(а):
а так же предоставляет доступ напрямую к .rider: Files.Reader, который используется, например, в TextModels. Как вы планируете реализовать эту возможность основывая хранилище .odcx (например) на базе xml?
Я не знаю как всё это устроено в ББ, поэтому я и поднял данную тему.

Формат XML не является полноценным решением при работе с версионностью составных документов, однако он позволяет работать инструментами за пределами ББ, в котором таковых ещё нет. Так что сериализация View могла бы частично решить как этот вопрос, так и второстепенный: просмотр документов внешним ПО, таким как веб-броузер.

Автор:  Пётр Кушнир [ Пятница, 16 Август, 2013 10:28 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Роман М. писал(а):
Пётр Кушнир писал(а):
конвертируя их на лету в значения других базовых типов
Что значит "на лету"? Поясни, пожалуйста.
Ну в кратце, это значит, что установив Reader на позиции в файле и видя перед собой 4 байта данных пользователь может прочитать их как 4 байта, как одно INTEGER, как две юникодных литеры, и это никак не регламентируется на уровне байтов в файле, грубо говоря, нет никакой возможности узнать, что записывает/читает Store, кроме как взглянуть в её исходный код, который выполняется в рантайме, а значит на лету. А раз так, то сериализовав что-то в формат xml нельзя будет предугадать, что хочет прочесть пользователь, следовательно, выходные данные могут быть неверны, следовательно, не реализуется контракт. А значит нельзя говорить о сериализации View в xml. Как-то так.

Автор:  Иван Кузьмицкий [ Пятница, 16 Август, 2013 11:43 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Как-то так получается, что ветер майнстрима поднимает на форуме вихрь обсуждения. И неспроста.

Ведь вопрос о слиянии должен вывести нас на понимание сущности того, что же мы собираемся сливать. Составные документы - это не просто текст, а хранилище программных объектов.

Если мы отказываемся от идеи хранилища, то начинаем работать с текстами "как все", привлекая на свою сторону всю мощь наработанных сторонних инструментов, заточенных на plain-text. Но раз мы убираем хранилища, тогда и идея составных документов сама собой исчезает, а вслед за ней канут в Лету и Тексты, и Stores, и Операции. Всё это станет ненужным, а значит, и фреймворк ББ исчезнет сам собой.

Поэтому вопрос о том, где хранить исходники ББ, является эсхатологическим :) Вопрос - "быть или не быть плоскому тексту", равносилен вопросу "быть или не быть Блэкбоксу", как ни крути.

Автор:  ilovb [ Пятница, 16 Август, 2013 11:54 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Мне кажется, что можно остаться в рамках ББ, если:
1. Хранить текст и оформление с вьюшками в разных файлах.
2. Ограничить (или изменить) формат .odc для модулей.

Автор:  Иван Кузьмицкий [ Пятница, 16 Август, 2013 12:07 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Я провожу такую разделительную линию.

Давайте переведём все исходники ББ в плоский текст. Почему нет? Это удобно для версионных систем и систем коллективной разработки, которые работают с плоским текстом.

Следующий логичный шаг, раз у нас тут плоский текст, то давайте править исходники в Notepad++, ведь там нормальная работа с кодом и много прочих вкусных плюшек.

После этого логично выделить консольный компилятор, который всё откомпиляет без промежуточного преобразования в odc.

В итоге, мы храним исходники в plaintext, правим их сторонними средствами, компилируем отдельно от ББ. И всё для того, чтобы запустить ББ и начать в нём программировать?

Автор:  ilovb [ Пятница, 16 Август, 2013 12:41 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Давайте зайдем с другой стороны. Зачем вам модули хранить в .odc?
Выделять цветом? Менять шрифт? Вставлять вьюшки?

Вы ведь это делаете для себя... У меня в конторе принято оформлять код одинаково. Все должно быть однообразно. Так код значительно проще читать. Мы бьем по рукам если кто-то напишет IF в одну строку.
Кроме того у простого текста нет всяких курсивов и прочего. Это дает возможность иметь такое оформление, какое хочет читатель, а не писатель.
Вот я работаю на 14 шрифте с откорректированной раскраской. Любой код у меня выглядит одинаково, независимо от того, кто его писал.

В исходниках ББ же с этим делом полнейший хаос. Кто во что горазд. Каждый мнит себя дизайнером.

Вам нравится как сделано в ББ, мне нет. Что будем делать?

Автор:  Роман М. [ Пятница, 16 Август, 2013 12:42 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Пётр Кушнир писал(а):
Роман М. писал(а):
Пётр Кушнир писал(а):
конвертируя их на лету в значения других базовых типов
Что значит "на лету"? Поясни, пожалуйста.
Ну в кратце, это значит, что установив Reader на позиции в файле и видя перед собой 4 байта данных пользователь может прочитать их как 4 байта, как одно INTEGER, как две юникодных литеры, и это никак не регламентируется на уровне байтов в файле, грубо говоря, нет никакой возможности узнать, что записывает/читает Store, кроме как взглянуть в её исходный код, который выполняется в рантайме, а значит на лету. А раз так, то сериализовав что-то в формат xml нельзя будет предугадать, что хочет прочесть пользователь, следовательно, выходные данные могут быть неверны, следовательно, не реализуется контракт. А значит нельзя говорить о сериализации View в xml. Как-то так.

Программа, распознающая формат ODC, знает где и когда можно ожидать ту или иную последовательность байтов, преобразовывая их во внутренние структуры данных. Reader управляется "сверху" объектом модели контейнера, когда Reader'у указывается что, где и сколько нужно прочесть.

Когда речь идёт о сериализации/десериализации текста в/из кодировки UTF-8, в каждой заданной позиции символа алгоритм должен просчитывать как закодировать последовательность, решая по месту.
При сериализации (или "экстернализации", как принято в ББ) некоторого состояния View в составной документ, данный составной объект преобразуется в некоторую последовательность байтов с одним и тем же содержанием, поэтому понятие "на лету" (иными словами, "по месту") здесь неуместно (не беря в расчёт кодирование некоторого текста объекта в заданной кодировке), на мой взгляд, так как все шаги заранее просчитаны.

Таким образом, я всё ещё неубеждён в принципиальной невозможности сериализации составного документа в формат XML. Аналогичным образом, в этот формат можно сохранить дерево всех объектов. Кроме того, вопрос о размере данных в формате XML не стоит.

Автор:  Alexey Veselovsky [ Пятница, 16 Август, 2013 12:50 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Иван Кузьмицкий писал(а):
ilovb писал(а):
Полностью согласен с Романом. Вполне штатная ситуация.

Я например регулярно с этим сталкиваюсь на работе при обновлении конфигураций 1С у клиентов. Да и внутри моей команды такое частенько бывает, т.к. в SVN иногда одновременно разными кодерами правится одна разработка, т.к. ресурсы не резиновые, и повесить все на одного человека невозможно.
В каких единицах измеряется ваша "разработка"? В оберонах мы имеем дело с модулями, которые позволяют разделить ответственность и изолировать проблемы.


В одном моем проекте эти самые единицы - отдельные приложения, причем они пишутся на разных ЯП. То есть за одним человеком закреплено одно приложение. Так вот, инструмент для слияния (в том числе автоматического) все равно периодически нужен.

Автор:  Пётр Кушнир [ Пятница, 16 Август, 2013 13:04 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Роман, как вы правильно сказали
Роман М. писал(а):
Reader управляется "сверху" объектом модели контейнера, когда Reader'у указывается что, где и сколько нужно прочесть.
значит только полное повторение кода управляющей сущности может привести к повторению последовательности операций чтения, а значит моя фраза про отсутствие возможности узнать, что же записывает Store, глядя на odc извне, верна. То есть, внешним утилитам надо быть "как ББ" только на своём языке программирования. И каждое новое отображение в документе будет требовать такого же отображения реализованного на другом языке.

Далее, мы говорили о том, что Stores.Reader предоставляет интерфейсы перемещения и произвольного чтения каретки по цепочке байт, следовательно, этот интерфейс должен быть реализован в хранилище на основе xml, вместе с тем, интерфейс Stores.Reader таков, что позволяет прочитать весь файл, а не только область выделенную для конкретной Store, следовательно, этот интерфейс может быть использован в работе одной из Store ещё неизвестной нам, а значит, она не будет работать с вашей реализацией хранилища, контракты будут нарушены. А компонент персистентности на основе XML с нарушением контракта не может считаться полноценным. Но это не исключает возможности создания чего-то на основе XML, только наверное не стоит называет это Stores.

Я это говорю не к тому, что я против вашей идеи, на самом деле, возможность полноценной экстернализации в различные форматы данных является привлекательной с точки зрения осуществления обмена информацией по всяким сетям, но после изучения интерфейса я понял, что интерфейс сам по себе не позволяет нам ограничивать контракты и функциональность Reader/Writer так как они не являются расширяемыми. Фактически, либо мы пользуемся функциями персистентности, которые реализованы в Stores, либо не пользуемся ими, создаём свои механизмы и используем их в обход Stores.

Автор:  Иван Кузьмицкий [ Пятница, 16 Август, 2013 13:14 ]
Заголовок сообщения:  Re: BlackBox Merge tool

ilovb писал(а):
Давайте зайдем с другой стороны. Зачем вам модули хранить в .odc?
Этот вопрос рано или поздно приведёт к другому, "а зачем вам вообще ББ?". Но я всё равно отвечу.

Да, цветом я помечаю особые участки кода, выключая отлаженный (нераскрашенный) код из локуса внимания (автораскраска мной давно отнесена к разряду каменных топоров). Прямо в коде могут храниться виджеты-помогальники. Формат .odc универсален для хранения всего, давая возможность одним и тем же способом как писать программы, так и оформлять документацию (читайте Раскина, почему монотонность ценна).

ilovb писал(а):
Вы ведь это делаете для себя... У меня в конторе принято оформлять код одинаково. Все должно быть однообразно. Так код значительно проще читать. Мы бьем по рукам если кто-то напишет IF в одну строку.
Кроме того у простого текста нет всяких курсивов и прочего. Это дает возможность иметь такое оформление, какое хочет читатель, а не писатель.
Вот я работаю на 14 шрифте с откорректированной раскраской. Любой код у меня выглядит одинаково, независимо от того, кто его писал.
Вы мне так всё подробно рассказываете, так я сообщу - всё это я проходил уже 10 и более лет назад. Плавали, знаем.
Но составные документы предоставляют несколько другой стиль работы, а объектная модель текста позволяет сделать с этим текстом что угодно. Внедряйте в документы виджеты-стилисты и получайте какое угодно однообразие, сохраняя при этом оригинальное форматирование. Объектная модель по определению мощнее плоскотекстовой модели.

ilovb писал(а):
В исходниках ББ же с этим делом полнейший хаос. Кто во что горазд. Каждый мнит себя дизайнером.
Ложь. Исходники ББ созданы в одном стиле, следуя указанным в документации соглашениям. Проблемы же стиля, принятые в организации, можно решить либо технически (как я чуть выше указал), либо организационно - наказывая рублём за отступление от соглашений. В любом случае, это не настоящие проблемы и офтопик.

Автор:  Роман М. [ Пятница, 16 Август, 2013 13:14 ]
Заголовок сообщения:  Re: BlackBox Merge tool

Что касается формата составного документа, то всё объяснимо:
  1. История исходит из периода создания ОС Оберон: тогда Никлаус Вирт обдумывал каким образом он будет организовывать вывод объектов на экран. Для этого ему нужно было создать систему вёрстки на своей ОС. Так, он взял за основу базовые понятия типографики и, таким образом, организовал минимальный набор инструментов для вёрстки, по подобию TeX. Чтобы иметь возможность сохранять текст и графику документа, свёрстанного в его системе, ему нужно было обдумать набор инструкций для последующего воспроизведения содержимого сохранённого документа на экране. Так и была заложена основа тому самому формату составных документов Блэлбокса.
  2. Далее, поскольку Вирту не хотелось распыляться на создание специального ПО - ИСР (IDE), он воспользовался готовой системой вёрстки и для написания исходного кода программ.
  3. Впоследствии, ему требовалось следить за изменениями в документе. Так, за неимением системы контроля версий документов, он стал раскрашивать код в разные цвета, чтобы было легче отметить что и когда он делал.

Сегодня мы имеем широкий набор инструментов для отслеживания версий документов и грех не пользоваться их преимуществами.

Я считаю, что исходный код не должен помечаться цветами красок. Вместо этого нужно придумывать интерактивные средства для замены ручной покраски кода. И необязательно для этого накладывать нагрузку на сам документ. Вместо этого, стоит лучше продумать среду разработки.
Скажем, исходный текст может храниться в кодировке UTF-8 (скелет), а на него "надевается" интерактивность, в виде сопровождающего файла-контейнера, содержащего мета информацию: командеры, ссылки, объекты и прочее.

Страница 1 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/