Re: [chromium-dev] seeking c++ expertise for a tiny tricky bit of code
Dan Kegel wrote: On Wed, Jan 13, 2010 at 9:12 AM, Stephen White senorbla...@chromium.org wrote: 2) Most of the supposed performance advantage of strict aliasing rules is probably taken care of by memory disambiguation in modern (ie., Core2 and later) CPUs. I kind of doubt that. Disallowing aliasing lets the compiler do a number of high-level optimizations that the chip could never do on its own. See e.g. http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html I'm for -fstrict-aliasing except for third_party. Me too. I support -fstrict-aliasing or not specifying anything explicitly (as we presently do), and only using -fno-strict-aliasing for specific third_party libraries that are known to need it. Mark -- 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] seeking c++ expertise for a tiny tricky bit of code
I don't think that a firing squad will materialize over this change, but if one does, I'll quell them for you. LGTM in principle (but I haven't seen the actual change). Mark Craig Schlenter wrote: On Wed, Jan 13, 2010 at 9:00 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jan 13, 2010 at 10:53 AM, Craig Schlenter craig.schlen...@gmail.com wrote: I'm one try-server run away from possibly turning -fno-strict-aliasing on for all linux/bsd gcc: http://codereview.chromium.org/519034 From a process standpoint, given that there is some disagreement here is someone going to come find me with a clue bat if I commit this? I don't think anyone will be rabid :) That said, my comment in my prior email stands: if we're basically capable of throwing -fstrict-aliasing for first-party code now, what do we gain by instead throwing -fno-strict-aliasing? I would be sad to see us do this unless it really buys us something. Other than the immediate gain of hiding crbug.com/28749, I think the biggest benefit is that end users relying on 4.4 builds are likely to have a more stable experience in future since it is a safe default. The PPA ubuntu builds from fta are already running with no_strict_aliasing=1 btw. The other thing it buys us is a more relaxed timetable to solve the aliasing problems if it doesn't break the tree by default. Anyway, I think I'll commit this and then go hide somewhere :) --Craig -- 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: Running Chromebot on official builds from trunk
Thomas Van Lenten wrote: Where are the profile dirs going on disk? Time machine doesn't have to be on, we can add things to this file incase it is turned on. (and again. the multiple-address interface for mailing lists kind of sucks.) -- 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: Running Chromebot on official builds from trunk
Debugging tips:
1. What's the parent pid of your zombies? Is it a browser process or
something else?
2. Temporarily move /bin/ps to /bin/ps.real, and at /bin/ps put a
small script that writes the full argument list and maybe other
debuggery to a log file somewhere, and then invokes /bin/ps.real. For
example:
#!/bin/sh
(date ; echo ${$} ${PPID} $...@}) /tmp/pslog.${EUID}
exec ${0}.real $...@}
Then, using the logged data, you'll see what arguments ps is being
invoked with, and you'll be able to look to see where we make those ps
calls in our own code (if it's even happening in our own code).
3. Try to reproduce it in a developer build instead of a released
official build. You'll need to reproduce it to know if you've fixed
it once you think you've figured it out.
h-n-y,
Mark
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Running Chromebot on official builds from trunk
Viet-Trung Luu wrote: 2. Temporarily move /bin/ps to /bin/ps.real, and at /bin/ps put a small script that writes the full argument list and maybe other debuggery to a log file somewhere, and then invokes /bin/ps.real. For example: [...] Done. And I now see that it looks like my fault. Now I need to figure out why ps is being run, and why it's not being properly reaped For those of us following along from home while on vacation, what did the arguments look like? It sounds like you're on track again. Excellent. Mark -- 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] Modifying .gyp files
Igor Gatis wrote: Really? At least, it does not seem to be the case for make generator. There are no rules for handling .proto files in make generator. That's actually what I've been trying to do in the last couple of days. GYP rules are something that you have to write yourself, there aren't any pre-baked ones other than the native support each environment provides to compile C++. A GYP rule applies to input files in a 'sources' section based on the file's extension. Look at the 'rules' sections in some of Chromium's .gyp files for examples. Mark -- 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] Modifying .gyp files
Igor Gatis igorga...@gmail.com wrote:
Great, just wrote a rule for that. I placed it on the final target of my
project. What would be nice is to define such rule on the protobuf library
gyp and export it. It seems this file does that. But when I try doing the
same, I get the following error:
[...]
File
/home/wgatis/google-apis/tools/third_party/gyp/pylib/gyp/generator/make.py,
line 606, in WriteRules
for rule_source in rule['rule_sources']:
KeyError: 'rule_sources'
Sounds like a bug in the make generator. It shouldn't be an error to
define a rule but not have any sources that match its extension in a
specific target. Try changing line 606 of make.py to:
for rule_source in rule.get('rule_sources', []):
although that may be incomplete: you may also need to keep the block
at lines 666-668 from executing if |not 'rule_sources' in rule| too.
Mark
--
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] Running multiple Google Chrome channels side-by-side (for testing)
Finnur Thorarinsson wrote: You can use the channel changer, as PhistucK points out, to switch and then use the About box to update, but you can only move forward in time (stable - beta - dev). I'm pretty sure the changer is deprecated. The supported way to hop between channels is to run the installer for whatever channel you want to move to. Mark -- 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] Core Text
We will. It's on my plate and TVL's. We did have some hardware slated to use for this, but we've slowly chipped away at that, so it'll come out of the next batch. Bringing up the 10.6 bots had to take a back seat to the other things that we needed to do in the beta run-up, but 10.6 bots are a much higher priority now. Mark Darin Fisher wrote: It seems like we should have perf bots for 10.6 and 10.5. (We have perf bots for XP and Vista.) -Darin On Mon, Dec 14, 2009 at 9:03 AM, Jeremy Moskovich jer...@chromium.org wrote: I'll put together some numbers. Best regards, Jeremy On Mon, Dec 14, 2009 at 6:46 PM, Mark Mentovai m...@chromium.org wrote: Jeremy Moskovich wrote: Yep, Avi's right - we don't really have that option here. ATSUI is deprecated in 10.6 - we're seeing crashes and incorrect rendering. If there are perf issues we can file radars against Core Text. We should at least know what this change does to us perf-wise. If we're not happy with the outcome, there may be things we can tune on our side or things that we can press on Apple to investigate on the CoreText side. Mark -- 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] Modifying .gyp files
Igor Gatis wrote: You mean they were manually pre-created, right? Yes I used a custom action with success and I believe that sounds better for module updates purposes. We used to do things like that in the pre-GYP days. When we moved our builds over to GYP, we decided that it wasn't anywhere near worthwhile. It inflated build times (autoconf's configure is SLOW) and was difficult to capture dependency data properly and get the output in the right place. I don't recommend adding configure steps when you can configure once for the platforms you need and check the results in. Mark -- 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] Thoughts on // NOLINT?
There are cases where you'll want to flout the linter, but this isn't one of them. Scott and Peter have both posted viable workarounds that don't hamper readability (and in fact improve it relative to the snippet Jonathan is asking about.) Personally, I prefer Scott's, but Peter's is good too. Don't do what Jacob proposed in this case: it's a net a readability loss because the pattern is unfamiliar. (Sorry, Jacob!) Mark Scott Hess wrote: On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.com wrote: On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.org wrote: In essence: return DoWork(foo) #if defined(OS_POSIX) DoWork(posix_specific) #endif ; // -- Lint complains about this guy I'd prefer this: #if defined(OS_POSIX) return DoWork(foo) DoWork(posix_specific); #else return DoWork(foo); #endif The same number of lines, but much easier to read. Or: bool ret = DoWork(foo); #if defined(OS_POSIX) ret = ret DoWork(posix_specific); #endif return ret; Breaking a single statement up with a macro is icky. -scott -- 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] Re: Can't build r34152
gclient sync --force Gary Thomas wrote: Indeed, this is in thread: http://groups.google.com/group/chromium-dev/browse_thread/thread/0053084fdb3f7742 However, there is no solution there. I have a brand new download/ checkout and I ran 'gclient sync' immediately thereafter. The thread implies the file should exist; it does not. [gtho...@hermes src]$ svn ls third_party/yasm/source/patched-yasm/ modules/arch svn: 'third_party/yasm/source/patched-yasm/modules/arch' is not under version control I did 'svn up third_party/yasm/source/patched-yasm' and found many missing files. Perhaps 'gclient sync' didn't do the right thing? On Dec 9, 9:42 am, Evan Martin e...@chromium.org wrote: Try pasting a subphrase of that into a search engine. :) On Wed, Dec 9, 2009 at 6:55 AM, Gary Thomas samoht.y...@gmail.com wrote: Fedora Linux host: make: *** No rule to make target `third_party/yasm/source/patched-yasm/ modules/arch/x86/gen_x86_insn.py', needed by `out/Debug/obj/gen/ third_party/yasm/x86insns.c'. Stop. -- 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] Modifying .gyp files
There's better info in gclient.py, as a comment. Maybe we can just
rip this off and stick it in a web page somewhere on the developer
site.
Hooks
.gclient and DEPS files may optionally contain a list named hooks to
allow custom actions to be performed based on files that have changed in the
working copy as a result of a sync/update or revert operation. This
could be prevented by using --nohooks (hooks run by default). Hooks can also
be forced to run with the runhooks operation. If sync is run with
--force, all known hooks will run regardless of the state of the working
copy.
Each item in a hooks list is a dict, containing these two keys:
pattern The associated value is a string containing a regular
expression. When a file whose pathname matches the expression
is checked out, updated, or reverted, the hook's action will
run.
action A list describing a command to run along with its arguments, if
any. An action command will run at most one time per gclient
invocation, regardless of how many files matched the pattern.
The action is executed in the same directory as the .gclient
file. If the first item in the list is the string python,
the current Python interpreter (sys.executable) will be used
to run the command. If the list contains string $matching_files
it will be removed from the list and the list will be extended
by the list of matching files.
Example:
hooks = [
{ pattern: \\.(gif|jpe?g|pr0n|png)$,
action: [python, image_indexer.py, --all]},
]
Marc-Antoine Ruel wrote:
Humm, that's a good question. Right now the only doc is gclient help
runhooks which is .. uh .. not really useful.
M-A
On Wed, Dec 9, 2009 at 3:28 PM, Igor Gatis igorga...@gmail.com wrote:
Is there documentation somewhere regarding gclient? I'd like to know more
about how hooks and other gclient features work.
On Tue, Dec 8, 2009 at 6:27 PM, Mark Mentovai mmento...@google.com wrote:
Igor Gatis wrote:
When I change a .gyp, do I need to call gyp or the build process does
that
for me?
When you change it yourself, in your own working copy, you run
gclient runhooks to get new files generated.
When a .gyp change is checked in, you don't need to do this: gclient
will automatically run GYP as needed when you run gclient sync.
Mark
--
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] Splitting off some pieces of chrome.gyp...
I think that the stripped-down NaCl-specific 64-bit targets are the right thing to have happened to base, at least for now. Mark Brad Nelson wrote: I had talked about this with mmentovai and some others. Concern was raised about the complexity this would introduce into gyp. I do have a gut feeling we'll eventually go there. What Greg is currently doing at least works with gyp as it now stands, but it isn't pretty. Mark, does what's happened to base scare you enough that we should look at this again? -- 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] Splitting off some pieces of chrome.gyp...
Bradley Nelson wrote: You mean as 'base' currently is, or duplicating the file lists? I mean I have no problem with base_nacl_win64 existing as a target, and with adding files that are needed in that target to that target. Mark -- 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] Splitting off some pieces of chrome.gyp...
Bradley Nelson wrote: Even if those files are largely a duplicate of those in base? If it gets to that point, we can maintain the sources list, or the shared sources list, in a variable. Then we could do explicit additions to the targets that need it, or explicit excludes if that winds up easier. Mark -- 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] Modifying .gyp files
Igor Gatis wrote: When I change a .gyp, do I need to call gyp or the build process does that for me? If it does, how does it detect the .gyp file has been modified? When you change it yourself, in your own working copy, you run gclient runhooks to get new files generated. When a .gyp change is checked in, you don't need to do this: gclient will automatically run GYP as needed when you run gclient sync. Mark -- 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] UI Jank Task Force Status Update
Is this thought to be http://crbug.com/29240, or are there other problems with the signal handler? The change to fix that is out at http://codereview.chromium.org/460094. Mark Evan Stade wrote: On Mon, Dec 7, 2009 at 1:41 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: On Mon, Dec 7, 2009 at 22:34, Glenn Wilson gwil...@chromium.org wrote: Evan Triaging Linux Jank bugs. Probably not many that are actionable right now, though. That's not exactly Jank issue, but on a lot of our bots we're getting leftover processes on Linux. It seems they don't respond properly to SIGTERM. This seems to have started after we added the handler for SIGTERM (previously chrome was using the default handler). So this causes quite a lot of flakiness, but is also kind-of janky. As you pointed out, this is not jank (i.e., sluggish user experience). Have you filed a bug and cc'ed agl + willchan + mark (who I believe have worked on the new handler)? -- 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] Can't build on Snow Leopard anymore
This script runs on
third_party/WebKit/WebKitLibraries/libWebKitSystemInterfaceLeopard.a,
but that file hasn't changed in the past couple of days, so I don't
see why this would be happening.
The script that's driving the failed step is at
third_party/WebKit/WebCore/WebCore.gyp/mac/adjust_visibility.sh. I'd
be curious to figure out what value you're getting for ARCHS at line
58 of that script.
You should file a bug and assign it to me, and you can put the answer
to this question there.
Mark
Robert Sesek wrote:
I've tried to build on Snow Leopard twice. I've tried both an incremental
and a clobber, but both times I get this error:
=== BUILD AGGREGATE TARGET webkit_system_interface Support OF PROJECT
WebCore WITH THE DEFAULT CONFIGURATION (Debug) ===
Check dependencies
PhaseScriptExecution Action \Adjust Visibility\
../../../../xcodebuild/WebCore.build/Debug/webkit_system_interface
Support.build/Script-C2FA7E609918094ADF85F31E.sh
cd
/Users/rsesek/Projects/chromium/src/third_party/WebKit/WebCore/WebCore.gyp
/bin/sh -c
\/Users/rsesek/Projects/chromium/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webkit_system_interface
Support.build/Script-C2FA7E609918094ADF85F31E.sh\
ar: input.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: input.a: Inappropriate file type or format
ld: file not found:
/Users/rsesek/Projects/chromium/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/adjust_visibility/self/*.o
Command /bin/sh failed with exit code 1
Command /bin/sh failed with exit code 1
** BUILD FAILED **
The following build commands failed:
webkit_system_interface Support:
PhaseScriptExecution Action \Adjust Visibility\
/Users/rsesek/Projects/chromium/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webkit_system_interface
Support.build/Script-C2FA7E609918094ADF85F31E.sh
(1 failure)
This script contains:
#!/bin/sh
exec mac/adjust_visibility.sh
../../WebKitLibraries/libWebKitSystemInterfaceLeopard.a
${BUILT_PRODUCTS_DIR}/libWebKitSystemInterfaceLeopardPrivateExtern.a
${INTERMEDIATE_DIR}/adjust_visibility
exit 1
Any ideas? This only started happening recently (last 2 days or so).
rsesek / @chromium.org
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Use of external libICU
nikuli...@gmail.com wrote: LibICU is almost ubiquitous in non microsoft OS distributions, usually more upstream and ahead of upstream with bugs subsequent to every ICU release. Also it takes a lot of time to compile. Is there any point of having it bundled? Our version of ICU is patched relative to the upstream version. Distribution versions of ICU don't contain our patches. See http://crbug.com/28294 for the details. Mark -- 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] Xcode, whitespace and you
Dave MacLachlan wrote: If you don't ever use Xcode as an editor, don't ever want to use Xcode as an editor, or don't know what Xcode is, you can stop reading now. Hopefully I've got a few of you left ;-) This is awesome! I can't wait to give it a try. Eric Seidel wrote: I'm anti trailing whitespace. I think they're only agnostic about it because XCode can't zap it for them. I think better would be to get this kind of functionality pushed into XCode. You might ask Mark Mentovai to work his connections as he's had dealing with the XCode team rather recently. All with backend stuff, though. I'll poke and see. Mark -- 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] class has virtual method but non-virtual destructor
rahulsin...@gmail.com wrote: I was trying to compile chromium today on Linux and I got this error. This error occurred because of -Werror CFLAG set in the Makefile. I remedied by writing a one-liner to delete all occurrences of -Werror from CFLAGS in all Makefiles. I happen to find this warning very useful, just as I find our policy to make warnings hard errors in our own code helpful. Base *b = new Sub(); delete b; To the best of my knowledge, if Base is the class which defines virtual methods but non-virtual destructor, delete can cause a memory leak if Sub happens to be taking more memory than Base. Strictly speaking, the problem isn't precisely that a leak will occur if Sub is larger than Base. The real problem is that Sub::~Sub won't run unless Base declares a virtual destructor. I think that the destructor for a class with virtual methods has either to be public virtual or protected non-virtual for the proper freeing of memory. Would someone help me clarify this? From our style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Inheritance#Inheritance Make your destructor virtual if necessary. If your class has virtual methods, its destructor should be virtual. As Evan points out, there are some cases when it's not absolutely necessary to have a base or interface class declare a virtual destructor. Mark -- 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] Splitting apart chrome.gyp
Bradley Nelson wrote: If we move the gypi's to subdirectories, paths in them will still be relative to src/chrome, which might be confusing. I would prefer if gypi's didn't have this behavior, and plan to fix it: http://code.google.com/p/gyp/issues/detail?id=116 That bug only refers to the 'includes' section of a .gypi file in a different directory than its including .gyp file. I don't think that's relevant here. Path reparenting means that paths in a .gypi file should be treated as relative to that .gypi file, not the including .gyp. (With the exception of paths in 'includes', apparently, which is GYP bug 116.) Anything that's in input.py's path_sections or any value associated with a *_dir, *_file, or *_path key or their plural forms, should currently be subject to reparenting. We currently rely on this behavior in build/common.gypi. As an example, at one point in that file, I set a variable named 'strip_from_xcode_path' to 'mac/strip_from_xcode' and then use that variable in an action. Only build/mac/strip_from_xcode exists in our repository, but the path is adjusted properly for each .gyp file that common.gypi is included into. 'sources' is in path_sections, but you'll need to take care with regular expressions for 'sources/': those aren't (and can't be) path sections, and you might need to adjust the patterns to take this into account. Path reparenting has nothing to do with Julie. Mark -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: sheriff's keep the tree *open* WAS: [chromium-dev] More sheriffs?
Ojan Vafai o...@google.com wrote: I don't think this is what sheriffs are supposed to do, although there is clearly not consensus here. The goal of the sheriff is to keep the tree open as long as possible without carpeting over regressions. The sheriff should suffer through minor flakiness without closing the tree (e.g. a couple flaky webkit tests should not close the tree). YES. This is important, and I want to expand on it. A good sheriff doesn’t just open and close the tree. A good sheriff actively monitors and manages the tree. As much as we might want to codify how to respond to certain situations, I think that the best sheriffs rely on experience and good judgment more than anything else. Don’t read that to mean that we shouldn’t document sheriffing duties and tools, I think that’s important too. What might be even more helpful to a rookie (or a bad sheriff) would be to watch a good sheriff work through a troublesome tree before the rookie’s own number is up. If our tree were completely flake-free, we could rely on tools to keep things green, and we wouldn’t need sheriffs at all, or at least not in the same capacity that we need them today. Unfortunately, we’re not there yet. Until that problem is solved, we need the shades of gray between “the tree should be open” and “the tree should be closed” that a good sheriff’s human judgment provides. Mark -- 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] More sheriffs?
Peter Kasting wrote: On Fri, Nov 13, 2009 at 12:44 PM, Stuart Morgan stuartmor...@google.com wrote: If we end up actually having four at a time that seems likely to be worse than two: either four people are doing nothing but sheriffing, which there is probably not enough work for, or all four people are more likely to think that someone else is probably watching and they can do something else. I didn’t see Stuart’s original message, so I don’t know if there was more context, but I agree with what he’s saying here. In my experience, sheriffing is a one-person job, except we want that one person to be able to take a break or have lunch or have someone to fall back on when there are compound problems. I think it’s actually pretty rare for there to be more than three things wrong at a time, and usually when there are that many wrong, they didn’t all go bad simultaneously. It’s a one-person job, but it’s more than a full-time job, so we schedule two. Recently, there have been a few cases where people on the schedule couldn’t sheriff and didn’t arrange for a replacement. Things have gotten really bad when this happened, and for that reason alone, I’d support going to three. I also agree that going three months between shifts means that you might lose touch with how to do it effectively. Maybe we’ve got enough people now that we don’t need to sheriff for two days at a time. Maybe we can move from two sheriffs for two days to three for one. I’m not terribly motivated by any of the time zone policies, because I haven't seen this as a significant source of problems. Mark -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Circular relationship in NaCl .gyp files - this is bad!
Robert, try patching http://codereview.chromium.org/373002 into your copy of GYP and see if it raises an exception. Mark Robert Muth wrote: We do not want circular deps in our build system anyway, so having the hard error is desirable for us. I think I fixed the problem you complained about but there could be others. What is the best way for use to check this other than eyeballing. We will push a new nacl version into chrome later this week and I want to make sure it is clean. Robert On Thu, Nov 5, 2009 at 8:38 PM, Mark Mentovai mmento...@google.com wrote: Right. Xcode project objects are reference-counted, and when there's a circular relationship, their reference counts never drop to zero and thus can never be freed. When this happens, Xcode won't ever reload the affected project files; the state that they were in when the cycle was created will be the state that they're frozen in. It won't be able to read updates in from disk, and it will notice the discrepancy between what's in memory and what's on disk, try to save the project again, and fail. It's a mess. Xcode is perfectly happy to let you set up an arrangement like this, even in the absence of GYP. Command-Q wipes the slate clean, as Brad points out. This doesn't affect the buildbots because they don't run Xcode.app, they run xcodebuild, which results in a new process and a clean slate each time. Once the NaCl dependencies are cleaned up, I'll turn this into a hard error in GYP so it shouldn't affect us in the future. (This is the third time that it's bitten us, and the second in a month.) Mark Bradley Nelson wrote: Some further info on this topic: There are circular dependencies in nacl, but the reason this does not afflict the buildbots is that xcode will handle this correctly IF you CMD-Q out of xcode before regenerating the project file. We should nonetheless fix the circularity and then have gyp complain. -BradN On Thu, Nov 5, 2009 at 3:33 PM, Mark Mentovai mmento...@google.com wrote: Robert Muth wrote: I am looking into it. Thanks. I have a change for GYP ready to detect these cases and raise an exception. Once you get your fix in, I'll check my fix into GYP so that we can catch these early before they start causing problems. PS: Hope we will be sitting close to each other soon. Definitely! --~--~-~--~~~---~--~~ 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: Coping with configurations differences in sources
(m...@chromium.org, please - that's the address that I can post to mailing lists from.) There was a chromium-dev thread on this on Friday. http://groups.google.com/group/chromium-dev/browse_thread/thread/932a19ed777b9bb4 Between your two choices, I have a slight preference for option 1. Option 2, while it has an identical result, is confusing in that it results in .cc files that aren't used directly as compiler input. Putting them into a .gyp file's 'sources' section would then require custom excludes in 'sources!' or 'sources/' to keep the compiler from trying to crunch them. Mark Brad Nelson wrote: Hi Mark, So the nacl guys have a use case where they would be tempted to have per-configuration sources, if it were supported. Since this is particularly hairy for xcode, I wanted to see if you could offer some guidance as to how they should tackle this. Currently they are porting base + app to 64-bit for windows. They only need a limited subset of functionality for nacl, so they have only made some source files 64-bit clean. They would like to simply disable the rest for 64-bit (at least for now). With gyp's current limitations, they appear to have a limited set of option, all of which will affect others: 1. Surround each of the several dozen source files with #ifdefs gated on some 64-bit windows define. 2. Add app.cc, base.cc which #includes all the other .cc files, and gates them en-mass on some 64-bit windows define. 1 seems better to me, though a bit tedious. How would you suggest they proceed? --~--~-~--~~~---~--~~ 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: compile fails on Ubuntu 9.04
Paweł Hajdan Jr. wrote: scons: *** [/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o] Source `/home/ph/chromium/src/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.c' not found, needed by target `/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o'. scons: building terminated because of errors. That file, third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.c, should be part of the checkout. gclient should have brought it in via the DEPS entry for src/third_party/yasm/source/patched-yasm. If you don't have that file, start looking at how things were checked out, and maybe try a gclient sync --force. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Inheritance in gyp configurations
We've got the gypd (d = debug) sorta-generator format as an option,
alongside xcode, msvs, make, etc. It dumps the dicts it receives as
.gypd files next to your .gyp files, so you can see what would be fed
to a generator. You might need to feed it some -D because it's not
tied to an OS by default.
Albert J. Wong (王重傑) wrote:
On Sun, Nov 1, 2009 at 3:26 PM, Bradley Nelson bradnel...@google.com
wrote:
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.com
wrote:
configurations can now inherit from one or more other configurations,
and configurations which are not fully expressed should be marked
'abstract': 1,
So something like this:
'configurations': {
'Common: {
'abstract': 1,
# common settings
},
'Debug': {
'inherit_from': ['Common'],
# Debug specific
},
'Release': {
'inherit_from': ['Common'],
# Release specific
},
},
-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.com
wrote:
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] Re: Inheritance in gyp configurations
I'm sure that there are better examples than the below. Presumably if
you want something defined in both Debug and Release, you want it
globally, and you'd be better off specifying it outside of the
configuration altogether.
Brad, we can still inherit from non-abstract configurations, right?
This might be useful...
'configurations': {
'Release': {
# not abstract
},
'Valgrind': {
'inherit_from': ['Release'],
# Make stacks somewhat more friendly
'optimization': 1, # not a real keyword, just an example
},
},
Mark
Bradley Nelson wrote:
configurations can now inherit from one or more other configurations, and
configurations which are not fully expressed should be marked 'abstract': 1,
So something like this:
'configurations': {
'Common: {
'abstract': 1,
# common settings
},
'Debug': {
'inherit_from': ['Common'],
# Debug specific
},
'Release': {
'inherit_from': ['Common'],
# Release specific
},
},
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: BUILT_PRODUCTS_DIR: command not found build error on OS X
Oops.
http://codereview.chromium.org/353002
Nico Weber wrote:
Hi,
when building after syncing, I now get
/Users/thakis/src/chrome-git/src/chrome/../xcodebuild/chrome.build/Debug/chrome.build/Script-649B47660F26D59AE4D7EEA0.sh:
line 2: BUILT_PRODUCTS_DIR: command not found
every time. If you get this too, it can be fixed by going to
Targets-Chrome-Postbuild cleanup_theme_pak, double-clicking that,
and changing $(BUILT_PRODUCTS_DIR) to ${BUILT_PRODUCTS_DIR} (i.e.
change the parens to braces).
Nico
ps: This is probably caused by
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?view=diffr1=30643r2=30644
, which probably needs to look more like
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?view=diffr1=28870r2=28871
, so the Real Fix is some change to chrome.gyp.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Why is Linux Chrome so fast?
Darin Fisher wrote: I suspect this is at least one of the bigger issues. I also suspect that process creation is a problem on Windows. We should probably look into having a spare child process on Windows to minimize new tab jank. Maybe there is a bug on this already? This shouldn't be restricted to Windows, we should do it on all platforms. And we should start the first one as early as possible during the startup process. When I benchmarked this a few months ago on a fairly ordinary Mac, it took nearly 100ms from the time that the browser started a renderer to the time that the renderer was ready to service requests. A decent chunk of that is load time and pre-main initialization in system libraries. It's beyond our control, but there's no reason we can't make it happen sooner. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is Linux Chrome so fast?
Jens Alfke wrote: Unfortunately, it's nearly impossible to continue a forked process on OS X if it uses any higher-level (above POSIX) APIs. The main problem is that Mach ports can't be replicated across the fork, so if any ports were already open, they'll all be bogus in the new process. And all kinds of stuff in the OS is done via IPC across Mach ports, most significantly to the window server. Sure, we understand that. Why does that become a concern with pre-warmed renderers in a way that it's not with the renderers we're using now? My proposal is to fork a new process, exec the renderer, and then let it bring itself up. That's exactly how we start renderers now. The only difference is that I'm suggesting we should always keep a spare one warmed up and ready to go, and we should start the initial one sooner instead of waiting for something in the browser to say um, I'm gonna need a renderer. We can pretty much guarantee that we'll always need a renderer, let's give it a head start. I don't want to just pre-fork a process and have it sit around with its thumb up its Mach port. That wouldn't really gain us much on the Mac anyway, because our fork is relatively cheap. As I mentioned, the big losses that we experience in bringing up a new renderer process are in loading and initialization. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac renderer launch (Was: Why is Linux Chrome so fast?)
Jens Alfke wrote: How much would that increase memory use? (says the guy on the Memory task force...) I.e. what's the RPRVT of a warmed-up renderer process? Does it matter? At least for the startup case, that's a renderer we know we'll need anyway. You could use this argument to shoot down keeping a spare warmed-up renderer ready to go at other times, but I don't think it's relevant to the startup case. If bringing up the first renderer is CPU-bound, that would be a great idea. If it's disk-bound, then it could have a negative effect on launch time. Do we have profiles/samples of renderer launch, both warm and cold? I suspect that most (but not all) of the stuff that the renderer needs to read to warm itself up will already be in the buffer cache. The renderer shouldn't be doing much writing. But we could profile it. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: compile error on Snow Leopard
thakis r29990 (http://codereview.chromium.org/336001) -[NSString stringWithCString:] is deprecated as of Mac OS X 10.4. The replacement is -[NSString stringWithCString:encoding:]. We also have base::SysUTF8ToNSString from base/sys_string_conversions.h. Mark Paweł Hajdan Jr. wrote: I get this when compiling unit_tests on Mac OS X 10.6 Snow Leopard: /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689:0 /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689: warning: 'stringWithCString:' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:364) And warnings are treated as errors so it breaks the build. Mac OS X build is healthy on the buildbot, so it's either something on my machine, or the GCC in Snow Leopard has more warnings. Is there some easy workaround? I don't know what's the correct fix for 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: compile error on Snow Leopard
Nico Weber wrote: Is SL a supported platform for building? Certainly. If so, should we have an SL buildbot? Yes, but Tom and I have other priorities right now. We should have 10.6 bots running next month. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: External protocol dialog checkbox
Evan Stade wrote: There's a checkbox in the external protocol dialog with the text Remember my choice for all links of this type. (On windows and linux, this is not actually implemented, but there are bugs out to fix that) The options are then Cancel and Launch Application. The conflict here is that in general Cancel is supposed to not do anything, hence it can't honor the Remember my choice for all links of this type option. So that checkbox should either be renamed Always allow this protocol, and not allow the user to always block that protocol, or the cancel button should be renamed to don't launch app or equivalent. I agree with this 100%. When Avi implemented this dialog on the Mac, I was really mean about it and I wouldn't let him make the remember checkbox actually remember anything as long as the button's text remained Cancel. The button label should change to Don't Launch or something along those lines. Leaving it at Cancel is ambiguous. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Mac] Chromium terminates when running from Terminal
Mikhail Naganov wrote: Also answering on Mark's question. $ pwd /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS [...] $ ./Chromium this way, it fails OK, I know what's happening here. Having a dot after MacOS in the path to the executable is what breaks things. I usually sit in the Release directory and start Chromium as: $ Chromium.app/Contents/MacOS/Chromium Here is the value of 'path' when running from Terminal: /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/./Chromium There's the dot I'm talking about. When I run it under gdb, the path is printed two times: /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/Chromium /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/Versions/4.0.223.1/Chromium Helper.app/Contents/MacOS/Chromium Helper Right, once from the browser process (the one we care about) and once from the first renderer (which never gets a chance to start up when you have the dot in an unexpected spot). If you had tried a debug build, you would have seen output like this: [mmdd/hhmmss:FATAL:/chrome/trunk/src/base/mac_util.mm(80)] Check failed: bundle. failed to load the bundle: .../Debug/Chromium.app/Contents/MacOS/Versions/4.0.223.2/Chromium Framework.framework The framework should be at Chromium.app/Contents/Versions/4.0.223.2. The code that builds the path to the framework is not expecting a dot after MacOS in the pathname, it's just stripping a fixed number of components (2) off of the executable's pathname, expecting it to be .../Contents/MacOS/Chromium. You can use don't put dots there as a workaround in the mean time, and I'll cook up something to fix this in the code. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Mac] Chromium terminates when running from Terminal
Evan Martin wrote: On Mon, Oct 19, 2009 at 7:43 AM, Mark Mentovai m...@chromium.org wrote: If you had tried a debug build, you would have seen output like this: [mmdd/hhmmss:FATAL:/chrome/trunk/src/base/mac_util.mm(80)] Check failed: bundle. failed to load the bundle: .../Debug/Chromium.app/Contents/MacOS/Versions/4.0.223.2/Chromium Framework.framework Should this be a CHECK instead? Yup, I'll fix. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Who's sheriff?
Today on the waterfall, I see: Sheriffs: munjal From past experience, one sheriff really isn't enough. Munjal should be able to take a lunch break. Also, I think that this will be his first stint as sheriff. It would probably help him out if he had a co-sheriff who had done it at least once before. (Munjal, apologies if you've done it before and I missed it - in that case, maybe we can get you a rookie co-sheriff so you can be the mentor.) Who's sheriff? What do we do in cases where a sheriff declines or goes on vacation without swapping with someone else? Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Mac] Chromium terminates when running from Terminal
How are you launching it from the Terminal? Can you tell me the exact invocation? $PATH and working directory too? Can you log the value of path after PathService::Get(base::FILE_EXE, path) in chrome::GetVersionedDirectory(), chrome/common/chrome_paths_mac.mm:72? Mark Mikhail Naganov wrote: Hi all, Starting from today, I can't run Chromium from Terminal, unless I'm running it under gdb. I'm getting the following bunch of error messages (on a Release build): 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in -[BrowserWindowController initWithWindowNibPath:owner:], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was raised 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not satisfying: windowNibPath 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: windowNibPath' 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( 2417545195, 2485780027, 2417544651, 2463723204, 2433132475, 36896176, 36889665, 36840062, 36542144, 36543780, 36611717, 36618850, 36622599, 36646971, 35731773 ) Trace/BPT trap If I launch Chromium from Finder, XCode, or under gdb in Terminal, it works fine. I've done a clean rebuild of Chromium, and I'm seeing this behavior on two machines. Does anyone have a similar problem, or maybe have a clue what goes wrong? --~--~-~--~~~---~--~~ 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
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] Re: [mac] Chromium Helper + ffmpeg binary location == no video
Albert J. Wong wrote: What is @loader_path relative off of? @loader_path is the directory that contains whatever is being loaded. While loading the main executable, @loader_path is equivalent to @executable_path. If your three dylibs refer to one another and are always in the same directory, they can refer to one another by @loader_path/libwhatever.dylib. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
If anyone want to work on this, we've left some breadcrumbs behind by declaring libraries that could be built as either static or shared as a GYP variable named library_type. It expands to static_library by default, but the intention was to make it easy to switch to a shared library build by flipping it to shared_library. I'm sure there's a bunch of work to be done even with that switch flipped, but it might be a good start if anyone's interested. Mark Evan Martin wrote: On Fri, Oct 2, 2009 at 8:26 AM, Marc-Antoine Ruel mar...@chromium.org wrote: is linking. To give you an idea, here's a truncated dir list: (...) 10,223,616 dump_cache.exe 10,309,632 fetch_client.exe 10,600,448 net_perftests.exe 12,406,784 sync_unit_tests.exe 14,966,784 net_unittests.exe 22,118,400 mini_installer.exe 55,029,760 tab_switching_test.exe Does anyone (not necessarily you :P) have building a web of .dlls in their plans? I've seen a number of patches from mmoss to get that working on Linux with the intent of using it on buildbots... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI, project cruft
Nick Carter wrote: The pollution obscures the actual dependency structure. One man's pollution is another's...? Seriously, we do this because the typical pattern is to say anyone that depends on this library needs to use these include directories or have these macros defined. With 120 or so targets, maintaining these settings on the consumers (dependents) instead of the dependencies is a huge loser. These are settings that belong on the dependency target. The GYP model was designed to track the use of using_*.vsprops files that we used to use in the MSVS-based build. A transitive version of 'direct_dependent_settings' that works on indirect dependencies might improve the situation. We do have a way to do that, but it's actually almost never what anyone wants. In the early days of GYP, I spent a lot of time barking at people who tried to abuse the transitive form. In almost all cases, what you really want actually is direct_dependent_settings or link_settings, or in special cases, direct_dependent_settings + export_dependent_settings. Brad covered these in detail in his response 7 minutes ago, so I'm not going to repeat what he said. He also used some CAPITAL LETTERS in his post, so I don't need to bark this time either. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI, project cruft
Nick Carter wrote: I've been assuming that a 'dependencies' entry between two targets implies the serialization of their build order, and a missed opportunity for build parallelization. That's not true. If a static library depends on another static library (the common case among our targets), no direct build order relationship is created. Instead, the build order relationship is pushed to concrete linkable dependents, such as executables, shared libraries, and loadable modules. In order to force a static library dependency to behave in the way that you suggest, it would need to have the 'hard_dependency' property set. Most don't because this would be inappropriate. In other words, we've already solved the parallelization problem you're trying to solve. :) Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Pasteboards and the mac valgrind builder
Yes, I was poking this a little bit last week, and a little bit the week before. It seems that under Valgrind, tests involving the pasteboard, and maybe a couple of other things too, will always fail. In some cases, the test failures result in certain things not being cleaned up, which in turn results in something that Valgrind detects as a leak at the end of the run. I tried to fix some of these so that at least the tests always clean up after themselves, but was only partially successful. The underlying issue here is that the tests are failing, but only under Valgrind. Nico Weber wrote: [--] Global test environment tear-down [==] 981 tests from 219 test cases ran. (908043 ms total) [ PASSED ] 978 tests. [ FAILED ] 3 tests, listed below: [ FAILED ] AutocompleteTextFieldEditorTest.CutCopyTest [ FAILED ] BookmarkEditorControllerTest.UserEditsStuff [ FAILED ] DownloadUtilTest.AddFileToPasteboardTest However, the tests work fine on the other bots and locally, they only fail on the valgrind builder. Which is however still green. The Valgrind test step doesn't turn red for test failures, only for unsuppressed leaks. I wanted to ask dank about that last week, but he wasn't around when it initially upset me, so I moved on. Let's ask him now. dank? Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Without SSe2
Is there a reason we gate this on branding? The comment doesn't speak
to that at all.
Evan Martin wrote:
The code doesn't lie:
'conditions': [
['branding==Chromium', {
'cflags': [
'-march=pentium4',
'-msse2',
'-mfpmath=sse',
],
}],
],
--~--~-~--~~~---~--~~
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 Without SSe2
Dan Kegel wrote: It's so our tests pass, I think. We don't have tests for nothing. If a test exposes a case where something requires 53/64-bit IEEE double precision as opposed to 64/80-bit double extended, and we're changing our configuration to make tests pass but then releasing in another configuration where those same tests wouldn't pass, we're doing something wrong. Using SSE2 floating-point operations in a configuration that we test and then using x87 floating-point operations in a configuration that we release is completely bogus. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Without SSe2
Adam Langley wrote: * x87 doubles are 80-bits in registers and 64-bits in memory. Depending on the state of the x87 floating point control word. Can bracket significant test-impacting floating point operations with fldcw or do something else in that code to force spills to memory? I'm aware of the performance implication of mucking with the floating point control register on older CPUs. I'm also aware that some GNU libm functions assume that the x87 is set to 64/80-bit precision. Maybe we care, maybe we don't. Maybe we can just set the register to 53/64-bit precision on renderer threads and leave it that way. If we can't require SSE2 as a baseline on Linux, and I'd agree that we can't, then it seems that we should find a way to do the right things within the confines of the x87 instruction set. Is the issue simply test results are different due to rounding, or are there actually cases where a spec requires that we do floating-point operations in a certain mode? (I know that the JS and XSL or XPath specs fall into the latter bucket.) Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Problem with gyp every time v8 updates their branch
This happened after a GYP change that Brad made recently (last week, I think). We need to add to v8's svn:ignore. John Abd-El-Malek wrote: Every time v8 team updates which branch is the one that's used in Chrome, gclient sync fails on Windows. The error is below. running 'svn update a:\chrome2\src\tools\tryserver' in 'a:\chrome2' At revision 3275. Error: Can't switch the checkout to http://v8.googlecode.com/svn/tr...@2966; UUID don't match and there is local changes in a:\chrome2\src\v8. Delete the direct ory and try again. a:\chrome2\src\v8svn st ? tools\gyp\v8.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\js2c.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_nosnapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_snapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_shell.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_base.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\mksnapshot.vcproj.GOOGLE.jabdelmalek.user I have to delete the v8 directory and run gclient sync again (or remove the generated files). This is annoying, since it breaks syncing to all the Windows developers (I don't think this happens on Mac and Linux). Can the generated files be put elsewhere? Or is there a way that gyp can tell svn to ignore .user files? I realize I could put it in my svn config file, but this doesn't solve it for all the other developers. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Problem with gyp every time v8 updates their branch
John Abd-El-Malek wrote: I've seen this before last week as well. OK, then there might be something else going on. When it happened in the past, what did svn status show? I've never seen this, by the way. (Any time I make changes to V8, I don't do it in a Chromium working copy.) Can this really be added to v8's svn:ignore? These VS generated files have the username in them. Yeah, they're patterns. You can svn:ignore *.vcproj.*.user Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: svn --depth not recognized?
Drew Wilson wrote: I'm trying to do a gcl try on my mac, but getting this error: svn checkout --depth empty svn://svn.chromium.org/chrome-try/try /var/folders/zz/zzzivhrRnAmviuee++2D3++-1lE/-Tmp-/tmpMRXSrL --username atwil...@google.com Ouput: svn: invalid option: --depth Type 'svn help' for usage. Sorry, Tryserver is not available. My macbook comes with SVN 1.4.4 - do we require a newer version (I didn't see anything about that on dev.chromium.org). I've been able to do gcl try in the past with no problems, so I'm not sure what's suddenly going wrong now... Any tips for me? I'd prefer not to upgrade SVN unless I know it's necessary, since I don't know if/how it'd affect my webkit development. Apparently, gcl try over svn requires svn 1.5. gcl try also works over http. In fact, I think http is the default - but only if you can see the try http server. You may not be able to. The try svn server is more accessible. According to gcl help try, --use_http, --host, --port, and --proxy can be used to control access over HTTP. We don't require svn 1.5 in most cases, we want our tools to be compatible with the svn that most people are using, which on Leopard systems is 1.4. I'm not sure if it would be easy to make try server svn access work without --depth. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac Chrome launch speed = the awesome
On behalf of the Mac folks, you're quite welcome! Mark Adam Barth wrote: Thanks for making Mac Chrome launch ridiculously fast. I really enjoy that, on my laptop, the main window is painted before the dock icon has even crested its first bounce. --~--~-~--~~~---~--~~ 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 pixel tests: Why rebaselining is the only real option
Avi Drissman wrote: Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa sizes scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a viewsize value related to the physical size of the scrollbar. The precise formula Cocoa uses to turn the view size into its proportion value is unknown and would either have to be coaxed out of Apple or reverse-engineered. But even if you could fix both of these screws, you'd have to deal with... This all sounds reasonable to me. I'd still like to know a little bit more about screw #2 because it seems like something that we should understand a bit better before we decide to establish our own baselines for these tests. I wonder what happens when the viewsize or one of the other parameters is changed by ±15. Maybe Cocoa is accounting for the other scrollbar's presence or absence differently. 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] Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
I spent a chunk of last week looking at the new tab page performance on startup on the Mac. I found that the renderer was waiting on data from the browser process for what seemed like far too long. The key to this problem is that resource requests for the new tab page are funneled through the browser process' main (UI) thread. At least on the Mac, when a new tab is being created or while the application is starting up, there's a lot of contention for the UI thread: the window is being drawn and there might be animations or other effects, not to mention that infernal throbber. The good news is that turning off the tab strip's Core Animation layer improves this, as well as many other things. A patch to do this just landed again at r24881 (on the third try). In my experiments, this reduced the time from when the renderer requests the new tab page to the time that all of the resources are present in the renderer from between 1-3 seconds to just a hair over 300ms. This is a huge improvement. I still think that 300ms is too long, though, especially when you consider that this is not the time from launch, but the time from the renderer's request, which itself can come as much as 300ms after launch. I'm experimenting with a change that lets the new tab HTML and CSS be served directly from the browser's IO thread instead of the UI thread. Since these tasks require profile and theme access, the approach is to build up the HTML and CSS early, on the UI thread where such access is permitted, and cache them. When a request for the HTML or CSS comes in, the browser can then service them entirely on the IO thread. This gets the data into the renderer almost immediately after it's requested, so that the renderer is able to fully lay out the new tab page without having to wait for the browser to do things like draw the new tab. Additional resource requests, such as thumbnails and favicons, are still being served from the UI thread. Based on my experiments, this shouldn't be a problem: the renderer isn't ready to receive these until it's done with layout based on the HTML and CSS, and once it reaches that point, the browser should be done with heavy UI tasks and there shouldn't be much contention for its main loop. It might ultimately be better to be able to serve all new tab requests from a non-UI thread in the browser, but that could mean additional caching. This change improves new tab page performance by about 65ms on my laptop in release mode. Now we're down to 240. Great. What else can we do? Well, that annoying throbber is still chewing up time, causing some amount of UI loop contention while the images, thumbnails, and icons are fetched. Windows and Linux don't have a throbber for the new tab page. We shouldn't either. Excellent, now we're down to 200ms. It's still high, but it's reasonable. It's a perceptible improvement from the 300ms we started with. What else can we do? One thing that's begging for improvement based on my timings is the renderer startup delay. We don't bother starting up a renderer until about 200ms after launch, and it takes the renderer 70ms from that point to reach its main loop. I bet that if we did renderer startup much earlier, we'd have one warm and ready to go by the time we needed it. This doesn't have to be startup-specific, we could always maintain a spare renderer in the pool (within reason) so that we're not caught twiddling our thumbs waiting for the one we just launched. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
Amanda Walker wrote: Great writeup. There's definitely too much going on in the UI thread. Even after the page paints, I'm seeing multi-second pauses while additional stuff comes in, where the browser process is unresponsive (example: iGoogle with a bunch of gadgets). It's not clear to me why any http resource loading is on the main thread at all... HTTP resource loading shouldn't be on the browser's main thread. This only applies to DOM UI resource loading, chrome: and chrome-internal:. That stuff gets funneled through the browser's main thread for things like profile and theme access. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
Evan Martin wrote: This cache is in-memory only, right? That is, it's generated during startup? (In the past I've talked about caches but I'm worried that the NTP positioning will jump around due to stale caches, since the site ranking is based on day granularity. Though that could be considered a design flaw.) Right now, I'm hanging a new method on NewTabHTMLSource to generate the data and store it in a member. I'm calling that from the NTHS constructor, and I'm doing the same thing for the CSS in DOMUIThemeSource. It seems that each occurrence of the New Tab Page gets its own NewTabHTMLSource and DOMUIThemeSource objects, so the cache should be scoped to a single instance of a New Tab Page. I haven't experimented with Reload or tried other things that might abuse the cache. Another option is for the browser push these resources into the NTP as it's being constructed. That is, textually append a script tag with the JSON blob of the NTP data at the bottom of the NTP HTML. That's how our translation templating works and it skips all the back-and-forth of requests. Yup, that would cover it too. Thanks for the suggestion. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
Andrew Scherkus wrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? According to style guide it needs to be fully justified, but it'd be nice to use DCHECK_xx/EXEPCT_xx/ASSERT_xx with TimeDeltas. I think this is fine. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
Ben Laurie wrote: The observation is that many places that are currently: #if defined(OS_LINUX) are going to become: #if defined(OS_LINUX) || defined(OS_FREEBSD) and this is ugly. I think that these would generally be proper as defined(OS_POSIX) !defined(OS_MACOSX). If people think that's ugly, maybe we need a new macro that means the same thing. Maybe OS_UNIXISH. OS_MACOSX should not come out of OS_POSIX. Mac OS X is of course Unixish but I'm having a hard time coming up with a better macro name for what's being proposed here other than OS_POSIX_NOT_MACOSX. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac Debug is hosed, needs an owner
I've tracked this down to WebKit r47270, which we picked up in our merge at r23446. It looks like there's a fix for our specific case upstream at r47333, but I believe that function still contains bugs. I'm going to talk to Simon, the author of the relevant WebKit patches, about that. I can own this if I can have the WebKit sheriff's assistance. The easiest thing to do here is probably to move up to r47333 or higher of WebKit, but the canary shows that will bring us some test failures. Mark Mike Pinkerton wrote: Over the weekend, we developed an assert loading any page, even the NTP ASSERTION FAILED: m_clients.contains(renderer) (/Users/pinkerton/src/chromium/src/webkit/../third_party/WebKit/WebCore/css/CSSGradientValue.cpp:109 virtual WebCore::Image* WebCore::CSSGradientValue::image(WebCore::RenderObject*, const WebCore::IntSize)) Discussions in IRC this morning have linked it to WebKit merge r23527. This appears to only hit Mac debug, but it makes it impossible to do any work with a trunk debug build. I think we should hold the tree closed until we can get this resolved. --~--~-~--~~~---~--~~ 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 Debug is hosed, needs an owner
This should be fixed at our r23546. Mark I wrote: I've tracked this down to WebKit r47270, which we picked up in our merge at r23446. It looks like there's a fix for our specific case upstream at r47333, but I believe that function still contains bugs. I'm going to talk to Simon, the author of the relevant WebKit patches, about that. I can own this if I can have the WebKit sheriff's assistance. The easiest thing to do here is probably to move up to r47333 or higher of WebKit, but the canary shows that will bring us some test failures. Mark Mike Pinkerton wrote: Over the weekend, we developed an assert loading any page, even the NTP ASSERTION FAILED: m_clients.contains(renderer) (/Users/pinkerton/src/chromium/src/webkit/../third_party/WebKit/WebCore/css/CSSGradientValue.cpp:109 virtual WebCore::Image* WebCore::CSSGradientValue::image(WebCore::RenderObject*, const WebCore::IntSize)) Discussions in IRC this morning have linked it to WebKit merge r23527. This appears to only hit Mac debug, but it makes it impossible to do any work with a trunk debug build. I think we should hold the tree closed until we can get this resolved. --~--~-~--~~~---~--~~ 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
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. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: tryserver flakiness
I don't think so. It looks like VS doesn't rebuild files when the compiler invocation to build them would change. Michael added a new macro definition on the command line. If that's the case, this would be a VS problem (I'd call it a bug), and I'm not sure how easy it would be to work around in GYP. Jeremy Orlow wrote: Brad, looks like we might have another dependency bug in GYP? J On Wed, Aug 12, 2009 at 1:57 PM, Michael Nordman micha...@google.com wrote: I just submitted the change that ENABLE's that flag a moment ago... we're clobbering things now On Wed, Aug 12, 2009 at 1:55 PM, Jeremy Orlow jor...@google.com wrote: Clobber needed? I know Michael just enabled this within the last 24 hours. On Wed, Aug 12, 2009 at 1:49 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just got this on the Windows tryserver: C:\b\slave\win\build\src\chrome\renderer\renderer_webkitclient_impl.cc : error C2220: warning treated as error - no 'object' file generated C:\b\slave\win\build\src\chrome\renderer\renderer_webkitclient_impl.cc : warning C4651: '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for precompiled header but not for current compile render_thread.cc C:\b\slave\win\build\src\chrome\renderer\render_thread.cc : error C2220: warning treated as error - no 'object' file generated C:\b\slave\win\build\src\chrome\renderer\render_thread.cc : warning C4651: '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for precompiled header but not for current compile renderer_glue.cc C:\b\slave\win\build\src\chrome\renderer\renderer_glue.cc : error C2220: warning treated as error - no 'object' file generated C:\b\slave\win\build\src\chrome\renderer\renderer_glue.cc : warning C4651: '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for precompiled header but not for current compile It's a bit annoying... Is it easily fixable? --~--~-~--~~~---~--~~ 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: Clobbering
Dimitri Glazkov wrote: The culprit here was the change to the CodeGeneratorV8.pm. It looks like we should somehow trigger clobber of of rule_binding.py when that happens. We already do. In the .idl rule in webkit.gyp, we have: 'inputs': [ '../third_party/WebKit/WebCore/bindings/scripts/generate-bindings.pl', '../third_party/WebKit/WebCore/bindings/scripts/CodeGenerator.pm', '../third_party/WebKit/WebCore/bindings/scripts/CodeGeneratorV8.pm', '../third_party/WebKit/WebCore/bindings/scripts/IDLParser.pm', '../third_party/WebKit/WebCore/bindings/scripts/IDLStructure.pm', ], meaning that if any of those files changes, or an .idl file changes, we'll run generate-bindings.pl again. 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] Debugging Mac Chrome in release mode
I just checked in r22506, which alters the structure of the application on disk on the Mac slightly. The entire program has moved into a dylib (framework) that lives within the app bundle, and the main executable is now a tiny stub that doesn't do anything but jump to the entry point in the dylib. I've got more related changes in the oven, but that's another story... The only noticeable change now from a development perspective is that gdb won't be able to find debugging symbols for the dylib when you're working in release mode. gdb looks for a dSYM bundle next to the framework, but we don't copy the dSYM into the app bundle (because we don't want it there). In case you need to debug a release-mode bundle, you'll need to place a symlink: cd xcodebuild ln -fs ../../../Chromium\ Framework.framework.dSYM Release/Chromium.app/Contents/Frameworks/ Then, when you debug Chromium.app: gdb Release/Chromium.app it will be able to load the framework's debugging symbols. I haven't used the Xcode debugger in a while, but the same symlink should work to get you on track there as well, since the Xcode debugger is just a gdb front-end. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
Evan Martin wrote: When we load a plugin any symbols we export come before its symbols. This doesn't happen on the Mac unless you go out of your way to arrange for it to happen. Even so, we do use -fvisiblility=hidden for all Mac builds, because I like for these things to be well-trimmed anyway. The -fvisibility=hidden flag is maybe supposed to do this (see discussion on http://gcc.gnu.org/wiki/Visibility ), but I tried building both with and without it and found that: - in debug builds, objdump -T shows all of our symbols, regardless of the flags I pass to gcc or strip - in release builds, objdump -T doesn't show us exporting symbols, regardless of the flags I pass to gcc The resulting release binaries are within 1kb of each other. I don't really know what I'm doing, so my guess is that some other compilation flags we're using already produce the intended effect. Clearly this flag does *something* as the resulting binaries have slightly different sizes, but maybe it's not intended to apply to binaries or maybe it doesn't in my gcc (4.2.4). In order for any of this to apply to executables (as opposed to static libraries), you need to be linking with ld -E. Otherwise, global symbols that wind up in the executable don't get exported via the dynamic symbol table. I don't know how you guys are linking, but this can be significant here. This -E business applies to Linux/ELF. On the Mac, things work a little differently: there's only one symbol table, symbols wind up in it pretty much identically whether you're linking an executable or a library, and as I mentioned above, the runtime loader does a better job of resolving undefined symbols to the same libraries that provided them at link time. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: CMake for chromium
pjwaffle wrote: Why don't we use CMake for chromium's build system? It would ease the pain on for example xcode or kdevelop users. Because we have GYP, which eases the pain on Xcode, Visual Studio, SCons, and make users. We developed GYP specifically to meet Chromium's needs. We did consider CMake and even did some prototypes with it, but there were several areas where it wasn't able to meet our needs squarely. More on GYP: http://groups.google.com/group/chromium-dev/browse_thread/thread/7b881a18437fa320/ . Also, a recent thread on webkit-dev about GYP, WebKit, and Chromium touched on CMake: https://lists.webkit.org/pipermail/webkit-dev/2009-July/008881.html . I think i'll work on studying the current build system to figure out how to implement a CMake one. That's fine. Let us (including me) know what you come up with. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
(Third try to send this to the list, and then I'm giving up. They keep bouncing.) Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). Mark Dan Kegel wrote: Hi Mark, I'm interested in cleaning up how we invoke gyp when building for use with valgrind. Right now it's a bit of a hodgepodge, and it'd be nice if we could use the variant method you introduced here http://codereview.chromium.org/115922 and discussed on the list http://www.mail-archive.com/chromium-dev@googlegroups.com/msg03185.html Is there doc for this yet? I can't see how to invoke variants from the commandline, and gyp --help doesn't mention variants. The syntax mentioned in the mailing list, gclient runhooks --force -Dcoverage=1 fails with gclient.py: error: no such option: -D Also, will the makefile generator need to be modified to support variants? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
I don't think I've seen it. Is it gonna work on the Mac? Evan Martin wrote: On Fri, Jul 17, 2009 at 7:38 PM, Mark Mentovaim...@chromium.org wrote: Dan, variants aren't implemented for non-scons builds yet. There's a plan in place, but it'll happen after loops are added (which should be next week). What do we need loops for? mmoss has a patch for the locale files that just uses an action, which seems preferable to me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp variants?
Michael Moss wrote: I agree. I thought we wanted to avoid that kind of bloat, which is why I went the helper script route instead of pestering for loops. If we add too many features, pretty soon we'll just have scons-NG (not that there's anything wrong with that, but I don't understand that to be the goal of gyp). It's not, but loops weren't supposed to be too ridiculous. I'll reserve further judgment until I've digested what you've come up with for localizations. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: [webkit-dev] Please welcome GYP to the our dysfunctional build family
Ben Goodger (Google) wrote: Specifically, there were reasons why GYP was created instead of just using CMake. Mark Mentovai should comment. I'm not on webkit-dev, but I was on the cc list for that thread. I'm unwinding from the weekend now, but I'll subscribe and post a response later tonight or tomorrow. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: help with gyp?
You probably want 'actions' - these run at compile time. You can find examples of these all over our tree. Mark Mike Mammarella wrote: Hi all, I'm trying to add a file which needs to be processed autoconf-style at compile time. It's a script with things like @@FOO@@ that are values known at the time gyp runs, but which should actually be substituted during the compile when the .in version of the script is processed and written to the output directory. (This is only for the Linux port.) It looks like the !() feature will only run a command when gyp runs, not when the build system later runs, so using that would mean that changes to the .in file would not be taken up unless gyp is rerun. For files that don't need this processing, I could use the copies facility in gyp, but I can't figure out how to tell it to process the file (e.g. with sed -e 's/@@FOO@@/(FOO)/g' or something) when the build system runs. Anyone know how to do this? Thanks, --Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Buildbot Mac compiles are now being assisted by Linux
Since yesterday, all of the Mac builds in BigHouse (including main Buildbot builds and tryserver builds) have been supported by an extra set of distccd servers running on nearby Linux systems. The only impact should be that builds should be faster now, since there are more CPUs available to do Mac compilations. I've been running this same setup locally for a couple of months and don't anticipate any problems, but if you notice anything suspicious, please let me know. I'll be monitoring the builds to make sure that everything's going smoothly. (Yes, this is distcc pump mode. We've actually been using pump mode on the Macs for about a month, but they were only distributing to other Macs.) Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2000 errors building WebCore bindings!
= needs to be quoted if it occurs in the first word passed to the
shell (or, if the first word was a variable assignment, the second
word, and so on). EncodePOSIXShellArgument doesn't know or care
whether it's working with the first word or a subsequent one.
I'm pretty much convinced that whatever is going on here ought to be
dealt with in webkit/build/rule_binding.py.
Mark
Ben Laurie wrote:
On Mon, Jul 6, 2009 at 3:43 PM, Dimitri Glazkovdglaz...@google.com wrote:
Apply this locally, if you want to get rid of them:
diff --git a/WebCore/bindings/scripts/IDLParser.pm
b/WebCore/bindings/scripts/IDLParser.pm
index c4cb041..0a6832f 100644
--- a/WebCore/bindings/scripts/IDLParser.pm
+++ b/WebCore/bindings/scripts/IDLParser.pm
@@ -75,7 +75,7 @@ sub Parse
print | *** Starting to parse $fileName...\n |\n unless $beQuiet;
- open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map { -D$_
} split(' ', $defines)), $
+ open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map {
s///g; -D$_ } split(' ', $defi
close PP_IN;
my @documentContent = PP_OUT;
close PP_OUT;
Unfortunately, this is probably not the proper fix -- it deals with
the symptom, not the cause.
The cause is gyp.common.EncodePOSIXShellArgument, which thinks the
presence of an '=' means the argument needs to be quoted. I am less
than convinced this is really true, no matter what POSIX says :-)
:DG
On Mon, Jul 6, 2009 at 7:29 AM, Evan Martine...@chromium.org wrote:
http://code.google.com/p/chromium/issues/detail?id=15904
Something went wrong with quoting when some v8-related script was
upstreamed. Dimitri's working on it.
On Mon, Jul 6, 2009 at 7:18 AM, Mike Pinkertonpinker...@chromium.org
wrote:
When I try to build today, I get 2000 errors of the form:
command line:1:1: error: macro names must be identifiers
when building WebCore bindings. Others have complained of similar
errors on Linux. What's going on here? Reports are that it seems to
still build correctly, but this really throws XCode for a loop.
This was introduced at r19816.
--
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: 2000 errors building WebCore bindings!
I can help you out this afternoon if necessary.
Dimitri Glazkov wrote:
I agree -- if weren't such a Python n00b I'd already have a patch. I
am looking through it now
:DG
On Mon, Jul 6, 2009 at 8:19 AM, Mark Mentovaim...@chromium.org wrote:
= needs to be quoted if it occurs in the first word passed to the
shell (or, if the first word was a variable assignment, the second
word, and so on). EncodePOSIXShellArgument doesn't know or care
whether it's working with the first word or a subsequent one.
I'm pretty much convinced that whatever is going on here ought to be
dealt with in webkit/build/rule_binding.py.
Mark
Ben Laurie wrote:
On Mon, Jul 6, 2009 at 3:43 PM, Dimitri Glazkovdglaz...@google.com wrote:
Apply this locally, if you want to get rid of them:
diff --git a/WebCore/bindings/scripts/IDLParser.pm
b/WebCore/bindings/scripts/IDLParser.pm
index c4cb041..0a6832f 100644
--- a/WebCore/bindings/scripts/IDLParser.pm
+++ b/WebCore/bindings/scripts/IDLParser.pm
@@ -75,7 +75,7 @@ sub Parse
print | *** Starting to parse $fileName...\n |\n unless $beQuiet;
- open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map { -D$_
} split(' ', $defines)), $
+ open2(\*PP_OUT, \*PP_IN, split(' ', $preprocessor), (map {
s///g; -D$_ } split(' ', $defi
close PP_IN;
my @documentContent = PP_OUT;
close PP_OUT;
Unfortunately, this is probably not the proper fix -- it deals with
the symptom, not the cause.
The cause is gyp.common.EncodePOSIXShellArgument, which thinks the
presence of an '=' means the argument needs to be quoted. I am less
than convinced this is really true, no matter what POSIX says :-)
:DG
On Mon, Jul 6, 2009 at 7:29 AM, Evan Martine...@chromium.org wrote:
http://code.google.com/p/chromium/issues/detail?id=15904
Something went wrong with quoting when some v8-related script was
upstreamed. Dimitri's working on it.
On Mon, Jul 6, 2009 at 7:18 AM, Mike Pinkertonpinker...@chromium.org
wrote:
When I try to build today, I get 2000 errors of the form:
command line:1:1: error: macro names must be identifiers
when building WebCore bindings. Others have complained of similar
errors on Linux. What's going on here? Reports are that it seems to
still build correctly, but this really throws XCode for a loop.
This was introduced at r19816.
--
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] Developing Chromium Mac? Try using it as your primary browser!
Sometimes, it's hard to work on a product and actually use it at the same time. The rapid stop/start cycles aren't exactly conducive to keeping long-lived activities like your e-mail open. I work on Chromium, but I surf in Camino, or Safari, or Firefox. Does that sound familiar? I've worked on other browsers in the past, and I've had the same problems with them too. Fortunately, Chromium supports multiple user profiles, so it actually is possible to leave a long-lived process around for your daily surfing hooked up to one profile, while you're developing in another. For the past couple of days, I've been trying this out, and I think it would be a good idea if everyone else who's not already doing so gave it a try too. Here's what I'm doing: I'm starting my long-lived Chrome (in my case, an official Google Chrome dev-channel build - ideally it shouldn't be the executable/bundle you're actively working on) with an alternate profile by telling my shell to do this: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=~/Library/Application\ Support/ChromeToo chrome.out leaving the main profile at ~/Library/Application Support/Chrome free for development. (You could easily do it the other way around, but since I'm more likely to want to start the development Chromium more frequently, I figure I'll save myself some keystrokes.) So far, the biggest drawback has been no YouTube, but I bet you knew that already. I think it would be a great idea for everyone developing for the Mac to join me in eating our dogfood. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
If you've got a file that begins its life as something on-disk, and
you just need to carry the path to it around, then that's fine, it
should live its life as a FilePath.
If you've got to create a file using some name where the name is some
constant in code, use FilePath with ASCII constants. AppendASCII
exists to stick new ASCII components onto existing FilePaths. This is
fine and is considered safe because ASCII is a subset of any rational
filesystem encoding.
If you've got to take an arbitrary FilePath and convert it for display
to the user, or take an arbitrary string in a known encoding and
re-encode it for the filesystem, then we don't have anything in
FilePath for this. I believe that if we do add something, it should
strictly operate only on single pathname components at a time, and not
entire pathnames. We could add it to FilePath or we could add it
somewhere else, because it is sort of distinct from what FilePath is
really supposed to be, which is just a container for ferrying around
native paths.
It's also a specification and implementation nightmare. Everyone has
a different idea of what normalization means. What's your idea?
Yes, I know it's a nightmare all around, but I think it would be useful to
have something that addresses this. My idea would be the same as Python's
os.path.normpath, mainly because it's a well-tested, seasoned example with
test cases. Windows also has a routine for this (PathCanonicalize) that
could be used (but I know it doesn't work for UNC paths).
Why would it be useful? Do you want to compare paths for equality?
Then we should have an API that compares paths for equality. It would
have to hit the disk to do so. You might need general-purpose
canonization to implement that on some systems. Great, you need to
hit the disk to do that too. It's fine if you want these things, but
we can't put them into FilePath. It's important that FilePath remain
lightweight and not make any system calls, because system calls can
block and FilePath is just a data carrier.
os.path.normpath is known to be buggy. It might be well-tested and
seasoned, but only within the confines of its known limitations.
Watch this.
m...@anodizer bash$ ls -l a/b/../c
-rw-r--r-- 1 mark staff 0 May 13 15:47 a/b/../c
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
import os.path
os.path.normpath('a/b/../c')
'a/c'
^D
m...@anodizer bash$ ls -l a/c
ls: a/c: No such file or directory
Probably the same as os.path.normcase in Python. I want this stuff so that
I can make sure that I can at least semi-reliably compare/manipulate
FilePaths to do things like absolute-relative path conversion, or store
FilePaths in a set or map and be sure I don't have multiple entries pointing
to the same file. Without these kinds of operations, doing these things is
pretty much impossible.
I don't think os.path.normcase does what you're asking for either.
m...@anodizer bash$ ls -lid /System/Library
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /System/Library
m...@anodizer bash$ ls -lid /system/LIBRARY
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /system/LIBRARY
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
import sys
sys.platform
'darwin'
import os.path
os.path.normcase('/System/Library')
'/System/Library'
os.path.normcase('/system/LIBRARY')
'/system/LIBRARY'
^D
Even os.path.realpath returns the same results.
Again, it sounds like what you really want is a pathname comparator
that hits the disk. You really can't do this stuff correctly on most
systems without talking to the filesystem. You can't even do
general-purpose canonization without talking to the filesystem.
Let me make clear: I'm not trying to shoot down the idea of needing to
be able to compare paths or even necessarily canonize them. I'm
arguing primarily against doing it in FilePath, but I'm also also
trying to illustrate that doing proper comparisons and canonization is
harder than it seems, that even seasoned and well-tested APIs are
limited in ways that developers don't necessarily expect, and that the
semantics and expectations need to be well-defined.
Mark
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
Amanda Walker wrote: Yeah. And I have to say, the tab-modal file sheet is very, very cool. It would be a shame to lose that capability. I agree, I think it'd be worth seeing how polished we can get things with Avi's POC. It's a cool behavior that has the exact feel that sheet users would expect. --~--~-~--~~~---~--~~ 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: Tab-modal dialogs on the Mac
The sheet approach or the sheet-look approach? I like the sheet-look approach, but Cocoa sheets are window-modal, which I don't think is all that cool given how we use tabs (or want to use tabs). Mark Ben Goodger (Google) wrote: The sheet approach sounds fine to me for Mac dialogs. Note also that anything you do should not become app-modal when the tab is selected. On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ 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: Tab-modal dialogs on the Mac
Yeah, that'd be awesome. Ben Goodger wrote: I remember Nicholas saying he thought it'd be possible to fabricate a non-modal sheet like thing. -Ben On Tue, May 5, 2009 at 3:25 PM, Mark Mentovai m...@chromium.org wrote: The sheet approach or the sheet-look approach? I like the sheet-look approach, but Cocoa sheets are window-modal, which I don't think is all that cool given how we use tabs (or want to use tabs). Mark Ben Goodger (Google) wrote: The sheet approach sounds fine to me for Mac dialogs. Note also that anything you do should not become app-modal when the tab is selected. On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ 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: Changes to FilePath?
Greg Spencer wrote: So there's currently no right way to do the conversion, but I still think that the FilePath constructor is probably in the best position to inspect LC_ALL, etc. and do as close to the right thing as possible. I doubt most Linux developers even think about this, and so the chances that they will implement anything other than assuming that it's ASCII are slim -- this would allow us to at least implement a baseline for them. Not doing the conversion is kinda the point. Well, it's exactly the point. (Hi, I'm the author of FilePath.) If you've got an arbitrary path, it might be encoded in some scheme, and it might not, and it might contain a mix of encodings. The point of FilePath is we know it's a path and we don't necessarily know anything else. Chromium didn't used to have FilePath. Everything was a wstring which implied UTF-16/32, and the conversions implied UTF-8 because we couldn't do anything smarter, and there was all sorts of potential for messing things up. Not a pretty story. When FilePath was born, the *Hack methods showed up to give us a way to transition the old-style wstring APIs to new-style FilePath APIs at reasonable cut points, instead of having to do everything all at once. I understand your problem. You're saying I have user-supplied data that I want to build a filename from, and I have this pathname that I want to display back to the user. I agree that it would be good to have a way to handle these cases in base. I don't know if FilePath proper is the right place to do it. If we do it in FilePath, it still won't really be right. If we had something, it should probably be made to operate only on single pathname components, and it should be the caller's responsibility to only deal with user-created names with this interface. 2) I'd like to make it possible to instantiate a POSIX FilePath object on Windows and a Windows FilePath on POSIX platforms. This is because some libraries (e.g. the zip library, or tar files), use POSIX semantics for their paths even on Windows (I haven't seen a use case for Windows paths on POSIX yet, actually). This would make it possible to use the nice API that FilePath has to manipulate paths appropriately for these other libraries. This could be easily accomplished by having POSIX and Windows versions of FilePath, and then typedef'ing FilePath differently on different platforms to one of these versions. Sounds pretty Pythonic. FilePath already sort of has some support for this - it does a bunch of things based on feature macros, mostly so that as I was writing it, I could test the Windows semantics without having to (shudder) resort to running on Windows. These could probably be adapted to do what you're asking. 3) It would be helpful to have real path normalization for each of the platforms (although I know what a testing nightmare that can be). I might try and tackle this if people think it would be beneficial. It's also a specification and implementation nightmare. Everyone has a different idea of what normalization means. What's your idea? 4) Make sure we handle case sensitivity vs case preservation correctly. It's unclear to me that FilePath does this correctly on the Mac -- Mac file names are case preserving, but case insensitive, Unix filenames are both (and windows filenames are neither :-). Again with the normalization. What do you want this stuff for? What's your idea of how this should work? Remember: FilePath is specified to be light and to never touch the disk. If you've got a disk-touching operation, it probably doesn't belong in FilePath proper. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: chromium resources always rebuilding
Tony Chang wrote: I'm not sure this is related to the mac try servers being slow. This only causes GRIT to re-run (maybe 10s to run on all files?), but prevents .cc files from being recompiled. If there was a change that (intentionally or otherwise) caused GRIT to run on each build, the effects could easily add up to more than 10s on all files even during a null build when you start to factor in additional linking time, etc., as Mike points out. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp build on Linux
Craig Schlenter wrote: When I add -Wl,--start-group and -Wl,--end-group to that (manually since haven't figured out how to make gyp do it), then the missing symbol problem goes away (at least when loading chrome and navigating to mail.google which is where I was seeing the problem). I don't know that there should be circular dependencies any more. Between what modules are you seeing them? We can do a workaround temporarily if needed, but I'm very interested in actually fixing any circular relationships. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: variant definitions in the .gyp files
Marc-Antoine Ruel wrote: One answer: try server. OK, I'm sold. --~--~-~--~~~---~--~~ 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: variant definitions in the .gyp files
Steven Knight wrote: What's the workflow for enabling coverage in this model? gclient runhooks --force -Dcoverage=1 and then re-start XCode? That doesn't seem natural for the Linux side, but I could live with it. Linux devs: comments? I think that the variant model is a stronger way to handle coverage. Once we do have a variant-based model to handle coverage, the only thing missing from John's work would be the coverage-running target. We could easily retain that target, unconditionally, and just have the script be a no-op (or fail) when run on a coverage-free variant. Long-term, we might even want to integrate the coverage runner stuff more directly into GYP, the way we have done with test runners. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium App Executables Disk Layout
Dean McNamee wrote: Something important would be to understand the overhead for a shared library (fpic, relocation, etc). On the Mac, I actually want to link the main executable with -pie so that it loads at a different address each time anyway. That implies PIC. It's still wise to understand the overhead, which is why I've been waiting until we have some perf tests running to make this change. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: When i open the chrome.sln,vs report a lot vcproj file missing?
Jim Roskind wrote: The problem with that list is that we alternately generate the sln files (from gyp), and then try to update and revert them via svn. The remnant files generated by gyp screw up the process :-(. OK, that's bad. I thought Brad took steps to ensure that we'd either generate .sln/.vcproj files from GYP or use checked-in files but not have them conflict. This is certainly the intended design. svn and GYP should not be fighting. Brad? Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: When i open the chrome.sln,vs report a lot vcproj file missing?
Bradley Nelson wrote: On Tue, Mar 17, 2009 at 9:28 PM, Mark Mentovai m...@chromium.org wrote: OK, anything that's GYP-generated does need to be in svn:ignore. Not understanding why? The try servers clean out previous state with gclient revert, which will remove any file that shows up as ? in svn status. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: When i open the chrome.sln,vs report a lot vcproj file missing?
Bradley Nelson wrote: It certainly was my intention to have atomic changes that remove sln/vcprojs in the same change that causes them to be generated. Did you mean something stronger Mark? Nope, that's exactly what I meant and all of the changelists I saw from you did do this. It seems that some of the other messages in this thread indicate that svn and GYP are fighting over the same files, though. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy/Paste, Cocoa, and you
Avi Drissman wrote: Sure. I'm also curious about why we're dying in WTF::HashTable::contains. Are there some statics that are conflicting? Not likely, those should all be bound at link time unless someone's specifically doing a runtime lookup (à la dlsym()). Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy/Paste, Cocoa, and you
Not to gloat or anything, but Obj-C dynamic dispatch was responsible. The solution is to hide the few remaining exposed bits of Obj-C from our libwebcore by giving them names that won't conflict with those used by the system-provided WebCore.framework. I'll send something around later. --~--~-~--~~~---~--~~ 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: Need an idiot's guide to GYP
I'm working on documenting everything this week. There's some stuff at http://code.google.com/p/gyp/w/list now. Mike Belshe wrote: I probably missed the email on the new Mac build system. (I was gypped!) So I went to http://dev.chromium.org/developers/quick-reference to try to learn how to add a file to the mac port. But alas, it just talks about xcodeproj. And of course, GMail search doesn't work, so I can't find any doc in email either. Probably more user-error on my part. Question: Can someone send consolidated instructions on how to use GYP to add files? Let me know if you want to update the wiki, or I will be happy to do so as well. --~--~-~--~~~---~--~~ 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: Let's make build system history!
The GYP-based build is now automatic, mandatory, and totally awesome on the Mac. I just checked in a change to remove our old Xcode projects and have GYP generate project files for you every time you gclient sync. If you participated in the test on Friday, please remove the hooks section from your .gclient file. Project file generation is now automatic on all Macs via a hook in the DEPS file. In order to maintain the Mac build now, you must edit the .gyp files checked in throughout the tree. Some of you have been doing this already (thanks!) and all of the feedback I've received with respect to .gyp file maintenance has been very positive. Additional documentation will be coming soon. In the mean time, you no longer need to Cc me on reviews involving trivial changes to .gyp files (such as adding or removing files), although I will keep up with changes to those files after they've been committed for at least the next week. If you have more complicated .gyp file changes to make, or you just want peace of mind, please do send the review to me. When you make a change to a .gyp file locally and want to regenerate new Xcode projects, you can use gclient runhooks --force. This is a new command that will cause the GYP hook in the DEPS file to run. Please use this instead of invoking GYP directly as I had previously advised. If you have made any local modifications to the old set of Xcode projects, just revert them. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Let's make build system history!
Ben Goodger wrote: Awesome! Thanks for getting this together, Mark. Do you have any idea what the ETA for Linux and Windows is? My pleasure! I know that the MSVS and Linux SCons generators are up as far as WebKit, or nearly so. WebKit's really the difficult piece of the puzzle, so once that's solid, it shouldn't be long. Perhaps bradn (MSVS) and sgk (SCons) can provide better estimates of when they think their generators will be ready to begin wider testing. evanm has also been working on a Linux Makefile generator, which is newer and I think not quite as far along, but I hear it's pretty zippy. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Let's make build system history!
Mac users, help me test out GYP's integration with gclient. Please
add this to the end of your .gclient file, which lives in the parent
of your src directory:
hooks = [
{ pattern: \\.gypi?$,
action: [python, src/tools/gyp/gyp, src/build/all.gyp],
}
]
This tells gclient to run GYP any time a .gyp or .gypi file changes.
(.gypi files are ones that get included into other .gyp files.)
gclient will run GYP during sync and revert operations as needed.
When you check out an updated .gyp file, you'll wind up with a
corresponding updated .xcodeproj. I'm also planning on adding
something to process hooks on files that you have modified in your own
tree. Until then, you'll still need to run GYP manually when you
change .gyp files to get your Xcode projects regenerated. Just use
the command I sent out before, run ../tools/gyp/gyp from the src/build
directory.
This .gclient modification is temporary. When we go live with this,
within the next few days, the hook will move into the DEPS file, so
you won't need to specify it manually. At that point, I'll ask
everyone who has put the hook in their .gclient to remove it.
Mark
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
Wan-Teh Chang wrote: Another idea is to work harder with Ubuntu to provide the ia32 NSPR/NSS libs for x86_64 in Ubuntu 8.04 LTS. That'd be the best solution but require a lot of red tape. It sounds like the red tape is the real problem here. Are we attacking the problem on this front at all? It seems like all of this becomes moot if we can get it resolved from that angle. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Let's make build system history!
Matt Perry wrote: Does this mean the checked-in xcode project files are obsolete? Not yet, but they will be soon. Or do we need to update both .gyp and .xcodeproj files now? If you only update one, it has to be the checked-in .xcodeproj for now. That's still the official build for the Mac. Ideally you'd update the .gyp too and Cc me on the review. You don't have to wait for a response from me for simple changes, I just want to keep tabs on what's changing because I'm still working pretty heavily on some parts. The more that people start updating .gyp files when they change things now, the less I'll have to play catch-up. That leaves me with more time to finish the actual conversion so that we can svn remove the old xcodeprojs and switch to GYP-only on the Mac. I think that this is in everyone's best interest, but especially mine. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: eliminating build/build_config.h -- need help on mac
I don't agree with this approach. I think that we should include what we use, and that should extend to headers that provide nonstandard macro definitions. I think that we should be expressing as much as possible in code rather than in build environments. Most importantly, I don't like the idea of globally polluting the macro namespace for something like this. Our OS_* macros are ours (emphasis on ours) and I don't want to leak those defines to all of the other third-party code that we build. Mark Evan Martin wrote: A few people I've talked to independently have expressed interest in getting rid of build/build_config.h. It is easy to forget to include, requires being included in a nonstandard place, and ends up being used everywhere anyway. It is easier to just define the few #defines we need in build scripts. (I think the compiler- and architecture- specific defines could move to a different file eventually, but we almost never use those.) http://codereview.chromium.org/21401 does this. It seems to work on Windows (I'd like an expert to doublecheck I did it the right way) but my wild guess at making Mac work is apparently wrong. If any Mac expert could help out, I'd appreciate it. --~--~-~--~~~---~--~~ 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: webkit merge delayed on mac errors
No, you need to re-land the merge but with V8EventTargetNode.cpp removed from webkit.xcodeproj. Clobber shouldn't be necessary. Ojan wrote: So, it just needs a clobber then? On Sun, Feb 8, 2009 at 9:11 PM, Mark Mentovai m...@chromium.org wrote: (...posting again from the right e-mail address...) Oh, I see in your r9380 of webkit/webkit.xcodeproj/project.pbxproj, you removed EventTargetNode.cpp but you never removed V8EventTargetNode.cpp. So the Mac was still trying to build the old obsolete file which just happens to exist because it used to be generated by DerivedSources.make but is no longer valid or up to date. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
