[chromium-dev] Re: Formatting substrings in a views::Label
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 a...@chromium.org 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] The webkit canary bots, now with performance tests!
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: Git woes
Not knowingly, at least. `git --version` says 1.6.0.2, which I believe is what it always said. On Wed, Aug 26, 2009 at 10:50 PM, Jeremy Moskovichjer...@chromium.org wrote: Git is comprised of billions of tiny orthogonal binaries. When this happened to me the cause was some old git binaries in the path that where being called by others, the version mismatch was silent and caused this error. Have you upgraded to a new version of git recently that might cause such a mismatch? Best regards, Jeremy On Wed, Aug 26, 2009 at 10:42 PM, Nico Weber tha...@chromium.org 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: The webkit canary bots, now with performance tests!
Yay! This is fantastic! Adam On Wed, Aug 26, 2009 at 11:47 PM, Darin Fisherda...@chromium.org 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: Formatting substrings in a views::Label
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 Steelet...@chromium.org 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 a...@chromium.org 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
On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google)b...@chromium.org 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
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
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 Laurieb...@google.com 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?
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?
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 Laurieb...@chromium.org 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
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 a...@chromium.org wrote: On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google)b...@chromium.org 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
On Thu, Aug 27, 2009 at 2:57 AM, Ben Laurieb...@google.com 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
On Thu, Aug 27, 2009 at 8:13 AM, Ben Laurieb...@google.com wrote: On Thu, Aug 27, 2009 at 3:56 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 27, 2009 at 2:57 AM, Ben Laurieb...@google.com 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
On Thu, Aug 27, 2009 at 12:14 AM, Aaron Boodmana...@chromium.org wrote: On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google)b...@chromium.org 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
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 Webertha...@chromium.org 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
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 Martine...@chromium.org 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 Webertha...@chromium.org 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
On Thu, Aug 27, 2009 at 3:56 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 27, 2009 at 2:57 AM, Ben Laurieb...@google.com 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
Awesome, thanks! On Thu, Aug 27, 2009 at 8:50 AM, Steven Knights...@chromium.org 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%20GYPbuilder=Chromium%20Mac%20GYPbuilder=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%20Linuxbuilder=GYP%20Macbuilder=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
Try git gc On Thu, Aug 27, 2009 at 8:27 AM, Nico Webertha...@chromium.org 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 Martine...@chromium.org 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 Martine...@chromium.org 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 Webertha...@chromium.org 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
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 e...@chromium.org 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 Thorarinssonfin...@chromium.org 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 a...@chromium.org wrote: On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google)b...@chromium.org 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?
On Thu, Aug 27, 2009 at 3:17 AM, Ben Laurie b...@chromium.org 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
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 Martine...@chromium.org 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 Martine...@chromium.org 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 Webertha...@chromium.org 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
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 Thorarinssonfin...@chromium.org 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 a...@chromium.org wrote: On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google)b...@chromium.org 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
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%20GYPbuilder=Chromium%20Mac%20GYPbuilder=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%20Linuxbuilder=GYP%20Macbuilder=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
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 Martine...@chromium.org wrote: Try git gc On Thu, Aug 27, 2009 at 8:27 AM, Nico Webertha...@chromium.org 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 Martine...@chromium.org 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 Martine...@chromium.org 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 Webertha...@chromium.org 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
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 Webertha...@chromium.org 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 Martine...@chromium.org wrote: Try git gc On Thu, Aug 27, 2009 at 8:27 AM, Nico Webertha...@chromium.org 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 Martine...@chromium.org 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 Martine...@chromium.org 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 Webertha...@chromium.org 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
On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google) b...@chromium.orgwrote: 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
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
On Wed, Aug 26, 2009 at 7:48 PM, PhistucK phist...@gmail.com 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
On Thu, Aug 27, 2009 at 11:57 AM, hap 497 hap...@gmail.com wrote: On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek j...@chromium.orgwrote: On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.orgwrote: On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com 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 ...
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
On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek j...@chromium.org wrote: On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.org wrote: On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com 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
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 Vafaio...@chromium.org 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 dglaz...@chromium.org 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 Vafaio...@chromium.org 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 jor...@chromium.org 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 o...@chromium.org wrote: On Thu, Aug 27, 2009 at 10:34 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 27, 2009 at 10:31 AM, o...@chromium.org 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
On Thu, Aug 27, 2009 at 3:02 AM, Ben Laurieb...@google.com 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
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 Glazkovdglaz...@chromium.org 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 Webertha...@chromium.org 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 Martine...@chromium.org wrote: Try git gc On Thu, Aug 27, 2009 at 8:27 AM, Nico Webertha...@chromium.org 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 Martine...@chromium.org 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 Martine...@chromium.org 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 Webertha...@chromium.org 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.
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!
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) 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 aba...@chromium.org wrote: Yay! This is fantastic! Adam On Wed, Aug 26, 2009 at 11:47 PM, Darin Fisherda...@chromium.org 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
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 dglaz...@chromium.orgwrote: 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 Vafaio...@chromium.org 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 dglaz...@chromium.org 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 Vafaio...@chromium.org 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 jor...@chromium.org 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 o...@chromium.org wrote: On Thu, Aug 27, 2009 at 10:34 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 27, 2009 at 10:31 AM, o...@chromium.org 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
On Thu, Aug 27, 2009 at 11:57 AM, hap 497 hap...@gmail.com wrote: On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek j...@chromium.orgwrote: On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.orgwrote: On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com 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!
Thank you!!! On Thu, Aug 27, 2009 at 4:03 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: 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) 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 aba...@chromium.org wrote: Yay! This is fantastic! Adam On Wed, Aug 26, 2009 at 11:47 PM, Darin Fisherda...@chromium.org 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
On Wed, Aug 26, 2009 at 7:48 PM, PhistucKphist...@gmail.com 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 d...@kegel.com wrote: On Wed, Aug 26, 2009 at 12:59 PM, Jeremy Orlowjor...@chromium.org 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 -~--~~~~--~~--~--~---
