![[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
>брекпоинтам, только через жопу
не весь, а ключевые места. их не так много, на самом деле. у тебя виндовз головного мозга (не в обиду): там не принято, чтобы программы рассказывали военные секреты. а у меня юникс головного мозга: я считаю, что программа должна срать в логи как можно больше. причём юникс головного мозга у меня случился задолго до того, как я первую *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
т.е. ты про кэш процессора. опция линкера студии /ALIGN годится?
[ в релиз-версии софта, пожалуйста ]
в релизе и юниксы не умеют - разве что ценой навешивания тяжелой и медленной хуиты на распределитель памяти
no subject
при чём тут выравнивание? O_O во-первых, это совсем из другой музыки. во-вторых, я говорил про построчную раскладку исполнения с указанием, например, количества исполнений строки и количества cache miss там. ну, хотя бы это.
а надо оно, например, чтобы подогнать структуры данных, чтобы они пореже выпадали из кэша, и чтобы числодробилка со сложными данными (к примеру), считала не за неделю, а за пять дней. не спорю, задача несколько специфическая, однако это ж ты сказал, что студия сие умеет, не я.
хинт: да не мучайся ты, не умеет она; m$ сказала, что это не надо. ибо без денамического эмулятора машинного кода — коим и является valgrind — сие делать очень напряжно.
>в релизе и юниксы не умеют
благодарю, я долго ржал. надо сообщить авторам valgrind потрясающую новость, а то мужики не в курсе, что столько лет пилят неработающий софт. особенно охуеют те, кто этот неработающий софт успешно использует. %-)
зыж на винде, вроде бы, была в этом плане какая-то дорогая поделка от ню-мега. что она точно умеет — я не в курсе, ибо дохуя дорогая, а мне бабла жалко.
no subject
дык, размер страницы кэша 4096, выравнивание данных способствует уменьшению числа кэш-промахов.
[ я говорил про построчную раскладку исполнения с указанием, например, количества исполнений строки и количества cache miss там. ну, хотя бы это ]
благодаря выравниванию, это не нужно. компилятор сам подгонит, а не ты будешь подгонять
[ благодарю, я долго ржал. надо сообщить авторам valgrind потрясающую новость ]
а valgrind разве не меняет бинарник программы в сторону распухания и уторможения?
от нюмега называлась bounds checker. но, начиная, с 2008 это встроено в компилятор - но только в отладочной версии. релиз не засирает.
no subject
>компилятор сам подгонит, а не ты будешь подгонять
ниугадал. один, например, лишний байт в структуре вполне может вызвать большой катаклизм.
>а valgrind разве не меняет бинарник программы в сторону распухания и
>уторможения?
нет. он вообще ничего с оным бинарником не делает, окромя его исполнения (потому ему ваще срать, чем там что компилировалось и так далее; а если он обнаруживает инфу в формате gcc, то умеет и красивые развёртки с именами и строчками показывать). это таки весьма мощный исполнитель машинного кода x86/x64 с динамической рекомпиляцией и кучей гитик (благодаря чему не особо даже и тормозит). и благодаря этому он как раз может много разного.
>начиная, с 2008 это встроено в компилятор - но только в отладочной версии. релиз не
>засирает
ну да, опять отлаживают не то, что будет работать у юзера. за что мне и не нравятся подобные вещи: отлаживать надо то, что пойдёт в продакшн, а не искусственное непонятно что.
no subject
катаклизму надо ставить тем, кто создает такие структуры :)
[ он вообще ничего с оным бинарником не делает, окромя его исполнения ]
чаво? мы о релизе говорим? релиз будет исполняться valgrind-ом, а не сам по себе?
[ ну да, опять отлаживают не то, что будет работать у юзера. ]
чудес не бывает: либо у юзера будет работать быстро, либо со всякой трассировкой аллокаций
no subject
так вот чтобы сие понять, и надо на кэш посмотреть. вот убираем одно поле — и в кэш помещается 9e+3 всего. добавляем — и лезут промахи. вполне себе жизненная ситуация.
>релиз будет исполняться valgrind-ом, а не сам по себе?
а что такое «сам по себе»? O_O это тогда и без ядра ос, и без беблиотек? %-)
valgrind — это инструменталка. соответственно, ей скармливается то, что потом пойдёт «в печать». valgrind это исполняет и прилежно рапортует. если рапорт годный — «в печать» и идёт as is. если негодный — пилится дальше.
>либо у юзера будет работать быстро, либо со всякой трассировкой аллокаций
а при чём тут valgrind на стороне юзера? O_O
инструменталит софт девелопер, натурально. разница в том, что инструменталит он не некий непонятный код, собраный в «отладочном режиме», а самый что ни на есть боевой, который потом в неизменном (если повезло, и багов нет) виде пойдёт юзеру. таким макаром мы точно знаем, что проверяем именно юзерский вариант софта. ибо ты, думаю, не менее меня в курсе, как опции компилятора могут повлиять на забагованность.
конечно, остаются баги самого valgrind'а, но я за несколько лет ни разу на них не натыкался. а вот на «плавающие» ошибки, которые в «отладочном» варианте отсутствуют, а при сборке с -O3, например, в полный рост есть — это было не раз.
а вообще — ты не устал? мне уже как-то поднадоело срацца. давай объявим ничью. %-)
no subject
структура размером > 4K - не вполне жизненная :)
[ а что такое «сам по себе»? ]
без присутствия каких-либо следов валгринда на релиз машине
[ инструменталит софт девелопер, натурально. разница в том, что инструменталит он не некий непонятный код, собраный в «отладочном режиме», а самый что ни на есть боевой, который потом в неизменном (если повезло, и багов нет) виде пойдёт юзеру. ]
...в заинструменталенном (читай: тормозящем) виде.
пиздец.
[ мне уже как-то поднадоело срацца. давай объявим ничью. ]
я думал, мы вроде как не на победу чьей то точки зрения, а просто пиздели :) кое-что новое для себя по ходу узнал - о красноглазых :)
no subject
а вот несколько структур, которые ВНИЗАПНА! не помещаются в кэш парой полей — вполне жизненная.
>без присутствия каких-либо следов валгринда на релиз машине
натурально, так.
>…в заинструменталенном (читай: тормозящем) виде.
лолщито? я уже устал повторять, что релизный код — тот же самый, который гоняется под valgrind'ом. считай, что valgrind — это такой супервизор-частично-виртуализатор, только заточеный не на шуструю эмуляцию a-la vmware или vbox, а на сбор всяких данных об исполняющемся «родном» коде.
>я думал, мы вроде как не на победу чьей то точки зрения, а просто пиздели
ну да, если бы на победу — я бы раньше заебался. просто откровенно повторяться начинаем.
>кое-что новое для себя по ходу узнал — о красноглазых
и это для тебя было новостью? %-)
зыж я бы тебе предложил просто поставить valgrind, почитать доки и поиграться с ним. тогда масса непоняток пропадёт.
no subject
no subject
ну вот при чём тут распространение? у тебя какое-то непонятное убеждение, что valgrind неведомым образом «пристёгивается» к программе и живёт вместе с ней. откуда? O_O
я ж уже не раз пояснял, что это эмулятор-супервизор, и код, который он жуёт, как раз и есть обычный выход обычного компилятора, без спецзаглушек и спецмодулей. gcc -O3 shit.c → valgrind ./a.out → cp a.out ~happyuser/release. при этом средний пункт ничего не добавляет, не убавляет и смело может быть опущен: код от этого не меняется. valgrind всё делает в реальном времени. может, от этого у тебя непонятка — тебе показалось, что он сначала превращает бинарь в неведомую ёбаную хуйню, а потом пристёгивает свой рантайм? ни разу, всё «на лету», во время исполнения и исключительно в памяти.
именно поэтому valgrind можно натравить на любой «нативный» x86/x64 бинарь (даже на виндовый софт, который стартует через вайн, и не обязательно его собирать gcc).