If people need things moved to base, you can file a bug against me.
During this refactor, it would be nice to also have the opposite, a
clean dependencies on what uses views. For Linux we would like to
build without views. Right now there are dependencies from outside of
views/ to views/.
The deps for all the files generated is a problem, Mark and I have talked
about it a few times, but haven't come up with something complete for it
yet, hopefully it will pop back up on our queues shortly so we can figure
out something more complete.
TVL
On Mon, Apr 27, 2009 at 6:14 PM, Evan
You really should take a look ASAP because yesterday, the mac try
slaves were like 35+ jobs being. That makes mac testing inexistent and
will just cause more mac breakage. I assume today, tomorrow, etc will
be as bad.
You can be our sheriff in the meantime if you want. :)
M-A
On Tue, Apr 28,
Yes, this is certainly a direct cause of making a null build on mac
take far, far longer than it should.
Can we just back out Tony's change that was made in the rules to go
back to the way things were in the short term?
On Tue, Apr 28, 2009 at 11:31 AM, Marc-Antoine Ruel mar...@chromium.org
On Mon, Apr 27, 2009 at 6:47 PM, Glen Murphy g...@chromium.org wrote:
I have zero need for the layout tests, yet I've never been able to set
up a client without them - even with the suggested custom_deps line, I
still get them.
I've tried deleting my webkit dir, a carpet-bomb custom deps
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.
Mike is right that it causes null builds to be slower.
I'm happy to rollback, it doesn't matter either way for me, but
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
On Tue, Apr 28, 2009 at 10:26 AM, Mark Mentovai m...@chromium.org wrote:
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
In http://codereview.chromium.org/99132 , I split one library into two.
This worked fine up until the Windows build, which only uses gyp
halfway, got the change to use the split library but didn't get the
change to fix consumers of the library. :(
Is there any reasonable way to work through
Hi Evan,
I'll take a look.
Once we switched completely the msvs_guid's can go away (it will generate
stable but random ones).
-BradN
On Tue, Apr 28, 2009 at 12:31 PM, Evan Martin e...@chromium.org wrote:
In http://codereview.chromium.org/99132 , I split one library into two.
This worked fine
For reference, here was the failure:
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/4079/steps/compile/logs/stdio_html
It needed to depend on this new main lib from gtest.
On Tue, Apr 28, 2009 at 12:34 PM, Bradley Nelson bradnel...@google.com wrote:
Hi Evan,
I'll
It's not urgent at all.
On Tue, Apr 28, 2009 at 1:06 PM, Bradley Nelson bradnel...@google.com wrote:
Hi Evan,
I'm doing a similar change now to migrate v8.gyp from temp_gyp to src/v8.
Once I get that working I'll see if I can get this change working.
If it isn't urgent, it might be easier to
Hi Chromium Developers,
I'm working on Google's O3D (http://code.google.com/p/o3d), and we
(naturally) share some of Chrome's base classes for our code, including the
very useful class FilePath.
However, in using FilePath in the last few months, I've seen that it needs
some refinement. I'd like
On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer gspen...@google.com wrote:
Hi Chromium Developers,
I'm working on Google's O3D (http://code.google.com/p/o3d), and we
(naturally) share some of Chrome's base classes for our code, including the
very useful class FilePath.
However, in using
- Having used this for a while, my main feedback is that that icons
are subtle enough that I don't notice them.
It's possible they're playing into my subconscious, but it doesn't
feel that way.
- It's a little strange that starred entries in the result list have
the *empty* star as their icon.
On Tue, Apr 28, 2009 at 1:39 PM, Greg Spencer gspen...@google.com wrote:
1) I'd like to add some explicit routines for converting to/from UTF8 and
UTF16. While it's nice (and important) that FilePath uses the platform's
native string, we've found that many third party libraries have made
On Tue, Apr 28, 2009 at 1:57 PM, Thomas Van Lenten thoma...@chromium.orgwrote:
On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer gspen...@google.com wrote:
4) Make sure we handle case sensitivity vs case preservation correctly.
It's unclear to me that FilePath does this correctly on the Mac --
On Tue, Apr 28, 2009 at 1:39 PM, Greg Spencer gspen...@google.com wrote:
1) I'd like to add some explicit routines for converting to/from UTF8 and
UTF16. While it's nice (and important) that FilePath uses the platform's
native string, we've found that many third party libraries have made
On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer gspen...@google.com wrote:
1) I'd like to add some explicit routines for converting to/from UTF8 and
UTF16. While it's nice (and important) that FilePath uses the platform's
native string, we've found that many third party libraries have made
On Tue, Apr 28, 2009 at 2:31 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Apr 28, 2009 at 1:39 PM, Greg Spencer gspen...@google.com wrote:
1) I'd like to add some explicit routines for converting to/from UTF8 and
UTF16. While it's nice (and important) that FilePath uses the
On Tue, Apr 28, 2009 at 2:48 PM, Greg Spencer gspen...@google.com wrote:
So, I was unable to find the conversion utilities in base that do the
conversion to/from UTF8. What are they called? If I missed them (and I
looked for a while before I gave up), then maybe they need to be more
(resend - arg)
On Tue, Apr 28, 2009 at 2:47 PM, Greg Spencer gspen...@google.com wrote:
On Tue, Apr 28, 2009 at 2:41 PM, Amanda Walker ama...@chromium.orgwrote:
On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer gspen...@google.com
wrote:
1) I'd like to add some explicit routines for
On Tue, Apr 28, 2009 at 3:19 PM, Greg Spencer gspen...@google.com wrote:
On Tue, Apr 28, 2009 at 3:11 PM, Erik Kay erik...@google.com wrote:
The biggest problem with this change is that it's not possible to do this
conversion on Linux in a safe way.
And besides -- this problem isn't
On Tue, Apr 28, 2009 at 3:19 PM, Greg Spencer gspen...@google.com wrote:
On Tue, Apr 28, 2009 at 3:11 PM, Erik Kay erik...@google.com wrote:
The biggest problem with this change is that it's not possible to do this
conversion on Linux in a safe way. In Linux, there is no charset defined by
On Tue, Apr 28, 2009 at 3:26 PM, Erik Kay erik...@chromium.org wrote:
On Tue, Apr 28, 2009 at 3:19 PM, Greg Spencer gspen...@google.com wrote:
But that's exactly the point. FilePath is the class that created the path
to begin with. So it can know what the LC_*/LANG variables were was when
Yes, yes, I know this is a horrible idea, but please hear me out :-)
Last week, a couple of us (Darin F, Michael N, Jeremy M, and I) had lunch at
Apple to talk to talk about sharing more code. HTML 5 brings with it a lot
of APIs that reach outside of the top level browsing context boundary
Hi All,
Due to some last minute integration issues this will get pushed to 8pmPDT.
Wish me luck!
-BradN
On Mon, Apr 27, 2009 at 4:51 PM, Steven Knight s...@chromium.org wrote:
Brad Nelson is planning to close the tree some time tomorrow night (Tuesday
28 April) to land the conversion of
On Tue, Apr 28, 2009 at 5:27 PM, Michael Nordman micha...@google.comwrote:
In some sense we do have separate process in which to run sandboxed
'backend' code relevant to multiple renders if the need arises... the
worker process.
The way you stated this is a bit odd, but on the surface I
I have always felt like running the WebCore backend in the browser
process with an IPC channel between it and the frontend was a really
elegant design for this problem. And I never really understood why we
weren't allowed to depend on WebCore (even indirectly) in the browser
process. Is the idea
Well, the question comes down to this: Can we trust running small amounts of
WebCore in the browser process.
Historically, the answer to running WebCore in the browser has been a
resounding no. Can you please explain what you think has changed since such
decisions were made (or why it's time to
+ chromium-dev
Can you please explain what you think has changed since such decisions were
made (or why it's time to revisit such decisions)?
I don't think there was code in webcore suitable for this purpose
before... html parsing, javascript,sql interpretting... all dangerous
from a
On Tue, Apr 28, 2009 at 6:26 PM, Evan Martin e...@chromium.org wrote:
On Tue, Apr 28, 2009 at 5:59 PM, Aaron Boodman a...@chromium.org wrote:
Is the idea that someday the browser and renderer processes
might be separate binaries?
Though this shouldn't drive your decision, about 50% of our
Yup. I am not saying we need to get rid of all of it immediately; just put
some comments in the header so that we don't use it *more*.
Mike
On Tue, Apr 28, 2009 at 6:38 PM, Feng Qian fq...@google.com wrote:
CppBindingClass was started for test_shell if I remember correctly,
and I think
The tree is closed. Several people are seeing the following error when
compiling on Windows:
Error 1 fatal error C1083: Cannot open source file:
'..\..\..\chrome\Debug\obj\global_intermediate\libraries.cc': No such
file or directory c1xx
Error 2 fatal error LNK1181: cannot
It looks like the missing dependency did the trick: both clobber of
Chromium builder and clean local build work now. Can haz open tree?
:DG
On Tue, Apr 28, 2009 at 9:04 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
Testing the fix ...
:DG
On Tue, Apr 28, 2009 at 8:36 PM, Bradley Nelson
Yes I think so.-BradN
On Tue, Apr 28, 2009 at 9:20 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
It looks like the missing dependency did the trick: both clobber of
Chromium builder and clean local build work now. Can haz open tree?
:DG
On Tue, Apr 28, 2009 at 9:04 PM, Dimitri Glazkov
36 matches
Mail list logo
