LINUX.ORG.RU

название кодогенератора

 ,


0

1

привет всем :)

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

  • g3io
  • modegen
  • mdg или mdg2
  • multigen
  • mambino
  • mombiz
  • ingom

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

Если идти от назначения и в угоду некоторым, то «инструктаж» или более универсальное «inseq» («инсектор»), «seqrator» («секатор» - абстрактно и мощно), «inquetor» («инквизитор» - не менее мощно).

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

ну, не хотел грузть лишними подробностями, пока даже названия не мог предоставить :)

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

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

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

zerhud ()

В компиляторе A2 три звена - «frontend», «middle tier» и «backend». Из них frontend и backend являются сменными. Есть куча картинок про архитектуру компилятора, но они не такие. При том в A2 нет названия для middle tier, а есть просто набор модулей, которые его воплощают. Соответственно, я перевёл как «голова», «тело» и «хвост». В качестве неожиданного побочного эффекта появились сообщения:

если options.backend.error то
  FinalMessage(правда," не скомпилировался (ошибки хвоста).");
возврат ложь

и

иначе 
  compilerOptions.frontend := 
    Frontend.GetFrontendByName(DefaultFrontend);
  если compilerOptions.frontend = НУЛЬ то 
    Error("не удалось подключить голову по умолчанию"); 
    result := ложь кн кн;

А, хотя у тебя не генератор машинного кода, а генератор кода на разных языках. Тогда «хвост» не подходит. Назови M31 - Туманность Андромеды. Будет аллюзия на m4, который, я надеюсь, ты изучил перед тем, как браться за дело.

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

о, я как-то не подумал,чтобы создавать некие аллюзии. m4 я не использовал, только awk и sed для повседневных, так сказать, нужд. не очень представляю как m4 можно использовать тут, это больше таки для шаблоноризатора задачи.

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

кабачковый генератор. Мощно. Солидно.

Кто о чем, а вы все о кабачке в своей сраке мечтаете … Как не стыдно столько флудить…

Владимир 123

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

да, согласен, на awk не нагенеришь :) если я не ошибаюсь, m4 позиционирует себя как препроцессор. просто, как я оцениваю m4 - мне легче бойлерплейт код писать. одно из требований, которе я себе ставил - легче написать шаблон, чем бойлерплейт код.

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

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

zerhud ()

Purgen же. Смотри как хорошо звучит:

"Возьми пурген и примени его по назначнию.

Что это за высер? Не иначе пугрен виноват."

anonymous ()
  • GenDir (как генеральный директор).
  • Gender (популярная тема).
  • mutagen (на входе одно, на выходе другое).
  • Geneva (хрен загуглишь, зато красиво).
  • poorgen (бедный генератор, управлять ожиданиями — ключ к успеху).
ugoday ★★★★★ ()
Ответ на: комментарий от zerhud

Как-то судя по описанию, получается универсальный генератор всего из всего? Тогда «Генералиссимус», как предлагали выше. :)

Но я как-то скептически к идее отношусь. Универсальный проект, imho, означает, что для применения его к чему-то конкретному надо будет приложить усилия, сравнимые с написанием компилятора, имея под рукой flex и bison. Ну насчёт сравнимых я утрирую, конечно, но…

Вот чего бы я хотел видеть — это генератор кода десктопных программ по работе с БД, исходя из структуры самой БД на входе, допустим, на основе Qt. И с возможностью последующего редактирования, разумеется. Почему Qt — потому, что QtSql позволяет единообразно работать с разными СУБД, и притом кроссплатформенно.

Проприетарные решения я видел, но они мало того, что проприетарные, так все из прошлого века и прибиты гвоздями либо к ОС, либо к СУБД. Сейчас вряд ли кто такое выпустит, поскольку информационные системы массово переехали в веб. А для немногих БД, нужных «домашнему» пользователю, «массовый» подход к программированию, вероятно, не оправдан. Sad but true.

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

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

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

добавил в варианты генералссимуса :) сейчас пытаюсь определится.

генератор кода десктопных программ по работе с БД

а что за программа по работе с бд? типа гуй (или интерфейс командной строки) реализующий crud? а как тебе это https://www.webtoolkit.eu/wt/doc/tutorial/dbo.html ? кое кто в своей книге называет crud мертвым микросервисом от того, что там не раелизованно никакой логики. кажется, что такой гуй тоже будет мертвым. хотелось бы иметь какик-то полезные функции, поиск какой-нибудь хитрый, автоматизацию прикладных задач.. но такое не сгенеришь (в смысле это для конкретной домена нужно).

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

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

Но я как-то скептически к идее отношусь.

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

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

ой, не дочитал, извини :) типа мастер такой? ну кажется это достаточно легко реализуется в рамках того, о чем я говорю.

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

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

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

Ну тут можно ввести режим обновления: если ui менялся, то парсить ui-файл и учитывать при перегенерации. Да, это сложнее, но в принципе, решаемо.

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

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

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

zerhud ()

народ, спасибо всем большое, а то мне бы не нравилось название своего проекта :)

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

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

clojure после common lisp - насколько омерзительно и в чём именно?

раз там огорожено, пишу сюда.

зачем нужен Clojure лично мне как-то немного стало понятно после прочтения и протыкивания примеров про Arcadia – ну реально просто на кложе пишутся всякие там простенькие поделки на юнити. ну или play-cljc с примерами

плюс есть lightmod в котором всё-в-одном, кложа и как бы IDE. и сразу можно сесть и что-то наколбасить на этой связке. не то чтобы clojure box с емаксом сильно хуже, но тут не емакс, проще.

ещё есть Nighlight про разработку в образе, внутри самого дорабатываемого прототипа. + презентацияMaking Games at Runtime with Clojure

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

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

«Representing Game Dialogue as Expressions in First-Order Logic» .pdf by Kaylen FJ Wheeler.

там в общем про игру типа квест, RPG с игровыми диалогами. сейчас, как пишут – в основном тупо линейно хардкодят все варианты вручную, получают тупой конечный автомат или хуже типа лесенки из IF-ов, всё линейное.

что предлагает автор. наподобие того как в ложбане можно выражать логические выражения в конструируемом языке, он предлагает эти самые игровые диалоги нелинейные генерировать, синтезировать из DSL на основе логических выражений логики первого порядка. для симуляции Theory Of Mind этих NPC на основе представления знаний – для построения Beliavable Agents персонажей игрока и NPC.

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

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

учитывая что это не базовый CL или схема а кложа, за счёт интеграции с JVM получаем функционально-логический интерфейс доступа к «разработке в образе» со стандартными JVM/CLR API. например того же Unity через Arcadia либо нативных JVM движков через play-cljc.

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

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

ну в общем, есть куда ещё расти им в плане такой вот кодогенерации.

anonymous ()