The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

10.11.2016 17:33

Проект Kaitai представил новый релиз Kaitai Struct версии 0.5, декларативного языка описания бинарных форматов и структур данных. Как и прежде, основная идея проекта заключается в том, что практически любой формат файла или структуру сетевого протокола можно описать на Kaitai Struct, составив исходный файл .ksy, который затем компилируется (с помощью прилагаемого компилятора ksc) в готовый парсер на любом из поддерживаемых языков программирования.

Основная сфера применения подобного решения - разбор всевозможных существующих (зачастую закрытых и проприетарных) форматов (офисных, мультимедийных и т.д.) и протоколов. Благодаря наличию продвинутых инструментов отладки и визуализации, Kaitai Struct нашел свое применение и в быстром реверс-инжиниринге неизвестных форматов, а также в digital forensics. Ряд организаций, занимающийся хранением исторических цифровых архивов, взяли Kaitai Struct на вооружение как стандарт описания форматов данных. Компилятор Kaitai Struct распространяется под лицензией GPLv3, большая часть runtime - под MIT. Для желающих попробовать компилятор без установки подготовлен JavaScript-вариант компилятора KS с примерами.

Наиболее заметные изменения:

  • Поддержка новых целевых языков
    • Полная поддержка целевого языка C++ (на базе STL), а также новые целевые языки PHP и Perl:
    • Вывод описаний форматов в виде наглядных человеко-читаемых схем (через GraphViz). Подборка примеров визуализаций доступна в галерее;
    • Многочисленные доработки и проверки для полноценной поддержки как Python 2, так и Python 3.
    • Как и раньше, кроме новых языков, все еще поддерживаются C#, Java, JavaScript, Python, Ruby.
  • Новые инструменты для разработки, отладки и визуализации
    • Консольный визуализатор ksv обновлен и теперь работает не только на UNIX-консолях (Linux, *BSD, OS X), но и под Windows:
    • Появился экспериментальный GUI-визуализатор на Java/Swing:
    • Начата разработка интегрированной среды на основе web-технологий, работающей в браузере и совмещающей в себе редактор для создания .ksy-файлов, компилятор, визуализатор дерева объектов, hex viewer и менеджер библиотеки ksy-форматов. Среда реализована на HTML/JavaScript, но благодаря технологии ScalaJS, внутри у нее использоваться абсолютно такой же компилятор, как и в большой, "десктопной" версии Kaitai Struct. Доступна онлайн демо-версия.
  • Новые возможности языка .ksy
    • Switch-подобный механизм определения типов данных на основе условия позволяет отказаться от кучи однотипных if'ов:
    • Цикл repeat-until позволяет объявить массив элементов, повторяющихся до достижения определенного условия. Для ссылки на текущий элемент следует использовать специальную переменную `_`. Например, следующее объявление задает массив целых знаковых 4-байтовых чисел, заканчивающийся -1:
      
         - id: elements
           type: s4
           repeat: until
           repeat-until: _ == -1
      

      Более сложный пример — массив сегментов (тип segment - пользовательский, объявлен отдельно), заканчивающийся чтением сегмента с кодом "segment_code::end":
      
         - id: segments
           type: segment
           repeat: until
           repeat-until: _.code == segment_code::end
      
    • Каждое поле теперь может аннотироваться строчкой человеко-читаемой документации. Кроме видимости в .ksy-файле, эта документация будет выгружаться в doc-систему целевого языка (JavaDoc, JSDoc, YARD/RDoc и т.п.):
    • В язык выражений добавлены операции над потоком (`_io`). С их помощью можно, например, адресовать структуры относительно конца потока (а не только относительно начала):
      
         instances:
           from_start: # 0x10 байт, начиная с 0x40 байта от начала
             pos: 0x40
             size: 0x10
           from_end:   # 0x10 байт, начиная с 0x40 байта с конца
             pos: _io.size - 0x40
             size: 0x10
      

      Или, например, удобно делать условные структуры, которые будут парситься, только если что-то еще осталось в потоке:

      
         seq:
           # основной элемент, присутствует всегда
           - id: main_element
             type: ...
           # дополнительный элемент, будет зачитан, только в потоке еще что-то есть
           - id: aux_element
             type: ...
             if: not _io.eof
      
  • Важные мелочи
    • Существенно улучшена диагностика ошибок, усилена строгость проверки исходных .ksy. При обнаружении ошибки компилятор теперь генерирует понятные ссылки на конкретные элементы, в которых проблема и предлагает варианты решения. При обнаружении ошибки с данными в runtime в debug-режиме теперь производится попытка оставить как можно больше данных в структуре (включая не полностью заполненные классы), чтобы легче было понять, где именно произошел сбой парсинга.
    • Стандартизация сборки: в дополнение к ранее собираемым runtime-модулям для Ruby в виде gem, появились доступные для инсталляции из соответствующих репозиториев пакеты для Python в PyPI и для Java-платформы. Авторы призывают помочь с упаковкой runtime-библиотек и для других языков.


  1. Главная ссылка к новости (http://kaitai.io/news/2016-11-...)
  2. OpenNews: Релиз системы разбора произвольных бинарных файлов Kaitai Struct 0.4
  3. OpenNews: Kaitai Struct запустил веб-версию компилятора
  4. OpenNews: Декларативная спецификация парсинга бинарных файлов Kaitai Struct
Автор новости: GreyCat
Тип: Программы
Ключевые слова: kaitai
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (69) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, АнонимХ (ok), 19:52, 10/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Нужно!

    Предлагаю всем собраться и решить вопрос с генератором, ибо это тоже нужно, но сложнее

     
     
  • 2.4, YetAnotherOnanym (ok), 21:12, 10/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Генератор декларативных языков описания бинарных форматов и структур данных нужен, однозначно!
     

  • 1.2, Uri (??), 20:16, 10/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Ура! Да здравствует тысяча первый язык описания бинарных форматов!
     
     
  • 2.3, GreyCat (ok), 20:44, 10/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Назовите хотя бы 3 предыдущих живых языка, если не сложно? Чтобы им можно было описать структуру файловой системы или там какого-нибудь JPEG- или PNG-файла.
     
     
  • 3.15, chinarulezzz (ok), 04:38, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://github.com/kaitai-io/kaitai_struct/wiki/FAQ#how-does-it-compare-to-
     
     
  • 4.16, GreyCat (ok), 08:45, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что самое смешное - там сейчас ни одного из языков описания бинарных форматов не затронуто. Речь про DFDL, BinPAC, PacketTypes, DataScript, PADS, PEG и т.п.
     

  • 1.6, Аноним (-), 22:39, 10/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    интересно, может ли эта вещь выполнять роль компилятора/кросскомпилятора, в последствии заменив собой гцц/шланг?
     
     
  • 2.11, Аноним (-), 00:57, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > интересно, может ли эта вещь выполнять роль компилятора/кросскомпилятора, в последствии
    > заменив собой гцц/шланг?

    Столица переезжает в Нью-Васюки!

     
  • 2.14, Led (ok), 04:28, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже не надейся: домашние задания всё равно будут задавать.
     

  • 1.8, zztop (?), 22:55, 10/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Подскажите в какой программе сделана схема в первом изображении?
     
     
  • 2.9, GreyCat (ok), 00:21, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот эта - http://kaitai.io/img/code1.png ? Это HTML, написанный в первом попавшемся текстовом редакторе и отрендеренный в первом попавшемся браузере.
     
     
  • 3.13, chinarulezzz (ok), 04:12, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    подскажите плиз, что за шрифт на скриншоте?
     
     
  • 4.29, GreyCat (ok), 15:26, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На каком из и какой из шрифтов - их тут как бы много?..
     
     
  • 5.33, chinarulezzz (ok), 16:49, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > На каком из и какой из шрифтов - их тут как бы
    > много?..

    http://kaitai.io/img/code1.png

     
     
  • 6.34, GreyCat (ok), 17:21, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> На каком из и какой из шрифтов - их тут как бы
    >> много?..
    > http://kaitai.io/img/code1.png

    Это те же шрифты, что и на сайте kaitai.io. Exo и Share Tech Mono.

     

  • 1.12, chinarulezzz (ok), 04:09, 11/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Однозначно нужно.

    Что там с поддержкой регулярных выражений?

     
     
  • 2.17, GreyCat (ok), 08:46, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что там с поддержкой регулярных выражений?

    Ничего. А зачем?

     
  • 2.18, Comdiv (ok), 12:27, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько можно судить, грамматика Kaitai Struct мощнее, или, как минимум, не уже регулярных выражений.
     
     
  • 3.19, GreyCat (ok), 12:36, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Насколько можно судить, грамматика Kaitai Struct мощнее, или, как минимум, не уже
    > регулярных выражений.

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

    Бинарные форматы в массе своей куда проще. Здесь нет неоднозначности - они специально так проектируются, чтобы их было легко читать алгоритмом. Соответственно, и нет почти никакой необходимости в механиках неоднозначности.

     
     
  • 4.20, Comdiv (ok), 13:11, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, регулярные выражения в классическом понимании не требуют сложных механизмов разбора. В прагматичных применениях нет смысла замедлять разборщик, позволяя делать откат при разборе текста по приведённому Вами выражению и достаточно жадной стратегии, так как такие выражения не имеют практического смысла, и легко могут быть заменены на нормальные.

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

     
     
  • 5.21, GreyCat (ok), 13:27, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну, регулярные выражения в классическом понимании не требуют сложных механизмов разбора.

    Ну, как минимум DFA-то требуют. Хотя что считать сложным.

    > P.S Обратил внимание на недостатки:
    > 1. В документации отсутсвует грамматика самого Katai Struct, это усложняет ознакомление.

    По-моему, в документации как раз ничего, кроме грамматики и нет :( Для упрощения ознакомления надо по идее писать какие-то туториалы, quick start и человеческие гайды, но мне все некогда, а кто-то еще никак не сподвигнется. Единственный гайд, который до сих пор написали - та самая статья в двух частях про реверсинг VN - но ее сложно назвать "гайдом по инструментарию".

    > 2. Входной документ не проверяется на корректность

    Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных примеров?

    > и генератор легко делает некомпилируемый код

    Это довольно многогранный вопрос, не совсем связанный с корректностью входного ksy. Например, если мы компилируем два ksy по отдельности: FormatA и FormatB, и FormatA ссылается на FormatB. На момент компиляции FormatA компилятор ничего не знает о структуре (и даже существовании) FormatB, поэтому лучшее, что он может сделать, встретив неописанный тип - просто вывести его названием, как есть, в предположении, что это тип верхнего уровня. По отдельности FormatA не скомпилируется. А вот FormatA + FormatB в одном проекте уже дадут искомую работающую связку.

     
     
  • 6.22, Comdiv (ok), 14:05, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных
    > примеров?

    Я не экспериментировал много, просто ввёл такое:

    meta:
      id: Операция Ы


    что разборщик съел и не поморщился, выдав:

    ...
    public class Операция Ы extends KaitaiStruct {
        public static Операция Ы fromFile(String fileName) throws IOException {
            return new Операция Ы(new KaitaiStream(fileName));
        }
    ...

     
     
  • 7.25, GreyCat (ok), 14:14, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Ох. Как раз вроде бы теперь сильно больше проверяется. Можно больше конкретных
    >> примеров?
    > Я не экспериментировал много, просто ввёл такое:
    > meta:
    >   id: Операция Ы

    Да, факт. Не должно. Вообще все идентификаторы как раз проверяются, кроме, как оказалось, этого ;) Сейчас починю.

    Хотя вообще само по себе это наталкивает на забавную дилемму. "Операция Ы", может, и невалидный идентификатор, а вот "операция_ы" (который станет в Java "ОперацияЫ") - вполне себе. Может, разрешить non-ASCII?..

     
     
  • 8.28, Comdiv (ok), 14:45, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если разрешать, тогда, наверное, для целевых языков, не поддерживающих такие сим... текст свёрнут, показать
     
     
  • 9.32, chinarulezzz (ok), 16:47, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проще -- не всегда лучше Предлагаю ограничиться предупреждением А то в начале ... текст свёрнут, показать
     
  • 6.23, chinarulezzz (ok), 14:12, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    О, разработчик! Очень приятно.

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

     
     
  • 7.26, GreyCat (ok), 14:28, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хотел спросить еще, что на счет юзерских
    > функций? Заметил, что есть 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 такой интерфейс.

     
     
  • 8.30, chinarulezzz (ok), 16:45, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ок Если реализуете идею с интерфейсом наружу, то не забудьте про передачу парам... текст свёрнут, показать
     
     
  • 9.35, GreyCat (ok), 17:23, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Например Распаковщик, если что, инициализируется вручную на том же уровне, на к... текст свёрнут, показать
     
  • 6.24, Comdiv (ok), 14:13, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > По-моему, в документации как раз ничего, кроме грамматики и нет :(

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

     
     
  • 7.27, GreyCat (ok), 14:31, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> По-моему, в документации как раз ничего, кроме грамматики и нет :(
    > Я имел ввиду формальное определение в РБНФ или что-то подобное. Такое описание
    > позволяет быстрей ухватить суть за счёт компактности определения - синтаксис серьёзных
    > языков умещается в несколько страниц, простых предметно ориентированных может влезть и
    > в несколько строк. Зависит, конечно, от навороченности языка.

    Тогда нужно придумать какую-то очередную вариацию БНФ для YAML-based форматов. Или можно по идее сделать YAML-схему...

     
     
  • 8.37, Comdiv (ok), 19:45, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если сам YAML вписывается в БНФ, то проблем быть не должно, но всё же РБНФ лучше... текст свёрнут, показать
     
     
  • 9.38, GreyCat (ok), 20:10, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Писать самому парсер YAML - это да, мягко говоря, удручающее занятие Вообще вес... текст свёрнут, показать
     
     
  • 10.40, Comdiv (ok), 20:23, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Конечно, нечто подобное и хотелось бы видеть в качестве входного языка вместо мо... текст свёрнут, показать
     
     
  • 11.41, GreyCat (ok), 20:39, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И тот, и другой выбор - в любом случае спорные с многих точек зрения Кому-то нр... текст свёрнут, показать
     

  • 1.31, Петр Семилетов (?), 16:47, 11/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    необходимо!
     
  • 1.36, КО (?), 18:52, 11/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вот бы кто скрестил с Orcc (http://orcc.sourceforge.net/), там у них в библиотечке https://github.com/orcc/orc-apps есть много интересный форматов, вроде HEVC...
     
     
  • 2.39, GreyCat (ok), 20:13, 11/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот бы кто скрестил с Orcc (http://orcc.sourceforge.net/), там у них в библиотечке
    > https://github.com/orcc/orc-apps есть много интересный форматов, вроде HEVC...

    Интересная ссылка, спасибо. Попробую может быть с ними связаться и пообщаться.

     

  • 1.43, Аноним (-), 05:34, 12/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Прекрасно оформленная новость и очень крутой апдейт с кучей полезностей!
     
  • 1.44, Аноним (-), 06:03, 12/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Увы, пока очень слабо. Но потенциал для развития есть. Автор, откройте драфт какого-нибудь стандарта, например, H.264 и сами все поймете.
     
     
  • 2.45, GreyCat (ok), 15:34, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А драфт-то зачем? ;)
     
     
  • 3.46, Max (??), 16:44, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А как можно начать считывание типов со смещением от конца потока?
     
     
  • 4.47, GreyCat (ok), 16:45, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А как можно начать считывание типов со смещением от конца потока?

       instances:
         foo:
           pos: _io.size - смещение_от_конца

     
     
  • 5.48, Max (??), 17:05, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как ни странно, но именно это я и попробовал сделать в первую очередь...
    Не работает оно(
     
     
  • 6.49, GreyCat (ok), 17:07, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Как ни странно, но именно это я и попробовал сделать в первую
    > очередь...
    > Не работает оно(

    Можно чуть более развернуто - что именно не работает? Не компилируется ksc, не компилируется целевым языком, компилируется, но зачитывает не то, что ожидалось?

     
     
  • 7.50, Maxim (??), 17:23, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А теперь до меня дошло, что в ksv не подсвечиваются секции указанные в instances...
    Печально. Я думал, что оно тоже должно подсвечиваться.
     
     
  • 8.51, GreyCat (ok), 17:24, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще должно Сейчас проверю Можно какой-нибудь пример ... текст свёрнут, показать
     
     
  • 9.52, Maxim (??), 17:26, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    meta id test endian le seq - id header type u4 instances offs... текст свёрнут, показать
     
     
  • 10.53, GreyCat (ok), 17:34, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, факт, так не определяется Вообще, в реальной жизни это практически не замет... текст свёрнут, показать
     
     
  • 11.59, Maxim (??), 21:58, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за исправление Теперь все работает как надо Еще я хотел узнать, а можн... текст свёрнут, показать
     
     
  • 12.60, GreyCat (ok), 22:00, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Эм, я вроде бы пока ничего не исправлял А в каком выражении его хочется получ... текст свёрнут, показать
     
     
  • 13.61, Maxim (??), 22:07, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как так Я обновил ksv до версии 0 5 и проблема исчезла instances test p... текст свёрнут, показать
     
     
  • 14.62, GreyCat (ok), 22:13, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    0 5 выпустилась в более-менее штатном режиме по итогам последних нескольких меся... текст свёрнут, показать
     
     
  • 15.63, Maxim (??), 22:20, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А вот я уже не наблюдаю Зато значительно компактнее ... текст свёрнут, показать
     
     
  • 16.64, GreyCat (ok), 22:21, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Какой из вариантов компактнее ... текст свёрнут, показать
     
     
  • 17.65, Maxim (??), 22:23, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Тут дело в другом Какой из вариантов рабочий Я не совсем понял, как заставит... текст свёрнут, показать
     
     
  • 18.66, GreyCat (ok), 22:27, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вам что нужно получить-то в итоге У вас есть что-то типа types main se... текст свёрнут, показать
     
     
  • 19.67, Maxim (??), 22:33, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Да Именно то, что мне нужно Просто не привык я к таком OOP Спасибо ... текст свёрнут, показать
     
  • 19.68, Maxim (??), 22:57, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, в данном случае надо сбросить подсветку родительской секции В данном сл... текст свёрнут, показать
     
  • 3.54, Аноним (-), 19:05, 12/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А драфт-то зачем? ;)

    Драфты бесплатные, скачать можно.

     

  • 1.55, Вареник (?), 23:39, 14/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нужная штука. Как бы так ее скрестить с Thrift/Avro....
     
     
  • 2.56, GreyCat (ok), 08:36, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Нужная штука. Как бы так ее скрестить с Thrift/Avro....

    А зачем? Разбирать Thrift или Avro в KS?

     

  • 1.57, КО (?), 18:00, 15/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Битовые поля поддерживаются? Или можно ли таким инструментом описывать регистры аппаратуры, где далеко не все поля кратны байтам?
     
     
  • 2.58, GreyCat (ok), 18:01, 15/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Битовые поля поддерживаются? Или можно ли таким инструментом описывать регистры аппаратуры,
    > где далеко не все поля кратны байтам?

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

     
     
  • 3.69, Rustlang (?), 12:21, 17/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Здравствуйте. Мне попался бинарный файл, который содержит в качестве дескриптора таблицу вида: тип элемента+конец смещения относительно начала файла.
    Размер элемента определяется разностью между концом и началом, но началом служит конец блока дескрипторов, а эту информацию внутри instances никак не получить...
    Нужно все-таки научить этот язык итерировать списки.
    И я так и не нашел как создавать предусловия для цикла.
     
     
  • 4.70, GreyCat (ok), 22:33, 23/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Очень мало что понял без более конкретных примеров, но попробую ответить.

    > Размер элемента определяется разностью между концом и началом, но началом служит конец > блока дескрипторов, а эту информацию внутри instances никак не получить...

    Если нужно получить "начало" через конец блока дескрипторов - то, вероятно, нужно создать отдельный элемент в seq, который бы начинался сразу после этого самого блока дескриптора - он создаст поток, в этом потоке размечать уже instances. Индексация при этом уже будет с 0, получать ничего не нужно.

    Альтернативный (но относительно хаковый) вариант - каким-то образом сделать так, чтобы после блока дескрипторов вызвался _io.pos и сохранился где-то (в вычислимом instance, например). А затем уже отчитывать вручную от него.

    > Нужно все-таки научить этот язык итерировать списки.

    Зачем?

    > И я так и не нашел как создавать предусловия для цикла.

    Никак.

     
     
  • 5.71, Maxim (??), 23:20, 24/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Если нужно получить "начало" через конец блока дескрипторов - то, вероятно, нужно
    > создать отдельный элемент в seq, который бы начинался сразу после этого
    > самого блока дескриптора - он создаст поток, в этом потоке размечать
    > уже instances. Индексация при этом уже будет с 0, получать ничего
    > не нужно.

    Вот именно, что нужно не просто получить "начало", а использовать блок дескрипторов для разбора этих элементов. Нужно как-то итерировать блок дескрипторов внутри instances после блока...

     
     
  • 6.72, GreyCat (ok), 19:20, 25/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Если нужно получить "начало" через конец блока дескрипторов - то, вероятно, нужно
    >> создать отдельный элемент в seq, который бы начинался сразу после этого
    >> самого блока дескриптора - он создаст поток, в этом потоке размечать
    >> уже instances. Индексация при этом уже будет с 0, получать ничего
    >> не нужно.
    > Вот именно, что нужно не просто получить "начало", а использовать блок дескрипторов
    > для разбора этих элементов. Нужно как-то итерировать блок дескрипторов внутри instances
    > после блока...

    Можно какой-то чуть более конкретный пример? Я пока понял, что вроде бы речь идет о случае, когда есть два отдельных массива (прямо совсем отдельных, чуть ли не в разных объектах на разных уровнях лежащих), и надо итерироваться сразу по обоим одновременно?

     
     
  • 7.73, Max (??), 03:09, 26/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну почти так.
    Нужно сначала получить все дескрипторы, а потом уже получить второй массив.
    Могу скинуть пример позже.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру