LINUX.ORG.RU

Ричард Столлман хочет видеть некоторые возможности Eclipse реализованными в Emacs

 , ,


1

0

В воскресном письме в список рассылки emacs-devel, Ричард Столлман сообщил о своих впечатлениях от знакомства со средой разработки Eclipse. Некоторые свойства Eclipse Ричард хотел бы увидеть реализованными в Emacs:

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

>>> Подробности

anonymous

Проверено: Shaman007 ()

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

> Мы под реверс-инженирингом понимаем одно и тоже? Анализ и декомпозицию исполняемого (байт)кода? Или подразумевалось "чтение исходников"?

Я второе понимал (в данной дискуссии). И, полагаю, не я один.

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

> в Emacs его изначально тоже нет, а через плагин он (вроде бы) есть и для Eclipse.

Я скорее про M-x, который в Имаксе есть всегда.

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

> Да путь подумают хотя бы о template

А-а-а!!! Не надо вот этого, а?!!

С уважением, Лёша, второй день описывающий грамматику в терминах boost::spirit

P.S. А CDT в разборе выхлопа из-под g++, выматерившегося на несоответствие типов в spirit-centric коде, не помогает, а скорее даже мешает, т.к. не умеет по-человечьи парсить g++'ный выхлоп. Впрочем, "по-человечьи" для g++'ного выхлопа - это в корне не верно, там как раз нечеловечий выхлоп... Впрочем, не будем о грустном, мир и так полон скорби...

AlexM ★★★★★
()

Товарищи! Стране нужен МЕТАН. :)

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

> Вспоминаю тут чью-то историю с отлавливанием бага, из-за которого программа работала в Debug и крашилась в Release. Баг был отловлен параллельной пошаговой отладкой -00 и -O3 версии программы - это бы выход за границу массива, который проявлялся на девятом уровне вложенности. Программист получил премию в 50K $ за нахождение корня проблемы.

Слово называется valgrind? Нет, возможно, Вы удивитесь, но вот такие ошибки он отлавливает на ура.

P.S. Правда, премию в 50K баков мне за такое никогда не платили. Наверное, недостаточно хорошо изображал моральные и физические мучения в процессе ;-)

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

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

На самом деле, конечно, "выход за границу массива" - это какой-то привет из 70х. Нонче ошибки уже куда как неуловимее и больнее ;-)

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

> но выход за границу случается и сейчас, к сожалению

Особенно забавно смотреть на сегфолт на команде prefetchnta, когда она по спеку никаких сегфолтов не генерит. Ан нет, кое-где генерит... ;)

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

>как был UNIX-way так он и остаётся им. Это в MS каждый год революция.

Вы, кстати, заметили, что MS в ходе этих эволюционных революций все больше и больше напоминает Unix? :-) А Java, между прочим, С++...

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

>Мало чем поможет, если баг вызван определённой последовательностью данных, пришедшими по сети, и хорошо размазанными по времени :)

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

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

> Для особо упертых я привел выше определение отладки. Какое у вас определение?

Найденное в википедии? При отладке неприменным инструментом является отладчик, уж простите за тавтологию. У Вас же тестирование.

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

> При отладке неприменным инструментом является отладчик

Это не так. Для некоторых вещей отладчиков просто нет. Что, пока для ядра Линукс не появился отладчик, оно не отлаживалось?

> У Вас же тестирование.

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

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

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

А для этого потребуется обложиться кучей книг по elisp, man'a-ми, и и статьями про emacs и.т.д. Сколько времени на это уйдет?

> А для внесения изменений в Eclipse прийдется обложиться кучей книг по Яве и разгребать серсы плагинов с их фреймворками и ооп нагромождениями.

Это если только внести изменения в существующий плагин, который, кстати совсем просто написать. Для нового, достаточно одной книги: "Расширения Eclipse. Принципы, шаблоны и подключаемые модули".

Да и не надо это в большинстве случаев. А вот в Emacs постоянно приходится что-то прикручивать самому, что "искаропки" есть в Eclipse.

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

> Трудно провести между отладкой и тестированием четкую грань.

Согласен, грань размыта (что подтвержтает ваша предыдущая фраза). И тем не менее, во фразе "unit testing" присутствует слово "testing".

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

> С уважением, Лёша, второй день описывающий грамматику в терминах boost::spirit

А вы stl используйте, и ждите C++ox без тех извращений что сейчас есть в boost. И будет счастье, но я имел в виду: std::cout << anything;

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

> В Eclipse встроен компилятор Java. А парсер CDT недалеко ушел от front-end компилятора.

1) Не надо смешивать синтаксический анализ и компиляцию.

2) CDT за каких-нибудь 5 лет прошел путь, который другие средства не осилили за 10-15 лет и продолжает развиваться (надеюсь в ближайшие 1-2 года в нем появится такой же Quick Fix, как и у JDT).

PS

Пожалуй единственный недостаток Eclipse - это выбор статически типизированного языка в качестве основного средства разработки. Emacs в этом смысле гораздо практичнее, но его концепция интерфейса проигрывает Eclipse (о чем собственно и задумался Столлман). Взяв современный CommonLisp с его CLOS, CELLS и прочими наработками реально создать совершенно термоядерную среду.

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

> Найденное в википедии? При отладке неприменным инструментом является отладчик, уж простите за тавтологию. У Вас же тестирование.

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

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

>> В Eclipse встроен компилятор Java. А парсер CDT недалеко ушел от front-end компилятора.

> 1) Не надо смешивать синтаксический анализ и компиляцию.

Я не смешиваю. У компилятора есть функции (оптимизация, генерация машинного кода), которые просто не нужны для "понимания" исходника. Парсер CDT строит не только AST, он называется "парсер", но является чем-то большим.

> 2) CDT за каких-нибудь 5 лет прошел путь, который другие средства не осилили за 10-15 лет и продолжает развиваться

Это да. Ждем CDT 5.0

> Пожалуй единственный недостаток Eclipse - это выбор статически типизированного языка в качестве основного средства разработки

.oO( не пофлеймить ли о том, что для больших проектов статика рулит, а динамика сосет? )

> Взяв современный CommonLisp с его CLOS, CELLS и прочими наработками реально создать совершенно термоядерную среду.

Ну так на JVM есть несколько Лиспов.

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

> Emacs в этом смысле гораздо практичнее, но его концепция интерфейса проигрывает Eclipse

Поподробнее про концепцию можно? Я всегда думал что именно у Emacs, единственного IDE есть эта концепция, а именно унификация правил интерфейса без модальных окон и прочих выдумок Xerox.

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

> А для этого потребуется обложиться кучей книг по elisp, man'a-ми, и и статьями про emacs и.т.д. Сколько времени на это уйдет?

"Ах как бы так сделать чтобы ничего не делать но чтобы при этом всё делалось?"

Кухарка должна управлять ... (c)

Может мышкой программировать?

Вообще-то все IDE были написаны адкватными людьми, к вам это видимо не относится.

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

> Речь шла об ООП. На прологе же пишут knowledge-based системы, и выбор там между Прологом, и, скажем, CLIPS и OPS5. Где там переработка архитектуры - мне неведомо.

Ага расскажите это тем что erlang двигают. :-D

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

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

+1024. google delta debugging

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

> Ага расскажите это тем что erlang двигают. :-D

Причем Erlang к Прологу?

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

> Нет, это _использование_ объектных библиотек. Код вида:

> #include <iostream>

> void main() { for(int i=0;i<5;i++) std::cout << i; }

> процедурный, хоть и использует объект iostream.

А у меня код объектный. ООП может быть тонкостью реализации. Я же не говорю - обязан.

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

> по этому определению Emacs это IDE похлеще других - много ли IDE имеет такой же список поддерживаемых систем контроля версий как Emacs? это например? или список поддерживаемых отладчиков?

OK. Пусть будет IDE - дальше что? :)

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

> Давайте теперь попробуем найти хотя бы одно решение из реального мира, где бы не было завязки на язык?

Из свеженького - Hibernate (два языка), Lucene (десяток языков).

> Если удастся - надо понять какие плюсы получили авторы решения и какие минусы.

Какие плюсы понятно - более широкую область применения. На счёт минусов не знаю - в разработке не участвовал.

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

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

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

> с его помощью вам тяжело клепать блоатваре

не надо грязи - с помощью Emacs замечательно клепается блоатваре :D

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

> не надо грязи - с помощью Emacs замечательно клепается блоатваре :D

Так вот он, корень всех проблем! Запретить поганый Емакс и насильно пересадить их на пресвятой Эклипс, и сразу мировой коммунизм наступит!

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

>> не надо грязи - с помощью Emacs замечательно клепается блоатваре :D

> Так вот он, корень всех проблем!

Если тебе будет легче, скажу - с помощью Eclipse оно тоже клепается неплохо :)

> Запретить поганый Емакс и насильно пересадить их на пресвятой Эклипс

Ты увидел свет, брат!

:D

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

>> Ты увидел свет, брат! :D

> Да. И явился ко мне святой IGNUcius и сказал, что выход из Church of Emacs только посмертно.

Какой-то не тот свет ты увидел, ей-ей :)

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

> Кухарка должна управлять ... (c)

> Может мышкой программировать?

> Вообще-то все IDE были написаны адкватными людьми, к вам это видимо не относится.

Что здесь имелось ввиду я так и не понял.

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

> я просто не понимаю, в чем ваши претензии к емаксу

Много у меня было претензий к емаксу? Тред пошёл от того, что в Eclipse есть UML, а в емаксе его нету, ну потом и понеслось на тему кто такой отладчик.

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

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

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

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

Bloatware клепать можно на чем угодно, в.т.ч и на Emacs.

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

> http://cedet.sourceforge.net/cogre2.jpg - вполне себе UML, хоть и не такой красивый

Шикарный пример самой главной проблемы Emacs. Как я говорил, наследие 20-летней давности мешает нормально развивать программу.

Впрочем, это и не нужно. Для любителей "покастамизировать" под себя, есть jEdit.

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

> что в вашем понимании нормально развивать? обвешивать побрякушками?

Пользоваться всеми преимуществами графического интерфейса (в данном случае).

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

> Шикарный пример самой главной проблемы Emacs. Как я говорил, наследие 20-летней давности мешает нормально развивать программу.

Сильно подозреваю, что это не проблема - если я нарисую UML диаграммку в Eclipse, она прочитается в emacs, ибо стандарт. Другое дело, что в эклипсе или в Ubrello у меня на экран влезет больше графов. Но это зависит от разрешения экрана :D

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

да я видимо пропустил это обсуждение. а вообще это нашлось первой ссылкой при поиске emacs uml

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

> Сначала попробуйте jEdit, потом комментируйте.

Сначала попробуйте Emacs, потом комментируйте

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