Название, видимо с каким-то смыслом

http://www.urbandictionary.com/define.php?term=vial

sam -d не требует предварительного сохранения для модификации

Не понятно причем тут сохранение, если он держит копию (не совсем).

на месте несохранённого файла

Вот как раз по этому поводу и возражения: что подразумевается под «несохраненным файлом»?

возможности в sam модифицировать через перенаправление

Почему это принципиально?

то он должен быть сохранён иначе версии поползут ветвится

В этом тоже не вижу: если очень хочется можно засунуть хоть в vcs.

сори но вы реагируете на знакомые слова - а не излагаемую ими ситуацию

под версиями подразумевается лиш различее между на диске и в открытом редакторе(без автосохранение перед вызовом !)

Почему это принципиально?

не принципиально, просто в ручную сохраняем w

ps. ed (sed)|sam прекрасный инструмент именно по тому что его интерфейс «встраимаем» в отличии от гуи в которых просто обычно не преследуют сохранение равной лёгкости доступа к чему-либо не только при помощи поинт&клик , но и однородного языка(случае «аутоитов» имеют тот недостаток , что в командах теряется семантика действия , и команды просто используют факт что нужная кномка имеет тот или иной уникальный признак.)

Я, пожалуй, согласен с Брэмом. Его надо держать как можно в более простом виде, чтоб он не скрывал за собой vimscript.

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

Изначально был setup.py. Но я подумал, что как отдельная библиотека (тем более требующая рута для установки), vial совершенно бесполезен, поэтому выпилил. Ну не нужно это в site-packages. К тому же, таким образом, плагин абсолютно инддиферентен к версии питона.

Зачем root? Pip отлично умеет устанавливать только для одного пользователя.

Кажется поправил. Проблема была в установке стиля приложения. Инициализация была сделана в точности так, как рекомендует QT, но для некоторых стилей это приводило к крэшу. Возможно, играет роль и точная версия библиотек. Скорее всего вы поменяли стиль по умолчанию plastique на какой-то другой. Все, что я сделал, это поменял две строчки местами - теперь сначала инициализируется QApplication, а потом устанавливается выбранный пользователем стиль. Исправления в файле ui/application.py, ревизия 1542.

Попробуйте, пожалуйста, и сообщите о результате. Если ошибка уйдет, то надо будет пересобрать пакеты.

Заранее спасибо.

Повторяю комментарий, сделанный для I-Love-Microsoft. Скорее всего на вашей системе тот же случай... Буду признателен, если вы тоже поделитесь результатом.

Кажется поправил. Проблема была в установке стиля приложения. Инициализация была сделана в точности так, как рекомендует QT, но для некоторых стилей это приводило к крэшу. Возможно, играет роль и точная версия библиотек. Скорее всего вы поменяли стиль по умолчанию plastique на какой-то другой. Все, что я сделал, это поменял две строчки местами - теперь сначала инициализируется QApplication, а потом устанавливается выбранный пользователем стиль. Исправления в файле ui/application.py, ревизия 1542.

Попробуйте, пожалуйста, и сообщите о результате. Если ошибка уйдет, то надо будет пересобрать пакеты.

Заранее спасибо.

Когда у тебя 5-10 файлов - ide не нужно, не спорю. А если у тебя их пара сотен? И из каждого импортируются методы из 5-10 других файлов, раскиданных по куче модулей?

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

А под win я так понимаю нет сборки, а жаль хотел нашим коллегам подкинуть.

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

Об этом знает только 1% питонистов. Не вижу никаких, ну вообще никаких преимуществ в пакете.

* Зависимостей нет и не будет
* Лишний головняк с дистрибуцией
* Решать волшебные проблемы, если пользователь установил vial в несколько мест
* Почему vial можно установить как пакет, а его плагины нет?

Vial это обычный vim-плагин, не нужно использовать инородную инфраструктуру, никаких плюсов это не даст.

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

Если этих возможностей нет в VimL, то в первую очередь стоит их добавить туда, а не в интерфейс.

Хорошо, вечером обязательно попробую!

Так точно. Я всегда первым делом менял пластик на оксиджен.

Напишите, пожалуйста, о результате.

А вы попробовали с исправлениями? Помогло?

Пока нет возможности добраться до компьютера с этой прогой. Завтра только могу протестировать.

А под win я так понимаю нет сборки

Нет. Чуть подробнее здесь: Codimension Python IDE 2.0.1 (комментарий)

Я так понимаю, что Илья использует codimension под Windows в качестве IDE без запуска/профилировки/отладки.

Если этих возможностей нет в VimL, то в первую очередь стоит их добавить туда, а не в интерфейс.

В VimL эти возможности неудобны. И, что хуже, неоптимальны. Я могу сделать итератор для тёгов или quickfix, но в VimL нет итераторов. Превращение функций в более абстрактный тип (с указателем на void * и на структуру типа PySequenceMethods) в планах (даже есть экспериментальная почти нерабочая версия), причём Bram вроде не возражает. Тем более, что такое добавление заметно облегчит задачу создания lambda‐функций, которые ему бы хотелось видеть. Но вот добавление новых типов — геморрой совершенно иного уровня, чем прикрученные сбоку «указатели на функции». Я совершенно не заинтересован иметь итераторы в VimL, потому что его синтаксис не станет от них ни на йоту лучше. А добавление таких вещей как with просто потратит неприлично большое время на то, чем я не буду пользоваться (из‐за совместимости со старыми версиями).

Кроме того, это уводит от таких проблем VimL как излишняя зависимость некоторых вещей от настроек. Делать интерфейс для Python на основе VimL, да ещё и с пачкой set’ов (точнее, уже присвоений значений ключам vim.options/{buffer}.options/{window}.options), которые непременно затрут информацию о том, где реально присваиволось данное значение данной настройки, при возможностях Python C API как‐то неприлично.

И ещё не забывайте про закон дырявых абстракций. Можно протаскивать что‐то через функции VimL в Python. Но чем больше слоёв, тем больше абстракций и тем больше дырок. И не забывайте, что функции в VimL должны задумываться так, чтобы было удобно тем, кто пишет на VimL. Это делает интерфейс либо неудобным, либо отнимает ещё больше ресурсов на написание и сопровождение. С кодом на C, конечно, не сравнится, но зачем нужен такой интерфейс, если есть готовность написать лучше?

Да и для quickfix list дёргать malloc примерно 21 раз на каждый элемент списка, и потом то же самое для PyMem_* — это нечто. С предлагаемым кодом malloc дёргаться вообще не будет, а для атрибутов память будет выделяться только когда они будут запрошены (впрочем, с последним утверждением возможны варианты: эту часть кода я ещё не трогал).

qflist это странный пример. Он же не бывает сильно гигантским. Я даже не знаю при каком сценарии {set|get}qflist должен тормозить.

// Моя грепалка по файлам проектов сессии выдавала несколько тысяч записей и как бы ничего страшного не происходило.

Меня больше всего волнует обратная совместимость. Сейчас есть старый как говно мамонта macvim и еще более окаменевшие дистрибутивные сборки. Если +python внезапно станет обрастать фичами, то поддержка плагинов может превратится в ад.

Об этом знает только 1% питонистов. Не вижу никаких, ну вообще никаких преимуществ в пакете.

Откуда статистика? Большинство из тех, с кем я общаюсь, про --user в курсе. Пользователи powerline отлично вычитывают информацию об этой возможности в документации (на powerline).

* Зависимостей нет и не будет

Не уверен, что это хорошая идея.

* Лишний головняк с дистрибуцией

Не больше, чем с http://www.vim.org. Написал скрипт и радуюсь.

* Почему vial можно установить как пакет, а его плагины нет?

Потому что плагины должны быть устанавливаемы как пакет. С тем же python-mode-klen у меня уже были «волшебные проблемы» из‐за того, что в системе установлен rope, а пакет содержит другую его версию. С pip таких проблем бы не было. Или вы хотите сказать, что не только vial, но и никакие его дополнения никогда не потребуют никаких зависимостей?

Мне не нравится ни одна из следующих идей:

1. дополнения или сам vial будут содержать самописные велосипеды;
2. дополнения или сам vial будут содержать в себе конкретные версии других библиотек;
3. дополнения или сам vial будут требовать от меня лично установить все зависимости.

Первый вариант ненадёжен, второй провоцирует конфликты версий, третий просто неудобен. Как вы собираетесь делать, к примеру, vial-c без выбора одного из вышеописанных вариантов я не представляю. И, кстати, что использует vial-python для автодополнения?

* Решать волшебные проблемы, если пользователь установил vial в несколько мест

По опыту powerline могу сказать, что волшебные проблемы возникают только при сильно разных установленных версиях. И быстро заканчиваются. В отличие от волшебных проблем с различными версиями Python в Mac OS и шрифтами (последнее — на любой системе).

qflist это странный пример. Он же не бывает сильно гигантским. Я даже не знаю при каком сценарии {set|get}qflist должен тормозить.

QFlist действительно не слишком удачен. Сильно тормозят тёги (taglist()) (в первую очередь из‐за IO, происходящего каждый раз при вызове). Сильно тормозила передача данных (десятки килобайт) в VimL. Сильно тормозит соединение строк и запись в буфер. Но самое главное — сильно тормозит любой сколько‐нибудь часто вызываемых код на VimL. Тормоза + синтаксис + настройки = полное нежелание его использовать, когда можно без него обойтись.

Ну и сокращение объёма необходимых знаний тоже.

Меня больше всего волнует обратная совместимость. Сейчас есть старый как говно мамонта macvim и еще более окаменевшие дистрибутивные сборки. Если +python внезапно станет обрастать фичами, то поддержка плагинов может превратится в ад.

Я потом напишу библиотеку совместимости. Скорее всего, после того, как разберусь со ссылками на функции (потому что если я возьмусь за библиотеку только после реализации всего RFC, то из‐за объёма её будет сильно неохота писать, а за функции я уже взялся).

Большинство из тех, с кем я общаюсь

Как правило, наш круг общения соответсвует нашему же уровню, не так ли?

Не уверен, что это хорошая идея.

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

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

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

И, кстати, что использует vial-python для автодополнения?

Собственно он и использует supplement как внешнюю зависимость. Которую надо ставить отдельно.

Как правило, наш круг общения соответсвует нашему же уровню, не так ли?

Как я сказал, те, кто не знал об --user ранее, спокойно вычитывали это в документации. Неспособных прочитать документацию почему‐то не привлекает ни Vim, ни powerline.

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

Но их нельзя установить с помощью pip, а, следовательно, также установить и зависимости одной командой.

Собственно он и использует supplement как внешнюю зависимость. Которую надо ставить отдельно.

Ну и что в этом хорошего? С поддержкой pip ничего отдельно ставить не надо, он и vial, и supplement установит. Люди придумывали пакетные менеджеры не для того, чтобы их игнорировать. Тем более, что с pip можно в качестве временной меры использовать git+git:// для установки. (С powerline, правда, ситуация несколько сложнее: данное имя уже занято неподдерживаемым и, насколько я помню, неустанавливающимся пакетом. Что по этому поводу делает автор — не знаю, вроде кто‐то собирался у кого‐то просить освободить имя.)

Но их нельзя установить с помощью pip.

Много чего нельзя установить через pip. Ты слишком python-addicted.

Ну и что в этом хорошего?

KISS. Поэтому мне нравится патоген, и не нравится vundle и иже с ним.

Люди придумывали пакетные менеджеры не для того, чтобы их игнорировать.

Люди также придумали кучу дистрибутивных менеджеров пакетов.

Вообще мне несколько неудобно перед ТС. Такое 4.1 развели с тобой. Куда только модераторы смотрят ))

Много чего нельзя установить через pip. Ты слишком python-addicted.

Если бы вы писали на ruby, я бы спрашивал про gem. Если на чистом VimL либо указали бы какую‐либо достойную причину требовать отсутствие зависимостей от библиотек на Python — про VAM. (Честно говоря, я себе такую причину не могу представить совсем.)

KISS. Поэтому мне нравится патоген, и не нравится vundle и иже с ним.

Пользователь — это определённо на порядки более сложная система, чем менеджер пакетов. Поэтому полагаясь на пользователя как на его замену вы совершенно точно нарушаете этот самый KISS.

Люди также придумали кучу дистрибутивных менеджеров пакетов.

У powerline есть «пакеты» (точнее, ebuild и pkgbuild) для всех систем, используемых основными разработчиками. При использовании distutils создание пакета не составляет никакой проблемы для любого современного дистрибутива, пользователи которого считают, что оный им нужен. К примеру, насколько я знаю, есть аналог ebuild для Mac (что‐то с homebrew), описывающий автоматическую установку powerline, причём разработчики последнего его не писали.

А возможность установки с помощью distutils и setup.py означает автоматическую поддержку pip. (Точнее, поддержка pip означает использование setup.py.)

Верни аватарку из GTO привыкли же. Зачем ведёшься на всё это раздувание.

Что я сделал : 1) Во-первых, установка стиля должна происходить исключительно после создания QApplication. Делать так как было сейчас - грубая ошибка, ибо стиль можно установить в любой момент, а так как сейчас - нарушение логики в пух и прах. 2) Убрал PixmapCache - стало запускаться. 3) Убрал обработчик исключений и вижу что даже вызов Help->Codimension home page - вызывает кучу исключений, но через секунд 15 браузер таки начинает грузить сайт.

После шага 1 перестало падать сразу (это естественно что в текущем виде падает), после шага 2 стало проходить этап Creating layout.

Причем сейчас - среда на «Loading recent project» может висеть и минуту, интенсивно читая с диска что-то, но потом открывается.

Спасибо за проведенные эксперименты!

Делать так как было сейчас - грубая ошибка

Вот цитата из документации QT: «To ensure that the application's style is set correctly, it is best to call this function before the QApplication constructor, if possible.» По иронии судьбы, мой первый вариант был как раз сначала конструктор, а потом setStyle(...) хотя бы из соображений симметричности - пользователь может сменить стиль уже во время работы приложения. Но потом я наткнулся на приведенный выше абзац и поменял порядок. На 13.04 работает в обоих позах при всех доступных стилях. Может быть там уже поправили что-то. В любом случае, порядок изменен на более надежный и назад я его уже ни за что менять не буду.

Убрал PixmapCache - стало запускаться

Это странно. Ожидаемый результат - запуск после изменения порядка конструктор -> стиль. Еще один коллега жаловался на такое же поведение и ему помогло только изменение порядка. Однако, строчки с созданием кэша картинок можно убрать совершенно безопасно. Там все равно сделан singleton, который будет создан при первом вызове. Я уберу эти строки из следующего релиза.

Убрал обработчик исключений

Куча исключений опять-таки странна. Я подобного не наблюдал. Попробую сегодня вечером. А какие именно сообщения появляются? Еще более странно то, что этот обработчик для случая, когда поймано unhandled exception. Соответственно реакция на такое исключение - аварийное завершение, а у вас продолжает работать. Не понимаю, как такое возможно. Моя реализация нужна была только для того, чтобы информацию об исключении сохранить в файле и показать окошко перед закрытием. Но все равно - закрытием приложения.

на «Loading recent project» может висеть и минуту

Такое может быть, если вы завели проект в существующей папке, в которой много вложенных папок/файлов. Codimension в момент старта составляет список файлов проекта, определяя типы файлов, парсит все питон файлы и состовляет списки объектов проекта - функции, классы, глобальные переменные. Кроме того на каждый подкаталог создается watcher, чтобы отслеживать изменения со стороны: добавился / удалили файл из папок проекта => автоматически изменения будут произведены везде, в дереве проекта, в списках объектов проекта. Был один эпизод, когда коллега создал проект в папке, где уже было несколько десятков тысяч файлов. Открытие длилось еще дольше, чем у вас. Но открылось. Если большое количество файлов это не ваш случай, то значит это баг какой-то. Например, неверное определение типа каких-либо файлов. Я помню вы упоминали, что проект был создан в temp. А можете попробовать создать новую папку для проекта где-нибудь? Будет так же медленно?

Сергей

Бага в федоровском пакете

соберите же пакетик для федоры!

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

Сегодня сделан релиз IDE 2.0.2 и парсера 1.6.2 c исправлениями ошибок, замеченными посетителями linux.org.ru, но опять-таки, пакеты только для ubuntu. rpm планируется, но у Ильи - добровольца, который взялся помогать с пакетами, возникли какие-то сложности.

Как промежуточный вариант, могу описать как заставить работать codimension из чекаута из транка или из тэга.

А если можете помочь с подготовкой пакетов для rpm-based систем - еще лучше.

Сергей

Пришли обновления пакетов, это я так понял - пересобрали с исправлением ошибок?

Что касается с проектом вне temp а в отдельной папке - да, стало мгновенно загружаться.

И кстати, лучше создавать для проекта новую папку автоматически - не сложно ведь? Зато меньше вопросов от пользователей.

пересобрали с исправлением ошибок?

Да, поменян порядок создания QApplication и установки стиля, исправлены несколько мелких ошибок и добавлена новая фича - calltips. В парсере тоже есть исправление ошибки. Полные changelogs здесь: http://code.google.com/p/codimension/source/browse/trunk/src/ChangeLog и http://code.google.com/p/codimension/source/browse/trunk/pythonparser/ChangeLog

с проектом вне temp а в отдельной папке - да, стало мгновенно загружаться

Очень хорошо!

лучше создавать для проекта новую папку автоматически

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

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

Сергей