пятница, 16 ноября 2012 г.

FarColorer включен в официальный дистрибутив Far Manager

Случилось неожиданное, но очень приятное событие. С 12.11.2012 плагин FarColorer включен в официальную поставку Far Manager.
Теперь, при каждой ночной сборке Far, будет так же собрана текущая версия (trunk) FarColorer. Так же происходит сборка схем и цветовых стилей.

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

Так получилось, что это событие совпало с открытием у меня странички "Проекты" (в шапке). На ней поднят Redmine - багтрекер. В нем создан проект "Colorer Library".
Данный проект является зеркалом проекта Colorer Library на sourceforge.net .
Цель создания зеркала:
  • решить проблему с медленной работой сайта sourceforge.net
  • использование нормального функционала по управлению проектом
  • создание Issue и контроль их исправления
Теперь все полученные ошибки и пожелания я заношу туда. Так проще отслеживать что нужно сделать - ранее страдал забывчивостью, да простит меня Roman Kuzmin -).
Создавать Issue на данном сайте имеет смысл только для FarColorer. Для остальных подпроектов Colorer Library следует использовать основной сайт . При необходимости они будут продублированы на этом сайте мной.

четверг, 18 октября 2012 г.

Особенности использования git subtree

В Git есть замечательная возможность по внедрению в проект внешних проектов, называемая Subtree Merging. Её плюсы в том, что можно править код этого внешнего проекта и при необходимости/возможности вносить эти изменения в его хранилище. так же легко и прозрачно сливать новые изменения из этого внешнего проекта к себе.
Но не все так просто. В приведенной выше ссылке на главу книги, посвященной под-деревьям, не говорится о том, при сливании в свой проект свежих изменений из внешнего проекта вы теряете свои локальные изменения данного проекта.  Единственное упоминание об этом я нашел только в документации по модулю git-subtree, который является альтернативным способом использования под-деревьев.
merge::
 Merge recent changes up to <commit> into the <prefix> subtree. As with normal 'git merge', this doesn't remove your own local changes; it just merges those changes into the latest <commit>. With '--squash', creates only one commit that contains all the changes, rather than merging in the entire history.
Правильной стратегией использования под-деревьев является следующее:
  1. влить в свой проект внешний проект, как это описано в инструкции
  2. если требуются изменения в локальной копии внешнего проекта - делаем их и коммитим.
  3. если требуется слить к себе изменения внешнего проекта, то в начале нужно слить локальные изменения этого проекта в бранч (созданный на шаге 1). Cливать той же командой, что и из бранча к себе
     git merge --squash -s subtree --no-commit your_branch
    Ну а затем делаем pull из внешнего проекта, в результате которого локальные изменения сливаются с внешними. Далее сливаем бранч к себе.
Жаль, что данное поведение не описано было. Начал проект, опираясь на под-деревья. И пройдя много коммитов напоролся на такую проблему. Ушло много времени, чтобы разобраться.

понедельник, 8 октября 2012 г.

Colorer 1.0.3.12 и обновления схем


Colorer 1.0.3.12 для Far 3

Изменения
  1. Плагин адаптирован под Far3 build 2876 API
  2. исправлена ошибка чтения настроек
Изменения схем
New:
- powershell (Roman Kuzmin)
- R (Roman Kuzmin)
- Lemon Parser Generator (Aleksey Dobrunov)
- json (Aliaksei Chapyzhenka)
- LLVM IR (Aliaksei Chapyzhenka)
Fixed:
- sql - 'end' for case block; fixed qualified host variables
- csharp - add struct in outlined; keyword 'var'; simple parse verbatim string
- php - php 5.4 support: traits, binary numbers, some functions deprecation (lazyeugene)
- less - some fixes (lazyeugene)
- SilverStripe - some fixes (lazyeugene)
- css - new keywords (lazyeugene)
- cobol - many fixes (Pavel Pleva)
- cobolfr - many fixes (Pavel Pleva)
- jcl - many fixes (Pavel Pleva)
- makefile- fixed comment after var definition (Pavel Pleva)
- pl1 - many fixes (Pavel Pleva)
- sh - fixed --eq (Pavel Pleva)
- graphviz - updated for Graphviz 2.28 (Roman Kuzmin)

Измененные схемы так же можно скачать отдельно по ссылке hrc-update.2012-10-08.zip

среда, 26 сентября 2012 г.

FarColorer 1.0.3.11

К очередному большому слому API в Far новая версия плагина.
Colorer 1.0.3.11 для Far 3

Изменения
  1. Плагин адаптирован под Far3 build 2838 API
  2. Исправлена ошибка вставки текста по ctrl+Enter из outline

понедельник, 26 марта 2012 г.

FarColorer 1.0.3.10



Colorer 1.0.3.10 для Far 3

Изменения
  1. Плагин адаптирован под Far3 build 2573 API
  2. Выводим название текущего региона, а не родительского в меню "Данные региона"
Изменения схем
New:
- UniVision Basic (Pete Howell)
- markdown (Roman Kuzmin)
- squirrel
Fixed:
- matlab - try/catch support
- postscript - add keyword
- fix error in csharp, markdown, pl1, ubasic
- c-win32.ent - add keyword, constants
- c.hrc - printf format string


среда, 14 марта 2012 г.

FarColorer 1.0.3.9 и обновление схем


Colorer 1.0.3.9 для Far 3

Изменения
  1. В меню добавлен пункт вывода имени региона и схемы под курсором
  2. Исправлено: после смены цветового стиля не происходило обновление экрана
  3. Реализован вызов плагина из макросов по callplugin 
Изменения схем
New:
- SHPAML (Eric Gustavson https://github.com/occulens/shpaml-colorer)
- Less Css (lazyeugene)
- SilverStripe (lazyeugene)
Fixed:
- Far MacroLib
- Far.hrc - new in Far3
- Html - pair tags, conditional comments (IE) , new tags and etc. (lazyeugene)
- CSS - new keywords (lazyeugene)
- ASP - insertions in the scipt tags (lazyeugene)
- php - new keywords, json, OAuth; function name and constants case insensitive (lazyeugene)

Измененные схемы так же можно скачать отдельно по ссылке hrc-update.2012-03-15.7z

воскресенье, 8 января 2012 г.

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

Очень часто C++ упрекают в том, что в нем сложно управлять памятью. Постоянно программисты забывают освобождать указатели. Из-за этого падают программы, или в лучшем случае съедают много памяти. Сам часто делаю такие ошибки, благо современный инструментарий позволяет находить такие ошибки. Но самое главное, ты сам можешь управлять памятью. Хочешь - выделил, хочешь удалил. Свобода выбора.
Другое дело встроенные в ПО языки программирования. Например Oracle PL/SQL.
Последние пару месяцев довелось проводить нагрузочное тестирование продукта, работающего на Oracle 10g. Куча тестов, снятие трейсов, анализ трейсов. Рекомендации по оптимизации, патчи. Вроде все нормально. Но как обычно, пришел он. Писец. Процессы на базе данных съели всю память, PGA вырос до максимума, база встала. Налицо серьезная утечка памяти.
Первая мысль - сейчас возьмем какой-нибудь инструмент для oracle и найдем, что течет. Ха, нет такого. DBA говорят, что есть вроде тузла, но плохо документирована, и они её сами не знают. Поиск в гугле по возможному поиску утечек памяти говорит только об оном - снять дамп памяти с процесса и провести анализ. Что этот анализ даст не очень понятно.
Вторая мысль - у нас ведь есть код. Будем в нем искать. Но что может течь в pl/sql ? встроенные типы number, varchar ? более сложные структуры ? в pl/sql нет понятия деструктора. Присвоил переменной значение, попользовался, забыл. Oracle сам подчищает. Максимум для массивов можно и нужно вызывать удаление всех элементов. Плюс в некоторых пакетах, работающих с clob и xml, нужно вызывать методы очистки. Хотя по умолчанию, время жизни у них в пределах функции.
Поиск по коду, комментирование кусков кода и т.п. в итоге указало на массив с переменными типа xmltype. Но все было корректно с точки зрения кода. Печальный вывод - бага oracle.  Oracle сам управляет памятью, мы ничего не можем вручную удалить (кроме массива). При присвоениях переменным результата работы функции мы не знаем, что будет сделано с памятью - будет копирование, или присвоение указателя на кусок памяти. Мы отданы на милость Oracle и его баги.
Для подтверждения лезем на металинк и ищем похожие ошибки. И оказываемся не одинокими. Куча ошибок с утечкой памяти в xmltype. Патчи? не, вы обновитесь на 11g (задача не тривиальная, и требующая проверки всего кода на совместимость), там скорее всего нормально. А если нет, мы вам выпустим патч на 11g. И сплошь попытки найти ошибки в коде заявителей. К нашей радости, мы нашли обходной путь для очистки памяти.

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