cogeotiff | Cloud Optimized GeoTiff utility tools | GCP library

As only comments where posted, I will summarize all the answers I got from the comments here, my further research and the #perl6 IRC chatroom.

Concerning the support of binding for X library (in the test case, it was GDAL), the strategy inside the perl6 community is to either leverage :

• Use the Inline::Foo modules aiming at launching and accessing the ecosystem of the Foo language (by example : Inline::Perl5, Inline::Python and so on). List of Inline::X modules from the Perl6 Module Directory ;
• Use or write a binding using NativeCall to bind to dynamic libraries who follow the C Calling Covention ;
• Use or write a native perl6 module.

Concerning the parsing of binary data, I'll split the subject in two parts :

1. Generally speaking ;
2. Leveraging Grammars ;

Leveraging the P5pack module or using Inline::Perl5 to use the unpack/pack is actually (with perl6.c) the best to parse binary data structure (the former seems favoraed as it's native module). Go to see first comment from @raiph to a SO anwser showing a basic use case.

With perl6.c, grammars can only parse text. However, the question about parsing binary data seems to be moderatly hot (based on feedbacks seen on the #perl6 irc channel) and a few to document, yet not implemetend, seems to pave the way with a hope to see it happens in a future (near or distant?).

The last part of the @raiph's anwser list a lot of ressources aiming at that direction. Moreover, in the Synopses 05 - Regexes and Rules : line 432 a :bytes modifier is evoked. We will have to see at which point those modifiers will be implemented and what is missing to bring them to the language. On the #perl6 irc channel, MasterDuke said « also, i think the nqp binary reading/writing ops that jnthn recently specced and nine implemented were a prerequisite for anything further ». I still have to investigated what exactly he is talking about but it seems to go to the good direction.

One of the main point, IMO, is the related to the grapheme definition based on the UTF-8 one. If we were able to overwrite the grapheme definition to a custom one for specialized grammar as we can for now overwrite the :sigspace modifier to affect what is the separators for rulesand tokens, we will access a new way to operate around data structure and grammars. For now, the grapheme is defined in the string-level not the grammar-level or meta. See @timotimo comments linking to the UTF-8 document describing the Grapheme Cluster Boundary Rules.

A way to bend the rules was linked by @jjmererlo : Parsing GFX3 format with perl6 grammars.