Очешуенная новость! У меня уже есть некоторые наработки, нужно их причесать и добавить вам в каталог.

Kaitai это ня^^

А существует парсер для plain c?

У меня уже есть некоторые наработки, нужно их причесать и добавить вам в каталог.

Велкам :) Я тут сам несколько поофигел, когда начали считать форматы и контрибьюторов - оказалось, что уже 79 форматов и 18 контрибьюторов.

А существует парсер для plain c?

Имеется в виду, можно ли генерировать из ksy парсеры в plain C?

Имеется в виду, можно ли генерировать из ksy парсеры в plain C?

Да, именно так.

можно ли генерировать из ksy парсеры в plain C?

Пока нет, основной затык в нахождении всех устраивающей библиотеки базовых структур (растущие массивы элементов, строки и т.п.).

В какой-то степени, я надеюсь, что Go станет этаким «пробным шаром», который концептуально будет генерировать полностью такой же код, как должен был бы генерироваться для C (т.е., например, строго без exceptions и не укладывающийся в парадигму «все является выражением»), но с адекватной stdlib, где все-таки есть упомянутые выше массивы, строки и т.д.

Отличная новость!

YSFlight: *.dat, *.dnm, *.lst, *.acp, *.srf, *.yfs, *.ter, *.pc2, *.stp, *.fld, *.ist

Добавьте форматы файлов используемые в бесплатном авиасимуляторе YSFlight, а также сетевой протокол (NETVERSION 20150425) используемый для мультиплея на портах 7914/7915
1) https://ysflight.org/files/
2) https://ysflight.org/serverlist/
3) https://github.com/ysflight-opensource

«YSFlight Handbook» содержит спецификации - https://forum.ysfhq.com/viewtopic.php?f=147&t=8172#p92286

На базе проекта Kaitai Struct запущен сайт-каталог

А генерацию PDF-каталога можете прикрутить? Чтобы можно было выбрать необходимые форматы и сгенерировать доки

Ну емана, кто ж заместо тебя все эти форматы разбирать будет, она ж не структурирована?

Ну, я буду рад помочь. Что нужно делать? Есть пошаговое руководство?

P.S.: Есть прямые ссылки на DEB-файлы для 14.04 (или хотя бы для 16.04)?

There is an official .deb repository available for Debian / Ubuntu-based distributions

Сделайте нормальное IDE на Python+Tkinter/wxWidgets — для работы в офлайне на десктопе.

Ну, или для Geany плагин сделайте хотя бы.

WebIDE/JavaScript/онлайн — это жесть....

Что нужно делать?

Создать .ksy-файл для каждого из запрошенных форматов.

Есть пошаговое руководство?

http://doc.kaitai.io/ и далее по ссылкам - в помощь :)

Сделайте нормальное IDE на Python+Tkinter/wxWidgets — для работы в офлайне на десктопе.

Patches are welcome :) Исходя из того, что до сих пор никто не сделал - видимо, людям хватает либо Web IDE, либо любимого текстового редактора + консольного визуализатора.

WebIDE/JavaScript/онлайн — это жесть....

Оно не онлайн, если что. Никто не мешает то же самое запустить абсолютно без доступа к сети.

А генерацию PDF-каталога можете прикрутить?

Спасибо за идею, подумаем.

Оно не онлайн, если что. Никто не мешает то же самое запустить абсолютно без доступа к сети.

Всякие JavaScript-based «програмки» превращают мой ноут в камин, в котором работает турбо-нагнетатель

либо любимого текстового редактора + консольного визуализатора.

Добавьте «Kaitai plugin for Geany» себе в список feature-request'ов.

У меня аж пригорело, откуда вы такие берётесь, и как вас земля носит?

на Python+Tkinter

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

Geany

И опять маргинальщина. Зачем кому-то корячиться и пилить плагин для IDE с полутора юзерами?

Пиши сам, пиявка.

У меня аж пригорело

Да, это видно.

Мало того, что клянчишь что-то

Вообще-то, он не халяву клянчит, а готов помочь проекту, но тяжеловесные инструменты его отпугивают.

так ведь ещё и пытаешься впарить угодные тебе инструменты для реализации

Да, список конкретных инструментов меня тоже покоробил, тут товарищ погорячился, но это не повод обзывать его нехорошими словами. Лично я тоже недоволен вебнёй и сильно бы обрадовался среде на Qt/C++ либо GTK+GObject/C, но сам писать оную, увы, не готов, поэтому смиренно прошу авторов рассмотреть вариант написания таковой, когда-нибудь, если можно.

Ну а использовать в качестве ругательного словом «маргинальщина» на ресурсе, посвящённом операционной системе, занимающей аж ДВАПРОЦЕНТА рынка десктопов - это ты знатно повеселил, конечно.

Можно ли им описывать формат древовидных структур?

Планируется ли поддержка каких-либо других методов шифрования/дешифровки кроме XOR? Я хотел как-то описать формат файлов в которых гном хранит пароли, но уперся в то что часть файла должна быть расшифрована перед разбором.

Планируется ли поддержка каких-либо других методов шифрования/дешифровки кроме XOR?

Вот, да. Тоже интересует этот вопрос.

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

Вы бы знали, сколько таких запросов валится каждую неделю ;) Из языков программирования, например, просили уже в разных видах Ocaml, Haskell, Pascal, Ada, какие-то виды Scheme, Nim, Elixir, Vala, кучу всяких местечковых вариантов JavaScript и т.д. - в общем, разве что 1С, по-моему, не просили ;)

Можно ли им описывать формат древовидных структур?

Разумеется. Protobuf, AVI или там, не знаю, ext2 - достаточное доказательство?

Планируется ли поддержка каких-либо других методов шифрования/дешифровки кроме XOR?

Планируется: https://github.com/kaitai-io/kaitai_struct/issues/45 - если хотите ускорить этот процесс - присоединяйтесь - нужно по хорошему выписать какие-то алгоритмы и библиотеки, которые есть везде, создать какой-то стандартизированный набор идентификаторов и параметров этих алгоритмов и написать, как вызов конкретного алгоритма на каждом из поддерживаемых языков будет выглядеть. Не так страшно, на самом деле, но довольно объемная задача.

Сделайте нормальный HTTPS, что ли, а то некомильфо в 2017 году-то.

Пока нет, основной затык в нахождении всех устраивающей библиотеки базовых структур (растущие массивы элементов, строки и т.п.).

Не рассматриваете вариант написания своей? Отсутствие С в качестве выходного языка - пожалуй, единственное, что до сих пор останавливает от освоения этого инструмента. C# и Java - это круто, но часто не то, что нужно, а плюсы (да еще и с STL) - это совсем не С.

Профиты с удовлетворения хотелок таких поциентов как максимум в халявных фейспалмах. Нужность нормальных инструментов я не оспариваю, но разрабы и сами всё понимают.

На счёт маргинальщины не согласен. Пусть даже 2%, но с учётом размера рынка линуксы никак не выглядят маргинальщиной.

Сделайте нормальный HTTPS, что ли, а то некомильфо в 2017 году-то.

Мда, eSyr, я от тебя не ожидал...

Не рассматриваете вариант написания своей?

Кто сейчас мешает вызвать C++-код из C? Никто. Вот, можно считать, что «своя» есть - она называется STL. Много желающих так делать? Что-то не наблюдаю.

Так что «своя» скорее всего будет нужна всем примерно с такой же степенью, т.е. никак не будет нужна. Все C-проекты, как правило, какие-то состоявшиеся большие начинания, со своей историей, гигантской codebase и своими практиками, как по их мнению правильно читать файлы, делать массивы и работать со строками. В лучшем случае есть хоть какой-то общий знаменатель типа glib, но опять же - проектов на glib даже не половина и не треть от общего числа проектов на C.

Нужность нормальных инструментов я не оспариваю, но разрабы и сами всё понимают.

Да с инструментами вроде бы все относительно неплохо. Огромная туча народа не то, что не жалуется, а вполне себе хвалит.

Кто сейчас мешает вызвать C++-код из C? Никто. Вот, можно считать, что «своя» есть - она называется STL. Много желающих так делать? Что-то не наблюдаю.

Потому что по факту это будет все-таки плюсовый код, со всеми вытекающими.

А в чем тогда проблема выбора готовой библиотеки?

Я не предъявляю каких-то претензий, просто интересно получить информацию из первых рук. Если поддержка plain C не планируется, буду знать, что под мои задачи проект не подходит и можно за ним не следить, вот и все.

А в чем тогда проблема выбора готовой библиотеки?

В том, что не очень хочется тратить достаточно большое количество времени на разработку вещи, которая окажется никому толком не нужна. Вот вам лично вариант с glib будет чем-то более интересен, чем вариант с STL?

Если поддержка plain C не планируется

Поддержка обсуждается уже больше года. Принципиальных возражений против, разумеется, нет. Есть n-ное количество практических сложностей (например, то, что C - язык без исключений и надо предусматривать возможность возврата кода ошибки на каждый случай, или то, что в C огромная масса всего будет делаться не выражениями, а именно операторами или вызовами функций с параметрами по указателю), но это все постепенно решается. Есть n-ное количество теоретических сложностей: начиная от «кому это все вообще будет нужно», плавно переходя «кому это будет нужно, если мы привяжем это к библиотеке N».

А есть какой-то мануал добавлению в ваш генератор парсеров дополнительного языка?
Я мог бы Rust добавить, проект очень крутой

/me с надеждой: что и в свои проекты можно будет такие парсилки форматов оттуда забирать?

Посмотрел. Для интересующихся - каждый формат под своей лицензией выложен, хорошо бы сказать об этом сразу в новости.

Поддержка форматов со сжатием — как в предыдущих версиях, или есть изменения?

Проект отличный, спасибо разработчикам.

Что же касается С, то я думаю всем кому действительно нужна автоматизация, давно используют вариант с STL. Для совсем низкоуровневых вещей Kaitai будет выстрелом из пушки по воробьям: если на девайсе 256кб памяти, вряд ли кто-то сможет заюзать Kaitai, всё равно для таких вещей всё как правило пишется с нуля.

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

*fixed

очень немногие не будут довольны.

очень многие будут недовольны.

в общем, разве что 1С, по-моему, не просили ;)

Это упущение, надо срочно исправить!

Да, я это и хотел написать, но что-топошло не так.

А есть какой-то мануал добавлению в ваш генератор парсеров дополнительного языка?

http://doc.kaitai.io/new_language.html

Я мог бы Rust добавить, проект очень крутой

Вот человек уже пытался, даже рантайм написал, но в итоге не осилил: https://github.com/kaitai-io/kaitai_struct/issues/22

Поддержка форматов со сжатием — как в предыдущих версиях, или есть изменения?

Новых релизов пока не выходило. В 0.8, когда он выйдет, основными изменениями будут поддержка вычисляемой endianness, ограниченная поддержка записи и ограниченная поддержка go. По сжатиям как таковым ситуация действительно практически не изменялась: либо zlib, либо через внешние модули.

Для совсем низкоуровневых вещей Kaitai будет выстрелом из пушки по воробьям: если на девайсе 256кб памяти, вряд ли кто-то сможет заюзать Kaitai, всё равно для таких вещей всё как правило пишется с нуля.

Если на девайсе очень-очень мало памяти, то, как правило, проблема будет в том, что программа строится в совсем другой парадигме, чем ту, которую предлагает KS. Сейчас KS раскладывает все в памяти и генерирует интерфейсы, которые позволяют обращаться к этому всему чем-то типа my_object.header.aux_header.some_field. Там же это все не нужно, каждый лишний байт в памяти держать накладно, поэтому все по-максимуму на потоке и в памяти если и оставляют, то совсем не полное отображение объекта, а какие-то избранные кусочки.

«Постоянный» инструмент - компилятор ksc, вызывается из командной строки и, как правило, вообще не руками, а из какой-нибудь build-системы.

В том, что не очень хочется тратить достаточно большое количество времени на разработку вещи, которая окажется никому толком не нужна. Вот вам лично вариант с glib будет чем-то более интересен, чем вариант с STL?

Честно говоря, не очень - мне бы хотелось видеть какую-нибудь более легковесную библиотеку. В идеале - чтобы сгенерированный код вообще ничего, кроме libc, не требовал. С другой стороны, я понимаю, что это СПО, поэтому «тебе нужно - ты и пили» и участники проекта сами вправе принимать решения.

Поддержка обсуждается уже больше года. ...

Хорошо, я понял. Спасибо за информацию!

Честно говоря, не очень - мне бы хотелось видеть какую-нибудь более легковесную библиотеку. В идеале - чтобы сгенерированный код вообще ничего, кроме libc, не требовал.

К сожалению, в libc нет ни адекватных ресайзящихся типизированных массивов, ни строк, ни даже толком массивов байт. То есть либо мы статически засовываем в сгенерированный код еще тучу всего самописного, либо статически линкуемся с libkaitaistruct.a, либо динамически линкуемся с libkaitaistruct.so, либо тащим еще 1-2 «легковесных» библиотеки.

И да, я прекрасно понимаю, что в C - каждая дополнительная библиотека - это боль и печаль :( - по крайней мере, в отличие от тех же C# / Java / Python / Ruby / PHP / Perl, где дополнительная библиотека = +1 строчка в файле с зависимостями.

И когда там появится полное и непротиворечивое описание форматов *.doc/*.xls ?

Когда его туда кто-нибудь положит, очевидно? Сейчас там есть описание Microsoft'овского CFB, на которых основывается и doc, и xls.

Сейчас там есть описание Microsoft'овского CFB, на которых основывается и doc, и xls.

CFB — это конечно здорово, но говорить, что doc и/или xls основываются на используемом контейнере наверное не совсем правильно.

описание форматов *.doc/*.xls

И кому оно нужно?