Можно ли использовать Perl6 грамматику на растровых данных?(Вариант использования: облачная оптимизация проверки GeoTIFF) - PullRequest
0 голосов
/ 03 февраля 2019

Несколько вопросов прочесывают грамматику perl6 и растровые (в общем случае двоичные данные).Насколько я понимаю, текстовый подход состоит в том, чтобы работать на трех грамматиках уровня графемы, можем ли мы подходить к растровым данным таким образом?Можем ли мы сделать собственное определение графемы для доступа к растровым данным или базовую единицу двоичных данных для их анализа с использованием грамматик?

Учитывая, что perl6 определяется грамматиками perl6, можем ли мы определить похожие грамматики как своего рода «проверочный» тестс основным случаем, если грамматика может анализировать данные, данные хорошо сформированы и структурно проверены?Используя этот подход для текстовых данных, это очевидно для грамматик, поскольку базовая единица является тексто-ориентированной, но можем ли мы настроить это внутреннее определение (например, можно перезаписать :sigspace, чтобы сделать rules и tokens разбор с другим разделителем для графемы) для включения мощности грамматик в области двоичных данных?

Спасибо!

Для фоновой части:

В прошломЧерез несколько недель я начинаю изучать Perl6 по личным интересам.После того, как увидел этот доклад в FOSDEM 2019 , я начал спрашивать себя (и окружающих меня людей) об использовании грамматик для проверки / анализа двоичных данных.Мой пример использования будет, например, для репликации валидатора Cloud Optimized Geotiff без поддержки привязки GDAL (я еще не видел его в perl6).Для меня это явно учебный проект.

Спецификация для оптимизированного для облака геотипа

На данный момент основная идея состоит в том, чтобы проанализировать двоичную структуру с помощью грамматик perl6если это возможно в качестве первого базового шага, в надежде иметь возможность проверить данные и метаданные в качестве основной цели.

Примечание: не носитель языка, если некоторые части нуждаются в переписывании / точности, не стесняйтесь указывать.

1 Ответ

0 голосов
/ 07 февраля 2019

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


Относительно поддержки связывания для библиотеки X (в тестовом случае это был GDAL), стратегия в сообществе perl6 заключается в том, чтобы либо использовать:

  • Использовать модули Inline :: Foo, направленные на запуск и доступ к экосистеме языка Foo (путемпример: Inline :: Perl5, Inline :: Python и т. д.) Список модулей Inline :: X из каталога модулей Perl6 ;
  • Используйте или напишите привязку, используя NativeCall для привязки к динамическим библиотекам, которые следуют C Calling Covention;
  • Используйте или напишите собственный модуль perl6.

Что касается анализа двоичных данных, я разделю тему на две части:

  1. Вообще говоря;
  2. Использование грамматик;

1.Вообще говоря,

Использование модуля P5pack или использование Inline :: Perl5 для использования unpack / pack на самом деле(с perl6.c) лучше всего разбирать структуру двоичных данных (первый кажется предпочтительным, так как это собственный модуль).Перейдите к первому комментарию от @raiph к SO anwser, в котором показан базовый вариант использования.

2.Использование грамматик

С perl6.c грамматики могут только анализировать текст.Тем не менее, вопрос о разборе двоичных данных кажется умеренно горячим (основываясь на отзывах, замеченных по каналу # perl6 irc), и некоторые из них, которые можно документировать, но не реализуют, похоже, прокладывают путь с надеждой увидеть, что это произойдет в будущем.(ближний или дальний?).

В последней части the @ raiph's anwser перечислено множество ресурсов, направленных на это направление.Более того, в Synopses 05 - Regexes and Rules: строка 432 a: вызывается модификатор байтов.Нам нужно будет увидеть, в какой момент эти модификаторы будут реализованы и чего не хватает, чтобы привести их к языку.На канале # perl6 irc MasterDuke сказал: «Кроме того, я думаю, что двоичные операции чтения / записи nqp, которые недавно провела jnthn и девять реализовали, были предварительным условием для чего-либо дальнейшего» * ​​1048 *.Я все еще должен исследовать, о чем именно он говорит, но, похоже, он идет в правильном направлении.

Один из главных моментов, IMO, связан с определением графемы, основанным на UTF-8.Если мы сможем переписать определение графемы на пользовательское определение для специализированной грамматики, как мы можем сейчас перезаписать модификатор: sigspace, чтобы повлиять на разделители для rules и tokens, мы получим новый способ работы сструктура данных и грамматика.На данный момент графема определяется на уровне строки, а не на уровне грамматики или мета.См. Комментарии @timotimo, ссылающиеся на документ UTF-8, описывающий правила границ кластера графем.

Способ изменения правил был связан с помощью @jjmererlo: Синтаксический анализ формата GFX3 с грамматиками perl6 .

...