SlickEdit 2007

>3. С тэгами основной недостаток - невозможность инкрементального обновления. Если у вас 1 TAGS на все ядро, то после (порой довольно незначительных) изменений одного файла тэги (в пределах этого файла) становятся неправильными. А чтоб их поправить, надо перегенерировать весь TAGS, т.е. опять индексировать все ядро. Устраняет ли SE указанную проблему ?

SE может иметь любое количество подключенных tag-файлов. Например можно проиндексировать ядро не целиком а частями (по подсистемам). Если всё ядро затащено как проект то tag-файл(ы) для воркспейса обновляются по мере внесения в них изменений. Ну или есть еще группа тег-файлов auto-updated

Про скорости точно не скажу - с секундомером не сравнивал...

на самом деле у SE есть еще один серьёзный плюс. в него встроена DiffZilla которая позволяет сравнивать каталоги рекурсивно, она находит раpличающиеся файлы, и прямо в ней можно вносить изменения.

я сравнивал изменения внесённые в ядро OpenSolaris за пол года (~80 мб) она ето делала с приемлимой скоростью, а аналога под линукс я просто не знаю.

может кто ткнёт меня носом в аналог, если он есть ?

>1. За вычетом рефакторинга, что я могу интересного сделать с SE, что ну никак (или очень геморройно) сделать с ctags + vi/emacs ?

Я не настолько много работал с vim/emacs и особенно с их плагинами чтобы сказать что в них есть а чтего нет по сравнению с SE (с ним работаю с 1998 года) 

Ну например SE позволяет просканировать файл на все входящие в него директивы препроцессора и вручную указать какие #define определены
а потом "свернуть" неиспользуемые куски типа ...
#ifdef _XXX_
....
#endif // _XXX_
 есть ли такое в vim/emacs я ХЗ

А просто перечислять все фичи подряд очень долго ;)

> Прикинь, чтобы вырезать 8-ю колонку (к примеру) из такого файла и сложить её в отдельный файл будет быстрее сделать в SE чем писать и отлаживать скрипт. Пока ты новый файл открываешь и cut blah-blah-blah в нём наберёшь я уже буду с новым файлом работать ;)

Альтернативно-одаренных, открывающих многогигабайтные файлы в WISIWIG-редакторах следует немножко убивать :)

>Альтернативно-одаренных, открывающих многогигабайтные файлы в WISIWIG-редакторах следует немножко убивать :)

В чём-чём открывать ? ;) Ты таки внимательней задачу прочитай.

Тя бы нужно заставить посчитать к примеру локального Рейнольдса в ткнутой наугад заказчиком точке "альтернативным" способом ;)

Само то вычисление это перемножить и поделить 3 цифры ... токо ты их замучаешся искать в 3Гб файле - "альтернативным" способом ;)

так народ который тут говорит что slickedit нафиг не нужен

вы вот скажите что использовать вместо него и так чтоб был и под win и под linux для C++ ?

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

да еще вменяемый отладчик в стиле slickedit, vs2005

gdb не приводить

вабще то SE сам gdb использует...

> вы вот скажите что использовать вместо него и так чтоб был и под win и под linux для C++ ?

Не поверишь, но emacs/vim :)

Мэстные пиарщики SE тут мне напоминают виндузятников, освоивших FAR: они уже свысока смотрят на остальное "ламерье", возящее мышку в проводниках. Они изо всех сил и крайне энергично доказывают, что FAR - это вершина достижений человеческой мысли и ничего, кроме него в жизни не нужно. Но они не понимают людей, добровольно отказавшихся от него и перешидших (о ужас!) даже вообще в другую систему. Они днюют и ночуют в форуме, разными идиотскими примерами и высказываниями пытаясь вызвать гуру на откровенность: "как, зачем?!"

Если у кого-то возникает необходимость искать 2-3 цифры в многогигабайтном файле, да еще без точного (формального!) признака, где они находятся - увы, ребятки, вы профессией ошиблись. Вам - в поэты. Говорю это как человек, у которого 50-100 Мб выходных текстовых файлов - рутина. Да не простых "столбцов", а сложных, многосекционных, гетерогенных.

> Они изо всех сил и крайне энергично доказывают, что FAR - это вершина достижений человеческой мысли и ничего, кроме него в жизни не нужно.

Это доказывает, что FAR не нужен? Или что он бесполезен?

> Если у кого-то возникает необходимость искать 2-3 цифры в многогигабайтном файле, да еще без точного (формального!) признака, где они находятся - увы, ребятки, вы профессией ошиблись.

То есть заказчик sS ошибся профессией?

> Это доказывает, что FAR не нужен? Или что он бесполезен?

именно так, far - не нужен. Причем немалой толике людей, не использующих windows :)

> То есть заказчик sS ошибся профессией?

Исполнитель sS ошибся профессией.

> именно так, far - не нужен.

Интересная логика: если программу хвалят - значит, она не нужна. Здесь хвалят Линукс :)

>> То есть заказчик sS ошибся профессией?

>Исполнитель sS ошибся профессией.

Тоже интересная логика. Столько людей ошиблись профессией и не знали, пока ты им не сказал... а ведь жили, работали, и работа им нравилась... как жить дальше... :'-(

Это про ручное применение изменений? ediff в emacs, kompare в kde

> Интересная логика: если программу хвалят - значит, она не нужна. Здесь хвалят Линукс :)

Интересную Вы логику используете :) Моя логика была такова: как бы ни была хороша программа с чьей-то точки зрения, найдутся условия, когда все ее достоинства будут нивелированы. И SE, несомненно, выглядящий неплохо на фоне инструметов программирования для леммингов, ничем особым не выделен в среде, где традиции программирования наследуются уже около 40 лет. Здесь методом естественного отбора сформировались приемы и инструменты _другие_, с другими требованиями к мастеру, пользующемуся этим инструментом. И SE смотрится как дикообраз среди морских свинок :)

> Тоже интересная логика. Столько людей ошиблись профессией и не знали, пока ты им не сказал... а ведь жили, работали, и работа им нравилась... как жить дальше... :'-(

Да так же, как и жили. "Нравится", "как-то живут" и т.д. - это все отмазки для непрофессионалов :) А раз они такие, то вес их мнения, хм, не самый большой, скажем.

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

И как всегда: nothing personal :)

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

> так народ который тут говорит что slickedit нафиг не нужен

> вы вот скажите что использовать вместо него и так чтоб был и под win и под linux для C++ ?

> да да в кривом проекте где приходится часто пользоваться поиском классов и их мемберов и приходится часто делать рефакторинг кода

Emacs + ECB + X-Refactory

> да еще вменяемый отладчик в стиле slickedit, vs2005

> gdb не приводить

emacs + gdb/mi.

А отладчик в vs2005 умеет отлаживать код, отличный от виндозного?

> вабще то SE сам gdb использует...

Ну просто нравится человеку, как выглядит SE, и не нравится, как выглядит Emacs. Разве это не понятно с самого начала было? ;)

> Здесь методом естественного отбора сформировались приемы и инструменты _другие_, с другими требованиями к мастеру, пользующемуся этим инструментом.

Ну просто тоска... _ВСЕ_ фичи SE представлены и в существующих образцово-классических инструментах Unix'а (emacs, vim). Но (по утверждениям) в SE они реализованы на порядок лучше.

> Если ты достиг просветления, то уж, по крайней мере, ты не будешь этого никому доказывать

Я и не пытался доказывать, что я чего-то там достиг. Я просто хотел обратить твое внимание, что если ветеран пргораммирования, с нехилым опытом работы в Линуксе, говорит о неком инструменте "это хороший инструмент", то это не повод заявлять, что он неправильно выбрал профессию. Поправь меня, если я ошибаюсь, но у тебя - другая профессия, на каком основании судишь?

> как всегда: nothing personal :)

Ну да, "увы, ребятки, вы профессией ошиблись" - это совершенно не personal :D

>Если у кого-то возникает необходимость искать 2-3 цифры в многогигабайтном файле, да еще без точного (формального!) признака, где они находятся - увы, ребятки, вы профессией ошиблись. Вам - в поэты. Говорю это как человек, у которого 50-100 Мб выходных текстовых файлов - рутина. Да не простых "столбцов", а сложных, многосекционных, гетерогенных.

Вы таки не поняли о чём идёт речь.

Речь идёт о _возможностях_ SE (подправить многомегабайтный файл 
причём сделать это ну очень быстро) а не о его профильном использовании. Непосредственно же для работы с выходными данными используется постпроцессор(ы) (tecplot,paraview, gnuplot) который тоже имеет такую же возможность (tecplot) но в _SE_ это можно сделать быстрее. К слову сказать возможности tecplot куда как более наворочены (это действительно в некотором роде "визивиг" редактор, только вы видите не колонки циферок а сразу визуализированную картинку и можете работать с ней как с неким набором данных,ассоциированных с вырезанным куском, который копируется/вставляется/экспортируется а в результате вы имеете точно такой же кусок ascii данных ) только иногда бывает быстрее залезть непосредственно в ascii данные чтобы быстренько получить нужные циферки. Это, так сказать,  пример "побочного" использования выдающихся возможностей SE как редактора.

Кстати формат вывода данных придумал не я а аффтары этих постпроцессоров коих кроме 3-х вашеназваных есть еще вагон и маленькая телега.


PS: 50-100Mb ascii файл это несерьёзно :)

ss@toshiba:/mnt/usb-storage/device-0/CSPM-2006/Results$ ls -gh *.plt
-rwxrwxr-x 1 users 555M 2006-09-04 14:01 CSPtest-4.plt
-rwxrwxr-x 1 users 244M 2006-09-04 13:29 CSPtest4.plt
-rwxrwxr-x 1 users 555M 2006-09-02 03:58 CSPtest-5.plt
-rwxrwxr-x 1 users 244M 2006-09-04 13:26 CSPtest5.plt
-rwxrwxr-x 1 users 555M 2006-09-11 23:19 CSPtest-6.plt
-rwxrwxr-x 1 users 244M 2006-09-12 14:13 CSPtest6.plt
-rwxrwxr-x 1 users 555M 2006-09-23 20:54 CSPtest-7.plt
-rwxrwxr-x 1 users 244M 2006-09-23 20:57 CSPtest7.plt
-rwxrwxr-x 1 users 404M 2007-03-17 01:59 test.plt

Это только "вырезки" избранных мест, которые пошли в отчёт ;)

>Исполнитель sS ошибся профессией.

И какая у меня интересно по вашему профессия ? ;)

>Если этого в емаксе нет, то можно легко написать. Само по себе сворачивание кусков кода есть.

В этом всё и дело. Всё по отдельности в разных продуктах есть. Есть даже более навороченные "изобразительные" возможности чем в SE. Просто в SE это в одном флаконе и от рождения.

плять читать то умеете, я говорил в стиле таком же

>вабще то SE сам gdb использует...

да вы что, а я и не знал блин -)

>Мэстные пиарщики SE тут мне напоминают виндузятников, освоивших FAR: они уже свысока смотрят на остальное "ламерье", возящее мышку в проводниках. Они изо всех сил и крайне энергично доказывают, что FAR - это вершина достижений человеческой мысли и ничего, кроме него в жизни не нужно. Но они не понимают людей, добровольно отказавшихся от него и перешидших (о ужас!) даже вообще в другую систему. Они днюют и ночуют в форуме, разными идиотскими примерами и высказываниями пытаясь вызвать гуру на откровенность: "как, зачем?!"

не смешите тапочки, "гуру"

ты читай лучше что emacs для С++ проектов больших мало применим, если только для lisp, да и то просирает полностью LispWorks

vim вообще для редактирования только конфигов и не более

>Если у кого-то возникает необходимость искать 2-3 цифры в многогигабайтном файле, да еще без точного (формального!) признака, где они находятся - увы, ребятки, вы профессией ошиблись. Вам - в поэты. Говорю это как человек, у которого 50-100 Мб выходных текстовых файлов - рутина. Да не простых "столбцов", а сложных, многосекционных, гетерогенных.

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

> Поправь меня, если я ошибаюсь, но у тебя - другая профессия, на каком основании судишь?

О, я ждал этого вопроса! :) Отвечу два раза: в шутку и всерьез. В шутку: а когда это на ЛОРе в теме про программирование выступали программисты, а в теме про Гном - гномеры? :) Нет, я не программист по профессии, скорее ближе к вычислительной математике.

А всерьез: видишь, ли, тайлганнер (не против, что на "ты"?), ты показался мне грамотным и рассудительным человеком. Так вот, скажи мне, разве это признак профессионала - уповать на "серебряную пулю" и верить в существование универсального средства или решения? Давай посмотрим на вещи шире: многообразие мира познается человеком с помощью, пожалуй, одного принципа, который можно сформулировать как "разделяй и властвуй". Он существует в культуре (в самом широком смысле этого слова - науке, технике) под множеством псевдонимов: "метод декомпозиции", процедурной и объектной парадигм, барьеров абстракции, аксиоматизации и абстрагирования, моделей и схем, формальных языков и многих других. Так вот, пресловутый unix-way - это он самый, все тоже тысячекратное отражение этого самого принципа - разделяй и влавствуй! Посему, "комбайны" - они представляют собой вершину и, одновременно, тупик развития. Образование комбайнов - естественный процесс, как образование концернов (монополий) в экономике. Но монополия в экономике - тупик, ибо она разрушается инновациями и борется с ними.

Вернемся опять-таки к шуткам: скажу даже больше, я SE в глаза не видел. Но то, как он функционирует (по мотивам, что мне тут "Рабинович напел") говорит о том, что он именно "комбайн", а значит - уже мертв :)

А что касается примеров с редактированием гигантских файлов - он был для меня знаковым в свое время. Выходные файлы с расчетов - часто бывают по 200-500 Мб. Я тоже по наивности сначала пытался вырезать из них нужную информацию инструментами типа mcedit и vim (а моя бывшая руководитель - в far'е). Не было тогда у меня SE :) Они были способны поставить комп на колени, но работу свою выполняли плохо (а был это 2002 год и 1Гб памяти на компе). Far так просто падал. И тогда я открыл для себя и grep с awk, и csplit.

ЗЫ. многое из написанного следует воспринимать как шутку

> не смешите тапочки, "гуру"

Если ты обижен, значит ты не прав, мой юный падаван :)

>да вы что, а я и не знал блин -)

в $VSLICKBIN загляни ;)

ls $VSLICKBIN/gbd прямо в SE-шной вкладке build ;)

так давайте определимся почему тогда emacs не комбайн?

> И какая у меня интересно по вашему профессия ? ;)

Скорее всего, менеджер. Только им по должности полагается потакать клиетам с идиотс^U, простите, плохо продуманными вопросами и желаниями :)

я шутил -)

спасибо конечно, но это знал с самого начала использования -)

> так давайте определимся почему тогда emacs не комбайн?

Потому, что в голом emacs'е ничего сделать нельзя :) Это ж только шкурка.

>Потому, что в голом emacs'е ничего сделать нельзя :) Это ж только шкурка.

так ну давайте уж тогд рассудительно

значит когда emacs нагружают всякими ecb+xrefactory(за который еще заплатишь 399$) уже не комбайн?

> скажи мне, разве это признак профессионала - уповать на "серебряную пулю" и верить в существование универсального средства или решения?

Нет (краснеет от сказанной банальности). Но sS и не уповает на SE как "на серебряную пулю". Посмотри на его посты - у них там используется куча инструментов.

> скажу даже больше, я SE в глаза не видел.

Я тоже :D

> Я тоже по наивности сначала пытался вырезать из них нужную информацию инструментами типа mcedit и vim

Аааа... понятно. Видишь ли, ты делал это по наивности, а он - осознанно. Он-то давно знает о awk и К. Прочитай внимательно его слова - что касается больших файлов с данными, в SE он делает one-off ad-hoc задачуб, автоматизировать которую невыгодно по трудозатратам. Для штатной работы - постпроцессоры (скриптованные, наверняка).

так и еще тогда получается что anjuta,kdevelop тоже для ламеров и те кто их делают 3.14здюки, так получается?

> значит когда emacs нагружают всякими ecb+xrefactory(за который еще заплатишь 399$) уже не комбайн?

Нет, конечно. Ибо этого можно не делать. А можно поставить auctex+reftex и превратить emacs в удобнейший редактор статей, для чего я его и использую :)

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

> Нет (краснеет от сказанной банальности)

Не все очевидное - осознано и опробовано на прочность :)

> Аааа... понятно. Видишь ли, ты делал это по наивности, а он - осознанно. Он-то давно знает о awk и К. Прочитай внимательно его слова - что касается больших файлов с данными, в SE он делает one-off ad-hoc задачуб, автоматизировать которую невыгодно по трудозатратам. Для штатной работы - постпроцессоры (скриптованные, наверняка).

При всем моем уважении к опыту sS - должны быть _очень_сильные_ аргументы, чтобы так поступать - грузить _весь_ файл в редактор :)

>Нет, конечно. Ибо этого можно не делать. А можно поставить auctex+reftex и превратить emacs в удобнейший редактор статей, для чего я его и использую :)

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

так тогда получается что вы делаете себе какое то универсальное средство которое делает все и вся, так получается?

а именно здесь уже кто то писал что универсальные средства зло

что то расхождения тут у вас получаются

>Так вот, скажи мне, разве это признак профессионала - уповать на "серебряную пулю" и верить в существование универсального средства или решения?

вот цитата

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

для остального юзаю emacs и джаббер на нем -)

>Нет, я не программист по профессии, скорее ближе к вычислительной математике.

Дело не в профессии а в ваших суждениях что нужно профессионалу а что нет , причём в совершенно другой предметной области.

Я же не говорю что vim а особенно emacs плох. Дело в заточке инструмента. Я даже своим коллегам не пытаюсь доказывать что они неправы когда к примеру используют vs2005 или emacs (есть и те и другие). Это их право и их профессиональный выбор.

> скажу даже больше, я SE в глаза не видел.

Но уже мнение составили ;)

>что он именно "комбайн", а значит - уже мертв :)

А emacs кто по вашему ? паравоз ? ;)

>А что касается примеров с редактированием гигантских файлов - он был для меня знаковым в свое время. Выходные файлы с расчетов - часто бывают по 200-500 Мб. Я тоже по наивности сначала пытался вырезать из них нужную информацию инструментами типа mcedit и vim (а моя бывшая руководитель - в far'е). Не было тогда у меня SE :) Они были способны поставить комп на колени, но работу свою выполняли плохо (а был это 2002 год и 1Гб памяти на компе). Far так просто падал. И тогда я открыл для себя и grep с awk, и csplit.

И только исходя из этого вы сделали для себя вывод что SE плох ? ;)

Просто вы изначально выбрали никуда не годные инструменты (mcedit, vim) Скажу по секрету, для действительно быстрой обработки начиная с некоторого размера обрабатываемых данных скрипты не очень подходят. Приходится писать парсеры на C/C++ и пытаться использовать возможности параллельной обработки.

> должны быть _очень_сильные_ аргументы, чтобы так поступать - грузить _весь_ файл в редактор :)

Экономия двух минут на написание _одноразового_ скрипта - это очень даже веская приина :)

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

> так тогда получается что вы делаете себе какое то универсальное средство которое делает все и вся, так получается?

Нет, юный падаван, речей многомудрого Йоды не понял ты :)

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

Пусть у нас есть, для определенности, n утилит, каждая из которых умеет что-то принимать в качестве входных данных и что-то отдавать в качестве результата. Соединяем их конвеерами. тогда комбинаторика говорит, что есть n^n способов получить разные комбинации этих утилит. Даже включая тот буддистский вариант, когда ты не использовал ни одной утилиты и наградил себя недеянием :)

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

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

Речь свою Йода кончил :)

так это понятно, но ты не ответил на предыдущие вопросы

>При всем моем уважении к опыту sS - должны быть _очень_сильные_ аргументы, чтобы так поступать - грузить _весь_ файл в редактор :)

Я уже аргумент приводил. Это элементарно быстрее чем написать скрипт. Даже на 500Mb файле. Вся фишка в том _как_ SE открывает файл, а делает это он совсем не так как к примеру делает gvim. Потому что первую порцию данных даже на таком файле SE открывает _мгновенно_ после чего он позволяет прочитанный кусок совершенно свободно редактировать. Подождать придётся только поле команды на сохранение. Причем не очень долго.

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

> Дело не в профессии а в ваших суждениях что нужно профессионалу а что нет , причём в совершенно другой предметной области.

Да что ж Вы так смертельно серьезны? Это же ЛОР - место где смеясь, постигают истины. :)

> Но уже мнение составили ;)

Естественно, я ведь продукт регистрационной мутации anonymous'а :)

> А emacs кто по вашему ? паравоз ? ;)

О, у меня появился новый ученик! Нет, он не комбайн, по той же причине, что "не комбаин" и дистрибутив линукса. Читаем речь Йоды :)

> И только исходя из этого вы сделали для себя вывод что SE плох ? ;)

Такой подход - говорит о том, что он плох. Не надо писать хитроумный редактор, чтобы грузить большие файлы. Значит и в остальном он весь такой же - гениальные решения задач о мостах из винных пробок :)

> Просто вы изначально выбрали никуда не годные инструменты (mcedit, vim) Скажу по секрету, для действительно быстрой обработки начиная с некоторого размера обрабатываемых данных скрипты не очень подходят. Приходится писать парсеры на C/C++ и пытаться использовать возможности параллельной обработки.

Что было под рукой, то и пробовал :)

И между прочим, не приписывайте мне то, чего я не говорил. Я рекламирую скриптовые языки. Я говорю, что эта проблема решается поиском и выделением в _потоке_данных. А на чем Вы эту парадигму реализуете - дело Ваше :)

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

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

Опции - это просто возможность пользоваться псевдонимами - одним и тем же именем для _разных_ утилит :) Это способ увеличить разноообразие. :)

А SE - его уменьшает, ибо предлагает _готовые_композиции_ элементарных действий.

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