OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 16 Апрель, 2024 12:24

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




Начать новую тему Ответить на тему  [ Сообщений: 62 ]  На страницу 1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Понедельник, 26 Декабрь, 2022 17:45 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
Мы со Стюартом Гринхиллом стартовали проект по портированию VisualOberon с OO2C под Ofront+


Также есть мысли добавить туда бэк-энд для SDL/Cairo. Посмотрим, как пойдёт. Там много работы. В качестве языка разработки взяли Компонентный Паскаль - там есть удобная работа с двухбайтовыми строками.

VisualOberon устроен очень интересно - там сменные бэк-энды под разные оконные системы. Есть возможность с одного исходника собирать программу и с графическим интерфейсом, и с текстовым (рамочки, псевдографика), что может быть удобно при использовании таких программ в терминальном режиме (через PuTTY и т.д.).

Если кому-то интересно данное начинание, будем рады кооперации.

P.S. Наблюдаю некоторую активность в изучении багов в OO2C, однако всё же настоятельно рекомендую присмотреться к Ofront+ :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Понедельник, 26 Декабрь, 2022 18:30 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Т.е. Visual Oberon написан на Обероне, раньше транслировался в С с помощью ОО2С, а теперь задача - транслировать его в С с помощью Офронт+?
Кажется, нет, потому что в этой схеме не нужен КП, а он у вас указан в качестве языка разработки?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Понедельник, 26 Декабрь, 2022 22:50 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Oleg N. Cher писал(а):
P.S. Наблюдаю некоторую активность в изучении багов в OO2C, однако всё же настоятельно рекомендую присмотреться к Ofront+ :)

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

а так-то мне оберон/кп как «самостоятельный компилятор» совершенно неинтересен. в составе компонентной среды — да: я всё ещё наивно уверен, что будущее — именно за компонентными средами (точнее, за компонентными системами). а для написания «самостоятельного» софта я предпочитаю си: тупо по той причине, что си, фактически, есть везде, и «фактор автобуса» играет против оберона. да, си — инструмент не самый приятный; ну да чего уж… играем теми картами, которые есть на руках.

p.s.: я там, тащемта, высказал мнение про практическую полезность oo2c.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Среда, 28 Декабрь, 2022 08:40 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
adimetrius писал(а):
Т.е. Visual Oberon написан на Обероне, раньше транслировался в С с помощью ОО2С, а теперь задача - транслировать его в С с помощью Офронт+?
Кажется, нет, потому что в этой схеме не нужен КП, а он у вас указан в качестве языка разработки?

У Олега Ofront+ поддерживает вход на Компонентном Паскале уже довольно давно. Поэтому .cp файлы ему можно скармливать. А GitHub их уже умеет распознавать, как файлы на Компонентном Паскале. Я думаю, что надо .cp также, чтобы поддерживался Блэкбоксом наравне с .odc, чтобы какие-то уже обесцвеченные проекты можно было хранить также в плоском тексте на GitHub, популяризировать язык таким образом. Я помню, что у вас ведь Антон Александрович, было такое желание или даже наработки. Там основная проблема в том, что odc прибит гвоздями как основной формат для автодополнения расширений файлов при поиске по исходникам, сохранении и т.п.
Думал, как это можно было бы расширить, и я придумал, что нужен как с STANDARD и USE директорией понятие теневого расширения. То есть установлено .cp скажем, а .odc будет при этом теневым расширением, если при открытии файл .cp не найден.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Среда, 28 Декабрь, 2022 09:37 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
простите, но мне кажется, что в погоне за некоей абстрактной «популярностью» вы пытаетесь сделать из изящной среды с простыми концепциями кадавра. вот это вот: «а давайте среда будет Умной» — это первый шаг к «умным компиляторам» и прочей избыточной сложности.

у Ominc не вышло сделать BB популярным, а у них хоть какие-то деньги были, и пусть небольшое, но имя; запутывание среды «теневыми документами» уж точно этому не поможет. а вот нормальная интеграция с DVCS — поможет. если нужен git — надо научить git читать odc через фильтры, которые покажут гиту текст. на крайний случай просто организовать закат солнца вручную: напрямую работать с дб гита, а дифф и мерж сделать средствами BB (у Советской вон даже модуль для этого есть уже).

p.s. или… о, Ересь! начать использовать вместо бинарного формата документов некий BB-специфичный вариант «богатого текста» с возможностью встраивать туда блобы. и тогда любая DVCS сможет с ним Просто Работать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Среда, 28 Декабрь, 2022 10:47 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
простите, но мне кажется, что в погоне за некоей абстрактной «популярностью» вы пытаетесь сделать из изящной среды с простыми концепциями кадавра. вот это вот: «а давайте среда будет Умной» — это первый шаг к «умным компиляторам» и прочей избыточной сложности.

у Ominc не вышло сделать BB популярным, а у них хоть какие-то деньги были, и пусть небольшое, но имя; запутывание среды «теневыми документами» уж точно этому не поможет. а вот нормальная интеграция с DVCS — поможет. если нужен git — надо научить git читать odc через фильтры, которые покажут гиту текст. на крайний случай просто организовать закат солнца вручную: напрямую работать с дб гита, а дифф и мерж сделать средствами BB (у Советской вон даже модуль для этого есть уже).

p.s. или… о, Ересь! начать использовать вместо бинарного формата документов некий BB-специфичный вариант «богатого текста» с возможностью встраивать туда блобы. и тогда любая DVCS сможет с ним Просто Работать.

Я могу написать энциклопедию про ересь относительно Блэкбокса. Так что всё, что делаю, это со знанием ситуации, не переживайте :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Среда, 28 Декабрь, 2022 13:08 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
ну, я не пытаюсь вас остановить, конечно, ни в коем случае. просто Не Могу Молчать же! ;-)

а про текстовый формат документов я давно думаю, на самом деле. как минимум для модулей. в смысле — именно «богатый текст», который позволит сохранять odc без потерь, но при этом обрабатывать их стандартными инструментами для текстового diff/patch. может даже какой-нибудь богомерзкий xml (да простят меня древние боги за такое). лично я считаю, что бинарный лучше, но такая малая уступка (возможно) позволит в дальнейшем меньше париться интерфейсами с DVCS. к тому же совсем убирать бинарный формат не обязательно: пусть себе существует параллельно. я подозреваю, что можно просто сделать обёртку, которая будет писать в текст только текстовые модели, а остальное оставлять блобами, например, и втихаря подсовывать её среде вместо «настоящих файлов». в смсле — среда по-прежнему уверена, что она пишет и читает бинарные odc, но на самом деле они прозрачно конвертируются в текст и обратно.

но мы, кажется, засоряем чужую тему этой нашей беседой. может, модераторы перенесут сообщения начиная с моего куда-то в более правильное место?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 01:23 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Делать из изящной среды с уникальными средствами работы с текстом - подобие мейнстрима с плоским текстом и синтаксической пестротой, как хвост павлина - не, увольте.
К тому же, это же окажется ловушкой: сейчас сделаем одновременную поддержку плоского текста и компонентного формата, а завтра компонентный формат выкинут, и вы же его первым предложите выкинуть.

Правильный путь - научить гит читать модули из odc. Кто способен к сему?

Идеи технического решения для всяких "подсовываний", чтобы система думала, что читает из компонентного хранилища, а на самделе читала из плоского текста - никто еще не предложил. Подозреваю, что это невозможно; как только у кого-то в руках окажется плоский текст, они моментально его откроют в блокнотэ/ноутпадэ/гедитэ/атомэ/сублимэ, поправят, и все, что было в компонентном "хвосте" - рассинхронизируется, потеряет смысл и будет выкинуто.

И так в погоне за гипотетической популярностью ББ превратиться в непоймичто: уже и не ББ, но и не мейнстрим.

И кто замерил, или хотя бы рассудил, что отсутствие плоского текста - фактор-минимум для продвижения ББ?

Есть масса других препятствий, их преодолевать и преодолевать; и более весомых, чем формат файлов. Вот например нет "герметичных" выпадающих списков. Какое современное приложение можно сделать без таковых? Это весомей, чем формат файлов, имхо. Я уйму сил и времени потратил, чтобы их сделать. И таких дел еще стопицот.

И вообще, как arisu писал в параллельной ветке - хочется все иметь внутри ББ.
И не хочется насиловать ББ, чтобы подстроить его под гит. Лучше потратить силы и время на то, чтобы решить задачу групповой разработки средствами ББ.
А просмотр модулей в интернете у Ивана Андреевича уже есть. Вот взять бы и довести до какого-то ума, чтобы интересующиеся могли смотреть тексты программ в браузере. Чем не шаг к популяризации?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 08:06 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Да не, бинарный формат останется с Блэбоксом по любви, а не по насилию, не переживайте. Очень много уж людей, которые являются апологетами использования цвета в семантических целях. И ведь это по умолчанию может быть и выключено. Для продвинутых пользователей будет некий альтернативный Librarian. Пользователи смогу активировать это расширение в своём Config Блэкбокса. Тут ведь какая мысль, и почему это в теме про Ofront+ тоже актуально. Так получатся мини проекты, которые и с Блэкбоксом совместимы и с другими компиляторами типа Ofront+, и с МультиОбероном. А расширение CP уже поддерживается GitHub. Делать какой-то свой GitHub, как не поддерживал распыление сил сообщества на такое изобретение велосипедов, так и не поддеживаю. Блэкбокс уже поддерживает открытие файлов cp без проблем. Первый шаг - научить Librarian их использовать как источник.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 10:09 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Я накидал вот такой демонстрационный пример.
Антон, я не совсем понимаю, почему нужен именно DevCPM.lib ? почему нельзя пользоваться StdLibrarian напрямую? В нем же есть уже стандартный библиотекарь...


Код:
MODULE EasyLibrarian;
(**
   project   = "BlackBox 2.0"
   organization   = "www.oberon.ch, blackbox.oberon.org"
   contributors   = "Ivan Denisov"
   version   = "System/Rsrc/About"
   copyright   = "System/Rsrc/About"
   license   = "The 2-Clause BSD License"
   changes   = ""
   issues   = ""

**)

   IMPORT Files, DevCPM, StdLibrarian;

   TYPE
      Librarian = POINTER TO RECORD (StdLibrarian.Librarian)
         root: Files.Locator
      END;

   PROCEDURE (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER; OUT loc: Files.Locator; OUT fname: Files.Name; OUT ftype: Files.Type);
   VAR f: Files.File; loc2: Files.Locator;
   BEGIN
      loc := lib.root.This(sub);
      CASE what OF
      | StdLibrarian.source:
         loc := loc.This('Mod');
         IF loc.res = 0 THEN
            loc2 := loc;
            f := Files.dir.Old(loc2, name + ".cp", Files.shared);
            IF loc2.res = 0 THEN
               ftype := "cp";
               f.Close;
            ELSE
               ftype := "odc"
            END;
         ELSE
            ftype := "odc"
         END;
         fname := name$
      | StdLibrarian.symbols: loc := loc.This('Sym'); ftype := 'osf'; fname := name$
      | StdLibrarian.code: loc := loc.This('Code'); ftype := 'ocf'; fname := name$
      | StdLibrarian.docu: loc := loc.This('Docu'); ftype := 'odc'; fname := name$
      | StdLibrarian.moddocu: loc := loc.This('Docu'); ftype := 'odc'; fname := name$
      | StdLibrarian.rsrc: loc := loc.This('Rsrc'); ftype := 'odc'; ; fname := name$
         (* not sure... how 'bout arbitrary resources? *)
      ELSE HALT(20)
      END;
      lib.res := StdLibrarian.OK
   END GetSpec;

   PROCEDURE Set*;
   VAR lib: Librarian;
   BEGIN
      NEW(lib);
      lib.root := Files.dir.This("");
      StdLibrarian.SetLib(lib);
      DevCPM.lib := lib;
   END Set;

END EasyLibrarian.Set

DevCompiler.CompileThis EasyTest EasyLibrarian


Вложения:
Снимок экрана от 2022-12-29 14-07-32.png
Снимок экрана от 2022-12-29 14-07-32.png [ 81.08 КБ | Просмотров: 3138 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 10:57 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
Делать какой-то свой GitHub

…отличная идея. только git надо выкинуть, он отвратителен. есть прелестнейший Fossil, использую сам и рекомендую всем (первая доза традиционно бесплатно; остальные тоже). для любителей гитовщины фоссил умеет автоматически заталкивать коммиты в зеркало. автор у фоссила тот же, что и у SQLite, так что про то, как хорошо делать надёжные системы на плохих языках — он в курсе. и все внутренние форматы фоссила документированы. в принципе, среди моих «планов громадьё» прямая поддежка фоссила тоже есть.

кстати, фоссил лучше гита для BB как минимум тем, что его diff для сохранения побайтовый, а не построчный, и фоссил без проблем применяет его к бинарным файлам. в плане merge это нам ничего не даёт, конечно, но в плане уменьшения размера репозиториев — ещё как.

ну, и фоссил — это один самодостаточный бинарь. хучь на винде, хучь на GNU/Linux, хучь на маках (кажется).

а, да. в любой фоссил-репозиторий автоматически интегрированы wiki, issues, и даже простенький форум. что важно: это не прилепленая сбоку нашлёпка, а именно часть репозитория. и любой, кто репозиторий склонирует себе — автоматически получает и слепок вики, багтрекера и так далее.

мне вообще кажется, что для оберон-проектов фоссил как-то идеологически даже ближе будет: он построен на очень простой базе, из простых интрументов, является в какой-то степени средой (даже немножко расширяется на встроеном диалекте Tcl), мультиплатформа без танцев с бубном, и при этом весьма мощный.


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

ну вот как: если надо что-то в BBCB собирать — так можно импортировать это в нормальный odc, и нормально использовать. если надо это отдать наружу — то есть как минимум три рабочих варианта: экспорт средствами BBCB, внешняя утилита на модуле, внешняя утилита на крестах. мне кажется, Иван Андреевич, вы пытаетесь партизанскими тропами затащить в BBCB часть подхода «тяп-ляп и в продакшон». оно ведь начинается с малого: в одном месте разрешили идеологическую дырку, в другом, глядь — а у нас уже решето.


p.s.: исходник в полноценном документе — это ведь не только про текст и шрифты. люди вообще преступно мало пользуются преимуществами, которые предоставляют живые документы. у меня по этому поводу пока одни междометия, когда (если) оно оформится во что-то адекватное — я попробую сделать Программный Пост на эту тему.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 12:36 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
мне кажется, Иван Андреевич, вы пытаетесь партизанскими тропами затащить в BBCB часть подхода «тяп-ляп и в продакшон». оно ведь начинается с малого: в одном месте разрешили идеологическую дырку, в другом, глядь — а у нас уже решето.

Креститься надо, когда кажется. Я самый закостенелый говнохранитель из всех пользователей блэкбокса. Антон Александрович не даст соврать. Однако, о чем я говорю, что мы в Блэкбоксе 2.0 сделали идеалогически огромный шаг — внедрили StdLibrarian!, который позволяет гибко настраивать что откуда брать. Мало кто ещё это осмыслил. Так что поддержка исходников в любом формате уже сейчас есть прямо вот смотрите мой пример выше. А то, что оно кое-де во фреймворке по прежнему не поддерживается. Вот это я буду устранять, так как требуется гармония и слаженность.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 12:38 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
Иван Денисов писал(а):
Делать какой-то свой GitHub

…отличная идея.
Я оценил ваш юмор, но лучше так не перевирайте :) Идея ужасная, ИМХО.
Но если кто-то хочет, то кто мы такие, чтобы мешать. Свобода превыше всего.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 12:42 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Важный момент для понимания. Я не предлагаю делать код из EasyLibrarian в сборке Блэкбокса 2.0, которую я публикую. Это может быть пользовательское расширение, если кто-то захочет себе организвать поддержку плоских файлов с расширением .cp. Важно только сделать, чтобы в Блкэкбосе не было для этого каких-то помех.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 12:56 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
Однако, о чем я говорю, что мы в Блэкбоксе 2.0 сделали идеалогически огромный шаг — внедрили StdLibrarian!, который позволяет гибко настраивать что откуда брать. Мало кто ещё это осмыслил.
вы сейчас говорите о технических нюансах. я же вёл речь об идеологических. технически я могу прыгнуть с крыши соседнего дома, но идеологически считаю это неправильным. это, однако, не повод запрещать кому-то прыгать с крыши, конечно. но повод попробовать отговорить.

Иван Денисов писал(а):
arisu писал(а):
Иван Денисов писал(а):
Делать какой-то свой GitHub
…отличная идея.
Я оценил ваш юмор, но лучше так не перевирайте :)
видите ли: я совершенно не шутил.

Иван Денисов писал(а):
Но если кто-то хочет
если есть цель совместно разрабатывать BBCB, то есть смысл делать для этого свой инструмент. github (и типа-аналоги) для этого не подходит примерно по тем же причинам, по которым обычный текстовый редактор не подходит для правки odc. и обсуждение в нескольких последних сообщениях как раз о том, надо ли адаптировать BBCB для того, чтобы как-то использовать с ним текстовый редактор, или предлагать несчастным пользователям текстовых редакторов отбросить уже их костыли и пойти. это всё взаимосвязано. и на всякий случай: я сейчас не троллю.

Иван Денисов писал(а):
Важный момент для понимания. Я не предлагаю делать код из EasyLibrarian в сборке Блэкбокса 2.0, которую я публикую. … Важно только сделать, чтобы в Блкэкбосе не было для этого каких-то помех.
я ни в коем случае не оспариваю ваше право заниматься тем, что вы считаете нужным/полезным/etc. просто лично с моей точки зрения это выглядит как работа над раскраской синтаксиса в редакторе BBCB: кому это нужно — те обычно ещё не умеют, а когда они становятся уметь — им это уже не нужно.


Последний раз редактировалось arisu Четверг, 29 Декабрь, 2022 13:02, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 13:01 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
Иван Денисов писал(а):
Но если кто-то хочет
если есть цель совместно разрабатывать BBCB, то есть смысл делать для этого свой инструмент. github (и типа-аналоги) для этого не подходит примерно по тем же причинам, по которым обычный текстовый редактор не подходит для правки odc. и обсуждение в нескольких последних сообщениях как раз о том, надо ли адаптировать BBCB для того, чтобы как-то использовать с ним текстовый редактор, или предлагать несчастным пользователям текстовых редакторов отбросить уже их костыли и пойти. это всё взаимосвязано. и на всякий случай: я сейчас не троллю.

Нет, вы просто неправильно истолковываете, а вернее просто озвучиваете какую-то выдуманную мотивацию. При чем сдесь сторонние редакторы? Я же говорю только про совместимость компиляторов, а также удобство публикации небольших проектов в существующих системах типа GitHub. Я не призываю использовать какие-то внешние редакторы с блэкбоксом. Это что-то у вас личное всплыло в сознании.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 13:03 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
Иван Денисов писал(а):
Важный момент для понимания. Я не предлагаю делать код из EasyLibrarian в сборке Блэкбокса 2.0, которую я публикую. … Важно только сделать, чтобы в Блкэкбосе не было для этого каких-то помех.
я ни в коем случае не оспариваю ваше право заниматься тем, чем вы считаете нужным/полезным/etc. просто лично с моей точки зрения это выглядит как работа над раскраской синтаксиса в редакторе BBCB: кому это нужно — те обычно ещё не умеют, а когда они становятся уметь — им это уже не нужно.
Спасибо, что не оспариваете. Весьма возможно тогда удастся с вами общаться дальше на позитивной волне. Это важно. Ну и здорово, что вы подключились к Блэкбоксу 2.0.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 13:31 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
Нет, вы просто неправильно истолковываете, а вернее просто озвучиваете какую-то выдуманную мотивацию. При чем сдесь сторонние редакторы? Я же говорю только про совместимость компиляторов, а также удобство публикации небольших проектов в существующих системах типа GitHub. Я не призываю использовать какие-то внешние редакторы с блэкбоксом.
дело в том, что вы решаете тактическую задачу, а я пытаюсь просчитать стратегические последствия. моя вина, плохо поясняю.

с моей точки зрения ущерб на длинных дистанциях от подобного намного перевешивает сиюминутную пользу. человека невозможно научить плавать, если налить в бассейн воды по щиколотку, и потом надеяться, что он, побродив там, пойдёт к речке и поплывёт. компонентная среда с живыми документами — инструмент невиданной в мэйнстриме мощи: у них просто нет ничего, что хотя бы отдалённо к этому приближалось. поэтому человек, воспитаный на мэйнстриме, будет рассматривать «герметичность» BBCB как досадную помеху (собственно, свидетельства этого можно найти прямо на форуме, и даже долго искать не придётся); поэтому он будет использовать текстовый редактор и дальше, а BBCB запускать с отвращением, и только чтобы быстренько сделать «compile» и убежать. а также будет распространять информацию (подтверждённую фактами!) о том, что даже те, кто используют BBCB, считают его ущербным, и создают инструменты для «интеграции с современными средствами разработки кода». так мы слона не продадим.

таким образом, задача «привлечения людей в BBCB» вышеуказаными средствами не решается.

теперь рассмотрим задачу «использовать из BBCB библиотеки для других компиляторов». оставив в стороне тот факт, что их не нестолько много, просто скажу, что любой человек, привыкший к BBCB, первым делом импортирует текст в нормальный документ, и будет работать с ним как с документом, а не как с плоским текстом. то есть, этим людям подобное тоже не надо.

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

BBCB никогда не станет популярным, если идти по пути облегчения взаимодействия с мэйнстримными инструментами. максимум, что можно получить на этом пути — труп некогда великой системы. слишком разные идеологии. (добавлю в скобках, что я в принципе не уверен, есть ли необходимость «делать BBCB популярным».) именно поэтому я пишу, что BBCB необходима своя среда в том числе и для совместной разработки, которая в полной мере пользуется преимуществами компонентной системы и живых документов. вы же идёте в совершенно противоположном направлении. «псевдотекстовый формат», который я предлагал выше — это было предложение сделать временную меру, пока у нас ещё нет подобной среды.

собственно, именно над чем-то подобным я и собираюсь работать — по мере наличия сил и времени, которых, увы, не так много, как мне бы хотелось. для начала работ мне была необходима «родная» версия BBCB под GNU/Linux, и, похоже, BB2.0 на эту роль уже подходит, несмотря на имеющиеся (пока) недоработки.

возможно, это выглядит как утопический экстремизм. одна из проблем в том, что я обдумывал эту тему не один год, и часто пишу так, как будто все остальные сидели всё это время в моей голове и в курсе, что там происходит. mea maxima culpa. возможно, для разъяснения моей позиции нужна серия программных статей — но это опять-таки время и силы, которых у меня сейчас нет. простите за этот дамп сознания.

p.s.: это всё не значит, что я требую от вас Немедленно Прекратить. я просто пытаюсь пояснить, почему именно мне кажется, что это путь не просто тупиковый, но и идеологически неправильный. естественно, я могу ошибаться; просто хочется, чтобы вы чуть лучше понимали, откуда «растут ноги» у моих возражений.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 13:45 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван, А почему вам не подходит консольный компилятор КП?
И к тому же, у вас есть где-то утилита, которая делает odc из плоского текста. Ну вот совместить консольный компилятор с этой утилитой, и будет вам компиляция .cp файлов. Unix way. Скрипт на баше.

В приведенном вами примере заложена мина.
f := Files.dir.Old(..., Files.shared);
...
f.Close

Если вдруг окажется, что кто-то где-то до вас открыл этот же файл, а вы его закрыли, то сильновероятно тот кто-то придет к авосту. Выяснить причину будет крайне затруднительно, и прожить такая "закладка" может очень долго.

Не стоит проверять существование файла таким образом. Стоит писать процедуру FileExists и пользоваться File.dir.FileList.

А можно предложить включить FileExists (loc: Files.Locator; IN fname: Files.Name): BOOLEAN в модуль Files как вспомогательную процедуру. Но можно и ручками писать, везде где она нужна.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 14:03 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
arisu писал(а):
дело в том, что вы решаете тактическую задачу... откуда «растут ноги» у моих возражений.


ПЛЮСУЮ!!!

В Гершеле я использовал коммандеры, вкладки и спец. виды для ведения тестовой базы; использовал встроенную возможность вкладок иметь метку, расширил вкладки, чтобы эту метку было видно. Во вкладку помещал тест, в другую - эталонный ответ, и т.д. Документы ББ - это мощь. Минимальными усилиями сделал для себя тестовую инфраструктуру.
Изображение

В модуле StdDocuments вставил схему, чтобы пояснить взаимосвязь полдюжины полей др с др и с геометрией документа.
Не хватает времени, чтобы сделать более практичный редактор схем.
Изображение


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

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


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

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


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

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