Re: [webkit-dev] Can't upload patch
Instead of piping the output of git show, I'd use git format-patch -1 This will generate a patch file for the topmost commit of your current branch. Cheers, Konrad From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of jpe...@gmx.at [jpe...@gmx.at] Sent: Thursday, January 17, 2013 3:43 PM To: Raymond Toy Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Can't upload patch ... valid *diff* file. Damn you autocorrect! From: jpe...@gmx.at Sent: Thursday, January 17, 2013 3:42 PM To: Raymond Toy Cc: webkit-d e...@lists.webkit.org Subject: Re: [webkit-dev] Can't upload patch Note that git show produces a valid different file, extra commit message notwithstanding. (The commit message is part of the header and will be ignored when used with diff and related tools.) If you have your commit, plus the ChangeLog changes mer ged into the same commit, you can just pipe the output of git show to a file and attach that to your bug manually instead. For the bots and the review machinery, the patch should be the same as if you had uploaded it through webkit-patch. You'll only miss out on a few sanity checks that webkit-patch performs before uploading, and the raw file will look slightly differently. Cheers, Jakob From: Raymond Toy Sent: Thursday, January 17, 2013 1:49 PM To: Adam Barth Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Can't upload patch Hmm. I have a git checkout of webkit so svn-create-patch doesn't want to work. Yeah, the patch is probably too big. The particular patch could be broken up into 3-4 separate smaller patches. Perhaps that will work. On Thu, Jan 17, 2013 at 9:52 AM, Adam Barth aba...@webkit.orgmailto:aba...@webkit.org wrote: Have you tried uploading the patch manually by running svn-create-patch and using the attachments UI in bugs.webkit.orghttp://bugs.webkit.org? One possibility is that your patch is too big for bugs.webkit.orghttp://bugs.webkit.org to handle. You mention that it contains a number of binary files, which might be the cause of the problem. Adam On Thu, Jan 17, 2013 at 9:43 AM, Raymond Toy r...@google.commailto:r...@google.com wrote: I'm trying to upload a patch and webkit-patch upload appears to do everything except actually add the patch to the bug. I first ran webkit-patch upload and it correctly created the bug (https://bugs.webkit.org/show_bug.cgi?id=106955) for me, but didn't upload the patch. When I run webkit-patch upload again, it correctly shows the diff, which consists of a a change to TestExpectations and several binary files. It says it adding the patch, but when I look at the bug, there's no patch. I'm missing something, but I don't know what it is. I've uploaded patches before, so I know it used to work. :-( Any suggestions? Ray ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can't upload patch
You could have kept your commits separate and generated a patch for each. The parameter for format-patch is the number of commits for which to generate patches. -Konrad Sent from my BlackBerry smartphone. From: Raymond Toy Sent: Thursday, January 17, 2013 6:00 PM To: Konrad Piascik Cc: jpe...@gmx.at; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Can't upload patch On Thu, Jan 17, 2013 at 1:17 PM, Konrad Piascik kpias...@rim.commailto:kpias...@rim.com wrote: Instead of piping the output of git show, I'd use git format-patch -1 This will generate a patch file for the topmost commit of your current branch. Thanks! That does the trick. I wasn't sure if the patches for the multiple commits would work if I concatenated them into one, so I just squashed my commits. It turns out that the patch was 2.16 MB, just over the limit. Ray Cheers, Konrad From: webkit-dev-boun...@lists.webkit.orgmailto:webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.orgmailto:webkit-dev-boun...@lists.webkit.org] on behalf of jpe...@gmx.atmailto:jpe...@gmx.at [jpe...@gmx.atmailto:jpe...@gmx.at] Sent: Thursday, January 17, 2013 3:43 PM To: Raymond Toy Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Can't upload patch ... valid *diff* file. Damn you autocorrect! From: jpe...@gmx.atmailto:jpe...@gmx.at Sent: Thursday, January 17, 2013 3:42 PM To: Raymond Toy Cc: webkit-d e...@lists.webkit.orgmailto:e...@lists.webkit.org Subject: Re: [webkit-dev] Can't upload patch Note that git show produces a valid different file, extra commit message notwithstanding. (The commit message is part of the header and will be ignored when used with diff and related tools.) If you have your commit, plus the ChangeLog changes mer ged into the same commit, you can just pipe the output of git show to a file and attach that to your bug manually instead. For the bots and the review machinery, the patch should be the same as if you had uploaded it through webkit-patch. You'll only miss out on a few sanity checks that webkit-patch performs before uploading, and the raw file will look slightly differently. Cheers, Jakob From: Raymond Toy Sent: Thursday, January 17, 2013 1:49 PM To: Adam Barth Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Can't upload patch Hmm. I have a git checkout of webkit so svn-create-patch doesn't want to work. Yeah, the patch is probably too big. The particular patch could be broken up into 3-4 separate smaller patches. Perhaps that will work. On Thu, Jan 17, 2013 at 9:52 AM, Adam Barth aba...@webkit.orgmailto:aba...@webkit.orgmailto:aba...@webkit.orgmailto:aba...@webkit.org wrote: Have you tried uploading the patch manually by running svn-create-patch and using the attachments UI in bugs.webkit.orghttp://bugs.webkit.orghttp://bugs.webkit.org? One possibility is that your patch is too big for bugs.webkit.orghttp://bugs.webkit.orghttp://bugs.webkit.org to handle. You mention that it contains a number of binary files, which might be the cause of the problem. Adam On Thu, Jan 17, 2013 at 9:43 AM, Raymond Toy r...@google.commailto:r...@google.commailto:r...@google.commailto:r...@google.com wrote: I'm trying to upload a patch and webkit-patch upload appears to do everything except actually add the patch to the bug. I first ran webkit-patch upload and it correctly created the bug (https://bugs.webkit.org/show_bug.cgi?id=106955) for me, but didn't upload the patch. When I run webkit-patch upload again, it correctly shows the diff, which consists of a a change to TestExpectations and several binary files. It says it adding the patch, but when I look at the bug, there's no patch. I'm missing something, but I don't know what it is. I've uploaded patches before, so I know it used to work. :-( Any suggestions? Ray ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
It's down in Waterloo, ON as well, so I guess it's just down :( Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Shawn Singh [mailto:shawnsi...@chromium.org] Sent: Tuesday, August 07, 2012 12:27 PM To: Osztrogonac Csaba o...@inf.u-szeged.hu Cc: WebKit Development webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] bugs.webkit.org and trac.webkit org down? It also seems to be down for me here in Mountain View, CA USA, right next to Apple... On Tue, Aug 7, 2012 at 9:20 AM, Osztrogonac Csaba o...@inf.u-szeged.humailto:o...@inf.u-szeged.hu wrote: Hi, It seems bugs.webkit.orghttp://bugs.webkit.org and trac.webkit.orghttp://trac.webkit.org is unavailable now. (at least from Hungary) Have you got any idea what happened? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] C++ unit tests for WebKit?
Don't we have gunit tests in Tools/TestWebKitAPI already? From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Hans Muller [hmul...@adobe.com] Sent: Wednesday, July 11, 2012 5:23 PM To: webkit-dev Subject: [webkit-dev] C++ unit tests for WebKit? Bear Travis, Alexandru Chiculita, and I have been working on the WebKit CSS Exclusions implementation. I've been working on a set of C++ classes that are used to compute the layout of inline content around or within exclusion shapes. When I got started, before attempting to integrate the code with WebKit, I wrote a pile of unit tests. This was helpful for the usual reasons but there doesn't appear to be a place for low level unit tests in WebKit. Naturally what I've done will be tested in terms of the Exclusions public JavaScript and CSS APIs, so adding lower level unit tests will not drastically change our confidence about the overall feature working correctly. On the other hand, unit tests can be useful for isolating problems and for implicitly specifying interface semantics that wouldn't otherwise be documented. Have the merits of C++ unit tests been debated before? I noticed that a bug representing as much has been around since 2008 (https://bugs.webkit.org/show_bug.cgi?id=21010). The last comment (2009) concludes with: I'd be interested to hear other's thoughts. Personally, I'd like to be able to include unit tests with worthy C++ classes, however I would also like to hear other's thoughts. Thanks, - Hans - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please include function-level comments in change log entries
I find that the function level comments, while potentially more time consuming to create are more beneficial than the comments at the top. It makes it not only easier to review but for also when going through the history and trying to see what changes were made. About iterations of the changelog during review updating the log at the top or at the function level (once the comments are already in place) should be an equivalent amount of time, at least in my experience. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Dana Jansens [mailto:dan...@chromium.org] Sent: Friday, July 06, 2012 02:42 PM To: Dan Bernstein m...@apple.com Cc: WebKit Development webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Please include function-level comments in change log entries On Fri, Jul 6, 2012 at 1:05 PM, Dan Bernstein m...@apple.commailto:m...@apple.com wrote: It appears that lately most WebCore change log entires don’t include any comments on individual functions. An overall description of the change at the top of the change log entry is valuable, but it is no substitute for describing the changes to each function. Good function-level comments are useful both while reviewing a patch and while revisiting existing code. Personally, I find that writing the function-level comments helps me a lot in reviewing my own patches before I post them. I find that the overhead of maintaining comments outside of the top of the changelog is excessive. Every time I change a patch in a non-trivial way during the review process, I must regenerate the changelogs. Copy/paste/edit the description at the top is not unreasonable. Hand-merging my old changelog with the new one for each method becomes an egregious amount of work. And I don't see how it helps review more than a proper description at the top that mentions the methods of interest as appropriate. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Web Inspector files
Hi, I'm trying to combine all the web inspector resources CSS, JS HTML into as few files as possible. I know that there are scripts in Source/WebCore/inspector but I'm not sure which ones should be used and some don't contain usage information. Also there's both combine-front-end.py and combine-front-end.sh iirc the shell script is to be deprecated in favour of python. Do any of these or other scripts use the closure compiler to even further compress or optimize the JavaScript? Thanks in advance, Konrad Sent from my BlackBerry on the Rogers Wireless Network - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Inspector files
We're already using a homegrown script that does what you mention in PlatformBlackBerry.cmake lines 194-214 but wanted to switch to something that was maintained by the community. I'll look at the gyp/gypi files for more info. Thanks, Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Pavel Feldman [mailto:pfeld...@chromium.org] Sent: Friday, June 08, 2012 07:59 AM To: Konrad Piascik Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web Inspector files [From chromium.orghttp://chromium.org] We throw away closure compiler output and use compilation step for type checking only. The best way to learn what files you should combine and bundle is via looking at WebCore.gyp(i) and WebKit.gyp(i). You basically need what is listed in inspector.html (these you can concatenate) + a bunch of standalone CSS files that are lazily loaded + a couple of web worker scripts. Regards Pavel On Jun 8, 2012 12:54 PM, Konrad Piascik kpias...@rim.commailto:kpias...@rim.com wrote: Hi, I'm trying to combine all the web inspector resources CSS, JS HTML into as few files as possible. I know that there are scripts in Source/WebCore/inspector but I'm not sure which ones should be used and some don't contain usage information. Also there's both combine-front-end.py and combine-front-end.sh iirc the shell script is to be deprecated in favour of python. Do any of these or other scripts use the closure compiler to even further compress or optimize the JavaScript? Thanks in advance, Konrad Sent from my BlackBerry on the Rogers Wireless Network - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing target-densitydpi (was Re: Device and page scaling)
it would still be useful for ports to set their own target density. I know currently 160 is what the auto value is and all content is scaled to this DPI it would be nice to have the option to not scale content, even if it is for just the embedder to decide. We want this on BlackBerry, and I'm sure that there are others who may find this useful. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Adam Barth [mailto:aba...@webkit.org] Sent: Friday, June 01, 2012 01:54 PM To: Konrad Piascik Cc: Maciej Stachowiak m...@apple.com; kenn...@webkit.org kenn...@webkit.org; webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Removing target-densitydpi (was Re: [webkit-dev] Device and page scaling) I think folks agree that these are important use cases. The disagreement is about how to address them. For example, another approach is to use responsive images (e.g., srcset and image-set) together with device units in CSS. Now that WebKit has support for subpixel layout, we can provide a high quality implementation of these features. By contrast, target-densitydpi does not have broad support from implementors, and there are concerns about the quality of the current implementation and its maintainability. Adam On Fri, Jun 1, 2012 at 9:15 AM, Konrad Piascik kpias...@rim.com wrote: Reposting comment from Bug 88047 After discussing this internally we believe that while the current implementation of target-densitydpi is not ideal it's ability to allow you scale your viewport to a given target density as well as to allow you to not scale (deviceDPI) are both desired features of this API that we'd like to have available to developers. This is useful for 2 cases: 1) automatically scaling content to the AutoValue (ie 160) DPI, which is what most mobile optimized sites do 2) allowing the user to have pixel perfect rendering on a given device. -Konrad From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Adam Barth [aba...@webkit.org] Sent: Friday, June 01, 2012 2:21 AM To: Maciej Stachowiak Cc: kenn...@webkit.org; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Device and page scaling I've posted a patch to remove target-densitydpi: https://bugs.webkit.org/show_bug.cgi?id=88047 There's some concern that target-densitydpi is used by some apps that are bundled with Android, but folks appear willing to deprecate the feature and to migrate those apps to using other mechanisms, such as responsive images and CSS device units. Once that patch lands, I'll start to unwind the complexity introduced by the feature. Thanks, Adam - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Device and page scaling
Reposting comment from Bug 88047 After discussing this internally we believe that while the current implementation of target-densitydpi is not ideal it's ability to allow you scale your viewport to a given target density as well as to allow you to not scale (deviceDPI) are both desired features of this API that we'd like to have available to developers. This is useful for 2 cases: 1) automatically scaling content to the AutoValue (ie 160) DPI, which is what most mobile optimized sites do 2) allowing the user to have pixel perfect rendering on a given device. -Konrad From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Adam Barth [aba...@webkit.org] Sent: Friday, June 01, 2012 2:21 AM To: Maciej Stachowiak Cc: kenn...@webkit.org; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Device and page scaling I've posted a patch to remove target-densitydpi: https://bugs.webkit.org/show_bug.cgi?id=88047 There's some concern that target-densitydpi is used by some apps that are bundled with Android, but folks appear willing to deprecate the feature and to migrate those apps to using other mechanisms, such as responsive images and CSS device units. Once that patch lands, I'll start to unwind the complexity introduced by the feature. Thanks, Adam On Wed, May 30, 2012 at 7:57 PM, Maciej Stachowiak m...@apple.com wrote: On May 30, 2012, at 4:24 PM, John Mellor joh...@chromium.org wrote: Maciej Stachowiak wrote: Can you explain why the target-densitydpi feature even exists? It seems ill-conceived to me, and the most straightforward fix would be to remove it. I have not heard anyone explain the use case for it. (I'm also not clear on the details of what it actually does, and neither the name nor the docs are enlightening.) Designers who insist on pixel-perfect rendering can use width=device-width, target-densityDpi=device-dpi to make their site render at one CSS pixel per screen pixel, letting you get crisp non-scaled borders etc. It does however require the designer to manually adjust dimensions and font-sizes to compensate for the dpi using window.devicePixelRatio, which is incredibly onerous (especially in a cross-platform design, which must look the same on devices that don't support target-densityDpi, hence everything needs to be implemented twice). That's the main use case, though it's pretty niche (if you want pixel-perfect UI, it's generally less hassle to just use high resolution images and scale them down). The other values I don't know of any compelling use cases for; I'll talk to the engineer who first added this and see if they have any good ones. It seems to me that you could better address this use case by supporting fractional CSS pixels, which hopefully our new subpixel layout code can enable. The tricky thing about target-densityDpi=device-dpi is that it forces you to sniff the device pixel ratio and change pretty much all your layout based on it. If historically it would actually alter what is reported for devicePixelRatio, then it would be pretty hard to make a site design that looks right on both 1x and 2x devices with target-densityDpi=device-dpi. So I'm skeptical that anyone has made good use of it. I don't know whether or not we can remove it (would need to check how popular it is), but it might be possible to deprecate it (recommend against using it). That's probably something we should discuss on www-style rather than here. I guess that would be the right place to discuss dropping it from the spec, but it seems like here is the right place to discuss dropping it from the implementation. From comments in the CSS Device Adaptation spec, it seems like it was only added because it was in Android. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Device and page scaling
How will these changes affect window.devicePixelRatio and the associated media queries? Will they still key off of Page::deviceScaleFactor? Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Adam Barth [mailto:aba...@webkit.org] Sent: Tuesday, May 29, 2012 10:10 PM To: Fady Samuel fsam...@chromium.org Cc: kenn...@webkit.org kenn...@webkit.org; webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Device and page scaling On Tue, May 29, 2012 at 7:03 PM, Fady Samuel fsam...@chromium.org wrote: This sounds good to me, but is there any reason why we can't support physical device changes (switching monitors) and support target-densitydpi? This would be highly desirable for us. We can support that. We just need to decide how to change the effective device scale factor when the actual device scale factor changes. Adam == Page::effectiveDeviceScaleFactor == Page::effectiveDeviceScaleFactor starts off as matching Page::deviceScaleFactor but changes to reflect any target-densitydpi directives. It's unclear to me how Page::effectiveDeviceScaleFactor should react when the underlying physical device changes its scaling factor. Currently, that shouldn't occur, so I'm inclined to add an ASSERT and worry about it later. == Settings::defaultDeviceScaleFactor == This variable will be deleted. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] win-ews linker error
I'm writing a patch for inspector that is giving me a linker error that I'm not able to track down since I don't have a windows build setup. Bug: https://bugs.webkit.org/show_bug.cgi?id=83282 This is the build output from win-ews. http://queues.webkit.org/results/12476169 Inline for convenience: 12WebCore.lib(InspectorInstrumentation.obj) : error LNK2001: unresolved external symbol public: void __thiscall WebCore::InspectorResourceAgent::didReceiveWebSocketFrame(unsigned long,class WebCore::WebSocketFrame const ) (?didReceiveWebSocketFrame@InspectorResourceAgent@WebCore@@QAEXKABVWebSocketFrame@2@@Z) 12WebCore.lib(InspectorInstrumentation.obj) : error LNK2001: unresolved external symbol public: void __thiscall WebCore::InspectorResourceAgent::didSendWebSocketFrame(unsigned long,class WebCore::WebSocketFrame const ) (?didSendWebSocketFrame@InspectorResourceAgent@WebCore@@QAEXKABVWebSocketFrame@2@@Z) 12WebCore.lib(WebSocketChannel.obj) : error LNK2001: unresolved external symbol private: static void __cdecl WebCore::InspectorInstrumentation::didReceiveWebSocketFrameImpl(class WebCore::InstrumentingAgents *,unsigned long,struct WebCore::WebSocketFrame const ) (?didReceiveWebSocketFrameImpl@InspectorInstrumentation@WebCore@@CAXPAVInstrumentingAgents@2@KABUWebSocketFrame@2@@Z) 12WebCore.lib(WebSocketChannel.obj) : error LNK2001: unresolved external symbol private: static void __cdecl WebCore::InspectorInstrumentation::didSendWebSocketFrameImpl(class WebCore::InstrumentingAgents *,unsigned long,struct WebCore::WebSocketFrame const ) (?didSendWebSocketFrameImpl@InspectorInstrumentation@WebCore@@CAXPAVInstrumentingAgents@2@KABUWebSocketFrame@2@@Z) I can't find where the symbols for WebSocketHandshakeRequest and WebSocketHandshakeResponse are exported because WebSocketFrame would need something similar. Thanks in advance, Konrad - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging inspector injected scripts
Hi Vivek, You can use the inspector to inspect itself. I've done this on chrome many times using the keyboard shortcut ctrl+shift+c (win linux) or command+shift+c (mac). In order for the keyboard shortcut to work you need to have the inspector undocked and the focus of the inspector be on the panel icons. Hope this helps you achieve what you're looking to do. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Vivek Galatage [mailto:vivekgalat...@gmail.com] Sent: Thursday, March 29, 2012 07:23 AM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: [webkit-dev] Debugging inspector injected scripts Hello webkit-dev, I would like to debug the various scripts those are injected by inspector component. Lets say I load a page from xyz.comhttp://xyz.com which has some script named xyz.js.. I am able to put breakpoints in this xyz.js and do the normal debugging. But what I am interested in is debugging the inspector injected scripts such as ResorucePanel.js etc by putting breakpoints. But whenever I try to do this, the inspector becomes non-responsive and I have to come out of the debug session by closing the browser. This I am experimenting on Windows port. So am I doing something wrong or is there any other method to achieve this? Any help? Thank you, Vivek - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging inspector injected scripts
Ok, well I was only able to do this on chrome. I have heard of issues with Qt and debugging the inspector. The possible reason for your inability to debug may be their sub event loop. Can any Qt developers comment? Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Vivek Galatage [mailto:vivekgalat...@gmail.com] Sent: Thursday, March 29, 2012 08:32 AM To: Konrad Piascik Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Debugging inspector injected scripts Hi Konrad, Thank you for your reply. Yes as you pointed out, I have tried this but was unable to do any live debugging of the javascript from inspector( such as ResourcesPanel.js etc ). I am able to inspect the inspector but debugging the script is what I am looking forward to.. I am working on webkit trunk revision 112378 on Qt port on ubuntu 11.10 as well as on Windows port. Thank you, Vivek On Thu, Mar 29, 2012 at 5:40 PM, Konrad Piascik kpias...@rim.commailto:kpias...@rim.com wrote: Hi Vivek, You can use the inspector to inspect itself. I've done this on chrome many times using the keyboard shortcut ctrl+shift+c (win linux) or command+shift+c (mac). In order for the keyboard shortcut to work you need to have the inspector undocked and the focus of the inspector be on the panel icons. Hope this helps you achieve what you're looking to do. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Vivek Galatage [mailto:vivekgalat...@gmail.commailto:vivekgalat...@gmail.com] Sent: Thursday, March 29, 2012 07:23 AM To: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: [webkit-dev] Debugging inspector injected scripts Hello webkit-dev, I would like to debug the various scripts those are injected by inspector component. Lets say I load a page from xyz.comhttp://xyz.com which has some script named xyz.js.. I am able to put breakpoints in this xyz.js and do the normal debugging. But what I am interested in is debugging the inspector injected scripts such as ResorucePanel.js etc by putting breakpoints. But whenever I try to do this, the inspector becomes non-responsive and I have to come out of the debug session by closing the browser. This I am experimenting on Windows port. So am I doing something wrong or is there any other method to achieve this? Any help? Thank you, Vivek - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ChangeLogs
There are some changes which have bug descriptions which are complete enough to not need additional comments and any changes to existing scripts should keep this in mind. One way to do this is to check for the number of lines/files the diff has. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Timothy Hatcher [mailto:timo...@apple.com] Sent: Wednesday, March 21, 2012 05:29 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: [webkit-dev] ChangeLogs Lately I have observed morehttp://trac.webkit.org/changeset/111595 and morehttp://trac.webkit.org/changeset/111577 and morehttp://trac.webkit.org/changeset/111527 changes going into WebKit that lack any details about why a particular change was made. It is intended that the ChangeLog (and commit message) contain some details about your change, not just the bug title and URL. The contributing informationhttp://www.webkit.org/coding/contributing.html#changelogs on subject is pretty sparse, which has likely caused this problem to manifest. However, the example ChangeLoghttp://trac.webkit.org/changeset/43259 linked from that page is prime example of what we all should strive for when describing our changes. To help curb this lack of detail in ChangeLogs, I propose we add scripthttps://bugs.webkit.org/show_bug.cgi?id=81828 (or augment an existing script) to check for this missing information and inform the contributor. It is clear not all reviewers are asking patch authors to provide this information when reviewing, and such a tool would help enforce it. — Timothy Hatcher - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using GitHub to Contribute to WebKit (Experimental)
Bugs.webkit.org has an integrated bug tracking and code review tool. I find this integration is good as it stands. I use git for development and don't think there's anything wrong with the current tools. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Jarred Nicholls [mailto:jar...@webkit.org] Sent: Friday, March 16, 2012 03:50 PM To: Ariya Hidayat ariya.hida...@gmail.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Using GitHub to Contribute to WebKit (Experimental) On Fri, Mar 16, 2012 at 3:41 PM, Ariya Hidayat ariya.hida...@gmail.commailto:ariya.hida...@gmail.com wrote: See point 3 of Landing your code. Reviewer adds a link to pull request in changelog. But now it means I have to search in two places: Bugzilla and Github, in case I want to look up some past issues/problems. In fact, Github does not a way to search for review comments. GitHub's API has hooks/events for comments on issues PRs to where it would be possible to integrate WebKit's GitHub mirror with Bugzilla so that all comments on PRs could post back to the related Bugzilla bug. Some convention would be necessary in the PR title or description to figure out which bug # it relates to, and a little work would be necessary to write out the comment into Bugzilla with some code for context (by taking the diff that's sitting on GitHub). Definitely work involved, but doable. -- Ariya Hidayat, http://ariya.ofilabs.com ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Version control survey
Where can we see the results to date? Also there should be a closing date for the survey and it should also be announced to this DL. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Saturday, March 10, 2012 02:38 AM To: Adam Barth aba...@webkit.org Cc: WebKit Development webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Version control survey I added a Both Git and Subversion option. Unfortunately, I can't change the question after the fact to allowing multiple options to be checked. Anyone else with an unusual answer should just fill in the Other (please specify) option. Regards, Maciej On Mar 9, 2012, at 10:49 PM, Adam Barth wrote: Can you add an option for folks who use both git and SVN? I use both frequently. Thanks, Adam On Fri, Mar 9, 2012 at 10:20 PM, Maciej Stachowiak m...@apple.com wrote: Since the answer to this factual question seems to be of interest to some people, here's a survey about what version control tools people use to access the WebKit repository, and approximate contribution level. http://www.surveymonkey.com/s/JQMW2QV (Note that it doesn't ask about preference for change, just what people use currently.) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Version control survey
I checked non-contributor thinking being a contributor meant being listed on this page http://trac.webkit.org/wiki/WebKit%20Team even though I've landed 10+ patches. I don't want my vote to be discounted. I use git only. Konrad Sent from my BlackBerry on the Rogers Wireless Network From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Saturday, March 10, 2012 02:52 PM To: Ryosuke Niwa rn...@webkit.org Cc: Konrad Piascik; webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Version control survey On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote: On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak m...@apple.commailto:m...@apple.com wrote: Unfortunately SurveyMonkey sucks and I can't give everyone access to live responses without paying them money. Current results: - 97 people have answered - About 67% use Git only (this has been consistent throughout the survey) - Aabout 20% use Subversion only - About 13% use Git and Subversion - No one checked Other As far as contribution levels of the responders: - 37% are WebKit reviewers - 25% are WebKit committers - 25% are WebKit contributors (but presumably not committers or reviewers yet) - 13% are not WebKit contributors Can we see the breakdown of git/svn users among reviewers committers? I'm not certain if it's really useful to consider votes casted by non-contributors here since we're presumably not trying to decide which version control system is more popular in general public. I would indeed like to get the contributor-only (and reviewer/committer-only) statistics, but I'm having trouble upgrading to the pro account that would enable this. I'll post the data once I have it. I do think it is somewhat interesting to find out what non-contributors who nontheless check out source are using to access the WebKit repository. The fact that so many people use Git says to me that our basic checkout instructions should include the relevant git instructions as an alternative. SVN instructions are on the main site at http://www.webkit.org/building/checkout.html but Git instructions are buried in the wiki. Regards, Maciej - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
Hi Ryosuke, There are solutions in git for all of your raised issues. If you want to have git diff work against master then you just need to setup an alias to do that for you. http://gitready.com/intermediate/2009/02/06/helpful-command-aliases.html This way you can create aliases for all the commands and syntax you want. Alexis mentioned that it is possible to have a linear history that Qt uses. It should also be possible to setup a git hook on the server side to modify the commit message and include the revision number. -Konrad From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Friday, March 09, 2012 11:33 AM To: Ashod Nakashian Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote: Can you be more specific? What do you find wanting in the git workflow besides the few cases raised by svn users (such as svn up that can be supported in update-webkit)? I'm also annoyed by now git diff works since I almost always want git diff master as I said in another thread. There are a number of other things I don't like about git. Also, I think I'd prefer mercurial over git for its saner behavior and terminologies if we're switching to a different VCS but I'm not about to start a thread for that. Quite frankly, moving to git will make my workflow worse regardless of improvements... It's like forcing me to use Linux instead of Windows/Mac. I'll do it if the overwhelming majority of the community thinks that's a good thing but I won't be happy about it. I think if we address the main issues raised by the svn users, the current consensus (if representative) seems to point towards an overwhelming support (and demand?) for git over svn. On that point it's reasonable to say that we're heading towards option #1 or #2 of Maciej. As such, I'm humbly proposing the following (hopefully without getting ahead of myself): Frankly, I don't quite understand the benefit of this transition. Do we really need to move to git? If the only problem of keeping svn was about svn-apply being broken, I'm more than happy to fix that script. A) Address as many of the issues raised by the svn users and streamline their use-cases in the current scripts on top of git that we can (this would leave generation numbers out of scope as it's a git issue, although we can push that on git's mail-list). Address any current issues that (advanced/seasoned) git users find wanting/missing to have a solid system that capitalizes on the powers of git as much as possible. I'd argue that generation numbers is a requirement for this transition. Monotonically increasing number is one major benefit of using svn server. Also, ideally, this generation number will be consisnte with the existing svn revision numbers so that if N is the last revision committed to the svn repository then the first commit in the git repository should have the generation number of N+1. - Ryosuke - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
I personally use either git or git-svn and would welcome the move. -Konrad From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ashod Nakashian [ashodnakash...@yahoo.com] Sent: Thursday, March 08, 2012 8:56 AM To: Sergio Villar Senin Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? From: Sergio Villar Senin svil...@igalia.com To: webkit-dev@lists.webkit.org Sent: Thursday, March 8, 2012 4:46 PM Subject: Re: [webkit-dev] Moving to Git? En 08/03/12 13:35, Ashod Nakashian escribiu: WebKittens, In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). Please correct me if I'm wrong but IIRC the main blocker was that any user with an standard OS X setup should be able to start hacking on WebKit without having to install any additional dependency. SVN is shipped with OS X and git is not. Ahh, the days when one didn't have to download anything to start hacking away... But seriously, why should I care about OS X when Windows comes packed with git?/sarcasm Anyway I'd be really pleased if that move happens. Same here. And my hope is that there are many more of us. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
I typically use webkit-patch to upload a single patch but really like your proposed change in 2a) to diff against what is staged for commit. This looks like it will be useful and cool. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Dirk Pranke [mailto:dpra...@chromium.org] Sent: Monday, February 27, 2012 08:56 PM To: WebKit-Dev webkit-dev@lists.webkit.org Subject: [webkit-dev] (no subject) Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit b) 'git diff commitish would show the diff between commitish and your current working directory If there is a consensus that we shouldn't change the defaults, I will likely implement a different command line argument that does mirror what git does. As an aside, I will probably be adding a patch that will figure out what the 'tracking' branch (as defined by branch.branchname.merge) is for your current checkout, and give webkit-patch a way to use that instead of the remote head (this would make using stacked local branches much easier). I haven't decided if this should be the default or if you should have to request this via something like 'webkit-patch diff -g UPSTREAM' instead; if you have an opinion, feel free to comment. There is a bug tracking this work at https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment there instead of here or follow along with whatever ends up happening. Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org is offline
I'm still getting: $ git fetch origin git.webkit.org[0: 17.254.20.231]: errno=Connection refused fatal: unable to connect a socket (Connection refused) Same with commit-queue: Failed to run ['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-... exit_code: 2 Updating working directory Failed to run ['Tools/Scripts/update-webkit', '--chromium'] exit_code: 2 Updating OpenSource git.webkit.org[0: 17.254.20.231]: errno=Connection refused fatal: unable to connect a socket (Connection refused) Died at Tools/Scripts/update-webkit line 162. Failed to run ['Tools/Scripts/update-webkit', '--chromium'] exit_code: 2 Updating OpenSource git.webkit.org[0: 17.254.20.231]: errno=Connection refused fatal: unable to connect a socket (Connection refused) Died at Tools/Scripts/update-webkit line 162. -Konrad From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of William Siegrist [wsiegr...@apple.com] Sent: Wednesday, February 15, 2012 2:29 PM To: Osztrogonac Csaba Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] git.webkit.org is offline All services are back. -Bill On Feb 15, 2012, at 8:55 AM, William Siegrist wrote: That server (which includes git, build, nightly, and lists) is having trouble keeping up with load, probably due to a disk array problem. I will be rebooting it one more time in an hour or two to try to clear up the problem. -Bill On Feb 15, 2012, at 6:38 AM, Osztrogonac Csaba wrote: Hi, It seems git.webkit.org is offline. Could you check what happened? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Commit-queue
Hi All, I'm seeing the commit-queue bot http://webkit-commit-queue.appspot.com/queue-status/commit-queue/bots/ec2-cq-02 consistently rebooting about every hour. I know I'm not the only one with a patch that has commit-queue+ waiting for this to be resolved. Can someone look into this failure. The last commit-queue patch that I see was from Saturday night and even the bot confirms that the last PASS was 1 day 15 hours ago. Thanks, Konrad - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
