OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 29 Март, 2024 00:18

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




Начать новую тему Ответить на тему  [ Сообщений: 67 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Среда, 21 Август, 2013 23:23 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
И ещё раз по Линуксу: обещания нужно выполнять. Если мы связали себя обязательствами, то до того, как будет сказано, что мы больше не свзяны этими обязательствами, нужно поступать так, как обещали. Или у Вас есть другие варианты поведения? Сейчас всё почти опубликовано по воле Ominc, но с нас пока никто обязательств не снял.

Опять таки - свободной работе никто и ничто не мешает. Ширяев был связан таким обещанием, так он сам переписал, что нужно и всё. Теперь оно лицензионно чисто. Он ничего не нарушил.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Среда, 21 Август, 2013 23:25 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Иван Денисов писал(а):
это что? «призывает всех членов Сообщества поддержать такой подход.» вот я и высказываю свое отношение к вашему призыву.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Среда, 21 Август, 2013 23:49 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
А что касается общения более живого чем форум... Были бы Вы поближе, я предложил бы встретиться пообщаться. Но так, вы же предлагали видеоконференцию? Вот можно и устроить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Среда, 21 Август, 2013 23:50 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
И ещё раз по Линуксу: обещания нужно выполнять. Если мы связали себя обязательствами, то до того, как будет сказано, что мы больше не свзяны этими обязательствами, нужно поступать так, как обещали. Или у Вас есть другие варианты поведения? Сейчас всё почти опубликовано по воле Ominc, но с нас пока никто обязательств не снял.
Ну вы как в анекдоте про зайца и динозавра. А спросить?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 22 Август, 2013 21:38 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Зря, народ, вы между собой ругаетесь.
У меня пока с ББ только шапочное знакомство, заглянул, посмотрел,
пошел дальше, ну еще «Проект Оберон» поверхностно прочитал.
Что могу сказать — к самому языку Компонентный Паскаль претензий
никаких, а вот излишняя привязка программы к среде напрягает.
Исходники, работающие только с win32 собираются в .exe и запускаются,
а попытка превратить в .exe программу с оконным интерфейсом кончилась
тем, что .exe вроде собрался, но вылетел при запуске.
Дальше я разбираться особо не стал, Delphi как средства для написания своих
утилит для собственного использования мне за глаза хватает.

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

!!! Открытая среда программирования с исходниками на русском языке — вот
это было бы здорово. Это была бы общедоступная библиотека хорошо
документированных алгоритмов, которые все могли бы использовать бесплатно
и при необходимости переводить в свои системы программирования (в связи с
чем очень интересен проект Валерия Лаптева и его команды).
Вот что могло бы стать самым ценным моментом во всем этом деле.



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



ПУТЬ К БЫСТРОМУ ПОНИМАНИЮ

профессор: студент, сформулируйте мне закон Штурма-Луивиля.
студент: Луивиль должен быть взят !


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

Для быстрого понимания логической структуры нужно строгое и
УДОБОЧИТАЕМОЕ описание этой логической структуры.

Как описывать ? Желательно на родном языке читателя, иначе он вообще
ничего не поймет ...

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

Вопрос заключается в том, что современные языки программирования (как
подмножество языков описания и решения логических и математических
задач), даже с возможностью написания ключевых слов и имен переменных
на родном языке программиста, даже с возможностью визуализации
логических структур алгоритмов и данных, не могут со 100% гарантией
обеспечить быстрого и полного понимания посторонним человеком
описываемой и решаемой задачи.

В качестве причин непонимания можно выделить 2 основных проблемы.
(проблема 3, "ничего непонятно и вообще тут без ... не разобраться"
как самая сложная в данном материале не рассматривается)

1. Проблема контекста за рамками описания.
Даже самая большая визуальная схема формата А0, не говоря уже о листе
А4 или экране монитора, как правило не может охватить целиком весь
контекст описываемой задачи - что-то всегда приходится держать в голове,
а человеку со стороны, который глянул на описание задачи впервые, этот
контекст вообще неизвестен.

Способ борьбы с этой проблемой - создание простых и понятных ссылок
между разными частями описания задачи.

2. Проблема сложности языка описания задачи.
Говорят, что нельзя просто описать сложную задачу.
Сложность языков описания (решения) задач постоянно растет вместе со
сложностью решаемых задач и даже быстрее - так сказать, про запас.

Герберт Шилдт, автор книги "C++ from the Ground Up": "По правде говоря,
синтаксис шаблонов, который описывает STL (стандартная библиотека
шаблонов), может показаться достаточно пугающим - хотя он выглядит более
сложным, чем есть на самом деле. ... Только будьте терпеливы, изучайте
примеры и не позволяйте незнакомому синтаксису затемнить лежащую в
основе STL простоту."

Оправдано ли упрощение языка программироания с целью снижения его
сложности, пусть даже и ценой обеднения средств решения поставленной
задачи ?
Ответ неоднозначный для многих.
Вроде бы признали - шаблоны в С++ слишком сложны и их в С# сначала
не было, но потом подумали и решили все-таки ввести.
А потом шаблоны и в Delphi проникли.


Никлас Вирт борется со сложностью программирования.
Но кому он сейчас интересен, старый классик-чудак, придумал Паскаль и
Оберон - спасибо, на их основе соорудили Аду и Джаву.
Чем сложнее язык программирования, тем больше средств для решения
поставленных задач, а дополнительные возможности, по мнению разработчиков
языка, хотя и делают его сложнее, но кому-нибудь да пригодятся. «Да и
вообще, если у других это уже есть, то чем мы хуже ?»

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


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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 22 Август, 2013 22:22 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Дмитрий_ВБ писал(а):
Что могу сказать — к самому языку Компонентный Паскаль претензий
никаких, а вот излишняя привязка программы к среде напрягает.
А Вас не напрягает ли привязка .exe к среде Windows? ;) Просто сразу хотелось бы напомнить, что ББ - это расширяемая среда выполнения, этакая мини-ОС поверх Windows, с интересным генезисом, компилятором на борту и составными документами в качестве приятного бонуса.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Пятница, 23 Август, 2013 07:24 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Иван Кузьмицкий писал(а):
Дмитрий_ВБ писал(а):
Что могу сказать — к самому языку Компонентный Паскаль претензий
никаких, а вот излишняя привязка программы к среде напрягает.
А Вас не напрягает ли привязка .exe к среде Windows? ;) Просто сразу хотелось бы напомнить, что ББ - это расширяемая среда выполнения, этакая мини-ОС поверх Windows, с интересным генезисом, компилятором на борту и составными документами в качестве приятного бонуса.

Человек просто не разобрался как собрать все в EXE и он не одинок в этой проблеме. По просьбе одного нашего преподавателя, сделал специальную команду, которая тупо пакует всю среду в EXE в Красноярской сборке (Red → Упаковать все в EXE). Это очень топорное решение, но позволяет получить независимый EXE малой кровью. Предлагаю в будущие сборки добавить продвинутый инструмент для этого. Сейчас есть (Инфо → Создать иснтрумент) но он не всегда корректно работает и пользоваться им сложновато для новичков.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2013 06:46 
Аватара пользователя

Зарегистрирован: Среда, 29 Март, 2006 12:09
Сообщения: 495
Да, уважаемые...
Почитал форум, август у вас был жаркий :)

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

За время моего отсутствия у меня произошло много событий, в основном связанных с необходимостью кормить семью. Я сменил работу, поработал на функциональных языках (Лисп и клон ML) и все же возвращаюсь к ББ. И вот почему.

Оберон (и КП) предоставляют уникальную возможность обеспечить динамическую загрузку/выгрузку модулей при очень мощном потенциале самого языка. Кроме того, каркас можно обозреть и понять в одно лицо, что важно для разработки малыми силами. И мне очень нравится сам язык.

Теперь конкретика.

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

1) Чтобы была понятна моя мотивация, поясню, у меня появился коммерческий интерес; я делаю проект, связанный с графикой, детали пока не раскрываю. ГУИ для него я планирую делать на ББ. Для этого делаю графику на AGG. Соответственно, для меня важно, чтобы ББ рос и развивался.

2) Было обсуждение инструментов слияния. Один из менеджеров, с кем мне довелось поработать, сказал замечательную вещь: «Если пользователю надо что то делать, и программа может принимать его ошибки и обрабатывать их, то она должна это делать, даже если пользователь трижды неправ.» После чего у нас в программе появился примерно десяток способов ввода одного и того же и программа подсказывает, не падая, где пользователю следовало бы написать по-другому. Это я к чему? ODC и составные документы — всего лишь инструмент общения пользователя и ББ. Не более того. Для запуска готового продукта ODC не нужен. Нужен скомпилированный код.

Пользователю удобно работать с подсветкой синтаксиса? Пускай. Пользователю хочется plain text diff? В чем проблема? Никто не говорит о том, что сразу надо пересобрать версию ББ с Kernel.ODC в виде текстового файла. Но если будет поддержка текстовых файлов в качестве исходников — так это же прекрасно! И не ломает архитектуру системы, а лишь увеличит потенциальную пользовательскую базу.

3) При старте ББ бутстрапится. Запускается ядро, которое затем запускает ГУИ и т.д.
Когда я увидел работу Петра, меня буквально озарило — в этом корень проблемы и решение одновременно!

Сейчас огромная сложность работы с ББ в том, что ГУИ неотделим от ядра. Вернее, отделение не дается малой кровью. Отсюда же вытекает проблема получения работающего исполняемого файла. Собрать его проблемы нет, но мы должны понимать, что отсекать. Должно быть наоборот. Сборка исполняемого файла должна быть приятным бонусом. Ядро, затем утилиты вокруг него, затем, если нужно, ГУИ.

Если удастся разнести код по независимым подсистемам, что обсуждалось и предоставить пользователю самому решать, как и что будет бутстрапиться, то мы получим очень, нет, ОЧЕНЬ гибкую систему. Вопрос с консольной версией и переносом на другие платформы упростится в разы.

4) Развитие языка. Мы можем сколько угодно говорить о канонической версии, о том, что Оберон крут и ограничения суть есть хорошо, но жизнь не стоит на месте, и кое-какие изменения бы не помешали. Причем это не прихоти новичков, тыкающих пальцем в документацию с фразой «ай-ай-ай, у вас нет вот этой крутой фишки, смотри язык X и Y». Все же практика — критерий истины.


Вот вещи, которые нужны лично мне:

-- инициализация массивов, как это сделано в XDS:
BEGIN
gsv_default_font^ := GSV_DEFAULT_FONT{040H,000H,06cH,00fH,015H,000H,00eH,000H}
END.

-- Процедура SYSTEM.ToString(x), которая позволила бы произвести распечатку содержимого произвольной переменной по аналогии с трапом, но без трапа.

-- Однострочные комментарии.

---------------------------------------

Поймите меня правильно, я не собираюсь развивать флейм, это неконструктивно. Больше того, я действительно был разочарован общением на форуме и менторским тоном многих обсуждений (напомню, было закрыто две ветки про Оберон на Королевстве Дельфи).

Но сейчас все изменилось — Оминк вышли из игры и после смены лицензии мы имеем дело с обычным opensource проектом. И теперь все должны договариваться, ибо сил мало, а задач много. Привет Карлу Фогелю.

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

Простите за сумбур.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2013 13:25 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Димыч писал(а):
Код:
BEGIN
gsv_default_font^ := GSV_DEFAULT_FONT{040H,000H,06cH,00fH,015H,000H,00eH,000H}
END.
Никогда не понимал, зачем такая магия в исходниках важных системных компонентов :) И сопровождать такое я бы не хотел.
Ну, это к вопросу о хотелках.

Димыч писал(а):
у меня появился коммерческий интерес;

Димыч писал(а):
Пользователю хочется plain text diff? В чем проблема?

Димыч писал(а):
Пользователю удобно работать с подсветкой синтаксиса? Пускай.
Ы, я думаю, в 90-х так же рассуждали бизнесмены владельцы жавы.
Бизнес, он такой.
Берем примитивный базис (плейнтекст, низкие издержки на старте) ->
стартуем и заполняем рынок (пусть программа неправильная - зато работает) ->
вокруг примитивного базиса наращиваем платную инфраструктуру (без гитхаба уже никуда) ->
растем, доминируем, меняем реальность (теперь плейнтекст у всех, гитхаб у всех, а кто не с нами, тот без денег останется).

Разумно ли позволять чужому базису проникать в ББ, я не знаю. Ведь бизнес, кроме очевидной цели срубить бабла подразумевает (в идеале) реализацию твоих или близких тебе идей.
А то ведь, все эти плейнтексты такой пустяк. Вон, тут говорят, что ИТ стагнирует, что кризис идей. В мире плейнтекста закончились идеи :D

Димыч писал(а):
Если удастся разнести код по независимым подсистемам, что обсуждалось и предоставить пользователю самому решать, как и что будет бутстрапиться, то мы получим очень, нет, ОЧЕНЬ гибкую систему.
Угу. Все именно так и получилось в прототипах. Ведь ядру все равно, что запускать, для него "хост" это просто подсистема.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2013 23:43 

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

GUI в Блэкбокс имеет свои особенности. Поскольку Блэкбокс наследует многие черты от Оберон ОС, у которой графика - это неотъемлемая часть пользовательского интерфейса, то, по мне, несколько странно представить себе Блэкбокс без этой самой графики. Графика изначально "вшита" в Блэкбокс. Поэтому "Безголовый" Блэкбокс получится именно безголовым, то есть оторванным от интерфейса Оберон ОС. Таким образом, "безголовые" варианты несут другой смысл и уже не должны являться логическим продолжением развития Блэкбокса.

Но это абсолютно не означает, что я против идеи отделения графики от каркаса Блэкбокса. Поэтому наиболее логичным путём я считаю выделение "безголовых" вариантов в отдельные проекты. В этом случае, однако, следует переосмыслить их назначение.

В теме headless-сборка для Windows (Linux) уже высказывался на тему отделения графики.
Роман М. писал(а):
Пётр Кушнир писал(а):
Уважаемые коллеги, я смутно припоминаю, что кто-то делал сборку с модификацией хоста, вырезав gui-часть, но оставив остальной фреймворк полноценно работающим, то есть внутри работали Actions, крутился главный цикл и тому подобное.
По форуму не нашел.
Если таковой нет, предлагаю здесь её обсудить/реализовать. В частности, обсудить идею реализации blackbox-daemon :)

Каркас БлэкБокс исторически основан на идее Оберон ОС, то есть активно использует графический вывод на экран, интерактивно взаимодействуя с пользователем. Это включает вывод графических примитивов и текста.
Поэтому логично задать вопрос о перечне возможностей такой сборки. Ведь если таковая предоставлят какие-то сервисы, то посредством какого канала? По некоторому сетевому протоколу, через файлы, сокеты (IPC)?
По-моему, для без-GUI режима работы имеет смысл вообще отвязаться от совместимости с БлэкБокс.

Следует ответить на вопрос о перечне предоставляемых сервисов и то по какому каналу они будут предлагаться, иначе нет смысла затевать новые сборки.
Какие имеем варианты работы: библиотечные вызовы, в виде архитектуры клиент-сервер.
Если библиотечные вызовы, значит нужно строить некоторый аналог из существующих каркасов, таких какие есть для Java, .NET. Допустим, нужно работать с веб - берём компонент, дающий сервисы для веба. Также для работы с периферийными устройствами, с базами данных и прочими.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Понедельник, 23 Декабрь, 2013 00:14 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Роман М. писал(а):
Следует ответить на вопрос о перечне предоставляемых сервисов и то по какому каналу они будут предлагаться, иначе нет смысла затевать новые сборки.
Ну так запуск и работа без гуя и есть предоставляемый сервис.
Кто-то на этом напишет погодный бэкэнд для датчика влажности в виде демона, кто-то - своего убийцу дропбокса в системном трее, а кто-то - консольный олимпиадный сервер на вдс в амстердаме. Вот и весь смысл. Вы либо можете запустить компонентный каркас в виде такой-то безголовой сборки, либо не можете.
А как только запустили - там уже компоненты порешают.
А компонентам что нужно - им нужен кроссплатформенный слой да возможности рантайма, типа System + Kernel, чтобы write once run everywhere :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Среда, 25 Декабрь, 2013 16:16 
Аватара пользователя

Зарегистрирован: Среда, 29 Март, 2006 12:09
Сообщения: 495
Пётр Кушнир писал(а):
Димыч писал(а):
Код:
BEGIN
gsv_default_font^ := GSV_DEFAULT_FONT{040H,000H,06cH,00fH,015H,000H,00eH,000H}
END.

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



Практическая задача!
Есть матрица инициализации для алгоритма CRC:
Код:
    static const unsigned crc32tab[256] =
    {
       0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,


Как мне ее инициализировать?
Если не вложенной инициализацией (по аналогии с CONST S='Димыч';), то как?
Подскажите, если есть другой способ. Конечно, кроме самоочевидного
Код:
crctab[0]=…; crctab[1]=…;crctab[2]=…;


Пётр Кушнир писал(а):
Ы, я думаю, в 90-х так же рассуждали бизнесмены владельцы жавы.
Бизнес, он такой.

Да, и где сейчас жава и где КП?
При сопоставимых функциональных возможностях жава запускается на миллиардах устройств :)

Есть масса инструментов, которые делают мою работу с plain text крайне эффективной.
sed, awk, diff и прочее. Мой любимый Emacs сколько бы не хаяли — весьма крутая штука. И ведь это все еще простой текст. Даже org-mode работает в простом тексте.

Пётр Кушнир писал(а):
И вот любое изменение будет приводить к тому же самому. Вот вы захотите развить SYSTEM, и в остальном мире тут же образуются горы несовместимого кода. Нехорошо.

Насчет SYSTEM я, вероятно, был неправ. Пусть будет что-нибудь вроде DevDebug.ToString()

Но что важно, так это тот факт, что обратная совместимость не панацея.
Мы с вами тут не Internet Explorer поддерживаем, чтобы считаться с миллионами пользователей. Если есть возможность поиметь массу плюсов от реструктуризации да от переделки, то можно и что-нибудь поломать. Тем более, что не один раз уже писалось о том, что часть функционала ББ писалась в спешке и с нарушением герметичности.

Мне надо, я буду писать ассемблерные вставки и ставить костыли. Я никому ничего не навязываю.
Важно было узнать, что Оминк изменили лицензию. Теперь можно работать так, как считаю нужным.
Другой разговор, что девелоперов мало и нужно считаться с другими и договариваться. Я прекрасно осознаю последствия поломки интерфейсов, поэтому думаю, что это нужно делать осознанно и осторожно. Но и считать что-то незыблемым не хочу.

Разбираюсь сейчас с хостом. Странно, почему не сделали модуль Cursors/HostCursors?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Среда, 25 Декабрь, 2013 19:07 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Димыч писал(а):
Подскажите, если есть другой способ. Конечно, кроме самоочевидного
Почему "кроме"?
Если эти значения можно генерировать, то нет нужды в константах. Если эти значения нельзя генерировать, то разместите все 256 присваиваний в отдельном модуле, ну или сгенерируйте его исходник. Разве не проще, чем усложнять компилятор, который будет очень трудно потом раздать всем девелоперам-пользователям вашего продукта.
Вот, например https://github.com/kpmy/zinnamirror/tre ... nicode/Mod и все работает :)
Димыч писал(а):
Да, и где сейчас жава и где КП?
Да это же опять двадцать пять :D Джава там же, где и миллиарды долларов.
Димыч писал(а):
Есть масса инструментов, которые делают мою работу с plain text крайне эффективной.
sed, awk, diff и прочее. Мой любимый Emacs сколько бы не хаяли — весьма крутая штука.
Мне все же кажется, наличие удобных инструментов для plaintext это не доказательство. Представьте себе стимпанк-вселенную с прецизионными механическими вычислителями размером с Кремль. Ну, зато технологии будет уже 200 лет.
Я вот думаю, что проблема плейнтекста в ББ высосана из пальца. Как и другие проблемы, типа важности автокомплита. Если бы плейнтекст был важен, то давно бы появился компонент, который помогает работать с плейн-текст исходником незаметно, прозрачно и без проблем совместимости. Пока что я вижу лишь предложения перевести весь ББ на плейнтекст, чтобы кому-то было хорошо. Это не похоже на реально необходимую фичу, это скорее удовлетворение амбиций по управлению общим проектом.
Димыч писал(а):
Мы с вами тут не Internet Explorer поддерживаем, чтобы считаться с миллионами пользователей. Если есть возможность поиметь массу плюсов от реструктуризации да от переделки, то можно и что-нибудь поломать.
<...>
Мне надо, я буду писать ассемблерные вставки и ставить костыли. Я никому ничего не навязываю.
Любой из подходов приведет к потере пользователей. Но ломать и менять всегда успеем. А вот сделать тонко и продуманно, это задача, да. :) Ну и хорошо ведь, когда любой твой код может пролежать три года в архиве, а потом сразу заработать. Потому что преемственность и совместимость для всех это лучше, чем форсированный прогресс единиц. Учитывая, что сейчас оминк нет, любое разбегание людей по своим норам приведет к окончательному забытию ББ. Линукс-версию таким образом чуть не похоронили.
Лично я вот опасаюсь, что любое нестандартное решение оставит код невостребованным. Код может быть сколь угодно крутым и ценным, а пока его заведешь - все проклянешь. Либо же должны быть такие решения, чтобы работа по запуску компонента не приводила к необходимости патчить HostFiles, прости господи :D Про них и думаем.
Димыч писал(а):
Разбираюсь сейчас с хостом. Странно, почему не сделали модуль Cursors/HostCursors?
Как разбираетесь? Если не трудно, пишите о результатах в виде блога, так веселее.
По поводу курсоров есть мысль, что малое количество типов курсоров потенциально совместимо с большим числом ОС, чем огромный набор курсоров, который ни в одной ОС полностью не представлен.
Поэтому в системном слое представлено обобщенное множество (стрелка, палец, крестик), а в хосте уже конкретные.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 26 Декабрь, 2013 04:59 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Пётр писал(а):
Но ломать и менять всегда успеем. А вот сделать тонко и продуманно, это задача, да. :) Ну и хорошо ведь, когда любой твой код может пролежать три года в архиве, а потом сразу заработать. Потому что преемственность и совместимость для всех это лучше, чем форсированный прогресс единиц.
Вот, согласен с Петром, надо менять потихоньку, обсуждая последствия и совместимость, и что важно не усложняя особо каркас.

Дмитрий, за обсуждения плоского текста я предлагаю карать баном на неделю за троллинг. Вроде понятно ведь, что куча народа против и любая дискуссия при этом накаляется. Если вам так хочется, никто не мешает хоть сейчас хранить все исходники в плоском тексте, так уже сделали Роман М., Борис И., ... Заведите отдельную тему для обсуждения этого плоского ответвления от Блэкбокса.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 26 Декабрь, 2013 08:30 
Аватара пользователя

Зарегистрирован: Среда, 29 Март, 2006 12:09
Сообщения: 495
Ладно, ответы на свои вопросы я получил.
Когда руки дойдут, сделаю себе плоские исходники. Хотя я и так, сначала делаю все в тексте.
Тема закрыта.

Блог есть, буду писать туда; ссылка чуть позже будет, когда первую доку допишу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 26 Декабрь, 2013 08:33 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Поддержка в BlackBox "плоских" исходников сразу приведёт к тому, что основная масса разработчиков будет писать код не внутри системы, а в различного рода IDE со свистелками и наворотами. Не думаю, что сообщество хочет этого.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 26 Декабрь, 2013 09:02 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Madzi писал(а):
Поддержка в BlackBox "плоских" исходников сразу приведёт к тому, что основная масса разработчиков будет писать код не внутри системы, а в различного рода IDE со свистелками и наворотами. Не думаю, что сообщество хочет этого.
Разрешите подписаться. Исходники ББ в плоских текстах разрушат саму идеологию ББ. Лично я придерживаюсь такой логики (извините за цитату самого себя):
Цитата:
переведём все исходники ББ в плоский текст. Почему нет? Это удобно для версионных систем и систем коллективной разработки, которые работают с плоским текстом.

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

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

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


Есть ещё размышления:
http://forum.oberoncore.ru/viewtopic.php?p=81520#p81520
http://forum.oberoncore.ru/viewtopic.php?p=81553#p81553


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 26 Декабрь, 2013 12:00 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Вот она, избыточная сложность.

Цитата:
Исходники ББ в плоских текстах разрушат саму идеологию ББ

И вернут идеологию Оберона.

ps Тролю, да.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 26 Декабрь, 2013 12:15 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Димыч писал(а):
Блог есть, буду писать туда; ссылка чуть позже будет, когда первую доку допишу.
Ну я подразумевал писать в ветку форума сообщения типа блоговых :)

Димыч писал(а):
Когда руки дойдут, сделаю себе плоские исходники.
Мне кажется, имеет смысл изучить работу с исходниками в ББ и по результатам реализовать компонент, который позволит прозрачно управлять исходниками любых типов. По принципу черного ящика: доминирующая реализация не исключает остальных.
Плейнтекст таким похвастаться вообще не может, впрочем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Куда собсна плывем?
СообщениеДобавлено: Четверг, 26 Декабрь, 2013 15:46 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Борис Рюмшин писал(а):
...Сейчас запал есть, а через год?

Все задачи, что тут решались --- решались пока только в контексте того, что на практике требовалось. На счастье ещё кое-кому требовалось и требуется каркас изучать изнутри.... Вот требовался бы до зарезу 64 бит, ибо страсть как нужен и часть ведущегося проекта --- был бы. А нет... и что делать?


Добавлю свои пять копеек. Необходимо для начала написать и согласовать между участниками проектую документацию, где будет описано, что предполагается делать и как. Если есть проектная документация, то даже если кто-то покинет проекте, кто-то другой по этой документации сможет продолжить развивать проект.

Также можно на практике поддержать не только движение за открытые исходные тексты, но и движение за открытую проектную документацию:
http://is.ifmo.ru/works/open_doc/
При этом хотелось бы, чтобы документация была на русском и английском языках.


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

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


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

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


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

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