не последние (продолжение следует) новости из мира id3project:
сегодня я доделывал обратное преобразование структур тегов в байт-последовательность. и всё бы хорошо,, ведь делается это просто: создаётся класс с одной полиморфной функцией(которая и делает преобразование) и для каждой структуры определяется как работает эта функция, а работает она рекурсивно - структуры-то составные,, вот и получается, что преобразование сложной структуры - это просто склейка преобразований её частей (и для частей выполняется тоже самое).
и вот из тех примитивов, для которых надо определять преобразование напрямую,, мне остались только числа (Integer) со значением размера. а тут особую сложность представляет такая неприятная штука как синхронизация "/ по англицки synchsafe integer - это что-то вроде синхробезопасное число о_О
я уже достаточно намучался с десинхронизацией в самом начале - поскольку размер тега и размеры фреймов в соответствии со стандартом id3v2.4 синхронизированы. до сих пор не понимаю зачем это вообще нудно делать /= но фиг с ним,, когда я разбирался с десинхронизацией, я не очень-то понял как она происходит,, грубо говоря, я просто взял какую-то готовую функцию на с++ и переписал на haskell'е. но теперь, когда мне нужно было сделать функцию обратную к этой - такой готовой в интернетах не нашлось. в общем мне пришлось разобраться с десинхронизацией и придумать обратную функцию для синхронизации. и я очень доволен что у меня это получилось (:
теперь вроде бы все структуры обратно-конвертируемы. и надо это проверять. то есть надо проверить на заданном множестве это преобразование - обратная к парсеру.
собственно будет повод разобраться с Quickcheck (или HUnit).
следующий шаг: тестирование, оформление и документирование того, что уже готово.
6 февр. 2009 г.
4 февр. 2009 г.
Трансформируемся! "/ тьфу! Абстрагируемся!
трудовой план на сегодня выполнен!
я внёс существенные изменения во внутреннюю структуру id3project. преобразования и улучшения были направлены на абстрагирование структур данных представляющих теги и их внутренности. теперь можно менять (усложнять/совершенствовать) эти структуры, не меняя при этом остальную часть библиотеки.
внешне же ничего не изменилось. по завершении работ, я запускаю тестовую программу точно также как и вчера,, и что я вижу?? да всё тоже самое! работает всё точно также как работало вчера, изменилиcm только внутренние связки и механизмы взаимодействия структур.
следующий шаг: обратное преобразование структур в данные для записи в файл.
я внёс существенные изменения во внутреннюю структуру id3project. преобразования и улучшения были направлены на абстрагирование структур данных представляющих теги и их внутренности. теперь можно менять (усложнять/совершенствовать) эти структуры, не меняя при этом остальную часть библиотеки.
внешне же ничего не изменилось. по завершении работ, я запускаю тестовую программу точно также как и вчера,, и что я вижу?? да всё тоже самое! работает всё точно также как работало вчера, изменилиcm только внутренние связки и механизмы взаимодействия структур.
следующий шаг: обратное преобразование структур в данные для записи в файл.
3 февр. 2009 г.
readTag :: FilePath -> IO ID3Tag
доделал сегодня в более или менее приемлемой форме часть id3project отвечающую за чтение тегов.
то есть группу модулей с парсерами и модуль-обёртку с функцией, которая просто берёт файл и выдаёт весь тег в виде структуры данных.
тип этой структуры объявлен членом класса Show - так что можно просто применить функцию print к тегу и он будет выведен на экран в аккуратном, читабельном виде. и вообще можно таким образом преобразовывать структуру в текст, если нас не интересуют внутренние нюансы структуры тега.
сделал-то в общем я вчера. но сейчас подправил обработку кодировки - вроде всё правильно работает.
на настоящий момент 100%-ного соответствия стандарту нету (кстати речь пока только о id3v2). поскольку там много тонкостей с флагами - во-первых я не очень понимаю назначение некоторых из них,, а во-вторых некоторые из них требуют использования дополнительных библиотек, как то компрессия или перекодирование фреймов и тому подобные хитрости.
из поддерживаемых фреймов - основные используемые и те, которые не требуют особенной обработки. надо ещё сделать парсинг фрейма с обложкой альбома - для этого тоже придётся использовать отдельную библиотеку, благо такая вроде бы уже есть в хаскелле.
100% поддержка стандарта пока не предполагается,, поскольку это не очень-то нужно. я полагаю что в тегах редко используется компрессия и тому подобные заморочки - никто не заморачивается. да и из фреймов используется небольшой набор. другое дело что попадаются те, которые используются в реальности, но не описаны в стандарте - например я встретил фрейм TYER который содержит год выпуска альбома, но в стандарте для этого используется TDRC. поэтому важно добавить поддержку "неофициальных", но реально используемых фреймов.
а так в общем-то всё здорово. следующий шаг - обратное преобразование: корректная запись абстрактной структуры тега в файл. дальше замена, добавление, удаление, редактирование тега - это всё просто. ну и разумеется надо сделать для этого какой-то интерфейс..
сложно придумать "интуитивно-понятный" интерфейс - это идеал. надо будет почитать ещё Джефа Раскина на тему интерфейсов - у него есть интересные идеи. хотя для меня Vim уже опроверг одну из его заповедей - он категорически против модальности (то есть интерфейса с режимами),, а у Vim'а на этом построена вся идеология - "в одном режиме он всё портит, а в другом бибикает" (:
то есть группу модулей с парсерами и модуль-обёртку с функцией, которая просто берёт файл и выдаёт весь тег в виде структуры данных.
тип этой структуры объявлен членом класса Show - так что можно просто применить функцию print к тегу и он будет выведен на экран в аккуратном, читабельном виде. и вообще можно таким образом преобразовывать структуру в текст, если нас не интересуют внутренние нюансы структуры тега.
сделал-то в общем я вчера. но сейчас подправил обработку кодировки - вроде всё правильно работает.
на настоящий момент 100%-ного соответствия стандарту нету (кстати речь пока только о id3v2). поскольку там много тонкостей с флагами - во-первых я не очень понимаю назначение некоторых из них,, а во-вторых некоторые из них требуют использования дополнительных библиотек, как то компрессия или перекодирование фреймов и тому подобные хитрости.
из поддерживаемых фреймов - основные используемые и те, которые не требуют особенной обработки. надо ещё сделать парсинг фрейма с обложкой альбома - для этого тоже придётся использовать отдельную библиотеку, благо такая вроде бы уже есть в хаскелле.
100% поддержка стандарта пока не предполагается,, поскольку это не очень-то нужно. я полагаю что в тегах редко используется компрессия и тому подобные заморочки - никто не заморачивается. да и из фреймов используется небольшой набор. другое дело что попадаются те, которые используются в реальности, но не описаны в стандарте - например я встретил фрейм TYER который содержит год выпуска альбома, но в стандарте для этого используется TDRC. поэтому важно добавить поддержку "неофициальных", но реально используемых фреймов.
а так в общем-то всё здорово. следующий шаг - обратное преобразование: корректная запись абстрактной структуры тега в файл. дальше замена, добавление, удаление, редактирование тега - это всё просто. ну и разумеется надо сделать для этого какой-то интерфейс..
сложно придумать "интуитивно-понятный" интерфейс - это идеал. надо будет почитать ещё Джефа Раскина на тему интерфейсов - у него есть интересные идеи. хотя для меня Vim уже опроверг одну из его заповедей - он категорически против модальности (то есть интерфейса с режимами),, а у Vim'а на этом построена вся идеология - "в одном режиме он всё портит, а в другом бибикает" (:
Подписаться на:
Сообщения (Atom)
