27434 2009-07-19 15:48:14 -0700 adding necessary functions and properties to Document IDL gobject bindings 2011-07-11 13:06:20 -0700 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED P2 Normal --- 16401 0 lkcl webkit-unassigned mrobinson xan.lopez oldest_to_newest 133034 0 lkcl 2009-07-19 15:48:14 -0700 this is part of the split of #16401 patch into separate patches under an agreement suggested by david. inexplicably, three key features that are available under javascript bindings have been shut out: ability to change a document's domain; ability to set its location (and thus do weird but essential stuff); call document.getSelection(). it should be fairly obvious as to why these would be needed: the fact that they exist in javascript is reason enough alone, to put webkit language bindings "on a par" with javascript and also with its peers. 133035 1 33063 lkcl 2009-07-19 15:50:29 -0700 Created attachment 33063 adds 3 essential features to gobject document idl 133239 2 eric 2009-07-20 14:54:58 -0700 These again seem like they shoudl be !objc. 134057 3 33063 mrowe 2009-07-23 00:56:27 -0700 Comment on attachment 33063 adds 3 essential features to gobject document idl > Index: WebCore/dom/Document.idl > =================================================================== > --- WebCore/dom/Document.idl (revision 44473) > +++ WebCore/dom/Document.idl (working copy) > @@ -154,7 +154,8 @@ > > attribute [ConvertNullToNullString] DOMString title; > readonly attribute DOMString referrer; > -#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT > +#if (defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT) || \ > + (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT) > attribute [ConvertNullToNullString] DOMString domain; > #else > readonly attribute DOMString domain; I wonder why the non-JavaScript case is marked as readonly. The HTML 5 spec suggests it should not be. It may be that we should consider removing the #if's here. > @@ -180,7 +181,8 @@ > > NodeList getElementsByName(in DOMString elementName); > > -#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT > +#if (defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT) || \ > + (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT) > attribute [Custom] Location location; > #endif This is flagged as being [Custom] but I don't see a gobject method implementing this property anywhere in the patch. Did you forget to include it? > @@ -193,7 +195,8 @@ > Element elementFromPoint(in long x, in long y); > > // Mozilla extensions > -#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT > +#if (defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT) || \ > + (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT) > DOMSelection getSelection(); > #endif The #if's should probably be removed from this one. The method was added in <http://trac.webkit.org/changeset/30515>, where the ChangeLog notes that it was restricted to JS as it was only added for web compatibility. Since then, the getSelection attribute on Document has made its way in to the HTML 5 specification: <http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#documents>. 134060 4 mrowe 2009-07-23 01:13:46 -0700 (In reply to comment #3) > > @@ -180,7 +181,8 @@ > > > > NodeList getElementsByName(in DOMString elementName); > > > > -#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT > > +#if (defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT) || \ > > + (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT) > > attribute [Custom] Location location; > > #endif > > This is flagged as being [Custom] but I don't see a gobject method implementing > this property anywhere in the patch. Did you forget to include it? Thinking on this further, I suspect Custom may actually mean JSCustom so my question may not have been quite right. The WebCore::Location object itself does not have any mutable members, while the IDL specifies that the properties are mutable. The JavaScript bindings have custom logic for Location so that manipulating its properties results in the expected navigations. Without this custom logic it's not clear to me how the bindings for Location will compile, and thus why it is useful to expose this particular attribute. 134069 5 lkcl 2009-07-23 02:54:31 -0700 (In reply to comment #3) > (From update of attachment 33063 [details]) > > Index: WebCore/dom/Document.idl > > =================================================================== > > --- WebCore/dom/Document.idl (revision 44473) > > +++ WebCore/dom/Document.idl (working copy) > > @@ -154,7 +154,8 @@ > > > > attribute [ConvertNullToNullString] DOMString title; > > readonly attribute DOMString referrer; > > -#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT > > +#if (defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT) || \ > > + (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT) > > attribute [ConvertNullToNullString] DOMString domain; > > #else > > readonly attribute DOMString domain; > > I wonder why the non-JavaScript case is marked as readonly. The HTML 5 spec > suggests it should not be. It may be that we should consider removing the > #if's here. ok - i'm happy to submit a [separate] patch and you can make a decision then. > > @@ -180,7 +181,8 @@ > > > > NodeList getElementsByName(in DOMString elementName); > > > > -#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT > > +#if (defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT) || \ > > + (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT) > > attribute [Custom] Location location; > > #endif > > This is flagged as being [Custom] but I don't see a gobject method implementing > this property anywhere in the patch. Did you forget to include it? no - i added it on the basis that its inclusion will have no impact on the day-to-day compilation of webkit. the implementation comes automatically as part of the addition of gobject property auto-generation, in CodeGeneratorGObject.pm. and as you know, that's being reviewed separately. > > @@ -193,7 +195,8 @@ > > Element elementFromPoint(in long x, in long y); > > > > // Mozilla extensions > > -#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT > > +#if (defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT) || \ > > + (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT) > > DOMSelection getSelection(); > > #endif > > The #if's should probably be removed from this one. The method was added in > <http://trac.webkit.org/changeset/30515>, where the ChangeLog notes that it was > restricted to JS as it was only added for web compatibility. Since then, the > getSelection attribute on Document has made its way in to the HTML 5 > specification: > <http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#documents>. ack, ok, likewise, i'll include it in a separate patch, as both DOMString domain and DOMSelection getSelection() changes aren't specifically gobject-related. 134074 6 lkcl 2009-07-23 03:23:25 -0700 (In reply to comment #4) > (In reply to comment #3) > > > @@ -180,7 +181,8 @@ > > > > > > NodeList getElementsByName(in DOMString elementName); > > > > > > -#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT > > > +#if (defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT) || \ > > > + (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT) > > > attribute [Custom] Location location; > > > #endif > > > > This is flagged as being [Custom] but I don't see a gobject method implementing > > this property anywhere in the patch. Did you forget to include it? > > Thinking on this further, I suspect Custom may actually mean JSCustom so my > question may not have been quite right. The WebCore::Location object itself > does not have any mutable members, while the IDL specifies that the properties > are mutable. The JavaScript bindings have custom logic for Location so that > manipulating its properties results in the expected navigations. Without this > custom logic it's not clear to me how the bindings for Location will compile, > and thus why it is useful to expose this particular attribute. ohhh, i see. hah. right. that helps to know that there will be extra work required to make that happen at some point. context: the pyjamas API provides access to location because that's what GWT does. the functions provided _mostly_ comprise "decoding" of location (reading from it). however, for personal projects that utilise the pyjamas API, i never used _setting_ of location, i always utilised Window.open(). that's not to say that someone else might try to use them and get unexpected results, so i will submit a patch which makes them read-only for now. thanks for noting this, mark. 134076 7 33324 lkcl 2009-07-23 03:31:52 -0700 Created attachment 33324 adds read-only access to Document.location pending writing of custom code to set location properties (at some indeterminate future point) 134077 8 lkcl 2009-07-23 03:36:43 -0700 > Without this > custom logic it's not clear to me how the bindings for Location will compile, they'll compile all right (and do) - it will just be that you set the location and nothing happens (because the custom code is missing). hmmm.... are we confusing setting of location itself with setting of location's properties? looking at Location.idl, i'd be reluctant to submit even an interim patch that switches on read-only on an already-overcrowded IDL file just for gobject bindings, and would instead place warnings in the pyjamas API [or just say "nuts" to it, because XULrunner, as the more mature bindings, i'd expect to work fine] 134136 9 33324 mrowe 2009-07-23 09:56:14 -0700 Comment on attachment 33324 adds read-only access to Document.location pending writing of custom code to set location properties (at some indeterminate future point) As far as I can see this doesn't really address the issue, which relates to a member of type Location being exposed. Document::location being read-only does not prevent you from mutating Location::href, which will fail unless your bindings explicitly handle setters for Location's members in a custom fashion (WebCore::Location has no setHref method). Given that the URL of a document is trivially retrievable from the ports WebView object, I don't see any reason to #if this particular member until the problem here can be addressed in a more robust manner. 134141 10 lkcl 2009-07-23 10:19:51 -0700 (In reply to comment #9) > (From update of attachment 33324 [details]) > As far as I can see this doesn't really address the issue, which relates to a > member of type Location being exposed. Document::location being read-only does > not prevent you from mutating Location::href, which will fail unless your > bindings explicitly handle setters for Location's members in a custom fashion > (WebCore::Location has no setHref method). as a first revision, i'd consider that to be acceptable. anything else requires additional work. > Given that the URL of a document is > trivially retrievable from the ports WebView object, I don't see any reason to > #if this particular member until the problem here can be addressed in a more > robust manner. ok - but that requires development. i've made it clear that further _development_ is not going to happen, not until the existing work is accepted. there's just far _far_ too much that's outstanding, and to increase that burden of work further is simply not acceptable. so, unfortunately, you'll need to accept the reality of that. i'll happily document the required work, mark it as "TODO" etc. etc. but there will be _no_ further development until this series of patches which comprise #16401 are landed. you _do_ need to accept that, and adjust accordingly. 134143 11 lkcl 2009-07-23 10:22:33 -0700 ok - how about a patch which takes all of the properties in Location.idl and makes them read-only? that's simple (and i don't care if it complicates the IDL file). i'm _not_ adding yet more code to this series, there's far too much outstanding as it is. 134150 12 33344 lkcl 2009-07-23 10:35:08 -0700 Created attachment 33344 makes Document.location and all Location properties read-only, pending writing of custom code (at some indeterminate future point) like this? what do you think? it's an intermediate "safety" step. i can't cut access to Location out entirely, because of the "get" code in the pyjamas API: http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/library/pyjamas/Location.py?content-type=text%2Fplain 134154 13 lkcl 2009-07-23 10:45:14 -0700 (In reply to comment #5) > ack, ok, likewise, i'll include it in a separate patch, as both > DOMString domain and DOMSelection getSelection() changes aren't > specifically gobject-related. done as https://bugs.webkit.org/show_bug.cgi?id=27603 134203 14 33344 mrowe 2009-07-23 12:37:29 -0700 Comment on attachment 33344 makes Document.location and all Location properties read-only, pending writing of custom code (at some indeterminate future point) I would prefer that we skip generation of Location and Document::location until they can be supported properly. As I noted in a previous comment, the WebKit APIs already provide mechanisms for retrieving the URL of a frame so I don't buy the argument that this property *needs* to be exposed *now*. 134258 15 lkcl 2009-07-23 14:25:12 -0700 (In reply to comment #14) > (From update of attachment 33344 [details]) > I would prefer that we skip generation of Location and Document::location until > they can be supported properly. As I noted in a previous comment, the WebKit > APIs already provide mechanisms for retrieving the URL of a frame so I don't > buy the argument that this property *needs* to be exposed *now*. this is similar to what sam asked, here: https://bugs.webkit.org/show_bug.cgi?id=27435#c10 and, likewise, there are a number of reasons, repeated here. out of simplicity, to not massively disrupt the existing test platform - the _only_ comprehensive test platform, pyjamas-desktop, you don't go ripping sections of the available test suite out. you also don't go making developers' lives more difficult. if code has to be written that doesn't conform to the API, that's more code to maintain. yes, it _needs_ to be exposed _now_ because it's being _used_. _now_. and has been for several months. this isn't some futuristic API: it's in actual use. fortunately, as i mentioned, actual changing of location isn't being used (and hasn't been asked for) as there is Window.open(.....) so - sorry, but utilising some quotes "existing" quotes API that isn't actually the DOM isn't acceptable. forcing people to write code that makes exceptions for webkit, by having a non-standard, non-DOM-based version of the API is _not_ a good enough reason to turn down a review. thus, review- is denied, which leaves me free to re-enable it. 135714 16 mrowe 2009-07-29 16:31:32 -0700 (In reply to comment #15) > yes, it _needs_ to be exposed _now_ because it's being _used_. _now_. and > has been for several months. > > this isn't some futuristic API: it's in actual use. This argument is nonsense. WebKit does not expose this method so by definition nothing is currently using it. > so - sorry, but utilising some quotes "existing" quotes API that isn't > actually the DOM isn't acceptable. forcing people to write code that makes > exceptions for webkit, by having a non-standard, non-DOM-based version of the > API is _not_ a good enough reason to turn down a review. An application using WebKit by definition has to make use of WebKit-specific API. > thus, review- is denied, which leaves me free to re-enable it. And yet doing so without addressing the points that reviewers raise serves no purpose other than wasting our time. We don't like having our time wasted. Please stop it. 135809 17 lkcl 2009-07-30 04:54:33 -0700 (In reply to comment #16) > > thus, review- is denied, which leaves me free to re-enable it. > > And yet doing so without addressing the points that reviewers raise serves no > purpose other than wasting our time. mark - with respect, in many cases, the complete opposite is the case. i raise issues, and it is _you_ that do not answer them satisfactorily. if at all. in some cases, i have asked _nineteen_ times that you look at issues, and you have failed in your responsibility to do so. that having been said, i'm aware that in #16401 there have been issues overlooked, and i apologise for that, but if you look closely, you will see that the sheer _number_ of issues involved means that mistakes are going to be made. i _did_ say, _very_ early on, that a single bugreport would be inadviseable to discuss this complex topic, but you and the other reviewers over-ruled me, even to the extent of closing down bugreports that i created to keep track of the issues related to #16401. so, i had to wait until it was _david_ who suggested that the bug be split down into separate patches, and it's why i've quoted david's name at the top of each one, so that you and your associates don't go closing them down on a whim. so, it would do you quite a lot of credit, as a responsible reviewer, to be patient and accept that on complex issues, the "process" is creaking at the seams, and you have to work round that. > We don't like having our time wasted. > Please stop it. neither do i like having my time wasted. please stop it. is that what you wanted me to say? do you _want_ these discussions to go on, in this childish - and non-technical way? do you _remember_ your agreement in #16401 (around comment number 70), to stick to technical discussions? ehn? come on, mark. if the process sucks, don't blame the people that are using it: learn from it, adapt and work with the _people_, not the process. i'll do the same, ok? 135813 18 lkcl 2009-07-30 05:03:53 -0700 (In reply to comment #16) > (In reply to comment #15) > > yes, it _needs_ to be exposed _now_ because it's being _used_. _now_. and > > has been for several months. > > > > this isn't some futuristic API: it's in actual use. > > This argument is nonsense. WebKit does not expose this method so by definition > nothing is currently using it. you've lost me. > > so - sorry, but utilising some quotes "existing" quotes API that isn't > > actually the DOM isn't acceptable. forcing people to write code that makes > > exceptions for webkit, by having a non-standard, non-DOM-based version of the > > API is _not_ a good enough reason to turn down a review. > > An application using WebKit by definition has to make use of WebKit-specific > API. > sorry, but you've completely lost me. i thought we were discussing the definition of the webkit-specific API. please correct me if i'm wrong, but it sounds like you're saying that the webkit API is set in stone, and that anyone wishing to make use of webkit must live with that, even if it doesn't do what's actually needed. ... but i doubt very much that that's what you're saying. please could you clarify? 135898 19 mrowe 2009-07-30 11:35:02 -0700 (In reply to comment #17) > (In reply to comment #16) > > > thus, review- is denied, which leaves me free to re-enable it. > > > > And yet doing so without addressing the points that reviewers raise serves no > > purpose other than wasting our time. > > mark - with respect, in many cases, the complete opposite is the case. i > raise issues, and it is _you_ that do not answer them satisfactorily. if at > all. in some cases, i have asked _nineteen_ times that you look at issues, and > you have failed in your responsibility to do so. You appear to think that because I disagree with you I must be uninformed. I've looked at the issues involved and reached a different conclusion, as have the other WebKit reviewers. > i _did_ say, _very_ early on, that a single bugreport would be inadviseable to > discuss this complex topic, but you and the other reviewers over-ruled me, even > to the extent of closing down bugreports that i created to keep track of the > issues related to #16401. > > so, i had to wait until it was _david_ who suggested that the bug be split > down into separate patches, and it's why i've quoted david's name at the top of > each one, so that you and your associates don't go closing them down on a whim. You're conflating the recent filing of bugs (designed to get small patches landed) with your previous attempt to file bugs about things that would remain to be implemented if your original mega-patch were landed. The former is quite reasonable. The latter simply doesn't make sense when the patch is so far from being landed. > > We don't like having our time wasted. > > Please stop it. > > neither do i like having my time wasted. > please stop it. > > is that what you wanted me to say? do you _want_ these discussions to go on, > in this childish - and non-technical way? What I would like you to do is quite simple: stop wasting our time. You can do this by being more reasonable and respectful in your approach to dealing with the WebKit community. You can do this by simply going away. To be quite blunt: I am sick of your incoherent ranting and your self-centered world view. Even in the rare occasions that you stick to the technical issues it is barely possible to follow what you're saying. Not because what you're saying is so brilliant that I cannot follow, but because it reads like it was written by a child with an ego the size of a small country. You ramble and repeat yourself. You demand special treatment. You throw veiled insults at the people you're supposedly trying to work with. You try and pass opinion off as fact. The reason that no one responds in detail to comments that you make is because it's simply not possible to respond in a sensible way to something that doesn't make sense. People have suggested many times that you be more concise and stick to the technical issues. Unless you do that I'm afraid you're not going to make much in the way of progress. > do you _remember_ your agreement in #16401 (around comment number 70), to > stick to technical discussions? "Stop abusing the patch review process" is a technical issue. > come on, mark. if the process sucks, don't blame the people that are using > it: learn from it, adapt and work with the _people_, not the process. i'll do > the same, ok? The process isn't perfect, but you're the only one that has had such huge problems with it. I'm certain that this says more of you than it does the process. [ This is a lot more personal than I had originally intended but, frankly, I don't see how else to address the fact that the person is the problem. ] 135904 20 mrowe 2009-07-30 11:44:56 -0700 (In reply to comment #18) > > > so - sorry, but utilising some quotes "existing" quotes API that isn't > > > actually the DOM isn't acceptable. forcing people to write code that makes > > > exceptions for webkit, by having a non-standard, non-DOM-based version of the > > > API is _not_ a good enough reason to turn down a review. > > > > An application using WebKit by definition has to make use of WebKit-specific > > API. > > > > sorry, but you've completely lost me. > > i thought we were discussing the definition of the webkit-specific API. > > please correct me if i'm wrong, but it sounds like you're saying that the > webkit API is set in stone, and that anyone wishing to make use of webkit must > live with that, even if it doesn't do what's actually needed. > > ... but i doubt very much that that's what you're saying. That would be a stupid thing for me to say. Thanks for suggesting that it was what I said. You were arguing that it is vitally important to expose this incomplete DOM binding immediately, even though the same information (the URL of a document) is exposed via the WebKit API in a different manner. My point is simple: I don't see the value in exposing an incomplete DOM binding for this property since there is an existing means of retrieving this information. It doesn't seem worth the mess of #if'ing up the IDL files and the confusion that would result from users who expected the exposed properties to behave in the standard manner. 136597 21 lkcl 2009-08-03 01:19:22 -0700 > > please correct me if i'm wrong, but it sounds like you're saying that the > > webkit API is set in stone, and that anyone wishing to make use of webkit must > > live with that, even if it doesn't do what's actually needed. > > > > ... but i doubt very much that that's what you're saying. > > That would be a stupid thing for me to say. Thanks for suggesting that it was > what I said. this comes across as a sarcastic comment, which i am sure you did not intend it to be. i did no such thing: i respectfully requested clarificaiton, which you've kindly provided, below. i apologise for giving the wrong impression. > You were arguing that it is vitally important to expose this incomplete DOM > binding immediately, yes. the read-only information is vital, and is in real-world usage, today. the writing can wait. > even though the same information (the URL of a document) > is exposed via the WebKit API in a different manner. in a manner which has knock-on complications for upstream development, yes. > My point is simple: I don't see the value in exposing an incomplete DOM binding > for this property since there is an existing means of retrieving this > information. It doesn't seem worth the mess of #if'ing up the IDL files and > the confusion that would result from users who expected the exposed properties > to behave in the standard manner. ahh, but mark, it was you who turned down the review on the simple approach, which was to just have the Document.location property made available and be done with it, on the basis that the custom functions can be added later. so, now i think we've covered the possibilities, we have three approaches to take. which is it going to be? 1) make life damn awkward for upstream development 2) "complicate" the IDL file (but protect users from the consequences) 3) "clean" IDL, make things easy for upstream developers, with known consequences and an upgrade / development path which can be fixed at a later date? 1) isn't acceptable. 2) i can live with. 3) i believe is the best, pragmatic workable path. 136694 22 mrowe 2009-08-03 10:26:35 -0700 (In reply to comment #21) > > even though the same information (the URL of a document) > > is exposed via the WebKit API in a different manner. > > in a manner which has knock-on complications for upstream development, yes. I don't understand what you mean by "upstream development". I suspect what you mean here is "it would affect my project". That is indeed unfortunate. However, I don't think it's a reasonable approach for you to write a patch, start using it in your own project before it has been accepted upstream, and then insist it be accepted in the form you provided because you're using it in that form and you don't want to adapt to changes that are requested. > > My point is simple: I don't see the value in exposing an incomplete DOM binding > > for this property since there is an existing means of retrieving this > > information. It doesn't seem worth the mess of #if'ing up the IDL files and > > the confusion that would result from users who expected the exposed properties > > to behave in the standard manner. > > > ahh, but mark, it was you who turned down the review on the simple > approach, which was to just have the Document.location property made > available and be done with it, on the basis that the custom functions > can be added later. A simple approach that had similar issues to the current patch: it exposes what is at best a confusing subset of the bindings. > so, now i think we've covered the possibilities, we have three approaches to > take. which is it going to be? > > 1) make life damn awkward for upstream development > > 2) "complicate" the IDL file (but protect users from the consequences) > > 3) "clean" IDL, make things easy for upstream developers, with known > consequences and an upgrade / development path which can be fixed > at a later date? Since you've injected hyperbole and omitted clarity from this list it's not clear to me what each of the options corresponds to. I'll restate what I feel the situation is: The patches so far expose a subset of the Location bindings that allows one to access the location of a Document. The WebKit APIs expose existing means of accessing the location of a document. I have not seen a good argument for why adding #if's to the IDL files in order to expose functionality that is already available via other means is a good thing. Exposing full bindings for Location does seem like a good idea, but you've expressed reluctance to do that at this time. That seems fine to me, since as I've mentioned the information is already exposed using other API. 138044 23 lkcl 2009-08-07 12:34:08 -0700 (In reply to comment #22) > (In reply to comment #21) > > > even though the same information (the URL of a document) > > > is exposed via the WebKit API in a different manner. > > > > in a manner which has knock-on complications for upstream development, yes. > > I don't understand what you mean by "upstream development". ah, sorry. > I suspect what you > mean here is "it would affect my project". That is indeed unfortunate. it would affect "the" project which i happen to be working on, yes. as i explained when martin also used a personal pronoun to refer to some code that i had written, i don't use personal pronouns to indicate claims of ownership over code. it's a standard rule of software engineering: the usual phrase to refer to it is "egoless programming". much appreciated if you could say "the project that you're working on" rather than "your project" etc. etc. so, anyway... i should explain [in the context of the project that i'm working on, which happens to be the only active major project / test case / use case for these bindings] * pyjamas-desktop now has three ports: XULrunner, webkit and MSHTML. * all three have python bindings. * python-xpcom has read-only access to Document location properties [through a weird read-only interface], and the nsIHTMLDOMDocument interface appears to be TR-DOM2 only, with the location properties themselves [if you follow the weird interface] are read-write: http://www.oxymoronical.com/experiments/apidocs/interface/nsIDOMNSDocument http://www.oxymoronical.com/experiments/apidocs/platform/1.9.2a1pre/interface/nsIDOMLocation through which, it's possible to get and set location, in exactly the way that's intuitively expected. * MSHTML's COM interface has read-write access to Document.location: http://msdn.microsoft.com/en-us/library/aa752596(VS.85).aspx http://msdn.microsoft.com/en-us/library/aa703641(VS.85).aspx through which, it's possible to get and set location, in exactly the way that's intuitively expected. * webkit's javascript interface has read-write access to Document.location * webkit's gobject interface has a bun-fight going on over its format, with several options being presented and discussed. [one is read-only identical access to what the other competitor language bindings provide] * webkit's gtk interface has a non-W3C-DOM-spec-compliant read-write interface so - with the option that has the least "knock-on complications for upstream development", the pseudo-code would look like this: def getLocation(document): return document.location and then, to get or set them, you just... do so. that's pretty simple, huh? with the method which you're recommending, _all_ upstream implementors [language bindings developers, users of the language bindings, or just people who use gobject c bindings direct] would have to do something like this: def getLocation(document): if systemtype == 'mshtml' or systemtype == 'xulrunner': return document.location else # heeere we go.... class LocationWrapperToDealWithStupidAPIDecision: def __init__(self, document): self.wrapped_document = document def get_hash(self): return webkit_web_frame_get_location_hash(self.wrapped_document) def set_hash(self, value): ...... ..... ..... ..... return LocationWrapperToDealWithStupidAPIDecision(document) do you see how pointless and ridiculous that is? do you also appreciate how much work it is? now multiply it up by the number of developers of language bindings. > However, I don't think it's a reasonable approach for you to write a patch, > start using it in your own project [correction: using it in a project which is entirely free software, on which i happen to have chosen to contribute to] > before it has been accepted upstream, and > then insist it be accepted in the form you provided because you're using it in > that form and you don't want to adapt to changes that are requested. ah. the clue here is "that are requested". there's an assumption that i agree with the changes requested. as you've discovered: sometimes i do, sometimes i don't. if i agree, i'll get on with it immediately, as you've noticed. if i don't, i'll say so. what i _won't_ do is simply make changes "that are requested" just _because_ they have been requested. it's up to you to convince me that the changes requested don't have adverse consequences and/or don't force on people [times however many gobject language bindings autogenerators etc.] an extra workload. and, as i'm working on the only project which is _actively_ dependent on these bindings, it gives me some active experience and a direct feel for what's needed, which i believe is very relevant. so. in this case, the changes "that are requested" have a nasty set of knock-on implications that will burden absolutely everyone using them. not only that, but i really don't see what the problem is. if people _need_ the write-capabilities to Location right now, right this second, then, yes, they'll use the [stupidly-named, non-W3C-compliant] webkitgtk+ functions. if they don't, they can use the temporarily-made-read-only W3C-compliant versions. or the temporarily-not-working-as-writeable W3C-compliant ones. > > > My point is simple: I don't see the value in exposing an incomplete DOM binding > > > for this property since there is an existing means of retrieving this > > > information. It doesn't seem worth the mess of #if'ing up the IDL files and > > > the confusion that would result from users who expected the exposed properties > > > to behave in the standard manner. > > > > > > ahh, but mark, it was you who turned down the review on the simple > > approach, which was to just have the Document.location property made > > available and be done with it, on the basis that the custom functions > > can be added later. > > A simple approach that had similar issues to the current patch: it exposes > what is at best a confusing subset of the bindings. well, you can't have it both (all) ways, right now. which would you prefer - make up your mind! :) > > so, now i think we've covered the possibilities, we have three approaches to > > take. which is it going to be? > > > > 1) make life damn awkward for upstream development > > > > 2) "complicate" the IDL file (but protect users from the consequences) > > > > 3) "clean" IDL, make things easy for upstream developers, with known > > consequences and an upgrade / development path which can be fixed > > at a later date? > > Since you've injected hyperbole and omitted clarity from this list make up your mind which you would like! if i provide sufficient detail so as to be clear, you accuse me of wasting time! :) ok, that's being silly, but it has a grain of truth in it. the above pseudo-code helps clarify what 1) is. 2 lines of code (or not even that) or a ridiculous wrapper class which "normalises" the DOM API, redirecting from what would otherwise be a decent (albeit limited) and above all *standard* API, into some code that was added in a decision by the webkitgtk+ developers to avoid writing the gobject bindings. > it's not > clear to me what each of the options corresponds to. I'll restate what I feel > the situation is: ok. good idea. > The patches so far expose a subset of the Location bindings that allows one to > access the location of a Document. ack. > The WebKit APIs expose existing means of > accessing the location of a document. yep. and changing it, too. > I have not seen a good argument for why > adding #if's to the IDL files in order to expose functionality that is already > available via other means is a good thing. Exposing full bindings for Location > does seem like a good idea, but you've expressed reluctance to do that at this > time. yes. although, the amount of time spent just discussing this somewhat laboriously does lead me to wonder if i should reconsider that. but - what's stopping me from doing that is that it will have knock-on implications for the CodeGeneratorGObject code, because anything that's "Custom" has to be special-cased right now [because many of the "Custom" functions and properties are either skipped, or the "Custom" property ignored entirely]. yet more changes and additions to an already complex generator, through non-webkit-standard controlled process, just seems like a truly bad idea, to me. > That seems fine to me, since as I've mentioned the information is > already exposed using other API. ok - it seems fine to you, because you're not the one who has to write the "wrapper" classes, upstream (in every single programming language which utilises the gobject bindings) to re-normalise the webkit-gobject API to one which matches the W3C specification _just_ for what will turn out to be a relatively small period of time. this is an _interim_ measure we're discussing, not a permanent one, after all. so. implications 1) : webkit is quotes nice and simple quotes, but everybody _else_ has to do a lot of work. implications 2) : read-only on Location properties and read-only on Document.location is quotes complicated in the IDL file quotes yet is also simple for upstream developers. but it has the advantage that in between the time when the gobject patches are being landed and when somebody writes the necessary gobject custom location code, upstream developers are protected from nasty consequences. implications 3) : read-write on Location properties is quotes simple for the IDL file quotes and also simple for upstream developers, but has the nasty consequence that if the upstream developers try to set location properties... nothing happens. fortunately, this will only be for a short period of time (until someone writes the necessary gobject custom location code), but even so... 1) is definitely not an option i would deem acceptable [and, if there _were_ any other developers other than myself and yorba doing language bindings to gobject...] 2)... *shrug*. 3)... *shrug*. also, for completeness, there's this: 4) - i write the gobject custom bindings _before_ landing the gobject patches: nnnnno. there's been enough svn-history / information been lost as it is, already, through the use of an external non-webkit-based repository (github.org) in the maintenance of the gobject bindings. 5) other [anyone else got any ideas?] so - 2 3 or 5 - you choose, i don't mind which. 435158 24 mrobinson 2011-07-11 13:06:20 -0700 Pretty sure this is completed now. Feel free to re-open if I'm mistaken. 33063 2009-07-19 15:50:29 -0700 2009-07-23 03:31:52 -0700 adds 3 essential features to gobject document idl doc.idl.patch text/plain 1982 lkcl SW5kZXg6IFdlYkNvcmUvZG9tL0RvY3VtZW50LmlkbAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2Rv bS9Eb2N1bWVudC5pZGwJKHJldmlzaW9uIDQ0NDczKQorKysgV2ViQ29yZS9kb20vRG9jdW1lbnQu aWRsCSh3b3JraW5nIGNvcHkpCkBAIC0xNTQsNyArMTU0LDggQEAKIAogICAgICAgICAgICAgICAg ICBhdHRyaWJ1dGUgW0NvbnZlcnROdWxsVG9OdWxsU3RyaW5nXSBET01TdHJpbmcgdGl0bGU7CiAg ICAgICAgIHJlYWRvbmx5IGF0dHJpYnV0ZSBET01TdHJpbmcgcmVmZXJyZXI7Ci0jaWYgZGVmaW5l ZChMQU5HVUFHRV9KQVZBU0NSSVBUKSAmJiBMQU5HVUFHRV9KQVZBU0NSSVBUCisjaWYgKGRlZmlu ZWQoTEFOR1VBR0VfSkFWQVNDUklQVCkgJiYgTEFOR1VBR0VfSkFWQVNDUklQVCkgfHwgXAorICAg ICAoZGVmaW5lZChMQU5HVUFHRV9HT0JKRUNUKSAmJiBMQU5HVUFHRV9HT0JKRUNUKQogICAgICAg ICAgICAgICAgICBhdHRyaWJ1dGUgW0NvbnZlcnROdWxsVG9OdWxsU3RyaW5nXSBET01TdHJpbmcg ZG9tYWluOwogI2Vsc2UKICAgICAgICAgcmVhZG9ubHkgYXR0cmlidXRlIERPTVN0cmluZyBkb21h aW47CkBAIC0xODAsNyArMTgxLDggQEAKIAogICAgICAgICBOb2RlTGlzdCBnZXRFbGVtZW50c0J5 TmFtZShpbiBET01TdHJpbmcgZWxlbWVudE5hbWUpOwogCi0jaWYgZGVmaW5lZChMQU5HVUFHRV9K QVZBU0NSSVBUKSAmJiBMQU5HVUFHRV9KQVZBU0NSSVBUCisjaWYgKGRlZmluZWQoTEFOR1VBR0Vf SkFWQVNDUklQVCkgJiYgTEFOR1VBR0VfSkFWQVNDUklQVCkgfHwgXAorICAgICAoZGVmaW5lZChM QU5HVUFHRV9HT0JKRUNUKSAmJiBMQU5HVUFHRV9HT0JKRUNUKQogICAgICAgICAgICAgICAgICBh dHRyaWJ1dGUgW0N1c3RvbV0gTG9jYXRpb24gbG9jYXRpb247CiAjZW5kaWYKIApAQCAtMTkzLDcg KzE5NSw4IEBACiAgICAgICAgIEVsZW1lbnQgICAgICAgICAgICBlbGVtZW50RnJvbVBvaW50KGlu IGxvbmcgeCwgaW4gbG9uZyB5KTsKIAogICAgICAgICAvLyBNb3ppbGxhIGV4dGVuc2lvbnMKLSNp ZiBkZWZpbmVkKExBTkdVQUdFX0pBVkFTQ1JJUFQpICYmIExBTkdVQUdFX0pBVkFTQ1JJUFQKKyNp ZiAoZGVmaW5lZChMQU5HVUFHRV9KQVZBU0NSSVBUKSAmJiBMQU5HVUFHRV9KQVZBU0NSSVBUKSB8 fCBcCisgICAgIChkZWZpbmVkKExBTkdVQUdFX0dPQkpFQ1QpICYmIExBTkdVQUdFX0dPQkpFQ1Qp CiAgICAgICAgIERPTVNlbGVjdGlvbiAgICAgICBnZXRTZWxlY3Rpb24oKTsKICNlbmRpZgogICAg ICAgICByZWFkb25seSBhdHRyaWJ1dGUgW0NvbnZlcnROdWxsU3RyaW5nVG89TnVsbF0gRE9NU3Ry aW5nIGNoYXJhY3RlclNldDsKSW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IFdlYkNvcmUvQ2hhbmdlTG9nCShyZXZpc2lvbiA0NDQ3MykKKysrIFdlYkNvcmUvQ2hhbmdlTG9n CSh3b3JraW5nIGNvcHkpCkBAIC02MjM3OCw2ICs2MjM4NiwxNCBAQAogICAgICAgICAoV2ViQ29y ZTo6UGFzdGVib2FyZDo6ZG9jdW1lbnRGcmFnbWVudCk6CiAgICAgICAgIChXZWJDb3JlOjpQYXN0 ZWJvYXJkOjp3cml0ZUltYWdlKToKIAorMjAwOC0xMS0zMCAgbGtjbCA8bGtjbEBsa2NsLm5ldD4K KworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKQorCisgICAgICAgIGh0dHBzOi8v YnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yNzQzNAorCisgICAgICAgICogZG9tL0Rv Y3VtZW50LmlkbDogYWRkZWQgTEFOR1VBR0VfR09CSkVDVC1zcGVjaWZpYyBJREwKKwogMjAwOC0x Mi0wNCAgS2V2aW4gT2xsaXZpZXIgIDxrZXZpbm9AdGhlb2xsaXZpZXJzLmNvbT4KIAogICAgICAg ICB3eCBidWlsZCBmaXggZm9yICFVU0UoV1hHQykgYnVpbGQgY29uZmlnLgo= 33324 2009-07-23 03:31:52 -0700 2009-07-23 10:35:08 -0700 adds read-only access to Document.location pending writing of custom code to set location properties (at some indeterminate future point) doc.idl.patch text/plain 1472 lkcl SW5kZXg6IFdlYkNvcmUvZG9tL0RvY3VtZW50LmlkbAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2Rv bS9Eb2N1bWVudC5pZGwJKHJldmlzaW9uIDQ0NDczKQorKysgV2ViQ29yZS9kb20vRG9jdW1lbnQu aWRsCSh3b3JraW5nIGNvcHkpCkBAIC0xODMsNiArMTgzLDExIEBACiAjaWYgZGVmaW5lZChMQU5H VUFHRV9KQVZBU0NSSVBUKSAmJiBMQU5HVUFHRV9KQVZBU0NSSVBUCiAgICAgICAgICAgICAgICAg IGF0dHJpYnV0ZSBbQ3VzdG9tXSBMb2NhdGlvbiBsb2NhdGlvbjsKICNlbmRpZgorICAgICAgICAv LyBGSVhNRTogZ29iamVjdCBiaW5kaW5ncyBuZWVkIHN1cHBvcnQgZm9yIGNoYW5naW5nIGxvY2F0 aW9uJ3MKKyAgICAgICAgLy8gcHJvcGVydGllcy4gIG1ha2luZyByZWFkb25seSBhcyBhbiBpbnRl cmltIGZpeC4KKyNpZiAoZGVmaW5lZChMQU5HVUFHRV9HT0JKRUNUKSAmJiBMQU5HVUFHRV9HT0JK RUNUKQorICAgICAgICAgICAgICAgICByZWFkb25seSBhdHRyaWJ1dGUgW0N1c3RvbV0gTG9jYXRp b24gbG9jYXRpb247CisjZW5kaWYKIAogICAgICAgICAvLyBJRSBleHRlbnNpb25zCiAKSW5kZXg6 IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9nCShyZXZp c2lvbiA0NDQ3MykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC02MjM3 OCw2ICs2MjQzMywxOSBAQAogICAgICAgICAoV2ViQ29yZTo6UGFzdGVib2FyZDo6ZG9jdW1lbnRG cmFnbWVudCk6CiAgICAgICAgIChXZWJDb3JlOjpQYXN0ZWJvYXJkOjp3cml0ZUltYWdlKToKIAor MjAwOC0xMS0zMCAgbGtjbCA8bGtjbEBsa2NsLm5ldD4KKworICAgICAgICBSZXZpZXdlZCBieSBO T0JPRFkgKE9PUFMhKQorCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVn LmNnaT9pZD0yNzQzNAorCisJCWh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9p ZD0yNzQzNCNjNCBub3RlcyB0aGF0CisJCWNoYW5naW5nIGxvY2F0aW9uIHJlcXVpcmVzIGN1c3Rv bSBjb2RlLiAgcmVhZCBhY2Nlc3MgdG8KKwkJbG9jYXRpb24gaXMgaG93ZXZlciBlc3NlbnRpYWws IHNvIGFjY2VzcyB0byB0aGlzIHByb3BlcnR5CisJCWluIGdvYmplY3QgYmluZGluZ3MgaXMgYmVp bmcgbWFkZSB0ZW1wb3JhcmlseSByZWFkLW9ubHkuCisKKyAgICAgICAgKiBkb20vRG9jdW1lbnQu aWRsOiBMQU5HVUFHRV9HT0JKRUNUIHJlYWQtb25seSBhY2Nlc3MgdG8gbG9jYXRpb24KKwogMjAw OC0xMi0wNCAgS2V2aW4gT2xsaXZpZXIgIDxrZXZpbm9AdGhlb2xsaXZpZXJzLmNvbT4KIAogICAg ICAgICB3eCBidWlsZCBmaXggZm9yICFVU0UoV1hHQykgYnVpbGQgY29uZmlnLgo= 33344 2009-07-23 10:35:08 -0700 2010-06-10 18:00:14 -0700 makes Document.location and all Location properties read-only, pending writing of custom code (at some indeterminate future point) doc.idl.patch text/plain 3587 lkcl SW5kZXg6IFdlYkNvcmUvZG9tL0RvY3VtZW50LmlkbAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2Rv bS9Eb2N1bWVudC5pZGwJKHJldmlzaW9uIDQ0NDczKQorKysgV2ViQ29yZS9kb20vRG9jdW1lbnQu aWRsCSh3b3JraW5nIGNvcHkpCkBAIC0xODMsNiArMTgzLDExIEBACiAjaWYgZGVmaW5lZChMQU5H VUFHRV9KQVZBU0NSSVBUKSAmJiBMQU5HVUFHRV9KQVZBU0NSSVBUCiAgICAgICAgICAgICAgICAg IGF0dHJpYnV0ZSBbQ3VzdG9tXSBMb2NhdGlvbiBsb2NhdGlvbjsKICNlbmRpZgorICAgICAgICAv LyBGSVhNRTogZ29iamVjdCBiaW5kaW5ncyBuZWVkIHN1cHBvcnQgZm9yIGNoYW5naW5nIGxvY2F0 aW9uJ3MKKyAgICAgICAgLy8gcHJvcGVydGllcy4gIHNlZSAjMjc0MzQgZm9yIGRldGFpbHMgb2Yg dGhlIGRpc2N1c3Npb24uCisjaWYgKGRlZmluZWQoTEFOR1VBR0VfR09CSkVDVCkgJiYgTEFOR1VB R0VfR09CSkVDVCkKKyAgICAgICAgICAgICAgICAgcmVhZG9ubHkgYXR0cmlidXRlIFtDdXN0b21d IExvY2F0aW9uIGxvY2F0aW9uOworI2VuZGlmCiAKICAgICAgICAgLy8gSUUgZXh0ZW5zaW9ucwog CkluZGV4OiBXZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL0NoYW5nZUxv ZwkocmV2aXNpb24gNDQ0NzMpCisrKyBXZWJDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpA QCAtNjIzNzgsNiArNjI0MjksMTYgQEAKICAgICAgICAgKFdlYkNvcmU6OlBhc3RlYm9hcmQ6OmRv Y3VtZW50RnJhZ21lbnQpOgogICAgICAgICAoV2ViQ29yZTo6UGFzdGVib2FyZDo6d3JpdGVJbWFn ZSk6CiAKKzIwMDktMDctMjMgIEx1a2UgS2VubmV0aCBDYXNzb24gTGVpZ2h0b24gPGxrY2xAbGtj bC5uZXQ+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkKKworICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Mjc0MzQKKworCQlodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Mjc0MzQjYzQgbm90ZXMgdGhhdCBjaGFu Z2luZyBsb2NhdGlvbiByZXF1aXJlcyBjdXN0b20gY29kZS4gIHJlYWQgYWNjZXNzIHRvIGxvY2F0 aW9uIGlzIGhvd2V2ZXIgZXNzZW50aWFsLCBzbyBhY2Nlc3MgdG8gdGhpcyBwcm9wZXJ0eSBpbiBn b2JqZWN0IGJpbmRpbmdzIGlzIGJlaW5nIG1hZGUgdGVtcG9yYXJpbHkgcmVhZC1vbmx5LCBhbmQg dGhlIHByb3BlcnRpZXMgb2YgTG9jYXRpb24gYXJlIG1hZGUgcmVhZC1vbmx5IGFzIHdlbGwsIGZv ciBnb2JqZWN0IGJpbmRpbmdzLiAgCisgICAgICAgICogZG9tL0RvY3VtZW50LmlkbDogTEFOR1VB R0VfR09CSkVDVCByZWFkLW9ubHkgYWNjZXNzIHRvIGxvY2F0aW9uCisgICAgICAgICogcGFnZS9M b2NhdGlvbi5pZGw6IExBTkdVQUdFX0dPQkpFQ1QgcmVhZC1vbmx5IGFjY2VzcyB0byBhbGwgcHJv cGVydGllcworCiAyMDA4LTEyLTA0ICBLZXZpbiBPbGxpdmllciAgPGtldmlub0B0aGVvbGxpdmll cnMuY29tPgogCiAgICAgICAgIHd4IGJ1aWxkIGZpeCBmb3IgIVVTRShXWEdDKSBidWlsZCBjb25m aWcuCkluZGV4OiBXZWJDb3JlL3BhZ2UvTG9jYXRpb24uaWRsCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNv cmUvcGFnZS9Mb2NhdGlvbi5pZGwJKHJldmlzaW9uIDQ0NDczKQorKysgV2ViQ29yZS9wYWdlL0xv Y2F0aW9uLmlkbAkod29ya2luZyBjb3B5KQpAQCAtNDAsMTMgKzQwLDI3IEBACiAgICAgICAgIEN1 c3RvbVByb3RvdHlwZVB1dEZ1bmN0aW9uLAogICAgICAgICBDdXN0b21Qcm90b3R5cGVEZWZpbmVH ZXR0ZXIKICAgICBdIExvY2F0aW9uIHsKKyNpZiBkZWZpbmVkKExBTkdVQUdFX0dPQkpFQ1QpICYm IExBTkdVQUdFX0dPQkpFQ1QKKyAgICAgICAgICAgICAgICAgcmVhZG9ubHkgYXR0cmlidXRlIFtE b05vdENoZWNrRG9tYWluU2VjdXJpdHlPblNldCwgQ3VzdG9tU2V0dGVyLCBWOERpc2FsbG93U2hh ZG93aW5nXSBET01TdHJpbmcgaHJlZjsKKyNlbHNlCiAgICAgICAgICAgICAgICAgIGF0dHJpYnV0 ZSBbRG9Ob3RDaGVja0RvbWFpblNlY3VyaXR5T25TZXQsIEN1c3RvbVNldHRlciwgVjhEaXNhbGxv d1NoYWRvd2luZ10gRE9NU3RyaW5nIGhyZWY7CisjZW5kaWYKIAogICAgICAgICBbQ3VzdG9tLCBW OE9uSW5zdGFuY2VdIHZvaWQgYXNzaWduKGluIERPTVN0cmluZyB1cmwpOwogICAgICAgICBbQ3Vz dG9tLCBWOE9uSW5zdGFuY2VdIHZvaWQgcmVwbGFjZShpbiBET01TdHJpbmcgdXJsKTsKICAgICAg ICAgW0N1c3RvbSwgVjhPbkluc3RhbmNlXSB2b2lkIHJlbG9hZCgpOwogCiAgICAgICAgIC8vIFVS SSBkZWNvbXBvc2l0aW9uIGF0dHJpYnV0ZXMKKyNpZiBkZWZpbmVkKExBTkdVQUdFX0dPQkpFQ1Qp ICYmIExBTkdVQUdFX0dPQkpFQ1QKKyAgICAgICAgICAgICAgICAgLy8gc2VlICMyNzQzNAorICAg ICAgICAgICAgICAgICByZWFkb25seSBhdHRyaWJ1dGUgW0N1c3RvbVNldHRlcl0gRE9NU3RyaW5n IHByb3RvY29sOworICAgICAgICAgICAgICAgICByZWFkb25seSBhdHRyaWJ1dGUgW0N1c3RvbVNl dHRlcl0gRE9NU3RyaW5nIGhvc3Q7CisgICAgICAgICAgICAgICAgIHJlYWRvbmx5IGF0dHJpYnV0 ZSBbQ3VzdG9tU2V0dGVyXSBET01TdHJpbmcgaG9zdG5hbWU7CisgICAgICAgICAgICAgICAgIHJl YWRvbmx5IGF0dHJpYnV0ZSBbQ3VzdG9tU2V0dGVyXSBET01TdHJpbmcgcG9ydDsKKyAgICAgICAg ICAgICAgICAgcmVhZG9ubHkgYXR0cmlidXRlIFtDdXN0b21TZXR0ZXJdIERPTVN0cmluZyBwYXRo bmFtZTsKKyAgICAgICAgICAgICAgICAgcmVhZG9ubHkgYXR0cmlidXRlIFtDdXN0b21TZXR0ZXJd IERPTVN0cmluZyBzZWFyY2g7CisgICAgICAgICAgICAgICAgIHJlYWRvbmx5IGF0dHJpYnV0ZSBb Q3VzdG9tU2V0dGVyXSBET01TdHJpbmcgaGFzaDsKKyNlbHNlCiAgICAgICAgICAgICAgICAgIGF0 dHJpYnV0ZSBbQ3VzdG9tU2V0dGVyXSBET01TdHJpbmcgcHJvdG9jb2w7CiAgICAgICAgICAgICAg ICAgIGF0dHJpYnV0ZSBbQ3VzdG9tU2V0dGVyXSBET01TdHJpbmcgaG9zdDsKICAgICAgICAgICAg ICAgICAgYXR0cmlidXRlIFtDdXN0b21TZXR0ZXJdIERPTVN0cmluZyBob3N0bmFtZTsKQEAgLTU0 LDYgKzY4LDcgQEAKICAgICAgICAgICAgICAgICAgYXR0cmlidXRlIFtDdXN0b21TZXR0ZXJdIERP TVN0cmluZyBwYXRobmFtZTsKICAgICAgICAgICAgICAgICAgYXR0cmlidXRlIFtDdXN0b21TZXR0 ZXJdIERPTVN0cmluZyBzZWFyY2g7CiAgICAgICAgICAgICAgICAgIGF0dHJpYnV0ZSBbQ3VzdG9t U2V0dGVyXSBET01TdHJpbmcgaGFzaDsKKyNlbmRpZgogCiAjaWYgZGVmaW5lZChMQU5HVUFHRV9K QVZBU0NSSVBUKSAmJiBMQU5HVUFHRV9KQVZBU0NSSVBUCiAgICAgICAgIFtEb250RW51bSwgQ3Vz dG9tLCBWOE9uSW5zdGFuY2UsIFY4UmVhZE9ubHldIERPTVN0cmluZyB0b1N0cmluZygpOwo=