mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.1.0 2022-02-28T16:41:13Z 2022-02-28T16:41:13Z eta tor@eta.st 2022-02-25T18:13:02Z urn:sha1:13ba0ea005ddd87bba2d53ab738ce948f031e1e8 This makes using the `PreferredRuntime` the first-class option inside `arti-client`, freeing users who don't want to think about runtimes from having to do so. `TorClient::create_unbootstrapped` and `builder` now automatically use this runtime, leaving only `builder_custom` for users who wish to manually specify a runtime. This lets us clean up the docs a lot: mentions of using custom runtimes are now relegated to nearer the end of the crate-level documentation, and we mostly just link to `tor_rtcompat`'s docs to explain more there. Instead, we take some more time to explain how you use the builder API to create clients synchronously. Other doc cleanups included getting rid of the explanation of `TorAddr` in the main crate-level doc; this is already well-documented elsewhere, and is something users should discover organically later. fixes arti#326 2022-02-25T14:20:48Z Nick Mathewson nickm@torproject.org 2022-02-25T14:17:37Z urn:sha1:a3bc59918d5cca780f87a12cfc30a4cd209a6cfc 2022-02-14T14:24:06Z Nick Mathewson nickm@torproject.org 2022-02-14T14:24:06Z urn:sha1:1cecc7e45a9a432f87a8f11abb8cb86b35464a0b Closes #338. 2022-02-11T16:42:19Z eta tor@eta.st 2022-02-09T16:27:34Z urn:sha1:882e75cd280ede6dc284f11db9e8f17947435ebe This commit changes how the `TorClient` type works, enabling it to be constructed synchronously without initiating the bootstrapping process. Daemon tasks are still started on construction (although some of them won't do anything if the client isn't bootstrapped). The old bootstrap() methods are now reimplemented in terms of the new create_unbootstrapped() and bootstrap_existing() methods. This required refactoring how the `DirMgr` works to enable the same sort of thing there. closes #293 2022-02-02T18:18:22Z Dimitris Apostolou dimitris.apostolou@icloud.com 2022-02-02T18:18:22Z urn:sha1:65263218510ee9375ed423b42fbf555e96eab275 2022-02-02T17:31:23Z Ian Jackson iwj@torproject.org 2022-02-02T17:31:23Z urn:sha1:1c313993567bf59b1440ffda95058056a7ddd35c Preparatory work for auto config reload See merge request tpo/core/arti!284 2022-02-01T19:26:39Z Nick Mathewson nickm@torproject.org 2022-02-01T19:21:58Z urn:sha1:feab848509a25c4865ccb41e990a010ba33eaa44 This is by no means our final API, but should represent an improvement. Here instead of having to specify a list of files and their is-this-optional status, along with a list of command-line options, we have a single structure that encapsulates all of that information. Two advantages here: - Callers no longer have to remember what the boolean means. - We can "reload" more easily, by keeping the source object around. This change also implements the correct behavior for our default configuration file in `arti::main`: if the file is absent and the user doesn't list a config file, that's no problem. But if the user lists _that very same config file, we should insist that it be present. 2022-02-01T16:09:24Z eta tor@eta.st 2022-02-01T16:09:24Z urn:sha1:5b14008a82b9efbf3e260d08f65322a04fc96bbd This implements the proposal from arti#298, making the `BenchmarkResults` type be made out of a bunch of new `Statistic` types (which summarize the mean, median, range, and standard deviation of an arbitrary value) instead of overloading `TimingSummary` for this purpose. 2022-01-26T19:06:58Z Nick Mathewson nickm@torproject.org 2022-01-26T13:40:35Z urn:sha1:6f29d485e460b30cba992bcb407bf3c7e2a479b7 This should help avoid some amount of temptation towards API proliferation. 2022-01-18T13:46:36Z eta tor@eta.st 2022-01-18T13:41:43Z urn:sha1:2aeac45f49f5266fe3cf3f9f249ed4eb8aeffabb We now conduct benchmark tests with multiple concurrent streams (by default; this is configurable by passing `-p` to `arti-bench`). Currently, these results just get "flattened" for the purposes of statistical analysis (as in, results_raw contains the results of each connection's timing summary, across all benchmark runs). This might be something we wish to change in future. The stats summary now also records "best" and "worst" values for each metric, to give a rough idea of the range of values encountered. Additionally, we now support writing the benchmark results out to a JSON file. A future commit may integrate this with CI, so that we have benchmark results for every commit as a build artefact. (some documentation was also fixed) part of arti#292