On 20/06/2011 22:35, Chris Frey wrote: > On Mon, Jun 20, 2011 at 11:26:12AM +0100, Toby Gray wrote: >>> 1) Your SetAltInterface() TODO message >>> > Sounds good to me.
Fixed and tested on MacOSX 10.6.4 in e309b9847afc9a2ea86e on my github. > > I want to get away from a static context if at all possible. I believe > you're right that the change to the API would be minimal. Probe is > where the context would be fed in. Any state that would need to live > for as long as the underlying libusb could be placed into the context. I've moved usbwrap to use a context which is currently just static within common.cc in b144ccb9199b4295db40. I had a go at creating a Barry::Context, but it turns out there's quite a lot to do. Every use of dout(), ddout() and eout() needs to have a context passed to it and that means that almost every Barry object has to hold a reference to the context object. Are you happy for this to be the case? There will also need to be some moving around of how some of the error logging works to simplify getting hold of the currently library context. For example Data::InputHexLine() uses dout, but having data objects all having references to the context just for debug logging in InputHexLine seems a little excessive. Or do you have an alternative suggestion of how dout(), ddout() and eout() can interoperate with a Barry context? > >>> 3) The Probe results >> However I see a couple of problems with that. Firstly it gives the false >> impression that you can keep ProbeResults around after reprobing, which >> won't work with libusb 0.1 due to probing calling usb_scan_busses() to >> be called and therefore invalidating previous DeviceIDs. > This impression already exists, unfortunately. The user can copy around > ProbeResults that outlive Probe. That can be a problem with libusb 0.1 if the following sequence of events happens: 1. Program calls Probe() 2. Program copies a ProbeResult 3. Program calls ~Probe() 4. Program calls Probe() 5. Program attempts to use ProbeResult from 2. I think that step 5 will have undefined behaviour as libusb 0.1 will have freed/reused the memory pointed to by usb_device* when the second probe occurred at step 4. >> Secondly I've got a background task of trying to get Barry compiling and >> running on Android tablet devices. The bit that I'm currently stuck on >> with getting Barry to compile for Android is that there is no >> <tr1/memory> support in Android, so the Router class fails to compile. > Ouch. Is there a technical reason for this on Android? I think they've just not added it. They use their own custom written libc and they only just started providing STL support in the latest NDK (the development kit used to build native code). Anyway I'll do some further investigation when I look at it next, but I think for now there's no reason not to use shared_ptr in another place as there's already the need for it. > I like that idea a lot. :-) Actually, you could have an impl pointer in the > DeviceID class, probably even managed with shared_ptr<> internally, and the > DeviceID object could then be treated like POD, and copied straight. Done in b4c48ac76f0fc78b3fe0. The old workaround for barrydesktop in fa10f865f61e73fbb89b was reverted in da1bd634f33658646728. Regards, Toby ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
