allo david, thanks for responding here. On Sun, Feb 26, 2012 at 4:20 AM, L. David Baron <[email protected]> wrote: > On Saturday 2012-02-25 19:38 +0000, lkcl luke wrote: >> 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. > > It's not. It's a massive task. (I'd guess it's roughly equivalent > in complexity to everything else in PyXPCOM. That is, I'd guess > that this would be about half the work of writing PyXPCOM from > scratch with it included. That's a very rough guess, though.)
*whistles*. if you have time, could you help me to assess what's actually involved? what code uses the "cycle collector", what patch implemented a change-over to the functions behind "cycle collector" etc. etc. i note for example in xpcom/src/PyISupports.cpp that there are functions utilised called nsMemory::Alloc and nsMemory::Free, and a quick grep | wc shows 45 such functions in the 7,000 lines comprising xpcom/src/*.cpp but i have no actual idea which c/c++ functions you're referring to, yet. >> ... 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. > > Why do you consider Mozilla employees different from other members > of the software community? Mozilla is paying its employees to be > members of the community -- and to perform the tasks where they'd > most effectively advance Mozilla's mission > ( http://www.mozilla.org/about/manifesto.en.html ). There are other > companies who pay people to work on Mozilla code (e.g., in the area > of embedding, a number of Linux distributors have at various times). this is a good point - i can't explain it though. i know that something's "not right", but i don't have the... how-to-say... i haven't been able to accurately articulate what i feel is the matter. does that make any sense? i'm sitting here waving my hands, trying to think how to express the frustration that i feel but the words just aren't coming to me :) >> 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. > > Demanding that somebody else do work for you doesn't seem like an > approach likely to succeed. for "me"? no. you misunderstand. if this was for *me* i would go and - personally - use pythonwebkit. which i - me - *i* wrote that. http://www.gnu.org/software/pythonwebkit. pythonwebkit does the *exact* same job as xpcom+hulahop, from the high-level (python-based) API perspective. when i say the exact same job i mean that by the time you get to the DOM/HTML5 level, all of the thousands of properties and functions, and the hundreds of objects that are accessible to python, are EXACTLY the same [near as damnit, and the pyjamas desktop codebase has a way of normalising those differences seamlessly so that developers using its SDK don't have to worry about those discrepancies]. so if this was JUST ME - if it was alllll about me, meee, meee, i would be the kind of hypothetical egomaniac who would hypothetically say hypothetically "f*** it, i'm not going to bother with these [hypothetical] mozilla [hypothetical] jerks, iiii'm gonna use that pythonwebkit code, nyer nyer nyer, [hypothetically] sod the lot of you, nyer nyer nyer" - don't for one second think or imagine that i ACTUALLY would say that, ok! i - personally - have the intelligence and the capability to do that kind of thing - to take on code that other people simply don't even grasp, and to join it to *other* code that serves some completely alternative purpose, and make the whole thing work. btw it may interest you to know that pythonwebkit actually uses the xulrunner python-based IDL file parser! i modified it to be able to understand webkit's IDL files instead of xulrunner's IDL files! i also adapted python-gobject's codegen.py for outputting the back-end part of the c-based python module, joined the two together. ... but you see where i'm going with this? i neither made demands nor expected my ego to be evaluated as part of the equation. >> 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. > > That's at least a more reasonable argument. I don't believe it, > though. https://bugzilla.mozilla.org/show_bug.cgi?id=728645 looking back at the file history of FocusManager.cpp the bugreports indicate that there have been changes to the FocusManager API in exactly the area which is involved. now the problem that _i_ have, as an outsider, is that normally i would deploy "git bisect" techniques to track down the commit revision with a binary search in order to isolate the commits between xulrunner 9.0 and xulrunner 10.0.2 which resulted in the segfault. this technique is, as you know, commonly deployed as a means to substitute for lack of unit test regression which _should_ have been being run on a regular basis [note, pointedly, that hulahop is *entirely* excluded from that daily continuous unit test regression testing, which is what this is all about]. i looked for *two days* for an understanding of the mozilla codebase and organisation in order to be able to provide that valuable information - the two consecutive commits that did and did not result in that segfault. could i find _anything_ which guided me on how to do that commit bisecting? naah. i cannot find _anything_ on how to relate commits in mozilla-central to the release cycles tree... it's just .... waargh! :) but anyway, that aside: can you see that between [working] xulrunner 9.0 code and [non-working] xulrunner 10.0.2 code (when using xpcom+hulahop), there were some commits made that dealt with segfaults on certain platforms (macosx, windows), but that somehow xulrunner on gnu/linux does *not* have such segfaults? but the key question is this: what do you think would have happened if there was daily automated regression tests being carried out using xpcom+hulahop? do you think that xulrunner 10.0.2 would have gone out the door at the time that it did, if this segfault had been detected at the time? > I think any future in our embedding API should be based around APIs > designed to be an embedding API, not around a collection of internal > functions gathered up and labeled as an API. david - you've entirely - i mean so completely missed the point it actually takes my breath away. > The problem with the > latter is that it's hard to avoid changing them, because they > weren't designed to be permanent. david: please look up what middleware technologies such as CORBA, COM, Objective-C, gobject introspection etc. are, have achieved and enabled, both historically (if 20 years can be considered "historic" in the context of computing) as well as recently. i don't wish to offend you or anything but the fact remains that you've demonstrated a complete lack of comprehension of what XPCOM actually brings to the table. the summary is this: Common Object Model middleware such as microsoft's COM, CORBA and XPCOM *are* permanent. they're a permanent API that's so absolute "set-in-stone permanent" that 20 YEARS later, it's possible to connect to even _proprietary_ DLLs that have a COM interface, for example, and still use them in a modern application, today. even advances and improvements in COM over the past 2 decades are done in such a way that they're always, always backwards-compatible. backwards-compatibility is DESIGNED into the fundamental API of a good Common Object Model's infrastructure, right at the very very beginning when it's first created. so please excuse me, but i'm a bit taken aback that you're commenting on this topic when you've demonstrated a complete lack of knowledge of the fundamentals of Common Object Model architectures. you're not alone, though, i have to say. > You're not going to turn the > latter into the former by shaking bugs out through additional > testing. david - i'm not being rude or anything but you just don't get it. please review and understand what XPCOM and technology similar to it actually is before commenting further on this subject. i look forward to hearing from you in the near future when you will be able to say "omg, did i _really_ say that? that's very funny!" and we can have a bit of a laugh and share a joke about how much you didn't know about the immense power of Common Object Model technology (in general). you're not alone. very very VERY few people in the Free Software Community understand the immense power and design freedom that Common Object Model technology gives people. some people _are_ finally reinventing some of the concepts of COM, in the form of gobject introspection, but that is really a very recent addition which will take some considerable time to percolate through the free software community. l. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
