| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"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.)
|
|
|
This will make it easier to add other Python packages in the future
as needed.
|
