On Wed, Apr 09, 2014 at 11:26:08AM -0700, Dave Huseby wrote: > 3. It's painfully obvious that we have multiple solutions for the same > problems. It's also painfully obvious that it isn't easy for developers > to find out about existing tools (I know, I've been digging for days) > and therefore build their own solution under the false pretense that a > tool doesn't already exist. (I'm guilty of this myself, see #2).
There's also some unfortunate duplication with respect to sending information in the opposite direction. For example, the B2G about:memory support claims three realtime signals (one each for "dump report", "dump report after minimizing usage", and "dump GC/CC logs"), which are sent by a special utility we build because the existing kill(1) can't deal with numbers >= 32, and then the pipe-to-self trick is used to get out of signal handler context, etc. Followed by the previously mentioned polling for files to appear, which results in hacks like MOZ_IGNORE_NUWA_PROCESS that annoy people and reduce their productivity. Except we already have Marionette and XPConnect, which (now that bug 973090 landed) can replace all of that. I think. The only inelegance is that I'd like JS callbacks to call up into Python on the host, but execute_script can only return a value; this is workaroundable, but it'd be nice if there already were some way to yield a stream of events.... The situation with the profiler is similar, except the reinvented wheel is IMHO a bit more angular. There might be some interest in removing the overt async signal unsafety, the custom sort-of-CSV parser, etc. --Jed _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
