forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Вышел язык спецификации бинарных форматов Kaitai Struct 0.5, opennews (ok), 10-Ноя-16, (0) [смотреть все]

Нужно Предлагаю всем собраться и решить вопрос с генератором, ибо это тоже нужно, АнонимХ (ok), 19:52 , 10-Ноя-16, (1) +11 //

Генератор декларативных языков описания бинарных форматов и структур данных нуже, YetAnotherOnanym (ok), 21:12 , 10-Ноя-16, (4)

Ура Да здравствует тысяча первый язык описания бинарных форматов , Uri (??), 20:16 , 10-Ноя-16, (2) –6 //

Назовите хотя бы 3 предыдущих живых языка, если не сложно Чтобы им можно было о, GreyCat (ok), 20:44 , 10-Ноя-16, (3) +3 //

https github com kaitai-io kaitai_struct wiki FAQ how-does-it-compare-to-, chinarulezzz (ok), 04:38 , 11-Ноя-16, (15) +1 //

Что самое смешное - там сейчас ни одного из языков описания бинарных форматов не, GreyCat (ok), 08:45 , 11-Ноя-16, (16) +2

интересно, может ли эта вещь выполнять роль компилятора кросскомпилятора, в посл, Аноним (-), 22:39 , 10-Ноя-16, (6) –5 //

Столица переезжает в Нью-Васюки , Аноним (-), 00:57 , 11-Ноя-16, (11) +1
Даже не надейся домашние задания всё равно будут задавать , Led (ok), 04:28 , 11-Ноя-16, (14) +1

Подскажите в какой программе сделана схема в первом изображении , zztop (?), 22:55 , 10-Ноя-16, (8) +1 //

Вот эта - http kaitai io img code1 png Это HTML, написанный в первом попавше, GreyCat (ok), 00:21 , 11-Ноя-16, (9) +1 //

подскажите плиз, что за шрифт на скриншоте , chinarulezzz (ok), 04:12 , 11-Ноя-16, (13) +1 //

На каком из и какой из шрифтов - их тут как бы много , GreyCat (ok), 15:26 , 11-Ноя-16, (29) +1

http kaitai io img code1 png, chinarulezzz (ok), 16:49 , 11-Ноя-16, (33)

Это те же шрифты, что и на сайте kaitai io Exo и Share Tech Mono , GreyCat (ok), 17:21 , 11-Ноя-16, (34) +1

Однозначно нужно Что там с поддержкой регулярных выражений , chinarulezzz (ok), 04:09 , 11-Ноя-16, (12) //

Ничего А зачем , GreyCat (ok), 08:46 , 11-Ноя-16, (17) +1
Насколько можно судить, грамматика Kaitai Struct мощнее, или, как минимум, не уж, Comdiv (ok), 12:27 , 11-Ноя-16, (18) //

Нет, здесь просто область применения радикально другая Регулярные языки да и в, GreyCat (ok), 12:36 , 11-Ноя-16, (19) +1 //

Ну, регулярные выражения в классическом понимании не требуют сложных механизмов , Comdiv (ok), 13:11 , 11-Ноя-16, (20)

Ну, как минимум DFA-то требуют Хотя что считать сложным По-моему, в документаци, GreyCat (ok), 13:27 , 11-Ноя-16, (21) +1

Я не экспериментировал много, просто ввёл такое meta id Операция Ы что разбор, Comdiv (ok), 14:05 , 11-Ноя-16, (22)

Да, факт Не должно Вообще все идентификаторы как раз проверяются, кроме, как о, GreyCat (ok), 14:14 , 11-Ноя-16, (25) +1

Если разрешать, тогда, наверное, для целевых языков, не поддерживающих такие сим, Comdiv (ok), 14:45 , 11-Ноя-16, (28)

Проще -- не всегда лучше Предлагаю ограничиться предупреждением А то в начале , chinarulezzz (ok), 16:47 , 11-Ноя-16, (32) +1

О, разработчик Очень приятно С регулярными выражениями позицию понял Хотел спр, chinarulezzz (ok), 14:12 , 11-Ноя-16, (23) +1

Пока - вручную То есть один формат, в котором все заканчивается на meta , GreyCat (ok), 14:28 , 11-Ноя-16, (26) +2

Ок Если реализуете идею с интерфейсом наружу, то не забудьте про передачу парам, chinarulezzz (ok), 16:45 , 11-Ноя-16, (30) +1

Например Распаковщик, если что, инициализируется вручную на том же уровне, на к, GreyCat (ok), 17:23 , 11-Ноя-16, (35) +2

Я имел ввиду формальное определение в РБНФ или что-то подобное Такое описание п, Comdiv (ok), 14:13 , 11-Ноя-16, (24)

Тогда нужно придумать какую-то очередную вариацию БНФ для YAML-based форматов И, GreyCat (ok), 14:31 , 11-Ноя-16, (27) +1

Если сам YAML вписывается в БНФ, то проблем быть не должно, но всё же РБНФ лучше, Comdiv (ok), 19:45 , 11-Ноя-16, (37) +1

Писать самому парсер YAML - это да, мягко говоря, удручающее занятие Вообще вес, GreyCat (ok), 20:10 , 11-Ноя-16, (38) +1

Конечно, нечто подобное и хотелось бы видеть в качестве входного языка вместо мо, Comdiv (ok), 20:23 , 11-Ноя-16, (40) –1

И тот, и другой выбор - в любом случае спорные с многих точек зрения Кому-то нр, GreyCat (ok), 20:39 , 11-Ноя-16, (41) +1

необходимо , Петр Семилетов (?), 16:47 , 11-Ноя-16, (31)
Вот бы кто скрестил с Orcc http orcc sourceforge net , там у них в библиотеч, КО (?), 18:52 , 11-Ноя-16, (36) +1 //

Интересная ссылка, спасибо Попробую может быть с ними связаться и пообщаться , GreyCat (ok), 20:13 , 11-Ноя-16, (39) +1

Прекрасно оформленная новость и очень крутой апдейт с кучей полезностей , Аноним (-), 05:34 , 12-Ноя-16, (43) +1
Увы, пока очень слабо Но потенциал для развития есть Автор, откройте драфт как, Аноним (-), 06:03 , 12-Ноя-16, (44) –1 //

А драфт-то зачем , GreyCat (ok), 15:34 , 12-Ноя-16, (45) //

А как можно начать считывание типов со смещением от конца потока , Max (??), 16:44 , 12-Ноя-16, (46) //

instances foo pos _io size - смещение_от_конца, GreyCat (ok), 16:45 , 12-Ноя-16, (47)

Как ни странно, но именно это я и попробовал сделать в первую очередь Не работ, Max (??), 17:05 , 12-Ноя-16, (48)

Можно чуть более развернуто - что именно не работает Не компилируется ksc, не к, GreyCat (ok), 17:07 , 12-Ноя-16, (49)

А теперь до меня дошло, что в ksv не подсвечиваются секции указанные в instances, Maxim (??), 17:23 , 12-Ноя-16, (50)

Вообще должно Сейчас проверю Можно какой-нибудь пример , GreyCat (ok), 17:24 , 12-Ноя-16, (51)

meta id test endian leseq - id header type u4instances offset , Maxim (??), 17:26 , 12-Ноя-16, (52)

Да, факт, так не определяется Вообще, в реальной жизни это практически не замет, GreyCat (ok), 17:34 , 12-Ноя-16, (53) +2

Спасибо за исправление Теперь все работает как надо Еще я хотел узнать, а можно , Maxim (??), 21:58 , 15-Ноя-16, (59)

Эм, я вроде бы пока ничего не исправлял А в каком выражении его хочется получа, GreyCat (ok), 22:00 , 15-Ноя-16, (60)
Как так Я обновил ksv до версии 0 5 и проблема исчезлаinstances test pos , Maxim (??), 22:07 , 15-Ноя-16, (61)
0 5 выпустилась в более-менее штатном режиме по итогам последних нескольких меся, GreyCat (ok), 22:13 , 15-Ноя-16, (62)
А вот я уже не наблюдаю Зато значительно компактнее , Maxim (??), 22:20 , 15-Ноя-16, (63)
Какой из вариантов компактнее , GreyCat (ok), 22:21 , 15-Ноя-16, (64)
Тут дело в другом Какой из вариантов рабочий Я не совсем понял, как заставить, Maxim (??), 22:23 , 15-Ноя-16, (65)
Вам что нужно получить-то в итоге У вас есть что-то типа types main seq , GreyCat (ok), 22:27 , 15-Ноя-16, (66) +1
Да Именно то, что мне нужно Просто не привык я к таком OOP Спасибо , Maxim (??), 22:33 , 15-Ноя-16, (67)
Кстати, в данном случае надо сбросить подсветку родительской секции В данном сл, Maxim (??), 22:57 , 15-Ноя-16, (68)

Драфты бесплатные, скачать можно , Аноним (-), 19:05 , 12-Ноя-16, (54)

Нужная штука Как бы так ее скрестить с Thrift Avro , Вареник (?), 23:39 , 14-Ноя-16, (55) //

А зачем Разбирать Thrift или Avro в KS , GreyCat (ok), 08:36 , 15-Ноя-16, (56)

Битовые поля поддерживаются Или можно ли таким инструментом описывать регистры , КО (?), 18:00 , 15-Ноя-16, (57) //

Пока нет, но, надеюсь, скоро сделаем Пока все побитовые операции делаются через, GreyCat (ok), 18:01 , 15-Ноя-16, (58) +1 //

Здравствуйте Мне попался бинарный файл, который содержит в качестве дескриптора, Rustlang (?), 12:21 , 17-Ноя-16, (69) //

Очень мало что понял без более конкретных примеров, но попробую ответить Если ну, GreyCat (ok), 22:33 , 23-Ноя-16, (70)

Вот именно, что нужно не просто получить начало , а использовать блок дескрипто, Maxim (??), 23:20 , 24-Ноя-16, (71)

Можно какой-то чуть более конкретный пример Я пока понял, что вроде бы речь иде, GreyCat (ok), 19:20 , 25-Ноя-16, (72)

Ну почти так Нужно сначала получить все дескрипторы, а потом уже получить второй, Max (??), 03:09 , 26-Ноя-16, (73)

Сообщения [Сортировка по времени | RSS]

19. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от GreyCat (ok), 11-Ноя-16, 12:36

> Насколько можно судить, грамматика Kaitai Struct мощнее, или, как минимум, не уже
> регулярных выражений.
Нет, здесь просто область применения радикально другая. Регулярные языки (да и вообще традиционные задачи парсинга) упираются в разрешение неоднозначности: всякие там ^(a*)(aaa)$ - очередная "a" - это еще первая группа или уже вторая? И, соответственно, приносятся всякие бэктрекинги, DFA, LL/LR/LALR, lookup'ы и т.д.
Бинарные форматы в массе своей куда проще. Здесь нет неоднозначности - они специально так проектируются, чтобы их было легко читать алгоритмом. Соответственно, и нет почти никакой необходимости в механиках неоднозначности.

Ответить | Правка | Наверх | Cообщить модератору

20. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +/–

Сообщение от Comdiv (ok), 11-Ноя-16, 13:11

Ну, регулярные выражения в классическом понимании не требуют сложных механизмов разбора. В прагматичных применениях нет смысла замедлять разборщик, позволяя делать откат при разборе текста по приведённому Вами выражению и достаточно жадной стратегии, так как такие выражения не имеют практического смысла, и легко могут быть заменены на нормальные.
P.S Обратил внимание на недостатки:
1. В документации отсутсвует грамматика самого Katai Struct, это усложняет ознакомление.
2. Входной документ не проверяется на корректность и генератор легко делает некомпилируемый код

Ответить | Правка | Наверх | Cообщить модератору

21. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от GreyCat (ok), 11-Ноя-16, 13:27

> Ну, регулярные выражения в классическом понимании не требуют сложных механизмов разбора.
Ну, как минимум DFA-то требуют. Хотя что считать сложным.
> P.S Обратил внимание на недостатки:
> 1. В документации отсутсвует грамматика самого Katai Struct, это усложняет ознакомление.
По-моему, в документации как раз ничего, кроме грамматики и нет :( Для упрощения ознакомления надо по идее писать какие-то туториалы, quick start и человеческие гайды, но мне все некогда, а кто-то еще никак не сподвигнется. Единственный гайд, который до сих пор написали - та самая статья в двух частях про реверсинг VN - но ее сложно назвать "гайдом по инструментарию".
> 2. Входной документ не проверяется на корректность
Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных примеров?
> и генератор легко делает некомпилируемый код
Это довольно многогранный вопрос, не совсем связанный с корректностью входного ksy. Например, если мы компилируем два ksy по отдельности: FormatA и FormatB, и FormatA ссылается на FormatB. На момент компиляции FormatA компилятор ничего не знает о структуре (и даже существовании) FormatB, поэтому лучшее, что он может сделать, встретив неописанный тип - просто вывести его названием, как есть, в предположении, что это тип верхнего уровня. По отдельности FormatA не скомпилируется. А вот FormatA + FormatB в одном проекте уже дадут искомую работающую связку.

Ответить | Правка | Наверх | Cообщить модератору

22. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +/–

Сообщение от Comdiv (ok), 11-Ноя-16, 14:05

> Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных
> примеров?
Я не экспериментировал много, просто ввёл такое:
meta:
  id: Операция Ы

что разборщик съел и не поморщился, выдав:
...
public class Операция Ы extends KaitaiStruct {
    public static Операция Ы fromFile(String fileName) throws IOException {
        return new Операция Ы(new KaitaiStream(fileName));
    }
...

Ответить | Правка | Наверх | Cообщить модератору

25. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от GreyCat (ok), 11-Ноя-16, 14:14

>> Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных
>> примеров?
> Я не экспериментировал много, просто ввёл такое:
> meta:
>   id: Операция Ы
Да, факт. Не должно. Вообще все идентификаторы как раз проверяются, кроме, как оказалось, этого ;) Сейчас починю.
Хотя вообще само по себе это наталкивает на забавную дилемму. "Операция Ы", может, и невалидный идентификатор, а вот "операция_ы" (который станет в Java "ОперацияЫ") - вполне себе. Может, разрешить non-ASCII?..

Ответить | Правка | Наверх | Cообщить модератору

28. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +/–

Сообщение от Comdiv (ok), 11-Ноя-16, 14:45

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

Ответить | Правка | Наверх | Cообщить модератору

32. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от chinarulezzz (ok), 11-Ноя-16, 16:47

> Если разрешать, тогда, наверное, для целевых языков, не поддерживающих такие символы нужно
> делать преобразование имён. Короче говоря, проще запретить.
Проще -- не всегда лучше. Предлагаю ограничиться предупреждением. А то в начале вводят в языки UTF8, а потом ограничивают его использование.

Ответить | Правка | Наверх | Cообщить модератору

23. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от chinarulezzz (ok), 11-Ноя-16, 14:12

О, разработчик! Очень приятно.
С регулярными выражениями позицию понял. Хотел спросить еще, что на счет юзерских функций? Заметил, что есть process. Можно задавать собственные функции обработки? Бывает, попадаются извращенцы, которые упаковывают так, что одними xor/rol/ror/zlib не обойтись. Если да, то как?

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

26. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +2 +/–

Сообщение от GreyCat (ok), 11-Ноя-16, 14:28

> Хотел спросить еще, что на счет юзерских
> функций? Заметил, что есть process. Можно задавать собственные функции обработки? Бывает,
> попадаются извращенцы, которые упаковывают так, что одними xor/rol/ror/zlib не обойтись.
> Если да, то как?
Пока - вручную. То есть один формат, в котором все заканчивается на
   meta:
     id: Format1
   seq:
     # ...
     - id: buf
       size: something
дальше в целевом языке:
    Format1 foo = Format1.fromFile("...");
    byte[] buf = foo.buf();
    // как-то распаковали, отталкиваясь от buf
    byte[] unpacked = ...;
    // и запускаем парсить то, что внутри по второму формату:
    Format2 bar = new Format2(new KaitaiStream(unpacked));
и дальше уже отдельный тип Format2 в ksy описывает все, что внутри.
В целом уже обсуждалась идея выдать наружу интерфейс, на котором можно реализовывать произвольные функции распаковки (туда - поток байт, оттуда - поток). Тогда все будет сводиться к чему-то типа:
   - id: buf
     size: something
     process: user(some_unpacker)
И тогда внутри будет генерироваться вызов чего-то типа
   buf = new SomeUnpacker().unpack(raw)
А от пользователя, соответственно, будет предполагаться, что у него где-то неподалеку в окружении найдется класс SomeUnpacker, который implements такой интерфейс.

Ответить | Правка | Наверх | Cообщить модератору

30. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от chinarulezzz (ok), 11-Ноя-16, 16:45

Ок. Если реализуете идею с интерфейсом наружу, то не забудьте про передачу параметров. Иногда нужно передать в распаковщик ранее распарсенную структуру.

Ответить | Правка | Наверх | Cообщить модератору

35. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +2 +/–

Сообщение от GreyCat (ok), 11-Ноя-16, 17:23

> Ок. Если реализуете идею с интерфейсом наружу, то не забудьте про передачу
> параметров. Иногда нужно передать в распаковщик ранее распарсенную структуру.
Например? Распаковщик, если что, инициализируется вручную на том же уровне, на котором класс формата. И никто не мешает там использовать хоть весь класс формата целиком. Когда и что может потребоваться еще передавать?

Ответить | Правка | Наверх | Cообщить модератору

24. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +/–

Сообщение от Comdiv (ok), 11-Ноя-16, 14:13

> По-моему, в документации как раз ничего, кроме грамматики и нет :(
Я имел ввиду формальное определение в РБНФ или что-то подобное. Такое описание позволяет быстрей ухватить суть за счёт компактности определения - синтаксис серьёзных языков умещается в несколько страниц, простых предметно ориентированных может влезть и в несколько строк. Зависит, конечно, от навороченности языка.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

27. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от GreyCat (ok), 11-Ноя-16, 14:31

>> По-моему, в документации как раз ничего, кроме грамматики и нет :(
> Я имел ввиду формальное определение в РБНФ или что-то подобное. Такое описание
> позволяет быстрей ухватить суть за счёт компактности определения - синтаксис серьёзных
> языков умещается в несколько страниц, простых предметно ориентированных может влезть и
> в несколько строк. Зависит, конечно, от навороченности языка.
Тогда нужно придумать какую-то очередную вариацию БНФ для YAML-based форматов. Или можно по идее сделать YAML-схему...

Ответить | Правка | Наверх | Cообщить модератору

37. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от Comdiv (ok), 11-Ноя-16, 19:45

Если сам YAML вписывается в БНФ, то проблем быть не должно, но всё же РБНФ лучше для восприятия человеком.
Нашёл БНФ для YAML https://gist.github.com/tociyuki/3936873 - выглядит удручающе, но вполне возможно, что грамматика Kaitai Struct, являясь подмножеством, будет попроще.

Ответить | Правка | Наверх | Cообщить модератору

38. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от GreyCat (ok), 11-Ноя-16, 20:10

> Если сам YAML вписывается в БНФ, то проблем быть не должно, но
> всё же РБНФ лучше для восприятия человеком.
> Нашёл БНФ для YAML https://gist.github.com/tociyuki/3936873 - выглядит удручающе, но
> вполне возможно, что грамматика Kaitai Struct, являясь подмножеством, будет попроще.
Писать самому парсер YAML - это да, мягко говоря, удручающее занятие. Вообще весь смысл использования YAML (XML, JSON, или чего-то такого высокоуровневого) был ровно в том, чтобы *не* заморачиваться с любыми описаниями грамматик и Бэкусом-Науром, а использовать какие-то инструменты более высокого уровня для описания того, что дозволено иметь в формате.
Как правило - такие инструменты начинаются со схем. Для YAML это, например, Kwalify - http://www.kuwata-lab.com/kwalify/ruby/users-guide.01.html#s....
Если хочется именно грамматику и BNF / ENBF / RNBF / ANTLR / yacc / etc - то тогда имеет смысл ее просто придумать и описать, в терминах, формализуемых проще, чем языки разметки. В свое время на LOR народ предлагал вместо:
    meta:
      id: foo
    seq:
      - id: len
        type: u1
      - id: my_str
        type: str
        encoding: UTF-8
        size: len
делать что-то C-подобное, а ля
    type foo {
        u1 len;
        str(len, UTF-8) my_str;
    }

Ответить | Правка | Наверх | Cообщить модератору

40. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" –1 +/–

Сообщение от Comdiv (ok), 11-Ноя-16, 20:23

>    type foo {
>        u1 len;
>        str(len, UTF-8) my_str;
>    }
Конечно, нечто подобное и хотелось бы видеть в качестве входного языка вместо монотонно многословного YAML. Если такой вариант рассматривался, что стало преградой для воплощения?

Ответить | Правка | Наверх | Cообщить модератору

41. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5" +1 +/–

Сообщение от GreyCat (ok), 11-Ноя-16, 20:39

>>    type foo {
>>        u1 len;
>>        str(len, UTF-8) my_str;
>>    }
> Конечно, нечто подобное и хотелось бы видеть в качестве входного языка вместо
> монотонно многословного YAML. Если такой вариант рассматривался, что стало преградой для
> воплощения?
И тот, и другой выбор - в любом случае спорные с многих точек зрения. Кому-то нравится одно, кому-то - другое. С точки зрения написания вручную - кому-то проще выучить синтаксис-скобочки-всякие []{}(), кому-то - держать в голове ключевые слова "size", "type", "id" и т.д.
С точки зрения программной обработки - конечно, любой язык разметки (YAML, JSON, XML) сильно выигрывает в плане того, что можно сделать красивый GUI, где показывать всю эту штуку в виде дерева с менюшками добавления элементов. Да и если надо сделать что-то простое с ksy-описанием - например, написать скрипт автоматического переименования типов - добавлять префикс - на любом скриптовом языке сейчас это делается в 2 строчки. Решать аналогичную задачу с полноценным языком с грамматикой - задача на два порядка более сложная.
Поддерживать параллельно два-три альтернативных представления формата (YAML/JSON, XML, C-подобный) мне на данном этапе развития проекта кажется не очень актуальным - хотя, в теории, дописать такую поддержку - задача на один-два вечера. Благо парсер с грамматиками у нас все равно уже есть. Дольше, скорее, это C-подобное представление придумывать.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	19. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от GreyCat (ok), 11-Ноя-16, 12:36
	> Насколько можно судить, грамматика Kaitai Struct мощнее, или, как минимум, не уже > регулярных выражений. Нет, здесь просто область применения радикально другая. Регулярные языки (да и вообще традиционные задачи парсинга) упираются в разрешение неоднозначности: всякие там ^(a*)(aaa)$ - очередная "a" - это еще первая группа или уже вторая? И, соответственно, приносятся всякие бэктрекинги, DFA, LL/LR/LALR, lookup'ы и т.д. Бинарные форматы в массе своей куда проще. Здесь нет неоднозначности - они специально так проектируются, чтобы их было легко читать алгоритмом. Соответственно, и нет почти никакой необходимости в механиках неоднозначности.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+/–
	Сообщение от Comdiv (ok), 11-Ноя-16, 13:11
	Ну, регулярные выражения в классическом понимании не требуют сложных механизмов разбора. В прагматичных применениях нет смысла замедлять разборщик, позволяя делать откат при разборе текста по приведённому Вами выражению и достаточно жадной стратегии, так как такие выражения не имеют практического смысла, и легко могут быть заменены на нормальные. P.S Обратил внимание на недостатки: 1. В документации отсутсвует грамматика самого Katai Struct, это усложняет ознакомление. 2. Входной документ не проверяется на корректность и генератор легко делает некомпилируемый код
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от GreyCat (ok), 11-Ноя-16, 13:27
	> Ну, регулярные выражения в классическом понимании не требуют сложных механизмов разбора. Ну, как минимум DFA-то требуют. Хотя что считать сложным. > P.S Обратил внимание на недостатки: > 1. В документации отсутсвует грамматика самого Katai Struct, это усложняет ознакомление. По-моему, в документации как раз ничего, кроме грамматики и нет :( Для упрощения ознакомления надо по идее писать какие-то туториалы, quick start и человеческие гайды, но мне все некогда, а кто-то еще никак не сподвигнется. Единственный гайд, который до сих пор написали - та самая статья в двух частях про реверсинг VN - но ее сложно назвать "гайдом по инструментарию". > 2. Входной документ не проверяется на корректность Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных примеров? > и генератор легко делает некомпилируемый код Это довольно многогранный вопрос, не совсем связанный с корректностью входного ksy. Например, если мы компилируем два ksy по отдельности: FormatA и FormatB, и FormatA ссылается на FormatB. На момент компиляции FormatA компилятор ничего не знает о структуре (и даже существовании) FormatB, поэтому лучшее, что он может сделать, встретив неописанный тип - просто вывести его названием, как есть, в предположении, что это тип верхнего уровня. По отдельности FormatA не скомпилируется. А вот FormatA + FormatB в одном проекте уже дадут искомую работающую связку.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+/–
	Сообщение от Comdiv (ok), 11-Ноя-16, 14:05
	> Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных > примеров? Я не экспериментировал много, просто ввёл такое: meta: id: Операция Ы что разборщик съел и не поморщился, выдав: ... public class Операция Ы extends KaitaiStruct { public static Операция Ы fromFile(String fileName) throws IOException { return new Операция Ы(new KaitaiStream(fileName)); } ...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от GreyCat (ok), 11-Ноя-16, 14:14
	>> Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных >> примеров? > Я не экспериментировал много, просто ввёл такое: > meta: > id: Операция Ы Да, факт. Не должно. Вообще все идентификаторы как раз проверяются, кроме, как оказалось, этого ;) Сейчас починю. Хотя вообще само по себе это наталкивает на забавную дилемму. "Операция Ы", может, и невалидный идентификатор, а вот "операция_ы" (который станет в Java "ОперацияЫ") - вполне себе. Может, разрешить non-ASCII?..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+/–
	Сообщение от Comdiv (ok), 11-Ноя-16, 14:45
	Если разрешать, тогда, наверное, для целевых языков, не поддерживающих такие символы нужно делать преобразование имён. Короче говоря, проще запретить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от chinarulezzz (ok), 11-Ноя-16, 16:47
	> Если разрешать, тогда, наверное, для целевых языков, не поддерживающих такие символы нужно > делать преобразование имён. Короче говоря, проще запретить. Проще -- не всегда лучше. Предлагаю ограничиться предупреждением. А то в начале вводят в языки UTF8, а потом ограничивают его использование.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от chinarulezzz (ok), 11-Ноя-16, 14:12
	О, разработчик! Очень приятно. С регулярными выражениями позицию понял. Хотел спросить еще, что на счет юзерских функций? Заметил, что есть process. Можно задавать собственные функции обработки? Бывает, попадаются извращенцы, которые упаковывают так, что одними xor/rol/ror/zlib не обойтись. Если да, то как?
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	26. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+2 +/–
	Сообщение от GreyCat (ok), 11-Ноя-16, 14:28
	> Хотел спросить еще, что на счет юзерских > функций? Заметил, что есть process. Можно задавать собственные функции обработки? Бывает, > попадаются извращенцы, которые упаковывают так, что одними xor/rol/ror/zlib не обойтись. > Если да, то как? Пока - вручную. То есть один формат, в котором все заканчивается на meta: id: Format1 seq: # ... - id: buf size: something дальше в целевом языке: Format1 foo = Format1.fromFile("..."); byte[] buf = foo.buf(); // как-то распаковали, отталкиваясь от buf byte[] unpacked = ...; // и запускаем парсить то, что внутри по второму формату: Format2 bar = new Format2(new KaitaiStream(unpacked)); и дальше уже отдельный тип Format2 в ksy описывает все, что внутри. В целом уже обсуждалась идея выдать наружу интерфейс, на котором можно реализовывать произвольные функции распаковки (туда - поток байт, оттуда - поток). Тогда все будет сводиться к чему-то типа: - id: buf size: something process: user(some_unpacker) И тогда внутри будет генерироваться вызов чего-то типа buf = new SomeUnpacker().unpack(raw) А от пользователя, соответственно, будет предполагаться, что у него где-то неподалеку в окружении найдется класс SomeUnpacker, который implements такой интерфейс.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от chinarulezzz (ok), 11-Ноя-16, 16:45
	Ок. Если реализуете идею с интерфейсом наружу, то не забудьте про передачу параметров. Иногда нужно передать в распаковщик ранее распарсенную структуру.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+2 +/–
	Сообщение от GreyCat (ok), 11-Ноя-16, 17:23
	> Ок. Если реализуете идею с интерфейсом наружу, то не забудьте про передачу > параметров. Иногда нужно передать в распаковщик ранее распарсенную структуру. Например? Распаковщик, если что, инициализируется вручную на том же уровне, на котором класс формата. И никто не мешает там использовать хоть весь класс формата целиком. Когда и что может потребоваться еще передавать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+/–
	Сообщение от Comdiv (ok), 11-Ноя-16, 14:13
	> По-моему, в документации как раз ничего, кроме грамматики и нет :( Я имел ввиду формальное определение в РБНФ или что-то подобное. Такое описание позволяет быстрей ухватить суть за счёт компактности определения - синтаксис серьёзных языков умещается в несколько страниц, простых предметно ориентированных может влезть и в несколько строк. Зависит, конечно, от навороченности языка.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	27. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от GreyCat (ok), 11-Ноя-16, 14:31
	>> По-моему, в документации как раз ничего, кроме грамматики и нет :( > Я имел ввиду формальное определение в РБНФ или что-то подобное. Такое описание > позволяет быстрей ухватить суть за счёт компактности определения - синтаксис серьёзных > языков умещается в несколько страниц, простых предметно ориентированных может влезть и > в несколько строк. Зависит, конечно, от навороченности языка. Тогда нужно придумать какую-то очередную вариацию БНФ для YAML-based форматов. Или можно по идее сделать YAML-схему...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от Comdiv (ok), 11-Ноя-16, 19:45
	Если сам YAML вписывается в БНФ, то проблем быть не должно, но всё же РБНФ лучше для восприятия человеком. Нашёл БНФ для YAML https://gist.github.com/tociyuki/3936873 - выглядит удручающе, но вполне возможно, что грамматика Kaitai Struct, являясь подмножеством, будет попроще.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от GreyCat (ok), 11-Ноя-16, 20:10
	> Если сам YAML вписывается в БНФ, то проблем быть не должно, но > всё же РБНФ лучше для восприятия человеком. > Нашёл БНФ для YAML https://gist.github.com/tociyuki/3936873 - выглядит удручающе, но > вполне возможно, что грамматика Kaitai Struct, являясь подмножеством, будет попроще. Писать самому парсер YAML - это да, мягко говоря, удручающее занятие. Вообще весь смысл использования YAML (XML, JSON, или чего-то такого высокоуровневого) был ровно в том, чтобы не заморачиваться с любыми описаниями грамматик и Бэкусом-Науром, а использовать какие-то инструменты более высокого уровня для описания того, что дозволено иметь в формате. Как правило - такие инструменты начинаются со схем. Для YAML это, например, Kwalify - http://www.kuwata-lab.com/kwalify/ruby/users-guide.01.html#s.... Если хочется именно грамматику и BNF / ENBF / RNBF / ANTLR / yacc / etc - то тогда имеет смысл ее просто придумать и описать, в терминах, формализуемых проще, чем языки разметки. В свое время на LOR народ предлагал вместо: meta: id: foo seq: - id: len type: u1 - id: my_str type: str encoding: UTF-8 size: len делать что-то C-подобное, а ля type foo { u1 len; str(len, UTF-8) my_str; }
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	–1 +/–
	Сообщение от Comdiv (ok), 11-Ноя-16, 20:23
	> type foo { > u1 len; > str(len, UTF-8) my_str; > } Конечно, нечто подобное и хотелось бы видеть в качестве входного языка вместо монотонно многословного YAML. Если такой вариант рассматривался, что стало преградой для воплощения?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Вышел язык спецификации бинарных форматов Kaitai Struct 0.5"	+1 +/–
	Сообщение от GreyCat (ok), 11-Ноя-16, 20:39
	>> type foo { >> u1 len; >> str(len, UTF-8) my_str; >> } > Конечно, нечто подобное и хотелось бы видеть в качестве входного языка вместо > монотонно многословного YAML. Если такой вариант рассматривался, что стало преградой для > воплощения? И тот, и другой выбор - в любом случае спорные с многих точек зрения. Кому-то нравится одно, кому-то - другое. С точки зрения написания вручную - кому-то проще выучить синтаксис-скобочки-всякие []{}(), кому-то - держать в голове ключевые слова "size", "type", "id" и т.д. С точки зрения программной обработки - конечно, любой язык разметки (YAML, JSON, XML) сильно выигрывает в плане того, что можно сделать красивый GUI, где показывать всю эту штуку в виде дерева с менюшками добавления элементов. Да и если надо сделать что-то простое с ksy-описанием - например, написать скрипт автоматического переименования типов - добавлять префикс - на любом скриптовом языке сейчас это делается в 2 строчки. Решать аналогичную задачу с полноценным языком с грамматикой - задача на два порядка более сложная. Поддерживать параллельно два-три альтернативных представления формата (YAML/JSON, XML, C-подобный) мне на данном этапе развития проекта кажется не очень актуальным - хотя, в теории, дописать такую поддержку - задача на один-два вечера. Благо парсер с грамматиками у нас все равно уже есть. Дольше, скорее, это C-подобное представление придумывать.
	Ответить \| Правка \| Наверх \| Cообщить модератору