Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>CSV подходит под нетривиальный парсер? ) А JSON подходит? ) G>>CSV на несколько порядков проще, так как CSV описывается регулярной грамматикой. JSON в этом плане почти также сложен, как XML.
_>JSON почти также сложен, как XML?
Да.
_>>>А зачем писать парсер с нуля?) Естественно надо пользоваться удобными инструментами. О чём и было сказано в моём первом сообщение. G>>Написание парсера с нуля полезно как упражнение на понимание проблем и их решений. Если не понимаешь этих проблем, то вряд ли сделаешь парсер с приемлемой производительностью. _>В качестве обучения конечно же полезно. Но мы тут вроде бы совсем другое обсуждаем...
Мы тут обсуждаем "быстрые и простые парсеры", понимание нужно чтобы разбираться какая связь между простотой и скоростью парсера.
G>>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит.
_>А если он возьмёт в руки скажем bison+flex? )))
Ага, и доку на 900кб прочитает (три войны и мира в объеме). Ты думаешь это так просто, взять и написать парсер нетривиального яызка? Даже с тулами? Как минимум про грамматики надо прочитать, понимать что такое лексеры и парсеры, зачем они нужны, уметь отличать LL от LR и от GLR, понимать что такое lookahead.
Здравствуйте, alex_public, Вы писали:
_>Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит.
Более чем хватит для чего? Чтобы хоть как-то заработал конечно хватит. Если для обработки сотен тысяч сериализаций-десериализаций в секунду, то вряд ли.
Здравствуйте, gandjustas, Вы писали:
g> _>Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит.
g> Более чем хватит для чего? Чтобы хоть как-то заработал конечно хватит. Если для обработки сотен тысяч сериализаций-десериализаций в секунду, то вряд ли.
В ветке в основном обсуждалось использование json для конфига и в таком случае(1-2 файла и относительно редкое чтение) куцая грамматика 'на спирите' (если учесть что boost и так используется в проекте) будет не таким уж плохим решением.
Здравствуйте, Dziman, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
g>> _>Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит.
g>> Более чем хватит для чего? Чтобы хоть как-то заработал конечно хватит. Если для обработки сотен тысяч сериализаций-десериализаций в секунду, то вряд ли.
D>В ветке в основном обсуждалось использование json для конфига и в таком случае(1-2 файла и относительно редкое чтение) куцая грамматика 'на спирите' (если учесть что boost и так используется в проекте) будет не таким уж плохим решением.
Для конфигов это совершенно быссмысленно. Объем кода для парсера будет в разы больше больше, чем суммарный объем кода, который конфиг использует. Поэтому вдвойне важно иметь готовый парсер.
_>Однако если мне потребуется работа с JSON в моём проекте, я не побегу делать парсер на спирите, а возьму готовую библиотечку.
Вот именно. _>Ну а про "несколько строк на спирите" я упомянул в качестве оценки сложности парсера JSON и сомнительности выражения "промышленные парсеры json". )))
Надеюсь, теперь сомненительность выражения развеяна?
S>>И ключ к такой международной кооперации как раз во внятной спеке, на которую мы можем полагаться.
_>Это о чём вообще речь? ) Об api библиотек? Так он же у каждой библиотеки свой...
Речь о том, что мы с производителем библиотеки одинаково понимаем, что такое JSON. Например, оба ожидаем, что duplicate keys запрещены.
Или оба ожидаем, что выигрывает последнее значение. А не так, что я считаю корректным только какое-то одно поведение, а производитель парсера считает, что он волен выбирать поведение по своему вкусу. И вот он в ответ на какую-нибудь жалобу от тех, кому надо коммутировать JSON со скоростью 2GB/sec немножечко меняет внутреннее устройство, и для duplicate keys возврашается первое значение, а не последнее. Потому что он вообще думал, что такого JSONа не бывает, и во всех его тест кейзах ключи уникальны. Так что у него регрессия пролетает на ура, а я огребаю мучительную отладку тикета у удалённого клиента, потому что хрен его пойми, откуда что берётся.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
_>>JSON почти также сложен, как XML? G>Да.
Ты серьёзно? ))) Ну ок... Я тут уже приводил полную грамматику json'a (правда в синтаксисе спирит'а, но это не суть). Можешь привести аналогичное для xml? )
G>>>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит. _>>А если он возьмёт в руки скажем bison+flex? ))) G>Ага, и доку на 900кб прочитает (три войны и мира в объеме). Ты думаешь это так просто, взять и написать парсер нетривиального яызка? Даже с тулами? Как минимум про грамматики надо прочитать, понимать что такое лексеры и парсеры, зачем они нужны, уметь отличать LL от LR и от GLR, понимать что такое lookahead.
Для нетривиального языка конечно (там кстати и bison не особо подходит). Но мы же тут не C или вообще C++ обсуждаем, а простенький JSON...
Здравствуйте, gandjustas, Вы писали:
D>>В ветке в основном обсуждалось использование json для конфига и в таком случае(1-2 файла и относительно редкое чтение) куцая грамматика 'на спирите' (если учесть что boost и так используется в проекте) будет не таким уж плохим решением. G>Для конфигов это совершенно быссмысленно. Объем кода для парсера будет в разы больше больше, чем суммарный объем кода, который конфиг использует. Поэтому вдвойне важно иметь готовый парсер.
Какое в разы больше? ) Я же чуть выше уже показывал пример задания грамматики json'a для спирита. Там короткий элементарный код.
Здравствуйте, Sinclair, Вы писали:
_>>Ну а про "несколько строк на спирите" я упомянул в качестве оценки сложности парсера JSON и сомнительности выражения "промышленные парсеры json". ))) S>Надеюсь, теперь сомненительность выражения развеяна?
Разве что после начала массового применения тех самых json парсеров с SIMD. )
S>>>И ключ к такой международной кооперации как раз во внятной спеке, на которую мы можем полагаться. _>>Это о чём вообще речь? ) Об api библиотек? Так он же у каждой библиотеки свой... S>Речь о том, что мы с производителем библиотеки одинаково понимаем, что такое JSON. Например, оба ожидаем, что duplicate keys запрещены. S>Или оба ожидаем, что выигрывает последнее значение. А не так, что я считаю корректным только какое-то одно поведение, а производитель парсера считает, что он волен выбирать поведение по своему вкусу. И вот он в ответ на какую-нибудь жалобу от тех, кому надо коммутировать JSON со скоростью 2GB/sec немножечко меняет внутреннее устройство, и для duplicate keys возврашается первое значение, а не последнее. Потому что он вообще думал, что такого JSONа не бывает, и во всех его тест кейзах ключи уникальны. Так что у него регрессия пролетает на ура, а я огребаю мучительную отладку тикета у удалённого клиента, потому что хрен его пойми, откуда что берётся.
Ааа, ну это другой вопрос. ) Вообще я помнится видел в каком-то стандарте требование на уникальность ключей в json. Так что если кто-то не соблюдает, то...
Здравствуйте, netch80, Вы писали:
N>Да вот берут, постоянно. Предпочитают изобретать собственные стандарты (bencode, protocol buffers и тому подобное), gzip-овать XML и JSON, лишь бы к ASN.1 не приближаться. Мне это тоже немного непонятно, чисто практические наблюдения.
Насколько мне известно (сам не трогал, сужу с чужих слов и статей) для ASN.1 до сих пор нет нормальных бесплатных инструментов. Для Си вроде(?) что-то есть, для java, C#, python, js и тому подобного — нет, а ведь разработчику потребуется структуры протокола отображать в структуры языка, "простым" использованием сишной библиотеки (которая то ли есть, то ли нет) не обойдешься.
Здравствуйте, Sinclair, Вы писали:
S>Или оба ожидаем, что выигрывает последнее значение. А не так, что я считаю корректным только какое-то одно поведение, а производитель парсера считает, что он волен выбирать поведение по своему вкусу. И вот он в ответ на какую-нибудь жалобу от тех, кому надо коммутировать JSON со скоростью 2GB/sec немножечко меняет внутреннее устройство, и для duplicate keys возвращается первое значение, а не последнее. Потому что он вообще думал, что такого JSONа не бывает, и во всех его тест кейзах ключи уникальны. Так что у него регрессия пролетает на ура, а я огребаю мучительную отладку тикета у удалённого клиента, потому что хрен его пойми, откуда что берётся.
Когда я занимался автоматизацией автосервисов, то одним из направлений было создание парсеров для сайтов-поставщиков очередного клиента. У некоторых сайтов были вебсервисы, у некоторых приходилось просто разбирать страницы.
И как же чудесно были сделаны их "вебсервисы"! WSDL нет, или есть, да кривой, сертификат самоподписанный и просроченный, digest-аутентификация, которая работает по-разному в зависимости от user-agent, слегка кривой SOAP, формируемый слегка кривой их библиотечкой на PHP. При этом, нормальным считалось не вправлять мозги магазину, чтобы они починили свой уебсервис, привели его в соответствие со стандартами, а разбирать то, что есть. Более того, я уверен, что во многих случаях разработчик с той стороны вообще не понял бы, что от него требуют. Слаще морковки они не едали, какой-то автогенерации stub по wsdl в жизни не видели, у них это никогда не работало и для них норма — подкручивать все руками в каждом индивидуальном случае.
JSON — порождение мира веб-разработки. Где всегда что-то не работает, и это считается нормой вещей.
Тут в теме уже успели пнуть WCF, обозвав его "устаревшей технологией". Немного поработав c проектом, где активно использовался asp.net web api на json, и из сайта, и из мобильных клиентов, меня поразило, что вместо вызова какого-то метода с DTO, эти ребята руками собирают post-запрос с параметрами, все это в using, оттуда летят ошибки, в именах параметров — опечатки. Простой вызов вида
_proxy.Method1(object1, object2)
превращается в какую-то лапшу на 30 строк. В WCF такого безобразия не было. Зато json, js, мобильность и bootstrap с ангуляром ("где $%#&ь с хулиганом, да сифилис" (с) Маяковский).
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>JSON почти также сложен, как XML? G>>Да.
_>Ты серьёзно? ))) Ну ок... Я тут уже приводил полную грамматику json'a (правда в синтаксисе спирит'а, но это не суть). Можешь привести аналогичное для xml? )
Сам гуглить не умеешь? http://www.boost.org/doc/libs/1_48_0/libs/spirit/example/qi/mini_xml3.cpp
както вообще не космос.
G>>>>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит.
_>>>А если он возьмёт в руки скажем bison+flex? ))) G>>Ага, и доку на 900кб прочитает (три войны и мира в объеме). Ты думаешь это так просто, взять и написать парсер нетривиального яызка? Даже с тулами? Как минимум про грамматики надо прочитать, понимать что такое лексеры и парсеры, зачем они нужны, уметь отличать LL от LR и от GLR, понимать что такое lookahead.
_>Для нетривиального языка конечно (там кстати и bison не особо подходит). Но мы же тут не C или вообще C++ обсуждаем, а простенький JSON...
См выделенное.
Здравствуйте, alex_public, Вы писали:
_>Какое в разы больше? ) Я же чуть выше уже показывал пример задания грамматики json'a для спирита. Там короткий элементарный код.
Не видел. Опубликуй исходники на github.
Здравствуйте, netch80, Вы писали:
N>В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323.
На ASN.1 основан ISO9506. И хотя сам протокол уже даже окаменелым говном мамонта назвать не получится, внедрение его в энергетике только сейчас пошло полным ходом. См. IEC61850, вторая версия которого по меркам индустрии вышла только сегодня утром после завтрака.
Насколько широко оно распространено? Ну, индустриальные защитные и контрольные приборы для подстанций уже практически поголовно если не поддерживают его из коробки, то имеют версию или прошивку с этим протоколом, на худой конец адаптер. Скорее всего, многие бытовые электросчетчики тоже скоро будут поддеживать этот протокол, по крайней мере для smart grids.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, netch80, Вы писали:
N>>Тогда и код на C/Delphi/LISP/etc. — бинарь, а не текстовик.
MD>А где в коде C/Delphi/LISP/etc. используются ссылки на encoding?
MD>Тут речь про другое. Создайте такой Xml-файл: MD>
MD>Парсится? Парсится, успешно.
MD>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14".
Ну таки проблема скорее всего в том, что при созранении текстового файла ему BOM не добавили, а FAR по умолчанию не UTF-8 исползует.
Т.е. не больше чем обычная проблема кодировок.
Тот же php в живой природе бывает и в koi-8 и в 1251 и в utf-8, но там все понимают, что это encoding и никто сорсы бинарями не называет.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Kolesiki, Вы писали: K>>Но в чём прекрасен JSON, так это в удобстве
S>Ну так сценарии использования у них разные, чего смешивать-то?
Какие сценарии? всё та же древняя проблема "передать данные неизвестно куда, но чтобы их поняли".
S>Как показывает практика, на более-менее сложных структурах json откровенно сливает.
Что такое "сложные структуры" и каким образом "сливает"? Что такого немыслимого можно сериализовать, чтобы не уложилось в JSON?
S>И по удобству редактирования...
Нет никакого "редактирования" — "это всё фантастика!". В жизни не видел чудаков, создающих JSON с нуля. Ну а влезть раз в сто лет и поправить структуру — бывало и не составляло НИКАКИХ трудностей, благо редатор умеет даже схлопывать структуры.
S>...и по объёму выигрыш редко превышает 20%
Ну так в XML каждый тег продублирован — это автоматом даёт в JSON более компактный выхлоп! Что тут рассуждать о процентах? Это вопрос принципа: не создавать избыточных данных, сохраняя читабельность.
S> и отсутствие комментов/дат тоже радости не добавляет.
Пофиг. Сериализация придумана ДЛЯ КОМПЬЮТЕРА, но как бонус отладки — текстовый формат, который можно прочитать без спец-редакторов. Комментарии должны быть В КОДЕ — у десериализуемой структуры можно пометить что где означает, зачем их (комменты) дублировать ещё и в сериализованном тексте??
S>Чтоб далеко не ходить: xml, json. На переносы строк в json внимания не обращаем — я их для читабельности оставил. Без них вообще каша получается.
Ну вот! Что непонятного-то? JSON очевидно удобнее — видны названия и значения, всё сгруппировано (вместо XML-мешанины — хрен поймёшь куда там затесался < ). Просто сам формат проекта в студии бестолковый — ты пытаешься понять семантику, хотя речь идёт о читабельности в целом.
Здравствуйте, gandjustas, Вы писали:
_>>Ты серьёзно? ))) Ну ок... Я тут уже приводил полную грамматику json'a (правда в синтаксисе спирит'а, но это не суть). Можешь привести аналогичное для xml? ) G>Сам гуглить не умеешь? http://www.boost.org/doc/libs/1_48_0/libs/spirit/example/qi/mini_xml3.cpp G>както вообще не космос.
Это не XML, а его маленькое простенькое подмножество.
G>>>>>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит. G>_>>>А если он возьмёт в руки скажем bison+flex? ))) G>>>Ага, и доку на 900кб прочитает (три войны и мира в объеме). Ты думаешь это так просто, взять и написать парсер нетривиального яызка? Даже с тулами? Как минимум про грамматики надо прочитать, понимать что такое лексеры и парсеры, зачем они нужны, уметь отличать LL от LR и от GLR, понимать что такое lookahead. _>>Для нетривиального языка конечно (там кстати и bison не особо подходит). Но мы же тут не C или вообще C++ обсуждаем, а простенький JSON... G>См выделенное.
Т.е. по твоему парсер языка уровня json написанный неподготовленным человеком с помощью таких инструментов как boost.spirit или bison+flex обязательно будет сильно тормозить? )
Здравствуйте, gandjustas, Вы писали:
_>>Какое в разы больше? ) Я же чуть выше уже показывал пример задания грамматики json'a для спирита. Там короткий элементарный код. G>Не видел. Опубликуй исходники на github.
Здравствуйте, Mr.Delphist, Вы писали:
N>>Тогда и код на C/Delphi/LISP/etc. — бинарь, а не текстовик.
MD>А где в коде C/Delphi/LISP/etc. используются ссылки на encoding?
В Python есть. Но наличие текстового encoding как раз и означает текст.
MD>Тут речь про другое. Создайте такой Xml-файл: MD>
MD>Парсится? Парсится, успешно.
MD>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14".
Объясни, пожалуйста. Стандартный парсер умирает на utf-8 без схемы?
Здравствуйте, Kolesiki, Вы писали:
K>Нет никакого "редактирования" — "это всё фантастика!". В жизни не видел чудаков, создающих JSON с нуля.
Сплошь и рядом, и никакого чудачества. Кто-то же должен был эти структуры впервые создать?
А проверять свои интерфейсные модули на чём?
K>Ну так в XML каждый тег продублирован — это автоматом даёт в JSON более компактный выхлоп! Что тут рассуждать о процентах? Это вопрос принципа: не создавать избыточных данных, сохраняя читабельность.
Как раз наличие именованного закрывающего тега повышает читабельность сложных структур, в отличие от простой "}" без возможности комментировать.
S>> и отсутствие комментов/дат тоже радости не добавляет. K>Пофиг. Сериализация придумана ДЛЯ КОМПЬЮТЕРА, но как бонус отладки — текстовый формат, который можно прочитать без спец-редакторов. Комментарии должны быть В КОДЕ — у десериализуемой структуры можно пометить что где означает, зачем их (комменты) дублировать ещё и в сериализованном тексте??
Затем, что там, где структура используется как часть _конфига_ для человека, крайне полезна возможность комментировать. Конфиг — он, знаешь ли, руками пишется, правится, какие-то части могут быть временно выключены, часто в штатных комментариях идут примеры, как писать (чтобы не лезть далеко в документацию).
K>Ну вот! Что непонятного-то? JSON очевидно удобнее — видны названия и значения, всё сгруппировано (вместо XML-мешанины — хрен поймёшь куда там затесался < ).
Здравствуйте, mtnl, Вы писали:
MD>>Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14". M>Ну таки проблема скорее всего в том, что при созранении текстового файла ему BOM не добавили, а FAR по умолчанию не UTF-8 исползует.
У меня в обстановке (Ubuntu, FreeBSD) utf-8 по умолчанию. Пробовал через xml.parsers.expat от Python 3.4. Да, если BOM нет, то без явного указания utf-8 при создании объекта парсера оно такое не понимает, вылетает с руганью. Увидев BOM — понимает само. Посмотрел на реальный конфиг (~/.purple/blist.xml) — там BOM нет, но парсер понимает (важен другой парсер в libpurple, или ему заранее задают кодировку?)
M>Т.е. не больше чем обычная проблема кодировок. M>Тот же php в живой природе бывает и в koi-8 и в 1251 и в utf-8, но там все понимают, что это encoding и никто сорсы бинарями не называет.
