• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

gnosis / dex-services / 4143
31%

Build:
DEFAULT BRANCH: master
Ran 15 Jul 2020 10:08AM UTC
Jobs 1
Files 81
Run time 5min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

15 Jul 2020 09:52AM UTC coverage: 27.971% (+0.04%) from 27.93%
4143

push

travis-pro

web-flow
Separate API operations into modules (#1118)

This PR just splits the `Pricegraph` `impl` blocks into multiple submodules. The ultimate plan is to lift `Orderbook` methods into the `Pricegraph` type (for computing transitive orderbooks and price estimates) so that the `Orderbook` type only contains primitives for manipulating the orderbook graph while the `Pricegraph` type actually computes things by combining these primitives.

This is in an effort to reduce the size of `orderbook.rs` which is currently >1000L long :disappointed:. The motivation for splitting operations into their own modules is to allow the `Pricegraph` API surface to grow without creating another run-away module with way too much code that becomes hard to navigate.

In the following PRs, I plan on:
- move `Orderbook::{reduce_overlapping_transitive_orderbook, fill_transitive_orders}` to `src/api/transitive_orderbook.rs`, implemented with the new `Orderbook::{fill_optimal_transitive_order_if, fill_market_ring_trade}` primitive operations
- move `Orderbook::{fill_market_order, fill_order_at_price}` to `src/api/price_estimation.rs` module implemented with the `Orderbook::fill_optimal_transitive_order_if` primitive.

This has the added benefit that each module will contain unit tests specific to the operation, so hopefully the code will be easier to test and develop for.

One thing I don't 100% like about the structure is that `Pricegraph` methods are split into multiple files, which might be a bit counter-intuitive and make methods harder to find. Another option here would be to implement "helper" functions for each operations in these modules and have `Pricegraph` methods wrap them in `src/lib.rs`. However, this feels like extra work (double method signature for each operation) so I'm not sure if its worth it. Yet another option would be to implement operations as traits. This would be nice since the traits and implementations could live in the same file, and make `Pricegrap... (continued)

10180 of 41696 branches covered (24.41%)

Branch coverage included in aggregate %.

2729 of 4455 relevant lines covered (61.26%)

13467.51 hits per line

Jobs
ID Job ID Ran Files Coverage
3 4143.3 (OPEN_SOLVER_VERSION=v0.0.10 PRIVATE_SOLVER_VERSION=v0.8.1) 15 Jul 2020 10:08AM UTC 0
27.97
Travis Job 4143.3
Source Files on build 4143
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #4143
  • 87300b1b on github
  • Prev Build on master (#4141)
  • Next Build on master (#4148)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc