Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion crates/processing_pyo3/examples/animated_mesh.py
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
geometry = None
grid_size = 20
spacing = 10.0
offset = (grid_size * spacing) / 2.0;
offset = (grid_size * spacing) / 2.0
time = 0.0

def setup():
Expand Down
2 changes: 1 addition & 1 deletion docs/principles.md
Original file line number Diff line number Diff line change
Expand Up @@ -83,7 +83,7 @@ user-facing API via an overload.
We never return pointers to data that lives in libprocessing. Because we use the ECS to manage Rust data, where longer
lifetimes are necessary we return an `Entity` id, which can be returned to the user as a `u64` containing both the index
and generation of the ECS entity. Any data not representing an API-level object should be returned on the stack and
where an allocation is necessary (e.g. buffers for pixel data), it's the responsibility of the consumer to allocate a
where an allocation is necessary (e.g. buffers for pixel data), it's the responsibility of the consumer to allocate and
provide the pointer to the requisite allocation.

API-level objects should wrap ids and they should never be exposed to the user as a first-class concept. All data which
Expand Down