OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 06:10

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 72 ]  На страницу 1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: BlackBox Merge tool
СообщениеДобавлено: Среда, 14 Август, 2013 17:36 

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1177
Откуда: Мариуполь
Здравствуйте!

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 14 Август, 2013 18:09 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Роман М. писал(а):
Здравствуйте!

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 14 Август, 2013 18:11 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Дело в том, что формат .odc - это не просто "ещё один способ хранения текста". По сути, это объектный репозиторий.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 14 Август, 2013 19:51 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 14 Август, 2013 20:07 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
View может быть тот же самый, только с модифицированным Externalize, внутри которого может развернуться ряд вложенных Externalize. Просто глядя на составной документ, решить, какой ряд правильный, невозможно.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Четверг, 15 Август, 2013 10:49 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
В целом, если учитывать, что для двух .odc файлов невозможно найти универсальный способ выделения различий, а для узкой задачи отображения различий в системах CVS достаточно только примитивного plain-text отражения содержимого текстового файла ББ, есть предложение разработать специальный контрол версионности.
По своим функциям он будет представлять мощный аналог контрола StdStamps, и внутри себя сможет содержать отображение текста исходника, например, отдельный детектируемый внешними инструментами непрерывный блок байтов, представляющий текст формате utf8, который смогут читать внешние инструменты, типа diff-плагина и в то же время, такой расширенный Stamp уже внутри ББ сможет предоставлять функции версионности на уровне отдельного документа, с возможностью просмотра диффоф и так далее.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Четверг, 15 Август, 2013 11:50 
Аватара пользователя

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

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

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

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


Последний раз редактировалось Евгений Темиргалеев Пятница, 16 Август, 2013 13:43, всего редактировалось 1 раз.
пометка о разделении тем


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Четверг, 15 Август, 2013 11:50 

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1177
Откуда: Мариуполь
О сериализации 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, чтобы стороннее ПО тоже могло читать).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Четверг, 15 Август, 2013 11:54 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Четверг, 15 Август, 2013 22:19 

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1177
Откуда: Мариуполь
Хотел ответить раньше, но в середине дня форум не работал.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 10:28 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 11:43 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Как-то так получается, что ветер майнстрима поднимает на форуме вихрь обсуждения. И неспроста.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 11:54 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Мне кажется, что можно остаться в рамках ББ, если:
1. Хранить текст и оформление с вьюшками в разных файлах.
2. Ограничить (или изменить) формат .odc для модулей.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 12:07 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Я провожу такую разделительную линию.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 12:41 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Давайте зайдем с другой стороны. Зачем вам модули хранить в .odc?
Выделять цветом? Менять шрифт? Вставлять вьюшки?

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 12:42 

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 12:50 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Иван Кузьмицкий писал(а):
ilovb писал(а):
Полностью согласен с Романом. Вполне штатная ситуация.

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 13:04 

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 13:14 

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Пятница, 16 Август, 2013 13:14 

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

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 72 ]  На страницу 1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB