dora-rs
/
dora
Not watched
1
0
Fork 0
Code
Releases 124 Wiki evaluate Activity
Issues 0 Pull Requests 0 Datasets Model Cloudbrain HPC
You can not select more than 25 topics Topics must start with a chinese character,a letter or number, can include dashes ('-') and can be up to 35 characters long.
688 Commits
57 Branches
16 MB
7672 Download
Tree: 8cbc891251
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '8cbc891251'
${ noResults }
dora/apis/python/node/Cargo.toml

Cargo.toml 530 B
Raw Normal View History

init `dora-node-api-python`
3 years ago
​
Bumping dora version
3 years ago
init `dora-node-api-python`
3 years ago
Refactoring `python-node-api`
3 years ago
init `dora-node-api-python`
3 years ago
​
​
​
​
Add Python Node API metadata (#101) * Add a `dora-python-operator` crate to hold utils functions for dora python * Remove python serialisation and deserialisation from `dora-runtime` * Update `python` documentation
3 years ago
Add `dora-node-api-python` package publication on pypi to release workflow (#92) * add `pip` release in release workflow * add blank space * Reduce Python verion to 3.7 for default conda support * Split CI workflows to avoid name collusions There is a name collusion issue within cargo. See: https://github.com/rust-lang/cargo/issues/6313 That make it impossible to build at the same time the `dora` cli binary, and the `dora` python shared library. To avoid the collusion, this commit split the two workflows: - `main` workflows consists of default-members and is tested on `ci.yml` - `python` workflow is on `ci-python.yaml` which is only run when python file changed. * add root example package * add python version * Fix Minor pypi release issue - Name is `dora-rs` and not `dora` - maturin 0.13 does not have `extension-module` features built in. * Use `--all` to check build of `dora` As the cli name was changed to `dora-cli`, we don't have name collusion anymore and can use `--all` flags for building and testing `dora`
3 years ago
Adding `next`, `send_output` for Python node API Adding `next` and `send_output` requires an async threadpool as the communication Layer defined by the Middleware Layer returns an async Future stream. I solve this issue by adding a tokio runtime on a separater thread that is connected with two channels. One for sending data and one for receiving data. Those channel are then exposed synchronously to Python. This should not be cause for concern as channel are really fast. Looking at Zenoh Python client, they are heavily using `pyo3-asyncio` implementation of futures to pass Rust futures into Python. This can be a solution as well, but, from previous experiment, I'm concerned about performance on such solution. I have experienced that putting futures from Rust into the `asyncio` queue to be slow. I'm concerned also by mixing `async` and `sync` code in Python, as it might be blocking. This might requires 2 threadpool in Python. This might seem as heavy overhead for some operations.
3 years ago
​
Update python node API to work with synchronous Rust node API
3 years ago
Add start runtime function to python node api again
3 years ago
Adding `next`, `send_output` for Python node API Adding `next` and `send_output` requires an async threadpool as the communication Layer defined by the Middleware Layer returns an async Future stream. I solve this issue by adding a tokio runtime on a separater thread that is connected with two channels. One for sending data and one for receiving data. Those channel are then exposed synchronously to Python. This should not be cause for concern as channel are really fast. Looking at Zenoh Python client, they are heavily using `pyo3-asyncio` implementation of futures to pass Rust futures into Python. This can be a solution as well, but, from previous experiment, I'm concerned about performance on such solution. I have experienced that putting futures from Rust into the `asyncio` queue to be slow. I'm concerned also by mixing `async` and `sync` code in Python, as it might be blocking. This might requires 2 threadpool in Python. This might seem as heavy overhead for some operations.
3 years ago
​
​
​
 1234567891011121314151617181920 
  1. [package]

  2. name = "dora-node-api-python"

  3. version.workspace = true

  4. edition = "2021"

  5. license = "Apache-2.0"

  6. 

  7. # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

  8. 

  9. [dependencies]

  10. dora-node-api = { path = "../../rust/node" }

  11. dora-operator-api-python = { path = "../operator" }

  12. pyo3 = { version = "0.16", features = ["eyre", "abi3-py37"] }

  13. eyre = "0.6"

  14. serde_yaml = "0.8.23"

  15. flume = "0.10.14"

  16. dora-runtime = { path = "../../../binaries/runtime" }

  17. 

  18. [lib]

  19. name = "dora"

  20. crate-type = ["cdylib"]

DORA (Dataflow-Oriented Robotic Architecture) is middleware designed to streamline and simplify the creation of AI-based robotic applications. It offers low latency, composable, and distributed datafl