SlickEdit 2007

> вообщем давай аналог slickedit со всеми фичами на emacs'e и чтоб рефаторинг и automplete был

Emacs + X-Refactory. SE предыдущей версии реально хуже справлялся.

Emacs + X-Refactory.

ага, окно с аутокомплишеном на пол экрана через "splitview" это конечно лучше. ;) при попытке зааутокомплитить "a*" придется долго ждать, потому что нужно все варианты отправить через пайп и дать емаксу распарсить, вместо того чтобы найти только те варианты которые видны в актокомплит-окне, и в пределах одного адресного пространства, в специальной структуре данных, передать их в это актокомплит-окно.(ленивость) и передавать/искать отсальные части только при скроллинге вниз. ну а какой там проject менеджмент, и вспоминать страшно.

для тех кто не видел, вот их аутокомплишен http://www.xref-tech.com/xrefactory/images/emacs/completion.png

ещё xref заметно медленне чем SE(проверял на исходниках ядра, в ~4 раза если память не изменяет), такой же платный и стоит дороже (399$) хотя конечно html карты исходников заруливают.

>>А cut здесь не поможет? Вроде он специально для вырезания колонок и создавался.

>На самом деле в этих файликах есть одна "хытрасть"

>У них вот такая вот структура [хидер] [данные] [хидер] [данные] ....

Понятно. Я обычно в подобных случаях таки скрипт на perl заставляю себя писать. Так как ручная работа не свпособствует автоматизации :) Если не напишешь сразу, то потом много раз будешь повторять операцию cut and past доводя свои рефлексы до автоматизм - бррр. Лучше потормозить и подумать.

А для интерактивной работы с большим объёмом данных ASCII файлы конечно не рулят. Приходится использовать "энтаплы" или "деревья". В общем это всё в сторону paw или root.

>> солюшены vs2005 не поддерживает (да конечно можно все это самому написать но время деньги)

>Зачем они вам? А если нужны, зачем вам что-то отличное от генеральной линии партии?

по работе вот зачем

я же ведь не сижу просто так не кричу везде что vim, emacs и фсио остальное гавно

да и то если брать emacs+slime как IDE для lisp, то тут более привлекательна LispWorks с гораздо большими возможностями

> :D Мьсе вантузятник не иначе..

> man cut уже наверное не модно?

Во-во... Латентный, не иначе. Любит ручной труд.

подобная задача может быть разовой. что, каждый раз скрипт писать ?

> подобная задача может быть разовой. что, каждый раз скрипт писать ?

Нет, можно в командной строке cut -c x-y написать.

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

> да и то если брать emacs+slime как IDE для lisp, то тут более привлекательна LispWorks с гораздо большими возможностями

А в LispWorks можно почту читать и mpd управлять?

>> Зачем они вам? А если нужны, зачем вам что-то отличное от генеральной линии партии?

> по работе вот зачем

А емакс зачем?

> я же ведь не сижу просто так не кричу везде что vim, emacs и фсио остальное гавно

Можете кричать, оппоненты вас по местной традиции всё равно не услышат :)

> ага, окно с аутокомплишеном на пол экрана через "splitview" это конечно лучше. ;) при попытке зааутокомплитить "a*" придется долго ждать, потому что нужно все варианты отправить через пайп и дать емаксу распарсить, вместо того чтобы найти только те варианты которые видны в актокомплит-окне, и в пределах одного адресного пространства, в специальной структуре данных, передать их в это актокомплит-окно.(ленивость) и передавать/искать отсальные части только при скроллинге вниз.

У вас закостеневший взгляд на вещи.

> ну а какой там проject менеджмент, и вспоминать страшно.

Autotools, какой ещё?.. Руками правишь configure.in и Makefile.am, всё потом собирается вне зависимости от существования SE для данного юникса.

> ещё xref заметно медленне чем SE(проверял на исходниках ядра, в ~4 раза если память не изменяет),

Вы натравите SE лучше на C++-проект, активно использующий boost. SE предыдущей версии мне пришлось убить, а xref потарахтел винтом минутки 3-4. Да, кстати, я с чужим кодом поплотнее знакомлюсь, autocomplete'ом не пользуюсь. Не говоря уж про свой.

> такой же платный и стоит дороже (399$)

Это продукты в абсолютно разных категориях. И разница в цене, кстати, непринципиальная.

> индексация ядра полностью, нужна для копания в нем, узнавания как оно работает...

А я книжек купил

>У вас закостеневший взгляд на вещи.

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

а аутокомплит на пол экрана это не эргономично (глазам дергаться приходится, видимость сокращается, итп)

>Вы натравите SE лучше на C++-проект,

в рефакторине SE сливает тотально, отрицать не буду, но в ориентации по символам и индексации, скорости работы самой ide - заруливает.

>autocomplete'ом не пользуюсь.

а исходники в hexedit'е не редактируете ? ;) а у христианских монахов "крутым" считается не есть и себя мучить ... это что то в этом роде.

>Autotools, какой ещё?..

нет я говорю про тот что связан xref-овским elisp пакетом.

>А я книжек купил

вот это не адекватный ответ. покажи мне книжку которая 100мб исходников подробно а не абстрактно описать сможет.

>Это продукты в абсолютно разных категориях.

не в разных, просто они к своему xrefу emacs в пакет не суют, но обеспечивают его поддержку. чтобы люди сами скачали или приделали к уже установленному т.е. в результате получается редактор+аутокомплит+рефакторинг+проджект_менедж. - тоже самое что и SE. а без emacsа xref почти бесполезен.

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

странно, а это что ?

http://www.lispworks.com/products/lwl.html

>LispWorks (64-bit) for Linux supports Linux running on AMD64-compatible hardware

>покажи мне книжку которая 100мб исходников подробно а не абстрактно описать сможет.

Может тогда проще с K&R начать, а? ;)

>> А я книжек купил

> вот это не адекватный ответ. покажи мне книжку которая 100мб исходников подробно а не абстрактно описать сможет.

Знания - это принципы, а не факты, читайте "Структуру реальности" Дойча. Мне достаточно знать, как в принципе устроена сетевая подсистема в линуксе, а не помнить наизусть мегабайт 20-50 кода, которые через год будут неактуальны.

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

> достаточно знать, как в принципе устроена сетевая подсистема в линуксе, а не помнить наизусть мегабайт 20-50 кода

+1, но речь шла о другом :)

>но речь шла о другом :)

+1

речь шла об облегчении ориентации.

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

А зачем это знать? Чем мне поможет SE, если я не знаю, как хотя бы называется функция, которая мне нужна? :))

> и помогает моментально переходить от файла к файлу не пользуясь диалогом открытия или аналогом. .... рассказывайте эти сказки кому-нибудь другому.

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

> речь шла об облегчении ориентации

Можете ещё втирать, что цветовая гамма SE также многократно увеличивает производительность труда программиста.

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

ИМХО потребности в такого рода манипуляциях (беготня по всему коду) - верный признак бездарно спроектированной программы.

>Вы натравите SE лучше на C++-проект, активно использующий boost. SE предыдущей версии мне пришлось убить, а xref потарахтел винтом минутки 3-4. Да, кстати, я с чужим кодом поплотнее знакомлюсь, autocomplete'ом не пользуюсь. Не говоря уж про свой.

в прошлом проекте активно юзал boost 1.33 и без проблем все работало (slickedit 11.02

>А в LispWorks можно почту читать и mpd управлять?

а вам что нравятся комбайны?

разве принцип(unix) каждая программа выполняет свою функцию вам не знаком?

>ИМХО потребности в такого рода манипуляциях (беготня по всему коду) - верный признак бездарно спроектированной программы.

о да, конечно же вы всегда приходите когда на новую работу и там всегда проект просто с супер архитектурой

> а вам что нравятся комбайны?

Скорее, агрегаты. Комбайн - это MS Windows.

> разве принцип(unix) каждая программа выполняет свою функцию вам не знаком?

Т.е. для управления одной программой обязательная нужна другая программа?

Unix-way соблюдается: mpd играет музыку, fetchmail качает почту, exim её отправляет, а я управляю и контролирую работу всего этого из емакса :)

А при чем тут новая работа? Когда человеку, чтобы найти определение ф-ции надо перелопатить кучу файлов - это изначально убогий дизайн, часто люди начинают писать проект на С/С++, заботясь об оптимизации, не имея даже работающего прототипа.

> о да, конечно же вы всегда приходите когда на новую работу и там всегда проект просто с супер архитектурой

А зачем вы ушли с одной плохой работы на другую плохую работу? Надо идти на такую работу, где вы сможете прогрессировать.

>ИМХО потребности в такого рода манипуляциях (беготня по всему коду) - верный признак бездарно спроектированной программы.

Ядро Linux ? ;)

> Ядро Linux ? ;)

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

>А при чем тут новая работа? Когда человеку, чтобы найти определение ф-ции надо перелопатить кучу файлов - это изначально убогий дизайн, часто люди начинают писать проект на С/С++, заботясь об оптимизации, не имея даже работающего прототипа.

Код OpenFOAM видел ? ;)

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

Дык не всегда приходится одну отдельную подсистему копать. К примеру тот же код драйвера web-камеры как минимум затрагивает 2 подсистемы (USB и video)

> Дык не всегда приходится одну отдельную подсистему копать. К примеру тот же код драйвера web-камеры как минимум затрагивает 2 подсистемы (USB и video)

Не смешите тапки, это, наверное, две самые простые части ядра.

>Не смешите тапки, это, наверное, две самые простые части ядра

И что ? Дело не в том что они простые или сложные а в том что в одном драйвере требуются различные подсистемы ядра. Пример привёл только потому что приходится иметь с ними дело и это первое что пришло в голову.

>верный признак бездарно спроектированной программы.

ядро линукса ... там есть где побегать.

Ну я бы сказал, что это образец, весьма далекий от подражания. Как же несчастные разработчики железа писали драйвера под UnixWare, Solaris или Windows, вообще без кода ядра. Говорят, что драйвера для NT4 вполне работали под W2k/XP, хотя железки давно уже не выпускали и не поддерживали.

знание в каком файле находится функция сильно время не экономит. при таком знании всё равно приходится сначала найти этот файл по алфавиту в длиннющем списке, затем найти местоположение функции внутри файла(и не всегда они в алфавитном порядке). а с "автоматизированной бегатнёй" нужно только нажать на "go to defenition" - 1 сек, против 7 - 15.

вы нам что, предлагаете брать пример с виндовых драйверо писателей, и не знать как ОС работает ?

>Как же несчастные разработчики железа писали драйвера под UnixWare, Solaris или Windows, вообще без кода ядра. Говорят, что драйвера для NT4 вполне работали под W2k/XP, хотя железки давно уже не выпускали и не поддерживали.

Только для тех подсистем, которых не коснулись изменения NT->2k->XP

Их было немного но они были.

Кстати для нетривиальных случаев M$ вполне себе раздаёт куски ядра под NDA Ну или умельцы выдёргивают нужную инфу с помощью RE...в курсе сколько потом такая инфа стоит ? ;) У меня коллеги на сей счёт общались с Руссиновичем. Платить $15к им показалось неоптимальным и они за 3 месяца наковыряли аналог ... зарплата ковырятелей обошлась им дешевле ;)

А если это драйвер для raid контроллера, который должен работать вообще под людой системой, включая dos и Novell NetWare, у тебя голова не распухнет от обилия деталей?

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

я повторю саой вопрос

вы нам что, предлагаете брать пример с виндовых драйверо писателей, и не знать как ОС работает, хотя бы одна ?

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

Даже это не является необходимым - можно отреверсить драйверный API по существующим драйверам. Но с документацией и тулкитом - проще. С документацией, тулкитом и исходниками ядра - еще проще. Если исходники есть - глупо ими не пользоваться.

Вопрос поставлен некорректно, естественно интерфейс системы описан в терминах ее объектов, буфера, дисциплины обработки прерываний и т.д.

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

Например файерволл (ipfilter) в Solaris - просто STREAM модуль, встраевымый в цепочку обработчиков TCP/IP. Научитесь один раз в жизни писать эти самые STREAM и будете писать под любой юникс.

>С документацией, тулкитом и исходниками ядра - еще проще.

+1

К вопросу о ядре линукса, точнее беготне по таковому.

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

2. Быстрее ли SE проиндексирует ядро, чем find -name '*.[chS]' | xargs ctags -e -a ?

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