[chromium-dev] Re: Formatting substrings in a views::Label

[Ben Goodger (Google)]

I actually don't like having a mix of HTML/native UIs in the product.
When we switched to the NTP from the old Destinations page we made the
decision to have the content of tabs feel webby and the content of
dialogs feel dialoggy.

As a result the NTP now feels pleasantly webby, but many of the HTML
dialogs don't feel dialoggy (focus issues, key accelerators, etc).

-Ben

On Wed, Aug 26, 2009 at 11:43 PM, Tim Steele wrote:
> fwiw, another way to write a dialog like this platform independently without
> an extra abstraction for Label would be to use our html UI; that's what I
> did for the sync setup dialog/wizard flow, and so far so good!
>
> On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman  wrote:
>>
>> I'm playing with different ideas for the extension install dialog, and
>> would like to do something like the attacked mock.
>>
>> I can see that there is no support for this in Label presently and I'm
>> told by Dean that the APIs for doing this are different across
>> platforms. Is it worth adding an abstraction to Label for this?
>>
>> - 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: Formatting substrings in a views::Label

[Aaron Boodman]

On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google) wrote:
> I actually don't like having a mix of HTML/native UIs in the product.
> When we switched to the NTP from the old Destinations page we made the
> decision to have the content of tabs feel webby and the content of
> dialogs feel dialoggy.
>
> As a result the NTP now feels pleasantly webby, but many of the HTML
> dialogs don't feel dialoggy (focus issues, key accelerators, etc).

This is why I decided to go with native for the install dialog.

I feel like doing this the way that the about dialog is done would be
incredibly painful and buggy because of wrapping issues. Also, at
least on my machine (I am one of those weirdos that uses vista with
the classic theme), the about dialog does not look right. The
alignment of the links is slightly off.

I would prefer to use the platform APIs that already know how to do
this correctly. I'm thinking of adding something like
set_bold_delimiter(const std::string&) on Label. You could use it like
this:

myLabel->set_bold_delimiter("*");
myLabel->set_text("hello *world*");

Is this totally lame?

- 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] FreeBSD port, take 2

[Ben Laurie]

As brettw requested, I ported chrome/browser/renderer_host/ and base/.
This is now done and can be reviewed here:

http://codereview.chromium.org/172032

The description summarises the changes I made, what do people think?
(I haven't forgot that I said I'd document defines - I'll do that once
people are happy with them)

Added USE_GDK, set when either TOOLKIT_GTK or TOOLKIT_VIEWS is set but
not OS_WIN.

Added USE_X11. Set when OS_LINUX or OS_FREEBSD is set.

Added USE_BASE_DATA_PACK for base::DataPack usage, set for OS_MACOSX,
OS_LINUX or OS_FREEBSD.

Added USE_NSS for ... nss (for crypto). Windows and MacOS use
platform-specific libraries.

All of the above cause slightly odd formulations like:

#if defined(OS_WIN)
...
#elif defined(USE_BASE_DATA_PACK)
...
#endif

Possibly should also define USE_DLL_FOR_DATA, etc? Or something?

Wrapped various references to struct stat64 and stat64() to use struct
stat and stat() for FreeBSD - but a "man stat64" on Linux suggests
that we could do the same thing for at least Linux, too, and perhaps
eliminate the wrapper?

--~--~-~--~~~---~--~~
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: FreeBSD port, take 2

[Ben Laurie]

I forgot to mention - there's a single file that may not be complete,
base/crypto/signature_verifier_nss.cc - this is because the FreeBSD
port of NSS is too old and doesn't have a function it needs. I'll get
to that at some point soon, but I don't anticipate it being a problem.

On Thu, Aug 27, 2009 at 10:57 AM, Ben Laurie wrote:
> As brettw requested, I ported chrome/browser/renderer_host/ and base/.
> This is now done and can be reviewed here:
>
> http://codereview.chromium.org/172032
>
> The description summarises the changes I made, what do people think?
> (I haven't forgot that I said I'd document defines - I'll do that once
> people are happy with them)
>
> Added USE_GDK, set when either TOOLKIT_GTK or TOOLKIT_VIEWS is set but
> not OS_WIN.
>
> Added USE_X11. Set when OS_LINUX or OS_FREEBSD is set.
>
> Added USE_BASE_DATA_PACK for base::DataPack usage, set for OS_MACOSX,
> OS_LINUX or OS_FREEBSD.
>
> Added USE_NSS for ... nss (for crypto). Windows and MacOS use
> platform-specific libraries.
>
> All of the above cause slightly odd formulations like:
>
> #if defined(OS_WIN)
> ...
> #elif defined(USE_BASE_DATA_PACK)
> ...
> #endif
>
> Possibly should also define USE_DLL_FOR_DATA, etc? Or something?
>
> Wrapped various references to struct stat64 and stat64() to use struct
> stat and stat() for FreeBSD - but a "man stat64" on Linux suggests
> that we could do the same thing for at least Linux, too, and perhaps
> eliminate the wrapper?
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Problem with try servers?

[Ben Laurie]

If I do a gcl try, I get prompted for a password for 'ben', which is
my login name on my FreeBSD machine. Whatever I enter, the script then
hangs - investigation shows that this is because it is prompting for a
username, but gcl is swallowing the output.

If I then enter b...@chromium.org, I get prompted for a password
again. At that point, neither my googlecode password nor my gaia
password work.

Am I doing something wrong? How is this supposed to work?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Problem with try servers?

[Marc-Antoine Ruel]

It's asking you for your svn password because you have no http access.

I realize the faq at
http://dev.chromium.org/developers/try-server-usage has no connection
troubleshooting guide. feel free to add.

M-A

On Thu, Aug 27, 2009 at 6:17 AM, Ben Laurie wrote:
>
> If I do a gcl try, I get prompted for a password for 'ben', which is
> my login name on my FreeBSD machine. Whatever I enter, the script then
> hangs - investigation shows that this is because it is prompting for a
> username, but gcl is swallowing the output.
>
> If I then enter b...@chromium.org, I get prompted for a password
> again. At that point, neither my googlecode password nor my gaia
> password work.
>
> Am I doing something wrong? How is this supposed to work?
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Formatting substrings in a views::Label

[Finnur Thorarinsson]

It is only incredibly painful if you mix in the link in with other words in
the middle of a sentence, like I had to do with the About box. If you,
instead, have a link below the main text (like the mock shows) it is dead
simple and easy.
I don't see why you should avoid using Link in that case.

On Thu, Aug 27, 2009 at 00:14, Aaron Boodman  wrote:

>
> On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google)
> wrote:
> > I actually don't like having a mix of HTML/native UIs in the product.
> > When we switched to the NTP from the old Destinations page we made the
> > decision to have the content of tabs feel webby and the content of
> > dialogs feel dialoggy.
> >
> > As a result the NTP now feels pleasantly webby, but many of the HTML
> > dialogs don't feel dialoggy (focus issues, key accelerators, etc).
>
> This is why I decided to go with native for the install dialog.
>
> I feel like doing this the way that the about dialog is done would be
> incredibly painful and buggy because of wrapping issues. Also, at
> least on my machine (I am one of those weirdos that uses vista with
> the classic theme), the about dialog does not look right. The
> alignment of the links is slightly off.
>
> I would prefer to use the platform APIs that already know how to do
> this correctly. I'm thinking of adding something like
> set_bold_delimiter(const std::string&) on Label. You could use it like
> this:
>
> myLabel->set_bold_delimiter("*");
> myLabel->set_text("hello *world*");
>
> Is this totally lame?
>
> - 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: FreeBSD port, take 2

[Evan Martin]

On Thu, Aug 27, 2009 at 2:57 AM, Ben Laurie wrote:
> Added USE_GDK, set when either TOOLKIT_GTK or TOOLKIT_VIEWS is set but
> not OS_WIN.

I believe VIEWS still uses GTK (for bits like the omnibox).

> All of the above cause slightly odd formulations like:
>
> #if defined(OS_WIN)
> ...
> #elif defined(USE_BASE_DATA_PACK)
> ...
> #endif

My only concern with these is that if some platform happens to get
excluded in one of those chained statements, we'll have functions
silently skipping code that's important.  (This was a real problem in
bringing up the ports -- people would occasionally do "#ifdef OS_WIN
important_code() #endif", and finding out why some variable isn't
getting set sometimes isn't obvious.)

It seems some sort of "#else #error need code here" pattern would be
nice to define and use.

> Wrapped various references to struct stat64 and stat64() to use struct
> stat and stat() for FreeBSD - but a "man stat64" on Linux suggests
> that we could do the same thing for at least Linux, too, and perhaps
> eliminate the wrapper?

Until recently we couldn't build with _FILE_OFFSET_BITS=64, so maybe
stat64 is just a holdover from before that was fixed.
http://code.google.com/p/chromium/issues/detail?id=17492

--~--~-~--~~~---~--~~
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: FreeBSD port, take 2

[Evan Martin]

On Thu, Aug 27, 2009 at 8:13 AM, Ben Laurie wrote:
> On Thu, Aug 27, 2009 at 3:56 PM, Evan Martin wrote:
>> On Thu, Aug 27, 2009 at 2:57 AM, Ben Laurie wrote:
>>> Added USE_GDK, set when either TOOLKIT_GTK or TOOLKIT_VIEWS is set but
>>> not OS_WIN.
>>
>> I believe VIEWS still uses GTK (for bits like the omnibox).
>
> So this should be USE_GTK?

I'm not sure, just pointing out the problem.  :\
TOOLKIT_FOO vs USE_FOO is a bit confusing but documentation could fix that.


>>> All of the above cause slightly odd formulations like:
>>>
>>> #if defined(OS_WIN)
>>> ...
>>> #elif defined(USE_BASE_DATA_PACK)
>>> ...
>>> #endif
>>
>> My only concern with these is that if some platform happens to get
>> excluded in one of those chained statements, we'll have functions
>> silently skipping code that's important.  (This was a real problem in
>> bringing up the ports -- people would occasionally do "#ifdef OS_WIN
>> important_code() #endif", and finding out why some variable isn't
>> getting set sometimes isn't obvious.)
>>
>> It seems some sort of "#else #error need code here" pattern would be
>> nice to define and use.
>
> Can do. Obviously this problem already existed, I haven't introduced it.

Yes.  I think it was simpler when there were just three targets (I
wouldn't be surprised if there are places where the "else" is just
"the platform I haven't yet mentioned").  I think with these
more-complicated overlapping feature-level defines it'll be very easy
to accidentally drop a platform.

--~--~-~--~~~---~--~~
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: Formatting substrings in a views::Label

[Scott Violet]

On Thu, Aug 27, 2009 at 12:14 AM, Aaron Boodman wrote:
>
> On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google) 
> wrote:
>> I actually don't like having a mix of HTML/native UIs in the product.
>> When we switched to the NTP from the old Destinations page we made the
>> decision to have the content of tabs feel webby and the content of
>> dialogs feel dialoggy.
>>
>> As a result the NTP now feels pleasantly webby, but many of the HTML
>> dialogs don't feel dialoggy (focus issues, key accelerators, etc).
>
> This is why I decided to go with native for the install dialog.
>
> I feel like doing this the way that the about dialog is done would be
> incredibly painful and buggy because of wrapping issues. Also, at
> least on my machine (I am one of those weirdos that uses vista with
> the classic theme), the about dialog does not look right. The
> alignment of the links is slightly off.
>
> I would prefer to use the platform APIs that already know how to do
> this correctly. I'm thinking of adding something like
> set_bold_delimiter(const std::string&) on Label. You could use it like
> this:
>
> myLabel->set_bold_delimiter("*");
> myLabel->set_text("hello *world*");
>
> Is this totally lame?

Then you have to worry about escape characters, which ends up being a
bit finicky. I would rather see some way to add specify an attribute
over a range of the text. Perhaps though we end up with what you are
suggesting in our resources files. Hm.

  -Scott

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Git woes

[Evan Martin]

Aside from basic stuff like running out of disk space, I have no idea
what would cause this problem.  (It's weird that pread would fail with
"no such file" when its API is to take an open file descriptor.)

One workaround might be to try setting this defined, mentioned in the Makefile:
# Define NO_PREAD if you have a problem with pread() system call (e.g.
# cygwin.dll before v1.5.22).


Not exactly sure it's relevant, but from a script that wraps git where
this error came up, the author of the script asks "are you on OS X?"
http://groups.google.com/group/repo-discuss/msg/d6b4fd3d8a1677a2
"Unfortunately, either Python or Mac OS X is busted.  With multiple cores
present, we seem to get the result from waitpid() before all of the changes
made by the child process are actually visible in the filesystem, so when we
start the next child, the next child might be missing modifications it
expected to see. "

On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber wrote:
>
> Trying to pull:
>
> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
> remote: Counting objects: 1859, done.
> remote: Compressing objects: 100% (1267/1267), done.
> remote: Total 1393 (delta 1087), reused 195 (delta 107)
> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
> fatal: cannot pread pack file: No such file or directory
> fatal: index-pack failed
>
> Ideas? The interwebs suggest deleting some file from my .git folder
> that's not in there.
>
> Nico
>
> >
>

--~--~-~--~~~---~--~~
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: Git woes

[Evan Martin]

https://kerneltrap.org/mailarchive/git/2007/7/23/252538
old and maybe obsolete, but has some exposition from Linus

On Thu, Aug 27, 2009 at 7:51 AM, Evan Martin wrote:
> Aside from basic stuff like running out of disk space, I have no idea
> what would cause this problem.  (It's weird that pread would fail with
> "no such file" when its API is to take an open file descriptor.)
>
> One workaround might be to try setting this defined, mentioned in the 
> Makefile:
> # Define NO_PREAD if you have a problem with pread() system call (e.g.
> # cygwin.dll before v1.5.22).
>
>
> Not exactly sure it's relevant, but from a script that wraps git where
> this error came up, the author of the script asks "are you on OS X?"
> http://groups.google.com/group/repo-discuss/msg/d6b4fd3d8a1677a2
> "Unfortunately, either Python or Mac OS X is busted.  With multiple cores
> present, we seem to get the result from waitpid() before all of the changes
> made by the child process are actually visible in the filesystem, so when we
> start the next child, the next child might be missing modifications it
> expected to see. "
>
> On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber wrote:
>>
>> Trying to pull:
>>
>> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
>> remote: Counting objects: 1859, done.
>> remote: Compressing objects: 100% (1267/1267), done.
>> remote: Total 1393 (delta 1087), reused 195 (delta 107)
>> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
>> fatal: cannot pread pack file: No such file or directory
>> fatal: index-pack failed
>>
>> Ideas? The interwebs suggest deleting some file from my .git folder
>> that's not in there.
>>
>> Nico
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: FreeBSD port, take 2

[Ben Laurie]

On Thu, Aug 27, 2009 at 3:56 PM, Evan Martin wrote:
> On Thu, Aug 27, 2009 at 2:57 AM, Ben Laurie wrote:
>> Added USE_GDK, set when either TOOLKIT_GTK or TOOLKIT_VIEWS is set but
>> not OS_WIN.
>
> I believe VIEWS still uses GTK (for bits like the omnibox).

So this should be USE_GTK?

>> All of the above cause slightly odd formulations like:
>>
>> #if defined(OS_WIN)
>> ...
>> #elif defined(USE_BASE_DATA_PACK)
>> ...
>> #endif
>
> My only concern with these is that if some platform happens to get
> excluded in one of those chained statements, we'll have functions
> silently skipping code that's important.  (This was a real problem in
> bringing up the ports -- people would occasionally do "#ifdef OS_WIN
> important_code() #endif", and finding out why some variable isn't
> getting set sometimes isn't obvious.)
>
> It seems some sort of "#else #error need code here" pattern would be
> nice to define and use.

Can do. Obviously this problem already existed, I haven't introduced it.

>> Wrapped various references to struct stat64 and stat64() to use struct
>> stat and stat() for FreeBSD - but a "man stat64" on Linux suggests
>> that we could do the same thing for at least Linux, too, and perhaps
>> eliminate the wrapper?
>
> Until recently we couldn't build with _FILE_OFFSET_BITS=64, so maybe
> stat64 is just a holdover from before that was fixed.
> http://code.google.com/p/chromium/issues/detail?id=17492
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [gyp-developer] GYP buildbots

[Evan Martin]

Awesome, thanks!

On Thu, Aug 27, 2009 at 8:50 AM, Steven Knight wrote:
> Of interest to GYP developers (or anyone else who may need to roll the GYP
> revision in DEPS):
> The FYI (experimental) buildbot master now has a set of of canary slaves
> that build Chromium with the latest tip-of-tree GYP on Linux/Mac/Win (and
> run unit_tests and a few others, just for a sanity check):
> http://build.chromium.org/buildbot/waterfall.fyi/waterfall?builder=Chromium%20Linux%20GYP&builder=Chromium%20Mac%20GYP&builder=Chromium%20XP%20GYP
> Before you update the GYP revision in DEPS, it would be a Good Idea to check
> these slaves to make sure they're green.
> Another set of slaves run the stand-alone GYP test suite:
> http://build.chromium.org/buildbot/waterfall.fyi/waterfall?builder=GYP%20Linux&builder=GYP%20Mac&builder=GYP%20XP
> Anyone wanting to speed switching the official Linux build from SCons to
> Make would be very welcome to dive in and help turn the "make" step of the
> Linux bot green.
>         --SK

--~--~-~--~~~---~--~~
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: Git woes

[Evan Martin]

Try "git gc"

On Thu, Aug 27, 2009 at 8:27 AM, Nico Weber wrote:
> The "pack file truncated" theory sounds most likely. Is there any way
> I could tell git to regenerate the newest N packfiles?
>
> On Thu, Aug 27, 2009 at 8:00 AM, Evan Martin wrote:
>> https://kerneltrap.org/mailarchive/git/2007/7/23/252538
>> old and maybe obsolete, but has some exposition from Linus
>>
>> On Thu, Aug 27, 2009 at 7:51 AM, Evan Martin wrote:
>>> Aside from basic stuff like running out of disk space, I have no idea
>>> what would cause this problem.  (It's weird that pread would fail with
>>> "no such file" when its API is to take an open file descriptor.)
>>>
>>> One workaround might be to try setting this defined, mentioned in the 
>>> Makefile:
>>> # Define NO_PREAD if you have a problem with pread() system call (e.g.
>>> # cygwin.dll before v1.5.22).
>>>
>>>
>>> Not exactly sure it's relevant, but from a script that wraps git where
>>> this error came up, the author of the script asks "are you on OS X?"
>>> http://groups.google.com/group/repo-discuss/msg/d6b4fd3d8a1677a2
>>> "Unfortunately, either Python or Mac OS X is busted.  With multiple cores
>>> present, we seem to get the result from waitpid() before all of the changes
>>> made by the child process are actually visible in the filesystem, so when we
>>> start the next child, the next child might be missing modifications it
>>> expected to see. "
>>>
>>> On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber wrote:

 Trying to pull:

 thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
 remote: Counting objects: 1859, done.
 remote: Compressing objects: 100% (1267/1267), done.
 remote: Total 1393 (delta 1087), reused 195 (delta 107)
 Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
 fatal: cannot pread pack file: No such file or directory
 fatal: index-pack failed

 Ideas? The interwebs suggest deleting some file from my .git folder
 that's not in there.

 Nico

 

>>>
>>
>

--~--~-~--~~~---~--~~
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: Formatting substrings in a views::Label

[Finnur Thorarinsson]

Oh, I see. I thought you meant the link since Brett said I had done this for
the About box (Now Aaron's code snippet makes more sense) :).
I didn't have to do any "bolding" of text in the About box, but I can see
you running into exactly the same problems I did with the link.
There be dragons. I have scars to prove it.

On Thu, Aug 27, 2009 at 08:01, Evan Martin  wrote:

> To be clear, Aaron's asking how to get the bold text in his paragraph,
> not the "More information..." link.  :)
>
> On Thu, Aug 27, 2009 at 7:42 AM, Finnur Thorarinsson
> wrote:
> >
> > It is only incredibly painful if you mix in the link in with other words
> in
> > the middle of a sentence, like I had to do with the About box. If you,
> > instead, have a link below the main text (like the mock shows) it is dead
> > simple and easy.
> > I don't see why you should avoid using Link in that case.
> >
> > On Thu, Aug 27, 2009 at 00:14, Aaron Boodman  wrote:
> >>
> >> On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google) >
> >> wrote:
> >> > I actually don't like having a mix of HTML/native UIs in the product.
> >> > When we switched to the NTP from the old Destinations page we made the
> >> > decision to have the content of tabs feel webby and the content of
> >> > dialogs feel dialoggy.
> >> >
> >> > As a result the NTP now feels pleasantly webby, but many of the HTML
> >> > dialogs don't feel dialoggy (focus issues, key accelerators, etc).
> >>
> >> This is why I decided to go with native for the install dialog.
> >>
> >> I feel like doing this the way that the about dialog is done would be
> >> incredibly painful and buggy because of wrapping issues. Also, at
> >> least on my machine (I am one of those weirdos that uses vista with
> >> the classic theme), the about dialog does not look right. The
> >> alignment of the links is slightly off.
> >>
> >> I would prefer to use the platform APIs that already know how to do
> >> this correctly. I'm thinking of adding something like
> >> set_bold_delimiter(const std::string&) on Label. You could use it like
> >> this:
> >>
> >> myLabel->set_bold_delimiter("*");
> >> myLabel->set_text("hello *world*");
> >>
> >> Is this totally lame?
> >>
> >> - 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: Problem with try servers?

[Nicolas Sylvain]

On Thu, Aug 27, 2009 at 3:17 AM, Ben Laurie  wrote:

>
> If I do a gcl try, I get prompted for a password for 'ben', which is
> my login name on my FreeBSD machine. Whatever I enter, the script then
> hangs - investigation shows that this is because it is prompting for a
> username, but gcl is swallowing the output.
>
> If I then enter b...@chromium.org, I get prompted for a password
> again. At that point, neither my googlecode password nor my gaia
> password work.
>
> Am I doing something wrong? How is this supposed to work?


I talked to benl offline, and he actually does not have a svn password yet.

He will get one once he gets committer access.

Nicolas


>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Git woes

[Nico Weber]

The "pack file truncated" theory sounds most likely. Is there any way
I could tell git to regenerate the newest N packfiles?

On Thu, Aug 27, 2009 at 8:00 AM, Evan Martin wrote:
> https://kerneltrap.org/mailarchive/git/2007/7/23/252538
> old and maybe obsolete, but has some exposition from Linus
>
> On Thu, Aug 27, 2009 at 7:51 AM, Evan Martin wrote:
>> Aside from basic stuff like running out of disk space, I have no idea
>> what would cause this problem.  (It's weird that pread would fail with
>> "no such file" when its API is to take an open file descriptor.)
>>
>> One workaround might be to try setting this defined, mentioned in the 
>> Makefile:
>> # Define NO_PREAD if you have a problem with pread() system call (e.g.
>> # cygwin.dll before v1.5.22).
>>
>>
>> Not exactly sure it's relevant, but from a script that wraps git where
>> this error came up, the author of the script asks "are you on OS X?"
>> http://groups.google.com/group/repo-discuss/msg/d6b4fd3d8a1677a2
>> "Unfortunately, either Python or Mac OS X is busted.  With multiple cores
>> present, we seem to get the result from waitpid() before all of the changes
>> made by the child process are actually visible in the filesystem, so when we
>> start the next child, the next child might be missing modifications it
>> expected to see. "
>>
>> On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber wrote:
>>>
>>> Trying to pull:
>>>
>>> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
>>> remote: Counting objects: 1859, done.
>>> remote: Compressing objects: 100% (1267/1267), done.
>>> remote: Total 1393 (delta 1087), reused 195 (delta 107)
>>> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
>>> fatal: cannot pread pack file: No such file or directory
>>> fatal: index-pack failed
>>>
>>> Ideas? The interwebs suggest deleting some file from my .git folder
>>> that's not in there.
>>>
>>> Nico
>>>
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
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: Formatting substrings in a views::Label

[Evan Martin]

To be clear, Aaron's asking how to get the bold text in his paragraph,
not the "More information..." link.  :)

On Thu, Aug 27, 2009 at 7:42 AM, Finnur Thorarinsson wrote:
>
> It is only incredibly painful if you mix in the link in with other words in
> the middle of a sentence, like I had to do with the About box. If you,
> instead, have a link below the main text (like the mock shows) it is dead
> simple and easy.
> I don't see why you should avoid using Link in that case.
>
> On Thu, Aug 27, 2009 at 00:14, Aaron Boodman  wrote:
>>
>> On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google)
>> wrote:
>> > I actually don't like having a mix of HTML/native UIs in the product.
>> > When we switched to the NTP from the old Destinations page we made the
>> > decision to have the content of tabs feel webby and the content of
>> > dialogs feel dialoggy.
>> >
>> > As a result the NTP now feels pleasantly webby, but many of the HTML
>> > dialogs don't feel dialoggy (focus issues, key accelerators, etc).
>>
>> This is why I decided to go with native for the install dialog.
>>
>> I feel like doing this the way that the about dialog is done would be
>> incredibly painful and buggy because of wrapping issues. Also, at
>> least on my machine (I am one of those weirdos that uses vista with
>> the classic theme), the about dialog does not look right. The
>> alignment of the links is slightly off.
>>
>> I would prefer to use the platform APIs that already know how to do
>> this correctly. I'm thinking of adding something like
>> set_bold_delimiter(const std::string&) on Label. You could use it like
>> this:
>>
>> myLabel->set_bold_delimiter("*");
>> myLabel->set_text("hello *world*");
>>
>> Is this totally lame?
>>
>> - 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] GYP buildbots

[Steven Knight]

Of interest to GYP developers (or anyone else who may need to roll the GYP
revision in DEPS):
The FYI (experimental) buildbot master now has a set of of canary slaves
that build Chromium with the latest tip-of-tree GYP on Linux/Mac/Win (and
run unit_tests and a few others, just for a sanity check):

http://build.chromium.org/buildbot/waterfall.fyi/waterfall?builder=Chromium%20Linux%20GYP&builder=Chromium%20Mac%20GYP&builder=Chromium%20XP%20GYP

Before you update the GYP revision in DEPS, it would be a Good Idea to check
these slaves to make sure they're green.

Another set of slaves run the stand-alone GYP test suite:

http://build.chromium.org/buildbot/waterfall.fyi/waterfall?builder=GYP%20Linux&builder=GYP%20Mac&builder=GYP%20XP

Anyone wanting to speed switching the official Linux build from SCons to
Make would be very welcome to dive in and help turn the "make" step of the
Linux bot green.

--SK

--~--~-~--~~~---~--~~
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: Git woes

[Nico Weber]

Didn't help. Oh well, back to my fallback svn client for now. Will
create a new git checkout in the new feature.

On Thu, Aug 27, 2009 at 9:12 AM, Evan Martin wrote:
> Try "git gc"
>
> On Thu, Aug 27, 2009 at 8:27 AM, Nico Weber wrote:
>> The "pack file truncated" theory sounds most likely. Is there any way
>> I could tell git to regenerate the newest N packfiles?
>>
>> On Thu, Aug 27, 2009 at 8:00 AM, Evan Martin wrote:
>>> https://kerneltrap.org/mailarchive/git/2007/7/23/252538
>>> old and maybe obsolete, but has some exposition from Linus
>>>
>>> On Thu, Aug 27, 2009 at 7:51 AM, Evan Martin wrote:
 Aside from basic stuff like running out of disk space, I have no idea
 what would cause this problem.  (It's weird that pread would fail with
 "no such file" when its API is to take an open file descriptor.)

 One workaround might be to try setting this defined, mentioned in the 
 Makefile:
 # Define NO_PREAD if you have a problem with pread() system call (e.g.
 # cygwin.dll before v1.5.22).


 Not exactly sure it's relevant, but from a script that wraps git where
 this error came up, the author of the script asks "are you on OS X?"
 http://groups.google.com/group/repo-discuss/msg/d6b4fd3d8a1677a2
 "Unfortunately, either Python or Mac OS X is busted.  With multiple cores
 present, we seem to get the result from waitpid() before all of the changes
 made by the child process are actually visible in the filesystem, so when 
 we
 start the next child, the next child might be missing modifications it
 expected to see. "

 On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber wrote:
>
> Trying to pull:
>
> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
> remote: Counting objects: 1859, done.
> remote: Compressing objects: 100% (1267/1267), done.
> remote: Total 1393 (delta 1087), reused 195 (delta 107)
> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
> fatal: cannot pread pack file: No such file or directory
> fatal: index-pack failed
>
> Ideas? The interwebs suggest deleting some file from my .git folder
> that's not in there.
>
> Nico
>
> >
>

>>>
>>
>

--~--~-~--~~~---~--~~
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: Git woes

[Dimitri Glazkov]

I've had this issue before and found that if I used svn rebase it
would sometimes fix it. So I am thinking perhaps instead of git pull,
you could attempt doing git fetch first and then git merge? This would
do the same thing, except not in atomic op.

:DG<

On Thu, Aug 27, 2009 at 10:49 AM, Nico Weber wrote:
>
> Didn't help. Oh well, back to my fallback svn client for now. Will
> create a new git checkout in the new feature.
>
> On Thu, Aug 27, 2009 at 9:12 AM, Evan Martin wrote:
>> Try "git gc"
>>
>> On Thu, Aug 27, 2009 at 8:27 AM, Nico Weber wrote:
>>> The "pack file truncated" theory sounds most likely. Is there any way
>>> I could tell git to regenerate the newest N packfiles?
>>>
>>> On Thu, Aug 27, 2009 at 8:00 AM, Evan Martin wrote:
 https://kerneltrap.org/mailarchive/git/2007/7/23/252538
 old and maybe obsolete, but has some exposition from Linus

 On Thu, Aug 27, 2009 at 7:51 AM, Evan Martin wrote:
> Aside from basic stuff like running out of disk space, I have no idea
> what would cause this problem.  (It's weird that pread would fail with
> "no such file" when its API is to take an open file descriptor.)
>
> One workaround might be to try setting this defined, mentioned in the 
> Makefile:
> # Define NO_PREAD if you have a problem with pread() system call (e.g.
> # cygwin.dll before v1.5.22).
>
>
> Not exactly sure it's relevant, but from a script that wraps git where
> this error came up, the author of the script asks "are you on OS X?"
> http://groups.google.com/group/repo-discuss/msg/d6b4fd3d8a1677a2
> "Unfortunately, either Python or Mac OS X is busted.  With multiple cores
> present, we seem to get the result from waitpid() before all of the 
> changes
> made by the child process are actually visible in the filesystem, so when 
> we
> start the next child, the next child might be missing modifications it
> expected to see. "
>
> On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber wrote:
>>
>> Trying to pull:
>>
>> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
>> remote: Counting objects: 1859, done.
>> remote: Compressing objects: 100% (1267/1267), done.
>> remote: Total 1393 (delta 1087), reused 195 (delta 107)
>> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
>> fatal: cannot pread pack file: No such file or directory
>> fatal: index-pack failed
>>
>> Ideas? The interwebs suggest deleting some file from my .git folder
>> that's not in there.
>>
>> Nico
>>
>> >
>>
>

>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Formatting substrings in a views::Label

[Evan Martin]

On Thu, Aug 27, 2009 at 7:42 AM, Scott Violet wrote:
>> myLabel->set_bold_delimiter("*");
>> myLabel->set_text("hello *world*");
>>
>> Is this totally lame?
>
> Then you have to worry about escape characters, which ends up being a
> bit finicky. I would rather see some way to add specify an attribute
> over a range of the text. Perhaps though we end up with what you are
> suggesting in our resources files. Hm.

To complete the discussion I had with Aaron, this is more or less what
I wrote for the pre-HTML history system, for formatting snippets that
contained bold text.  (It's especially tricky in the presence of
word-wrapping.)  You could probably dig the code out of the repository
history somewhere.

--~--~-~--~~~---~--~~
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: Formatting substrings in a views::Label

[Tim Steele]

On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google) wrote:

> I actually don't like having a mix of HTML/native UIs in the product.
> When we switched to the NTP from the old Destinations page we made the
> decision to have the content of tabs feel webby and the content of
> dialogs feel dialoggy.
>
> As a result the NTP now feels pleasantly webby, but many of the HTML
> dialogs don't feel dialoggy (focus issues, key accelerators, etc).


AFAIK there are only two such dialogs, and it sounds like focus / key
accelerator issues should be things we could fix, aren't they? There was
talk at one time about making more of the browser UI HTML based, having it
tweakable by extensions, stuff like that.. but I guess that is obsolete
now.  At least for Google Accounts login, it was nice to be able to just use
a provided standard HTML template and stuff it into an html dialog, and have
it look-and-feel like GAIA on all platforms (minus a few kinks).
To me the ability to do that seems useful in general, instead of having to
"fake it" when integrating with a web service that has a well known look and
feel (particularly on a platform geared towards the idea of integrating more
closely with web apps).

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] git-try now lives in depot_tools

[Evan Martin]

git-try is a Chrome-specific tool for running changes managed with git
against the trybots.

It probably always belonged in depot_tools, but I wrote it as a quick
hack and didn't do it the proper way.
It now is part of the depot_tools checkout and future patches should
go against that version.  I've taken my public repo down.

(git-cl is still in a separate repo because it's used by projects
other than Chrome.)

--~--~-~--~~~---~--~~
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: Copying of profiles across systems

[Peter Kasting]

On Wed, Aug 26, 2009 at 7:48 PM, PhistucK  wrote:

> Bearing the upcoming Chrome OS in mind, this should be taken into account
> quite strongly.
>

I don't think it's appropriate to speculate on what will and will not be
useful for Chrome OS until more details about it are made public.

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: Question about resource_dispatcher_host.h

[John Abd-El-Malek]

On Thu, Aug 27, 2009 at 11:57 AM, hap 497  wrote:

>
>
> On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson wrote:
>>
>>>
>>> On Mon, Aug 24, 2009 at 12:49 PM, hap 497 wrote:
>>> > Thanks. But the picture in the document shows there is only 1
>>> > ResourceDispatcherHost and there are 2 Renderer Processes:
>>> >
>>> >
>>> http://dev.chromium.org/developers/design-documents/multi-process-architecture
>>> > And the ResourceDispatcherHost has access to both Channels for each
>>> Renderer
>>> > Process.
>>>
>>> Information about each request including the originating renderer is
>>> tacked onto each URLRequest in the form of "ExtraRequestInfo." See one
>>> of the functions in there such as
>>> ResourceDispatcherHost::OnResponseCompleted for how this is retrieved.
>>>
>>
>> Right, information such as renderer process id is available, but there are
>> no pointers to the ResourceMessageFilter in there.  Using the process id,
>> you could get to the RenderProcessHost (but only on the UI thread) and from
>> there to the RMF.
>>
>>
>
> Thanks for all the answers.
>
> If ResourceMessageFilter has all the information for dispatching the
> message, why it needs to talk to ResourceDispatcherHost ( a singleton class)
> for dispatching? Looking at resource_dispatcher_host.h, I am not sure what
> centralized information it is holding so that each ResourceMessageFilter
> needs ResourceDispatcherHost for dispatching.
>

ResourceDispatcherHost is also used by other classes that represent
plugin/worker sub-processes.

Additionally, separating resource loading into a separate class makes
testing easier.

>
> Thank you for your help.
>
>
>
>
>
>>
>>> Brett
>>>
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Tales from the test_expectations ...

[Dimitri Glazkov]

It's like "Tales from the crypt", but less fun and actually scary.

I just found out that we wall-papered over about 80-100 tests in
fast/repaint dir. I will be removing bad baselines shortly.

The bad news is that this bumped our failures to 875 (from 778 this morning).

The good news is that they all (and more!) will be fixed once we fix
http://crbug.com/8630.

I think this case particularly highlights the nature of our layout
test woes: there are only a handful of actual problems,
splattered over a large area. The best analogy here is an oil spill.
And we are all pelicans.

:DG<

P.S.: evmar, eroman: this may be why your attempts to write
layoutTestController.display(); for test_shell were so frustrating:
the regressions you were seeing might have been false-negatives.

--~--~-~--~~~---~--~~
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: Question about resource_dispatcher_host.h

[hap 497]

On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek  wrote:

>
>
> On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson  wrote:
>
>>
>> On Mon, Aug 24, 2009 at 12:49 PM, hap 497 wrote:
>> > Thanks. But the picture in the document shows there is only 1
>> > ResourceDispatcherHost and there are 2 Renderer Processes:
>> >
>> >
>> http://dev.chromium.org/developers/design-documents/multi-process-architecture
>> > And the ResourceDispatcherHost has access to both Channels for each
>> Renderer
>> > Process.
>>
>> Information about each request including the originating renderer is
>> tacked onto each URLRequest in the form of "ExtraRequestInfo." See one
>> of the functions in there such as
>> ResourceDispatcherHost::OnResponseCompleted for how this is retrieved.
>>
>
> Right, information such as renderer process id is available, but there are
> no pointers to the ResourceMessageFilter in there.  Using the process id,
> you could get to the RenderProcessHost (but only on the UI thread) and from
> there to the RMF.
>
>

Thanks for all the answers.

If ResourceMessageFilter has all the information for dispatching the
message, why it needs to talk to ResourceDispatcherHost ( a singleton class)
for dispatching? Looking at resource_dispatcher_host.h, I am not sure what
centralized information it is holding so that each ResourceMessageFilter
needs ResourceDispatcherHost for dispatching.

Thank you for your help.





>
>> Brett
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: [chromium-reviews] Re: WebKit deps roll 47797:47804

[Dimitri Glazkov]

Tests only pass if they are actually not loading any media. Which is a
number of tests, yes. As an alternative maybe we could just agree
among all WebKit gardeners to dump the new failures to bug 16779 and
not add them to the end of test_expectations?

:DG<

On Thu, Aug 27, 2009 at 1:25 PM, Ojan Vafai wrote:
> -chromium-reviews
> +chromium-dev
> Don't we currently pass a large percentage of the LayoutTests/media tests?
> Won't we lose coverage of these tests by doing this?
> Maybe it's worth the savings maintenance cost until we have a complete
> solution for them?
>
> Ojan
> On Thu, Aug 27, 2009 at 11:46 AM, Dimitri Glazkov 
> wrote:
>>
>> BTW, about to filter out all LayoutTests/media out for now, skipping
>> them. We can't have codecs for most of these tests, so we (Alpha and
>> myself) decided it's easier to skip them for now. Permanent solution
>> coming in Q4.
>>
>> :DG<
>>
>> On Thu, Aug 27, 2009 at 11:42 AM, Ojan Vafai wrote:
>> > I see what you're saying. I think the best solution here is to just have
>> > one
>> > line with two bugs listed. This will also help whoever is going to fix
>> > the
>> > test as they'll be able to easily see all the reason's it's failing.
>> > BUG20376 BUG13907 WIN : LayoutTests/media/video-src-remove.html =
>> > TIMEOUT
>> > FAIL
>> > That OK?
>> > On Thu, Aug 27, 2009 at 11:02 AM, Jeremy Orlow 
>> > wrote:
>> >>
>> >> Yes, but it's not flaky now.  If you'd like, I can move the commented
>> >> out
>> >> one down to right after the new version of it.  I think what'd be even
>> >> better is if multiple entries for one layout test didn't cause the
>> >> script to
>> >> parse.  Or it'd at least be nice if we could list 2 bugs for one test.
>> >> The commented out one is NOT deadit's another type of failure that
>> >> is
>> >> currently overshadowed by the new type of failure.
>> >>
>> >> On Thu, Aug 27, 2009 at 10:57 AM, Ojan Vafai  wrote:
>> >>>
>> >>> On Thu, Aug 27, 2009 at 10:34 AM, Jeremy Orlow 
>> >>> wrote:
>> 
>>  On Thu, Aug 27, 2009 at 10:31 AM,  wrote:
>> >
>> > http://codereview.chromium.org/173555/diff/1/2
>> > File webkit/tools/layout_tests/test_expectations.txt (right):
>> >
>> > http://codereview.chromium.org/173555/diff/1/2#newcode745
>> > Line 745: //BUG13907 WIN : LayoutTests/media/video-src-remove.html =
>> > FAIL
>> > Why leave this in commented out instead of just removing it?
>> 
>>  Well, there's 2 problems with that test.  1) it's flaky and 2) it's
>>  failing.  Someone fixing 2 doesn't necessarily fix 1.  So they'll
>>  probably
>>  want to add it back into that list when they're finished.  It's also
>>  documentation.  I don't really see any downside.
>> >>>
>> >>> We have a process for dealing with flaky tests. If it passes sometimes
>> >>> and fails sometimes, mark it PASS FAIL. Why is this case an exception?
>> >>> I see
>> >>> two downsides:
>> >>>
>> >>> Now when it fails, it will turn the tree red.
>> >>> If we make a practice of leaving in commented out tests this file
>> >>> becomes
>> >>> even more bloated than it is now.
>> >
>> >
>
>

--~--~-~--~~~---~--~~
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: [chromium-reviews] Re: WebKit deps roll 47797:47804

[Ojan Vafai]

-chromium-reviews
+chromium-dev

Don't we currently pass a large percentage of the LayoutTests/media tests?
Won't we lose coverage of these tests by doing this?
Maybe it's worth the savings maintenance cost until we have a complete
solution for them?

Ojan

On Thu, Aug 27, 2009 at 11:46 AM, Dimitri Glazkov wrote:

>
> BTW, about to filter out all LayoutTests/media out for now, skipping
> them. We can't have codecs for most of these tests, so we (Alpha and
> myself) decided it's easier to skip them for now. Permanent solution
> coming in Q4.
>
> :DG<
>
> On Thu, Aug 27, 2009 at 11:42 AM, Ojan Vafai wrote:
> > I see what you're saying. I think the best solution here is to just have
> one
> > line with two bugs listed. This will also help whoever is going to fix
> the
> > test as they'll be able to easily see all the reason's it's failing.
> > BUG20376 BUG13907 WIN : LayoutTests/media/video-src-remove.html = TIMEOUT
> > FAIL
> > That OK?
> > On Thu, Aug 27, 2009 at 11:02 AM, Jeremy Orlow 
> wrote:
> >>
> >> Yes, but it's not flaky now.  If you'd like, I can move the commented
> out
> >> one down to right after the new version of it.  I think what'd be even
> >> better is if multiple entries for one layout test didn't cause the
> script to
> >> parse.  Or it'd at least be nice if we could list 2 bugs for one test.
> >> The commented out one is NOT deadit's another type of failure that
> is
> >> currently overshadowed by the new type of failure.
> >>
> >> On Thu, Aug 27, 2009 at 10:57 AM, Ojan Vafai  wrote:
> >>>
> >>> On Thu, Aug 27, 2009 at 10:34 AM, Jeremy Orlow 
> >>> wrote:
> 
>  On Thu, Aug 27, 2009 at 10:31 AM,  wrote:
> >
> > http://codereview.chromium.org/173555/diff/1/2
> > File webkit/tools/layout_tests/test_expectations.txt (right):
> >
> > http://codereview.chromium.org/173555/diff/1/2#newcode745
> > Line 745: //BUG13907 WIN : LayoutTests/media/video-src-remove.html =
> > FAIL
> > Why leave this in commented out instead of just removing it?
> 
>  Well, there's 2 problems with that test.  1) it's flaky and 2) it's
>  failing.  Someone fixing 2 doesn't necessarily fix 1.  So they'll
> probably
>  want to add it back into that list when they're finished.  It's also
>  documentation.  I don't really see any downside.
> >>>
> >>> We have a process for dealing with flaky tests. If it passes sometimes
> >>> and fails sometimes, mark it PASS FAIL. Why is this case an exception?
> I see
> >>> two downsides:
> >>>
> >>> Now when it fails, it will turn the tree red.
> >>> If we make a practice of leaving in commented out tests this file
> becomes
> >>> even more bloated than it is now.
> >
> >
>

--~--~-~--~~~---~--~~
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: FreeBSD port, take 2

[Wan-Teh Chang]

On Thu, Aug 27, 2009 at 3:02 AM, Ben Laurie wrote:
>
> I forgot to mention - there's a single file that may not be complete,
> base/crypto/signature_verifier_nss.cc - this is because the FreeBSD
> port of NSS is too old and doesn't have a function it needs. I'll get
> to that at some point soon, but I don't anticipate it being a problem.

Our code can be built with NSS 3.12, but we should now use
NSS 3.12.3 or later for fixes of the security vulnerabilities in
the "PKI Layer Cake" paper.

Wan-Teh

--~--~-~--~~~---~--~~
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: Git woes

[Nico Weber]

I accidentally fixed the problem by running something like

  rm -rf .git/svn/
  git svn fetch; git merge trunk
  git merge refs/remotes/origin/trunk
  git checkout -f HEAD
  git pull

. Not sure what fixed it, but pulling works again. Yay, I guess, but
of course I fixed it about 2 minutes before someone asked me to send a
dtrace to the git mailing list :-/

On Thu, Aug 27, 2009 at 10:54 AM, Dimitri Glazkov wrote:
> I've had this issue before and found that if I used svn rebase it
> would sometimes fix it. So I am thinking perhaps instead of git pull,
> you could attempt doing git fetch first and then git merge? This would
> do the same thing, except not in atomic op.
>
> :DG<
>
> On Thu, Aug 27, 2009 at 10:49 AM, Nico Weber wrote:
>>
>> Didn't help. Oh well, back to my fallback svn client for now. Will
>> create a new git checkout in the new feature.
>>
>> On Thu, Aug 27, 2009 at 9:12 AM, Evan Martin wrote:
>>> Try "git gc"
>>>
>>> On Thu, Aug 27, 2009 at 8:27 AM, Nico Weber wrote:
 The "pack file truncated" theory sounds most likely. Is there any way
 I could tell git to regenerate the newest N packfiles?

 On Thu, Aug 27, 2009 at 8:00 AM, Evan Martin wrote:
> https://kerneltrap.org/mailarchive/git/2007/7/23/252538
> old and maybe obsolete, but has some exposition from Linus
>
> On Thu, Aug 27, 2009 at 7:51 AM, Evan Martin wrote:
>> Aside from basic stuff like running out of disk space, I have no idea
>> what would cause this problem.  (It's weird that pread would fail with
>> "no such file" when its API is to take an open file descriptor.)
>>
>> One workaround might be to try setting this defined, mentioned in the 
>> Makefile:
>> # Define NO_PREAD if you have a problem with pread() system call (e.g.
>> # cygwin.dll before v1.5.22).
>>
>>
>> Not exactly sure it's relevant, but from a script that wraps git where
>> this error came up, the author of the script asks "are you on OS X?"
>> http://groups.google.com/group/repo-discuss/msg/d6b4fd3d8a1677a2
>> "Unfortunately, either Python or Mac OS X is busted.  With multiple cores
>> present, we seem to get the result from waitpid() before all of the 
>> changes
>> made by the child process are actually visible in the filesystem, so 
>> when we
>> start the next child, the next child might be missing modifications it
>> expected to see. "
>>
>> On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber wrote:
>>>
>>> Trying to pull:
>>>
>>> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
>>> remote: Counting objects: 1859, done.
>>> remote: Compressing objects: 100% (1267/1267), done.
>>> remote: Total 1393 (delta 1087), reused 195 (delta 107)
>>> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
>>> fatal: cannot pread pack file: No such file or directory
>>> fatal: index-pack failed
>>>
>>> Ideas? The interwebs suggest deleting some file from my .git folder
>>> that's not in there.
>>>
>>> Nico
>>>
>>> >
>>>
>>
>

>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] OS X debugging tip - turn off the sandbox.

[Jeremy Moskovich]

When the sandbox gets in the way of the kernel or other parts of the system,
very strange things can happen.

If you're running into unexplained behavior on OS X try disabling the
sandbox by running with --no-sandbox.

This was the key to a crash we where looking at today which is why I'm
sending this mail.

More tips on OS X debugging can be found here:
http://dev.chromium.org/developers/debugging-on-os-x

Best regards,
Jeremy

--~--~-~--~~~---~--~~
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: The webkit canary bots, now with performance tests!

[Nicolas Sylvain]

And now it is also running test_shell_tests in purify and valgrind:
http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=&builder=Webkit+(purify+webkit.org)&builder=Webkit+Linux+(valgrind+webkit.org)


Nicolas


On Wed, Aug 26, 2009 at 11:53 PM, Adam Barth  wrote:

>
> Yay!  This is fantastic!
>
> Adam
>
>
> On Wed, Aug 26, 2009 at 11:47 PM, Darin Fisher wrote:
> > Thanks to bevc and nsylvain, we now have performance bots testing
> chromium
> > with the very latest webkit code:
> >
> http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=&builder=XP+Perf+(webkit.org)&builder=Linux+Perf+(webkit.org)&reload=none
> > (no mac bot yet)
> > The dashboard is here:
> > http://build.chromium.org/buildbot/perf/dashboard/overview-canary.html
> > Now, we can see with much finer granularity the impact of webkit changes
> on
> > the chromium performance tests!  No more guessing as to what will happen
> to
> > performance when we roll deps ;-)  Marvelous!
> > -Darin
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: [chromium-reviews] Re: WebKit deps roll 47797:47804

[Andrew Scherkus]

The media tests are highly platform specific at the moment due to
differences in codec support.  Keeping them lumped together under one bug
works for me.
Andrew

On Thu, Aug 27, 2009 at 1:55 PM, Dimitri Glazkov wrote:

>
> Tests only pass if they are actually not loading any media. Which is a
> number of tests, yes. As an alternative maybe we could just agree
> among all WebKit gardeners to dump the new failures to bug 16779 and
> not add them to the end of test_expectations?
>
> :DG<
>
> On Thu, Aug 27, 2009 at 1:25 PM, Ojan Vafai wrote:
> > -chromium-reviews
> > +chromium-dev
> > Don't we currently pass a large percentage of the LayoutTests/media
> tests?
> > Won't we lose coverage of these tests by doing this?
> > Maybe it's worth the savings maintenance cost until we have a complete
> > solution for them?
> >
> > Ojan
> > On Thu, Aug 27, 2009 at 11:46 AM, Dimitri Glazkov  >
> > wrote:
> >>
> >> BTW, about to filter out all LayoutTests/media out for now, skipping
> >> them. We can't have codecs for most of these tests, so we (Alpha and
> >> myself) decided it's easier to skip them for now. Permanent solution
> >> coming in Q4.
> >>
> >> :DG<
> >>
> >> On Thu, Aug 27, 2009 at 11:42 AM, Ojan Vafai wrote:
> >> > I see what you're saying. I think the best solution here is to just
> have
> >> > one
> >> > line with two bugs listed. This will also help whoever is going to fix
> >> > the
> >> > test as they'll be able to easily see all the reason's it's failing.
> >> > BUG20376 BUG13907 WIN : LayoutTests/media/video-src-remove.html =
> >> > TIMEOUT
> >> > FAIL
> >> > That OK?
> >> > On Thu, Aug 27, 2009 at 11:02 AM, Jeremy Orlow 
> >> > wrote:
> >> >>
> >> >> Yes, but it's not flaky now.  If you'd like, I can move the commented
> >> >> out
> >> >> one down to right after the new version of it.  I think what'd be
> even
> >> >> better is if multiple entries for one layout test didn't cause the
> >> >> script to
> >> >> parse.  Or it'd at least be nice if we could list 2 bugs for one
> test.
> >> >> The commented out one is NOT deadit's another type of failure
> that
> >> >> is
> >> >> currently overshadowed by the new type of failure.
> >> >>
> >> >> On Thu, Aug 27, 2009 at 10:57 AM, Ojan Vafai 
> wrote:
> >> >>>
> >> >>> On Thu, Aug 27, 2009 at 10:34 AM, Jeremy Orlow  >
> >> >>> wrote:
> >> 
> >>  On Thu, Aug 27, 2009 at 10:31 AM,  wrote:
> >> >
> >> > http://codereview.chromium.org/173555/diff/1/2
> >> > File webkit/tools/layout_tests/test_expectations.txt (right):
> >> >
> >> > http://codereview.chromium.org/173555/diff/1/2#newcode745
> >> > Line 745: //BUG13907 WIN : LayoutTests/media/video-src-remove.html
> =
> >> > FAIL
> >> > Why leave this in commented out instead of just removing it?
> >> 
> >>  Well, there's 2 problems with that test.  1) it's flaky and 2) it's
> >>  failing.  Someone fixing 2 doesn't necessarily fix 1.  So they'll
> >>  probably
> >>  want to add it back into that list when they're finished.  It's
> also
> >>  documentation.  I don't really see any downside.
> >> >>>
> >> >>> We have a process for dealing with flaky tests. If it passes
> sometimes
> >> >>> and fails sometimes, mark it PASS FAIL. Why is this case an
> exception?
> >> >>> I see
> >> >>> two downsides:
> >> >>>
> >> >>> Now when it fails, it will turn the tree red.
> >> >>> If we make a practice of leaving in commented out tests this file
> >> >>> becomes
> >> >>> even more bloated than it is now.
> >> >
> >> >
> >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Question about resource_dispatcher_host.h

[Michael Nordman]

On Thu, Aug 27, 2009 at 11:57 AM, hap 497  wrote:

>
>
> On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson wrote:
>>
>>>
>>> On Mon, Aug 24, 2009 at 12:49 PM, hap 497 wrote:
>>> > Thanks. But the picture in the document shows there is only 1
>>> > ResourceDispatcherHost and there are 2 Renderer Processes:
>>> >
>>> >
>>> http://dev.chromium.org/developers/design-documents/multi-process-architecture
>>> > And the ResourceDispatcherHost has access to both Channels for each
>>> Renderer
>>> > Process.
>>>
>>> Information about each request including the originating renderer is
>>> tacked onto each URLRequest in the form of "ExtraRequestInfo." See one
>>> of the functions in there such as
>>> ResourceDispatcherHost::OnResponseCompleted for how this is retrieved.
>>>
>>
>> Right, information such as renderer process id is available, but there are
>> no pointers to the ResourceMessageFilter in there.  Using the process id,
>> you could get to the RenderProcessHost (but only on the UI thread) and from
>> there to the RMF.
>>
>>
>
> Thanks for all the answers.
>
> If ResourceMessageFilter has all the information for dispatching the
> message, why it needs to talk to ResourceDispatcherHost ( a singleton class)
> for dispatching? Looking at resource_dispatcher_host.h, I am not sure what
> centralized information it is holding so that each ResourceMessageFilter
> needs ResourceDispatcherHost for dispatching.
>
> Thank you for your help.
>

Resource loading involves interactions with a number of objects that span
all child processes (renderers, workers, plugins, etc). So while
ResourceMessageFilter does contain all of the info needed to communicate a
response back to its child process, it does not contain all of the
information to handle the request. That is where ResourceDispatcherHost
comes in. It does contain all of the info needed to fully handle the
request.

Things like... SafeBrowsingService, UserScriptListener, a centralized timer
for stats collection, the list of 'observers' to spam with info about what
requests are happening system wide, a centralized place to all things
down... etc...

Not sure we're doing this yet, but it also provides a centralized place to
prioritize requests on behalf of processA vs processB.

--~--~-~--~~~---~--~~
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: The webkit canary bots, now with performance tests!

[Darin Fisher]

Thank you!!!
On Thu, Aug 27, 2009 at 4:03 PM, Nicolas Sylvain wrote:

> And now it is also running test_shell_tests in purify and valgrind:
>
> http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=&builder=Webkit+(purify+webkit.org)&builder=Webkit+Linux+(valgrind+webkit.org)
>
>
> 
> Nicolas
>
>
> On Wed, Aug 26, 2009 at 11:53 PM, Adam Barth  wrote:
>
>>
>> Yay!  This is fantastic!
>>
>> Adam
>>
>>
>> On Wed, Aug 26, 2009 at 11:47 PM, Darin Fisher wrote:
>> > Thanks to bevc and nsylvain, we now have performance bots testing
>> chromium
>> > with the very latest webkit code:
>> >
>> http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=&builder=XP+Perf+(webkit.org)&builder=Linux+Perf+(webkit.org)&reload=none
>> > (no mac bot yet)
>> > The dashboard is here:
>> > http://build.chromium.org/buildbot/perf/dashboard/overview-canary.html
>> > Now, we can see with much finer granularity the impact of webkit changes
>> on
>> > the chromium performance tests!  No more guessing as to what will happen
>> to
>> > performance when we roll deps ;-)  Marvelous!
>> > -Darin
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Copying of profiles across systems

[Evan Stade]

On Wed, Aug 26, 2009 at 7:48 PM, PhistucK wrote:
> Bearing the upcoming Chrome OS in mind, this should be taken into account
> quite strongly.
> Regular programs will probably not move cleanly and nicely from Windows to
> Chrome OS, but, at least, Google products should migrate seamlessly, without
> any data loss (and passwords are a very important part, too), in my opinion.
> Having a specific export option for passwords only (only during the
> transition, only when the profile is not used anymore in the former OS),
> even unencrypted and then re-encrypt them when Chrome on the new OS finds an
> old profile from another platform - could be some sort of a solution.
> ☆PhistucK

Indeed, I suspect that "regular Windows programs" will have a very
hard time migrating cleanly to ChromeOS, and I somehow doubt that
profile portability would be the hardest step.

>
>
> On Wed, Aug 26, 2009 at 23:20, Dan Kegel  wrote:
>>
>> On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlow wrote:
>> >> I really like the idea of being able to move people between
>> >> operating systems and just bringing the profile along
>> >> without having to export and import...
>> >>
>> >> (seems to me there are online services that offer that
>> >> convenience, but being able to do it with the raw file
>> >> is cool.)
>> >
>> > In what scenarios would this be useful?  If it's easy to do, it'd be
>> > cool,
>> > but it seems like this would have a very small minority of users.
>>
>> When migrating users between operating systems.  Say,
>> a company decides to migrate all its office workers from
>> Windows to Linux.   Or if somebody installs Ubuntu on
>> a Windows machine on its own; I believe they try
>> to migrate settings when you do that.
>>
>> One goal of Chrome was to make operating systems not matter;
>> one way to do that is to make the profile file (mostly) portable.
>> - Dan
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] How to run chrom automation test

[hap 497]

Hi,

In src/chrome/test/automation, it has a automation_proxy_uitest.cc, How can
I run the automation test on MacOSX?
I see that is a directory
xcodebuild/chrome.build/Debug/automated_ui_tests.build, but there is no
*.app under there.

Thank you for any tip.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---