[chromium-dev] Re: [Chrome-team] Coding style and code size
On Wed, Jul 22, 2009 at 12:40 AM, Stephen Adams s...@chromium.org wrote:
This is one example of where coding style affects code size:
int foo(const std::wstring s);
...
int x = foo(LHello);
The compiler generates an expression-lifetime temporary object of type
std::wstring, which entails calls to the constructor and destructor.
This happens at every call site where the argument gets implicitly
converted; there is an additional pair of calls.
If you provide an overload
int foo(const wchar_t* s) { return foo(std::wstring(s)); }
this moves the constructor / destructor call into the overload (and
hopefully the overload does not get inlined).
How effective is this at shrinking the overall code size?
I'm not sure that it is worth-while. The function has to be called many
times to get much saving, since the saving is about 40 bytes per call site
(win).
The savings on Windows and Linux are comparable: 0.11-0.12% for the four
functions in the changelist. The functions in the change list are ideal
candidates because they are called many times - 397 calls.
win: save 17k of 15MB
linux: save 33k of 28MB (stripped)
http://codereview.chromium.org/159156
For the record, on Windows you built in release and not a whole program
optimized build so your test is not that valuable.
You need to set CHROMIUM_BUILD=_official first to enable LTCG.
M-A
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Shankland: Thanks for giving my back pixels, browser makers
Did we not plan to allow them even one bar higher? I had thought that was the resolution for the fellow who wanted to add a bookmarks button next to the page and tools menus. On Tue, Jul 28, 2009 at 10:05 AM, Aaron Boodmana...@chromium.org wrote: One person who, like me, would probably prefer toolstrips on the bookmark bar: http://news.cnet.com/8301-17939_109-10296433-2.html - 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] Duplicate expectations?
We used to have to run: run_webkit_tests.sh --lint-test-files in order to check for duplicate WebKit layout test expectations. A while back, this was turned into a pre-submit hook so we couldn't forget to run it. However, in the last couple of days, both pkasting and I have been tripped up by this. What happened? Did it get lost, or did we change our minds? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Shankland: Thanks for giving my back pixels, browser makers
Yes, but for v1 we will just have one home for them. We are trying to decide between the bookmark bar and the bottom bar now. They both have their plusses and minuses: - The bookmark bar is better for people who already use the bookmark bar, particularly if it isn't already full. - The bottom bar is a lot simpler to implement and better for people who don't use the bookmark bar, or people who would have many toolstrips. On Tue, Jul 28, 2009 at 10:11 AM, Evan Martine...@chromium.org wrote: Did we not plan to allow them even one bar higher? I had thought that was the resolution for the fellow who wanted to add a bookmarks button next to the page and tools menus. On Tue, Jul 28, 2009 at 10:05 AM, Aaron Boodmana...@chromium.org wrote: One person who, like me, would probably prefer toolstrips on the bookmark bar: http://news.cnet.com/8301-17939_109-10296433-2.html - 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: Duplicate expectations?
No idea. I was similarly burned by this. I wish it could be run as a presubmit check. -Darin On Tue, Jul 28, 2009 at 11:01 AM, Mike Pinkerton pinker...@chromium.orgwrote: We used to have to run: run_webkit_tests.sh --lint-test-files in order to check for duplicate WebKit layout test expectations. A while back, this was turned into a pre-submit hook so we couldn't forget to run it. However, in the last couple of days, both pkasting and I have been tripped up by this. What happened? Did it get lost, or did we change our minds? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-extensions] Inter-extension communication API proposal
+chromium-dev
I think this is great. I suggest creating a wiki page with a design
for this so that we can refer to it whenever we implement, and a bug
that refers to the wiki page.
Up until now, we've been putting our designs here:
http://dev.chromium.org/developers/design-documents/extensions (see
proposed api), but that page isn't editable without a @chromium.org
account.
I've been thinking we should move that content to the wiki so that it
is editable by all. So if you want, you could be the first.
Besides that, a few minor comments:
1. I think we should add a permission for inter-extension
communication once we have a permissions mechanism. That is, an
extension should have to declare in the manifest which extensions it
would like to contact. This is just a security precaution against the
extension accidentally leaking privileges if it gets XSS'd or
something.
On Tue, Jul 28, 2009 at 10:58 AM, James Robinsonjam...@google.com wrote:
I think that extensions should be able to communicate with each other
using message passing. Currently, it's possible to do something like
this:
var ext = new chrome.Extension('abcdefgh...');
var port = ext.connect('channel from another world!');
port.postMessage({message: im in ur channel});
However, there are a few problems with this approach. First, it's
probably a bug that it works. The more serious issue is that a
onConnect event is fired at extension 'abcdefgh...' and there is no
way for that extension to know that the port is not from a content
script within the same extension but from another extension. An
extension should be able to allow other extensions to open connections
to it, be explicitly aware of where the connection is coming from, and
then communicate with it using the existing chrome.extension.Port
system.
This would require two new APIs on the chrome.extension object, based
on the ones presented in
http://dev.chromium.org/developers/design-documents/extensions/content-scripts:
// Open a channel to another extension with the provided ID.
// If no extension with the provided ID exists, nothing happens.
// Otherwise the chrome.extension.onConnectExternal event is fired
// to all components of the extension with the provided ID each time
// the method is called.
// The channel can optionally be named. This name will be sent along
with the
// onConnectExternal event
Port connectExternal(String ID, [String channelName])
2. I think we can merge connect() and connectExternal() by adding an
optional param to connect() that specifies the target extension. If
omitted it defaults to the current extension.
// Fired when another extension opens a channel to this extension via
// chrome.extension.connectExternal().
// If a channelName was provided, it is accessible via port.name.
Event onConnectExternal(Object port)
In order for an extension to know what the other side of a connection
is I'd also propose adding the following property to the
chrome.extension.Port class:
// ID of the extension at the other side of this port.
String senderID;
An extension could check this field in the onConnectExternal handler
and compare it to a whitelist/blacklist to decide whether to attach
onMessage handlers. An extension might also want to expose some UI to
the user listing all connected extensions.
The other issue to address is startup order. The order in which the
scripts within different background pages is not defined, which is
entirely reasonable, but it means that doing the obvious thing:
script
var port = chrome.extension.connectExternal('abcdef..');
/script
would work unreliably depending on the exact order in which the
background pages get loaded, the event handlers get registered, and
the events are fired. To resolve this I think that all connectExternal
() events be queued until each extension's background page has loaded,
so that any handler registration code in top-level scripts has a
chance to run.
This seems reasonable. It might be possible to be even cleverer if we
know who wants to connect to who by way of what they declare in their
manifests.
- 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: [chromium-extensions] Inter-extension communication API proposal
On Tue, Jul 28, 2009 at 11:30 AM, Drew Wilsonatwil...@chromium.org wrote: SGTM. Note that we're essentially duplicating (assumedly intentionally so) the window.postMessage() APIs which require specifying a target domain and whose connect event has a source and origin attribute specifying the window that sent the message. Yeah, intentionally so. It seemed OK in this instance to not try and couple ourselves directly to postMessage() since the shape of extensions and web pages are slightly different. In the future, if it gets easier to use IDL (I hear other teams on Chromium are working on this), we might adopt something closer to postMessage(). It's an excellent point about connectExternal and startup ordering - in fact, one of the problems with window.postMessage now is that there's no guarantee that your message will be delivered if the target window has not loaded yet. I brought this up in the original design discussions, that messages should be queued until the page either loads or fails. Web platform APIs should be deterministic! Blech. In extensions, we queue the messages :). - 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: [chromium-extensions] Inter-extension communication API proposal
Thanks for the feedback. I've created
http://code.google.com/p/chromium/wiki/InterExtensionCommunication with the
proposal and would appreciate if someone with an @chromium account could
link to it from
http://dev.chromium.org/developers/design-documents/extensions. I copied
the proposal pretty much unchanged to get the page started but since it's a
wiki anyone should be able to edit freely. Some comment replies inline:
On Tue, Jul 28, 2009 at 2:30 PM, Drew Wilson atwil...@chromium.org wrote:
SGTM. Note that we're essentially duplicating (assumedly intentionally so)
the window.postMessage() APIs which require specifying a target domain and
whose connect event has a source and origin attribute specifying the
window that sent the message. It might be valuable to just explicitly adopt
those interfaces wholesale, substituting extension IDs for domains.
It's an excellent point about connectExternal and startup ordering - in
fact, one of the problems with window.postMessage now is that there's no
guarantee that your message will be delivered if the target window has not
loaded yet.
-atw
On Tue, Jul 28, 2009 at 11:19 AM, Aaron Boodman a...@chromium.org wrote:
+chromium-dev
I think this is great. I suggest creating a wiki page with a design
for this so that we can refer to it whenever we implement, and a bug
that refers to the wiki page.
Up until now, we've been putting our designs here:
http://dev.chromium.org/developers/design-documents/extensions (see
proposed api), but that page isn't editable without a @chromium.org
account.
I've been thinking we should move that content to the wiki so that it
is editable by all. So if you want, you could be the first.
Besides that, a few minor comments:
1. I think we should add a permission for inter-extension
communication once we have a permissions mechanism. That is, an
extension should have to declare in the manifest which extensions it
would like to contact. This is just a security precaution against the
extension accidentally leaking privileges if it gets XSS'd or
something.
I agree completely.
On Tue, Jul 28, 2009 at 10:58 AM, James Robinsonjam...@google.com
wrote:
I think that extensions should be able to communicate with each other
using message passing. Currently, it's possible to do something like
this:
var ext = new chrome.Extension('abcdefgh...');
var port = ext.connect('channel from another world!');
port.postMessage({message: im in ur channel});
However, there are a few problems with this approach. First, it's
probably a bug that it works. The more serious issue is that a
onConnect event is fired at extension 'abcdefgh...' and there is no
way for that extension to know that the port is not from a content
script within the same extension but from another extension. An
extension should be able to allow other extensions to open connections
to it, be explicitly aware of where the connection is coming from, and
then communicate with it using the existing chrome.extension.Port
system.
This would require two new APIs on the chrome.extension object, based
on the ones presented in
http://dev.chromium.org/developers/design-documents/extensions/content-scripts
:
// Open a channel to another extension with the provided ID.
// If no extension with the provided ID exists, nothing happens.
// Otherwise the chrome.extension.onConnectExternal event is fired
// to all components of the extension with the provided ID each time
// the method is called.
// The channel can optionally be named. This name will be sent along
with the
// onConnectExternal event
Port connectExternal(String ID, [String channelName])
2. I think we can merge connect() and connectExternal() by adding an
optional param to connect() that specifies the target extension. If
omitted it defaults to the current extension.
This sounds like it should be possible, but since connect() takes an
optional param 'name' of type string already and the ID will also be of type
string it seems like this would be ambiguous.
// Fired when another extension opens a channel to this extension via
// chrome.extension.connectExternal().
// If a channelName was provided, it is accessible via port.name.
Event onConnectExternal(Object port)
In order for an extension to know what the other side of a connection
is I'd also propose adding the following property to the
chrome.extension.Port class:
// ID of the extension at the other side of this port.
String senderID;
An extension could check this field in the onConnectExternal handler
and compare it to a whitelist/blacklist to decide whether to attach
onMessage handlers. An extension might also want to expose some UI to
the user listing all connected extensions.
The other issue to address is startup order. The order in which the
scripts within different background pages is not defined, which is
entirely reasonable, but
[chromium-dev] Re: [chromium-extensions] Inter-extension communication API proposal
On Tue, Jul 28, 2009 at 12:09 PM, James Robinsonjam...@google.com wrote: Thanks for the feedback. I've created http://code.google.com/p/chromium/wiki/InterExtensionCommunication with the proposal and would appreciate if someone with an @chromium account could link to it Done. I also created a bug: http://code.google.com/p/chromium/issues/detail?id=17910 This sounds like it should be possible, but since connect() takes an optional param 'name' of type string already and the ID will also be of type string it seems like this would be ambiguous. Yeah, I don't feel too strongly about it. I was bringing it up more as a possibility. I presume that whenever someone implements this they will pick the best of the several ways to phrase this. We'll always know what extension the onConnectExternal event will be fired at when the connectExternal() call is made, so at the very least we could promise that no onConnectExternal event will be fired at an extension until its background page, if there is one, has fully loaded. Queuing until all extensions' background pages load is a simpler way to guarantee the same thing. Using the manifests could be a way to have a clever implementation, but in general the best you can get out of manifests is a partial order of extensions and you might get cycles. True. I guess I am worried about blocking an extension from communicating with, eg, itself, until all other extensions have loaded their background pages. This doesn't seem fair. - 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: [chromium-extensions] Inter-extension communication API proposal
On Tue, Jul 28, 2009 at 12:20 PM, Aaron Boodmana...@chromium.org wrote: We'll always know what extension the onConnectExternal event will be fired at when the connectExternal() call is made, so at the very least we could promise that no onConnectExternal event will be fired at an extension until its background page, if there is one, has fully loaded. Queuing until all extensions' background pages load is a simpler way to guarantee the same thing. Using the manifests could be a way to have a clever implementation, but in general the best you can get out of manifests is a partial order of extensions and you might get cycles. True. I guess I am worried about blocking an extension from communicating with, eg, itself, until all other extensions have loaded their background pages. This doesn't seem fair. I like your other proposal best, of just queuing onConnect events fired at an extension until its background page has loaded. We should do this for extensions talking to themselves, too. - 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: Duplicate expectations?
Was it ever a pre-submit check? I filed http://crbug.com/15883 against myself a bit ago, but had trouble making it work. I was going to work with Marc-Antoine this week to figure it out. J On Tue, Jul 28, 2009 at 11:13 AM, Darin Fisher da...@chromium.org wrote: No idea. I was similarly burned by this. I wish it could be run as a presubmit check. -Darin On Tue, Jul 28, 2009 at 11:01 AM, Mike Pinkerton pinker...@chromium.orgwrote: We used to have to run: run_webkit_tests.sh --lint-test-files in order to check for duplicate WebKit layout test expectations. A while back, this was turned into a pre-submit hook so we couldn't forget to run it. However, in the last couple of days, both pkasting and I have been tripped up by this. What happened? Did it get lost, or did we change our minds? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Duplicate expectations?
I'm almost positive we made it so because we had so much trouble when we were bringing up the mac and linux ports. I could be on crack tho On Tue, Jul 28, 2009 at 3:41 PM, Jeremy Orlowjor...@chromium.org wrote: Was it ever a pre-submit check? I filed http://crbug.com/15883 against myself a bit ago, but had trouble making it work. I was going to work with Marc-Antoine this week to figure it out. J On Tue, Jul 28, 2009 at 11:13 AM, Darin Fisher da...@chromium.org wrote: No idea. I was similarly burned by this. I wish it could be run as a presubmit check. -Darin On Tue, Jul 28, 2009 at 11:01 AM, Mike Pinkerton pinker...@chromium.org wrote: We used to have to run: run_webkit_tests.sh --lint-test-files in order to check for duplicate WebKit layout test expectations. A while back, this was turned into a pre-submit hook so we couldn't forget to run it. However, in the last couple of days, both pkasting and I have been tripped up by this. What happened? Did it get lost, or did we change our minds? -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Duplicate expectations?
You are, in fact, on crack. :) It was never a presubmit script. We just talked about making it one a lot. On Tue, Jul 28, 2009 at 3:52 PM, Mike Pinkerton pinker...@chromium.orgwrote: I'm almost positive we made it so because we had so much trouble when we were bringing up the mac and linux ports. I could be on crack tho On Tue, Jul 28, 2009 at 3:41 PM, Jeremy Orlowjor...@chromium.org wrote: Was it ever a pre-submit check? I filed http://crbug.com/15883 against myself a bit ago, but had trouble making it work. I was going to work with Marc-Antoine this week to figure it out. J On Tue, Jul 28, 2009 at 11:13 AM, Darin Fisher da...@chromium.org wrote: No idea. I was similarly burned by this. I wish it could be run as a presubmit check. -Darin On Tue, Jul 28, 2009 at 11:01 AM, Mike Pinkerton pinker...@chromium.org wrote: We used to have to run: run_webkit_tests.sh --lint-test-files in order to check for duplicate WebKit layout test expectations. A while back, this was turned into a pre-submit hook so we couldn't forget to run it. However, in the last couple of days, both pkasting and I have been tripped up by this. What happened? Did it get lost, or did we change our minds? -- Mike Pinkerton Mac Weenie pinker...@google.com -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-extensions] Inter-extension communication API proposal
Two suggestions (one I accidentally sent only to James):
chrome.extension.Port:
// ID of the extension at the other side of this port.
String senderID;
Port currently has a 'tab' property if the sender was a tab. Maybe we
should group these:
chrome.extension.Port:
Object sender:
Object tab; // if the sender was a tab
String id; // ID of the sending extension.
chrome.extension:
// Open a channel to another extension with the provided ID.
// If no extension with the provided ID exists, nothing happens.
// Otherwise the chrome.extension.onConnectExternal event is fired
// to all components of the extension with the provided ID each time
// the method is called.
// The channel can optionally be named. This name will be sent along
// with the onConnectExternal event
Port connectExternal(string ID, [string channelName])
It makes more sense to me to have the API mirror the regular connect event:
chrome.extension.connect(); // connects to my own extension
other = new chrome.Extension('abcef...');
other.connect(); // connects to extension abcdef...
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Design Doc: Adaptive spell checking for multilingual users
Sid and I discussed this further, and would like to suggest an simpler first step. Sid is going to take a stab at implementing automatic language detection for spellcheck. When the spell-checking language is set to auto and the user focuses a text field, we will use CLD to set the spellcheck language to: - the language of the contents of the text field, if there is enough content (useful for email replies, for example). - otherwise, fall back on the language of the page itself, if there is enough content. - otherwise, fall back on Chrome's UI language. - optional sanity check: after the first ~20 words have been typed, run CLD again and switch the language if appropriate (only do this once to avoid flicker). The user would never have to worry about setting their spell-checking language: we would always correct the input in the language that was typed. This will also prevent everything from getting underlined when typing in a foreign language (which is a common annoyance for multi-lingual users). Gmail does this for their spell-checking, and it works very well. If this feature works well, we can reconsider more complex features such as multi-lingual spell-check down the line. -Nick On Fri, Jul 24, 2009 at 3:00 AM, progame prog...@chromium.org wrote: if both dictionaries are not recognizing a word and only one of them suggests a correction (which will be a very common case for Hebrew users i am sure) - i rather not see a submenu in that case - it's one more click which isn't needed some sort of title item in the context menu can be added to indicate the language source in that case maybe... or a leading [Hebrew] string before the word? --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
I'm working on gclient to pass the matching file list to the hook, or some equivalent. I discovered another issue, which I highly suspect is caused by a build issue (I'm not sure if it's the same issue). waiting_animation_frames = rb.GetBitmapNamed(IDR_THROBBER_WAITING); DCHECK(waiting_animation_frames); DCHECK(waiting_animation_frames-width() % waiting_animation_frames-height() == 0); // -- this DCHECK fails waiting_animation_frame_count = waiting_animation_frames-width() / waiting_animation_frames- height(); It seems that a wrong bitmap is being loaded. What can it mean for the build? On Mon, Jul 27, 2009 at 16:54, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: I'm going to try writing the hook, but I would first ask for advice. The hook syntax takes a filename pattern and a command. So I would have to create a new command (probably in src/tools), like clobber_generated_headers or something similar. And the tool itself does not get the list of changed files, so it has to clobber all of them, and have the list of files to be clobbered hardcoded. Do you see better solutions? --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
This happens semi-frequently. It's related to the grit resources rebuilding. Something like: not remapping IDR_THROBBER_WAITING to the right place, or remapping it to the right place but not rebuilding this file, or something like that. On Tue, Jul 28, 2009 at 4:18 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I'm working on gclient to pass the matching file list to the hook, or some equivalent. I discovered another issue, which I highly suspect is caused by a build issue (I'm not sure if it's the same issue). waiting_animation_frames = rb.GetBitmapNamed(IDR_THROBBER_WAITING); DCHECK(waiting_animation_frames); DCHECK(waiting_animation_frames-width() % waiting_animation_frames-height() == 0); // -- this DCHECK fails waiting_animation_frame_count = waiting_animation_frames-width() / waiting_animation_frames- height(); It seems that a wrong bitmap is being loaded. What can it mean for the build? On Mon, Jul 27, 2009 at 16:54, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I'm going to try writing the hook, but I would first ask for advice. The hook syntax takes a filename pattern and a command. So I would have to create a new command (probably in src/tools), like clobber_generated_headers or something similar. And the tool itself does not get the list of changed files, so it has to clobber all of them, and have the list of files to be clobbered hardcoded. Do you see better solutions? --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
On Tue, Jul 28, 2009 at 4:35 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: On Tue, Jul 28, 2009 at 16:30, Evan Martin e...@chromium.org wrote: This happens semi-frequently. It's related to the grit resources rebuilding. Something like: not remapping IDR_THROBBER_WAITING to the right place, or remapping it to the right place but not rebuilding this file, or something like that. Will the workaround for the original problem (clobbering headers generated by .grd files) work also for this issue? If not, do you have any idea for a fix or workaround? Or maybe... why not set the resources projects to always-build, even just for the buildbots? lastchange works this way, so it is possible. I think it is not more or less crude than the clobbering workaround, and is simpler to implement. Increase in the build time should not be significant (on the bots; doing that on developers' machine probably isn't a good idea). I like the idea of always-building the resources project. Though note it can cause a lot of code to rebuild: it generates headers, which are included via includes via includes... --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
On Tue, Jul 28, 2009 at 4:37 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 28, 2009 at 4:35 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: On Tue, Jul 28, 2009 at 16:30, Evan Martin e...@chromium.org wrote: This happens semi-frequently. It's related to the grit resources rebuilding. Something like: not remapping IDR_THROBBER_WAITING to the right place, or remapping it to the right place but not rebuilding this file, or something like that. Will the workaround for the original problem (clobbering headers generated by .grd files) work also for this issue? If not, do you have any idea for a fix or workaround? Or maybe... why not set the resources projects to always-build, even just for the buildbots? lastchange works this way, so it is possible. I think it is not more or less crude than the clobbering workaround, and is simpler to implement. Increase in the build time should not be significant (on the bots; doing that on developers' machine probably isn't a good idea). I like the idea of always-building the resources project. Though note it can cause a lot of code to rebuild: it generates headers, which are included via includes via includes... I still vote for the original idea of clobbering the .h files if the .grd file is changed. I think it should be easy to implement with the DEPS file. The faster the incremental build is on the bots, the faster they cycle. They are already too slow, that'd be sad to make it even slower. 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: avoiding compile failures on buildbot
FTR, doing optimized builds on the try server is on my plate: http://crbug.com/17946 And arbitrary tests is http://crbug.com/17948 Star them if this is the kind of things that excites you. :) M-A On Thu, Jul 23, 2009 at 7:31 AM, Thomas Van Lenten thoma...@chromium.orgwrote: Just to be complete, linux can have the same issue, and I'd expect Windows also to be able too. This is one class of things the try server doesn't catch because it is building debug/unoptimized. TVL On Wed, Jul 22, 2009 at 10:09 PM, Andrew Scherkus scher...@chromium.orgwrote: On Wed, Jul 22, 2009 at 7:07 PM, Dan Kegel d...@kegel.com wrote: That's consistent with trybots doing debug builds. Uninitialized var warnings only show up in optimized builds, nothing we can do there but turn on optimizations. Gotcha -- thanks for the explanation! Andrew On Thu, Jul 23, 2009 at 2:00 AM, Andrew Scherkusscher...@chromium.org wrote: On a related note, Frank (cc'd) ran into an issue where the mac try bots have a less-strict compiler warning error than the build bots, which led to a broken build once he checked in: http://codereview.chromium.org/155834 Probably a simple config tweak somewhere, but interesting nonetheless. Andrew On Wed, Jul 22, 2009 at 6:19 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: One thing that would help us keep the tree more green is avoiding compile failures. A compile failure is very bad, because without binaries the tests can't run, and then we have to wait for all of them to run, which may reveal additional failures etc. I'm actually surprised by some failures on buildbot, but at least one thing was not surprising for me: Windows Release compile failures when the Debug compiles fine (because we don't have Release trybot). How often does something run in Windows when compiled with the release configuration but not the debug? I've definitely seen it, but I'm not sure it's terribly common. My guess is that there are other causes of the build breaking that should be addressed first. Are there any stats on this? My gut feeling is that many of the build breaks are for things that never passed on a try bot. For example, WebKit gardening patches almost never work on the try bots so we just ignore them. I think working on stuff like this will bear more fruit. Not to mention that each bot costs a lot in terms of the machine, power, maintenance time, etc. What do you think? Do you have any ideas how we could avoid more compile failures, even if they are not possible to apply now due to lack of resources? (for example adding trybots, which seems to not happen soon). I was also thinking about allowing simple check-ins when the tree is waiting for cycle state (when the sheriff wants to verify that bots cycle green after a lot of redness). The status would say (Tree closed, waiting for cycle; ask sheriff to commit a simple change), or maybe some abbreviation for that. It would help people getting code in, and the sheriff could require really a lot from that change (like full green trybot pass etc). What do you think about that (especially sheriffs)? I think you can always ask the sheriffs if you can put something small in. I don't see the point of making any such message policy or a convention. That said, unless it doesn't compile or is REALLY obviously OK, I don't think it's a good idea. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [linux, maybe mac] gcc -fvisibility=hidden
When we load a plugin any symbols we export come before its symbols. We don't want a plugin to accidentally rely on our symbols, or more generally we don't want to export any symbols. The -fvisibility=hidden flag is maybe supposed to do this (see discussion on http://gcc.gnu.org/wiki/Visibility ), but I tried building both with and without it and found that: - in debug builds, objdump -T shows all of our symbols, regardless of the flags I pass to gcc or strip - in release builds, objdump -T doesn't show us exporting symbols, regardless of the flags I pass to gcc The resulting release binaries are within 1kb of each other. I don't really know what I'm doing, so my guess is that some other compilation flags we're using already produce the intended effect. Clearly this flag does *something* as the resulting binaries have slightly different sizes, but maybe it's not intended to apply to binaries or maybe it doesn't in my gcc (4.2.4). *shrug*, waste of an evening but I was doing something else all the while anyway --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to attach to Renderer Process in XCode
On Sun, Jul 26, 2009 at 3:52 PM, Jeremy Moskovichjer...@chromium.org wrote: Command line gdb is one way to go... I always use the XCode IDE gdb integration, as documented on the wiki. While trying to attach to the Chrome process directly from the IDE can get funky, the method documented on the wiki always works for me. XCode attaches itself to a running renderer which is paused [by calling pause() ] so you need to click continue in the IDE to get it to keep running and render a webpage. It's possible that the broken pipe you're seeing is the result of killing the renderer from the debugger. Thank you for the help. I did what you suggest. And I attached gdb to 2516 via command line. Chromium does start and I see the 'New tab page'. Like this: $ ~/chromium/src/xcodebuild/Debug/Chromium.app/Contents/MacOS/Chromium --renderer-stp-dialog [2516:2055:3122095122007:WARNING:/Users/n179911/chromium/src/chrome/renderer/renderer_main.cc(65)] Renderer (2516) paused waiting for debugger to attach @ pid Then I go to the URL text box of chromium and type in 'http://www.cnn.com' But what I get is I see this but with a new pid (2220). [2516:2055:3122095122007:WARNING:/Users/n179911/chromium/src/chrome/renderer/renderer_main.cc(65)] Renderer (2220) paused waiting for debugger to attach @ pid But question is why chromium starts a new Renderer process when I just trying to load my first URL (http://www.cnn.com). Why it does not re-used 2516 before? Thanks in advance. Best regards, Jeremy On Sun, Jul 26, 2009 at 9:23 PM, n179911 n179...@gmail.com wrote: On Thu, Jul 16, 2009 at 12:46 AM, Jeremy Moskovichjer...@chromium.org wrote: You can find instructions here: http://dev.chromium.org/developers/debugging-on-os-x Ultimately, we should really combine all the platform debugging articles into one page :| Best regards, Jeremy Thanks. I tried it. I saw this in the shell: [460:2055:4872081828141:WARNING:/Users/n179911/chromium/src/chrome/renderer/renderer_main.cc(65)] Renderer (460) paused waiting for debugger to attach @ pid And then I got XCode and Attached to '460'. But i see this in my shell, and chromium never get launched. [460:11783:4914670085769:ERROR:/Users/n179911/chromium/src/ipc/ipc_channel_posix.cc(649)] pipe error on 3: Broken pipe Thank you for any help. On Thu, Jul 16, 2009 at 9:29 AM, hap497 hap...@gmail.com wrote: Hi, chromium.org has this http://dev.chromium.org/developers/how-tos/debugging for debugging renderer process on Windows. My question is how can I do the same in XCode on MacOS X? I go to Run-Attach To Process, all the menu item entries are disabled. 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
Evan Martin wrote: When we load a plugin any symbols we export come before its symbols. This doesn't happen on the Mac unless you go out of your way to arrange for it to happen. Even so, we do use -fvisiblility=hidden for all Mac builds, because I like for these things to be well-trimmed anyway. The -fvisibility=hidden flag is maybe supposed to do this (see discussion on http://gcc.gnu.org/wiki/Visibility ), but I tried building both with and without it and found that: - in debug builds, objdump -T shows all of our symbols, regardless of the flags I pass to gcc or strip - in release builds, objdump -T doesn't show us exporting symbols, regardless of the flags I pass to gcc The resulting release binaries are within 1kb of each other. I don't really know what I'm doing, so my guess is that some other compilation flags we're using already produce the intended effect. Clearly this flag does *something* as the resulting binaries have slightly different sizes, but maybe it's not intended to apply to binaries or maybe it doesn't in my gcc (4.2.4). In order for any of this to apply to executables (as opposed to static libraries), you need to be linking with ld -E. Otherwise, global symbols that wind up in the executable don't get exported via the dynamic symbol table. I don't know how you guys are linking, but this can be significant here. This -E business applies to Linux/ELF. On the Mac, things work a little differently: there's only one symbol table, symbols wind up in it pretty much identically whether you're linking an executable or a library, and as I mentioned above, the runtime loader does a better job of resolving undefined symbols to the same libraries that provided them at link time. Mark --~--~-~--~~~---~--~~ 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: Quota UI for LocalStorage (and others in the future)
On Tue, Jul 28, 2009 at 8:40 PM, Jeremy Orlow jor...@chromium.org wrote: One approach that seems obvious to a lot of people I've talked to is asking the user (maybe via an info bar?) whenever an origin hits its limit Putting aside the technical questions here, I'm a little skeptical from a UI perspective. How do I know what's OK and what's not? If a bad app wants to use a lot of disk, can it convince me to let it if I'm a novice user? In other words, are my choices going to be significantly better than random, if I don't know a ton about computers (e.g. can't keep track of the difference between disk and memory usage)? In the world of normal applications, you basically give them arbitrary permission to use your disk, but the good ones write some requirements ahead of time like requires 200 MB free hard drive space and warn you at install if you're below that. Can we make the UI more like that, where you make a single trust decision up front? Yes an app can lie, but normally-installed apps can lie too. Can we provide enough ranking and feedback somewhere to make this decision easier on users? For example, 57% of users chose to install foo.com, and gave it an average rating of 2.3 stars. Finally, 5 MB? I hardly blink at 100 MB these days, and the average hard drive now is something north of 100 GB. 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: Quota UI for LocalStorage (and others in the future)
On 28-Jul-09, at 11:55 PM, Peter Kasting wrote: Putting aside the technical questions here, I'm a little skeptical from a UI perspective. How do I know what's OK and what's not? If a bad app wants to use a lot of disk, can it convince me to let it if I'm a novice user? In other words, are my choices going to be significantly better than random, if I don't know a ton about computers (e.g. can't keep track of the difference between disk and memory usage)? First of all, this really hasn't actually come up in real world usage. No web app that I've experienced uses localStorage past 5MB, and indeed once you get that much data out there people start crying for the W3C Storage spec and we all start debating SQLite vs. CouchDB again. All we're doing at this point is preventing malicious applications from eating up disk, really. For Firefox, we do this by setting some sane cap (I think it's 5MB, can't recall exactly) and then notifying users if the application attempts to go over. In the world of normal applications, you basically give them arbitrary permission to use your disk, but the good ones write some requirements ahead of time like requires 200 MB free hard drive space and warn you at install if you're below that. Can we make the UI more like that, where you make a single trust decision up front? Yes an app can lie, but normally-installed apps can lie too. Can we provide enough ranking and feedback somewhere to make this decision easier on users? For example, 57% of users chose to install foo.com, and gave it an average rating of 2.3 stars. Oooh, web of trust. There are some flaws. :) I do think the right answer here is to only get the user involved when the case seems pathological. Most uses of localStorage will be for better than cookies, I suspect. cheers, mike --~--~-~--~~~---~--~~ 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: Quota UI for LocalStorage (and others in the future)
On Tue, Jul 28, 2009 at 9:23 PM, Mike Beltzner beltz...@mozilla.com wrote: All we're doing at this point is preventing malicious applications from eating up disk, really. Yep, I agree (although that may no longer be true in a few years as web apps grow in power and complexity). In the world of normal applications, you basically give them arbitrary permission to use your disk, but the good ones write some requirements ahead of time like requires 200 MB free hard drive space and warn you at install if you're below that. Can we make the UI more like that, where you make a single trust decision up front? Yes an app can lie, but normally-installed apps can lie too. Can we provide enough ranking and feedback somewhere to make this decision easier on users? For example, 57% of users chose to install foo.com, and gave it an average rating of 2.3 stars. Oooh, web of trust. There are some flaws. :) I do think the right answer here is to only get the user involved when the case seems pathological. Most uses of localStorage will be for better than cookies, I suspect. One case I'm trying to prevent is getting separate requests, at different times, from the same app. You get some up-front query about desktop shortcuts, and then a query five minutes later about using your camera, and then a year later about going over 5 MB of storage, and so on. Sucky. Really all I care about is an up-front let this do whatever the heck it wants versus no thanks. 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: [extensions] Shankland: Thanks for giving my back pixels, browser makers
Which I meant to implement but still could not find the right time.:( ☆PhistucK On Tue, Jul 28, 2009 at 21:12, Darin Fisher da...@chromium.org wrote: +1 for bookmark bar. or, maybe the extension bar could similarly have a keyboard shortcut to hide/show it? moar screen space at my fingertips please :) -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: Quota UI for LocalStorage (and others in the future)
On Tue, Jul 28, 2009 at 9:30 PM, Peter Kasting pkast...@chromium.orgwrote: On Tue, Jul 28, 2009 at 9:23 PM, Mike Beltzner beltz...@mozilla.comwrote: All we're doing at this point is preventing malicious applications from eating up disk, really. Yep, I agree (although that may no longer be true in a few years as web apps grow in power and complexity). In the world of normal applications, you basically give them arbitrary permission to use your disk, but the good ones write some requirements ahead of time like requires 200 MB free hard drive space and warn you at install if you're below that. Can we make the UI more like that, where you make a single trust decision up front? Yes an app can lie, but normally-installed apps can lie too. Can we provide enough ranking and feedback somewhere to make this decision easier on users? For example, 57% of users chose to install foo.com, and gave it an average rating of 2.3 stars. Oooh, web of trust. There are some flaws. :) I do think the right answer here is to only get the user involved when the case seems pathological. Most uses of localStorage will be for better than cookies, I suspect. One case I'm trying to prevent is getting separate requests, at different times, from the same app. You get some up-front query about desktop shortcuts, and then a query five minutes later about using your camera, and then a year later about going over 5 MB of storage, and so on. Sucky. Really all I care about is an up-front let this do whatever the heck it wants versus no thanks. Another thing to consider is that, if our limits are per-origin (what most implementations use IIRC), a malicious attacker could easily use lots of host names (i.e. host1.bad-site.com through host1000.bad-site.com) to still fill things up. I'm starting to wonder if some sort of web of trust or black list type solution is the only way to avoid users getting DOSed. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
