On Sat, Feb 25, 2012 at 4:59 PM, L. David Baron <[email protected]> wrote: > On Saturday 2012-02-25 00:53 -0800, [email protected] wrote: >> On Monday, March 28, 2011 10:03:11 PM UTC+1, Benjamin Smedberg wrote: >> > * Embedding Mozilla rendering into other processes is a tough >> > problem. >> >> no it's not - the python-hulahop widget uses GTK just like >> firefox does: it works perfectly, and it even provides access to >> XPCOM so that python-xpcom can get hold of the NPAPI and use DOM >> functionality in exactly the same way that javascript does [when >> xulrunner is embedded in firefox] > > Has PyXPCOM been hooked up to the cycle collector yet, or do uses of > APIs that depend on cycle collection just leak memory?
david, thank you for responding on this. ... now, you see... this kind of information is entirely missing - and it's the relegation of pyxpcom to "third party status" within mozilla's project management - i.e. its removal from mozilla-central - that results in things like that massive PRBool->bool substitution, and other straightforward maintenance, being entirely missed. so the code is just left to rot, or is left to someone who really doesn't have the time or resources to focus 100% on keeping absolutely without fail without exception absolutely 100% up-to-date with every single one of the advances and modifications made to the mozilla core codebase such that they even *know* about things like "the cycle collector". now, as it's a small codebase, i'm certain that someone who *does* know about this "cycle collector", or any other code modifications, could probably bring pyxpcom up-to-date prior to each xulrunner stable release in very short order, especially when working alongside someone like todd who is familiar with the code. ... but the fact that nobody has even bothered, and has pretty much abandoned the code, leaves it as worse than useless, and a massive drain on the time and resources of the free software community, who have to learn or "re-learn" about each and every single API change, each and every single mozilla core codebase change each and every monotonous time *right* before a release. that's massively unfair to expect members of the free software community to do. hence why i have requested - formally on mozilla.governance - for advice on how to go about making a formal request that the mozilla foundation a) adopt python-hulahop as a 1st level priority project b) reinstate pyxpcom as a 1st level priority project - preferably *back* into mozilla-central. c) introduce unit tests that, if not passed, will block the release of *any* xulrunner release at the time until such time as the bugs are fixed and the unit tests pass. the end result will actually be an *improvement* in the quality of the xulrunner and the firefox codebase because it will result in a different kind of testing - from a different angle with different code-paths of the exact same core components that are utilised in firefox. do you happen to know to whom such formal requests should be directed? many thanks, l. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
