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.
3273 Commits
57 Branches
16 MB
7670 Download
Tree: 066d47007c
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '066d47007c'
${ noResults }
dora/apis/python/node/Cargo.toml

Cargo.toml 1.0 kB
Raw Normal View History

init `dora-node-api-python`
3 years ago
Release dora-rs version 0.1.3
3 years ago
init `dora-node-api-python`
3 years ago
chore: use workspace edition
1 year ago
add documentation and description to all crates test rc 2 version fix version typo Test crates.io new dora tag release
2 years ago
​
Add missing licenses and centralise license definition test new crates version release
2 years ago
Set `repository` metadata for all our crates
1 year ago
init `dora-node-api-python`
3 years ago
​
​
Remove code duplicate for tracing subscriber and use env variable to manage log level. The intent of this commit is to remove the quantity of log that is being pushed to user. This commit removes the redeclaration of a set up tracing methods to centralise the tokio-tracing subscriber within the extension crate. It also add the feature to filter information based on Environment variable. This makes it possible to define the log level for tokio tracing like this: ``` RUST_LOG=debug dora-daemon --run-dataflow dataflow.yml ``` I have also unified the feature flag to make it easier to manage tracing features among the workspace. I did not change the default behaviour of tracing in our crates and therefore by using the command above you should get the same tracing log as before. fix merge conflict generated
2 years ago
Enable python to use opentelemetry by default ( if env variable is configured for it)
2 years ago
Remove code duplicate for tracing subscriber and use env variable to manage log level. The intent of this commit is to remove the quantity of log that is being pushed to user. This commit removes the redeclaration of a set up tracing methods to centralise the tokio-tracing subscriber within the extension crate. It also add the feature to filter information based on Environment variable. This makes it possible to define the log level for tokio tracing like this: ``` RUST_LOG=debug dora-daemon --run-dataflow dataflow.yml ``` I have also unified the feature flag to make it easier to manage tracing features among the workspace. I did not change the default behaviour of tracing in our crates and therefore by using the command above you should get the same tracing log as before. fix merge conflict generated
2 years ago
Enable python to use opentelemetry by default ( if env variable is configured for it)
2 years ago
Remove code duplicate for tracing subscriber and use env variable to manage log level. The intent of this commit is to remove the quantity of log that is being pushed to user. This commit removes the redeclaration of a set up tracing methods to centralise the tokio-tracing subscriber within the extension crate. It also add the feature to filter information based on Environment variable. This makes it possible to define the log level for tokio tracing like this: ``` RUST_LOG=debug dora-daemon --run-dataflow dataflow.yml ``` I have also unified the feature flag to make it easier to manage tracing features among the workspace. I did not change the default behaviour of tracing in our crates and therefore by using the command above you should get the same tracing log as before. fix merge conflict generated
2 years ago
init `dora-node-api-python`
3 years ago
Remove static path from workspace dependency Removing those path make it easier to move package, reduce path management reduce complexity and make it easier to export crates to `crates.io`
2 years ago
​
Rename and use multiple_pymethods trait
1 year 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
Simplyfing the metrics functionality by using meter provider instead of the global meter.
2 years ago
Adding run comand within python API
10 months ago
​
Update `arrow` and `pyo3` dependencies to latest versions
2 years ago
​
Update `pyo3` and `arrow` version to use latest version
2 years ago
Import ros2_bridge as experimental submodule of python node API
2 years ago
Bump arrow version to latest version
10 months ago
Adding run comand within python API
10 months 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
​
​
Fix CD errors and try to release new version
2 years ago
 123456789101112131415161718192021222324252627282930313233343536 
  1. [package]

  2. version.workspace = true

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

  4. edition.workspace = true

  5. documentation.workspace = true

  6. description.workspace = true

  7. license.workspace = true

  8. repository.workspace = true

  9. 

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

  11. 

  12. [features]

  13. default = ["tracing", "telemetry"]

  14. tracing = ["dora-node-api/tracing"]

  15. telemetry = ["dora-runtime/telemetry"]

  16. 

  17. [dependencies]

  18. dora-node-api = { workspace = true }

  19. dora-operator-api-python = { workspace = true }

  20. pyo3.workspace = true

  21. eyre = "0.6"

  22. serde_yaml = "0.8.23"

  23. flume = "0.10.14"

  24. dora-runtime = { workspace = true, features = ["tracing", "metrics", "python"] }

  25. dora-daemon = { workspace = true }

  26. dora-download = { workspace = true }

  27. arrow = { workspace = true, features = ["pyarrow"] }

  28. pythonize = { workspace = true }

  29. futures = "0.3.28"

  30. dora-ros2-bridge-python = { workspace = true }

  31. # pyo3_special_method_derive = "0.4.2"

  32. tokio = { version = "1.24.2", features = ["rt"] }

  33. 

  34. [lib]

  35. name = "dora"

  36. 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