Здравствуйте, Ops, Вы писали:

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

Да? ) Т.е. на форуме ты тут пишешь "я сделал file open и потом запустил debug"? ) Или может всё же по другому пишешь? )

Здравствуйте, alex_public, Вы писали:

_>У вас какая-то путаница в голове: слиты в единое целое система сборки (которая в принципе должна быть независима от ide) и система проектов ide (хранящая настройки проекта нужные для ide).

Наоборот, путаница у вас. В CLion разделена модель проекта (то, что необходимо для его сборки) и опции IDE (code style, настройки контроля версий, цвета и размеры шрифтов, прочие ненужные для сборки вещи). Модель читается из CMake-файла, т.к. именно там написано как скомпилировать каждый файл и что перед этим нужно сделать.

_>Никто не предлагает писать свою систему сборки. А вот написать свою систему проектов (т.е. по сути просто сохранение/востановление пары опций) явно не помешало бы. При таком раскладе не надо было бы страдать парсингом конфига для сборки и соответственно можно было бы одним простейшим движением (возможностью запуска произвольной команды при построение) поддержать сразу все существующие системы сборки.

Как вы себе представляете поддержку "простейшим движением" какого-нибудь средней руки проекта, скажем, самого CMake? Там нужно заголовочники перед компиляцией погенерить (иначе остальные файлы просто не распарсить), для нескольких множеств файлов составить соответствующие наборы опций компиляции (в общем случае у каждого файла этот набор свой), сам компилятор выбрать (у них разные built-in функции/макросы и IDE должна их видеть именно такими и именно для этой версии компилятора). Теперь умножайте это в несколько раз, ибо есть релизная сборка, дебажная, специальная сборка для ООО "Вектор", сборка под другую платформу, под другую архитектуру и т.п. Не от безделья же люди пишут километры конфигов в CMakeLists.txt . Теперь вы предлагаете то же самое описать руками второй раз через некие настройки, которые никому, кроме IDE не нужны. Сколько найдется желающих делать работу дважды, сколько будет у такой IDE пользователей?

Конечно, необходимо поддерживать и другие модели проекта, в том числе простейшую, где можно открыть папку с лабой студента, дописать header search paths, и все полетит. Но сначала придется пилить CMake, т.к. большинство программистов хотят открывать не HelloWorld и laba-3, а LLVM и InsightToolkit.

_>Более того, у вас такая система проектов похоже уже есть прямо сейчас (судя по тексту ниже), только она не имеет такого официального названия (ну да, "специфичные для проекта code style" — это конечно совсем другое... ). Так что я вдвойне не понимаю это ваше странное решение.

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

Здравствуйте, alex_public, Вы писали:

_>Да? ) Т.е. на форуме ты тут пишешь "я сделал file open и потом запустил debug"? ) Или может всё же по другому пишешь? )

Есть и другие примеры. Например, знаешь, что такое "иерархия вызовов"? Это так call stack обозвали. Или вот "панель элементов" — toolbox. Попробуй угадай.
А если в настройки проекта залезть, то сидишь и думаешь, что бы эта настройка значила, inline — оно и в индии inline, накрайняк инлайн, а оказывается "подставляемая". Тьфу.

Здравствуйте, Ops, Вы писали:

Ops>Есть и другие примеры. Например, знаешь, что такое "иерархия вызовов"? Это так call stack обозвали. Или вот "панель элементов" — toolbox. Попробуй угадай.
Ops>А если в настройки проекта залезть, то сидишь и думаешь, что бы эта настройка значила, inline — оно и в индии inline, накрайняк инлайн, а оказывается "подставляемая". Тьфу.

А чем не нравится перевод то? ) Или нравится заменять всё англицизмами?

Вообще, если где-то в нашей области и существуют неустоявшиеся до конца термины, то это вина исключительно нас с вами (в смысле русского сообщества программистов), потому как, а кто собственно кроме нас будет определять эти стандарты? )

Здравствуйте, alex_public, Вы писали:

_>А чем не нравится перевод то? ) Или нравится заменять всё англицизмами?

Так первые 2 примера просто некорректны, а 3-й — это уже плюсы начали переводить. Дальше смотреть не стал, переключил обратно на английский, потому как бяка.

_>Вообще, если где-то в нашей области и существуют неустоявшиеся до конца термины, то это вина исключительно нас с вами (в смысле русского сообщества программистов), потому как, а кто собственно кроме нас будет определять эти стандарты? )

В смысле неустоявшиеся? Call stack — это стек вызовов, или просто стек, в подходящем контексте. А когда в это лезут литературоведы, да еще и язык программирования переводить пытаются, то нафиг мне такое счастье, и с английским неплохо.

Здравствуйте, noone, Вы писали:

N>Наоборот, путаница у вас. В CLion разделена модель проекта (то, что необходимо для его сборки) и опции IDE (code style, настройки контроля версий, цвета и размеры шрифтов, прочие ненужные для сборки вещи). Модель читается из CMake-файла, т.к. именно там написано как скомпилировать каждый файл и что перед этим нужно сделать.

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

N>Как вы себе представляете поддержку "простейшим движением" какого-нибудь средней руки проекта, скажем, самого CMake? Там нужно заголовочники перед компиляцией погенерить (иначе остальные файлы просто не распарсить), для нескольких множеств файлов составить соответствующие наборы опций компиляции (в общем случае у каждого файла этот набор свой), сам компилятор выбрать (у них разные built-in функции/макросы и IDE должна их видеть именно такими и именно для этой версии компилятора). Теперь умножайте это в несколько раз, ибо есть релизная сборка, дебажная, специальная сборка для ООО "Вектор", сборка под другую платформу, под другую архитектуру и т.п. Не от безделья же люди пишут километры конфигов в CMakeLists.txt. Теперь вы предлагаете то же самое описать руками второй раз через некие настройки, которые никому, кроме IDE не нужны. Сколько найдется желающих делать работу дважды, сколько будет у такой IDE пользователей?

Я вроде бы достаточно чётко описал реализацию этого простейшего движения (собственно оно имеется во всех конкурирующих IDE). Это возможность запуска произвольной команды (а будет это make/nmake/waf/scons или вообще bat файл решает пользователь в простейшей настройке) по нажатию кнопки build в IDE. В таком случае будут одинаково отлично работать и студенческая поделка и проект с километровым конфигом в CMakeLists.txt.

Кстати, нечто очень отдалённое там всё же реализовано. Только почему-то не в настройках build, а в настройках run/debug. Там можно добавить произвольную команду перед запуском и даже убрать стандартный шаг build. Однако это всё же решение через задницу. Тем более, что без CMakeLists.txt анализатор кода всё равно работать не будет.

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

N>Никакого отношения к структуре проекта эти опции не имеют. Они нужны только CLion (и даже он без них проживет на стандартных значениях), а остальному миру не нужны. Поэтому живут отдельно.

Ну так и настройки анализатора кода нужны только CLion — вот там им и самое место.

Здравствуйте, Ops, Вы писали:

Ops>В смысле неустоявшиеся? Call stack — это стек вызовов, или просто стек, в подходящем контексте. А когда в это лезут литературоведы, да еще и язык программирования переводить пытаются, то нафиг мне такое счастье, и с английским неплохо.

Вооот. Т.е. нормальные термины вполне себе существуют и ты даже сам их озвучил. Т.е. суть проблемы в том, что данный конкретный перевод почему-то делали криворукие специалисты. А не в самом факте идеи локализации подобного ПО.

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

Все эти термины и названия типа call stack, по сути — компьютерный жаргон. Смысла придумывать еще и русские переводы — нет никакого. Не так уж и много этих английских названий, запомнить для программиста — не вопрос. К тому же переводы частенько неоднозначные, кривые или все равно состоят из других англицизмов

Здравствуйте, alex_public, Вы писали:
_>Вооот. Т.е. нормальные термины вполне себе существуют и ты даже сам их озвучил. Т.е. суть проблемы в том, что данный конкретный перевод почему-то делали криворукие специалисты. А не в самом факте идеи локализации подобного ПО.

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

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

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, noone, Вы писали:
_>Собственно вы повторили в точности мою мысль, только своими словами. Задам вам простейший вопрос уже в вашей терминологии: а зачем ide читать "модель проекта"? Сборкой то в любом случае занимается не она, а сторонняя система сборки.

Я в прошлом посте на пол-страницы распинался, рассказывая зачем. Потому что в C++ нет исходных файлов, а есть зависящие от контекста единицы компиляции. Для того, чтобы понять что написано в этой конкретной единице, вы должны повторить все шаги системы сборки и получить на входе все нужные опции и такое же, как при сборке, расположение/содержание других файлов на диске. Существуют (полу)декларативные модели проекта, откуда это можно дешево вычитывать (см. VS, Xcode), но CMake к ним не относится, его приходится заставлять такую модель генерировать (см. загадочная папка).

_>Я вроде бы достаточно чётко описал реализацию этого простейшего движения (собственно оно имеется во всех конкурирующих IDE). Это возможность запуска произвольной команды (а будет это make/nmake/waf/scons или вообще bat файл решает пользователь в простейшей настройке) по нажатию кнопки build в IDE. В таком случае будут одинаково отлично работать и студенческая поделка и проект с километровым конфигом в CMakeLists.txt.

Это программы будут отлично собираться и работать. А IDE работать не будет, потому что нужных настроек компиляции и правильного окружения у нее нет.

_>Что касается настроек, необходимых для работы анализатора кода, то это совсем другой вопрос. Настройка там всегда одинаковая, тривиальная (всего то пара опций) и во всех нормальных IDE делается за пару минут, в том числе и под несколько конфигураций. Я это делал не раз и в разных IDE. И никаких сложностей не встречал.

Возможно, что у вас в программе пара опций. Это очень хорошо, вы легко напишете двухстрочный CMakeLists.txt и вот вам паллиатив до момента поддержки более удобных для вас моделей. Но CLion должен поддерживать все корректно настроенные проекты, и показывать при этом что-то более осмысленное, чем редактор с подсветкой текста. Вы предлагаете разработчикам LLVM переписать все опции под все платформы в удобном для IDE виде, а потом поддерживать одно и то же в двух разных местах? Возьмите упоминавшийся проект http://www.itk.org/ и сформулируйте "пару опций", которые для каждой единицы компиляции эквивалентны тем, что получаются у CMake сейчас. Плюс позволяют как-то легко сгенерировать необходимые файлы из имеющихся болванок. Для 4-х платформ — Win 64, OS X 32, OS X 64, Linux 32 (всякие IRIX и AIX пока пропустим), и двух фронтендов — GCC, Clang.

_>Ну так и настройки анализатора кода нужны только CLion — вот там им и самое место.

Настройки анализатора кода ("отслеживать неприсвоенные переменные или забить", "искать бесконечные циклы или забить" и т.п.) как раз в .idea и хранятся. А настройки компиляции и окружения, без которых до анализа кода дело не дойдет, хранятся в CMakeLists.txt, где их все равно уже пишет и поддерживает автор программы. При открытии проекта они распаковываются с помощью CMake во временную папку в относительно удобоваримом для CLion виде.

Здравствуйте, Ops, Вы писали:

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

Ну это скорее такое следствие особенностей развития в 90-ые годы. )))

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

Кстати, вообще говоря на нашей планете есть всего 3 языка, которые обладают полным набором необходимой терминологии для всей современной науки и инженерного дела. В других языках просто нет нужных понятий. Т.е. если учиться не на одном из них, то просто физически невозможно стать специалистом высшего уровня. Так вот русский — это один из этих трёх. И очень не хотелось бы, чтобы благодаря халтурной работе наших компьютерщиков (это я не про тебя, а про тех, кто делает сомнительные переводы или же использует англицизмы на каждом шагу) таких языков стало бы только два... Хотя я уже вижу что такого не будет — маятник "моды" уже некоторое время назад как пошёл в обратную сторону. )

Здравствуйте, noone, Вы писали:

N>Я в прошлом посте на пол-страницы распинался, рассказывая зачем. Потому что в C++ нет исходных файлов, а есть зависящие от контекста единицы компиляции. Для того, чтобы понять что написано в этой конкретной единице, вы должны повторить все шаги системы сборки и получить на входе все нужные опции и такое же, как при сборке, расположение/содержание других файлов на диске. Существуют (полу)декларативные модели проекта, откуда это можно дешево вычитывать (см. VS, Xcode), но CMake к ним не относится, его приходится заставлять такую модель генерировать (см. загадочная папка).

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

N>Это программы будут отлично собираться и работать. А IDE работать не будет, потому что нужных настроек компиляции и правильного окружения у нее нет.

И что мешает настроить это в окошке IDE? Как собственно и реализовано во всех конкурентах CLion? )

N>Возможно, что у вас в программе пара опций. Это очень хорошо, вы легко напишете двухстрочный CMakeLists.txt и вот вам паллиатив до момента поддержки более удобных для вас моделей. Но CLion должен поддерживать все корректно настроенные проекты, и показывать при этом что-то более осмысленное, чем редактор с подсветкой текста. Вы предлагаете разработчикам LLVM переписать все опции под все платформы в удобном для IDE виде, а потом поддерживать одно и то же в двух разных местах? Возьмите упоминавшийся проект http://www.itk.org/ и сформулируйте "пару опций", которые для каждой единицы компиляции эквивалентны тем, что получаются у CMake сейчас. Плюс позволяют как-то легко сгенерировать необходимые файлы из имеющихся болванок. Для 4-х платформ — Win 64, OS X 32, OS X 64, Linux 32 (всякие IRIX и AIX пока пропустим), и двух фронтендов — GCC, Clang.

Ещё раз: у вас общетеоретические рассуждения, почему это не может работать (а вы хоть пробовали?), а у меня конкретная практика перед глазами. Причём на проекте использующем тяжёлые кроссплатформенные (т.е. куча этих самых ifdef в них) библиотеки типа boost, wxWidgets, OpenCV и имеющим много разных конфигураций сборки. Да, и кстати собирающимся под кучу разных платформ (правда это никак не пересекается с конфигурациями — каждая из них собирается везде). Так вот в Netbeans анализатор кода превосходно всё видит и для этого потребовалась всего несколько минут на его настройку (те самые указания каталогов заголовочных файлов и директив препроцессора). Более того, до этого у меня не было проблем с аналогичным в Eclipse, а до этого в VisualStudio. Почему-то во всех приличных IDE есть такие настройки. Наверное потому, что они не предназначены для "серьёзных" проектов?

N>Настройки анализатора кода ("отслеживать неприсвоенные переменные или забить", "искать бесконечные циклы или забить" и т.п.) как раз в .idea и хранятся. А настройки компиляции и окружения, без которых до анализа кода дело не дойдет, хранятся в CMakeLists.txt, где их все равно уже пишет и поддерживает автор программы. При открытии проекта они распаковываются с помощью CMake во временную папку в относительно удобоваримом для CLion виде.

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

весь тред не читал, может быть уже и ответили.
вопрос в том, почему в линуксе один и тот же шрифт который в kate и qtcreator выглядит превосходно, в Clion — просто вырвиглазие?!
какие шрифты не пробовал — все вырвиглазные.

чо делать-то?

ping?