[chromium-dev] [PATCH] Recent modification in chromium media project breaks audio rendering, data size is always zero
Dear:
As subject!
The following patch fixed the bug:
Index: ffmpeg_audio_decoder.cc
===
--- ffmpeg_audio_decoder.cc (revision 20937)
+++ ffmpeg_audio_decoder.cc (working copy)
@@ -108,6 +108,7 @@
// If we have decoded something, enqueue the result.
if (output_buffer_size) {
DataBuffer* result_buffer = new DataBuffer(output_buffer_size);
+result_buffer-SetDataSize(output_buffer_size);
uint8* data = result_buffer-GetWritableData();
memcpy(data, output_buffer, output_buffer_size);
--
-
My key fingerprint: d1:03:f5:32:26:ff:d7:3c:e4:42:e3:51:ec:92:78:b2
Inspired by http://www.nextplayer.net. Your potential. Our passion.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
fix_audio_size_in_DataBuffer.diff
Description: Binary data
[chromium-dev] Re: How to Generate Visual Studio .SLN file from gyp
I found it. I had to put GYP_MSVS_VERSION=2005 env var However I don't think I have seen that in any docs!!! But somewhere in this discussion group. (http://groups.google.com/group/chromium-dev/browse_thread/thread/ c715a6389c576470/d83d93107454e602? lnk=gstq=GYP_MSVS_VERSION#d83d93107454e602) It is weird it is not documented! regards Ziad --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: novel use of v8 - CSS Scripting Layout
security is an issue no matter where javascript is executed. it is addressed here... http://groups.google.com/group/chromium-dev/browse_thread/thread/118689ceda861163 I'm using this execution in a parallel universe technique in my implementation. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac Valgrind Bots
We've finished the shuffle of the Mac Valgrind bots over to release builds. It looks like some of the slower tests now run 2x as fast, so the cycles types seem to be a lot better (fewer cls per cycle). There are two bots on the main waterfall, and a few more on the fyi waterfall. Nirnimesh Stuart have been doing a great job working through the data on the FYI so we can get those green and move them over where folks will see them. With the faster cycle times, please make sure you help keep an eye on them as cls land. We're still finding some leaks in the System Libs that we have to add suppressions for, but we're also find valid leaks in the core code too. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac Valgrind Bots
On Fri, Jul 17, 2009 at 10:31 AM, Dan Kegel d...@kegel.com wrote: On Fri, Jul 17, 2009 at 2:07 PM, Nicolas Sylvainnsylv...@chromium.org wrote: We've finished the shuffle of the Mac Valgrind bots over to release builds. It looks like some of the slower tests now run 2x as fast, so the cycles types seem to be a lot better (fewer cls per cycle). Great! Should we do the same for linux too? We're already running at -O1 on Linux, so there isn't much improvement left to be had, I suspect. It might be worth it, dunno. There is a lot of code cut out by being NDEBUG instead of DEBUG, that's where I think the mac is getting its speed up. Yesterdays mac valgrind runs on the main waterfall were actually -O0 while we waited for the v8 issue to be fixed and they saw that speed up. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac Valgrind Bots
On Fri, Jul 17, 2009 at 7:40 AM, Dan Kegel d...@kegel.com wrote: On Fri, Jul 17, 2009 at 2:34 PM, Thomas Van Lententhoma...@chromium.org wrote: We're already running at -O1 on Linux, so there isn't much improvement left to be had, I suspect. It might be worth it, dunno. There is a lot of code cut out by being NDEBUG instead of DEBUG, that's where I think the mac is getting its speed up. Yesterdays mac valgrind runs on the main waterfall were actually -O0 while we waited for the v8 issue to be fixed and they saw that speed up. FWIW, I saw a noticable speedup from goint to -O1. Glad to hear there's more to be had. I guess I'll try it. On Windows we also use a release build without optimization. Purify can barely run with a debug build. Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: novel use of v8 - CSS Scripting Layout
The next step for your specification is to go to the W3C. CSS expressions have be a huge pain point for Internet Explorer, both in terms of security and in terms of performance. We'll want to be extremely careful before implementing a similar feature. Finally, features at this layer should go into WebKit directly, not into Chromium. Once your spec has been approved by W3C, you should take your feature request to webkit.org. Adam On Fri, Jul 17, 2009 at 5:27 AM, darrel karischdkari...@gmail.com wrote: security is an issue no matter where javascript is executed. it is addressed here... http://groups.google.com/group/chromium-dev/browse_thread/thread/118689ceda861163 I'm using this execution in a parallel universe technique in my implementation. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Code coverage
I'm interested in seeing code coverage. We have a code coverage page (http://build.chromium.org/buildbot/perf/dashboard/coverage.html), but I can't make heads or tails of this. Is there a page that shows coverage per file, so that we know what areas to add tests for? Thanks, -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: Fixing the ... in Issue Tracker
Thank you for asking this. This privacy feature is a real pain for me. Unfortunately, I can't turn it off by default for team members. I wish I could. I am dependent on everyone to discover the checkbox in the privacy section of http://code.google.com/hosting/settings and turn it off. Jon On Thu, Jul 16, 2009 at 3:49 PM, Fabien Tassin f...@sofaraway.org wrote: Hi, by any chance, do you know if it's possible to change how my name is shown in code.google.com? I appear as 'f...@sofaraway.org', i would prefer just 'fta' as in my profile. Some other users seem to be able to do that, i can't figure out how. Thanks. /Fabien --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Code coverage
On Fri, Jul 17, 2009 at 8:39 AM, Scott Violet s...@chromium.org wrote: I'm interested in seeing code coverage. We have a code coverage page (http://build.chromium.org/buildbot/perf/dashboard/coverage.html), but I can't make heads or tails of this. Is there a page that shows coverage per file, so that we know what areas to add tests for? I agree that this is not easy to find. Click on the view coverage link on the coverage bot on the experimental (FYI) waterfall. It brings you to the detailed result for a given build. http://build.chromium.org/buildbot/coverage/linux-debug/20957/CHROMIUM/index.html http://build.chromium.org/buildbot/coverage/linux-debug/20957/CHROMIUM/index.html Nicolas Thanks, -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to Generate Visual Studio .SLN file from gyp
Sorry about the confusion, yes Thomas is correct, gyp_dogfood did recently get renamed to gyp_chromium.(Stale client...) Interesting that GYP_MSVS_VERSION=2005 was actually required (as that should be the default currently). The docs definitely need another pass. :-) -BradN On Fri, Jul 17, 2009 at 2:44 AM, zys ziadsall...@gmail.com wrote: I found it. I had to put GYP_MSVS_VERSION=2005 env var However I don't think I have seen that in any docs!!! But somewhere in this discussion group. (http://groups.google.com/group/chromium-dev/browse_thread/thread/ c715a6389c576470/d83d93107454e602? lnk=gstq=GYP_MSVS_VERSION#d83d93107454e602) It is weird it is not documented! regards Ziad --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Code coverage
Thanks! Personally I think the overall numbers are the most important, rather than what they are for a build. Any reason we don't drop you into the subdirectory view from the get go? -Scott On Fri, Jul 17, 2009 at 9:37 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Fri, Jul 17, 2009 at 8:39 AM, Scott Violet s...@chromium.org wrote: I'm interested in seeing code coverage. We have a code coverage page (http://build.chromium.org/buildbot/perf/dashboard/coverage.html), but I can't make heads or tails of this. Is there a page that shows coverage per file, so that we know what areas to add tests for? I agree that this is not easy to find. Click on the view coverage link on the coverage bot on the experimental (FYI) waterfall. It brings you to the detailed result for a given build. http://build.chromium.org/buildbot/coverage/linux-debug/20957/CHROMIUM/index.html Nicolas Thanks, -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: novel use of v8 - CSS Scripting Layout
Jut to be clear, we are happy that you used chromium to create your proof-of-concept. I hope you take the comments above as constructive critic. The order W3C - webkit is not set on stone. You can also approach webkit first, or find out who is the lead on CSS for webkit and talk directly to that person. On Jul 17, 8:27 am, Adam Barth aba...@chromium.org wrote: The next step for your specification is to go to the W3C. CSS expressions have be a huge pain point for Internet Explorer, both in terms of security and in terms of performance. We'll want to be extremely careful before implementing a similar feature. Finally, features at this layer should go into WebKit directly, not into Chromium. Once your spec has been approved by W3C, you should take your feature request to webkit.org. Adam On Fri, Jul 17, 2009 at 5:27 AM, darrel karischdkari...@gmail.com wrote: security is an issue no matter where javascript is executed. it is addressed here... http://groups.google.com/group/chromium-dev/browse_thread/thread/1186... I'm using this execution in a parallel universe technique in my implementation. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Code coverage
+cc randall, the coverage guru On Fri, Jul 17, 2009 at 10:20 AM, Scott Violet s...@chromium.org wrote: Thanks! Personally I think the overall numbers are the most important, rather than what they are for a build. Any reason we don't drop you into the subdirectory view from the get go? -Scott On Fri, Jul 17, 2009 at 9:37 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Fri, Jul 17, 2009 at 8:39 AM, Scott Violet s...@chromium.org wrote: I'm interested in seeing code coverage. We have a code coverage page (http://build.chromium.org/buildbot/perf/dashboard/coverage.html), but I can't make heads or tails of this. Is there a page that shows coverage per file, so that we know what areas to add tests for? I agree that this is not easy to find. Click on the view coverage link on the coverage bot on the experimental (FYI) waterfall. It brings you to the detailed result for a given build. http://build.chromium.org/buildbot/coverage/linux-debug/20957/CHROMIUM/index.html Nicolas Thanks, -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Proposal for new changelist annotation: RELEASE_NOTE=....
I propose we add a new tag to changelist descriptions: RELEASE_NOTE=description of something interesting that users would like to know happened in this build It would be up to the developer to decide whether something was worth going in the release notes. In the extension world, the reason I specifically want this is I want to keep people testing the system up to date with changes. I have been trying to do this with a mail I send to chromium-extensions@ with each new release, but it is hard to stay in sync with build schedule. Thoughts? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Purpose of middle-click on a link?
Hello, There is a particular website where you click a picture to view the enlarged version. If the picture is a certain large size, it will open in a new window when you click it. However, if the picture is small enough a Flash/Javascript popup appears and displays the image in that. It's very inconsistent. When I middle click on a picture that opens in a new window, this opens it in a new tab like I expect, however the URL is different. If I Right Click Open link in new tab, this produces the same behavior but with a different URL it seems. Also, for the flash/javascript popup, middle-click does not open the picture in a new tab but Right Click Open link in new tab does. I thought middle-click was a shortcut for Right Click Open link in new tab. Am I wrong? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Purpose of middle-click on a link?
Webpages can intercept and cancel mouse clicks - the site could be changing the URL depending on the type of click you're doing; or performing some other action. On Fri, Jul 17, 2009 at 10:48 AM, Robert Daileyrcdai...@gmail.com wrote: Hello, There is a particular website where you click a picture to view the enlarged version. If the picture is a certain large size, it will open in a new window when you click it. However, if the picture is small enough a Flash/Javascript popup appears and displays the image in that. It's very inconsistent. When I middle click on a picture that opens in a new window, this opens it in a new tab like I expect, however the URL is different. If I Right Click Open link in new tab, this produces the same behavior but with a different URL it seems. Also, for the flash/javascript popup, middle-click does not open the picture in a new tab but Right Click Open link in new tab does. I thought middle-click was a shortcut for Right Click Open link in new tab. Am I wrong? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: Fixing the ... in Issue Tracker
On Fri, Jul 17, 2009 at 10:37 AM, Mark Larson (Google) m...@chromium.orgwrote: On Fri, Jul 17, 2009 at 09:35, Jon j...@chromium.org wrote: Thank you for asking this. This privacy feature is a real pain for me. Unfortunately, I can't turn it off by default for team members. I wish I could. I am dependent on everyone to discover the checkbox in the privacy section of http://code.google.com/hosting/settings and turn it off. I encourage everyone to uncheck the box that says 'Show my name as foo...@'. It makes it a lot easier to tell m...@chromium.org apart from mar...@chromium.org. If you're committing to SVN, your address is already out there in public anyway and bugdroid is even adding it to bug reports, so you're not getting any spam protection by hiding your address in the bug tracker. Sign in to code.google.com For me, the profile link wasn't on the home page. But it was at http://code.google.com/p/chromium/ and click Profile in the upper right. Click the Settings tab and uncheck When I participate in projects, show my email address as m...@chromium.org . Thanks, Mark Jon On Thu, Jul 16, 2009 at 3:49 PM, Fabien Tassin f...@sofaraway.org wrote: Hi, by any chance, do you know if it's possible to change how my name is shown in code.google.com? I appear as 'f...@sofaraway.org', i would prefer just 'fta' as in my profile. Some other users seem to be able to do that, i can't figure out how. Thanks. /Fabien --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for new changelist annotation: RELEASE_NOTE=....
Would this be optional? I ask because the TEST one seems to have junk in it half the time. I think it'd be valuable, but most patches won't need it. On Fri, Jul 17, 2009 at 10:48 AM, Aaron Boodman a...@chromium.org wrote: I propose we add a new tag to changelist descriptions: RELEASE_NOTE=description of something interesting that users would like to know happened in this build It would be up to the developer to decide whether something was worth going in the release notes. In the extension world, the reason I specifically want this is I want to keep people testing the system up to date with changes. I have been trying to do this with a mail I send to chromium-extensions@ with each new release, but it is hard to stay in sync with build schedule. Thoughts? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for new changelist annotation: RELEASE_NOTE=....
That will be great!If you can automate the insertion of the values of these tags to the current upcoming release notes post (like the automated comments in the issue tracker) at submit, that will be helpful for everyone. (Of course, reverts should also be noted) And then, finally, the poster will just remove the redundant entries (that were reverted), if any and post them. I would also add a hook for every Dev branching (that will include the WebKit\V8\Chrome revision), since it is usually a good thing to have in the release notes and it is not always included. Plus, the release notes will be more consistent and accurate this way. ☆PhistucK On Fri, Jul 17, 2009 at 20:48, Aaron Boodman a...@chromium.org wrote: I propose we add a new tag to changelist descriptions: RELEASE_NOTE=description of something interesting that users would like to know happened in this build It would be up to the developer to decide whether something was worth going in the release notes. In the extension world, the reason I specifically want this is I want to keep people testing the system up to date with changes. I have been trying to do this with a mail I send to chromium-extensions@ with each new release, but it is hard to stay in sync with build schedule. Thoughts? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Purpose of middle-click on a link?
That is a fault of the website. They did not cancel (return false) the link or handled it gracefully and properly (onclick instead of href).Bad coding can lead to non future proof behavior. :( ☆PhistucK On Fri, Jul 17, 2009 at 20:48, Robert Dailey rcdai...@gmail.com wrote: Hello, There is a particular website where you click a picture to view the enlarged version. If the picture is a certain large size, it will open in a new window when you click it. However, if the picture is small enough a Flash/Javascript popup appears and displays the image in that. It's very inconsistent. When I middle click on a picture that opens in a new window, this opens it in a new tab like I expect, however the URL is different. If I Right Click Open link in new tab, this produces the same behavior but with a different URL it seems. Also, for the flash/javascript popup, middle-click does not open the picture in a new tab but Right Click Open link in new tab does. I thought middle-click was a shortcut for Right Click Open link in new tab. Am I wrong? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for new changelist annotation: RELEASE_NOTE=....
On Fri, Jul 17, 2009 at 11:07 AM, Aaron Boodmana...@chromium.org wrote: Sorry, my idea was that the release manager would use these notes to create the actual release notes (with some editorializing along the way), and then I wouldn't have to do my side email. - a On Fri, Jul 17, 2009 at 11:05 AM, Evan Martine...@chromium.org wrote: I say go for it. Even if you're the only one who uses it it'll help you. :) On Fri, Jul 17, 2009 at 5:48 PM, Aaron Boodmana...@chromium.org wrote: I propose we add a new tag to changelist descriptions: RELEASE_NOTE=description of something interesting that users would like to know happened in this build It would be up to the developer to decide whether something was worth going in the release notes. In the extension world, the reason I specifically want this is I want to keep people testing the system up to date with changes. I have been trying to do this with a mail I send to chromium-extensions@ with each new release, but it is hard to stay in sync with build schedule. Thoughts? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Purpose of middle-click on a link?
But am I correct to assume that Middle Click is the same as Open link in new tab? On Jul 17, 1:08 pm, PhistucK phist...@gmail.com wrote: That is a fault of the website. They did not cancel (return false) the link or handled it gracefully and properly (onclick instead of href).Bad coding can lead to non future proof behavior. :( ☆PhistucK On Fri, Jul 17, 2009 at 20:48, Robert Dailey rcdai...@gmail.com wrote: Hello, There is a particular website where you click a picture to view the enlarged version. If the picture is a certain large size, it will open in a new window when you click it. However, if the picture is small enough a Flash/Javascript popup appears and displays the image in that. It's very inconsistent. When I middle click on a picture that opens in a new window, this opens it in a new tab like I expect, however the URL is different. If I Right Click Open link in new tab, this produces the same behavior but with a different URL it seems. Also, for the flash/javascript popup, middle-click does not open the picture in a new tab but Right Click Open link in new tab does. I thought middle-click was a shortcut for Right Click Open link in new tab. Am I wrong? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for new changelist annotation: RELEASE_NOTE=....
On Fri, Jul 17, 2009 at 10:48, Aaron Boodman a...@chromium.org wrote: I propose we add a new tag to changelist descriptions: RELEASE_NOTE=description of something interesting that users would like to know happened in this build It would be up to the developer to decide whether something was worth going in the release notes. In the extension world, the reason I specifically want this is I want to keep people testing the system up to date with changes. I have been trying to do this with a mail I send to chromium-extensions@ with each new release, but it is hard to stay in sync with build schedule. Thoughts? I've been thinking of something along the same lines. I was also considering a ReleaseNotes file, like a ChangeLog but only to announce noteworthy changes. The advantages are that it can be edited post-commit and that your notes get reverted if your change gets reverted. In any case, if you want to pioneer 'add an optional RELEASE_NOTES line to your log description', I'm all for it. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for new changelist annotation: RELEASE_NOTE=....
I say go for it. Even if you're the only one who uses it it'll help you. :) On Fri, Jul 17, 2009 at 5:48 PM, Aaron Boodmana...@chromium.org wrote: I propose we add a new tag to changelist descriptions: RELEASE_NOTE=description of something interesting that users would like to know happened in this build It would be up to the developer to decide whether something was worth going in the release notes. In the extension world, the reason I specifically want this is I want to keep people testing the system up to date with changes. I have been trying to do this with a mail I send to chromium-extensions@ with each new release, but it is hard to stay in sync with build schedule. Thoughts? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for new changelist annotation: RELEASE_NOTE=....
On Fri, Jul 17, 2009 at 11:16 AM, Mark Larson (Google)m...@chromium.org wrote: I've been thinking of something along the same lines. I was also considering a ReleaseNotes file, like a ChangeLog but only to announce noteworthy changes. The advantages are that it can be edited post-commit and that your notes get reverted if your change gets reverted. In any case, if you want to pioneer 'add an optional RELEASE_NOTES line to your log description', I'm all for it. Ok, I will start using it. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac Valgrind Bots
TThomas Van Lententhoma...@chromium.org wrote: We're already running at -O1 on Linux, so there isn't much improvement left to be had, I suspect. =A0 It might be worth it, dunno. There is a lot of code cut out by being NDEBUG instead of DEBUG, that's where I think the mac is getting its speed up. =A0Yesterdays mac valgrind= runs on the main waterfall were actually -O0 while we waited for the v8 issue = to be fixed and they saw that speed up. Thanks, I guess I'll try it. (FWIW, I saw a noticable speedup from going to -O1, so we're already partway there.) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Purpose of middle-click on a link?
Yes, the default action of middle-click a link is the same as open link in new tab. This is the default action for many browsers including Chrome. But Glen's note is important because you cannot tell by just looking at a link on a webpage whether or not the default action has been overridden or not. If the default action has been overridden, then middle clicking that link will do whatever the website has specified. On Jul 17, 11:15 am, Robert Dailey rcdai...@gmail.com wrote: But am I correct to assume that Middle Click is the same as Open link in new tab? On Jul 17, 1:08 pm, PhistucK phist...@gmail.com wrote: That is a fault of the website. They did not cancel (return false) the link or handled it gracefully and properly (onclick instead of href).Bad coding can lead to non future proof behavior. :( ☆PhistucK On Fri, Jul 17, 2009 at 20:48, Robert Dailey rcdai...@gmail.com wrote: Hello, There is a particular website where you click a picture to view the enlarged version. If the picture is a certain large size, it will open in a new window when you click it. However, if the picture is small enough a Flash/Javascript popup appears and displays the image in that. It's very inconsistent. When I middle click on a picture that opens in a new window, this opens it in a new tab like I expect, however the URL is different. If I Right Click Open link in new tab, this produces the same behavior but with a different URL it seems. Also, for the flash/javascript popup, middle-click does not open the picture in a new tab but Right Click Open link in new tab does. I thought middle-click was a shortcut for Right Click Open link in new tab. Am I wrong? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Confusing test coverage numbers
I think something's busted. If you look at the percent of test code executed: http://build.chromium.org/buildbot/perf/linux-debug/coverage/report.html?history=150header=Linuxgraph=PercentCoveredTest http://build.chromium.org/buildbot/perf/linux-debug/coverage/report.html?history=150header=Linuxgraph=PercentCoveredTest...the graph goes down when people check in unit tests, and goes up when people clean up or modify existing tests. If you look to the far left of this graph, you'll notice our test code coverage jumped from 58% to 72%: http://build.chromium.org/buildbot/perf/mac-debug/coverage/report.html?history=300header=Macgraph=PercentCoveredTest http://build.chromium.org/buildbot/perf/mac-debug/coverage/report.html?history=300header=Macgraph=PercentCoveredTestThere's no way the CLs checked in are responsible for that jump. What appears to have happened was previously non-executing-but-accounted-for tests (like the ones I checked in) tests all started getting executed. One of many examples: http://build.chromium.org/buildbot/coverage/mac-debug/20419/CHROMIUM/chrome/browser/tabs/index.html http://build.chromium.org/buildbot/coverage/mac-debug/20419/CHROMIUM/chrome/browser/tabs/index.html http://build.chromium.org/buildbot/coverage/mac-debug/20426/CHROMIUM/chrome/browser/tabs/index.html Andrew On Thu, Jul 16, 2009 at 4:06 PM, John Grabowski j...@chromium.org wrote: For starters, thanks for caring about coverage It is possible your checkin was timed poorly (didn't land in time for the bot start), but looking at the coverage scripts I don't see how that could happen. I noticed you landed, then reverted, this CL the day before. My best guess is that such an action was enough info for croc to learn the filename and stick, but since you reverted it didn't compile or get run. Let's wait one more run and see if things fix themselves. Ping again if the problem continues. jrg On Thu, Jul 16, 2009 at 3:38 PM, Andrew Scherkus scher...@chromium.orgwrote: I think we're getting confused by time zones here. I checked in at Wednesday at 18:26 PST (UTC-7), and assuming the coverage bot is also in my time zone that'd mean these results were generated ~20 minutes afterwards. On Thu, Jul 16, 2009 at 3:22 PM, Nick Carter n...@chromium.org wrote: The bottom of the link says that coverage information was generated Wednesday. Your checkin was Thursday. Would that have something to do with it? - nick On Thu, Jul 16, 2009 at 12:43 PM, Andrew Scherkus scher...@chromium.org wrote: So I checked in a change that did some refactoring and added unit tests for two classes that were previously not tested: http://src.chromium.org/viewvc/chrome?view=revrevision=20836 According to the coverage graphs, that change actually brought both the source code and test code coverage *down*. What's interesting is the coverage analysis reports my new tests aren't being executed at all: http://build.chromium.org/buildbot/coverage/linux-debug/20836/CHROMIUM/media/filters/index.html Now I have no clue who/what process is generating these numbers, but maybe it needs to be clobbered. Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Code coverage
I had to watch someone do this once before I figured it out. Starting with the link below: 1) Click on either mac or linux 2) Click somewhere on the ensuing graph, to bring up the CL you care about 3) Click on the Coverage tab on the right. This will let you browse through subdirectories. - Rohit On Fri, Jul 17, 2009 at 11:39 AM, Scott Violets...@chromium.org wrote: I'm interested in seeing code coverage. We have a code coverage page (http://build.chromium.org/buildbot/perf/dashboard/coverage.html), but I can't make heads or tails of this. Is there a page that shows coverage per file, so that we know what areas to add tests for? Thanks, -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for new changelist annotation: RELEASE_NOTE=....
On Fri, Jul 17, 2009 at 11:00 AM, Jeremy Orlowjor...@chromium.org wrote: Would this be optional? I ask because the TEST one seems to have junk in it half the time. I think it'd be valuable, but most patches won't need it. It would definitely be optional, and it developers would be encouraged to only add it when they think something is useful to go in the release notes. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Access to window handles from plugins?
Hi, Can anyone help me with this? How can I get the window handle of an element from its JS DOM node? Perhaps a little background might help! I'm currently working on WebDriver, a browser testing automation tool[1], to add Chrome support. As suggested by the chrome team, this is being written as an extension with an embedded NPAPI plugin. The original driver worked with the AutomationProxy, but this is not available in release binaries, which means that a user would need to compile a custom version of Chrome; obviously a less than ideal user experience :) We use a native interactions library for sending keys/clicks/etc at the OS level, which requires a window handle to the window containing the element to do its thing. This library is shared between all the drivers for a particular platform (at the moment, only Windows, but X support is coming soon). Thanks, Daniel Wagner-Hall 1: http://code.google.com/p/webdriver/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac Valgrind Bots
Right, we use -O1 instead of -O2 or -O0 with valgrind; it strikes a good balance between good stack and speed. On Jul 17, 2009 9:46 AM, Erik Kay erik...@chromium.org wrote: On Fri, Jul 17, 2009 at 8:12 AM, Nicolas Sylvain nsylv...@chromium.org wrote: On Fri, Jul ... One other tradeoff to consider with these build options for valgrind is quality and consistency of stack traces. I don't know how much of an issue this has been for valgrind, but I'll share the Purify side of it with you. As Nicolas points out, Purify runs a Release build with no optimizations, and some linker options disabled. Running release is a huge performance improvement since it gets rid of a lot of extra code that's being run. Minimizing the optimizations allows for more consistent stack traces since levels of the stack aren't getting optimized away and line number info is more accurate. Further, we disable COMDAT folding in the linker, which with visual studio combines identical code into the same entry point. This is a great optimization for code like ours that uses templates heavily, but it winds up making the stacks less understandable and less deterministic. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] V8 bindings are now fully upstreamed!
As of r20923, src/webkit/port/ has been deleted and the last of the V8 bindings are living in svn.webkit.org. There's still some cleanup of the bindings to be done, but they are all upstream now. Hopefully this will make everyone's life a little easier. If you're reading this email, you probably deserve thanks for one or more of the following reasons: * You authored a V8 binding upstreaming patch * You reviewed a V8 binding upstreaming patch * You suffered through an extended build breakage caused by a V8 binding upstreaming patch Thanks! ~Nate --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] sbox_integration_tests.exe build fails
If you have a well-known (yet subpar) anti-virus whose name I don't want to mention. Your build might fail: general error c101008d: Failed to write the updated manifest to the resource of file ..\chrome\Release\sbox_integration_tests.exe Solution: tweak your AV if you can. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Access to window handles from plugins?
On Fri, Jul 17, 2009 at 10:45 AM, Daniel Wagner-Hall dawag...@gmail.comwrote: Hi, Can anyone help me with this? How can I get the window handle of an element from its JS DOM node? DOM elements, with the exception of plugins and select controls, don't have window handles because they're not implemented as native controls (otherwise we'd run out of OS handles on some pages). Are you asking specifically about a plugin node? Perhaps a little background might help! I'm currently working on WebDriver, a browser testing automation tool[1], to add Chrome support. As suggested by the chrome team, this is being written as an extension with an embedded NPAPI plugin. The original driver worked with the AutomationProxy, but this is not available in release binaries, which means that a user would need to compile a custom version of Chrome; obviously a less than ideal user experience :) We use a native interactions library for sending keys/clicks/etc at the OS level, which requires a window handle to the window containing the element to do its thing. This library is shared between all the drivers for a particular platform (at the moment, only Windows, but X support is coming soon). Thanks, Daniel Wagner-Hall 1: http://code.google.com/p/webdriver/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: V8 bindings are now fully upstreamed!
Woohoo On Fri, Jul 17, 2009 at 10:42 AM, Nate Chapin jap...@google.com wrote: As of r20923, src/webkit/port/ has been deleted and the last of the V8 bindings are living in svn.webkit.org. There's still some cleanup of the bindings to be done, but they are all upstream now. Hopefully this will make everyone's life a little easier. If you're reading this email, you probably deserve thanks for one or more of the following reasons: * You authored a V8 binding upstreaming patch * You reviewed a V8 binding upstreaming patch * You suffered through an extended build breakage caused by a V8 binding upstreaming patch Thanks! ~Nate --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Access to window handles from plugins?
On Fri, Jul 17, 2009 at 5:45 PM, Daniel Wagner-Halldawag...@gmail.com wrote: Can anyone help me with this? How can I get the window handle of an element from its JS DOM node? Perhaps a little background might help! I'm currently working on WebDriver, a browser testing automation tool[1], to add Chrome support. As suggested by the chrome team, this is being written as an extension with an embedded NPAPI plugin. The original driver worked with the AutomationProxy, but this is not available in release binaries, which means that a user would need to compile a custom version of Chrome; obviously a less than ideal user experience :) We use a native interactions library for sending keys/clicks/etc at the OS level, which requires a window handle to the window containing the element to do its thing. This library is shared between all the drivers for a particular platform (at the moment, only Windows, but X support is coming soon). John would have a more definite answer, but my understanding is: - all content aside from windowed plugins use one OS-level window, wrapping the page - NPAPI has no API for querying for that window Windowed plugins do get a parent window from the SetWindow call of NPAPI. You could imagine walking the window hierarchy upwards to figure that out, but it's surely fragile. On different browsers I expect that to be a window arbitrarily below the outer window described above. Even within Chrome it's different: On Windows the nesting is one extra window in the plugin process, then one more in the browser process, and there's an extra dummy window used in some circumstances I don't quite understand. On Linux there's just one extra wrapping window browser-side. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Access to window handles from plugins?
I can happily get the plugin's window handle using standard NPAPI calls, I'm trying to get the window handle of arbitrary tabs (and indeed frames) which my extension has loaded Specifically, I am opening pages, at the moment using window.open in the background page (though this may change to something slightly more clean, I haven't really considered what/how yet), and manipulating them with Javascript (e.g. grabbing their title). I can interact with them through Javascript from the background page, but would like to be able to generate native OS events to the window handle of the windows/tabs which I open... From my experimenting with Spy++ and the results of NPAPI SetWindow calls, the HWND returned for the plugin has no parent which can be conveniently used, though there may be some clever scheme used which I'm just not seeing by not knowing how things really work. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [PATCH] Recent modification in chromium media project breaks audio rendering, data size is always zero
Thanks for spotting this! Figures it happened in one of the files I didn't
write a unit test for :)
Fix is up for review: http://codereview.chromium.org/155703
Andrew
On Fri, Jul 17, 2009 at 10:19 AM, Jeremy Orlow jor...@chromium.org wrote:
Hi ffmpeg, :-)
Chromium doesn't accept patches like this. It's possible some kind soul
will go ahead and patch this into their client and get it reviewed and
committed for you, but the way things usually work is described here:
http://dev.chromium.org/developers/contributing-code
J
On Fri, Jul 17, 2009 at 12:53 AM, avcoder ffm...@gmail.com wrote:
Dear:
As subject!
The following patch fixed the bug:
Index: ffmpeg_audio_decoder.cc
===
--- ffmpeg_audio_decoder.cc (revision 20937)
+++ ffmpeg_audio_decoder.cc (working copy)
@@ -108,6 +108,7 @@
// If we have decoded something, enqueue the result.
if (output_buffer_size) {
DataBuffer* result_buffer = new DataBuffer(output_buffer_size);
+result_buffer-SetDataSize(output_buffer_size);
uint8* data = result_buffer-GetWritableData();
memcpy(data, output_buffer, output_buffer_size);
--
-
My key fingerprint: d1:03:f5:32:26:ff:d7:3c:e4:42:e3:51:ec:92:78:b2
Inspired by http://www.nextplayer.net. Your potential. Our passion.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Access to window handles from plugins?
On Fri, Jul 17, 2009 at 7:06 PM, Daniel Wagner-Halldawag...@gmail.com wrote: From my experimenting with Spy++ and the results of NPAPI SetWindow calls, the HWND returned for the plugin has no parent which can be conveniently used, though there may be some clever scheme used which I'm just not seeing by not knowing how things really work. As I was trying to describe earlier, it's not so much the parent as it is the great-grandparent. If you are willing to write something fragile I think that's your best bet. One trick that might help is that we set a window title (::SetWindowText()) on the window containing the page, while all of the windows in between don't have one. Here's an xwininfo -tree snippet on Linux with one plugin: xwininfo: Window id: 0x31e file:///work/chrome/src/webkit/data/test_shell/plugins/embed4.htm - Chromium Root window id: 0x13b (the root window) (has no name) Parent window id: 0x147981d (has no name) 8 children: 0x344 (has no name): () 617x519+0+93 +515+384 4 children: 0x3000398 (has no name): () 296x21+0+667 +515+1051 1 child: 0x3000399 (has no name): () 294x19+1+1 +516+1052 0x3000176 test_shell home: () 617x518+0+1 +515+385 1 child: 0x30004c9 (has no name): () 300x300+8+71 +523+456 1 child: 0x343 chrome: (chrome Chrome) 300x300+0+0 +523+456 2 children: 0x340001e (has no name): () 300x300+0+0 +523+456 0x344 (has no name): () 1x1+-1+-1 +522+455 0x30004c9 is the window that was passed to NPAPI's SetWindow, and 0x3000176 (which has the page title test_shell home) is the one that contains the page. But the general answer to your question remains: no, there's no non-fragile way of doing this. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Access to window handles from plugins?
On Fri, Jul 17, 2009 at 12:06 PM, Daniel Wagner-Hall dawag...@gmail.comwrote: I can happily get the plugin's window handle using standard NPAPI calls, I'm trying to get the window handle of arbitrary tabs (and indeed frames) which my extension has loaded Specifically, I am opening pages, at the moment using window.open in the background page (though this may change to something slightly more clean, I haven't really considered what/how yet), and manipulating them with Javascript (e.g. grabbing their title). I can interact with them through Javascript from the background page, but would like to be able to generate native OS events to the window handle of the windows/tabs which I open... From my experimenting with Spy++ and the results of NPAPI SetWindow calls, the HWND returned for the plugin has no parent which can be conveniently used, though there may be some clever scheme used which I'm just not seeing by not knowing how things really work. This wouldn't be robust, as Chrome has switched the window hierarchy in the past and it might occur again in the future (even to the extreme of that plugin window not having a parent). What you probably want to do is call NPN_GetValue on NPNVnetscapeWindow to get the HWND of the page where the calling plugin is hosted. To get the HWND of other windows that you open, you can embed a plugin instance in them, and script them using JS which ends up calling into binary code, which then calls NPN_GetValue. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
(Third try to send this to the list, and then I'm giving up. They keep bouncing.) Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). Mark Dan Kegel wrote: Hi Mark, I'm interested in cleaning up how we invoke gyp when building for use with valgrind. Right now it's a bit of a hodgepodge, and it'd be nice if we could use the variant method you introduced here http://codereview.chromium.org/115922 and discussed on the list http://www.mail-archive.com/chromium-dev@googlegroups.com/msg03185.html Is there doc for this yet? I can't see how to invoke variants from the commandline, and gyp --help doesn't mention variants. The syntax mentioned in the mailing list, gclient runhooks --force -Dcoverage=1 fails with gclient.py: error: no such option: -D Also, will the makefile generator need to be modified to support variants? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
On Fri, Jul 17, 2009 at 7:38 PM, Mark Mentovaim...@chromium.org wrote: Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). What do we need loops for? mmoss has a patch for the locale files that just uses an action, which seems preferable to me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
I don't think I've seen it. Is it gonna work on the Mac? Evan Martin wrote: On Fri, Jul 17, 2009 at 7:38 PM, Mark Mentovaim...@chromium.org wrote: Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). What do we need loops for? mmoss has a patch for the locale files that just uses an action, which seems preferable to me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
I haven't sent it yet because it's broken on the Mac due to that gyp regex bug we talked about this morning. I'm currently hacking at gyp to see how best to rewrite that regex. You can preview the Chrome change at http://codereview.chromium.org/149781. Michael On Fri, Jul 17, 2009 at 1:12 PM, Mark Mentovaim...@chromium.org wrote: I don't think I've seen it. Is it gonna work on the Mac? Evan Martin wrote: On Fri, Jul 17, 2009 at 7:38 PM, Mark Mentovaim...@chromium.org wrote: Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). What do we need loops for? mmoss has a patch for the locale files that just uses an action, which seems preferable to me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
I agree. I thought we wanted to avoid that kind of bloat, which is why I went the helper script route instead of pestering for loops. If we add too many features, pretty soon we'll just have scons-NG (not that there's anything wrong with that, but I don't understand that to be the goal of gyp). Michael On Fri, Jul 17, 2009 at 1:14 PM, Bradley Nelsonbradnel...@google.com wrote: Yeah I feel like loops take things to a bad bad place If we can avoid adding it, that would be ideal. -BradN On Fri, Jul 17, 2009 at 1:10 PM, Evan Martin e...@chromium.org wrote: On Fri, Jul 17, 2009 at 7:38 PM, Mark Mentovaim...@chromium.org wrote: Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). What do we need loops for? mmoss has a patch for the locale files that just uses an action, which seems preferable to me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
Michael Moss wrote: I agree. I thought we wanted to avoid that kind of bloat, which is why I went the helper script route instead of pestering for loops. If we add too many features, pretty soon we'll just have scons-NG (not that there's anything wrong with that, but I don't understand that to be the goal of gyp). It's not, but loops weren't supposed to be too ridiculous. I'll reserve further judgment until I've digested what you've come up with for localizations. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Confusing test coverage numbers
I'll take a look at this. jrg On Fri, Jul 17, 2009 at 11:40 AM, Andrew Scherkus scher...@chromium.orgwrote: I think something's busted. If you look at the percent of test code executed: http://build.chromium.org/buildbot/perf/linux-debug/coverage/report.html?history=150header=Linuxgraph=PercentCoveredTest http://build.chromium.org/buildbot/perf/linux-debug/coverage/report.html?history=150header=Linuxgraph=PercentCoveredTest...the graph goes down when people check in unit tests, and goes up when people clean up or modify existing tests. If you look to the far left of this graph, you'll notice our test code coverage jumped from 58% to 72%: http://build.chromium.org/buildbot/perf/mac-debug/coverage/report.html?history=300header=Macgraph=PercentCoveredTest http://build.chromium.org/buildbot/perf/mac-debug/coverage/report.html?history=300header=Macgraph=PercentCoveredTestThere's no way the CLs checked in are responsible for that jump. What appears to have happened was previously non-executing-but-accounted-for tests (like the ones I checked in) tests all started getting executed. One of many examples: http://build.chromium.org/buildbot/coverage/mac-debug/20419/CHROMIUM/chrome/browser/tabs/index.html http://build.chromium.org/buildbot/coverage/mac-debug/20419/CHROMIUM/chrome/browser/tabs/index.html http://build.chromium.org/buildbot/coverage/mac-debug/20426/CHROMIUM/chrome/browser/tabs/index.html Andrew On Thu, Jul 16, 2009 at 4:06 PM, John Grabowski j...@chromium.org wrote: For starters, thanks for caring about coverage It is possible your checkin was timed poorly (didn't land in time for the bot start), but looking at the coverage scripts I don't see how that could happen. I noticed you landed, then reverted, this CL the day before. My best guess is that such an action was enough info for croc to learn the filename and stick, but since you reverted it didn't compile or get run. Let's wait one more run and see if things fix themselves. Ping again if the problem continues. jrg On Thu, Jul 16, 2009 at 3:38 PM, Andrew Scherkus scher...@chromium.orgwrote: I think we're getting confused by time zones here. I checked in at Wednesday at 18:26 PST (UTC-7), and assuming the coverage bot is also in my time zone that'd mean these results were generated ~20 minutes afterwards. On Thu, Jul 16, 2009 at 3:22 PM, Nick Carter n...@chromium.org wrote: The bottom of the link says that coverage information was generated Wednesday. Your checkin was Thursday. Would that have something to do with it? - nick On Thu, Jul 16, 2009 at 12:43 PM, Andrew Scherkus scher...@chromium.org wrote: So I checked in a change that did some refactoring and added unit tests for two classes that were previously not tested: http://src.chromium.org/viewvc/chrome?view=revrevision=20836 According to the coverage graphs, that change actually brought both the source code and test code coverage *down*. What's interesting is the coverage analysis reports my new tests aren't being executed at all: http://build.chromium.org/buildbot/coverage/linux-debug/20836/CHROMIUM/media/filters/index.html Now I have no clue who/what process is generating these numbers, but maybe it needs to be clobbered. Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Landing WebKit patches
FYI, I'm now a WebKit committer. I know I'm going to regret this, but feel free to ping me if you have reviewed WebKit patches that you need to get in. Everyone else was really great about landing my patches, so now it's time to pay it forward. :-) If you want to see who else is a committer/reviewer from our team, check this out: http://trac.webkit.org/wiki/WebKit%20Team#FolksfromGoogle (Note that abarth is on there too, but not under the Google section.) J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Landing WebKit patches
You should know about bugzilla-tool http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/bugzilla-tool if you plan on doing commits for other people. It will make your life much easier. :) bugzilla-tool land-patches BUGNUMBER is all you need. :) (Assuming the tree is green so that all the tests will pass locally.) see bugzilla-tool --help for more info. -eric On Fri, Jul 17, 2009 at 2:47 PM, Jeremy Orlowjor...@chromium.org wrote: FYI, I'm now a WebKit committer. I know I'm going to regret this, but feel free to ping me if you have reviewed WebKit patches that you need to get in. Everyone else was really great about landing my patches, so now it's time to pay it forward. :-) If you want to see who else is a committer/reviewer from our team, check this out: http://trac.webkit.org/wiki/WebKit%20Team#FolksfromGoogle (Note that abarth is on there too, but not under the Google section.) J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mozilla design challenge
http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Code coverage
We can do this. The priority is hooking up windows coverage; Randall finished his end (weeks ago) and I've mostly finished mine but I haven't hooked things up yet. Next is tracking down the add more unit tests and coverage goes down problem reported by the media guys. Once we're hooked up and correct we can spend some time on UI. jrg On Fri, Jul 17, 2009 at 10:20 AM, Scott Violet s...@chromium.org wrote: Thanks! Personally I think the overall numbers are the most important, rather than what they are for a build. Any reason we don't drop you into the subdirectory view from the get go? -Scott On Fri, Jul 17, 2009 at 9:37 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Fri, Jul 17, 2009 at 8:39 AM, Scott Violet s...@chromium.org wrote: I'm interested in seeing code coverage. We have a code coverage page (http://build.chromium.org/buildbot/perf/dashboard/coverage.html), but I can't make heads or tails of this. Is there a page that shows coverage per file, so that we know what areas to add tests for? I agree that this is not easy to find. Click on the view coverage link on the coverage bot on the experimental (FYI) waterfall. It brings you to the detailed result for a given build. http://build.chromium.org/buildbot/coverage/linux-debug/20957/CHROMIUM/index.html Nicolas Thanks, -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
