RUSSIAN(Русский)
ENGLISH


Эта функция использует куки.
Если браузер не принимает куки,
используется светлая тема.

Введение
 

Здесь представлены планы по развитию языка AL-IV (АЛФОР), расширению его синтаксиса и семантики, по реализации его поддержки для различных платформ.
 

Мои текущие планы

(в виде "карточек")

 

Мои старые планы с 2016

по 2020 (в основном реализованы ранее):

 

Что надо сделать

Что делается

Что уже сделано

Что отменено
   
Все эти работы завершены и могут использоваться в реальных программах. Могут потребоваться специальные модули для особых случаев (например, модули для работы с БД MS SQL, mySQL и т.п.), но они несложным образом могут быть добавлены по мере надобности.
 
   
Путь к программированию под Linux есть - по крайней мере, через Free Pascal + Lazarus. Можно так же скомпилировать компилятор (AL-IV -> Pascal) под Linux, и заниматься разработкой под Linux. (Если что-то сломалось в конкретной текущей версии, исправления вряд ли займут много времени).
 
   

Многопоточность в основном реализована. Но результат - сомнительный. Слишком большие затраты на создание/работу/завершение самих потоков. В случае разбиения задачи на однотипные подзадачи результат - только общее замедление. Или, крайне незначительное увеличение скорости работы. Многопоточность может иметь смысл при разделении на потоки различных видов работ (обмен данными с дисками, с БД, вычисления, графика, звук).
  
   
IDE + Дизайнер формы + Дизайнер меню + Дизайнер печатных отчетов
  
 

 

 RTTI: класс {RTTI} + встроенная поддержка RTTI
   
Интерпретатор - готова версия на C#. Быстродействие отвратительное, но на C# вряд ли получится быстрее. Для запуска ненагруженных приложений, впрочем, очень хорошо работает.
  
   
Программирование для платформы Android. Используется Java for Android + Android Studio и сборка из командной строки (требуется Android Studio  установленный + драйвера adb).

В связи с большим объемом работ, по этой тематике ведется собственная доска планирования.

 

Mac / iPhone

Что касается платформы Mac / iPhone, то эту умирающую платформу, вероятно, уже нет необходимости поддерживать.

 
Профилировщик может быть получен практически бесплатно, т.к. счетчики вызовов функций уже есть в коде (кроме /final).

 

      

 

Что сделано

 

Дизайнер формы
 

Реализован. Даже с дизайнером меню. Не хватает дизайнера печатных отчетов. И компонентов / классов для печати.

 

Параллельное программирование
 

 

Что надо сделать

Что делается

Что уже сделано

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

Для передачи объекта в процесс используется метод
Take({Object} A|rray_of_objects[],
BOOL Together|_with_all_hard_linked_fields)
Отправленные объекты изымаются из адресного пространства текущего процесса (ссылки на них перенаправляются на NONE).

Для обратной отправки обработанных объектов в родительский процесс, текущий процесс может использовать глобальную функцию
Yield({Object} A|rray_of_ready_objects[]). Или просто удалить на них все ссылки, после чего объект автоматически окажется в породившей нити.

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

Важный момент: при отправке объекта он изолируется от прочих объектов, остающихся в потоке-отправителе. Объекты остаются связанными ссылками-полями, только если отправляются вместе, одной командой Send или Yield.

 Для обеспечения возможности частичной обработки массивов в таких нитях-потоках, реализован специальный класс {Slice}, позволяющий "отрезать" часть массива, "изъяв" эту часть из памяти самого массива, после чего объект такого класса с отрезанным фрагментом массива может быть перенаправлен на обслуживание в другую нить-поток.
Особые синтаксические конструкции.

Реализован простой вариант, без введения специальных языковых конструкций:

специальный объект базового класса {Thread}, при его запуске в порождающей нити формируется зеркальный объект класс {Thread} становится выходным порталом, через который можно передавать данные (объекты) и управлять работой созданной нити.

 
Доступ из отправляющего потока на чтение требуется для {Slice}-фрагментов, с защитой от записи, при полном доступе в том потоке исполнения, в который он передан на исполнение. В этом случае можно будет избавиться от копирования массива перед его передаче на нижний уровень для обработки (например, в алгоритме быстрой сортировки quick sort), и реально достить увеличения производительности при распараллеливании сортировки массивов.
      
 

 

Поддержка платформы Android

Используется Java + Android Studio.

 

 

 
 

Что надо сделать

Что делается

Что уже сделано

Что отменено
   
Компилятор ALIV -> Java. Предыдущая версия была ориентирована на первоначальную библиотеку Java awt, не на Android Java. Но сам язык не отличается, отличаются только библиотеки.
Поддержка фреймворка awt. Похоже, не имеет вообще смысла ориентироваться на любые фреймворки Java для работы на desktop. Ни один из них не годится для серьезной работы, все недоделанные и глючные. Чего стоит сам установщик Java, в котором кнопки уехали за пределы диалога, и никто в Oracle этого не видит и не может исправить.
   
Разработка визуальных приложений под Android (пока без OpenGL). Цель - запуск минимального приложения с пустой формой на устройстве с Android 5 или выше.
  
 
Запуск приложения с несколькими формами и простейшими контролами (метка, кнопка). Обработка событий нажатия и перетаскивания (onTouch) на всех элементах. Рисование на битмапе и сохранение в файл PNG. Формирование лога (перенаправление консольного вывода в лог). Разметка элементов на форме.

Переключение между формами (через системное меню активности). Программное завершение.

Модальный диалог (одна кнопка ОК или два ДА/НЕТ). Обработка системной кнопки НАЗАД (ответ на модальный диалог/отправка на задний план).

Ввод текста в компоненте {Paint_lines}, отображение каретки в позиции ввода.
  
 
Базовое программирование визуальных приложений. Все тесты из Test_visual_projects и часть из папки Demo компилируются и работают.
  
Диалоги выбора файла/папки. Стандарт программирования для андроид не предполагает таких средств для использования в пределах одного приложения. Необходима реализация платформо-независимого диалога выбора мест для сохранения файла / файла для открытия в процессе работы, хотя бы из ограниченного набора локаций (доступных пользователю).
  
Рисование в канве. C учетом поворотов, корректное отображение фигур, закраска, текст, рисование битмапов.
  
   
Обработка событий.

Сохранение по событию closed, восстановление в конструкторе главной формы.

 		  
   
OpenGL под Android.
  
IDE под Android должен работать как минимум как текстовый редактор с подсветкой синтаксиса и другими функциями, необходимыми при разработке.
  IDE: для проектов под Android есть генерация проектов {Project_wizard}.  
   
Консольные приложения под Android (в режиме имитации консольного окна: для консольного приложения, в него встраивается стаб-приложение Console_app).
 
Интерпретатор под Android. Должен позволить разрабатывать приложения для Android, используя только Android устройство.
      
 
 

 

 

RTTI
 

Для того, чтобы для передачи данных из объекта в набор визуальных элементов ({Edit}, {Checkbox}, {Combo}, {Memo}, ...) и обратно можно было не выписывать наборы присваиваний типа
Edit_something.Set_text(
    obj.Something)
Checkbox_number_1.Set_checked(
    obj.Some_flag_set)
Combo_number_2.Select(
    Combo_number_2.Find(
        obj.Item_X))
... и т.п.

А можно было вызвать процедуру типа
Read_values_from_obj(obj), которая перечислила бы все поля объекта obj, нашла те из них, которые соответствуют визуальным компонентам на форме (Имя поля = имя компонента), и присвоила им значения в соответствии с типами элементов и полей.

То же и в обратную сторону, чтобы это можно было сделать одним вызовом Write_values_to_obj(obj), плюс окрасить в красный цвет при этом те поля, значения которых по разным причинам не удалось положить в объект.
 

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

Так же, {RTTI} позволяет обеспечить механизм изоляции объектов при отправке их из одной нити в другую (методы Take/Yield класса {Thread}).

 

 

Интерпретатор
 

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

Теоретически, интерпретатор может позволить внедрить пошаговую отладку кода. Интепретатор может быть внедрен в редактор (для реализации работы кода, начинающегося символами '**').
 

Самая сложная проблема создания интерпретатора- вызов CALLBACK-функций из нативного кода. Но все решаемо.

Что надо сделать

Что делается

Что уже сделано

Что отменено
   
Интерпретатор на C#. С одной стороны, C# легче отлаживать, с другой - особенности языка не позволяют использовать низкоуровневые приемы, позволяющие ускорить исполнение кода. В случае интерпретатора, быстродействие результирующего кода получается в ~200 раз меньше, чем в случае откомпилированного кода. Хотя это не критично для режима отладки, или, например, для реализации визуальных интерфейсов, где не требуется перемалывать миллионы байт в секунду.
  
Интерпретатор на Delphi. Теоретически, может позволить сократить различие в быстродействии между интерпретатором и машинным кодом примерно на порядок. К сожалению, полезен только под платформами Windows + Linux.
      
Интерпретатор на Java - для платформы Android. Проблемы с быстродействием примерно те же, что и в C#, но есть шанс позволить разрабатывать код для Android прямо на Android,  в отсутствие средств для компиляции непосредственно нга платформе Android.
      
 

 

 

 

IDE AL-IV
 

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

Приоритет: ВАЖНО.

Что надо сделать

Что делается

Что уже сделано

Что отменено
   
Редактор с подсветкой синтаксиса для языка AL-IV. С возможностью навигации по вызываемым функциям, полям. С подсказкой параметров функций. С визуальным дизайнером форм и меню.
Отменена предварительная компиляция кода с целью организовывать подсказки по параметрам функций на основе результатов предкомпиляции. Причина - медленно, возникают значительные задержки во времени.
   
Возможность запуска компилятора непосредственно из редактора, с отображением списка полученных ошибок и предупреждений и с возможностью навигации по этим ошибкам. С учетом изменяющихся позиций ошибок в коде, при редактировании кода. Недостаток: пока работает компилятор, редактор находится в режиме ожидания, и недоступен.
  
Распараллеливание запуска компилятора из IDE с редактированием кода.
      
Встроенный пошаговый отладчик (режим интерпретатора).
      
Интеграция с профилировщиком (цель: визуальное отображение наиболее часто используемых операторов).
      
Подсказка по библиотечным функциям и функциям из классов проекта, даже из не загруженных классов (использование теневой загрузки в режиме только чтение).
      
Быстрые подсказки по переменным (полное имя переменной/поля, значение константы), функциям, типам при наведении мыши (без клика).
 Когда идет подсказка в режиме вставки выделенного текста, стрелка вправо должна по одному символу вводить предложенное, сдвигая курсор вправо. Аналогично, CTRL_вправо - двигаясь вправо до очередной границы регистра или буквы/не-буквы.    
 

 

Отладчик, встроенный в IDE
 

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

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

 

 

 

Содержание

Введение

Мои текущие планы

Мои старые планы с 2016

Что сделано

Содержание

 

 

 


 В начало