2 files changed, 4 insertions(+), 2 deletions(-)

M 2021/2021-08-26-atlas-grok/_code/xaod_egamma.grok
M 2021/2021-08-26-atlas-grok/talk.slide

@@ 8,7 8,7 @@ import (
 )
 
 type EgammaContainer    EgammaContainer_v1
-type EgammaContainer_v1 []ath.DataVector[Egamma_v1]
+type EgammaContainer_v1 ath.DataVector[Egamma_v1]
 type Egamma             Egamma_v1
 
 // Egamma_v1 represents an e/gamma object.

@@ 64,7 64,8 @@ Each `xAOD` class description would hold:
 `grok` would process these `.grok` files and:
 
 - generate the corresponding `C`, `C++`, `Go`, ... code to create, access and modify `xAOD` data
-- (possibly) generate metadata informations describing the memory layout known at compile-time (à la `NumPy` or `Arrow`)
+- (possibly) generate metadata informations describing the memory layout known at compile-time
+  - [PEP-3118](https://www.python.org/dev/peps/pep-3118/), [NumPy](https://numpy.org/devdocs/reference/generated/numpy.frombuffer.html), [Apache Arrow](https://arrow.apache.org)
 
 The generated code would be committed to the repository: clients of `xAOD` packages would not need to know about `grok`.
 


@@ 201,6 202,7 @@ Right now, `grok` is a simple self-contained, statically-compiled, portable [Go]
 - assess performances over a set of packages
   - if needed, define an archive format for the result of "compiled" `.grok` files to efficiently store the IR (and avoid importing+re-parsing over and over `.grok` files)
 - flesh out the import mechanism (I've cheated for now w/ `AthContainers`)
+- define execution model (per class, per package or per project)
 
 ## Open issues