The devices crate is a crates.io dependency rather than a github one,
since we publish new changes to crates.io. That means adding an entry to
the existing [patch.crates-io] category instead of creating a new
category for the github repository.
On 3/31/19 6:56 PM, Niveditha Shankar wrote:
Thank you , I will look into it and see if I can fix them.
We referred to the links you sent us on overriding dependancies and tried
them. We are unable to run it. We get the error
*error:* failed to resolve patches for `https://github.com/servo/devices`
Caused by:
patch for `devices` in `https://github.com/servo/devices` did not resolve
to any crates. If this is unexpected, you may wish to consult:
https://github.com/rust-lang/cargo/issues/4678
Build FAILED in 0:00:00
The path we added was,
[patch."https://github.com/servo/devices";]
devices = { path = "/Users/jayaharsha/Desktop/devices" }
-Niveditha Shankar
On Sun, Mar 31, 2019 at 5:27 PM Josh Bowman-Matthews <j...@joshmatthews.net>
wrote:
Those errors are difficult to diagnose without seeing the rest of the
code. However, given that BluetoothAdapter is supposed to be a trait
now, the second function does not look like it is using trait objects
correctly. As for the first function, the error message appears to be
describing a concrete problem that it should be possible to figure out
independently.
In general in the new trait-based code, we should not be using the
`get_inner_and_call` macro any more:
https://github.com/servo/devices/blob/d6c62e0873b2ec9a68c97a3370667e8b9a879cf4/src/bluetooth.rs#L188-L256
It was written to effectively perform the same work as the new traits,
so I would expect the resulting trait implementations to directly call
the appropriate platform-specific code, rather than using a macro.
On 3/31/19 3:45 PM, Niveditha Shankar wrote:
Hello Josh
We are trying to fix the errors we got in adapter.rs. We fixed most of
them.
The errors that are left are due to the changes we made to the init
functions.
We are not sure about the following errors, could you help us with this?
error[E0407]: method `get_modalias` is not a member of trait
`BluetoothAdapter`
--> src\adapter.rs:335:6
|
335 | / fn get_modalias(&self) -> Result<(String, u32, u32, u32),
Box<Error>> {
336 | | get_inner_and_call!(self, BluetoothAdapter, get_modalias)
337 | | }
| |_____^ not a member of trait `BluetoothAdapter`
error[E0277]: the size for values of type `(dyn
adapter::BluetoothAdapter +
'static)` cannot be known at compilation time
--> src\adapter.rs:156:6
|
156 | / fn new() -> Result<BluetoothAdapter, Box<Error>> {
157 | | let adapter = try!(BluetoothAdapterEmpty::init());
158 | | Ok(BluetoothAdapter::Empty(Arc::new(adapter)))
159 | | }
| |_____^ doesn't have a size known at compile-time
-Niveditha Shankar
On Sat, Mar 30, 2019 at 1:09 PM Josh Bowman-Matthews <
j...@joshmatthews.net>
wrote:
Yes - use a Cargo override to build Servo with your local modified
version of the devices crate. You can read more about overrides at
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies
and
https://doc.rust-lang.org/cargo/reference/manifest.html#the-patch-section
and you can see where to add this at
https://github.com/servo/servo/blob/master/Cargo.toml#L17-L26 . Once
Servo builds with the modified crate, you can run the automated
bluetooth tests to verify that the behaviour is the same: `./mach
test-wpt tests/wpt/mozilla/tests/bluetooth`.
Cheers,
Josh
On 3/30/19 12:50 PM, Niveditha Shankar wrote:
Okay I think I get it. Thank you!
Is there anyway I can check if the changes I make to the devices crate
is
right?
Our submission is on Monday and we are going to continue working with
Webbluetooth for our final project too. So if our implementation of our
adapter.rs file is right, we can go ahead and do something similar for
the
rest of the enum values. It would be really helpful if there is a way
to
check that.
Niveditha Shankar
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
