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

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



Последнее исправление: CYB3R (всего исправлений: 7)
Ответ на: комментарий от vq156

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

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

Что там в реализациях на ардуино - не знаю, но в JavaCard STK он просто не требуется, ибо выделение памяти полностью статично.

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

Это су… нет, не существо, а вещество вообще даже не представляет различий между десктопом и эмбеддедом.

Сборщик мусора, бугога.

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

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

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

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

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

Вопрос из разряда: Нахрена Си если есть ассемблер.
Ответ один: Человеческая жизнь короче чем кажется.

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

Ты своих-то не показал еще, а от меня требуешь...

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

Встречный вопрос: Нахрена Си, когда есть джава, Go, Rust, Erlang и JS, каждый из которых уже сейчас прекрасно справляется в своей области?

И следующий вопрос: Нахрена будет это всё лет через 5, когда полностью допилят Red, который в своём допиленном состоянии будет прекрасно справляться в любой области и служить основой для более узконишевых DSL?

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

Встречный вопрос: Нахрена Си, когда есть джава, Go, Rust, Erlang и JS, каждый из которых уже сейчас прекрасно справляется в своей области?

У Rust нет никакой области лол. Си тоже прекрасно справляется, и появилась сишка раньше, так что плохо у тебя вышло отразить вопрос.

когда полностью допилят Red

Ахахахахахаах!!!

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

Я не про то совсем. Java которая для SIM карт это вообще извращение какое то, там ничего нет, это просто какой то полу-ассемблер похожий на Java.

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

JavaScript это тоже своеобразная Java

Малчег, ты совсем ку-ку?

У Rust нет никакой области лол.

Челябинской, может, и нет. Конечно, откуда шлакварному кукаретику знать о реальных бизнес-задачах…

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

Малчег, ты совсем ку-ку?

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

Конечно, откуда шлакварному кукаретику знать о реальных бизнес-задачах…

Забавно что борщ тоже red %)

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

Вообще философия Java :написано 1 раз - работает везде. Оно вообще для стиральных машинок предназначалось сперва. Теперь оно везде. Вообще везде.

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

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

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

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

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

Дурака учить - только портить.

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

везде, где есть JVM

Везде, где ты ее впихнешь и она будет выжирать памяти и процессорного времени в лучшем случае в разы (а может и в десяки-сотни раз) больше, чем тот же алгоритм на Си. https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/gcc-java.html

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

если ни на чем кроме Лабвью ничего делать не хочу

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

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

А ещё ты будешь агитировать других людей на свой подход. И одно дело сказать «я знаю Java, на ней написана первая рабочая версия IDE Metaprog, Метапрог лучше». И совсем другое — «я написал Метапрог, ни с какими внешними инструментами он не совместим, я знаю только Си». Во втором случае гораздо больше шансов, что тебя просто пошлют и тыкать ничего не будут.

Нежелание учиться — это всегда худший выбор.

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

На сим картах у явы нету даже char, float типов. У явы кстати вообще нету unsigned, убогенький язычек.

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

Тем не менее на нем написана целая микроОС. Которая крутиться на симке.

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

Ну и что? Зато работать будет куда лучше. Кстати, Метапрог эту задачу облегчит. Под каждую архитектуру свои низкоуровневые плюшки, высокоуровневые алгоритмы можно будет не менять.

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

Графическое программирование не спасёт тебя от тестирования, от грамотной организации совместной работы и ещё много чего

Оно означает абсолютно новый подход ко всему вышеперечисленному.

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

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

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

и появилась сишка раньше

Как появилась, так и исчезнет. «Эволюция, Морфеус, эволюция…»

Просто легаси дофигища поддерживать приходится на Си, это да. Но ни один новый проект системного ПО никто в здравом уме на Си не начинает. Не подскажешь, почему?

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

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

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

И все будет заменено на твой ред. Только он существует с 2011 года и никаких реальных примеров его применения я до сих пор не видел.

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

Подводные камни есть?

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

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

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

и что? гцц гцц рознь. Перенос с архитектуры на другую может потребовать серьезных переработок кода.

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

Как появилась, так и исчезнет.

Конечно, когда появится что то лучше.

Просто легаси дофигища поддерживать приходится на Си, это да.

Да, на других языках легаси тоже есть.

Но ни один новый проект системного ПО никто в здравом уме на Си не начинает.

Ядро продолжают писать на С, могли бы давно интерфейс сделать для какого нибудь язычка, как NetBSD сделали для lua. Ну я системные вещи это слишком ограниченно, возьмем к примеру systemd, старенький слишком? Ну тогда pipewire. Кодеки на чем пишут? Там вообще ассемблер есть.

Не подскажешь, почему?

Потому что это происходит в твоих фантазиях?

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

Когда же редактирование появится у меня!

Ну я системные вещи

Ну системные вещи*

Назови чего нового серьезного появилось на других язычках лучше.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.