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

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

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

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

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

ossa ()

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

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

а твои нечёткие украинские подписи не текстовые?

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

+1. я даже после того как он рассказал ничего не понял. и это какой то простенький helloworld. я даже не понял что такое «нормальный массив». это что то типа struct { size_t length; char *start; };. афтар выложи лучше Cшный код будет понятнее ей богу даже если он криво сгенерирован твоей утилитушкой.

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

не люблю ссылки на видево но на этот раз решился посмотреть и не пожалел. очень точно описывает впечатление от «кода» афтара.

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

Так-то миникс сейчас очень популярная ОС, с вероятностью 40-50% она прямо сейчас запущена у вас на ПК. И вообще, хватит приводить Таненбаума в пример, он был прав по большинству вопросов. Если бы вы почитывали иногда lkml, проблемы монолита частенько всплывают там.

balsoft ()
Последнее исправление: balsoft (всего исправлений: 1)
Ответ на: комментарий от cluge

А сейчас есть помощь в подсказках по гтк и нюансам Си. Не от тебя, конечно.

Готовенькое всем, видите ли, подавай.

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

Данные из строки копируются в массив и сохраняется длинна? В текстовом представлении это выглядит так:

char arr[128], *s = "Hello World!", *p = arr;
int n = 0;
while((*s+1) && (*p++ = *s++)) n++;
Я набрал этот код за ~30 секунд, а что со схемами?

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

Так-то миникс сейчас очень популярная ОС, с вероятностью 40-50% она прямо сейчас запущена у вас на ПК

Ты про Intel ME? А где еще миникс есть? На ARM?

Если бы вы почитывали иногда mailing lists, проблемы монолита частенько всплывают там.

А в 1991 (когда Линус сделал Линукс) была куча проблем с микорядром Миникса. И винда тоже, кстати, мироядерная, насколько я знаю - разве она лишена проблем?

Есть и другой подтекст сравнения ООП с микроядерной архитектурой ОС: ООП, наверное, лучше всего будет ложиться именно на микроядерную архитектуру. Но практика с Линуксом показывает, что моноядро лучше.

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

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

Кстати, arr у тебя длиной 128. А если строка больше?

metaprog ()

Кстати, там про завтипы и алгтипы было: они просто позволяют писать код, в котором гарантированно не будет ошибок. Если какой-нибудь условный readFile :: String -> IO String обернуть в optional :: Applicative f => f a -> f (Maybe a) и если так сделать для всей стандартной библиотеки (для хаскеля реализовано во всяких safe-prelude или intro), то можно гарантировать отсутствие неявных ошибок в коде.

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

И винда тоже, кстати, мироядерная, насколько я знаю - разве она лишена проблем?

Кек. Чукча не читатель, чукча писатель :) Винда – лютый монолит, но при этом NT вполне себе в ООП-стиле работает – везде передаются объекты, а не текст. Да и Linux на самом деле тоже написан с использованием многих практик ООП, иначе бы на первый год разработки всё схлопнулось бы.

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

Опять же, ограничение на 128. Лучше не избавляться от *s, вместо этого лучше всего лишь просмотреть какое из его значений «0» и сделать вывод о длине строки.

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

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

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

По гтк есть отличная документация доступная онлайн, если что-то не понятно, то исходники открыты.

Ты не стесняйся, создвай темы с непонятными тебе вопросам в Си и гтк, тебе всегда ответят и без стеба.

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

Там данные вообще не копируются.

Тогда получается это аналог?

char *s = "Hello World!", *p = s;
size_t n = 0;
while(*s++) n++;


// length(Hello World!) == 12
printf("length(%s) == %zu", p, n);

А если строка больше?

segfault.

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

Си по критерию качества программ бесспорно выигрывет

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

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

Как ни странно, монолитные линукс и винда захватили мир, а микроядерный миникс только в Intel ME тихонько сидит, Hurd вообще на обочине...

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

В 2000х у них спутник был на Commmon Lisp запрограммирован. Используется много чего! А не только Ada.

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

был на Commmon Lisp запрограммирован. Используется много чего! А не только Ada.

Используется много чего! А не только C, да.

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

А твоя ссылка не доказывает что все ракеты на C.

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

Поехавший чтоли? Где я доказывал что ВСЕ ракеты на Ада?

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

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

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

Так текстовое программирование тоже захватило мир, и самые популярные представители ГП типа Лабвью не имеют и доли от (небольшого) успеха микроядра. Заставляет задуматься.

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

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

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

Текстовое программирование, может быть, по-своему прекрасно, но меня оно не устраивает.

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

Ого! Прогресс.

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

Например то, что я уже задолбался предлагать — пусть диаграммы будут диаграммами, но внутренний формат их представления оставить текстовым. Это сразу снимет с тебя бремя писать свою VCS и ещё дохрена всего. Да и вообще — если какой-то левый чувак может просто посмотреть потроха твоей диаграммы в виде plain text, это сразу снимет кучу вопросов, понизит порог доверия и создаст предпосылки, чтобы этот чувак стал твоим союзником, а не наоборот.

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)

А у меня вопрос по п.2 FAQ

Я никак не могу понять причин не открывать исходники. Хотелось бы услышать, таки, разумное объяснение. Потому что:

Он весьма глючный,

И что?

прожорливый по памяти,

И что?

зависит от пропиетарного LabVIEW

И что?

вряд ли кто-либо из здешней публики будет контрибутить

Это не более, чем предположение. Но если исходники не открыть, то «контрибутить» точно никто не будет.

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

Уверенно поддерживаю!

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

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

И визуальные средства просмотра этих бинарных файлов не помогут - если ошибка в программе просмотра файлов, то будет сегфолт, а не «диаграмма файла».

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

arturianec100 ()
Ответ на: А у меня вопрос по п.2 FAQ от Quickern

Лабвьюшный прототип все равно будет отброшен после раскрутки Метапрога (то есть, когда Метапрог будет сделан «сам на себе»). И после раскрутки код будет открытым.

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

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

если ошибка в программе просмотра файлов, то будет сегфолт

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

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/

Что-то подобное будет и в Метапроге.

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

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

В ООП, судя по всему, такой же оверхед по передаче данных между объектами. Микроядра - это ООП от операционных систем.

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

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

Визуальное программирование никак не спасает от невнимательности.

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

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

А вот питон, php, js с магией, perl5 и прочая скриптота даёт оверхед из-за key-value структур данных.

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

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

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

И, кстати, больше никакого ручного проставления всяких скобок, ";" и прочих текстовых разделителей.

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

ручного проставления всяких скобок

Они нужны для компактности кода, Metaprog: универсальная графическая среда программирования [в разработке] часть 4 (комментарий) насколько компактнее текстовый вариант тех схем! Надо что то с этим придумывать...

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

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

metaprog ()
Ответ на: А у меня вопрос по п.2 FAQ от Quickern

Я никак не могу понять причин не открывать исходники

Причина одна - их нет. Автор троллирует и пытается развести на донат, попутно заманивая неосведомленных для написания этой поделки. Сам он естественнно руки марать не хочет. Да и знаний у него явно не хватает для таких вещей.

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