After a few days of hard work, we've gotten the Mac build back in
shape following the recent WebKit merge. A special thanks to Jeremy,
Amanda, and Mike, who worked with me to get this done.
This puts us back where we were last week, but with an updated WebKit
snapshot. We're currently building
On the Mac, I think we want to match Apple WebKit baselines. I don't
know if there are any baselines currently in chromium-win that we
should share.
Mark
Dean wrote:
I talked to Mads a bit, basically:
1) I think the Mac expected result fallback is currently wrong, it
doesn't seem to look
(...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
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
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
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.
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
= 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
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
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
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
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
(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
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
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
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
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
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
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': [
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
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?
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 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
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
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
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
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
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
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.
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
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'
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',
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
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
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
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
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
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
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
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
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
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,
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
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:
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.
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
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
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
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
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
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
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
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?
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
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
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
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
(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
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
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
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
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
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
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
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
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,
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
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:
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
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
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
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
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.
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
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
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
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
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:
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:
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
1 - 100 of 103 matches
Mail list logo
