[chromium-dev] Re: Mac Chrome launch speed = the awesome

Would like to add my many thanks to the chrome team for the amazingly blazingly fast Chromium on Mac :) Awesome work you guys! On Sep 8, 8:11 am, Adam Barth wrote: > Dear Mac folks: > > Thanks for making Mac Chrome launch ridiculously fast.  I really enjoy > that, on my laptop, the main window i

[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 wrote: > Thanks, gla

[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. -Da

[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 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-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("%s" % (i, i) for i in bugs if i != "") bug_pattern = r"(?<=BUG=)(\s*\d+\s*(?:,\s*\d+\s*)*)" result =

[chromium-dev] Re: Are we going to support active FTP?

Does IE support active mode? Firefox doesn't, and it hasn't been a huge problem for users.-Darin On Wed, Sep 9, 2009 at 10:53 AM, Paweł Hajdan Jr. 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 prior

[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 suc

[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("%s" % (s, s) > for s in issues) > if __name__ == '__main__': description = "\nBUG=1,2, 3,4" description = re.sub("\nBUG=(\d+[\,\s?\d+]*)", repl, descript

[chromium-dev] Re: Argh: Rebuilding installer_util on every F5

This sounds like exactly the problem I was having a few days ago, except that it was fixed in: http://src.chromium.org/viewvc/chrome?view=rev&revision=25290 I wonder what version of this file you have. If you are up to date I know sgk

[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

[chromium-dev] Re: autolinking BUG= lines in Rietveld

How about just this: def repl(m): issues = m.group(1).split(', ') return ", ".join("%s" % (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 Man

[chromium-dev] Re: autolinking BUG= lines in Rietveld

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

[chromium-dev] Re: autolinking BUG= lines in Rietveld

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

[chromium-dev] Re: found corrupted db

Maybe we could try something like "if the last launch of chrome shutdown uncleanly, do an integrity check before starting the next time". We already track if the last instance crashed for metrics purposes. On Wed, Sep 9, 2009 at 6:34 PM, cpu wrote: > > Larson gave me a profile that can consiste

[chromium-dev] Re: found corrupted db

On Wed, Sep 9, 2009 at 6:34 PM, cpu wrote: > D:\test>sqlite3.exe "zzz\User Data\Default\History Index 2009-09" > SQLite version 3.6.17 Gmail wants me to add this to my calendar, heh. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups

[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 -

[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. wrote: > I just noticed that BUG=1234 lines are autolinked to the correct

[chromium-dev] autolinking BUG= lines in Rietveld

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 op

[chromium-dev] Re: Argh: Rebuilding installer_util on every F5

Oops, looking. On Wed, Sep 9, 2009 at 8:32 PM, Nicolas Sylvain wrote: > +maruel, who changed this code yesterday > Nicolas > > On Wed, Sep 9, 2009 at 5:29 PM, Peter Kasting wrote: >> >> Somehow, starting today, I'm now rebuilding installer_util (recompiling a >> half dozen files, which then caus

[chromium-dev] Re: Argh: Rebuilding installer_util on every F5

On Thu, Sep 10, 2009 at 9:36 AM, Matt Perry wrote: > This doesn't answer the question, but here's a workaround for these sorts > of issues that you might find tolerable:- Go to Tools -> Options -> > Projects and Solutions -> Build and Run. > - Under "On Run, when projects are out of date", select

[chromium-dev] Re: Argh: Rebuilding installer_util on every F5

This doesn't answer the question, but here's a workaround for these sorts of issues that you might find tolerable:- Go to Tools -> Options -> Projects and Solutions -> Build and Run. - Under "On Run, when projects are out of date", select "Never build". This makes it so that F5 starts debugging im

[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 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 r

[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 tou

[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

[chromium-dev] Sync engine code landing in trunk later today

Hi all, This is just a heads-up that we are going to land the sync code in trunk later today. After committing the sync glue code a little over a month ago, we are now ready to commit the code we use for building syncapi.dll, which is the sync DLL we included in the recent Dev Channel releases. We

[chromium-dev] Re: Are we going to support active FTP?

On Wed, Sep 9, 2009 at 4:31 PM, Michal Zalewski 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

[chromium-dev] Re: WebKit Chromium Port

On Thu, Sep 10, 2009 at 2:10 AM, Dimitri Glazkov wrote: > > 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 win

[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 o

[chromium-dev] Re: Are we going to support active FTP?

On Wed, Sep 9, 2009 at 4:11 PM, Michal Zalewski 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

[chromium-dev] Re: Are we going to support active FTP?

On Wed, Sep 9, 2009 at 3:52 PM, Michal Zalewski 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

[chromium-dev] Re: Are we going to support active FTP?

On Wed, Sep 9, 2009 at 4:02 PM, Michal Zalewski 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 fire

[chromium-dev] Re: Are we going to support active FTP?

Agreed. If PASV returns success, but the connection fails, timing out is the only option, and it's annoying. I admit I haven't played with FTP-aware firewalls since the mid 90s, but for a firewall to support active FTP at all, it must be sniffing or proxying all FTP command channel traffic. Thi

[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 wrote: > >> I can't think of any. It would be nice to have active support. I'm not

[chromium-dev] Re: icu was upgraded to 4.2.1 : you want to clobber on Windows

I had to clobber on Mac this morning as well. Go figure. Probably best to clobber everything everywhere. 2009/9/9 Jungshik Shin (신정식, 申政湜) : > > 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 li

[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 > I had to clobber on Mac this morning as well. Go figure. > > Probably best to cl

[chromium-dev] Re: Are we going to support active FTP?

On Wed, Sep 9, 2009 at 10:53 AM, Paweł Hajdan Jr. 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? Like with PASV, you need

[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]

[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 > s

[chromium-dev] Re: Are we going to support active FTP?

On Wed, Sep 9, 2009 at 1:56 PM, Peter Kasting 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.

[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, Pa

[chromium-dev] Re: [Chrome-team] understanding layout test flakiness

Nice write up. Idea by Drew Wilson: 5. Make test shell dump (partial) results when there is a timeout. (This may actually be an item under "2".) On Wed, Sep 9, 2009 at 10:51 AM, Ojan Vafai wrote: > I'm including at the top concrete tasks people can take to help identify > and reduce flakiness.

[chromium-dev] Re: Are we going to support active FTP?

On Wed, Sep 9, 2009 at 10:53 AM, Paweł Hajdan Jr. 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? > I can't think of any.

[chromium-dev] 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? --~--~-~--~~~---~--~~ Chromium Developers mailing list: c

[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.

[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 ast 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 clobber

[chromium-dev] Re: WebKit Chromium Port

Marc-Antoine, you will forever have a special place in every WebKit committer's heart if you can pull of setting up these trybots. 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. :DG<

[chromium-dev] Re: WebKit Chromium Port

On Wed, Sep 9, 2009 at 1:19 AM, Ojan Vafai 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 doi

[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 a

[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 an

[chromium-dev] Re: Windows trybot issue.

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 Orlow wrote: > Please follow the instructions on the email you get from the t

[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 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 follo

[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 lib

[chromium-dev] Re: WebKit Chromium Port

On Tue, Sep 8, 2009 at 11:02 PM, Jeremy Orlow 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