| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I find this names confusing. To my mind "is" implies a function
returning `bool`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I find these names confusing. To my mind "check" implies a function
returning `Result<(), _>`.
Some other APIs use `unwrap` here but I think `if` is good.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
It wouldn't make much sense for one concrete type to be unwrappable
variously as different inner types.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
It is better to return a more cooked type. `TimeRange` aka
`TimeRangeBound<()>` is perfect for this.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that we have `bounds()`, we can centralise this implementation and
delete the implementations.
I don't think it's necessary to provide an engineered safeguard
against downstreams overriding this method. Any existing implementors
of this trait will break because they must provide `.bounds()` now,
which is an opportunity to notice that the `is_valid_at` can be
deleted. But, if it is not deleted, nothing goes wrong.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This was always TimeValidityError. And we want to rely on that so we
can do the validity checking more centrally.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This makes a `TimeBound` much more convenient to work with, will allow
more centralisation.
This replaces temporary `bound` inherent method on `TimeRangeBound`.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is our time range type, so it wants a bunch of useful methods and
conversions.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It was confusing that one of these functions had "which bound"
mentioned in its name, but the other didn't. So add `end` and switch
from `tolerance` to `bound` (see previous commit message).
*This* commit should deal only in `extend_tolerance` and `end` and
shouldn't touch `extend_start_bound` or `extend_pre_tolerance`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Although it is often used to apply a tolerance, it doesn't make sense
to say that this is extending the "tolerance" of a `TimeRangeBound`.
A `TimeRangeBound` doesn't have a tolerance, only bounds.
Also we should be consistent in our terminology, and use `start`
rather than `pre`.
We'll rename the other method too. Doing them one at a time will
makes it easier to spot any "pre/start" vs "<nothing>/end" slips:
*this* commit should deal only in `pre` and `start` and shouldn't
touch `extend_tolerance`.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This puts the start bounds extension function before the end one.
That makes sense because starts are before ends.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This just returns a tuple.
We're going to introduce a new method that returns a `TimeRagne` and
will want to be called `bounds`.
That method will want to be in the `TimeBound` trait, but for now we
add it here. Various call sites will be added in forthcoming commits.
|
| | | | |
| | | |
| | | |
| | | | |
I find this hard to read without them.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This module has only few public items - currently, only one. And it
has the word "time" in it. It doesn't make sense to expect callers to
write `timed::`.
|
| |/ / /
| | |
| | |
| | |
| | | |
I noticed this clumsiness while passing. We can't do the same
for SystemTime because we have the wasm SystemTime thing too :-/.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Bump edition of tor-dirserver and tor-dirauth
See merge request tpo/core/arti!4227
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | | |
Apparently these crate creations were outstanding when the workspace's
edition was increased.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-netdoc testdata-live: Update and expand
See merge request tpo/core/arti!4224
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Run crates/tor-netdoc/testdata-live-download with the locally saved,
previously downloaded, network statuses.
It downloaded these descriptors.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
(effect)
Run crates/tor-netdoc/testdata-live-download with the locally saved,
previously downloaded, network statuses.
(It didn't download anything extra, but it did produced these new
output files, as expected.)
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This will be convenient for saving their descriptors, and may be
useful for other purposes too.
|
| | | | |
| | | |
| | | |
| | | | |
Precisely a run of crates/tor-netdoc/testdata-live-download.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We don't fetch files to the names we commit.
|
| | | | |
| | | |
| | | |
| | | | |
curl infers this, but we should include it.
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ideally we would have Arti sort things sensibly but currently we have
no types in Arti that are (1) faithful (2) sort correctly.
Most of the existing types eventually have a `TorVersion` inside,
which is lossy, so we can't use them for (eg) dirauth network status
processing.
|
| | | |
| | |
| | |
| | |
| | | |
Context:
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4222#note_3437336
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
As suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4222#note_3437129
|
| | | |
| | |
| | |
| | | |
Applies @opara's suggested rephrasing.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes the `DirMirror` return a dummy 500 response.
This enables us to (manually) verify that the new relay BEGIN_DIR stream
handler works as expected. We will of course need some automated e2e
tests too, but for the time being a manual test should do.
This will all be replaced by the real implementation, once that's ready
(TODO DIRMIRROR).
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Directory streams are accepted and turned into `DataStreams` by an
`arti-relay` task. The `DataStream`s are then passed to the `DirMirror`
for handling.
|
| | | | |
|