[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors
John, I'll try to reproduce the error as you suggested tomorrow. In the mean time, I enlisted from another (much cleaner) Win7-x64 box and was able to build successfully. With respect to your question about the crash, please refer to my initial post. Yes, gclient sync finished successfully. On Oct 1, 5:08 pm, John Abd-El-Malek j...@chromium.org wrote: Chrome's cygwin installation is hermetic. It works for a number of Google devs on Windows 7/64 bit so I don't think it's a simple case of the cygwin installation being broken. What do you mean the binaries crash, did they not resolve any dependent dlls? Are you sure your gclient sync finished successfully? If you can move your working binaries off to another directory, sync again, and try to repro this and get this data, it would be helpful in determining how we can fix this. Thanks On Thu, Oct 1, 2009 at 4:46 PM, vuh...@gmail.com wrote: Ok, I fixed the problem by installing Cygwin (1.5.25-15), copying sh.exe and bash.exe over to src\third_party\cygwin\bin. So it may be a good idea to check in this Cygwin version. On Oct 1, 2009 4:43pm, John Abd-El-Malek j...@chromium.org wrote: I built using the instructions on Windows 7 64 bit without installing another cygwin. On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote: So it looks like I need to install Cygwin separately before I can build Chrome? If so this should be added to the Windows build instruction page. On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote: I run Cygwin Bash Shell not from Command Prompt: moha...@mohamed-pc ~$ bash -Mohamed On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote: Hi Mohamed, can you run bash.exe from cmd? I get the following error: E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin \binbash 9 [main] bash 8384 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 211065 [main] bash 8384 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 229623 [main] bash 8384 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote: Windows 7 64bit works fine here (using the default settings from dev.chromium.org) Make sure you have access to the folder your writing to. Some folders require admin mode. -Mohamed On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote: Detailed error message: 1-- Build started: Project: js2c, Configuration: Debug Win32 -- 1js2c 2-- Build started: Project: cygwin, Configuration: Debug Win32 -- 2setup_mount 1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 1 3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 2The operation completed successfully. 2The operation completed successfully. 1Project : error PRJ0002 : Error result 35584 returned from 'C: \Windows\SysWow64\cmd.exe'. Content of bash.exe.stackdump: E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore bash.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30 eax= ebx= ecx=61106EC8 edx= esi=611021A0 edi=0045A3E0 ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball \chromium\s rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0028CBC8 0043AE30 (0003, 02361C00, 02360090, 772F) 0028CD68 610060D8 (, 0028CDA0, 61005450, 0028CDA0) 61005450 61004416 (009C, A02404C7, E8611021, FF48) 431390 [main] bash 8296 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VI OLATION 509897 [main] bash 8296 _cygtls::handle_exceptions: Error while dumping state ( probably corrupted stack) --~--~-~--~~~---~--~~ 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: library targets with no sources fail to build on OS X
The targets need a type so it knows what to build. I guess the different
generators are defaulting differently.
TVL
On Thu, Oct 1, 2009 at 2:45 PM, brymcq bmcqu...@gmail.com wrote:
I'm working on some code that uses the gyp build system. I find that
there are cases where I want to aggregate several libraries into a
single library target so other clients can depend on one public
library target instead of having to reference a bunch of individual
library targets. For instance I might have:
'targets': [
{
'target_name': 'foo',
'dependencies': [
some deps here
],
'sources': [
some sources here
]
},
{
'target_name': 'bar',
'dependencies': [
some deps here
],
'sources': [
some sources here
]
},
{
'target_name': 'public',
'dependencies': [
'foo',
'bar',
],
},
]
I then have consumers of my library depend on the 'public' target
rather than depending on 'foo' and 'bar'
This actually works fine on Linux and Windows builds, but on OS X
using xcodebuild, my builds fail with:
libpublic.a: No such file or directory
Is there some way to get the xcodebuilds to properly build these stub
libraries that don't have any source files? Does the gyp-xcode
generation code need to change to support 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] Turning on Mac pixel tests! Heads-up!
I'm turning on the Mac pixel tests today. There's two parts to this. First is the new expectations (http://codereview.chromium.org/249043) which just adds IMAGE failures and won't affect anything. The second is telling the bots to run the pixel tests (http://codereview.chromium.org/242099) and that might be an issue. If everything goes as planned, no one will notice. If things do not go as planned, the first build after the second checkin might fail with pixel issues. If that happens, blame me. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Debugging glibc malloc double free or corruption
A Fedora user recently reported that loading www.msnbc.com causes the Oh snap! and unhappy mac, which I was able to reproduce. The gory details are filed here: http://code.google.com/p/chromium/issues/detail?id=23635 I hate to just open bugs and say go fix it!, at least not without significantly narrowing down the problem. Does anyone have any suggestions on how to debug a glibc malloc double free or corruption error? I tried valgrind, but it gave up after 1000 errors. :/ ~spot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Modules XP, revision 27841
Automatically closing tree for net_unittests on Modules XP http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP/builds/16575 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP --= Automatically closing tree for net_unittests on Modules XP =-- Revision: 27841 Blame list: miran...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Scalability
Hi I want to explain that if you want me to scale, we need to follow some rules. Sorry for being somewhat rude sometimes, it's usually not deserved. In particular I apologize for the last thread to Jenn. This is really about scalability. There is 100+ try server users. They run a few try a day each, well, at least the productive people, which excludes me. Each job is run usually on 3 'builders'. That results in *thousands* of runs each days. So yes, it does break in awful ways *every days*. Let me explain why there is this sentence in the try job emails: If you think the try slave is broken (it happens!), please REPLY to this email, don't ask on irc, mailing list or IM. Some facts to back this sentence: - chromium-dev@ and the equivalent googler mailing lists have thousands of people and only a few care. - The irc channel has 150+ persons but if you don't mind not getting an answer, go ahead. :) - IM me (or Nicolas or Brad), seems like a good idea but if it happens 50 times a day for different problems, we really can't get any work done since we're constantly interrupted. - Emailing tryser...@chromium.org is the way to go. I receive it on my phone and I can batch replies together. In addition, at the end of the week, I can get an approximation of how much time this took me. Sometimes I don't reply, especially for flaky test. Be sure these emails are appreciated and helps me pinpoint bad slaves. There's definitely a scale advantage to ping the smallest number of folks first and escalate accordingly. If I don't reply fast enough for you, let's say 15min ~ 1 hour or even sooner if you are really blocked, feel free to escalate to a mailing list or irc or IM me but please, give me a chance to fix it first. And to fix it first; I need to know which slaves you are talking about. To know that, I need the try job url, it's in every try job email. If you are still reading, thanks, that means you find this resource useful or it wastes enough of your time each day for you to bother reading this email. That is truly appreciated. If you finds ways to improve the functionality, the efficiency, to reduce the maintenance burden or to stop working on webkit for a day or two (who on earth would want to do that?), when I say patches are welcome, I say that in it truest meaning and I'm not trying to be sarcastic. If you don't have time, please file a bug to http://new.crbug.com and assign it to me. I'll triage it accordingly. A fair number of people contributed to the try server, the buildbot code in general and to the depot tools. The try server maintenance squads includes Bev and Nicolas. They help me tremendously. The try server specific code also includes Brad, Dan, Marc-André, Steven and Thomas. The buildbot code in general also includes Allen, Antony, Anthony, Chase, Evan #1, Glenn, Alpha, Huan, Ian, Jungshik, Ken, Rahul, Mark and Mark, Micheal, Nick, Ojan, Pam, Patrick, Paul, Pavel, Robert, Randall, Sid, Stuart, Tony, Lei, Timur, Takeshi, Victor and William. In addition, people contributing to depot_tools also includes Albert, Elliot, Evan #2, Nirnimesh, Pawel, Scott, B.J. and Sverrir. So that's a lot of people helping improving everyone's workflow. I really want to thanks each of them. I want to be clear: this is fine to IM me but please reply to the email first. --- So, what's next? The windows try slaves are atrociously slow right now. They even time out during compile these days. The bottleneck is linking. To give you an idea, here's a truncated dir list: (...) 10,223,616 dump_cache.exe 10,309,632 fetch_client.exe 10,600,448 net_perftests.exe 12,406,784 sync_unit_tests.exe 14,966,784 net_unittests.exe 22,118,400 mini_installer.exe 55,029,760 tab_switching_test.exe 55,029,760 url_fetch_test.exe 55,046,144 memory_test.exe 55,066,624 page_cycler_tests.exe 60,858,368 test_shell.exe 63,164,416 test_shell_tests.exe 65,908,736 generate_profile.exe 66,113,536 perf_tests.exe 67,272,704 ui_tests.exe 67,362,816 sync_integration_tests.exe 67,948,544 interactive_ui_tests.exe 72,175,616 unit_tests.exe (...) 258,968,576 generate_profile.pdb 262,237,184 perf_tests.pdb 262,351,872 chrome_dll.pdb 265,300,992 sync_integration_tests.pdb 266,202,112 ui_tests.pdb 266,333,184 browser_tests.pdb 266,841,088 interactive_ui_tests_dll.pdb 266,882,048 interactive_ui_tests.pdb 281,095,168 unit_tests.pdb 273 File(s) 7,391,294,890 bytes Yes, that's 7gigs of crap. And that doesn't include lib\ and obj\. So the poor VMs have a bit of a hard time to keep up and a significant number of them are simply timing out. I'm working on reducing the injected dependencies in our projects but it takes time. As an example, syncapi links with net for a single string parsing function. But pulling net also pulls v8 so I'm splitting net in two to remove the dependency injection. We may go back to disabling PDBs, saving several gigs but that slightly reduce the usefulness. That's probably what needs to happen right now. Thanks,
[chromium-dev] Re: Turning on Mac pixel tests! Heads-up!
That didn't turn out so bad. Pixel tests turned on as of r27839. The first batch had failures http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4417/steps/webkit_tests/logs/stdio but the second one had just a timeout: http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20%28dbg%29%281%29/builds/4845/steps/webkit_tests/logs/stdio I think that'll do it. Let's let this run for a few cycles and throw flaky tests into the expectations. Avi On Fri, Oct 2, 2009 at 9:52 AM, Avi Drissman a...@google.com wrote: I'm turning on the Mac pixel tests today. There's two parts to this. First is the new expectations (http://codereview.chromium.org/249043) which just adds IMAGE failures and won't affect anything. The second is telling the bots to run the pixel tests (http://codereview.chromium.org/242099) and that might be an issue. If everything goes as planned, no one will notice. If things do not go as planned, the first build after the second checkin might fail with pixel issues. If that happens, blame me. Avi --~--~-~--~~~---~--~~ 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: Turning on Mac pixel tests! Heads-up!
Avi, thanks! We should also keep an eye on the cycle times for the bots to see how much more time they take with the pixel tests enabled. TVL On Fri, Oct 2, 2009 at 11:55 AM, Avi Drissman a...@google.com wrote: That didn't turn out so bad. Pixel tests turned on as of r27839. The first batch had failures http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4417/steps/webkit_tests/logs/stdio but the second one had just a timeout: http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20%28dbg%29%281%29/builds/4845/steps/webkit_tests/logs/stdio I think that'll do it. Let's let this run for a few cycles and throw flaky tests into the expectations. Avi On Fri, Oct 2, 2009 at 9:52 AM, Avi Drissman a...@google.com wrote: I'm turning on the Mac pixel tests today. There's two parts to this. First is the new expectations (http://codereview.chromium.org/249043) which just adds IMAGE failures and won't affect anything. The second is telling the bots to run the pixel tests (http://codereview.chromium.org/242099) and that might be an issue. If everything goes as planned, no one will notice. If things do not go as planned, the first build after the second checkin might fail with pixel issues. If that happens, blame me. Avi --~--~-~--~~~---~--~~ 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: Debugging glibc malloc double free or corruption
The first step is usually to build a reduced test case. The MSNBC home page is pretty complex. Try removing things until you find the simplest thing that still exhibits the bug. Adam On Fri, Oct 2, 2009 at 7:32 AM, spotrh spo...@gmail.com wrote: A Fedora user recently reported that loading www.msnbc.com causes the Oh snap! and unhappy mac, which I was able to reproduce. The gory details are filed here: http://code.google.com/p/chromium/issues/detail?id=23635 I hate to just open bugs and say go fix it!, at least not without significantly narrowing down the problem. Does anyone have any suggestions on how to debug a glibc malloc double free or corruption error? I tried valgrind, but it gave up after 1000 errors. :/ ~spot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] FAIL not catching image failures
Latest Mac pixel test result is here: http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4420/steps/webkit_tests/logs/stdio : Regressions: Unexpected failures (2): LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL LayoutTests/svg/hixie/error/012.xml = FAIL Those are both image mismatches, but are both accounted for in the expectations file: // Flaky. The width of containing RenderBlocks sometimes becomes larger BUG21958 WIN MAC LINUX DEBUG : LayoutTests/svg/hixie/error/012.xml = FAIL PASS and // Regressions from WebKit Merge 42932:42994 BUG11239 MAC DEBUG : LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL PASS Why is the FAIL in those lines not catching the image failure? Avi --~--~-~--~~~---~--~~ 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: FAIL not catching image failures
I think that's a Release builder, and the tests are marked DEBUG, no? Stephen On Fri, Oct 2, 2009 at 12:34 PM, Avi Drissman a...@google.com wrote: Latest Mac pixel test result is here: http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4420/steps/webkit_tests/logs/stdio : Regressions: Unexpected failures (2): LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL LayoutTests/svg/hixie/error/012.xml = FAIL Those are both image mismatches, but are both accounted for in the expectations file: // Flaky. The width of containing RenderBlocks sometimes becomes larger BUG21958 WIN MAC LINUX DEBUG : LayoutTests/svg/hixie/error/012.xml = FAIL PASS and // Regressions from WebKit Merge 42932:42994 BUG11239 MAC DEBUG : LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL PASS Why is the FAIL in those lines not catching the image failure? Avi -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Try server follow up
The windows slaves are really having a hard time to compile, if it fails, just try again :( The command is or s/gcl/git/: gcl try foo --bot win In the short term, I'm disabling debug info on windows so they are at least somewhat useful. I'll probably restart the master in the middle of the day to fix this though. M-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] Build failure
Hi All, I tried to build chromium by following the Windows Build Instructions for the first time today :). But unfortunately after opening the chrome.sln file when I build the project, I got three build errors. All the build errors reported the same problem The binary is not a valid windows image Build O/P snippet: 4-- Build started: Project: chrome_dll, Configuration: Debug Win32 -- 4Embedding manifest... 4mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file .\Debug\chrome.dll. The binary is not a valid Windows image. 4Build log was saved at file://C:\Bala\chromium\chromium.r27598\home \chrome-svn\tarball\chromium\src\chrome\Debug\obj\chrome_dll \BuildLog.htm 4chrome_dll - 1 error(s), 0 warning(s) 5-- Build started: Project: generate_profile, Configuration: Debug Win32 -- 5Embedding manifest... 5mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file .\Debug\generate_profile.exe. The binary is not a valid Windows image. 5Build log was saved at file://C:\Bala\chromium\chromium.r27598\home \chrome-svn\tarball\chromium\src\chrome\Debug\obj\generate_profile \BuildLog.htm 5generate_profile - 1 error(s), 0 warning(s) . . 7-- Build started: Project: browser_tests_dll, Configuration: Debug Win32 -- 7Embedding manifest... 7mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file .\Debug\browser_tests.dll. The binary is not a valid Windows image. 7Build log was saved at file://C:\Bala\chromium\chromium.r27598\home \chrome-svn\tarball\chromium\src\chrome\Debug\obj\browser_tests_dll \BuildLog.htm 7browser_tests_dll - 1 error(s), 0 warning(s) After googling I found this link http://www.wintellect.com/CS/blogs/ jrobbins/archive/2009/01/24/the-case-of-the-corrupt-pe- binaries.aspx. The workaround as stated in the blog is to change linker option from / DYNAMICBASE:NO to /DYNAMICBASE. But the projects which reported errors (chrome_dll, generate_profile and browser_test_dll) all have their linker option set to /DYNAMICBASE only. So, please let me know how to resolve this build error? Waiting avidly for your reply :) Thanks, Bala. --~--~-~--~~~---~--~~ 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: Extracting Webkit Test Shell and its dependencies
Also you should get webkit/tools/tests_shell.sln -BradN On Thu, Oct 1, 2009 at 10:45 AM, Peter Kasting pkast...@google.com wrote: On Wed, Sep 30, 2009 at 4:06 AM, plafayette pierre.lafaye...@gmail.comwrote: Is there a good, and less painful, way to extract test_shell into its own project? I don't understand. test_shell already is its own project (.vcproj). 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] Jank: performance and animation frame rates
[from correct addr this time] I've noticed that most animation frame rates in chrome are hard-coded to values around 50 or 60. Certainly 50 or 60 is a good upper bound and there's no point in going higher. But when the system is under load or is just plain slow to begin with, having a value this high can make the animation come out jankier. It would be nice to have some mechanism for telling the animation we are done with the last update, ready for another. I don't see any way of doing this on Windows, and I know it doesn't happen on Linux. Maybe it happens implicitly somewhere on Windows. Anyone know? But for GTK at least, I'm pretty sure that if you have a 1 second animation at 60 hz then you will get 60 re-layouts (paint events might get collapsed). When the download shelf is opening in particular this can be really ugly (between the download started animation, the opening of the shelf, the resizing of the download item, and the cranking of the progress circle, there's a lot going on), and I believe the animation winds up taking much longer than you actually asked it to. Would it be profitable to try adding a function call to Animation that just says I'm done with the last update, hit me again -- Evan Stade --~--~-~--~~~---~--~~ 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: Build failure
On Thu, Oct 1, 2009 at 10:02 PM, Bala balaraj...@gmail.com wrote: Hi All, I tried to build chromium by following the Windows Build Instructions for the first time today :). But unfortunately after opening the chrome.sln file when I build the project, I got three build errors. All the build errors reported the same problem The binary is not a valid windows image Build O/P snippet: 4-- Build started: Project: chrome_dll, Configuration: Debug Win32 -- 4Embedding manifest... 4mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file .\Debug\chrome.dll. The binary is not a valid Windows image. It turns out this failure is usually caused by anti-virus software activities. Disable it from scanning the source dir and try again. Huan 4Build log was saved at file://C:\Bala\chromium\chromium.r27598\home \chrome-svn\tarball\chromium\src\chrome\Debug\obj\chrome_dll \BuildLog.htm 4chrome_dll - 1 error(s), 0 warning(s) 5-- Build started: Project: generate_profile, Configuration: Debug Win32 -- 5Embedding manifest... 5mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file .\Debug\generate_profile.exe. The binary is not a valid Windows image. 5Build log was saved at file://C:\Bala\chromium\chromium.r27598\home \chrome-svn\tarball\chromium\src\chrome\Debug\obj\generate_profile \BuildLog.htm 5generate_profile - 1 error(s), 0 warning(s) . . 7-- Build started: Project: browser_tests_dll, Configuration: Debug Win32 -- 7Embedding manifest... 7mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file .\Debug\browser_tests.dll. The binary is not a valid Windows image. 7Build log was saved at file://C:\Bala\chromium\chromium.r27598\home \chrome-svn\tarball\chromium\src\chrome\Debug\obj\browser_tests_dll \BuildLog.htm 7browser_tests_dll - 1 error(s), 0 warning(s) After googling I found this link http://www.wintellect.com/CS/blogs/ jrobbins/archive/2009/01/24/the-case-of-the-corrupt-pe- binaries.aspx. The workaround as stated in the blog is to change linker option from / DYNAMICBASE:NO to /DYNAMICBASE. But the projects which reported errors (chrome_dll, generate_profile and browser_test_dll) all have their linker option set to /DYNAMICBASE only. So, please let me know how to resolve this build error? Waiting avidly for your reply :) Thanks, Bala. --~--~-~--~~~---~--~~ 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: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 11:57 AM, Evan Stade est...@chromium.org wrote: It would be nice to have some mechanism for telling the animation we are done with the last update, ready for another. AFAIK this is already what effectively happens. We try to fire the timer rapidly, but if we get bogged down, it just won't fire until later; when it actually does fire, we update our state based on how much time has really passed instead of how many times the timer has triggered. Maybe, though, what you're seeing is that we don't bog down on the UI thread where the timer is firing, so we end up doing a lot of updates, but these updates can (for some animations) create a backlog of events on other threads/processes, which may take a while to be dealt with? I'm not sure how to deal with this other than to create a separate queue of events triggered by animations and let later updates overwrite earlier ones that haven't yet been processed; that would be really hard to plumb, though. 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] buildbot failure in Chromium on Modules XP (dbg), revision 27876
Automatically closing tree for net_unittests on Modules XP (dbg) http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16419 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29 --= Automatically closing tree for net_unittests on Modules XP (dbg) =-- Revision: 27876 Blame list: robertshi...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on XP Tests (dbg)(1), revision 27876
Automatically closing tree for installer_util_unittests on XP Tests (dbg)(1) http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests%20%28dbg%29%281%29/builds/13092 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests%20%28dbg%29%281%29 --= Automatically closing tree for installer_util_unittests on XP Tests (dbg)(1) =-- Revision: 27876 Blame list: robertshi...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on XP Tests, revision 27879
Automatically closing tree for installer_util_unittests on XP Tests http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12838 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests --= Automatically closing tree for installer_util_unittests on XP Tests =-- Revision: 27879 Blame list: a...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ 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: Jank: performance and animation frame rates
We try to fire the timer rapidly, but if we get bogged down, it just won't fire until later; when it actually does fire, we update our state based on how much time has really passed instead of how many times the timer has triggered. In this case, something is not working as expected (at least on Linux), because when I test on the download shelf slide animation, the number of AnimationProgressed calls is exactly what one would calculate based on the frame rate and duration, even if I put a Sleep(1000) in the middle of the callback. Reading the Animation code, it seems the number of iterations is hard coded at the start: iteration_count_ = duration_ / timer_interval_; So we don't update our state on how much time has actually passed, we update it based on the number of times the timer has fired. It would be easy enough to fix this to do as you say while only touching the Animation class, although on a very bogged down machine the effect would be that instead of having some slow-looking animation we have a jerky (but fast!) animation. I personally think that trade-off is worth it, maybe others don't? I'm not sure how to deal with this other than to create a separate queue of events triggered by animations and let later updates overwrite earlier ones that haven't yet been processed; that would be really hard to plumb, though. Hmm, why would we need a separate queue for that? Seems we could search for other animation events when dequeueing an animation event on the normal message loop. But the above fix seems cleaner/safer anyway. --~--~-~--~~~---~--~~ 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: FAIL not catching image failures
Stephen's right; if that doesn't fix things, let me know and I'll look at it. -- Dirk On Fri, Oct 2, 2009 at 9:59 AM, Stephen White senorbla...@chromium.org wrote: I think that's a Release builder, and the tests are marked DEBUG, no? Stephen On Fri, Oct 2, 2009 at 12:34 PM, Avi Drissman a...@google.com wrote: Latest Mac pixel test result is here: http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4420/steps/webkit_tests/logs/stdio: Regressions: Unexpected failures (2): LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL LayoutTests/svg/hixie/error/012.xml = FAIL Those are both image mismatches, but are both accounted for in the expectations file: // Flaky. The width of containing RenderBlocks sometimes becomes larger BUG21958 WIN MAC LINUX DEBUG : LayoutTests/svg/hixie/error/012.xml = FAIL PASS and // Regressions from WebKit Merge 42932:42994 BUG11239 MAC DEBUG : LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL PASS Why is the FAIL in those lines not catching the image failure? Avi -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ 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: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote: In this case, something is not working as expected (at least on Linux), because when I test on the download shelf slide animation, the number of AnimationProgressed calls is exactly what one would calculate based on the frame rate and duration, even if I put a Sleep(1000) in the middle of the callback. That sounds very wrong. Please treat that as a bug. I'm not sure how to deal with this other than to create a separate queue of events triggered by animations and let later updates overwrite earlier ones that haven't yet been processed; that would be really hard to plumb, though. Hmm, why would we need a separate queue for that? Seems we could search for other animation events when dequeueing an animation event on the normal message loop. But the above fix seems cleaner/safer anyway. I mean for eventstriggered by animation events. Let's say the download shelf animation resizes the download shelf, which resizes the content area, which sends a message to the renderer to relayout at the new size. Now the renderer process his a resize cued up that in theory should be canceled by a future resize from the animation but in practice wouldn't be. Of course this example is bogus because IIRC the renderer already collapses resize requests, to deal with mases like moving the mouse around a lot while resizing. 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] buildbot failure in Chromium on Linux Builder (Views dbg), revision 27890
Automatically closing tree for compile on Linux Builder (Views dbg) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28Views%20dbg%29/builds/1701 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28Views%20dbg%29 --= Automatically closing tree for compile on Linux Builder (Views dbg) =-- Revision: 27890 Blame list: pkast...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ 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: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote: We try to fire the timer rapidly, but if we get bogged down, it just won't fire until later; when it actually does fire, we update our state based on how much time has really passed instead of how many times the timer has triggered. In this case, something is not working as expected (at least on Linux), because when I test on the download shelf slide animation, the number of AnimationProgressed calls is exactly what one would calculate based on the frame rate and duration, even if I put a Sleep(1000) in the middle of the callback. Reading the Animation code, it seems the number of iterations is hard coded at the start: iteration_count_ = duration_ / timer_interval_; So we don't update our state on how much time has actually passed, we update it based on the number of times the timer has fired. It would be easy enough to fix this to do as you say while only touching the Animation class, although on a very bogged down machine the effect would be that instead of having some slow-looking animation we have a jerky (but fast!) animation. I personally think that trade-off is worth it, maybe others don't? I also agree this is the better tradeoff. Better to have a jerky animation than slowing the machine even more. I'm not sure how to deal with this other than to create a separate queue of events triggered by animations and let later updates overwrite earlier ones that haven't yet been processed; that would be really hard to plumb, though. Hmm, why would we need a separate queue for that? Seems we could search for other animation events when dequeueing an animation event on the normal message loop. But the above fix seems cleaner/safer anyway. --~--~-~--~~~---~--~~ 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: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 2:02 PM, John Abd-El-Malek j...@chromium.org wrote: On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote: We try to fire the timer rapidly, but if we get bogged down, it just won't fire until later; when it actually does fire, we update our state based on how much time has really passed instead of how many times the timer has triggered. In this case, something is not working as expected (at least on Linux), because when I test on the download shelf slide animation, the number of AnimationProgressed calls is exactly what one would calculate based on the frame rate and duration, even if I put a Sleep(1000) in the middle of the callback. Reading the Animation code, it seems the number of iterations is hard coded at the start: iteration_count_ = duration_ / timer_interval_; So we don't update our state on how much time has actually passed, we update it based on the number of times the timer has fired. It would be easy enough to fix this to do as you say while only touching the Animation class, although on a very bogged down machine the effect would be that instead of having some slow-looking animation we have a jerky (but fast!) animation. I personally think that trade-off is worth it, maybe others don't? I also agree this is the better tradeoff. Better to have a jerky animation than slowing the machine even more. From the 3D Graphics background: when skipping frames, time-driven animations feel infinitely less jerky than frame-driven ones. I think it's mostly the same with video. I.E. use time, not ticks. Antoine --~--~-~--~~~---~--~~ 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: Q about closing valgrind issues
So I got a reply from Apple saying this should be fixed in Snow Leopard. Is it closable? Certainly keep it in the suppression list until we upgrade the bots. Avi On Wed, Sep 23, 2009 at 12:46 AM, Erik Kay erik...@chromium.org wrote: I didn't say it would be easy. ;-) I also wouldn't be surprised if window position varied across unit test runs. I think my main point here wasn't to drop everything you're doing to track this down. I'm just saying that it's a dangerous bug to throw into the supression list and forget about. Erik On Tue, Sep 22, 2009 at 11:11 AM, Avi Drissman a...@google.com wrote: If this is caught in the unit tests ~1/30 times, then it's happening despite the window positionings and view positionings being the same. There's multiple layers of indirection in there (two context types, four libraries) all totally closed source. Tracking it down feels like it would take way too much effort and I'm swamped. If you have some spare time... Avi On Tue, Sep 22, 2009 at 11:56 AM, Erik Kay erik...@chromium.org wrote: I'd suspect an alignment / positioning bug for what you're seeing. Often rect fill algorithms have several paths with different loop unrolling tricks based on the size and position of the rect. I agree with Evan that it may be worth tracking this down a bit more. Even if it's not our bug, we need to find a way to avoid the memory stomping. I'm nervous about adding this to the upstream suppression list. I think that's OK to do for memory leaks, or for memory errors where it's been demonstrated that the result of the error is benign (like the UMRs in parts of Microsoft's STL implementation), but it doesn't seem like this fits into that case. Erik On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman a...@google.com wrote: I have no evidence to confirm/deny that. Even so it deserves an upstreaming. I'll look at it but why would it show up 1/30 times? Avi On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin e...@chromium.org wrote: Could it possibly be related to passing a zero-sized rect in somewhere? On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote: crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:26 PM, Ben Laurie b...@chromium.org wrote: zygote_host_linux.cc creates a socketpair using SOCK_SEQPACKET rather than the more usual SOCK_STREAM? Before I trawl through code, does anyone know why? This is a problem for the FreeBSD port: FreeBSD doesn't support SOCK_SEQPACKET for unix domain sockets... SOCK_STREAM certainly won't work, but SOCK_DGRAM should be fine. There was some concern that a renderer could use sendto on a SOCK_DGRAM to direct packets to other destinations. However, when created with socketpair, this isn't an issue as I recall. AGL --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:30 PM, Adam Langley a...@chromium.org wrote: There was some concern that a renderer could use sendto on a SOCK_DGRAM to direct packets to other destinations. However, when created with socketpair, this isn't an issue as I recall. Wait a minute. Idiot alert; I got that wrong. It *is* an issue with SOCK_DGRAM, which is why we're using SEQPACKET. So, if you change it to DGRAM for FreeBSD, please make sure that it's still SEQPACKET on Linux. Cheers AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Why SOCK_SEQPACKET?
zygote_host_linux.cc creates a socketpair using SOCK_SEQPACKET rather than the more usual SOCK_STREAM? Before I trawl through code, does anyone know why? This is a problem for the FreeBSD port: FreeBSD doesn't support SOCK_SEQPACKET for unix domain sockets... --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:30 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:26 PM, Ben Laurie b...@chromium.org wrote: zygote_host_linux.cc creates a socketpair using SOCK_SEQPACKET rather than the more usual SOCK_STREAM? Before I trawl through code, does anyone know why? This is a problem for the FreeBSD port: FreeBSD doesn't support SOCK_SEQPACKET for unix domain sockets... SOCK_STREAM certainly won't work, but SOCK_DGRAM should be fine. Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There was some concern that a renderer could use sendto on a SOCK_DGRAM to direct packets to other destinations. However, when created with socketpair, this isn't an issue as I recall. AGL --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. AGL --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
BTW I think this API (and the associated registerContentHandler) aren't that great... imagine a feed reader that wants to handle feed types and feed protocol links... do they need to call these functions one per protocol scheme and per feed content type (there are several), showing a UI for each? This sort of thing seems better handled through some kind of manifest. -Ben On Thu, Oct 1, 2009 at 8:06 PM, Darin Fisher da...@chromium.org wrote: I've added this to my list for review by the group. -Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ 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: Q about closing valgrind issues
I'd say when we verify and remove the suppression, it's closable. From a triage perspective, I think it's fine to lower priority, etc. Erik On Fri, Oct 2, 2009 at 2:11 PM, Avi Drissman a...@google.com wrote: So I got a reply from Apple saying this should be fixed in Snow Leopard. Is it closable? Certainly keep it in the suppression list until we upgrade the bots. Avi On Wed, Sep 23, 2009 at 12:46 AM, Erik Kay erik...@chromium.org wrote: I didn't say it would be easy. ;-) I also wouldn't be surprised if window position varied across unit test runs. I think my main point here wasn't to drop everything you're doing to track this down. I'm just saying that it's a dangerous bug to throw into the supression list and forget about. Erik On Tue, Sep 22, 2009 at 11:11 AM, Avi Drissman a...@google.com wrote: If this is caught in the unit tests ~1/30 times, then it's happening despite the window positionings and view positionings being the same. There's multiple layers of indirection in there (two context types, four libraries) all totally closed source. Tracking it down feels like it would take way too much effort and I'm swamped. If you have some spare time... Avi On Tue, Sep 22, 2009 at 11:56 AM, Erik Kay erik...@chromium.org wrote: I'd suspect an alignment / positioning bug for what you're seeing. Often rect fill algorithms have several paths with different loop unrolling tricks based on the size and position of the rect. I agree with Evan that it may be worth tracking this down a bit more. Even if it's not our bug, we need to find a way to avoid the memory stomping. I'm nervous about adding this to the upstream suppression list. I think that's OK to do for memory leaks, or for memory errors where it's been demonstrated that the result of the error is benign (like the UMRs in parts of Microsoft's STL implementation), but it doesn't seem like this fits into that case. Erik On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman a...@google.com wrote: I have no evidence to confirm/deny that. Even so it deserves an upstreaming. I'll look at it but why would it show up 1/30 times? Avi On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin e...@chromium.org wrote: Could it possibly be related to passing a zero-sized rect in somewhere? On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote: crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. Ah, I see. Hmmm. --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
I totally agree. I envision it being something much more like RSS feeds. In my mind, it should always advertise itself to the browser and then the browser should decide how to advertise it to the user. Requiring scripts to initiate things seems silly to me. Is this API even part of any standard? Maybe we should bring this up on WhatWG? On Fri, Oct 2, 2009 at 2:43 PM, Ben Goodger (Google) b...@chromium.orgwrote: BTW I think this API (and the associated registerContentHandler) aren't that great... imagine a feed reader that wants to handle feed types and feed protocol links... do they need to call these functions one per protocol scheme and per feed content type (there are several), showing a UI for each? This sort of thing seems better handled through some kind of manifest. -Ben On Thu, Oct 1, 2009 at 8:06 PM, Darin Fisher da...@chromium.org wrote: I've added this to my list for review by the group. -Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) 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: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. 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: [DESIGN DOC] registerProtocolHandler HTML5 API
I had included the link to the specification in the design document: http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler -brad On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: I totally agree. I envision it being something much more like RSS feeds. In my mind, it should always advertise itself to the browser and then the browser should decide how to advertise it to the user. Requiring scripts to initiate things seems silly to me. Is this API even part of any standard? Maybe we should bring this up on WhatWG? On Fri, Oct 2, 2009 at 2:43 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I think this API (and the associated registerContentHandler) aren't that great... imagine a feed reader that wants to handle feed types and feed protocol links... do they need to call these functions one per protocol scheme and per feed content type (there are several), showing a UI for each? This sort of thing seems better handled through some kind of manifest. -Ben On Thu, Oct 1, 2009 at 8:06 PM, Darin Fisher da...@chromium.org wrote: I've added this to my list for review by the group. -Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ 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: Jank: performance and animation frame rates
On Fri, Oct 2, 2009 at 2:07 PM, Antoine Labour pi...@google.com wrote: On Fri, Oct 2, 2009 at 2:02 PM, John Abd-El-Malek j...@chromium.org wrote: On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote: We try to fire the timer rapidly, but if we get bogged down, it just won't fire until later; when it actually does fire, we update our state based on how much time has really passed instead of how many times the timer has triggered. In this case, something is not working as expected (at least on Linux), because when I test on the download shelf slide animation, the number of AnimationProgressed calls is exactly what one would calculate based on the frame rate and duration, even if I put a Sleep(1000) in the middle of the callback. Reading the Animation code, it seems the number of iterations is hard coded at the start: iteration_count_ = duration_ / timer_interval_; So we don't update our state on how much time has actually passed, we update it based on the number of times the timer has fired. It would be easy enough to fix this to do as you say while only touching the Animation class, although on a very bogged down machine the effect would be that instead of having some slow-looking animation we have a jerky (but fast!) animation. I personally think that trade-off is worth it, maybe others don't? I also agree this is the better tradeoff. Better to have a jerky animation than slowing the machine even more. From the 3D Graphics background: when skipping frames, time-driven animations feel infinitely less jerky than frame-driven ones. I think it's mostly the same with video. I.E. use time, not ticks. Antoine FYI: http://codereview.chromium.org/257038/show --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 02, 2009 at 02:45:21PM -0700, Ben Laurie wrote: On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. Ah, I see. Hmmm. The Linux send(2) man page explicitly says the message is all-or-nothing, and the SUS entry seems to indicate the same thing, though not as clearly, so that framing protocol can probably just be [lengthdata]* Still more complicated than having the socket layer do it though. -- Jacob --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote: There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. The Linux send(2) man page explicitly says the message is all-or-nothing, and the SUS entry seems to indicate the same thing, though not as clearly, so that framing protocol can probably just be [lengthdata]* Still more complicated than having the socket layer do it though. And SOCK_SEQPACKET is atomic, but simulating it with lengthdata isn't, so the simulation might break down with multiple concurrent writers. --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote: The Linux send(2) man page explicitly says the message is all-or-nothing, I don't think so. It says: If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted. I think the confusion is that the underlying protocol for SOCK_STREAM isn't atomic. The description of the error is clearer: EMSGSIZE: The socket type requires that message be sent atomically, and the size of the message to be sent made this impossible. AGL --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 02, 2009 at 03:48:02PM -0700, Adam Langley wrote: On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote: The Linux send(2) man page explicitly says the message is all-or-nothing, I don't think so. It says: If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted. I think the confusion is that the underlying protocol for SOCK_STREAM isn't atomic. The description of the error is clearer: EMSGSIZE: The socket type requires that message be sent atomically, and the size of the message to be sent made this impossible. It also says: When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-block‐ ing I/O mode. In non-blocking mode it would return EAGAIN in this case. Which reads like all or nothing to me, though I could imagine a (perverse?) implementation with each writer having a send buffer lower layer pulling data from multiple writers' send buffers in an interleaved manner. (But maybe there's something else which restricts sockets to a single send buffer.) -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium Builder, revision 27910
Automatically closing tree for compile on Chromium Builder http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/16572 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder --= Automatically closing tree for compile on Chromium Builder =-- Revision: 27910 Blame list: nsylv...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. 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] buildbot failure in Chromium on Chromium Builder (dbg), revision 0
Automatically closing tree for compile on Chromium Builder (dbg) http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/11423 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29 --= Automatically closing tree for compile on Chromium Builder (dbg) =-- Revision: Blame list: Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 4:02 PM, Jacob Mandelson ja...@mandelson.org wrote:
Which reads like all or nothing to me, though I could imagine a (perverse?)
implementation with each writer having a send buffer lower layer pulling
data from multiple writers' send buffers in an interleaved manner. (But
maybe there's something else which restricts sockets to a single send buffer.)
http://www.opengroup.org/onlinepubs/95399/functions/write.html
says
An attempt to write to a pipe or FIFO has several major characteristics:
Atomic/non-atomic: A write is atomic if the whole amount written in
one operation is not interleaved with data from any other process.
This is useful when there are multiple writers sending data to a
single reader. Applications need to know how large a write request can
be expected to be performed atomically. This maximum is called
{PIPE_BUF}. This volume of IEEE Std 1003.1-2001 does not say whether
write requests for more than {PIPE_BUF} bytes are atomic, but requires
that writes of {PIPE_BUF} or fewer bytes shall be atomic.
(I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.)
and
If fildes refers to a socket, write() shall be equivalent to send()
with no flags set.
So there is at least some cause to worry about data interleaving
between processes
without the fancy SOCK_SEQPACKET.
--~--~-~--~~~---~--~~
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: [DESIGN DOC] registerProtocolHandler HTML5 API
That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 4:20 PM, Dan Kegel d...@kegel.com wrote: (I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.) I seem to recall that pipe buf is a page and /usr/include/linux/limits.h says #define PIPE_BUF4096 -- Steve --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
I don't think Hixie was a huge fan of it iirc ;-) He didn't like the idea of installing webapps... though that's just a UA defined semantic. -Ben On Fri, Oct 2, 2009 at 4:23 PM, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.org wrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. 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: [DESIGN DOC] registerProtocolHandler HTML5 API
BTW this is something that we want to pursue independently of whether or not it's in HTML5... we already have app frames/app shortcuts, we would like to streamline this some. If someone wants to work with other vendors to come up with a standardized version great, so long as the UA controls the UX and can extend the feature set in a compatible way. -Ben On Fri, Oct 2, 2009 at 4:29 PM, Ben Goodger (Google) b...@chromium.org wrote: I don't think Hixie was a huge fan of it iirc ;-) He didn't like the idea of installing webapps... though that's just a UA defined semantic. -Ben On Fri, Oct 2, 2009 at 4:23 PM, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.org wrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. 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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 4:25 PM, Steve Vandebogart vand...@chromium.org wrote: (I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.) I seem to recall that pipe buf is a page and /usr/include/linux/limits.h says #define PIPE_BUF 4096 Yeah, I got PIPE_BUF and pipe capacity mixed up. man 7 pipe set me straight. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Modules XP (dbg), revision 27921
Automatically closing tree for net_unittests on Modules XP (dbg) http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16452 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29 --= Automatically closing tree for net_unittests on Modules XP (dbg) =-- Revision: 27921 Blame list: atwil...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ 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: Try server follow up
The windows try slaves are now back up with the symbols disabled. A side-effect is that process dump will always be red, since the symbols cannot be found. I'll remove this step soon. M-A On Fri, Oct 2, 2009 at 1:10 PM, Marc-Antoine Ruel mar...@chromium.org wrote: The windows slaves are really having a hard time to compile, if it fails, just try again :( The command is or s/gcl/git/: gcl try foo --bot win In the short term, I'm disabling debug info on windows so they are at least somewhat useful. I'll probably restart the master in the middle of the day to fix this though. M-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] buildbot failure in Chromium on Webkit Builder (dbg), revision 27930
Automatically closing tree for compile on Webkit Builder (dbg) http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Builder%20%28dbg%29/builds/17198 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Builder%20%28dbg%29 --= Automatically closing tree for compile on Webkit Builder (dbg) =-- Revision: 27930 Blame list: bre...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromeOS), revision 27937
Automatically closing tree for compile on Linux Builder (ChromeOS) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/3966 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29 --= Automatically closing tree for compile on Linux Builder (ChromeOS) =-- Revision: 27937 Blame list: bre...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromeOS), revision 27938
Automatically closing tree for compile on Linux Builder (ChromeOS) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/3967 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29 --= Automatically closing tree for compile on Linux Builder (ChromeOS) =-- Revision: 27938 Blame list: atwil...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 27939
Automatically closing tree for check deps on Chromium XP http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/7758 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP --= Automatically closing tree for check deps on Chromium XP =-- Revision: 27939 Blame list: bre...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
