Здравствуйте, Marty, Вы писали:
M>>>Ну, например, какой-нибудь class wizard свой. M>·>Магию в топку. Ты программист или где? M>Ок, я не программист.
Тогда найми программиста, чтобы он тебе на ангуляре сваял визарда.
M>Я не пойму, что ты мне доказать-то хочешь?
Что программистам гуй не нужен.
M>И при чем тут хорошая IDE, это только пример был для плюсиков, а в реале, допустим, надо сформировать командную строку для вызова какой-нибудь тулзы, или это
Программист напишет код, хоть там одноразовый bash-скриптик. Непрограммисту командные строки c lua не нужны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
M>>Ну, например, какой-нибудь class wizard свой. M>>1) На первой странице вводим имя ...
N>Да поняли мы что ты хочешь. Тебя спрашивают нафига тратить время на GUI? У MS уже есть VS и им имеет какой-то смысл это туда пихать, но тебе то нафига лишние сущности?
На гуй тратить время обычно не стоит, я консольку люблю и все тулзы у меня консольные, ибо городить какой-то спец гуй действительно лишняя трата времени, просто...
N>Документации не аргумент, так как гораздо проще ее добавить в "--help" или wiki.
Ну, например, одна самописная простенька тулза по --help выдает 250 строчек, другая 700. И это чисто краткая подсказка. Дока на вторую тулзу — порядка 60 страниц. В баш добалена поддержка автокомплита, но этого не хватает.
Хочется за полчасика, ну, может за час описать в каком-то формальном текстовом виде все основные юз-кейсы, и скормить его какой-то проге, которая по шагам позволит выбрать настройки так, как нужно для моего конкретного случая.
Здравствуйте, ·, Вы писали:
M>>>>Ну, например, какой-нибудь class wizard свой. M>>·>Магию в топку. Ты программист или где? M>>Ок, я не программист. ·>Тогда найми программиста, чтобы он тебе на ангуляре сваял визарда.
M>>Я не пойму, что ты мне доказать-то хочешь? ·>Что программистам гуй не нужен.
M>>И при чем тут хорошая IDE, это только пример был для плюсиков, а в реале, допустим, надо сформировать командную строку для вызова какой-нибудь тулзы, или это ·>Программист напишет код, хоть там одноразовый bash-скриптик. Непрограммисту командные строки c lua не нужны.
Здравствуйте, Marty, Вы писали:
N>>Документации не аргумент, так как гораздо проще ее добавить в "--help" или wiki. M>Ну, например, одна самописная простенька тулза по --help выдает 250 строчек, другая 700. И это чисто краткая подсказка. Дока на вторую тулзу — порядка 60 страниц. В баш добалена поддержка автокомплита, но этого не хватает. M>Хочется за полчасика, ну, может за час описать в каком-то формальном текстовом виде все основные юз-кейсы, и скормить его какой-то проге, которая по шагам позволит выбрать настройки так, как нужно для моего конкретного случая. Это как раз про то что ты говоришь:
To make a complex subsystem easier to use, a simple interface should be provided for a set of interfaces in the subsystem.
Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?..
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Marty, Вы писали:
M>·>Это как раз про то что ты говоришь: M>·>
To make a complex subsystem easier to use, a simple interface should be provided for a set of interfaces in the subsystem.
M>·>Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?.. M>А чем консоль лучше, чем гуй?
Лучше для чего/кого? Interface бывает трёх типов: API, CLI и GUI. Программистам удобнее первое, сисадминам второе, пользователям третье.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>·>Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?.. M>>А чем консоль лучше, чем гуй? ·>Лучше для чего/кого? Interface бывает трёх типов: API, CLI и GUI. Программистам удобнее первое, сисадминам второе, пользователям третье.
Здравствуйте, Marty, Вы писали:
M>>>·>Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?.. M>>>А чем консоль лучше, чем гуй? M>·>Лучше для чего/кого? Interface бывает трёх типов: API, CLI и GUI. Программистам удобнее первое, сисадминам второе, пользователям третье.
M>И? Ты сейчас это в lynx'е ответ писал?
Программист это не расовая принадлежность, а роль. Этот ответ не код, а значит я писал его не как программист, а пользователь, поэтому использовал GUI.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>>>·>Хинт: зачем обязательно этот interface должнен быть GUI с учётом того, что им подразумевается будут пользоваться программисты?.. M>>>>А чем консоль лучше, чем гуй? M>>·>Лучше для чего/кого? Interface бывает трёх типов: API, CLI и GUI. Программистам удобнее первое, сисадминам второе, пользователям третье.
M>>И? Ты сейчас это в lynx'е ответ писал? ·>Программист это не расовая принадлежность, а роль. Этот ответ не код, а значит я писал его не как программист, а пользователь, поэтому использовал GUI.
Здравствуйте, Marty, Вы писали:
M>>>И? Ты сейчас это в lynx'е ответ писал? M>·>Программист это не расовая принадлежность, а роль. Этот ответ не код, а значит я писал его не как программист, а пользователь, поэтому использовал GUI. M>vi/emacs и gdb — наше ффсё?
vi/emacs это не cli. Дебаггер это когда не хватает опыта и написанным кодом (ака тестами) не получается обойтись. Впрочем, это всё очень далеко от сабжа.
А ещё ты путаешь редактирование и генерацию кода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>>>И? Ты сейчас это в lynx'е ответ писал? M>>·>Программист это не расовая принадлежность, а роль. Этот ответ не код, а значит я писал его не как программист, а пользователь, поэтому использовал GUI. M>>vi/emacs и gdb — наше ффсё? ·>vi/emacs это не cli.
Не cli, да.
Гуй, наверное
·>Дебаггер это когда не хватает опыта и написанным кодом (ака тестами) не получается обойтись. Впрочем, это всё очень далеко от сабжа. ·>А ещё ты путаешь редактирование и генерацию кода.
А ты путаешь конструктивный диалог с тупым флеймом ради флейма
M>Описываем это всё в каком-нибудь конфиге, например, в каком-то "стандартном XML" (превед Шеридану ) или в джейсоне. Первый многословен, зато всё буль менее самодокументирован, во втором — писать проще, но с валидацией похуже.
Ага-ага. «Все будет задокументировано», как же.
M>Из плюсов — такое описание само будет, как документация — видно, какие есть альтернативы, какие опции при разных альтернативах доступны, и тп. Можно по этому формальному описанию и доку человекочитаемую сгенерить.
С какого перепугу это описание будет, как документация?
Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться.
От того, что ты эту сотню параметров закинешь в XML, оно станет более понятным? Или описание того, что эти параметры делают, появится магическим образом из воздуха?
Кто будет эти XMLи писать? Чем они отличаются от скриптов, в которых надо разбираться? Ты заменишь «питон, который никто не знает» кривой конфигурацией, которую так же никто не знает. Потому что это будет не конфигурация, а DSL. Кто будет писать весь функционал и логику для вот этого:
— После нажатия "Finish" берется пара шаблонов .cpp/.h, в подаем их на вход шаблонизатору вместе с выбранными опциями
— Сконфигурировать так, чтобы какая-то команда запустилась, или еще что-то.
Вся эта логика магическми образом будет реализована, ага, и магическми образом самодокументируется, ага.
Вместо того, чтобы сесть:
— и написать документацию к сущесвтующим тулзам
— написать tool help и tool help option
— хотя бы просто вписать в скрипт в начало файла большой комментарий, как этим пользоваться
— вынести всю эту ненужную трахотню с отдельным запуском каких-то скриптов в настройки проекта, условные куски кода, генерацию в процессе сборки.
Здравствуйте, Mamut, Вы писали: M>>Из плюсов — такое описание само будет, как документация — видно, какие есть альтернативы, какие опции при разных альтернативах доступны, и тп. Можно по этому формальному описанию и доку человекочитаемую сгенерить. M>С какого перепугу это описание будет, как документация?
Визард, помимо всего прочего, подразумевает внятное предложение или абзац, в котором раскрывается, что предлагается выбрать на данной странице.
Каждое возможное значение чего-либо тоже обладает описанием
M>
M>Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться.
M>От того, что ты эту сотню параметров закинешь в XML, оно станет более понятным? Или описание того, что эти параметры делают, появится магическим образом из воздуха?
Не магическим, а из описания страницы. Из того описания, которое будет отображаться пользователю визарда
M>Кто будет эти XMLи писать? Чем они отличаются от скриптов, в которых надо разбираться? Ты заменишь «питон, который никто не знает» кривой конфигурацией, которую так же никто не знает. Потому что это будет не конфигурация, а DSL.
Писать будет тот, кому больше всех это надо
Вот я напилил несколько тулз, запилил статей в вики, чтобы коллегам было понятно, что к чему, но всё равно не очень — всем проще меня спросить чо как, а я в ответ уже просто ссылку на конкретный раздел доки скидываю. Мне бы проще было один раз напилить визардов, и чтобы меня никто не трогал
M>Кто будет писать весь функционал и логику для вот этого: M>- После нажатия "Finish" берется пара шаблонов .cpp/.h, в подаем их на вход шаблонизатору вместе с выбранными опциями M>- Сконфигурировать так, чтобы какая-то команда запустилась, или еще что-то.
Опять же — тот, кому больше всех надо
Вот у меня такая рутина появилась, раз, другой руцами сделал. Вижу, что часто повторяется, запилил конфиг для визарда, в следующий раз и себе меньше работы, и расшарить практику на тим легко
M>Вся эта логика магическми образом будет реализована, ага, и магическми образом самодокументируется, ага.
Не магическим образом, а интерпретатором. Который на входе берет DSL, ага, и показывает нужные странички в нужном порядке, а потом вызывает шаблонизатор или еще что-то.
M>Вместо того, чтобы сесть: M>- и написать документацию к сущесвтующим тулзам
Документация написана. На некоторые тулзы у меня мануалы на не один десяток страниц написан.
M>- написать tool help и tool help option
--help — выдает обычно 200+ строк, в пике сейчас 700 строк просто перечисления опций.
Каждая тулза абсолютно автономна (не требует какой-либо установки) и умеет сама прописывать в баш правила автокомплита, а для CMD — я нагуглил некий CLINK, который умеет примерно в тоже самое. Это помогает, но только когда сам уже хорошо понимаешь, что тулза умеет, и что ты хочешь от неё. M>- хотя бы просто вписать в скрипт в начало файла большой комментарий, как этим пользоваться
Большой коментарий — это ссылка на вики, где лежит дока
M>- вынести всю эту ненужную трахотню с отдельным запуском каких-то скриптов в настройки проекта, условные куски кода, генерацию в процессе сборки.
Трахотня вынесена в батники, которые запускаются перед сборкой проекта. Но, чтобы написать эти батники, нужно покурить доку и правильно настроить вызов соответствующих тулз.
Пример конфига такого визарда-всемогутора (всё чисто гипотетическое, чисто для теста):
Скрытый текст
{
"wizard" :
{
"dummy-first":"",
"geometry":"AUTO",
"title":"Wizardry Test",
"icon":"pw.ico",
"banner":"",
"logo":"pw-logo.png",
"image":"pw-img.png",
"style":"classic",
"generate-guids":5,
"template":"$template-file",
"template-buddies":"+.app,.rep",
"output" :"$output-file",
"output-buddies":"+.app,.rep",
"force-single-line":0,
"show-completion-message":"Job done",
"dummy-last":""
},
"values":
{
"radio-choise-1":
{
"title":"Radio button 1",
"description":"Description of radiobutton #1"
},
"radio-choise-2":
{
"title":"Radio button 2",
"description":"Description of radiobutton #2"
},
"radio-choise-3":
{
"title":"Radio button 3",
"description":"Description of radiobutton #3"
},
"welcome":
{
"title":"Welcome",
"description":"Loop to welcome page"
},
"dropdown-val-1": {
"title": "Dropval One",
"long-title": "This is the dropval one value",
"description": "Description not required if used only in dropdowns"
},
"dropdown-val-2":
{
"title":"The Second Dropval",
"description":"Description not required if used only in dropdowns"
},
"dropdown-optional-val-1":
{
"title":"First value",
"long-title":"This is the First",
"description":"Description for the first value"
},
"dropdown-optional-val-2":
{
"title":"Second value",
"description":"Second value description"
},
"edit-val-1":
{
"title":"Edit control test 1",
"description":"Edit control test 1 description"
},
"edit-val-2":
{
"title":"Edit control test 2",
"description":"Edit control test 2 description"
},
"edit-val-3":
{
"title":"Edit control test 3",
"description":"Edit control test 3 description"
},
"edit-val-phone-1":
{
"title":"Phone number #1"
},
"edit-val-phone-2":
{
"title":"Phone number #2"
},
"edit-val-phone-3":
{
"title":"Phone number #3"
},
"password1":
{
"title":"Password"
},
"password2":
{
"title":"Password"
},
"password3":
{
"title":"Password"
},
"input-file":
{
"title":"Input file"
},
"output-file":
{
"title":"Output file"
},
"template-file":
{
"title":"Template file"
}
},
"pages" :
{
"welcome":
{
"page-type":"welcome",
"title":"Welcome!",
"subtitle":"Welcome to the Wizardry Test wizard",
"description":"This wizard helps your to go through the rest of all Wizardry Test and sample pages",
"next-page":"fileselection-test",
"dummy-last":""
},
"fileselection-test":
{
"page-type":"fileselections",
"title":"Wizard File Selection",
"subtitle":"File Selection controls test",
"description":"Select files into each field",
"next-page":"edit-test",
"controls-width":"/2",
"fileselections":
[
{ "target-var":"input-file",
"default":"test.txt",
"options":"open-existing,readonly-edit,native",
"filters":"Text files - *.txt; Ini Files - *.ini; All files - *"
},
{ "target-var":"output-file",
"options":"save-dialog,not-native",
"filters":"Text files - *.txt; *.cpp *.cxx *.c; *.hpp *.hxx; Template files - *.tpl; All files - *"
},
{ "target-var":"template-file",
"options":"open-existing",
"filters":"Text files - *.txt; Template files - *.tpl; All files - *"
}
],
"dummy-last":""
},
"edit-test":
{
"page-type":"editfields",
"title":"Wizard Edit Test",
"subtitle":"Edit controls test",
"description":"Enter value into each edit control",
"next-page":"listsinglesel-test",
"controls-width":"/2",
"editfields":
[
{ "title":"Edit 1",
"target-var":"edit-val-1",
"target-var-title":"Overrided target value title",
"default":"Text1"
},
{
"target-var":"edit-val-2",
"input-mask":""
},
{ "title":"Edit 3",
"target-var":"edit-val-3"
},
{ "target-var":"edit-val-phone-1",
"default":"+1 (123) 456-78-90"
},
{ "target-var":"edit-val-phone-2",
"placeholder":"+1 (123) 456-78-90"
},
{ "target-var":"edit-val-phone-3",
"placeholder":"+1 (123) 456-78-90",
"mask":"+D (DDD) DDD-DD-DD;X"
},
{ "title":"Mode - password-echo",
"target-var":"password1",
"mode":"password-echo"
},
{ "title":"Mode - password",
"target-var":"password2",
"mode":"password"
},
{ "title":"Mode - silent",
"target-var":"password3",
"mode":"silent"
}
],
"dummy-last":""
},
"listsinglesel-test":
{
"page-type":"listsinglesel",
"title":"Wizard Single Selection List Test",
"subtitle":"Single Selection List selection and flow control choice test",
"description":"Single Selection List one of items in the list",
"next-page":"dropdowns-test",
"target-var":"listsinglesel-test",
"target-var-title":"Single Selection List test",
"list-choice":
[
{ "value":"radio-choise-1", "setwo":[ {"buddies":".def"} ] },
{ "value":"radio-choise-2", "appwo":[ {"buddies":".bla"} ] },
{ "value":"radio-choise-3" },
{ "value":"dropdown-val-1" },
{ "value":"dropdown-val-2" },
{ "value":"dropdown-optional-val-1" },
{ "value":"optional-dropdowns", "next-page":"optional-dropdowns", "text":"Go to optional dropdown test" },
{ "value":"summary", "next-page":"summary", "text":"Go to summary (skip all other pages)" }
],
"dummy-last":""
},
"dropdowns-test":
{
"page-type":"dropdowns",
"title":"Wizard Dropdown Comboboxes Test",
"subtitle":"Select value in dropdown list test",
"description":"Select value in each dropdown",
"next-page":"radiobuttons-test",
"controls-width":"/3",
"dropdowns":
[
{ "title":"Dropdown 1",
"target-var":"dropdown1-res",
"target-var-title":"Dropdown 1",
"add-values-long-title":1,
"values":
[
{ "value":"radio-choise-1" },
{ "value":"radio-choise-2", "default":1 },
{ "value":"radio-choise-3" }
]
},
{ "title":"Dropdown 2",
"target-var":"dropdown2-res",
"use-values-long-title":1,
"values":
[
{ "value":"dropdown-val-1" },
{ "value":"dropdown-val-2", "default":1 }
]
},
{ "title":"Dropdown 3 - same as Dropdown 2, but without default value",
"target-var":"dropdown3-res",
"values":
[
{ "value":"dropdown-val-1" },
{ "value":"dropdown-val-2" }
]
}
],
"dummy-last":""
},
"radiobuttons-test":
{
"page-type":"radio-choice",
"title":"Wizard Radiobuttons Test",
"subtitle":"Radiobuttons value selection and flow control choice test",
"description":"Select one of three first items or choose last one to go directly to summary final page",
"next-page":"test-page3",
"target-var":"radiobuttons-test",
"target-var-title":"Radiobuttons test",
"default-choice":"radio-choise-3",
"radio-choice":
[
{ "value":"radio-choise-1" },
{ "value":"radio-choise-2", "default":1 },
{ "value":"radio-choise-3" },
{ "value":"optional-dropdowns", "next-page":"optional-dropdowns", "text":"Go to optional dropdown test" },
{ "value":"summary", "next-page":"summary", "text":"Go to summary (skip all other pages)" }
],
"dummy-last":""
},
"optional-dropdowns":
{
"page-type":"dropdowns",
"title":"Wizard Optional Dropdown Combobox Test",
"subtitle":"Select value in taken dropdown list",
"next-page":"test-page3",
"controls-width":"/3",
"dropdowns":
[
{ "title":"Select value",
"target-var":"optional-dropdown-res",
"target-var-title":"Optional Dropdown Value",
"values":
[
{ "value":"dropdown-optional-val-1" },
{ "value":"dropdown-optional-val-2" }
]
}
],
"dummy-last":""
},
"test-page3":
{
"page-type":"info",
"title":"Test Page number three",
"subtitle":"Test Page number three subtitle",
"description":"This is a simple page number 3",
"next-page":"summary",
"dummy-last":""
},
"summary":
{
"title":"Wizardry Test Summary",
"page-type":"summary",
"subtitle":"Please check the options collected during walking through the wizard",
"dummy-last":""
}
}
}
Здравствуйте, Marty, Вы писали:
S>>Он MSVC пришиблен. M>Я тебя так сильно чем-то обидел?
Извини, я резко высказался. Мир-дружба-жевачка.
Я хотел сказать, что с моей точки зрения, студия прививает неправильную культуру управления проектами. При всей уродливости языка идеалогически подход типа CMake правильнее.
Здравствуйте, Marty, Вы писали:
M> Здравствуйте!
M>Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Я бы шаблонизатор прикрутил. Например ту-же j2cli, у ней унутрях привычная jinja2.
Шаблон:
server {
listen 80;
server_name {{ nginx.hostname }};
root {{ nginx.webroot }};
index index.htm;
}
Здравствуйте, Marty, Вы писали:
M>А чем консоль лучше, чем гуй?
интеграцией с другими программами (my_tool_1 | my_tool_2)
возможностью поиска (my_tool --help | grep "do all the good")
простотой (в GUI "найдите кнопку 'ФЫВА'", в CLI — "наберите 'ФЫВА'", над вторым вариантом думать вообще не надо).
Re[3]: Универсальный визард (мастер) - зачем таки нужно
Здравствуйте, Mamut, Вы писали:
M>Потому что это фиксированный набор с заранее известными параметрами. Там нет никаких «универсальных визардов».
ЕМНИП в QtCreator именно универсальный визард для новых проектов, возможные параметры, на основе которых генерится GUI, хранятся где-то в текстовом виде.
M>>С какого перепугу это описание будет, как документация?
M>Визард, помимо всего прочего, подразумевает внятное предложение или абзац, в котором раскрывается, что предлагается выбрать на данной странице. M>Каждое возможное значение чего-либо тоже обладает описанием
и тут же
M> Документация написана. На некоторые тулзы у меня мануалы на не один десяток страниц написан.
Но в визарде эта доукментация ВНЕЗАПНО станет короткой и всем понятной, ага.
M>Писать будет тот, кому больше всех это надо M>Не магическим образом, а интерпретатором. M>Пример конфига такого визарда-всемогутора (всё чисто гипотетическое, чисто для теста):
То есть точно так же, как сейчас скрипты Ты жалуешься, что народ не понимает, что в питоновых скриптах написано. А вот в твоем мега-XML'е/мега-JSON'е с каким-то магическим интерпретатором (который тоже видимо магическим образом появляется и не требует ни документации ни сопровождения — ничего) все автоматом сразу разбираются и радостно пишут на нем визарды
M>Вот я напилил несколько тулз, запилил статей в вики, чтобы коллегам было понятно, что к чему, но всё равно не очень — всем проще меня спросить чо как, а я в ответ уже просто ссылку на конкретный раздел доки скидываю. Мне бы проще было один раз напилить визардов, и чтобы меня никто не трогал
Ага. В визарде будет 100 параметров с 10 страницами документации, но тебя никто не будет спрашивать, ага.
M>Вот у меня такая рутина появилась, раз, другой руцами сделал. Вижу, что часто повторяется, запилил конфиг для визарда, в следующий раз и себе меньше работы, и расшарить практику на тим легко
Л — логика:
— скрипты на питоне никто не понимает, документацию на 10 страниц не читают, расшаривать с командой сложно
— визард на неизвестном никому DSL'е на неизвестном никому интерпретаторе это хорошо, все понимают, 10 страниц документации в визарже все будут читать, расшаривать визард с командой — легко
M>--help — выдает обычно 200+ строк, в пике сейчас 700 строк просто перечисления опций.
Ну у тебя будет 700 строк опций в визарде. Стало сильно легче?
M>>- вынести всю эту ненужную трахотню с отдельным запуском каких-то скриптов в настройки проекта, условные куски кода, генерацию в процессе сборки.
M>Трахотня вынесена в батники, которые запускаются перед сборкой проекта. Но, чтобы написать эти батники, нужно покурить доку и правильно настроить вызов соответствующих тулз.
Раз это делает несколько раз, постоянно, то вот эти несколько раз вписываются в батники.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Marty, Вы писали:
M>> Здравствуйте!
M>>Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
S>Я бы шаблонизатор прикрутил. Например ту-же j2cli, у ней унутрях привычная jinja2.
У меня пайтоновский mako
Но это не снимает вопроса способе задания аргументов
Здравствуйте, Skorodum, Вы писали:
S>>>Он MSVC пришиблен. M>>Я тебя так сильно чем-то обидел? S>Извини, я резко высказался. Мир-дружба-жевачка.
Ок
S>Я хотел сказать, что с моей точки зрения, студия прививает неправильную культуру управления проектами. При всей уродливости языка идеалогически подход типа CMake правильнее.
У тебя сложилось несколько превратное впечатление. Я конечно люблю студию, и под винду пишу под ней, но вообще не чужд и работе в консольке по ssh, а сейчас отлаживаюсь на железках через COM-порт.