[chromium-dev] Re: readability extension (experience writeup)
- The docs around content scripts communicating with the embedding page aren't too clear. See e.g.: http://code.google.com/chrome/extensions/content_scripts.html#messaging That section is mostly just a big example but for example nowhere is the postMessage API described. I'd prefer it to be laid out more like: - how to make each endpoint listen for messages - how to make each endpoint send a message Yes, these need to be improved. There will also be some new API that'll make the common case of sending a message much easier. - Doc organization. It would've been clearer to me if there is one more level of nesting. Sections like toolstrips, page actions are features with manifest edits as well as APIs, while sections like tabs and windows are just API references. If you look at the trunk version of the docs, there is one more level of nesting in the sidenav. Does this help? http://code.google.com/chrome/extensions/trunk/ -k- --~--~-~--~~~---~--~~ 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: Fie Foh Fum! I smell the blood of the WebKit-man: MStone:4 is nigh.
I punted the WebKitAPI related tasks since they don't block M4. -Darin On Sat, Oct 31, 2009 at 7:56 PM, Dimitri Glazkov dglaz...@google.comwrote: The moon is high. The zombies, wizards and various other bizarre beings are prowling the streets. Which could mean only one thing: Tombstone 4 is coming to get us. http://crbug.com/horizon/webkit So be prepared, dear WebKit Chromium people. On Monday, check your bug list: http://crbug.com/?q=owner:me+Mstone:4 Make an effort. Fix yer bugs. Help us escape what could be a terrifying conclusion of this stable release. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Inheritance in gyp configurations
1) Do you support multiple inheritance? I notice the inherit_from is
specified as an array. That's scaryish.
Multiple inheritance is supported, not sure it's wise to use, but well gyp
has lots of features like that :-)
I almost didn't support it, but concluded that, for instance 64-bit, might
have a common set of configuration properties that you'd want to mix-in to a
given config.
2) If you do have multiple inheritance, how are conflicts handled? Are
they just rejected, or is there a pre-defined name resolution order? What
would you do with diamond shapes?
Names are resolved based on the order in which parent classes are listed
after 'inherit_from'. Parent classes are applied depth first, and only the
first instance of a parent gets applied. So for example:
Base
/\\
A B C
\ //
D
Names are picked in this order: D, C, B, A, Base.
I'm not wedded to this arrangement (in fact I'm generally skeptical of
multiple inheritance).
I definitely think that in practice diamond inheritance should be avoided,
but I can imagine some cases were it might make sense.
I think in general we should try to have a single primary tree and mix-ins
for simple self contained features.
3) Is there a way to reference super, or various ancestors?
No.
This gets implemented as merging (similar to target_defaults), so nothing is
left of the ancestors from the point of view of their descendants.
4) How does this interact with late-resolution variables?
Late resolution variables are expanded after inheritance.
There are serious limitations on what can happen in a configuration,
however, so I'm hard pressed to imagine a case where you'd be able to use
late-resolution in the context of a configuration.
5) How about conditionals? Can we conditionally inherit?
Conditionals are expanded before inheritance is applied, so you could in
principle make it conditional.
This is already being used in a related context (the Purify configuration
only exists for windows).
It might make sense with inheritance, but probably would be a bad idea.
It's supported largely as a side effect of normal gyp expansion.
If you feel strongly, we could take it out. I'm on the fence as to whether
its dangerous in the unusual context in which it applies to gyp.
Let me know. :-)
-BradN
-Albert
On Thu, Oct 29, 2009 at 5:42 PM, Bradley Nelson bradnel...@google.comwrote:
configurations can now inherit from one or more other configurations, and
configurations which are not fully expressed should be marked 'abstract': 1,
So something like this:
'configurations': {
'Common: {
'abstract': 1,
# common settings
},
'Debug': {
'inherit_from': ['Common'],
# Debug specific
},
'Release': {
'inherit_from': ['Common'],
# Release specific
},
},
-BradN
On Thu, Oct 29, 2009 at 5:37 PM, Nick Carter n...@chromium.org wrote:
What does the syntax look like?
- nick
On Thu, Oct 29, 2009 at 3:22 PM, Bradley Nelson
bradnel...@google.comwrote:
Hi All,
I've just rolled out an enhancement to gyp to support inheritance in
configurations.
This shouldn't have any noticeable effect other than reducing the
repetition needed for things like Purify/notcmalloc.
I've tested it as best I can, but please let me know if you experience
anything strange with Debug vs Release or with Purify/notcmalloc.
This was primarily meant as a baby step towards supporting x64
configurations in gyp on windows, but I thought I'd let this part soak
first.
-BradN
--~--~-~--~~~---~--~~
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: Inheritance in gyp configurations
I'm sure that there are better examples than the below. Presumably if
you want something defined in both Debug and Release, you want it
globally, and you'd be better off specifying it outside of the
configuration altogether.
Brad, we can still inherit from non-abstract configurations, right?
This might be useful...
'configurations': {
'Release': {
# not abstract
},
'Valgrind': {
'inherit_from': ['Release'],
# Make stacks somewhat more friendly
'optimization': 1, # not a real keyword, just an example
},
},
Mark
Bradley Nelson wrote:
configurations can now inherit from one or more other configurations, and
configurations which are not fully expressed should be marked 'abstract': 1,
So something like this:
'configurations': {
'Common: {
'abstract': 1,
# common settings
},
'Debug': {
'inherit_from': ['Common'],
# Debug specific
},
'Release': {
'inherit_from': ['Common'],
# Release specific
},
},
--~--~-~--~~~---~--~~
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: Inheritance in gyp configurations
Brad, we can still inherit from non-abstract configurations, right?
This might be useful...
yes, we can, and it would
Mark
Bradley Nelson wrote:
configurations can now inherit from one or more other configurations, and
configurations which are not fully expressed should be marked 'abstract':
1,
So something like this:
'configurations': {
'Common: {
'abstract': 1,
# common settings
},
'Debug': {
'inherit_from': ['Common'],
# Debug specific
},
'Release': {
'inherit_from': ['Common'],
# Release specific
},
},
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] BUILT_PRODUCTS_DIR: command not found build error on OS X
Hi,
when building after syncing, I now get
/Users/thakis/src/chrome-git/src/chrome/../xcodebuild/chrome.build/Debug/chrome.build/Script-649B47660F26D59AE4D7EEA0.sh:
line 2: BUILT_PRODUCTS_DIR: command not found
every time. If you get this too, it can be fixed by going to
Targets-Chrome-Postbuild cleanup_theme_pak, double-clicking that,
and changing $(BUILT_PRODUCTS_DIR) to ${BUILT_PRODUCTS_DIR} (i.e.
change the parens to braces).
Nico
ps: This is probably caused by
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?view=diffr1=30643r2=30644
, which probably needs to look more like
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?view=diffr1=28870r2=28871
, so the Real Fix is some change to chrome.gyp.
--~--~-~--~~~---~--~~
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: BUILT_PRODUCTS_DIR: command not found build error on OS X
Oops.
http://codereview.chromium.org/353002
Nico Weber wrote:
Hi,
when building after syncing, I now get
/Users/thakis/src/chrome-git/src/chrome/../xcodebuild/chrome.build/Debug/chrome.build/Script-649B47660F26D59AE4D7EEA0.sh:
line 2: BUILT_PRODUCTS_DIR: command not found
every time. If you get this too, it can be fixed by going to
Targets-Chrome-Postbuild cleanup_theme_pak, double-clicking that,
and changing $(BUILT_PRODUCTS_DIR) to ${BUILT_PRODUCTS_DIR} (i.e.
change the parens to braces).
Nico
ps: This is probably caused by
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?view=diffr1=30643r2=30644
, which probably needs to look more like
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?view=diffr1=28870r2=28871
, so the Real Fix is some change to chrome.gyp.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] [FYI] Build errors while building Chromium with gcc 4.4.
Greetings Chromium-developers,
(Please ignore this e-mail when you are not building Chromium with gcc 4.4.)
Today, a person reported gcc 4.4 yields the following build errors
while building Chromium on IRC:
cc1plus: error: dereferencing pointer '...' does break strict-aliasing rules
Unfortunately, gcc 4.4 checks the pointer conversion more strictly
than the previous gcc and it yields some warnings while compiling
chromium.
Even though it is definitely better to change our code to make it
compile with gcc 4.4, I would like to write a temporary workaround
that avoids these warnings.
1. Creating a file ~/.gyp/inclulde.gypi'.
2. Adding a following lines to the file.
{
'variables': {
'no_strict_aliasing': 1
}
}
3. Run gclient runhooks --force to re-build scons or make files.
4. Run hammer or make to re-build Chromium.
Regards,
Hironori Bono
E-mail: hb...@chromium.org
--~--~-~--~~~---~--~~
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: [FYI] Build errors while building Chromium with gcc 4.4.
Hi all,
2009/11/2 Hironori Bono (坊野 博典) hb...@chromium.org
1. Creating a file ~/.gyp/inclulde.gypi'.
2. Adding a following lines to the file.
{
'variables': {
'no_strict_aliasing': 1
}
}
IIRC specifying 'gcc_version': '44' does the same thing as above. This might
be better than specifying 'no_strict_aliasing' directly.
3. Run gclient runhooks --force to re-build scons or make files.
4. Run hammer or make to re-build Chromium.
Thanks,
Yuta
--~--~-~--~~~---~--~~
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: [FYI] Build errors while building Chromium with gcc 4.4.
2009/11/2 Yuta Kitamura yu...@chromium.org: IIRC specifying 'gcc_version': '44' does the same thing as above. This might be better than specifying 'no_strict_aliasing' directly. Ah, you bet me to it. You're right; gcc_version is used to only enable -fno-strict-aliasing when building v8. Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
