Thanks for clarifying the doubt! We were doing exactly this but did not know how to access the respective properties under BluetoothAdapter. Now we get it!
-Niveditha Shankar On Mon, Apr 1, 2019 at 10:23 AM Josh Bowman-Matthews <j...@joshmatthews.net> wrote: > Previously we had an enum > (https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html) like this: > enum BluetoothAdapter { > Bluez(Arc<BluetoothAdapterBluez>), > Android(Arc<BluetoothAdapterAndroid>), > } > > The Bluez, Android, etc. names gave us variants to refer to, with the > real type stored inside. We should now be able to define something like > this instead: > > trait BluetoothAdapter { > ... > } > > struct Bluez(Arc<BluetoothAdapterBluez>); > impl BluetoothAdapter for Bluez { > .. > } > > and in methods of this BluetoothAdapter implementation, refer to > `self.0.foo` to access property `foo` on the inner BluetoothAdapterBluez > (since Arc<T> is a smart pointer that automatically dereferences to the > inner type). > > Cheers, > Josh > > On 4/1/19 12:55 AM, Niveditha Shankar wrote: > > 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> < > https://github.com/servo/devices> > >>> > >>> > >>> Caused by: > >>> > >>> patch for `devices` in `https://github.com/servo/devices` > <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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
