Open EnergonV opened 6 years ago
Мда, работы тут непочатый край. К сожалению из меня помощник никакой. Мало того, что у меня почти совсем нет свободного времени, так ещё и знаний для такой работы маловато будет. Меня больше волнуют прикладные решения, типа портирования Qt-5 на данную платформу. В дебри компилятора лезть совсем не хочется. На работе только успевай выдавать готовый код.
Qt-5 MSYS2 устанавливает через pacman -S mingw-w64-i686-qt5-static
Пытаюсь перейти с Visual Studio на Mingw, поскольку приходится работать на оба фронта, фактически на нескольких языках сразу. Но C++ vs. D - это как самолёт по сравнению с автомобилем. Пока никак не удаётся довести wxWidgets до нормы - код из С++ нужно представлять в Си через dll. Хоть в неомонастырь подавайся))) специальный, для разработчиков ПО))) "Не жди меня, мама)))
Что касается рантаймной библиотеки Динрус, то в ней осталось устранить несколько недоработок, связанных с потоками (stream), конкурентностью (concurency), работой с COM и вводом-выводом на русском в консоль и файл в правильной кодировке. DinrusWX и GtkD станут после этого работать лучше. То есть, с формами вопрос полу-решённый. Останется доработать графику. А после можно будет уверенно браться за более масштабные и того-стоящие проекты. (Это тот ряд задач, который у меня перед собой. Конечно никак не получается заниматься тем, что требует работодатель и проч. Но как-то с этим нужно справляться.)
У нас осталось пару дней на подачу заявки - https://gosstart.ru/ Не знаю, уложимся ли... Требуется ещё пару человек в команду... Фактически, я подаю заявку. Чисто в информационном порядке. Не думаю, что из этого что-то получится. В этот раз - едва ли...
А в чем модель коммерциализации? Как это все продать то ....
Так выглядит заполненная мною в субботу, 13-го января, форма с заявкой. Не думаю, что "победа за нами", да и к участию мало кто готов. Тем не менее, "пусть знают".
Это "разведывытельное мероприятие" с целью узнать, делает ли 1С язык программирования. Результат показывает, что создать национальный язык программирования у них как задача отсутствует. Честно говоря, чувствуется некоторая усталость от постоянных доказательств необходимости создания национального языка программирования. Работал бы он уже полноценно, писал бы на нём другие вещи, например, искусственный интеллект, новую операционную систему или систему электронного самоуправления.
Java, действительно, на данный момент занимает первое место в рейтингах. Однако, уже готовятся - на базе LLVM - фронтэнды для всех традиционных языков программирования (даже для интерпретируемых, таких как Python). На входе могут быть любые языки.
Почему бы не использовать русский при программировании? - Это уже не вопрос. Ответ на него - да, можно. Вот поэтому перспектива у нашего проекта есть в любом случае. И это просто НЕОБХОДИМО для детей, науки, ускорения прогресса и т.д.(!)
О РАНТАЙМЕ ДИНРУС
Уолтер Брайт, основатель
D
, утверждал, что статических библиотек достаточно; динамические (dll) только увеличивают число файлов программы, что ухудшает переносимость, так как часто тот или иной элемент теряется. Однако, исполнимые модули без динамических разделяемых библиотек приобретают огромные размеры.Выводы:
ДПБ (динамическая переносимая библиотека)
, т.е.DLL
, представляет собой файл с конечным - машинным - кодом для определённой архитектуры ЭВМ. Поэтому является "конечным" целевым продуктом, который может далее быть использован уже без обязательного наличия исходников. Совокупность таких библиотек должна представлять собой систему. Коды из библиотек должны просто и эффективно использоваться в основанных на них приложениях.В языке D рантаймная библиотека строится не без использования стандартной, кроме неё также используются
Windows API
или API другой системы-хоста. В итоге нельзя отделить её в небольшую самостоятельную часть. Кроме того, все потоки и проч объекты языка тесно связываются со сборщиком мусора - основным элементом рантаймной библиотеки.Вывод:
Разделять код на рантайм, сборщик мусора и стандартную библиотеку мало практично. По сути, это единое ядро языка.
DINRUS.BASE.DLL
Исходя из этого, я и пришёл к решению собрать все эти детали в
Dinrus.Base.dll
На данный момент это лишь экспериментальная версия, которая проходит ряд испытаний и усовершенствований.В ней использованы элементы из разных версий языка D, переработанные мною. Многие элементы нахлёстываются один на другой, так как унаследованные коды языка были написаны без единого стандарта и используют разные классы и функции с одинаковым функционалом... Этот момент заставляет тщательно выбирать наиболее практичный вариант реализации, либо комбинировать несколько вариантов в одном.
Так как библиотека динамическая, то в ней уже нет смысла сохранять деление на пакеты, и есть смысл собирать всё в один модуль для импорта. Поэтому весь функционал пакета
std
собран в одном модулеstdrus
; весь функционал пакетаstd.c.*
- в модулеcidrus
. Все объявления типов помещены в модуль base, который наряду с модулемobject
используется при компиляции автоматически.На данный момент в СМ и в коде Динрус используется два класса Нить -
stdrus.Нить
иthread.Нить
. Первый - отPhobos
, второй - отTango
. Это вынужденная мера. Возможно, в последующей переработке ситуация изменится.ПОРТИРУЕМОСТЬ
Естественно,
Dinrus.Base.dll
- это решение только для ОС Windows. На других платформах можно просто собрать эту библиотеку из имеющегося рантайма, сделав соответствующие обёртки-руссификаторы. Можно даже использовать вторую версию языка D, так как в форме dll это никак не повлияет на её применение с первой.Реальный эксперимент состоит в том, как будет работать код на русском языке, помещаться в библиотеки и т.д. Так, например, при декорировании компилятор указывает число символов, а затем имя. Возьмём, например,
Так записывается
struct ДинАрг(цел i)
из модуляtpl.bind
в статической или динамической библиотеке. Из чего видим, что число символов явно указано для размещения памяти при чтении и раздекорировании. Кроме того, становится понятно, что русские символы требуют в 2 раза больше пространства, так как вUTF8
используется, в отличие отASCI
, не 1, а 2 байта для представления символа.Следовательно, было бы экономнее, если бы компилятор вместо русских букв транслитерировал запись в английский, как это реализовано, например, в языке
Глагол
. (Это информация для размышления для того, кто намерен заняться компилятором и его усовершенствованием, например, подGCC
илиLLVM
).Значит, приходим к выводу, что библиотка с русскими знаками будет на 20-30, а то и более, процентов больше по объёму занимаемой памяти, что не очень хорошо. Другое дело, использование алиасов.
Если бы
ДинАрг
был объявленstruct DynArg (int i){}; alias DynArg ДинАрг;
мы бы могли в коде использовать русский псевдоним, но в компиляции был бы отражён английский. Однако, это усложнило бы нам работу написанием лишних объявлений псевдонимов...Таким образом, с тем, что русский язык добавляет веса, приходится смириться.
Но всё же остаётся масса сомнений, что всё отражается правильно, так как в листинге наблюдаются нередко странные значки.
Например,
Создаётся впечатление, что местами код "битый"...
Таким образом, возникает твёрдая необходимость основательно переработать код компилятора. И, пожалуй, на этом и сосредоточу своё внимание(!)
ПОСЛЕДНИЕ ПАКЕТЫ
Два последних пакета -
WX
иgtkD
показали неудовлетрворительные результаты. В версииРулада
они работают на тройку - часто возникаетAccessViolation
по непонятным причинам. В версииДинрус
некоторые вещи, работающие вРуладе
, вообще не работают.Рулада фактически основана на чистом рантайме
D1
. Динрус - это его руссифицированная переработка.Таким образом, баги из
D1
перешли вРуладу
"унаследованным" путём; ну, а вДинрус
я их добавил ещё больше. Такие выводы.На этом почти всё, что можно было сказать о базовых вещах языка.
Некоторые моменты появляются из-за разницы в статическом и динамическом базировании рантайма: то, что нормально работает в статике, в динамике нужно передавать как-то иначе. Например, если ряд классов основан на абстрактном классе и на шаблонах, то какой-то из "потомков" теряет свои "корни" и связи с одним из предков, и начинает работать неправильно, поскольку какие-то условия были нарушены.
Так ведёт себя сейчас, например, класс
stdrus.БуфФайл
.thread.Фибра
не проходит тест на стресс памяти.stdrus.читайстр()
не может правильно передавать символы на русском из командной строки.И это лишь ряд замеченных недоработок. Будем надеяться, что дело не так уж безнадёжно )))