— во-первых, переводить текст Никиты на хабре — это LOL
— во-вторых, шёл 2018-й год, а люди до сих пор мучаются открывать и читать большие (0.5G+) файлы редакторами (в комментах 200M, блин, те же вим и емакс легко справляются с этим, правда у них тоже есть разумный предел — на моей памяти у емакса — 1.5G, у вима — 2G — ну т.е. открывает, но ходить по файлу уже неприятно).
— далее, камушек в свой огород. брался написать анализатор XML как-то и, как водится, не довёл эту активность до конца. каюсь, грешен. интересно, подобный софт всё ещё нужен кому-то, кроме моего бывшего работодателя?!
en.wikipedia.org уау будующее
#2808429 над XML 3.5 ГБ (one-line) или 4 ГБ (pretty-printed): Haskell вполне годится для потоковой обработки XML.
Тесты производились с помощью tagsoup + fast-tagsoup на ручной нарезке ленивых ByteString на чанки размером ~20 МБ (так, чтобы не разрезать события SAX парсинга).
Это Win!
Следите за ленью, юзайте beautiful folds (https://hackage.haskell.org/package/folds-0.6.3) и будет вам счастье!
Ухожу в подполье.
По итогам проведения разных тестов в Тесты производились с помощью tagsoup + fast-tagsoup на ручной нарезке ленивых ByteString на чанки размером ~20 МБ (так, чтобы не разрезать события SAX парсинга).
Это Win!
Следите за ленью, юзайте beautiful folds (https://hackage.haskell.org/package/folds-0.6.3) и будет вам счастье!
Ухожу в подполье.
Lazy ByteString хорошо, но долго.
Добавляем туда замечательных фолдов, просто считаем число событий, максимально не ленясь. Для начала.
Итого 1035 секунд на 3.5 ГБ.
Strict ByteString хорошо, но сразу не хватает памяти.
Думаю, раз такое дело, то стоит дробить Strict ByteString на куски определенного размера +- несколько десятков байт на то, чтобы гарантированно попасть на границу событий. И затем передавать вычисленный аккумулятор дальше по списку.
Думаю, так оно быстрее выйдет.
Если мы рассмотрим XML как цепочку символов StartTag a, EndTag a, Content a (или как говорят в соответствующей литературке — SAX), то совсем нетрудно будет заметить что он относится к классу языков сбалансированных скобок, т.е. не является регулярным.
Это не является проблемой самой по себе: мы всегда можем построить КА для разбора конкретной цепочки, и даже множества цепочек... Чем, собственно говоря, и занимаемся путём ваяния XML-схем различной степени упоротости.
А если есть способ? Нет понятно дело, можно перейти на новый уровень, взять МП-автомат и невозбранно юзать контекстно-свободные грамматики. Но тогда мы теряем всю алгебраическую вкусноту, присущую регулярным языкам... А в реальном мире алгебраические свойства регулярных языков куда важнее, чем возможность допускать более «широкие» множества цепочек!
Нет. Именно способ разбирать языки сбалансированных скобок, сохраяняя при этом все свойства регулярных языков. Как оказалось — есть!
Интуитивным объяснением почему КА не может разбирать языки сбалансированных скобок является отсутствие «памяти» . А если эту память можно присобачить?
Встречайте: Nested Word Automata (автоматы вложенных цепочек), а точнее его практическую реализацию Visibly Pushdown Automata.
Идея в том, что данный автомат жрёт три разных типа символов: «call» — обозначается как <a, «internal» — обозначается как a и «return» — обозначается как a>. Соответственно и функция переходов распадается на три: для символов «call» принимает текущее состояние и входящий call-сивол и возвращает следующее состояние и сивол который нужно засунуть на вершину стека, для «internal» принимает текущее состояние и входящий internal-символ и возвращает следующее состояние (т.е. как обычный КА), для «return» принимает текущее состояние, входящий internal-символ и символ с вершины стека и возвращает следующее состояние.
Т.е. в резултате мы получили класс МП-автомата, который не может за один символ запихивать и выпихивать символ из стека. Это повлияло на количество распознаваемых языков, но позволило сохранить свойства регулярных языков!
Более того, если у нас есть дерево t(a, b(c, d), e), то мы его можем закодировать как цепочку <t <a a> <b <c c> <d d> b> <e e> t>, т.е. ровно по такому же принципу как это делают SAX-парсеры.
За последний десякток лет была масса исследований на эту тему. С подборкой можно ознакомиться
madhu.cs.illinois.edu
cis.upenn.edu
Основополагающя статья Adding nesting structure to words: cis.upenn.edu
Слайды: cis.upenn.edu (с них лучше начать).
А теперь пара вопросов касательно первотега:
1. Неоднократно слышал что applicative-парсеры описывают регулярные языки. Где можно об этом почитать?
2. Кто-нибудь сталкивался с реализациями МП-автоматов на Х-е? Будут полезны также всякие LR/GLR/LALR реализации.
P.S.: Сабж применяется не только к XML, и вообще первоначально применялся для анализа программ, отсюда и call- и return- терминология.
linux.org.ru ) никто не предложил DocBook XML. Похоже, это то, что нужно. И позволит унифицировано задействовать разметки в других форматах, хоть Markdown, хоть AsciiDoc. Надо будет попробовать задействовать на практике.
Забавно, что пару лет назад, когда меня интересовал промежуточный слой XML для хранения логики BB-code разметки перед конвертацией в HTML ( Не, ясен пень, нужно сварганить простейший конечный автомат (вернее, трансдюсер), который будет разбивать поступающие на вход байтстринги на более мелкие байтстринги (ленивые, без копирования). А вот как это сделать в реале?
Перейти на стринги, перейти на текст? Важна даже не столько вычислительная сложность. Важно чтобы реализация как можно меньше сношала сборщик мусора.
Обойти — не вариант. Во-первых, такое поведение — MUST. Во-вторых, без реализации такого поведения к чертям полетит вся кошер^W каноничность.
Умные люди вообще считают что если закодировать XML бинарным деревом, то задачи валидации/навигации сведутся к SAT, и выдвигают туеву хучу вариантов реализации.
Есть и другая техника кодирования: карринг (или как её называют в TATA, extension encoding). Но почему-то я не нашел ни одной статьи по этому поводу.
Ну ёб вашу мать.
Дано: порождающая грамматика g, дерево t полученное из дерева x, которое производит парсер XML. Нужно проверить что дерево t может быть порождено g.
Тогда задача будет состоять из двух этапов:
1. Описать преобразование x -> t, т.е. XMLTree -> OurDomainTree. Это задача обычного парсера, с самой обычной КС-грамматикой. ЧСХ, на этом этапе будет задетекчены практически все возможные ошибки XML, собранного printf, а именно: отсутствующие аттрибуты, нарушение формата аттрибутов, левые теги, левые аттрибуты.
2. Проверить что дерево t может быть порождено g.
Как я понимаю, для «сферического XML в вакууме», будет достаточно самой обычной КС-грамматики, причем в LR(1) форме (рекурсивно, снизу-вверх и так далее...). Подойдет, наверно, и PEG. А в некоторых случаях и вообще регулярные грамматики. Например, моя задача ничего кроме Нетерминал/нетерминал/.../терминал не предусматривает.
Более того, грамматика g послужит железобетонной базой для определения катаморфизмов для t.
Вопрос, что можно почитать по п. 2? Может быть кто-то что-то похожее уже делал?
Короч, нашел texml генерю xml для него, оно высирает latex.
Само все искейпит, полет нормальный.
Правда пришлось повозиться когда надо вводить незаэскейпеные символы для латеха,
но накидал простой DSL, все норм.
fdik.org
YSLT — XSLT C style
Ссылка на YBlog2 битая, правильная — auchdieserschwachsinnmussinsinternet.de
А вообще я смотрел на этот проект: beremiz.org
YSLT — XSLT C style
Ссылка на YBlog2 битая, правильная — auchdieserschwachsinnmussinsinternet.de
А вообще я смотрел на этот проект: beremiz.org
Но блять, схемостроители, и уж тем более тулзы автоматизации построения схем, везде лепять именно ёбаный сиквенс! A это нихуя не сахар, если ты валидируешься по чужой схеме.
manifest.sysapps.org JSON захватывает (уже захватил) разум веба. Чем эта лапша лучше XML — не понятно :3
<ExtraDataItem name="GUI/DetailsPageBoxes" value="general,preview,system,display,storage,audio,network,usb,sharedFolders,description"/>
В другом месте увидел список путей через точку с запятой.
Имхо можно было разбить на отдельные ноды, и сунуть их внутрь... Мда, не понимаю.
webmasters.stackexchange.com "вывернулся" подставив '. См. unclev.ru
There was a task to evaluate bash variables within an XML. I couldn't cope with apostrophe. But found out webmasters.stackexchange.com and solved by replacing apostrophe character with '. See unclev.ru
Задачка подствить в XML переменные из bash-скрипта. Не смог справиться с апострофом. С учётом вот этого There was a task to evaluate bash variables within an XML. I couldn't cope with apostrophe. But found out webmasters.stackexchange.com and solved by replacing apostrophe character with '. See unclev.ru
1. SQL — в выбранных данных кавычка меняется на '<![CDATA['+replace(fieldname,'"', '\"')+']]>', т.е. экранируется по-хитрому
2. XML — поле выводится отдельным элементом, а не аттрибутом. можно. например, воспользоваться конструкцией [node!2!fieldname!xml]
3. XSL — убираются всякие disable-output-escaping="yes", т.е. не делается ничего. но не забыть что это не аттрибут и в <xsl:value-of select="fieldname"/> без @
4. JS — приготовленный в п.3 json использовать AS-IS (протестировано с document.createTextNode)
5. HTML — добавить CSS по вкусу, подавать свежим =)
котаны, а как в xpath получить значение атрибута? ну у меня есть вот такое: <?xml version="1.0" ?> <ipmi> <bmc_reset> <state code="ok"/> </bmc_reset> </ipmi> я пишу > root.xpath('//state/@code') > ['ok'] это оно типа список выдало, а можно как-то без списка? ну, [0] я то могу добавить в конце, но это помоему не то
А теперь можете меня бить: $messages = $xml->xpath('/validationErrors/validationError/message'); $messages = json_decode(json_encode($messages), TRUE);
1) установить пакеты ztcl, tclmore
deb people.debian.org etch main
либо ждите пока в вике выложат актуальную информацию: en.tkabber.jabe.ru
хотя тут актуально: =) ru.tkabber.jabe.ru
2) также нужна библиотека zlib (вероятно zlib1g или zlib1, в крайнем случае исходники где-то здесь: zlib.net )
3) в настроках выбираем Login->::::loginconf(stream_options) или в окне логина выбираем вкладку SSL&Сжатие
ставим там Сжатие или Шифрование (STARTTLS). наслаждаемся =)
не забываем сохранить в настройках эту опцию для текущей и следующих сессий.
cherianajay.hubpages.com
На волне обсуждения html — говно, наткнулся на возможность создания кастомных html-тегов с помощью js.
На волне обсуждения html — говно, наткнулся на возможность создания кастомных html-тегов с помощью js.