Представлена первая версия проекта LinuxTools — IDE для C/C++, основанной на Eclipse CDT

Фишка в том, что достаточно часто emacs/vim + плугины + руки перекрывают по функциональности и расширяемости тот же эклипс, сохраняя при этом достаточно умеренное потребление ресурсов.

> Нет. Редакторы ни во что не превратятся. Но, если редактор научится _нормально использовать_ эту утилиту (что само по себе будет нетривиальным процессом), то сумма редактора и утилиты будет IDE.

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

>> Нет. Редакторы ни во что не превратятся. Но, если редактор научится _нормально использовать_ эту утилиту (что само по себе будет нетривиальным процессом), то сумма редактора и утилиты будет IDE.

> С какой стороны посмотреть.

С любой.

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

Доведение идеи до абсурда - мощный полемический прием, я тоже так умею ;) IDE на самом деле является ЦП, ибо это он интегрирует все программы . Ну как? %)

> После старта она и у меня ~100М. Потом распухает до 200-300M (причем это на Java 6, на Java 5 было гораздо больше).

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

>> После старта она и у меня ~100М. Потом распухает до 200-300M (причем это на Java 6, на Java 5 было гораздо больше).

> Так а что там должно распухать?

ХЗ. Вот запустил сборку - стало 150М. Если поработать так, чтобы включился индексатор, автодополнение и прочее - распухнет и больше.

> Может быть дело в том, что у меня питоновский проект?

Может быть. PyDev относительно тупой, у меня смешанный Си/Питон проект.

>Также планируется рассмотрение идеи включения Eclipse

Включено.

> Доведение идеи до абсурда - мощный полемический прием, я тоже так умею ;) IDE на самом деле является ЦП, ибо это он интегрирует все программы . Ну как? %)

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

Кто в этом случае является IDE? :) Почти вся функциональность в этой "утилите" с CLI, с пользователем общается текстовый редактор, интегрирует вообще лично Linux. %)

Заметь, я про объем кода ничего не говорю. Я говорю про монструозность в отношении как раз таки функционала. Ведь основной тезис в ругани IDE - это то, что IDE по определению комбайн, а это плохо, не Unix-way etc.

Emacs - даст фору любому другому комбайну по монструозности. Не даром же шутят, что Emacs как отдельная перационная система. =) Почему вы не ругаете его? Он же самый настоящие не Unix-way!

В самодельности ничего плохого нет. И как правило создание собственной IDE на основе Emacs или Vim означает хорошее понимание человеком принципов систем сборок, etc. Это хорошо. Но это явно не единственный путь.

Иногда хочется сосредоточиться на задаче и не думать о средстве вообще. IDE это позволяет легко делать. Причем использование IDE совсем не означает, что люди полностью полагаются на ее возможности. У нас например написаны свои ant-скрипты для сборки. Это удобно, потому что много проектов, все еще к тому же завязано на SVN. IDE бы не справилась. Но тем не менее мы все равно используем Intelli JIdea.

>Окей, вот вам инженерная задача: нужно на 30% сократить объём сгенерированного кода (не влазит в флеш). Как вам поможет фолдинг в IDE?

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

Вот вам инженерная задача: Показать начальнику/заказчику общюю структуру классов и иерархию наследования в визуальном виде, со связями между объектами, с помощью VI/EMACS.

Задача два: отладить некорректный алгоритм расчета CRC-16 в VI.

Да, можно еще проще пример привести.

Было дело мне дали чужой код. Порядка 50 жутких классов. Надо было понять как работает и переписать. И вот, блин как эту кучу разгребать в Vim?

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

> Клиентский редактор только получает нажатия клавиш от пользователя, передаёт соответствующие команды и показывает пользователю результат.

>Кто в этом случае является IDE? :)

Сумма редактора и утилиты, как я уже говорил. Ибо именно редактор интегрирует инструменты (тот же VC, например).

> интегрирует вообще лично Linux. %)

Ну я вижу, мы продвигаемся к идее о том, что настоящая IDE - это ЦП :)

ctags?

> Вот вам инженерная задача: Показать начальнику/заказчику общюю структуру классов и иерархию наследования в визуальном виде, со связями между объектами, с помощью VI/EMACS.

При чём тут vi/emacs? для этого специальные средства есть. vi/emacs же не предназначены для того чтобы кодить, не вылазя из них.

Наприер, dil (http://code.google.com/p/dil/) умеет после компиляции писать иерархию классов в формате dot. То же самое можно тривиально сделать с помощью exuberant ctags для любого поддерживаемого им языка.

>для этого специальные средства есть

О том и реч, что вместо того чтобы решать задачи, все время надо переключаться с инструмента на инструмент. Unix-way хорош, спору нет, но все надо в меру, а то вместо echo будет команда printsymbol.

> Оптимизируем пометодно. Просмотренный метод сворачиваем. Пользуемся правилом: Все что видием еще не просмотрено и не оптимизировано. Появляется возможность оптимизации с любового места в исходнике а не сверху вниз.

Это ерунда какая-то, а не методология минимизации кода.

> Вот вам инженерная задача: Показать начальнику/заказчику общюю структуру классов и иерархию наследования в визуальном виде, со связями между объектами, с помощью VI/EMACS.

Это не инженерная задача. Техническую документацию на проект генерирую доксидженом.

> Задача два: отладить некорректный алгоритм расчета CRC-16 в VI.

Я просмотром кода такое способен отлаживать :-P

>> Задача два: отладить некорректный алгоритм расчета CRC-16 в VI.

>Я просмотром кода такое способен отлаживать :-P

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

>KDevelop - разработка под KDE (kdelibs) а не под чистый Qt.
Эээ 4.2 как бы, сейчас на Kdevelop'е под чистый Qt4 пишу не юзая Kdelibs, судя по всему автор этого заявления не слишком понимает процесс программирования :)

а почему еще не началась война Eclips vs NetBeans? это же два грандиозных комбайна

/me пойду-ка скачаю vim :D

> а почему еще не началась война Eclips vs NetBeans? это же два грандиозных комбайна

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

>Eclips vs NetBeans

if ((Eclips + NetBeans + VS + CodeBlocks + Kdevelop) == vim)

>/me пойду-ка скачаю vim :D;

лучше gtags, правда он меньше языков поддерживает чем ctags, но значительно быстрее

>Сколько гигабайт памяти надо для использования? 8 или 16?

Хватает одного.

> Вот вам инженерная задача: Показать начальнику/заказчику общюю структуру классов и иерархию наследования в визуальном виде, со связями между объектами, с помощью VI/EMACS.

вот например, http://fotki.yandex.ru/users/ottalex/view/146170 - это делает cogre, на основании информации от semantic. хочется изобразить по другому - дописываешь кусочек кода на elisp (не покидая среды разработки), и оно у тебя может быть представлено так, как ты захочешь...

>тормоз в линейке аля JAVA

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

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

Ну сама ява, может быть, и не виновата в плохих явовых программистах, но вот программисты на яве пишут плохие, медленные, жадные до памяти программы.

> 5)Визуальное проектирование морд Форм (как бы это не любили, это удобно)

Скорее неудобно. Как только начинаются ФОРМЫ.

>вот например, http://fotki.yandex.ru/users/ottalex/view/146170 - это делает cogre, на основании информации от semantic. хочется изобразить по другому - дописываешь кусочек кода на elisp (не покидая среды разработки), и оно у тебя может быть представлено так, как ты захочешь...

Потом кликаешь мышей по методу в классе -> переходишь на source code -> возвращаешься, скрываешь некоторые несущественные классы, сурывавешь несущественное в существенных классах, растаскиваешь так как хочется...

Да?

PS: сам UML не пользую и другим не рекомендую:)

> Отличная вещь для изучения С. Есть еще netbeans bundle for C. Хорошо ведь. Можно документацию сразу читать. Автозаполнение опять же и так далее.

OMG.

> Вот вам инженерная задача: Показать начальнику/заказчику общюю структуру классов и иерархию наследования в визуальном виде, со связями между объектами, с помощью VI/EMACS.

Освой doxygen и смени ник.

переход на source code - работает, несущественные класы - ради бога, удаляй со схемы.

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

> Как минимум 90% программирования - это обдумывание реализации в голове.

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

>> 3)Визуализация структуры проекта + поиск по проекту

>doxygen + *scope на этапе знакомства с уже существующим кодом. Ну допустим.

А что есть вменяемый "*scope" для C++? Можно найти все места, откуда вызывается определенная функция? Ведь нужен же полный разбор исходников, никакие регэкспы и grep не работают. У CDT уже очень неплохой С++ front-end, на моих проектах очень шустро работает и почти не ошибается:

Indexed <project> (376 sources, 369 headers) in 15,91 sec: 74 368 declarations; 242 295 references; 0 unresolved inclusions; 3 syntax errors; 1 998 unresolved names (0,63%)

т.е. более чем 99% кода разобрано правильно за ~16 сек с нуля. А при правке одного файла происходит инкрементальный переразбор нового кода, это вообще практически мгновенно.

Единственное, чего мне не хватает в Eclipse после Emacs - макросы.

> Можно найти все места, откуда вызывается определенная функция?

http://alexott-ru.blogspot.com/2008/12/cedet.html, ну и вообще - http://alexott-ru.blogspot.com/search/label/cedet

> Можно найти все места, откуда вызывается определенная функция?

Эти места вообще-то найти невозможно. Подсказка: указатели на функции, теорема Тьюринга-Чёрча.

> Окей, вот вам инженерная задача: нужно на 30% сократить объём сгенерированного кода

И как это согласуется с вашим же "Использование той или иной IDE никак не сказывает на скорости разработки"?

Сравниваем скорость и объем сгенерированного кода? Теплое с мягким?

> Или Вы считаете, что анализировать код и упрощать навигацию по нему умеет только еклипс?

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

И о чем тогда спор?

не стоИт у меня на еклипс
ну тяжелый он какой-то

> /me пойду-ка скачаю vim :D

<boremode>
kyxap пойду-ка скачаю vim :D

После /me нужно в третьем лице себя упоминать:
/me пошёл качать vim
</boremode>

>> Можно найти все места, откуда вызывается определенная функция?

> Эти места вообще-то найти невозможно. Подсказка: указатели на функции, теорема Тьюринга-Чёрча.

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

Указатели на функции в C++ - виртуальные функции, поэтому вызовы виртуальных функций также учитываются при поиске (что в CDT, что в Xref). А так, конечно, можно и мусор загрузить в память и управление передать, авось и нашу функцию вызовет...

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

> Indexed <project> (376 sources, 369 headers) in 15,91 sec: 74 368 declarations; 242 295 references; 0 unresolved inclusions; 3 syntax errors; 1 998 unresolved names (0,63%)

wc -m на этих исходниках что показывает? Хочу сравнить быстродействие с другой парсилкой.

>> Можно найти все места, откуда вызывается определенная функция?

> http://alexott-ru.blogspot.com/2008/12/cedet.html, ну и вообще - http://alexott-ru.blogspot.com/search/label/cedet

И как оно, вызовы через boost::shared_ptr уже умеет находить: http://pic.ipicture.ru/uploads/090218/LBPALWlFCo.png ? Насколько надежно работает?

> Если текстовый редактор начинает уметь делать подсветку синтаксиса, анализировать код, упращять навигацию, делать автокомлпишин, ... то он превращается в IDE.

Это всё относится к одной задаче - редактированию текста. Текстовый редактор, позволяющий не только редактировать текст но и дающий подсказки, основываясь на типе файла, и вообще всячески помогающий пользователю в *редактировании текста*, ещё не становится IDE.

Почитайте где-нибудь определение IDE. В википедии на крайний случай.

проект называется gnu global, пакет в дебиане называется global

у меня находит

> Почитайте где-нибудь определение IDE. В википедии на крайний случай.

An IDE normally consists of a:

* Source code editor
* Compiler and/or interpreter
* Build automation tools
* Debugger

И чего не хватает до IDE, даже в твоем примере?

>> Indexed <project> (376 sources, 369 headers) in 15,91 sec: 74 368 declarations; 242 295 references; 0 unresolved inclusions; 3 syntax errors; 1 998 unresolved names (0,63%)

> wc -m на этих исходниках что показывает? Хочу сравнить быстродействие с другой парсилкой.

На исходниках самого проекта получилось вот так (для wc -cwl):

characters: 4510046

words: 409174

lines: 130828

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

Есть. Отличная штука только вот:

"Global find the locations of specified object in C, C++, Yacc, Java, PHP and Assembly source files."

Множество поддерживаемых им и используемых мной языков не пересекается. :( Судя по исходникам они написали парсер для 6 языков сразу. Расширяемость нулевая. (Буду рад ошибаться)

> И чего не хватает до IDE, даже в твоем примере?
В моём примере та разрабатываемая утилита + vim образуют IDE если их рассматривать как единое целое, но мой ответ был направлен Korwin'у:

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

>И как оно, вызовы через boost::shared_ptr уже умеет находить?

Нет, ну реально с ЛОРом что-то не то творится....

Новость про C++, уже упомянут boost, уже нехило комментариев накидали --- а плюсосрач до сих пор не начался. Неужели мы потеряли главное действующее лицо? о_О

>> 6)Если повезет, то интеграция с системой контроля версий

>Да, с одной. SVN.

4.2
Смотреть youtube://Linus Torvalds on git до посинения.
Юзаю git для всех проектов. Раньше было SVN, но потом увидел, что оно тормозное и малофункциональное.