LINUX.ORG.RU

Metaprog: универсальная графическая среда программирования [в разработке] часть 4

 , , ,


4

3

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

FAQ

1. Где скачать?

Релиза еще не было. Идет разработка, темы посвящены ей. Есть сделанный на LabVIEW прототип (его работа показана в примерах).

2. Почему не открыт код LabVIEW-прототипа Метапрога?

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

3. Почему не Дракон, MIT App Inventor, Unreal Blueprints?

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

4. Чем плохи LabVIEW или MyOpenLab?

LabVIEW пропиетарный, а MyOpenLab - хоть и опенсорсный, но какой-то недоделанный (пытался у себя запустить - выдало джава эксепшоны). Да-да, опенсорсный «клон» LabVIEW написанный на джаве! LabVIEW хотя бы на C++, а это все же меньшее зло. Обе эти системы даже не сделаны «сами на себе» в графике. Они даже не пытаются претендовать на универсальную замену всем текстовым языкам, хотя LabVIEW могло бы, если бы не тупость копирастов. Эти системы написаны на текстовых языках, их код (даже если б LabVIEW был опенсорсным) невозможно редактировать, ни разу не обращаясь к текстовым языкам. Метапрог изначально предполагает полный отрыв от текста и текстовых языков, за исключением Си как бэкенда. И то пользователям никогда не придется иметь дело с текстовым Си за исключением блоков сишных вставок (для особых случаев типа арифметических операций, ассемблерных вставок итп).

5. Почему как бэкенд выбран именно Си?

Си - это по сути мощный «кроссплатформенный ассемблер». На нем сделано огромное количество кода, готовых библиотек, в Линуксе (и вообще UNIX) Си - общепринятый стандарт для системного программирования. Кроме того, на Си делаются прошивки микроконтроллеров. Си работает быстро, не требует тяжелых и глючных рантаймов, и в то же время дает наиболее полный контроль над поведением программы (из кроссплатформенных языков).

6. В Си указатели и ручное управление памятью. Это же так сложно!

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

7. А как же браузерные и игровые скрипты и прочие ситуации, где ручное управление памятью ненужно и даже опасно?

Пункт 6 касается разработки программ, то есть исполняемых файлов и библиотек. Для задач типа браузерных/игровых скриптов, разумеется, будут свои подмножества Метапрога без указателей.

8. Почему в Метапроге будут предпочитаться бинарные форматы и чем это лучше?

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

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/flatten_to_string/

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/unflatten_from_string/

Что-то подобное будет и в Метапроге. При открытом коде никаких сложностей с чтением бинарных файлов не будет.

9. А как будет обеспечиваться совместимость со старыми файлами, сетевыми протоколами итп, если будет изменен тип?

Если менять тип - надо использовать версионированный формат. Так будет несложно менять форматы файлов, сетевые протоколы итп, сохраняя обратную совместимость.

Примеры

Metaprog: универсальная графическая среда программирования [в разработке]

Metaprog: универсальная графическая среда программирования [в разработке] часть 2

Metaprog: универсальная графическая среда программирования [в разработке] часть 3

Прокручиваемая и выделяемая строка с автопереносом

https://i.postimg.cc/Gm6KMJBs/image.png

https://pastebin.com/SWJJwvvC

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

Скрины подфункций в следующем примере.

Тот же пример, но покрасивее

Что можно сделать для большего удобства? Убрать инициализацию, подвязку коллбэка на закрытие окна и главную петлю гтк в подддиаграму «главное окно»:

https://i.postimg.cc/vm5DYjsw/image.png

На сей раз не поленюсь сделать скрины и объяснить их суть.

В подфункциях есть три вида контейнеров с данными: константа (стала, constant), контроль и индикатор (сверху вниз):

https://i.postimg.cc/gJkfRVBd/image.png

Значение константы задается прямо в диаграмме. В Си константа превращается в объявление переменной с инициализатором. Контроли и индикаторы в теле подфункции превращаются в терминалы, к которым можно подключаться в «вызывающей» функции.

Сама подфункция «главное окно»:

https://i.postimg.cc/fbsDKR61/image.png

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

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

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

Подфункция для подцепки асинхронных функций:

https://i.postimg.cc/3r0rYVCS/image.png

Добавить объект в контейнер:

https://i.postimg.cc/SNGBhf51/image.png

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

https://i.postimg.cc/xjv7vP0j/image.png

Делаем лейбл (и любой другой нужный виджет) прокручиваемым:

https://i.postimg.cc/R0PtCmkd/image.png

Как видим, сишные функции успешно уходят под капот и программировать в графике становится намного проще. Из этого получается такой код:

https://pastebin.com/16bq1Jbs

Этот код делает ровно то же самое, что и предыдущий, а различия - чисто косметические, связанные с уборкой функции под капот и некоторыми доработками транслятора диаграмм в Си.

Каст типов и тактическая победа над нуль-терминированными строками

Оказывается в текстовых буферах гтк можно задавать текст не нуль-терминированной строкой. Этим грех не воспользоваться. Изменяю подфункцию, создающую текствью:

https://i.postimg.cc/s2hrDj6b/image.png

Беззнаковое 32-битное, означающее размер массива (темно-синий провод) кастуется в знаковое 32-битное (светло-синие провода и пустая константа, задающая тип). Функция gtk_text_buffer_set_text в качестве размера строки берет беззнаковое, а не знаковое, как принято - видимо, чтобы через "-1" говорить, что строка нуль-терминированная. Но из-за этого вместо 4 гб строки туда можно подать лишь 2 гб - аж в 2 раза меншье! Что за люди?

Тем не менее, с нуль-терминированными функциями в текстовых полях покончено - и это победа!

https://pastebin.com/hQRMSZ1s

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

Ответ на: комментарий от rebforce

У Вас лурчанка. В качестве лечения принимайте классическую литературу.

anonymous ()
Ответ на: комментарий от anonymous

Люто, бешено принимаю.

Кстати, если луркостатью о ЛОРе ещё не дополнили данным поциентом, то, чувствую, пора бы.

rebforce ()
Ответ на: комментарий от rebforce

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

metaprog ()
Ответ на: комментарий от rebforce

Вот, не поленился нарисовать, как должно выглядеть человеческое визуальное описание

Проще текстом написать, да и нифига не по человечески это, вообще ничего не ясно.

VarfolomeyKote4ka ()
Ответ на: комментарий от rebforce

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

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

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

А что расширять-то? Где хоть какой-нибудь базис? Ноль \times ноль даёт ноль

Я кроме пространных упоминаний о каких-то терминалах и невнятной маниловщины ничего в упор не вижу.

anonymous ()
Ответ на: комментарий от VarfolomeyKote4ka

Metaprog же %) Как emacs, только графический.

Сначала занеси 100, а лучше 500 баксов, а потом расширяй.

anonymous ()
Ответ на: комментарий от VarfolomeyKote4ka

Какие баксы? О чем ты?.

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

anonymous ()
Ответ на: комментарий от anonymous

Автор исходники просто так не отдаст.

Потому что нету :-)

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

Вот rebforce хочет выкинуть типы, только динамическая типизация. «Упрощение» для тех, у кого с логикой полный завал. В итоге оно будет означать в итоге только усложнение. Например, если с его подходом (https://i.imgur.com/gW0M4aj.png) по ошибке подключить текстовую переменную к функции чтения файла, что будет? Не будет ли текст восприниматься в качестве пути к файлу? Его «умный» конструктор схем с динамической типизацией (и компилятор) в таком случае и слова не скажет, ведь почему бы текстовой строке не быть путем к файлу?

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

metaprog ()
Ответ на: комментарий от metaprog

В моем же редакторе схем таких неоднозначностей не может быть в принципе.

Так ведь в С тоже проблемы с типами, float между int свободно конвертируются, всюду юзается void*, NULL.

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

C++ эту проблему хорошо решает кстати! Вместо void* - шаблоны к примеру, это и производительность повышает, сделать тоже самое на С можно только с помощью внешних инструментов.

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

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

metaprog ()
Ответ на: комментарий от metaprog

В моем же редакторе схем таких неоднозначностей не может быть в принципе.

Ну ты же передавал тогда неверные callback'и, значит они есть, неоднозначности эти %) Нужны зависимые типы!

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

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

metaprog ()
Ответ на: комментарий от metaprog

На уровне Метапрога реализуем.

Да, да! Будет прекрасно.

Только запретить бы еще подключение флоатов и указателей одновременно

Ну так запрети на уровне metaprog'a, не понял проблемы.

VarfolomeyKote4ka ()
Ответ на: комментарий от rebforce

Полнота по Тьюрингу (или даже https://ru.wikipedia.org/wiki/Теорема_Бёма_—_Якопини которая мне больше нравится) - это сферическая абстракция в вакууме, если нет возможности обращаться к системным вызовам и прочим готовым библиотекам. Си в этом плане - очень хорошая стартовая платформа для Метапрога и я выбрал Си, так как руководствуюсь исключительно практическими соображениями. А к условному Brainfuckу, чтобы он стал полноценным языком с «полнотой по практике» (а не только лишь Тьюрингу), надо с нуля прикручивать кучу функций и системных вызовов, начиная от ассемблера инлайном.

metaprog ()
Ответ на: комментарий от metaprog

Ну допустим тебе нужен указатель который никогда не будет NULL, и будет меньше 100000. Ты создаешь такой тип.

// [[в скобках типа требования]] 
typedef int *non_null_ptr [[value != NULL && value < 100000]];

// ну и потом можно написать функцию:
void print_intptr_value(non_null_ptr p) {
  // никогда не произойдет segment fault, так как в функцию
  // нельзя будет передать NULL
  printf("%d\n", *p);
}

VarfolomeyKote4ka ()
Ответ на: комментарий от metaprog

Будет segement fault)) Но это простой пример. Можно сделать встроенную функцию ptr_is_valid, для хоть какой то проверки правильности указателя. Главное что автоматические проверки избавляют от копипасты, и нельзя будет пропустить эту проверку! Так же можно генерировать проверки «с умом», metaprog их сам расставит где надо, с учетом оптимизаций, так, как человек в большом проекте просто не сможет.

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

Еще вот смотри.

typedef struct {
	const char *p = null;
	int len = 0;
} str_t;	

// Строка не должна быть пустой! 
void print_non_empty(str_t [[ value.len > 0 && ptr_is_valid(value.p) ]] str) {
	printf("%.*s\n", str.len, str.p);
}

str_t str;
print(str); // Ошибка при компиляции, а не во время программы
// Таким образом куча багов отсеивается еще на стадии компиляции!!!

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

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

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

metaprog ()
Ответ на: комментарий от VarfolomeyKote4ka

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

metaprog ()
Ответ на: комментарий от metaprog

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

Это даже более графический подход! Вообще идеально. Тут как бы не в типах дело, а в самой идее.

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

Да! Вот так и надо!

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

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

metaprog ()
Ответ на: комментарий от anonymous

Лурчанка почти у всех на ЛОРе. Это уже не лечится ничем кроме запрета лурки лет так на 50. Да и зачем? Языки эволюционируют, меняются, что в этом ужасного?

metaprog ()
Ответ на: комментарий от metaprog

Как будет рисоваться сама кнопочка? Как будет задаваться алгоритм ее рисования и все такое?

Зачем?! Я не велосипедостроитель, использую встроенные средства Red, а точнее - диалект Red/View. Но для тебя это всё равно пустые буковки, так ведь?

rebforce ()
Ответ на: комментарий от anonymous

Опять аллюзии на Дениса Попова? Не надоело? Сравнивая меня с ним, не забывайте приводить конкретные примеры, где меня уличили в плагиате. Примеров нет - значит сам ты Денис Попов.

metaprog ()
Ответ на: комментарий от rebforce

Это, конечно, хорошо, но будет ли у тебя возможна визуализация алгоритмов работы самого Red/View?

metaprog ()
Ответ на: комментарий от VarfolomeyKote4ka

Для рисования графических примитивов используется другая подсистема - Red/Draw. Но и существующие в Red/View уже кастомизируются так, что мама не горюй.

rebforce ()
Ответ на: комментарий от metaprog

Вполне возможно, как раз за счёт гомоиконности и однозначного соответствия блоков AMP базовым синтаксическим структурам Red.

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

rebforce ()
Ответ на: комментарий от rebforce

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

metaprog ()
Ответ на: комментарий от VarfolomeyKote4ka

Хм, видимо нет. Причем они сделали графику для MacOS, а для линукса ничего не сделали...

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

Вместо того чтобы просто опереться на Си с его готовыми библиотеками. Лол.

metaprog ()
Ответ на: комментарий от metaprog

А Rebol вообще в последний раз в 2011 году выпустился)) x86_64 версия только для eglibc... Ну metaprog уже идейно обогнал AMP. Tcl/Tk уж вместо Red, Rebol надо брать, оно хоть живое.

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

В альфа-ветках имеет. Но если для тебя гуй важнее базовых структур, то медицина бессильна. Иди лучше ещё раз пожалуйся модераторам на то, что ничтожных амёб назвали ничтожными амёбами. Пользы от тебя всё равно больше нет никакой и не будет.

rebforce ()
Ответ на: комментарий от metaprog

Эти библиотеки входят в состав GCC, что ли? Мегалол. Да будет тебе известно, что GCC используется в том числе и там, где никакой графики нет и в помине.

rebforce ()
Ответ на: комментарий от rebforce

Пользы от тебя всё равно больше нет никакой и не будет.

Я делаю приложения для людей. Они кстати реально что то делают, в отличие от каких то игрушечных язычков умещающихся в твит %)

Но если для тебя гуй важнее базовых структур

GUI это важно. Ты же понимаешь brainfuckprog можно сделать очень легко! Но какая польза? Что на этом можно сделать? Да ничего! На твоих недоязычках тоже ничего нельзя сделать, а С дает возможности, С дает мощь. До типов сишки redболам далеко.

VarfolomeyKote4ka ()
Ответ на: комментарий от metaprog

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

Тебя ждёт много чудных открытий… Хотел бы я посмотреть на сконвертированные таким образом исходники ядра Linux, ну или хотя бы libmodblug для начала.

Подсказка: в них НИКТО ничего не поймёт. И ты в первую очередь.

rebforce ()
Ответ на: комментарий от rebforce

Какая разница куда они входят? Половина софта вообще не по стандартам С написана, а с расширениями, никого это не волнует.

VarfolomeyKote4ka ()
Ответ на: комментарий от VarfolomeyKote4ka

Red анонсировался в 2011. Каков их прогресс за 8 лет, какие более-менее крупные и значимые проекты на нем уже готовы?:)

Метапрог был впервые анонсирован публично в 2019, месяц назад. Посмотрим, что будет через 8 лет. Возможно даже выбросим почти все текстовые языки в легаси. По крайней мере, проектов точно будет куча, я вот один (чатик через тор), может, сделаю еще на лабвьюшном прототипе, до релиза альфы самого Метапрога.

metaprog ()
Ответ на: комментарий от rebforce

Хотел бы я посмотреть на сконвертированные таким образом исходники ядра Linux

Это, кстати, одна из целей. А реболовская твоя система будет уметь визуализировать исходники ядра Линукс? И во что этот код превратится, будучи обратно переведенным в Си? Динамическая типизация точно ничего не похерит?

metaprog ()
Ограничение на отправку комментариев: