LINUX.ORG.RU

Метапрог-прототип 43: начало переделки «на самом себе»

 , , , ,


2

4

Скачать:

https://mega.nz/file/fUhEjbCI#1LbpnccSm_SkwJi5Bugwc679tFxj7YJzCTOQxmxHvq0

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

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

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

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

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

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

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

Метапрог-прототип 42



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

Учитывая, что Labview у меня нет и не будет - чем их читать-то?

LabVIEW, скачанным с торрентов.

Текст в крайнем случае можно человеку показать, он поправит

Ага, щас - текстовые конфиги, в которых черт ногу сломит.

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

пытался вводить js графическим способом

Это ерунда без пристойной типизации. Попробуй Метапрог или LabVIEW.

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

Но Лабвью от этого у меня не появится.

Учись пользоваться торрентами.

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

использовать на слабых микроконтоллерах.

А лабвью можно?

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

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

Это ерунда

Это немного лучше чем вводить шаблоны руками и следить за их целостностью (все ли скобочки закрыты).

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

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

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

Раньше они просто в жопу посылали …
Не матом

КУЛЬТУРНЫЕ РЕБЯТА!
anonymous
()
Ответ на: комментарий от MOPKOBKA

А ее невозможно приготовить, на то это и скриптуха.

Метаклоунам вечно что-то мешает, на то они и клоуны.

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

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

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

А лабвью можно?

Без понятия.

Питон или js точно так же сгенерит сишку как и лабвью.

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

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

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

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

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

И что? Компилятор си генерирует такое же г. в ассемблере на десятки килобайт, когда хватит одного.

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

Представляю как первобытные люди ухахатывались, когда появился цикл for, когда есть while.

А они разве не одновременно появились?

Лучше было привести в пример goto, с которым ни for, ни while «не нужны».

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

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

Жееесть. Иногда лучше промолчать. Вот скажи, что эффективнее, взять COBOL и вызвать подпрограмму SDELAT_KRUTO, или условный питон без библиотек и написать 500к строк на нем которые делают то же что и подпрограмма SLELAT_KRUTO? А какой язык лучше?

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

Как решает задачу лабвью - мы уже видим

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

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

А что сейчас, кто-нибудь найдется и скажет не нужно?

Сейчас от for избавляются в современных языках. foreach это другое.

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

Жееесть. Иногда лучше промолчать.

Вот и молчи, умнее будешь казаться.

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

Что такое нормальный язык

тот, который используют полтора «разработчика», очевидно же

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

Ты погоди. Ты не шаришь. Это революция в программировании. На этом можно сделать целый будильник!!!111 И это всего за 3 года разработки.

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

LabVIEW, скачанным с торрентов.

facepalm. Что тебе непонятно во фразе «нет и не будет»? Даже не столько из религиозно-идеологических соображений (а они у линуксоидов сильны, вам не понять), а по причине банальной гигиены.

Ага, щас - текстовые конфиги, в которых черт ногу сломит.

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

использовать на слабых микроконтоллерах.

А лабвью можно?

Кажется, Метапрог надеется, что его скриптуха будет работать быстрее. Правда, учитывая подход к архитектуре, будет чудом если она обгонит хотя бы bash.

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

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

Ты погоди. Ты не шаришь. Это революция в программировании. На этом можно сделать целый будильник!!!111 И это всего за 3 года разработки

…правда, он протекать будет.

Зато можно сделать решатель квадратных уравнений подбором!

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

Зато можно сделать решатель квадратных уравнений подбором!

Который не всегда дает правильные ответы

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

Зато можно сделать решатель квадратных уравнений подбором!

Крутой матан …

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

…правда, он протекать будет.

Увы, революция не может без жертв … оперативой. Зато еще пара десятков лет и … ядро линукса! И всё ГНОМ/КДЕ! и даже небо и даже аллах будет переписан на метанпроге!

anonymous
()

не взлетают для общего программирования такие вот графические язычки. причины:

  1. нужен специфический редактор, а не обычный редактор текста.

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

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

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

  5. диаграммы полагают редактирование и мышью и работу с клавиатурой. текстовой форме достаточно только клавиатуры.

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

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

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

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

Шутка

Почти обычное ТЗ, написанное тетей Лизой ...

Он это поймет и покаится …

И мы его ПРОСТИМ!
anonymous
()

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

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

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

Где-то так.
Но к примеру тот же Дракон вполне можно доработать таким образом, чтобы он был своего рода Диаграммой в которая содержит некий алгоритм, на основании которого генерируется и добавляется код в обычный текстовый код.
Что-то типа GUI Net …

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

Все это будет в 1941-й ПЕРЕДЕЛКЕ и тогда проект уже будет называться МетаИгоГоСофт

МетаОгоГоСофт

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

Что-то типа GUI Net …

У меня, когда использовал Foxpro 2 ручного кода было процентов пять.
Остальной весь код генерировался и дополнялся в основной код на основании генератора отчета и GUI /фокспрошные визарды не использовал/.

Сэкономил 50 лет жизни ...  

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

Вообщем легким движением руки ...

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

Ныне разрабатываю на порядок лучше функциональность ...

PS: Как-то так …

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

Так что пусть желтые не плачут.
Добавится, 2D и 3D графика и многое иное … Конечно мог бы неплохо баксов ХАПАНУТЬ, но

НЕ БУДУ!

Open source он разный бывает

Форумный и реальный ...
anonymous
()
Ответ на: комментарий от MOPKOBKA

я даже видео записывал как это сделать.

Я не вижу ссылку на видео у тебя в профиле. И да. Что за расстрельный список у тебя там, я там есть. Мне должно быть страшно? А то мало ли =)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Sorry за шутку

Что за расстрельный список у тебя там, я там есть. Мне должно быть страшно? А то мало ли =)

Он уже три панихиды по Вам справил …
А за мои посты

ТРИДЦАТЬ ТРИ ПАНИХИДЫ ...
anonymous
()
Ответ на: комментарий от LINUX-ORG-RU

А меня то за что, я хороший =)

Ему лучше знать …
А может «за здравие»?

PS: Все кто скритуху использует

ВРАГИ!
anonymous
()
Ответ на: комментарий от alysnix

Не претендуя на обобщение, дополню о Labview:

  1. Нет нормальных функций. sub-vi это не совсем оно. Нужно именно выделение участка кода.

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

  3. Низкая плотность информации: на экране одновременно помещается значительно меньше графики, чем текста. Приходится либо скроллить влево-вправо, либо запихивать в структуру "последовательность.

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

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

Но при этом с «алгоритмы естественно последовательны» не соглашусь. Распараллеливание на уровне языка там реализовано красиво. Жаль только, на уровне реализации не реализованы.

COKPOWEHEU
()
Ответ на: комментарий от LINUX-ORG-RU

скритуху

чёитатакое?

Все, для понимания чего не требуется метасознание

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

Но при этом с «алгоритмы естественно последовательны» не соглашусь.

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

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

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

Да тоже нет. Часто можно выделить параллельные участки. Только смысла в этом немного: типичное арифметическое выражение вычисляется настолько быстро, что распараллеливания просто не требует.

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

Кстати об уравнениях: было бы интересно как на Метапроге выглядит ну хотя бы уравнение параболы y=ax^2+bx+c, насколько оно менее читаемо, чем в тексте.

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

Кстати об уравнениях: было бы интересно как на Метапроге выглядит ну хотя бы уравнение параболы y=ax^2+bx+c, насколько оно менее читаемо, чем в тексте.

Ха. Он строку перевернуть не может уже 3 года, а ты про уравнения. Уравнений в версии не ниже 2000 будет.

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