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

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

На бесплатных хостингах сайты тоже дохнут.

Владимир

Не пора ли вам «засучить рукава» /да и мне нужно вернуться к «своим баранам»/?

Владимир

Попросите у all советов, помощи, идей, ... в разработке дизайна диаграмм.
То что было ранее представлено - не годится.

Это к обсуждению конкретного примера с GTK, или ты так собрался ВСЕ тексты из метапрога в си переводить?

Я бы все так переводил чисто в один main. За исключением случаев рекурсии и уменьшения дублирования кода. gcc и так поймет, зачем усложнять транслятор?

Исходник на си должен быть обозримым, например, один файл из одной диаграммы или хотя бы группы диаграмм. Ну и от обфусцированных имён переменных желательно бы уйти. Дарю идею: это вполне можно сделать на самих диаграммах, если у каждого блока/связи будет свойство «имя». По умолчанию генерить его из id (как, видимо, делается сейчас), но автор диаграммы может его поменять. Соответственно, переменную делать из него, при необходимости транслитерируя.

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

Имя переменных генерируется из уникальных номеров элементов, чтобы избежать возможности коллизий. А то предлагал сверху утонченный эстет называть функции mp_a, mp_b итд, забывая, что с такими короткими именами коллизии с именами из включенного через include стороннего кода неизбежны. И к тому же, если кому таки понадобится читать промежуточный сишный код, то все будет понятно сразу, без ознакомления со всякими конвенциями - где там указатель на массив, разветвление провода на диаграмме, объявление переменной итд.

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

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

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

Владимир

Речь идет не только об графическом представлении, но и интерфейсе в целом.
Диаграммы бывают разного вида и разной функциональности, ... /например объекты/.
Если это сразу не продумать, то проект будет востребован.
Кодинг это не разработка - кодинг.
Разработка - создание архитектуры /а может быть и нескольких/.

Вам бы оценить Лабвью и сказать что вам в нем не нравится.

Владимир

Sorry.

... Если это сразу не продумать, то проект будет востребован.

Если это сразу не продумать, то проект будет не востребован.

Кажется, в лабвью есть бесплатный триал на 7 дней, даже если вы не пират можно попробовать не платя.

Владимир

Если кратко.
https://www.youtube.com/watch?v=qeZrcdyM5Zg Малыш и карлсон - по телевизору показывают жуликов

Это вы о нашем политическом карнавале?:)

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

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

Владимир

Нет.
Это намек на то, что «без дела не сидим» /у вас MetaProg, у меня ... свои цели и задачи/.

А рекурсия?

Значение второго поля с «destroy» и «draw» определено на уровне gtk? То есть, на какие события вызывать функцию, подаваемую в третьем поле?

Да. Типом объекта. https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget.signals

А где ты берешь нужные прототипы функций?

Тип функции определяется там же (в документации на конкретный сигнал).

Четвертое NULL для чего?

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

А рекурсия?

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

Макрос шире функции. Вот как будешь использовать

#define G_DEFINE_TYPE_WITH_CODE(TN, t_n, T_P, _C_)	    _G_DEFINE_TYPE_EXTENDED_BEGIN (TN, t_n, T_P, 0) {_C_;} _G_DEFINE_TYPE_EXTENDED_END()

?

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

Владимир

Перспективное ли направление выбрал ТС?

А на уровне Си рекурсивной функцией или как еще?

Перспективное ли направление выбрал ТС?

Да, но, по-моему, неверный выбор базового языка. Если бы это был Haskell (или что-то другое лениво-функциональное), то схемы ложились бы органично. А придумать изящную схему, например, для «for(i=0, j=1; i<N; i++,j++) ...» я затрудняюсь.

Конечно. С автогенерированным названием.

По мне, так проще считать твой Metaprog отдельным языком, а не надмножеством Си

Совершенно верно.

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

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

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

Владимир

Направление перспективное.

PS: Нужно - «Учиться, учиться и еще раз учиться», а также
«Трудиться, трудиться и еще раз трудиться».

Но - «Мир многогранен и океан большой».

Чем, в конце концов, заменить «G_OBJECT(window)»?

Я могу сделать вставку сишного кода «G_OBJECT(window)» на хуйдой конец, но все же хотелось бы полностью все на графику переложить.

Короче, пока делаю вставку.

Я уже нашел в типе GtkWidget указатели на функции. Функционал по указателям на функцию уже наполовину готов, когда будет полностью - покажу как узнать типы функций для работы с GtkWidget без курения мануалов.

В конце-концов человечество начинало с наскальных рисунков

Начинало что именно? Инструктаж молодого поколения можно было и с помощью жестов и мимики проводить.

А я уж думал куда подевались адепты джавы и питона?)))

Си выбран из чисто практических соображений. Разве на Haskell делают ядра операционных систем, драйвера, прикладные программы, прошивки ардуино и прочих микроконтроллеров?

Хотя мне больше нравится когда все структуры и функции прямо на виду и ничего не скрывается

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

Я бы все так переводил чисто в один main. ... gcc и так поймет

У меня был случай, когда старенький gcc 4.7.2 вис наглухо на исходнике в 7000 строк (код не мой, разумеется). Более новый gcc каку таки переварил, но перед этим долго и упорно хрюкал. Да, гланды через анус удалять можно, но не нужно. К тому же, принцип «одна диаграмма — один исходник» очень облегчит борьбу с внутренними ошибками Метапрога и другими нетривиальными ситуациями.

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

Коллизии можно проверять, не все имена торчат наружу.

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

Что, прямо-таки для всех процессорных архитектур? Или будешь прибиваться гвоздями к интелу? Можно, конечно, потратить на это несколько лет, за которые можно было бы развить саму среду — но вот я не понимаю эту маниакальную страсть велосипедить кучу дурной работы, давно и успешно сделанной другими. Если только не прямо в машинный код, а подцепиться к какому-нибудь LLVM...

Функции с названием g_signal_connect в библиотеке нет (и это вряд ли баг в Метапроге, в castxml тоже ее нет). Вместо нее четыре функции:

Значит g_signal_connect это макрос.

G_OBJECT(window) - это каст в тип? Функции G_OBJECT нет.

Это точно макрос, если капслоком написано - точно макрос.

А где ты берешь нужные прототипы функций?

В документации, к каждому объекту есть список функций к которым можно привязаться с помощью g_signal_connect

Четвертое NULL для чего?

Туда можно передавать аргументы которые попадут в твою функцию, это как в моем примере с замыканиями, туда можно передать например структур аргументов...

Там я видел флоатами (а не целыми) задается цвет.

Да, флоатами, я просто интами написал для сокращения.

Еще вроде можно задавать полупрозрачность (RGBA), верно?

Да.

И вообще, что такое cairo? Типа рисующий курсор?

Cairo это библиотека, cairo_t *cairo это структура для работы с этим Cairo... Она в функции draw привязана к drawing_area, так как мы ее привязали с помощью g_signal_connect(...«draw», draw...)

Бесплатный хостинг умирает после того как на него зайдут 10 человек, и отключается до завтрашнего дня.) У меня был опыт...

Если бы это был Haskell

Может лучше Forth?)

Си выбран из чисто практических соображений.

Как будет в графике реализован сишный for? Или даже примитивная конструкция «while (*d++ = *s++);»?

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

Вот твой https://i.postimg.cc/v8KvKKmQ/fwrite2.png. Что бы было, если бы fwrite не выводил бы в файл а писал бы в первый байт первого аргумента значение последнего аргумента? Угадать последовательность вызовов практически невозможно. Впрочем, про желательность fclose на той картинке я уже писал.

Разве на Haskell делают ядра операционных систем, драйвера, прикладные программы, прошивки ардуино и прочих микроконтроллеров?

Да. При желании. http://programatica.cs.pdx.edu/House/

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

Поддерживаю! Но вместо Haskell можно использовать «функциональный» Forth, так будет попроще во всем %) А может и не проще, критикуйте!

Ну можно не бесплатный, на двухдолларовой VPSине...

Посмотрите на Factor (http://factorcode.org)

Весьма интересное продолжение Форта (в функциональщину)

Вот же почти бесплатный хостинг %) https://www.ihor.ru/php

Да, я как раз о нем и думал пока писал свое сообщение, но его за основу точно брать нельзя %) Пока что.

Open Dylan 2019.1 (комментарий)

Может лучше Forth?)

Forth как раз принципиально линеен и именно поэтому крайне тяжело читается. Каждое слово берёт состояние стека и возвращает состояние стека. Иногда выполняет побочные действия. Поэтому для изображения программы как потока данных подходит крайне плохо.

Вот Erlang возможно подошёл бы ещё больше. Там как раз можно будет (было бы) каждый блок компилировать в отдельный легковесный процесс.

Кстати, еще один интересный проект из области визуального программирования — PureData http://puredata.info

Но, как и все «визуальные» языки — весьма нишевой. Хотя и Тьюринг-полный.

LabView тоже нишевой, поскольку вырос из схемотехники. Хотя сама схемотехника, для работы со сложными проектами перешла на текст (см. Verilog, VHDL)

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

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

Без побочных действий не бывает ввода-вывода и язык бесполезен.

ну а линейность это же в плюс

Для линейного языка текста достаточно. Отрисовка потока данных полезна только если этот поток данных есть. А у форта для каждого слова один вход (стек) и один выход (стек). Плюс изменение состояния читателя (IMMEDIATE, [ и прочее).

Плюс изменение состояния читателя (IMMEDIATE, [ и прочее).

Ах да, точно. Ну значит не форт.

Для линейного языка текста достаточно. Отрисовка потока данных полезна только если этот поток данных есть. А у форта для каждого слова один вход (стек) и один выход (стек). Плюс изменение состояния читателя (IMMEDIATE, [ и прочее).

concatenative languages вообще не про data flow, хотя подкупают тем, что в них нет «переменных».

Ах да, точно. Ну значит не форт.

Sheme бы какой-нибудь подошел в качестве модели. И side-effect есть, и линейность, и функциональщина. Хорошая структурируемость, и data-flow можно отследить.

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

Sсheme бы какой-нибудь подошел в качестве модели. и data-flow можно отследить.

Не очень. Нарисовать какой-нибудь call/cc или (let ... (lambda ...)) достаточно нетривиально. Лексические замыкания тоже с потоком данных плохо дружат.