Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to
On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org wrote:
(As discussed during lunch...) Why not just do this in this case and
remove EmptyString() altogether?
const std::string MyClass::foo() const {
static std::string empty = EmptyString();
return (everything == OK) ? member_string : empty;
}
This is not thread safe. EmptyString() uses SingletonT to basically
achieve the same thing in a thread safe manner.
Is there something wrong with returning by copy, and relying on the compiler
to execute a return value optimization?
-Albert
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to
On Thu, Jan 7, 2010 at 2:53 PM, Victor Khimenko k...@google.com wrote:
On Fri, Jan 8, 2010 at 1:51 AM, Albert J. Wong (王重傑)
ajw...@chromium.orgwrote:
On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.orgwrote:
(As discussed during lunch...) Why not just do this in this case and
remove EmptyString() altogether?
const std::string MyClass::foo() const {
static std::string empty = EmptyString();
return (everything == OK) ? member_string : empty;
}
This is not thread safe. EmptyString() uses SingletonT to basically
achieve the same thing in a thread safe manner.
Is there something wrong with returning by copy, and relying on the
compiler
to execute a return value optimization?
Do you volunteer to rewrite the compilers to implement said optimization?
GCC, for one will not do so.
According to wikipedia,
http://en.wikipedia.org/wiki/Return_value_optimization, msvc, g++, and icc,
all support it...or am I missing something about this situation that makes
RVO inapplicable?
-Albert
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to
[ resending from correct e-mail ] If you are saying that everywhere in the code can return by value instead of by const ref and the compiler will optimize it equivalently, you are wrong; I was under the same misapprehension until yesterday. We've verified that even in the best case That's what I was indeed what I was thinking, and apparently, it was a bad assumption. :-/ Thanks for the explanation. -Albert -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Cannot find -lffmpegasm
There have been some changes to the ffmpeg.gyp file recently. Dominic makes a good point that the GYP_DEFINES will make a large difference. Thiago, what GYP_DEFINES do you have set? Note that ffmpeg_asm is not a build dependency. It's a target in the ffmpeg.gyp file that must somehow be getting excluded in your build. On Mon, Dec 14, 2009 at 10:34 AM, Dominic Mazzoni dmazz...@google.comwrote: What do you have GYP_DEFINES set to? I got a compilation error involving ffmpeg last week, but then I tried again with an empty GYP_DEFINES and it worked fine. - Dominic On Sun, Dec 13, 2009 at 9:32 AM, Thiago Farina thiago.far...@gmail.com wrote: Sorry for posting here, but I didn't find other place to ask, also I didn't find a solution too, so... I already tried everything, like, clobbering the out directory, synching again with 'gclient sync --force'. What I usually do is, in the trunk branch: $ git pull $ gclient sync $ time make CC=ccache gcc CXX=ccache g++ -k chrome But since friday this is not working and I'm getting weird errors. After some searching I ending up with this following line, but remaing this last error. $time make CC=ccache gcc CXX=ccache g++ LDFLAGS+=-ldl LDFLAGS+=- lpthread -k chrome SOLINK(target) out/Debug/lib.target/third_party/ffmpeg/ libffmpegsumo.so /usr/bin/ld: error: cannot find -lffmpegasm collect2: ld returned 1 exit status make: *** [out/Debug/lib.target/third_party/ffmpeg/libffmpegsumo.so] Error 1 make: Target `chrome' not remade because of errors. real1m3.344s user0m23.237s sys 0m7.532s I hope someone could give me a hint how to make this work again. Ah, I ran build/install-build-deps.sh to see if I was missing some dev package, but it says that everything is installed. PS: without these LDFLAGS , the compilation don't work also. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Symbolized backtrace on Linux chromium?
addr2line is another possible option. addr2line -e sconsbuild/Debug/chrome 0x87d9bc This works even if -fvisbility=hidden. I think w/o address space layout randomization, it's...relatively deterministic (I think). So, given that, maybe it would be sensible to find a way to add a small post-process hook in the layout bots to look for something that matches the Backtrace format, and runs addr2line on the trace. Same thing could work for mac, though I forget what the name of the tool is there and I've been told this issue is moot on OsX 10.6. -Albert On Mon, Nov 30, 2009 at 11:22 AM, Evan Martin e...@chromium.org wrote: On Mon, Nov 30, 2009 at 11:16 AM, Michael Moss mm...@chromium.org wrote: We have a test covering this: ./out/Debug/base_unittests --gtest_filter=StackTrace* Running it locally reveals that it is broken -- but the bots still work? It looks like there isn't a debug builder that runs base_unittests. It's the release build that passes. Since I (probably) broke this, I will fix it. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NameError: name 'ffmpeg_asm_lib' is not defined
For ffmpeg, you should be able to set GYP_DEFINES=use_system_ffmpeg=1 to
disable the in-tree ffmpeg build. That should get you past that stumbling
block. HTML5 video won't work, but like Evan said, that's probably the
least of your concerns.
-Albert
On Tue, Nov 24, 2009 at 1:25 PM, Evan Martin e...@chromium.org wrote:
We currently won't build on Solaris; ffmpeg is the least of your
worries. Someone contributed patches to build on FreeBSD that might
get you closer, but the patch is enormous (~100kb, I think?) so I've
been refactoring bits of it into reviewable chunks (very slowly in my
free time).
2009/11/24 Maciej Bliziński blizin...@google.com:
Hello chromium-dev,
I've started to work on building Chromium on Solaris. I've recently
finished completing the prerequisites (NSPR and NSS), and I'm moving
forward with the Linux build descriptions. I'm using a tarball
distribution. I don't run gclient sync, but gclient runhooks --
force. The instructions say that I'm going to miss on platform-
specific dependencies, but I guess I'm going miss on them anyway.
My current problem looks as follows:
mac...@netra ~/src/opencsw/pkg/chromium/trunk $ gmake build
gmake[1]: Entering directory `/home/maciej/src/opencsw/pkg/chromium/
trunk'
[= NOW BUILDING: chromium-0.32797 MODULATION isa-sparcv8:
ISA=sparcv8 =]
[extract-modulated] complete for chromium.
[patch-modulated] complete for chromium.
(cd work/build-isa-sparcv8/home/chrome-svn/tarball/chromium \
\
PATH=$PATH:/home/maciej/src/opencsw/pkg/chromium/trunk/
work/build-isa-sparcv8/depot_tools:/opt/csw/gcc4/bin \
GYP_GENERATORS=make \
gclient runhooks --force)
running '/opt/csw/bin/python src/build/gyp_chromium' in '/
home/maciej/src/opencsw/pkg/chromium/trunk/work/build-isa-sparcv8/home/
chrome-svn/tarball/chromium'
Updating projects from gyp files...
Traceback (most recent call last):
File src/build/gyp_chromium, line 79, in module
sys.exit(gyp.main(args))
File src/tools/gyp/pylib/gyp/__init__.py, line 423, in main
params, options.check)
File src/tools/gyp/pylib/gyp/__init__.py, line 83, in Load
depth, generator_input_info, check)
File src/tools/gyp/pylib/gyp/input.py, line 2004, in Load
depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 392, in
LoadTargetBuildFile
includes, depth, check)
File src/tools/gyp/pylib/gyp/input.py, line 350, in
LoadTargetBuildFile
build_file_path)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 737, in
ProcessConditionsInDict
variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 886, in
ProcessVariablesAndConditionsInDict
build_file)
File src/tools/gyp/pylib/gyp/input.py, line 901, in
ProcessVariablesAndConditionsInList
ProcessVariablesAndConditionsInDict(item, is_late, variables,
build_file)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 737, in
ProcessConditionsInDict
variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 879, in
ProcessVariablesAndConditionsInDict
build_file, key)
File src/tools/gyp/pylib/gyp/input.py, line 860, in
ProcessVariablesAndConditionsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File src/tools/gyp/pylib/gyp/input.py, line 718, in
ProcessConditionsInDict
if eval(ast_code, {'__builtins__': None}, variables):
File string, line 1, in module
NameError: name 'ffmpeg_asm_lib' is not defined while evaluating
condition 'ffmpeg_asm_lib==1' in src/third_party/ffmpeg/ffmpeg.gyp
while loading dependencies of src/media/media.gyp while loading
dependencies of src/chrome/chrome.gyp while loading dependencies of
src/build/all.gyp while trying to load src/build/all.gyp
failed to run command: /opt/csw/bin/python src/build/gyp_chromium
gmake[1]: *** [gclient-runhooks] Error 2
gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/chromium/
trunk'
gmake: *** [build-isa-sparcv8] Error 2
My guess is that I need to build chromium-specific ffmpeg on Solaris
as a prerequisite, by following src/third_party/ffmpeg/
README.chromium. Is that correct?
Maciej
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Re: [chromium-dev] Do people still use scons to build anymore?
We're still in the middle of switching. I had made a pass over the docs a few weeks ago, but I'm sure I missed some spots. If you see any more spots, or want to do another pass to make sure the docs push people towards the make build by default, it'd be much appreciated! Thanks, Albert On Fri, Nov 13, 2009 at 1:56 PM, Chris Bentzel cbent...@gmail.com wrote: A number of pages on dev.chromium.org reference scons/hammer as the default tools for Linux builds. I've been using make just fine for the past week. If make is the standard tool now, I'll volunteer to clean up the documentation. Chris -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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
On Mon, Nov 2, 2009 at 3:37 PM, Bradley Nelson bradnel...@google.comwrote:
S,o as it happens, I just had someone on nacl make the first use of
multiple inheritance this morning.
He hasn't checked it in yet, but the use case is:
'Common': {
# bunch of global stuff
'defines': [
# bunch of 32-bit defines.
],
},
'Debug': {
# bunch of general debug stuff assumes 32-bit
'inherit_from': ['Common'],
},
'Release': {
# bunch of general release stuff assumes 32-bit
'inherit_from': ['Common'],
},
'Common_x64': {
# Customizations to change 32-bit - 64-bit
'abstract': 1,
'defines!': [
# bunch of 32-bit defines
],
'defines': [
# bunch of 64-bit defines
],
},
'Debug_x64': {
'inherit_from': ['Debug', 'Common_x64'],
},
'Release_x64': {
'inherit_from': ['Release', 'Common_x64'],
},
This use case seems reasonable enough.
It might fit into something like (b), but at least as currently conceived,
'Common_x64' has overrides of stuff in 'Common'.
It might be possible to refactor Common and Common_x64 to avoid collisions,
maybe pull out all the 32-bit stuff into Common_x86 and leave Common with
truly common stuff. On the other hand, the current arrangement allowed a
fairly small modification while 64-bit is being experimented with.
Suggestions?
Sorry for the slow response to this...missed it in my inbox. :(
It's hard to see w/o a concrete example, but in general I would have wanted
to do it via conditionals inside 'Common.'
Why rely on shadowing when you can explicitly do it via conditionals here?
IMO, the more dimensions in which we have to alter how the final dictionary
is created, the harder it will be to maintain -- especially if there
construct is one which relies on order of lookup, and doesn't encourage
co-locating where the decision is made for which modifications are included
(with conditionals, you know the else portion is likely in the same file.
With inheritance, it's all over the place.)
-Albert
--~--~-~--~~~---~--~~
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
On Sun, Nov 1, 2009 at 3:26 PM, Bradley Nelson bradnel...@google.comwrote:
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.
So, I'm tempted to go two routes...none great.
a) disallow multiple inheritance initially. Until someone demonstrates a
need, don't add it.
b) validate the full inheritance tree to ensure there are no name
collisions. I think this becomes less trivial because of the conditional
inherit below. Though, I guess this static checking phase could also reject
conditional inherits (which I'm a bit of a fan of).
(a) Feels like the best initial route IMO. Going (b) sounds nice in theory,
but in other systems that I've used which reject collisions, it makes
configuration maintenance pretty annoying.
In the end, what I think would really help is actually a config differ.
Basically, so I can do
gyp printtree all.gyp
gyp printtree all.gyp_with_changes
and then diff the output, after various bits. Don't know if something like
this already exists.
-Albert
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] New ffmpeg sumo lib requires libbz2-dev, and possibly a clobber build
As of r30640, on Linux and FreeBSD, we are now building the FFmpeg binaries as part of the normal Chromium build process. This means we now have a dependency on libbz2. :) Make sure to install the libbz2-dev package. I've updated the src/build/install-build-deps.sh script to reflect the new dependency. Also, in some situations, the linux build may require a clobber. If you see an issue where ffmpegsumo_nolink cannot resolve the uncompress symbol, try clobbering your build. It seems to work fine for most people, but every now and then a client seems borked. If you're curious to see the gritty change in full glory, the main change was here: http://src.chromium.org/viewvc/chrome?view=revrevision=30571. -Albert --~--~-~--~~~---~--~~ 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
Sounds really powerful...but this scares methough that could just be my
generalized fear of inheritance. However, if we start putting inheritance
into the system, I worry about the level of complexity the gyp specification
language will pick up and the possible breakages of information hiding that
it can entail.
Here's a couple of questions about syntax and semantics:
1) Do you support multiple inheritance? I notice the inherit_from is
specified as an array. That's scaryish.
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?
3) Is there a way to reference super, or various ancestors?
4) How does this interact with late-resolution variables?
5) How about conditionals? Can we conditionally inherit?
-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] How can we kill scons?
If I'm not mistaken, I think like most everyone running on linux is using the make build nowadays, and the make build seems to work well enough for most people. The only time I hear someone mention the scons build, it's in reference to you broke the scons build, or so you developed on make. Did you check it worked on scons? Given that, what's keeping us from killing the scons build completely? My current motivation for asking is that I've been spending the last hour trying to figure out why scons is deciding to insert an -fPIC into my build, whereas make is not. This is on top of my previous motivation (from about 3 days ago) where I spent another few hours making something that worked fine on the make build, scons compatible. I'd rather spend that time killing scons if there was a clear list of what was needed to make that happen. -Albert --~--~-~--~~~---~--~~ 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 can we kill scons?
On Wed, Oct 28, 2009 at 12:34 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: Not that it is effective :) Starred. :) Now what? On Wed, Oct 28, 2009 at 3:34 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Have you tried starring http://crbug.com/22044 ? On Wed, Oct 28, 2009 at 3:28 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: If I'm not mistaken, I think like most everyone running on linux is using the make build nowadays, and the make build seems to work well enough for most people. The only time I hear someone mention the scons build, it's in reference to you broke the scons build, or so you developed on make. Did you check it worked on scons? Given that, what's keeping us from killing the scons build completely? My current motivation for asking is that I've been spending the last hour trying to figure out why scons is deciding to insert an -fPIC into my build, whereas make is not. This is on top of my previous motivation (from about 3 days ago) where I spent another few hours making something that worked fine on the make build, scons compatible. I'd rather spend that time killing scons if there was a clear list of what was needed to make that happen. -Albert --~--~-~--~~~---~--~~ 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 can we kill scons?
I ran into that yesterday as well trying to make a make generator fix. I think I'll hang on until mmoss gets back since I heard he's in the middle of trying to fix that. But assuming the unittest can all be made green, then it's update the public instructions, and finally buildbot work? I can pickup on fixing the public instructions if no one objects. I don't think that needs to be blocked on the unittests, and might as well allow it to propagate out to the casual developers like while we get our ducks in line. -Albert 2009/10/28 Bradley Nelson bradnel...@google.com Looks like the failures are part of the same test case. It's the case where the same source file is built as part of two different targets using different defines. The make generator appears to build it only one way and use it in both targets. -BradN 2009/10/28 Bradley Nelson bradnel...@google.com So we have set of tests for gyp which are green for all the generators other than make. I believe mmoss has been whittling away on them, and I think its down to just 2 failures. go/gypbot After that its just a matter of the will to switch over the buildbots and fix any unforeseen issues. -BradN 2009/10/28 Lei Zhang thes...@chromium.org mmoss has been working on the make gyp generator, maybe he has a better feel for what's keeping us from switching. On Wed, Oct 28, 2009 at 12:35 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Wed, Oct 28, 2009 at 12:34 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Not that it is effective :) Starred. :) Now what? On Wed, Oct 28, 2009 at 3:34 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Have you tried starring http://crbug.com/22044 ? On Wed, Oct 28, 2009 at 3:28 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: If I'm not mistaken, I think like most everyone running on linux is using the make build nowadays, and the make build seems to work well enough for most people. The only time I hear someone mention the scons build, it's in reference to you broke the scons build, or so you developed on make. Did you check it worked on scons? Given that, what's keeping us from killing the scons build completely? My current motivation for asking is that I've been spending the last hour trying to figure out why scons is deciding to insert an -fPIC into my build, whereas make is not. This is on top of my previous motivation (from about 3 days ago) where I spent another few hours making something that worked fine on the make build, scons compatible. I'd rather spend that time killing scons if there was a clear list of what was needed to make that happen. -Albert --~--~-~--~~~---~--~~ 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 can we kill scons?
I actually got some weird warnings on the make build a while back when I specified the same file in two sources entries...something about circular dependencies and make ignore one. But don't remember the exact scenario. I betcha it isn't a problem in chrome cause it'd only trigger a bug if the file was compiled with different flags that modified behavior. Since our defines and compiler options are so stable (especially within one target), building once probably doesn't break stuff... -Albert 2009/10/28 Bradley Nelson bradnel...@google.com Updating the public instructions would be helpful! Please proceed. I'd be willing do the buildbot switchover, unless someone is more eager. I'm a little surprised that the failing test doesn't hork something in the chromium build. I known that there are some shared files like that (though it may be only on windows come to think of it). -BradN On Wed, Oct 28, 2009 at 1:13 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: I ran into that yesterday as well trying to make a make generator fix. I think I'll hang on until mmoss gets back since I heard he's in the middle of trying to fix that. But assuming the unittest can all be made green, then it's update the public instructions, and finally buildbot work? I can pickup on fixing the public instructions if no one objects. I don't think that needs to be blocked on the unittests, and might as well allow it to propagate out to the casual developers like while we get our ducks in line. -Albert 2009/10/28 Bradley Nelson bradnel...@google.com Looks like the failures are part of the same test case. It's the case where the same source file is built as part of two different targets using different defines. The make generator appears to build it only one way and use it in both targets. -BradN 2009/10/28 Bradley Nelson bradnel...@google.com So we have set of tests for gyp which are green for all the generators other than make. I believe mmoss has been whittling away on them, and I think its down to just 2 failures. go/gypbot After that its just a matter of the will to switch over the buildbots and fix any unforeseen issues. -BradN 2009/10/28 Lei Zhang thes...@chromium.org mmoss has been working on the make gyp generator, maybe he has a better feel for what's keeping us from switching. On Wed, Oct 28, 2009 at 12:35 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Wed, Oct 28, 2009 at 12:34 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Not that it is effective :) Starred. :) Now what? On Wed, Oct 28, 2009 at 3:34 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Have you tried starring http://crbug.com/22044 ? On Wed, Oct 28, 2009 at 3:28 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: If I'm not mistaken, I think like most everyone running on linux is using the make build nowadays, and the make build seems to work well enough for most people. The only time I hear someone mention the scons build, it's in reference to you broke the scons build, or so you developed on make. Did you check it worked on scons? Given that, what's keeping us from killing the scons build completely? My current motivation for asking is that I've been spending the last hour trying to figure out why scons is deciding to insert an -fPIC into my build, whereas make is not. This is on top of my previous motivation (from about 3 days ago) where I spent another few hours making something that worked fine on the make build, scons compatible. I'd rather spend that time killing scons if there was a clear list of what was needed to make that happen. -Albert --~--~-~--~~~---~--~~ 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: Fun with timers! A horror story
Would a hack like running nm --defined-only on each generated object, and then checking for dups work? You'd have to ignore weak symbols, and probably some others, but sounds doable. -Albert On Tue, Oct 27, 2009 at 6:48 PM, Peter Kasting pkast...@google.com wrote: On Tue, Oct 27, 2009 at 4:40 PM, James Robinson jam...@chromium.orgwrote: So what's the problem? WTF::currentTime() is implemented twice, once in JavaScriptCore/wtf/CurrentTime.cpp and once in webkit/api/src/ChromiumCurrentTime.cpp. The latter simply defers to base::Time::Now().ToDoubleT(), the former uses a somewhat different algorithm to try to normalize what the system returns. ThreadTimers.cpp was linking against the JavaScriptCore/wtf/CurrentTime.cpp version and webkitclient_impl.cc was linking against the webkit/api/src/ChromiumCurrentTime.cpp version. Arrrgghh Is there a way we can compile-time detect similar symbol names like this and throw fits (with a whitelist for any we know are OK)? Seems like this is an issue for something with linking that maruel might have looked at long ago. PKJ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Creating a flakey-test bot?
What do people think about creating a bot for isolating flakey tests from each major category of tests? The idea would be to try and move the flaky tests onto one bot so that the signal-to-noise ratio on the other bots gets better. Also, with layout tests that might flake via timeouts, you can improve the cycle time of the non-flakey bots. To update which bots go where, scrape the flakiness dashboard and reclassify tests based on their track record for the last N runs? -Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [mac] Chromium Helper + ffmpeg binary location == no video
We just noticed that the Chromium Helper.app cannot locate the ffmpeg binaries (libav*.dylib) in Mac Chromium. This leads to the video feature being disabled. :( Where should the ffmpeg binaries go? Should they be put alongside the binary in the Chromium Helper.app/Contents/MacOS? If we do this, I think it will break --single-process mode unless we keep a copy of the binary in both spots (which is ugly). Is there a shared location that both application bundles will be able to search for the ffmpeg binaries? -Albert P.S. The reason this wasn't noticed earlier is that all the video devs have been executing the app either by setting DYLD_LIBRARY_PATH in their environment manually, or via Xcode -- which sets DYLD_LIBRARY_PATH to include the output directory, again allowing for resolution of the ffmpeg binaries. Using --single-process also avoids this issue since it doesn't use Chromium Helper. *sigh* --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
On Wed, Oct 7, 2009 at 11:36 AM, Andrew Scherkus scher...@chromium.orgwrote: On Wed, Oct 7, 2009 at 11:34 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: We just noticed that the Chromium Helper.app cannot locate the ffmpeg binaries (libav*.dylib) in Mac Chromium. This leads to the video feature being disabled. :( Where should the ffmpeg binaries go? Should they be put alongside the binary in the Chromium Helper.app/Contents/MacOS? If we do this, I think it will break --single-process mode unless we keep a copy of the binary in both spots (which is ugly). If it helps, I believe --single-process is disabled for Google Chrome builds -- maybe a non issue and simply an inconvenience to us working on Mac video? Yeah, if we don't care about single-process, we can just move the binaries, and things becomes happy. However, it'd be nice not to lose --single-process. -Albert --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
What is @loader_path relative off of? On Wed, Oct 7, 2009 at 12:35 PM, Mark Mentovai m...@chromium.org wrote: My preference would be to place them inside Chromium Framework.framework, then. If you need to, you can put them inside Chromium Helper.app/Contents/MacOS instead, but I'm trying really hard to minimize the amount of stuff inside the app and the helper app. You can get the framework as a bundle from mac_util::MainAppBundle() since r28262. If you put the dylibs in the framework and they depend on one another, you may need to switch them to refer to each other using @loader_path instead of @executable_path. Mark scherkus wrote: On Wed, Oct 7, 2009 at 12:17 PM, Mark Mentovai m...@chromium.org wrote: Which processes need to load these libraries? Render process. Are these libraries loaded at launch time or by dlopen? dlopen() 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] Starting Git Cookbook for chromium
I've started a little wiki to record useful git recipes that people use for developing chromium. http://code.google.com/p/chromium/wiki/GitCookbook Currently, it just has an entry for how to exclude files from a git-cl upload, while preserving them in another branch. If you have a useful recipe, or if you notice a question pop up on IRC multiple times, please add it to the page! The wiki is linked it off our For Developer Page. Happy gitting! -Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Heads up: changing location of ffmpeg binaries
We're moving the location of the ffmpeg binaries -- hopefully for the last time -- to allow for different variants for each platform. The specific first use case is x64 linux, and debug builds of ffmpeg for mac and linux. We don't do debug builds for windows because the gcc-built ffmpeg cannot generate compatible symbols for useful debugging. The CL for this review is: http://codereview.chromium.org/215016 When this is committed, you'll need to clean up your local client to avoid getting warnings from gclient. Specifically, you should: 1) rm -rf or del /s /q src/third_party/ffmpeg/binaries 2) remove the src/third_party/ffmpeg/binaries/chromium from your .gclient_entries file If you don't do this, things will still work, but gclient will complain at you. I will send an update once this is committed. -Albert --~--~-~--~~~---~--~~ 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 Linux 64-bit
Awesome! :) FYI, video will not work out of the box since the ffmpeg binaries we have are 32-bit. We need a bit of work to shift them over. If you see bugs there, it's expected. -Albert On Thu, Aug 20, 2009 at 10:18 AM, Michael Moss mm...@chromium.org wrote: Awesome! I'll work on the buildbot, then start marking all the ia32-libs bugs invalid :) On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Common terms + Techno Babble glossary
I started a page to collect the common terms/lingo that gets used in chromium development. It's pretty anemic right now, but if a term keeps needing to get reexplained to people, please add it to the page. Also, if anyone has a better idea for formatting, please feel free to change it. I tried messing with tables on sites, but got confused and gave up. http://sites.google.com/a/chromium.org/dev/developers/common-terms--techno-babble I linked to it off the main For Developers page under Communication. Thanks, Albert --~--~-~--~~~---~--~~ 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: Common terms + Techno Babble glossary
Nope. Feel free to move it, or I'll do it tomorrow. -A On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade est...@chromium.org wrote: is there a reason this isn't on the wiki? -- Evan Stade On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: I started a page to collect the common terms/lingo that gets used in chromium development. It's pretty anemic right now, but if a term keeps needing to get reexplained to people, please add it to the page. Also, if anyone has a better idea for formatting, please feel free to change it. I tried messing with tables on sites, but got confused and gave up. http://sites.google.com/a/chromium.org/dev/developers/common-terms--techno-babble I linked to it off the main For Developers page under Communication. Thanks, Albert --~--~-~--~~~---~--~~ 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: Common terms + Techno Babble glossary
awesome. thanks! 2009/8/20 Evan Stade est...@chromium.org ported: http://code.google.com/p/chromium/wiki/Glossary?ts=1250828818updated=Glossary -- Evan Stade On Thu, Aug 20, 2009 at 8:57 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: Nope. Feel free to move it, or I'll do it tomorrow. -A On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade est...@chromium.org wrote: is there a reason this isn't on the wiki? -- Evan Stade On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: I started a page to collect the common terms/lingo that gets used in chromium development. It's pretty anemic right now, but if a term keeps needing to get reexplained to people, please add it to the page. Also, if anyone has a better idea for formatting, please feel free to change it. I tried messing with tables on sites, but got confused and gave up. http://sites.google.com/a/chromium.org/dev/developers/common-terms--techno-babble I linked to it off the main For Developers page under Communication. Thanks, Albert --~--~-~--~~~---~--~~ 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: Does Chromium use boost library
On Sun, Aug 16, 2009 at 7:37 AM, Mark Mentovai m...@chromium.org wrote: n179...@gmail.com wrote: Does Chromium use boost library? In the source tree, i see there is a 'boost' directory under 'third-party'. It appears to be an incomplete version of boost 1.36. I said incomplete since a lot of directories of boost are missing? Does anyone know why is that? (Authoritatively) As previously mentioned, boost was only present in support of gmock. The gmock-boost dependency was dropped in r18923, and all of boost was supposed to be removed in r20159. It seems that the removal was incomplete. It got rid of all of the files in third_party/boost, but not that directory or any of its subdirectories. I've just committed r23531, which removes the third_party/boost directory structure. It seems that git rm didn't delete the directories themselves. :( Thanks for fixing Mark! As for why the boost structure is incomplete, when we added it for gmock, we stripped it down to the minimal set of files needed to support tr1/tuple since that was al gmock needed. But all of that is gone now. -Albert --~--~-~--~~~---~--~~ 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: Parallel builds w/ VS2005 (or, what Darin learned after mistakenly committing changes to common.gypi)
oh man...been wanting this for ages. Thanks!
On Fri, Aug 14, 2009 at 2:06 PM, Eric Seidel esei...@chromium.org wrote:
That is really slick. gyp-authors++
-eric
On Fri, Aug 14, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote:
If you are like me and accustomed to hacking build/common.gypi to enable
/MP under VS2005, then please read on:
It turns out that there is a better way! Instead, just create a
~/.gyp/include.gypi file containing the following:
{
'variables': {
'msvs_multi_core_compile': 1
}
}
Then re-run gclient runhooks --force to rebuild the VS project files.
This will force GYP to output /MP :-)
-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: build error, libavcodec.so.52
On the bright side, now you only download the binaries that make sense for your platform. :) -Albert On Mon, Aug 10, 2009 at 5:18 PM, Andrew Scherkus scher...@chromium.orgwrote: We shuffled these around on Friday such that these binaries now live in /deps/third_party/ffmpeg and are pulling in via DEPS. Try: rm -rf src/third_party/ffmpeg/binaries rm .gclient_entries gclient sync --force On Mon, Aug 10, 2009 at 5:04 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just got this error: scons: *** [/chromium/src/sconsbuild/Debug/libavcodec.so.52] Source `/chromium/src/sconsbuild/Debug/obj/third_party/ffmpeg/binaries/chromium/libavcodec.so.52' not found, needed by target `/chromium/src/sconsbuild/Debug/libavcodec.so.52'. I'll try to workaround it, but it looks like a bug. I did gclient sync recently (which ran 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: Stack traces on layout test crashes
FYI, the code in debug_util.h will generate a stack trace, but symbol resolution doesn't work on mac. Last I messed with it (~4 months ago), mac didn't work because most of the symbols are private. Mark Mentovai suggested trying to reimplement dladdr, but I could never get it working. Here's the uploaded code if anyone to mess with it: http://codereview.chromium.org/164228 On windows and linux, assuming you actually have symbols generated (which I don't think you do for windows on the build bots), getting a trace should be as simple as creating one of those StackTrace objects in debug_util.h, and calling PrintBacktrace or OutputToStream on it. The hard part is knowing when to create the object, and making sure you're on the right thread. Also, these functions do some heap allocations so using them in a crash handler might be a bit unsafe...but if it's crashing, and there's already no way to get a core or something, making it crash harder isn't going to matter. -Albert On Sat, Aug 8, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.org wrote: I'll take a look. If anyone has ideas on how to implement this (beyond looking at base/debug_util.h) please let me know! The last time I messed around with programatic stack traces was 5+ years ago. :-) On Sat, Aug 8, 2009 at 7:53 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: Somebody please run with this! :) :DG On Fri, Aug 7, 2009 at 8:45 PM, Darin Fisherda...@chromium.org wrote: On Fri, Aug 7, 2009 at 8:39 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Aug 7, 2009 at 8:45 PM, Jeremy Orlow jor...@chromium.org wrote: Has anyone ever looked into printing out stack traces when layout tests crash? Of the couple layout test crashes I've investigated, I think most could have been solved just by having a stack trace. I'm not really sure what's involved or if anyone's looked into this, which is why I'm asking. This could be especially helpful for flaky tests that crash. I don't remember anyone having looked into this. I agree that this would make tracking down and fixing these issues immensely easier, especially for tests that only sometimes crash. Ojan I've wanted this for a very long time. I think there might be a bug on it. At any rate, we now have a nice utility in base/debug_util.h that can provide a stack trace. I would love to see crash stacks on the buildbot. It would probably help us eliminate a lot of flakiness! -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 usage in chromium
On Thu, Aug 6, 2009 at 10:36 AM, Evan Martin e...@chromium.org wrote: On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafaio...@chromium.org wrote: After following the instructions in that document trunk/src is git and everything else (pulled in via DEPS, including webkit and also ICU, skia, etc.) is via svn. I've been wondering about this. What would it take to modify our git checkout process to pull third_party/WebKit via git as well? Would it mostly work to just exclude third_party/WebKit via DEPS, create it via a git checkout and then write a script that wraps gclient sync to also git pull/rebase third_party/WebKit? Is there a better way? I had an old version of gclient that did this. The problem you run into is that there are more possible tree states of git than in svn so it's hard to map across. Say DEPS says web...@revision A, and you have webkit at revision A~10. gclient sync should probably fast-forward your checkout. Say DEPS says web...@revision A, and then you've checked out trunk and have local changes. gclient sync should probably... do nothing? But then how do we tell DEPS checked them out at A~10 before, so we should fast forward to A from they checked out A~10 because that was trunk at the time, so we should fast forward to trunk? Etc. It's basically some UI questions that I haven't had the time to worry about yet. Currently, I just manage the webkit changes by hand rather than letting gclient do it. I have a git checkout of webkit symlinked (mounted in XP since symlinks don't work right until vista) on top of third_party/WebKit. You'll need to add the following into the custom_deps of your .gclient: src/third_party/WebKit/JavaScriptCore: None, src/third_party/WebKit/WebCore: None, src/third_party/WebKit/WebKitLibraries: None, src/third_party/WebKit/LayoutTests: None, Then after a gclient sync, to get a branch of webkit at the right revision + all the build files regenerated, I do some variant of ajwong$ i=`head ~/src/git-chrome/src/DEPS | grep webkit_revision | cut -d '' -f4`; git checkout -b $i `git svn find-rev r$i` ajwong$ i gclient runhooks --force Any of the merges/cherry-pick of current work off the webkit tree, I do by hand. It's been working pretty well for me. -Albert --~--~-~--~~~---~--~~ 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: Make PostTask virtual?
Responding to three separate parts of the thread (too bad we aren't using
Wave :P).
On Tue, Aug 4, 2009 at 7:35 AM, Darin Fisher da...@chromium.org wrote:
I don't think we want a HasPendingTasks method. Consider that the
MessageLoop may be used by multiple threads. Any code depending on
HasPendingTasks is likely to be fragile. Also, a MessageLoop may have work
to do that is not task related.
I think adding inspection functions isn't a bad solution, assuming they're
marked for testing (eg., Making the name HasPendingTasksForTest()).
Using these functions in a multithreaded is not safe, but in unittests,
we've been using a pattern of creating a message loop, then executing
message_loop.RunAllPending() to simulate one iteration of the loop. This
setup doesn't execute a new thread and gives us a paused loop that would
actually be quite suitable for inspection.
This might actually be one of the least invasive methods of allowing for a
test point to be inserted.
On Tue, Aug 4, 2009 at 6:41 AM, Andrew Scherkus scher...@chromium.orgwrote:
I think it'd interesting to try. I imagine we'd need some helper gmock
actions to take care of executing/deleting tasks.
Out of curiosity, would adding a HasPendingTasks() method solve your
current testing issue?
On Tue, Aug 4, 2009 at 6:28 AM, Marc-Antoine Ruel mar...@chromium.orgwrote:
I'm slightly against. No real reason :) except that it'll definitely
bloat the WPO build.
How bad would the bloat be?
Another possible solution that avoids a virtual is to add a constructor that
takes a mock delegate for just the for functions. Then in the message loop
code, add a shim into each API that can be intercepted. Something like
MessgaeLoop(PostTaskDelegate *mock_delegate)
: mock_delegate_(mock_delegate) {
}
void PostTask(...) {
if (mock_delegate_) {
mock_delegate_-PostTask();
return;
}
// do real work.
}
This is a bit ugly since it will take a bit of inspection to know which
methods are mockable, and the shim needs to be put into each mockable
function. However, it has the niceness of not really disturbing the current
API structure and avoiding virtual.
M-A
On Tue, Aug 4, 2009 at 2:37 AM, Darin Fisherda...@chromium.org wrote:
MessageLoop is not designed to be subclassed. Call me a minimalist,
but I
think it damages slightly the readability of the code to have methods
marked
virtual that do not need to be. That said, I love mocking. Since a
lot of
code doesn't actually need a MessageLoop so much as a place to post
tasks,
maybe it would be better to define an interface for posting tasks that
MessageLoop can implement. Then a lot of code could be switched over
to
that interface, making the code a bit more abstract. Think of
IPC::Message::Sender as an example of this kind of abstraction.
That'd work and give a pretty clear separation. However, I also have a
couple of slight hesitations:
(a) It adds yet another interface + complexity. We already have
MessagePump,
MessagePump::Delegate, MessageLoop, etc., which at least when
starting out, can get really confusing.
(b) It still makes the methods virtual, which has the effect of making
them
feel subclassable (like you said), and bloating the build (like M-A
said)
Of these three choices, I'm tempted to go with the shim approach, with the
mock being passed during construction.
-Albert
On Mon, Aug 3, 2009 at 8:23 PM, Albert J. Wong (王重傑)
ajw...@chromium.org
wrote:
I've noticed that most public functions on MessageLoop are
non-virtual.
How bad would it be to make PostTask, and its variants, virtual? Are
the
perf implications or similar that would be bad?
I'd like to be able to use gmock to mock out a message loop so I can
test
if my code knows to stop posting tasks. However, not having the
message
loop be virtual makes this hard.
Thanks,
Albert
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Testing HTML5 Video tag in chromium
This has come up a bunch, so I think it warrants a post. If you're playing with the HTML5 video tag in a chromium build (ie. Daily builds, or your own builds from source), the only video codec enabled is Ogg/Vorbis. Thus, http://www.youtube.com/html5 isn't going to work. Please try a ogg/vorbis site instead such as http://tinyvid.tv instead to test. This is true for all platforms. -Albert --~--~-~--~~~---~--~~ 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 Make breakage workaround
It seems like there's some bad interaction between gclient and gyp's make build generator that got uncovered when the gyp DEPS were rolled to r555. The effect is the top-level make file ends up having src/ prepended to the paths for all the sub-makefiles. A simple work around is to run gyp by manually from the src directory. Note that the directory is important, as is *not* running it via gclient runhooks. The specific bug seems to be as follows: 1) gyp was switched to using relative path generation on linux. 2) gclient invokes up from one level above src 3) The relative paths that are inserted into the root Makefile are mistakenly made relative off of the directory that gyp was invoked in. We could probably unroll the DEPS to fix it, but since it's friday night, and this wasn't the only change included in the gyp update, publishing a workaround seemed safer. -Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Knowing when a context menu is closed
I need to find a way to know when a context menu is closed, either via a menu item selection, or via hitting escape, opening a new menu, unfocusing the window, etc. Ideally, there'd be some sort of menu closed function or event that is called when the menu stops being displayed. On the gtk port, I see a RenderViewContextMenuGtk::StoppedShowing(), but nothing similar for Windows and Mac. Can anyone give me a pointer on how to do something like this for mac, and windows? Thanks, Albert --~--~-~--~~~---~--~~ 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: Knowing when a context menu is closed
On Wed, Jul 22, 2009 at 1:19 PM, Nico Weber tha...@chromium.org wrote: On mac, you can probably set the NSMenu's delegate to an object of your choice and have it implement menuDidClose: if you want to implement this yourself. Cool, I'll look into that once I get the windows side settled. On Wed, Jul 22, 2009 at 1:07 PM, Tommito...@chromium.org wrote: for Windows: http://msdn.microsoft.com/en-us/library/ms647599(VS.85).aspx The WM_EXITMENULOOP message informs an application's main window procedure that a menu modal loop has been exited. I also see WM_UNINITMENUPOPUP. The description of that is: The *WM_UNINITMENUPOPUP* message is sent when a drop-down menu or submenu has been destroyed. Is that less appropriate to use that WM_EXITMENULOOP? Thanks, Albert On Wed, Jul 22, 2009 at 2:13 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: I need to find a way to know when a context menu is closed, either via a menu item selection, or via hitting escape, opening a new menu, unfocusing the window, etc. Ideally, there'd be some sort of menu closed function or event that is called when the menu stops being displayed. On the gtk port, I see a RenderViewContextMenuGtk::StoppedShowing(), but nothing similar for Windows and Mac. Can anyone give me a pointer on how to do something like this for mac, and windows? Thanks, Albert --~--~-~--~~~---~--~~ 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: Knowing when a context menu is closed
On Wed, Jul 22, 2009 at 1:26 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: On Wed, Jul 22, 2009 at 1:19 PM, Nico Weber tha...@chromium.org wrote: On mac, you can probably set the NSMenu's delegate to an object of your choice and have it implement menuDidClose: if you want to implement this yourself. Cool, I'll look into that once I get the windows side settled. On Wed, Jul 22, 2009 at 1:07 PM, Tommito...@chromium.org wrote: for Windows: http://msdn.microsoft.com/en-us/library/ms647599(VS.85).aspx The WM_EXITMENULOOP message informs an application's main window procedure that a menu modal loop has been exited. I also see WM_UNINITMENUPOPUP. The description of that is: The *WM_UNINITMENUPOPUP* message is sent when a drop-down menu or submenu has been destroyed. Is that less appropriate to use that WM_EXITMENULOOP? I tried this, but it doesn't quite do what I want. The messages that are received by the context menu window after a left-click are: 0x215 - WM_CAPTURECHANGED 0x125 - WM_UNINITMENUPOPUP 0x11f - WM_MENUSELECT 0x212 - WM_EXITMENULOOP 0x126 - WM_MENUCOMMAND This is a problem because WM_EXITMENULOOP occurs before WM_MENUCOMMAND. The problem currently is that, for certain context menu items on a HTML5 media element, I need to keep a reference inside the renderer to the actual HTML5 DOM node so that if an action is selected I can call commands on this DOM node. If the context menu is dismissed, I need to send message to the render to the drop the reference in order to not leak a resource. If an action is selected on the context menu, I need to send the selected action to the renderer before I instruct the renderer to drop the reference. Unforutnately, the message ordering for the window doesn't allow for me to do this. Currently, I'm down to really cheesy solutions like posting a delayed task for 500ms later to drop the reference on a WM_EXITMENULOOP in hopes that the WM_MENUCOMMAND can beat it in the race and send the selected action to the renderer before the reference drop. Is there any windows magic that I'm missing to be able to get a guaranteed windows message that will show up after WM_MENUCOMMAND if a selection is made? Thanks, Albert --~--~-~--~~~---~--~~ 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: Knowing when a context menu is closed
On Wed, Jul 22, 2009 at 6:11 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 22, 2009 at 6:05 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: The problem currently is that, for certain context menu items on a HTML5 media element, I need to keep a reference inside the renderer to the actual HTML5 DOM node so that if an action is selected I can call commands on this DOM node. Can you keep a weak reference, and if the node is no longer available at MENUCOMMAND time, just do nothing? That would work. Does WebKit have weak references? I don't see anything that looks obviosuly like one in JavaScriptCore/wtf. I also got another suggestion that on the action, I should just redo the hit test to retrieve the media node, which nicely handles cases where the movie node is getting changed out via javascript from undernearth the context menu. -Albert --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:45 PM, Adam Barth aba...@chromium.org wrote: On Wed, Jul 15, 2009 at 1:40 PM, Peter Kastingpkast...@chromium.org wrote: On Wed, Jul 15, 2009 at 1:34 PM, Adam Barth aba...@chromium.org wrote: On Wed, Jul 15, 2009 at 12:57 PM, Peter Kastingpkast...@chromium.org wrote: I am still confused. I recommend the experimental method. If you have trouble, we can try to figure out what's different between your setup and my setup. OK, first problem: I get the following warning spew after every gclient sync: WARNING: src/third_party/WebKit/WebCore is no longer part of this client. It is recommended that you manually remove it. WARNING: src/third_party/WebKit/JavaScriptCore is no longer part of this client. It is recommended that you manually remove it. WARNING: src/third_party/WebKit/LayoutTests is no longer part of this client. It is recommended that you manually remove it. No matter what I do (resync, delete these directories and resync, etc.) I still get these warnings. This sounds like a recent change to gclient. The old behavior was that gclient would delete these directories during the first sync (because it decided they were no longer needed). The second sync would then pull them in from svn.webkit.org. Maybe try removing those directories from your .gclient_entries file? I actually added that change to keep gclient from deleting subdirectories underneath a git controlled webkit checkout. The old behavior is available if you specified the --delete_unversioned_trees option. -Albert --~--~-~--~~~---~--~~ 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 in starting My Chromium on MacOSX
Since you built it, you should be able to fire it up in a debugger and see where it's dying. That's what I'd try first. -A On Wed, Jul 15, 2009 at 3:47 PM, n179911 n179...@gmail.com wrote: Hi, I download the source of chromium and build successfully on MacOSX. When I start the TestShell.app, it launches successfully and I can load a page (www.cnn.com) But when I start the Chromium.app, i see the Chromium appears on the Dock for 1-2 seconds and then it kills itself. Can you please tell me how can I get more information why my Chromium fails to launch? Or what am i missing to start my Chromium on Macos x. Thank you. p.s. Sorry for cross-posting. I couldn't get any help in chromium-discuss mailing list. --~--~-~--~~~---~--~~ 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: vs2008 and gyp
(Oh and for the folks that added in boost, I'll be adding in an MSVS_VERSION variable you'll be able to use at gyp time so you can have different behaviors). Good to know. BTW, boost got removed about 3 weeks ago after zhanyong broke the dependency from gmock to boost and tr1 (yay!). So no need to worry about it anymore! -Albert --~--~-~--~~~---~--~~ 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: Buildbot performance issue.
On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org wrote: The underlying problem with buildbot is the database format, which is just hundred of thousand of files on the harddrive, with no seek capability, and the fact that the webserver itself is single threaded. We currently have 63 slaves on our main waterfall. I think this is too many for what buildbot can really support. We would ideally need to split it. Can we get upstream buildbot devs involved in this discussion? It seems they ought to be able to scale better than they have. I talked to them a little. They do plan some of that for their 1.0 release, but they said that it was not on the radar until then. It seems to me a caching layer that only ever hit the backend every ten seconds would allow it ten seconds to grind through its computations, which should be more than sufficient, without any extra splitting up required. That is, we should (a) fix the proxy and (b) make every use the proxy. That makes a lot of sense. I agree that we should fix the proxy, and make more people use it. Some direct buildbot access would still be required internally to force a build and stuff like that. Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? I personally hate auto-refresh. We should make it opt-in since I doubt most users need it and it adds load. I expect many people (myself included) leave the buildbot page open in a background tab and have it continually refreshing despite not looking at it. (My other common use case: the tree is red, I start scrolling down to see what's gone wrong, and then the page refreshes out from under me and I lose where I was looking.) Yep, a lot of people told me the same thing. Some other told me they would like a faster reload. Now i'm tempted to let the user control the reload and not give a default one. - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. This is absurdly powerful! It should have all the data necessary to generate the page in RAM already, no need for even touching the disks (?). Yeah, i'm not too sure how to debug this. When I strace the process I only see file reads, scrolling, like crazy, all the time. That is pretty nuts. Is it calling fsync or something crazy? Since you said strace, I'm assmuming linux. In that case, the buffer cache should be saving you from disk accesses for most everything. -Albert --~--~-~--~~~---~--~~ 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: Which means TBR and CL
TBR = To be reviewed (means the checkin was done w/o a review and needs to be looked at by someone) CL = Change list. Usually referring to some rietveld change number. On Sun, Jul 5, 2009 at 12:54 PM, Thiago Farina thiago.far...@gmail.comwrote: In some reviews and patch I saw this abreviations, but I don't know what it means. --~--~-~--~~~---~--~~ 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: Should GYP files be UTF8 Encoded?
If it's assumed ASCII, would it be sensible to assert it in the gyp parser? On Sat, Jun 27, 2009 at 1:17 PM, Daniel Cowx daniel.c...@gmail.com wrote: No use case. I was just creating a new GYP file and wanted to know what encoding to save the file as...that's all :-) On Jun 26, 10:52 pm, Bradley Nelson bradnel...@google.com wrote: The intention was ascii AFAIK. Unless someone has a use case? -BradN On Fri, Jun 26, 2009 at 3:05 PM, Daniel Cowx daniel.c...@gmail.com wrote: Not that I'm aware of. Just wanted to confirm that intention is ASCII for now unless need arises. On Jun 26, 2:18 pm, Dan Kegel daniel.r.ke...@gmail.com wrote: On Fri, Jun 26, 2009 at 1:50 PM, Daniel Cowxdaniel.c...@gmail.com wrote: Should GYP files be UTF8 Encoded? We can probably get away with ascii for now... are there any filenames that really need to be in a wider character set? --~--~-~--~~~---~--~~ 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: Gmock compilation errors on VS2008SP1
I haven't heard back about any more VS2008 issues. I'm going to remove boost tuple from the chromium tree next week, which will break the workaround nakro posted earlier. If there any more VS2008 issues, please let me know soon so I don't break you. :) Thanks, Albert On Tue, Jun 23, 2009 at 9:49 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: Hi Thiago, Did you sync pas revision 19049? And did you do a clean build? Thanks, Albert On Tue, Jun 23, 2009 at 9:37 AM, Thiago Farina thiago.far...@gmail.comwrote: I have the same problem with tuple. On Jun 15, 1:24 pm, Marc-Antoine Ruel mar...@chromium.org wrote: I'm fine with that if necessary. On Mon, Jun 15, 2009 at 12:11 PM, Albert J. Wong(王重傑) ajw...@chromium.org wrote: On Mon, Jun 15, 2009 at 9:03 AM, nakro yoav.zilberb...@gmail.com wrote: Hi albret, projects that fail : gmockj gmockmain here is an example out from gmockmain C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : error C2065: '_Is_swap_move' : undeclared identifier 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple (504) : see reference to class template instantiation 'std::_Move_operation_categorystd::tr1::tuple_Arg0,_Arg1,_Arg2,_Arg3,_Arg 4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9' being compiled 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499) : error C2226: syntax error : unexpected type 'std::_Move_operation_category_Value::_Move_cat' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2947: expecting '' to terminate template-argument-list, found '' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2976: 'std::_If' : too few template arguments 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include \xutility(1018) : see declaration of 'std::_If' the solution on my machine is this to do HAS_TR1=0 (you have 1 by default) and to change gmock_port.h to include the boost version even on 2008, which initially your code goes to the tuple path That's a good workaround. Switching to the boost implementation would almost certainly work for now. I'll attempt to reproduce and figure out a long term fix (including just whacking the tr1 dependency out of gmock...started a discussion with zhanyong about this last week). If it gets bad enough, we could consider changing over the VS2008 builds to use boost as well, and then disable _HAS_TR1 as you described above, but that'll require a full clobber from everyone due to precompiled header issues. -Albert but i must have something wrong with my machine if i am the only one who is having this --~--~-~--~~~---~--~~ 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: gclient runhooks --force not forceful enough?
Doesn't gclient runhooks --force setup the scons build on linux? Or did the make build become default at some point? On Thu, Jun 25, 2009 at 5:57 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: I did rm Makefile gclient runhooks --force and it didn't regenerate Makefile. tools/gyp/gyp -f make build/all.gyp does rebuild it. Seems like gclient runhooks --force ought to, no? --~--~-~--~~~---~--~~ 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: Heads up: Clobber required for disabling TR1 in windows
I just submitted this change (r19049). It's cycling through the build bots now. http://src.chromium.org/viewvc/chrome?view=revrevision=19049 If you sync past this point, you will need to do a clobber build, otherwise you will get precompiled header problems. -Albert On Thu, Jun 18, 2009 at 4:03 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: 2009/6/18 Evan Martin e...@chromium.org On Thu, Jun 18, 2009 at 3:51 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: This upgrade should fix the compatibility issues MSVS 2008 users hav been having due to bad tr1 interactions with various bits of code. It also moves us closer to killing rtti. What else needs rtti? Do we have a bug open on killing it? base/hash_table.h pulls in tr1/functional which uses typeid. -Albert --~--~-~--~~~---~--~~ 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: Gmock compilation errors on VS2008SP1
I just submitted the change to remove _HAS_TR1 in vs2008. http://src.chromium.org/viewvc/chrome?view=revrevision=19049 This should fix the vs2008 issues with gmock. Let me know if you continue to see problems. -Albert On Fri, Jun 19, 2009 at 5:23 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: If you didn't see my other mail to chromium-dev, I'll be trying to whack the tr1 dependency next week. That should hopefully fix the issue you were having. Will update this thread again when the patch is committed. -Albert On Mon, Jun 15, 2009 at 9:11 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Mon, Jun 15, 2009 at 9:03 AM, nakro yoav.zilberb...@gmail.com wrote: Hi albret, projects that fail : gmockj gmockmain here is an example out from gmockmain C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : error C2065: '_Is_swap_move' : undeclared identifier 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple (504) : see reference to class template instantiation 'std::_Move_operation_categorystd::tr1::tuple_Arg0,_Arg1,_Arg2,_Arg3,_Arg4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9' being compiled 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499) : error C2226: syntax error : unexpected type 'std::_Move_operation_category_Value::_Move_cat' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2947: expecting '' to terminate template-argument-list, found '' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2976: 'std::_If' : too few template arguments 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include \xutility(1018) : see declaration of 'std::_If' the solution on my machine is this to do HAS_TR1=0 (you have 1 by default) and to change gmock_port.h to include the boost version even on 2008, which initially your code goes to the tuple path That's a good workaround. Switching to the boost implementation would almost certainly work for now. I'll attempt to reproduce and figure out a long term fix (including just whacking the tr1 dependency out of gmock...started a discussion with zhanyong about this last week). If it gets bad enough, we could consider changing over the VS2008 builds to use boost as well, and then disable _HAS_TR1 as you described above, but that'll require a full clobber from everyone due to precompiled header issues. -Albert but i must have something wrong with my machine if i am the only one who is having this --~--~-~--~~~---~--~~ 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: Gmock compilation errors on VS2008SP1
Hi Thiago, Did you sync pas revision 19049? And did you do a clean build? Thanks, Albert On Tue, Jun 23, 2009 at 9:37 AM, Thiago Farina thiago.far...@gmail.comwrote: I have the same problem with tuple. On Jun 15, 1:24 pm, Marc-Antoine Ruel mar...@chromium.org wrote: I'm fine with that if necessary. On Mon, Jun 15, 2009 at 12:11 PM, Albert J. Wong(王重傑) ajw...@chromium.org wrote: On Mon, Jun 15, 2009 at 9:03 AM, nakro yoav.zilberb...@gmail.com wrote: Hi albret, projects that fail : gmockj gmockmain here is an example out from gmockmain C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : error C2065: '_Is_swap_move' : undeclared identifier 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple (504) : see reference to class template instantiation 'std::_Move_operation_categorystd::tr1::tuple_Arg0,_Arg1,_Arg2,_Arg3,_Arg 4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9' being compiled 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499) : error C2226: syntax error : unexpected type 'std::_Move_operation_category_Value::_Move_cat' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2947: expecting '' to terminate template-argument-list, found '' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2976: 'std::_If' : too few template arguments 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include \xutility(1018) : see declaration of 'std::_If' the solution on my machine is this to do HAS_TR1=0 (you have 1 by default) and to change gmock_port.h to include the boost version even on 2008, which initially your code goes to the tuple path That's a good workaround. Switching to the boost implementation would almost certainly work for now. I'll attempt to reproduce and figure out a long term fix (including just whacking the tr1 dependency out of gmock...started a discussion with zhanyong about this last week). If it gets bad enough, we could consider changing over the VS2008 builds to use boost as well, and then disable _HAS_TR1 as you described above, but that'll require a full clobber from everyone due to precompiled header issues. -Albert but i must have something wrong with my machine if i am the only one who is having this --~--~-~--~~~---~--~~ 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: Gmock compilation errors on VS2008SP1
If you didn't see my other mail to chromium-dev, I'll be trying to whack the tr1 dependency next week. That should hopefully fix the issue you were having. Will update this thread again when the patch is committed. -Albert On Mon, Jun 15, 2009 at 9:11 AM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: On Mon, Jun 15, 2009 at 9:03 AM, nakro yoav.zilberb...@gmail.com wrote: Hi albret, projects that fail : gmockj gmockmain here is an example out from gmockmain C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : error C2065: '_Is_swap_move' : undeclared identifier 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple (504) : see reference to class template instantiation 'std::_Move_operation_categorystd::tr1::tuple_Arg0,_Arg1,_Arg2,_Arg3,_Arg4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9' being compiled 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499) : error C2226: syntax error : unexpected type 'std::_Move_operation_category_Value::_Move_cat' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2947: expecting '' to terminate template-argument-list, found '' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2976: 'std::_If' : too few template arguments 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include \xutility(1018) : see declaration of 'std::_If' the solution on my machine is this to do HAS_TR1=0 (you have 1 by default) and to change gmock_port.h to include the boost version even on 2008, which initially your code goes to the tuple path That's a good workaround. Switching to the boost implementation would almost certainly work for now. I'll attempt to reproduce and figure out a long term fix (including just whacking the tr1 dependency out of gmock...started a discussion with zhanyong about this last week). If it gets bad enough, we could consider changing over the VS2008 builds to use boost as well, and then disable _HAS_TR1 as you described above, but that'll require a full clobber from everyone due to precompiled header issues. -Albert but i must have something wrong with my machine if i am the only one who is having this --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Heads up: Clobber required for disabling TR1 in windows
I'll be upgrading googletest to r267 and googlemock to r173 in order to break our tr1 dependency on windows, and one rtti dependency in linux/mac. When I land the patch to set _HAS_TR1=0 on windows, it will necessitate a full clober to fix the precompiled headers. Over the last couple of weeks, Zhanyong added multiple patches to to hack around the tr1 issues on gcc and msvs. In r267, he added a subset of tr1::tuple so that we no longer need either boost or tr1 in visual studio. IN r265 of googlemock, he added a hack to disable a suprious include of tr1/functional from tr1/tuple (this is apparently fixed in later versions of gcc) that was forcing rtti to be enabled due to a use of typeid. This upgrade should fix the compatibility issues MSVS 2008 users hav been having due to bad tr1 interactions with various bits of code. It also moves us closer to killing rtti. I'm going to try to get this change landed tonight so it can bake over friday. If I don't get it in tonight, I'll wait until next week. Let me know if there are any questions or issues. -Albert --~--~-~--~~~---~--~~ 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: Heads up: Clobber required for disabling TR1 in windows
2009/6/18 Evan Martin e...@chromium.org On Thu, Jun 18, 2009 at 3:51 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: This upgrade should fix the compatibility issues MSVS 2008 users hav been having due to bad tr1 interactions with various bits of code. It also moves us closer to killing rtti. What else needs rtti? Do we have a bug open on killing it? base/hash_table.h pulls in tr1/functional which uses typeid. -Albert --~--~-~--~~~---~--~~ 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: Gmock compilation errors on VS2008SP1
This isn't an issue that I've heard of yet... Can you post a few more details such as which file (or files) is failing the compile? -Albert On Sun, Jun 14, 2009 at 4:01 PM, nakro yoav.zilberb...@gmail.com wrote: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : error C2065: '_Is_swap_move' : undeclared identifier and many more like it i clobbered my build, synced --force, did revert this only started to happen in the last 24 hours or so is anyone able to compile it on their VS2008SP1 machines ? --~--~-~--~~~---~--~~ 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: Gmock compilation errors on VS2008SP1
On Mon, Jun 15, 2009 at 9:03 AM, nakro yoav.zilberb...@gmail.com wrote: Hi albret, projects that fail : gmockj gmockmain here is an example out from gmockmain C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : error C2065: '_Is_swap_move' : undeclared identifier 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple (504) : see reference to class template instantiation 'std::_Move_operation_categorystd::tr1::tuple_Arg0,_Arg1,_Arg2,_Arg3,_Arg4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9' being compiled 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499) : error C2226: syntax error : unexpected type 'std::_Move_operation_category_Value::_Move_cat' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2947: expecting '' to terminate template-argument-list, found '' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2976: 'std::_If' : too few template arguments 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include \xutility(1018) : see declaration of 'std::_If' the solution on my machine is this to do HAS_TR1=0 (you have 1 by default) and to change gmock_port.h to include the boost version even on 2008, which initially your code goes to the tuple path That's a good workaround. Switching to the boost implementation would almost certainly work for now. I'll attempt to reproduce and figure out a long term fix (including just whacking the tr1 dependency out of gmock...started a discussion with zhanyong about this last week). If it gets bad enough, we could consider changing over the VS2008 builds to use boost as well, and then disable _HAS_TR1 as you described above, but that'll require a full clobber from everyone due to precompiled header issues. -Albert but i must have something wrong with my machine if i am the only one who is having this --~--~-~--~~~---~--~~ 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: Makefile build broken
sorry for the bustage. I had assumed the make file was still a toy with only 2-3 people using it (not many linux chrome folks where I am). Thanks for rolling it back Adam. I'll probably just submit the generated files as tony suggested. -Albert On Thu, Jun 11, 2009 at 9:51 AM, Thomas Van Lenten thoma...@chromium.orgwrote: On Thu, Jun 11, 2009 at 12:48 PM, Adam Langley a...@chromium.org wrote: On Thu, Jun 11, 2009 at 8:52 AM, Tony Changt...@chromium.org wrote: Albert, what do you think? I estimate that about 5-7 people on the linux team use the make build these days. I reverted in r18168. It sucks that there's no try or builders for the make build, but it's what everyone uses these days. If the times are really better, we can change the default in gyp, someone just needs to update the buildbot scripts accordingly. TVL AGL --~--~-~--~~~---~--~~ 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: CL 115977 will require clobber build
This has been submitted as r17430. On Mon, Jun 1, 2009 at 2:13 PM, Albert Wong (王重傑) ajw...@chromium.orgwrote: I will be checking in a /D change to essential.vsprops that requires a clobber build. The change is to enable TR1 for VS2008 SP1 so that gmock can compile on that platform. I'm running through the clobber builds locally right now, and will probalby submit the change tomorrow morning. Will send out an update with the revision number when it's it's landed. For those interested, the CL is here: http://codereview.chromium.org/115977 -Albert http://codereview.chromium.org/115977 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] CL 115977 will require clobber build
I will be checking in a /D change to essential.vsprops that requires a clobber build. The change is to enable TR1 for VS2008 SP1 so that gmock can compile on that platform. I'm running through the clobber builds locally right now, and will probalby submit the change tomorrow morning. Will send out an update with the revision number when it's it's landed. For those interested, the CL is here: http://codereview.chromium.org/115977 -Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Make sure all hex digis in msvs_guid are capitalized.
Found this yesterday. If any of the hex digits in the msvs_guid (specified in the .gyp files) for your target are lowercase, IncrediBuild's BuildConsole will silently ignore building said target. The target will build fine under Visual Studio, using either normal build, or IncrediBuild. However, executing the IncrediBuild via the commandline via BuildConsole, like the build bots do, will manage to trigger this error and likely cause link issues. It seems that IncrediBuild's guid validation logic permits lowercase letters in the hex string, but then chokes on them when using the guid to determine build targets. Here's a patch to gyp that will check for this specific error case so it doesn't happen again: http://codereview.chromium.org/118021. But, incase anyone else see strange skipped build target issues, try checking the GUID. -Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] GoogleMock not available for use in src/testing
As of r17066, GoogleMock (also known as gmock) is available for use in unit tests! Yaay! *What is it?* Gmock it is a is a C++ mock-object framework, similar to EasyMock for java, built on top of Google Test for use in C++. There's lots of documentation on the Google Mock project pagehttp://code.google.com/p/googlemock/. Start with the ForDummieshttp://code.google.com/p/googlemock/wiki/ForDummiesguide, or this TotT episodehttp://googletesting.blogspot.com/2008/12/mockers-of-c-world-delight.html . *Who should use it?* Most anyone writing mock objects. *Who wants to write mock objects anyways?* Probably anyone that writes unittests. *Why should I use it?* Cause it makes writing unittests easier, which means it makes it makes your life easier. :) *How to use it?* Add a dependency on testing/gmock.gyp:gmock #include testing/gmock/include/gmock/gmock.h *Got an Example?* There's a example of the syntax in src/base/gmock_unittest.cc that shows off some of the features of Google Mock. Note that this is just an example of how to use the syntax for Google Mock. It is *not *meant to be an example/guide for how to use mock objects in testing. If you want to learn about how to use mock objects for better unittests, here are a few TotT episodes that are good starting points: http://googletesting.blogspot.com/2008/06/tott-friends-you-can-depend-on.html http://googletesting.blogspot.com/2009/02/tott-partial-mocks-using-forwarding_19.html They assume Java/EasyMock, but the concepts still apply with C++/Gmock. Enjoy! -Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] GoogleMock now available for use in src/testing
...fixing...the subject. It's now available. Small difference in semantics. :-/ On Thu, May 28, 2009 at 11:16 AM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: As of r17066, GoogleMock (also known as gmock) is available for use in unit tests! Yaay! *What is it?* Gmock it is a is a C++ mock-object framework, similar to EasyMock for java, built on top of Google Test for use in C++. There's lots of documentation on the Google Mock project pagehttp://code.google.com/p/googlemock/. Start with the ForDummieshttp://code.google.com/p/googlemock/wiki/ForDummiesguide, or this TotT episodehttp://googletesting.blogspot.com/2008/12/mockers-of-c-world-delight.html . *Who should use it?* Most anyone writing mock objects. *Who wants to write mock objects anyways?* Probably anyone that writes unittests. *Why should I use it?* Cause it makes writing unittests easier, which means it makes it makes your life easier. :) *How to use it?* Add a dependency on testing/gmock.gyp:gmock #include testing/gmock/include/gmock/gmock.h *Got an Example?* There's a example of the syntax in src/base/gmock_unittest.cc that shows off some of the features of Google Mock. Note that this is just an example of how to use the syntax for Google Mock. It is *not *meant to be an example/guide for how to use mock objects in testing. If you want to learn about how to use mock objects for better unittests, here are a few TotT episodes that are good starting points: http://googletesting.blogspot.com/2008/06/tott-friends-you-can-depend-on.html http://googletesting.blogspot.com/2009/02/tott-partial-mocks-using-forwarding_19.html They assume Java/EasyMock, but the concepts still apply with C++/Gmock. Enjoy! -Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Unittesting python
Do we have any unittest support for python in the chromium code base? I did a find ./ -name '*test*.py' and didn't find much. I'm writing a tool to auto-gen some stub code, and didn't see a clear test framework to hook into. -Albert --~--~-~--~~~---~--~~ 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 build now depends on alsa
As of r16639, the linux build now requires ALSA to build. src/build/install-build-deps.sh has been updated with the dependency. Please run that if the compiler starts complaining that alsa/asound.h cannot be found. -Albert --~--~-~--~~~---~--~~ 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: Add in boost_tuple into third-party for use by googlemock in windows.
One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, «To use Google Mock, you will need the TR1http://en.wikipedia.org/wiki/Technical_Report_1 tuple C++ library installed.» and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Packhttp://www.microsoft.com/downloads/details.aspx?FamilyId=D466226B-8DAB-445F-A7B4-448B326C48E7 . Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it *could *be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off upstream gmock from using it.) --SK On Fri, May 15, 2009 at 7:40 AM, nsylv...@chromium.org wrote: LGTM with my comment and sgk's comments. As for maruel's comment : It made me sad too. gmock seems to be a lot of troubles (svn:external, then ugly dependencies). Have we at least considered using something else? Or not using it at all? http://codereview.chromium.org/115398/diff/1/2 File third_party/boost/README.chromium (right): http://codereview.chromium.org/115398/diff/1/2#newcode3 Line 3: http://googlemock.googlecode.com/files/boost_tr1_tuple_1_36_0.zip Can you add a line that says what the license is. http://codereview.chromium.org/115398 --~--~-~--~~~---~--~~ 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: Add in boost_tuple into third-party for use by googlemock in windows.
[ +zhanyong ] I chatted with Zhanyong about both swapping out tr1::tuple, and about removing the svn:external reference in the repository. The gmock actions use tr1:tuple as part of the public interface for defining new actions. Thus, changing the tuple implementation would basically mean that any other googlemock client using tr1::tuple in their code would have clashing tuple implementations. This will only get worse as tr1 is adopted more widely. As for getting our own version of gtest instead of retrieving it through svn:external, the implementation of gmock and gtest are pretty tightly coupled. Thus, versioning gtest separately might be a bad idea. The suggestion is to consider gmock a super-set of gtest and drop the original dependency. Zhanyong, please correct me if I got something wrong here. Regarding the svn:external reference to google test, currently, the best solution seems to be either a) having 2 copies of gtest in the tree (a bit dangerous due to possible shadowing issues) b) passing --ignore-externals to svn in gclient (an incomplete solution because not every svn access goes through gclient) How bad is it if we don't explicitly version gtest ourselves? -Albert 2009/5/15 Scott Hess sh...@chromium.org If this is the only reason gmock needs boost, it seems like a better idea would be to push a copy of tuple.h into gmock and submit a patch to make it more self-contained in the first place. -scott On Fri, May 15, 2009 at 11:17 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.org wrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, To use Google Mock, you will need the TR1 tuple C++ library installed. and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Pack. Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it could be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off upstream gmock from using it.) --SK On Fri, May 15, 2009 at 7:40 AM, nsylv...@chromium.org wrote: LGTM with my comment and sgk's comments. As for maruel's comment : It made me sad too. gmock seems to be a lot of troubles (svn:external, then ugly dependencies). Have we at least considered using something else? Or not using it at all? http://codereview.chromium.org/115398/diff/1/2 File third_party/boost/README.chromium (right): http://codereview.chromium.org/115398/diff/1/2#newcode3 Line 3: http
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
If there was a nice way to get a PlatformCanvas out of a
PlatformGraphicsContext when PLATFORM(CG), that'd be awesome.
Brett, I'm not quite sure how you mean to do that. Do you mean that in the
glue code, we should instantiate a byte buffer that we ask the rendered to
fill in, then use webkit's GraphicsContext functions to write that buffer to
screen?
For reference, here's the entry point (plus termporary compilation fix)
that's causing us the headaches:
void MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) {
if (m_data) {
#if PLATFORM(SKIA)
AsDelegate(m_data)-Paint(p-platformContext()-canvas(),
webkit_glue::IntRectToWebRect(r));
#else
// TODO(port): Mac builds use PLATFORM(CG) which does not expose a
// PlatformCanvas from the PlatformContext. Figure out how to render
the
// video on a mac.
notImplemented();
#endif
}
}
2 delegations later, this ends up in video_render_impl.cc which finds the
current video frame to draw, and then writes it to the passed in
PlatformCanvas.
-Albert
On Tue, May 5, 2009 at 7:57 PM, Amanda Walker ama...@chromium.org wrote:
That would be pretty clean--or perhaps wrap it in a PlatformCanvas
instead of a bare PlatformGraphicsContext? I haven't looked at the
media code yet, so I'm not familiar with what it's actually trying to
do.
--Amanda
On Tue, May 5, 2009 at 10:08 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, May 6, 2009 at 8:40 AM, Andrew Scherkus scher...@chromium.org
wrote:
WebKit's MediaPlayerPrivate interface is a bit backwards where they pass
in
a GraphicsContext:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup
We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p,
const
IntRect r) call into Chrome, converting the GraphicsContext to
a PlatformContextSkia in the process. We realized today this doesn't
work
on Mac since it's actually a CGContext.
Without resorting to #ifdefs everywhere, what's the best way to pass
a PlatformGraphicsContext back to Chrome?
Can you just pass a pointer to the pixels and the size? I think the
pixel format should be well-defined on each platform, and it should be
easy to make a SkBitmap in the Chrome side that uses those pixels
directly.
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: Passing PlatformGraphicsContext from WebKit to Chrome code
On Tue, May 5, 2009 at 9:38 PM, Amanda Walker ama...@chromium.org wrote: Ah, I see. Hmm, going in that direction (from a GraphicsContext back up to the PlatformCanvas that wraps it) is an interesting question (the rest of our rendering code goes in the other direction). And as Brett can attest, this isn't the first time that PLATFORM(CG) has caused a headache--we just (so far) haven't been willing to duplicate/fork all of the Mac rendering code that currently lives in PLATFORM(CG), since there's a lot of it (especially text handling) that would end up the same. Brett's idea (change your paint routine to take a raw pixmap (an RGBA32Buffer), which we can easily draw into a GraphicsContext on any platform, is basically what the ImageDecoder subclasses do (including rudimentary multi-frame support for things like animated GIFs). If that will work, it's probably the easiest to integrate into all 3 platforms, since the dirty work has already been done. If that's too many frame copies for video, we can write a function that can create, say, an SkBitmap* pointing at the destination bits given a GraphicsContext and a rectangle. Would either of those approaches work? They both sound workable, and might be the best option at this point. We'd actually considered something similar, but didn't really like the idea of having the GraphicsContext draw call happen inside the webkit glue code; all our other glue code just delegates, so this would suddenly add behavior into the glue class. Another suggestion that Alpha brought up was to write some sort of simple wrapper for GraphicsContext that could allow us to call the draw lower down in the call chain without violating the typing abstraction. -Albert --Amanda On Tue, May 5, 2009 at 11:38 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: If there was a nice way to get a PlatformCanvas out of a PlatformGraphicsContext when PLATFORM(CG), that'd be awesome. --~--~-~--~~~---~--~~ 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: Why are pref keys wchar_t's?
Is there a place that actually describes when it's appropriate to use which string type, and how to know if we should be fixing code we run across? Is everything just supposed to be string16? -Albert On Fri, May 1, 2009 at 11:59 AM, Evan Martin e...@chromium.org wrote: We have a bunch of places where wchar_ts still exist, and none of them are correct. I think this isn't particular instance isn't likely to b *that* much waste but it definitely would be nice to fix. I fixed command line switch names to be ASCII on the train into work once just 'cause it was bothering me. On Fri, May 1, 2009 at 11:42 AM, Mike Pinkerton pinker...@chromium.org wrote: Why are our internal pref keys all wchar_t strings? That's pretty wasteful for something the user never sees and doesn't need to be localized. It's really wasteful on Mac and Linux (32bit wchar_t). Is this on anyone's radar to fix? Should I file a bug? -- 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: POSIX: EINTR correctness
On Fri, May 1, 2009 at 1:31 PM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, May 1, 2009 at 1:27 PM, Adam Langley a...@chromium.org wrote:
On Fri, May 1, 2009 at 12:53 PM, Jeremy Orlow jor...@google.com wrote:
I'm still kind of new here, so forgive me if this is a silly question,
but
why do this with a define and not an template function?
One could imagine a template function:
templatetypename T
T handle_eintr(T a) {
..
}
But when using it as:
handle_eintr(close(fd));
How would one trigger close(fd) to be possibly evalulated multiple
times? I think that's the one thing which precludes a template
function sadly.
Creating a set of templates isn't too bad. Looking through the list of
functions agl sent, sendto and recvfrom take hte most arguments, at 6.
IOCtl will be annoying though cause of the vararg.
-Albert
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
