Could you please brief us a little on "Bluez(Arc<BluetoothAdapterBluez>), Android(Arc<BluetoothAdapterAndroid>)... " so that we can get an idea of how they should be declared in trait.
Since the implementation has to be per platform, I understand that the function calls for say, get_id() should be direct like - bluez.get_id(). It would be helpful if I had a better understanding of Bluez(Arc<BluetoothAdapterBluez>). Thank you! Niveditha Shankar On Sun, Mar 31, 2019 at 8:32 PM Josh Bowman-Matthews <j...@joshmatthews.net> wrote: > 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` <https://github.com/servo/devices> > > > > > > Caused by: > > > > patch for `devices` in `https://github.com/servo/devices` > <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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
