Для нашей задачи нам понадобится небольшие познания в программировании на Delphi, бесплатные компоненты из набора «Embedded Web Browser».
В самом начале нам требуется иметь установленную Delphi7, и наличие соединения с Интернет, для проверки работы программы.
Для начала скачаем и установим их. Сам компонент расположен тут — bsalsa.com/DP/download.php?file=0.

Недавно вышла в свет версия 3.2.2 объектно-ориентированнаго языка «Парсер», последнее обновление которого было немного ни мало почти два года назад.

Вот заявленые улучшения:

Parser 3 — простой и удобный объектно-ориентированный язык, позволяющий быстро создавать хорошие сайты.

* Теперь на 30% удобнее!
* Новое ядро (переработанное и, разумеется, улучшенное)
* Новый улучшенный синтаксис
* Поддержка XML, XSL, XPath и DOM
* Доступен в документированных исходных текстах
* Расширенная поддержка баз данных
* Поддержка объектно-ориентирующихся программистов
* Подробная документация по языку на русском языке (160 страниц!)
* Поддержка UTF-8
Веб-сайт языка → http://www.parser.ru/

Такой вот новогодний подарок для тех кто использует этот язык в своей работе.

… А кто-то вообще использует?

Прямо перед новым годом некто Лебедев сообщил в новостях Студии о том, что вышла новая версия Parser. Сразу после этого некто fuksitofuksito запостил тему «Объектно-ориентированный язык от „Студии Артемия Лебедева“». Тема вызвала бурную дискуссию: кто-то просто высказывался, кто-то умудрился опустить ближнего своего ниже плинтуса, кто-то… В общем атмосфера накалилась по самое нехочу.

Так вот, чтобы не говорить что-то типа «Прочитал новость. Прочитал комменты. 160 страниц руководства. Пришёл к выводу -> Дерьмо полное», я откинулся в кресле, поёрзал недвижимостью так, чтобы найти наиболее удобное положение для долгого сидения и принялся вчитываться в документацию Парсера.

Мой вердикт?

У меня есть идея и работающий макет CMS. Рабочее название — Одминко :-) Я хотел бы, чтобы она (CMS) развилась до уровня коммерческого продукта. Один я не смогу довести проект до такого уровня. Нужно принять решение, что дальше с проектом делать.

sspp маленький парсер написанный на php для сортировки и анализа server-status

Проверяет на валидность json код, строит разного вида древа элементов.

Проект парсера

Решил как-то упорядочить избитую проблему: практически в каждом проекте приходится делать кастомный парсер, который бы выводил текст в удобочитаемом виде. И практически в каждом проекте 80% этого парсера — это решение уже решенных задач.

StringParser — это плагин к Рельсам и либа, которая включает методы, реализующие наиболее часто встречающиеся задачи парсинга. Давайте я покажу на примере:

StringParser.new("what a cool url: url.com and image image.com/image.jpg<br/>").urls_to_images.urls_to_links.html_escape.string

То же самое можно оформить в блоке (это кому как больше нравится):

parser = StringParser.new("what a cool url: url.com and image image.com/image.jpg<br/>") do |p|
p.urls_to_images.urls_to_links
p.html_escape
end
parser.string

Я просто приведу названия методов, которые я уже успел закодить, а более подробнее описание можно найти в доках или в исходниках:

break_long_words
close_tags
cut
highlight_code # использует для подсветки gem ultraviolet
html_escape # в отличие от рельсового аналога принимает :except => []
newlines_to_br
urls_to_images
urls_to_links

Хотел бы пригласить всех дополнить либу и довести до ума.

На хабре проскакивали статьи про PHP и Javascript beautifier'ы, но для SQL запросов я тут ничего не нашёл. Постараюсь исправить этот пробел.

Наиболее популярный SQLinForm. Единственный минус этого решения является требование Java Runtime.

Менее «фичастый» и более удобный для работы Instant SQL Formatter. Пример работы можно посмотреть здесь.

Я только что защитил свой отчёт по практике «Создание сайта и его продвижение в поисковых системах». В связи с этим хотелось бы также услышать мнение читателей Хабра по моей работе. Результат работы — сайт EasySki.ru. В данном посте хочу рассказать Вам о процессе создания сайта.

В марте от хабраюзера Wave появилась новость, заставившая затрепетать сердца всех любителей фрэймворка CodeIgniter: вот-вот должна появиться версия 2.0 этой ляльки. И вот, прошло уже больше двух месяцец, а воз и ныне там, «двушка» для скачивания с офф.сайта так и недоступна.

И все бы ладно, да очень не хватало метода, который обещали внедрить во вторую версию фрэймворка — parse_string() в классе Parser, который бы позволил нам парсить шаблоны не только из файлов, но и из переменных. А так, как в одной из моих разработок есть потребность хранить небольшие шаблончики в БД, то, так сказать, стало мне невтерпеж.

Хвала разработчикам, нам дали возможность расширять все стандартные классы, чем мы и воспользуемся.

За реализацией этого метода — добро пожаловать под хаброкат.

В общем, наверное, как и другой любой начинающий JavaScript прогрммист (2 года назад), мне хотелось все реализовать своими руками. Так возникло ужасающее очень быстрое регулярное выражение из 280 символов.

Немного истории

Приблизительно полтора года назад, я узнал о библиотеке yass, которая была самым быстрым инструментом для поиска DOM элементов в JavaScript по CSS селекторам (ссылка на тесты).
И тут у меня возник ужасный интерес. Я захотел придумать способ, который будет еще быстрее. В то время я как раз читал книгу «Регулярные выражения Библиотека программиста» второе издание от Дж. Фридла. И вот… Это было лето, я еще был студентом и у меня была масса времени. Работа закипела…

 

Добро пожаловать в Главу 2 учебника «Создание языка программирования с LLVM». В этой главе мы увидим, как использовать лексический анализатор, созданный в Главе 1, чтобы построить полный синтаксический анализатор для нашего языка Kaleidoscope. После того, как у нас будет готов парсер, мы будем строить Abstract Syntax Tree (AST) (Абстрактное синтаксическое дерево).

Недавно возникла необходимость в парсере интернет-счета банковской карты для дальнейшего уведомления об операциях посредством смс\e-mail. Сделать это было решено по-быстрому шел-скриптом, который будет парсить страницу со счетом с определенной периодичностью при помощи задания в cron, а в случае изменения баланса счета — высылать сообщение на мобильный телефон или e-mail. Ничего сложного на первый взгляд, однако в ходе написания пришлось решить некоторые сложности, о которых вы сможете прочесть под катом.

Детерминированный конечный автомат можно использовать для реализации очень быстрого способа разбора входной последовательности. Требуется всего один проход по входной последовательности, и минимальные действия на каждом шаге. К сожалению эта модель имеет ограничения — не всегда возможно построить ДКА, для имеющегося Недетерминированного конечного автомата (регулярного выражения, грамматики). Или даже если возможно построить, автомат может иметь слишком большое число состояний.

Тем не менее я решил попробовать создать парсер для HTTP запроса на основе ДКА. Основная задача не просто проверить корректность HTTP запроса, а именно выделить во входной строке элементы соответствующие определенным значениям полей HTTP запроса. Автомат должен генерироваться из BNF правил (разбросанных по) RFC2616. Реализовано все на C#, автомат на выходе тоже на C#. Хотя понятно что когда автомат готов, сгенерировать его на любом языке, в любом виде не проблема.

Вступление

Уже около двух лет я участвую в OpenSource проекте SourceAnalyzer, и вот появилась необходимость написать парсер для языка Python, который должен уметь строить граф вызовов (Call Graph) и граф зависимостей классов (Class Graph Dependency). Если точнее, граф строится с помощью других инструментов, а парсер должен лишь подготовить для этих инструментов данные.

Процесс работы над парсером был довольно занятным и мне бы хотелось поделиться с вами приобретенным опытом, а также поведать о некоторых подводных камнях, которые встретились на этапе разработки.

Начиная с версии Python 2.7, в набор стандартных библиотек была включена библиотека argparse для обработки аргументов (параметров, ключей) командной строки. Хотелось бы остановить на ней Ваше внимание.

Перевод статьи The MediaWiki parser, uncovered.

Актуальность перевода статьи 2009 года в том, что, во-первых, костяк парсера с тех пор существенно не поменялся, и во-вторых, с ним приходится ежедневно сталкиваться тем, кто пишет расширения для Mediawiki, на котором крутятся их корпоративные сайты.

Парсер Mediawiki — фундаментальная часть кода движка Mediawiki. Без него вы бы не смогли вставлять в свои статьи Википедии различные метки: секции, ссылки или картинки. Вы даже не смогли бы увидеть или быстро изменить разметку других статей. Вики-разметка достаточно гибка, чтобы дать возможность одинаково легко писать статьи как новичкам, так и HTML-экспертам. Из-за этого код парсера несколько сложноват, и с годами проходил через множество попыток его улучшить. Тем не менее, даже сегодня он все еще достаточно быстро работает для Википедии, одного из самых больших веб-сайтов в мире. Давайте взглянем на внутренности этого ценного (но чуть-чуть заумного) куска кода.

Переписывал в островке кусок одного сервиса с Python на Erlang. Сам сервис занимается тем, что скачивает по HTTP значительное количество однотипных HTML страниц и извлекает из них некоторую информацию. Основная CPU нагрузка сервиса приходится на парсинг HTML в DOM дерево.

Сперва захотелось сравнить производительность Erlang парсера mochiweb_html с используемым из Python lxml.etree.HTML(). Провел простейший бенчмарк, нужные выводы сделал, а потом подумал что неплохо было бы добавить в бенчмарк ещё парочку-другую парсеров и платформ, оформить покрасивее, опубликовать код и написать статью.
На данный момент успел написать бенчмарки на Erlang, Python, PyPy, NodeJS и С в следующих комбинациях:

• Erlang — mochiweb_html
• CPython — lxml.etree.HTML
• CPython — BeautifulSoup 3
• CPython — BeautifulSoup 4
• CPython — html5lib
• PyPy — BeautifulSoup 3
• PyPy — BeautifulSoup 4
• PyPy — html5lib
• Node.JS — cheerio
• Node.JS — htmlparser
• Node.JS — jsdom
• C — libxml2 (скорее для справки)

В тесте сравниваются скорость обработки N итераций парсера и пиковое потребление памяти.

Интрига: кто быстрее — Python или PyPy? Как сказывается иммутабельность Erlang на скорости парсинга и потреблении памяти? Насколько быстра V8 NodeJS? И как на всё это смотрит код на чистом C.

В рамках создания фреймворка для некоторой системы Enterprise класса, у меня стояла задача создания утилиты для автоматизированной генерации кода по UML модели. Ничего наиболее подходящего для быстрого и эффективного решения задачи, кроме как использование Ruby, и встроенного шаблонизатора ERB, под руку не подвернулось.

Файл проекта из среды UML моделирования представлял собой базу данных формата SQLite3, однако некоторую часть информации в этой БД среда хранила в виде сериализованных в BLOB поля объектов. Формат сериализации был текстовый, но не совместимый ни с одним из известных, такими как XML, YAML, совсем отдаленно напоминал JSON. Использовать существующие в природе парсеры было невозможно.

В простых случаях, когда вам не требуется весь объект целиком, а только пара скалярных полей конкретной инстанции, то конечно можно тупо добраться до нужного регулярками. В противном случае, есть универсальное решение проблемы, позволяющее быстро создавать собственные парсеры для подобных структур, десериализующие их в объекты Ruby.