On Fri, Sep 5, 2008 at 6:13 AM, Brett Wilson [EMAIL PROTECTED] wrote:
On Sep 3, 9:56 pm, Mark Wang [EMAIL PROTECTED] wrote:
The render processes paint to offscreen DCs. Each render process (ie,
tab)
retains its own DC.
This isn't true. Each render process paints into a new DC every time
It looks like you may be having trouble building the V8Bindings_prebuild
project. Can you try building only that project? You might want to blow
away your chrome/Debug folder first just to make sure you have a clean
starting point.
-Darin
On Sun, Sep 7, 2008 at 11:28 PM, raymond [EMAIL
/pub/tr/TR-2001-50.pdf
213-status of /pub/tr/TR-2001-50.pdf:
05-01-01 11:58AM78322 TR-2001-50.pdf
213 End of status.
QUIT
221
Doing it the way IE (and Firefox iirc) do it, using SIZE, seems much
more logical and bug-proof to me.
-[Unknown]
On Sep 9, 10:20 pm, Darin Fisher
On Fri, Sep 12, 2008 at 8:07 PM, Ben Goodger (Google) [EMAIL PROTECTED] wrote:
I've been doing some janitorial work in the browser/ dir today, moving
various files into better places, and creating subdirectories for
significant chunks of code. Without trying to create a byzantine
directory
will be the TCPClientSocket. this extra layering would only
happen of course when a SOCKS proxy is enabled.
This should clarify why we need to parameterize SSLClientSocket in
terms of ClientSocket.
-darin
On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher [EMAIL PROTECTED] wrote:
On Tue, Sep 16, 2008 at 9:42 AM, Dan
On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote:
One more data point: we'll also need to support SSL over SOCKS one
day, and that means that the ClientSocket passed to SSLClientSocket
On Wed, Sep 17, 2008 at 11:52 PM, Darin Fisher [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote:
One more data point: we'll also need to support SSL over SOCKS one
day
On Thu, Sep 18, 2008 at 2:36 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher [EMAIL PROTECTED] wrote:
In previous discussion with Darin, it seemed we
wanted to use epoll rather than poll. This
implies that we want to not use NSPR for our
network I
I thought the plans for mac osx did not involve nss. I think we should do
an implementation based on the mac ssl apis so that we get good integration
w/ the keychain or what have you. right?
-darin
On Fri, Sep 19, 2008 at 12:40 PM, Dan Kegel [EMAIL PROTECTED]wrote:
On Fri, Sep 19, 2008 at
This was done for compatibility. Unfortunately a lot of web sites look for
safari in the UA string to determine if they should tailor their content
for webkit! It is a very sad state of affairs. All webkit based browsers
(e.g., Omniweb) include safari in their UA strings for this exact reason,
I share your frustration ;-)
-darin
On Thu, Sep 25, 2008 at 4:39 AM, Bernd Kreuss [EMAIL PROTECTED]wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Darin Fisher wrote:
This was done for compatibility. Unfortunately a lot of web sites look
for safari in the UA string to determine
The version number is specified in the chrome/VERSION file. The build
system should automatically detect changes to that file. We don't change
that file too frequently
-Darin
On Thu, Sep 25, 2008 at 10:47 PM, Wei Hu [EMAIL PROTECTED] wrote:
Hello,
It seems that the version number is
The plan that we have been operating under so far is to have Chromium render
form controls and fonts in a manner that is most appropriate for each
platform. I think this is an important element of making a browser feel
right on each platform.
-Darin
On Fri, Oct 17, 2008 at 11:23 AM, Marshall
On Fri, Oct 17, 2008 at 3:33 PM, Steven Knight [EMAIL PROTECTED] wrote:
We're getting ready to start going live (really) with the Hammer build
configuration for Chromium. This is to give everyone a heads up, and allow
for feedback.
Testing the default SCons generation of Visual Studio
FYI, this change is complete now. We no longer defined PLATFORM(WIN) in the
windows build of Chromium.
-Darin
On Thu, Oct 16, 2008 at 5:29 PM, Darin Fisher [EMAIL PROTECTED] wrote:
FYI, I'm working to turn off PLATFORM(WIN) for the windows build now.
There are many hurdles in the way, so
On Thu, Oct 23, 2008 at 11:02 AM, Evan Martin [EMAIL PROTECTED] wrote:
When you have things looking mostly-ok (e.g. stuff links on Windows),
can you send out a will land again soon warning so we can
double-check it doesn't break the ports?
On Wed, Oct 22, 2008 at 7:47 PM, Darin Fisher [EMAIL
I have a cross-platform (based on V8) proxy resolver implementation in my
tree. I just haven't found the time to finish it. We should probably use
it.
Then, we'll just need to write code to figure out what the proxy
configuration is for each operating system.
I plan to change things so that the
On Mon, Oct 27, 2008 at 2:12 PM, Avi Drissman [EMAIL PROTECTED] wrote:
WPAD just means use http://wpad/wpad.dat as the PAC URL. This is
supported by Firefox on all platforms, and it is easy to support in Chrome
;-)
Right, but the question is where the switch is. Firefox uses its own UI
Thanks Finnur. There are some interesting challenges to get it working
properly. We have to re-implement the tick marks code upstream. The issue
of find-in-page not working at all is probably unrelated to tick marks
presentation, so we should be able to fix that separately.
-Darin
On Mon,
FYI, we have started the next webkit merge to r38097. Please minimize your
changes to third_party/WebKit. Unlike last time, you do not need to apply
your changes to the third_party/WebKit on the merge branch. We'll take care
of that, but please please please try not to make many changes to
On Tue, Nov 4, 2008 at 11:01 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]wrote:
On Nov 4, 9:11 am, Darin Fisher [EMAIL PROTECTED] wrote:
Some comments:
1. Returns the port for the host page to communicate with the
background
task. Null is returned if the task is not started. -- How do you
FYI: the rough plan is for a webkit merge to start every Tuesday. Dimitry
and I will team up with someone from the V8 team to make this a regular
event. This regularity should help keep the cost of the merges down and
allow everyone to be able to anticipate when changes made upstream to webkit
at 3:30 PM, Darin Fisher [EMAIL PROTECTED] wrote:
What do we need Mach semaphores for? You mention issues with named pipes,
but what about anonymous pipes? I'm curious why we need a different
implementation on OSX and Linux. It seems worth while if we can have a
shared implementation
?
--Amanda
On Wed, Nov 5, 2008 at 8:26 PM, Darin Fisher [EMAIL PROTECTED] wrote:
Sorry to be so persistent, but I don't understand why you need those
things. Can you provide some specific examples?
As far as I know, we need the ability to have shared memory. It seems
like we can do
On Thu, Nov 6, 2008 at 2:05 PM, Amanda Walker [EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 4:45 PM, Darin Fisher [EMAIL PROTECTED] wrote:
It sounds like things are still fairly speculative...
Well, performance differences are not speculative, though we don't know
what the effect
Oh, sorry for the error. I think I missed this because all of our builders
are doing incremental builds.
I will apply your fix.
-Darin
On Tue, Nov 11, 2008 at 10:26 PM, Jo [EMAIL PROTECTED] wrote:
On the latest revision @5254, I got those errors:
1-- Build started: Project:
of us. In the
absence of that, I think that going on general principles and prior
experience, and doing an implementation bake-off , is a reasonable
course of action.
--Amanda
On Thu, Nov 13, 2008 at 1:12 AM, Darin Fisher [EMAIL PROTECTED] wrote:
Keep in mind that pipes are not really
Thanks for cleaning this up, Pam!!!
On Thu, Nov 13, 2008 at 4:57 PM, Pam Greene [EMAIL PROTECTED] wrote:
Today I got our custom (platform-specific) layout test results mostly
straightened out. (Apologies for the large-ish sync that will cause.)
If you re-baseline tests, please keep reading.
The scons build definitely lets you build only a single target (program or
library) at a time. What is missing is the ability to compile a single
source file.
The nice thing about the scons build is that it will compile source files in
parallel and not just projects in parallel. I think this
This sounds great. I always thought of these UI elements as siblings to the
WebContents, so it seems nice that they be moved out of WebContents.
-Darin
On Wed, Nov 19, 2008 at 10:03 PM, Ben Goodger (Google) [EMAIL PROTECTED]wrote:
In a continuation of the state/view separation work I have
Yeah, the error is very similar to the one in that bug. Here's the error
that we are seeing on the bots:
124javascriptcore_pcre.lib(pcre_xclass.obj) : error LNK2005: bool __cdecl
kjs_pcre_xclass(int,unsigned char const *) (?kjs_pcre_xclass@@[EMAIL
PROTECTED])
already defined in
By the way, if it proves to be easiest to have real named objects in the
file system, we can always scope them to the browser process's
user-data-dir. There is one user-data-dir per browser process, so this
could allow us to solve the traditional managment issues with named objects
in the
Hopefully we can solve the callback interface issue much as it was solved
for FileStream.
-Darin
On Wed, Nov 26, 2008 at 10:47 AM, Mike Pinkerton [EMAIL PROTECTED]wrote:
Just wondering if anyone involved in the porting effort has started
poking around common/ipc_* and the channel/message
The closest thing to a list is probably this declaration of IPC messages:
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/render_messages_internal.h
In a debug build, you can use about:ipc to monitor IPC traffic.
-Darin
On Fri, Dec 12, 2008 at 8:17 AM, karthic...@gmail.com
Thanks for the write-up. I did not fully grok what the problem was with
Mach ports. It turns out that we had the same performance problem on
Windows when I tried converting IPC::Channel over to using
base::ObjectWatcher (i.e., RegisterWaitForSingleObject) due to the thread
context switching
By the way, WebKit has support for drawing the resizer. So, if you are
trying to add a resizer to windows that display web content, you might want
to just enable the feature in WebKit (or at least the rendering portion of
it).
-Darin
On Fri, Dec 12, 2008 at 1:32 PM, Marc-Andre Decoste
, but if it is the
only way to do it over the tab content... so be it... Unless someone else
has another suggestion?
Thanks!
BYE
MAD
On Sat, Dec 13, 2008 at 11:37 PM, Darin Fisher da...@chromium.org wrote:
By the way, WebKit has support for drawing the resizer. So, if you are
trying to add a resizer
does the webkit resizer disappear when the download shelf appears?
-darin
On Mon, Dec 15, 2008 at 11:27 AM, Ben Goodger (Google) b...@chromium.orgwrote:
A few thoughts on implementing the resizer:
- Windows supports a resizer hit test code return value from
WM_NCHITTEST. I think it's
sorry, s/does/should/
On Mon, Dec 15, 2008 at 11:44 AM, Darin Fisher da...@chromium.org wrote:
does the webkit resizer disappear when the download shelf appears?
-darin
On Mon, Dec 15, 2008 at 11:27 AM, Ben Goodger (Google)
b...@chromium.orgwrote:
A few thoughts on implementing
On Tue, Dec 16, 2008 at 2:44 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Dec 16, 2008 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
http://nightly.webkit.org/start has a link to the list of approved
patcheshttps://bugs.webkit.org/buglist.cgi?query_format=advancedshort_desc_type
This sounds nice and simple on the surface I spent a lot of energy
trying to figure out how to make it fly to no avail.
Short version:
The problem is that no matter how you cut it, you end up violating the
run-to-completion (non-reentrant) constraint of javascript. It is not
enough to
that something happened.
Trying to coerce alerts to be page-modal is just going to hurt a lot and be
way more work than the feature could possibly be worth in my opinion.
-Darin
On Tue, Dec 16, 2008 at 3:36 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Dec 16, 2008 at 3:30 PM, Darin Fisher da
per-machine extensions are very important. that turns out to greatly
simplify the task of distributing an extension via a third-party installer.
-darin
On Tue, Dec 16, 2008 at 5:40 PM, Peter Kasting pkast...@chromium.orgwrote:
On Tue, Dec 16, 2008 at 5:34 PM, Aaron Boodman a...@chromium.org
On Tue, Dec 16, 2008 at 5:47 PM, mpcompl...@chromium.org
mpcompl...@chromium.org wrote:
We need to at least support per-profile enabling/disabling of
extensions. The extension package may live outside the profile
directory, but if another profile has Random Extension X enabled, I
shouldn't
Chrome should give users the ability to disable extensions regardless of how
they are installed. Installation of an extension should just be about
making Chrome aware of extensions. I'm envisioning something that works
just like Firefox's system. When Firefox discovers a new extension
Firefox does not have such a restriction. I don't think we should go
overboard here. If a user can install Chrome, then they should also be able
to install other software that installs Chrome extensions. If we try to
prevent that from happening, then we will fail. People will instead write
On Wed, Dec 17, 2008 at 10:51 AM, Peter Kasting pkast...@google.com wrote:
On Wed, Dec 17, 2008 at 10:44 AM, Darin Fisher da...@chromium.org wrote:
Absolutely... extensions should be able to store data in the profile. I
think that issue is orthogonal to where the extensions get installed
On Thu, Dec 18, 2008 at 7:01 AM, idanan chr...@cybernium.net wrote:
On Dec 16, 8:50 pm, Mike Belshe mbel...@google.com wrote:
My thought is that extensions should not apply in the incognito mode.
That would be terrible. Imagine a usability extension (zoom part of
the view, support for
On Thu, Dec 18, 2008 at 11:18 AM, Peter Kasting pkast...@chromium.orgwrote:
On Thu, Dec 18, 2008 at 11:11 AM, Darin Fisher da...@chromium.org wrote:
I don't see how the UI for a seemingly random set of tabs being blocked by
a dialog in one tab could be done in a reasonable fashion. It seems
Yes. This thread has clearly grown too large. The proposal for calendar
like apps is mentioned above.
-Darin
On Thu, Dec 18, 2008 at 11:29 AM, Aaron Boodman a...@chromium.org wrote:
On Thu, Dec 18, 2008 at 11:25 AM, Darin Fisher da...@chromium.org wrote:
Why not try to do something
by the way, we already auto-dismiss alerts that have been generated too
frequently.
-Darin
On Thu, Dec 18, 2008 at 11:47 AM, Charles Reis cr...@chromium.org wrote:
On Thu, Dec 18, 2008 at 11:30 AM, Peter Kasting pkast...@google.comwrote:
On Thu, Dec 18, 2008 at 11:25 AM, Darin Fisher da
FYI
Please expect conflicts if you are trying to make changes to webkit/port.
-Darin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Chromium-dev group.
To post to this group, send email to
can't
find it
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/graphics/
or
http://trac.webkit.org/browser/trunk/WebCore/platform/graphics
Where did it go?
Adam
On Mon, Dec 22, 2008 at 8:42 PM, Darin Fisher da...@chromium.org
wrote:
OK, much of webkit
This problem could also be solved by ignoring DerivedSources.make, and
instead just add the source files to the vcproj. Then write a custom
.rules file for each file type that runs the appropriate batch command to
create the generated file. Then, dependency tracking would work just as it
does
This sounds like a great idea to me.
-Darin
On Mon, Jan 5, 2009 at 3:25 PM, Pam Greene p...@chromium.org wrote:
We don't have very good unit test coverage (in the broad sense, including
ui_tests, test_shell_tests, etc.) for our code. We've always had a policy
that any new code had to have
On Sun, Jan 4, 2009 at 5:44 PM, t...@chromium.org wrote:
On Sun, 4 Jan 2009, Brett Wilson wrote:
On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher da...@chromium.org wrote:
This problem could also be solved by ignoring DerivedSources.make, and
instead just add the source files
the winsock initialization can be removed now that we have EnsureWinSockInit
which should be called by any code that uses winsock. (we may not have
sprinkled that in all of the right places, but you get the idea.)
i really like your idea of documenting startup dependencies, and i agree
that the
Separate phase functions sounds good to me. We should make it clear that
stuff within a phase should not be interdependent, but that might be hard to
verify and enforce :-/
-Darin
On Thu, Jan 15, 2009 at 2:18 PM, Ben Goodger (Google) b...@chromium.orgwrote:
Here's my plan. The Mac and Linux
Wow. It sucks that we'll need to load plugins in the main browser process.
That gives plugins a nice opportunity to hose the browser. Oh well :-( If
we really wanted to, I suppose we could have a plugin scanner process, but
that seems unfortunately heavyweight.
-Darin
On Tue, Jan 27, 2009
On Tue, Jan 27, 2009 at 10:04 PM, Brett Wilson bre...@chromium.org wrote:
There are a lot of patches lately with a lot of reviewers on them,
especially related to porting since a lot of people might need to be
in the loop for some changes.
The problem is that there's no clear responsibility
It sounds like you should just propose a patch that adds a message_hwnd
getter on MessagePumpForUI :-)
-Darin
On Fri, Jan 30, 2009 at 2:59 PM, Daniel dpc...@hotmail.com wrote:
I need to obtain the HWND of the message window for a thread so that I
can call ::RegisterShellHookWindow() to get
On Tue, Feb 3, 2009 at 5:26 AM, Dean McNamee de...@chromium.org wrote:
Ever since I've been using git, I have super great and quick access to
our full history and commit logs. Being in a different time zone, I
usually warm up in the morning by reading yesterday's commits. I've
found in
The proposal was to search-n-replace std::wstring to string16. We would
have to invent a macro to replace L usage. Most usages of string literals
are in unit tests, so it doesn't seem to matter if there is cost associated
with the macro.
My belief is that there isn't much fruit to be had by
On Wed, Feb 4, 2009 at 9:35 AM, Dean McNamee de...@chromium.org wrote:
On Wed, Feb 4, 2009 at 6:11 PM, Darin Fisher da...@chromium.org wrote:
The proposal was to search-n-replace std::wstring to string16. We would
have to invent a macro to replace L usage. Most usages of string
literals
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote:
[Reposting from wrong mailing list, sorry for dupe.]
On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
pipes), with one end passed through the spawn to the child process.
Right now the interfaces don't
On Wed, Feb 11, 2009 at 11:42 PM, Evan Martin e...@chromium.org wrote:
(I'm not an expert on the drawing pipeline but I recently learned a
bit about it and I thought I'd write down notes before I forget.
Hopefully someone like Darin who understands better than me will fill
in the holes.)
On Thu, Feb 12, 2009 at 1:27 PM, Matt Perry mpcompl...@chromium.org wrote:
Thanks for taking the time to send this out. It was a good learning
experience. I have a tangential comment/question, but didn't think it
was worth splitting off a second thread.
Any thoughts how well extensions
I had assumed that NativeWindowID should just be the X window ID in our
Linux build. That is what NPAPI uses (see NPWindow), and so it is what we
will need to pass around.
I think you can initialize a GdkWindow from a X window ID. I don't think we
should worry about the case where GDK is not
On Fri, Feb 13, 2009 at 7:40 AM, Amanda Walker ama...@chromium.org wrote:
On Fri, Feb 13, 2009 at 1:34 AM, Dean McNamee de...@chromium.org wrote:
I believe the situation is similar on the Mac. I'm not sure the
current design of passing HWNDs between processes conceptually extends
beyond
You need to add something like what this file has for v8/include:
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/DEPS?view=markup
On Sun, Feb 15, 2009 at 1:42 AM, Aaron Boodman a...@chromium.org wrote:
I'm trying to commit a change
That sounds like a lot of overhead and a lot of costly plumbing to me. Is
it really beneficial?
-Darin
On Tue, Feb 17, 2009 at 3:07 AM, Dean McNamee de...@chromium.org wrote:
Is it not possible to process PAC in a renderer?
On Tue, Feb 17, 2009 at 5:02 AM, Darin Fisher da...@chromium.org
On Tue, Feb 17, 2009 at 10:15 AM, Erik Kay erik...@chromium.org wrote:
On Tue, Feb 17, 2009 at 8:06 AM, Marc-Antoine Ruel mar...@chromium.org
wrote:
I guess it's not doable ATM anyway but does the debugger really needs
to run in the browser?
I think the debugger's dependency is already
+1
Google style encourages including everything you need in the source. There
should be no magic -include lines required to build the source.
This is why pre-compiled headers are disabled in release builds. If they
were not, then over time people would only be able to build the source if
they
On Tue, Feb 17, 2009 at 10:31 AM, Evan Martin e...@chromium.org wrote:
On Tue, Feb 17, 2009 at 10:20 AM, Darin Fisher da...@chromium.org wrote:
What are the reasons to not like V8 in the browser?
To summarize the arguments:
- reduce memory fragmentation in browser by not creating a V8 heap
I wonder why this hasn't gotten much attention in other browsers...
-Darin
On Tue, Feb 17, 2009 at 1:42 PM, Adam Barth aba...@chromium.org wrote:
Hi Eric,
On Tue, Feb 17, 2009 at 12:47 PM, Eric Roman ero...@chromium.org wrote:
My goal is to do all the work necessary to get V8-PAC resolving
Or maybe it has? It looks like WinHTTP can perform PAC lookup
out-of-proc... maybe only under Vista.
-Darin
On Tue, Feb 17, 2009 at 9:42 PM, Darin Fisher da...@chromium.org wrote:
I wonder why this hasn't gotten much attention in other browsers...
-Darin
On Tue, Feb 17, 2009 at 1:42 PM
:
No one else has a sandbox for their JavaScript engine. ACE in their
JS engine is game over.
Adam
On Tue, Feb 17, 2009 at 9:42 PM, Darin Fisher da...@chromium.org wrote:
I wonder why this hasn't gotten much attention in other browsers...
-Darin
On Tue, Feb 17, 2009 at 1:42 PM, Adam
surface doesn't seem any larger with PAC than it already is for
plaintext HTTP.
-Darin
On Wed, Feb 18, 2009 at 8:00 AM, Darin Fisher da...@chromium.org wrote:
Right... I meant the particular vector of faking the proxy auto config file
to achieve HTTP interception. That Windows has auto detect
On Wed, Feb 18, 2009 at 8:28 AM, Avi Drissman a...@google.com wrote:
On Wed, Feb 18, 2009 at 11:22 AM, Darin Fisher da...@chromium.org wrote:
Notice that except for a bool, the rest are not part of the structure when
PLATFORM(CHROMIUM) is defined, so for us PlatformKeyboardEvent is platform
Yes... talk to maruel on #chromium.
-Darin
On Thu, Feb 19, 2009 at 6:24 AM, Yury Semikhatsky yu...@chromium.orgwrote:
Hi, Chromium build
pagehttp://build.chromium.org/buildbot/waterfall/waterfallis giving me
502/503 errors for about an hour. Is anyone looking at this?
Yury
We could we could also wait for the GYP conversion, which also addresses
this problem.
-Darin
On Thu, Feb 19, 2009 at 3:36 AM, Dean McNamee de...@chromium.org wrote:
When we spot cases like this, can't we fix the makefiles / build files
so that the dependencies are properly described?
With a change that I have just committed, it is now necessary to
delete src/third_party/WebKit/WebKit
and re-run gclient sync.
Sorry for any inconvenience!!
-Darin
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View
It is sometimes worth it to reduce the supported toolchain to help reduce
distractions. If these warnings are beneficial, then a bot is probably a
good idea. However, a red bot is bad... so we'd probably have to commit
ourselves to fixing any bustage. I'm not sure what's better... how
to sometime later switch to supporting a more recent release of GCC
and then realizing that we've got 50,000 errors to work through...
my $0.02
On Thu, Feb 19, 2009 at 9:14 AM, Darin Fisher da...@chromium.org wrote:
It is sometimes worth it to reduce the supported toolchain to help reduce
You should also just edit your .gclient_entries file, to remove the
src/third_party/WebKit/WebKit line. Otherwise, gclient sync will
complain about it after each run.
-Darin
On Thu, Feb 19, 2009 at 8:55 AM, Darin Fisher da...@chromium.org wrote:
With a change that I have just committed
...@kegel.com wrote:
Newer gcc versions tend generally to be stricter at parsing c++,
but otherwise compatible with previous versions.
Supporting VS2008 is more work because of its project file format
change.
On Thu, Feb 19, 2009 at 10:28 AM, Darin Fisher da...@chromium.org wrote:
We don't have
You are trying to deal with these fields:
std::vectorunsigned short text;
std::vectorunsigned short unmodified_text;
std::vectorunsigned short key_identifier;
Right?
Is it really the case that those are unbounded in length? Or, is there some
small max length that they can be? Maybe 2 or 4
. That is a more disruptive change, and only adds cost to Windows
and Linux.
-Darin
On Thu, Feb 19, 2009 at 11:37 AM, Avi Drissman a...@google.com wrote:
On Thu, Feb 19, 2009 at 2:35 PM, Darin Fisher da...@chromium.org wrote:
std::vectorunsigned short text;
std::vectorunsigned short
that.
Sound good?
Avi
On Thu, Feb 19, 2009 at 2:37 PM, Avi Drissman a...@google.com wrote:
On Thu, Feb 19, 2009 at 2:35 PM, Darin Fisher da...@chromium.org wrote:
std::vectorunsigned short text;
std::vectorunsigned short unmodified_text;
std::vectorunsigned short key_identifier
I'll cap it at, say, four, and
LOG(ERROR) if we get more than that.
Sound good?
Avi
On Thu, Feb 19, 2009 at 2:37 PM, Avi Drissman a...@google.com wrote:
On Thu, Feb 19, 2009 at 2:35 PM, Darin Fisher da...@chromium.org
wrote:
std::vectorunsigned short text;
std::vectorunsigned
V8somethingsomething.cpp, SVGNames.h,... and
wanted to cry.
I then repeated the steps but used gclient sync --force, and things seem to
be building smoothly now. Just mentioning in case someone else is suffering
from this, sorry Im not being very precise!
On Thu, Feb 19, 2009 at 10:54 AM, Darin Fisher da
, 2009 at 12:16 PM, Pam Greene p...@chromium.org wrote:
Do we plan to live on the edge of the wave once we're entirely unforked,
and never do merges again?
- Pam
On Fri, Feb 20, 2009 at 11:01 AM, Darin Fisher da...@chromium.org wrote:
This sounds good to me as a temporary measure while we
.
new tests from webkit merges that fail)
2. Same as proposal 1, except we also add a NOTIMPLEMENTED option for the
tests of features we haven't turned on yet.
Preferences? I'm happy to make either one happen.
Ojan
On Fri, Feb 20, 2009 at 12:33 PM, Darin Fisher da...@chromium.org wrote
mbel...@google.com wrote:
Maybe turn of crash reporting when these flags are enabled?
Mike
On Mon, Mar 2, 2009 at 4:49 PM, Darin Fisher da...@chromium.org wrote:
Wow... we definitely have re-entrancy bugs with --in-process-plugins that
are not worth fixing.
Command line options like
Yeah, that's a fair point. We'd probably always ask interested users to try
a Chromiumbuild before anything else if they are experiencing a Google
Chrome bug.
-Darin
On Mon, Mar 2, 2009 at 4:53 PM, John Abd-El-Malek j...@chromium.org wrote:
On Mon, Mar 2, 2009 at 4:49 PM, Darin Fisher da
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: ‘MyTest_ATest_Test’ has a field
at 4:30 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like
I think the merger should be responsible for ensuring that any layout test
fallout from the merge gets resolved. This doesn't mean necessary fixing
everything, but rather it can be mean reaching out to others for help.
I think the merger has to have incentive not to create a big mess with the
with.
On Wed, Mar 4, 2009 at 4:44 PM, David Levin le...@google.com wrote:
Aren't we trying to get rid of the merge process (soon-ish)?
If so, how would layout tests get fixed at that point?
Dave
On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher da...@chromium.orgwrote:
I think the merger should
of the person
who happened to bring the changes in.
- Pam
On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher da...@chromium.org wrote:
I think the merger should be responsible for ensuring that any layout test
fallout from the merge gets resolved. This doesn't mean necessary fixing
everything, but rather
1 - 100 of 340 matches
Mail list logo
