LINUX.ORG.RU

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

 , , ,


3

6

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

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

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

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

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

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

Полный отрыв от текста => околонулевая популярность. Не стройте иллюзий.

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, что ты там будешь в тексте высматривать? Изменения координат, траекторий проводков итп?

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

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

Именно так и будет. Показ изменений в два окна. Вот и весь diff.

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

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

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

Не совсем уж абсолютно фиолетеово – с текстом всё равно удобнее работать, чем с бинарниками.

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

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

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

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

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

Ну так мы и переходим потихоньку. Кто на protobuf. А кто (вместе со мной) на capnproto. Сначала XML хейтили, теперь и JSON тоже начинают

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

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

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

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

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

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

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

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

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

ты даже список не осилишь нормальный сделать, не то что сериализацию, да еще с версионностью.

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

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

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

Спасибо за подсказку. Весьма похоже на мои задумки. Но еще надо ознакомиться.

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

Если б еще реализацию на Лабвью кто подогнал)) Хотя на Метапроге тоже можно будет сделать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лабвью мне удобнее

Тогда и говори что пишешь ЯП только для себя.

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

Каждый программист должен в своей жизни написать язык программирования, текстовый редактор и операционную систему:)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

лучше и не скажешь. с графикой/анимацией/видео всё же очевидно. В смартфонах избавились (ну почти) от надписей и всё работает — вот он успех! а сколько времени в школах тратят на обучения «умению читать» — очевидно же ломают сознание юных гениев чужеродным «знанием». Графику все сразу понимают! А буквы нужно учить :( или китайцы-японцы обходятся иероглифами — не буквами! Да пора избавляться от наносного-ненужного хлама! metaprog это первый росток нового знания. его очевидный успех опрокинет всю эту книжную элитку! человечество раскрепостит свой дух и фантазию! прогресс не остановить!!!

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

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

Насколько я понял из описания capnproto, там все же небинарные заголовки. В Лабвью же даже заголовки бинарные, но они отображаются в графике. Вот старый формат моих метапроговских диаграмм:

https://postimg.cc/8JXwp6GC

Если есть корректный тип - все легко десериализируется из файлов и строк. Но в Лабвью нет встроенноо версионирования типов и структур условного выбора типа.

Версионирование я для своего формата диаграмм, кстати, ввел:

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

Я специально для скрина включил все подписи в типе блок-диаграммы. В них все должно быть очевидно. В новом формате я добавил «шлях» (путь) к файлу. Это нужно для управления зависимостями.

Структура условия (Case Structure) управляется цифрой версии формата (отдельная десериализация 64-битного беззнакового числа). В будущем, когда формат будет изменен, совместимость со старыми версиями будет сохранена и они будут обрабатываться соответствующими поддиаграммами.

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

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

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

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

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

Что за ЯП?

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

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

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

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

Да вот баловался я с crystal. Забавная игрушка. Всякие там язычки аля nim ненужны, когда есть кристал. Жалко только несколько непрактичен он. Так что я ухожу на раст.

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

Чем вообще раст лучше Си?

Кстати, думаешь ли перейти на Метапрог после релиза (и допилки, в которой сможешь поучаствовать)?))

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

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

Но именно для общения с людьми, а не машиной! Сделаешь опечатку в посте на форуме (кучу раз тут было) - ничего страшного, люди поймут (если не писать совсем уж по-наркомански). А с «тупой» программой (компилятором/IDE) пиши только то, что она поймет и ни на буковку не ошибайся, и большие буквы с маленькими спутать не смей, а то будут баги (редкое исключение - файловая система Windows).

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

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

metaprog ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)