[chromium-dev] Re: Chromium WebKit.org builder is now live
Nice work! Seems like a good thing to post to webkit-dev too :)-Darin On Tue, Sep 8, 2009 at 8:50 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Dear Chromiumites and friends of the show, We now have a builder upstream that builds Chromium webkit port: http://build.webkit.org/waterfall (look to the very right of the columns). Granted, the road to the actual complete Chromium WebKit port is still long and winding (https://trac.webkit.org/wiki/Chromium), since this builder simply builds the webcore project in the Chromium repository (kudos to nice WebKit folks allowed us to modify their master config to patch in Chromium-specific gclient sync and compile.py commands for us). Nevertheless, it's progress. Now you can watch all things WebKit blow up faster than ever before! :) More entertainment is coming soon to your ... whatever you're reading this on. :DG --~--~-~--~~~---~--~~ 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: WebKit Chromium Port
On Wed, Sep 9, 2009 at 2:47 PM, Eric Seidel esei...@chromium.org wrote: On Tue, Sep 8, 2009 at 10:39 PM, Jeremy Orlow jor...@chromium.org wrote: If it does work, we could definitely let them know it's an option for those who might want to. We'd have to phrase it delicately though. They're generally quite allergic to us even coming _close_ to pushing our infrastructure on them. Google has it's own fair dose of not invented here. :) True. WebKit has been quite receptive of the recent script additions we've made, including check-webkit-style (originally cpplint.py) which was entirely Google code. The entire commit-queue architecture they're now using was written by Google employed WebKit contributers (myself, Adam Barth and Dave Levin). I don't mean to pick a fight, but I just don't think this should be a we vs. they argument. Google employs 4 WebKit reviewers (myself, Adam Barth, Dimitri Glazkov and Darin Fisher). Reviewers tend to make the decisions in WebKit land. Furthermore, Apple tends to follow the saying code wins, meaning: given two ideas, one of which is coded and the other which is not the coded one wins. :) If a Googler produces functioning WebKit try bots, the WebKit community certainly isn't going to turn them down. I hope your right. I'm not convinced this is a given though. I think Google employed WebKit contributers should feel full license to set up try bots integrated with WebKit's buildbot. I think Googlers should also feel welcome to augment/replace parts of WebKit's buildbot architecture with our improved versions from build.webkit.org. This has not always been true in the past. I think we (people working on Chromium) made a good effort to help bring real code review infrastructure to WebKit and that was a disaster (though maybe I don't know the full story and we were in the wrong). I agree that things are getting better, but I don't think the picture is quite as rosy as you paint it. (And I know many who think I paint the picture rosier than it actually is.) --~--~-~--~~~---~--~~ 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: WebKit Chromium Port
On Tue, Sep 8, 2009 at 11:02 PM, Jeremy Orlow jor...@chromium.org wrote: This has not always been true in the past. I think we (people working on Chromium) made a good effort to help bring real code review infrastructure to WebKit and that was a disaster (though maybe I don't know the full story and we were in the wrong). Sounds like us vs them again. From what I saw in this case, things were done quickly without getting buy in. I saw at least one irc conversation in which folks had expressed their concerns about being asked about changes and then things done in less than an hour without giving time for a response. From this, it appeared to me that the effort may not have been handled in the best way. I have seen several WebKit reviewers who appear to be willing to consider a new code review tool, but there are lot of things to fix in the process, and there are a fair number of concerns about how some new would fit into the WebKit process. There was an email that outlined an approach to addressing process issues in WebKit, and it had evaluating new code review tools in there. I have also seen folks try to push chromium solutions on webkit in cases where it didn't make sense. This reminds me of the debates of git vs svn (or emacs vs vi, etc.). Each has their potential advantages, but adopting something new requires changes that may be painful so change takes time. Dave --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Windows trybot issue.
Hi, I tried a CL on trybot. Linux and Mac trybots finished without any problem very soon. But windows trybot spent more than 40 minutes to compile and failed with following error: Compiling... ui_test_utils.cc profile_sync_service_test_harness.cc Compiling resources... Linking... Creating library C:\b\slave\win\build\src\chrome\Debug\lib\sync_integration_tests.lib and object C:\b\slave\win\build\src\chrome\Debug\lib\sync_integration_tests.exp LINK : fatal error LNK1210: exceeded internal ILK size limit; link with /INCREMENTAL:NO Error executing link.exe (tool returned code: 1210) sync_integration_tests - 1 error(s), 0 warning(s) 1 build system warning(s): - PDB instance limit is enabled -- Done -- Build: 219 succeeded, 1 failed, 0 skippedprogram finished with exit code 1 Regards James Su --~--~-~--~~~---~--~~ 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: Windows trybot issue.
Please follow the instructions on the email you get from the try bot On Wed, Sep 9, 2009 at 8:55 PM, James Su su...@chromium.org wrote: Hi, I tried a CL on trybot. Linux and Mac trybots finished without any problem very soon. But windows trybot spent more than 40 minutes to compile and failed with following error: Compiling... ui_test_utils.cc profile_sync_service_test_harness.cc Compiling resources... Linking... Creating library C:\b\slave\win\build\src\chrome\Debug\lib\sync_integration_tests.lib and object C:\b\slave\win\build\src\chrome\Debug\lib\sync_integration_tests.exp LINK : fatal error LNK1210: exceeded internal ILK size limit; link with /INCREMENTAL:NO Error executing link.exe (tool returned code: 1210) sync_integration_tests - 1 error(s), 0 warning(s) 1 build system warning(s): - PDB instance limit is enabled -- Done -- Build: 219 succeeded, 1 failed, 0 skippedprogram finished with exit code 1 Regards James Su --~--~-~--~~~---~--~~ 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: Windows trybot issue.
I got a ping yesterday about a failed slave but I assumed it was still icu breakage so I just manually cleaned it. James did the right thing and replied to the email earlier today but I didn't realize all the try slaves needed a clobber until now. Since I had an errand, I couldn't do it before anyway. They should all be fixed now. M-A On Wed, Sep 9, 2009 at 9:32 AM, Mike Pinkertonpinker...@chromium.org wrote: I don't follow. Lots of people seem to be getting this error when they submit to the win trybot. What is he supposed to do that's specific to his CL when others see the same thing? On Wed, Sep 9, 2009 at 8:09 AM, Jeremy Orlowjor...@chromium.org wrote: Please follow the instructions on the email you get from the try bot On Wed, Sep 9, 2009 at 8:55 PM, James Su su...@chromium.org wrote: Hi, I tried a CL on trybot. Linux and Mac trybots finished without any problem very soon. But windows trybot spent more than 40 minutes to compile and failed with following error: Compiling... ui_test_utils.cc profile_sync_service_test_harness.cc Compiling resources... Linking... Creating library C:\b\slave\win\build\src\chrome\Debug\lib\sync_integration_tests.lib and object C:\b\slave\win\build\src\chrome\Debug\lib\sync_integration_tests.exp LINK : fatal error LNK1210: exceeded internal ILK size limit; link with /INCREMENTAL:NO Error executing link.exe (tool returned code: 1210) sync_integration_tests - 1 error(s), 0 warning(s) 1 build system warning(s): - PDB instance limit is enabled -- Done -- Build: 219 succeeded, 1 failed, 0 skipped program finished with exit code 1 Regards James Su -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Windows trybot issue.
I'm just following instructions: TRY FAILED *If you think the try slave is broken (it happens!), please REPLY to this email, don't ask on irc, mailing list or IM.* Thanks! I doubt emailing the list here asking what's up is going to help things much. Marc-Antoine is quite responsive about such issues. J On Wed, Sep 9, 2009 at 10:32 PM, Mike Pinkerton pinker...@chromium.orgwrote: I don't follow. Lots of people seem to be getting this error when they submit to the win trybot. What is he supposed to do that's specific to his CL when others see the same thing? On Wed, Sep 9, 2009 at 8:09 AM, Jeremy Orlowjor...@chromium.org wrote: Please follow the instructions on the email you get from the try bot On Wed, Sep 9, 2009 at 8:55 PM, James Su su...@chromium.org wrote: Hi, I tried a CL on trybot. Linux and Mac trybots finished without any problem very soon. But windows trybot spent more than 40 minutes to compile and failed with following error: Compiling... ui_test_utils.cc profile_sync_service_test_harness.cc Compiling resources... Linking... Creating library C:\b\slave\win\build\src\chrome\Debug\lib\sync_integration_tests.lib and object C:\b\slave\win\build\src\chrome\Debug\lib\sync_integration_tests.exp LINK : fatal error LNK1210: exceeded internal ILK size limit; link with /INCREMENTAL:NO Error executing link.exe (tool returned code: 1210) sync_integration_tests - 1 error(s), 0 warning(s) 1 build system warning(s): - PDB instance limit is enabled -- Done -- Build: 219 succeeded, 1 failed, 0 skipped program finished with exit code 1 Regards James Su -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] icu was upgraded to 4.2.1 : you want to clobber on Windows
Hi, I pulled in ICU 4.2.1 upgrade l http://codereview.chromium.org/172031ast night/this morning. To avoid link errors, you need to clobber your build on Windows. You may not hit upon link errors if icuuc.lib, icui18n.lib from the previous build in your build directory, but they need to be clobbered so that new ones will be built. Also make sure to remove src/third_party/icu38 directory. I hope this email is not too late and am sorry if some of you took had to scratch your heads about links errors blah_blah_3_8 symbols not found. In addition, C++ names in ICU always have to be qualified with 'icu::' as I wrote a couple of weeks ago. Our copy of ICU does not throw all C++ names into the global namespace any more, which is to avoid the name collision between our StringPiece and icu's StringPiece (they're different). Also, if you add a new gyp file that uses ICU, you have to use 'icu.gyp' instead of 'icu38.gyp'. We decided to use 'icu.gyp' (rather than icuNN.gyp) to avoid having to track down them all and change next time we upgrade ICU. I haven't yet done the same with 'icudtNN.dll' on Windows, but perhaps I have to do that, too. Once again, sorry if this email is too late to prevent you from wasting some time today. Cheers, Jungshik --~--~-~--~~~---~--~~ 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: [Chrome-team] understanding layout test flakiness
I'm including at the top concrete tasks people can take to help identify and reduce flakiness. Read below for more details. 1. Mark slow tests as SLOW and reduce the timeout on the bots to 2 seconds. 2. Look into the cause of the timeouts on HTTP tests, especially on Mac/Windows 3. Look at the actual results off the bots for the non-timeout flaky failures and identify the cause of the flakiness (likely the test itself). 4. Make test_expectations.txt match what's actually happening on the bots (see the flakiness dashboard for tests with incorrect expectations). All the data I use below is from: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html On Tue, Sep 8, 2009 at 5:52 PM, David Levin le...@chromium.org wrote: I agree that the chromium buildbot seems to have more flakiness on layout tests that webkit buildbots. While there is definitely more flakiness, I'm not sure how much more. I think the Chromium bots are primarily more flaky on the HTTP tests. What flakiness there is gets less noticed on the webkit buildbots since they don't close the tree. Here's two things that may help us to understand this: 1. It would be nice to save crash logs from OSX into the zip file. For example, this run http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20(dbg)(2)/builds/3323/steps/webkit_tests/logs/stdio had a crash and likely generated a crash log at ~/Library/Logs/CrashReporter/TestShell*.crash which would help point to a culprit. +1 This would be very useful. That said, it won't benefit with decreasing flakiness much. Very few of the flaky tests are flaky crashers. They're almost entirely flaky timeouts or failures, even in debug builders. 2. If we suspect that tests may pass if given more time, then increase the timeout and see if more tests pass but exceed this old timeout (log something when this happens so we can validate that it is working). -1 The test dashboard prints the out the amount of time a test takes to run if it takes 1 second. I don't think the timing out tests would pass if we just gave them more time. Specifically, there are tests that always timeout and there are flaky timeout tests. The flaky timeout tests, when they do pass, consistently take less than 10 seconds to run, most of them take less than 1 second. Increasing the test timeout also *considerably* increases how long it takes for the bots to cycle. In fact, I think we should be *decreasing* it to something like 2 seconds. This would actually shave minutes off of the current bot cycle times. We have ~100 tests that are slow, many of which timeout at 20 seconds. We should mark all the slow, but passing tests as SLOW in the test expectations file. This will give them more time to run than the other tests. Then we should bring the timeout down to something like 2 seconds. This will make the bots run a lot faster and distinguish between the tests that timeout versus just taking a long time to pass. On Tue, Sep 8, 2009 at 5:41 PM, Dirk Pranke dpra...@chromium.org wrote: From what I've poked around at, many of the LayoutTest flaky failures are timeout-related. While more than half of the flaky tests on Windows and Mac are timeouts, many of them are crashes or failures. You can see this pretty clearly on the layout test dashboard. I'll note that on Linux, a very small percentage of the flakiness is timeouts. Almost all of these timeouts on Windows/Mac are HTTP tests. There is likely one or two causes for all the flakiness with the HTTP tests. There's something in the test harness and web server configurations that cause tests to be unpredictably slower. I don't think Apple has this problem, and I think that's because they use the built in apache instance in OS X, We switched away from apache to lighttp because of flakiness it was causing on cygwin (cygwin and apache don't play well together). Maybe it makes sense to use lighttp on Windows and Apache on Mac? I think we should identify the cause of the flakiness on Windows. Fixing that might fix the flakiness on Mac as well and we wouldn't need to support two http servers. and also because they have a very different model for test execution (how we run tests in parallel). Running tests in parallel did seem to make things a bit more flaky, but not much. I haven't verified this, but I think it probably just magnified existing flakiness by putting higher load on the machine. Linux, the least flaky bot, is the only bot that has 4 cores instead of just 2, which means it runs using more TestShell instances in parallel. --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
The main problem is that it doesn't work through NAT routers or firewalls, since it relies on the remote end opening a connection back to the client. There's no big advantage unless you're talking to an old FTP server that doesn't support passive FTP. --Amanda On Wed, Sep 9, 2009 at 1:53 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: This is http://code.google.com/p/chromium/issues/detail?id=3073 . I think it's not so hard to implement it (and probably not so high priority either), but are there any potential security (or other) problems? -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
On Wed, Sep 9, 2009 at 1:56 PM, Peter Kasting pkast...@google.com wrote: I can't think of any. It would be nice to have active support. I'm not sure how easy it is to auto-detect which one we should use (since all the FTP clients I've ever used have forced me to specify manually). It should be fairly easy. Send the PASV command--if the server sends back a failure result code, fall back on active FTP and send a PORT command. --Amanda --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
This is http://code.google.com/p/chromium/issues/detail?id=3073 . I think it's not so hard to implement it (and probably not so high priority either), but are there any potential security (or other) problems? I can't think of any. It would be nice to have active support. I'm not sure how easy it is to auto-detect which one we should use (since all the FTP clients I've ever used have forced me to specify manually). If it matters, Mozilla hasn't ever implemented Active FTP and is seriously considering making FTP a non-browseable protocol (you may browse and download files, but we won't render them in-browser). --BDS --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Just got a backtrace from flaky RenderViewTest
So, RenderViewTest crashes very often. Now, thanks to maruel, we have a stack trace: [--] 16 tests from RenderViewTest [ RUN ] RenderViewTest.OnLoadAlternateHTMLText Backtrace: GetStackFrames [0x00FF6085+306229] _sbrk [0x00A7E5EE+70254] _sbrk [0x00A7E63E+70334] _sbrk [0x00A7E763+70627] _sbrk [0x00AB052E+274862] _sbrk [0x00A7EA20+71328] _sbrk [0x00A7EE50+72400] _sbrk [0x00A7F747+74695] (No symbol) [0x00431868] MallocExtension::SetMemoryReleaseRate [0x00924756+2127654] MallocExtension::SetMemoryReleaseRate [0x00925699+2131561] MallocExtension::SetMemoryReleaseRate [0x0091FCB5+2108549] MallocExtension::SetMemoryReleaseRate [0x00925E93+2133603] MallocExtension::SetMemoryReleaseRate [0x00925FFC+2133964] MallocExtension::SetMemoryReleaseRate [0x008CF119+1777897] MallocExtension::SetMemoryReleaseRate [0x008CF34E+1778462] (No symbol) [0x005D66E9] RegisterWaitForInputIdle [0x7C817067+73] Does anyone have some ideas why is it failing? --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
On Wed, Sep 9, 2009 at 10:53 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: This is http://code.google.com/p/chromium/issues/detail?id=3073 . I think it's not so hard to implement it (and probably not so high priority either), but are there any potential security (or other) problems? Like with PASV, you need to do validation on the IP address. With PORT, when you accept the incoming connection, check that the IP address matches that of the control connection. Otherwise, an attacker could be racing with the real FTP server to send you a fake download. Cheers Chris --~--~-~--~~~---~--~~ 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: icu was upgraded to 4.2.1 : Please, clobber your build.
Yeah, it seems that in some cases, Mac/Linux also need clobber. Given these, I agree with Mike that it's best to clobber everywhere. Sorry again for the loss of the productivity. Jungshik 2009/9/9 Mike Pinkerton pinker...@chromium.org I had to clobber on Mac this morning as well. Go figure. Probably best to clobber everything everywhere. 2009/9/9 Jungshik Shin (신정식, 申政湜) js...@chromium.org: Hi, I pulled in ICU 4.2.1 upgrade last night/this morning. To avoid link errors, you need to clobber your build on Windows. You may not hit upon link errors if icuuc.lib, icui18n.lib from the previous build in your build directory, but they need to be clobbered so that new ones will be built. Also make sure to remove src/third_party/icu38 directory. I hope this email is not too late and am sorry if some of you took had to scratch your heads about links errors blah_blah_3_8 symbols not found. In addition, C++ names in ICU always have to be qualified with 'icu::' as I wrote a couple of weeks ago. Our copy of ICU does not throw all C++ names into the global namespace any more, which is to avoid the name collision between our StringPiece and icu's StringPiece (they're different). Also, if you add a new gyp file that uses ICU, you have to use 'icu.gyp' instead of 'icu38.gyp'. We decided to use 'icu.gyp' (rather than icuNN.gyp) to avoid having to track down them all and change next time we upgrade ICU. I haven't yet done the same with 'icudtNN.dll' on Windows, but perhaps I have to do that, too. Once again, sorry if this email is too late to prevent you from wasting some time today. Cheers, Jungshik -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
The bug is about a firewall forbidding the connection. Why the trick won't work? If I can't connect to the PASV port, I'd try PORT, even on successful PASV response. On Wed, Sep 9, 2009 at 12:52, Michal Zalewski lcam...@gmail.com wrote: I can't think of any. It would be nice to have active support. I'm not sure how easy it is to auto-detect which one we should use (since all the FTP clients I've ever used have forced me to specify manually). It should be fairly easy. Send the PASV command--if the server sends back a failure result code, fall back on active FTP and send a PORT command. Are we trying to solve the problem of the server having no passive FTP support (how common would that be?), or of the server's firewall / NAT device not having FTP traffic inspection helpers? If the latter, which I suspect might be marginally more common, just probing for PASV and falling over to active mode then is not going to do the trick. /mz --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
On Wed, Sep 9, 2009 at 4:02 PM, Michal Zalewski lcam...@gmail.com wrote: My reading of the bug is the former, since the latter would be fairly astonishing. Passive FTP does not require any special inspection by NAT, while active does. Likewise, passive mode requires inspection on client end if firewalls or NAT is present, but no inspection on server Hmm. NAT itself shouldn't require inspection (that's why PASV was created). But yes, if the firewall does not allow general outbound TCP, it would have to inspect the command connection just as it would in order to set up inbound rules for active FTP. That still strikes me as unlikely, but more data from the bug filer would be good. --Amanda --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
On Wed, Sep 9, 2009 at 3:52 PM, Michal Zalewski lcam...@gmail.com wrote: Are we trying to solve the problem of the server having no passive FTP support (how common would that be?), or of the server's firewall / NAT device not having FTP traffic inspection helpers? My reading of the bug is the former, since the latter would be fairly astonishing. Passive FTP does not require any special inspection by NAT, while active does. It's possible that they're using an application-level FTP proxy, but in that case, if it's what's enforcing active only, I'd expect it to reject the PASV command. But it wouldn't hurt to get more detail before we leap into it. --Amanda --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
On Wed, Sep 9, 2009 at 4:11 PM, Michal Zalewski lcam...@gmail.com wrote: Err, the other way round obviously (passive requires server-side support to rewrite IP and port data in FTP command responses behind NAT, and punch a temporary hole in the firewall allowing the client to connect back to the server on a high port; Er, shouldn't it just need to do the latter? I've certainly done plenty of passive FTP through NAT that isn't rewriting anything. active requires a client-side support to rewrite PORT command if behind NAT, and punch a hole for the server to connect back to the client). Right. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chromium SharedWorker design doc
Hi all, I've put together a design doc for my upcoming SharedWorker implementation. The original lives here: http://docs.google.com/a/chromium.org/Doc?id=dgfs7fcc_0f32q7xdd and I'll migrate it to dev.chromium.org once it's less draft-y. I'd appreciate any feedback - there are a few highlighted open issues (how do we report worker exceptions, how do we report unexpected worker process termination) that I'd be particularly interested in getting some input on. Thanks, -atw -=-=- Chromium SharedWorkers designThis document describes the Chromium implementation of SharedWorkers. A useful background document is the WebKit SharedWorkers Doc?docid=0AaSJ7ekxGiStZGNuazV2MnZfMThjYjI0M2hnNwhl=en design document, which goes into more depth about the differences between SharedWorkers and dedicated Workers and the underlying WebKit implementation/interfaces. Additionally, the HTML5 Web Workershttp://www.whatwg.org/specs/web-workers/current-work/#shared-workers specification contains the formal definition of SharedWorker behavior. OverviewSharedWorkershttp://www.whatwg.org/specs/web-workers/current-work/#shared-workers are similar to dedicated workers, but with a simplified interface and lifecycle definition. SharedWorkers do not need their own messaging implementations - instead, they use MessagePorts to communicate with their parents. Likewise, SharedWorkers do not need to report their pending activity back to their parents to enable garbage collection of unreferenced workers - instead, the lifecycle of SharedWorkers depends solely on the lifecycle of their parent documents and not on the reachability of the associated SharedWorker objects. Ultimately, we will adopt this same lifecycle mechanism for all workers, because the current reachability mechanism used for dedicated workers starts to break down when you have nested workers. The WebKit page-context code interacts with SharedWorkers via the SharedWorkerRepository class, which has a very simple interface: // Connects the passed SharedWorker object with the specified worker thread, creating a new thread if necessary. static void connect(PassRefPtrSharedWorker, PassOwnPtrMessagePortChannel, const KURL, const String name, ExceptionCode); // Invoked when a document has been detached. static void documentDetached(Document*); // Returns true if the passed document is associated with any SharedWorkers. static bool hasSharedWorkers(Document*); SharedWorker threads interact with the system through WorkerReportingProxy and WorkerLoaderProxy objects, just like the current dedicated Worker objects do. SharedWorkerRepositoryImplThe WebKit code is structured to allow different ports (like Chrome) to supply their own implementations of the SharedWorkerRepository interface (it consists only of a set of static functions). The Chromium implementation will split the SharedWorkerRepository implementation into two pieces: multiple SharedWorkerRepositoryImpl instances, one of which runs in each of the renderer processes as a singleton, and the WorkerService which runs in the browser process and controls the lifecycle of all SharedWorkers, and ensures that only a single instance of a given SharedWorker exists at any time. SharedWorkerRepositoryImpl::hasSharedWorkers()This is invoked by the FrameLoader code in WebKit to determine whether a given page is cacheable (for the purposes of the user clicking the back button) - essentially, a page is cacheable if it has ever created a SharedWorker (ideally, when all of a SharedWorker's pages are in the cache, we would suspend the worker, then resume it if the user goes back to the page). Since we cannot suspend workers, we treat Documents that have associated SharedWorkers as uncacheable. This is implemented by just keeping a HashMap of every document in the current process that has called SharedWorkerRepository::connect(), then returning true if the map contains an entry for a given document. When a document is detached (documentDetached() is called) we can remove it from the map. SharedWorkerRepositoryImpl::documentDetached() When a document is detached, we update our hasSharedWorkersHashMap as described previously. If the Document was in the hasSharedWorkersHashMap, we also notify the browser process via an IPC (passing the associated document_id - see below) so the WorkerService can shutdown any associated workers. SharedWorkerRepositoryImpl::connect() Invoked when the page script creates a SharedWorker via the SharedWorker() constructor. This makes a blocking ConnectToSharedWorker IPC to the SharedWorkerRepositoryHost to see if the SharedWorker already exists, and to validate the parameters (the HTML5 spec requires that we throw an exception if the client passes the wrong URL to a named SharedWorker, so this has to be a blocking call). The ConnectToSharedWorker IPC will have the following parameters: int message_port_route_id int document_id std::string script_url std::string
[chromium-dev] Re: WebKit Chromium Port
On Thu, Sep 10, 2009 at 2:10 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: Marc-Antoine, you will forever have a special place in every WebKit committer's heart if you can pull of setting up these trybots. +100 Given that this thread quickly discombobulated into a general WebKit rant, I want to wind it back to the topic: Yaar, I think your plan is good. Keep it coming. +1 And sorry about derailing things...was having a bad day. I'm not normally that pessimistic. :-) :DG On Wed, Sep 9, 2009 at 9:35 AM, Marc-Antoine Ruelmar...@chromium.org wrote: On Wed, Sep 9, 2009 at 1:19 AM, Ojan Vafaio...@chromium.org wrote: This is easily my biggest painpoint with doing webkit development. If I could just grab windows baselines off a trybot and not need to built/run tests on Windows for WebKit, I honestly think I would be order of magnitude more productive doing webkit patches. In fact, all I really want is a Windows trybot (a Mac one wouldn't hurt). You know how much I like patches. You should definitely create your how try server with a spare workstation. http://dev.chromium.org/developers/testing/chromium-build-infrastructure/getting-the-buildbot-source How hard would it be to just set these up ourselves on a chromium.orgsite for our own use? (obviously we'd make it available to the broader WebKit community) See https://bugs.webkit.org/show_bug.cgi?id=29062 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] Re: Are we going to support active FTP?
On Wed, Sep 9, 2009 at 4:31 PM, Michal Zalewski lcam...@gmail.com wrote: Well, let's say the server has an internal IP of 1.2.3.4, and along with several other nodes in its cluster, is publicly NATed to 4.3.2.1. The client says PASV, and the server, unless explicitly aware of its current public IP, replies along the lines of: 227 Entering Passive Mode (1,2,3,4,200,200) NAT device should rewrite this to 4,3,2,1, and may also need to tweak the port to avoid collisions with holes punched for other hosts. Ah, right. I was only considering the browser's point of view :-), since a server responding with an incorrect address would be broken from the point of view of the Internet. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Help needed reproducing a crash
I'm trying to track down a crash (bug 20511) which no one on the team has been able to figure out how to reproduce. If you ever have the browser crash on you right when you hit enter in the address bar, or when you hover the Go button, and can remember anything about what you were doing at the time, please add a comment to that bug or let me know. If you find a way to reproduce it on command, that would be super amazingly awesome. 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] Argh: Rebuilding installer_util on every F5
Somehow, starting today, I'm now rebuilding installer_util (recompiling a
half dozen files, which then causes me to relink chrome.dll) every time I
hit F5. Deleting chrome.{ncb,suo} and rm -rfing Debug/ and Release/ do not
help.
Did someone goof with these recently? Did the ICU change somehow touch
this? It makes my retest cycle a lot slower :(
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: Argh: Rebuilding installer_util on every F5
+maruel, who changed this code yesterday
Nicolas
On Wed, Sep 9, 2009 at 5:29 PM, Peter Kasting pkast...@google.com wrote:
Somehow, starting today, I'm now rebuilding installer_util (recompiling a
half dozen files, which then causes me to relink chrome.dll) every time I
hit F5. Deleting chrome.{ncb,suo} and rm -rfing Debug/ and Release/ do not
help.
Did someone goof with these recently? Did the ICU change somehow touch
this? It makes my retest cycle a lot slower :(
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: autolinking BUG= lines in Rietveld
Very nice, no longer I have to put crbug.com/#. Whoever did that autolink, can you support multiple bugs as well? The format bugdroid uses is BUG=1, 2, 3 - Mohamed Mansour On Wed, Sep 9, 2009 at 8:58 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: I just noticed that BUG=1234 lines are autolinked to the correct bug when viewed in Rietveld (codereview.chromium.org). This is very useful, thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] found corrupted db
Larson gave me a profile that can consistently crash windows chrome (beta). I haven't tried loading the profile myself but we have crash dumps from it. It crashes in: 0x69db6e5d [chrome.dll - fts2.c:453] getVarint --- access violation at 0x0 0x69db6ef0 [chrome.dll - fts2.c:468] getVarint32 0x69dbacbf [chrome.dll - fts2.c:5078] leavesReaderDataBytes 0x69dbb1d7 [chrome.dll - fts2.c:5407] segmentMerge 0x69dbb0f9 [chrome.dll - fts2.c:5359] segdirNextIndex 0x69dbba45 [chrome.dll - fts2.c:5932] writeZeroSegment 0x69dbbbf5 [chrome.dll - fts2.c:5966] flushPendingTerms 0x69dbbc3c [chrome.dll - fts2.c:5984] initPendingTerms 0x69dba135 [chrome.dll - fts2.c:4050] index_delete 0x69dbbca4 [chrome.dll - fts2.c:6005] fulltextUpdate 0x69dc284a [chrome.dll - vdbe.c:4945] sqlite3VdbeExec 0x69da170f [chrome.dll - vdbeapi.c:476]sqlite3Step 0x69da1856 [chrome.dll - vdbeapi.c:544]sqlite3_step 0x6a09c1ab [chrome.dll - text_database.cc:290] history::TextDatabase::DeletePageData(..) 0x6a07d145 [chrome.dll - text_database_manager.cc:338] history::TextDatabaseManager::DeletePageData(...) 0x6a081c4a [chrome.dll - expire_history_backend.cc:366] history::ExpireHistoryBackend::DeleteVisitRelatedInfo(..); 0x6a082496 [chrome.dll - expire_history_backend.cc:592] history::ExpireHistoryBackend::ArchiveSomeOldHistory(..) 0x6a0822fa [chrome.dll - expire_history_backend.cc:553] history::ExpireHistoryBackend::DoArchiveIteration() 0x69ee8de1 [chrome.dll - message_loop.cc:313] MessageLoop::RunTask (Task *) The novel part is that sqlite can detect corruption: D:\testsqlite3.exe zzz\User Data\Default\History Index 2009-09 SQLite version 3.6.17 sqlite PRAGMA integrity_check; wrong # of entries in index info_time --~--~-~--~~~---~--~~ 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: autolinking BUG= lines in Rietveld
Would be nice if it still handled http://crbug.com/ and crbug.com/ since
people probably will continue using them for a while.
Also split(', ') ONLY works for when you do 'blah, blah'. Not 'blah,blah'.
Not 'blah blah'. Or any other crazy things people might do.
I didn't know that you could give re.sub a callback to format the replace
text though. That's cool and could probably make my code simpler.
J
On Thu, Sep 10, 2009 at 12:27 PM, Mohamed Mansour m...@chromium.org wrote:
How about just this:
def repl(m):
issues = m.group(1).split(', ')
return , .join(a href='
http://code.google.com/p/chromium/issues/detail?id=%s'%s/a % (s, s)
for s in issues)
if __name__ == '__main__':
description = \nBUG=2, 3
description = re.sub(\nBUG=(\d+[, \d+]*), repl, description)
print description
Works great!
- Mohamed Mansour
On Wed, Sep 9, 2009 at 11:25 PM, Jeremy Orlow jor...@chromium.org wrote:
I don't have a rietveld dev environment set up, so I wrote a quick script
to test the general algorithm. It's not as pythony as I'd like, but it
seems to be fairly robust:
#!/usr/bin/python
import re
description = \
Blah blah blah.
Blaaa
TEST=none
BUG=123,456, 798,0
BUG=888
BUG=none
BUG = none, 2349,2,asdf
BUG = http://crbug.com/123
BUG = crbug.com/234 crbug/82
LINK = a href='http://code.google.com/p/chromium/issues/detail?id=%s
'%s/a
def rewrite_bug_numbers(string):
if ',' in string:
right, left = string.split(',', 1)
return rewrite_bug_numbers(right) + ',' + rewrite_bug_numbers(left)
if ' ' in string:
right, left = string.split(' ', 1)
return rewrite_bug_numbers(right) + ' ' + rewrite_bug_numbers(left)
# Base cases:
if string.isdigit():
return LINK % (string, string)
match = re.search(r'^(http://|)crbug.com/(\d+)', string)
if match:
return LINK % (match.group(2), string)
return string
output = []
for line in description.splitlines():
match = re.search(r'^(\s*BUG\s*=)(.*)$', line)
if match:
line = match.group(1) + rewrite_bug_numbers(match.group(2))
output.append(line)
print br\n.join(output)
Prints out
Blah blah blah.br
Blaaabr
br
TEST=nonebr
BUG=a
href='http://code.google.com/p/chromium/issues/detail?id=123'123/a,a
href='http://code.google.com/p/chromium/issues/detail?id=456'456/a, a
href='http://code.google.com/p/chromium/issues/detail?id=798'798/a,a
href='http://code.google.com/p/chromium/issues/detail?id=0'0/abr
BUG=a href='http://code.google.com/p/chromium/issues/detail?id=888
'888/abr
BUG=nonebr
BUG = none, a href='
http://code.google.com/p/chromium/issues/detail?id=2349'2349/a,a
href='http://code.google.com/p/chromium/issues/detail?id=2
'2/a,asdfbr
BUG = a href='http://code.google.com/p/chromium/issues/detail?id=123'
http://crbug.com/123/abr
BUG = a href='http://code.google.com/p/chromium/issues/detail?id=234'
crbug.com/234/a crbug/82
If we weren't concerned about preserving formatting, you could do it with
replace and split:
line = 1234, 23 , 2
bugs = line.replace(,, ).split()
But it's not t much more work to keep in all the formatting.
On Thu, Sep 10, 2009 at 11:01 AM, John Abd-El-Malek j...@chromium.orgwrote:
Thanks, glad you enjoy it :)
This was a side distraction to fix the annoying issue of having to
manually copying and pasting the bug ids. It severely tested my regex-fu
and since the multiple bugs case should be rare, I'll hide behind the excuse
that if they're duplicates they should be marked as such and only end up
with one, and if they're different bugs there should be separate changelists
;) The rietveld change is at
http://code.google.com/p/rietveld/source/detail?r=455, if anyone sends
me a patch to make it work with multiple bug ids, I'd be happy to push it.
On Wed, Sep 9, 2009 at 6:15 PM, Mohamed Mansour m...@chromium.orgwrote:
Very nice, no longer I have to put crbug.com/#. Whoever did that
autolink, can you support multiple bugs as well? The format bugdroid uses
is
BUG=1, 2, 3
- Mohamed Mansour
On Wed, Sep 9, 2009 at 8:58 PM, Paweł Hajdan Jr.
phajdan...@chromium.org wrote:
I just noticed that BUG=1234 lines are autolinked to the correct bug
when viewed in Rietveld (codereview.chromium.org). This is very
useful, thanks!
--~--~-~--~~~---~--~~
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: autolinking BUG= lines in Rietveld
Then it would just be a simple regular expression:
def repl(m):
issues = re.split('\,|\s', m.group(1))
return , .join(a href='
http://code.google.com/p/chromium/issues/detail?id=%s'%s/a % (s, s)
for s in issues)
if __name__ == '__main__':
description = \nBUG=1,2, 3,4
description = re.sub(\nBUG=(\d+[\,\s?\d+]*), repl, description)
print description
- Mohamed Mansour
On Wed, Sep 9, 2009 at 11:32 PM, Jeremy Orlow jor...@chromium.org wrote:
Would be nice if it still handled http://crbug.com/ and crbug.com/ since
people probably will continue using them for a while.
Also split(', ') ONLY works for when you do 'blah, blah'. Not 'blah,blah'.
Not 'blah blah'. Or any other crazy things people might do.
I didn't know that you could give re.sub a callback to format the replace
text though. That's cool and could probably make my code simpler.
J
On Thu, Sep 10, 2009 at 12:27 PM, Mohamed Mansour m...@chromium.orgwrote:
How about just this:
def repl(m):
issues = m.group(1).split(', ')
return , .join(a href='
http://code.google.com/p/chromium/issues/detail?id=%s'%s/a % (s, s)
for s in issues)
if __name__ == '__main__':
description = \nBUG=2, 3
description = re.sub(\nBUG=(\d+[, \d+]*), repl, description)
print description
Works great!
- Mohamed Mansour
On Wed, Sep 9, 2009 at 11:25 PM, Jeremy Orlow jor...@chromium.orgwrote:
I don't have a rietveld dev environment set up, so I wrote a quick script
to test the general algorithm. It's not as pythony as I'd like, but it
seems to be fairly robust:
#!/usr/bin/python
import re
description = \
Blah blah blah.
Blaaa
TEST=none
BUG=123,456, 798,0
BUG=888
BUG=none
BUG = none, 2349,2,asdf
BUG = http://crbug.com/123
BUG = crbug.com/234 crbug/82
LINK = a href='http://code.google.com/p/chromium/issues/detail?id=%s
'%s/a
def rewrite_bug_numbers(string):
if ',' in string:
right, left = string.split(',', 1)
return rewrite_bug_numbers(right) + ',' + rewrite_bug_numbers(left)
if ' ' in string:
right, left = string.split(' ', 1)
return rewrite_bug_numbers(right) + ' ' + rewrite_bug_numbers(left)
# Base cases:
if string.isdigit():
return LINK % (string, string)
match = re.search(r'^(http://|)crbug.com/(\d+)', string)
if match:
return LINK % (match.group(2), string)
return string
output = []
for line in description.splitlines():
match = re.search(r'^(\s*BUG\s*=)(.*)$', line)
if match:
line = match.group(1) + rewrite_bug_numbers(match.group(2))
output.append(line)
print br\n.join(output)
Prints out
Blah blah blah.br
Blaaabr
br
TEST=nonebr
BUG=a
href='http://code.google.com/p/chromium/issues/detail?id=123'123/a,a
href='http://code.google.com/p/chromium/issues/detail?id=456'456/a,
a href='http://code.google.com/p/chromium/issues/detail?id=798'798/a,a
href='http://code.google.com/p/chromium/issues/detail?id=0'0/abr
BUG=a href='http://code.google.com/p/chromium/issues/detail?id=888
'888/abr
BUG=nonebr
BUG = none, a href='
http://code.google.com/p/chromium/issues/detail?id=2349'2349/a,a
href='http://code.google.com/p/chromium/issues/detail?id=2
'2/a,asdfbr
BUG = a href='http://code.google.com/p/chromium/issues/detail?id=123'
http://crbug.com/123/abr
BUG = a href='http://code.google.com/p/chromium/issues/detail?id=234'
crbug.com/234/a crbug/82
If we weren't concerned about preserving formatting, you could do it with
replace and split:
line = 1234, 23 , 2
bugs = line.replace(,, ).split()
But it's not t much more work to keep in all the formatting.
On Thu, Sep 10, 2009 at 11:01 AM, John Abd-El-Malek
j...@chromium.orgwrote:
Thanks, glad you enjoy it :)
This was a side distraction to fix the annoying issue of having to
manually copying and pasting the bug ids. It severely tested my regex-fu
and since the multiple bugs case should be rare, I'll hide behind the
excuse
that if they're duplicates they should be marked as such and only end up
with one, and if they're different bugs there should be separate
changelists
;) The rietveld change is at
http://code.google.com/p/rietveld/source/detail?r=455, if anyone sends
me a patch to make it work with multiple bug ids, I'd be happy to push it.
On Wed, Sep 9, 2009 at 6:15 PM, Mohamed Mansour m...@chromium.orgwrote:
Very nice, no longer I have to put crbug.com/#. Whoever did that
autolink, can you support multiple bugs as well? The format bugdroid uses
is
BUG=1, 2, 3
- Mohamed Mansour
On Wed, Sep 9, 2009 at 8:58 PM, Paweł Hajdan Jr.
phajdan...@chromium.org wrote:
I just noticed that BUG=1234 lines are autolinked to the correct bug
when viewed in Rietveld (codereview.chromium.org). This is very
useful, thanks!
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or
[chromium-dev] Re: found corrupted db
fts uses what is effectively a form of compression for the index, so most any stream of data will decode at some level. My bet in this case is that the segdir is referencing a segment block which doesn't exist, so someone inappropriately tries to decode NULL. From what I recall of debugging such things in Gears, that case does tend to go along with being able to detect via PRAGMA integrity_check, because it happens when a page containing SQLite metadata has been corrupted. For instance, if an interior node of a b-tree is replaced by a random other page (perhaps a node was split and the target page did not get overwritten due to lying disk cache). What's puzzling is how I know this, but we still see the crash. I'm pretty sure we fixed something or other around this. That was a year or more back, though, so maybe I'm not remembering right. Regardless, best-case scenario for something like this would be someone throwing SQLITE_CORRUPT and higher-level code doing something like poisoning (*) or deletion or mount some sort of salvage operation. -scott (*) This is what Gears did, it marked the database unusable in a way that would be recognized by all outstanding handles, and bumped the version in the mapping so that on next open a fresh new database would be created. Probably not appropriate in this case. On Wed, Sep 9, 2009 at 6:34 PM, cpuc...@chromium.org wrote: Larson gave me a profile that can consistently crash windows chrome (beta). I haven't tried loading the profile myself but we have crash dumps from it. It crashes in: 0x69db6e5d [chrome.dll - fts2.c:453] getVarint --- access violation at 0x0 0x69db6ef0 [chrome.dll - fts2.c:468] getVarint32 0x69dbacbf [chrome.dll - fts2.c:5078] leavesReaderDataBytes 0x69dbb1d7 [chrome.dll - fts2.c:5407] segmentMerge 0x69dbb0f9 [chrome.dll - fts2.c:5359] segdirNextIndex 0x69dbba45 [chrome.dll - fts2.c:5932] writeZeroSegment 0x69dbbbf5 [chrome.dll - fts2.c:5966] flushPendingTerms 0x69dbbc3c [chrome.dll - fts2.c:5984] initPendingTerms 0x69dba135 [chrome.dll - fts2.c:4050] index_delete 0x69dbbca4 [chrome.dll - fts2.c:6005] fulltextUpdate 0x69dc284a [chrome.dll - vdbe.c:4945] sqlite3VdbeExec 0x69da170f [chrome.dll - vdbeapi.c:476] sqlite3Step 0x69da1856 [chrome.dll - vdbeapi.c:544] sqlite3_step 0x6a09c1ab [chrome.dll - text_database.cc:290] history::TextDatabase::DeletePageData(..) 0x6a07d145 [chrome.dll - text_database_manager.cc:338] history::TextDatabaseManager::DeletePageData(...) 0x6a081c4a [chrome.dll - expire_history_backend.cc:366] history::ExpireHistoryBackend::DeleteVisitRelatedInfo(..); 0x6a082496 [chrome.dll - expire_history_backend.cc:592] history::ExpireHistoryBackend::ArchiveSomeOldHistory(..) 0x6a0822fa [chrome.dll - expire_history_backend.cc:553] history::ExpireHistoryBackend::DoArchiveIteration() 0x69ee8de1 [chrome.dll - message_loop.cc:313] MessageLoop::RunTask (Task *) The novel part is that sqlite can detect corruption: D:\testsqlite3.exe zzz\User Data\Default\History Index 2009-09 SQLite version 3.6.17 sqlite PRAGMA integrity_check; wrong # of entries in index info_time --~--~-~--~~~---~--~~ 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: autolinking BUG= lines in Rietveld
Hmm I was looking at my code, and its flawed (the usage of brackets). This
one should work better:
import re
def replace_bug(m):
bugs = re.split(r[\s,]+, m.group(1))
return , .join(a
href='http://code.google.com/p/chromium/issues/detail?id=%s'%s/a %
(i, i) for i in bugs if i != )
bug_pattern = r(?=BUG=)(\s*\d+\s*(?:,\s*\d+\s*)*)
result = re.sub(bug_pattern, replace_bug, \nBUG=1 , 2, 3 )
print result
http://codepad.org/DmH9r8I6I submitted the patch to rietveld:
http://codereview.appspot.com/115083
http://codereview.appspot.com/115083
-- Mohamed Mansour
On Wed, Sep 9, 2009 at 11:44 PM, Mohamed Mansour m...@chromium.org wrote:
Then it would just be a simple regular expression:
def repl(m):
issues = re.split('\,|\s', m.group(1))
return , .join(a href='
http://code.google.com/p/chromium/issues/detail?id=%s'%s/a % (s, s)
for s in issues)
if __name__ == '__main__':
description = \nBUG=1,2, 3,4
description = re.sub(\nBUG=(\d+[\,\s?\d+]*), repl, description)
print description
- Mohamed Mansour
On Wed, Sep 9, 2009 at 11:32 PM, Jeremy Orlow jor...@chromium.org wrote:
Would be nice if it still handled http://crbug.com/ and crbug.com/ since
people probably will continue using them for a while.
Also split(', ') ONLY works for when you do 'blah, blah'. Not
'blah,blah'. Not 'blah blah'. Or any other crazy things people might do.
I didn't know that you could give re.sub a callback to format the replace
text though. That's cool and could probably make my code simpler.
J
On Thu, Sep 10, 2009 at 12:27 PM, Mohamed Mansour m...@chromium.orgwrote:
How about just this:
def repl(m):
issues = m.group(1).split(', ')
return , .join(a href='
http://code.google.com/p/chromium/issues/detail?id=%s'%s/a % (s, s)
for s in issues)
if __name__ == '__main__':
description = \nBUG=2, 3
description = re.sub(\nBUG=(\d+[, \d+]*), repl, description)
print description
Works great!
- Mohamed Mansour
On Wed, Sep 9, 2009 at 11:25 PM, Jeremy Orlow jor...@chromium.orgwrote:
I don't have a rietveld dev environment set up, so I wrote a quick
script to test the general algorithm. It's not as pythony as I'd like, but
it seems to be fairly robust:
#!/usr/bin/python
import re
description = \
Blah blah blah.
Blaaa
TEST=none
BUG=123,456, 798,0
BUG=888
BUG=none
BUG = none, 2349,2,asdf
BUG = http://crbug.com/123
BUG = crbug.com/234 crbug/82
LINK = a href='http://code.google.com/p/chromium/issues/detail?id=%s
'%s/a
def rewrite_bug_numbers(string):
if ',' in string:
right, left = string.split(',', 1)
return rewrite_bug_numbers(right) + ',' + rewrite_bug_numbers(left)
if ' ' in string:
right, left = string.split(' ', 1)
return rewrite_bug_numbers(right) + ' ' + rewrite_bug_numbers(left)
# Base cases:
if string.isdigit():
return LINK % (string, string)
match = re.search(r'^(http://|)crbug.com/(\d+)', string)
if match:
return LINK % (match.group(2), string)
return string
output = []
for line in description.splitlines():
match = re.search(r'^(\s*BUG\s*=)(.*)$', line)
if match:
line = match.group(1) + rewrite_bug_numbers(match.group(2))
output.append(line)
print br\n.join(output)
Prints out
Blah blah blah.br
Blaaabr
br
TEST=nonebr
BUG=a
href='http://code.google.com/p/chromium/issues/detail?id=123'123/a,a
href='http://code.google.com/p/chromium/issues/detail?id=456'456/a,
a href='http://code.google.com/p/chromium/issues/detail?id=798'798/a,a
href='http://code.google.com/p/chromium/issues/detail?id=0'0/abr
BUG=a href='http://code.google.com/p/chromium/issues/detail?id=888
'888/abr
BUG=nonebr
BUG = none, a href='
http://code.google.com/p/chromium/issues/detail?id=2349'2349/a,a
href='http://code.google.com/p/chromium/issues/detail?id=2
'2/a,asdfbr
BUG = a href='http://code.google.com/p/chromium/issues/detail?id=123'
http://crbug.com/123/abr
BUG = a href='http://code.google.com/p/chromium/issues/detail?id=234'
crbug.com/234/a crbug/82
If we weren't concerned about preserving formatting, you could do it
with replace and split:
line = 1234, 23 , 2
bugs = line.replace(,, ).split()
But it's not t much more work to keep in all the formatting.
On Thu, Sep 10, 2009 at 11:01 AM, John Abd-El-Malek
j...@chromium.orgwrote:
Thanks, glad you enjoy it :)
This was a side distraction to fix the annoying issue of having to
manually copying and pasting the bug ids. It severely tested my regex-fu
and since the multiple bugs case should be rare, I'll hide behind the
excuse
that if they're duplicates they should be marked as such and only end up
with one, and if they're different bugs there should be separate
changelists
;) The rietveld change is at
http://code.google.com/p/rietveld/source/detail?r=455, if anyone sends
me a patch to make it work with multiple bug ids, I'd be happy to push it.
On Wed, Sep 9,
[chromium-dev] Re: Are we going to support active FTP?
Ah, I see it in the Advanced prefs. On my system, PASV is the default. -Darin On Wed, Sep 9, 2009 at 9:45 PM, Michal Zalewski lcam...@gmail.com wrote: Does IE support active mode? Yup - there's a manual toggle, but no auto-detection. Not sure which mode is on by default. /mz --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
For reference, this is https://bugzilla.mozilla.org/show_bug.cgi?id=465. A 3 digit Mozilla bug! Personally, I don't think we should spend much time on active mode FTP. It doesn't seem that valuable given that it is not supported by Firefox and only available in IE through an advanced option. -Darin On Wed, Sep 9, 2009 at 9:58 PM, Darin Fisher da...@chromium.org wrote: Ah, I see it in the Advanced prefs. On my system, PASV is the default. -Darin On Wed, Sep 9, 2009 at 9:45 PM, Michal Zalewski lcam...@gmail.com wrote: Does IE support active mode? Yup - there's a manual toggle, but no auto-detection. Not sure which mode is on by default. /mz --~--~-~--~~~---~--~~ 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: autolinking BUG= lines in Rietveld
Are we only talking about when it is viewed in Rietveld?What about when it is actually committed, can the change log be tweaked that way, automatically, too? That would be nice when reading change logs. Thank you! ☆PhistucK On Thu, Sep 10, 2009 at 05:01, John Abd-El-Malek j...@chromium.org wrote: Thanks, glad you enjoy it :) This was a side distraction to fix the annoying issue of having to manually copying and pasting the bug ids. It severely tested my regex-fu and since the multiple bugs case should be rare, I'll hide behind the excuse that if they're duplicates they should be marked as such and only end up with one, and if they're different bugs there should be separate changelists ;) The rietveld change is at http://code.google.com/p/rietveld/source/detail?r=455, if anyone sends me a patch to make it work with multiple bug ids, I'd be happy to push it. On Wed, Sep 9, 2009 at 6:15 PM, Mohamed Mansour m...@chromium.org wrote: Very nice, no longer I have to put crbug.com/#. Whoever did that autolink, can you support multiple bugs as well? The format bugdroid uses is BUG=1, 2, 3 - Mohamed Mansour On Wed, Sep 9, 2009 at 8:58 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I just noticed that BUG=1234 lines are autolinked to the correct bug when viewed in Rietveld (codereview.chromium.org). This is very useful, thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
