LINUX.ORG.RU

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

 , ,


3

5

Не нравится - проходите мимо. Нравится - помогайте проекту.

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

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

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

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

Чисто технические. По Си, библиотекам итп. А поучать не по делу - «не учите меня жить, лучше помогите материально».

Примеры

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

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

Собственная метапроговская функция

Метапрог не только умеет вызывать сишные функции, но на нем можно и свои делать. Функция для открытия слушателя (listener) на нужном адресе и порте и ее схема:

https://i.postimg.cc/8kXBCX40/image.png

Зеленые линии - особенные. Они задают жесткую последовательность выполнения. Сначала bind и только потом уж listen. Сначала listen - и только потом уж сокет можно передать дальнейшим функциям (например, accept).

У функции есть своя пиктограмма.

Открытие окошка

Этот пример открывает окно. Там же есть асинхронный вызов (на завершение):

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

Инициализация (отдельная функция, инлайнится еще на уровне метапрога в главную диаграмму):

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

Асинхронная функция на завершение:

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

Все это генерирует такой код (опять же - не для эстетов, а для скармливания gcc):

https://pastebin.com/T3Bu5Qy6

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

UML реально используется в проектировании ПО. Всякие графики активно используются в научных трудах. И так далее.

Это лишь наглядное ПРЕДСТАВЛЕНИЕ, что хотим или что уже получили.

При этом «для науки» график — это такое множество вида {(t, x, y, z)| x=x(t), y=y(t), z=z(t)} или нечто подобное, а вовсе не карандашная линия на бумазейке.

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

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

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

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

Это не про меня. Мне хочется делать драйвера, исправлять в них баги итп. У меня сейчас нет возможности делать это в графике. 2019 год на дворе!

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

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

ХОРОШИЙ GUI удобнее лишь тем, что разгружает память, освобождая от необходимости помнить наборы ключей к и наборы команд. Удобный GUI ещё позволяет полноценно управлять с клавиатуры. Но в CLI, если нет готовой команды, можно извратиться с цепочкой имеющихся и получить, что хочется, тогда как в GUI, если нет кнопочки, то либо капут, либо щёлкай кнопочками до посинения.

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

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

бинарный формат ломает VCS

Свою систему VCS сделать не так уж и сложно (имея в целом готовую среду программирвоания). Линус писал, что первую рабочую версию Git он сделал за две недели.

К тому же, в графических схемах, оторванных от текста, текстовые VCS неактуальны. Даже если вместо бинарного формата сделать какой-то XML или JSON, что ты там будешь в тексте высматривать? Изменения координат, траекторий проводков итп?

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

VCS, думаю, будет сделана незадолго после релиза или даже до него. Это весьма актуальное дело.

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

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

Свою систему VCS сделать не так уж и сложно

… имея хоть какие-то представления о программировании. Вы же не можете готовые алгоритмы на своём суржике переписать, какая там VCS.

Кстати, напомните-ка мне про VCS, которые умеют нормально мержить бинарники?

К тому же, в графических схемах, оторванных от текста, текстовые VCS неактуальны. Даже если вместо бинарного формата сделать какой-то XML или JSON, что ты там будешь в тексте высматривать? Изменения координат, траекторий проводков итп?

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

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

https://en.cppreference.com/w/cpp/language/auto - означает что тип будет выведен компилятором из контекста. Но в моем примере конечно же не будет работать, так как там выходит untagged union, который автоматически вывестись не может.

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

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

Если использовать автоформатирование графа по расположению на экране, то без вариантов. Но и без него тоже врядли, так как народ будет руками форматировать

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

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

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

Ну вариантов реализации много. Но в Unreal вроде как такого свойства небыло. Вообще по поводу VCS у меня тоже свои соображения были. А именно про интеграцию её в ИДЕ, чтоб операции рефакторинга и прочие массовые операции записывались как команды и могли быть применены даже после перезаписи/отмены одного из предыдущих коммитов. Для графической среды надо именно такую VCS клепать

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

Читать patch theory, щупать darcs и pijul, там как раз про независимость патчей друг от друга. Т.е. если у нас история A -> B -> C, то можно отменить B (если он не цепляет A и C) и после некоторых изменений (не цепляющих B) опять его применить, т.е. A -> B -> C -> ~B -> D -> B == A -> B -> C -> D . Конечно можно допилить интеграцию с IDE, но делать на основе патчей это будет легче, чем со снапшотами.

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

Именно, что патчами. В снапшот не запишешь «меню рефактор/ренейм на символе такомто -> новое имя символа». А восстановить такое по 2 снапшотам попросту невозможно

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

Кстати говоря при такой интеграции VCS в графическую среду становится абсолютно фиолетово, в каком формате хранятся сами схемы, так как формат хранения патчей можно разрабатывать независимо от схем, хотя реузать часть структур данных было бы тоже неплохо

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

К тому же, в графических схемах, оторванных от текста, текстовые VCS неактуальны. Даже если вместо бинарного формата сделать какой-то XML или JSON, что ты там будешь в тексте высматривать? Изменения координат, траекторий проводков итп?

чувак, не тормози, делаешь дифф описания диаграммы, изменения подсвечиваешь в своей среде (в два окна)

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

Еще есть идея по записи последовательности действий в процессе графического программирования. Чтоб потом показывать как кино или презентацию. Полезно для интерактивных обучалок.

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

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

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

Да каким боком его удобнее парсить-то? Если бы было удобно парсить бинари, то был бы не JSON с XML везде в вебе, а бинарные форматы. Удобно должно быть не только прям вот сейчас для одной тулзы – удобно должно быть с окружающим миром работать.

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

записи последовательности действий в процессе графического программирования

Вообще-то я имел ввиду прокачку такой штуки как undo. Но если есть желание, можно и в эту сторону покопать

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

To each their own, протобуф хорош для уже отлаженного софта где объём переданных данных и скорость парсинга важнее удобства дебага. В данном случае (до релиза) отладка явно важнее.

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

https://ru.wikipedia.org/wiki/Protocol_Buffers

Оно? Я вот думаю что-то подобное делать, только, скорее всего, своя система сериализации/десериализации с плюшками (версионирование форматов, структуры условного выбора типа итп).

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

Лучше https://capnproto.org бери. Оно хоть и более кустарное, но зато обладает киллерфичей в виде рандомного доступа к данным. Всмысле что в протобуфе для того, чтоб вычитать поле, находящееся в середине сообщения, придется перепарсить все байты сообщения до этого поля. Мало того, в официальном АПИ в принципе нет возможности прочитать поле выборочно, только собрать весь объект. Если для сообщений размером порядка мегабайт это и не особо больно, то мудаки, хранящие в протобафе 50-гигабайтные карты мира меня удивляют. Короче конкретно автор скорее всего и не заметит разницы, но я б не советовал поддерживать то, что must die.

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

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

Есть простое и русское/украинское описание capnproto? Может есть с чего взять пример (если даже не использовать непосредственно).

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

простое и русское/украинское описание capnproto

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

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

Особенно когда программирование будет удобным, графическим.

Вам уже разъяснили, что удобное программирование — ни разу не графическое. Ибо (а) программирование блок-схемами — это гигантские «простыни»; (б) сам процесс создания блок-схем дюже занудный и трудоёмкий, как и любое рисование на компе.

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

Понимаю я английский, но незнакомые понятия через него осваивать существенно труднее. Ладно, когда дойдет дело до сериализации/десериализации - попытаюсь вникнуть.

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

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

Каким образом одно связано со вторым? Это ортогональные вещи.

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

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

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

кстати, да. только не пристало гениям графического программирования текстовые редакторы пилить... надо графическийvideo редактор анонсировать.

Metaprog OS какой Вы видите? я полагаю нужно интерфейс GUI строить на анимации и видео. сразу решается проблема локализации — не нужно тратить усилия на кривые переводы. поместил курсор мыши на графический элемент управления — тебе показали анимацию. сразу всё понятно.

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

Да, возврат к корням!

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

Метапрог, как я понимаю — первый шаг по возвращению к истокам...

hobbit ★★★★★ ()