psilogic | Bard 0.1.3

Entry tags:

bard

Bard 0.1.3

Долгими зимними вечерами продолжаю ваять "Bard". Готова очередная бета: версия 0.1.3.

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

Эта версия - серьезный шаг, поскольку полностью переработано "ядро" - хранение промежуточных редактируемых данных. Переработка позволила сделать операции Undo/Redo практически мгновенными, понаделать легко и просто "preview" - но ценой отказа от немедленного save после каждой операции. Как следствие, autosave и autobackup убраны, теперь работа с файлом выглядит совершенно "стандартно": можно закрыть без сохранения и т.п.

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

На очереди две большие проблемы. Первая - приручение Wine. Вторая - возможность работать с плагинами VST (нашел документацию, буду делать). Пожелайте мне удачи - наступает трудный лично для меня этап: мне всегда было проще и приятнее писать своё, чем разбираться в чужих интерфейсах и прикручивать их.

Что касается испытаний для Wine, то пока все плохо. Первая попытка поставить убунту провалилась - инсталлятор линукса сначала показал 731% прогресса исполнения, а потом заявил, что отсутствует root file system или что-то в этом роде и предложил исправить дело в "partitioning menu", которое вызвать никак нельзя. На этом все и зависло. Я воспользовался инсталлятором убунты поверх винды (wubi.exe) и сказал ставить ее на свободный диск F. Там NTFS, подозреваю, что проблема в этом - хотя я надеялся, что инсталляшка по крайней мере сформатирует тот диск. Ан нет. Интересно, FAT32 ее устроит?

- Полный список изменений на странице загрузки
- Прямая ссылка для скачивания инсталлятора (11 Мб)
- Список возможностей редактора

Threaded | Top-Level Comments Only

>для реакций совсем другая схема
а какая? и ваще: покажи код, не жлобься. интересно же. обещаю ругаццо только по делу (скрестил за спиной пальцы %-).

[ как я давно говорю, исключения не надо отлавливать, их надо логировать и сразу падать нахуй. ]

зачем нахуй? хую больно =) ты так весь код себе "излоггируешь" - получатся та же самая отладка по брекпоинтам, только через жопу

[ а для этого у меня есть командная консоль и встроеный скриптовый язык. на котором я и стараюсь писать максимальную часть софта. опять отладчик не нужен. ]

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

[ как же вам тяжко-то без valgrind'а. а у нас этим занимается именно он. ]

"у нас" этим отладчик студии занимается - "именно он!" (C)

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

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

которая не засирает диск мусором :)

[ сначала полезно цель определить. как я написал, я не рассматриваю логи как «отладочный инструмент». ]

ну мы же рассматриваем замену отладчику - так? смотрим на кору в gdb, смотрим на аналогичную кору в студии - в студии в 10 раз меньше движений пальцами надо сделать, чтбы получить ту же инфу

вообще говоря, документация - это 50% крутости библиотеки. бывают охуенные по функцио-аналу библиотеки, но документация - сгенеренная или вовсе "читайте исходнЯки". с дрожью вспоминаю, как я ипался с FFMPEG...

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

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

>ну мы же рассматриваем замену отладчику — так?
ничего подобного. мы обсуждаем необходимость отладчика. если получится, что он не нужен — тогда глупо же будет заменять что-то ненужное, нес па?

>смотрим на кору в gdb, смотрим на аналогичную кору в студии - в студии в 10 раз меньше
>движений пальцами надо сделать, чтбы получить ту же инфу
да? O_O

а впрочем, да: там надо мышой возить. лично мне удобней набрать gdb

>вообще говоря, документация — это 50% крутости библиотеки
совершенно согласен, да. но мы же все знаем, как программисты обожают писать документацию… read the source, Luke!

схема из двух основных частей

1 - мессаги от виндов попадают в одно из окон, а потом начинают перекидываться по цепочке примерно в таком порядке, в каком имеют наибольший шанс быть "съеденными":

- от общей функции (типа handle(msg, WPARAM, LPARAM)) к частной (типа handle_key)
- от derived-класса к based-классу
- от child-окна к layout-у в котором оно лежит и далее по ветви к корню (parent-окну)

в какой-то момент мессагу кто-то съедает, просто прекратив пересылку по цепочке

там, где в QT пишется слот, я пишу виртуальную функцию, которая принимает мессаги нужного типа.

пример:

GDurationPlacer - это layout из десятка мелких окошек, который позволяет вводить время-длительность

bool GDurationPlacer::handle_changed(GChangedMessage &ev) //сообщения об важных изменениях
{
	GVisual *s= ev.source;
	if (NULL != s)
	{
		if (s == spBlock) // пришло сообщение от чайлда spBlock
		{
			convertToTime();
			send_changed_message(); //послать вверх сообщение от себя самого
		}
		else if (s == spMin || s == spSec || s == spMsec) 
		{
			convertToBlocks();
			send_changed_message();
		}
	}
    return GBaseClass::handle_changed(ev);//обработчик базового класса
}

про вторую часть щаз напишу

>ты так весь код себе "излоггируешь" — получатся та же самая отладка по
>брекпоинтам, только через жопу
не весь, а ключевые места. их не так много, на самом деле. у тебя виндовз головного мозга (не в обиду): там не принято, чтобы программы рассказывали военные секреты. а у меня юникс головного мозга: я считаю, что программа должна срать в логи как можно больше. причём юникс головного мозга у меня случился задолго до того, как я первую *nix-систему увидел. %-) отчасти это наследие DOS, где мелкий жоп часто приводил к весёлому ребуту.

>"у нас" этим отладчик студии занимается — "именно он!"
это опять ВГМ. у больных ЮГМ мнение другое: один инструмент для одной задачи. поэтому тот же valgrind состоит из нескольких программ, например.

кстати: не подскажешь, как мне у студии добыть хотя бы инфу по cache misses? нененене, покупать 3rd-party тулзы не предлагай, ты сказал, что оно это умеет.

ах, да, забыл:

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

а. то есть, стандарный старенький вариант, да. в принципе, мне лично неудобен, система подписки на сигналы лучше, мне кажется. в принципе, для неё даже отдельный препроцессор не нужен, можно на шаблонах нахреначить — libsig++, например.

то есть, в глубине Qt тоже, конечно, набор хандлеров, но он хорошо замаскирован. %-)

правда, в твоём варианте проще делать перехватчики, которые слопают или поменяют мессагу. в Qt есть фильтры, конечно, но выглядят как рукав на спине.

зыж а за скобочки на отдельных строках надо убивать, да. и за подчёркивания, потому что camelCase рулит. ну не смог удержаться! %-)

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

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

пример.

"аддон" GPipka :)) реализует любые "кнопкоподобные" элементы окон, начиная от обычной кнопки и кончая закладками в таббаре, кнопками тулбара и прочая и прочая. GPipka конструируется окном с "кнопкоподобными" элементами и начинает слать особые "пипочные" сообщения:

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

- и собственно главному окну стается минимум функционала: сказать, где у него "кнопкоподобное", не "задисаблено" ли оно - ну и отреагировать на нажатие

так это, по моему, и есть сигналослоты, только немножко наизнанку вывернуте, не?

Да, стандартный лежит в основе - а то что к нему добавлено - так это аккуратный "поток" сообщений от одного объекта к другому, пока не доедят. что приятно - да, с .moc-ами заморачиваться не нужно, нет никаких жутких макросов {AFX-чего-то там} как в MFC

У меня обычно подчеркиваниями "выделяются" хандлеры и всякие коллбэки - так удобнее, сразу ясно, что вот handle_changed/send_changed_message будут дергать по событиям (handle_ - извне, send_ - вовне). А вот convertToTime - это некая функция общего вида.

в принципе, с теми же моками проблем нет, потому что qmake генерит вполне себе рабочий Makefile. я, правда, make ненавижу лютой ненавистью, а написать обёртку для любимого jam всё никак не соберусь.

а подчёркивания я ненавижу потому, что с паскаля начинал. а там сие не принято. %-)

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

Qt мне, кстати, нравится ещё и тем, что с ним stl нахуй не нужен. а stl я иррационально ненавижу.

imho совсем из другой оперы. это ты как если бы в Qt обработчик сигнала конструировал из нескольких стандартных разноуровневых модулей, которые реализуют куски поведения. скажем, часто бывает надо нажать мышой и куда-то потянуть - вот чтобы каждый раз не писать код, который слушает мышку, реагирует на нажатие, реагирует на отпускание, отслеживает изменение, корректно все завершает - пишется 1 раз "аддон" GMouseDragger, которые потом присобачивается к окну и генерирует уже выокоуровневые сообщения типа: "мышь начала тянуть"/"мышь тянет"/"мышь закончила". А поверх этого может быть другой аддон, который на этих сообщениях реализует, скажем, drag-drop

ггг
у меня от STL только std::map, используемая в нескольких глубокожопных местах :) а так - тонна самопальных контейнеров. не так чтобы сильно отличающихся от STL по идеологии, просто больше функций и не надо писать длиннющие std::vector<хуй>::iterator...

особливо я люблю GBag - это хрень, куда можно сериализовать все подряд и потом доставать обратно

а, да, до меня потом дошло.

кстати, в Qt так тоже можно, тащемта.

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

[ ничего подобного. мы обсуждаем необходимость отладчика ]

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

[ да? O_O ]

да-а :) стек уже виден сразу. один клик - и показывается код, относящийся к этому уровню стека. в gdb понадобится 10 тыканий в клавиши, чтобы добраться до сорцов.

в gdb ты пишешь: print ... - а тут просто наводишь мышь на нужную переменную, всплывает ее значение - одно движение

чисто эргономически выгодно получается

ты про какие еще cache misses?

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

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

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

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

я, в принципе, вообще мышь стараюсь по минимуму использовать, она только темп сбивает.

[ вот это и есть офигенно неудобно, как по мне. надо рукой тащиться до мыши, елозить, потом назад… ]

в counter-strike такие получают пулю в лоб, едва выйдя из базы (найдя выход через 2 минуты после начала раунда) - и потом кричат "читер! читер!" :)))

>ты про какие еще cache misses?
а про те самые, когда программа промахивается мимо процессорного кэша. valgrind мне это покажет и расскажет, и я пойму, что надо делать с данными и прочей ерундой (и кодом тоже, хихикс), чтобы промахивалось оно реже. такой себе кусочек профайлера.

>когда в 1 инструменте 10 функций — это значит…
…что он удобен так же, как молоток, привареный к микроскопу. а также то, что его нельзя разломать на элементарные инструменты и построить всё заново, но чуть-чуть по другому. фича никсового «один инструмент для одного действия» именно в том, что инструменты можно соединять при необходимости, получая такой себе «метаинструмент». например, для того же gdb есть kdbg — гуя. всё, что они делают — рулят gdb. но выглядит — как гуёвый дебаггер. или для valgrind — kcachegrind, визуализатор, потому что сам valgrind не умеет ни хрена рисовать (да и не должен). а если бы всё было напихано в gdb, пришлось бы делать одни большие универсальные гуя, которые и сложнее, и памяти жрут больше.

Threaded | Top-Level Comments Only

Page 3 of 4

Bard 0.1.3

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject