тем, что твое говно нагенерит вот такую лапшу

struct struct1 {
    int element0;
    struct {
        int element0;
        char element1;
        int element2;
    } element1[4];
    struct {
        char element0[2];
        float element1;
    } element2[4];
};

Не те данные будут, структуры с разным pack отличаются. В ядре linux такие структуры кстати активно используются!

Царь, всё таки это Вы?

=) Терзают меня смутные сомненья... =)

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

Да.

=) Я только ждал когда же наш уважаемый ТС доберётся до кернела. Было бы весело. =)

Но пока надежда есть, умоляю... Не спугните! =)))

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

Нет. =)))

Боюсь его бы забанили в очередной раз ещё до комментария. Как только он бы первый сырец увидел и подумал только откомментировать. Вот именно в этот момент. =))) На подлёте, так сказать.

Ага...

Именно. =)

У Царя есть аккаунт.

Бережёт, поди...

Не рискует лишний раз. Я его понимаю... =)

Это типа разные бинарные интерфейсы? Как неанонимные структуры от этого страхуют?

Хммм, может и вкручу таки неанонимные структуры. Когда будут с этим проблемы. Пока, как ни странно, все работает штатно.

Нужны не анонимные, а те самые, которые объявлены для либы. struct1 неанонимная, однако она не тоже самое, что widget. Хотя кому я это все говорю...

Почему тогда мои примеры все равно работают?

Потому что gtk структуры не используют packed, если бы использовали - все бы вылетало. Но такие структуры много где используются.

Захотелось высказаться. ТС, не натыкайся на грабли, на которые уже наступил. Столько больших тредов, к тебе было куча вопросов, многие из них повторяются. Чтобы вопросы анонимусов не были однотипными, заведи FAQ и закрепи это в шапке. Анонимус не прочитает все треды, он прочитает шапку и очередной раз «а чем не устраивают альтернативы?». В ШАПКЕ должны быть комментарии или ссылки вида «не устраивает LabVIEW потому, что проприетарный», «не устраивает ДРАКОН потому, что ...», «не устраивает Unreal Engine Blueprints потому, что ...». В шапке нагляднее, чем искать ответ в куче постов, оффтопа и по делу.

С анрилом это вообще детский сад. Обзывать огромный работающий продукт, где объём работы сопоставим со строительством замка - urinal только потому, что отдельная подсистема (не самая важная) сделана не так, как тебе нравится - скотство. Unreal прекрасно может делать свою работу - создание игр - ВООБЩЕ без блюпринтов. У эпиков всё вращается вокруг игр, а не визуального программирования.

Почему тогда мои примеры все равно работают?

Создание программ «хоть бы компилировалось и запускалось» - это уровень зелёного новичка или «одноразовый скрипт на выброс». С таким подходом не создают серьёзное ПО.

Вот аналогия. «С» компилятор превращает сишный код в исполняемый файл с ассемблером. (LabVIEW/Метапрог) превращает диаграммы в сишный код. Разработчики компиляторов сильно заботятся о качестве «выхлопа», программисты потом говорят «ага, здесь условный gcc сгенерировал вот такой асм код, а условный clang - такой, гораздо хуже». И это важно даже для сишников, которые вообще не прикасаются к асму. Код, который генерируется твоими диаграммами - это «еда для компилятора». Он не предназначен для чтения людьми. Тебе уже указали на твой замкнутый круг - кроме тебя никто писать метапрог не будет, так как фанбои визуального программирования - новички, которые не в состоянии писать серьёзное ПО. А умеющие писать серьёзное ПО увидят нечеловеческий код на С и просто посмеются с тебя. Либо пройдут мимо.

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

Кстати, можно посчитать сколько раз люди заявляли о том, что твои диаграммы непонятны. Страшная цифра. Я заявляю, что для подавляющего большинства людей схемы Unreal Engine Blueprints нагляднее, красивее и удобнее, чем твои схемы из LabVIEW. И не urinal-urinal, а задаться вопросом «как я могу рисовать мои схемы на GTK так же красиво, как в UE, но без описанных мною недостатков». Все современные тулкиты (гтк один из них!) позволяют настраивать красивости очень гибко. Use the google, Luke! Правда, нужно много усидчивости, чувство вкуса и подход не «мне норм», а «как это сделать привлекательным для людей».

Пока что:

1. Критика аналогов визуального программирования, да и вообще все частые вопросы в шапке, а не где-то в глубине тредов. Иначе очередной анонимус и не только замучает вопросами, на которые ты уже ответил.
2. Результат не в виде «еды для компилятора», а в виде сишного кода, который приятно читать человеку и компилятор не даёт ни единого ворнинга. Иначе к разработке (а не только обсуждению) метапрога никто не подключится.
3. Красивый рендеринг диаграм. Иначе типичный человек, увидев интерфейс метапрога, скажет «фи, ничего не понятно».
4. Для реализации ПО нужно понимание, что конкретно оно должно делать. Для понимания этих процессов нужно RTFM, без вариантов. Даже джин из лампы из параллельной вселенной не даст тебе нужного ПО, если не знаешь матчасти и не можешь сформулировать требования.

   Даже пример. Типичный аутсорс. Заказчик не читал маны и не очень корректно ставит задачи. Менеджер за счёт знаний и опыта превращает хотелки заказчика в реализуемую форму. Без манов человек даже не может описать, что он хочет от ПО на формальном непротиворечивом языке.

Лично я бы смог написать не сильно сложную среду для визуального программирования. Только лично я не вижу смысла. Плюс я очень ленив. А если бы и делал, то только для «скриптования мышкой». Потому, что сделать скриптование проще и нагляднее - полезно и есть смысл. Но ни в коем случае не замахиваться на создание сложной логики на диаграммах. В сложном ПО важнее предметная область, а не на чём это делать.

Вот если бы меня смотивировали написать программу, где простые диаграммы генерирую простые скрипты а-ля «web crawler на питоне» или «одноразовая задача на баше» + возможно «вот лапша на баше, опиши мне человеческим языком - что делает этот скрипт», я бы сделал. Гораздо быстрее, чем метапрог на метапроге. Создание гуя для cli утилит за 5 минут было бы полезно. А если это никому не нужно - зачем???

Код, который генерируется твоими диаграммами - это «еда для компилятора». Он не предназначен для чтения людьми.
Тебе уже указали на твой замкнутый круг - кроме тебя никто писать метапрог не будет, так как фанбои визуального программирования - новички, которые не в состоянии писать серьёзное ПО.
А умеющие писать серьёзное ПО увидят нечеловеческий код на С и просто посмеются с тебя. Либо пройдут мимо.

и это печально, потому что если бы он генерировал не «нечеловеческий код на С», а например, «нечеловеческий код на лиспе», например этом http://lush.sf.net (который компилируется в тот же С, и через FFI позволяет прозрачно подключать любые С библиотеки, позволяет смешивать лисповый и си код) — то все эти проблемы с компиляцией и каноничной правильностью кода можно было бы решить в зародыше, компилируя автомагически за счёт лисповой магии.

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

Вот аналогия. «С» компилятор превращает сишный код в исполняемый файл с ассемблером. (LabVIEW/Метапрог) превращает диаграммы в сишный код. Разработчики компиляторов сильно заботятся о качестве «выхлопа», ...

ну например, превращал бы он диаграммы в лисповый код. или в XML, который парсился бы потом каким-то лиспом типа txrlisp (забутсрапился,примеры — см. про JSON и XML, awk). да хоть tcl/tk генерировал бы, блин.

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

непонятно всё: сам сгенерированный человеконечитаемый код для робатофф (и дело не в сложности неочевидных моментов си (хотя в тех же лиспах lush, txr lisp их меньше — а в неудобочитаемости сгенерированного); полезные сценарии и юзкейзы, чего этот (LabVIEW/Метапрог) должен уметь; полезные приёмы для разработки, которые этот (LabVIEW/Метапрог) должен уметь из коробки, обеспечивающие удобство. типа ну вот это я написал на обычном С за два часа, а на (LabVIEW/Метапрог) намалював за пару минут (потому что там это делается быстрее и удобнее), и сразу заработало. пока что выходит наоборот — рисовать и проводками соединять медленнее и менее очевидно. нету ни наглядности, ни скорости разработки в этой среде, ни удобства, увеличивающего скорость разработки.

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

ну, даже допустим окошко с кнопкой компилируется и запускается (ценой 500 варнингов, лол). почему это проще и нагляднее чем писать текстом — тоже непонятно.

например, в том же http://lush.sf.net GUI на лиспе, который называется OGRE в примерах окошко с кнопкой тоже очень просто выглядит (или здесь). вон, даже игрушку на SDL написали. для отрисовки диаграмм там тоже есть.

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

и при этом такой текстовый DSL может прозрачно отображаться на «графический» DSL (ещё бы узнать, что это такое, в случае (LabVIEW/Метапрог) ).

metaprog, DSL это язык описания предметной области. твоя предметная область — непонятна. и её язык тоже. не важно, графический он или текстовый. вот ДРАКОН тоже графический, и они говорят там про два альтернативных синтаксиса, текстовый и графический. LabVIEW тоже, при этом прочитав мануал в общем понятно назначение блоков и УГО.

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

вообще теоретически там ещё одна интересная фишка есть, про асинхронные процессы и dataflow. только она же опять в этих примерах не используется, и непонятно чем отличается этот dataflow (LabVIEW/Метапрог) например, от того же drakon-editor, в котором dataflow и асинхронности нет — примеры это не показывают.

вообще, в каком-нибудь Plan 9 можно графику и векторные диаграммы и скриптом из консоли рисовать: plan9-tutorial/graphics.md.

текстовым, да. пошагово отрисовали график и диаграмму — круг красный, с осями координат. нарисуй круг, ога.

что мешает вот эту circuit bending «мнемосхему» в (LabVIEW/Метапрог) каким-то подобным скриптом отрисовать?

circuit bending хотя бы звучит. и сразу понятно, наглядно и очевидно — что это такое.

думаю, даже если автор metaprog запишет летсплеи ютубовы про свою поделку (LabVIEW/Метапрог), и покажет как он в этом работает — всё равно непонятки останутся.

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

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

мы же тут извелись уже все в ожидании.

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

ну пусть возьмёт какой-нибудь текстовый Plant UML, например. и нарисует юзкейзы диаграмм прецедентов, картинками. типа вот это делает юзер, когда вызывает абстрактную фичу (LabVIEW/Метапрог). вот эти сценарии эта среда моделирования должна уметь. вот эту фигню я делаю в старом LabVIEW, и она делается долго/сложно/медленно/непонятно/неудобно. а вот эта вот фигня в (LabVIEW/Метапрог) получается гораздно быстрее/проще/понятней не только автору — за счёт этого вот юзкейза и прецедента.

дык, и этого ведь непонятно. потому что не понято. потому что прототипа не наблюдаем. потому что не понятны юзкейзы. потому что вместо релиза, хоть какого-то и publish or perish автор занимается болтовнёй. и заново открывает для себя этот волнительный текстовый язык программирования си со многими неочивидными граблями, лол. о, сколько нам открытий чудных. и гений, парадоксов друг. и случай, бог изобретатель.

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

тащем-та, shut up and show me the code

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

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

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

или просто описал бы словами. текстовыми.

Хайку дня! xD

ТЫ МОЖЕШЬ ТЫКАТЬ (гусары, про картинку справа молчать!!!)

Совсем не ясно зачем это нужно, но наличие ненужного лучше его, ненужного, отсутствия.

но наличие ненужного лучше его, ненужного, отсутствия.

Хм. Например рака мозга...

не используют packed, если бы использовали - все бы вылетало

Можно коротко и по-русски что это такое?

ты инвалид и не умеешь в гугл?

Чтобы вопросы анонимусов не были однотипными, заведи FAQ и закрепи это в шапке. Анонимус не прочитает все треды, он прочитает шапку

Завести FAQ действительно надо, дошли бы руки:)

Unreal прекрасно может делать свою работу - создание игр - ВООБЩЕ без блюпринтов. У эпиков всё вращается вокруг игр, а не визуального программирования.

Конкретно графическое программирование там реализовано убого, и вообще там, насколько я понимаю, нельзя все от начала до конца сделать в графике. Но мне его приводят как какой-то пример из области настоящего графического программирования. Убогая «графичская» надстройка над текстовым программированием, как Дракон и практически все кроме Лабвью. Так что в контексте обсуждаемой темы оно не Unreal, а Urinal.

Создание программ «хоть бы компилировалось и запускалось» - это уровень зелёного новичка или «одноразовый скрипт на выброс». С таким подходом не создают серьёзное ПО.

Брехня. Линукс в 1991 таким и был, увечной пародией на юникс, и только потом уже его постепенно допилили до чего-то более-менее юзабельного. Примерно так же будет и с Метапрогом. Для начала - минимально необходимый функционал для переноса кода Метапрога «сам на себя», а потом, когда уже другие смогут подключиться к разработке, - все остальное.

Ты инвалид и не можешь зарегистрироваться или залогинитья? Боишься, что забанят за оскорбления и оффтоп?

«Нет ты» (с)

Ну, раз ты, всеж, инвалид и не способен думать сам, учиться не хочешь, то вот тебе подсказанька. https://ideone.com/dFax18 Смотри выхлоп результата.

Вот тебе, инвалид, вторая подсказанька. Как раз то, как у тебя это будет «работать»

https://ideone.com/E7Ydfn

Кстати то, что в этом примере Shit result result: 0.000000 это тоже совпадение. Там может быть любой мусор. Хотя «они жи одинаковые!!111», «варнинги нинужны!!!!111», да ведь?

Тред не читал. Чем это лучше, не знаю, MIT AppInventor 2? Там на выходе готовые андроидные софтины получаются...

struct {
struct {
struct {
struct {
unsigned long int element0;
} *  element0;
} element0;
unsigned long int element1;
struct {
} *  element2;
} element0;
struct {
} *  element1;
} *  metaprog_instance_1408056545511792641_junction_3644609089020270593 = gtk_window_new(metaprog_instance_1408056545511792641__variable_5923075890728034305);

охлол. Эта лалка GtkWidget чтоль так размотала? А нахера? А чем не устроил GtkWidget?

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

Блджад. А лалке слабо в Red всю эту визуальщину оттранслировать и уже редовским компилятором компилять, который всю низкоуровневую дичь на себя возьмёт? Велосипедостроение на марше...

Транслятор прост как двери, вот и расписывает все из типов, полученных через castxml. От замены анонимной структуры на GtkWidget хоть что-то изменится в конечном итоге (то есть. в скомпилированном бинарном файле)?

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

Кстати как твой «Транслятор» размотает вот такое?

struct data {
	struct data *next;
};

struct data * create()
{
	struct data *result = (struct data *)calloc(1, sizeof(*result));
	result->next = (struct data *)calloc(1, sizeof(*result));
	result->next->next = (struct data *)calloc(1, sizeof(*result));
	result->next->next->next = (struct data *)calloc(1, sizeof(*result));
	return result;
}

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

Брехня у кого-то другого. Линукс в 1991 мало что умел, но автор сразу хоть и очертил себе узкую задачу и не собирался выносить код за пределы i386, но к решению задачи подошёл фундаментально.

Ты тут JFF копипастил неоднократно. Неужели ты пропустил тот кусок, где Линус через юзнет запрашивал текст стандарта POSIX? Как ты думаешь, для чего он его искал — вместо туалетной бумаги, что ли?

Обрати внимание — Линус реализовал стандарт POSIX, а не сказал «глупый стандарт, я буду его игнорировать и вызовы придумаю сам». Именно благодаря этому подходу его детище развилось и вышло за пределы i386, возможно, неожиданно для автора.

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

MIT AppInventor 2

Ого! ТС, посмотри на вот эту схемку, например. Ещё красивее, чем в Лабвью и чем-то похоже на твои рисуночки. И опенсорсное, с апачелицензией. Заточено под андроид, но опенсорс же, допилить можно.

Хотя стоп... Оно же на Java, ты такое не хочешь...

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

Как один их контриьбютеров AppInventor2 я протистую против такого сравнения!

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

Люто плюсую. Примерно так же делаю и Метапрог.

Весьма похоже на Stratch (кстати, от того же MIT). Эти поделки похожи больше на текст, чем на графику. Идеологически от текстового программирования оно ушло недалеко, разве что не ручками все прописываешь, а какие-то выпадающие менюшки. Но все равно там текст. Кстати, как думаешь, почему текстовое программирование не заменилось таким вот полутекстовым-полувизуальным программированием?

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

П. С.: почему-то в МИТе не удосужились даже сделать свой AppInventor (или Scratch) «сам на себе», хотя при желании могли бы. Это ж не шарашкина контора и не один разработчик, работающий в свободное время - могли бы допилить до универсального ИДЕ на все случаи жизни, после чего отбросить джаву за ненадобностью. Но не стали. Что за люди?

Есть такие понятия - «ABI совместимость» и «совместимость на уровне исходного кода». Первое есть только в языках, компилируемых в машинный код (С, С++,Rust...).

Пример. Человек написал программу, используя условный гтк. Разработчики условного гтк решили сделать новую версию - условную гк 4.0 и изменить поля внутри условного GtkWidget. Но api оставили таким же. Значит, сломали abi, но оставили совместимость на уровне исходников.

Какие следствия? Компилируем программу, линкуя с гтк3 - работает на гтк3, но undefined behaviour и вылет на гтк4. Не трогаем исходники программы, но линкуем с гтк4 - работает с гтк4, но ub на гтк3. Всё потому, что разработчик писал

void myfunc(GtkWidget* widget)

void myfunc(struct {...}* widget)

Если же делать анонимные функции и линковать с гтк4, то програма уже не будет работать ни с гтк4, ни с гтк3.

Пока не дойдут руки до FAQ, каждый второй анониус будет писать «непонятно зачем нужен этот той метапрог!!!».

А ещё есть паттерн «d-pointer», который помогает сохранять abi, но это только на совести разработчиков библиотеки.

Прочёл самый первый пост самой первой темы и самый первый пост этой. Больше пока не осилил. Теперь тем более не понимаю, чем аффтарский концепт, помимо бездарной трансляции в Си вместо более подходящих для этого языков вроде того же Red (да хоть бы и HTML5 для начала) или даже той же жабы, не просто отличается, а **выгодно** отличается от того же AppInventor(2).

Зато по самому первому посту ещё той темы понял, что у товарища весьма искажены представления о программировании в целом. Феномен RAD в девяностых-нулевых развился исключительно потому, что пролетариат ойтишного труда задолбало вручную выставлять графические элементы. И скорость накидывания этих самых графических элементов - это, блджад, **единственное**, в чём RAD-поделки себя как-то оправдывают. Скорость же имплементации **логики** от представления оной не зависит совершенно. Текст ли, графика ли - всё зависит от того, насколько хорошо реализованы, и какие реализованы вообще, уровни абстракции. И вот в том случае, когда они реализованы на самом деле хорошо, графическое представление может **ВНЕЗАПНО** оказаться помехой для производительности разработки.

Вот в качестве примера можно привести поистине охренительную платформу для создания и обработки звука - Pd (Pure Data). Человеку, который действительно полностью освоил эту платформу, нафиг не нужны все эти DAW за сотни нефти (разве что Reaktor, да и то не факт). Уровень абстракции весьма чётко сбалансирован, как и стандартная библиотека. Реализации достаточно стабильны и разнообразны. Всё хорошо. Авторам надо памятник при жизни ставить. Но есть один момент: этот язык сугубо визуален. Нет способа описать связи объектов (без мусора в виде координат и лейблов) чисто текстовым DSL, что во многих случаях было бы гораздо компактнее, да и в ядрёной консоли/эмбеддеде юзабельнее. В итоге приходится мышевозить там, где уровень абстракции и так достаточен для того, чтобы этого не делать.

И вместо эпилога хотелось бы привести известную цитату: «сделай инструмент, которым может пользоваться каждый идиот, и со временем только идиоты и будут им пользоваться». Думай... те. ©

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

P.S. «И тебя вылечат…»