pixie-py 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- pixie_py-0.1.0/.clang-format +1 -0
- pixie_py-0.1.0/.github/workflows/release.yml +75 -0
- pixie_py-0.1.0/.github/workflows/tests.yml +16 -0
- pixie_py-0.1.0/.gitignore +6 -0
- pixie_py-0.1.0/AGENTS.md +37 -0
- pixie_py-0.1.0/CMakeLists.txt +38 -0
- pixie_py-0.1.0/DESIGN.md +285 -0
- pixie_py-0.1.0/LICENSE +201 -0
- pixie_py-0.1.0/PKG-INFO +289 -0
- pixie_py-0.1.0/README.md +74 -0
- pixie_py-0.1.0/examples/encodings.py +15 -0
- pixie_py-0.1.0/examples/louds.py +8 -0
- pixie_py-0.1.0/examples/rmq.py +16 -0
- pixie_py-0.1.0/examples/traversal.py +17 -0
- pixie_py-0.1.0/pyproject.toml +28 -0
- pixie_py-0.1.0/src/bindings.cpp +1139 -0
- pixie_py-0.1.0/src/encoding_input.h +90 -0
- pixie_py-0.1.0/src/native_dispatch.h +237 -0
- pixie_py-0.1.0/src/pixie/__init__.py +20 -0
- pixie_py-0.1.0/src/pixie/__init__.pyi +203 -0
- pixie_py-0.1.0/src/pixie/py.typed +0 -0
- pixie_py-0.1.0/src/pixie/visualization.py +237 -0
- pixie_py-0.1.0/src/pointer_bindings.h +167 -0
- pixie_py-0.1.0/src/pointer_registration.h +379 -0
- pixie_py-0.1.0/src/rmq_bindings.cpp +260 -0
- pixie_py-0.1.0/tests/helpers.py +50 -0
- pixie_py-0.1.0/tests/test_construction.py +155 -0
- pixie_py-0.1.0/tests/test_display.py +174 -0
- pixie_py-0.1.0/tests/test_encodings.py +212 -0
- pixie_py-0.1.0/tests/test_louds.py +106 -0
- pixie_py-0.1.0/tests/test_public_names.py +33 -0
- pixie_py-0.1.0/tests/test_rmq.py +132 -0
- pixie_py-0.1.0/tests/test_traversal.py +108 -0
|
@@ -0,0 +1 @@
|
|
|
1
|
+
BasedOnStyle: Chromium
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
name: release
|
|
2
|
+
|
|
3
|
+
on:
|
|
4
|
+
push:
|
|
5
|
+
tags: ['v*']
|
|
6
|
+
|
|
7
|
+
permissions:
|
|
8
|
+
contents: read
|
|
9
|
+
|
|
10
|
+
jobs:
|
|
11
|
+
build:
|
|
12
|
+
runs-on: ubuntu-latest
|
|
13
|
+
steps:
|
|
14
|
+
- uses: actions/checkout@v4
|
|
15
|
+
- uses: actions/setup-python@v5
|
|
16
|
+
with:
|
|
17
|
+
python-version: '3.12'
|
|
18
|
+
- name: Check release version
|
|
19
|
+
run: |
|
|
20
|
+
python - <<'PY'
|
|
21
|
+
import os, tomllib
|
|
22
|
+
with open("pyproject.toml", "rb") as f:
|
|
23
|
+
version = tomllib.load(f)["project"]["version"]
|
|
24
|
+
assert os.environ["GITHUB_REF_NAME"] == f"v{version}"
|
|
25
|
+
PY
|
|
26
|
+
- run: python -m pip install build twine
|
|
27
|
+
- run: python -m build --sdist
|
|
28
|
+
- run: python -m twine check --strict dist/*
|
|
29
|
+
- uses: actions/upload-artifact@v4
|
|
30
|
+
with:
|
|
31
|
+
name: release-distributions
|
|
32
|
+
path: dist/*.tar.gz
|
|
33
|
+
if-no-files-found: error
|
|
34
|
+
|
|
35
|
+
test:
|
|
36
|
+
needs: build
|
|
37
|
+
runs-on: ubuntu-latest
|
|
38
|
+
strategy:
|
|
39
|
+
matrix:
|
|
40
|
+
python: ['3.10', '3.12']
|
|
41
|
+
steps:
|
|
42
|
+
- uses: actions/checkout@v4
|
|
43
|
+
- uses: actions/setup-python@v5
|
|
44
|
+
with:
|
|
45
|
+
python-version: ${{ matrix.python }}
|
|
46
|
+
- uses: actions/download-artifact@v4
|
|
47
|
+
with:
|
|
48
|
+
name: release-distributions
|
|
49
|
+
path: dist
|
|
50
|
+
- name: Install the release archive
|
|
51
|
+
run: python -m pip install dist/*.tar.gz pytest -Cbuild.tool-args=-j2
|
|
52
|
+
- run: python -m pytest
|
|
53
|
+
- run: python examples/louds.py
|
|
54
|
+
- name: Check core revision
|
|
55
|
+
run: |
|
|
56
|
+
python - <<'PY'
|
|
57
|
+
import pathlib, re, pixie
|
|
58
|
+
expected = re.search(r'set\(PIXIE_REVISION ([0-9a-f]+)\)', pathlib.Path('CMakeLists.txt').read_text()).group(1)
|
|
59
|
+
assert pixie.core_revision == expected, pixie.core_revision
|
|
60
|
+
PY
|
|
61
|
+
|
|
62
|
+
publish:
|
|
63
|
+
needs: [build, test]
|
|
64
|
+
runs-on: ubuntu-latest
|
|
65
|
+
environment:
|
|
66
|
+
name: pypi
|
|
67
|
+
url: https://pypi.org/project/pixie-py/
|
|
68
|
+
permissions:
|
|
69
|
+
id-token: write
|
|
70
|
+
steps:
|
|
71
|
+
- uses: actions/download-artifact@v4
|
|
72
|
+
with:
|
|
73
|
+
name: release-distributions
|
|
74
|
+
path: dist
|
|
75
|
+
- uses: pypa/gh-action-pypi-publish@release/v1
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
name: tests
|
|
2
|
+
on: [push, pull_request]
|
|
3
|
+
jobs:
|
|
4
|
+
python:
|
|
5
|
+
runs-on: ubuntu-latest
|
|
6
|
+
strategy:
|
|
7
|
+
matrix:
|
|
8
|
+
python: ['3.10', '3.12']
|
|
9
|
+
steps:
|
|
10
|
+
- uses: actions/checkout@v4
|
|
11
|
+
- uses: actions/setup-python@v5
|
|
12
|
+
with:
|
|
13
|
+
python-version: ${{ matrix.python }}
|
|
14
|
+
- run: python -m pip install '.[test]'
|
|
15
|
+
- run: python -m pytest
|
|
16
|
+
- run: python examples/louds.py
|
pixie_py-0.1.0/AGENTS.md
ADDED
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# pixie-py
|
|
2
|
+
|
|
3
|
+
- Keep Python bindings and ownership adapters here; consume only public Pixie headers.
|
|
4
|
+
- Keep the Pixie dependency pinned in CMakeLists.txt.
|
|
5
|
+
- Do not expose raw rank/select or RmM components with borrowed source lifetimes.
|
|
6
|
+
- Python succinct trees are immutable; PointerTree is an append-only mutable builder with stable handles. Views and node handles retain their backing owner.
|
|
7
|
+
- Validate inputs and handle provenance before entering unchecked C++ operations.
|
|
8
|
+
- Keep the GIL unless a change explicitly establishes lifetime and concurrency safety.
|
|
9
|
+
- Test navigation against an independent topology oracle, invalid inputs and owner deletion.
|
|
10
|
+
- Use the published core pin by default. For local development, set the shell variable `PIXIE_SOURCE_DIR` to an absolute checkout path and reinstall. Keep local paths out of repository configuration.
|
|
11
|
+
- Run `pytest` and `python examples/louds.py` after building.
|
|
12
|
+
- RMQ persistence must use the CLI's native format and implementation names.
|
|
13
|
+
Artifacts omit source values; Python must retain an owned copy of supplied values.
|
|
14
|
+
Default to full validation, reject trailing bytes, and test CLI-to-Python and
|
|
15
|
+
Python-to-CLI loading with `PIXIE_CLI=/path/to/pixie pytest`.
|
|
16
|
+
|
|
17
|
+
## Python docstrings
|
|
18
|
+
|
|
19
|
+
- Use NumPy-style docstrings for every public Python class, constructor, method,
|
|
20
|
+
function and property, including APIs defined through nanobind.
|
|
21
|
+
- Start with a short sentence explaining what the operation does. A generated
|
|
22
|
+
signature is not a description.
|
|
23
|
+
- Include a `Parameters` section for every public argument except `self`/`cls`.
|
|
24
|
+
State its type, purpose, units, defaults, indexing and valid range where relevant.
|
|
25
|
+
Document each constructor overload and summarize construction in the class docstring.
|
|
26
|
+
- Use `Returns` to explain returned values, especially ownership, snapshots and
|
|
27
|
+
possible `None` results. Use `Raises` for meaningful validation failures and
|
|
28
|
+
`Notes` only for constraints such as lifetime or concurrency.
|
|
29
|
+
- Present bound classes under their public `pixie` module. Generated signatures,
|
|
30
|
+
type representations and argument errors must not expose `pixie._core`.
|
|
31
|
+
Short names such as `Node` in docstrings refer to the public `pixie.Node` type.
|
|
32
|
+
- Keep descriptions concise; omit empty sections. Properties need a short value
|
|
33
|
+
description and type, not a parameter section. Keep type stubs consistent.
|
|
34
|
+
- Put native API docstrings in the nanobind registrations so `help()` and notebook
|
|
35
|
+
tooltips display them. Check the installed runtime docstrings after rebuilding;
|
|
36
|
+
merely checking that `__doc__` exists does not establish useful documentation.
|
|
37
|
+
- Reference convention: https://numpydoc.readthedocs.io/en/latest/format.html
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
cmake_minimum_required(VERSION 3.24)
|
|
2
|
+
project(pixie_py LANGUAGES CXX)
|
|
3
|
+
|
|
4
|
+
find_package(Python 3.10 REQUIRED COMPONENTS Interpreter Development.Module)
|
|
5
|
+
find_package(nanobind CONFIG REQUIRED)
|
|
6
|
+
include(FetchContent)
|
|
7
|
+
|
|
8
|
+
set(PIXIE_SOURCE_DIR "$ENV{PIXIE_SOURCE_DIR}" CACHE PATH "Optional local Pixie checkout")
|
|
9
|
+
set(PIXIE_REVISION be9f30dcc1b823fadf17c3fc67ee7cd425e98ee8)
|
|
10
|
+
# Consume public headers without importing the core's native CPU flags or tests.
|
|
11
|
+
FetchContent_Declare(pixie
|
|
12
|
+
GIT_REPOSITORY https://github.com/Malkovsky/pixie.git
|
|
13
|
+
GIT_TAG ${PIXIE_REVISION}
|
|
14
|
+
GIT_SUBMODULES ""
|
|
15
|
+
SOURCE_SUBDIR pixie-py-headers-only)
|
|
16
|
+
if(PIXIE_SOURCE_DIR)
|
|
17
|
+
set(FETCHCONTENT_SOURCE_DIR_PIXIE "${PIXIE_SOURCE_DIR}")
|
|
18
|
+
endif()
|
|
19
|
+
FetchContent_MakeAvailable(pixie)
|
|
20
|
+
if(NOT EXISTS "${pixie_SOURCE_DIR}/include/pixie/tree/decoded_tree.h")
|
|
21
|
+
message(FATAL_ERROR "The selected Pixie checkout is missing include/pixie/tree/decoded_tree.h. Use a checkout with the traversal API.")
|
|
22
|
+
endif()
|
|
23
|
+
|
|
24
|
+
nanobind_add_module(_core NB_STATIC src/bindings.cpp src/rmq_bindings.cpp)
|
|
25
|
+
target_compile_features(_core PRIVATE cxx_std_20)
|
|
26
|
+
target_include_directories(_core PRIVATE ${pixie_SOURCE_DIR}/include)
|
|
27
|
+
set(PIXIE_BUILD_REVISION "${PIXIE_REVISION}")
|
|
28
|
+
if(PIXIE_SOURCE_DIR)
|
|
29
|
+
execute_process(COMMAND git rev-parse HEAD WORKING_DIRECTORY "${pixie_SOURCE_DIR}"
|
|
30
|
+
OUTPUT_VARIABLE PIXIE_BUILD_REVISION OUTPUT_STRIP_TRAILING_WHITESPACE)
|
|
31
|
+
execute_process(COMMAND git diff --quiet -- include WORKING_DIRECTORY "${pixie_SOURCE_DIR}"
|
|
32
|
+
RESULT_VARIABLE PIXIE_CORE_DIRTY)
|
|
33
|
+
if(PIXIE_CORE_DIRTY)
|
|
34
|
+
string(APPEND PIXIE_BUILD_REVISION "-dirty")
|
|
35
|
+
endif()
|
|
36
|
+
endif()
|
|
37
|
+
target_compile_definitions(_core PRIVATE PIXIE_PY_CORE_REVISION="${PIXIE_BUILD_REVISION}")
|
|
38
|
+
install(TARGETS _core LIBRARY DESTINATION pixie)
|
pixie_py-0.1.0/DESIGN.md
ADDED
|
@@ -0,0 +1,285 @@
|
|
|
1
|
+
# Python tree experimentation API
|
|
2
|
+
|
|
3
|
+
This document records the agreed design, not a claim that the APIs below are
|
|
4
|
+
already implemented. The current baseline exposes owning LOUDS, BP, DFUDS and
|
|
5
|
+
pointer trees, retained complete-tree views and node handles. Core C++ changes are allowed where needed
|
|
6
|
+
for a clean public API; Python bindings should consume those public contracts.
|
|
7
|
+
|
|
8
|
+
The purpose is interactive exploration and experimentation. Individual Python
|
|
9
|
+
calls to navigation primitives need not approach native-call performance.
|
|
10
|
+
Higher-level operations can execute primarily in C++. Preserve native traversal
|
|
11
|
+
performance where possible; a measured 10–15% overhead can be acceptable when
|
|
12
|
+
it buys a better interface, rather than being a target overhead to spend.
|
|
13
|
+
|
|
14
|
+
## Complete trees and ownership
|
|
15
|
+
|
|
16
|
+
`LoudsTree`, `DfudsTree` and `BPTree` are immutable top-level objects sharing a
|
|
17
|
+
navigation interface corresponding to C++ `TreeBase`. Encoding, rank/select
|
|
18
|
+
and RmM dependencies remain encapsulated by these owning objects. Do not expose
|
|
19
|
+
standalone borrowed rank/select or RmM components in Python.
|
|
20
|
+
|
|
21
|
+
Python node handles, tree views, decoded results and other borrowers retain the
|
|
22
|
+
owners they require. C++ borrowers may continue using const references or
|
|
23
|
+
pointers with explicit lifetime requirements. Python validates handle provenance
|
|
24
|
+
before calling unchecked core operations. A handle includes representation-
|
|
25
|
+
specific information; numeric IDs are not assumed to survive tree conversion.
|
|
26
|
+
|
|
27
|
+
`TreeView` denotes a complete-tree storage view, distinct from a node view or
|
|
28
|
+
an incomplete decoded tree. The view retains its backing owner in Python.
|
|
29
|
+
|
|
30
|
+
### Text and visualization
|
|
31
|
+
|
|
32
|
+
`PointerTree()` is a mutable builder initially containing root zero.
|
|
33
|
+
`add_node(parent_id)` appends a last child and returns its insertion-order ID.
|
|
34
|
+
Stable pointer allocations keep existing handles valid; handles retain the
|
|
35
|
+
mutable backing owner. Mutation is serialized by the GIL. This binding-side
|
|
36
|
+
adapter implements the native ordered-tree source contract; the immutable C++
|
|
37
|
+
reference implementation is unchanged.
|
|
38
|
+
|
|
39
|
+
Succinct string constructors validate and pack their own native encoding
|
|
40
|
+
without converting through a pointer tree. BP uses balanced parentheses;
|
|
41
|
+
DFUDS uses unary degrees in preorder without a sentinel; LOUDS uses unary
|
|
42
|
+
degrees in BFS order and accepts its optional display prefix. PointerTree text
|
|
43
|
+
remains BP. All constructors also accept complete trees/views. Copies are
|
|
44
|
+
independent; pointer copies start with preorder IDs, and succinct conversions
|
|
45
|
+
assign IDs for their encoding. Conversions snapshot mutable topology. Public
|
|
46
|
+
list constructors are removed. `from_bp` remains an explicit parsing helper
|
|
47
|
+
accepting `()` or binary `10` (one means open), rejecting malformed or multiple
|
|
48
|
+
trees. Rejected strings include the reason, a format hint and a valid example.
|
|
49
|
+
Construction and conversion are iterative.
|
|
50
|
+
|
|
51
|
+
All complete trees now provide `to_louds()`, `to_bp()` and `to_dfuds()`.
|
|
52
|
+
The succinct encodings share Python navigation, index and context classes;
|
|
53
|
+
dispatch selects the native encoding without converting it for traversal.
|
|
54
|
+
Tree-like objects expose `to_dot()` and `visualize()` methods, in addition to
|
|
55
|
+
the module-level functions. Public Python classes, methods and properties carry
|
|
56
|
+
short human-readable docstrings.
|
|
57
|
+
|
|
58
|
+
`parentheses()` and `str(tree)` render the stored encoding with `1` as `(`
|
|
59
|
+
and `0` as `)`. `start` and `count` select logical bits directly, excluding
|
|
60
|
+
allocation padding. BP contains `2*n` bits; LOUDS and DFUDS contain `2*n - 1`,
|
|
61
|
+
with no stored sentinel. Both unary formats use one `1` per child followed by
|
|
62
|
+
`0`, in BFS order for LOUDS and preorder for DFUDS. Nonempty LOUDS output
|
|
63
|
+
starting at stored bit zero adds a display-only `(`. Its full display is balanced;
|
|
64
|
+
`start` and `count` exclude this prefix. DFUDS adds no prefix. Rendering takes
|
|
65
|
+
time proportional to output length and does not traverse or convert the tree.
|
|
66
|
+
Use `to_bp().parentheses()` for canonical BP topology. Pointer trees have no
|
|
67
|
+
stored bit encoding and return BP topology. Full string output round-trips
|
|
68
|
+
through the same class constructor; `from_bp` always parses BP.
|
|
69
|
+
`parentheses(verbose=True, max_nodes=25)` returns only a text topology diagram
|
|
70
|
+
with source node IDs. BP uses matching-parenthesis brackets and IDs at opening
|
|
71
|
+
parentheses; DFUDS brackets subtree spans and labels node-record closing
|
|
72
|
+
parentheses. Columns widen with ID length. The first max_nodes preorder nodes
|
|
73
|
+
are annotated; omitted encoding regions become `...`. Boundary detection scans
|
|
74
|
+
the complete encoding. LOUDS and pointer trees retain an indented diagram with
|
|
75
|
+
`...` children for truncated branches. Encoding slices do not restrict the
|
|
76
|
+
diagram, which starts at the root.
|
|
77
|
+
|
|
78
|
+
`repr(tree)` returns encoding text for complete trees and a short description
|
|
79
|
+
for partial trees. Notebook MIME display renders an SVG through optional Graphviz
|
|
80
|
+
and falls back to text when the package or executable is missing or rendering
|
|
81
|
+
fails. Automatic display, `to_dot()` and `visualize()` default to 50 nodes;
|
|
82
|
+
explicit `max_nodes` arguments control truncation in the latter two methods.
|
|
83
|
+
|
|
84
|
+
## Incomplete-tree interface
|
|
85
|
+
|
|
86
|
+
Introduce a common interface for represented portions of a complete tree.
|
|
87
|
+
Every incomplete tree is bound to an original complete tree through a const
|
|
88
|
+
reference/pointer and exposes `tree_base()`. Python retains that original owner.
|
|
89
|
+
|
|
90
|
+
The common inspection operations are:
|
|
91
|
+
|
|
92
|
+
- `contains(node)`: a node record is represented in this object.
|
|
93
|
+
- `children_complete(node)`: for a represented node, all immediate children are
|
|
94
|
+
represented and its child list is complete. This is true for a represented
|
|
95
|
+
leaf. It does not imply that descendants have complete child lists.
|
|
96
|
+
- `tree_base()`: access the original complete tree explicitly.
|
|
97
|
+
|
|
98
|
+
Use valid node handles initially. An arbitrary numeric-ID-to-handle API is a
|
|
99
|
+
separate future extension, not the same operation as decoded-cache lookup.
|
|
100
|
+
|
|
101
|
+
Inspection and navigation through the incomplete-tree interface describe only
|
|
102
|
+
represented data. They must not silently fetch additional data or fall back to
|
|
103
|
+
the complete tree. An incomplete child list must not masquerade as a complete
|
|
104
|
+
empty list. Boundary navigation distinguishes information outside the result
|
|
105
|
+
from a relation that does not exist. For example, a decoded subtree root can
|
|
106
|
+
have a parent in `tree_base()` that is absent from the decoded result. Exact
|
|
107
|
+
sentinel/result types will be selected with the concrete implementation.
|
|
108
|
+
|
|
109
|
+
Full trees can satisfy the same inspection contract trivially. Initial partial
|
|
110
|
+
representations include the root navigation index and decoded microtrees.
|
|
111
|
+
DFS events remain in scope as scan results; a public navigation adapter for
|
|
112
|
+
arbitrary event blocks is deferred because an event slice is not necessarily a
|
|
113
|
+
navigable partial tree. Do not force every event result into a topology interface
|
|
114
|
+
that it cannot meaningfully satisfy.
|
|
115
|
+
|
|
116
|
+
## Root navigation index
|
|
117
|
+
|
|
118
|
+
`RootNavigationIndex` is a separate immutable object associated with one tree.
|
|
119
|
+
Different indexes may use different budgets for the same tree. It is not owned
|
|
120
|
+
by the traversal context. C++ contexts hold an optional const pointer/reference;
|
|
121
|
+
Python contexts retain the index and tree owners. Validate that a supplied index
|
|
122
|
+
belongs to the supplied tree. Without one, traversal uses the tree directly.
|
|
123
|
+
|
|
124
|
+
Expose its represented topology through the incomplete-tree contract. Keep this
|
|
125
|
+
separate from its existing cursor behavior, which can fall back to the original
|
|
126
|
+
tree and therefore return complete answers beyond the cached region.
|
|
127
|
+
|
|
128
|
+
The current index follows contiguous child-entry ranges from a root cursor; it
|
|
129
|
+
has no arbitrary node-to-entry directory. Implementing `contains` and
|
|
130
|
+
`children_complete` requires inspection support, but does not by itself commit
|
|
131
|
+
to a general decoded-cache directory or public context `lookup` implementation.
|
|
132
|
+
Choose and document the inspection cost rather than assuming node IDs equal
|
|
133
|
+
entry offsets.
|
|
134
|
+
|
|
135
|
+
The index has its own budget and serialization. Context accounting covers its
|
|
136
|
+
own retained state and scratch; aggregate reports must identify shared index
|
|
137
|
+
memory separately to avoid double counting. Replace the context constructor
|
|
138
|
+
that takes ownership of a restored index with borrowing an externally owned one.
|
|
139
|
+
|
|
140
|
+
## Traversal context and scanning
|
|
141
|
+
|
|
142
|
+
Retain the existing decoding algorithms and configuration machinery where
|
|
143
|
+
possible. Extend `TreeTraversalContext` to own useful reusable mutable decoding
|
|
144
|
+
state and larger traversal buffers instead of leaving all of them in temporary
|
|
145
|
+
walkers. It borrows the complete tree and optional immutable root index.
|
|
146
|
+
|
|
147
|
+
Implement these operations now; `scan` replaces the earlier name `look_ahead`:
|
|
148
|
+
|
|
149
|
+
```python
|
|
150
|
+
context.scan(node, max_bits=...)
|
|
151
|
+
context.fetch(node, max_bits=...)
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
Both use the encoding-specific algorithm and the same scan-limit semantics.
|
|
155
|
+
`scan` returns extracted information without retaining the result in the
|
|
156
|
+
context. It may use and modify reusable scratch, so it is logically read-only
|
|
157
|
+
with respect to retained results, not necessarily a C++ const operation.
|
|
158
|
+
`fetch` returns extracted information and retains it in the context for reuse.
|
|
159
|
+
Neither method implicitly advances a traversal cursor. Retention does not yet
|
|
160
|
+
promise automatic cache hits or deduplication by node.
|
|
161
|
+
|
|
162
|
+
`max_bits` bounds the total logical encoding bits examined across the regions
|
|
163
|
+
scanned by the operation. Multiple regions are allowed; the algorithm may
|
|
164
|
+
navigate to another region instead of scanning an irrelevant gap. Word/SIMD
|
|
165
|
+
loads can touch surrounding valid storage without extending the logical scan.
|
|
166
|
+
This parameter is not a node count, memory budget or strict CPU-work limit.
|
|
167
|
+
Document separate navigation/backend work and logical scan accounting when
|
|
168
|
+
implementing the algorithms; physical reads are not all charged as scan bits.
|
|
169
|
+
|
|
170
|
+
Extract whatever useful information the bounded scan supports. It need not
|
|
171
|
+
produce a complete subtree. Budget exhaustion returns a useful partial result
|
|
172
|
+
(or an explicit empty/miss result when nothing useful fits), not an error.
|
|
173
|
+
Invalid handles and invalid parameter values remain errors.
|
|
174
|
+
|
|
175
|
+
The concrete return types will follow the decoder capabilities: decoded
|
|
176
|
+
microtrees, node runs, DFS events or other useful encoding-specific results.
|
|
177
|
+
Their kind and completeness must be explicit. Separate entry points or typed
|
|
178
|
+
results are acceptable if they avoid unnecessary conversion or materialization.
|
|
179
|
+
Do not impose a universal decoded representation at a substantial performance
|
|
180
|
+
cost merely to make all encodings look identical.
|
|
181
|
+
|
|
182
|
+
### LOUDS
|
|
183
|
+
|
|
184
|
+
LOUDS currently decodes word-sized delimiter batches with per-level cursors,
|
|
185
|
+
plus child boundaries and traversal frames. It does not currently retain a
|
|
186
|
+
subtree block equivalent to the BP/DFUDS microtree decoder.
|
|
187
|
+
|
|
188
|
+
A LOUDS result can contain consecutive nodes in a level and their children,
|
|
189
|
+
potentially spanning several short levels. Child encodings may occupy a separate
|
|
190
|
+
region from their parents; multiple-region scanning is explicitly allowed under
|
|
191
|
+
the same total bit limit. Knowing a parent's degree alone does not establish
|
|
192
|
+
`children_complete(parent)`: the child records must also be represented.
|
|
193
|
+
Boundary nodes can be present with incomplete children.
|
|
194
|
+
|
|
195
|
+
### Results, views and iterators
|
|
196
|
+
|
|
197
|
+
Returned Python results remain valid after subsequent context operations and
|
|
198
|
+
retain their original tree. Do not expose a silently overwritten scratch buffer
|
|
199
|
+
as a persistent result. Retained decoded blocks may be immutable while context
|
|
200
|
+
scratch and publication state remain mutable. The exact ownership mechanism is
|
|
201
|
+
an implementation choice; avoid unnecessary copies.
|
|
202
|
+
|
|
203
|
+
Allow multiple live views/iterators associated with a context and sequentially
|
|
204
|
+
interleaved use. One operation must not invalidate data still used by another
|
|
205
|
+
view or iterator. A node view supports arbitrary navigation from a node; a DFS
|
|
206
|
+
iterator tracks event order and traversal progress. These are distinct roles.
|
|
207
|
+
|
|
208
|
+
Keep small cursor state, node handles, event positions and navigation
|
|
209
|
+
memoization local to the view/iterator where useful. Larger decoded objects and
|
|
210
|
+
reusable buffers belong in the context. A cache-line-sized local cursor is a
|
|
211
|
+
performance goal, not a strict size contract: current microtrees themselves are
|
|
212
|
+
larger. Overflow traversal state may be context-allocated, but must remain
|
|
213
|
+
separate for each active iterator.
|
|
214
|
+
|
|
215
|
+
Ordinary `NodeView` computes parent and children lazily on access. This differs
|
|
216
|
+
from inspecting only represented data through an incomplete-tree object.
|
|
217
|
+
`TreeNavigationView` is a C++ concept describing the node-view interface, not an
|
|
218
|
+
additional runtime object or a synonym for traversal context. Defer Python
|
|
219
|
+
exposure of `TreePathView`.
|
|
220
|
+
|
|
221
|
+
### Concurrency
|
|
222
|
+
|
|
223
|
+
For this iteration, allow only one active operation per context, without locks.
|
|
224
|
+
Sequential handoff between threads is allowed; no permanent thread affinity is
|
|
225
|
+
required. Separate contexts may operate on a shared immutable tree/index when
|
|
226
|
+
the execution layer permits it. Multiple live views are allowed, but operations
|
|
227
|
+
using the same mutable context must not overlap.
|
|
228
|
+
|
|
229
|
+
Shared mutable session caching and internally parallel search operations are
|
|
230
|
+
deferred until beam search or another concrete workload needs them. Do not add
|
|
231
|
+
locking overhead now. If synchronization is introduced later, compare unguarded,
|
|
232
|
+
mutex and read/write-lock paths on cached reads, small decodes and sustained
|
|
233
|
+
traversal. Scratch-mutating scans cannot use a shared lock merely because they
|
|
234
|
+
are logically read-only.
|
|
235
|
+
|
|
236
|
+
The Python baseline retains the GIL. Native thread-safety contracts alone do not
|
|
237
|
+
promise Python-thread parallelism; GIL release requires an explicit review of
|
|
238
|
+
the operations and result lifetimes.
|
|
239
|
+
|
|
240
|
+
## Persistence
|
|
241
|
+
|
|
242
|
+
Serializable public objects expose `save` and `load`, with a load mode selecting
|
|
243
|
+
RAM or mmap backing, using Pixie's native formats. Do not introduce a
|
|
244
|
+
Python-specific wrapper format. Mmap mode does not promise that all metadata is
|
|
245
|
+
zero-copy; some backends restore owned metadata. Python objects retain mapped
|
|
246
|
+
resources for as long as any dependent view/result needs them.
|
|
247
|
+
|
|
248
|
+
Loading an index requires the associated complete tree. Use full validation by
|
|
249
|
+
default at the Python boundary, with explicit validation options where supported.
|
|
250
|
+
Structural validation and tree-size agreement do not establish artifact identity.
|
|
251
|
+
|
|
252
|
+
Do not promise serialization of mutable scratch, active iterators or in-progress
|
|
253
|
+
traversal sessions. Durable context configuration and externally owned indexes
|
|
254
|
+
can be restored separately. Resumable search checkpoints and identity binding
|
|
255
|
+
are future application-level work. Persistence is part of the overall design;
|
|
256
|
+
it can be delivered separately from the current traversal-interface changes.
|
|
257
|
+
|
|
258
|
+
## Implementation scope and verification
|
|
259
|
+
|
|
260
|
+
The current iteration establishes the incomplete-tree contracts, externalizes
|
|
261
|
+
the root index, implements bounded multi-region `scan`/`fetch`, adds the relevant
|
|
262
|
+
Python objects with lazy node views, and provides parenthesis output and Python
|
|
263
|
+
visualization. Adapt the C++ core where needed and keep the bindings on public
|
|
264
|
+
interfaces. The common tree interface targets LOUDS, BP and DFUDS; adding all
|
|
265
|
+
Python encodings and persistence need not be bundled into the first traversal
|
|
266
|
+
change.
|
|
267
|
+
|
|
268
|
+
Deferred items include public context `lookup(node, ...)`, a general decoded-cache
|
|
269
|
+
lookup/deduplication policy, arbitrary ID-to-handle resolution, event-block
|
|
270
|
+
navigation, `TreePathView` bindings, concurrent context sharing and beam-search
|
|
271
|
+
parallelization. Document future lookup semantics as checking retained data
|
|
272
|
+
without decoding, but do not add nonfunctional callable stubs.
|
|
273
|
+
|
|
274
|
+
Choose concrete result types and buffer layouts after inspecting and measuring
|
|
275
|
+
the decoding paths. A hard context memory limit must have explicit behavior when
|
|
276
|
+
live results prevent reclamation; do not evict live data or silently exceed the
|
|
277
|
+
limit. Caller-retained result memory and reusable context capacity must have
|
|
278
|
+
clear, separate accounting.
|
|
279
|
+
|
|
280
|
+
Verify topology and completeness against independent tree oracles, boundary
|
|
281
|
+
navigation, scan-limit accounting, multiple-region LOUDS scans, retained result
|
|
282
|
+
lifetimes, and interleaved views/iterators. Benchmark native decoding and repeated
|
|
283
|
+
result consumption against existing paths; Python scalar-call overhead is a
|
|
284
|
+
separate measurement. Record any meaningful performance tradeoff rather than
|
|
285
|
+
assuming the interface fits the accepted 10–15% tolerance.
|
pixie_py-0.1.0/LICENSE
ADDED
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for reasonable and customary use in describing the
|
|
141
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
171
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don't include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright 2026 Pixie contributors
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|