Здравствуйте, yrashk, Вы писали:
Y>Предположим, у нас есть объект OneKilo (названия здесь и далее только лишь для удобства). Значение, предположим, (uint32_t)1024 (4 байта). У объекта OneKilo метаобъектом может быть объект Number, у которого собственный метаобъект, например, Object.
Y>У объекта Number может быть, для примера, слоты
Y>- (мета=SymbolicName) "Number"
Y>в свою очередь, SymbolicName может иметь метой Symbol или Object.
Ты случайно не JavaScript пытаешься изобрести ?

Здравствуйте, shuklin, Вы писали:
S>У меня сейчас работают 3 сборщика мусора. Из них один — MSовский из .NET и два собственного изготовления. Надо сказать МС овский для ОБД подходит плохо, с ним приходится бороться.
Кстати, ты не мог бы чуть подробнее рассказать об этом? Я в свое время, когда об этом размышлял, то так и не придумал, как все правильно делать.
Вижу две фундаментальных проблемы:
1. Взаимодействие встроенного сборщика мусора и кэша СУБД.
Обеспечение своевременной уборки объектов, инстанцированных в рамках навигации или выполнения запросов, и при этом все еще приемлемой эффективности.
2. Сборка персистентного мусора.
Тут вообще все сложно. С одной стороны, сам по себе ввод операции Delete для хранимых объектов приводит к тем же проблемам, которые стимулировали развитие управляемых систем с автоматическим управлением памятью:
— риск повисших указателей
— риск двойного удаления
— риск получения утечек — объектов, которые никто не использует, но которые все еще живут.

Вроде как идеалом является автоматический сборщик мусора. Но его реализация упирается в то, что:
— при наличии языка запросов все объекты являются потенциально достижимыми (эта проблема снимается при ограничении чисто навигационными запросами. В таком случае можно считать мусором все объекты, недостижимые из предопределенного root-объекта базы данных)
— честное сканирование графа достижимости для хранимых данных неприемлемо: каждый проход сборщика мусора будет поднимать в память всю базу. А типичные применения СУБД подразумевают объем обрабатываемых данных далеко за пределами емкости оперативной памяти. Существующие сборщики мусора в Java и .Net предполагают большое количество временных объектов, а в базе большинство объектов — долгоживущие.
— подсчет ссылок имеет один фатальный недостаток: неумение детектировать циклы.

Я имел дело с реализацией, где был выбран компромиссный подход: он был основан на счетчике ссылок, но при этом у всех "живых" объектов всегда была "лишняя" ссылка. Так что можно было создать объект, и он жил без того, чтобы на него хоть кто-то сослался. Операция "удаления" снимала эту лишнюю ссылку, и помечала объект специальным флагом. Этот флаг запрещал делать новые ссылки на этот объект. Таким образом, пользователь мог выразить свое желание удалить объект, но реально он удалялся только после того, как на него пропадали все ссылки. Я не помню сейчас, снимались ли ссылки с тех, на кого объект ссылался, при пометке на удаление или только при реальном удалении. В любом случае, этот подход был достаточно рискованным: на практике он работал, но потенциально разработчик мог написать систему, чреватую утечками. Гарантировалась только ссылочная целостность.

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

Складывается ощущение дежа вю.Это вы наверно Windows .Net2 описываете
Только в мозгах пропитанных идеологией интерпретаторов могло возникнуть
что-либо подобное — любая Вавилонская башня состоит из более чем одного этажа.

Как только не найден готовый класс с соответствующей функциональностью,
все эти монстры мысли начинают изучать low-level API или нанимают C++ программиста
для разработки требуемого компонента

Изучение иерархии классов (1500 в Net framework) по сложности уже приближается
к толкованию Талмуда (и столь же спекулятивно, т.к.постоянная смена условий
порождает изменяющиеся требования = больше классов хороших и разных).
Рост количества классов сводит на нет преимущества быстрой разработки.
Критерием же на самом деле являются стоимость разработки и т.п.
реальные вещи.

Иначе происходит ситуация как с телом Лунного короля (из путешествиях Гулливера )
у которого оторвалась голова и принялась придумывать новый чудесный мир,
но когда ее тело поймало, плотские интересы победили

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

Y>>в свою очередь, SymbolicName может иметь метой Symbol или Object.
S>Ты случайно не JavaScript пытаешься изобрести ?
Я Вас порадую (или наоборот). Нет.

Sinclair,

dmz>>Это не "такая возможность". Это просто несколько команд на языке vim-а. yy (скопировать) 999p — вставить 999 раз. Потом, что значит не нужна. 1000 раз может и не нужна, просто скопировать несколько строк — вполне обычное дело.
S>"просто скопировать несколько строк" гораздо проще с помощью мыши.

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

Могу привести одно небольшое наблюдение. Все люди, которых я знаю (включая меня самого), в настройках клавиатуры ставят максимальную скорость повтора автонажатий и минимальную скорость задержки. Зачем? Эти люди очень часто используют действие "нажать и давить", хотя может быть не отдают даже себе в этом отчёт.

Но однажды у меня появился ноут, который страдал неприятным эффектом — даже если выставить на максимум, скорость повтора всё равно была низкой и скорость навигации по файлу методом "нажать и давить" упала просто ниже плинтуса. Чтобы ускориться потребовался пересмотр привычек и понадобились команды "перейти ко второй открывающей скобке, перейти к началу первого идентификатора после знака присваивания, заменить все is_done на is_finished в текущем блоке, добавить закрывающую скобку в конце этого выражения" и так далее.
И разумеется, шорткаты в kate имелись лишь для небольшого числа таких команд, и поэтому было быстрее ткнуть мышой — а это уже неизчезающий оверхед. Переезд на vim позволил избавиться от таких задержек благодаря большому количеству разнообразных примитивных операций.

Волею судьбы я уже полгода работаю под виндой, но до сих пор "vim-way" является эталоном — ценой небольших умственных усилий можно намного уменьшить рутину при редактировании текстов. К сожалению, в царстве "Visual чего-то-там" всё совсем по-другому, прикрутить vim сюда требует существенных усилий, так что я покатился по наклонной (VS, Eclipse, FAR etc.)

dmz>>Это никак не 15 секунд — сначала пришлось бы изучать бейсик или что это было.
S>О да, а знание команд vim наверное инсталлируется прямо в мозг при первом запуске.
Интересная метафора

S>Этот VBA к тому же обладает интеллисенсом и подсказывает, что можно сделать, имена объектов и методов выбраны так, чтобы типичный американец сразу знал, что куда вставлять, а кроме всего прочего, можно включить запись макроса. Поэтому типичная штука — это включить запись, вбить параграф, выключить запись, пойти в редактор макросов и обложить две строчки циклом. Я так в свое время выполнял подбор параметра в Excel для 2000 начальных условий.
Правда, есть замечание: эффективность использования для опытных пользователей важнее чем эффективность обучения.

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

LCR>Могу привести одно небольшое наблюдение. Все люди, которых я знаю (включая меня самого), в настройках клавиатуры ставят максимальную скорость повтора автонажатий и минимальную скорость задержки. Зачем? Эти люди очень часто используют действие "нажать и давить", хотя может быть не отдают даже себе в этом отчёт.
Ну что ж, приятно познакомиться Я никогда не трогал эти настройки. Когда мне надо несколько срабатываний, я в 90% быстро стучу по клавиатуре. Потому, что минимальная задержка (в досе) была практичкски 0 — это умножение почти всех символов. И очень трудно угадать нужное время удерживания.

LCR>Но однажды у меня появился ноут, который страдал неприятным эффектом — даже если выставить на максимум, скорость повтора всё равно была низкой и скорость навигации по файлу методом "нажать и давить" упала просто ниже плинтуса. Чтобы ускориться потребовался пересмотр привычек и понадобились команды "перейти ко второй открывающей скобке, перейти к началу первого идентификатора после знака присваивания, заменить все is_done на is_finished в текущем блоке, добавить закрывающую скобку в конце этого выражения" и так далее.
LCR>И разумеется, шорткаты в kate имелись лишь для небольшого числа таких команд, и поэтому было быстрее ткнуть мышой — а это уже неизчезающий оверхед.
На практике я тоже никогда не копирую мышкой. Навигация с клавиатуры точнее и быстрее. Но я очень интенсивно использую Shift+Ctrl+Right и Shift+Ctrl+Left для выделения по словам (если не использую выделение по строкам).

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

S>Складывается ощущение дежа вю.Это вы наверно Windows .Net2 описываете
S>Только в мозгах пропитанных идеологией интерпретаторов могло возникнуть
S>что-либо подобное — любая Вавилонская башня состоит из более чем одного этажа.

Ващето мозги пропитаны нейронными сетями, семантическими сетями фреймов, экспертными системами и прочей ИИшной мутью )))

А за одно пришлось поучаствовать в весьма крупных промышленных проектах, в которых без этой мути ну просто никак (((


С тем, что при существующем объеме классов в FCL .NET стал чудищем страшнее MFC — согласен полностью. Ну законы природы таковы, что сложные проблемы действительно требуют сложных решений и сложных инструментов для их решения.

Вот мне такой инструмент понадобился, я решил сделать его сам, так как я умею делать такие штуки

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

S>Кстати, ты не мог бы чуть подробнее рассказать об этом? Я в свое время, когда об этом размышлял, то так и не придумал, как все правильно делать.

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

S>Вижу две фундаментальных проблемы:
S>1. Взаимодействие встроенного сборщика мусора и кэша СУБД.
S>Обеспечение своевременной уборки объектов, инстанцированных в рамках навигации или выполнения запросов, и при этом все еще приемлемой эффективности.

Какое решение ИМХО было самым прямым, и какое я и применил. Отслеживать объекты, инстанциированные и на которые еще существуют указатели в рам. Остальные выстроить в список last recently used и выгружать начиная с самых старых. Вобщем так мой первый сборщик и работает. У меня есть класс-паразит над Win32 Heap Alloc который ведет список всех размещенных блоков памяти, следит за очередностью их использования и пытается выгрузить самые старые при превышении колличества размещенных блоков заданной константе или при превышении размера выделенной памяти заданной константе. Эта система размещения работает только для объектов, сопровождающих экземпляры пользовательских объектов. Остальные служебыне объекты размещаются своими собственными средсвами. Ну с виду тут все красиво, более менее. Однако граблей много.

взяли мы ИД объекта и разадресовали по нему указатель на .NET объект. Этот указатель кудато сунули, а потом через пару минут по нему ударили. Но учитывая мою собственную сборку мусора, этот объект уже давно задиспосен и все управляющие структуры выгружены. Возможно в рам есть его клон, но у него уже другой указатель, по любому GPF. Узнать, остались ли ссылки на какойто .NET экземпляр нельзя. Тоесть провести целевую выгрузку какого то конкретного объекта .NET нельзя. Можно ждать, пока сам .NET сборщик мусора начнет собирать объекты и вызовет Finalizer но тут тоже все плохо. Вызов пойдет в отдельном треде, вызов пойдет в совершенно непредсказуемый момент, может уже приложение остановлено БД потушена и сохраняться уже кудато позно. Потом в финализере нет гарантии, что связанные с данным объектом другие объекты еще существуют. + еще проблема — нужно перекрыть финализеры всех пользовательских экземпляров. Тоесть обязать наследовать пользовательские экземпляры от собственного класса => все value types сразу пролетают, и все системные classes тоже. Вобщем слишком много минусов у перекрытия финализера. Я от этого тоже отказался.
Еще один вариант, каждый раз при адресации объекта его блокировать, и затем в ручную unpin когда он не нужен. Так я и поступаю внутри ядра. Но обязать пользователей относится к этому моменту аккуратно во первых жестоко, во вторых нереально. Мне самому не нужна такая ОБД в которой я буду получить выстрел в голову каждый раз как забуду сделать unpin. В ядре, к отладке которого я подхожу осторожно это допустимо. Но не на пользовательском уровне.

В результате остановился на следующей схеме. Итак я возвращаю после разадресации не сам объект а оболочку IConnector. У этой оболочки есть свойство Component через которое доступен пользовательский экземпляр. Оставлять себе указатели на пользовательский экземпляр без сохранения указателя на Connector нельзя. В конструкторе коннектора идет пиннинг объекта. В деструкторе — unpin. В большинстве случаев паттерн работы с объектом выглядит следующим образом:
using(IConnector c = workspace.AttachConnector(h))
{
((MyClass)c.Component).MyMethod(c, ...);
}
Зачем желательно передать в метод c это отдельная тема связанная с паттерном FLYWEIGHT — но это не обязательно.
Итак при разадресации по идентификатору h объекта в методе workspace.AttachConnector возвращается его оболочка IConnector. После завершения работы с объектом эту оболочку необходимо Dispose что удобно с помощью конструкции usint () Если же по каким то причинам using не приемлем, и пользователь забыл или не смог провести Dispose то сам .NET вызовет Dispose в процессе сборки мусора и утечки памяти не будет. Побочный эффект — невозможность использовать экземпляр пользовательского объекта на прямую. На форуме по LINQ мне подсказали одну идею, но она сложна в реализации и всех деталей я еще не знаю. Решает это неудобство лишь частично. Поэтому я оставлю эту проблему как открытую для свободного обсуждения.


S>2. Сборка персистентного мусора.
S>Тут вообще все сложно. С одной стороны, сам по себе ввод операции Delete для хранимых объектов приводит к тем же проблемам, которые стимулировали развитие управляемых систем с автоматическим управлением памятью:
S>- риск повисших указателей
S>- риск двойного удаления
S>- риск получения утечек — объектов, которые никто не использует, но которые все еще живут.

Этим занимается вторая подсистема сборки мусора.

Есть такое дело на 100% ну я решил все очень прямо. У меня в персистент объектах есть счетчики входящих указателей. Когда на объект не указывает ни одного персистент указателя объект удаляется из системы по завершению транзакции или при сборке мусора если он вне транзакции.

S>- при наличии языка запросов все объекты являются потенциально достижимыми (эта проблема снимается при ограничении чисто навигационными запросами. В таком случае можно считать мусором все объекты, недостижимые из предопределенного root-объекта базы данных)

Это не проблема и для декларативного языка запросов. Там тоже можно считать достижимыми только такие же объекты. Считать — не значит достигать. Тоесть персистентный сборщик мусора работает на основе навигации, а декларативная система — только по существующим объектам, до которых сборщик еще не добрался. Учитывая возможность построения индексов на коллекциях, эта проблема ваще не теоретическая проблема а лишь проблема зверски сложной реализации (ведь в общем случае надо не забывать про распределенные транзакции)

S>- честное сканирование графа достижимости для хранимых данных неприемлемо: каждый проход сборщика мусора будет поднимать в память всю базу. А типичные применения СУБД подразумевают объем обрабатываемых данных далеко за пределами емкости оперативной памяти. Существующие сборщики мусора в Java и .Net предполагают большое количество временных объектов, а в базе большинство объектов — долгоживущие.
Согласен полностью. Поэтому второй сборщик мусора работает на той же идее подсчета ссылок, что и COM. Для подсчета ссылок всю БД держать в рам вовсе не нужно. Те объекты, которые участвуют в операциях установки связей по указателям по любому инстанциированы для их апдейта, так что за одно еще и каунтер проинкрементить декрементить — оверхеад мизерный.

S>- подсчет ссылок имеет один фатальный недостаток: неумение детектировать циклы.

Увы да. Чтож, в COM от этого никто не умер пока, хотя неудобств много. И в перспективе можно сделать четвертую подсистему сборки мусора, которая будет работать честно и запускаться во время "сна" системы.


S>Я имел дело с реализацией, где был выбран компромиссный подход: он был основан на счетчике ссылок, но при этом у всех "живых" объектов всегда была "лишняя" ссылка. Так что можно было создать объект, и он жил без того, чтобы на него хоть кто-то сослался. Операция "удаления" снимала эту лишнюю ссылку, и помечала объект специальным флагом. Этот флаг запрещал делать новые ссылки на этот объект. Таким образом, пользователь мог выразить свое желание удалить объект, но реально он удалялся только после того, как на него пропадали все ссылки. Я не помню сейчас, снимались ли ссылки с тех, на кого объект ссылался, при пометке на удаление или только при реальном удалении. В любом случае, этот подход был достаточно рискованным: на практике он работал, но потенциально разработчик мог написать систему, чреватую утечками. Гарантировалась только ссылочная целостность.

Да, у меня похожая система 1 к 1. Даже флаг такой есть, только он действует в пределах рам. При выгрузке объекта из рам принимается окончательное на данное время решение, или он будет таки убит, или останется жив. После выгрузки флаг теряется. лишняя ссылка на объект появляется при включении объекта в лог транзакции. Пока жива транзакция в которой к этому объекту обращались он будет жив даже если его "удалят". Так как в Cerebrum нет принудительного удаления объекта, а есть только операция снятия с него ссылок, логических парадоксов не возникает. Если к концу транзакции ссылок не осталось — объекту хана. Если осталось хоть одна, еще поживет )))

Sinclair,

LCR>>Могу привести одно небольшое наблюдение. Все люди, которых я знаю (включая меня самого), в настройках клавиатуры ставят максимальную скорость повтора автонажатий и минимальную скорость задержки. Зачем? Эти люди очень часто используют действие "нажать и давить", хотя может быть не отдают даже себе в этом отчёт.
S>Ну что ж, приятно познакомиться Я никогда не трогал эти настройки. Когда мне надо несколько срабатываний, я в 90% быстро стучу по клавиатуре. Потому, что минимальная задержка (в досе) была практичкски 0 — это умножение почти всех символов. И очень трудно угадать нужное время удерживания.
Ну хорошо, будем знакомы, очень приятно

Итак, ты говоришь, что не трогаешь настройки, перемещаешься исключительно нажатиями.

Давай рассмотрим такой пример:
Функция полностью на экране, количество строк в функции где-то 60-70 строк. Мы где-то в середине экрана, тут становится понятным, что нужно в начало функции вставить инициализацию чего-нибудь. Для этого нужно перейти на строку чуть ниже заголовка:

CString simpleTest2(const char *url)
{
    error_td_t err;
    roi_proxy_t *ro;
    // надо вот сюда, чтобы вставить эти 2 строки ниже
    // WSADATA wsaData;
    // WSAStartup(MAKELONG(2,0), &wsaData);
    AfxMessageBox(_T("Before Login procedure invocation"));

    ... // далее идут 30 строк кода
    |   // а курсор здесь

PageUp делать нельзя, потому что функция уедет вниз, а хочется её сохранить на экране.

Посему я вижу три альтернативы:
1. Медленно, но верно "нажать и давить" клавишу "вверх".
2. Быстро-быстро нажимать клавишу "вверх".
3. Использовать умный keystroke чтобы сразу попасть в нужное место (vim-way).

Итак, позволь задать следующие вопросы:

1. Что ты делаешь, когда надо несколько десятков срабатываний, и соответствующего шортката (типа Ctrl+Right) нет, как в примере выше?
2. Можешь ли достигнуть "трели" в 10 нажатий в секунду (это скорость автоповтора, на глазок)?

S>На практике я тоже никогда не копирую мышкой. Навигация с клавиатуры точнее и быстрее. Но я очень интенсивно использую Shift+Ctrl+Right и Shift+Ctrl+Left для выделения по словам (если не использую выделение по строкам).
В данном случае нам повезло, ибо есть шорткат (хотя и неудобный:-P).

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

S>Складывается ощущение дежа вю.Это вы наверно Windows .Net2 описываете Только в мозгах пропитанных идеологией интерпретаторов могло возникнуть что-либо подобное — любая Вавилонская башня состоит из более чем одного этажа.
Те по твоему .NET интерпритатор? Или я что-то не понял?

S>Как только не найден готовый класс с соответствующей функциональностью, все эти монстры мысли начинают изучать low-level API или нанимают C++ программиста для разработки требуемого компонента
Расказывай это тем кто на .NET не писал. В реальной жизни WinAPI нужно очень редко.

S>Изучение иерархии классов (1500 в Net framework) по сложности уже приближается к толкованию Талмуда (и столь же спекулятивно, т.к.постоянная смена условий порождает изменяющиеся требования = больше классов хороших и разных).
А зачем изучать все классы в .NET Framework? Это всеравно что требовать изучить все библиотеки С/С++ для работы на С++.

S>Рост количества классов сводит на нет преимущества быстрой разработки.
Правда? Что-то на практике имеем обратный эффект.

S>Критерием же на самом деле являются стоимость разработки и т.п. реальные вещи.
И именно управляемые среды такие как .NET и Java на очень большом классе задач сильно снижают стоимость разработки.

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

LCR>Давай рассмотрим такой пример:
LCR>Функция полностью на экране, количество строк в функции где-то 60-70 строк. Мы где-то в середине экрана, тут становится понятным, что нужно в начало функции вставить инициализацию чего-нибудь. Для этого нужно перейти на строку чуть ниже заголовка:
Ну, в языке, где я пишу, редко бывает нужно вставить что-то так далеко от курсора А вообще в таких случаях я не стесняюсь пользоваться мышкой. Потому что мне лень осваивать шорткуты, нужные столь редко.
Кстати, сделать 8-9 нажатий в секунду не столь уж сложно.

Sinclair,

S>Ну, в языке, где я пишу, редко бывает нужно вставить что-то так далеко от курсора А вообще в таких случаях я не стесняюсь пользоваться мышкой. Потому что мне лень осваивать шорткуты, нужные столь редко.
Полагаю, у тебя просто неторопливый стиль работы и скорость редактирования для тебя не имеет значения, поскольку "ботлнек" находится несколько (совсем?) в другом месте. Так?

(Если это так, то ладно, можно закрывать дискуссию о скорости редактирования.)

S>Кстати, сделать 8-9 нажатий в секунду не столь уж сложно.
Тем не менее автоповтор может быстрее, а подходящие комбинации команд могут сделать повторы ненужными.

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

S>>Ну, в языке, где я пишу, редко бывает нужно вставить что-то так далеко от курсора А вообще в таких случаях я не стесняюсь пользоваться мышкой. Потому что мне лень осваивать шорткуты, нужные столь редко.
LCR>Полагаю, у тебя просто неторопливый стиль работы и скорость редактирования для тебя не имеет значения, поскольку "ботлнек" находится несколько (совсем?) в другом месте. Так?

LCR>(Если это так, то ладно, можно закрывать дискуссию о скорости редактирования.)
Просто у людей использующих всякие студии скорость кодирования повышают не всякие примитивы типа повторить комманду N раз(кстати в студииэто делается

Автор: WolfHound
Дата: 22.04.06

легко), а гораздо болие мощьные вещь типа умного автокомплита и кучи рефакторингов плюс продвинутая система навигации по коду. Для того чтобы это понять нужно поработать в студии с ReSharper'ом некоторое время.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Полагаю, у тебя просто неторопливый стиль работы и скорость редактирования для тебя не имеет значения, поскольку "ботлнек" находится несколько (совсем?) в другом месте. Так?
Совершенно верно. Нет смысла писать быстрее, чем думаешь.

WolfHound,

LCR>>(Если это так, то ладно, можно закрывать дискуссию о скорости редактирования.)
WH>Просто у людей использующих всякие студии скорость кодирования повышают не всякие примитивы типа повторить комманду N раз(кстати в студииэто делается

Автор: WolfHound
Дата: 22.04.06

легко), а гораздо болие мощьные вещь типа умного автокомплита и кучи рефакторингов плюс продвинутая система навигации по коду. Для того чтобы это понять нужно поработать в студии с ReSharper'ом некоторое время.

И работа в Идее (при чём тут решарпер, скажите на милость?.) не спасает от необходимости как минимум 10 раз в день совершить некоторое сложное действие n раз.

И вообще, это всё (рефакторинг, автокомплит етц) ортогонально командам редактирования.

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

LCR>И работа в Идее (при чём тут решарпер, скажите на милость?.) не спасает от необходимости как минимум 10 раз в день совершить некоторое сложное действие n раз.
ДЕСЯТЬ РАЗ В ДЕНЬ Зачем? Можно пару примеров? У меня такие случаи пару раз в месяц происходят. Не чаще.
Но если тебе это так нужно то ссылку на то как это сделать в студии я тебе уже давал.
Идею я не видел как это сделать там я не знаю.

LCR>И вообще, это всё (рефакторинг, автокомплит етц) ортогонально командам редактирования.
Интересная логика

WolfHound,

LCR>>И вообще, это всё (рефакторинг, автокомплит етц) ортогонально командам редактирования.
WH>Интересная логика

Ага. Я к тому, что (в принципе) расширенный набор шорткатов можно склеить с рефакторингом и афтокомплитом етц без ущерба для организма. Как например, в Idea с vim плагином (между прочим было здорово!), или в емаксе.

А сейчас я имею либо сытых волков, либо нетронутых овечек.