slick-queue-py 1.0.0__tar.gz

slick_queue_py-1.0.0/.github/FUNDING.yml

@@ -0,0 +1,15 @@
+# These are supported funding model platforms
+
+github: SlickQuant
+patreon: # Replace with a single Patreon username
+open_collective: # Replace with a single Open Collective username
+ko_fi: # Replace with a single Ko-fi username
+tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
+liberapay: # Replace with a single Liberapay username
+issuehunt: # Replace with a single IssueHunt username
+lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
+polar: # Replace with a single Polar username
+buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
+thanks_dev: # Replace with a single thanks.dev username
+custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']

slick_queue_py-1.0.0/.github/workflows/ci.yml

@@ -0,0 +1,32 @@
+name: CI
+
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+
+permissions:
+  contents: read
+
+jobs:
+  build-and-test:
+    strategy:
+      matrix:
+        os: [ubuntu-latest, windows-latest, macos-latest]
+        build_type: [Release, Debug]
+
+    runs-on: ${{ matrix.os }}
+
+    steps:
+    - uses: actions/checkout@v4
+
+    - name: Configure CMake
+      run: cmake -B build -DCMAKE_BUILD_TYPE=${{ matrix.build_type }}
+
+    - name: Build
+      run: cmake --build build --config ${{ matrix.build_type }}
+
+    - name: Run Tests
+      working-directory: build
+      run: ctest -C ${{ matrix.build_type }} --output-on-failure

slick_queue_py-1.0.0/.gitignore

@@ -0,0 +1,243 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+#poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+#pdm.lock
+#pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+#pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Abstra
+# Abstra is an AI-powered process automation framework.
+# Ignore directories containing user credentials, local state, and settings.
+# Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#  Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#  that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#  and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#  you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Cursor
+#  Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
+#  exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
+#  refer to https://docs.cursor.com/context/ignore-files
+.cursorignore
+.cursorindexingignore
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+dist/
+build/
+*.DS_Store
+.vscode/
+.idea/
+
+# CMake build artifacts
+CMakeCache.txt
+CMakeFiles/
+cmake_install.cmake
+Makefile
+*.cmake
+!CMakeLists.txt
+
+# C++ build artifacts
+*.o
+*.obj
+*.exe
+*.out
+*.app
+cpp_producer
+cpp_consumer
+cpp_multi_producer
+
+# Test artifacts
+tests/*.txt
+!tests/CMakeLists.txt
+!tests/*.py
+!tests/*.cpp
+
+# Shared memory cleanup
+*.shm
+
+# File indicating readiness
+ready

slick_queue_py-1.0.0/API_DIFFERENCES.md

@@ -0,0 +1,249 @@
+# C++ / Python API Differences
+
+This document explains the intentional API differences between the C++ `slick::SlickQueue<T>` and Python `SlickQueue` implementations.
+
+## Core Compatibility
+
+Both implementations:
+- ✅ Use identical memory layouts
+- ✅ Use identical atomic operations
+- ✅ Are fully interoperable (C++ ↔ Python communication works)
+- ✅ Support lock-free multi-producer multi-consumer semantics
+
+## API Differences
+
+### 1. Constructor / Opening Queues
+
+**C++:**
+```cpp
+// Create new queue in shared memory
+slick::SlickQueue<uint8_t> q(queue_size, queue_name);
+
+// Open existing queue
+slick::SlickQueue<uint8_t> q(queue_name);
+
+// Local memory mode
+slick::SlickQueue<uint8_t> q(queue_size); // No shared memory
+```
+
+**Python:**
+```python
+# Create new queue in shared memory
+q = SlickQueue(name=queue_name, size=queue_size, element_size=element_size, create=True)
+
+# Open existing queue
+q = SlickQueue(name=queue_name, element_size=element_size)
+
+# Local memory mode
+q = SlickQueue(size=queue_size, element_size=element_size)  # No shared memory
+```
+
+**Rationale:** Python uses keyword arguments for clarity and supports both shared memory and local memory modes.
+
+---
+
+### 2. read() Method - Return Value vs. Reference Parameter
+
+**C++:**
+```cpp
+uint64_t read_index = 0;
+
+// read() returns (data, size) and updates read_index by reference
+auto [data, size] = queue.read(read_index);  // read_index modified in-place
+
+if (data != nullptr) {
+    process(data, size);
+    // read_index has been updated automatically
+}
+```
+
+**Python:**
+```python
+read_index = 0
+
+# read() returns (data, size, new_read_index)
+data, size, read_index = q.read(read_index)  # Returns new index
+
+if data is not None:
+    process(data, size)
+    # read_index now holds the new value
+```
+
+**Rationale:**
+- Python doesn't have true pass-by-reference for primitive types
+- Returning the new index is the Pythonic pattern (like `list.pop()`, `str.split()`, etc.)
+- The assignment `read_index = q.read(read_index)` is clear and explicit
+
+**Important:** This is a **usage difference**, not a compatibility issue. The underlying memory operations are identical. When C++ and Python processes communicate:
+- C++ `read()` and Python `read()` both read from the same atomic slots
+- Both update their local `read_index` variable correctly
+- The memory layout and atomic semantics are identical
+
+---
+
+### 3. Element Access
+
+**C++:**
+```cpp
+auto idx = queue.reserve();
+uint8_t* slot = queue[idx];  // Returns pointer
+std::memcpy(slot, data, data_len);
+queue.publish(idx);
+```
+
+**Python:**
+```python
+idx = q.reserve()
+slot = q[idx]  # Returns memoryview
+slot[:data_len] = data
+q.publish(idx)
+```
+
+**Rationale:** Python uses `memoryview` for safe buffer access instead of raw pointers.
+
+---
+
+### 4. Type Safety
+
+**C++:**
+```cpp
+// Template-based, compile-time type safety
+slick::SlickQueue<int32_t> q(1024, "queue");
+auto idx = q.reserve();
+*q[idx] = 42;  // Type-safe int32_t access
+```
+
+**Python:**
+```python
+# Element size specified, runtime packing/unpacking
+q = SlickQueue(name='queue', size=1024, element_size=4)
+idx = q.reserve()
+import struct
+q[idx][:4] = struct.pack("<i", 42)  # Manual packing
+```
+
+**Rationale:** Python doesn't have templates. Users explicitly handle serialization with `struct` module.
+
+---
+
+### 5. Resource Management
+
+**C++:**
+```cpp
+{
+    slick::SlickQueue<T> q(size, "name");
+    // ... use queue ...
+}  // Destructor automatically cleans up
+```
+
+**Python:**
+```python
+# Option 1: Manual cleanup
+q = SlickQueue(name='name', size=size, element_size=elem_size, create=True)
+try:
+    # ... use queue ...
+finally:
+    q.close()
+    q.unlink()  # Only call from creator process
+
+# Option 2: Context manager (recommended)
+with SlickQueue(name='name', size=size, element_size=elem_size, create=True) as q:
+    # ... use queue ...
+    pass  # Automatic cleanup
+```
+
+**Rationale:** Python's garbage collection is non-deterministic, so explicit cleanup or context managers are needed.
+
+---
+
+## Interoperability Examples
+
+### Example 1: C++ Producer → Python Consumer
+
+**C++ (producer.cpp):**
+```cpp
+#include <slick/queue.h>
+#include <cstring>
+
+int main() {
+    slick::SlickQueue<uint8_t> queue("my_queue");  // Open existing queue
+
+    for (int i = 0; i < 100; i++) {
+        auto idx = queue.reserve();
+        uint32_t value = i;
+        std::memcpy(queue[idx], &value, sizeof(value));
+        queue.publish(idx);
+    }
+}
+```
+
+**Python (consumer.py):**
+```python
+from slick_queue_py import SlickQueue
+import struct
+
+# Create queue (C++ will open it)
+q = SlickQueue(name='my_queue', size=64, element_size=32, create=True)
+
+read_index = 0
+for _ in range(100):
+    data, size, read_index = q.read(read_index)
+    if data:
+        value = struct.unpack("<I", data[:4])[0]
+        print(f"Received: {value}")
+
+q.close()
+q.unlink()
+```
+
+### Example 2: Python Producer → C++ Consumer
+
+**Python (producer.py):**
+```python
+from slick_queue_py import SlickQueue
+import struct
+
+q = SlickQueue(name='my_queue', size=64, element_size=32, create=True)
+
+for i in range(100):
+    idx = q.reserve()
+    q[idx][:4] = struct.pack("<I", i)
+    q.publish(idx)
+
+q.close()
+# Don't unlink yet - C++ will use it
+```
+
+**C++ (consumer.cpp):**
+```cpp
+#include <slick/queue.h>
+#include <iostream>
+#include <cstring>
+
+int main() {
+    slick::SlickQueue<uint8_t> queue("my_queue");  // Open existing queue
+
+    uint64_t read_index = 0;
+    for (int i = 0; i < 100; i++) {
+        auto [data, size] = queue.read(read_index);  // Updates read_index
+
+        if (data) {
+            uint32_t value;
+            std::memcpy(&value, data, sizeof(value));
+            std::cout << "Received: " << value << std::endl;
+        }
+    }
+}
+```
+
+## Summary
+
+| Feature | C++ | Python | Reason for Difference |
+|---------|-----|--------|---------------------|
+| `read()` return | `(data, size)` | `(data, size, new_index)` | Python has no pass-by-reference |
+| Constructor | `(size, name)` or `(name)` | Named parameters with `create` flag | Python idioms |
+| Element access | Pointer | `memoryview` | Python memory safety |
+| Type safety | Templates | `struct` module | Language difference |
+| Cleanup | RAII (destructor) | Explicit or context manager | Python GC is non-deterministic |
+
+**Bottom Line:** The Python API is designed to be Pythonic while maintaining **100% binary compatibility** with C++. All atomic operations and memory layouts are identical, enabling seamless C++/Python interoperability.