LINUX.ORG.RU

Метапрог-прототип, версия 4

 , ,


0

3

В новой версии серьезно доработана система типов. Теперь сложные типы (структуры (аналог struct/union), пронумерованные списки (аналог enum), структуры условного выбора типа) можно сохранять на диск как отдельный файл и использовать ссылки на них в диаграммах и других типах.

Скачать:

https://www38.zippyshare.com/v/KUuZC9Ie/file.html

Из недоработанного: трансляция массивов в структурах в Си. В сишном представлении метапроговская структура с массивом должна превращаться в несколько переменных:

1. Саму структуру (struct/union), в которой на месте массива - указатель на его первый элемент.

2. Вторую структуру (struct) подобного вида:

struct {
char * pointer;
size_t size;
char dynamic; //динамический массив?
} metaprog_array_structure_123;

Так что диаграммы со структурами, содержащими массив, пока корректно не транслируются.

Предыдущая тема:

Metaprog: выпуск прототипа (универсальная графическая среда программирования)



Последнее исправление: metaprog (всего исправлений: 2)

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

Ну по сути, ЕМНИП, это «бинарное отображение XML». Т.е. если ТС дозреет до того, чтобы описать XML Schema своих диаграмм, он легко может замутить и XML, и WBXML. Более того, можно сделать выбор формата прямо в программе.

А если не дозреет — ему и WBXML не поможет.

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

Достаточно сделать struct2xml() и xml2struct().

Т.е. если ТС дозреет до того

А он и так это хочет сделать, правда не в wbxml, но суть одна.

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

Если «не в wbxml», то нужно описание этого самого «Не». Чтобы опять-таки был способ однозначного преобразования ЭТОГО в текст. Иначе суть будет прямо противоположная — неопознанная летающая фигня неясного наполнения.

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

Я смотрю, ты продолжаешь мне писать зачем-то. Ты в игноре, чудик. Это значит, что даже если я увижу твой пост, то скорее всего не стану его читать, поскольку мне не интересны словеса, которые ты генерируешь, за их тупостью.

А почему тогда вы пишите про те сроки что называл ОП

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

Засим снова иди в игнор.

liksys ★★★☆
()
Последнее исправление: liksys (всего исправлений: 4)
Ответ на: комментарий от Tanger

Да, в этом была доля шутки.

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

Гит/хаб — относительно сложный инструмент, учитывая отсутствие инженерной культуры ТС, шансов нафакапить с ним заметно больше.

ЗЫ спасибо Хоббиту за отслеживание проекта, если бы не он, кто бы ещё держал нас в курсе? :-)

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

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

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

Если я правильно понимаю, лабвью — это рантайм этой штуки, а не просто UI. Если так, ТС едва ли осилит его поменять. Но к нему может присоединиться кто-нибудь другой, кто осилит. А может кто-нибудь уведёт идею. А может и сам лабвью это сделает :-)

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

(Я тоже думаю, что не взлетит)

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

рантайм

Да. Поэтому все заявления о том, что он перепишет (перерисует, пардон) рантайм лабвью на своем си в кружочках, и все будет в шоколаде, являются бредом.

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

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

Я смотрю, ты продолжаешь мне писать зачем-то. Ты в игноре, чудик.

Ты понимаешь что ты - поехавший уже, все?

Потому что ты не умеешь в логику, дискуссию и последовательность суждений.

Ты стрелки то не переводи.

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

Если я правильно понимаю, лабвью — это рантайм этой штуки, а не просто UI.

UI рисуется попиксельно сейчас. А из LabView используются примитивнейшие функции которые не сложны в реализации.

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

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

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

Если я правильно понимаю, лабвью — это рантайм этой штуки, а не просто UI

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

А может кто-нибудь уведёт идею. А может и сам лабвью это сделает :-)

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

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

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

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

не знает ни одного языка и учиться не хочет

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

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

Твоя практика и твои же субъективные суждения. По крайней мере, в такой сложной задаче как сделать Метапрог или его аналог никто меня пока не опередил. Кое-какой прототип я уже выложил, и он успешно сделан на Лабвью в диаграммах, причем с онлайн-функционалом. arturianec100 свой Skyvis на С++ https://github.com/arturianec100/skyvis походу забросил, rebforce харахорился что сделает «антиметапрог» на реде - и пшик, i-rinat с его «графическими брейнфаками» не в счет - это не полноценные аналоги Лабвью/Метапрога. Но у Рината и Артурианца есть хоть что-то, у тебя - только твое диванное «экспертное» мнение. С чего бы мне тебя слушать?

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

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

Гтк я отбросил потому что слишком ООПшно, несмотря на Си, а нуклеар - очень кроссплатформенная вещь: Х11, SDL, линукс, винда - да даже на андроид идет! Сейчас тормозов больше со стороны прототипа - надо его доработать настолько, чтоб нормально работали все нужные для раскрутки/бутстрапа метапроговские плюшки, а с ними будет уже куда проще.

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

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

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

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

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

Бугага! Никакой алгоритмичности для этого нафиг не нужно. Открой для себя компоновщики (layouts, containers). Это делается объединением нескольких виджетов в один компоновщик и задания оному пары свойств. Мышкой, всё как ты любишь, без единой строки кода на C/C++.

Логика (минимальная) бывает нужна, когда в зависимости от какого-нибудь поля выбора (radio butons, check boxes) нужно включать/выключать доступность других виджетов. Это пара строк кода, которые раньше пихались в обработку событий. В QML, кстати, это сделали через property bindings, там и для этого никакой алгоритмичности тоже не нужно.

Логика, не сводящаяся ни к первому, ни ко второму, при программировании GUI ИНОГДА бывает, но настолько редко (я даже не вспомню, когда мне это последний раз было нужно), что ради этого делать всё построение GUI алгоритмичым нецелесообразно. Это всё равно, что плац подметать ломом из-за того, что в углу плаца торчат две доски. Достаточно оставить возможность программного вмешательства для экстренных случаев — и довольно.

Я тебе об этом и говорю.

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

Выдохнул.

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

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

Во имя справедливости стоит отметить, что практика хоть и многолетняя, но однобокая.

Насколько я понимаю, у хоть сколько-нибудь работающих инструментов ГП (тот же Дракон) почти всегда концепция сводится к превращению блок-схем, похожих на взятые из ГОСТ 19.701-90 или чего-то подобного, в работающие программы. Получается громоздко и ничуть не лучше текста, тут @metaprog с тобой согласен, кстати.

В LabVIEW подход иной, там вместо последовательности выполнения кода строятся потоки данных. Что, как я понимаю, и привлекло ТСа. Если бы у LabVIEW был полноценный открытый или хотя бы не столь «элитарный» по сравнению с оригиналом аналог — было бы интересно посмотреть на движуху.

С другой стороны, если его за 33 года (1986 год, первый выпуск LabVIEW) так и не написали — значит, не очень-то и был нужен. Так что скорее всего, ты прав.

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

считаю глупым, отсталым и неудобным прописывать в тексте сложную логику

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

Твоя практика

Мировая, клоун. Весь софт в мире написан в текстовых языках. Давай, скажи про миллионы мух.

субъективные суждения

Объективные, разумеется. Просто неудобные лично для тебя,

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

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

С чего бы мне тебя слушать?

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

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

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

Что бы оценить супец нужно иметь громадный опыт готовки супов? Да и недостатки я например уже расписывал.

Мировая, клоун. Весь софт в мире написан в текстовых языках.

Когда то не был. И что?

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

«Я могу мне просто лень!2121»

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

Во имя справедливости

Я же ясно написал: ОБЩЕГО НАЗНАЧЕНИЯ. Инструментов для графического программирования всегда было вагон и маленькая тележка, да они и сейчас существуют. У мертвопрога, между прочим, совершенно те же блок-схемы, и он ничем не отличается от того, что ТС ругает. Просто свое не пахнет.

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

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

Мой главный тезис во всех этих темах - человек без опыта разработки больших разнообразных проектов не может разработать ЯП. У него нет ни соответствующих знаний, ни понимания того, что нужно исправить в существующих средствах разработки. Мертвопрог же возник из идеи того, что ТС, в силу своей необразованности и невнимательности, не может пользоваться текстовыми языками. Это не та проблема, в решении которой нуждается все IT.

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

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

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

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

В Nuklear как раз nk_row_layout дефолт для размещения элементов.

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

Бугага! Никакой алгоритмичности для этого нафиг не нужно. Открой для себя компоновщики (layouts, containers). Это делается объединением нескольких виджетов в один компоновщик и задания оному пары свойств. Мышкой, всё как ты любишь, без единой строки кода на C/C++.

Посоветуй плиз что попробовать. И это все на гтк? На нуклеар что-то подобное есть?

Логика, не сводящаяся ни к первому, ни ко второму, при программировании GUI ИНОГДА бывает

Мне надо на нуклеаре, скажем, рисовать диагарммы. Это именно тот случай, разве нет?

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

его «инструмент» не позволяет нормально пользоваться произвольными сишными библиотеками, и при попытке сделать что-то из либэвента, ТС начал испытывать боль. Такую, что целый месяц тут ныл, чтобы ему решили проблему с чтением из сокета.

А что ТЫ сделал для того, чтобы решить эту проблему?

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

На нуклеар что-то подобное есть?

nk_layout_row_dynamic например. Кстати, оригинальный репозиторий автор забросил, так что нужно теперь следить за этим: https://github.com/Immediate-Mode-UI/Nuklear

Мне надо на нуклеаре, скажем, рисовать диагарммы. Это именно тот случай, разве нет?

Это можно делать везде.

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

А что по нуклеар+? Он вообще датируется 2017 годом.

Кстати, релиза 5 версии прототипа в скором времени таки не обещаю. Хорошо если до нового года управлюсь. Много косяков всплыло. Но когда будет релиз - то уже должны будут работать основные метапроговские плюшки.

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

А что по нуклеар+?

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

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

Насколько я понимаю, у хоть сколько-нибудь работающих инструментов ГП (тот же Дракон) почти всегда концепция сводится к превращению блок-схем, похожих на взятые из ГОСТ 19.701-90 или чего-то подобного, в работающие программы. Получается громоздко и ничуть не лучше текста, тут @metaprog с тобой согласен, кстати.

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

В LabVIEW подход иной, там вместо последовательности выполнения кода строятся потоки данных. Что, как я понимаю, и привлекло ТСа.

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

Если бы у LabVIEW был полноценный открытый или хотя бы не столь «элитарный» по сравнению с оригиналом аналог — было бы интересно посмотреть на движуху. С другой стороны, если его за 33 года (1986 год, первый выпуск LabVIEW) так и не написали — значит, не очень-то и был нужен.

Все дело в инерции мышления. Программы только «пишут», даже про мою работу ты говоришь что я «пишу» прототип Метапрога на Лабвью, хотя я его не «пишу», а собираю из блоков - и так в сознании не только кодеров, но и корпорастов, которые задают моду. Даже NI, авторы Лабвью, недостаточно серьезно воспринимают идею графического программирования. Зачем им это, когда они и так нехило рубят бабло на фирменном железе и софте? История знает множество примеров, когда человеческая глупость тормозила прогресс.

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

Все дело в инерции мышления

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

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

Этого мало.

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

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

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

Кстати

Тут сегодня с ребёнком проходили «урок цифры» на datalesson.ru. Там надо робота гонять. Язык похож на некий объектный вариант Лого (robot.move 5, robot.rotate left и др.), но основной предлагаемый способ набора команд чем-то напоминает твою визуальную шутку, правда, не до уровня букв - сначала мышкой щёлкаешь по слову robot, потом по слову move, и др. Впрочем, с клавиатуры вводить тоже можно.

hobbit ★★★★★
()
Ответ на: Кстати от hobbit

Для такой задачи можно было как в ZX Spectrum сделать: нажимаешь одну кнопку, вставляется целое слово. Блоки подписать хоткеями, примерно как в vimperator делается.

i-rinat ★★★★★
()
Ответ на: Кстати от hobbit

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

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

И это все на гтк?

Есть на GTK, есть на Qt, есть на wxWidgets. Да много где есть.

На нуклеар что-то подобное есть?

Про нуклеар тебе Котечка ответил, он его знает лучше меня. Но если помнить контекст, то более интересный вопрос — есть ли для нуклеара программная среда, позволяющая конструировать формы визуально, как в Gtk и Qt? Я-то говорил о том, что в тех тулкитах, от которых ты отворачиваешься из-за того, что они «слишком ООПшны», как раз задача визуального проектирования GUI решена. Без лишних проводков и паутин. И те примеры, которые ты приводил в старых темах «как нарисовать кнопку в метапроге» — они выглядят переусложнённо и ущербно по сравнению со знакомыми большинству программистов визуальными инструментами. Уже написанными визуальными инструментами, замечу.

Хочешь победить традиционное программирование — не стесняйся брать из него лучшее.

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

Да, в гтк визуальный дизайнер формочек, но за это, скорее всего, придется расплачиваться большей завязкой на текстовом (а не визуальном) программировании и ООПшными заморочками. И кроссплатформенность: нуклеар+ легко портится на линукс (Х11, SDL и не только), винду, веб и даже андроид! Гтк или что-либо еще так умеет?

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

Кстати, насчет сетевых библиотек. Мне Котечка подсказал #include <SDL2/SDL_net.h>. Выглядит симпатично, и без секса с колбеками.

Ты об этой либе знал? Это есть в той книжке, которую ты мне рекомендовал? Оно вообще есть в прочитанных тобой книжках?:)

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

SDL_net

Тебя ждёт сюрприз. Но мы его тут пока спойлить не будем. Пусть останется сюрпризом.

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

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

Ты про то, что сам дизайнер написан (уже написан, Карл!) на текстовом языке? Ну так я тебе и говорю: догма «всё должно быть на диаграммах» доведёт до цугундера. Учись комбинировать.

и ООПшными заморочками.

В GTK-то какие заморочки? Ну я помню, в языках со встроенной поддержкой ООП тебе не нравилась инкапсуляция…

нуклеар+ легко портится на линукс (Х11, SDL и не только), винду, веб и даже андроид! Гтк или что-либо еще так умеет?

Qt умеет линукс (X11, Wayland), винду, андроид и даже макось!

hobbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.