A cleaner more generalized solutions sounds excellent to me. Adapting
consumers to that incrementally is a plus if you can do it.
It might help the discussion if you could toss out a proposal for what you
think might work.
-Darin
On Mon, Nov 30, 2009 at 1:59 PM, Paweł Hajdan Jr.
On Mon, Nov 30, 2009 at 10:01 PM, Antony Sargent asarg...@chromium.orgwrote:
I just updated to revision 33425, and a clean build (manually deleted Debug
directory before opening .sln file) gives the following error in
service_runtime_x86. I'm running Visual Studio 2008 on Vista x64. Anyone
Dear:
Never build chromium by Visual Studio 2008 + SP1, otherwise, you will
get huge performance penalty
***Visual Studio 2008 C++ code slower than Visual Studio 2005***
Please check the following link:
Sorry:
.I can only get about 34xx score if i built chromium
by VS2005, but I get 23xx score if I built with VS2008, the
performance difference is huge( 34xx vs 23xx)
should be:
.I can get about 34xx score if i built chromium
by VS2005, but I only get 23xx score if I built with VS2008, the
Automatically closing tree for compile on Webkit Linux (valgrind)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%29/builds/7118
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%29
--= Automatically closing tree for
Dear chromiumers,
Relatively recently I stopped seeing information about revisions for
build bot graphs. If I open our debugger it reports something like:
Uncaught TypeError: Cannot call method 'slice' of undefined.
Line number it gives is incorrect. Most probably it should be actually line
Are the buildbots archiving the intermediate builds before building
the final executable?
If they do, where are they saving them? are they available to
download?
If they don't, it would be pretty good if the masters of buildbots
could assist in this topic :)
As we talked in this thread:
Thanks for the notice but we have good performance regression testing.
Also, the official builds don't use /O2. Only the continuous build uses /O2.
IIRC, VS2008 RTM cannot be used to build Chromium.
M-A
On Tue, Dec 1, 2009 at 4:54 AM, avcoder ffm...@gmail.com wrote:
Sorry:
.I can only get
I had intention in archiving the intermediate build outputs in a shallow git
repo for try server speedup but I have no intention in publishing this repo
externally. I would recommend you to checkout the buildbot code and setup a
local continuous build yourself.
Instructions:
repost from right account...
-- Forwarded message --
Date: Tue, Dec 1, 2009 at 10:50 AM
Subject: Re: [chromium-dev] Where buildbot outputs the intermediate builds?
To: robj.pe...@gmail.com
Cc: Chromium-dev chromium-dev@googlegroups.com
On Tue, Dec 1, 2009 at 10:27 AM, Roberto
We do now:
7433107 Add preference to Xcode to automatically add newline to end of
file
Cheers,
Dave
On Dec 1, 2009, at 5:29 AM, Thomas Van Lenten wrote:
Dave - do you have a radar for the trailing newline also?
TVL
On Tue, Dec 1, 2009 at 12:39 AM, Dave MacLachlan dmacl...@chromium.org
*UI Jank Task Force Status Update*
The UI Jank Task Force is out to fix UI Jank and slowness in the browser. A
list of open Jank bugs is here: http://code.google.com/
p/chromium/issues/list?q=label:Jank (feel free to take one!)
*Updates*
John
- Bug fixing
- Last shutdown file Lookup on
I've tried a few combinations of deleting my Debug directory and running
gclient runhooks, and I *think* I've narrowed the problem down to the
build failing if do a command-line build, but working ok if I build from
within the Visual Studio GUI. The script I have which does the (now failing)
Automatically closing tree for taskkill on XP Perf (1)
http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf%20%281%29/builds/1643
http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Perf%20%281%29
--= Automatically closing tree for taskkill on XP Perf (1) =--
On Mac* the WebCore Xcode project has a separate build target
webcore_bindings that contains DerivedSourcesAllInOne.cpp and a
handful of other files. This setup is really slowing down the build
process on my Mac Pro, because DerivedSourcesAllInOne takes much
longer to compile than any of
DerivedSourcesAllInOne.cpp is the biggest bottleneck on Linux too.
Even when running make with a high -j value, one would end up in the
situation where one core is pegged for more than a minutes while all
the others sit idle.
On Tue, Dec 1, 2009 at 10:57 AM, Lei Zhang thes...@google.com wrote:
Hi chomium-dev,
When could we add context menu items in an extension? I really which
at least there would be something like FlashGot or DownloadThemAll for
Chrome.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
Hi Antony,
My fixes arrived at 33433. Did you sync that before trying the above?
I hadn't validated command line builds (I'm checking that myself now).
Oh by the way, I assume you're using /Out because of devenv.exe 's weird
console piping behavior.
Something we learned with the bots is that if
Can you be more specific? I gather you mean the revision information at the
bottom of the performance graphs, when you select a data point on the graph.
I just tried one at random (Page Cycle Intl1 - XP Perf) and it seems to be
working correctly. What exactly causes this error?
Thanks,
- Pam
On
Good day, Pam.
On Tue, Dec 1, 2009 at 11:13 PM, Pam Greene p...@chromium.org wrote:
Can you be more specific? I gather you mean the revision information at the
bottom of the performance graphs, when you select a data point on the graph.
Precisely, one with SVN path, revision range, etc.
I
Hi, Anton,
Thanks for the additional information. I tried several points on that graph.
They didn't show any revision information at first, but a few seconds later
the frame loaded. Now I can look at other data points without any delay.
Since it works sometimes, I suspect that the problem is in
Hmmn, ok builds for me at the command line. I'll drop by in a bit.
-BradN
On Tue, Dec 1, 2009 at 11:00 AM, Bradley Nelson bradnel...@google.comwrote:
Hi Antony,
My fixes arrived at 33433. Did you sync that before trying the above?
I hadn't validated command line builds (I'm checking that
Looks like there are more tests that failing in valgrind test.
shard=1 id=1513
[ FAILED ] WorkerTest.MultipleWorkers (103254 ms)
[ FAILED ] NewTabUITest.ChromeInternalLoadsNTP (74002 ms)
[ FAILED ] ChromeMainTest.AppLaunch (36539 ms)
shard=2 id=1916
[ FAILED ]
Should the various browser vendors try to use common iconography for
geolocation, similar to how a standard symbol for Web Feeds emerged?
The external consistency would likely help users as they moved between
multiple apps and sites that support geolocation.
-Alex
On Nov 28, 2009, at 5:07
On Tue, Dec 1, 2009 at 2:30 PM, oshima osh...@chromium.org wrote:
Looks like there are more tests that failing in valgrind test.
...
This is not good. Is there any issue if we make a valgrind test fail when
the test itself fails?
If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt
On Tue, Dec 1, 2009 at 6:07 PM, Alex Faaborg faab...@mozilla.com wrote:
Should the various browser vendors try to use common iconography for
geolocation, similar to how a standard symbol for Web Feeds emerged?
The external consistency would likely help users as they moved between
multiple
On Tue, Dec 1, 2009 at 2:30 PM, oshima osh...@chromium.org wrote:
Looks like there are more tests that failing in valgrind test.
shard=1 id=1513
[ FAILED ] WorkerTest.MultipleWorkers (103254 ms)
[ FAILED ] NewTabUITest.ChromeInternalLoadsNTP (74002 ms)
[ FAILED ]
That is excellent! I didn't know there was such a thing.
Thanks,
Dave
On Tue, Dec 1, 2009 at 4:09 PM, oshima osh...@chromium.org wrote:
# Re-sending b/c gmail didn't use my account properly. Sorry if you get
this twice.
On Tue, Dec 1, 2009 at 3:53 PM, David Levin le...@chromium.org wrote:
1) Why green? The other infobars in the product are yellow.
Historically, green in browsers has signaled extended validation.
We had intended to use a few differently-colored infobars for a while,
but a more recent discussion (which got out of sync with the geo team;
my fault) has trimmed it
On Tue, Dec 1, 2009 at 4:13 PM, Glen Murphy g...@chromium.org wrote:
1) Why green? The other infobars in the product are yellow.
Historically, green in browsers has signaled extended validation.
We had intended to use a few differently-colored infobars for a while,
but a more recent
Automatically closing tree for unit_tests on Mac10.5 Tests
http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Tests/builds/9177
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Mac10.5%20Tests
--= Automatically closing tree for unit_tests on Mac10.5 Tests =--
# Re-sending b/c gmail didn't use my account properly. Sorry if you get this
twice.
On Tue, Dec 1, 2009 at 3:53 PM, David Levin le...@chromium.org wrote:
On Tue, Dec 1, 2009 at 2:30 PM, oshima osh...@chromium.org wrote:
Looks like there are more tests that failing in valgrind test.
I'd expect the icons in the mocks to be BSD licensed, which means
you'd be free to use them in Firefox if you liked them. Does Firefox
already have Geolocation iconography that we should consider? The
right folks to get on board are the members of the UI team. Glen's
probably the right person
No time frame, though they keep it in mind for the future.
☆PhistucK
On Tue, Dec 1, 2009 at 21:27, est electronix...@gmail.com wrote:
Hi chomium-dev,
When could we add context menu items in an extension? I really which
at least there would be something like FlashGot or DownloadThemAll for
34 matches
Mail list logo
