![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
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 Мб)
- Список возможностей редактора
Учтены многие пожелания и нарекания френдов. Те, что еще не учтены, можете не повторять, у меня все записано и распланировано до версии 0.2. Но, если найдете новые баги - очень хорошо.
Эта версия - серьезный шаг, поскольку полностью переработано "ядро" - хранение промежуточных редактируемых данных. Переработка позволила сделать операции Undo/Redo практически мгновенными, понаделать легко и просто "preview" - но ценой отказа от немедленного save после каждой операции. Как следствие, autosave и autobackup убраны, теперь работа с файлом выглядит совершенно "стандартно": можно закрыть без сохранения и т.п.
Внешний вид переработан в угоду эстетам - теперь окно основного редактора выглядит так.
На очереди две большие проблемы. Первая - приручение Wine. Вторая - возможность работать с плагинами VST (нашел документацию, буду делать). Пожелайте мне удачи - наступает трудный лично для меня этап: мне всегда было проще и приятнее писать своё, чем разбираться в чужих интерфейсах и прикручивать их.
Что касается испытаний для Wine, то пока все плохо. Первая попытка поставить убунту провалилась - инсталлятор линукса сначала показал 731% прогресса исполнения, а потом заявил, что отсутствует root file system или что-то в этом роде и предложил исправить дело в "partitioning menu", которое вызвать никак нельзя. На этом все и зависло. Я воспользовался инсталлятором убунты поверх винды (wubi.exe) и сказал ставить ее на свободный диск F. Там NTFS, подозреваю, что проблема в этом - хотя я надеялся, что инсталляшка по крайней мере сформатирует тот диск. Ан нет. Интересно, FAT32 ее устроит?
- Полный список изменений на странице загрузки
- Прямая ссылка для скачивания инсталлятора (11 Мб)
- Список возможностей редактора
no subject
к сожалению, нет. то ублюдство, что там дают, даже на самокат не тянет, а ты его с «ламборджини» сравниваешь.
>основной плюс отладчика с GUI — минимальное время для ловли багов
неа. основной плюс отладчика с гуями — это помощь в имитации работы.
— чо делаешь?
— да вот, отлаживаю.
— а, ну-ну, молодец, работай дальше.
а время, затраченое на поиск ошибок, только увеличивается. потому что долбаггер вынимаем мозги и заменяет их тыцаньем по брякпоинтам в надежде, что как-нибудь, да осенит.
no subject
неужели у "ламборджини" есть удобный GUI?
(кажется, я знаю ответ...)
[ а время, затраченое на поиск ошибок, только увеличивается ]
докажи =)
no subject
>докажи
интересно, как ты это представляешь? %-)
no subject
фишка в том, что это сильно от разрабатываемой программы зависит - не везде отладчик поюзаешь. но там, где можно поюзать, он экономит время.
а про тупое тыцанье по брякпоинтам - это из разряда "зелен виноград" в басне Крылова :)
no subject
а) сразу делать много вкусных логов в софте (очень полезная привычка, кстати сказать; вообще, любой софт сложнее «привета» должен, ящитаю, иметь командную консоль a-la Quake, куда активно и срать);
б) при помощи оных логов быстро локализовать место ошибки и прибить оную путём чтения-правки исходника.
вот честно: сколько у меня было ошибок — отладчик мне помогал только наиболее продуктивно просрать время, тупо трассируя говнокод. но отучался я от него с матом, конечно, ибо пялиться в отладчик очень увлекательное занятие (как и многая другая бессмыслица).
no subject
А вот, скажем, отлов исключения ДО момента его выброса без перекомпиляции. Или edit-and-continue для ситуации, которую трудно воспроизвести. Или отлов момента переполнения буфера непонятно кем и непонятно, когда - после того, как тот же отладчик уведомил о переполнении и сказал ГДЕ.
no subject
как я давно говорю, исключения не надо отлавливать, их надо логировать и сразу падать нахуй. натурально, если софтина ведёт аккуратный лог, то по нему вполне себе понятно, что произошло. отладчик снова не нужен.
>Или edit-and-continue для ситуации, которую трудно воспроизвести
а для этого у меня есть командная консоль и встроеный скриптовый язык. на котором я и стараюсь писать максимальную часть софта. опять отладчик не нужен.
>Или отлов момента переполнения буфера непонятно кем и непонятно, когда — после
>того, как тот же отладчик уведомил о переполнении и сказал ГДЕ.
как же вам тяжко-то без valgrind'а. а у нас этим занимается именно он. в том числе он умеет сообщать и про использование непроиниченых переменных (с чем компилятор справляется далеко не всегда), и про то, куда память проебалась и где она была выделена, и строить профили cache miss, и ещё over 9000 гитик. и всё это, заметим, без перекомпиляции или линковки специальных «отладочных» библиотек. достаточно догадаться не стрипать символы — и всё будет в лучшем виде. и снова — да — отладчик не нужен.
отладчик — это такой инструмент, который издалека кажется полезным, а вблизи оказывается гибридом ёжика и бензопилы: смешно, забавно, бесполезно и неудобно.
no subject
зачем нахуй? хую больно =) ты так весь код себе "излоггируешь" - получатся та же самая отладка по брекпоинтам, только через жопу
[ а для этого у меня есть командная консоль и встроеный скриптовый язык. на котором я и стараюсь писать максимальную часть софта. опять отладчик не нужен. ]
отладчик вообще не нужен. он только ускоряет процесс. это надо писать консоль, скриптовый йэзыг... а в нем тоже логи? а для логов еще один язык? :)
[ как же вам тяжко-то без valgrind'а. а у нас этим занимается именно он. ]
"у нас" этим отладчик студии занимается - "именно он!" (C)
ежиком тоже надо уметь пользоваться :) а если в молодости был травмирующий опыт ... тогда канэшна, "все бабы бляди!" :)
no subject
>брекпоинтам, только через жопу
не весь, а ключевые места. их не так много, на самом деле. у тебя виндовз головного мозга (не в обиду): там не принято, чтобы программы рассказывали военные секреты. а у меня юникс головного мозга: я считаю, что программа должна срать в логи как можно больше. причём юникс головного мозга у меня случился задолго до того, как я первую *nix-систему увидел. %-) отчасти это наследие DOS, где мелкий жоп часто приводил к весёлому ребуту.
>"у нас" этим отладчик студии занимается — "именно он!"
это опять ВГМ. у больных ЮГМ мнение другое: один инструмент для одной задачи. поэтому тот же valgrind состоит из нескольких программ, например.
кстати: не подскажешь, как мне у студии добыть хотя бы инфу по cache misses? нененене, покупать 3rd-party тулзы не предлагай, ты сказал, что оно это умеет.
no subject
когда в 1 инструменте 10 функций - это значит, что ты 10 раз не отвлекаешься на то, чтобы лезть я ящик с инструментами. на 11-й раз таки лезешь, но 10 минут - сэкономил.
no subject
а про те самые, когда программа промахивается мимо процессорного кэша. valgrind мне это покажет и расскажет, и я пойму, что надо делать с данными и прочей ерундой (и кодом тоже, хихикс), чтобы промахивалось оно реже. такой себе кусочек профайлера.
>когда в 1 инструменте 10 функций — это значит…
…что он удобен так же, как молоток, привареный к микроскопу. а также то, что его нельзя разломать на элементарные инструменты и построить всё заново, но чуть-чуть по другому. фича никсового «один инструмент для одного действия» именно в том, что инструменты можно соединять при необходимости, получая такой себе «метаинструмент». например, для того же gdb есть kdbg — гуя. всё, что они делают — рулят gdb. но выглядит — как гуёвый дебаггер. или для valgrind — kcachegrind, визуализатор, потому что сам valgrind не умеет ни хрена рисовать (да и не должен). а если бы всё было напихано в gdb, пришлось бы делать одни большие универсальные гуя, которые и сложнее, и памяти жрут больше.
no subject
а, хз, никогда такого не попадалось. да и на хуя непонятно :)
[ …что он удобен так же, как молоток, привареный к микроскопу. ]
нет, в том то и дело. до такой степени аналогия не работает. когда брекпоинт ставится прямо на текст сорца - это совмещение отладчика и редактора. но это удобнее, чем просмотр сорца в самом крутом редакторе а потом ввод имени функции в самом крутом отладчике.
в юниксах роль таких инструментов играют всякие bash-ы/шеллы - на них висит миллион разных разномастных функций
[ но выглядит — как гуёвый дебаггер ]
опечатка: хуёвый дебаггер :)
no subject
чтобы структуры данных, например, покрасивше уложить. ибо кэшэвая память шустрей. и, поскольку ты сказал, что у вас этим занимается студия, то моя хотеть знать, как там это сделать.
вопрос номер два будет — как мне от студии получить список потеряной памяти (с местом, где конкретно выделили и разворотом вызовов) и такой же список мест, где программа читала из неинициализированной памяти (то бишь, умудрилась взять значение непроиниченой переменной). только костыли с линковкой каких-то отладочных библиотек и прочего не предлагать. в релиз-версии софта, пожалуйста.
>но это удобнее, чем просмотр сорца в самом крутом редакторе а потом ввод имени
>функции в самом крутом отладчике.
достаточно спорное утверждение. ну и, конечно, Emacs никто не отменял.
>всякие bash-ы/шеллы — на них висит миллион разных разномастных функций
you are terribly wrong. видишь ли, у нас очень дешёвый запуск процесса. поэтому шеллу достаточно уметь примитивнейший язык -- условие там, цикл, переменные, запуск процесса. всё остальное делается как раз внешними командами.
bash, конечно, тот ещё монстрик, но это гнутая болезнь. в оригинале sh (да и сейчас такие есть) даже математики ни фига не умел, зато имелась внешняя команда expr. так же, как внешняя команда [ (да-да, скобочка), которая умела вычислять всякие условия (а sh не умел). это вот и называется unix way, тащемта.
>опечатка: хуёвый дебаггер
это характеристика абсолютно любого долбагера. %-)
(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
это глупое сравнение. совсем без кода никак - значит есть смысл сравнивать один и другой код. а логи - с каким-то другим методом для той же цели.
[ что забавно — я с годами пришёл ко мнению, что логи необходимы всегда. ]
дык, если без отладчика жить - куда деваться? только аналогами студенческих printf-ов восполнять пробелы, так сказать :)
[ особенно когда программа работает хуй знает где, да ]
особенно когда программа работает чуть ли не у меня на хуе =)
no subject
сначала полезно цель определить. как я написал, я не рассматриваю логи как «отладочный инструмент».
>студенческих printf
отчего же «студенческих»? думаешь, если у тебя watch window, это не тот же самый printf? да тот же самый, тащемта.
хотя да — я, конечно, использую gdb. как post mortem debugger.
no subject
ну мы же рассматриваем замену отладчику - так? смотрим на кору в gdb, смотрим на аналогичную кору в студии - в студии в 10 раз меньше движений пальцами надо сделать, чтбы получить ту же инфу
no subject
ничего подобного. мы обсуждаем необходимость отладчика. если получится, что он не нужен — тогда глупо же будет заменять что-то ненужное, нес па?
>смотрим на кору в gdb, смотрим на аналогичную кору в студии - в студии в 10 раз меньше
>движений пальцами надо сделать, чтбы получить ту же инфу
да? O_O
а впрочем, да: там надо мышой возить. лично мне удобней набрать gdb
no subject
это бессмысленно. в конечном счете вообще ничего не нужно - все баги можно отловить вдумчивым чтением кода. речь идет о том, что отладчик - инструмент, который выигрывает час или минуту из конечной жизни программиста. если, конечно, им пользоваться с умом - можно ведь и гаечным ключом гвозди забивать, а молотком пытаться гайку отвинтить
[ да? O_O ]
да-а :) стек уже виден сразу. один клик - и показывается код, относящийся к этому уровню стека. в gdb понадобится 10 тыканий в клавиши, чтобы добраться до сорцов.
в gdb ты пишешь: print ... - а тут просто наводишь мышь на нужную переменную, всплывает ее значение - одно движение
чисто эргономически выгодно получается
no subject
натурально. однако же я веду к тому, что некоторые инструменты, предназначеные жизнь упрощать, как раз её усложняют. и поэтому их надо не заменять, а просто выкидывать.
>наводишь мышь
вот это и есть офигенно неудобно, как по мне. надо рукой тащиться до мыши, елозить, потом назад… а в gdb есть автодополнение. pr . в итоге, как не смешно, получается быстрее. по крайней мере, у меня. и целиться никуда не надо.
я, в принципе, вообще мышь стараюсь по минимуму использовать, она только темп сбивает.
(no subject)
(no subject)
(no subject)
(no subject)