https://m.opennet.dev/openforum/vsluhforumID3/107525.html Проект Kaitai представил (http://kaitai.io/) первый публичный релиз спецификации парсинга произвольных бинарных файлов и инструментария к нему: Kaitai Struct 0.2 (https://github.com/kaitai-io/kaitai_struct). Kaitai Struct предлагается использовать в качестве формального описания любых бинарных форматов. <br><br><br><br>Формат описывается в виде файла .ksy (который представляет собой YAML специального вида), который можно не только использовать в качестве документации, но и сразу же скомпилировать с помощью специального компилятора (ksc). На выходе компилятора &#8212; исходные коды библиотеки на одном из поддерживаемых языков, которая автоматически будет выполнять парсинг описанного в .ksy формата. Первый публичный релиз поддерживает Java, JavaScript, Python, Ruby, ожидается поддержка C, C++ и C#.<br><br><br>Заявляется, что сгенерированные таким образом парсеры, как правило, не уступают парсерам, написанным вручную, а зачастую и превосходят их &#8212; за счет более корректной обработки исключительных ситуаций, гарантированно https://m.opennet.dev/openforum/vsluhforumID3/107525.html#44 Wed, 20 Apr 2016 18:52:43 GMT &gt; Господа! Если время старта/компиляции критично, то можно файлы *.class скормить компилятору <br>&gt; gcj (все про него забыли). Получится нативный исполняемый бинарь, который порадует <br>&gt; вас не только быстрым стартом, но и шустрым исполнением кода.<br><br>Эм, вы сами пробовали? Нативный бинарь получается размером эдак мегабайт 30-35, JIT в нем отсутствует начисто, внутри по сути примерно такая же виртуальная машина, стартап там тоже мягко говоря небыстрый и сама программа работает, как правило, в несколько раз медленнее того, как она работает в JVM.<br><br>Плюс, пардон, когда я последний раз туда смотрел, там не то, что Java 7 не поддерживалась, даже Java 6 местами не была реализована.<br> https://m.opennet.dev/openforum/vsluhforumID3/107525.html#43 Wed, 20 Apr 2016 18:34:55 GMT Господа! Если время старта/компиляции критично, то можно файлы *.class скормить компилятору gcj (все про него забыли). Получится нативный исполняемый бинарь, который порадует вас не только быстрым стартом, но и шустрым исполнением кода.<br> https://m.opennet.dev/openforum/vsluhforumID3/107525.html#42 Wed, 20 Apr 2016 17:21:24 GMT Для парсинга *любого* бинарника нужна машина тюринга. Бинарь частично упакованый gzip или зашифрованый ssl, смогёт?<br> https://m.opennet.dev/openforum/vsluhforumID3/107525.html#41 Thu, 14 Apr 2016 07:42:10 GMT Генератора пока нет &#8212; есть далекоидущая цель сделать это где-нибудь ко второй major версии. По большому счету в декларативном формате эта задача упирается в необходимость (и возможность) символического вывода: например, если где-то объявлено число x, а где-то есть строка str длиной (2 * x + 3), т.е. str.length = 2 * x + 3. Значит, при записи нужно развернуть формулу и записывать x = (str.length - 3) / 2. И, внезапно, иногда решений может вообще не быть, а иногда их может быть бесконечно много.<br> https://m.opennet.dev/openforum/vsluhforumID3/107525.html#40 Wed, 13 Apr 2016 19:53:27 GMT &gt; Avro &#8212; в смысле, с генерируемых классах сразу Avro-аннотации генерировать, как-то <br>&gt; так?<br><br>В идеале + код. Если говорим о Hadoop семействе, то оптимально - InputFormat c выходом Avro объектов. Кроме самого Hadoop-а это практически автоматом даст интеграцию с Spark и Hive<br><br>&gt; CDR &#8212; имеются в виду всякие логи сотовых операторов и прочая биллинг-ориентированная <br>&gt; тематика?<br><br>Сырые логи с оборудования. Навскидку http://bill-parser.googlecode.com/svn/trunk/doc/CDR_Description_M14.3.pdf<br><br>При этом CDR - это вершина айсберга. Там еще траффик, технические логи итд<br><br><br> https://m.opennet.dev/openforum/vsluhforumID3/107525.html#39 Wed, 13 Apr 2016 18:01:38 GMT &gt;Последнее, кстати, запускается радикально быстрее<br><br>Была какая-то тулза для ускорения многократного запуска программ на Java за счет переиспользования JVM<br> https://m.opennet.dev/openforum/vsluhforumID3/107525.html#38 Wed, 13 Apr 2016 14:53:34 GMT В этом и преимущество велосипедных DSL - больше возможности для краткости.<br> https://m.opennet.dev/openforum/vsluhforumID3/107525.html#37 Wed, 13 Apr 2016 10:30:46 GMT &gt; Можно было и валиндный yaml: <br>&gt; seq: <br>&gt; image_width: u2 <br>&gt; image_height: u2 <br>&gt; flags: u1 <br>&gt; bg_color_index: u1 <br>&gt; pixel_aspect_ratio: u1 <br>&gt; только это не расширяемо.<br><br>Главная проблема здесь в том, что у вас получился map под названием seq, в котором порядок элементов не определен. А нам он важен, т.к. нам их надо парсить именно в определенной последовательности.<br> https://m.opennet.dev/openforum/vsluhforumID3/107525.html#36 Wed, 13 Apr 2016 10:28:57 GMT Можно было и валиндный yaml:<br><br>seq:<br> image_width: u2<br> image_height: u2<br> flags: u1<br> bg_color_index: u1<br> pixel_aspect_ratio: u1<br><br>только это не расширяемо.<br>