Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Короче говоря, мой вики-конвертер (дядя Макс, не надо? могу поделиться 
) тоже все почти "в лоб" решает — из-за большой "нерегулярности" вики-разметки.
ЗХ>Я покрутил-покрутил ее с недельку в попытках написать простого формата расширяемый конфиг, да и.... захардкодил. 
ЗХ>Така грустна история.
Я тоже могу "похвастаться" своим подходом
, буду рад, если навеет какие-нибудь мысли.
Поскольку исходный формат не поддается четкому описанию в терминах формальной грамматики (на самом деле, конечно же поддается, но превышает все разумные пределы по сложности), то я сразу отверг классический однопроходный конечный автомат и сделал конвейер, который в несколько проходов преобразует "неформальный" синтакс в строгую well-formed XML-like структуру, то есть,
\element[attributes]{content}
Разметка "нерегулярна"? Что надо сделать? Формализовать и "регуляризировать"!
Например, toc_structurizer преобразует:
\h1{Part}
. . .
\h2{Chapter}
. . .
\h3{Section}
. . .
. . .
\h2{Another Chapter}
. . .
в следующую строгую иерархическую стркуктуру:
\h1[Part]
{
. . .
\h2[Chapter]
{
. . .
\h3[Section]
{
. . .
. . .
}
}
\h2[Another Chapter]
{
. . .
}
. . .
}
Далее, обрабатываюся параграфы, то есть, просто-напросто, куски текста, отделенные пустой строкой обрамляются в
\p{. . .}
После чего, обрабатываются списки и так же формализуются в \ol{...}, \ul{...}, \li{...}
То же происходит с таблицами, линками, декорированием wiki-like элементов. На выходе всего этого дела получается well-formed структура, которую очень легко преобразовать в XML/HTML, и т.д. Фактически, методом контекстной замены. Для каждого типа элемента в конфиге определяются его обрамляющие таги, которые в частном случае могут быть и пустыми. Ну, плюс еще есть доступ к псевдо-переменным, типа $(this.content), $(this.attribute.image), и т.д. Вместо "this" можно получить доступ к любому элементу, либо от корня, типа $(title.content), либо от текущего узла, например, $(../../menu.content).
Когда абсолютно все сущности формализованы подобным образом, синтакс и содержимое конфига уже не составляют проблемы.
ЗХ>ЗЫ: у меня в результате получился формат конфига такой, что, чтобы его разобрать, по уму надо было бы сделать еще один расширяемый парсер и конфиг к нему 
А у меня конфиг парсится тем же самым примитивным базовым парсером:
\tr_open [<TR>]
\tr_close [</TR>]
\thr_open [<TR>]
\thr_close [</TR>]
\th_open [<TH>]
\th_close [</TH>]
\td_open [<TD>]
\td_close [</TD>]
\tdr_open [<TD style="text-align:right">]
\tdr_close [</TD>]
\tdc_open [<TD style="text-align:center">]
\tdc_close [</TD>]
\tdj_open [<TD style="text-align:justify">]
\tdj_close [</TD>]
Более того, оглавление и индекс тоже собираются в отдельный файл такой же структуры, после чего снова парсится:
\toc
{
\toc1[Rendering Buffer; anchor="toc0001";]{
\toc2[The First and the Simplest Example; anchor="toc0002";]{}
\toc2[Class rendering_buffer; anchor="toc0003";]{}
\toc2[Two Modifications of the Example; anchor="toc0004";]{}}
\toc1[Pixel Format Renderers; anchor="toc0005";]{
\toc2[Creation; anchor="toc0006";]{}
\toc2[Member Functions; anchor="toc0007";]{}
\toc2[Alpha-Mask Adaptor; anchor="toc0008";]{}}
\toc1[Basic Renderers; anchor="toc0009";]{
\toc2[Creation; anchor="toc0010";]{}
\toc2[Member Functions; anchor="toc0011";]{}
\toc2[A common example; anchor="toc0012";]{}}
\toc1[Primitives and Markers Renderers; anchor="toc0013";]{
\toc2[Primitives Renderer; anchor="toc0014";]{
\toc3[Declaration; anchor="toc0015";]{}
\toc3[Creation; anchor="toc0016";]{}
\toc3[Member functions; anchor="toc0017";]{}}
\toc2[Marker Renderer; anchor="toc0018";]{
\toc3[Declaration; anchor="toc0019";]{}
\toc3[Creation; anchor="toc0020";]{}
\toc3[Member Functions; anchor="toc0021";]{}}}
}
Это надо для того, чтобы была возможность быстрой перегенерации только изменившихся файлов с использованием прежнего индекса и оглавления.
Данный подход тоже не лишен недостатков, например, очень тяжело становится ассоциировать номера строк с исходным файлом для выдачи синтаксических ошибок. Однако, мне он все-таки представляется наиболее оптимальным по соотношению трудозатрат к результату с минимумом рака головы
Кстати, можете посмеяться еще и вот над чем.
Базовый парсер создает в памяти некую псевдо-DOM структуру с возможностью рекурсивного доступа ко всем элементам. Но эта структура потом обрабатывается примитивным рекурсивным процессором, который вызывает абстрактный event-driven consumer в SAX-режиме(!) (там всего 3 функции, start_element, content, end_element), То есть, рекурсия таким образом линеаризуется, но зато консьюмеры неизбежно становятся конечными автоматами (хоть и примитивными). Не знаю, что лучше, рекурсия или конечные автоматы. По мне так чем меньше рекурсии, тем лучше. Умственный мозг у меня какой-то не очень рекурсивный
Здравствуйте, c-smile, Вы писали:
CS>Согласен! За! Теорию знаю! Твою статью прочитал в свое время, кул! Но!
CS>Мне не надо 12.67! Вообще! У меня в то место палец попасть вообще не должен.
CS>Как художник художнику:
CS>У меня 16 на 16 пикселей. Итого 256 родимых.
CS>Я хочу что-бы линия начиналась пикселом № 21 и заканчивалась № 220.
CS>Начало и конец — это принципиально. Как она раскрасится посредине (линия наклонная) это уже не важно (лишь бы "антиалиаснуто").
На самом деле, надо и то и другое.
CS>Если я захочу то я могу выставить на самом деле и 12.67. Хочу я этого числа правда не часто.
CS>Т.е. нужен snap-to-grid с интеллигентной оптимизацией от "антиалиасера" в случае привязанного (snap'нутого) отрезка.
CS>Вот. Это конечно не строгое определение но близко.
Snap-to-grid — действительно архиважная задача, причем, не обязятельно к пикселам. В той же самой XaraX Snap-to-grid формально присутствует, но когда делаешь copy/paste привязка тут же теряется. Нафига он такой Snap-to-grid уперся?! Да и вообще, парадигма copy/paste в существующих редакторах устарела как дерьмо мамонта. Вот пример грамотного copy/paste в моем понимании:
http://www.rsdn.ru/Forum/Message.aspx?mid=780253&only=1Автор: McSeem2
Дата: 26.08.04
Рисуем некую молекулу из шаблонов (несколько бензольных гаек), далее — Lasso, выделяем, Ctrl-C, Ctrl-V и enjoy
Далее, мощность процессоров возросла настолько, что для несложных сцен можно все перерисовывать заново, а не использовать всякие устаревшие XOR-режимы для рисования управляющих элементов. Собственно, так оно и делается в скетчере.
MS>>Я могу войти в долю, сделав собственно рендерер, то есть набор классов типа Java2D или Quartz с необходимой функциональностью для рисования как основного канваса, так и контролов. Разумеется, со всеми прибамбасами, гаммами и прочими омегами.
CS>Вот а еще если при этом к DOM можно будет достукиваться да c-smile(JavaScript) управлять можно вообще
CS>строить генераторы изображений.
CS>Да любая Вижуал Студия с руками ногами оторвет.
Я не был бы столь оптимистичен, то тоже думаю, что время пришло.
Здравствуйте, McSeem2, Вы писали:
CS>>Как художник художнику:
MS>Snap-to-grid — действительно архиважная задача, причем, не обязятельно к пикселам. В той же самой XaraX Snap-to-grid формально присутствует, но когда делаешь copy/paste привязка тут же теряется. Нафига он такой Snap-to-grid уперся?! Да и вообще, парадигма copy/paste в существующих редакторах устарела как дерьмо мамонта. Вот пример грамотного copy/paste в моем понимании:
MS>http://www.rsdn.ru/Forum/Message.aspx?mid=780253&only=1Автор: McSeem2
Дата: 26.08.04
"Офигеть!" Извиняюсь за вульгаризм. Но the Sketcher меня убил
Только сейчас его увидел.
Toolbar конечно отдает "Mac'сизмом" но ведь прелесть же!
Шляпу снимаю
MS>Рисуем некую молекулу из шаблонов (несколько бензольных гаек), далее — Lasso, выделяем, Ctrl-C, Ctrl-V и enjoy
MS>Далее, мощность процессоров возросла настолько, что для несложных сцен можно все перерисовывать заново, а не использовать всякие устаревшие XOR-режимы для рисования управляющих элементов. Собственно, так оно и делается в скетчере.
MS>Я не был бы столь оптимистичен, то тоже думаю, что время пришло.
Конечно, но!
"Дорогу осилит идущий".
Здравствуйте, c-smile, Вы писали:
CS>Макс, там в Sketcher у тебя похоже WM_ERASEBСKG не перекрыта.
CS>Мигает на ресайзе, а не должно.
Совершенно верно. Это я разбирался с WinAPI AlphaBlend(), чтобы буфер можно было делать полупрозрачным. А вырубить WM_ERASEBСKG потом забыл. А полупрозрачность работает в лучшем виде, например, для windowless activex:
http://antigrain.com/stuff/sketcher_ie.png (175k).
MS>Да и вообще, парадигма copy/paste в существующих редакторах устарела как дерьмо мамонта. Вот пример грамотного copy/paste в моем понимании:
Old like mammoth's manure
(c) описание Antigrain
... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is playing "Silence">>
Здравствуйте, c-smile, Вы писали:
CS>Toolbar конечно отдает "Mac'сизмом" но ведь прелесть же!
Когда заканчивается trial period, надо не просто ограничиваться скучным окошком с надписью о том, что пора бы заплатить, а при этом еще продолжать функционировать, но "красиво"
http://antigrain.com/stuff/sketcher2.zip (370K)
Вроде бы ничего особенного, но попробуйте что-нибудь дорисовать. А как красиво работает Lasso — чтобы включить, нажмите Ctrl-L
