Придется обсуждать Метапрог тут.

Так все линки надо выкладывать:

Структуры условного выбора типа

Ты же в metaprog собираешься это запихнуть?

Предлагайте альтернативные площадки.

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

Тема перевалила за 1000, читай правила.

Владимир

Просьба назвать топик «Metaprog: универсальная графическая среда
программирования [в разработке] часть 2» /стандартный подход/

Владимир

Да и первый топик прерывать не нужно.
Буду умничать во второй части.

Предлагайте альтернативные площадки.

Люто, бешено, от всего сердца предлагаю альтернативные площадки!

Заранее спасибо.

Владимир

Не везде анонимусы допустимы /это не плохая фича www.linux.org.ru/
Вроде больших притеснений по этому топику не наблюдалось.
ИМХНО можно и на этом сайте остаться /не знаю как лучше/.

Судя по всему, лучше сделать свой метапроговский мессенджер и форум, словом - соцсеть.

Да. Спасибо за линк.

А что его делать, все готовое уже есть. Надо только сервер или хостинг.

лучше сделать свой метапроговский мессенджер

Или в IRC канал открыть?

Тоже хорошо будет! ОП, выбирай, создавай!

Прошлая тема закрылась (для немалой части присутствущих) автоматически после достижения 1000 комментов. Это не прихоть модераторов.

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

А чому? Так проще и работать будет быстрее.

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

Парсить сторонними утилитами неудобно

Чому? Зато удобно работать с этим всем.

в стороннем текстовом редакторе не почитаешь и не отредактируешь

Тоже что и выше.

Еще и между версиями бинарная совместимость сломается

Заголовок с версией же надо просто.

При грамотном подходе потери производительности минимальны, зато легче поддерживать.

Возможно, но я тут не эксперт.

https://developer.gnome.org/gtk3/stable/gtk-getting-started.html

Я могу обойтись без этого:

g_signal_connect (app, «activate», G_CALLBACK (activate), NULL);

И просто открыть окно? Зачем вообще эта ерунда? Да, RTFM, но это долго и могу не с первого раза понять.

При запуске «app» будет выполнена функция переданная как G_CALLBACK, можешь попробовать убрать app и сделать все как в функции active.

Могу просто в один int main(){...} запихнуть?

Все? Нет.

Что не могу?

Написать gtk программу используя лишь main, окно в одном main создать можно.

Переписал свой старый пример.

use v5.22.2;
use Gtk3 -init;

my $window = Gtk3::Window->new('toplevel');
$window->signal_connect(destroy => sub {
	Gtk3::main_quit
});

my $draw_area = Gtk3::DrawingArea->new(); 
$draw_area->set_size_request(640, 480);
$draw_area->signal_connect(draw => sub {
	my ($widget, $cairo, $pointer) = @_;
	
	$cairo->set_source_rgb(0, 1, 0);
	$cairo->rectangle(20, 20, 200, 200);
	$cairo->fill();
	
	$cairo->set_source_rgb(0, 0, 1);
	$cairo->rectangle(150, 150, 200, 200);
	$cairo->fill();
	
	$cairo->set_source_rgb(0, 0, 0);
	$cairo->select_font_face(
		"DejaVu Sans", 
		"normal",
		"bold"
	);
	$cairo->set_font_size(20);
	$cairo->move_to(300, 30);
	$cairo->show_text("Hello World!");
	$cairo->fill();
});

$window->add($draw_area);
$window->show_all;
Gtk3::main;

#include <cairo.h>
#include <gtk/gtk.h>

static void destroy(GtkWidget *widget, gpointer data)
{
	gtk_main_quit();
}

static gboolean draw(GtkWidget *widget, cairo_t *cairo, gpointer data)
{
	cairo_set_source_rgb(cairo, 0, 1, 0);
	cairo_rectangle(cairo, 20, 20, 200, 200);
	cairo_fill(cairo);
	
	cairo_set_source_rgb(cairo, 0, 0, 1);
	cairo_rectangle(cairo, 150, 150, 200, 200);
	cairo_fill(cairo);
	
	cairo_set_source_rgb(cairo, 0, 0, 0);
	cairo_select_font_face(
		cairo, 
		"DejaVu Sans",
		CAIRO_FONT_SLANT_NORMAL,
		CAIRO_FONT_WEIGHT_BOLD
	);
	
	cairo_set_font_size(cairo, 30);
	cairo_move_to(cairo, 300, 30);
	cairo_show_text(cairo, "Hello World!");
	cairo_fill(cairo);
	
	return FALSE;
}

int main(int argc, char **argv)
{
	GtkWidget *window;
	GtkWidget *drawing_area;
	
	gtk_init(&argc, &argv);

	window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
	g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(destroy), NULL);
	
	drawing_area = gtk_drawing_area_new();
	gtk_widget_set_size_request(drawing_area, 640, 480);
	g_signal_connect(G_OBJECT(drawing_area), "draw", G_CALLBACK(draw), NULL);
	
	gtk_container_add(GTK_CONTAINER(window), drawing_area);
	gtk_widget_show_all(window);
	gtk_main();
}

Опять словил Fatal error C++ на Лабвью:)))

gtk_init обязательно?

Да, обязательно.

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

Это аналог пеги, но на сях?

Судя по всему, лучше сделать свой метапроговский мессенджер и форум, словом - соцсеть.

Сделай для начала хотя бы мини-сайтик, пусть даже на бесплатном хостинге, и перенеси туда все картинки, которые в первую тему выкладывал. А то на картинкопомойке они через полгода или сколько там сдохнут, потом тема всплывёт, люди сюда пойдут вспоминать, что обсуждалось, а ссылки уже дохлые. На ЛОРе это обычная тема, к сожалению.

На всякий случай уточню

Могу просто в один int main(){...} запихнуть?

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

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

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

Другими словами, сгенерированный сишный файл должен быть по возможности доступен для анализа человеком (которого ты в прошлом ОП обозвал эстетом, но это же просто навешивание ярлыка как способ уйти от ответа по существу). Мало ли что, придётся потенциальные уязвимости искать, ошибки кодогенерации локализовывать...

И имя темы слишком длинное. Уже сейчас достаточно было бы «Metaprog: графическая среда программирования, часть 2». С тегом «визуальное программирование» ты угадал, кроме твоей программы по нему находится как раз Дракон :) а тег «нетекстовое программирование» частично дублирует предыдущий и ничего больше не содержит, его можно вообще удалить.

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

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

Владимир

Преобразование любого C кода в диаграммы /скорее всего/ также
сложно как реверсинг бинарного представления в C.

Скорее всего вам нужно спроектировать высокоуровневую надстройку над C.

Далее все экспромтом /скорее размышление, а не совет/.

C++ предоставляет перегрузку операций, ..., в C многого нет.
Предоставьте в диаграммах возможность работы с строками а-ля С++ /а можно и лучше/.
К примеру: (CP1252) Молоток = (CP1251) Ручка + (CP866) Боек
А еще имеется STL с ее контейнерами /не советую слепо повторять/.
Вообщем мне бы была интересна высокоуровневая надстройка над C.

Не утверждаю, что прав /но где-то так/.

PS: Если ваша цель - денег заработать, то должны понять современные тренды и научиться триндеть, как того любят «высокие технологии».

g_signal_connect(G_OBJECT(window), «destroy», G_CALLBACK(destroy), NULL);

Только начинаю въезжать в этот функционал. Это что, вызов функции по событию (типа клик мышкой)? Или просто вариации на тему ООП? Объекты... не нравится мне все это. Уже усложняет жизнь. Так и возникает соблазн найти что-то понизкоуровнее (только кроме xlib вклеить opengl или другое графическое api).

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

https://i.postimg.cc/7hw73xzq/g-signal-connect.png

Они - подмножества g_signal_connect? Сокращение для «удобства» программирования в тексте? Какую из них вызывать? Эту?

https://i.postimg.cc/FH8LPbSW/g-signal-connect1.png

Понапридумывают сокращений, объектных моделей и прочих лямбда-исчислений, а потом парси их да дебажь. Хорошо хоть castxml подвернулся, на полгода, наверное, ускорил работу. И это еще Си, а плюсы, джава и прочие «высокоуровневые» абстракции - вообще отдельный котел в аду. Тут без мата выражаться трудно:)

Поехали по аргументам. G_OBJECT(window) - это каст в тип? Функции G_OBJECT нет.

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

В третье поле вбиваю функцию вызова подфункции G_CALLBACK(имя_нужной_функции)? А где ты берешь нужные прототипы функций?

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

cairo_set_source_rgb(cairo, 0, 1, 0);

Там я видел флоатами (а не целыми) задается цвет. Нигде больше такого не видел. Чудеса в решете. Еще вроде можно задавать полупрозрачность (RGBA), верно?

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

Это что, вызов функции по событию (типа клик мышкой)?

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

Объекты... не нравится мне все это. Уже усложняет жизнь.

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

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

Это функция библиотеки GObject (бывший GLib, на котором базируется GTK и ещё дофига всего).

// И на мой комментарий выше таки посмотри.

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

Это функция библиотеки GObject (бывший GLib, на котором базируется GTK и ещё дофига всего).

Это не функция, это макрос.

обсуждали ли ранее о системе контроля версий для визуального программирования ?

Да, «гений» предложил таблички с надписями и стрелочками в местах изменений.

Они - подмножества g_signal_connect? Сокращение для «удобства» программирования в тексте? Какую из них вызывать? Эту?

#define g_signal_connect(instance, detailed_signal, c_handler, data) \
    g_signal_connect_data ((instance), (detailed_signal), (c_handler), (data), NULL, (GConnectFlags) 0)

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

Поехали по аргументам. G_OBJECT(window) - это каст в тип? Функции G_OBJECT нет.

макрос есть.

#define G_OBJECT(object)            (G_TYPE_CHECK_INSTANCE_CAST ((object), G_TYPE_OBJECT, GObject))

Сразу предваряя вопросы:

#define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type)    (_G_TYPE_CIC ((instance), (g_type), c_type))

#ifndef G_DISABLE_CAST_CHECKS
#  define _G_TYPE_CIC(ip, gt, ct) \
    ((ct*) g_type_check_instance_cast ((GTypeInstance*) ip, gt))
#  define _G_TYPE_CCC(cp, gt, ct) \
    ((ct*) g_type_check_class_cast ((GTypeClass*) cp, gt))
#else /* G_DISABLE_CAST_CHECKS */
#  define _G_TYPE_CIC(ip, gt, ct)       ((ct*) ip)
#  define _G_TYPE_CCC(cp, gt, ct)       ((ct*) cp)
#endif /* G_DISABLE_CAST_CHECKS */

если текст, то удобно видеть строки добавленные, измененные, удаленные

ломается уже на xml

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

gcc -E -o ./incl.c ./incl.h

В ./incl.h все include, из которых надо выдернуть все типы и функции для списка. И макросы в incl.c не показываются, только конечные функции. А как сделать так, чтоб показывались и «функции-макросы»?

Приучись уже рассматривать объект как структуру данных с определённым именно для неё набором функций

Ладно, с этим жить еще можно, если не создает оверхеда по времени исполнения и сложности в изучении программистом. Хотя мне больше нравится когда все структуры и функции прямо на виду и ничего не скрывается (за что я люблю Си и не люблю ООП).

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

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

Владимир

Осильте AST gcc и будет вам радость.
Для поиска в гугле «gcc ast tree»

Пишешь в test.c «g_signal_connect(G_OBJECT(window), „destroy“, G_CALLBACK(destroy), NULL)» и смотришь, что получилось после gcc -E.

Макросы не являются функциями, поэтому в явном виде их никак. Разве что вытащить всё, что начинается с #define, но тогда надо как-то #ifdef обрабатывать.

Для поиска в гугле «gcc ast tree»

И там будет виден список макросов с аргументами? Неужели!?

При желании можно. Я кстати пилил даже свой обработчик препроцессора, пока не узнал про gcc -E. После чего решил таки использовать gcc -E, чтоб уж «официально» и без ошибок было.

Владимир

Не знаю. http://icps.u-strasbg.fr/~pop/gcc-ast.html AST representation in GCC

PS: «Хочу все знать»

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

Надо же, графические схемы!!! Уже намного понятнее, чем курение гигабайтов мануалов.

На основе AST representation можно будет сделать парсер сишного кода в диаграммы.