LINUX.ORG.RU

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

 , , ,


4

3

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

FAQ

1. Где скачать?

Релиза еще не было. Идет разработка, темы посвящены ей. Есть сделанный на LabVIEW прототип (его работа показана в примерах).

2. Почему не открыт код LabVIEW-прототипа Метапрога?

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

3. Почему не Дракон, MIT App Inventor, Unreal Blueprints?

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

4. Чем плохи LabVIEW или MyOpenLab?

LabVIEW пропиетарный, а MyOpenLab - хоть и опенсорсный, но какой-то недоделанный (пытался у себя запустить - выдало джава эксепшоны). Да-да, опенсорсный «клон» LabVIEW написанный на джаве! LabVIEW хотя бы на C++, а это все же меньшее зло. Обе эти системы даже не сделаны «сами на себе» в графике. Они даже не пытаются претендовать на универсальную замену всем текстовым языкам, хотя LabVIEW могло бы, если бы не тупость копирастов. Эти системы написаны на текстовых языках, их код (даже если б LabVIEW был опенсорсным) невозможно редактировать, ни разу не обращаясь к текстовым языкам. Метапрог изначально предполагает полный отрыв от текста и текстовых языков, за исключением Си как бэкенда. И то пользователям никогда не придется иметь дело с текстовым Си за исключением блоков сишных вставок (для особых случаев типа арифметических операций, ассемблерных вставок итп).

5. Почему как бэкенд выбран именно Си?

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

6. В Си указатели и ручное управление памятью. Это же так сложно!

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

7. А как же браузерные и игровые скрипты и прочие ситуации, где ручное управление памятью ненужно и даже опасно?

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

8. Почему в Метапроге будут предпочитаться бинарные форматы и чем это лучше?

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

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/flatten_to_string/

http://zone.ni.com/reference/en-XX/help/371361R-01/glang/unflatten_from_string/

Что-то подобное будет и в Метапроге. При открытом коде никаких сложностей с чтением бинарных файлов не будет.

9. А как будет обеспечиваться совместимость со старыми файлами, сетевыми протоколами итп, если будет изменен тип?

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

Примеры

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

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

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

Прокручиваемая и выделяемая строка с автопереносом

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

https://pastebin.com/SWJJwvvC

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

Скрины подфункций в следующем примере.

Тот же пример, но покрасивее

Что можно сделать для большего удобства? Убрать инициализацию, подвязку коллбэка на закрытие окна и главную петлю гтк в подддиаграму «главное окно»:

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

На сей раз не поленюсь сделать скрины и объяснить их суть.

В подфункциях есть три вида контейнеров с данными: константа (стала, constant), контроль и индикатор (сверху вниз):

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

Значение константы задается прямо в диаграмме. В Си константа превращается в объявление переменной с инициализатором. Контроли и индикаторы в теле подфункции превращаются в терминалы, к которым можно подключаться в «вызывающей» функции.

Сама подфункция «главное окно»:

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

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

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

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

Подфункция для подцепки асинхронных функций:

https://i.postimg.cc/3r0rYVCS/image.png

Добавить объект в контейнер:

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

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

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

Делаем лейбл (и любой другой нужный виджет) прокручиваемым:

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

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

https://pastebin.com/16bq1Jbs

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

Каст типов и тактическая победа над нуль-терминированными строками

Оказывается в текстовых буферах гтк можно задавать текст не нуль-терминированной строкой. Этим грех не воспользоваться. Изменяю подфункцию, создающую текствью:

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

Беззнаковое 32-битное, означающее размер массива (темно-синий провод) кастуется в знаковое 32-битное (светло-синие провода и пустая константа, задающая тип). Функция gtk_text_buffer_set_text в качестве размера строки берет беззнаковое, а не знаковое, как принято - видимо, чтобы через "-1" говорить, что строка нуль-терминированная. Но из-за этого вместо 4 гб строки туда можно подать лишь 2 гб - аж в 2 раза меншье! Что за люди?

Тем не менее, с нуль-терминированными функциями в текстовых полях покончено - и это победа!

https://pastebin.com/hQRMSZ1s

Также там был изменен текст. В остальном пример соответствует скринам выше.

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

Линус попросил стандарты POSIX, кажется, месяца за три до релиза 0.01. Я сейчас, по аналогии, открыл тему на ЛОРе около месяца назад (и уже многого добился с того момента), надеюсь через месяц-другой выкачу альфу. Хотя до этого, скорее всего, будет чатик через тор и, возможно, файловый сервер.

Вы посмотрите как Линус реализовывал системные вызовы вместо того чтобы тупить в талмуд со стандартами:

Похоже, Ари Лемке страдал излишним оптимизмом. Он создал каталог (ftp://ftp.funet.fi) задолго до того, как у меня появилось что туда положить. У меня был пароль, и все было готово для того, чтобы я мог просто войти в систему и закачать свою программу. Но прошло долгих четыре месяца, прежде чем мне захотелось чем-нибудь поделиться с миром или хотя бы с Ари и несколькими другими фанатами операционных систем, с которыми я переписывался.

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

Как создать операционку? Надо выяснить, что должны делать системные вызовы, и написать программы, которые будут это делать. Вообще говоря, системных вызовов около двух сотен. Некоторые из них могут соответствовать целому набору функций. Другие — совсем просты. Наиболее фундаментальные системные вызовы могут быть весьма сложными и в значительной мере зависят от имеющейся инфраструктуры. Возьмем системные вызовы Write (запись) и Read (чтение). Для записи на диск и чтения с диска нужно создать драйвер дисковода. Возьмем вызов Open (открыть). Нужно создать весь уровень файловой системы, который будет анализировать имена и определять, где что лежит на диске. На один этот системный вызов ушло несколько месяцев. Но когда он был уже готов, тот же самый программный код можно было использовать и для других функций.

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

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

В Unix оболочка  — это своего рода мать всех программ. Она всегда наготове, чтобы запустить любой другой бинарник. (Бинарник — это программа, составленная из нулей и единиц — на языке, который понимает машина. Если вы написали программу на каком-то языке программирования, нужно откомпилировать исходный код, чтобы получить бинарник.) Прежде всего оболочка позволяет вам войти в систему. Ну хорошо, в реальной Unix-системе по традиции первая программа, которую вы запускаете, это init, но для работы init необходима большая инфраструктура. Это своего рода контроллер происходящего. Но если у вас нет ничего работающего, то вам и init не нужна.

Поэтому мое ядро запускало не init, а оболочку. К тому времени я реализовал около двадцати пяти системных вызовов и, как я уже писал, это была первая настоящая программа, которую я хотел запустить. Оболочку я сам не писал. Я загрузил к себе на диск клон Bourne Shell, одной из исходных оболочек Unix. Он бесплатно распространялся по Интернету, и его название представляло собой плохой каламбур. Исходную оболочку написал чувак по имени Bourne, поэтому клон назывался Bourne-Again Shell (Bourne-Again произносится как born again -- укрепившаяся в вере. — Прим. пер). Обычно его сокращали до bash.

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

Я дошел до той стадии, когда моя программа загружала оболочку и выдавала на печать сообщение о каждом системном вызове, который содержался в оболочке, но который я еще не реализовал. Я загружался, запускал оболочку, а она выплевывала что-нибудь типа: «Системный вызов 512 не выполнен». День и ночь я вчитывался в распечатки системных вызовов, пытаясь понять, какие я написал неправильно. Но это было намного увлекательнее, чем идти по списку системных вызовов и реализовывать их один за другим. Теперь продвижение было более наглядным.

Наконец, в конце августа или начале сентября, оболочка заработала. После этого все стало намного проще.

Это был важный момент.

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

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

В моем случае вместо стандартов POSIX мне нужны библиотеки (например для графики) и прочие нюансы Си. Кстати, я взял гтк, хотя и не подумал бы этого делать, если б не подсказали и доступно рассказали чем это лучше чистого Xlib.

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

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

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

Мне вот давече попалась на глаза луркостатья «Быдлокодер», дык там в разделе «Поведение быдлокодера» есть хороший пункт:

… 8. Всегда планирует завтра написать Мегапрогу; …

Вот как увидел название - первая ассоциация. А как почитал тему - ещё больше эта ассоциация укрепилась.

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

веб-сервер с графическим интерфейсом??? вы имеете в виду утилиту настройки?

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

Инвалид, поинт мессаджа был не в том, что «Линукс 0.01 не умел даже компилировать сам себя», а в том, что а) Линус прочитал дохера и удосужился ознакомится с основами, которых ты не знаешь от слова «совсем», б) ядро 0.01 БЫЛО. Его можно было ВЗЯТЬ и ОТКОМПИЛИРОВАТЬ и даже, о чудо то, ЗАПУСТИТЬ! Можно было посмотреть его код и натыкать носом, где разраб облажался, то есть говорить по существу. У тебя пока только убогие картиночки, которые понятны только тебе и пачка нагенеренного гов-на, которое потенциально не просто не рабочее, но и опасное в плане использования, а еще наполеоновские планы про Мегапрогу и раздутое ЧСВ. В результате черех месяц ты заведешь 10 тему, где будет все то же самое, с картиночками, с кривым кодом и планами. И через 2 месяца и через 2 года.

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

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

Чесслово, лучше бы чистовый текстовый DSL для Pure Data запилил, и то пользы было бы больше (при условии такой же кроссплатформенности, как и сам движок Pd).

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

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

Ты всерьёз судишь о чёткости и немыльности графики по скриншоту в __JPG__???

hobbit ★★★★★ ()

Автор, какие операции уже реализованы в твоей мегапроге прямо сейчас? Какие алгоритмы уже можно визуально набросать? Есть ли сетевой I/O, буферизация, многопоточность?

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

И что ты этой цитатой доказал?

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

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

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

То же и с читаемостью текста. Если ты эту читаемость обеспечишь, ты обеспечишь себе канал обратной связи. Тебе сообщат, в какой функции у тебя ошибка, ты найдёшь это место. В противном случае ты никакого ответа на багрепорты, кроме «УМВР», выдавить не сможешь. Сопровождение написанного продукта (даже хорошо написанного) очень часто оказывается более трудоёмким, чем его написание...

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

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

Посмотрим как работает мой транслятор. Берется файл incl.h, в котором все нужные инклюды, например:

//gcc ./test.c -o ./test $(pkg-config --cflags --libs gtk+-3.0)

#include <stdlib.h>
#include <stdio.h>
#include <gtk/gtk.h>

Прогоняется через gcc -E, результат сразу в castxml. Все возможные типы и структуры разбиваются до самой элементарщины. Кстати, скорее всего, мне нужно поменять gtk на именно гтк 3.0 в зависимостях, чтоб никаких неоднозначностей (UB) точно не было.

Далее работает транслятор из castxml в бинарный файл с метапроговскими типами и функциями. Все сводится к примитивным типам, которых в Си не так уж и много, а со структурами, юнионами, массивами и указателями Метапрог обращается как с составными типами из примитивных типов. Из них уже стоставляются даграммы, функции итп. И они как раз и превращаются в многоэтажные структуры вместо коротких названий.

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

Тут, кстати, весьма актуальным становится вопрос о контроле изменений в зависимостях. Я вот недавно (вместе с версионированием форматов) внедрил управление зависимостями. Данные обо всех объектах диаграммы (подфункции, сишные вставки, контейнеры с данными) хранятся в файле диаграммы. Но при загрузке этого файла идет проверка на зависимости. Если файла зависимости нет - вылетает предупреждение. Если он был как-то изменен, Метапрог спрашивает, заменить ли зависимость новой версией. Примерно так же будет и с типами, в том числе взятыми из сишных инклюдов: если что-то изменилось - изменение будет подсвечиваться и спрашивать заменять ли на новую версию типа.

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

Все возможные типы и структуры разбиваются до самой элементарщины.

И вот тут ты получаешь тот самый факап, в который тебе уже носом натыкали.

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

Какие алгоритмы уже можно визуально набросать?

Какие показаны, такие и можно набросать.

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

А какие показаны? И какие операции реализованы? Словами можно объяснить? Потому как твой postimage.cc грузится целую вечность и содержит туеву хучу баннеров. Нормальные люди пользуются Imgur (как минимум).

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

Если ты эту читаемость обеспечишь, ты обеспечишь себе канал обратной связи. Тебе сообщат, в какой функции у тебя ошибка, ты найдёшь это место

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

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

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

Учись писать секцию «Примеры», дундель. Ты хоть сам смотрел, на какие посты ведут ссылки в этой секции?

Стыдно за соотечественников. Вот такие и выбирают всяких Педь и Зюзь...

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

Я, если что, ни за того ни за другого не голосовал. Ладно, хватит, а то за политоту хлопнут.

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

Всё ещё жду список реализованных на данный момент операций.

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

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

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

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

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

То, что за промежуточный этап трансляции был выбран Си, уже красноречиво говорит само за себя. Чел просто не в состоянии объективно оценить объём работ. Да и ставит он совершенно оторванные от реальности цели.

P.S. Был один такой товарищ - Базист, он же RStudio - тоже соотечественник (говорю же, херню творят они, а стыдно почему-то мне) с кучей мегапрожектов, но в памяти народной отложился именно ультракороткий язык программирования RS. Вот советую и топикстартеру тоже ту тему осилить, чтобы понять, как не надо подходить к задачам, дабы не повторить ту же ошибу.

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

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

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

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

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

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

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

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

Я из тех, кто вёл с ним тесный дискурс © в темах FVMas и Стебелька, так что этого персонажа (наряду с Дедалом) мне сложно будет забыть и через 20 лет. А этот кедр - что-то среднее между Дедалом, Базистом и Санёцком (автором Aulix Backup2DVD, если кто-то это УГ ещё помнит здесь…)

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

прямо по делу и по существу

Тебе уже конкретно на последних 2 страницах сказали аж 3 критические неприятности которые у тебя есть

  • Выравнивание структур в памяти, которые ломаются твоим «простым как дверь транслятором»
  • выворачивание рекурсивных структур типа struct data {struct data *next; }
  • Количество варнингов, которое производит твоя нагенеренная лапша

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

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

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

Ибо по делу и существу всё уже давно посоветовано:

  1. Создать, устаканить и обнародовать чёткую спецификацию визуальных компонентов и уровней абстракции. В идеале это надо было сделать прежде, чем вообще начинать что-то писать.
  2. Создать понятную документацию по уже существующим компонентам. Это нужно не столько потенциальным пользователям, сколько тебе самому. Ибо через 3 месяца уже сам запутаешься в этом всём.
  3. Транслировать в Java/Red/WxPython вместо Си. На худой конец - в HTML+ JS (ES6) или Gjs. Не привызяваться к конкретным библиотекам.
  4. Сделать транслирующий бэкэнд настолько стабильным, насколько это вообще возможно. Потом уже приступать к визуальной части (фронтенду).
  5. Меньше клянчить и обещать, но больше делать. Как говорил твой любимый Торвальдс, «talk is cheap, show me some code».
anonymous ()
Ответ на: комментарий от anonymous

С конкретными тезисами я еще могу работать.

Выравнивание структур в памяти, которые ломаются твоим «простым как дверь транслятором»

Что такое «выравнивание структур в памяти» и почему оно ломается моим транслятором?

выворачивание рекурсивных структур типа struct data {struct data *next; }

С рекурсивными структурами еще есть время подумать что делать. Пока с ними не сталкивался.

Количество варнингов

Об этом я уже ответил. Варнинги - всего лишь рекомендации. О сути этих варнингов есть что сказать?

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

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

Все создается в процессе и диктуется практикой, а не сферической теорией в вакууме.

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

Документацию? Лучше сделаю интерактивную обучалку. Я в Лабвью клепаю прототип Метапрога (и другие проекты) и вообще в них не путаюсь. Лабвьюшные диаграммы - сами по себе документация. Понятная схема вместо тысячи слов.

Транслировать в Java/Red/WxPython вместо Си. На худой конец - в HTML+ JS (ES6) или Gjs. Не привызяваться к конкретным библиотекам.

Зачем мне, черт побери, джаву или питон осваивать вместо Си? В чем их преимущества? Что такое Red я вообще не знаю, и не буду даже пытаться узнать если ты мне не объяснишь доступно по-русски (или українською мовою) что это такое и с чем его едят.

Сделать транслирующий бэкэнд настолько стабильным, насколько это вообще возможно. Потом уже приступать к визуальной части (фронтенду).

Нет, тут все наоборот. Сначала я сделал именно конструктор графических диаграмм, чтобы было что транслировать. Имея графические диаграммы сделать транслятор в Си - дело техники.

Меньше клянчить и обещать, но больше делать. Как говорил твой любимый Торвальдс, «talk is cheap, show me some code».

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

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

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

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

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

Про текстовый сишный уровень можно будет забыть как только будет на 100% надежная трансляция в сишный код

Эта самая надёжность должна быть проверяемой. Не «один раз проверил и забыл», так не получится, а проверяемой в течение всего жизненного цикла твоего продукта для стороннего человека.

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

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

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

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

Варнинги - всего лишь рекомендации.

Формально да. А по факту игнорирование таких «рекомендаций» ведёт к печальным последствиям.

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

Вот думаю, не начать ли пилить AntiMetaprog (то есть то же самое, но с нормальным подходом к делу и на вменяемых технологиях)… Чисто чтобы посмотреть, каков будет прогресс в сравнении с аффтаром.

Одобряю. Больше метапрогов богу метапрогов! Не посмотреть ли тебе на уже неоднократно склонявшуюся здесь MyOpenLab — вдруг это хорошая основа для старта...

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

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

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

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

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

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

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

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

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

Все создается в процессе и диктуется практикой, а не сферической теорией в вакууме.

Что самое смешное - Базист в той теме высказывался ровно так же.

Документацию? Лучше сделаю интерактивную обучалку.

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

Зачем мне, черт побери, джаву или питон осваивать вместо Си? В чем их преимущества?

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

Что такое Red я вообще не знаю, и не буду даже пытаться узнать если ты мне не объяснишь доступно по-русски (или українською мовою) что это такое и с чем его едят.

Якщо IT-спеціаліст не знає англійської, йому в галузі робити нічого.

Имея графические диаграммы сделать транслятор в Си - дело техники.

Так думают все дилетанты.

Код, я кстати, показываю, точнее скрины и результаты работы транслятора.

Это не код.

Ты бы что показал реально полезного для проекта

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

или хоть донат сделал

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

А если нет желания делать ни того ни другого - иди лесом.

Ну пойти-то могу, но то, с чем я вернусь, тебе не понравится.

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

без формального описания языка все твои потуги - пшик.

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

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

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

Якщо IT-спеціаліст не знає англійської, йому в галузі робити нічого.

Это, пожалуй, главный миус современного айти. А насчет Red ты меня не убедил. Читать я твой линк не буду - лень. Осваивать Red с нуля без ОЧЕНЬ уважительной на то причины - тем более. Ты мне по-русски давай рассказывай, чем твой Red лучше Си для моего проекта, если хочешь меня убедить.

Это не код.

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

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

MyOpenLab - не совсем то, что соответствует задумке. Это скорее закос под тот же лабвью. Если я правильно распарсил бред ТС, то он ставит во главу угла визуальное описание не готовых компонентов, а алгоритмов и структур данных. Имхую, что эти вещи можно сделать гораздо проще, но гибче, чем в лабвью и опенлабах. Но я, в отличие от ТС, словами разбрасываться не привык, так что что-либо конкретное скажу уже тогда, когда устаканится сам концепт.

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

Ждем-с. Неужто я кого-то еще вдохновил на визуализацию программирования?

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

А Си я, кстати, знаю.

Я аж чаем от смеха поперхнулся

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

Чисто с целью утереть нос всяким прожектёрам - почему бы и нет? Ударим редом и визуальщиной по базистике и дедаловщине!

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

Я уже свои примерные сроки называл. А у тебя что, товарищ анонимус?

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

Вот как только у тебя что-то запуститься, сгенерит код и соберет без предупреждений и без уб, тогда будет.

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

Чего там не знать? Сам язык прост как двери, другое дело всякие там библиотеки и функции.

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

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

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

Когда будет релиз? Или хоть концепт?

Концепт будет не позже 3 мая.

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

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

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

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

P.S. Залогинился, дабы остальные анонимусы не имперсонировали.

rebforce ()
Ограничение на отправку комментариев: