| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
This provides an API and tests for create_polling(), poll(), and
related APIs.
|
| |
|
|
|
|
|
| |
These wrappers present a "pythonic" API to the C functions for
submit and wait.
Tests included.
|
| |
|
|
|
| |
These are low-level wrappers that let us call the relevant C code,
but are not suitable for general use.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Previously we were using c_int unconditionally, which works
everywhere else.
Closes #2305.
Co-Authored-By: Carti
|
| | |
|
| |
|
|
| |
It was removed in 08847ab290a8d554ccf18e49b3de3abe7d6be9f2.
|
| |\
| |
| |
| |
| |
| |
| | |
rpc: Document what is actually going on with stream optimism.
Closes #1583
See merge request tpo/core/arti!2753
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our documentation had dated to an older version of our RPC stream
code, where all streams were automatically optimistic.
But as explained, our use of "optimistic"ness in RPC stream code is
now purely internal, to make it possible to get an DataStreamCtrl.
This isn't user-visible in our rpc_conn_open_stream code.
Closes #1583
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expose ArtiRpcConnBuilder and appropriate C wrapper functions in
our FFI code, and wrap those functions in our python wrapper.
This breaks the old C API, but that's allowed since the API
is still experimental.
Some design decisions:
* I've wrapped the builder in a Mutex, so that we can continue
our FFI rule that we do not require non-Rust code to wrap `&mut`.
* I've removed the non-builder connect() function from the C API
as extraneous.
* I've made a single function to prepend elements to the search
path.
|
| | |
|
| |
|
|
|
|
| |
It no longer reflects our current API, refers to no-longer-extant
bugs, and was never a terribly good example of what you were
supposed to do with RPC.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Black" is an "opinionated" python formatter, whose opinionatedness
is somewhat in the spirit of rustfmt.
This MR runs black with default settings on all of our python code
in Arti. It was produced by the following commands
```
# Everything in python/
black python/
# Everything with a .py extension
fd '.py$' -X black
# Everything with a python shebang.
git grep -l '#! */usr/bin/env *python' | xargs black
```
|
| | |
|
| | |
|
| |
|
|
|
|
| |
After calling a `foo_free()` method on a ctypes pointer object,
we now set that pointer to None, so that we cannot inadvertently
pass the freed pointer to anything else.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Make the return type from connect() more sensible.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This tweaks the APIs to return a dict in cases where we know
that we are getting a result, and to return an ArtiRpcResponse
in cases where we don't know what kind of response we're getting.
It also expands our Error objects to support decoding.
Rationale: everybody who is using this libaray will want to
decode the json objects that they receive. By doing it in the
library, we can save them some annoyance.
|
| |
|
|
|
| |
Previously, they only took strings, which sometimes required the caller
to use json.
|
| |
|
|
| |
(Found while writing a test.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
@opara says that we'll want to have our API functions be
`extern "C"` everywhere, and so `ctypes.CDLL` should work fine for
them on Windows. This sounds good to me.
|
| |
|
|
| |
This, incidentally, turned up a repeated mistake in the code.
|
| |
|
|
|
| |
Since params can be "anything encodeable to json", there isn't a lot
of point in restricting its type.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has required a few code changes and turned up a few bugs.
The type annotations pass with `mypy`.
Notable code changes:
With type annotations, variable assignment may no longer change
the type of a variable. (I disagree with these semantics, but
here we are.)
Note that some TODOs remain: I have no clear sense how to annotate
the library type from `ctypes`, and better wrappers are needed in
some cases.
|
| | |
|
| |
|
|
| |
(The windows case is untested; the osx case worked fine.)
|
| |
|
|
|
| |
I've tried "python -m build" to make sure it works;
haven't tested anything else.
|
| |
|
|
|
| |
This will make it easier to add other Python packages in the future
as needed.
|
| |
|
|
|
| |
This module tries to provide a set of APIs more closely resembling
those you'd expect to use in a real python program.
|
|
|
This wrapper uses Python's `ctypes` module to wrap the APIs
from `arti-rpc-client-core`. It needs more work on Windows
(and likely MacOS too), but that will come later.
This is not a suitable API for direct use in Python.
|
