27436 2009-07-19 16:08:07 -0700 gobject bindings need access to keyCode on KeyboardEvents! 2014-04-08 18:10:50 -0700 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) PC OS X 10.5 RESOLVED LATER P2 Normal --- 16401 0 lkcl webkit-unassigned ap eric mrobinson mrowe oldest_to_newest 133039 0 lkcl 2009-07-19 16:08:07 -0700 this is part of the split of #16401 into smaller patches as part of an agreement recommended by david. take this lightly, please, but whoever thought that you could do language bindings without having access to keyCodes ... honestly, it's just so daft! and, if there _are_ workarounds that get at the same information... honestly, why make developers' lives damn awkward. just publish the same consistent API and be done with it, for goodness sake! :) anyway: it can be seen from the IDL itself that the exposed initKeyboardEvent function doesn't match up with the W3C DOM spec, so any arguments made - and there have been several, by reviewers - that Webkit language bindings stick religiously to the W3C spec are moot. 133040 1 33065 lkcl 2009-07-19 16:10:44 -0700 Created attachment 33065 enables access to keyCode and charCode properties and W3C-compliant initKeyboardEvent function under gobject language bindings 133237 2 eric 2009-07-20 14:53:38 -0700 Please look back into the history of this line. I expect this was added to avoid Obj-C generation and shoudl be changed to !objc now. 133533 3 lkcl 2009-07-21 11:25:02 -0700 (In reply to comment #2) > Please look back into the history of this line. I expect this was added to > avoid Obj-C generation and shoudl be changed to !objc now. ack. same as #27437 then, basically. willdo. 133535 4 lkcl 2009-07-21 11:34:20 -0700 ah... looking at this a little closer, i believe that the reason why i commented out the initKeyboardEvent function on GOBJECT bindings would have been because you can't, in c, have two functions with the same name. and the gobject bindings auto-generator would have created two gdom_keyboard_event_init_keyboard_event() functions, because of the two initKeyboardEvent entries in the IDL file. so i simply #ifdef'd one of them out. stupidly, i actually managed to #ifdef out keyCode and charCode as well! so, duh, thank you for drawing my attention to this! anyway - i'll submit a revised patch which has !LANGUAGE_OBJC around keyCode and charCode.... errr... are you sure? i'll submit it for your attention, you let me know if it should be !LANGUAGE_OBJC or !LANGUAGE_JAVASCRIPT ok? 133539 5 33193 lkcl 2009-07-21 11:42:25 -0700 Created attachment 33193 comments out only the 2nd initKeyboardEvent function on LANGUAGE_GOBJECT probably a good idea to look at #27437 this likely needs discussion, i'm happy to submit necessary patches to keep Obj-C happy but don't have the expertise to say what is what, here - just let me know what needs to be done. i do know however that you can't have two versions of the same c function which is why one of the initKeyboardEvent functions _has_ to be #ifdef'd out. 135734 6 mrowe 2009-07-29 16:57:21 -0700 I think this ties in to the more general issue of how to handle overloaded methods in a C-based bindings. Perhaps we should decide on a more general solution to this problem rather than #if'ing throughout the IDLs. 136359 7 33193 eric 2009-07-31 20:08:12 -0700 Comment on attachment 33193 comments out only the 2nd initKeyboardEvent function on LANGUAGE_GOBJECT ChangeLog name: +2008-11-30 lkcl <lkcl@lkcl.net> Tabs in ChangeLog. I think Mark wanted a different solution for c bindings in general, but in this change looks fine overall to me. r- for the ChangeLog issues. 136594 8 lkcl 2009-08-03 01:02:56 -0700 (In reply to comment #7) > (From update of attachment 33193 [details]) > ChangeLog name: > +2008-11-30 lkcl <lkcl@lkcl.net> > > Tabs in ChangeLog. yes. sorry. found that out a bit late - have corrected most of them in the [15] patches submitted, must have missed this one. will redo. > I think Mark wanted a different solution for c bindings in general, in each instance where the discussion comes up, i mention that there is no issue. the current solution has been proven to work, and, because of the violation of the W3C DOM spec in this case (to very sensibly add support for Alt-Gr) this is pretty much the _only_ case where the [clashing] function needs to be #ifdef'd out. more details have been given in other bugreports [several times]. > but in this > change looks fine overall to me. great. > r- for the ChangeLog issues. will fix. 136595 9 33963 lkcl 2009-08-03 01:07:05 -0700 Created attachment 33963 fixes tabs in CHANGELOG, alters date from original patch creation date (2008) to current date 136644 10 33963 eric 2009-08-03 08:52:58 -0700 Comment on attachment 33963 fixes tabs in CHANGELOG, alters date from original patch creation date (2008) to current date Assuming Mark's concerns with this general approach were resolved (as you noted above), then this looks fine to me. 136711 11 mrowe 2009-08-03 10:50:21 -0700 As I've outlined in bug 27435, my concerns about the handling of overloaded methods have yet to be addressed. 136714 12 mrowe 2009-08-03 10:59:26 -0700 (In reply to comment #8) > > I think Mark wanted a different solution for c bindings in general, Yes, I'm after a more general solution than picking a single function and #if'ing the rest out. As I've mentioned in bug 27435, there are other situations in which this is necessary. Since a general solution would obviate the need for #if'ing in IDL files I would prefer to see it explored before we go landing changes that add #if's. 136726 13 33963 eric 2009-08-03 11:48:07 -0700 Comment on attachment 33963 fixes tabs in CHANGELOG, alters date from original patch creation date (2008) to current date r- per mark's above comments. 136728 14 eric 2009-08-03 11:53:58 -0700 I think you should try to enlist one of the longer-term WebKitGtk contributers to help you with these patches. You're hitting a lot of road-blocks at once. Much of that is likely due to uploading 15 "first time" patches at once. So you end up hitting similar combinations of starter-mistakes with each. In this case, Mark is asking for a re-architecture of how we do autogeneration. That's a little much to expect of a new contributer, but certainly possible. Especially if you engage other senior members of the project. In this case, it may be too much to ask, because our auto-gen system is a pile of ugly perl which several of us have wanted to re-write for years. Eventually one of us will get around to re-writting it in c++ or python. I think it would be a relatively easy change to add some sort of ALLOW_ARGUMENT_OVERLOADS or similar define which encapsulated !JAVASCRIPT and GOBJECT. That wouldn't involve re-writing the world, but it also wouldn't be poluting our IDL files more. 136735 15 mrowe 2009-08-03 12:10:33 -0700 (In reply to comment #14) > I think it would be a relatively easy change to add some sort of > ALLOW_ARGUMENT_OVERLOADS or similar define which encapsulated !JAVASCRIPT and > GOBJECT. That wouldn't involve re-writing the world, but it also wouldn't be > poluting our IDL files more. Except for the small issue that JavaScript DOM bindings support overloaded functions. 136738 16 eric 2009-08-03 12:22:11 -0700 (In reply to comment #15) > (In reply to comment #14) > > I think it would be a relatively easy change to add some sort of > > ALLOW_ARGUMENT_OVERLOADS or similar define which encapsulated !JAVASCRIPT and > > GOBJECT. That wouldn't involve re-writing the world, but it also wouldn't be > > poluting our IDL files more. > > Except for the small issue that JavaScript DOM bindings support overloaded > functions. Sounds like either I have the ! reversed in my example text above, or I'm misunderstanding the issue. Are you saying that it would not be good/possible/sufficient to replace the proposed !JAVASCRIPT && GOBJECT && ... with a single define? 136748 17 mrowe 2009-08-03 12:51:52 -0700 (In reply to comment #16) > Sounds like either I have the ! reversed in my example text above, or I'm > misunderstanding the issue. Are you saying that it would not be > good/possible/sufficient to replace the proposed !JAVASCRIPT && GOBJECT && ... > with a single define? In some places that overloading is used, such as XHR, the IDL contains a single version of the method that is annotated with [Custom] to indicate that a custom JS implementation of the binding for that method will be provided. That custom implementation typically introspects the arguments that were provided and dispatches to the appropriate method on the wrapped DOM object. In most cases, functions that are #if'd in the IDLs to exclude them from JavaScript are not done so for a reason related to overloading, so changing them to be wrapped by a define related to overloading would not be appropriate. In the case of initKeyboardEvent it's not clear why one variant is excluded from JavaScript. The variant without altGraph was added in <http://trac.webkit.org/changeset/16277/trunk/WebCore/dom/KeyboardEvent.idl> by Sam without much explanation. 136830 18 lkcl 2009-08-03 16:14:37 -0700 (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > I think it would be a relatively easy change to add some sort of > > > ALLOW_ARGUMENT_OVERLOADS or similar define which encapsulated !JAVASCRIPT and > > > GOBJECT. That wouldn't involve re-writing the world, but it also wouldn't be > > > poluting our IDL files more. > > > > Except for the small issue that JavaScript DOM bindings support overloaded > > functions. > > Sounds like either I have the ! reversed in my example text above, or I'm > misunderstanding the issue. Are you saying that it would not be > good/possible/sufficient to replace the proposed !JAVASCRIPT && GOBJECT && ... > with a single define? see https://bugs.webkit.org/show_bug.cgi?id=27435#c29 and previous. overloaded functions = same function with different numbers of arguments. think: "the usual c / c++ problem, basically". XULrunner have run into exactly the same problem: https://bug459452.bugzilla.mozilla.org/attachment.cgi?id=342670 https://bugzilla.mozilla.org/show_bug.cgi?id=502234 except there, the users have c++ as the native API, and the python bindings are direct to that. any mess-ups are due to implementation flaws (as can be seen from the above two bugs) and precedence given to javascript rather than any particularly good reason. MSHTML does two tricks: * adds rolling numbers onto the overloaded functions. burden is passed to users to work out which one to use. * and, also, i thiiink what they do is create different COM interfaces and then create a coclass merging them all together. IDispatch can cope with telling users about the interfaces and their functions (at run-time) and in this way, dynamic use of the MSHTML interface simply passes the burden onto the users. both of which are greeeaat. but. seriously. see https://bugs.webkit.org/show_bug.cgi?id=27435#c29 - the conclusion is that i don't believe it's that big a deal. even if what small API changes are required happen in 6 months or a year. 136835 19 lkcl 2009-08-03 16:32:31 -0700 (In reply to comment #14) > I think you should try to enlist one of the longer-term WebKitGtk contributers > to help you with these patches. *sigh*. sadly, they've all said "we'd love to, but we don't have time". please don't spend time reading any of the 300 comments in #16401, it won't help :) > You're hitting a lot of road-blocks at once. well, that's better than hitting one and only one, for eight months straight. > Much of that is likely due to uploading 15 "first time" patches at once. So > you end up hitting similar combinations of starter-mistakes with each. yep. caught lots of them. cancelled review on ones where i remember. > In this > case, Mark is asking for a re-architecture of how we do autogeneration. That's > a little much to expect of a new contributer, but certainly possible. *sssss*... i'm not the person to ask to do that. not on something that's at the core of the project. and, also, i think it would be a good idea to get the gobject bindings in, first, _before_ making any significant changes. in that way, all the bindings can be considered - and taken into consideration - all at once. if one of them is left out, then... > In this case, it may be too much to ask, because our auto-gen system is a pile > of ugly perl which several of us have wanted to re-write for years. i did as best i could a hybrid cut/paste job. > Eventually > one of us will get around to re-writting it in c++ or python. > > I think it would be a relatively easy change to add some sort of > ALLOW_ARGUMENT_OVERLOADS or similar define which encapsulated !JAVASCRIPT and > GOBJECT. That wouldn't involve re-writing the world, but it also wouldn't be > poluting our IDL files more. mmm.... can't give an opinion - bit tired, and also i don't quite follow [need context]. i can say however that the mozilla approach is to simply add extra IDL attributes, and they have a "no" prefix to indicate !. e.g. [noscript] means "exclude from both javascript and xpcom when generating bindings" which they freely admit is a broken idea. as you can see from this: https://bug459452.bugzilla.mozilla.org/attachment.cgi?id=342670 this is an attempt to fix the issue by adding an [optional_arg] IDL attribute, and then the number of arguments is inserted as an additional argument into the c++ code. i don't like it. and, as mentioned here: https://bugs.webkit.org/show_bug.cgi?id=27435#c29 i believe that this whole issue is moot, i.e. from a "practical" software engineering perspective, a whole boat-load of complexity could end up getting added for very little extra benefit / ROI. evidence to the contrary, i _do_ subscribe to the "good enough" software engineering principle - it's just that with webkit-gobject and pyjamas-desktop the bar's a bit damn high. 136838 20 lkcl 2009-08-03 16:41:57 -0700 (In reply to comment #12) > (In reply to comment #8) > > > I think Mark wanted a different solution for c bindings in general, > > Yes, I'm after a more general solution than picking a single function and > #if'ing the rest out. As I've mentioned in bug 27435, there are other > situations in which this is necessary. [answered there] > Since a general solution would obviate > the need for #if'ing in IDL files I would prefer to see it explored before we > go landing changes that add #if's. * a general solution would require across-the-board changes [to CodeGenerator.pm], including to CodeGeneratorGObject.pm. if they're willing to do that. * that means that someone would need to look at code that's in webkit svn _and_ code that's not. if they're willing to do that. * it could be months before an updated solution is discussed and ready [if in fact one is needed at all - see #27435 answer] on balance, therefore, i would consider it a wiser move to tolerate #ifdefs, warts and all, land the CodeGeneratorGObject and _then_ look at all of the CodeGenerators all at once. if it's _really_ a problem to have an "un-finalised" c-based gobject API out there, then there are plenty of ways to stop people from using it whilst matters are discussed, whilst also not impeding people who are willing to use what's there, regardless. putting in a #ifdef DO_NOT_USE_GOBJECT_API_ONLY_AT_OWN_RISK_NOT_FINALISED_YET is the most obvious one. 998958 21 mrobinson 2014-04-08 18:10:50 -0700 This isn't going to happen now, but maybe we can think about it when we rework the GObject DOM bindings. 33065 2009-07-19 16:10:44 -0700 2009-07-21 11:42:25 -0700 enables access to keyCode and charCode properties and W3C-compliant initKeyboardEvent function under gobject language bindings kbe.idl.patch text/plain 1211 lkcl SW5kZXg6IFdlYkNvcmUvZG9tL0tleWJvYXJkRXZlbnQuaWRsCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNv cmUvZG9tL0tleWJvYXJkRXZlbnQuaWRsCShyZXZpc2lvbiA0NDQ3MykKKysrIFdlYkNvcmUvZG9t L0tleWJvYXJkRXZlbnQuaWRsCSh3b3JraW5nIGNvcHkpCkBAIC01OSw3ICs1OSw4IEBACiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gYm9vbGVhbiBhbHRHcmFwaEtleSk7CiAKICAg ICAgICAgLy8gV2ViS2l0IEV4dGVuc2lvbnMKLSNpZiAhZGVmaW5lZChMQU5HVUFHRV9KQVZBU0NS SVBUKSB8fCAhTEFOR1VBR0VfSkFWQVNDUklQVAorI2lmICghZGVmaW5lZChMQU5HVUFHRV9KQVZB U0NSSVBUKSB8fCAhTEFOR1VBR0VfSkFWQVNDUklQVCkgJiYgXAorICAgICAoIWRlZmluZWQoTEFO R1VBR0VfR09CSkVDVCkgfHwgIUxBTkdVQUdFX0dPQkpFQ1QpCiAgICAgICAgIHJlYWRvbmx5IGF0 dHJpYnV0ZSBsb25nICAgICAgICAgICAgIGtleUNvZGU7CiAgICAgICAgIHJlYWRvbmx5IGF0dHJp YnV0ZSBsb25nICAgICAgICAgICAgIGNoYXJDb2RlOwogICAgICAgICAKSW5kZXg6IFdlYkNvcmUv Q2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9nCShyZXZpc2lvbiA0NDQ3 MykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC02MjM1MCw2ICs2MjM1 OCwxNCBAQAogICAgICAgICAqIHBsYXRmb3JtL3RleHQvVGV4dENvZGVjSUNVLmNwcDoKICAgICAg ICAgKFdlYkNvcmU6OlRleHRDb2RlY0lDVTo6cmVnaXN0ZXJFeHRlbmRlZEVuY29kaW5nTmFtZXMp OgogCisyMDA4LTExLTMwICBsa2NsIDxsa2NsQGxrY2wubmV0PgorCisgICAgICAgIFJldmlld2Vk IGJ5IE5PQk9EWSAoT09QUyEpCisKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hv d19idWcuY2dpP2lkPTI3NDM2CisKKyAgICAgICAgKiBkb20vS2V5Ym9hcmRFdmVudC5pZGw6IGFk ZGVkIExBTkdVQUdFX0dPQkpFQ1Qtc3BlY2lmaWMgSURMCisKIDIwMDgtMTItMDQgIEtldmluIFdh dHRlcnMgIDxrZXZpbndhdHRlcnNAZ21haWwuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IEtl dmluIE9sbGl2aWVyLgo= 33193 2009-07-21 11:42:25 -0700 2009-08-03 01:07:05 -0700 comments out only the 2nd initKeyboardEvent function on LANGUAGE_GOBJECT kbe.idl.patch text/plain 1493 lkcl SW5kZXg6IFdlYkNvcmUvZG9tL0tleWJvYXJkRXZlbnQuaWRsCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNv cmUvZG9tL0tleWJvYXJkRXZlbnQuaWRsCShyZXZpc2lvbiA0NDQ3MykKKysrIFdlYkNvcmUvZG9t L0tleWJvYXJkRXZlbnQuaWRsCSh3b3JraW5nIGNvcHkpCkBAIC02Miw3ICs2MiwxMSBAQAogI2lm ICFkZWZpbmVkKExBTkdVQUdFX0pBVkFTQ1JJUFQpIHx8ICFMQU5HVUFHRV9KQVZBU0NSSVBUCiAg ICAgICAgIHJlYWRvbmx5IGF0dHJpYnV0ZSBsb25nICAgICAgICAgICAgIGtleUNvZGU7CiAgICAg ICAgIHJlYWRvbmx5IGF0dHJpYnV0ZSBsb25nICAgICAgICAgICAgIGNoYXJDb2RlOworI2VuZGlm CiAgICAgICAgIAorI2lmICghZGVmaW5lZChMQU5HVUFHRV9KQVZBU0NSSVBUKSB8fCAhTEFOR1VB R0VfSkFWQVNDUklQVCkgJiYgXAorICAgICAoIWRlZmluZWQoTEFOR1VBR0VfR09CSkVDVCkgfHwg IUxBTkdVQUdFX0dPQkpFQ1QpCisgICAgICAgIAogICAgICAgICB2b2lkIGluaXRLZXlib2FyZEV2 ZW50KGluIERPTVN0cmluZyB0eXBlLCAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp biBib29sZWFuIGNhbkJ1YmJsZSwgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4g Ym9vbGVhbiBjYW5jZWxhYmxlLCAKSW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIFdlYkNvcmUvQ2hhbmdlTG9nCShyZXZpc2lvbiA0NDQ3MykKKysrIFdlYkNvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC02MjM1MCw2ICs2MjM3MywxOCBAQAogICAgICAgICAqIHBs YXRmb3JtL3RleHQvVGV4dENvZGVjSUNVLmNwcDoKICAgICAgICAgKFdlYkNvcmU6OlRleHRDb2Rl Y0lDVTo6cmVnaXN0ZXJFeHRlbmRlZEVuY29kaW5nTmFtZXMpOgogCisyMDA4LTExLTMwICBsa2Ns IDxsa2NsQGxrY2wubmV0PgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpCisK KyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTI3NDM2CisK KwkJR09iamVjdCBiaW5kaW5ncyBhcmUgYy1iYXNlZDogeW91IGNhbm5vdCBoYXZlIHR3byBjIGZ1 bmN0aW9ucworCQlnZG9tX2tleWJvYXJkX2V2ZW50X2luaXRfa2V5Ym9hcmRfZXZlbnQsIHNvIG9u ZSBvZiB0aGVtIGlzCisJCWRpc2FibGVkIChhcyBpdCBpcyBvbiB0aGUgSlMgYmluZGluZ3MgYXMg d2VsbCwgYWxyZWFkeSkuCisKKyAgICAgICAgKiBkb20vS2V5Ym9hcmRFdmVudC5pZGw6IGFkZGVk IExBTkdVQUdFX0dPQkpFQ1Qtc3BlY2lmaWMgSURMCisKIDIwMDgtMTItMDQgIEtldmluIFdhdHRl cnMgIDxrZXZpbndhdHRlcnNAZ21haWwuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IEtldmlu IE9sbGl2aWVyLgo= 33963 2009-08-03 01:07:05 -0700 2010-06-10 17:57:09 -0700 fixes tabs in CHANGELOG, alters date from original patch creation date (2008) to current date kbe.idl.patch text/plain 1526 lkcl SW5kZXg6IFdlYkNvcmUvZG9tL0tleWJvYXJkRXZlbnQuaWRsCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNv cmUvZG9tL0tleWJvYXJkRXZlbnQuaWRsCShyZXZpc2lvbiA0NjM5NSkKKysrIFdlYkNvcmUvZG9t L0tleWJvYXJkRXZlbnQuaWRsCSh3b3JraW5nIGNvcHkpCkBAIC02Miw3ICs2MiwxMSBAQAogI2lm ICFkZWZpbmVkKExBTkdVQUdFX0pBVkFTQ1JJUFQpIHx8ICFMQU5HVUFHRV9KQVZBU0NSSVBUCiAg ICAgICAgIHJlYWRvbmx5IGF0dHJpYnV0ZSBsb25nICAgICAgICAgICAgIGtleUNvZGU7CiAgICAg ICAgIHJlYWRvbmx5IGF0dHJpYnV0ZSBsb25nICAgICAgICAgICAgIGNoYXJDb2RlOworI2VuZGlm CiAgICAgICAgIAorI2lmICghZGVmaW5lZChMQU5HVUFHRV9KQVZBU0NSSVBUKSB8fCAhTEFOR1VB R0VfSkFWQVNDUklQVCkgJiYgXAorICAgICAoIWRlZmluZWQoTEFOR1VBR0VfR09CSkVDVCkgfHwg IUxBTkdVQUdFX0dPQkpFQ1QpCisgICAgICAgIAogICAgICAgICB2b2lkIGluaXRLZXlib2FyZEV2 ZW50KGluIERPTVN0cmluZyB0eXBlLCAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp biBib29sZWFuIGNhbkJ1YmJsZSwgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4g Ym9vbGVhbiBjYW5jZWxhYmxlLCAKSW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIFdlYkNvcmUvQ2hhbmdlTG9nCShyZXZpc2lvbiA0NjM5MykKKysrIFdlYkNvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xNzM3NSw2ICsxNzQwOSwxOCBAQAogICAgICAgICAgIGhh bmRsaW5nIGluIFdvcmtlciBjb25zdHJ1Y3RvciBmb3IgVjggYmluZGluZ3MuCiAgICAgICAgIChX ZWJDb3JlOjpDQUxMQkFDS19GVU5DX0RFQ0wpOgogCisyMDA5LTA4LTAzICBMdWtlIEtlbm5ldGgg Q2Fzc29uIExlaWdodG9uIDxsa2NsQGxrY2wubmV0PgorCisgICAgICAgIFJldmlld2VkIGJ5IE5P Qk9EWSAoT09QUyEpCisKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTI3NDM2CisKKyAgICAgICAgR09iamVjdCBiaW5kaW5ncyBhcmUgYy1iYXNlZDogeW91 IGNhbm5vdCBoYXZlIHR3byBjIGZ1bmN0aW9ucworICAgICAgICBnZG9tX2tleWJvYXJkX2V2ZW50 X2luaXRfa2V5Ym9hcmRfZXZlbnQsIHNvIG9uZSBvZiB0aGVtIGlzCisgICAgICAgIGRpc2FibGVk IChhcyBpdCBpcyBvbiB0aGUgSlMgYmluZGluZ3MgYXMgd2VsbCwgYWxyZWFkeSkuCisKKyAgICAg ICAgKiBkb20vS2V5Ym9hcmRFdmVudC5pZGw6IGFkZGVkIExBTkdVQUdFX0dPQkpFQ1Qtc3BlY2lm aWMgSURMCisKIDIwMDktMDYtMTYgIEJyZW50IEZ1bGdoYW0gIDxiZnVsZ2hhbUB3ZWJraXQub3Jn PgogCiAgICAgICAgIFJldmlld2VkIGJ5IE1hY2llaiBTdGFjaG93aWFrLgo=