2015-05-01 21:17 GMT-03:00 Chapman Flack <gh...@anastigmatix.net>: > 2015-04-28 11:16:13 Wander Lairson Costa <wander.lairson@gm...>: >>> Should that name just be added to the big list o' names already >>> in libusb0.py _load_library()? Or check for sys.platform == 'sunos5' >>> and define a different _load_library that knows the right path? Or >>> some other approach? > >> Sorry, you commented this in the patch and I completely forgot >> to answer it. I think the simplest solution would be to add it >> to the list of candidates. > > Looking more closely, it wouldn't need added to the candidate list, > because it's called libusb.so and "usb" is already a candidate. It > would be found if it were in a more usual directory, but not in > /usr/sfw/lib. I was working on Solaris 10; possibly Solaris 11 has > moved it to solve that problem, as > https://www.mail-archive.com/opensolaris-arc@mail.opensolaris.org/msg13077.html > suggests. >
This probably fixes the issue, but PyUSB needs to be fixed for Solaris 10 too (I think). >> He doesn't necessarily need to rewrite the app in C, but he >> can write a faster backend. I am not worried about optimization >> right now, but guessing common paths seems like a smart and simple >> optimization. > > I looked more at where the external processes he complained of get run, > and sure enough, it's in ctypes.util.find_library. It /unconditionally/ > tries to run expensive stuff like gcc or objdump to "find" your argument, > even if you pass a full path. (oh yes, another thing that wasn't working: > the /usr/sfw/bin/gcc on solaris actually does know to look in /usr/sfw/lib, > but it uses the Solaris ld. The ctypes.util.find_library code assumes GNU ld > with a -t option to write all the found file names as it sees them, but -t > to solaris ld means something else altogether.) > Well, maybe the issue lies on ctypes, and we could patch it to find libraries in Solaris. I am not versed on Solaris, so what I am saying might be bs. > I don't really feel like also writing patches for ctypes, but I think it > probably would be a good optimization here to just try a few common > full paths before falling back to the ctypes.util.find_library. It might > just plain work better, in addition to solving the whole startup delay > issue that made that blogger think he had to port everything to C. :) > IMO, This kind of optimization should live in cypes, because all applications using it will benefit of faster startup times. If Python guys are not interested, I am. > I'll think about how a patch would look.... > I think a dictionary indexed by sys.platform, whose contents is a list of well known directories to try load libusb from. This code should live in the libloader module. -- Best Regards, Wander Lairson Costa ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ pyusb-users mailing list pyusb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyusb-users
