How about this one?
(Follow the same instructions I gave you earlier)
http://groups.google.com/group/chromium-dev?hl=en
http://groups.google.com/group/chromium-dev?hl=en
☆PhistucK
On Thu, Dec 10, 2009 at 09:02, canbo2000 canbo2...@gmail.com wrote:
i found there's no such path,i can't
Thanks Mark.
BTW, do you guys know of lists or wiki I could get more information
regarding GYP tool?
On Wed, Dec 9, 2009 at 5:40 PM, Mark Mentovai m...@chromium.org wrote:
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
http://code.google.com/p/gyp has some wiki pages.
On Thu, Dec 10, 2009 at 10:49 AM, Igor Gatis igorga...@gmail.com wrote:
Thanks Mark.
BTW, do you guys know of lists or wiki I could get more information
regarding GYP tool?
On Wed, Dec 9, 2009 at 5:40 PM, Mark Mentovai m...@chromium.org
http://code.google.com/p/gyp/w/list
On Thu, Dec 10, 2009 at 18:49, Igor Gatis igorga...@gmail.com wrote:
Thanks Mark.
BTW, do you guys know of lists or wiki I could get more information
regarding GYP tool?
On Wed, Dec 9, 2009 at 5:40 PM, Mark Mentovai m...@chromium.org wrote:
There's
On Thu, Dec 10, 2009 at 2:44 AM, Ian Hickson i...@google.com wrote:
I'd recommend switching to a mixed content lock whenever any
interaction occurs with any insecure content (unencrypted or imperfect
cert), whether that be posting to an http:// window with
postMessage(), receiving a message
John,
I build this target daily on Vista64, so I believe the problem is not caused
by building on Vista alone. Also, disabling nacl won't help in this case -
the flag does not disable the 64-bit targets. However, Chrome does not
depend on the 64-bit targets at this stage, they are only built as
This is back in. XSLT is no longer required (though it doesn't hurt to
have it), and it seems some machines are also missing bzip2 headers,
so for Hardy, the new command to install the deps is:
sudo apt-get install -y libbz2-dev libjpeg62-dev
After you update your packages and sync your sources,
Automatically closing tree for compile on Webkit Linux (valgrind)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%29/builds/7663
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%29
--= Automatically closing tree for
Automatically closing tree for compile on Linux Perf
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/4401
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Perf
--= Automatically closing tree for compile on Linux Perf =--
Revision: 34252, 34253,
http://code.google.com/p/chromiumembedded/.
Marshall would probably appreciate to have some help.
On Thu, Dec 10, 2009 at 12:43 PM, hap 497 hap...@gmail.com wrote:
Hi,
Is it possible to embed a chromium in my c/c++ application? (just like
someone embed a Webkit rendering engine in his
On Thu, Dec 10, 2009 at 1:24 PM, Marc-Antoine Ruel mar...@chromium.orgwrote:
http://code.google.com/p/chromiumembedded/.
Marshall would probably appreciate to have some help.
More help is always welcome :-)
On Thu, Dec 10, 2009 at 12:43 PM, hap 497 hap...@gmail.com wrote:
Hi,
Is it
2009/12/10 Brett Wilson bre...@chromium.org
On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek j...@chromium.org
wrote:
btw I searched the code, almost all the instances are in code from
different
repositories, like v8, gtest, gmock. I counted only 17 instances in
Chrome's code.
Most
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)
On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.org wrote:
2009/12/10 Brett Wilson bre...@chromium.org
On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek j...@chromium.org
wrote:
btw I searched the code, almost all the instances are in code from
different
repositories,
Why then do you think vandebo and I hit this error? Or is this an error
from a subbuild whose result is ignored so the build otherwise works?
jrg
On Thu, Dec 10, 2009 at 9:31 AM, Gregory Dardyk grego...@google.com wrote:
John,
I build this target daily on Vista64, so I believe the problem is
Hey everyone, I noticed I'm on the hook for sheriff duty on Dec 18/21
(Friday/Monday) but I was hoping to be taking vacation during that
time. Does someone want to swap with me?
Thanks in advance!
--
Mike Pinkerton
Mac Weenie
pinker...@google.com
--
Chromium Developers mailing list:
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
On Thu, Dec 10, 2009 at 11:14:32AM -0800, 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)
On Thu, Dec 10, 2009 at 11:20 AM, Jacob Mandelson ja...@mandelson.orgwrote:
If something extra in an expression is a common case, I've sometimes
seen it done like:
return DoWork(foo) POSIX_ONLY( DoWork(posix_specific));
where POSIX_ONLY will expand to nothing or its argument.
It's ugly,
On Thu, Dec 10, 2009 at 2:24 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Dec 10, 2009 at 11:20 AM, Jacob Mandelson ja...@mandelson.org
wrote:
If something extra in an expression is a common case, I've sometimes
seen it done like:
return DoWork(foo) POSIX_ONLY(
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.
Automatically closing tree for compile on Chromium Builder
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/20216
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder
--= Automatically closing tree for compile on Chromium Builder =--
On Thu, Dec 10, 2009 at 3:02 PM, Shall be Unnamed @google.com wrote:
On Thu, Dec 10, 2009 at 2:29 PM, Marc-Antoine Ruel mar...@chromium.orgwrote:
On Thu, Dec 10, 2009 at 2:24 PM, Peter Kasting pkast...@google.com
wrote:
On Thu, Dec 10, 2009 at 11:20 AM, Jacob Mandelson ja...@mandelson.org
On Mon, Dec 7, 2009 at 1:43 PM, Bradley Nelson bradnel...@google.com wrote:
Hello All,
Last week I re-landed a change to split off parts of chrome.gyp into .gypi's
in the same directory.
I had done something similar a couple weeks back, but took it out because
concern was raised about merge
I have similar concern about our build, in a way we handle different
configurations.
There are several ways to specify a set of files for different
configurations, such as suffic (_gtk/_mac),
source!, exclude/include, concat file lists, and I'm worrying that
it's getting out of control.
I'm
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.orgwrote:
In essence:
return DoWork(foo)
#if defined(OS_POSIX)
DoWork(posix_specific)
#endif
; // -- Lint complains about this guy
I'd
Automatically closing tree for compile on Linux Builder (ChromiumOS)
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/1213
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29
--= Automatically closing
On Thu, Dec 10, 2009 at 1:02 PM, oshima osh...@chromium.org wrote:
I have similar concern about our build, in a way we handle different
configurations.
There are several ways to specify a set of files for different
configurations, such as suffic (_gtk/_mac),
source!, exclude/include, concat
Automatically closing tree for compile on Chromium Builder (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/14559
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29
--= Automatically closing tree for
On Thu, Dec 10, 2009 at 1:22 PM, Evan Stade est...@chromium.org wrote:
On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.comwrote:
On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.orgwrote:
In essence:
return DoWork(foo)
#if defined(OS_POSIX)
On Fri, Dec 11, 2009 at 04:08, Sofia Tahseen sofia.tahs...@gmail.com wrote:
You are so right, Joel... I corrected my .so and now I could build the
chrome browser ...finally!!
I copied the whole /src/out/Release directory
While it's not important, that is unnecessary. This directory
contains
Summary:
We're increasing sharding for running webkit tests and it's increasing test
flakiness a bit.
1. Is the tradeoff of (hopefully) temporary increased flakiness worth the
speed gains? We retry these failures, so they rarely actually turn the bots
red,
2. The flakiness is temporary only if we
I expect that WebKit folks would be willing to help flight WebKit test
flakyness once we move more of our testing infrastructure into the
svn.webkit.org repository.
You might make a similar plea for help on webkit-dev, although I doubt
you'll get a super-positive response until webkit folks can
Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a Windows
.dll on the Mac.
Huh? Then I went to look at the docs (
http://code.google.com/chrome/extensions/npapi.html):
{
name: My extension,
...
*plugins: [
{
Filed http://code.google.com/p/chromium/issues/detail?id=30052 .
Avi
On Thu, Dec 10, 2009 at 7:03 PM, Avi Drissman a...@chromium.org wrote:
Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a
Windows .dll on the Mac.
http://codereview.chromium.org/492012
So the design is for every platform to try to load all plugins. We don't
even want to have a hint that allows the website to say this is
Windows-only?
How about from the browser perspective? Is failure to load a library a fatal
error? (Sorry, we can't load
Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
because we didn't like any of the alternatives. (Even if we do have a
manifest syntax for it, the extension package becomes bloated with plugin
binaries for other platforms.) But I didn't realize that it could cause a
Can we at least deny installing the extension in Chromium if it contains
plugins that cannot be used in that operating system for now until a better
design for cross-platform manifest?
- Mohamed Mansour
On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry mpcompl...@chromium.org wrote:
Yeah, that's
The crash is fixed. But the fact that we're now expecting random dll loads
to fail prevents us from giving good UI to users, and not labelling what
platforms it'll work on prevents us from warning in advance.
Imagine a million angry Mac and Linux users filing bugs because their
favorite extension
Can we have the syntax say platform x loads x.dll, platform y loads y.so,
etc?
If a dll required by a platform fails to load, we need to alert the user
that their extension is busted. The prospect of having failure to load
binaries be an expected thing scares me.
Avi
On Thu, Dec 10, 2009 at
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
Andy sent me a CL for review about an extension crashing
(http://crbug.com/29584). Turns out the cause was a failure to load a
Windows .dll on the Mac.
We have had threads on this before. The consensus was that it was
On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman a...@google.com wrote:
Can we have the syntax say platform x loads x.dll, platform y loads y.so,
etc?
Yes that is the idea.
If a dll required by a platform fails to load, we need to alert the user
that their extension is busted. The prospect of
It is good that we can avoid the crash. We do need to get some kind of
syntax in the manifest.
- a
On Thu, Dec 10, 2009 at 4:18 PM, Avi Drissman a...@google.com wrote:
The crash is fixed. But the fact that we're now expecting random dll loads
to fail prevents us from giving good UI to users,
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
If we had something like:
plugins: {
mac: ...
win: ...
linux: ...
}
FWIW, one reason to avoid this sort of thing is that there is really
no single thing called linux to target. For example, because our
builds of
Is there a timetable? http://crbug.com/14936 has been Mstone-Xed since June.
Avi
On Thu, Dec 10, 2009 at 7:30 PM, Aaron Boodman a...@google.com wrote:
On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman a...@google.com wrote:
Can we have the syntax say platform x loads x.dll, platform y loads
On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin ev...@google.com wrote:
Distributing binaries on Linux = sadness, as the Flash guys will tell
you.
[...]
In summary, all I offer you is more problems and the plea that we
should really really deter people from doing this kind of thing. I
imagine
Don't forget x64 user... ;)
On Dec 10, 7:03 pm, Avi Drissman a...@chromium.org wrote:
plugins: {
mac: ...
win: ...
linux: ...
}
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
On Thu, Dec 10, 2009 at 4:38 PM, Avi Drissman a...@google.com wrote:
On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin ev...@google.com wrote:
Distributing binaries on Linux = sadness, as the Flash guys will tell
you.
[...]
In summary, all I offer you is more problems and the plea that we
On Thu, Dec 10, 2009 at 7:55 PM, Ojan Vafai o...@google.com wrote:
I think we can wait to see what percentage of extensions actually include
binaries before devoting too much time to this. Our expectation is that this
will be a very small percentage, right?
Quick, look at
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a
Windows .dll on the Mac.
Huh? Then I went to look at the docs (
On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai o...@chromium.org wrote:
I think we can wait to see what percentage of extensions actually include
binaries before devoting too much time to this. Our expectation is that this
will be a very small percentage, right?
If we give people the
On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:
Q: Can't we have the extensions gallery warn that it won't work?
A: Sorry, we can't do that in an automated fashion. The extensions author
should mention it. Too bad they don't.
But we explicitly review patches with binary
On Thu, Dec 10, 2009 at 5:05 PM, Avi Drissman a...@google.com wrote:
On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai o...@chromium.org wrote:
I think we can wait to see what percentage of extensions actually include
binaries before devoting too much time to this. Our expectation is that this
We do? I didn't know that. Then we should enforce some kind of labeling.
Avi
On Thu, Dec 10, 2009 at 8:12 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:
Q: Can't we have the extensions gallery warn that it won't work?
A:
Or reject extensions that could be written without a NPAPI component.
*ducks*
On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:
Q: Can't we have the extensions gallery warn that it won't work?
A:
Much of what can't be done on the web platform also can't be done inside the
NaCl sandbox.
On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek
jabdelma...@google.comwrote:
NaCl is the answer to all these problems...
On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow jor...@google.com wrote:
Or
NaCl is the answer to all these problems...
On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow jor...@google.com wrote:
Or reject extensions that could be written without a NPAPI component.
*ducks*
On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.comwrote:
On Thu, Dec 10, 2009 at
The goal is to expose all this through Pepper.
On Thu, Dec 10, 2009 at 5:50 PM, Jeremy Orlow jor...@chromium.org wrote:
Much of what can't be done on the web platform also can't be done inside
the NaCl sandbox.
On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek jabdelma...@google.com
Yes, extensions that include NPAPI are a very small minority. Last
time I checked there were something like 5. It is a way out for people
who already have binary code that they would like to reuse, or who
need to talk to the platform.
I don't see what the big deal is about a few extensions only
Hi all,
If you never run the webkit layout tests, you can stop reading.
Otherwise, earlier today I checked in a patch that should make the
output much less verbose in the normal case. From the CL:
First, a number of log messages have had their levels changed (mostly to
make them quieter).
Have you considered making the output closer to that of WebKit's
run-webkit-tests?
It seems that would ease the hopeful transition to this version upstream.
dave
On Thu, Dec 10, 2009 at 7:23 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
If you never run the webkit layout tests, you
After reading the WebGL blog post today, and following the link to the wiki,
it struck me as fairly *bad* that we are telling people to disable the
sandbox. A good number of folks are going to disable the sandbox and forget
that they had ever done so.
Once we can support WebGL in the sandbox,
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:
Perhaps --enable-webgl should instead implicitly disable the sandbox today
I think this is better than having users manually disable it. They'll be
running without a sandbox either way, but this (a) makes the enabling
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:
After reading the WebGL blog post today, and following the link to the
wiki, it struck me as fairly *bad* that we are telling people to disable the
sandbox. A good number of folks are going to disable the sandbox and
On Thu, Dec 10, 2009 at 9:29 PM, Jeremy Orlow jor...@google.com wrote:
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:
After reading the WebGL blog post today, and following the link to the
wiki, it struck me as fairly *bad* that we are telling people to disable the
We disable --single-process and --in-process-plugins on release Google
Chrome builds to avoid the support headache that it causes. I think we
should do the same for --no-sandbox.
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:
After reading the WebGL blog post today,
I wonder... should we show an infobar on startup when the sandbox is
disabled?
On Thu, Dec 10, 2009 at 21:38, John Abd-El-Malek j...@chromium.org wrote:
We disable --single-process and --in-process-plugins on release Google
Chrome builds to avoid the support headache that it causes. I think
That would be nice to have. Everyone agrees that is a critical option to
turn on, so a light red tone info bar would be great for that.
-Mohamed Mansour
On Fri, Dec 11, 2009 at 12:49 AM, Finnur Thorarinsson
fin...@chromium.orgwrote:
I wonder... should we show an infobar on startup when the
Yes, I did consider that. The fatal flaw in that plan is that the
webkit test script is single-threaded and runs through the tests in
order. Ours doesn't, and so we can't easily guarantee the same sort of
output they have. Eric and I will probably work through this as we
upstream the code. I'm
On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.org wrote:
We disable --single-process and --in-process-plugins on release Google
Chrome builds to avoid the support headache that it causes. I think we
should do the same for --no-sandbox.
There are legit reasons we have
Automatically closing tree for compile on Webkit Linux (valgrind)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%29/builds/7715
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%29
--= Automatically closing tree for
On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote:
On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote:
We disable --single-process and --in-process-plugins on release
Automatically closing tree for test_shell_tests on Webkit Mac10.5 (dbg)(3)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20%28dbg%29%283%29/builds/8163
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Mac10.5%20%28dbg%29%283%29
--= Automatically
On Thu, Dec 10, 2009 at 10:57 PM, Dirk Pranke dpra...@chromium.org wrote:
We could do this, but we'd have to add logic to track when directories
were done, and arbitrarily delay printing results about other
directories (hence delaying and serializing results). This might end
up causing
I don't think we should take away --no-sandbox in official builds. It's a
valuable debugging tool in case an end-user is experiencing a startup crash
or other wackiness.
I think we should just add a modal dialog at startup that you must dismiss
each time you launch Chrome until you remove the
75 matches
Mail list logo
