From af71d23a80a168afbea32e40e51960f77f6273e3 Mon Sep 17 00:00:00 2001 From: Sebastien Binet Date: Thu, 26 Aug 2021 15:28:53 +0200 Subject: [PATCH] 2021-08-26-atlas-grok: fix EgammaContainer_v1 definition, add pointers to Arrow Signed-off-by: Sebastien Binet --- 2021/2021-08-26-atlas-grok/_code/xaod_egamma.grok | 2 +- 2021/2021-08-26-atlas-grok/talk.slide | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/2021/2021-08-26-atlas-grok/_code/xaod_egamma.grok b/2021/2021-08-26-atlas-grok/_code/xaod_egamma.grok index 6097f05..cf24159 100644 --- a/2021/2021-08-26-atlas-grok/_code/xaod_egamma.grok +++ b/2021/2021-08-26-atlas-grok/_code/xaod_egamma.grok @@ -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. diff --git a/2021/2021-08-26-atlas-grok/talk.slide b/2021/2021-08-26-atlas-grok/talk.slide index 19779c6..1be510e 100644 --- a/2021/2021-08-26-atlas-grok/talk.slide +++ b/2021/2021-08-26-atlas-grok/talk.slide @@ -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 -- 2.45.2